2022/05/09

原生 vs 跨平台

現今軟體應用程式有四種使用者介面:終端機(Command Line Interface)、網頁、Mobile APP、Desktop APP。在為應用程式考量要提供哪一種使用者介面時,如果面對一般使用者,通常會以 網頁 -> Mobile -> Dekstop -> CLI 這樣的順序考慮。但每一種類型的使用者介面,又通常因為運作的 OS 平台不同而有不同的差異,導致開發的方法跟經驗,無法跨出熟悉的領域。

為了節省開發耗費的資源,跨平台成了開發者的首要考量,就如同 Java 一開始的宏願:Write Once, Run Everywhere!,這個目標,Java 並沒有取得全面的成功,但 Java 至少統一了過去數十年一部分的 Application 的開發。Java 在嵌入式環境、Mobile 行動平台、Desktop、網頁 Applet 直到現在都已經確認是失敗的。

失敗的重要原因在於效能及耗費的系統資源量,因為跨平台的要求,會需要將平台相關的功能包裝起來,再用另一個標準提供開發者介面,但這個封裝可能會造成系統資源的耗費,畢竟原生的函式庫會越貼近作業系統,資源的使用會比較少,效能也比較好。瀏覽器之間的差異相較於作業系統,差異是很小的,因此 Web 會是使用者介面的首選。

但為什麼還是會有跨平台的需求?畢竟不是每一個提供服務的廠商,都有足夠的工程師配額,能夠處理不同平台的開發。只要能夠節省成本,就永遠都會有跨平台的需求。

Web -> Mobile -> Dekstop -> CLI

一般使用者都能夠使用圖形介面 GUI 的應用程式,但終端機 Command Line Interface 就不同了,沒有經過 Linux OS 洗禮的使用者,通常無法適應一個字一個字敲打的指令列,通常也只有開發者才會去接觸 CLI 的程式。

在這幾種使用介面中,以網頁是最符合跨平台的開發方法,因為網頁的標準規格,各家瀏覽器都要遵循這些規格去開發,再加上有眾多框架與函式庫,解決了不同瀏覽器之間的些微差異問題,因此為應用提供網頁使用者介面,基本上是最常見的做法。

但實際上還是有很多應用程式,是沒辦法放在網頁裡面運作的,尤其是使用到 OS 原生的資源的應用。另外由於手機這種手持裝置的流行,人手一機,在面對一般使用者提供服務時,首先就會考慮提供手機 Mobile APP。

失敗經驗

過去曾經有使用過 Titanium 開發 iOS, Android 的失敗經驗,記得失敗的原因是 APP 只能做比較簡單的畫面,太複雜客製,非標準的 UI 元件,無法自由地透過 Titanium 產生,也無法產生具有不同平台特性的 UI 元件。

因此目前在 Mobile APP 比較常見的作法,是分開實作的,業界也分別需要 iOS 與 Android 的開發人員。也許當時我們是使用了一個封裝得不好的 Library 去開發,才導致失敗的結果。

不代表 iOS, Android 就一定要用原生開發,像 Game 的領域中,Unity 作為 Game Engine,也跨平台的 Game 開發做得很好。

Microsoft 也曾經想要統一 Desktop 與 Mobile 的使用者體驗,用 Tiles 做了 Windows Phone 及 Windows 10。現在大家已經知道,Windows Phone 已經完全在市場消失。而 Windows 11 的設計方式也已經向競爭對手看齊。

跨平台

是永久的需求及目標,成功與失敗的案例都有,但也都要經過嘗試,才能在一段時間後知道結果如何。

如果公司能夠負擔足夠的開發成本,或是專案運作的目標限制在某些平台上,當然就在不同平台去開發。要使用跨平台,如果能先用小的專案去測試,並先了解問題點,做先行測試,會是比較安全的作法。跨平台的效能跟資源耗費,必須要在可接受的範圍內。

另外也要考慮平台升級的問題,一但使用了跨平台的函式庫,就表示當核心升級後,會需要等待一段時間,才能取得跨平台函式庫的更新,這一段時間會是空窗期,遇到問題是完全無法解決的,也只能靜靜等待更新與修正。

References

2021 年加速開發的 8 個最佳跨平台框架

放弃坚持 15 年的原生开发,1Password 用 Electron 重写了全部代码

Top 10 Best Cross Platform App Development Frameworks in 2021

沒有留言:

張貼留言