前言

翻牆偶然讀到一篇不錯的文章，隨手翻譯，作者是jielse發表於androidHub。

隨著智慧手機的發明，許多開發人員都提出了同樣的問題：如何為多個移動平臺構建和釋出應用程式？ 包括最初的iPhone和BlackBerries，Android，以及Windows Phone和Web。 每個平臺單獨釋出應用程式是很昂貴的。我們最初的想法： 肯定有一個解決方案可以降低開發多個應用的成本。但是事實是不是這樣的呢？

在Pixplicity，超過六年來，我們一直在開發應用，並且企圖解決這個問題。結局並沒有什麼不同：雖然我們在提供全方位解決方案之前，就開始專門用本地開發人員開發Android。多年來，我們嘗試並測試了許多跨平臺解決方案，如PhoneGap，Xamarin和React。 最後，我們決定採用Android和iOS的本地解決方案。 具體的原因會在下文解釋。

那麼這個跨平臺又是什麼呢？

iOS應用程式傳統上用Objective-C或Swift編寫; Android應用程式用Java或Kotlin。 這些都是原生語言。 這意味著如果你想為兩個平臺製作應用程式，則需要至少知道兩種程式語言。 將web新增到組合中，你將需要用於UI的HTML + CSS + JavaScript，以及用於業務邏輯的PHP或Ruby類。 那將是很大的工作量。

跨平臺解決方案旨在通過為多個平臺使用單一程式語言來簡化（部分）此問題。

這些解決方案可以分為兩類：

1.使用所有平臺支援的Web技術的。 這些解決方案基本上載入了應用程式中的移動瀏覽器，並在該瀏覽器中執行所有邏輯，同時提供傳統網站技術沒有的附加功能，例如推送通知或訪問檔案儲存。 這個類別包括PhoneGap（或Cordova），Sencha和Ionic（一個構建在PhoneGap之上的框架），並使用JavaScript作為主要的程式語言。

2.另一類通常被稱為“本地跨平臺”，因為程式設計師編寫的程式碼由程式自動轉換為原生程式碼。 這具有以下優點：所產生的應用程式可以實現近乎原生的效能，而基於Web的解決方案則具有在瀏覽器中執行未編譯的程式碼的開銷。 這個類別包括React Native和（可能）最流行的一個：Xamarin。

這些本地跨平臺解決方案可以進一步分為

兩個類別：

1.共享UI程式碼（應用程式的可視部分）和不具有這些子類別的子類別。例如，常規的老Xamarin在平臺之間共享業務邏輯程式碼，但UI程式碼（和其他特定於平臺的程式碼）是專門為每個平臺編寫的。 即使作為開發人員，你正在使用單一語言（在這種情況下為C＃），你仍然在iOS和Android上為UI編寫單獨的程式碼。

2.Xamarin還提供了一個名為Xamarin.Forms的API，可以共享UI程式碼。 不用編寫單獨的UI程式碼，而是使用Xamarin.Form自己的標記格式來編寫它，然後將其轉換為本機控制元件。 React也屬於這一類; 而不是編寫本機檢視，將會寫出“React”檢視。

優點

所有這些技術都相當漂亮。共享程式碼意味著更少的工作和更少的學習，讓我們來看看使用上述選項之一的好處：

1.共享業務邏輯 - 將業務邏輯寫入一次，在任何平臺上執行。 Google通過使用自己的Java對Objective-C轉換器J2ObjC，在Android，iOS和Web應用程式中重新使用其70％的程式碼。這大大減少了構建應用程式所需的工作量，降低了成本，並縮短了釋出時間。 2.維護 - 共享程式碼不僅降低了初始構建期間的成本，而且對你的應用程式的使用壽命也將是有益的。 3.學習一門語言 - 如果你是一名尋求多個平臺的開發人員，那麼學習單一語言（或一組語言（通常是一種程式語言，構建指令碼語言和使用者介面的標記語言）比兩套更容易。 4.同一個團隊在兩個應用程式上工作 - 這是一個很大的工作。一個團隊經費更便宜，使專案管理更容易，更高效地工作。知識在團隊中更容易分享。 Android團隊的成員可以幫助iOS團隊，反之亦然，因為沒有Android團隊，沒有iOS團隊。只有一個團隊 共享單元測試 - 如果你有單元測試，跨平臺程式碼庫還可以共享單元測試。這意味著在寫測試時花費的時間更少。 5.與網路一起使用 - 當使用基於Web的解決方案（或支援網路的本機）解決方案時，所有上述規則也適用於Web平臺。 Xamarin只能在iOS和Android上共享程式碼的地方，基於網路的工具在你的應用程式的網頁版本之前提供了所有的優點。

顯然，無論你是單一的開發人員，跨多個開發團隊的跨國公司，還是學習構建你的第一個應用程式的學生，都可以從這些優勢中獲益很多。 “寫一次，無處不在”它經常被引用，雖然我不會認為它有時是專案的完美解決方案，但這聽起來太好了。

——by谷歌高階軟體工程師Chet Haase

多年來，Pixplicity的團隊和我使用了幾個平臺（不同程度的成功），我們可能不會再停止嘗試新的平臺。一路上，我們遇到了一些重大的陷阱，我認為在提交跨平臺工具之前應該仔細考慮。

缺點

所有的大公司都是跨平臺的嗎？ Google建立並使用（很多）J2ObjC。 Facebook建立並積極維護React。微軟收購併非常積極地維護Xamarin。

1.不同的平臺是不同的

你無法為一個平臺構建應用程式，並希望在將其複製貼上到另一個平臺上時獲得良好的評分。我知道你想要，雖然你技術上可以，但你不應該這樣做。 Android和iOS是不同的，Android和iOS使用者是不同的，他們應該接近不同。每個平臺都有自己的設計指南和規則來開發，使用者會知道你什麼時候破壞他們。

正如谷歌所說：

J2ObjC不提供任何型別的平臺無關的UI工具包，也沒有計劃在未來這樣做。 我們認為iOS UI程式碼需要使用Apple的iOS SDK（使用Android API的Android使用者介面，使用GWT的網路應用程式UI等）Objective-C，Objective-C ++或Swift中編寫。

Facebook，在React的官網上寫道：

值得注意的是，我們沒有追求“一次寫作，在任何地方執行”。不同的平臺具有不同的外觀，感覺和功能，因此我們仍然應該為每個平臺開發離散應用程式，但是同樣的工程師應該能夠為任何選擇的平臺構建應用程式，而無需為每個平臺學習一套不同的技術。 我們稱之為“學習一次，寫在任何地方”。

所以這意味著當你想要針對每個平臺優化UI時，共享UI平臺（如Xamarin.Forms）已經在視窗之外。這反過來意味著近100％的程式碼共享成為一個無法達到的目標。根據你的應用程式的性質，假定在平臺上共享60％的程式碼。

網路再次與移動平臺完全不同，至少是在膝上型電腦或桌面上使用時。螢幕大小很重要，鍵盤的存在也是如此，使用滑鼠與觸控式螢幕時的互動也是如此。一旦瞭解了效能，你將看到基於Web的解決方案的好處並不多，除非你在網路技術方面非常有經驗，絕對不想學習新的語言。 請注意，平臺的差異不僅限於你的應用程式的視覺化方面。它包括在每個作業系統上存在，丟失或不同的所有功能。 Android開發人員可以使用大量功能，這些功能在iOS上是不可能的。想想Android的豐富的通知，開放藍芽接入，NFC和USB通訊，永遠線上檢視，即時應用程式，啟動螢幕小部件，或許更多。 iOS反之亦然：智慧應用橫幅，專用加密硬體，3D觸控。其他的不同之處在於跨平臺的包裝器是統一的：畫中畫，ARKit與ARCore，播放音樂的機制，以及應用在後臺執行任務的時間和時間，何時以及如何請求許可權，訪問外部儲存...

感謝Google的高階軟體工程師Romain Guy解決了我們的部分擔憂。

2.效能

比本地程式更快是不可能的。 本地跨平臺程式碼被翻譯成位元組碼或本地機器碼，因此理論上可以實現原生效能，但是經常會有各種各樣的侷限。 例如，Xamarin向每個應用程式傳送一個導致一些開銷的功能庫，這對於動畫的平滑性或對使用者互動的響應可能並不重要，但它在啟動時間，記憶體使用和應用程式大小方面都很重要。 Xamarin內建的一個簡單的“hello world”應用程式可以佔用驚人的16Mb（比Instant App的最大尺寸大4倍）。

以毫秒為單位載入和儲存圖片; 越低越好。 統計從2017年8月

基於網路的方法的效能甚至沒有降低太多。傳統上在移動瀏覽器或網路檢視中執行的網站對於效能來說是不利的，但是在多年來已經有了很大的改進，響應能力的差異不僅是可測量的，而且也非常顯著。一個簡單而精心製作的基於Web的應用程式可能會欺騙使用者認為它是本地的，但是無論如何，動畫像其UI元件一樣平滑，螢幕轉換或裝置旋轉都會讓你失望。這是Facebook發明了React的主要原因。

“不幸的是，由於所有渲染都是使用Web技術完成的，所以我們無法產生真正的本地使用者體驗。” -by Facebook

3.易於擴充套件性

對於我來說，這是一個個人的抱負，因為我在建立Xamarin應用程式時遇到了很多麻煩。這些工具一直很麻煩，開發過程很麻煩，所以我必須盡力保持不要對Xamarin造成不利影響。

4.錯誤

Android和iOS是堅實的平臺，但即使存在一些bug。在作業系統，開發工具和使用的庫中存在錯誤或意外或未記錄的行為。在開發過程中新增另一層軟體，你將新增更多錯誤。在Xamarin的中，這個列表是很長的。在我們的辦公室有一個名為“Xamarin Sh * t的大清單”的共享檔案。它不僅僅處理更多的問題，而且還增加了工具鏈的複雜性，從而導致了更復雜的除錯過程。

5.工具的不成熟

跨平臺工具鏈比本機平臺不成熟的事實並不僅僅是導致更多的錯誤發生。這也意味著它們不完整。想想XCode和Android Lint執行的自動化程式碼檢查，它會在開發過程中警告錯誤和安全問題。想想IDE的幫助和加快編寫程式碼，有助於跟蹤錯誤，跟蹤效能問題（記憶體，CPU，gpu，電池使用情況等）。雖然其他平臺當然也會發布自己的類似工具，但本地平臺已經存在了多年。

6.新平臺功能的緩慢整合

XCode和Android Studio（基於IntelliJ）經過測試，始終是第一個釋出新功能的，並保證可以訪問開發人員可用的100％的平臺功能。由於固有性質，跨平臺工具將始終在每一次更新的曲線後面。可以肯定的是，Xamarin一直很快採用，他們甚至大膽地聲稱要花幾個小時來包括新的作業系統功能，但問題是很多的。有時候，Appstore強制應用程式為64位CPU構建，而Xamarin尚不穩定。

7.程式語言

哪些程式語言被認為是“好”，哪些是“壞”的。每種語言都有自己的優點和缺點。但是，儘管如此，個人意見在這個討論中起著重要的作用，但一些語言本身比其他語言更安全。無論你的codestyle-check還是IDE有多好，只能使用一種語言而不是另一種語言避免某些錯誤。 Javascript（由React使用）允許你使用直譯器無法列印的拼寫錯誤，導致執行時錯誤，而不是拼寫檢查器類似的警告。

8.庫的可用性

流行的跨平臺解決方案通常有一個良好的包管理器，可以提供各種各樣的外掛或庫。例如，Xamarin的NuGet儲存庫具有驚人的大量外掛，並且包括許多流行的本機庫。這些儲存庫中沒有一個與可用於本地平臺的庫的數量進行比較。你經常可以移植現有的本機庫，不好的事情是你經常需要這樣做。而對於某些跨平臺技術，這意味著你將需要了解本機程式語言，這是你在選擇跨平臺語言時所要避免的。

9.緩慢的編碼和執行週期

誠然，這個論點有兩個方面。有基於Web和本地的跨平臺選項，可以很快地顯示程式碼更改，還有一些平臺，每次你做一個小的改進時候，都需要部署到裝置或模擬器上更改。

10.白標籤

當你為不同的客戶端部署不同品牌的應用程式時，這一點很重要。 Android上的“構建版本”或iOS上的“目標” - 這些平臺具有簡單的系統來支援這一點。我所知道的跨平臺方法並不支援這一點，所以你將在構建過程中最終編寫自己的解決方案並使每個部署更加複雜。

11.專業知識

個人擅長是一個主觀的事情。如果你在Ruby中有豐富經驗，那麼你可能最喜歡在Rhomobile中建立移動應用。如果你在過去30年裡一直在Basic程式設計，你可以堅持你所知道和使用B4X。 Pixplicity的開發人員擁有多年的本地技術經驗，我們長期以來一直在高水平程式設計，並經常在我們的Android學院和世界各地的會議上教授我們的知識。這會影響你在選擇技術開發應用程式時的選擇，但應該如何？

12.學習一種新語言

但這是簡單的嗎？如果你想編寫一個高質量的應用程式，你需要知道你正在定位的平臺。你需要知道平臺可以做什麼和不能做什麼，他們的SDK提供什麼，甚至你需要考慮哪些錯誤或特性。對於每個平臺通常甚至每個平臺的每個版本。很容易估計你仍然需要學習的知識數量，遠超已經知道的知識。如果你是有經驗的C＃開發人員，那麼關於.Net和GDI的所有知識都是無用的。實際上，學習程式語言是應用程式開發的容易部分。這是從C＃到Java或從Swift到Kotlin的一小步。如果你理解這個概念，語法是微不足道的。

13.多年的經驗

當然，像Ruby，C＃或JavaScript這樣的跨平臺語言已經存在了，但這些平臺還沒有。 React Native於2015年3月釋出。在撰寫本文時，根本無法找到超過2.5年經驗的React Native開發人員。

14.文件

任何體面的跨平臺解決方案都有很好的記錄。本土發展記錄更好。他們有一個更大的線上社群。他們有更多的會議和更多的本地會議。在Stack Overflow上，Android + Java上有191,918個積極的問題，iOS + Swift上的103,641個，React的59,355個，Cordova的54,126個，Xamarin的25,976個。當然這表明社群規模和參與度，而不是本地程式設計是難於使用的。

15.業務依賴性

所以現在你知道我非常不喜歡跨平臺的開發，希望現在也可以這樣做。但到目前為止，我甚至只涵蓋了應用程式開發的實踐方面。我們來看看未來，看看它會如何影響你的業務。 蘋果和谷歌有巨大的團隊建立他們的平臺，只要這些平臺存在，他們就會有這樣的一面。這是你可以獲得的最佳保證，即對他們提供的工具的長期支援，以及其積極的持續發展。本地平臺的普及也為社群周圍的社群提供了更大的支援，並且有更多穩定的經驗豐富的程式設計師供應。 然而，跨平臺工具完全依賴於為其資助的公司的議程。他們都沒有對支援和未來計劃提供任何保證。沒有保證他們將與下一次更新的Android或iOS相容，不能保證他們下個月甚至會存在。如果發生這種情況，你只能希望這項技術將被移交給社群，並將繼續作為開源，毫無疑問，發展速度將會慢得多。 “該公司沒有提供任何保證，它不會拉插入專案 。”

Ariel Elkon關於React Native的評論。 如果過去是未來的任何跡象，那麼當今流行的跨平臺解決方案將在大約兩年的時間內被取代。 Titanium，PhoneGap和Adobe AIR都被視為跨平臺開發中的下一個重要任務。現在是React和Xamarin代替;先進的Web應用程式可能在未來接替他們。

注意

那麼什麼時候應該使用一些跨平臺的工具包呢？ 有兩個很大的例外：

遊戲 -

遊戲通常不依賴於本機元件。 他們正在使用自定義UI元件，這些UI元件旨在適應遊戲的外觀和風格，因此無需編寫本機佈局。 無論是2D還是3D，遊戲通常都是建立在OpenGL之上的，其中效能非常好，視覺邏輯構成了應用程式的很大一部分，可以跨平臺共享。 如果你正在做一個遊戲，那麼是的，你應該使用像Unity或Unreal這樣的東西。

快速原型

如果你很快想要測試一個想法並將其部署到一組測試人員，那麼你可能對應用程式的互動方式更感興趣，而不是它是否具有良好的效能。 根據你的專業知識，跨平臺工具集可以非常適合以快速簡便的方式建立原型。

TL; DR

你承諾了60％至90％的共享程式碼，從而實現更快的開發和更少的維護。但由於工具不足，開發過程已經放緩，開發人員不高興，由於缺少庫，手工製作更多的元件，每一個軟體更新都會開始破解。部署時間更長。測試不足，所以有更多的錯誤。現在，你將開發成本削減了20％，而不是預期的60-90％，除此之外，你的使用者還會留下不良評級。 我們已經看到它發生了，我們會繼續看到它發生。沒有人說這也會發生在你身上，但是在選擇平臺時請考慮這篇文章。客戶通過一個跨平臺的應用程式來找我們，要求使用本地技術重建它。沒有一次是相反的。

關於作者

Mathijs Lagerberg在建立了幾個Android應用程式後，於2012年初共同創立了Pixplicity。 Android OS在這些時代還很年輕，只有很小的市場份額。在無數的語言中程式設計好幾年的生活，將這個新技術潛入頭腦，加入一個專注於構建移動應用的初創企業是有道理的。隨著時間的推移，Pixplicity已經發展成為一個有創意的技術機構，有幸玩過所有有趣的雙字母縮寫：A.R.，V.R.和A.I ..仍然在構建應用程式，但不是跨平臺的。