跨平臺開發框架的大旗，究竟誰能扛起來？
近年來，移動端上各種跨平臺開發方案百花齊放，一方面是因為隨著移動網際網路的迅猛發展，純原生開發無法滿足業務快速增長的需求；另一方面，跨平臺可以增加程式碼複用，降低開發成本。在移動終端裝置的軟硬體、作業系統、開發工具鏈和技術社群等日趨成熟的今天，眾多開發者對“造輪子”躍躍欲試。
從早期的 PhoneGap，到後來的 React Native，再到現在的 Flutter，眾多跨平臺開發框架的應用實踐，與原生技術展開了一場博弈。使用者該如何在眾多選擇中，做好技術選型及落地實踐？使用跨平臺開發框架，應該注意哪些問題？對其通病有何應對方案？
InfoQ 記者帶著這些問題，採訪到了騰訊微信客戶端工程師方秋枋老師。另有結合微信團隊目前採用的跨平臺方案分析，希望能對大家有所啟發！
另外，方秋枋老師也將在 QCon 全球軟體開發大會（廣州站）：http://t.cn/ExOKNVC 分享題為《基於 C++ 構建微信客戶端跨平臺開發框架》 的話題，感興趣的同學也可以關注下。
InfoQ：從早期的 PhoneGap，到後來的 React Native，再到現在的 Flutter，移動端跨平臺開發框架一直是圈子裡的熱點。能否談談你對於跨平臺開發框架的認識？這些年技術在不斷迭代和演講，你怎麼看待他們背後的發展邏輯？
方秋枋：“Write once, run anywhere” 一直以來就是開發者的夢想。在移動客戶端領域，主流的跨平臺開發框架大體經歷了三個階段。
第一階段，主要通過 WebView 繪製介面，並通過 JavaScript Bridge 將系統的一部分能力暴露給 JS 呼叫。PhoneGap、Cordova 都可以歸屬於這一類。
第二階段，大家發現用 WebView 承載介面有效能等各種問題。於是將繪製交回給原生，通過 JS 來呼叫原生控制元件，編寫業務程式碼。Weex、RN 就是其中的佼佼者，這也是現在絕大部分跨平臺框架的思路。
第三階段，雖然使用原生控制元件承載 UI 解決不少渲染的問題。但是處理平臺差異性仍然需要耗費極大精力，效果也不盡如人意。這個時候，Flutter 提出的解決方案，就是連繪製引擎也自研，儘可能減少不同平臺之間的差異性, 同時保持和原生開發一樣的高效能。因此目前業界對 Flutter 的關注度也是最高的。
對於這樣的發展路線， 個人認為根本原因還是 Web 標準和能力在移動客戶端得不到很好的擴充套件與支援。實際上，Web 平臺才是真正意義上的跨平臺, 我們在所有主流作業系統上都能通過瀏覽器來訪問相同的網頁。目前第二，第三階段方興未艾，而 PWA、WebAssembly 等進一步增強 Web 能力的技術和標準並未成熟。 因此，在可預見的未來，移動端跨平臺開發還是主要以當前的形式為主。但是，隨著 Web 標準和能力的增強，最終絕大多數應用，只需要使用 Web 棧技術即可構建。
InfoQ：據瞭解，使用者在選擇跨平臺開發框架時，比較看重其是否具備熱更新的能力。但在 2017 年 3 月，蘋果下發了警告郵件，禁止 JSPatch 等 iOS App 熱更新方案，你如何看待“熱更新”這件事？
方秋枋：前段時間圍繞熱更新， InfoQ 主編徐川已經寫了一篇非常好的文章《 移動開發的羅曼蒂克消亡史》 。因此在這裡就不再贅述。
目前 iOS 平臺的熱更新更多地是用於修復 Bug，而不是直接拿來進行業務需求的開發和更新。實際上對業務體驗是無害的，但是也違反了蘋果的規則。因此，大家目前在 iOS 平臺基本只敢偷偷摸摸地做，沒有新的開源專案公佈。而安卓就百花齊放，有非常多的熱更新框架可以選擇。然而，安卓平臺側擁有了非常強的熱更新能力，使用者體驗有變得更佳麼？目前看來，好像還是沒有的，因為安卓平臺許可權控制等相關問題的存在，反而廠家會利用漏洞來騷擾使用者，獲取隱私。
從使用者角度來說，怎麼真正利用好熱更新能力來服務使用者，提升應用體驗，才是開發者真正需要考慮的問題。但是這也需要取捨。更開放的平臺策略更允許熱更新能力的存在，同時也會帶來其他的一些問題。
從開發者角度，我希望平臺能夠允許和放開熱更新技術。但從一個普通使用者的角度，我更喜歡當前蘋果的策略。
InfoQ：有人說，國外 App 開發偏重於“原生”，而國內 App 講究的是“迭代”。你認同這句話嗎？為什麼？
方秋枋：我不太認同這句話。其實國內國外的應用，都在不斷地迭代更新。只不過當下情況，國外 App 開發更傾向於使用原生技術進行開發，而國內則對跨平臺的熱更新能力非常關注。
InfoQ：2018 年，Airbnb 放棄使用 React Native，迴歸使用原生技術，究其原因主要是：專案龐大後，維護困難；第三方庫良莠不齊；相容上需要耗費更多精力……這是否是跨平臺框架存在的通病？有什麼解決辦法？
方秋枋：這的確是跨平臺框架存在的通病。 跨平臺意味著需要花費很多時間來解決平臺差異性問題，同時要面臨第三方庫不夠原生平臺豐富健壯的現狀。跨平臺其實是犧牲部分功能和體驗，換取開發速度和一致性的權衡，並不是業務開發的銀彈。
目前並沒有一個能完善解決這些問題的解決方案。 Flutter 可能相對來說在相容上會做得好一點，通過自底向上自研框架來儘可能減少平臺差異，但是可靠性仍需進一步檢驗，引入 Flutter 需要大家對自己公司業務有非常清晰的認知，並權衡好利弊。
對於初創公司和普通開發者，我個人的建議是可以利用小程式來進行跨平臺開發，把這些繁瑣的相容問題拋給小程式開發框架的開發者處理，這樣就可以把更多精力放在業務開發，也省卻了維護兩個平臺發版的工序。
InfoQ： 目前，微信團隊採用的是哪種跨平臺開發框架？基於哪種核心語言？是出於什麼考慮選擇這種語言的？聊一聊該框架的實現原理？
方秋枋：目前微信團隊並沒有統一使用一套跨平臺開發框架。我們也在積極探索各種可能性。
微信小程式，是前面提到的第一階段和第二階段的融合做法，利用 Webview 作為渲染容器，通過規定 Web 技術棧的子集（WXML、WXSS），讓客戶端獲得更多的渲染效能優化空間，同時通過規範化元件的使用，逐步引入原生控制元件代替 Webview 渲染。
除此之外，我們還探索了基於 C++ 進行跨平臺開發。實質上還是第二階段的做法，只不過是使用 C++ 作為中間語言，去編寫業務程式碼和呼叫原生控制元件。為什麼要採用 C++ 呢？ 因為 C++ 安全性會更高一點，同時效能也會更佳。可以應用在一些對安全性要求比較高的場景。 如果大家對基於 C++ 構建跨平臺框架和業務開發有興趣。可以關注一下 QCon 全球軟體開發大會（廣州站）， 我會更詳細地闡述如何基於 C++ 構建跨平臺開發框架。
InfoQ：你認為跨平臺開發的難點是什麼？Flutter 是如何解決這些問題的？你如何看待 Flutter 的發展？
方秋枋：從框架開發者的角度，我認為跨平臺開發的難點就在於處理平臺差異性。從框架使用者的角度 ，難點在於如果框架出問題了，維護成本將會變得非常高。
Flutter 通過自底向上自研框架來儘可能減少平臺差異，同時將 Dart 語言， 渲染引擎等組成部件都進行完整開源，任何人都可以除錯原始碼，當然維護門檻也是很高的。我認為如果谷歌願意繼續大力投入 Flutter 的開發，Flutter 會是跨平臺開發框架非常好的一個選擇。
方秋枋老師會在QCon 全球軟體開發大會（廣州站） 上帶來《基於 C++ 構建微信客戶端跨平臺開發框架》的話題分享，感興趣的同學可以來到現場交流。大會更有來自 BAT、京東、滴滴、網易等一線技術專家，共話微服務、大前端、人工智慧、高可用高效能架構、DevOps…13+ 熱門技術，探討多業務場景下的技術落地與發展趨勢。