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

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

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

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

“預見未來的最好方式，就是創造未來”– 亞伯拉罕 · 林肯

1、面向萬物智聯的應用框架的架構設計思考

1.1 萬物智聯下的新場景，新需求

隨著越來越多裝置的智慧化，新的場景以及新的需求也逐步呈現，主要包括：

a.更多的不同形態的裝置支援。包括各類螢幕（不同解析度，尺寸，縱橫比，摺疊屏的摺疊/展開切換，“劉海屏”等），以及各種互動模式（觸控、鍵盤、滑鼠、遙控器，錶冠，語音，3D手勢等）。

b.更多的不同能力的裝置支援。包括各種晶片規格，各種RAM（Random Access Memo-ry）/ROM（Read Only Memory）規格（百KB級別，MB級別到GB級別），各種系統能力規格等。

c.裝置之間的互動。包括應用在裝置之間流轉，協同等。

除此之外，對應用開發者而言，還有兩類非常重要的需求：

Ⅰ、跨OS（Operating System）平臺能力

由於事實上多個主流OS的存在，如何有效的提升可同時支援不同OS（比如iOS和Android等）的應用開發效率是個重要的需求。目前開發者主要還是依賴三方跨平臺框架。有些應用開發者在某些場景下，因為原生框架所帶來的效果體驗不一致帶來較大的適配成本，甚至在一些關鍵模組不使用原生應用框架的能力，而是重新設計一套具備跨平臺一致性的方案。

Ⅱ、動態化內容部署能力

如何將業務的內容在不違反相關規則的情況下迅速部署到客戶端，以便業務快速觸達客戶，也是大多數應用比較通用的需求。目前主要是應用開發者透過設計相關框架能力來支撐，不用應用採用方案各不相同。

這些對應用框架的設計都提出了新的要求，包括自適應能力、模組化能力，分散式能力，跨平臺能力，動態內容更新能力等。當然，有些場景需要OS底層本身也要做相應的演進，比如可部署到更輕量的裝置，分散式基礎設施構建等。

1.2 目前應用框架的侷限：

縱觀現有的各類方案，在新興的場景和應用需求下，逐漸呈現出一定的侷限性。

1.2.1 原生應用框架

先說Apple。以Apple的iOS上的應用框架為例，它在面向開發者的簡潔高效，面向消費者的自然流暢，語言、框架、工具的以及軟硬體的緊密結合，生態的管控等方面都是第一|流的。Apple的生態是自閉環的，也是有明確邊界的，這樣的策略在Apple生態是一家獨大時問題不大，但當事實上是多個主流OS生態並存，尤其隨著萬物智聯的生態進一步擴充套件時，Apple的方式呈現出了一定的侷限性：

1）Apple的應用框架僅限於自身OS系列，比如SwiftUI只會關注iOS, iPadOS,macOS等，並沒有考慮如何在其它OS上實現一定的複用能力。

另外，對應用常見的應用內容動態更新的需求，Apple則是嚴格的限制，並沒有在框架層面考慮怎麼在一個合適範圍內提供一定的支援。

2）Apple的應用框架對系統裝置有較高的要求，無法支撐輕量化的智慧裝置（比如M級記憶體的裝置等）。當然，這個也和Apple目前自身的定位相關。

再說Google。以Android為例，目前主推的Kotlin和以及Jetpack Compose基本是Google為了逐步擺脫Java，並對標Apple的Swift以及SwiftUI而研發的產物。Google的整體策略相對開放，在架構上， Jetpack Compose做了分層解耦的設計，提供不同層次的API的開發能力供開發者靈活接入。另外，在跨OS平臺維度，Jetpack Compose也做了一定的考慮，除了Android之外，透過JetBrains的推進， 也可支援PC平臺（Windows/macOS）等。不過，目前Jetpack Compose在成熟度，以及多裝置以及相關配套工具層面能力和Apple的SwfitUI相比還有不少差距。另外，前面所說的輕量化裝置的支援，以及動態化內容更新的能力，也未涉及。

1.2.2 三方跨平臺應用框架

三方跨平臺框架也在不斷演進。下圖總結了典型的三方框架的關鍵特徵：

Figure 1 對比原生框架，典型三方跨平臺框架的關鍵特徵

另外，從語言角度，儘管JS/TS具備較強的生態能力，業界也在不斷的演進相應的引擎、工具鏈，但從對標原生語言的效能體驗維度，還是有關鍵的不足，如下圖所示：

Figure 2 對比原生語言， JS/TS的現狀以及不足

上圖簡要描述了JS/TS從編譯到執行的大致過程。儘管業界在JS引擎方面持續在做最佳化提升，比如注重高效能JIT能力的Google的V8以及Apple的JavaScriptCore， 注重輕量化、高效解析能力的Facebook的Hermes, 個人開發者Fabrice Bellard的QuickJS等，但如果要對標原生語言的執行體驗，還有幾個重點的維度有待進一步突破：

1）結合型別資訊的最佳化，和更精細化型別的引入；

2）結合PGO（Profiling Guide Optimiza-tion）的AOT能力;

3）更高效的並行化機制等。

1.3 如何設計應用框架，實現系統性跨越

如上所述，現有的原生應用框架以及三方跨平臺框架都有自身定位/設計上的侷限。那在萬物智聯的場景下，應該如何設計應用框架，才能較好的滿足相關要求，並實現系統性跨越？

讓我們先回歸本源，審視一下應用框架要解決的核心問題。按遞進關係，個人總結了三個維度的關鍵需求，如下所示：

Figure 3 應用框架要解決的核心問題

對同一OS平臺而言，應用框架要解決的核心問題主要有三類：1.開發效率；2.效能體驗；3.跨裝置能力。

而當事實上有多個主流OS平臺長期並存時，跨平臺的需求，或者更準確的說，如何進一步降低主流平臺上應用適配的成本，就變的非常重要。它包括不同平臺上的開發效率，效能體驗，以及SDK包大小等要素。

除此之外，隨著業務演進，動態化內容更新機制也演變為了非常關鍵的需求。

要構建可對標主流作業系統(e.g. iOS,Android)原生應用框架，並能夠在面向萬物智聯的場景實現進一步跨越的新一代應用框架，個人認為，至少需圍繞以下幾個方面進行系統性的佈局和設計：語言生態以及效能體驗；宣告式開發框架能力；跨裝置自適應以及彈性部署能力；跨平臺能力。

1.2.3.1 語言生態以及效能體驗

iOS平臺的Swift以及Android平臺的Kotlin已經各自形成了相應的平臺的主導語言，並有相應的公司來主導。對於新的OS平臺而言，創造全新的語言是一種方式，不過語言以及相關生態的發展需要比較長的週期（從正式釋出到一定規模的應用一般至少需要5年以上的時間）。還有另外一種方式，則是選取現有的相對中立的並有廣泛應用基礎的語言，並在此基礎上演進。JS/TS即是這樣的語言，它應用生態廣泛，也有相應的業界標準-ECMAScript來持續演進。

以下圖片來源於RedMonk官網：

它顯示了2012-2022這十年來的程式語言的熱度排名情況（綜合考慮Github熱度以及StackOverflow熱度）。如下所示，JS/TS語言持續領先。

 Figure 4 程式語言排行榜 - RedMonk

如之前分析，要讓JS/TS具備可對標主流平臺原生語言的效能以及開發體驗，需要在語言、編譯器以及執行時實現關鍵的跨越：

1）基於型別資訊的編譯以及執行時最佳化

2）AOT能力，並可根據關鍵執行路徑資訊的反饋實現進一步最佳化

3）高效的並行化機制

4）宣告式語法擴充套件，實現簡潔自然的開發體驗

以這些為基礎，配合相應的最佳化的語言標準庫，更細粒度的型別擴充套件，比如64位/128位等數值型別進一步結合硬體實現SIMD（Single Instruction Multiple Data）的加速等，就具備了能達成高效的語言執行效能的關鍵能力。另外，在高效開發方面，除了語言層面的宣告式語法擴充套件，還可以進一步針對分散式場景對資料型別做相應擴充套件，提升跨裝置場景下應用開發體驗。

1.2.3.2 宣告式開發框架

宣告式開發框架的核心就是以簡潔自然的方式來描述UI，並透過資料的變化來驅動UI的自動變更。

從UI描述維度，它的關鍵組成如下（簡潔自然是關鍵需求）：

a. 一套UI描述機制，包括基礎結構語法，基礎佈局/元件/動效/事件處理/生命週期，以及元件化機制實現UI的積木式組合等

b.一套狀態管理描述機制，包括資料和UI的關聯，資料的共享和傳遞機制等

c.一套自定義擴充套件以及定製化機制，包括可自定義佈局/繪製/動效，可對現有元件根據需要做定製/動態擴充套件等

從執行時維度，它的關鍵要素如下（效能體驗是關鍵需求）：

a.高效的UI渲染管線，並可實現元件/屬性按需組合降低記憶體開銷

b.高效的狀態管理/UI更新機制，根據資料變化精準定位重新整理範圍

c.自適應UI能力，以及多型元件能力（同一UI描述在不同裝置可自動實現不同UI效果，自動適配不同的使用者互動模式等）

d.平臺無關的一致性渲染能力

另外，在配套的工具層面，比如IDE，需具備實時預覽能力（包括雙向預覽，多裝置預覽，預覽和除錯融合等）。

1.2.3.3 跨裝置自適應以及彈性部署能力

這裡主要包括針對不同形態的裝置的自適應（包括佈局，控制元件形態等），不同能力的裝置彈性部署（包括裝置的提供API差異，系統所需的資源差異等）。從架構設計而言，則需具備元件解耦，按需載入，以及輕量化等能力。

1.2.3.4 跨平臺

這裡主要包括平臺抽象層設計以及各個主流OS相應的適配實現，相關的工具鏈支援等。這樣就可以基於一套主程式碼，部署到不同的OS平臺上。其中的關鍵要素包括通用的API設計和實現（提升應用程式碼的複用度），元件化機制（降低SDK大小），以及上述提到的平臺一致化渲染能力等。