为什么小程序不提供 DOM 接口

浏览器的线程模型

我们知道浏览器内核是多线程的

• GUI 渲染线程
• JavaScript引擎线程
• 定时触发器线程
• 事件触发线程
• 异步http请求线程

其中 GUI 渲染线程和 JavaScript 引擎线程是交替执行的，JavaScript 也可以通过 DOM 接口来对视图进行控制。

这么样的结构还导致了 JS 就被设计成为了单线程的语言。因为若是多线程的话，那么操作 DOM，就会遇到麻烦。比如说一个修改节点，一个删除节点，DOM 视图先听谁的呢？解决这个问题就得上锁，但 JS 创立之初结构是比较简单的，为了避免语言变得复杂，而天然的使用了单线程。

小程序的双线程模型

回到小程序，小程序不同，它使用的是两个线程并行执行的模式，叫做双线程模型。

渲染和 JS 引擎这两个线程同时运行，并通过微信客户端来交换数据。

在小程序运行的时候，JS 层执行我们编写的逻辑，将数据通过 setData 发送到渲染层；而渲染层解析我们的 WXML 和 WXSS，并结合数据渲染出页面。

一方面，每个页面对应一个 WebView 渲染层，对于用户来说更加有页面的感觉，体验更好，而且也可以避免单个 WebView 的负担太重；另一方面，将小程序代码运行在独立的线程中的模式有更好的安全表现，允许有像 open-data 这样的组件可以在确保用户隐私的前提下让我们展示用户数据。

所以这就是为什么和页面有关的改动都只能通过 setData 来完成，它天生不能操作真实的 DOM 结构。

性能问题

问：用两个线程来渲染平时用单线程来渲染的 Web 页面，会不会有些「浪费」？而且每一个页面有一个对应的渲染层，那页面变多的时候，岂不是会有很大的开销？

答：不浪费。GUI 层和 JS 层可以并行处理，反而还会让小程序整体的响应速度更快了。并在小程序的运行过程中，逻辑层需要常驻，但渲染层是可以回收的。实际上，当页面栈的层数比较高的时候，栈底页面的渲染层是会被慢慢回收的。

那为什么不可代理 DOM 处理逻辑

问：实际的 DOM 树是存在于渲染层的，逻辑层并不存在，所以逻辑层才没有任何的 DOM 接口。但是既然可以实现像 setData 这样的接口，为什么不能直接把 DOM 接口也代理到逻辑层呢？我觉得小程序可以做一个封装，让我们在逻辑层调用 DOM 接口，在渲染层调用接口后再把结果返回给我们呀。

答：从理论上来说确实是可以的。但是线程之间的通信是需要时间的呀。将调用发送到渲染层，再将 DOM 调用结果发送回来，这中间由于线程通信发生的时间损耗可能会比这个接口本身需要的时间要多得多。如果以此为基础使用基于 DOM 接口的前端框架，大量的 DOM 调用可能会非常缓慢，让这个设计失去意义。

在实际测试中，如果每次 DOM 调用都进行一次线程通信，耗时大约是同等节点规模直接在渲染层调用的百倍以上；如果忽略通信需要的时间，一个实现良好的基于 DOM 代理的框架可以近似地看成一个动态模板的框架，而动态模板和静态模板相比要慢至少 50%

双线程间通信耗时问题

问：原来如此，线程通信的时间确实是我没有考虑到的问题。那现在的小程序框架中难道不存在这个问题吗？

答：在现在的小程序框架中，这个问题也是存在的，这也是现在的框架基于静态模板渲染的原因。静态模板可以在运行前就做好打包，直接注入到渲染层，省去线程传输的时间。在运行时，逻辑层只和渲染层进行最少的、必要的数据交换：也就是渲染用的数据，或者说 data 。另一方面，静态模板让两个线程都在启动时就拥有模板相关的所有数据，所以框架也充分利用了这一点，进行了很多优化。

像对象里或者数组里的数据怎么办呢

问：怪不得我在文档里发现很多和 setData 有关的性能提示，都提醒尽量减少设置不必要的数据，现在总算是知道为什么了。但是具体到实际开发里的时候，还是总觉得很难每次只设置需要的数据啊，像对象里或者数组里的数据怎么办呢？

答：如果只改变了对象里或者数组里的一部分数据，可以通过类似 array[2].message , a.b.c.d 这样的 数据路径 来进行「精准设置」。另外，现在自定义组件也支持 纯数据字段 了，只要在自定义组件的选项中设置好名为 pureDataPattern 的正则表达式， data 中匹配这个正则的字段将成为纯数据字段，例如，你可以用 /^_/ 来指定所有 开头的数据字段为纯数据字段。所有纯数据字段仅仅被记录在逻辑层的 this.data 中，而不会被发送到渲染层，也不参与任何界面渲染过程，节省了传输的时间，这样有助于提升页面更新性能。