作者丨趙鈺瑩、小智

Dropbox 最近宣布將放棄用 C++ 編寫跨 iOS、Android 平臺代碼，轉而使用各平臺的原生框架（Swift/Kotlin），理由是代碼共享相關的隱藏成本太高。有趣的是，2014 年，Dropbox 在給 Facebook 的開發人員做分享時，卻曾直言寫兩套代碼會帶來種種弊端，推薦使用 C++ 進行跨平臺開發。為什么幾年前的經驗之談卻成了幾年后的技術債？C++ 因何躺槍？跨平臺開發前景如何？本文試圖一一為你講解。

事件綜述

編寫一次，隨處運行。這句話不知道被多少工具和框架寫在開篇介紹中，用以吸引更多公司和開發者。然而，作為這一策略忠實的實踐者，Dropbox 近日宣布放棄這一想法，寧愿為不同的平臺寫兩遍代碼，也不用 C++ 跨 iOS、Android 兩大平臺共享代碼的方式進行開發。

早在 2013 年，Dropbox 就采用上述策略進行移動開發，這背后的想法很簡單：用 C++ 編寫一次代碼，而不是用 Java 和 Objective-C 編寫兩次。那時，整個移動工程團隊相對還比較小，但需要支持快速增長的移動路線圖。因此，公司希望找到一種方法，使這個小團隊可以快速交付大量 Android 和 iOS 代碼。

如今，Dropbox 完全放棄了這個策略，轉而使用各個平臺的原生語言（主要是 Swift 和 Kotlin，這兩種語言在剛開始制定移動策略時還不存在）。這個決定的主要原因是代碼共享相關的隱藏成本太高，這源于同一個基本問題：

以非標準的方式編寫代碼，使 Dropbox 承擔了一些開銷，而如果采用廣泛使用的平臺默認選項，就不必擔心這些開銷，這種開銷最終比只編寫兩次代碼要昂貴得多。

C++ 的問題？

隨后，Dropbox 總結了成本太過高昂的主要原因，比如自定義框架和庫的開銷、自定義開發環境的開銷、處理不同平臺差異的開銷以及培訓、招聘和留住開發人員的開銷，這與 C++ 本身存在的問題密切相關。但是，C/C++ 是唯一一種編譯器同時受到谷歌和蘋果支持的語言，如果使用其他語言將會產生一系列更麻煩的問題。

1、自定義框架和庫的開銷

關于使用 C++，最容易出現的開銷就是構建框架和庫，這大致可以分為兩類：

• 框架，讓開發者與主機環境交互，構建一個功能齊全的移動應用程序。例如 Djinni 、用于在后臺和主線程中運行任務的框架等。

• 一些取代本可以在平臺原生語言中使用的默認語言或開源標準的庫。例如：用于 JSON（反）序列化的 json11 ；C++ 非可空指針 nn 。

如果使用平臺原生語言，那么這些代碼都是不必要的。當然，并不排除個別開發者可以很好地利用開源 C++ 庫，但是 C++ 開發社區中的開源文化并不像移動開發社區那么強大（特別是幾乎不存在的 C++ 移動社區）。這些成本在 C++ 中特別高（與 Python 或 C# 等其他可能的非原生語言相比），因為它缺少一個功能齊全的標準庫。

雖然 C++ 標準委員會為了這門語言做了大量工作，甚至為了 C++20 的新特性舉辦了一場歷史上規模最大的會議（180 人參會），試圖通過會議確定哪些特性可以加入新版本，比如 Concepts、Ranges、Modules、Coroutines 等，但大部分開發人員并不認可此次調整，并將部分新特性歸結為“語法糖”，在社交平臺進行吐槽。

國外的一位游戲開發人員接連在社交平臺發表看法，甚至發表了一篇長文聲明自己不看好 C++20 的新特性，并認為新版本沒有解決最關鍵的問題，這讓其未出世就被群嘲。可見，整個 C++ 社區是存在一定問題的，很難讓其達到移動開發社區中的活躍度，很多問題也是懸而未決。

2、自定義開發環境的開銷

移動生態系統有許多工具可用來提高開發效率，但 C++ 社區就不太行。開發者必須投入時間構建支持 C++ 代碼共享的工具。甚至，Dropbox 親自做了定制構建系統，創建了包含 C++ 代碼以及 Java 和 Objective-C 封裝器的庫，并且生成 Xcodebuild 和 Gradle 都能識別的目標文件。這個系統是一個很大的成本支出和拖累，因為需要不斷更新以支持兩個構建系統中的更改。

3、處理不同平臺差異的開銷

盡管 iOS 和 Android 應用程序都是“移動應用程序”，通常具有相同的特性和功能，但平臺本身存在一些影響實現的差異，甚至不能真正地編寫一次代碼就在不同的平臺上運行，必須花費大量時間將代碼集成到不同的平臺中，并編寫特定于平臺的代碼（有時這些代碼就位于 C++ 層）。

4、培訓、招聘和留住開發人員的開銷

如今，市面上越來越難招聘到具有相關 C++ 經驗、對移動開發感興趣的高級工程師。當然，如果愿意提高招聘成本，給出更有吸引力的薪水，這個問題不難解決。但是，怎么把這些開發人員留住也是一個大問題。事實上，移動開發社區有大量新技術和新模式層出不窮，移動開發者可能根本不想從事 C++ 項目開發。

如上種種，通過 C++ 共享移動代碼的方式讓開發成本變得非常高昂，這也讓曾經的支持者 Dropbox 不得不選擇放棄。

跨平臺開發的 Yes or No

"Write once, run anywhere" 一直以來就是開發者的夢想。但從 Dropbox 的經驗來看，實現之路堪稱曲折甚至反復。

我們發現了一個特別有意思的新聞：2014 年，Dropbox 的開發人員給 Facebook 的開發人員做了個講座，分享了他們使用 C++ 做跨平臺開發的經驗之談。他們特別提到，iOS 和 Android 平臺代碼庫的不一致會帶來一系列問題：

• 開發和維護成本成倍增加。

• 開發團隊需要多次修復同樣的缺陷。

• 針對某個平臺報告的缺陷可能會被另一個平臺忽視掉。

• 不同平臺的 App 行為可能會有預料之外的細微差異。

• 性能優化成本高昂并且與平臺相關。

Dropbox 賴以克服上述這些問題的策略基礎就是為所有 UI 無關的代碼建立一個共享的跨平臺 C++ 庫，例如數據和網絡部分的邏輯。UI 部分還是使用原生代碼編寫，以便盡可能地利用平臺對動畫特效和設備傳感器等的支持，并且確保充分的響應速度。

5 年過去，當年的經驗之談似乎變成了 Dropbox 的技術債，他們最終放棄了用 C++ 做跨平臺開發，轉而用各平臺的原生語言做開發工作。

跨平臺開發，是時興潮流還是明日黃花？

2018 年，Airbnb 放棄使用 React Native，回歸使用原生技術，究其原因主要是：項目龐大后，維護困難；第三方庫良莠不齊；兼容上需要耗費更多精力……

騰訊客戶端工程師方秋枋接受 InfoQ 采訪時曾表示：

這些都是跨平臺框架的通病。跨平臺意味著需要花費很多時間來解決平臺差異性問題，同時要面臨第三方庫不夠原生平臺豐富健壯的現狀。跨平臺其實是犧牲部分功能和體驗，換取開發速度和一致性的權衡，并不是業務開發的銀彈。

微信團隊在跨平臺開發方面的解決方案是：

目前微信團隊并沒有統一使用一套跨平臺開發框架。我們也在積極探索各種可能性。

微信小程序，是跨平臺開發的第一、二階段的融合做法，利用 Webview 作為渲染容器，通過規定 Web 技術棧的子集（WXML、WXSS），讓客戶端獲得更多的渲染性能優化空間，同時通過規范化組件的使用，逐步引入原生控件代替 Webview 渲染。

除此之外，我們還探索了基于 C++ 進行跨平臺開發。實質上還是第二階段的做法，只不過是使用 C++ 作為中間語言，去編寫業務代碼和調用原生控件。為什么要采用 C++ 呢？因為 C++ 安全性會更高一點，同時性能也會更佳。可以應用在一些對安全性要求比較高的場景。

Flutter 會是跨平臺開發的終極之選嗎？這個問題很有意義。能實現跨平臺開發的框架也五花八門，讓人眼花繚亂。最流行的跨平臺框架有 Xamarin、PhoneGap、Ionic、Titanium、Monaca、Sencha、jQuery Mobile、React Native、Flutter 等等。但這些工具的表現也是高低有別，各有千秋。熱度不減的只有 React Native 和 Flutter，原因在于這二者背后有 Facebook 和 Google 背書，開發者更加信任。

Flutter 的優勢在于：它完全免費，徹底開源；可以用來更快地創建應用；具有出色的用戶界面（UI）；節省代碼量；可接入平臺原生功能；最適合 MVP 開發（最小化可行產品）；較老的設備也使用相同 UI 運行應用；減少測試工作量；更豐富的社區支持；較低的維護難度；內置來自 Dart 的包管理器。

其中不少特性如節省代碼量、接入平臺原生功能、支持較老設備、較低維護難度等等，都擊中了跨平臺開發的痛點。業界認為，目前跨平臺開發沒有一個完美的解決方案，相對來說 Flutter 在兼容上做得好一點，通過自底向上自研框架來盡可能減少平臺差異，但是可靠性仍需進一步檢驗，引入 Flutter 需要大家對自己公司業務有非常清晰的認知，并權衡好利弊。

隨著 Google 對 Flutter 的持續加碼，也許在不久的未來，Flutter 將成為跨平臺開發的最佳解決方案。

適配 Android P之非SDK接口限制的排查方法

一次 Android 權限刪除經歷

資本寒冬下的 android 面經

點個在看少個 bug????

總結

以上是生活随笔為你收集整理的宁愿写两遍代码，也不用C++跨iOS、Android平台开发？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。