作者：yuzhiqiang

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

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

“預(yù)見未來的最好方式，就是創(chuàng)造未來”–亞伯拉罕 · 林肯

1、面向萬物智聯(lián)的應(yīng)用框架的架構(gòu)設(shè)計思考

1.1萬物智聯(lián)下的新場景，新需求

隨著越來越多設(shè)備的智能化，新的場景以及新的需求也逐步呈現(xiàn)，主要包括：

a.更多的不同形態(tài)的設(shè)備支持。包括各類屏幕（不同分辨率，尺寸，縱橫比，折疊屏的折疊/展開切換，“劉海屏”等），以及各種交互模式（觸控、鍵盤、鼠標、遙控器，表冠，語音，3D手勢等）。

b.更多的不同能力的設(shè)備支持。包括各種芯片規(guī)格，各種RAM（Random Access Memo-ry）/ROM（Read Only Memory）規(guī)格（百KB級別，MB級別到GB級別），各種系統(tǒng)能力規(guī)格等。

c.設(shè)備之間的交互。包括應(yīng)用在設(shè)備之間流轉(zhuǎn)，協(xié)同等。

除此之外，對應(yīng)用開發(fā)者而言，還有兩類非常重要的需求：

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

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

Ⅱ、動態(tài)化內(nèi)容部署能力

如何將業(yè)務(wù)的內(nèi)容在不違反相關(guān)規(guī)則的情況下迅速部署到客戶端，以便業(yè)務(wù)快速觸達客戶，也是大多數(shù)應(yīng)用比較通用的需求。目前主要是應(yīng)用開發(fā)者通過設(shè)計相關(guān)框架能力來支撐，不用應(yīng)用采用方案各不相同。

這些對應(yīng)用框架的設(shè)計都提出了新的要求，包括自適應(yīng)能力、模塊化能力，分布式能力，跨平臺能力，動態(tài)內(nèi)容更新能力等。當然，有些場景需要OS底層本身也要做相應(yīng)的演進，比如可部署到更輕量的設(shè)備，分布式基礎(chǔ)設(shè)施構(gòu)建等。

1.2 目前應(yīng)用框架的局限：

縱觀現(xiàn)有的各類方案，在新興的場景和應(yīng)用需求下，逐漸呈現(xiàn)出一定的局限性。

1.2.1原生應(yīng)用框架

先說Apple。以Apple的iOS上的應(yīng)用框架為例，它在面向開發(fā)者的簡潔高效，面向消費者的自然流暢，語言、框架、工具的以及軟硬件的緊密結(jié)合，生態(tài)的管控等方面都是第一流的。Apple的生態(tài)是自閉環(huán)的，也是有明確邊界的，這樣的策略在Apple生態(tài)是一家獨大時問題不大，但當事實上是多個主流OS生態(tài)并存，尤其隨著萬物智聯(lián)的生態(tài)進一步擴展時，Apple的方式呈現(xiàn)出了一定的局限性：

1）Apple的應(yīng)用框架僅限于自身OS系列，比如SwiftUI只會關(guān)注iOS, iPadOS,macOS等，并沒有考慮如何在其它OS上實現(xiàn)一定的復用能力。

另外，對應(yīng)用常見的應(yīng)用內(nèi)容動態(tài)更新的需求，Apple則是嚴格的限制，并沒有在框架層面考慮怎么在一個合適范圍內(nèi)提供一定的支持。

2）Apple的應(yīng)用框架對系統(tǒng)設(shè)備有較高的要求，無法支撐輕量化的智能設(shè)備（比如M級內(nèi)存的設(shè)備等）。當然，這個也和Apple目前自身的定位相關(guān)。

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

1.2.2三方跨平臺應(yīng)用框架

三方跨平臺框架也在不斷演進。下圖總結(jié)了典型的三方框架的關(guān)鍵特征：

Figure 1對比原生框架，典型三方跨平臺框架的關(guān)鍵特征

另外，從語言角度，盡管JS/TS具備較強的生態(tài)能力，業(yè)界也在不斷的演進相應(yīng)的引擎、工具鏈，但從對標原生語言的性能體驗維度，還是有關(guān)鍵的不足，如下圖所示：

Figure 2對比原生語言，JS/TS的現(xiàn)狀以及不足

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

1）結(jié)合類型信息的優(yōu)化，和更精細化類型的引入；

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

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

1.3如何設(shè)計應(yīng)用框架，實現(xiàn)系統(tǒng)性跨越

如上所述，現(xiàn)有的原生應(yīng)用框架以及三方跨平臺框架都有自身定位/設(shè)計上的局限。那在萬物智聯(lián)的場景下，應(yīng)該如何設(shè)計應(yīng)用框架，才能較好的滿足相關(guān)要求，并實現(xiàn)系統(tǒng)性跨越？

讓我們先回歸本源，審視一下應(yīng)用框架要解決的核心問題。按遞進關(guān)系，個人總結(jié)了三個維度的關(guān)鍵需求，如下所示：

Figure 3 應(yīng)用框架要解決的核心問題

對同一OS平臺而言，應(yīng)用框架要解決的核心問題主要有三類：1.開發(fā)效率；2.性能體驗；3.跨設(shè)備能力。

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

除此之外，隨著業(yè)務(wù)演進，動態(tài)化內(nèi)容更新機制也演變?yōu)榱朔浅ｊP(guān)鍵的需求。

要構(gòu)建可對標主流操作系統(tǒng)(e.g. iOS,Android)原生應(yīng)用框架，并能夠在面向萬物智聯(lián)的場景實現(xiàn)進一步跨越的新一代應(yīng)用框架，個人認為，至少需圍繞以下幾個方面進行系統(tǒng)性的布局和設(shè)計：語言生態(tài)以及性能體驗；聲明式開發(fā)框架能力；跨設(shè)備自適應(yīng)以及彈性部署能力；跨平臺能力。

1.2.3.1語言生態(tài)以及性能體驗

iOS平臺的Swift以及Android平臺的Kotlin已經(jīng)各自形成了相應(yīng)的平臺的主導語言，并有相應(yīng)的公司來主導。對于新的OS平臺而言，創(chuàng)造全新的語言是一種方式，不過語言以及相關(guān)生態(tài)的發(fā)展需要比較長的周期（從正式發(fā)布到一定規(guī)模的應(yīng)用一般至少需要5年以上的時間）。還有另外一種方式，則是選取現(xiàn)有的相對中立的并有廣泛應(yīng)用基礎(chǔ)的語言，并在此基礎(chǔ)上演進。JS/TS即是這樣的語言，它應(yīng)用生態(tài)廣泛，也有相應(yīng)的業(yè)界標準-ECMAScript來持續(xù)演進。

以下圖片來源于RedMonk官網(wǎng)：

https://redmonk.com/rstephens/2022/03/28/top-20-jan-2022/）

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

Figure 4編程語言排行榜- RedMonk

如之前分析，要讓JS/TS具備可對標主流平臺原生語言的性能以及開發(fā)體驗，需要在語言、編譯器以及運行時實現(xiàn)關(guān)鍵的跨越：

1）基于類型信息的編譯以及運行時優(yōu)化

2）AOT能力，并可根據(jù)關(guān)鍵執(zhí)行路徑信息的反饋實現(xiàn)進一步優(yōu)化

3）高效的并行化機制

4）聲明式語法擴展，實現(xiàn)簡潔自然的開發(fā)體驗

以這些為基礎(chǔ)，配合相應(yīng)的優(yōu)化的語言標準庫，更細粒度的類型擴展，比如64位/128位等數(shù)值類型進一步結(jié)合硬件實現(xiàn)SIMD（Single Instruction Multiple Data）的加速等，就具備了能達成高效的語言執(zhí)行性能的關(guān)鍵能力。另外，在高效開發(fā)方面，除了語言層面的聲明式語法擴展，還可以進一步針對分布式場景對數(shù)據(jù)類型做相應(yīng)擴展，提升跨設(shè)備場景下應(yīng)用開發(fā)體驗。

1.2.3.2聲明式開發(fā)框架

聲明式開發(fā)框架的核心就是以簡潔自然的方式來描述UI，并通過數(shù)據(jù)的變化來驅(qū)動UI的自動變更。

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

a. 一套UI描述機制，包括基礎(chǔ)結(jié)構(gòu)語法，基礎(chǔ)布局/組件/動效/事件處理/生命周期，以及組件化機制實現(xiàn)UI的積木式組合等

b.一套狀態(tài)管理描述機制，包括數(shù)據(jù)和UI的關(guān)聯(lián)，數(shù)據(jù)的共享和傳遞機制等

c.一套自定義擴展以及定制化機制，包括可自定義布局/繪制/動效，可對現(xiàn)有組件根據(jù)需要做定制/動態(tài)擴展等

從運行時維度，它的關(guān)鍵要素如下（性能體驗是關(guān)鍵需求）：

a.高效的UI渲染管線，并可實現(xiàn)組件/屬性按需組合降低內(nèi)存開銷

b.高效的狀態(tài)管理/UI更新機制，根據(jù)數(shù)據(jù)變化精準定位刷新范圍

c.自適應(yīng)UI能力，以及多態(tài)組件能力（同一UI描述在不同設(shè)備可自動實現(xiàn)不同UI效果，自動適配不同的用戶交互模式等）

d.平臺無關(guān)的一致性渲染能力

另外，在配套的工具層面，比如IDE，需具備實時預(yù)覽能力（包括雙向預(yù)覽，多設(shè)備預(yù)覽，預(yù)覽和調(diào)試融合等）。

1.2.3.3跨設(shè)備自適應(yīng)以及彈性部署能力

這里主要包括針對不同形態(tài)的設(shè)備的自適應(yīng)（包括布局，控件形態(tài)等），不同能力的設(shè)備彈性部署（包括設(shè)備的提供API差異，系統(tǒng)所需的資源差異等）。從架構(gòu)設(shè)計而言，則需具備組件解耦，按需加載，以及輕量化等能力。

1.2.3.4跨平臺

這里主要包括平臺抽象層設(shè)計以及各個主流OS相應(yīng)的適配實現(xiàn)，相關(guān)的工具鏈支持等。這樣就可以基于一套主代碼，部署到不同的OS平臺上。其中的關(guān)鍵要素包括通用的API設(shè)計和實現(xiàn)（提升應(yīng)用代碼的復用度），組件化機制（降低SDK大?。?，以及上述提到的平臺一致化渲染能力等。

審核編輯：湯梓紅