小程序没有 DOM 接口，原因竟然是……？-杭州网站建设制作网站优化为你转播

翻了一圈文档，小程序好像并不提供 DOM 接口？我还以为可以像之前一样用我喜欢的前端框架来做开发呢。老李，你说小程序为什么不给我们提供 DOM 接口呀？

要提供 DOM 接口也没那么容易。你知道小程序的双线程模型吗？小程序是基于 Web 技术的，这你应该知道，但小程序和普通的移动端网页也不一样。你做了很多前端项目了，应该知道在浏览器里，UI 渲染和 JavaScript 逻辑都是在一个线程中执行的？

这我知道，在同一个线程中，UI 渲染和 JavaScript 逻辑交替执行，JavaScript 也可以通过 DOM 接口来对渲染进行控制

小程序使用的是一种两个线程并行执行的模式，叫做 双线程模型 。像我下图画的这样，两个线程合力完成小程序的渲染：一个线程专门负责渲染工作，我们一般称之为渲染层；而另外有一个线程执行我们的逻辑代码，我们一般叫做逻辑层。这两个线程同时运行，并通过微信客户端来交换数据。在小程序运行的时候，逻辑层执行我们编写的逻辑，将数据通过 setData 发送到渲染层；而渲染层解析我们的 WXML 和 WXSS，并结合数据渲染出页面。一方面，每个页面对应一个 WebView 渲染层，对于用户来说更加有页面的感觉，体验更好，而且也可以避免单个 WebView 的负担太重；另一方面，将小程序代码运行在独立的线程中的模式有更好的安全表现，允许有像 open-data 这样的组件可以在确保用户隐私的前提下让我们展示用户数据

怪不得所有和页面有关的改动都只能通过 setData 来完成。但是用两个线程来渲染我们平时用单线程来渲染的 Web 页面，会不会有些「浪费」？而且每一个页面有一个对应的渲染层，那页面变多的时候，岂不是会有很大的开销？

并不浪费，因为界面的渲染和后台的逻辑处理可以在同一时间运行了，这使得小程序整体的响应速度更快了。而在小程序的运行过程中，逻辑层需要常驻，但渲染层是可以回收的。实际上，当页面栈的层数比较高的时候，栈底页面的渲染层是会被慢慢回收的

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

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

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

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

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

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

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

小程序还有这样的功能，受教了。不过说来说去，我还是想在小程序里用我顺手的框架来开发，毕竟这样事半功倍嘛。我在网上搜索了一下，发现现在有很多支持用 Web 框架做小程序开发的框架，但好像都是将模板编译成 WXML，最终由小程序来做渲染，但这样的方法好像兼容性也不是很好。我在想，我们能不能在逻辑层仿造一套 DOM 接口，然后在运行时将 DOM 调用适配成小程序调用？

你的这个脑洞有一些意思。在逻辑层仿造一套 DOM 接口，直接维护一棵 DOM 树，这当然没问题。但是没有代理 DOM 接口，逻辑层的 DOM 树没法反映到渲染层，因为渲染层具体会出现什么样的组件，是运行时才能知道的，这不就没法生成静态模板了？

静态模板确实是没法生成了，但我看到小程序的框架支持自定义组件，我是不是可以做一个通用的自定义组件，让它根据传入的参数不同，变成不同的小程序内置组件。而且自定义组件还支持在自己的模板中引用自己，那么我只需要一个这个通用组件，然后从逻辑层用代码去控制当前组件应该渲染成什么内置组件，再根据它是否有子节点去递归引用自己进行渲染就可以了。你看这样可行吗？

这样的做法确实可行，而且微信官方已经按照这个思路推出小程序和 Web 端同构的解决方案 Kbone 了。Kbone 的原理就像你刚才说的那样，它提供一个 Webpack 插件，将项目编译成小程序项目；同时提供两个 npm 包，分别提供 DOM 接口模拟和你说的那个通用的自定义组件作为运行时依赖。要不你赶紧试试？

还有这么好的事，那我终于可以用我喜欢的框架开发小程序了！这么好的框架，为什么不直接内置到小程序的基础库里呀？

因为这样的功能完全可以用现在已有的基础库功能实现出来呀。Kbone 现在是 npm 包的形式，使得它的功能、问题修复可以随着自己的版本来发布，不需要依赖于基础库的更新和覆盖率，不是挺好的吗？

好是好，但我担心的是代码包大小限制的问题。除了我们已经写好的业务逻辑之外，现在还得加上 Kbone，会不会装不下呀？

原来你是担心这个呀，放心，Kbone 现在已经可以在 扩展库 里一键搞定啦。扩展库是帮我们解决依赖的全新功能，只要在配置项中指定 Kbone 扩展库，就相当于引入了 Kbone 相关的最新版本的 npm 包，这样就不占用小程序的代码包体积了，快试试吧！

哇，那可太爽了，马上就搞起！

如果使用Kbone的过程中遇到问题，还可以到PC端 Kbone社区主页 发帖交流，上面这个框架的官方开发人员会和大家一起互动哦！