Embarcadero的主要营销点之一是Delphi将创建对您的移动平台“原生”的应用程序。我从尝试在移动平台上使用Delphi的人们看到的主要抱怨之一是对这些“本机”应用程序的速度和外观的失望。这是公司过度销售产品，夸大客户期望，然后令他们失望的典型案例。

那么，Delphi是否真的为iOS和Android创建“本机”应用程序？答案是肯定的，是肯定的，根本没有。您需要认识到的是，应用程序可以通过多种方式本地化（或不本地化）到平台。我将讨论3种方法来帮助您了解Delphi有什么用处，而又不是那么好。硬件是本地的，操作系统是本地的，外观是本地的。

硬件原生

硬件的本机意味着您的代码被编译为硬件的实际机器指令。这是Embarcadero所做的出色工作，这实际上是其营销部门向您出售的产品。  与Java，Python或php不同，Delphi的代码不会被某些引擎或虚拟机解释。编译和链接完成后，二进制代码直接进入硬件，而中间没有任何层。Windows，MacOS，iOS和Android都是如此。 

请注意，这并不意味着您无法编写快速解释的代码或慢速编译的代码。您编写的算法以及解释器/编译器执行和不执行的优化会极大地影响执行速度。的确，这意味着Delphi与已解释的代码相比具有内在的优势。

注2：硬件的本机也可能意味着直接访问设备的硬件（例如GPS，相机等），但是除非您正在编写设备驱动程序，否则没有人会直接访问这种硬件。更适当地，它是OS API的功能，下一节将对此进行讨论。

本机操作系统

我所说的操作系统本机是指程序可以直接访问API和设备操作系统的控件吗？对于Delphi和iOS，这是“明确”的。对于Delphi和Android，这已经足够了。几乎根据定义，除非您的开发语言与操作系统使用的语言相同，否则您将始终必须使用对操作系统及其控件有  希望的 瘦应用程序编程接口（这是C ++ Builder比Delphi可以做得更好的一个领域）在iOS上）。由于iOS的“本机”语言是Objective-C，并且（从Delphi的角度来看更糟），Android的“本机”语言是Java，因此Delphi对IOS而言不是“本机”。  但是，这并不意味着它是开发的二等公民。

您会看到，Delphi，至少每个人都在思考的Delphi，从未直接访问API和操作系统控制。  使Delphi出色的原因之一是使用VCL进行的应用程序的真正快速应用程序开发。VCL  不是直接访问Window的API。从直接访问的角度来看，最好的情况是，您必须使用C标头来访问Window的服务，最糟糕的是，VCL是围绕Window控件的薄包装。TListBox不是Windows固有的-它是围绕Window对象的精美逻辑包装。Delphi牺牲了对API和控件的本机访问，颈椎枕从而为您提供了快速应用程序开发（RAD）。但是，目标是保持Delphi和OS之间的层尽可能薄和快速，同时保留RAD并现在增加了跨平台开发。

因此，操作系统原生是合格的。对于Windows，OSX和iOS（都基于C / C ++），可以通过API快速，干净地访问OS服务。  对于Android，访问权限不如Delphi需要使用JNI（Java本机接口）层，这相对于C API而言昂贵。

Delphi的跨平台库Firemonkey或FMX封装了Location和Camera等服务，我认为这是跨平台开发的一种非常好的方法。这些类有助于隐藏基础服务的复杂性，并为Delphi支持的所有平台抽象化它。它们很薄，但是对于底层OS服务来说是很好的层。

但是，访问本机OS控件是另外一回事了，这是我下一节的主题。

原生外观

本地外观是每个人都感到失望的地方。Delphi移动应用程序看起来可能有些错误，感觉有些迟钝，并且以非标准的方式运行（相对于OS控件）。 这是Embarcadero选择实现诸如TListBox，TMemo等跨平台控件的路径的结果。

与FMX不同，VCL是围绕本机Window控件的薄包装，因此具有Windows的外观和流畅的响应能力（在此插入Mac fanboy鄙视注释;-））。在Windows上单击并拖动鼠标时，即单击并拖动Window的控件。当应用程序在新的Windows操作系统上运行时，它将（主要）继承新的外观。VCL通过Windows消息与底层OS控件进行通信，一切正常。

FMX模拟基础操作系统的所有控件。它绘制每个像素本身并处理每个用户交互。这是外观和感觉略有错误的原因。这就是为什么Delphi TListBox与Android的列表框会有不同的bug的原因。这就是为什么它的刷新速度和响应速度都比iOS列表框慢的原因。这也是为什么在发布新的操作系统时，Delphi应用程序不会更新其外观和感觉，并且会过时的原因。

因此，尽管Embarcadero声称像素完美兼容，但Delphi并没有NATIVE的外观。FMX仍然在RAD中提供RAPID，而不仅仅是本机的外观。

我写道，这是Embarcadero决定的结果，事实是如此。 我真的不能怪他们的决定。  通过VCL，Embarcadero / Borland选择了OS方式上的薄包装器。它工作得很漂亮，但是将组件库与OS绑定在一起。Embarcadero可能会为FMX选择这种方法，但这确实非常困难，我们仍在等待跨平台兼容性。他们将不得不为FMX中的每个控件开发一个跨平台的抽象（这本身就是一项艰巨的任务，也许不可能）。然后，对于他们支持的每个平台，他们将不得不开发和维护FMX版本。Embarcadero选择尽可能快地“加入游戏”。我认为这是正确的决定，但这确实意味着他们必须应对自己选择的后果。

注意：BUG和响应速度将会提高（天哪，我知道有BUG！）。Embarcadero的每个版本都在改进FMX库。虽然它永远不会具有原生的外观和感觉，但会改善外观。

注意2：您可以在Windows和iOS上拥有原生的外观。选择Windows的VCL，然后选择DPF Delphi iOS本机组件（http://sourceforge.net/projects/dpfdelphiios/）或TMS的iCL（http://www.tmssoftware.com/site/tmsicl.asp），对于iOS，它们具有相同的作用。当然，您会牺牲跨平台的开发……尽管您继续使用自己的Delphi技能树，并且通过适当的模块化可以希望将不兼容性降至最低。

Delphi的长处和短处

那么这对开发人员意味着什么呢？这意味着Delphi有其优点和缺点，只要您知道它们的长处和短处，就可以选择Delphi来完成正确的工作。

如果您需要跨平台兼容性，并且只想处理一个代码库（大多数情况下），Delphi是一个绝佳的选择。它提供了操作系统及其服务的漂亮抽象，相对漂亮的GUI库以及对CPU的本地（非常快）访问。通常，Delphi还具有出色的数据库连接，Web服务连接和网络连接。这意味着Delphi是

  • 企业开发人员，他们希望提供移动访问功能，而不是真正在乎像素完美的外观
  • 科学和数字运算开发人员，他们需要快速处理以及一种很好地显示其结果的方法
  • 令人惊讶的是，游戏开发人员想要开发跨平台游戏，这些游戏无论如何都没有“本机”界面，而FMX可以在其中提供足够快的图形。（换句话说，不是Madden级图形，而是Angry Birds《疯狂的小鸟》）。
  • 无需使用大量控件即可与用户互动且不需要“像素完美”响应的“轻型”应用程序
  • 引人入胜的应用程序，用户可以原谅某些特质，因为该应用程序非常好。我之所以这样说是因为Delphi允许您专注于该应用程序。Delphi提供RAD和跨平台兼容性，您可以专注于制作杀手级应用程序。

希望本文能帮助您了解Delphi的“本性”。我相信，如果你选择Delphi着眼于自己的优势和局限，以及它如何可以帮助你解决  你的 问题，这是一个很好的选择。