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

HarmonyOS開發者社群發表於2023-05-04


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

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

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

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

1、應用框架概覽

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

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

undefined

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

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

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

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

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

其中, UI框架的主要組成如下圖所示:

undefined

Figure 2 UI框架的主要組成

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

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

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

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

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

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

undefined

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)逐步增加多裝置以及跨平臺支援。

undefined


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70009402/viewspace-2949766/,如需轉載,請註明出處,否則將追究法律責任。

相關文章