Delphi 开发手机 App 与其余工具之间的比较分析

写在前头

关于各类手机App开发的工具，从2010年先后到如今已经在不少不一样的场合介绍过，在元智大学、中台科技大学、德霖科技大学等不一样学校的讲座、课程当中，都有相似的主题，因此对我来讲，这个主题属于得心应手的范围。

 

在 KTOP 的论坛当中，有不少前辈但愿你们可以贡献所学，为资讯业共图将来的荣景。固然，KTOP 的主题当中仍然是以 Delphi 为主轴，因此当 Lazarus 前辈提了三个题目给我：

1.     Delphi/Lazarus INDY 网路程式设计

2.     Delphi 资料库程式设计 (什么 FireMonkey 架构 , 工做上没机会接触, 彻底不懂 … 我用传统连线方式同样能够连资料库啊 …)

3.     Delphi 手机 APP 程式开发, 不知 Delphi 是否有比其余手机 APP 专用的开发工具备优点 ..

这三个都是好题目，只是第一跟第二题须要比较多的篇幅来进行，因此我就先就第三题作了这篇文章。

 

第一题 Delphi/Lazarus Indy 网路程式设计，在我 2001 年的著述 – Delphi/Kylix Indy 网际网路程式设计当中已经写了三百多页，当年写的是 Delphi 7 + Indy 8/9，历经了17年，我在2009年曾经就内容版本作过一次更新，使用了Delphi 2009 与 Indy 10.0.52作了一次改版，但没有出版社有兴趣，因此只有 KTOP 副站长，也是 Embarcaderp MVP 的 GrandRuRu，以及少数几位网友跟我购买了两三个电子书的档案，并无机会出版实体书，以为有些遗憾。

 

第二题 Delphi 资料库程式设计，从 Delphi 7 时期的 BDE，到 Delphi 2005-2009 时期的 dbExpress，再到 XE2-10.2 时期的 FireDAC/UniDAC，我本身在使用上，以为除了 Connection 的设定上有所不一样，其他在 Table, Query 的使用上并无太大的改变，并且李维在为捷康所着的 Delphi Database 开发手册当中已经有很详尽的说明，因此我可能在接下来的几篇文章当中，提供一些使用上的范例与心得，至于资料库的使用细节，我就不敢斑门弄斧了。

现有的开发工具概观

从2008年 iPhone 跟 Android 把行动装置带向了没有微软的世界以后，开发工具也跟微软今后没有那么大的关系，如下，我把开发工具分红几大类：

• 原生工具
• 网页转换工具
• 其余需编译的工具

原生工具

顾名思义，是由该做业系统的开发者所提供的开发工具，在 iOS 跟 Android 两大阵营当中(抱歉，从2009至今，我从没看到 Windows Phone 有任何复甦的可能，因此直接忽略不计)，就是三种工具：

• iOS: Xcode (包含 Objective-C 跟 Swift 两种语言)
• Android: Eclipse 跟 Android Studio (都是 JAVA 语言)

若是您对任何语言都不太熟悉，或者说没有原有技能的包袱，学习原生工具天然是最跟的上做业系统更新的，由于每次做业系统一更新，都会或多或少有些变更，SDK也会跟着调整，这些调整都会直接包含在原生工具里面，因此SDK跟的最为紧密，也不用担忧有程式码或工具须要等开发工具的更新才能跟的上。

 

Objective-C 是从 2000 年先后就被苹果做为官方程式语言，本来在 1996-1998之间，Object Pascal一度在苹果的候选名单内，但后来我也不知道是什么缘由，苹果仍是决定本身定义 Objective-C 这个语言。

 

Objective-C 跟 C++, 跟 C 都彻底不一样，在语法上，使用中括号 [] 做为 method invoke 的符号，而使用 . 做为 property 的存取符号，也是由于 method invoke 的 statement 跟 C系列的语言彻底不一样，因此不少已经习惯 C 系列语言的开发人员彻底跨不过去。

 

但从语言的核心来看，用中括号做为 invoke，以空格加上 prefix descriptor来描述每一个参数，也很清楚易懂，可能人一习惯某种语法，就很难变化，因此 Objective-C 后来在推广上也老是有难以突破的障碍，例如 C# 阵营的开发人员，就很排斥这种语法，因此苹果后来在 2013 年先后开始推出 Swift 这个语言，语法就跟 C# 很类似，相信所以从微软阵营转向 Swift 的人不在少数。

 

Android 的开发工具则是在 2014 年做为一个分水岭。

2014年之前，官方开发工具是 Eclipse，不少人会用，但没有人敢说对 Eclipse 熟悉，由于 Eclipse 只要搭配不一样的 SDK，就能变成彻底不一样的面貌，因此用 Eclipse 开发 Android 虽然是在 2014 年之前的惟一选择，却也是让不少开发人员花费不少时间设定的工具。

 

2014年起，Google推出了 Android Studio，把不少以前难搞的SDK都整合在一个安装档里面了，很好用，但跟以前用 Eclipse 的专案又有不一样。前面我提到过，人习惯了某些东西之后就很难改变，因此目前 Android 的开发阵营里，原生工具仍旧分为两个不一样的派别：Eclipse 跟 Android Studio.

原生工具的优缺点

原生工具的好处，是可以跟做业系统紧密的结合，永远不会落后，也不用等待开发工具的厂商更新什么套件。但原生工具的致命缺点，就是两个平台必须维护两套 Source code，并且由于两个平台工具上的差别，同一个 App 在两个平台上的更新速度永远不可能同样，并且问题修正也不可能同步。

 

这就形成了原生工具开发的成本被垫高。通常客户须要App的，分为两种，一种是本身有养着开发人员，但开发人员对App不熟悉，因此先外包，再把Source code 接回来本身维护，这种客户比较能从开发人员的角度想问题。

 

也就知道养着两组人，就须要两份成本，时间虽然能够接近，但两组人的素质不可能彻底相同，业界同时写 iOS 跟 Android 的人很少，由于两个平台的概念有不小的差距。

 

第二种客户是行销类的客户，这类客户会把两个平台的 App 当作同一个东西，因此会要求用一份成本，作两个平台的 App，维护时间也同样，会要求同时产出、问题同时解决，时程要求短，成本要求低，品质要求高，并且不会有第二个案子，由于行销类的客户一般是为某个产品提案，效果没有在短期内看到，就不会有下一个案子。

 

就算有了效果，下一个案子的时间也是遥遥无期，并且会嫌成本过高，转而用其余方式制做，例如 RWD 网页。

网页转换工具

网页转换工具，则是前端工程师的最爱，这类工具只要把一个网站作好，全部网页作成能够离线浏览，经由转换包裹，就能够分别作成 iOS, Android 平台可使用的 App，表明性的工具备三个，但其实都是同一个：

• Adobe PhoneGap
• Apache Cordova
• IBM WorkLight

这三个都是同一个，最先都叫作 PhoneGap，但PhoneGap后来被 Adobe 买下，免费版的则转由 Apache 基金会继续维护下去，改了名字叫作 Apache Cordova。IBM 则在 2013年也用 Cordova 作了一个版本，给了新名字叫作 WorkLight。

 

这三个工具都是把网页直接转换成 App，也各自提供了不少 JQuery API，让前端开发人员可使用手机装置的内建功能，例如GPS,电话功能、重力感应器功能等。

 

PhoneGap 有方便的 App 端工具，让开发人员能够直接对包裹出来的页面作直接互动式的测试。

 

Cordova 则是比较阳春，要先透过 Chrome, FireFox 先把内容测试好，再进行包裹。

WorkLight 则是提供了强大的后台，能够不透过 AppStore 直接置换掉网页内容，换句话说，就是能够不透过 AppStore 的审查直接升级 App，因此国泰世华、中国信托的App后来都改用了 IBM WorkLight 来制做。

网页转换工具的优缺点

网页转换工具的好处是开发快速，前端设计师就能搞定一切，因此成本低，行销类的客户最喜欢这种工具。

 

缺点则是效能不彰，由于全部功能都是透过浏览器来显示的，浏览器全部的限制、效能的局限，都直接冲击网页转换工具制做的 App，可是成本低，因此从 2015 年之后，大量行销类的 App 都被使用这类工具的工做室或公司抢走了，行销类的App用原生工具的比例也大为下降。

其余需编译的工具

这类工具，一般是为了资深的开发人员而生的，包括有：

• Delphi – 为了原来对 Delphi 熟悉的开发人员而生
• Xamarin – 为了原来对 C# 熟悉的开发人员而生

这类工具，一般有本身的 IDE，也能够分别编译 iOS, Android 的 App，编译出来的执行档效能也接近原生工具的效能，但仍旧分别有其优缺点：

Delphi 的优缺点:

先讲缺点，Delphi制做App的缺点有两个。

 

首先是 Foot Print太大，也就是档案太肥。

由于 Delphi 制做 App 的时候是使用 FireMonkey 框架在 iOS 跟 Android 系统中产生两个平台的介面，整个框架必须都编译到程式中，因此档案必定会很肥，这是没法避免的。

 

其次是全部第三方元件的原罪，就是当 iOS 一更新，有可能 Xcode 工具里有修改功能，会致使 Delphi 须要等原厂出 patch 才能搭配新版的 Xcode 编译，这个问题从 XE5到 10.2.3 都有，但这是原罪，没办法。

 

其次是优势，因为使用 FireMonkey 框架，因此全部的元件都不依靠做业系统的元件，在 iOS 跟 Android 平台的 App 可使用同一套原始码，有问题的时候也比较容易一块儿解决，两平台的 App 能够由同一我的维护，成本比两我的低一些。

Xamarin的介绍与优缺点

Xamarin是在2014年先后由一家独立软体公司开发出来的，后来在2016年被微软收购，成为 Visual Studio的一部分。

 

Xamarin 的概念跟 Delphi 不同，这个工具是要让全部写 C# 的开发人员，能够用 C#开发 iOS 跟 Android 的 App。

 

但 C# 的控制，是在 iOS 上用 C# 操控 iOS SDK，在 Android 上用 C# 操控 Android SDK，所以形成了两个平台的专案中，介面必须分别写，而后共用的元件再另外写，但是 iOS SDK 跟 Android SDK 的差异很大，结果就是使用 Xamarin 的工程师必须把两个平台的 SDK 都要摸熟，并且一个 App 必须维护三种 code: iOS 介面, Android 介面, 以及核心逻辑程式。

 

对咱们有其余选择的人来看，这很浪费时间，但对只会 C# 的人来讲，这彻底获得了救赎。

 

因此，Xamarin 的优势跟缺点，必须从立场来看，对于不拘于只使用 C# 的人来讲，Xamarin 要维护三套程式的做法，很蠢。

 

但对于只会 C# 的人来讲，会了 C# 就能够畅行无阻，并且由于编译都是用原生工具，效能跟原生工具的产出同样好，且档案也不会大到很可怕，因此这些都是优势。

结语

以上就是各类不一样的开发工具的优缺点，跟你们分享。

 

我本身很熟悉 Objective-C跟 Delphi，JQuery也还能够，我不隐藏对JAVA的厌恶，但我也会 JAVA，因此我本身使用过 Delphi, Xcode, Apache Cordova, IBM WorkLight, Eclipse 开发过许多程式，或许这些心得算是开发人员能够有些共鸣的。

 

以我本身的喜爱来看，我一我的要维护多个App的话，我会选择 Delphi，由于程式逻辑跟介面都只须要一套，执行档 (ipa, apk)是肥了一点，但效能还不错，且在这些工具中，要跟资料库链接的话，Delphi 是不二之选。

 

Objective-C要直接连 DB? 只有 SQLite，并且写法挺烦的。透过 JSON 跟 Restful API 来处理还好一点。JQuery也只能透事后端工具来处理，我会选择PHP。

 

但前台 SQLite 全部工具都同样, 若是有须要直接连 MySQL, Delphi 会方便不少。

这些工具中，我独漏了 Unity 3D，由于这工具我归类是写 Game 的，写通常 App的话会很扰人且很恼人，因此没有在此说起。