作者|黃剛（騰淵）
出品|InfoQ&阿裡巴巴新零售淘系技術部
随着移動網際網路的發展，Android 和 iOS 呈兩分天下之勢，跨平台開發也逐漸成為移動領域的熱門話題之一。怎麼看待其背後的發展邏輯？跨平台開發的難點是什麼？未來的發展方向如何？阿裡巴巴淘系技術部資深無線技術專家黃剛（騰淵）受 InfoQ 采訪邀約，分享了跨平台開發的發展趨勢和變化。
作者簡介
黃剛（騰淵） 阿裡巴巴淘系技術部資深無線技術專家，現淘系技術部基礎鍊路負責人，負責首頁、商品詳情、交易、資訊流等核心業務。2014 年加入阿裡巴巴，2018 年雙十一淘寶技術部技術隊長，2019 年淘系技術部技術隊長。
前言
騰淵認為：從早期比較流行的 Hybrid App，到後來的 React Native、Weex，再到現在比較火爆的小程式和 Flutter，可以看到跨平台的發展趨勢是架構變得越來越重。如果目前的業務情況下前台呈現比較不穩定并且整個前台開發占比較高，那麼應用跨平台架構的收益就比較高了。到底哪個方向更正确、哪個架構更好其實是沒有标準答案的，更多需要開發者因時制宜地選擇。
騰淵還會在即将召開的 QCon 全球軟體開發大會 2020（北京站）上擔任「移動新生态趨勢下的應用實踐」專題的出品人，感興趣的讀者可以關注。以下為黃剛（騰淵）的觀點精華。
如何選擇适合自己的跨平台開發架構？
在移動網際網路時代，當 Android 和 iOS 奠定了整個移動 OS 的地位後，跨平台研發就一直是一個大的研究方向或者說大的課題。這個話題其實很有意思，因為很多時候大家會有些預設的假設，比較容易忽視這個方向出現或者變熱的前提條件。
從 PC 時代開始，就有一些像 Qt 之類的非常優秀的跨平台軟體研發架構。但是我們回過頭來看，那個時候面向個人使用者的跨平台研發很難說是一個非常熱的方向，其中最主要的原因就在于 PC 時代 Windows 的絕對統治地位。假設今天我們在移動網際網路上隻有一個 OS 占絕對統治地位，那可能今天也不太會有業界同仁在研究跨平台研發這個事情了，這是一個大的前提。
在移動時代，在 Android、iOS 作為移動 OS 雙巨頭的格局下，天然就會帶來一個重複開發導緻移動應用開發成本增大的問題。要開發一個應用，服務端、前端都可以是一套班子，用戶端基本需要 Android 和 iOS 兩套開發班子，是以不難了解跨平台研發這個話題的起點在于降低研發成本。在這個基本問題下，往下衍生的問題就是多平台的開發增加的額外成本到底是多少，在整個研發生命周期中的占比是多少，跨平台的開發架構能多大程度上解決這個問題？隻有這個問題回答清楚了，我們才能明确适合自己的跨平台開發架構應該具備哪些特征，這個跨平台架構在一個 App 應用中的使用範圍是多大。
從早期比較流行的 Hybrid App 到後來的 React Native、Weex，再到現在比較火爆的小程式和 Flutter，可以看到跨平台研發架構變得越來越重。是不是一定越重、越新的架構越好？答案是不一定。
從應用的 Life Cycle 來看，研發階段隻是其中一個階段，是否具有長久的可維護性、可運維性也是需要重點考慮的問題。再到研發階段本身，整個研發是從前端到後端 End-to-End 的，跨平台更多地是集中在大前端領域内的話題，如果在當下的業務形态裡，前台展現是高度産品化、比較穩定或者對于性能以及互動的要求極度苛刻的，那麼 Cross-Platform First 未必是一個理想的選擇。
一方面是多平台開發工作在整個研發成本裡的占比不高，ROI 未必高；另一方面是 Cross-Platform First 是以犧牲平台特性為代價來達到跨平台的一緻性（本質上跨平台研發架構也基本無法做到多平台上表現得完全一緻性）。在達到一緻性表現的過程中，工程上的填坑成本可能更高。
反過來講，如果目前的業務情況下，前台的呈現比較不穩定并且整個前台開發占比較高，那麼應用跨平台架構的收益就比較高了，在阿裡比較典型的例子就是 Weex 在大促會場上的應用。
我們都應該了解，從 Hybrid 的方案到 React Native、Weex 再到 Flutter，本質上都是在研發成本、靈活性、性能體驗三者間找一個平衡點，隻是大家切入的點不太一樣，最終導緻整個解決方案有了不同。假設說現在你要做一個新的 App，可能整個開發團隊是多前端、少用戶端的，那麼我可能會比較建議大家多考慮 Hybrid 的模式；如果對性能要求比較高，就可以考慮用用 Weex 或者 React Native；反過來，如果是用戶端同學比較多，那麼考慮下 Flutter 未嘗不可。
其實我們也可以看到，像 Google 同時在推 Flutter 和 Kotlin，這兩個東西本質是不一樣的，Flutter 更多地展現 Cross-Platform First，Kotlin 更多地展現 Platform First，到底哪個方向更正确，哪個架構更好，其實是沒有标準答案的，更多需要開發者因時制宜地進行選擇。
阿裡各跨平台開發架構的發展及應用
當下阿裡用的比較多的應該是 Weex、DinamicX 和小程式這幾個架構，在不同場景下解決不同的核心問題。任何架構都不能脫離當時發展的背景讨論，這幾個架構是因為在不同階段解決了當時手淘的一些核心問題，是以才能在各條業務線上廣泛應用。
我們從 2015 年開始做 Weex，2016 年大規模應用。當時我們大促會場頁面從研發效率以及釋出的靈活性考慮，統一使用的是 H5，但在當時，性能和體驗都有些問題。同樣，當時手淘上衆多的導購業務因為很難接受 H5 的性能與體驗，強烈要求使用 Native 做頁面開發，這樣就又帶來了另外一個問題，即 App 的包大小的問題。Weex 在這個背景下誕生，在盡量保留 H5 研發效率以及部署靈活性的前提下，盡量提升頁面的性能體驗。
不難想象，在這種情況下，我們整個開發架構必然是面向前端、全面相容 H5 的研發模式。當然其中 Vue 和 Rax 這樣的前端架構也是功不可沒的。因為 Weex 的出現，大幅度提高了當時會場頁面的性能，而且滿足了大部分導購頻道對于性能的要求。導購業務在性能基礎體驗能夠滿足的情況下，其實很多導購業務還是傾向于更靈活的研發與部署模式，是以當時很多的導購業務還從 Native 轉回到了 Weex 進行開發，間接幫助了手淘 App 包大小的控制。
我們從 2017 年開始做 DinamicX，2018 年大規模應用。這個架構的誕生就要順着剛才的曆史接着往下講。Weex 解決了原先使用 H5 的業務的性能訴求，但是我們發現 Weex 在一些産品化程度很高的業務域内，依然不能滿足性能要求，比如說首頁這類一級 Tab 頁，是以這種業務基本都還是保留了 Native 的開發模式。
雖然 Native 的開發模式被保留了下來，但是不意味着這些業務對于開發的平台一緻性、研發效率、部署效率沒有要求。為了解決這些問題，DinamicX 使用了類似于 Android layout 的聲明式布局。相較于 Weex，DinamicX 并沒有引入腳本引擎的能力，通過犧牲部分靈活性，來達到性能的極緻。通過這樣的方式，能夠做到在性能基本和 Native 開發持平的情況下，比較靈活地調整頁面布局，再通過和我們内部的新奧創研發平台的結合，實作頁面布局與業務邏輯的分離。通過這樣的方式，DinamicX 這個架構基本解決了我們在基礎産品業務域内的研發效率以及性能體驗的平衡問題。
再來講講小程式架構，現在我們更多地是使用在了商家應用場景上，核心是為了解決我們在集團多個 App 之間業務快速部署以及外部商家開發的頁面快速入駐手淘并且能夠得到有效管控的問題。小程式最近比較熱，這個點上我就不展開了。
至于 Flutter，我們内部使用比較深入的是閑魚的同學。對于跨平台領域的解決方案，我不太秉持隻有一個正确答案的想法，對于終極解決方案這個結論我還是比較存疑的，但有一個需要探索的重要方向是可以确定的：決定一個跨平台解決方案的成敗有兩個重要因素，一個是技術産品化程度，或者說是工程化水準；另外一個是整個開發者生态的建構。如果從這兩個因素來看的話，可以明确都還有一段很長的路要走。手淘今年也成立了專門的團隊在研究 Flutter 的應用，我們可以拭目以待。
5G 時代給移動領域帶來的新機會
5G 也是大家非常關注的熱點，我們内部的讨論也會比較多。毫無疑問，5G 将能帶來一些爆點場景，但是這方面的預測是相當困難的。現在市面上關于 AR/VR 和多媒體應用的暢想理論上都沒有什麼問題，但是從商業的角度來講，我們還不知道整個變化對于成本方面的影響，而成本的考量對于應用場景是極其重要的。
我舉個簡單的例子，很多 App 在視訊自動播放下都有一個設定選項，叫做“Wi-Fi 下自動播放”，絕大多數 App 在使用移動流量播放流媒體之前一般都會給使用者彈一個提醒，“目前在用移動流量播放，可能會産生資費”。大家想一想，這個背後的本質是不是就是關于成本的考量。這個限制其實對于整個應用的場景影響是非常大的，正如 4G 的流量費用大幅降低讓移動網際網路走到了億萬使用者手中，5G 的使用成本将極大影響它的使用場景。但是我們依然可以做一個大膽的預測，當 5G 幫助大家極大突破了網絡傳輸速率的束縛後，後面緊接而來的可能是對終端裝置算力大幅提升的訴求，最後才創造出一個個嶄新的應用場景，這是一個從網絡到終端裝置到應用場景整體更新的過程。
我個人最近比較關注 On-Device AI 的應用實踐，如果說跨平台解決的是節約研發成本的問題，On-Device AI 的應用是真正會産生業務增量的技術新賽道。過去的一年中，在 On-Device AI 上手淘有了比較大規模的應用，一個典型的場景就是資訊流這個商品、内容等的混合智能推薦場景。我們通過更低的資源消耗、更多的資料輸入、更實時的感覺，在整個資訊流場景導購側有了非常大幅度的提升。過去一年的實踐隻是一個開端，我們齊頭并進的應用場景還包括 AR 美妝、消息 Push、直播等等，這塊的想象空間是非常大的。
小結
在這一篇文章裡，我們介紹了跨平台開發的發展趨勢和變化，如何選擇适合自己的跨平台開發架構？阿裡各跨平台開發架構的發展及應用，以及5G 時代給移動領域帶來的新機會。未來「淘系技術」将持續與大家分享前端前沿技術和應用實踐。
We are hiring
淘系技術部依托淘系豐富的業務形态和海量的使用者，我們持續以技術驅動産品和商業創新，不斷探索和衍生颠覆型網際網路新技術，以更加智能、友好、普惠的科技深度重塑産業和使用者體驗，打造新商業。我們不斷吸引使用者增長、機器學習、視覺算法、音視訊通信、數字媒體、移動技術、端側智能等領域全球頂尖專業人才加入，讓科技引領面向未來的商業創新和進步。
請投遞履歷至郵箱：[email protected]
更多技術幹貨，關注「淘系技術」微信公衆号！
