面向萬物智聯(lián)的應用框架的思考和探索（上）

作者：yuzhiqiang

應用框架，是操作系統(tǒng)連接開發(fā)者生態(tài)，實現(xiàn)用戶體驗的關(guān)鍵基礎設施。其中，開發(fā)效率和運行體驗是永恒的訴求，業(yè)界也在持續(xù)不斷的發(fā)展和演進。

本文重點圍繞移動應用框架，梳理其關(guān)鍵發(fā)展脈絡，并分析其背后的技術(shù)演進思路以及目前的局限；同時，進一步結(jié)合萬物智聯(lián)的新場景和新生態(tài)，圍繞相應的應用框架的設計和演進，分享個人在這個領域的思考，實踐，以及下一步探索。

“凡是過往，皆為序章”-威廉·莎士比亞

1、應用框架概覽

1.1應用，以及應用框架的基本組成

應用是用戶使用操作系統(tǒng)/設備的入口，應用框架則是應用開發(fā)和運行的基礎設施。用戶通過各種各樣的應用來和操作系統(tǒng)/設備交互，來滿足相應的需求。以移動平臺為例，一個典型的應用以及相對應的應用框架的基礎組成大致如下所示：

Figure1典型的應用結(jié)構(gòu)以及相應的系統(tǒng)運行環(huán)境

一個典型的應用結(jié)構(gòu)主要包括以下幾個部分:

1）用戶界面以及相應的業(yè)務處理邏輯。這里主要包括構(gòu)建用戶界面所需的UI（User Interface）組件，布局，動效，事件交互響應處理，所需的資源（圖片/字體等），以及結(jié)合UI呈現(xiàn)的業(yè)務邏輯處理等。從運行時的維度來看，它主要對應了系統(tǒng)運行環(huán)境中的UI框架（含語言運行時），以及部分的系統(tǒng)能力API (Application Programming Interface)；

2）共享庫。這里主要包括開發(fā)者封裝好的SDK（Software Development Kit），以及使用的三方庫等。從運行時維度來看，它主要對應了系統(tǒng)能力API以及語言運行時，如果共享庫涉及UI的話，還對應了UI框架；

3）包清單文件。這里主要包括應用包的結(jié)構(gòu)描述，權(quán)限聲明等，它主要對應了系統(tǒng)運行環(huán)境中的包管理，應用生命周期/權(quán)限管理/進程管理等。

其中， UI框架的主要組成如下圖所示：

Figure2UI框架的主要組成

開發(fā)模型：對開發(fā)者提供的開發(fā)范式、UI組件/API能力、編程語言等，重點體現(xiàn)的是開發(fā)效率與難易程度；

運行框架：UI界面渲染及交互的基礎能力框架，將開發(fā)者的程序運行在具體系統(tǒng)平臺上，包括應用整體渲染處理流程，語言邏輯執(zhí)行流程，以及平臺能力擴展機制，重點體現(xiàn)的是應用運行的性能體驗；

平臺適配：承載框架的具體操作系統(tǒng)或平臺的適配層。

一般而言，應用框架中的包管理、生命周期/權(quán)限管理，和具體的操作系統(tǒng)關(guān)聯(lián)較緊，并相對穩(wěn)定；能力API則是操作系統(tǒng)對設備能力的封裝，主要影響應用使用設備的能力。UI框架以及相應的編程語言則是影響用戶體驗（包括開發(fā)和運行體驗）的關(guān)鍵要素，尤其隨著移動平臺的不斷普及以及移動設備的差異，移動平臺上的UI框架（含編程語言）是業(yè)界不斷演進的重點領域。

1.2移動平臺上應用框架的演進

縱觀十年來的發(fā)展，總體而言，移動平臺上應用框架圍繞著原生框架，三方跨平臺框架交織發(fā)展，并結(jié)合相應語言、工具的配套演進。下圖描述了其中的關(guān)鍵框架/語言的演進概覽。

Figure3 移動平臺上關(guān)鍵語言/開發(fā)框架/工具演進概覽

圖中有幾個關(guān)鍵節(jié)點：

1） 2013年，F(xiàn)acebook發(fā)布的React.js第一次綜合的將數(shù)據(jù)綁定，虛擬DOM（Document Object Model）等機制引入前端開發(fā)框架設計中。開發(fā)者只需聲明好相應的數(shù)據(jù)和UI的綁定，之后由框架來跟蹤數(shù)據(jù)的變化，并通過虛擬DOM樹的對比找出變化點，從而實現(xiàn)界面的自動更新，而無需開發(fā)者手動基于DOM 編程。

2）2018年，Google發(fā)布的Flutter則是個重要的分界點。Flutter融合了Dart語言，是第一個深度融合了語言的較為完整的聲明式開發(fā)框架，實現(xiàn)了完全通過數(shù)據(jù)驅(qū)動的UI變更。另外，F(xiàn)lutter通過基于Skia的自繪制引擎實現(xiàn)了高性能的跨平臺的平臺一致性的渲染能力，并提供了Hot Reload機制提升開發(fā)測試體驗。不過，F(xiàn)lutter的整體設計哲學偏向底層的靈活性–主要通過底層的細粒度的能力供開發(fā)者自由組合，另外，Google對Dart語言的簡潔度的改進較少，整體上開發(fā)的簡潔度以及對用戶的友好度相對不足。

3）2019年，Apple SwiftUI的推出，意味著主流OS的原生應用框架開始逐步往聲明式開發(fā)方式遷移。SwiftUI推動了Swift語言特性擴展實現(xiàn)了更加簡潔自然的UI描述，并通過XCode開發(fā)工具的所見即所得的高效預覽能力進一步提升開發(fā)效率。同時，SwiftUI也是真正意義上開始通過一套框架，逐步統(tǒng)一Apple生態(tài)中的不同的設備/OS上的應用開發(fā)。

另外，2019年Google將更簡潔的Kotlin語言升級為Android首選的編程語言，并在2021年推出基于Kotlin的UI框架Jetpack Compose, 同時結(jié)合開發(fā)工具Android Studio逐步往多設備以及跨平臺演進。

總體而言，移動端應用框架的演進包含以下幾個關(guān)鍵特征：

1）從命令式UI開發(fā)逐步演進到聲明式UI開發(fā)

2）UI和編程語言的融合從相對松散演進到逐步緊密

3）開發(fā)范圍從單設備演進到多設備，從單平臺演進到多平臺

接下來的章節(jié)會分別圍繞跨平臺框架，以及原生應用框架逐步展開，梳理其具體的演進脈絡。

1.2.1跨平臺框架

由于W3C（ World Wide Web Consortium）標準的普及以及Web天然的跨平臺能力， 跨平臺框架主要是基于Web或Web的衍生技術(shù)。

最早試圖補齊Web跨平臺能力是一家叫做PhoneGap的公司，后面被Adobe收購，2012年以Cordova的項目名開源發(fā)布。當時的W3C標準更多涵蓋的是頁面渲染，而設備相關(guān)能力的標準非常缺失，PhoneGap的目標則是圍繞著“Phone”補齊這方面能力“Gap”–它定義了一套移動平臺上常用的設備能力的JS API，并基于JS引擎設計了一套擴展方式來實現(xiàn)不同平臺上的API，同時結(jié)合系統(tǒng)的Webview，配套相關(guān)系統(tǒng)整合以及打包工具，部署成相應平臺上的應用格式在目標操作系統(tǒng)平臺上運行。PhoneGap一定程度上促進了Web在移動設備上的發(fā)展，但是它沒有解決Web引擎本身的體驗問題。當時的Web引擎(系統(tǒng)自帶的Webview），尤其是Android平臺上，能力較弱，并缺失硬件加速，稍微復雜的應用體驗較差。針對這些問題，2014年 Intel開源技術(shù)中心推出了Crosswalk項目，在Chromium內(nèi)核基礎上，針對移動平臺上Web應用，做了進一步解耦和性能優(yōu)化（包括硬件加速，包體積優(yōu)化，以及針對游戲?qū)ｉT設計一套渲染路徑等），并結(jié)合了Cordova補齊相關(guān)API能力，構(gòu)建了可獨立打包演進的Web引擎，性能體驗得到了較大的提升。而且，通過獨立打包，也解決了因為Android系統(tǒng)的碎片化，Webview的版本不一，從而引起的應用體驗（包括渲染能力和性能）不一致的問題。

Crosswalk發(fā)布一年左右就吸引了近千款應用基于Crosswalk構(gòu)建，其中有數(shù)款應用都達到了超過百萬級的下載量。不過后續(xù)由于Intel在移動平臺上的戰(zhàn)略調(diào)整，沒有進一步演進。但這塊的關(guān)鍵思路，后續(xù)或多或少在業(yè)界看到了相關(guān)的影子，比如Google后續(xù)推出的可獨立升級的ChromeWebview，以及國內(nèi)各互聯(lián)網(wǎng)公司各自構(gòu)建的WebView(騰訊的X5內(nèi)核，阿里巴巴的UC內(nèi)核等)。

Cordova+Crosswalk，一定程度上提升了基于Web的跨平臺框架所需的API能力以及渲染性能，不過還有幾個方面，還需要持續(xù)提升：

Ⅰ、開發(fā)范式/前端框架

標準的Web還是一種“半聲明式”的開發(fā)方式，即通過HTML（Hyper Text Markup Langua-ge）, CSS（Cascading Style Sheets）來描述整體頁面結(jié)構(gòu)和樣式，但當要改變其中的界面元素時，開發(fā)者需要基于W3C DOM API，通過具體編程，來實現(xiàn)其中相關(guān)節(jié)點的定位以及增刪改。當所面對的界面交互越復雜，所關(guān)聯(lián)的數(shù)據(jù)越多，開發(fā)者負擔就越重，也越容易出錯。

2013年Facebook發(fā)布的React.js，引入了數(shù)據(jù)和UI自動綁定，以及組件化機制，將聲明式的能力較好的融合到前端框架中。這是開發(fā)理念的一次比較大的進步。這樣方式下，開發(fā)者無需去手動更改UI的結(jié)構(gòu)，只需要描述好UI結(jié)構(gòu)本身，以及數(shù)據(jù)和UI的綁定關(guān)系，框架層會自動跟蹤數(shù)據(jù)的變化并更新相應的UI，這樣進一步提升了UI框架開發(fā)效率。后續(xù)個人開發(fā)者尤雨溪推出的Vue.js框架本質(zhì)上也是采用了類似的思路，只不過在表達方式以及具體實現(xiàn)上有所不同。另外，通過前端框架層提供的組件能力，本質(zhì)上是對W3C HTML/CSS標準的進行了進一步封裝，提供了更加高層的能力，這樣有利于聚焦于相對常用的W3C標準能力，同時通過類似Virtual DOM的機制，對底層的Web引擎做了進一步的解耦，從而為后續(xù)的進一步演進建立了一定的基礎。

Ⅱ、性能體驗

由于W3C標準本身龐雜的歷史積累和復雜性，相對應的Web引擎復雜度也非常高。復雜的渲染管線，千萬量級的代碼，百兆級的二進制大小，以及大幾十兆甚至百兆級的基礎內(nèi)存占用，讓基于Web引擎的應用在整體性能體驗，資源占用等相關(guān)方面，尤其在移動平臺上，和原生應用都有較大的差距，并難以較好解決。

2015年Facebook在React.js基礎上推出的RN(React Native)，是Web+Native的一個典型代表。RN的基本思路是開發(fā)范式上基于React.js，而具體渲染路徑上，則完全繞過Web引擎，直接橋接到了操作系統(tǒng)原生的UI框架。2016年阿里巴巴推出的Weex也是采用了和RN類似的思路。

另外，針對RN的關(guān)鍵架構(gòu)，F(xiàn)acebook持續(xù)做了不少演進：

1）布局引擎（Yoga）。2016年推出。通過實現(xiàn)CSS子集的模式實現(xiàn)高效的一致的跨平臺布局體驗；

2）JS引擎（Hermes）。2019年推出。針對移動平臺上體驗問題做相應改進，比如通過引入一定的AOT（Ahead Of Time）機制，主要是中間碼預編譯，來提升啟動速度；

3）高效交互/按需加載等新架構(gòu)。2022 年推出。支持高效的跨語言交互、數(shù)據(jù)共享，組件按需加載等相關(guān)機制。

通過這些相關(guān)的改進， RN實現(xiàn)了一定的平衡，基于Web的開發(fā)范式實現(xiàn)了較好的性能體驗。不過，由于原生UI框架本身的差異，RN難以達成較好的跨平臺一致性；另外由于需要額外一層Web到Native的橋接轉(zhuǎn)換，和原生相比，RN在性能體驗上天然就有一定差距，難以跨越。

Google在2018年推出的Flutter，則是借鑒了React的思想，走了另外一條較為創(chuàng)新的路。主要特征如下：

1）基于Dart語言的全新聲明式范式設計，一切皆為Widget，可靈活組合，并通過數(shù)據(jù)驅(qū)動UI渲染

2）基于底層畫布的高效自繪制能力

3）Dart運行時優(yōu)化，比如高效的小對象分配釋放能力，AOT機制等

再配合相對完整的跨平臺能力，以及相應的工具鏈，F(xiàn)lutter具備了較好的綜合競爭力。和類RN的方案相比，F(xiàn)lutter在以下幾個方面具備一定優(yōu)勢：

1）跨平臺一致性。通過自繪制機制，具備更好的跨平臺一致性的高效的渲染能力。

2）語言執(zhí)行性能。通過強類型語言Dart的引入以及相應的運行時優(yōu)化（AOT等），具備更好的語言執(zhí)行性能，理論上可對標iOS/Android原生語言。

不過，F(xiàn)lutter也有自身的不足：

1）語言生態(tài)。Dart語言生態(tài)和JS相比，有比較大的差距。而且生態(tài)培育過程一般都比較漫長。

2）動態(tài)化能力。Flutter尚不具備可對標JS相關(guān)框架的動態(tài)化部署機制，實現(xiàn)應用界面/業(yè)務的動態(tài)刷新，而這塊又是大多數(shù)移動應用的強訴求。當然，這里有技術(shù)的因素，也有非技術(shù)的因素綜合引起的。

另外一個層面，F(xiàn)lutter聲明式UI的設計原則上更側(cè)重靈活組合，暴露了較多的細粒度底層的機制（包括各種細粒度的Widget, 以及需進一步區(qū)分Widget的有狀態(tài)和無狀態(tài)等等），而在整體應用開發(fā)的簡潔自然度方面，則考慮的相對較少。

受到Flutter的啟發(fā)，業(yè)界又衍生出了一些新的方案。比如橋接標準的Web前端框架到Flutter，其目的是復用Web的生態(tài)優(yōu)勢，以及Flutter的高性能跨平臺渲染能力。這塊的典型代表是阿里巴巴2021年開源的Kraken，以及2022年進一步在此基礎上演進的KUN。這種方案有一定程度的優(yōu)勢，不過由于它本質(zhì)上還是橋接轉(zhuǎn)換，另外引入了兩種虛擬機（JS和Dart），架構(gòu)上就決定了這種方案在性能和內(nèi)存體驗存在難以解決的缺陷。還有JS前端框架+ C/C++自繪制的方案，比如Weex2.0，它在一定程度上較好綜合了JS層的生態(tài)和底層自繪制的優(yōu)勢，不過在語言運行時，開發(fā)的便捷度等方面，還缺少本質(zhì)的改進。

總體而言，基于Web或通過Web衍生出來的跨平臺框架，業(yè)界一直在持續(xù)的演進，包括Web API擴展，統(tǒng)一的持續(xù)優(yōu)化的Web引擎，聲明式前端框架，Web+Native的融合，自繪制機制，語言和框架深度融合的架構(gòu)等等。但這些跨平臺框架，離真正意義上的極簡開發(fā)，極致性能，并可對標原生應用體驗的設計方面，還缺少系統(tǒng)性的革新和跨越。

1.2.2原生應用框架

1.2.2.1 iOS平臺

iOS的原生應用框架是Cocoa Touch，其中的UI框架和語言最早分別是UIKit和OC(Objective-C)，提供了傳統(tǒng)的命令式（imperative）編程方式。2014年Apple推出了Swift語言，在簡潔性，安全性，性能等方面都有進一步的提升。2019年，在Swift語言發(fā)布了5年之后，Apple推出了新一代的UI框架– SwiftUI，在開發(fā)理念上做了一次全面升級：從命令式編程演進到了簡潔自然的聲明式（declarative）編程，并通過一套UI框架可開發(fā)Apple生態(tài)中的不同OS上的應用（iOS/iPadOS/watchOS/macOS等）。以下是幾個比較重要的演進點：

a.全面采用聲明式來描述UI，并且后續(xù)的UI變更都是通過數(shù)據(jù)驅(qū)動來完成。

具體而言，Apple重新定義了一整套開發(fā)范式，涵蓋了UI的關(guān)鍵組成，UI和數(shù)據(jù)的關(guān)聯(lián)等信息。整個UI就是一段描述，本質(zhì)上就是描述界面的一個值，而不是任何實例；另外UI變化通過單一數(shù)據(jù)源來驅(qū)動（Apple稱之為“Single Source of Truth”），而不是像之前命令式編程那樣，開發(fā)者可以任意獲取某個實例，定位到某個節(jié)點來進行更改。這跟傳統(tǒng)的開發(fā)方式，有本質(zhì)的不同。

b.簡潔自然的開發(fā)范式。盡管在SwiftUI之前也有各種聲明式編程框架，但SwiftUI在簡潔性以及類自然語言的易理解性實現(xiàn)了極大的提升。具體而言，Apple通過語言和框架的深度結(jié)合，達成了簡潔自然的開發(fā)體驗。Swift的一些語言特性基本就是為SwiftUI服務，比如

1）Property Delegates（屬性代理）

屬性代理本質(zhì)上一種語法糖機制，當訪問指定的數(shù)據(jù)時，包括Get或Set，可以附加插入額外的處理邏輯。這個機制用來實現(xiàn)@State這類的裝飾器，實現(xiàn)數(shù)據(jù)和UI之間的自動綁定，簡化應用開發(fā)邏輯。

2）Trailing closure（尾隨閉包）

尾隨閉包主要用來增強可讀性。當一個很長的閉包表達式作為最后一個參數(shù)傳遞給函數(shù)時，可以把它放在在函數(shù)括號之后。函數(shù)支持將其作為最后一個參數(shù)來調(diào)用。

3）Function Builders（函數(shù)構(gòu)造器）

函數(shù)構(gòu)造器也用來增強可讀性，它可以用語句塊作為接受參數(shù)列表，每行代碼返回一個參數(shù)。

還有其他一些語法比如鏈式調(diào)用等等，這些共同組成了簡潔自然的開發(fā)范式。

另外，SwiftUI中自定義組件的內(nèi)容，其實是通過Function Builders返回的遵守View協(xié)議的類型組成，這就意味著框架運行時有機會結(jié)合編譯時的UI類型信息做相應優(yōu)化來實現(xiàn)視圖變化的快速更新。

c.配套工具支持。在工具層面，除了傳統(tǒng)的調(diào)試調(diào)測等能力，Apple的Xcode圍繞SwiftUI預覽做了比較重要的增強，簡要說明如下：

1）實時雙向預覽。UI代碼刷新可實時看到相應的界面效果，同時可實現(xiàn)代碼-界面的雙向預覽–點擊代碼可看到的相應的UI界面，選擇UI界面也可同步顯示相應的代碼。另外預覽可以指定到組件級–通過加@Preview標簽來指定相應組件進行預覽

2）自定義預覽。預覽時可支持參數(shù)配置來定義預覽的設備型號，暗黑模式，語言地區(qū)等上下文，并可以設置頁面所依賴的入?yún)⒌取?/p>

3）預覽時動態(tài)交互，并可支持在預覽器上調(diào)測。預覽時可以實現(xiàn)常用的動態(tài)交互，比如手勢、鍵盤等輸入，音量、Home鍵、電源鍵等按鍵操作，以及網(wǎng)絡、文件、多媒體能力支持等

這些預覽相關(guān)的功能極大提升了應用的開發(fā)效率。本質(zhì)上，高效的效果一致的預覽是需要SwiftUI以及相應能力能夠直接運行在PC（Personal Computer）平臺上，才能達成較好的效果。

另外，從2022年SwiftUI 4.0的關(guān)鍵特性來看，Apple不斷增強高級組件，以及自定義等相關(guān)能力，持續(xù)提升開發(fā)效率。比如更多的高級組件（各類圖表，分享組件等），布局類型以及自定義布局能力增強（添加Grid網(wǎng)格布局，另外增強了自定義布局的能力，以及布局變化相關(guān)的動畫）等等。

1.2.2.2Android平臺

Android的原生應用框架（Application Framework）主要包括應用管理，View 系統(tǒng)，后臺服務（Service），內(nèi)容提供者(Content Provider)，廣播接受機制(Broadcast Receiver)等。其中UI框架和語言最早分別是Android View系統(tǒng)以及Java，主要也是采用了命令式的開發(fā)模式（其中界面的初始聲明可以通過XML(eXtensible Markup Language)方式來定義，后續(xù)的操作則都是通過相應的命令式API來完成）。2016年JetBrains公司正式發(fā)布Kotlin 1.0版本, 它是一種靜態(tài)類型語言，提供了更加簡潔，安全的語法特性（比如說解決Java的語法冗長以及空指針等問題）。同時，Kotlin在字節(jié)碼級別和Java兼容。隨著Kotlin的不斷完善，再加上Java語言的版權(quán)問題等背后的原因，很快， 2019年Google宣布Kotlin為Android移動開發(fā)的首選語言。2021年，Google發(fā)布了基于Kotlin的聲明式UI框架– Jetpack Compose 1.0版本。本質(zhì)上，Jetpack Compose和SwiftUI類似，都是聲明式編程，都是單一可信數(shù)據(jù)源驅(qū)動UI變更。不過，也有幾點不同：

1）Jetpack Compose中的界面表示為一切皆為可組合的函數(shù)。這些函數(shù)通常建議設計為無附帶效應（即不會發(fā)生在可組合函數(shù)作用域之外的應用狀態(tài)的變化）。從運行時維度，這些無附帶效應的組合函數(shù)可并行執(zhí)行。

2） Jetpack Compose整體開源，架構(gòu)上則是提供了多層次的API，從底往上，提供了運行時， 界面，基礎，Material設計系統(tǒng)的實現(xiàn)，每一層都是基于較低層的公共API構(gòu)建。

3）跨平臺能力。在Google發(fā)布 Jebpack Compose 1.0版本后，Jetbrains公司緊接著推出Compose Multiplatform項目，將Compose延伸到桌面平臺(Windows, macOS, Linux)，同時，配合Kotlin Multiplatform項目中的跨平臺類庫（網(wǎng)絡、存儲等），進一步簡化基于Jetpack Compose的跨平臺應用的開發(fā)。

在開發(fā)工具層面，Android Studio支持Jetpack Compose實時預覽等特性，但目前成熟度相對弱一些，截至2022年，還未支持多設備預覽，代碼界面的雙向預覽，預覽時調(diào)試，以及基礎系統(tǒng)能力（比如網(wǎng)絡/存儲）的模擬等。

Google在2022/10/24給出的Jetpack Compose路線圖中，Jetpack Compose接下來重點會圍繞性能體驗，高級組件，開發(fā)工具改進（包括預覽和實時編輯），多平臺支持（WearOS，大屏設備，主屏幕Widget）等方面展開。

總體而言，不管是原生框架，還是三方框架，除了性能體驗，關(guān)鍵演進方向主要包括以下幾點：

1）開發(fā)方式從命令式轉(zhuǎn)為聲明式；

2）語言和框架和工具結(jié)合更加緊密；

3）逐步增加多設備以及跨平臺支持。

審核編輯：湯梓紅