面向萬物智聯的應用框架的思考和探索（上）

原文： https://mp.weixin.qq.com/s/G6o6xSAWroz0fJK7oShYLA ，點選連結檢視更多技術內容。

應用框架，是作業系統連線開發者生態，實現使用者體驗的關鍵基礎設施。其中，開發效率和執行體驗是永恆的訴求，業界也在持續不斷的發展和演進。

本文重點圍繞移動應用框架，梳理其關鍵發展脈絡，並分析其背後的技術演進思路以及目前的侷限；同時，進一步結合萬物智聯的新場景和新生態，圍繞相應的應用框架的設計和演進，分享個人在這個領域的思考，實踐，以及下一步探索。

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

1、應用框架概覽

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

應用是使用者使用作業系統/裝置的入口，應用框架則是應用開發和執行的基礎設施。使用者透過各種各樣的應用來和作業系統/裝置互動，來滿足相應的需求。以移動平臺為例，一個典型的應用以及相對應的應用框架的基礎組成大致如下所示：

Figure 1 典型的應用結構以及相應的系統執行環境

一個典型的應用結構主要包括以下幾個部分:

1）使用者介面以及相應的業務處理邏輯。這裡主要包括構建使用者介面所需的UI（User Interface）元件，佈局，動效，事件互動響應處理，所需的資源（圖片/字型等），以及結合UI呈現的業務邏輯處理等。從執行時的維度來看，它主要對應了系統執行環境中的UI框架（含語言執行時），以及部分的系統能力API (Application Programming Interface)；

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

3）包清單檔案。這裡主要包括應用包的結構描述，許可權宣告等，它主要對應了系統執行環境中的包管理，應用生命週期/許可權管理/程式管理等。

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

Figure 2 UI框架的主要組成

開發模型：對開發者提供的開發正規化、UI元件/API能力、程式語言等，重點體現的是開發效率與難易程度；

執行框架：UI介面渲染及互動的基礎能力框架，將開發者的程式執行在具體系統平臺上，包括應用整體渲染處理流程，語言邏輯執行流程，以及平臺能力擴充套件機制，重點體現的是應用執行的效能體驗；

平臺適配：承載框架的具體作業系統或平臺的適配層。

一般而言，應用框架中的包管理、生命週期/許可權管理，和具體的作業系統關聯較緊，並相對穩定；能力API則是作業系統對裝置能力的封裝，主要影響應用使用裝置的能力。UI框架以及相應的程式語言則是影響使用者體驗（包括開發和執行體驗）的關鍵要素，尤其隨著移動平臺的不斷普及以及移動裝置的差異，移動平臺上的UI框架（含程式語言）是業界不斷演進的重點領域。

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

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

Figure 3 移動平臺上關鍵語言/開發框架/工具演進概覽

圖中有幾個關鍵節點：

1） 2013年，Facebook釋出的React.js第一次綜合的將資料繫結，虛擬DOM（Document Object Model）等機制引入前端開發框架設計中。開發者只需宣告好相應的資料和UI的繫結，之後由框架來跟蹤資料的變化，並透過虛擬DOM樹的對比找出變化點，從而實現介面的自動更新，而無需開發者手動基於DOM 程式設計。

2）2018年，Google釋出的Flutter則是個重要的分界點。Flutter融合了Dart語言，是第一個深度融合了語言的較為完整的宣告式開發框架，實現了完全透過資料驅動的UI變更。另外，Flutter透過基於Skia的自繪製引擎實現了高效能的跨平臺的平臺一致性的渲染能力，並提供了Hot Reload機制提升開發測試體驗。不過，Flutter的整體設計哲學偏向底層的靈活性 – 主要透過底層的細粒度的能力供開發者自由組合，另外，Google對Dart語言的簡潔度的改進較少，整體上開發的簡潔度以及對使用者的友好度相對不足。

3）2019年，Apple SwiftUI的推出，意味著主流OS的原生應用框架開始逐步往宣告式開發方式遷移。SwiftUI推動了Swift語言特性擴充套件實現了更加簡潔自然的UI描述，並透過XCode開發工具的所見即所得的高效預覽能力進一步提升開發效率。同時，SwiftUI也是真正意義上開始透過一套框架，逐步統一Apple生態中的不同的裝置/OS上的應用開發。

另外，2019年Google將更簡潔的Kotlin語言升級為Android首|選的程式語言，並在2021年推出基於Kotlin的UI框架Jetpack Compose, 同時結合開發工具Android Studio逐步往多裝置以及跨平臺演進。

總體而言，移動端應用框架的演進包含以下幾個關鍵特徵：

1）從命令式UI開發逐步演進到宣告式UI開發

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

3）開發範圍從單裝置演進到多裝置，從單平臺演進到多平臺

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

1.2.1 跨平臺框架

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

最早試圖補齊Web跨平臺能力是一家叫做PhoneGap的公司，後面被Adobe收購，2012年以Cordova的專案名開源釋出。當時的W3C標準更多涵蓋的是頁面渲染，而裝置相關能力的標準非常缺失，PhoneGap的目標則是圍繞著“Phone”補齊這方面能力“Gap” – 它定義了一套移動平臺上常用的裝置能力的JS API，並基於JS引擎設計了一套擴充套件方式來實現不同平臺上的API，同時結合系統的Webview，配套相關係統整合以及打包工具，部署成相應平臺上的應用格式在目標作業系統平臺上執行。PhoneGap一定程度上促進了Web在移動裝置上的發展，但是它沒有解決Web引擎本身的體驗問題。當時的Web引擎(系統自帶的Webview），尤其是Android平臺上，能力較弱，並缺失硬體加速，稍微複雜的應用體驗較差。針對這些問題，2014年 Intel開源技術中心推出了Crosswalk專案，在Chromium核心基礎上，針對移動平臺上Web應用，做了進一步解耦和效能最佳化（包括硬體加速，包體積最佳化，以及針對遊戲專門設計一套渲染路徑等），並結合了Cordova補齊相關API能力，構建了可獨立打包演進的Web引擎，效能體驗得到了較大的提升。而且，透過獨立打包，也解決了因為Android系統的碎片化，Webview的版本不一，從而引起的應用體驗（包括渲染能力和效能）不一致的問題。

Crosswalk釋出一年左右就吸引了近千款應用基於Crosswalk構建，其中有數款應用都達到了超過百萬級的下載量。不過後續由於Intel在移動平臺上的戰略調整，沒有進一步演進。但這塊的關鍵思路，後續或多或少在業界看到了相關的影子，比如Google後續推出的可獨立升級的ChromeWebview，以及國內各網際網路公司各自構建的WebView(騰訊的X5核心，阿里巴巴的UC核心等)。

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

Ⅰ、開發正規化/前端框架

標準的Web還是一種“半宣告式”的開發方式，即透過HTML（Hyper Text Markup Langua-ge）, CSS（Cascading Style Sheets）來描述整體頁面結構和樣式，但當要改變其中的介面元素時，開發者需要基於W3C DOM API，透過具體程式設計，來實現其中相關節點的定位以及增刪改。當所面對的介面互動越複雜，所關聯的資料越多，開發者負擔就越重，也越容易出錯。

2013年Facebook釋出的React.js，引入了資料和UI自動繫結，以及元件化機制，將宣告式的能力較好的融合到前端框架中。這是開發理念的一次比較大的進步。這樣方式下，開發者無需去手動更改UI的結構，只需要描述好UI結構本身，以及資料和UI的繫結關係，框架層會自動跟蹤資料的變化並更新相應的UI，這樣進一步提升了UI框架開發效率。後續個人開發者尤雨溪推出的Vue.js框架本質上也是採用了類似的思路，只不過在表達方式以及具體實現上有所不同。另外，透過前端框架層提供的元件能力，本質上是對W3C HTML/CSS標準的進行了進一步封裝，提供了更加高層的能力，這樣有利於聚焦於相對常用的W3C標準能力，同時透過類似Virtual DOM的機制，對底層的Web引擎做了進一步的解耦，從而為後續的進一步演進建立了一定的基礎。

Ⅱ、效能體驗

由於W3C標準本身龐雜的歷史積累和複雜性，相對應的Web引擎複雜度也非常高。複雜的渲染管線，千萬量級的程式碼，百兆級的二進位制大小，以及大幾十兆甚至百兆級的基礎記憶體佔用，讓基於Web引擎的應用在整體效能體驗，資源佔用等相關方面，尤其在移動平臺上，和原生應用都有較大的差距，並難以較好解決。

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

另外，針對RN的關鍵架構，Facebook持續做了不少演進：

1）佈局引擎（Yoga）。2016年推出。透過實現CSS子集的模式實現高效的一致的跨平臺佈局體驗；

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

3）高效互動/按需載入等新架構。2022 年推出。支援高效的跨語言互動、資料共享，元件按需載入等相關機制。

透過這些相關的改進， RN實現了一定的平衡，基於Web的開發正規化實現了較好的效能體驗。不過，由於原生UI框架本身的差異，RN難以達成較好的跨平臺一致性；另外由於需要額外一層Web到Native的橋接轉換，和原生相比，RN在效能體驗上天然就有一定差距，難以跨越。  

Google在2018年推出的Flutter，則是借鑑了React的思想，走了另外一條較為創新的路。主要特徵如下：

1）基於Dart語言的全新宣告式正規化設計，一切皆為Widget，可靈活組合，並透過資料驅動UI渲染

2）基於底層畫布的高效自繪製能力

3）Dart執行時最佳化，比如高效的小物件分配釋放能力，AOT機制等

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

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

2）語言執行效能。透過強型別語言Dart的引入以及相應的執行時最佳化（AOT等），具備更好的語言執行效能，理論上可對標iOS/Android原生語言。

不過，Flutter也有自身的不足：

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

2）動態化能力。Flutter尚不具備可對標JS相關框架的動態化部署機制，實現應用介面/業務的動態重新整理，而這塊又是大多數移動應用的強訴求。當然，這裡有技術的因素，也有非技術的因素綜合引起的。

另外一個層面，Flutter宣告式UI的設計原則上更側重靈活組合，暴露了較多的細粒度底層的機制（包括各種細粒度的Widget, 以及需進一步區分Widget的有狀態和無狀態等等），而在整體應用開發的簡潔自然度方面，則考慮的相對較少。

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

總體而言，基於Web或透過Web衍生出來的跨平臺框架，業界一直在持續的演進，包括Web API擴充套件，統一的持續最佳化的Web引擎，宣告式前端框架，Web+Native的融合，自繪製機制，語言和框架深度融合的架構等等。但這些跨平臺框架，離真正意義上的極簡開發，極|致效能，並可對標原生應用體驗的設計方面，還缺少系統性的革新和跨越。

1.2.2 原生應用框架

1.2.2.1 iOS平臺

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

a.全面採用宣告式來描述UI，並且後續的UI變更都是透過資料驅動來完成。

具體而言，Apple重新定義了一整套開發正規化，涵蓋了UI的關鍵組成，UI和資料的關聯等資訊。整個UI就是一段描述，本質上就是描述介面的一個值，而不是任何例項；另外UI變化透過單一資料來源來驅動（Apple稱之為“Single Source of Truth”），而不是像之前指令式程式設計那樣，開發者可以任意獲取某個例項，定位到某個節點來進行更改。這跟傳統的開發方式，有本質的不同。

b.簡潔自然的開發正規化。儘管在SwiftUI之前也有各種宣告式程式設計框架，但SwiftUI在簡潔性以及類自然語言的易理解性實現了極大的提升。具體而言，Apple透過語言和框架的深度結合，達成了簡潔自然的開發體驗。Swift的一些語言特性基本就是為SwiftUI服務，比如

1）Property Delegates（屬性代理）

屬性代理本質上一種語法糖機制，當訪問指定的資料時，包括Get或Set，可以附加插入額外的處理邏輯。這個機制用來實現@State這類的裝飾器，實現資料和UI之間的自動繫結，簡化應用開發邏輯。

2）Trailing closure （尾隨閉包）

尾隨閉包主要用來增強可讀性。當一個很長的閉包表示式作為最後一個引數傳遞給函式時，可以把它放在在函式括號之後。函式支援將其作為最後一個引數來呼叫。

3）Function Builders（函式構造器）

函式構造器也用來增強可讀性，它可以用語句塊作為接受引數列表，每行程式碼返回一個引數。

還有其他一些語法比如鏈式呼叫等等，這些共同組成了簡潔自然的開發正規化。

另外，SwiftUI中自定義元件的內容，其實是透過Function Builders返回的遵守View協議的型別組成，這就意味著框架執行時有機會結合編譯時的UI型別資訊做相應最佳化來實現檢視變化的快速更新。

c.配套工具支援。在工具層面，除了傳統的除錯調測等能力，Apple的Xcode圍繞SwiftUI預覽做了比較重要的增強，簡要說明如下：

1）實時雙向預覽。UI程式碼重新整理可實時看到相應的介面效果，同時可實現程式碼-介面的雙向預覽 – 點選程式碼可看到的相應的UI介面，選擇UI介面也可同步顯示相應的程式碼。另外預覽可以指定到元件級 – 透過加@Preview標籤來指定相應元件進行預覽

2）自定義預覽。預覽時可支援引數配置來定義預覽的裝置型號，暗黑模式，語言地區等上下文，並可以設定頁面所依賴的入參等。

3）預覽時動態互動，並可支援在預覽器上調測。預覽時可以實現常用的動態互動，比如手勢、鍵盤等輸入，音量、Home鍵、電源鍵等按鍵操作，以及網路、檔案、多媒體能力支援等

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

另外，從2022年SwiftUI 4.0的關鍵特性來看，Apple不斷增強高|級元件，以及自定義等相關能力，持續提升開發效率。比如更多的高|級元件（各類圖表，分享元件等），佈局型別以及自定義佈局能力增強（新增Grid網格佈局，另外增強了自定義佈局的能力，以及佈局變化相關的動畫）等等。

1.2.2.2 Android平臺

Android的原生應用框架（Application Framework）主要包括應用管理，View 系統，後臺服務（Service），內容提供者(Content Provider)，廣播接受機制(Broadcast Receiver)等。其中UI框架和語言最早分別是Android View系統以及Java，主要也是採用了命令式的開發模式（其中介面的初始宣告可以透過XML(eXtensible Markup Language)方式來定義，後續的操作則都是透過相應的命令式API來完成）。2016年JetBrains公司正式釋出Kotlin 1.0版本, 它是一種靜態型別語言，提供了更加簡潔，安全的語法特性（比如說解決Java的語法冗長以及空指標等問題）。同時，Kotlin在位元組碼級別和Java相容。隨著Kotlin的不斷完善，再加上Java語言的版權問題等背後的原因，很快， 2019年Google宣佈Kotlin為Android移動開發的首|選語言。2021年，Google釋出了基於Kotlin的宣告式UI框架 – Jetpack Compose 1.0版本。本質上，Jetpack Compose和SwiftUI類似，都是宣告式程式設計，都是單一可信資料來源驅動UI變更。不過，也有幾點不同：

1）Jetpack Compose中的介面表示為一切皆為可組合的函式。這些函式通常建議設計為無附帶效應（即不會發生在可組合函式作用域之外的應用狀態的變化）。從執行時維度，這些無附帶效應的組合函式可並行執行。

2） Jetpack Compose整體開源，架構上則是提供了多層次的API，從底往上，提供了執行時， 介面，基礎，Material設計系統的實現，每一層都是基於較低層的公共API構建。

3）跨平臺能力。在Google釋出 Jebpack Compose 1.0版本後，Jetbrains公司緊接著推出Compose Multiplatform專案，將Compose延伸到桌面平臺(Windows, macOS, Linux)，同時，配合Kotlin Multiplatform專案中的跨平臺類庫（網路、儲存等），進一步簡化基於Jetpack Compose的跨平臺應用的開發。

在開發工具層面，Android Studio支援Jetpack Compose實時預覽等特性，但目前成熟度相對弱一些，截至2022年，還未支援多裝置預覽，程式碼介面的雙向預覽，預覽時除錯，以及基礎系統能力（比如網路/儲存）的模擬等。

Google在2022/10/24給出的Jetpack Compose路線圖中，Jetpack Compose接下來重點會圍繞效能體驗，高|級元件，開發工具改進（包括預覽和實時編輯），多平臺支援（WearOS，大屏裝置，主螢幕Widget）等方面展開。

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

1）開發方式從命令式轉為宣告式；

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

3）逐步增加多裝置以及跨平臺支援。