本文主要介绍Angular中的黑科技之WebWorker Renderer,使用Worker线程渲染如何渲染页面?从源码的角度切入,带领带大家看个究竟。
先来做个对比
开发框架版本@H_301_10@:Angular 4.x
项目地址@H_301_10@:angular-webworker-renderer-demo
对比对象@H_301_10@:传统的UI线程渲染和使用WebWorker线程渲染页面
对比方法@H_301_10@:各执行1到1000的连乘,并循环20次,要求实时展示进度
运行结果@H_301_10@:
首先是传统的UI线程渲染效果:
其次时使用WebWorker线程渲染效果:
从动图中很明显可以看出,使用了WebWorker Renderer渲染的页面运行流畅,没有卡顿。
简单介绍下Web Woker
Web Workers是一种机制,通过它可以使一个脚本操作在与Web应用程序的主执行线程分离的后台线程中运行。这样做的优点是可以在单独的线程中执行繁琐的处理,让主(通常是UI)线程运行而不被阻塞/减慢。 —— Web Workers API from MDN
简单来说,在出现WebWoker之前,Web开发人员无法手动在浏览器中创建线程,而出现WebWoker之后,Web开发人员可以进入多线程开发Web项目了。
Web Worker的优势
下面根据YouTube视频(见参考)中的内容总结了下使用WebWorker的优势:
- 运行过程中不会阻碍主线程(UI渲染线程)的运行,特别适合执行计算密集型的程序
- WebWorker线程可跨窗口或frames(使用SharedWorker)
- 使用WebWorker后能更优雅地执行测试过程(一些脱离可DOM操作的测试)
- 兼容性(IE 10+)
- 更高效地利用电量
对于最后一点的解释,应该先转化为另外一个问题,一些计算密集型的程序为什么不在服务端执行完毕后返回给前端?这在视频中也给出了解释,作者总结了一句话:It costs more to transmit a byte than to compute it@H_301_10@,意思是传输一个byte比计算出一个byte的消耗更大。为什么呢?自己想吧
Web Worker可能的使用场景
那么真的有这么多应用场景吗?以下列举了几个场景:
- 解析一个庞大的JSON结构
- 图片/音频处理
- 大规模数据可视化
仔细想一想,这样的场景还是很特殊的,可能在实际的应用中并不多见。那么,在目前的主流前端框架是否有利用到WebWorker的特性来帮助其提升性能呢?经过调研,发现很多还在探索阶段,比如在React框架中的探索,Parashuram在2016年发布了文章《Using Webworkers to make React faster》,文章是关于如何利用Webworker提升React的渲染速度,主要是把Virtual DOM的相关计算过程(如diff算法)放入WebWorker线程,从结果可以看出,在Benchmark的对比下,使用WebWorker的一方帧率有所提高,感兴趣的同学可以查看其演示示例和项目地址。这里忍不住要引用作者的一张图(如下图所示,纵轴是帧率,横轴是节点的个数),简要展示下React项目在使用WebWorker的情况下,性能的提升效果。
(图片来源:Using Webworkers to make React faster)
那么WebWorker已经面世这么了,浏览器支持也跟上了,为何其应用场景或者与主流框架的结合并没有很多见?我想可能与以下几点WebWorker的缺点相关:
- 在Webworker线程中无法访问DOM节点
- 无法与UI线程共享内存
- 与UI线程通讯的信息需要序列化
- 线程间通讯不可避免的并发问题
虽然如此,Angular背后的Google团队已经开始尝试打破这些限制,并已经在Angular 2.x中得进行了应用(WebWorker Renderer),虽然到了目前的Angular 4.x在源码中仍标识为@experimental,但相信其在将来会成为Angular框架的标配。接下来的文章内容,会分析到在Angular框架中Webworker Renderer是如何工作的,包括如下三个要点:
- 通讯信息如何序列化与反序列化?内存数据如何共享?
- 如何打破Webworker线程不能操作DOM节点的局限?
- 如何处理并发?
希望你能带着这两个问题阅读完以下的篇幅。
先感受一下
图中显示的基本是整个UI线程与WebWorker线程通讯的过程,给你来个初步的影响,可以帮助你在阅读后续内容时有个整体观的把控,图中涉及的类、方法以及过程,在接下来的文章中会一一介绍到。
介绍几个基本的类
先来看看这个RenderStroe@H_301_10@类,在Angular是被标识为@Injectable()的可注入类,其中_nextIndex是一个自增的索引号,通过allocateId函数递增分配。store和remove函数是对_lookupById和_lookupByObject两个Map类型的容器进行新增和删除操作,其中的传入的id参数作为唯一的索引号(通过allocateId函数分配而来)。最后deserialize和serialize方法分别是根据id取出内容和根据内容取出id。这意味中在RenderStore@H_301_10@中序列化就是将对象转换成一个唯一数字,而相对应的反序列化就是将数字转换为一个对象。
这样一个很重要的RenderStore类就介绍完毕了,它承担了线程间数据信息通讯序列化/反序列化的重要工作。总的来说,就是将需要传输的内容对象与一个索引号对应起来,实现序列化和反序列化的过程。这个类会穿梭于整个工作流程,经常会注入到其他关键类中,是UI线程与WebWorker线程公用的类,两端共同维护同一个副本,间接到达线程间数据共享@H_301_10@的目的。
通过这个RenderStore@H_301_10@类,我们已经可以解决之前提出第一个问题,放张动图大家先消化消化。聪明的你可能会有以下几个疑问:
- Object对象里存的到底是什么东西?
- 难倒只能由WebWorker线程向UI线程单向地@H_301_10@发送同步RenderStore数据的指令?
不慌,我们接下去讲。
这个Serializer类主要用于WebWoker线程与UI主线程之间通讯的时候,提供消息信息序列化和反序列化的操作,其实还是主要依赖于RenderStore提供的方法。
该类定义了序列化的类型,对于string,number,boolean类型,即PRIMITIVE@H_301_10@类型,是不需要序列化/反序列化的。通过代码枚举得知,操作支持如下几种类型:
enum SerializerTypes { // RendererType2 RENDERER_TYPE_2,// Primitive types,such as string,number,boolean PRIMITIVE,// An object stored in a RenderStore RENDER_STORE_OBJECT,}
具体做如下说明(其中只列举了序列化的过程):
- PRIMITIVE@H_301_10@类型(原始类型),serializer方法不做任何处理,直接返回;
- Array@H_301_10@类型,使用map方法对数组中的每一项再serializer,然后返回;
- RENDER_STORE_OBJECT@H_301_10@类型,通过RenderStore类中的serialize方法序列化后返回;
- RENDERER_TYPE_2@H_301_10@类型,通过调用_serializeRendererType2方法处理后返回;
- RenderComponentType@H_301_10@类型,通过调用_serializeRenderComponentType方法处理后返回;
- LocationType@H_301_10@类型,通过调用_serializeLocation方法处理后返回;
其中,RenderComponentType@H_301_10@,RendererType2@H_301_10@类型是@angular/core中定义的,两者都是Angular编译器中对DOM节点进行渲染处理时定义的类型,这里不多做阐述。LocationType@H_301_10@类型是针对浏览器的路由操作(windows.locaion.*)进行的包装,包含href,protocol,host,hostname,port等,容易理解。
此外,serializeRendererType2@H_301_10@和serializeRenderComponentType@H_301_10@方法体中也是根据序列化对象的结构再进行拆分@H_301_10@对待,并继续调用serialize方法处理。比如_serializeRendererType2方法中是这样的:
private _serializeRendererType2(type: RendererType2): {[key: string]: any} { return { 'id': type.id,'encapsulation': this.serialize(type.encapsulation),'styles': this.serialize(type.styles),'data': this.serialize(type.data),}; }
从代码中可以看出,通讯信息的序列化/反序列化过程其实就是主要针对string,number,boolean类型(PRIMITIVE@H_301_10@类型)和RENDER_STORE_OBJECT@H_301_10@类型在作处理,前者不需要序列化/反序列化,后者通过RenderStore@H_301_10@提供的方法进行处理。
是时候回答下之前提出的问题:RenderStore@H_301_10@中存的Object对象到底是哪些?RENDER_STORE_OBJECT@H_301_10@类型是指哪些类型呢?
- WebWorkerRenderer2@H_301_10@类型,继承自Renderer2@H_301_10@类(该类是Angular的核心类,用于操作DOM相关,这里就不啰嗦了)
- WebWorkerRenderNode@H_301_10@类型,该类有且只有一个类型为NamedEventEmitter@H_301_10@的成员变量events
于是,不得不提到NamedEventEmitter@H_301_10@类,这个类维护了一个Map类型的容器_listener,存储了事件名称和对应的方法,并提供新增(listen)、删除(unliten)以及触发事件的方法(dispatchEvent)。
由此可见,事件的定义、维护和触发在整个线程间通讯过程中至关重要。
再说说与通讯相关的类
根据官方远源码介绍,MessageBus@H_301_10@类是一个低级别的API,是一个抽象类,主要用于UI主线程与WebWorker线程的通信相关。而双方的通信是基于通道(channel),通道的两端分别是MessageBusSink@H_301_10@(信息流出)和MessageBusSource@H_301_10@(信息流入),后续会细说到。类中提及的Zone是Angular的魔法,由于对与本文内容的理解不受影响,因此不做过多阐述,如感兴趣请自行查看。
首先是来列举下Angular中定义的三种通道的类型,三种通道负责不同的工作,分为渲染、事件和路由。
// DOM渲染通道 export declare const RENDERER_2_CHANNEL = "v2.ng-Renderer"; // DOM事件通道 export declare const EVENT_2_CHANNEL = "v2.ng-Events"; // 路由通道 export declare const ROUTER_CHANNEL = "ng-Router";
接下来具体讲下PostMessageBus@H_301_10@类,作为MessageBus@H_301_10@抽象类的一个实现,类结构如下图所示。
该类的两个公共成员变量分别是source(PostMessageBusSource@H_301_10@类型,是MessageBusSource类的一实现类)和sink(PostMessageBusSink@H_301_10@类型,是MessageBusSink的实现类),可以解释为水源和水槽@H_301_10@。可以这么理解,信息好比是水,可以通过水槽流出,也可以流入到水源中@H_301_10@。
类中的initChannel方法对这通道进行初始化,其中有2个的关键点:1)每个通道的实例最多只能有三个不同的通道类型;2)Channel通道信息初始化时候包含了一个EventEmitter@H_301_10@类的实例对象,在Sink通道初始化的时候还会对其进行了订阅操作,触发后会执行相应的sendMessage操作,这个发送信息的方法的实现主要是通过该类的构造函数中传入,后面会有所介绍。
另外需要介绍一下PostMessageBusSource@H_301_10@类,该类在构造函数中会对Worker对象通过addEventListener方法监听message事件,这个过程能监听信息接收的事件,并且做相应的信息处理的操作,即通过EventEmitter类的emit方法来触发相应的订阅事件。
首先介绍一下WebWorkerRendererFactory2@H_301_10@类,从类名中可以解释为WebWorker渲染工厂,在Angular中也被标为@Injectable()类型,其构造函数中依赖ClientMessageBrokerFactory@H_301_10@,MessageBus@H_301_10@,Serializer@H_301_10@,RenderStore@H_301_10@类的注入,并对其初始化,如下:
this._messageBroker = messageBrokerFactory.createMessageBroker(RENDERER_2_CHANNEL); bus.initChannel(EVENT_2_CHANNEL); const source = bus.from(EVENT_2_CHANNEL); source.subscribe({next: (message: any) => this._dispatchEvent(message)});
从构造函数中能了解到,主要依赖注入类型的作用,首先通过ClientMessageBrokerFactory@H_301_10@创建了通道为RENDERER_2_CHANNEL@H_301_10@的代理人,虽然还未具体解释ClientMessageBroker@H_301_10@类的作用,但从类命名中就可以了解到它的作用就是作为与UI线程通讯的中间代理人,在该类中负责向UI线程传输DOM节点渲染的工作,这个会在后续会详细介绍。另外,通过自身的MessageBus创建了EVENT_2_CHANNEL@H_301_10@通道,并且对信息源做了subscribe的订阅操作,即当UI线程DOM事件触发时,该MessageBus的Source会接收到信息,并触发相应的_dispatchEvent函数操作,在WebWorker层中做相应的处理。
与WebWorkerRendererFactory2@H_301_10@对应的就是WebWorkerRenderer2@H_301_10@类,该类从类结构中就可以看出包含了各种对DOM节点的操作函数,基本覆盖原生JS的DOM操作函数。特别注意@H_301_10@,该类里面的操作函数并不是真正地操作DOM节点@H_301_10@,而是在WebWorker线程中的模拟,最后还是以消息的形式发送给UI主线程中调用Renderer2@H_301_10@进行操作,后续会讲到。举例说一下其中的createElement@H_301_10@函数:
createElement(name: string,namespace?: string): any { const node = this._rendererFactory.allocateNode(); this.callUIWithRenderer('createElement',[ new FnArg(name),new FnArg(namespace),new FnArg(node,SerializerTypes.RENDER_STORE_OBJECT),]); return node; }
其函数体中的_rendererFactory成员变量是一个WebWorkerRendererFactory2@H_301_10@类的实例(在构造函数中传入),调用了allocateNode方法,创建一个包含事件处理的类,再通过RenderStore@H_301_10@生成唯一Id,并存储。然后调用callUIWithRenderer函数,如下:
private callUIWithRenderer(fnName: string,fnArgs: FnArg[] = []) { // always pass the renderer as the first arg this._rendererFactory.callUI(fnName,[this.asFnArg,...fnArgs]); }
其函数体中的_rendererFactory成员变量是一个WebWorkerRendererFactory2@H_301_10@类,调用了callUI@H_301_10@方法处理DOM相关的操作函数,包含fnName(方法名)和fnArgns(参数),其中asFnArg是一个默认参数(FnArg类的一个实例),并指定了序列化的类型,因此会被存入RenderStore@H_301_10@,定义如下:
private asFnArg = new FnArg(this,SerializerTypes.RENDER_STORE_OBJECT);
那么callUI@H_301_10@方法是怎么处理的呢?我们来看一下:
callUI(fnName: string,fnArgs: FnArg[]) { const args = new UiArguments(fnName,fnArgs); this._messageBroker.runOnService(args,null); }
从函数体中,可以看出调用了ClientMessageBroker@H_301_10@的runOnService方法,通过该方法向UI线程发送渲染指令(通过Sink的emit方法)并处理反馈信息,这里先做个简单的介绍,后续会详细介绍。
小小地总结下,WebWorkerRenderer2@H_301_10@类定义了在WebWorker线程中模拟操作DOM节点的方法,并且发出指令向UI线程发送信息。
与WebWorkerRenderer2@H_301_10@类对应的是MessageBasedRenderer2@H_301_10@类,前者在WebWorker线程中工作,后者在UI线程中工作。同样的,是MessageBasedRenderer2@H_301_10@类中也定义了丰富的DOM操作方法(与WebWorkerRenderer2@H_301_10@类对应),这些方法才是真正意义上操作DOM的方法,通过调用Renderer2@H_301_10@中的相关方法。同时,DOM的事件触发后会通过MessageBus的Sink发送给WebWorker线程中的WebWorkerRendererFactory2@H_301_10@类做处理。
WebWorkerRenderer2类既然有个ClientMessageBroker@H_301_10@类来作中间代理人,负责传递信息,那么,MessageBasedRenderer2@H_301_10@类也需要一个代理人来接头,这就是ServiceMessageBrokerFactory@H_301_10@类。它负责注册WebWorkerRenderer2@H_301_10@类中DOM操作函数,并接收从ClientMessageBroker@H_301_10@传过来的渲染指令,然后触发对应的方法,执行结束后,在反馈给ClientMessageBroker@H_301_10@代理人(成功还是失败)。
枯燥无聊的先前知基本都说到了,接下来该干正事了。
统观全局
我们看图说话。
图中只介绍了两个通道的(RENDERER_2_CHANNEL@H_301_10@通道和EVENT_2_CHANNEL@H_301_10@通道)的通讯流程,还差一个ROUTER_CHANNEL@H_301_10@通道没有提及,其通过过程和RENDERER_2_CHANNEL@H_301_10@通道类似。
先来介绍一下初始化的部分(图中的蓝色部分),从左到右来介绍。首先左侧MessageBasedRenderer2@H_301_10@类初始化的时候创建ServiceMessageBroker@H_301_10@类型作为自己的通讯代理人,同时初始化两条通道,创建PostMessageBusSink@H_301_10@和Source为通讯做准备(其中事件通道中只用到了Sink),并对Source订阅事件。右侧的WebWorker线程中的初始化操作类似,用到的类不同而已。
在启动时(图中的黄色部分),MessageBasedRenderer2@H_301_10@会在start函数中调用registerMethod方法去向ServiceMessageBroker@H_301_10@注册DOM操作相关的方法,存储在_methods中,等待触发。
接下来,就是正式运行渲染环节了,避免错乱,更新下图,如下:
图中显示了3种颜色,代表了3个线程间通讯的过程,从绿色的开始说。
在WebWorker线程中,Angular引擎首先会根据页面布局拆分为细化的DOM节点操作,并执行渲染操作。通过callUI调用Broker中的runOnService方法,并存储在_pending容器(存的是什么东西?@H_301_10@)中,同时使用Sink向UI线程的Source发送消息,包含id、方法名和参数。UI线程的代理人接收到信息后,触发相应的订阅事件_handleMessage方法,该方法就去_mehtods中找MessageBassedRenderer2@H_301_10@在启动时候注册的对应方法并执行,具体过程就是调用Renderer2@H_301_10@中相应的DOM操作方法。
等DOM操作结束,就进入了蓝色标示的过程,其实是个反馈的过程。通过Sink向WebWorker线程发送消息,消息内容如下:
{ 'type': 'result','value': this._serializer.serialize(result,type),'id': id,}
其中type类型是‘result’(其实还可能是'error',本文未指出),WebWorker线程收到消息后,会触发在初始化时候定义的订阅事件,执行_handleMessage方法,操作_pengding容器,根据id获取对应条目执行(执行的是什么?@H_301_10@)并且删除,这样这个蓝色过程就结束了。
那么_pending容器里面存的是什么?执行的又是什么?从字面理解是应该是用于存储'待解决'的事务,这也回答了,怎么处理线程间并发@H_301_10@这个问题?在此解答一下,先上相关代码:
interface PromiseCompleter { resolve: (result: any) => void; reject: (err: any) => void; } // ... let completer: PromiseCompleter = undefined !; let promise = new Promise((resolve,reject) => { completer = {resolve,reject}; }); let id = this._generateMessageId(args.method); // 存储 this._pending.set(id,completer); // catch和then promise.catch((err) => {...}); promise = promise.then((v: any) => this._serializer ? this._serializer.deserialize(v,returnType) : v); // ... 反馈时 if (message.type === 'result') { this._pending.get(id) !.resolve(message.value); } else { this._pending.get(id) !.reject(message.value); } this._pending.delete(id); // ...
_pending容器里面存了id和与之对应的Promise对象的 {resolve,reject},并且预先定义好then方法(这里是做了反序列化操作,并没有其余操作),当WebWorker线程接收到type为'result' or 'error'的消息时,并对应执行resolve或者reject方法,以此释放Promise。相信你已经明白了,线程间并发问题就是用过Promise方法来完成同步。
最后来到紫色的过程,UI线程中DOM节点绑定的事件触发后,通过Sink通过事件通道向WebWorker线程的Source发送消息,WebWorker线程收到消息后,触发相应的订阅方法,这里不像渲染通道一样,有反馈过程。可能的原因时,与事件相关的方法(大部分是在对DOM节点操作),还是通过渲染通道(通过绿色和蓝色的过程)通知给UI线程。
这样整个WebWoker Renderer的线程间通讯的部分就介绍完毕了。
回顾下一开始提出的三个问题:
- 通讯信息如何序列化与反序列化?内存数据如何共享? 答:通过RenderStore@H_301_10@类。
- 如何打破Webworker线程不能操作DOM节点的局限? 答:通过RENDERER_2_CHANNEL@H_301_10@通道。
- 如何处理并发?答:通过操作反馈与Promise@H_301_10@机制。
还没完
我猜你一定想知道Angular中是怎么启动WebWorker线程并执行渲染操作?如何开启UI线程中的start方法?来来来,慢慢絮叨。
我们从如何将传统的Angular项目(基于platformBrowserDynamic@H_301_10@的JIT项目或者基于platformBrowser@H_301_10@的AOT项目)转换成基于platformWorkerAppDynamic@H_301_10@的WebWorker项目,可以参考本文一开始提供的DEMO项目或者参考文章《Angular with Web Workers: Step by step》。基于现有的WebWorker项目,我们来讲解一下,启动过程。
首先会调用@angular/platform-webworker@H_301_10@中的bootstrapWorkerUi@H_301_10@方法启动一个WebWorkerLoader,传入的是一个WebPack打包输出的webworker.bundle.js(可在webpack.config.js输出),基于的文件就是一个platformWorkerAppDynamic@H_301_10@的启动文件,其余的配置与传统项无异,由此可见改动成本还是比较小的。
主要还是来看一下bootstrapWorkerUi@H_301_10@方法做了些什么?
export function bootstrapWorkerUi( workerScriptUri: string,customProviders: Provider[] = []): Promise<PlatformRef> { // For now,just creates the worker ui platform... const platform = platformWorkerUi([ {provide: WORKER_SCRIPT,useValue: workerScriptUri},...customProviders,]); return Promise.resolve(platform); }
从代码中看出主要是创建一个platformWorkerUi@H_301_10@对象,讲loader文件地址传入。
这么关键的一个platformWorkerUi@H_301_10@我们简单来将想,该对象通过createPlatformFactory@H_301_10@(Angular/core中的方法)创建,并传入一组Provider,包括MessageBasedRenderer2@H_301_10@,Serializer@H_301_10@,RenderStore@H_301_10@,MessageBus@H_301_10@等之前介绍过的注入类,
还有一个关键的WebWorkerInstance@H_301_10@,申明如下:
@Injectable() export class WebWorkerInstance { public worker: Worker; public bus: MessageBus; /** @internal */ public init(worker: Worker,bus: MessageBus) { this.worker = worker; this.bus = bus; } }
作为WebWorker的一个实例,包含Woker@H_301_10@对象的实例,和MessageBus@H_301_10@的实例,那么什么时候调用的init方法初始化呢?接着往下看,
Provider中还有一个关键init时需要的注入类,描述如下:
{ provide: PLATFORM_INITIALIZER,useFactory: initWebWorkerRenderPlatform,multi: true,deps: [Injector] }
里面使用了initWebWorkerRenderPlatform@H_301_10@方法,提取梳理出关键的步骤:
const webWorker: Worker = new Worker(url); const sink = new PostMessageBusSink(webWorker); const source = new PostMessageBusSource(webWorker); const bus = new PostMessageBus(sink,source); WebWorkerInstance.init(webWorker,bus); // initialize message services after the bus has been created const services = injector.get(WORKER_UI_STARTABLE_MESSAGING_SERVICE); // 这里的 WORKER_UI_STARTABLE_MESSAGING_SERVICE 在应用中归根到底其实就是调用的MessageBasedRenderer2类 zone.runGuarded(() => { services.forEach((svc: any) => { svc.start(); }); });
根据url路径创建Worder对象,该对应用于PostMessageBusSink@H_301_10@和PostMessageBusSource@H_301_10@对象初始化,比如在PostMessageBusSource@H_301_10@初始化中会对Worker对象addEventListener监听'message'事件。然后使用sink和source实例化PostMessageBus@H_301_10@类,再调用WebWorkerInstance@H_301_10@对象的init方法。最后,将注入的MessageBasedRenderer2@H_301_10@类自动调用start方法。
总结
说一下自己的感受,不要为了用WebWorker线程而用,还是要集合多方面因素来考虑,比如线程间通讯时间,开启线程的性能消耗等,毕竟WebWorker提出的初衷是为了那些计算密集型的操作,被Angular框架使用到渲染中,是一个有突破的创新,但目前并不能支持所有项目的转换,还不稳定(@experimental),请谨慎使用。但相信随着浏览器的发展,为了极致化用户体验,WebWorker的渲染势必会被各大主流前端框架考虑在内。
至此,Angular WebWorker Renderer的前前后后的源码解析就解密完了,肯定有诸多解析不到位的地方,欢迎留言吐槽。
知乎@charway
参考
Angular Platform-Webworker 源码
Angular Web Worker - Building Super Responsive UI
Using Web Workers for more responsive apps
Angular with Web Workers: Step by step