写在前头

关于各种手机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的话会很扰人且很恼人，所以没有在此提及。