華為自研的前端框架是什么樣的？
大家好，我卡頌。
最近，華為開源了一款前端框架 —— openInula[1]。根據(jù)官網(wǎng)提供的信息，這款框架有3大核心能力：
響應(yīng)式API
兼容ReactAPI
官方提供6大核心組件
并且，在官方宣傳視頻里提到 —— 這是款「大模型驅(qū)動」的「智能框架」。
那么，這究竟是款什么樣的前端框架呢？我在第一時間體驗了Demo，閱讀了框架源碼，并采訪了框架核心開發(fā)者。本文將包括兩部分內(nèi)容：
- 對框架核心開發(fā)者陳超濤的采訪
- 卡頌作為一個老前端，閱讀框架源碼后的一些分析
采訪核心開發(fā)者
開發(fā)Inula的初衷是？
回答：
華為內(nèi)部對于業(yè)務(wù)中強依賴的軟件，考慮到競爭力，，會開發(fā)一個內(nèi)部使用的版本。
Inula在華為內(nèi)部，從立項到現(xiàn)在兩年多，基本替換了公司內(nèi)絕大部分React項目。
卡頌補充背景知識：Inula兼容React 95% API，最初開發(fā)的目的就是為了替換華為內(nèi)部使用的React。為了方便理解，你可以將Inula類比于華為內(nèi)部的React
為什么開源？
回答：
華為對于「自研軟件」的公司策略，只要是公司內(nèi)部做的，覺得還ok的自研都會開源。
接下來的提問涉及到官網(wǎng)宣傳的內(nèi)容
宣傳片提到的大模型賦能、智能框架是什么意思？
回答：
這主要是Inula團隊與其他外部團隊在AI、低代碼方向的一些探索。比如：
- 團隊與上海交大的一個團隊在探索「大模型賦能chrome調(diào)試業(yè)務(wù)代碼」方面有些合作，目的是為了「自動定位問題」
- 團隊與華為內(nèi)部的「大模型編輯器」團隊合作，探索「框架與編輯器定制」可能性
以上還都屬于探索階段。
Inula未來有明確的發(fā)展方向么？
回答：
團隊正在探索引入「響應(yīng)式API」，相比于「React的虛擬DOM」方案，響應(yīng)式API能夠提高運行時性能。24年可能會從Vue composition API中尋求些借鑒。
新的發(fā)展方向會在項目倉庫以RFC的形式展開。
補充：RFC是「Request for Comments」的縮寫。這是一種協(xié)作模式，通常用于提出新的特性、規(guī)范或者改變現(xiàn)有的一些規(guī)則。RFC的目的是收集不同的意見和反饋，以便在最終確定一個決策前，考慮盡可能多的觀點和影響。
為什么要自研核心組件而不用社區(qū)成熟方案？
卡頌補充：所謂「核心組件」，是指狀態(tài)管理、路由、國際化、請求庫、腳手架這樣的框架生態(tài)相關(guān)的庫。既然Inula兼容React，為什么不直接用React生態(tài)的成熟產(chǎn)品，而要自研呢？畢竟，這些庫是沒有軟件風(fēng)險的。
回答：
主要還是豐富Inula生態(tài)，根據(jù)社區(qū)優(yōu)秀的庫總結(jié)一套Inula官方推薦的最佳實踐。至于開發(fā)者怎么選擇，我們并不強求。
卡頌的分析
以上是我對Inula核心開發(fā)者陳超濤的采訪。下面是我看了Inula源碼后的一些分析。
要分析一款前端框架，最重要的是明白他是如何更新視圖的？這里我選擇了兩種觸發(fā)時機來分析：
首次渲染
觸發(fā)的方式類似如下：
Inula.render(<App />, document.getElementById("root"));執(zhí)行useState的更新方法觸發(fā)更新
觸發(fā)的方式類似如下：
function App() {
const [num, update] = useState(0);
// 觸發(fā)更新
update(xxx);
// ...
}順著調(diào)用棧往下看，他們都會執(zhí)行兩步操作：
- 創(chuàng)建名為update的數(shù)據(jù)結(jié)構(gòu)
- 執(zhí)行l(wèi)aunchUpdateFromVNode方法
比如這是首屏渲染時：
這是useState更新方法執(zhí)行時：
launchUpdateFromVNode方法會向上遍歷到根結(jié)點（源碼中遍歷的節(jié)點叫VNode），再從根節(jié)點開始遍歷樹。由此可以判斷，Inula的更新機制與React類似。
所有主流框架在觸發(fā)更新后，都不會立刻執(zhí)行更新，中間還有個調(diào)度流程。這個流程的存在是為了解決：
- 哪些更新應(yīng)該被優(yōu)先執(zhí)行？
- 是否有些更新是冗余的，需要合并在一塊執(zhí)行？
在Vue中，更新會在微任務(wù)中被調(diào)度并統(tǒng)一執(zhí)行，在React中，同時存在微任務(wù)（promise）與宏任務(wù)（MessageChannel）的調(diào)度模式。
在Inula中，存在宏任務(wù)的調(diào)度模式 —— 當(dāng)宿主環(huán)境支持MessageChannel時會使用它，不支持則使用setTimeout調(diào)度：
同時，與這套調(diào)度機制配套的還有個簡單的優(yōu)先級算法 —— 存在兩種優(yōu)先級，其中：
- ImmediatePriority：對應(yīng)正常情況觸發(fā)的更新。
- NormalPriority：對應(yīng)useEffect回調(diào)。
每個更新會根據(jù)「更新的ID」（一個自增的數(shù)字）+ 「優(yōu)先級對應(yīng)的數(shù)字」 作為優(yōu)先級隊列中的排序依據(jù)，按順序執(zhí)行。
假設(shè)先后觸發(fā)2次更新，優(yōu)先級分別是ImmediatePriority與NormalPriority，那么他們的排序依據(jù)分別是：
- 100（假設(shè)當(dāng)前ID到100了）- 1（ImmediatePriority對應(yīng)-1） = 99。
- 101（100自增到101）+ 10000（NormalPriority對應(yīng)10000）= 10101。
99 < 10101，所以前者會先執(zhí)行。
需要注意的是，Inula中對更新優(yōu)先級的控制粒度沒有React并發(fā)更新細(xì)，比如對于如下代碼：
useEffect(function cb() {
update(xxx);
update(yyy);
})在React中，控制的是每個update對應(yīng)優(yōu)先級。在Inula中，控制的是cb回調(diào)函數(shù)與其他「更新所在回調(diào)函數(shù)」之間的執(zhí)行順序。
這意味著本質(zhì)來說，Inula中觸發(fā)的所有更新都是「同步更新」，不存在React并發(fā)更新中「高優(yōu)先級更新打斷低優(yōu)先級更新」的情況。
這也解釋了為什么Inula兼容 95% 的React API，剩下 5% 就是「并發(fā)更新相關(guān)API」（比如useTransition、useDeferredvalue）。
現(xiàn)在我們已經(jīng)知道Inula的更新方式類似React，那么官網(wǎng)提到的「響應(yīng)式API」該如何實現(xiàn)呢？這里存在三條路徑：
- 一套外掛的響應(yīng)式系統(tǒng)，類似React與Mobx的關(guān)系。
- 內(nèi)部同時存在兩套更新系統(tǒng)（當(dāng)前一套，響應(yīng)式一套），調(diào)用不同的API使用不同的系統(tǒng)。
- 重構(gòu)內(nèi)部系統(tǒng)為響應(yīng)式系統(tǒng)，通過編譯手段，使所有API（包括當(dāng)前的React API與未來的類 Vue Composition API）都走這套系統(tǒng)。
其中第一條路徑比較簡單，第二條路徑應(yīng)該還沒框架使用，第三條路徑想象空間最大。不知道Inula未來會如何發(fā)展。
總結(jié)
當(dāng)前，Inula是一款「類React的框架」，功能上可以類比為「React并發(fā)更新之前的版本」。
下一步，Inula會引入「響應(yīng)式API」，目的是提高渲染效率。
對于未來的發(fā)展，主要圍繞在：
- 探索類 Vue Composition API的可能性
- 迭代官方核心生態(tài)庫
對于華為出的這款前端框架，你怎么看？
參考資料
[1]openInula:https://www.openinula.net/。
