什么是 Sourcemaps uglifyjs、bable 等工具会对 源代码 进行编译处理生成编译后的代码（下称目标代码），而 sourcemaps 就是保留了目标代码在源代码中的 位置信息 --------- 大神分割线 --------- 如何解读 Sourcemaps Sourcemaps 是一个 json [代码]{ "version": 3, "sources": ["a.js", "b.js"], // 源文件列表，这个表示是由 a.js 和 b.js 合并生成 "names": ["myFn", "test"], // 如果开启了变量名混淆，这里会保留变量名在源文件中名字信息 "sourcesContent: [], // 可选项，保存源码信息，顺序与 sources 字段对应，chrome 的 sources 面板中源码使用了这个字段的内容进行展示 "sourceRoot": "", // 源文件所在的目录信息 "file": "dist.js", // 可选，编译后的文件名 "mappings": "" // 这个是重点，是目标代码和源文件的位置的映射关系 } [代码] mappings 目标文件"行"的信息 mappings 是使用 ; 分隔的，每个部分对应目标代码的行 如: “;AAAA;AAAA,BBBB;;” 本例子目标文件有 4 行 第 0 行和第 3 行没有源文件对应信息，所以这两行是编译过程中加入的代码 目标文件的"列"信息 如: “AAAA,CAEA,CAEA;” ‘,’ 表示行内的位置信息分隔符 本例表示目标文件的这一行有三个有效的位置信息。 位置信息的第一位表示目标文件的列的 偏移 信息 本例中，表示列的信息是 ‘A’、‘C’、‘C’，对应的数字为 0、+1、+1，(vlq 编码，在线编解码工具） 注意，这个是偏移信息； 列数从 0 开始，依次累加偏移值可以算出当前的位置信息对应的真正的列 所以本例中表示的是目标文件的第 n 行中的第 0 列，第 1 列，第 2 列（没错是第 2 列） 源文件的信息 如：‘AAAA;ACAA;ADAA;’ 位置信息的第二位表示源文件的信息，本例子中是 ‘A’、‘C’、‘D’，对应数字是 0、+1、-1 如果 sourcemaps 中的 sources 字段只有一个文件的话，那么位置信息中第二位一直是 A（不需要偏移） 假设 sourcemaps 中 sources: [‘a.js’, ‘b.js’] 本例的意思是 AAAA: 目标文件第 0 行第 0 列 对应 第 0 个文件 a.js ACAA; 目标文件第 1 行第 0 列 对应 第 1 个文件 b.js ADAA; 目标文件第 2 行第 0 列 对了 第 0 个文件 a.js (偏移是 -1 又回到了 a.js) 源文件的行信息 位置信息的第三位表示源文件中的行的信息, 理解了位置偏移的概念，我们很容易理解 如：‘AACA,CACA;AACA;‘ 那么 AACA: 目标文件的第 0 行第 0 列 对应 第 0 个文件的第 1 行 CACA: 目标文件的第 0 行第 0+1 列 对应 第 0 个文件的第 1+1 行 AACA：目标文件的第 1 行第 0 列 对应 第 0 个文件的第 1 行 (注意：’;’ 后的行列偏移信息归 0) 源文件中的列信息 位置信息的第四位表示源文件中的列的信息 如：'AAAA,CAAC;' 那么 AAAA: 目标文件的第 0 行第 0 列 对应 第 0 个文件的第 0 行第 0 列 CAAC: 目标文件的第 0 行第 0+1 列 对应 第 0 个文件的第 0 行第 0+1 列 位置信息的第五位 第五位表示变量的偏移，对应 sourcemaps 中的 names 字段，表示目标文件中的变量名对应域源文件中的变量 如：’AAAA,CAACC;AAAAD;' sourcemaps 中 names 字段是 [‘a’, ‘b’] 那么 AAAA: 目标文件的第 0 行第 0 列 对应 第 0 个文件的第 0 行第 0 列，没有变量的信息 CAACC: 目标文件的第 0 行第 0+1 列 对应 第 0 个文件的第 0 行第 0+1 列，有变量信息，变量在源文件中是 ‘b’ (0+1=1) AAAAD: 目标文件的第 1 行第 0 列 对应 第 0 个文件的第 0 行第 0 列，有变量信息，变量在源文件中是 ‘a’ (1-1=0) --------- 大神分割线 --------- 怎么使用 Sourcemaps Q: 线上小程序报错，我怎么通过 sourcemaps 还原到源代码中？ A: 如报错 appservice.js 1:15000, 表示目标文件第一行 第 15000 列位置报错。根据上文介绍的，通过 mappings 字段算。 Q: 不会。 A: 如果你会写代码的话，参考下边 [代码]import fs = require('fs') import {SourceMapConsumer} from 'source-map' async function originalPositionFor(line, column) { const sourceMapFilePath = '如果你不真的替换的成 sourcemaps 在硬盘中的位置，那你还是放弃自己写代码吧。 ' const sourceMapConsumer = await new SourceMapConsumer(JSON.parse(fs.readFileSync(sourceMapFilePath, 'utf8'))) return sourceMapConsumer.originalPositionFor({ line, column, }) } originalPositionFor(出错的行，出错的列) [代码] Q: 不会写代码 A: 下载最新版的开发者工具，菜单-设置-拓展设置-调试器插件 [图片] [图片] Q: 为啥都是 null？ A: 每个小程序版本都应该对应一个sourcemap文件。 运营中心那里下载的 sourcemap 是对应线上最新的小程序版本。但运营中心的报错集合了多个小程序版本。拿旧小程序版本的报错信息，和最新版本的 sourcemap，是匹配不出的。开发者工具和ci 上传的时候，会提示下载对应版本的 sourcemap 信息，可以自助保存。 [图片] Q: 怎么确定有没有版本对应上 A: 下载的 sourcemap 中有个 wx 字段，标明了该 sourcemap 文件对应小程序版本号。 [图片] [图片] 前提 1.确保发生错误的小程序版本和下载回来的 sourcemap 版本是一致的。 a. 下载 sourceMap 文件，可在 mp 后台或开发者工具上传成功弹窗下载 2.确保 map 文件和发生错误的 js 文件是对应的。sourcemap 的目录和文件说明 a. APP 是主包，FULL 是整包（仅在不支持分包的低版本微信中使用），其他目录是分包 b. 每个分包下都有对应的 app-service.js.map 文件。 c. 如果是使用了按需注入特性（app.json中配置了lazyCodeLoading），那么每个分包下还会有 appservice.app.js.map（对应分包下非页面的js），和所有页面的 xxx.js.map 以上事情都确保正确之后，还是出现行列号匹配不出来的情况。那就需要进一步排查。 线上运行的小程序 sourcemap 文件是怎么生成的？ 处理流程：源码 [ a.js a.js.map b.js b.js.map ] -> 开发者工具（JS转 ES5，压缩）-> 微信后台（合并 js 文件）[ appservice.app.js appservice.app.js.map]。 注意：如果源码在交给工具之前是经过了 webpack 等打包工具的处理，那源码这里需要有 map 文件。否则不需要存在 map 文件。 可以看出，map 文件经过三个步骤的处理，每个步骤都有可能导致出错，因此开发者需要先排查，是否是前两个步骤出错导致的 map 文件失效的。 如何排查前两个步骤产生的 map 文件是否有问题。 1.排查 a.js.map 文件是否有问题。 a. 可以在 a.js 的代码中写一下 throw new Error(‘test sourcemap’)。 b. 使用了 webpack 的情况下，要构建为生产环境的版本。 c. 在开发者工具模拟器中运行对应的页面，看看控制台中的报错，错误行列号是否能正常映射到源文件。 2.排查 开发者工具（JS转 ES5，压缩）步骤是否有问题。 在排查完第一步的基础上，点击预览，用微信上扫码预览，并打开调试 vConsole 功能，检查 vConsole 中是否有报错信息，检查报错信息中的行列号是否能正常映射到源文件。 如何排查 微信后台（合并 js 文件）是否有问题。 a. 一定要先排查完前两个步骤再来排查这一步，一般情况下，这一步是不会出错的。 b. 如果有问题，也只会导致 map 文件中的行号信息出现偏移。比如 Error 信息中显示报错地址是 100: 200，行号是 100。那么你可能直接用 100: 200 在 map 文件中搜索不出信息，但是如果 用 150: 200 就可以搜索出来，说明行号偏移了 50。那其他报错也可以偏移 50 后再进行搜索就找到结果。 c. 怎么排查偏移了多少？可以结合 error.message 的内容，初步判断大概错误的内容是什么。把对应的 map 文件放到这个网站上 source-map-visualization 进行搜索，找出哪些相同列号的地方。再结合 error.message 的内容进行判断。 d. 如果排查到是这一步导致的问题，请在社区上联系我们，我们会在后续版本进行修复。 依旧排查不出原因？ 先整理一下按照上述步骤排查的结论，再在社区上联系我们协助

1.背景 如今信息流业务是各大互联网公司争先抢占的一个大面包，为了提高用户的后续消费，产品想出了各种各样的方法，例如在微视中，用户可以无限上拉出下一条视频；在知乎中，也可以无限上拉出下一条回答。这样的操作方式用户体验更好，后续消费也更多。最近几年的时间，微信小程序已经从一颗小小的萌芽成长为参天大树，形成了较大规模的生态，小程序也拥有了一个很大的流量入口。 2.demo体验 那如何才能在小程序中实现类原生APP效果的下一条无限刷体验？ 这篇文章详细记录了下一条无限刷效果的实现原理，以及细节和体验优化，并将相关代码抽象成一个微信小程序代码片段，有需要的同学可查看demo源码。 线上效果请用微信扫码体验： [图片] 小程序demo体验请点击：https://developers.weixin.qq.com/s/vIfPUomP7f9a 3.实现原理 出于性能和兼容性考虑，我们尽量采用小程序官方提供的原生组件来实现下一条无限刷效果。我们发现，可以将无限上拉下一篇的文章看作一个竖向滚动的轮播图，又由于每一篇文章的内容长度高于一屏幕高度，所以需要实现文章内部可滚动，以及文章之间可以上拉和下拉切换的功能。 在多次尝试后，我们最终采用了在[代码]<swiper>[代码]组件内部嵌套一个[代码]<scroll-view>[代码]组件的方式实现，利用[代码]<swiper>[代码]组件来实现文章之间上拉和下拉切换的功能，利用[代码]<scroll-view>[代码]来实现一篇文章内部可上下滚动的功能。 所以页面的dom结构如下所示： [代码]<swiper class='scroll-swiper' circular="{{false}}" vertical="{{true}}" bindchange="bindChange" skip-hidden-item-layout="{{true}}" duration="{{500}}" easing-function="easeInCubic" > <block wx:for="{{articleData}}"> <swiper-item> <scroll-view scroll-top="0" scroll-with-animation="{{false}}" scroll-y > content </scroll-view> </swiper-item> </block> </swiper> [代码] 4.性能优化 我们知道view部分是运行在webview上的，所以前端领域的大多数优化方式都有用。例如减少代码包体积，使用分包，渲染性能优化等。下面主要讲一下渲染性能优化。 4.1 dom优化 由于页面需要无限上拉刷新，所以要在[代码]<swiper>[代码]组件中不断的增加[代码]<swiper-item>[代码]，这样必然会导致页面的dom节点成倍数的增加，最后非常卡顿。 为了优化页面的dom节点，我们利用[代码]<swiper>[代码]的[代码]current[代码]和[代码]<swiper-item>[代码]的[代码]index[代码]来做优化，控制是否渲染dom节点。首先，仅当[代码]index <= current + 1[代码]时渲染[代码]<swiper-item>[代码]，也就是页面中最多预先加载出下一条，而不是将接口返回的所有后续数据都渲染出来；其次，对于用户已经消费过的之前的[代码]<swiper-item>[代码]，不能直接销毁dom节点，否则会导致[代码]<swiper>[代码]的[代码]current[代码]值出现错乱，但是我们可以控制是否渲染[代码]<swiper-item>[代码]内部的子节点，我们设置了仅当[代码]current <= index + 1 && index -1 <= current[代码]时才会渲染[代码]<swiper-item>[代码]中的内容，也就是仅渲染当先文章，及上一篇和下一篇的文章内容，其他文章的dom节点都被销毁了。 这样，无论用户上拉刷新了多少次，页面中最多只会渲染3篇文章的内容，避免了因为上拉次数太多导致的页面卡顿。 4.2 分页时setData的优化 setData工作原理 [图片] 小程序的视图层目前使用[代码]WebView[代码]作为渲染载体，而逻辑层是由独立的 [代码]JavascriptCore[代码] 作为运行环境。在架构上，[代码]WebView[代码] 和 [代码]JavascriptCore[代码] 都是独立的模块，并不具备数据直接共享的通道。当前，视图层和逻辑层的数据传输，实际上通过两边提供的 [代码]evaluateJavascript[代码] 所实现。即用户传输的数据，需要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份 [代码]JS[代码] 脚本，再通过执行 [代码]JS[代码] 脚本的形式传递到两边独立环境。 而 [代码]evaluateJavascript[代码] 的执行会受很多方面的影响，数据到达视图层并不是实时的。 每次 [代码]setData[代码] 的调用都是一次进程间通信过程，通信开销与 setData 的数据量正相关。 [代码]setData[代码] 会引发视图层页面内容的更新，这一耗时操作一定时间中会阻塞用户交互。 [代码]setData[代码] 是小程序开发中使用最频繁的接口，也是最容易引发性能问题的接口。 避免不当使用setData [代码]data[代码] 应仅包括与页面渲染相关的数据，其他数据可绑定在this上。使用 [代码]data[代码] 在方法间共享数据，会增加 setData 传输的数据量，。 使用 [代码]setData[代码] 传输大量数据，通讯耗时与数据正相关，页面更新延迟可能造成页面更新开销增加。仅传输页面中发生变化的数据，使用 [代码]setData[代码] 的特殊 [代码]key[代码] 实现局部更新。 避免不必要的 [代码]setData[代码]，避免短时间内频繁调用 [代码]setData[代码]，对连续的setData调用进行合并。不然会导致操作卡顿，交互延迟，阻塞通信，页面渲染延迟。 避免在后台页面进行 [代码]setData[代码]，这样会抢占前台页面的渲染资源。可将页面切入后台后的[代码]setData[代码]调用延迟到页面重新展示时执行。 优化示例 无限上拉刷新的数据会采用分页接口的形式，分多次请求回来。在使用分页接口拉取到下一刷的数据后，我们需要调用[代码]setData[代码]将数据写进[代码]data[代码]的[代码]articleData[代码]中，这个[代码]articleData[代码]是一个数组，里面存放着所有的文章数据，数据量十分庞大，如果直接[代码]setData[代码]会增加通讯耗时和页面更新开销，导致操作卡顿，交互延迟。 为了避免这个问题，我们将[代码]articleData[代码]改进为一个二维数组，每一次[代码]setData[代码]通过分页的 [代码]cachedCount[代码]标识来实现局部更新，具体代码如下： [代码]this.setData({ [`articleData[${cachedCount}]`]: [...data], cachedCount: cachedCount + 1, }) [代码] [代码]articleData[代码]的结构如下： [图片] 4.3 体验优化 解决了操作卡顿，交互延迟等问题，我们还需要对动画和交互的体验进行优化，以达到类原生APP效果的体验。 在文章间上拉切换时，我们使用了[代码]<swiper>[代码]组件自带的动画效果，并通过设置[代码]duration[代码]和[代码]easing-function[代码]来优化滚动细节和动画。 当用户阅读文章到底部时，会提示下一篇文章的标题等信息，而在页面上拉时，由于下一篇文章的内容已经加载出来了，这样在滑动过程中会出现两个重复的标题。为了避免这种情况出现，我们通过一个占满屏幕宽高的空白[代码]<view>[代码]来将下一篇文章的内容撑出屏幕，并在滚动结束时，通过[代码]hidden="{{index !== current && index !== current + 1}}"[代码]来隐藏这个空白[代码]<view>[代码]，并对这个空白[代码]<view>[代码]的高度变化增加动画，来实现下一篇文章从屏幕底部滚动到屏幕顶部的效果： [代码].fake-scroll { height: 100%; width: 100%; transition: height 0.3s cubic-bezier(0.167,0.167,0.4,1); } [代码] [图片] 而当用户想要上拉查看之前阅读过的文章时，我们需要给用户一个“下滑查看上一条”提示，所以也可以采用同上的方式，通过一个占满屏幕宽高的提示语[代码]<view>[代码]来将上一篇文章的内容撑出屏幕，并在滚动结束时，通过[代码]wx:if="{{index + 1 === current}}"[代码]来隐藏这个提示语[代码]<view>[代码]，并对这个提示语[代码]<view>[代码]的透明度变化增加动画，来实现下拉时提示“下滑查看上一条”的效果： [代码].fake-previous { height: 100%; width: 100%; opacity: 0; transition: opacity 1s ease-in; } .fake-previous.show-fake-previous { opacity: 1; } [代码] 至此，这个类原生APP效果的下一条无限刷体验的需求的所有要点和细节都已实现。 记录在此，欢迎交流和讨论。 小程序demo体验请点击：https://developers.weixin.qq.com/s/vIfPUomP7f9a

我们知道小程序的wx.request网络接口只支持HTTPS协议（文档-小程序网络说明），为什么HTTPS协议就比HTTP安全呢？一次安全可靠的通信应该包含什么东西呢，这篇文章我会尝试讲清楚这些细节。 Alice与Bob的通信 我们以Alice与Bob一次通信来贯穿全文，一开始他们都是用明文的形式在网络传输通信内容。 [图片] 嗅探以及篡改 如果在他们的通信链路出现了一个Hacker，由于通信内容都是明文可见，所以Hacker可以嗅探看到这些内容，也可以篡改这些内容。 [图片] 公众号的文章之前就遇到很多被挟持篡改了内容，插入广告。 [图片] 加密解密 既然明文有问题，那就需要对明文进行加密处理，让中间人看不懂内容，于是乎要对原来的内容变成一段看不懂的内容，称为加密，反之则是解密。而本质其实就是一种数学运算的逆运算，类似加法减法，例如发送方可以将 abcd…xyz 每个字母+1映射成 bcd…yza，使得原文的字母变成看不懂的序列，而接收方只需要将每个字母-1就可以恢复成原来的序列，当然这种做法规律太容易被破解了，后边会有个案例示意图。 [图片] 对称加密 如果对2个二进制数A和B进行异或运算得到结果C, 那C和B再异或一次就会回到A，所以异或也可以作为加密解密的运算。 [图片] 把操作数A作为明文，操作数B作为密钥，结果C作为密文。可以看到加密解密运用同一个密钥B，把这种加解密都用同一个密钥的方式叫做对称加密。 [图片] 可以看到简单的异或加密/解密操作，需要密钥跟明文位数相同。为了克服这个缺点，需要改进一下，把明文进行分组，每组长度跟密钥一致，分别做异或操作就可以得到密文分片，再合并到一起就得到密文了。 [图片] 但是这种简单分组的模式也是很容易发现规律，可以从下图看到，中间采用对原图进行DES的ECB模式加密（就是上边提到简单分组的模式） [图片] 很明显，原图一些特征在加密后还是暴露无遗，因此需要再改进一把。一般的思路就是将上次分组运算的结果/中间结果参与到下次分组的运算中去，使得更随机混乱，更难破解。以下图片来自维基百科： [图片] 经过改良后，Alice与Bob如果能提前拿到一个对称加密的密钥，他们就可以通过加密明文来保证他们说话内容不会被Hacker看到了。 [图片] 非对称加密 刚刚还引发另一个问题，这个对称加密用到的密钥怎么互相告知呢？如果在传输真正的数据之前，先把密钥传过去，那Hacker还是能嗅探到，那之后就了无秘密了。于是乎出现另外一种手段： [图片] 这就是非对称加密，任何人都可以通过拿到Bob公开的公钥对内容进行加密，然后只有Bob自己私有的钥匙才能解密还原出原来内容。 [图片] RSA就是这样一个算法，具体数学证明利用了大质数乘法难以分解、费马小定理等数学理论支撑它难以破解。相对于前边的对称加密来说，其需要做乘法模除等操作，性能效率比对称加密差很多。 [图片] 由于非对称加密的性能低，因此我们用它来先协商对称加密的密钥即可，后续真正通信的内容还是用对称加密的手段，提高整体的性能。 [图片] 认证 上边虽然解决了密钥配送的问题，但是中间人还是可以欺骗双方，只要在Alice像Bob要公钥的时候，Hacker把自己公钥给了Alice，而Alice是不知道这个事情的，以为一直都是Bob跟她在通信。 [图片] 要怎么证明现在传过来的公钥就是Bob给的呢？在危险的网络环境下，还是没有解决这个问题。 [图片] 一般我们现实生活是怎么证明Bob就是Bob呢？一般都是政府给我们每个人发一个身份证（假设身份证没法伪造），我只要看到Bob身份证，就证明Bob就是Bob。 网络也可以这么做，如果有个大家都信任的组织CA给每个人出证明，那Alice只要拿到这个证明，检查一下是不是CA制作的Bob证书就可以证明Bob是Bob。所以这个证书里边需要有两个重要的东西：Bob的公钥+CA做的数字签名。 [图片] 前边说到用公钥进行加密，只有拥有私钥的人才能解密。数字证书有点反过来：用私钥进行加密，用公钥进行解密。CA用自己的私钥对Bob的信息（包含Bob公钥）进行加密，由于Alice无条件信任CA，所以已经提前知道CA的公钥，当她收到Bob证书的时候，只要用CA的公钥对Bob证书内容进行解密，发现能否成功解开（还需要校验完整性），此时说明Bob就是Bob，那之后用证书里边的Bob公钥来走之前的流程，就解决了中间人欺骗这个问题了。 这种方式也是一种防抵赖的方式，让对方把消息做一个数字签名，只要我收到消息，用对方的公钥成功解开校验这个签名，说明这个消息必然是对方发给我的，对方不可以抵赖这个行为，因为只有他才拥有做数字签名的私钥。 [图片] CA其实是有多级关系，顶层有个根CA，只要他信任B，B信任C，C信任D，那我们基本就可以认为D是可信的。 [图片] 完整性 上边基本上已经解决了保密性和认证，还有一个完整性没有保障。虽然Hacker还是看不懂内容，但是Hacker可以随便篡改通信内容的几个bit位，此时Bob解密看到的可能是很乱的内容，但是他也不知道这个究竟是Alice真实发的内容，还是被别人偷偷改了的内容。 [图片] 单向Hash函数可以把输入变成一个定长的输出串，其特点就是无法从这个输出还原回输入内容，并且不同的输入几乎不可能产生相同的输出，即便你要特意去找也非常难找到这样的输入（抗碰撞性），因此Alice只要将明文内容做一个Hash运算得到一个Hash值，并一起加密传递过去给Bob。Hacker即便篡改了内容，Bob解密之后发现拿到的内容以及对应计算出来的Hash值与传递过来的不一致，说明这个包的完整性被破坏了。 [图片] 一次安全可靠的通信 总结一下，安全可靠的保障： 对称加密以及非对称加密来解决：保密性 数字签名：认证、不可抵赖 单向Hash算法：完整性 来一张完整的图： [图片]

本文大致需要 14m+ 的阅读时间。 简述小程序的通信体系 为了大家能更好的开发出一些高质量、高性能的小程序，这里带大家理解一下小程序在不同端上架构体系的区分，更好的让大家理解小程序一些特有的代码写作方式。 整个小程序开发生态主要可以分为两部分： 桌面 nwjs 的微信开发者工具（PC 端） 移动 APP 的正式运行环境 一开始的考虑是使用双线程模型来解决安全和可控性问题。不过，随着开发的复杂度提升，原有的双线程通信耗时对于一些高性能的小程序来说，变得有些不可接受。也就是每次更新 UI 都是通过 webview 来手动调用 API 实现更新。原始的基础架构，可以参考官方图： [图片] 不过上面那张图其实有点误导行为，因为，webview 渲染执行在手机端上其实是内核来操作的，webview 只是内核暴露的一下 DOM/BOM 接口而已。所以，这里就有一个性能突破点就是，JSCore 能否通过 Native 层直接拿到内核的相关接口？答案是可以的，所以上面那种图其实可以简单的再进行一下相关划分，新的如图所示: [图片] 简单来说就是，内核改改，然后将规范的 webview 接口，选择性的抽一份给 JsCore 调用。但是，有个限制是 Android 端比较自由，通过 V8 提供 plugin 机制可以这么做，而 IOS 上，苹果爸爸是不允许的，除非你用的是 IOS 原生组件，这样的话就会扯到同层渲染这个逻辑。其实他们的底层内容都是一致的。 后面为了大家能更好理解在小程序具体开发过程中，手机端调试和在开发者工具调试的大致区分，下面我们来分析一下两者各自的执行逻辑。 tl;dr 开发者工具 通信体系 (只能采用双向通信) 即，所有指令都是通过 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 协议分析 前面简单了解了开发者工具上，小程序模拟的架构。而实际运行到手机上，里面的架构设计可能又会有所不同。主要的原因有： IOS 和 Android 对于 webview 的渲染逻辑不同 手机上性能瓶颈，JS 原始不适合高性能计算 video 等特殊元素上不能被其他 div 覆盖 … 一开始做小程序的双线程架构和开发者工具比较类似，content_webview 控制页面渲染，appservice 在手机上使用 JSCore 来进行执行。它的默认架构图其实就是这个： [图片] 但是，随着用户量的满满增多，对小程序的期望也就越高： 小程序的性能是被狗吃了么？ 小程序打开速度能快一点么？ 小程序的包大小为什么这么小？ … 这些，我们都知道，所以都在慢慢一点一点的优化。考虑到原生 webview 的渲染性能很差，组内大神 rex 提出了使用同层渲染来解决性能问题。这个办法，不仅搞定了 video 上不能覆盖其他元素，也提高了一下组件渲染的性能。 开发者在手机上具体开发时，对于某些 高阶组件，像 video、canvas 之类的，需要注意它们的通信架构和上面的双线程通信来说，有了一些本质上的区别。为了性能，这里底层使用的是原生组件来进行渲染。这里的通信成本其实就回归到 native 和 appservice 的通信。 为了大家更好的理解 appservice 和 native 的关系，这里顺便简单介绍一下 JSCore 的相关执行方法。 JSCore 深入浅出 在 IOS 和 Android 上，都提供了 JSCore 这项工程技术，目的是为了独立运行 JS 代码，而且还提供了 JSCore 和 Native 通信的接口。这就意味着，通过 Native 调起一个 JSCore，可以很好的实现 Native 逻辑代码的日常变更，而不需要过分的依靠发版本来解决对应的问题，其实如果不是特别严谨，也可以直接说是一种 "热更新" 机制。 在 Android 和 IOS 平台都提供了各自运行的 JSCore，在国内大环境下运行的工程库为： Anroid: 国内平台较为分裂，不过由于其使用的都是 Google 的 Android 平台，所以，大部分都是基于 chromium 内核基础上，加上中间层来实现的。在腾讯内部通常使用的是 V8 JSCore。 IOS: 在 IOS 平台上，由于是一整个生态闭源，在使用时，只能是基于系统内嵌的 webkit 引擎来执行，提供 webkit-JavaScriptCore 来完成。 这里我们主要以具有官方文档的 webkit-JavaScriptCore 来进行讲解。 JSCore 核心基础 普遍意义上的 JSCore 执行架构可以分为三部分 JSVirtualMachine、JSContext、JSValue。由这三者构成了 JSCore 的执行内容。具体解释参考如下： JSVirtualMachine： 它通过实例化一个 VM 环境来执行 js 代码，如果你有多个 js 需要执行，就需要实例化多个 VM。并且需要注意这几个 VM 之间是不能相互交互的，因为容易出现 GC 问题。 JSContext: jsContext 是 js代码执行的上下文对象，相当于一个 webview 中的 window 对象。在同一个 VM 中，你可以传递不同的 Context。 JSValue: 和 WASM 类似，JsValue 主要就是为了解决 JS 数据类型和 swift 数据类型之间的相互映射。也就是说任何挂载在 jsContext 的内容都是 JSValue 类型，swift 在内部自动实现了和 JS 之间的类型转换。 大体内容可以参考这张架构图： [图片] 当然，除了正常的执行逻辑的上述是三个架构体外，还有提供接口协议的类架构。 JSExport: 它 是 JSCore 里面，用来暴露 native 接口的一个 protocol。简单来说，它会直接将 native 的相关属性和方法，直接转换成 prototype object 上的方法和属性。 简单执行 JS 脚本 使用 JSCore 可以在一个上下文环境中执行 JS 代码。首先你需要导入 JSCore: [代码]import JavaScriptCore //记得导入JavaScriptCore [代码] 然后利用 Context 挂载的 evaluateScript 方法，像 new Function(xxx) 一样传递字符串进行执行。 [代码]let contet:JSContext = JSContext() // 实例化 JSContext context.evaluateScript(&quot;function combine(firstName, lastName) { return firstName + lastName; }&quot;) let name = context.evaluateScript(&quot;combine(&#39;villain&#39;, &#39;hr&#39;)&quot;) print(name) //villainhr // 在 swift 中获取 JS 中定义的方法 let combine = context.objectForKeyedSubscript(&quot;combine&quot;) // 传入参数调用: // 因为 function 传入参数实际上就是一个 arguemnts[fake Array]，在 swift 中就需要写成 Array 的形式 let name2 = combine.callWithArguments([&quot;jimmy&quot;,&quot;tian&quot;]).toString() print(name2) // jimmytian [代码] 如果你想执行一个本地打进去 JS 文件的话，则需要在 swift 里面解析出 JS 文件的路径，并转换为 String 对象。这里可以直接使用 swift 提供的系统接口，Bundle 和 String 对象来对文件进行转换。 [代码]lazy var context: JSContext? = { let context = JSContext() // 1 guard let commonJSPath = Bundle.main.path(forResource: &quot;common&quot;, ofType: &quot;js&quot;) else { // 利用 Bundle 加载本地 js 文件内容 print(&quot;Unable to read resource files.&quot;) return nil } // 2 do { let common = try String(contentsOfFile: commonJSPath, encoding: String.Encoding.utf8) // 读取文件 _ = context?.evaluateScript(common) // 使用 evaluate 直接执行 JS 文件 } catch (let error) { print(&quot;Error while processing script file: \(error)&quot;) } return context }() [代码] JSExport 接口的暴露 JSExport 是 JSCore 里面，用来暴露 native 接口的一个 protocol，能够使 JS 代码直接调用 native 的接口。简单来说，它会直接将 native 的相关属性和方法，直接转换成 prototype object 上的方法和属性。 那在 JS 代码中，如何执行 Swift 的代码呢？最简单的方式是直接使用 JSExport 的方式来实现 class 的传递。通过 JSExport 生成的 class，实际上就是在 JSContext 里面传递一个全局变量（变量名和 swift 定义的一致）。这个全局变量其实就是一个原型 prototype。而 swift 其实就是通过 context?.setObject(xxx) API ，来给 JSContext 导入一个全局的 Object 接口对象。 那应该如何使用该 JSExport 协议呢？ 首先定义需要 export 的 protocol，比如，这里我们直接定义一个分享协议接口： [代码]@objc protocol WXShareProtocol: JSExport { // js调用App的微信分享功能 演示字典参数的使用 func wxShare(callback:(share)-&gt;Void) // setShareInfo func wxSetShareMsg(dict: [String: AnyObject]) // 调用系统的 alert 内容 func showAlert(title: String,msg:String) } [代码] 在 protocol 中定义的都是 public 方法，需要暴露给 JS 代码直接使用的，没有在 protocol 里面声明的都算是 私有 属性。接着我们定义一下具体 WXShareInface 的实现： [代码]@objc class WXShareInterface: NSObject, WXShareProtocol { weak var controller: UIViewController? weak var jsContext: JSContext? var shareObj:[String:AnyObject] func wxShare(_ succ:()-&gt;{}) { // 调起微信分享逻辑 //... // 成功分享回调 succ() } func setShareMsg(dict:[String:AnyObject]){ self.shareObj = [&quot;name&quot;:dict.name,&quot;msg&quot;:dict.msg] // ... } func showAlert(title: String, message: String) { let alert = AlertController(title: title, message: message, preferredStyle: .Alert) // 设置 alert 类型 alert.addAction(AlertAction(title: &quot;确定&quot;, style: .Default, handler: nil)) // 弹出消息 self.controller?.presentViewController(alert, animated: true, completion: nil) } // 当用户内容改变时，触发 JS 中的 userInfoChange 方法。 // 该方法是,swift 中私有的，不会保留给 JSExport func userChange(userInfo:[String:AnyObject]) { let jsHandlerFunc = self.jsContext?.objectForKeyedSubscript(&quot;\(userInfoChange)&quot;) let dict = [&quot;name&quot;: userInfo.name, &quot;age&quot;: userInfo.age] jsHandlerFunc?.callWithArguments([dict]) } } [代码] 类是已经定义好了，但是我们需要将当前的类和 JSContext 进行绑定。具体步骤是将当前的 Class 转换为 Object 类型注入到 JSContext 中。 [代码]lazy var context: JSContext? = { let context = JSContext() let shareModel = WXShareInterface() do { // 注入 WXShare Class 对象，之后在 JSContext 就可以直接通过 window.WXShare 调用 swift 里面的对象 context?.setObject(shareModel, forKeyedSubscript: &quot;WXShare&quot; as (NSCopying &amp; NSObjectProtocol)!) } catch (let error) { print(&quot;Error while processing script file: \(error)&quot;) } return context }() [代码] 这样就完成了将 swift 类注入到 JSContext 的步骤，余下的只是调用问题。这里主要考虑到你 JS 执行的位置。比如，你可以直接通过 JSCore 执行 JS，或者直接将 JSContext 和 webview 的 Context 绑定在一起。 直接本地执行 JS 的话，我们需要先加载本地的 js 文件，然后执行。现在本地有一个 share.js 文件： [代码]// share.js 文件 WXShare.setShareMsg({ name:&quot;villainhr&quot;, msg:&quot;Learn how to interact with JS in swift&quot; }); WXShare.wxShare(()=&gt;{ console.log(&quot;the sharing action has done&quot;); }) [代码] 然后，我们需要像之前一样加载它并执行： [代码]// swift native 代码 // swift 代码 func init(){ guard let shareJSPath = Bundle.main.path(forResource:&quot;common&quot;,ofType:&quot;js&quot;) else{ return } do{ // 加载当前 shareJS 并使用 JSCore 解析执行 let shareJS = try String(contentsOfFile: shareJSPath, encoding: String.Encoding.utf8) self.context?.evaluateScript(shareJS) } catch(let error){ print(error) } } [代码] 如果你想直接将当前的 WXShareInterface 绑定到 Webview Context 中的话，前面实例的 Context 就需要直接修改为 webview 的 Context。对于 UIWebview 可以直接获得当前 webview 的Context，但是 WKWebview 已经没有了直接获取 context 的接口，wkwebview 更推崇使用前文的 scriptMessageHandler 来做 jsbridge。当然，获取 wkwebview 中的 context 也不是没有办法，可以通过 KVO 的 trick 方式来拿到。 [代码]// 在 webview 加载完成时，注入相关的接口 func webViewDidFinishLoad(webView: UIWebView) { // 加载当前 View 中的 JSContext self.jsContext = webView.valueForKeyPath(&quot;documentView.webView.mainFrame.javaScriptContext&quot;) as! JSContext let model = WXShareInterface() model.controller = self model.jsContext = self.jsContext // 将 webview 的 jsContext 和 Interface 绑定 self.jsContext.setObject(model, forKeyedSubscript: &quot;WXShare&quot;) // 打开远程 URL 网页 // guard let url = URL(string: &quot;https://www.villainhr.com&quot;) else { // return //} // 如果没有加载远程 URL，可以直接加载 // let request = URLRequest(url: url) // webView.load(request) // 在 jsContext 中直接以 html 的形式解析 js 代码 // let url = NSBundle.mainBundle().URLForResource(&quot;demo&quot;, withExtension: &quot;html&quot;) // self.jsContext.evaluateScript(try? String(contentsOfURL: url!, encoding: NSUTF8StringEncoding)) // 监听当前 jsContext 的异常 self.jsContext.exceptionHandler = { (context, exception) in print(&quot;exception：&quot;, exception) } } [代码] 然后，我们可以直接通过上面的 share.js 调用 native 的接口。 原生组件的通信 JSCore 实际上就是在 native 的一个线程中执行，它里面没有 DOM、BOM 等接口，它的执行和 nodeJS 的环境比较类似。简单来说，它就是 ECMAJavaScript 的解析器，不涉及任何环境。 在 JSCore 中，和原生组件的通信其实也就是 native 中两个线程之间的通信。对于一些高性能组件来说，这个通信时延已经减少很多了。 那两个之间通信，是传递什么呢？ 就是 事件，DOM 操作等。在同层渲染中，这些信息其实都是内核在管理。所以，这里的通信架构其实就变为： [图片] Native Layer 在 Native 中，可以通过一些手段能够在内核中设置 proxy，能很好的捕获用户在 UI 界面上触发的事件，这里由于涉及太深的原生知识，我就不过多介绍了。简单来说就是，用户的一些 touch 事件，可以直接通过 内核暴露的接口，在 Native Layer 中触发对应的事件。这里，我们可以大致理解内核和 Native Layer 之间的关系，但是实际渲染的 webview 和内核有是什么关系呢？ 在实际渲染的 webview 中，里面的内容其实是小程序的基础库 JS 和 HTML/CSS 文件。内核通过执行这些文件，会在内部自己维护一个渲染树，这个渲染树，其实和 webview 中 HTML 内容一一对应。上面也说过，Native Layer 也可以和内核进行交互，但这里就会存在一个 线程不安全的现象，有两个线程同时操作一个内核，很可能会造成泄露。所以，这里 Native Layer 也有一些限制，即，它不能直接操作页面的渲染树，只能在已有的渲染树上去做节点类型的替换。 最后总结 这篇文章的主要目的，是让大家更加了解一下小程序架构模式在开发者工具和手机端上的不同，更好的开发出一些高性能、优质的小程序应用。这也是小程序中心一直在做的事情。最后，总结一下前面将的几个重要的点： 开发者工具只有双线程架构，通过 appservice_webview 和 content_webview 的通信，实现小程序手机端的模拟。 手机端上，会根据组件性能要求的不能对应优化使用不同的通信架构。 正常 div 渲染，使用 JSCore 和 webview 的双线程通信 video/map/canvas 等高阶组件，通常是利用内核的接口，实现同层渲染。通信模式就直接简化为 内核 <=> Native <=> appservice。（速度贼快） 参考： 教程 | 《小程序开发指南》

接着上篇文章《小程序架构设计(一)》 前边我们说到采用Web+离线包的方式可以解决很多问题，但是遗留了一个安全问题有待解决。 经过了一番讨论，我们决定把开发者的JS逻辑代码放到单独的线程去运行，因为不在Webview线程里，所以这个环境没有Webview任何接口，自然的开发者就没法直接操作Dom，也就没法动态去更改界面，“管控”的问题得以解决。 还存在一个问题：开发者没法操作Dom，如果用户交互需要界面变化的话，开发者就没办法动态变化界面了。所以我们要找到一个办法：不直接操作Dom也能做到界面更新。 其实Facebook早有方案解决这个问题，就是上篇文章提到的React。React引入了Virtual Dom的概念（后文简称VD），业务侧只需要改变数据即可引起界面变化，相关原理后边再写篇文章来分享。 至此小程序双线程的模型就定下来了：渲染层(Webview)+逻辑层(JSCore) [图片] 其中渲染层用了Webview进行渲染，开发者的JS逻辑运行在一个独立的JSCore线程。 渲染层提供了带有数据绑定语法的WXML，逻辑层提供了setData等等API，开发者需要进行界面变化时，只需要通过setData把变化的数据传进去，小程序框架就会进行Dom Diff等流程最后把正确的结果更新在Dom树上。 [图片] 可以看到在开发者的逻辑下层，还需要有一层小程序框架的支持（数据通信、API、VD算法等等），我们把它称为基础库。 我们在两个线程各自注入了一份基础库，渲染层的基础库含有VD的处理以及底层组件系统的机制，对上层提供一些内置组件，例如video、image等等。逻辑层的基础库主要会提供给上层一些API，例如大家经常用到的wx.login、wx.getSystemInfo等等。 解决了渲染问题，我们还要看一下用户在和界面交互时的问题。 [图片] 用户在屏幕点击某个按钮，开发者的逻辑层要处理一些事情，然后再通过setData引起界面变化，整个过程需要四次通信。对于一些强交互（例如拖动视频进度条）的场景，这样的处理流程会导致用户的操作很卡。 对于这种强交互的场景，我们引入了原生组件，这样用户和原生组件的交互可以节省两次通信。 [图片] 正如上图所示，原生组件和Webview不是在同一层级进行渲染，原生组件其实是叠在Webview之上，想必大家都遇到过这个问题，video、input、map等等原生组件总是盖在其他组件之上，这就是这个设计带来的问题。 我们也很重视这个问题，经过了一段时间的努力，我们攻克了这个难题，把原生组件渲染到Webview里，从而实现同层渲染。目前video组件已经完成同层渲染的全量发布，详细可以看我们之前的公告：同层渲染公测。 为了让开发者可以更好的开发小程序，我们在后来还引入了自定义组件和插件的概念，我们后续会有相关的文章再介绍这两块的设计，希望大家关注我们社区的文章板块。 [图片] 以上就是小程序架构设计的历史。

一、写作背景 接触小程序一年多，真实体验就是小程序开发门槛相对而言确实比较低。不过小程序的开发方式，一直是开发者吐槽的，如习惯了 Vue，React 开发的开发者经常会吐槽小程序一个 Page 必须由多个文件组成，组件化支持不完善或者说不能非常愉快的开发组件。在以前小项目中没太大感觉，从加入有赞，参与有赞微商城小程序的开发，是真切的体会到对于大型小程序项目开发的复杂性。 有赞从微信小程序内测就开始开发小程序，在不支持自定义组件的时代，只能通过 import 的形式拆分模块或实现组件。在业务复杂的页面，可能会 import 非常多的模块，而相应的 wxss 也需要 import 样式，除了操作繁琐，有时候也难免遗漏。 作为开发者，我们当然希望可以让工作更简单，更愉快，也希望改善我们的开发方式。所以希望能够更了解微信小程序框架，减少不必要的试错，于是有了一次对小程序框架的 debug 之旅。(基础库 1.9.93) 通过三周空余时间的 debug，也算对小程序框架有了一些浅显的认识，达到了最初的目的；对小程序启动，实例，运行等有了真切的体会。这篇文章记录了小程序框架的基本代码结构，启动流程，以及程序实例化过程。 本文的目的是希望把我看到的分享给对小程序感兴趣或者正在开发小程序的读者，主要解答“框架对传入的对象等到底做了什么”。 二、从启动流程一窥小程序框架细节 在开发者工具中使用 help() 方法，可以查看一些指令和方法。使用其中的 openVendor 方法可以打开微信开发者工具在小程序框架所在目录。其中以包括以基础库命名的目录和其他帮助文件，如其中有两个工具 wcc，wcsc。wcc 可把 wxml 转换为对应的 JS 函数 —— $gwx(path, global)，wcsc 可将 wxss 转换为 css。而基础库目录包括 WAService.js 和 WAWebview.js 文件。小程序框架在开发者工具中以 WAService.js 命名（WAWebview.js 不知其作用，听说在真机环境使用该文件）。 在开发中工具命令行使用 document.head 可以查看到小程序的启动流程大致如下： [图片] 以小节的方式分别介绍这些流程，小程序是如何处理的（小节编号与图中编号相同）。 1、初始化全局变量 下图是小程序启动是初始化的一些全局的变量： [图片] 那些使用“__”开头，未在文档中提及可使用变量是不建议使用的，wxAppCode 在开发者工具中分为两类值，json 类型和 wxml 类型。以 .json 结尾的，其 key 值为开发者代码中对应的 json 文件的内容，.wxml 结尾的，其 key 值为通过调用 $gwx(’./pages/example/index.wxml’) 将得到一个可执行函数，通过调用这个函数可得到一个标识节点关系的 JSON 树。 [图片] 2、加载框架（WAService.js） 使用工具对 WAService.js 进行格式化后进行 debug。可以发现小程序框架大致由： WeixinJSBridge、 NativeBuffer、 wxConsole、 WeixinWorker、 JavaScript兼容（这部分为猜测）、 Reporter、 wx、 exparser、 virtualDOM、 appServiceEngine 几部分组成。 其中除了 wx 和 WeixinJSBridge 这两个基础 API 集合， exparser, virtualDOM, appServiceEngine 这三部分作为框架的核心， appServiceEngine 提供了框架最基本的接口如 App，Page，Component； exparser 提供了框架底层的能力，如实例化组件，数据变化监听，view 层与逻辑层的交互等；而 virtualDOM 则起着链接 appServiceEngine 和 exparser 的作用，如对开发者传入 Page 方法的对象进行格式化再传入 exparser 的对应方法处理。 框架对外暴露了以下API：Behavior，App，Page，Component，getApp，getCurrentPages，definePlugin，requirePlugin，wx。 3、业务代码的加载 在小程序中，开发者的 JavaScript 代码会被打包为 [代码]define('xxx.js', function(require, module, exports, window, document, frames, self, location, navigator, localStorage, history, Caches, screen, alert, confirm, prompt, fetch, XMLHttpRequest, WebSocket, webkit, WeixinJSCore, Reporter, print, WeixinJSBridge) { 'use strict'; // your code }) [代码] 这里的 define 是在框架中定义的方法，在框架中提供了两个方法：require 和 define 用来定义和使用业务代码。其方式有些像 AMD 规范接口，通过 define 定义一个模块，使用 require 来应用一个模块。但是也有很大区别，首先 define 限制了模块可使用的其他模块，如 window，document；其次 require 在使用模块时只会传入 require 和 module，也就是说参数中的其他模块在定义的模块中都是 undefined，这也是不能在开发者工具中获取一些浏览器环境对象的原因。 在小程序中，JavaScript 代码的加载方式和在浏览器中也有些不同，其加载顺序是首先加载项目中其他 js 文件（非注册程序和注册页面的 js 文件），其次是注册程序的 app.js，然后是自定义组件 js 文件，最后才是注册页面的 js 代码。而且小程序对于在 app.js 以及注册页面的 js 代码都会加载完成后立即使用 require 方法执行模块中的程序。其他的代码则需要在程序中使用 require 方法才会被执行。 下面详细介绍了 app.js，自定义组件，页面 js 代码的处理流程。 4、加载 app.js 与注册程序 在 app.js 加载完成后，小程序会使用 require(‘app.js’) 注册程序，即对 App 方法进行调用，App 方法是对 appServiceEngine.App 方法的引用。 下图是框架对于 App 方法调用时的处理流程： [图片] App 方法根据传入的对象实例化一个 app 实例，其生命周期函数 onLaunch 和 onShow 因为使用不同的方式获取 options的参数。在有些需要根据场景值来实现需求的，或许使用 onShow 中的场景值更合适。 在实际开发过程中发现，在微信顶部唤起小程序和在小程序列表唤起的 options 也是不一样的。在该案例中通过点击分享的小程序进入后，关闭小程序，再通过不同方式进入小程序，通过顶部唤起的还是 options 的 path 属性还是分享出来的 path，但是通过列表中打开直接回到了首页，这里 App 中的 onShow 就会获取到不同的 options。 5、加载自定义组件代码以及注册自定义组件 自定义组件在 app.js 之后被加载，小程序会在这个过程中加载完所有的自定义组件（分包中自定义组件没有有测试过），并且是加载完成后自动注册，只有注册完成后才会加载下一个自定义组件的代码。 下图是框架对于 Component 方法处理流程： [图片] 图中介绍了框架如何对传入 Component 方法的对象的处理，其后面还有很多深入的对于组件实例化的步骤没有在图中表示出来，具体可以在文章最后的附件中查看。 自定义组件在小程序中越来越完善，其拥有的能力也比 Page 更强大，而后面会提到在使用自定义组件的 Page 中，Page 实例也会使用和自定义组件一样的实例化方式，也就是说，他拥有和自定义组件一样的能力。 6、加载页面代码和注册页面 加载页面代码的处理流程和加载自定义组件一样，都是加载完成后先注册页面，然后才会加载下一个页面。 下图是注册一个页面时框架对于 Page 方法的处理流程： [图片] Page 方法会根据是否使用自定义组件做不同的处理。使用自定义组件的 page 对象会被处理为和自定义组件的结构，并在页面实例化时使用不同的处理流程进行实例化。当然对于开发而言没任何不同。 从图中可以发现 Page 传入的（生命周期）代码并不会在这里被执行，可以通过下面小节了解 Page 实例化的详细过程。 7、等待页面 Ready 和 Page 实例化 还记得上面介绍的启动流程中最后一步等待页面 Ready？严格来讲是等待浏览器 Ready，小程序虽然有部分原生的组件，不过本质上还是一个 web 程序。 在小程序中切换页面或打开页面时会触发 onAppRoute 事件，小程序框架通过 wx.onAppRoute 注册页面切换的处理程序，在所有程序就绪后，以 entryPagePath 作为入口使用 appLaunch 的方式进入页面。 下图是处理导航的程序流程： [图片] 从图中可以看出页面的实例化是在进入页面时进行，下图是具体的实例化过程： [图片] 下图是最终可得到 Page 实例： [图片] 可以发现其中多了 onRouteEnd API，实际该接口不会被调用。其中以 component 标记的表示只有在使用了自定义组件时才会有的方法和属性。在前面第 5 小节提到了对于使用自定义组件的页面会按照自定义组件方式解析，这些属性和方法与自定义组件表现一致。 8、关于 setData 小程序框架是一个以数据驱动的框架，当然不能少了对他如何实现数据绑定的探索，下图是 Page 实例的 setData 执行流程： [图片] 其中 component:setData 表示使用自定义组件的 Page 实例的 setData 方法。 三、写在最后 这是一次不完全的小程序框架探索，是在微信开发工具中 debug 的结果。虽然对于实际开发没有什么太大的帮助，但是对框架如何对开发的 js 代码进行处理有了一个很明确的认识，在使用一些 js 特性时可以有明确的感知。如果你还疑惑“小程序框架对传入的对象等到底做了什么”那一定是我表达能力太差，说声对不起。 通过这一次 debug ，也给我引入了新的问题，还希望能够有更多的讨论： · 自定义组件太多启动时会耗时处理自定义组件 · 文件太多会耗时读文件 · 合理的设计分包很重要 当然最后对于框架中已有的能力，还是非常希望微信可以开放更多稳定的接口，并在文档中告知开发者，让开发变得简单一些。