移動應用架構演變及泛前端趨勢下移動團隊破局

07-06

個人簡介

早期經歷是10年入行做java服務端和PC客戶端，11年以安卓個人開發者入行。

12年進入掌閱做閱讀器和排版引擎，期間也有機會做了一些電商、金融、智能穿戴方面的項目。

14年加入去哪兒，一直做圍繞移動端方面的研發。

背景

去年客戶端團隊從原生開發棧切React Native時想做一個分享，當時正是機票客戶端主業務開始切React Native初期，有些原生開發者困惑為什麼選擇逐步放下已經熟悉的技能和經驗，去使用RN這種較新的甚至「帶坑」的非官方的異構技術作為未來幾年的主要技術設施。做這樣一個主題是想對團隊成員在技能和心理認知上的做前期引導。

原生開發體系的演進

從2010年移動熱潮出現至今，回顧這些年來開發體系的演化還是蠻大的。

首先是小應用時代

大概在2011年左右，絕大多數是功能和業務單一的工具+遊戲類應用。之所以叫小應用時代，因為開發一個應用所需人少（1-3人），功能單一，業務邏輯少、尺寸小（普遍1~3MB）。那個時候的應用架構比較簡單，像網路、緩存、日誌、ORM、事件匯流排等基礎部分封裝為庫和框架做依賴下沉，其餘具體的功能業務交互和邏輯都放到主項目中。

早期的組件化方案 -- 靜態組件化架構

到了2013年左右開始出現「航母級」應用，類似像去哪兒旅行、攜程、天貓這樣的單一app里其實承載了n多個業務品類，這個階段稍大一些的應用里每個業務單元背後已經是專門團隊開發維護，在業務和功能膨脹、團隊拆分業務細化深耕的趨勢下之前的單點技術架構在協同性上效率會非常低，於是出現了早期的靜態組件化方案，主項目只是一個launcher的角色，具體的業務模塊是獨立的project，彼此之間使用aidl/schema/message/eventsbus等方式互操作。之所以叫「靜態」，是因為各個模塊只是開發階段彼此獨立的單元，但在部署、運行時還是把代碼和資源搞到了一起。

動態化組件架構

有了早期的組件化，接下來希望每個組件都能動態部署更新、載入和卸載，這個階段湧現了很多像atlas、qunar spider、small等開源閉源動態載入技術；動態化組件不僅能做到開發階段模塊隔離，在編譯期間和部署階段也是獨立的，運行時按需部署、載入對應的組件。

在這個階段Qunar較早實現了動態化組件技術並完善了運維設施，可以基於組件化技術對各BU的安卓組件進行發布熱更、回滾運維和以組件為單位的缺陷跟蹤統計。

虛擬化容器技術

目前主流的動態化組件是需要組件本身按照一定的規則去做特意編寫和打包甚至需要修改aapt的資源id生成規則，容器化技術類似於Android版的Docker，把應用所依賴的系統組件實例hook掉，提供一個偽環境。行業可見範圍內比較早期的原型是2015年360手助團隊的DroidPlugin和和天才少年Lody的Virtual App，後來兩位都另起爐灶做了商業化並停止更新開源版本。大家感興趣在安卓應用市場下載「閃電盒子」體驗。

異構開發方案

做一個app，除了原生開發以外還有很多其他選擇，在移動遊戲領域國內幾乎沒有團隊選擇用官方的或非跨平台的方式開發。因為這類應用開發複雜度較高且需要頻繁更新，11年左右就出現了類似cocos2d-x、egret這樣的包括跨平台開發框架、地圖/角色/骨骼編輯器等一整套設施解決方案。事實上在通用研發範疇，雖然沒有像遊戲開發那樣極端，但一個應用中原生代碼所佔比例已經越來越少，尤其業務驅動型產品中hybird已經是半壁江山。

這些異構方案被設計出來是有原因的，他們都有一些共性，一方面是它們都跨平台，只需開發一套代碼稍加適配就能跨不同系統運行，這樣能大幅提高業務的交付效率和單位人力產出；二是這些異構開發方案大多是引用了動態語言，天生能夠運行時動態載入，自然具備了熱部署、熱更新、熱修復和回滾的能力。

主流的異構開發方案分類

Hybird

最早出現的Hybird簡稱hy，它的原理是利用android和ios上的webview，webview容器提供了執行html、css和js腳本並完成渲染等完整的browser能力，需要原生功能支持就開發原生函數去port成javascript的api調用。

hy因為在開發協作上比較簡單並且背靠海量的生態資源很容易跨平台，至今是最普遍成熟的跨平台方案。但缺點也明顯就是載入和執行效率比原生慢，視圖和動效過於複雜場景容易出現性能熱點，細節像流量消耗、耗電量卡頓這些問題優化空間有限，不同瀏覽器內核上存在碎片化的適配點。

腳本+DSL類

第二類是像ReactNative、Weex、美團Picaso、阿里virtual view（可以看成是這個方向去掉script保留DSL的簡化版）等，腳本執行計算任務，用DSL來描述布局樣式和對屬性事件的綁定，運行時DSL在native層翻譯成native組件拼接構造出來，實際的視圖渲染和網路/IO等都是在native層來完成。這類方案和hy相比的優點是在開發者具備足夠經驗和技巧的前提下性能可以無限接近於原生，二是很容易和純native實現的控制項無縫集成，rn、weex這類技術因為實際繪圖就是用原生組件，所以可以很容易實現rn里套native，native里套rn這樣的特性。即便rn中出現性能熱點，多數情況都是可以用native來輔助解決。

由於早期的定位和設計原因，React Native的實現是兼容性優先而非性能優先，目前某些場景下還是有一些性能局限，主要是js和native域的非同步互操作延遲略高尤其不適合觸控聯動這類動效，還有就是渲染層從flexbox轉換成android本身的組件布局這個冗餘過程有性能損耗，我們針對React Native做了APM自動化性能分析設施幫助開發者在早期階段及時定位發現性能缺陷，並且facebook官方已經在著手改進rn的線程模型和渲染機制，大概會在18年底最晚2019年出一個比較大的底層重構版大幅提升性能。

獨立運行時

這是比較極端的解決方案，比如被微軟收購的xamarin，還有google的flutter，原理是在安卓上繞開Dalvik/ART，自己搞了一套虛擬機，而且把實際視圖渲染（大多基於skia）也在裡面做。優點是容易做成一個統一一致的系統無關的開發模型，理論上性能可以等同甚至超過Android原生方案。

對於iOS，由於蘋果大爺的政策原因，在iOS上再跑一個虛擬機有被拒審下架封號的風險，所以xamarin和flutter為iOS做了一套llvm編譯器，能把c#和dart直接編譯成機器碼，這樣只是用非官方語言去寫，但編譯出來的二進位文件對蘋果來說和oc、swift編譯出來的無異。但這個方式有個短板就是喪失了動態載入能力，不能熱部署熱更新。

移動端核心技術的變化趨勢

如果在5-10年前，什麼是移動開發，基本就是指開發一個app，什麼是核心技術，一套包括交互控制項、網路、存儲、MVC/P/VM、事件匯流排、ORM、日誌、圖片、緩存等的通用開發架構就是核心技術，但現在因為技術生態本身的積累，很多技術已經通過開源、培訓、mooc下放，技術門檻降低了。

那麼現在移動端技術，開發一個app已經是一個比較廉價的事情。未來幾年移動端技術哪些方向是可以幫助團隊和個人建立技術壁壘，我覺得有這些方面。

一個是最開始說到的基於虛擬化容器的動態化方案，這個方案在業內已經能看到非常成熟的產品，只是掌握這些技術的個人和公司現在都沒有把成熟的版本開源出來。目前能看到的主要是其app叫閃電盒子的公司，還有一個叫做Virtual App，和閃電盒子類似源碼都已經停更轉做閉源了，這兩個技術主要方案一樣都是把app所依賴的系統組件用動態代理替換掉，做大量的hook替換。

第二類是那些異構開發方案，在通用研發範疇尤其像常規界面和邏輯計算這些，原生開發技術是非常容易被跨平台方案所替換，這個本質上不是團隊或個人的選擇而是行業的選擇。在大趨勢下未來3-5年如果還要繼續做移動端技術，React Native/Weex/Flutter三個裡面從底層到應用至少要精通一個，PWA可關注。

第三類是垂直領域的技術，比如像圖像處理、AR/VR、音視頻編解碼流媒體、瀏覽器內核、閱讀排版引擎、複雜動效、更高效的UI繪製如litho等等。在至少一個專項領域去做深做透。

第四類是周邊運維包括對項目的定製化構建、持續集成、性能監控、代碼規範審查自動化、自動化測試這些。

泛前端趨勢下移動團隊和開發者面臨的挑戰和選擇

移動端熱潮褪去

早年在大學時候非常熱衷微軟系技術，從win32/mfc到早期的winform再到wpf、silverlight、wcf、ado ef、enterprice libary大致都搞了一遍。畢業前後一年的實習和工作主要和PC客戶端、Silverlight網遊有關，起初沒對Android感冒，11年那會正直第一波移動熱潮，在身邊同學的感染下以「安卓個人開發者」的方式切入這個領域，頭一年做了幾款小遊戲和工具類的app，通過投放移動廣告補貼生活，當時的感覺是雖然開發工具和官方的api、庫、框架相對.NET粗糙陳舊且系統的安全性、性能、兼容性問題多，但這樣一個免費且開源可定製系統確實命中了手機行業的痛點，尤其藉助早期的MTK方案大批手機公司繞過symbian、wince的授權壁壘快速切入進智能手機市場，Android終端設備數量的爆髮帶來了大量移動開發需求，以往web和pc的需求量快速萎縮。一部分java/.net開發者踏著這波市場供需更替的熱潮轉移到android和iOS陣地。

2015年後，一方面移動應用方面的創業增速下降，而且各種開閉源異構技術趨於成熟，通用型研發對原生的需求在持續下降，事實上即便沒有react native這樣的技術，hy或其他方案也會替換大部分的原生開發。就像以前java替代C/C++，web替代桌面客戶端的過程，不是原生開發不好，而是不可替代性在減弱。

市場需求下降，但從業人員供給沒有降低（大家都還年輕，最早一批移動開發者也就30+歲），那麼傳統的移動開發團隊和個人需要承擔的職能和技術輸出必定要有所轉變。

如何規劃未來要做什麼，可以從兩個角度出發

跟隨行業熱點趨勢，就是那些短期內聚集開發者關注的技術，簡單的篩選方式是通過Github Trending挖掘。

從公司需求、項目技術痛點出發，比如面對競品建立垂直技術壁壘，提高業務交付效率，減少版本生效延遲、研發完成即發布、發布即生效、線上問題快速修復回滾，怎麼自動化保障代碼規範和項目質量等。

轉變與堅守

在技能遷移甚至換賽道的過程中轉變的是具體的方式方法、語言、庫、框架甚至架構，堅守如底層相關的關鍵性技術，設計模式方法論這些。

大方向選擇

在熱點趨勢成為主流前提前進場做技術儲備

找到垂直專項領域，做深打透