逐行分析鴻蒙系統的 JavaScript 框架
我在前文中曾經介紹過鴻蒙的 Javascript 框架,這幾天終於把 JS 倉庫編譯通過了,期間踩了不少坑,也給鴻蒙貢獻了幾個 PR。今天我們就來逐行分析鴻蒙系統中的 JS 框架。
文中的所有程式碼都基於鴻蒙的當前最新版(版本為 677ed06,提交日期為 2020-09-10)。
鴻蒙系統使用 JavaScript 開發 GUI 是一種類似於微信小程式、輕應用的模式。而這個 MVVM 模式中,V 其實是由 C++ 來承擔的。JavaScript 程式碼只是其中的 ViewModel 層。
鴻蒙 JS 框架是零依賴的,只在開發打包過程中使用到了一些 npm 包。打包完之的程式碼是沒有依賴任何 npm 包的。我們先看一下使用鴻蒙 JS 框架寫出來的 JS 程式碼到底長什麼樣。
export default {
data: {
return { count: 1 };
},
increase() {
++this.count;
},
decrease() {
--this.count;
},
}
如果我不告訴你這是鴻蒙,你甚至會以為它是 vue 或小程式。如果單獨把 JS 拿出來使用(脫離鴻蒙系統),程式碼是這樣:
const vm = new ViewModel({
data() {
return { count: 1 };
},
increase() {
++this.count;
},
decrease() {
--this.count;
},
});
console.log(vm.count); // 1
vm.increase();
console.log(vm.count); // 2
vm.decrease();
console.log(vm.count); // 1
倉庫中的所有 JS 程式碼實現了一個響應式系統,充當了 MVVM 中的 ViewModel。
下面我們逐行分析。
src 目錄中一共有 4 個目錄,總計 8 個檔案。其中 1 個是單元測試。還有 1 個效能分析。再除去 2 個 index.js 檔案,有用的檔案一共是 4 個。也是本文分析的重點。
src
├── __test__
│ └── index.test.js
├── core
│ └── index.js
├── index.js
├── observer
│ ├── index.js
│ ├── observer.js
│ ├── subject.js
│ └── utils.js
└── profiler
└── index.js
首先是入口檔案,src/index.js,只有 2 行程式碼:
import { ViewModel } from './core';
export default ViewModel;
其實就是重新匯出。
另一個類似的檔案是 src/observer/index.js,也是 2 行程式碼:
export { Observer } from './observer';
export { Subject } from './subject';
observer 和 subject 實現了一個觀察者模式。subject 是主題,也就是被觀察者。observer 是觀察者。當 subject 有任何變化時需要主動通知被觀察者。這就是響應式。
這 2 個檔案都使用到了 src/observer/utils.js,所以我們先分析一下 utils 檔案。分 3 部分。
第一部分
export const ObserverStack = {
stack: [],
push(observer) {
this.stack.push(observer);
},
pop() {
return this.stack.pop();
},
top() {
return this.stack[this.stack.length - 1];
}
};
首先是定義了一個用來存放觀察者的棧,遵循後進先出的原則,內部使用 stack
陣列來儲存。
入棧操作
push
,和陣列的push
函式一樣,在棧頂放入一個觀察者 observer。出棧操作
pop
,和陣列的pop
函式一樣,在將棧頂的觀察者刪除,並返回這個被刪除的觀察者。取棧頂元素
top
,和pop
操作不同,top
是把棧頂元素取出來,但是並不刪除。
第二部分
export const SYMBOL_OBSERVABLE = '__ob__';
export const canObserve = target => typeof target === 'object';
定義了一個字串常量 SYMBOL_OBSERVABLE
。為了後面用著方便。
定義了一個函式 canObserve
,目標是否可以被觀察。只有物件才能被觀察,所以使用 typeof
來判斷目標的型別。等等,好像有什麼不對。如果 target
為 null
的話,函式也會返回 true
。如果 null
不可觀察,那麼這就是一個 bug。(寫這篇文章的時候我已經提了一個 PR,並詢問了這種行為是否是期望的行為)。
第三部分
export const defineProp = (target, key, value) => {
Object.defineProperty(target, key, { enumerable: false, value });
};
這個沒有什麼好解釋的,就是 Object.defineProperty
程式碼太長了,定義一個函式來避免程式碼重複。
下面再來分析觀察者 src/observer/observer.js,分 4 部分。
第一部分
export function Observer(context, getter, callback, meta) {
this._ctx = context;
this._getter = getter;
this._fn = callback;
this._meta = meta;
this._lastValue = this._get();
}
建構函式。接受 4 個引數。
context
當前觀察者所處的上下午,型別是 ViewModel
。當第三個引數 callback 呼叫時,函式的 this
就是這個 context
。
getter
型別是一個函式,用來獲取某個屬性的值。
callback
型別是一個函式,當某個值變化後執行的回撥函式。
meta
後設資料。觀察者(Observer)並不關注 meta
後設資料。
在建構函式的最後一行,this._lastValue = this._get()
。下面來分析 _get
函式。
第二部分
Observer.prototype._get = function() {
try {
ObserverStack.push(this);
return this._getter.call(this._ctx);
} finally {
ObserverStack.pop();
}
};
ObserverStack
就是上面分析過的用來儲存所有觀察者的棧。將當前觀察者入棧,並通過 _getter
取得當前值。結合第一部分的建構函式,這個值儲存在了 _lastValue
屬性中。
執行完這個過程後,這個觀察者就已經初始化完成了。
第三部分
Observer.prototype.update = function() {
const lastValue = this._lastValue;
const nextValue = this._get();
const context = this._ctx;
const meta = this._meta;
if (nextValue !== lastValue || canObserve(nextValue)) {
this._fn.call(context, nextValue, lastValue, meta);
this._lastValue = nextValue;
}
};
這部分實現了資料更新時的髒檢查(Dirty checking)機制。比較更新後的值和當前值,如果不同,那麼就執行回撥函式。如果這個回撥函式是渲染 UI,那麼則可以實現按需渲染。如果值相同,那麼再檢查設定的新值是否可以被觀察,再決定到底要不要執行回撥函式。
第四部分
Observer.prototype.subscribe = function(subject, key) {
const detach = subject.attach(key, this);
if (typeof detach !== 'function') {
return;
}
if (!this._detaches) {
this._detaches = [];
}
this._detaches.push(detach);
};
Observer.prototype.unsubscribe = function() {
const detaches = this._detaches;
if (!detaches) {
return;
}
while (detaches.length) {
detaches.pop()();
}
};
訂閱與取消訂閱。
我們前面經常說觀察者和被觀察者。對於觀察者模式其實還有另一種說法,叫訂閱/釋出模式。而這部分程式碼則實現了對主題(subject)的訂閱。
先呼叫主題的 attach
方法進行訂閱。如果訂閱成功,subject.attach
方法會返回一個函式,當呼叫這個函式就會取消訂閱。為了將來能夠取消訂閱,這個返回值必需儲存起來。
subject 的實現很多人應該已經猜到了。觀察者訂閱了 subject,那麼 subject 需要做的就是,當資料變化時即使通知觀察者。subject 如何知道資料發生了變化呢,機制和 vue2 一樣,使用 Object.defineProperty
做屬性劫持。
下面再來分析觀察者 src/observer/subject.js,分 7 部分。
第一部分
export function Subject(target) {
const subject = this;
subject._hijacking = true;
defineProp(target, SYMBOL_OBSERVABLE, subject);
if (Array.isArray(target)) {
hijackArray(target);
}
Object.keys(target).forEach(key => hijack(target, key, target[key]));
}
建構函式。基本沒什麼難點。設定 _hijacking
屬性為 true
,用來標示這個物件已經被劫持了。Object.keys
通過遍歷來劫持每個屬性。如果是陣列,則呼叫 hijackArray
。
第二部分
兩個靜態方法。
Subject.of = function(target) {
if (!target || !canObserve(target)) {
return target;
}
if (target[SYMBOL_OBSERVABLE]) {
return target[SYMBOL_OBSERVABLE];
}
return new Subject(target);
};
Subject.is = function(target) {
return target && target._hijacking;
};
Subject 的建構函式並不直接被外部呼叫,而是封裝到了 Subject.of
靜態方法中。
如果目標不能被觀察,那麼直接返回目標。
如果 target[SYMBOL_OBSERVABLE]
不是 undefined
,說明目標已經被初始化過了。
否則,呼叫建構函式初始化 Subject。
Subject.is
則用來判斷目標是否被劫持過了。
第三部分
Subject.prototype.attach = function(key, observer) {
if (typeof key === 'undefined' || !observer) {
return;
}
if (!this._obsMap) {
this._obsMap = {};
}
if (!this._obsMap[key]) {
this._obsMap[key] = [];
}
const observers = this._obsMap[key];
if (observers.indexOf(observer) < 0) {
observers.push(observer);
return function() {
observers.splice(observers.indexOf(observer), 1);
};
}
};
這個方法很眼熟,對,就是上文的 Observer.prototype.subscribe
中呼叫的。作用是某個觀察者用來訂閱主題。而這個方法則是“主題是怎麼訂閱的”。
觀察者維護這一個主題的雜湊表 _obsMap
。雜湊表的 key 是需要訂閱的 key。比如某個觀察者訂閱了 name
屬性的變化,而另一個觀察者訂閱了 age
屬性的變化。而且屬性的變化還可以被多個觀察者同時訂閱,因此雜湊表儲存的值是一個陣列,資料的每個元素都是一個觀察者。
第四部分
Subject.prototype.notify = function(key) {
if (
typeof key === 'undefined' ||
!this._obsMap ||
!this._obsMap[key]
) {
return;
}
this._obsMap[key].forEach(observer => observer.update());
};
當屬性發生變化是,通知訂閱了此屬性的觀察者們。遍歷每個觀察者,並呼叫觀察者的 update
方法。我們上文中也提到了,髒檢查就是在這個方法內完成的。
第五部分
Subject.prototype.setParent = function(parent, key) {
this._parent = parent;
this._key = key;
};
Subject.prototype.notifyParent = function() {
this._parent && this._parent.notify(this._key);
};
這部分是用來處理屬性巢狀(nested object)的問題的。就是類似這種物件:{ user: { name: 'JJC' } }
。
第六部分
function hijack(target, key, cache) {
const subject = target[SYMBOL_OBSERVABLE];
Object.defineProperty(target, key, {
enumerable: true,
get() {
const observer = ObserverStack.top();
if (observer) {
observer.subscribe(subject, key);
}
const subSubject = Subject.of(cache);
if (Subject.is(subSubject)) {
subSubject.setParent(subject, key);
}
return cache;
},
set(value) {
cache = value;
subject.notify(key);
}
});
}
這一部分展示瞭如何使用 Object.defineProperty
進行屬性劫持。當設定屬性時,會呼叫 set(value),設定新的值,然後呼叫 subject 的 notify 方法。這裡並不進行任何檢查,只要設定了屬性就會呼叫,即使屬性的新值和舊值一樣。notify 會通知所有的觀察者。
第七部分
劫持陣列方法。
const ObservedMethods = {
PUSH: 'push',
POP: 'pop',
UNSHIFT: 'unshift',
SHIFT: 'shift',
SPLICE: 'splice',
REVERSE: 'reverse'
};
const OBSERVED_METHODS = Object.keys(ObservedMethods).map(
key => ObservedMethods[key]
);
ObservedMethods
定義了需要劫持的陣列函式。前面大寫的用來做 key,後面小寫的是需要劫持的方法。
function hijackArray(target) {
OBSERVED_METHODS.forEach(key => {
const originalMethod = target[key];
defineProp(target, key, function() {
const args = Array.prototype.slice.call(arguments);
originalMethod.apply(this, args);
let inserted;
if (ObservedMethods.PUSH === key || ObservedMethods.UNSHIFT === key) {
inserted = args;
} else if (ObservedMethods.SPLICE) {
inserted = args.slice(2);
}
if (inserted && inserted.length) {
inserted.forEach(Subject.of);
}
const subject = target[SYMBOL_OBSERVABLE];
if (subject) {
subject.notifyParent();
}
});
});
}
陣列的劫持和物件不同,不能使用 Object.defineProperty
。
我們需要劫持 6 個陣列方法。分別是頭部新增、頭部刪除、尾部新增、尾部刪除、替換/刪除某幾項、陣列反轉。
通過重寫陣列方法實現了陣列的劫持。但是這裡有一個需要注意的地方,資料的每一個元素都是被觀察過的,但是當在陣列中新增了新元素時,這些元素還沒有被觀察。因此程式碼中還需要判斷當前的方法如果是 push
、unshift
、splice
,那麼需要將新的元素放入觀察者佇列中。
另外兩個檔案分別是單元測試和效能分析,這裡就不再分析了。
相關閱讀
相關文章
- 鴻蒙系統中的 JS 開發框架鴻蒙JS框架
- 鴻蒙系統系列教程1-鴻蒙系統的發展史鴻蒙
- 鴻蒙開發實戰:【系統服務框架部件】鴻蒙框架
- 鴻蒙系統嚐鮮鴻蒙
- 鴻蒙系統系列教程6-鴻蒙系統專案結構解析鴻蒙
- 鴻蒙系統中Intent的使用鴻蒙Intent
- 鴻蒙系統和安卓的區別 鴻蒙系統是基於安卓嗎鴻蒙安卓
- 鴻蒙系統系列教程2-鴻蒙OS系統分散式操作講解鴻蒙分散式
- 鴻蒙系統系列教程5-鴻蒙開發環境的搭建鴻蒙開發環境
- 鴻蒙輕核心原始碼分析:檔案系統LittleFS鴻蒙原始碼
- 鴻蒙系統系列教程3-鴻蒙OS的技術特徵講解鴻蒙特徵
- 鴻蒙OS的系統呼叫是如何實現的? | 解讀鴻蒙原始碼鴻蒙原始碼
- 鴻蒙系統什麼時候能用 鴻蒙系統有什麼特別之處鴻蒙
- 鴻蒙作業系統特點鴻蒙作業系統
- 鴻蒙系統freeModbusTcp移植簡介鴻蒙TCP
- 華為鴻蒙系統怎麼補電?華為鴻蒙系統手機補電的操作方法鴻蒙
- 鴻蒙系統超級終端怎麼使用?鴻蒙系統超級終端開啟教程鴻蒙
- 鴻蒙系統超級終端是幹什麼用的?鴻蒙系統超級終端的作用詳解鴻蒙
- 華為鴻蒙系統HarmonyOS學習之十:鴻蒙HarmonyOS微核心技術鴻蒙
- 成為自己(二):鴻蒙 Harmony 系統篇鴻蒙
- 鴻蒙系統應用基礎開發鴻蒙
- OS-鴻蒙系統-以及編譯器鴻蒙編譯
- 鴻蒙系統(HarmonyOS)全域性彈窗實現鴻蒙
- 鴻蒙系統(OpenHarmony HarmonyOS):面向全場景的分散式作業系統鴻蒙分散式作業系統
- 一文讀懂鴻蒙系統與安卓系統的區別鴻蒙安卓
- 華為鴻蒙進一步開啟海外市場!歐洲官宣“鴻蒙”新系統!鴻蒙
- 為什麼谷歌不起訴華為的鴻蒙系統?谷歌鴻蒙
- 實測!華為鴻蒙比 Android系統快60%!鴻蒙Android
- 聊聊鴻蒙系統與開發者生態前景鴻蒙
- 鴻蒙 next 原生系統自動化框架要怎麼實現?有啥思路提供不?鴻蒙框架
- 鴻蒙輕核心原始碼分析:Newlib C鴻蒙原始碼
- 3.5鴻蒙鴻蒙
- 鴻蒙layoutWeight鴻蒙
- 震驚!浙江某男子發現鴻蒙系統若干秘密鴻蒙
- 鴻蒙系統應用開發之入門解說鴻蒙
- 鴻蒙系統應用開發之開發準備鴻蒙
- 技術期刊 · 白日照耀開鴻蒙 | 深入鴻蒙 ACE UI 框架解析;無限迴圈的 useEffect 型別……鴻蒙UI框架型別
- 鴻蒙適配一多搭建首頁框架鴻蒙框架