258资源分享网

作为微信小程序底层 API 维护者之一，经历了风风雨雨、各种各样的吐槽。为了让大家能更好的写一手小程序，特地梳理一篇文章介绍。如果有什么吐槽的地方，欢迎去 https://developers.weixin.qq.... 开发者社区吐槽。

PS: 老板要找人，对自己有实力的前端er，可以直接发简历到我的邮箱: villainthr@gmail.com

为了大家能更好的开发出一些高质量、高性能的小程序，这里带大家理解一下小程序在不同端上架构体系的区分，更好的让大家理解小程序一些特有的代码写作方式。

整个小程序开发生态主要可以分为两部分：

桌面 nwjs 的 微信开发者工具 （PC 端）

移动 APP 的正式运行环境

一开始的考虑是使用双线程模型来解决安全和可控性问题。不过，随着开发的复杂度提升，原有的双线程通信耗时对于一些高性能的小程序来说，变得有些不可接受。也就是每次更新 UI 都是通过 webview 来手动调用 API 实现更新。原始的基础架构，可以参考官方图：

不过上面那张图其实有点误导行为，因为，webview 渲染执行在手机端上其实是内核来操作的，webview 只是内核暴露的一下 DOM/BOM 接口而已。所以，这里就有一个性能突破点就是，JSCore 能否通过 Native 层直接拿到内核的相关接口？答案是可以的，所以上面那种图其实可以简单的再进行一下相关划分，新的如图所示:

简单来说就是，内核改改，然后将规范的 webview 接口，选择性的抽一份给 JsCore 调用。但是，有个限制是 Android 端比较自由，通过 V8 提供 plugin 机制可以这么做，而 IOS 上，苹果爸爸是不允许的，除非你用的是 IOS 原生组件，这样的话就会扯到同层渲染这个逻辑。其实他们的底层内容都是一致的。

后面为了大家能更好理解在小程序具体开发过程中，手机端调试和在开发者工具调试的大致区分，下面我们来分析一下两者各自的执行逻辑。

开发者工具 通信体系 (只能采用双向通信) 即，所有指令都是通过 appservice <=> nwjs 中间层 <=> webview

Native 端运行的通信体系：

小程序基础通信：双向通信-- ( core <=> webview <=> intermedia <=> appservice )

高阶组件通信：单向通信体系 ( appservice <= android/Swift => core)

JSCore 具体执行 appservice 的逻辑内容

一开始考虑到安全可控的原因使用的是双线程模型，简单来说你的所有 JS 执行都是在 JSCore 中完成的，无论是绑定的事件、属性、DOM操作等，都是。

开发者工具，主要是运行在 PC 端，它内部是使用 nwjs 来做，不过为了更好的理解，这里，直接按照 nwjs 的大致技术来讲。开发者工具使用的架构是 基于 nwjs 来管理一个 webviewPool，通过 webviewPool 中，实现 appservice_webview 和 content_webview。

所以在小程序上的一些性能难点，开发者工具上并不会构成很大的问题。比如说，不会有 canvas 元素上不能放置 div，video 元素不能设置自定义控件等。整个架构如图：

当你打开开发者工具时，你第一眼看见的其实是 appservice_webview 中的 Console 内容。

content_webview 对外其实没必要暴露出来，因为里面执行的小程序底层的基础库和 开发者实际写的代码关系不大。大家理解的话，可以就把显示的 WXML 假想为 content_webview。

当你在实际预览页面执行逻辑时，都是通过 content_webview 把对应触发的信令事件传递给 service_webview。因为是双线程通信，这里只要涉及到 DOM 事件处理或者其他数据通信的都是异步的，这点在写代码的时候，其实非常重要。

如果在开发时，需要什么困难，欢迎联系： 开发者专区 | 微信开放社区

前面简单了解了开发者工具上，小程序模拟的架构。而实际运行到手机上，里面的架构设计可能又会有所不同。主要的原因有：

IOS 和 Android 对于 webview 的渲染逻辑不同

手机上性能瓶颈，JS 原始不适合高性能计算

video 等特殊元素上不能被其他 div 覆盖