1. 项目概述为什么需要梳理Delphi的平台支持如果你是一个Delphi的老用户或者正考虑将某个历史悠久的桌面应用现代化那么“Delphi到底支持哪些平台”这个问题绝对是你绕不开的坎。从经典的Delphi 7到最新的Delphi 12.3或按版本号称为D12即Delphi 12 Athens再到即将到来的Delphi 13D13Embarcadero以及之前的Borland、CodeGear对平台支持的策略发生了翻天覆地的变化。尤其是在Delphi XE42013年这个关键节点之后FireMonkey框架的成熟和移动开发的兴起彻底改变了Delphi的生态。我见过太多项目在升级或迁移时因为对平台支持范围理解不清而踩坑。比如一个用Delphi XE2写的FireMonkey应用想直接编译到最新的macOS Sonoma上却发现链接器报错或者一个VCL老项目想尝试发布到Linux服务器却发现无从下手。这些问题的根源就在于没有一张清晰的“平台支持地图”。这篇文章我就结合自己从XE时代一路用到D12的经验以及官方文档和社区动态为你彻底梳理从Delphi XE4到Delphi 13基于当前已发布和预览信息所支持的平台和操作系统。这不是一份简单的列表我会重点解释每个平台支持背后的技术架构VCL vs. FireMonkey、编译器差异、部署要求以及在实际开发中你会遇到哪些“坑”和“惊喜”。无论你是维护遗产代码还是启动一个全新的跨平台项目这张地图都能帮你做出更明智的技术决策。2. Delphi XE4~XE8移动时代开启与FireMonkey的进化这个时期是Delphi转型的阵痛期与机遇期。Delphi XE42013年发布是一个里程碑它首次正式将iOS支持纳入产品线而XE5则加入了Android支持。至此Delphi凭借FireMonkeyFMX框架正式吹响了向移动平台进军的号角。2.1 核心平台支持矩阵XE4~XE8我们先看一张简表了解这个阶段的基础支持情况版本Windows (VCL)Windows (FMX)macOS (FMX)iOS (FMX)Android (FMX)XE4Win32 (32-bit)Win32, Win64❌ 不支持iOS (32-bit, DeviceSimulator)❌ 不支持XE5Win32Win32, Win64❌ 不支持iOS (32-bit)Android (ARMv7)XE6Win32Win32, Win64❌ 不支持iOS (32-bit)Android (ARMv7)XE7Win32Win32, Win64❌ 不支持iOS (32-bit)Android (ARMv7)XE8Win32Win32, Win64❌ 不支持iOS (32-bit)Android (ARMv7)关键解读与实操要点Windows的绝对主场这个时期Windows平台依然由经典的VCLVisual Component Library和新兴的FMX共同覆盖。VCL仅支持32位WindowsWin32这是其技术根基决定的。而FMX项目则可以编译为32位或64位Windows应用。对于需要原生Windows外观和极致性能的桌面应用VCL仍是首选对于希望代码能跨平台尤其是移动端的项目则必须选择FMX。移动平台的初探iOS从XE4开始支持但仅限于32位。这意味着你只能针对较老的iOS设备和模拟器进行开发。随着苹果在iOS 112017年后彻底停止对32位应用的支持用XE4~XE8编译的iOS应用早已无法提交到App Store甚至在新设备上无法运行。这是一个巨大的历史局限性。Android从XE5开始支持目标是ARMv7架构的处理器俗称32位ARM。这在当时覆盖了绝大多数Android设备。部署时需要配置Android SDK/NDK路径这是第一个让许多Windows开发者感到陌生的环节。macOS的缺席是的在这个阶段Delphi官方并不支持直接开发macOS桌面应用。虽然FMX框架设计时考虑了跨平台但macOS的编译器后端和配套框架尚未就绪。社区有一些非官方的移植方案如用Free Pascal编译但并非生产级选择。2.2 技术架构与踩坑实录这个阶段的跨平台可以概括为“同一套UI代码多个后端渲染器”。FMX框架在Windows上使用DirectX或GDI进行渲染在iOS上使用原生Core Graphics在Android上使用自定义的基于OpenGL的渲染引擎。这种设计带来了灵活性也引入了复杂性。我踩过的一个典型坑控件的像素级差异。在Windows上设计得完美无缺的界面在iOS或Android上可能出现布局错乱、字体渲染不一致、甚至某些特效如模糊、阴影表现迥异。这是因为不同平台底层图形API的行为不同。解决方案是必须进行真机多轮测试并使用TForm.Scaled属性、PlatformVariant风格以及条件编译{$IFDEF IOS}来微调每个平台的UI细节。绝对不要假设“一次设计处处完美”。另一个常见问题是第三方控件的兼容性。许多优秀的VCL控件库如DevExpress VCL, TMS, ComponentOne等在这个时期开始推出对应的FMX版本但功能完整度和稳定性往往滞后于VCL版。在选择控件时必须仔细核查其宣称支持的FMX平台列表并最好能找到试用版进行实际跨平台编译测试。我曾遇到一个图表控件在Windows FMX上工作正常但在Android上直接导致应用崩溃原因是其使用了某个不兼容的底层API。部署与签名也是大坑。为iOS应用申请开发者证书、配置Provisioning Profile、理解Ad Hoc与App Store发布的区别为Android应用生成Keystore、对齐Zip。这些流程对于传统的Windows开发者来说完全是新领域。XE系列自带的部署工具Deployment Manager虽然提供了一些帮助但很多细节仍需手动配置或通过命令行脚本完成。我的经验是尽早建立一套自动化构建和签名脚本可以节省大量后期调试时间。3. Delphi 10.x 系列柏林~悉尼64位、Linux与macOS的加入Delphi 10 Berlin2016年开启了10.x时代这是一个平台支持大幅扩展的时期。最重要的变化是64位编译器成为主流并且加入了Linux和macOS服务器端支持以及后来的macOS桌面端支持。3.1 平台支持的重大扩展版本Windows (VCL)Windows (FMX)macOS (FMX)iOS (FMX)Android (FMX)Linux Server10 BerlinWin32Win32, Win64❌ 不支持iOS (32-bit)Android (ARMv7)❌ 不支持10.2 TokyoWin32Win32, Win64❌ 不支持iOS (32 64-bit)Android (ARMv7)✅ 引入 (Console App)10.3 RioWin32Win32, Win64✅ 引入 (64-bit)iOS (64-bit)Android (ARMv7, ARM64)✅ 支持10.4 SydneyWin32Win32, Win64✅ 支持 (64-bit)iOS (64-bit)Android (ARMv7, ARM64)✅ 支持关键解读与实操要点iOS 64位支持10.2 Tokyo这是生死攸关的更新。从10.2 Tokyo开始Delphi的iOS编译器支持生成64位代码使得开发的App能够符合苹果App Store的上架要求并支持所有现代iOS设备。如果你有从XE时代遗留下来的iOS项目升级到10.2 Tokyo或更高版本是将其现代化的第一步。迁移过程通常比较平滑主要工作是重新配置开发证书和更新一些可能废弃的API。Android ARM64支持10.3 Rio随着64位Android设备的普及Google Play也逐步要求应用支持64位架构。10.3 Rio增加了对ARM64AArch64的支持。在项目配置中你可以选择同时生成ARMv7和ARM64的应用包APK或者只生成64位版本以减小包体积。注意如果你的项目使用了特定的原生库.so文件必须确保有对应的ARM64版本否则在64位设备上会崩溃。Linux服务器端支持10.2 Tokyo这是一个战略性的转变。Delphi开始不再局限于客户端UI应用而是进军服务器端领域。10.2 Tokyo引入了对Linux最初是Ubuntu和RHEL/CentOS的控制台应用程序支持。这意味着你可以用熟悉的Object Pascal编写Web API服务器配合框架如DelphiMVCFramework、后台服务、数据处理工具等并部署到廉价的Linux云服务器上。技术栈上它使用的是非UI的“可移植类库”很多VCL/FMX的UI控件不可用但核心的RTL、数据库访问FireDAC、网络Indy等都能正常工作。macOS桌面端支持10.3 Rio千呼万唤始出来。10.3 Rio终于带来了官方的macOS桌面应用开发能力。同样是基于FMX框架你可以将Windows上的FMX应用编译为64位的macOS应用.app。这背后是Embarcadero与苹果LLVM工具链的深度集成。实测体验第一次将Windows FMX应用编译到macOS上运行感觉非常奇妙。大部分业务逻辑代码无需修改但UI需要针对macOS的HIG人机界面指南进行调整例如菜单栏、窗口样式、字体渲染等。同样第三方控件的macOS兼容性需要重点评估。3.2 Linux与macOS开发的实操细节Linux服务器开发编译器使用LLVM-based的dcclinux64编译器。部署产出是一个标准的Linux ELF 64位可执行文件。你需要通过FTP/SCP等方式将其上传到Linux服务器。依赖库这是最大的坑。你的程序可能依赖一些系统库比如libc.so,libpthread.so等。在开发机上通常是WindowsDelphi通过一个“SysRoot”目录来模拟Linux环境其中包含了链接时需要的库文件。但务必注意开发机SysRoot中的库版本必须与目标服务器上的库版本兼容。最好使用与目标服务器相同或相近版本的Linux发行版作为SysRoot来源。我曾因为开发机使用Ubuntu 18.04的SysRoot而服务器是CentOS 7导致程序运行时链接失败。调试远程调试支持有限更多依赖日志输出。建议在代码中集成强大的日志系统如CodeSite或LoggerPro。macOS桌面开发编译器使用基于苹果Clang/LLVM的dccosx64编译器。开发环境必须在Windows主机上安装一台macOS虚拟机或拥有一台网络可达的macOS编译服务器Paserver。Delphi IDE将代码发送到macOS机器上进行编译和链接。签名与公证从macOS Catalina开始未签名的应用运行会受到诸多限制。你需要加入苹果开发者计划为应用签名甚至进行公证Notarization才能分发给其他用户。这个过程比iOS签名更复杂涉及创建开发者ID应用证书、配置Entitlements文件等。强烈建议在项目初期就搭建好签名流程不要等到发布前才处理。UI适配FMX在macOS上使用Cocoa后端。要尊重macOS的设计规范例如使用TMainMenu并正确设置NSMenu的属性处理“关于”窗口和偏好设置的标准位置等。可以使用TPlatformServices来调用一些平台特有的服务。4. Delphi 11/12/13 (ALEXANDRIA~)统一与深化瞄准未来从Delphi 11 Alexandria2021年开始Embarcadero的发布节奏和平台战略趋于稳定。目标很明确巩固并优化现有平台支持提升开发体验和代码质量同时为未来的新平台如ARM64 Windows铺路。Delphi 12 Athens和预览中的Delphi 13进一步强化了这一路线。4.1 现代Delphi的全平台视图版本Windows (VCL)Windows (FMX)macOS (FMX)iOS (FMX)Android (FMX)Linux ServerAndroid (FMX) 64-bitmacOS (ARM64)11 AlexandriaWin32Win32, Win6464-bit (Intel)64-bitARMv7,ARM6464-bit✅ 成熟支持❌ 仅Intel12 AthensWin32Win32, Win6464-bit (Intel)64-bitARMv7, ARM6464-bit✅✅实验性支持13 (预览)Win32Win32, Win64,ARM6464-bit (Intel/ARM)64-bitARMv7, ARM6464-bit✅✅正式支持关键解读与实操要点Android ARM64的成熟从11 Alexandria开始对Android ARM64的支持已经非常稳定成为新建项目的默认选择。Google Play现在强烈推荐甚至要求上传64位版本。在Delphi中只需在“Project Options Building Target Platforms”中勾选“Android 64-bit”即可轻松生成对应的APK。Apple Silicon (macOS ARM64) 的支持这是近年来的热点。随着苹果Mac全面转向自研的ARM架构芯片M1, M2, M3应用需要原生ARM64版本以获得最佳性能。Delphi 12 Athens通过更新的LLVM工具链提供了对macOS ARM64的实验性支持。这意味着你可以编译出“Universal 2”应用同时包含Intel和ARM64代码。到了Delphi 13预计这将变为正式且完善的功能。对于需要发布到Mac App Store或面向新Mac用户的应用这将是必选项。迁移时需要注意所有依赖的第三方原生库如果有也必须提供ARM64版本。Windows on ARM64的展望Delphi 13的预览信息显示其一个重要特性就是对Windows ARM64平台的原生支持。随着高通骁龙X Elite等芯片的推出ARM架构的Windows设备预计会增多。Delphi提前布局允许开发者用同一套代码尤其是FMX为未来的Windows ARM设备做好准备。这可能是继移动端之后又一个重要的新市场。VCL的坚守与局限可以看到VCL依然坚守着32位Windows的阵地。Embarcadero多次明确表示会继续维护VCL因为它承载着海量的企业级遗产代码。但是VCL的跨平台之路基本已经关闭。它的未来在于现代化改造例如高DPI感知、视觉样式更新、与FMX共享非UI代码库等。对于全新的、需要跨平台的项目FMX是唯一的选择。4.2 平台选择的实战策略与心得面对如此多的平台选项在实际项目中该如何选择以下是我的几点心得策略一新项目从FMX和多平台开始。如果你的项目是全新的且潜在用户可能使用多种设备Windows PC、Mac、手机、平板那么毫不犹豫地选择FireMonkeyFMX。从项目创建的第一天起就为所有目标平台至少是Windows 64-bit, macOS, iOS, Android配置好构建配置。即使你暂时只发布一个平台这种架构也能保证未来扩展时成本最低。使用TForm.StyleBook和样式来统一管理UI外观而不是硬编码颜色和字体。策略二遗产VCL项目采用“绞杀者模式”渐进迁移。对于庞大的VCL桌面应用全部重写为FMX是不现实的。可以采用“绞杀者模式”Strangler Pattern将核心业务逻辑代码抽取到独立的、非UI的“共享单元”或“动态链接库”中。这部分代码通常与UI无关可以很容易地被FMX新项目引用。对于需要现代化或移动化的新功能模块使用FMX开发一个新的独立应用或插件。通过进程间通信IPC、本地网络接口或共享数据库让新的FMX模块与老的VCL主程序协同工作。随着时间的推移越来越多的功能被迁移到FMX端直到老的VCL主程序最终被“绞杀”替代。策略三服务器端拥抱Linux。如果你正在用Delphi开发后台服务、API接口或数据处理工具强烈建议将Linux作为首选部署平台。原因很简单成本低、性能高、资源占用少。Delphi 10.2的Linux服务器支持已经相当可靠。结合Docker容器化部署可以轻松实现持续集成和弹性伸缩。在开发时善用条件编译{$IFDEF LINUX}来处理平台特有的文件路径、系统调用等差异。关于第三方控件的忠告你的项目能走多远很大程度上取决于你所选的第三方控件库对目标平台的支持程度。在选择控件库时不要只看它宣传的“支持FMX”一定要查阅官方文档明确列出支持的具体平台如iOS 64-bit, Android ARM64, macOS。下载试用版在你的所有目标平台上实际编译和运行Demo。关注社区论坛看其他开发者在该平台上使用该控件时是否报告了重大问题。优先选择那些更新活跃、与Embarcadero新版本发布节奏保持同步的控件厂商。5. 未来展望与总结Delphi的平台之路回顾从XE4到D13的历程Delphi的平台支持策略清晰地反映了一条从“Windows专属”到“多端并进”的转型之路。FireMonkey框架是这场转型的技术基石虽然早期磕磕绊绊但如今已能胜任从移动应用到桌面软件的跨平台开发。Linux服务器端的支持则开辟了另一个广阔的战场。展望未来Delphi 13对Windows ARM64和macOS ARM64的强化支持表明Embarcadero正在紧跟硬件生态的变革。对于开发者而言这意味着我们手中的Pascal代码的生命力和适用场景再一次得到了扩展。最后分享一个我自己的项目决策框架当启动一个新项目时我会画一个简单的表格横轴是目标平台Win, Mac, iOS, Android, Linux纵轴是功能模块。然后评估每个模块在每个平台上的必要性和实现复杂度。如果某个模块在某个平台上复杂度极高而必要性极低也许可以考虑在该平台上简化或移除该功能而不是强求100%的代码复用。跨平台开发的目标不是“一份代码处处完美”而是“一份核心逻辑多端最佳体验”。在追求效率的同时尊重每个平台的特性这才是Delphi跨平台开发带给我们的真正挑战与乐趣。