隨著智能手機的發明，許多開發人員都提出了同樣的問題：如何為多個移動平臺構建和發布應用程序？ 包括最初的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”視圖。
　　
　　只用編寫一次UI代碼，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月統計
　　
　　以毫秒為單位加載和保存圖片; 越低越好。 統計從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，電池使用情況等）。雖然其他平臺當然也會發布自己的類似工具，但本地平臺已經存在了多年。
　　
　　高級Java IDE
　　
　　6.新平臺功能的緩慢整合
　　
　　XCode和Android Studio（基於IntelliJ）經過測試，始終是第一個發布新功能的，並保證可以訪問開發人員可用的100％的平臺功能。由於固有性質，跨平臺工具將始終在每一次更新的曲線後面。可以肯定的是，Xamarin一直很快采用，他們甚至大膽地聲稱要花幾個小時來包括新的操作系統功能，但問題是很多的。有時候，Appstore強制應用程序為64位CPU構建，而Xamarin尚不穩定。
　　
　　7.編程語言
　　
　　哪些編程語言被認為是“好”，哪些是“壞”的。每種語言都有自己的優點和缺點。但是，盡管如此，個人意見在這個討論中起著重要的作用，但一些語言本身比其他語言更安全。無論你的codestyle-check還是IDE有多好，只能使用一種語言而不是另一種語言避免某些錯誤。 Javascript（由React使用）允許你使用解釋器無法打印的拼寫錯誤，導致運行時錯誤，而不是拼寫檢查器類似的警告。
　　
　　javascript
　　
　　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,www.qinlinyu.cn641個，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或Unrealwww.yibaoyule1.com 這樣的東西。
　　
　　快速原型
　　
　　如果你很快想要測試一個想法並將其部署到一組測試人員，那麽你可能對應用程序的交互方式更感興趣，而不是它是否具有良好的性能。 根據你的專業知識，跨平臺工具集可以非常適合以快速簡便的方式創建原型。
　　
　　TL; DR
　　
　　你承諾了60％至90％的共享代碼，從而實現更快的開發和更少的維護。但由於工具不足，開發過程已經放緩，開發人員不高興，由於缺少庫，手工制作更多的組件，每一個軟件更新都會開始破解。部署時間更長。測試不足，所以有更多的錯誤。現在，你將開發成本削減了20％，而不是預期的60-90％，除此之外，你的用戶還會留下不良評級。
　　
　　我們已經看到它發生了，我們會繼續看到它發生。沒有人說這也會發生在你身上，但是在選擇平臺時請考慮這篇文章。客戶通過一個跨平臺的應用程序來找我們，要求使用本地技術重建它。沒有一次是相反的。
　　
　　國內某高校圖書館
　　
　　關於作者
　　
　　Mathijs Lagerberg在建立了幾個Android應用程序後，於2012年初共同創立了Pixplicity。 Android OS在這些時代還很年輕，只有很小的市場份額。在無數的語言中編程好幾年的生活，將這個新技術潛入頭腦，加入一個專註於構建移動應用的初創企業是有道理的。隨著時間的推移，Pixplicity已經發展成為一個有創意的技術機構，有幸玩過所有有趣的雙字母縮寫：A.R.，V.R.和A.I ..仍然在構建應用程序，但不是跨平臺的。

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