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的話會很擾人且很惱人，所以沒有在此提及。