实现微信小程序编译和运行环境系列 (进阶篇)

前言

距离上一篇初始篇过了一段时间,在初始篇里面主要分享了微信小程序工具 和微信小程序的文件组成，以及小程序架构的基本大纲和描述，看了第一篇的小伙伴应该大概知道了微信小程序运行时候各部分文件职能了,如果不太了解的话可以再去看下github、csdn。

进阶篇内容主要从以下几个方面来分享下微信小程序的架构

• 核心文件 WAService.js WAWebview.js appservice.js 的解析；

• 和其他文件在逻辑层和渲染层的⚠️注意事项

• websocket 通信在微信小程序框架中的应用实现；

• 通过几个案例和部分代码来实现自己的小程序运行环境；

• 微信小程序云开发和小游戏架构初步分析(后续会持续更新)。

正文

WAService.js 文件

在第一篇里面有讲到 WAService.js 文件是在逻辑层模版页面里面引入的，但是没有给予过多的介绍，

接下来主要分析下 WAService.js 的代码组成，这个文件算是微信小程序基础库文件里面很核心的文件了，所以微信对它的保护应该很到位了，微信通过了压缩，编译，打包后生成的一坨这个 js 文件(如下图)：

直接看完全没什么头绪，看着头很重！！

下面只有让我们来一步一步分解它，让它原形毕露

• 第一步让它变得看起来稍微美一点，毕竟大家都喜欢美一点的人事物，既然有需求那肯定有解决方案，所以给大家推荐一个工具包 js-beautify,可以先让代码看起来比原来漂亮很多。

直接执行命令(不要对他抱太大期望，美化后的不可能让你一步到位，还是要慢慢咔哧咔哧)。

js-beautify ./WAService.js -r

美化后的代码：

• 看着花花绿绿的还是要舒心很多，但是毕竟人家是一个 6 万多行编译后的大物，想看明白不是一件易事，但我们还是要和它死磕来慢慢消耗它，接下里给大家介绍下个我比较笨的一种方案就是一点点有策略性的手动给他反编译过来(中间的过程只有经历后才能明白其中的痛啊)，不过看到结果还是蛮欣慰的。

先给大家看下最终大部分解出来的编译文件如下图：

上面的图是通过分析代码还原的一些人看的代码，然后分类的。

在网上我有看到有人说通过一些工具对 WAService.js 进行格式化后进行 debug 来分析，这种方式也是 ok 的但是有一些门槛问题，对于一些同学来说不太方便也不太能处理，因为你没有调试这些文件的运行环境，在微信开发者工具里面你是看不到 WAService.js 文件的更不要说去调试了，如果非要在开发者工具调试的话方法也是有的，要通过修改微信开发者工具客户端的代码才可以但是一般都不知道怎么去修改基础库代码。

下面介绍一个好理解但是有点痛苦的方式，比较清晰的一个操作是在上面我们让它变得美一点了，现在让它变得有条理一些，推荐使用 vscode 格式化后进行方法折叠。

这样一看其实很清晰了我们可以看到这些我们常听说的一些微信对象，WeixinJSBridge、 NativeBuffer、 wxConsole、 WeixinWorker、Reporter、VirtualDom 等对象都打包一起了，

然后看到对象里面有很多个 function(e,t,n)文件对应的就是每个暴露的方法，下面要做的就是把这些方法的代码手动编译过来，可以给大家一个案例演示下。

下图这个是 VirtualDom 对象文件里面的一个方法：

下图的是上面的代码改成我们正常人读的代码

这个过程对你的 js 水平要有一定要求的，如果你基础不扎实和了解怎么应用的话，还原起来可能会很吃力的，如果你可以完整的编译这些文件的话，你的 js 水平完全可以超越大部分人。

可以先给大家简单分析一点非技术层面的一些疑问，具体的技术层面编译过程，可以熟悉 js 整个编译历史，和 es6 转 es5 的方式推荐大家熟悉下 babel 源码，可以有很多收获 由于本人也还比较小白（高手可以忽略这点），大家可以看到：

var i=n(22)我改成了 const DomIndex=require(’./domIndex’)

这个语句语意可能很多人都可以理解，但我为什么把 22 这个文件写成 DomIndex，其实这里面的变量和命名和对应的文件都不是自己想当然的，这个可以在文件中进行分析得到的，具体怎么分析的这里不过多介绍了，内容就太多了有兴趣可以留言讨论。

使用对 WAService.js 文件分析可以看出大致有 ： WeixinJSBridge、 NativeBuffer、 wxConsole、 WeixinWorker、 Reporter、 wx、 exparser、 virtualDOM、 appServiceEngine 等对象组成的。

WAWebview.js 文件

这个大致和 WAService.js 文件分析方式一样，大家感兴趣的可以自行尝试下，留给大家自己研究，理解的肯定比我写出来的要深刻很多。

appservice.js 文件

这个文件分析的结果可以让我们看到一些浮出水面的东西来，但这个过程比较曲折开始。

在微信小程序工具的渲染层和逻辑层里面和微信基础库都没有发现这个文件，说明可能是运行时注入进去的(猜测的)。

后来在 sources 里面有发现这个文件：

但是文件是空的，页面资源和 network 里面都没有找到对应的文件，一时比较绝望，后来就一直瞎折腾半天后，终于在工具包里面 appservice 找到来这个类似文件，让生活注入了一点希望。

但是一打开还是这一坨不是人看的代码，但奈何不看不行啊(阿弥陀佛)

通过分析研究发现，还是发现了一些蛛丝马迹，看到了这个文件里面存在 webstocket 和 http 通信方式，有通信说明就会和外界有关联，于是大胆尝试了在一些通信相关代码的地方，修改了一点代码和添加了日志

标记三就是稍微在原来微信 appservice.js 的基础上进行了一点修改，然后保存，期待这微信开发者工具上面会有一些不一样的烟火🎆，但奈何关了又开，开了又关半天屁的变化都没有，于是就产生了自我怀疑，难道不应该这样吗，但是还是感觉方向是对的，于是打算在试试终极解决方法《重启电脑》,果然当我在打开开发者工具的时候看到了不一样的烟火🎆，

在 console 里面出现了耀眼的光芒，这里应该算一个突破性进展吧！！！

看到 api 和返回的结果，发现这些其实就是微信提供对外的同步 api,可以看到 getSystemInfo 走的其实是同步的方式，那微信还提供了 getSystemInfoSync 说明也是同步的，他们的底层实现都是同步的不知道这个 api 还提供这两个接口有什么意义 没理解， 然后又试了下其他微信提供的同步方法发现都会出现在这里，其他很多异步 api 的不会走这里都是通过 webstocket 走的，这里可以得出结论这些同步 api 请求都是通过/apihelper/assdk 传输的，大家可以自己测试下拦截这个请求会发现更多内容。

至于这个文件和基础库的关联和最核心的 webstocket 的实现和在文章开头说的案例分析和云开发小游戏架构分析相关，我打算放在下几篇《核心篇》里面来一一分享，本来打算放在一起的，但写起来才发现虽然文字不多但考虑东西太多时间要很久，如果放在一起只是大概概括的话会很快少很多省时省力，但是感觉没太大意义可能对一些想了解的同学没有太大帮助，所以我就想通过我中途的过程和遇到的问题来分析可能会好理解一些