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的話會很擾人且很惱人，因此沒有在此說起。