1. 项目概述从桌面霸主到全栈利器的进化之路作为一名在Delphi生态里摸爬滚打了十几年的老程序员我亲眼见证了它从Windows桌面开发的王者一路演进到今天支持多平台、多操作系统的全栈开发工具。从经典的Delphi 7到如今的Delphi 12.3D13每一次版本迭代尤其是从XE4开始都伴随着对新兴平台支持的巨大飞跃。很多刚接触Delphi的朋友甚至一些老Delphi开发者可能对“Delphi现在到底能开发什么”这个问题感到困惑。是只能做Windows桌面程序吗还是能写手机App能跑在Linux服务器上吗今天我就结合自己从XE4到D13的实战经验为大家彻底梳理一遍Delphi所支持的平台和操作系统这不仅仅是官方文档的罗列更会分享在不同平台上开发、部署、调试时那些官方手册里不会写的“坑”和“技巧”。简单来说从Embarcadero推出FireMonkeyFMX框架的Delphi XE2开始Delphi就正式踏上了跨平台之路。而XE4是一个关键节点它极大地增强了对移动平台iOS和Android的支持。发展到今天的Delphi 12.3其支持的广度已经远超许多人的想象从传统的Windows桌面VCL应用到移动端的iOS和AndroidFMX应用再到服务器端的Linux和macOS甚至还能为这些平台开发Web服务、REST API以及数据库中间层。理解这些平台支持的具体细节、限制和最佳实践是高效利用Delphi进行现代软件开发的前提。无论你是想用Delphi重写一个遗留的Windows系统还是打算用同一套代码基础为手机和桌面同时开发新应用这篇文章都将为你提供一份详尽的路线图。2. Delphi跨平台架构核心VCL与FireMonkey的抉择要搞清楚Delphi能跑在哪些平台上首先必须理解其两大UI框架VCL和FireMonkey。这是所有平台选择的基石选错了框架后续的所有工作都可能事倍功半。2.1 VCLWindows原生生态的定海神针VCLVisual Component Library是Delphi的“开国功臣”它深度绑定Windows API。如果你的目标平台只有Windows并且需要极致的原生体验、高性能以及对Windows特定功能如COM、ActiveX、特定的注册表操作、原生Windows控件外观的深度集成那么VCL依然是无可替代的选择。支持的操作系统从Windows XP到最新的Windows 11包括对应的服务器版本如Windows Server 2012 R2, 2016, 2019, 2022。对于旧版本Delphi如XE4可能对Windows 10/11的新特性支持有限但编译出的程序通常能在新系统上运行。核心优势性能与资源占用直接调用Win32/64 API无中间层执行效率最高生成的可执行文件相对较小。控件丰富度与稳定性经过二十多年的积累VCL拥有海量成熟的第三方控件库如DevExpress VCL、TMS、Raize等覆盖图表、报表、网格、UI美化等所有领域稳定性和功能深度是FMX目前难以比拟的。与Windows系统无缝集成可以轻松操作注册表、WMI、服务、计划任务等开发系统管理工具、工业上位机软件得天独厚。实战心得与避坑指南注意在Delphi 11及更高版本中新建VCL项目默认启用“VCL样式”并可能链接了较大的运行时包。如果追求极致的轻量化和兼容性例如需要在纯净的WinPE或老旧XP上运行务必在项目选项中将“Application Appearance”设为“None”并使用“Runtime packages”链接为False进行静态编译。否则你的程序可能会因为缺少vclimg140.bpl之类的样式包而无法启动。2.2 FireMonkey真正的跨平台UI框架FireMonkey是Embarcadero为实现“一次编写多处编译”愿景而生的现代UI框架。它使用自己的绘图引擎最初基于DirectX和OpenGL不依赖原生控件因此理论上可以在任何有该引擎移植的平台运行。支持的操作系统/平台这是FMX的舞台。桌面端Windows, macOS。移动端iOS (iPhone/iPad), Android。其他Linux目前主要通过FMXLinux项目提供有限支持官方在D12后加强了对Linux GUI的原生支持但FMX for Linux仍处于演进阶段。核心优势真正的单一代码库UI布局和大部分业务逻辑代码可以在Windows、macOS、iOS、Android之间共享只需为每个平台单独编译。现代UI与特效内置支持矢量图形、动画、3D效果、多点触控更容易打造视觉效果华丽的现代化应用。灵活的自定义由于是自己绘制的控件UI的自定义能力极强可以轻松实现设计师要求的各种特殊效果。关键抉择与性能考量 选择FMX意味着你接受了一定的抽象层开销。在移动设备上这个开销经过优化后可以接受并且能利用GPU加速。但在Windows桌面端一个复杂的FMX窗体其性能特别是启动速度和UI响应可能不如同等复杂的VCL窗体。我的经验是如果你的应用是工具型、管理型强调稳定性和传统交互首选VCL。如果你的应用是媒体型、消费型需要酷炫的UI并面向多平台发布FMX是唯一的选择。对于需要同时服务桌面和移动端的项目可以采用“共享核心业务逻辑单元.pas文件分别为VCL和FMX编写UI层”的混合架构但这增加了架构复杂度。3. 各平台支持详解与实战配置XE4 ~ D13不同版本的Delphi对平台的支持程度和配置方式有显著差异。这里我以演进的时间线结合当前最新的D12.3来展开说明。3.1 Windows平台历久弥新的主战场从XE4到D13Windows始终是支持最完善、最稳定的平台。编译器与目标架构XE4~DX主要使用Delphi编译器DCC支持生成32位x86和64位x64Windows可执行文件。开发环境本身是32位的。D11~D13引入了基于LLVM的Clang编译器作为后端用于编译64位Windows目标代码生成质量和优化能力有提升。同时保留经典编译器。重要变化从D11开始IDE本身也是64位应用了解决了处理大型项目时内存不足的问题。配置要点 在Project - Options - Target Platform中你可以选择“Windows 32-bit”或“Windows 64-bit”。对于VCL项目你甚至可以同时添加这两个目标平台一键编译出两个版本。实操避坑路径与空格项目路径、单元路径、资源路径中尽量避免中文和空格。虽然新版IDE处理能力增强但在调用外部命令行工具如signtool代码签名时带空格的路径仍是常见的失败原因。清单文件Windows应用通常需要嵌入清单文件以声明DPI感知、请求管理员权限等。在项目选项中正确配置“Application - Manifest”至关重要。例如如果不声明DPI感知在高分屏上你的VCL应用可能会模糊。杀毒软件误报使用某些第三方控件库或特殊的打包方式编译出的.exe文件可能被Windows Defender等杀软误报为病毒。解决方案是对程序进行数字签名购买代码签名证书或引导用户将程序目录添加到杀软白名单。3.2 macOS平台从连接服务器到原生编译对macOS的支持是Delphi跨平台能力的重要体现。支持演进XE4~D10采用“远程调试”模式。需要在同一网络下的Mac电脑上安装“Platform Assistant”服务器PAServerDelphi在Windows上编译通过网络将可执行文件传输到Mac上运行和调试。配置繁琐网络稳定性影响体验。D11~D13实现了原生编译支持。可以在Windows上的Delphi IDE内直接编译出macOS的.app应用包无需中间传输。这是巨大的体验提升。当然你仍然需要一台Mac或macOS虚拟机用于代码签名和最终测试因为应用必须使用苹果开发者证书签名才能在非开发机上运行。配置与签名在“Target Platforms”中添加“macOS 64-bit”。在“SDK Manager”中配置指向macOS的SDK路径通常自动检测。最关键的步骤在“Project - Options - macOS - Version Info”和“Signing”中配置正确的Bundle Identifier、版本号并选择你的苹果开发者证书.p12文件和描述文件.mobileprovision。这个过程和Xcode开发类似。实战心得注意FMX在macOS上的控件风格是模拟macOS原生风格但并非百分百原生。例如窗口的关闭、最小化、最大化按钮行为与原生App可能略有差异。如果你的应用要求与macOS系统深度集成如状态栏菜单、Touch Bar支持可能需要通过Objective-C编写原生桥接代码并使用Delphi的External声明来调用。Embarcadero官方提供了一些示例但这属于高级话题。3.3 iOS平台移动开发的关键一环iOS支持是FMX框架最早发力的移动平台之一。支持方式与后期macOS类似主要采用“远程连接”模式。必须在网络可达的Mac电脑上安装PAServer。Delphi在Windows上编译出iOS的中间文件通过PAServer调用Mac上的Xcode工具链主要是clang和ld进行最终链接和签名生成.ipa文件。架构变迁XE4~D10支持armv732位和arm64。D11以后随着苹果淘汰32位应用现在主要只支持arm64架构。在项目选项中iOS Device - 64 bit是标准选择。证书与描述文件这是iOS开发的“拦路虎”。你必须拥有苹果开发者账号每年99美元在Apple Developer Portal创建App ID、开发证书Development Certificate和描述文件Provisioning Profile并将它们正确配置到Delphi的SDK Manager和项目签名选项中。这个过程任何一步出错都会导致编译失败。常见问题排查“Code Signing Failed”99%的问题出在证书和描述文件不匹配。检查证书是否过期描述文件是否包含了当前设备的UDID对于开发测试描述文件是否关联了正确的App IDBundle Identifier“No provisioning profile found”在Delphi的Tools - Options - SDK Manager - iOS 64-bit - Provisioning profile路径下确保选择了正确的.mobileprovision文件。网络连接失败确保Windows防火墙允许Delphi和PAServer通信并且PAServer在Mac上以正确的IP地址启动最好使用Mac的局域网IP而非localhost。3.4 Android平台最开放的移动生态Android是配置相对简单的移动平台因为它不需要强制性的代码签名发布到Google Play除外和复杂的远程编译。支持方式本地编译。Delphi使用自带的Android NDKNative Development Kit工具链直接在Windows上编译生成原生的ARM库.so文件并将其与Java封装层一起打包成.apk文件。配置步骤安装Android SDK和NDK。D11及以后版本IDE内置了SDK Manager可以一键下载和管理多个版本的SDK/NDK/平台工具比早期手动配置方便太多。在“Target Platforms”中添加“Android 64-bit”目前主流或“Android 32-bit”。在项目选项中可以指定目标Android API级别如API 33、应用图标、权限等。版本兼容性挑战 Android版本碎片化严重。Delphi编译时指定的Target SDK Version和Min SDK Version需要谨慎选择。例如将Target SDK Version设得太低如低于API 30可能无法上架Google Play设得太高又可能用到了旧版Android不支持的API。我的建议是Min SDK Version根据你的用户群体决定通常API 21以上覆盖大部分设备Target SDK Version尽量使用Delphi自带NDK支持的最新版本如D12.3对应API 34以确保兼容性和安全性。调试技巧 连接Android手机调试前需开启手机的“开发者选项”和“USB调试”。在Delphi的“Run”菜单下选择你的设备。如果设备未列出尝试重启ADB服务adb kill-server adb start-server。日志输出在“Event Log”窗口的“Android”标签页下这是排查运行时错误的最重要工具。3.5 Linux平台服务器与桌面新前沿Linux支持是Delphi近年来尤其是D10.3以后重点加强的方向分为服务器端和桌面端。Linux服务器应用Console/Non-UI 这是目前最成熟、最稳定的Linux支持。你可以用Delphi编写纯控制台应用、Web服务如使用DataSnap、RAD Server或第三方框架如mORMot、后台守护进程等。编译在Windows上完成生成一个原生的Linux ELF可执行文件然后拷贝到Linux服务器如Ubuntu, CentOS, RedHat上运行。配置在“Target Platforms”中添加“Linux 64-bit”。需要指定一个“Linux System Root”目录即一个包含Linux系统头文件和库的本地副本。可以通过安装一个Windows子系统LinuxWSL发行版并将其根文件系统路径提供给Delphi。部署编译出的可执行文件可能依赖特定的glibc版本。为了最大兼容性建议在较低版本的Linux发行版如Ubuntu 18.04或使用旧版glibc的Docker容器中进行编译。可以使用ldd命令检查依赖。Linux桌面应用FMXLinux 这是通过一个独立的开源项目FMXLinux实现的它让FireMonkey框架能运行在Linux桌面如Ubuntu GNOME上。Embarcadero从D12开始提供了官方的预览版支持。但需要注意的是其成熟度、控件完整性和性能目前仍无法与Windows/macOS版本相比更适合内部工具或特定场景。现状控件库不全一些高级特性如某些特效、3D可能缺失。部署时需要将FMXLinux的运行时库与应用程序一同分发。前景这是Delphi生态扩展的重要方向值得关注其后续发展。4. 跨平台开发的核心挑战与应对策略掌握了各个平台的配置方法只是第一步。真正的挑战在于如何让同一套代码优雅地运行在所有目标平台上。以下是我总结的几个核心挑战及应对策略。4.1 条件编译与平台检测这是处理平台差异最基本、最常用的手段。Delphi提供了丰富的条件编译指令和内建的System单元函数。条件编译指令{$IFDEF MSWINDOWS} // 这里是Windows特有的代码比如调用Windows API UseWindowsSpecificAPI; {$ENDIF} {$IFDEF IOS} // 这里是iOS特有的代码比如调整状态栏样式 SetiOSStatusBarStyle; {$ENDIF} {$IF Defined(ANDROID) or Defined(IOS)} // 这里是移动平台Android或iOS共有的代码 ShowMobileSpecificUI; {$ENDIF} {$IFDEF LINUX} // Linux服务器端代码 WriteLn(Running on Linux server); {$ENDIF}运行时平台检测uses System.Types; // 包含TOSVersion case TOSVersion.Platform of pfWindows: // 处理Windows逻辑 pfiOS: // 处理iOS逻辑 pfAndroid: // 处理Android逻辑 pfMacOS: // 处理macOS逻辑 pfLinux: // 处理Linux逻辑 end; // 更细粒度的版本检测 if (TOSVersion.Platform pfWindows) and (TOSVersion.Major 10) then begin // Windows 10及以上系统特有功能 end;实战技巧 不要滥用条件编译。应将平台相关的代码封装在独立的单元或类中通过接口或抽象类来调用保持主业务逻辑的整洁。例如可以定义一个IFileService接口然后分别实现TWindowsFileService、TMacFileService等。4.2 文件系统与路径处理不同操作系统的路径分隔符、根目录、大小写敏感性都不同。使用System.IOUtils单元这是处理文件路径的黄金法则。永远不要手动拼接字符串路径。uses System.IOUtils; var ConfigPath: string; begin // 获取跨平台的应用程序配置目录 ConfigPath : TPath.GetHomePath; // 用户主目录 ConfigPath : TPath.Combine(ConfigPath, MyApp); ConfigPath : TPath.Combine(ConfigPath, config.ini); // TPath提供了Combine, GetFileName, GetDirectoryName等方法自动处理分隔符。 end;大小写敏感性Linux和macOS的文件系统是大小写敏感的尽管macOS默认APFS不敏感但应视为敏感以保兼容而Windows不敏感。在代码中引用文件名时应保持大小写一致最好使用TPath的相关方法进行比较。4.3 用户界面与交互适配这是FMX跨平台开发中最耗时的部分。屏幕尺寸与密度使用FMX.Platform单元的Screen服务来获取屏幕尺寸和缩放比例。var ScreenService: IFMXScreenService; ScreenSize: TPointF; Scale: Single; begin if TPlatformServices.Current.SupportsPlatformService(IFMXScreenService, IInterface(ScreenService)) then begin ScreenSize : ScreenService.GetScreenSize; Scale : ScreenService.GetScreenScale; // 根据Scale和ScreenSize动态调整控件位置和大小 end; end;控件布局多使用TLayout、TRectangle等容器以及Align、Margins、Padding属性进行相对布局避免使用绝对的Left和Top。善用Anchors属性让控件随窗体大小变化。平台特有样式FMX的TStyleBook可以加载不同的样式文件。可以为iOS、Android分别设计符合其设计语言Human Interface Guidelines / Material Design的样式在程序启动时根据平台加载。4.4 第三方库与原生集成当Delphi自带组件无法满足需求时就需要集成第三方库。纯Pascal库这是最理想的情况直接添加.pas文件或.dcu到项目即可跨平台无忧。C/C库Windows使用.dll通过external声明导入函数。macOS/iOS使用.dylibmacOS或.a静态库iOS同样通过external声明但需要注意函数命名修饰Name Mangling可能不同通常需要cdecl调用约定。Android使用.so动态库通过System.DelphiInterface和JNIJava Native Interface进行调用。这是最复杂的一种通常需要编写Java包装层和对应的Pascal JNI桥接代码。Linux使用.so类似Windows的dll方式。建议对于复杂的原生功能如特定硬件访问、深度系统集成可以考虑购买成熟的第三方组件或者使用REST API与一个运行在本地的原生服务进程通信这比直接集成C/C库更易维护。5. 从编译到分发完整工作流指南理解了平台支持和技术挑战后一个清晰的开发、编译、调试、分发工作流至关重要。5.1 多目标项目管理Delphi的“项目组”Project Group和“构建配置”Build Configuration是管理多平台项目的利器。创建项目组为你的应用创建一个项目组.groupproj。添加多个目标平台在项目管理器中右键点击你的主项目选择“Add Target Platform”依次添加Windows 64-bit, macOS 64-bit, iOS 64-bit Device, Android 64-bit等。使用构建配置可以创建不同的构建配置如“Debug_Android”、“Release_iOS”、“Store_Windows”。在每个配置中独立设置编译器选项、条件定义、版本信息等。批量编译在项目组上右键选择“Build All”或“Batch Build”可以一次性编译所有激活的目标平台极大提升效率。5.2 调试技巧分平台解析Windows (VCL/FMX)直接按F9使用集成的调试器体验最好。可以设置断点、查看变量、调用栈等。macOS (FMX)在D11原生编译模式下调试体验接近Windows。需要确保macOS远程调试配置正确即使原生编译调试信息传输可能仍需网络。在Mac上运行的应用其标准输出会显示在Delphi的“Event Log”中。iOS (FMX)必须通过PAServer进行远程调试。在Windows的Delphi中设置断点当应用在连接的iOS设备或模拟器上运行时断点会命中。调试信息有网络延迟。关键iOS设备的日志在“Event Log”的“iOS Device Log”页签这是排查崩溃和异常的唯一途径。Android (FMX)USB连接调试类似iOS。日志在“Event Log”的“Android Log”页签。可以配合Log.dAndroid原生日志和Delphi的OutputDebugString来输出信息。Linux (Console)调试支持较弱。通常采用“日志法”在代码中关键位置写入文件日志。也可以使用GDB等命令行调试器附加到进程但这超出了Delphi IDE的集成范围。5.3 分发与部署清单编译成功后你需要将正确的文件打包分发给用户。平台输出文件额外依赖文件分发注意事项Windows (VCL).exe(可执行文件)可能需要的.dll文件如数据库客户端库、vclimg*.bpl等运行时包如果动态链接。制作安装包如Inno Setup。考虑是否需要管理员权限。进行数字签名。Windows (FMX).exeFMX运行时库如果动态链接、可能需要的.dll。同VCL。注意FMX应用可能依赖DirectX或OpenGL运行时需确保目标系统已安装。macOS.app(应用程序包)无。所有依赖已封装在.app包内的Frameworks或Resources文件夹。必须使用开发者证书签名和公证Notarization否则在macOS Catalina及更高版本上无法直接运行。分发.dmg镜像或上传至App Store。iOS.ipa(安装包)无。通过TestFlight进行内部测试分发或提交至App Store。Ad-Hoc方式用于有限设备测试。Android.apk或.aab无。.apk用于直接安装或第三方商店。.aab(Android App Bundle) 用于上传Google Play由Play商店动态生成针对不同设备的优化APK。Linux无扩展名的可执行文件可能依赖特定版本的glibc、libgtk等系统库。通常打包成.deb(Debian/Ubuntu) 或.rpm(RedHat/CentOS) 格式。使用Docker容器构建可以确保库版本兼容性。5.4 持续集成与自动化构建对于需要频繁为多个平台构建的项目手动操作是不可接受的。可以利用命令行编译器dcc、msbuild以及PAServer的命令行接口实现自动化。Windows/Linux命令行编译rem Windows 编译 64位 VCL 应用 dcc64 -B -NSsystem;vcl MyProject.dpr rem Linux 编译 64位 控制台应用 dcc64 -B -TLinux MyLinuxProject.dprmacOS/iOS自动化需要编写脚本在Windows端调用dcc编译后通过SSH或网络命令触发Mac上的PAServer执行链接和签名步骤。Embarcadero的RAD Server命令行工具radserver也提供了相关管理命令。集成到CI/CD可以将上述命令集成到Jenkins、GitLab CI、GitHub Actions等持续集成平台中实现代码提交后自动为所有平台编译、打包和测试。从Delphi XE4到D13其平台支持的广度和深度已经发生了翻天覆地的变化。它不再仅仅是一个Windows桌面开发工具而是一个能够触及桌面、移动、服务器乃至Linux桌面的全栈开发解决方案。成功的关键在于深刻理解VCL与FMX的差异熟练掌握各平台的配置、调试和分发细节并运用良好的架构设计来管理平台间的差异。这个过程充满挑战但当你看到同一套核心业务逻辑代码在Windows、macOS、iPhone和Android上同时流畅运行时那种效率与成就感是无可比拟的。对于现有的Delphi开发者拥抱这些新平台是延长技术生命周期的必然选择对于新开发者认识到Delphi的这些能力或许能为你下一个项目的技术选型提供一个意想不到的选项。