逐行分析鸿蒙系统的 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 部分。

逐行分析鸿蒙系统的 JavaScript 框架(推荐)

扫一扫手机访问