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