让别人的小程序运行在本身的app中

概要

本文包括的内容:

• 小程序在微信开发者工具中，经过构建生成真正的执行代码和安装包，****.wxapkg。wxml和wxss在构建这一步就被转换成了html和css(virtual-DOM)。微信开发者工具中能够获得构建脚本和各个版本的js运行SDK文件。
• 小程序是以wxapkg文件的形式下发的，能够拿到wxapkg后解压拿到执行代码。同时解压微信.ipa拿到当前的js运行SDK文件,主要是WAWebView.js和WAService.js。
• 小程序在App中执行时的时候分为三个不一样的模块，View/Service/Natvie，各司其职。
• 实现过程遇到大量的细节和坑。

介绍小程序原理的文章比较多，这篇讲的比较细:微信小程序架构分析。这篇文章的做者也成功的实现了wept,让小程序运行在本身的webapp里。

参考最多的是微店的Hera,完成度很是高的小程序框架，可以将小程序的demo代码在web/iOS/android运行起来，并且实现了不少工具。Hera的问题是开发于比较早期的版本，不兼容最新的版本了。Hera还有一个问题是他修改了小程序构建以后的目录结构，采用了service.html做为service部分的入口，跟小程序自己的实现尚有有一些区别。因此Hera只可以构建执行本身编写的小程序，不能执行别人编写的小程序。

个人目标是可以运行其它人开发的app，意味着我只能经过逆向的方式拿到wxapkg。可是由于拿不到源码，因此要尽量在构建环节跟小程序保持一致。

通过数周的挣扎，目前已经实现了运行官方demo。已经达到"可行"的阶段，可是还远远谈不上“可用”，由于须要实现小程序大量的API，这是个体力活，依赖我的的力量难以完成。

构建

官方demo小程序原先的目录分为几类文件:

• 配置: 在这个目录中，app.json里保存了页面信息、tabbar信息、网络超时配置等等。 config.js保存了腾讯云后台服务解决方案的配置。
• js文件: js定义了各类函数接口逻辑
• wxml: 相似于html,定义了页面结构
• wxss: 相似css

demo
├── app.js
├── app.json
├── app.wxss
├── config.js
├── image
│   ├── green_tri.png
│   ├── ...
├── page
│   ├── API
│   │   ├── index.js
│   │   ├── index.json
│   │   ├── index.wxml
│   │   ├── index.wxss
│   │   ├── pages
│   │   │   ├── action-sheet
│   │   │   │   ├── action-sheet.js
│   │   │   │   ├── action-sheet.json
│   │   │   │   ├── action-sheet.wxml
│   │   │   │   └── action-sheet.wxss
│   │   │   ├── ...
│   │   └── resources
│   │       └── ...
│   ├── ...
├── project.config.json
├── util
│   └── util.js
└── vendor
    └── qcloud-weapp-client-sdk
        ├── ...

复制代码

通过小程序的开发环境构建后，生成了一个*.wxapkg文件。 这个文件能够经过从越狱的iPhone或者root的安卓手机上拿到。有部分人用charles经过https抓包拿到了下载连接，也拿到了包。 拿到后要进行解包。有大神已经经过反编译安卓apk的方式拿到了解包部分的代码，而后用python重写了一遍。源码见wechat-app-unpack。

解包后获得的目录以下:

1.wxapkg_dir
├── app-config.json
├── app-service.js
├── app-service.js.map
├── image
│   ├── green_tri.png
│   ├── ...
├── page
│   ├── API
│   │   ├── index.html
│   │   ├── pages
│   │   │   ├── action-sheet
│   │   │   │   └── action-sheet.html
│   │   │   ├── ...
│   │   └── resources
│   │       └── kind
│   │           ├── api.png
│   │           ├── ...
│   ├── ...
└── page-frame.html
复制代码

转换过程能够分为三部分:

• 从wxml/wxss到html。 page-frame.html里定义了全部的virtural-dom，来自全部的wxss和wxml的转换，文件很是大。 page.html里很简单，就是从page-frame.html里提取对应的virtual-dom。包括wxss和wxml对应的逻辑。
• app-service.js是从以前全部的js文件转换而来。
• app-config.json是从app.json转换而来。

openVendor命令能够在小程序中获取到构建脚本wcc和wcsc, 以及各个版本小程序的执行SDK ****.wxvpkg,这个SDK也能够用wechat-app-unpack解开，解开后里面就是WAService.js和WAWebView.js等代码。

wxml/wxss的构建原理

wxss 转换成了css,wxml转换成了inject_js，实际上就是virtual_dom。 是用什么工具转换的？小程序里是叫wcc和wcsc。在开源工具hera本身实现了一套wxss-transpiler和wxml-transpiler。而hera的前身wept是直接使用wcc和wcsc。 咱们为了减小维护成本，直接采用wcc和wcsc。 由于咱们没有wcc和wcsc的源码，因此只能借助wxss-transpiler和wxml-transpiler来帮助咱们理解wxml/wxss的构建原理。

wxss-transpiler调用了一个PostCSS的插件，用来处理wxss。 PostCSS 提供了一种方式用 JavaScript 代码来处理 CSS。它负责把 CSS 代码解析成抽象语法树结构（Abstract Syntax Tree，AST），再交由插件来进行处理。插件基于 CSS 代码的 AST 所能进行的操做是多种多样的，好比能够支持变量和混入（mixin），增长浏览器相关的声明前缀，或是把使用未来的 CSS 规范的样式规则转译（transpile）成当前的 CSS 规范支持的格式。

wxml-transpiler:实现了一个转译器的工做，好比postcss也是转译器，包括解释器(parser),代码转换器(Transformer),代码生成器(Generator)。这个是闭源的。

• 根据输入的列表，读取全部文件
• 调用VUE的HTML Parser，解析输入的标签及属性，生成一颗DOM树。vue解决不了的js语言，用babylon库来处理。(Parse)
• 在解析组件的标签时，对其上包含的属性值进行解析（边Parse边Transform）
• 根据已有的AST生成JS文件（Generate）

更多实现原理见这篇文章

模块以前的通讯

小程序在App中执行时的时候分为三个不一样的模块，View/Service/Native，各司其职。

View和Service都在WKWebView中执行，互相没法调用。他们之间经过Native层通讯。

Native和WebView之间经过webkit.messagehandler和evaluateJavascript互相调用。

• WeixinJSBridge.publish: view和service之间的透传，在WKWebView之间传递消息。

• WeixinJSBridge.subscribe: 注册监听，监听view和service之间的消息调用。

• WeixinJSBridge.invoke: View或者Service传递消息到Native,而后Native使用逻辑调用js callback。

• WeixinJSBridge.on:监听Native的事件。

如何执行

这里以iOS为例介绍Native执行过程。安卓相似。

经过解压微信的ipa能够拿到WAService.js和WAWebView.js两个基础库文件，文件内容与hera的service.js/view.js已经有了较大的区别。 咱们采用小程序的架构和hera的两个webView的方案，尽量模仿小程序的执行过程。

View部分

View部分是比较直观的，就是WKWebView加载web页。这里须要在app-config.json里读取到首页的路径，而后加载该页面。这个路径下的xxx/index.html是没法直接加载的，须要作一些处理。要引入本地执行SDK里的index.css和view.js, 而后把page-frame.html里的virtual-dom所有塞进该页面。 而后loadHTML便可。

View全部的WKWebView也是要注册WKUserContentController的，用于通讯。 经过反汇编能够得知这个类在微信中叫YYWAWebView，调用js是直接调用-evaluateJavaScript:completionHandler:方法的。

view.js中包含的逻辑:

• WeixinJSBridge 对象处理消息通讯: invoke invokeCallbackHandler on publish subscribe subscribe subscribeHandler。
• Reporter 对象
• wxparser 对象，提供 dom 到 wx element 对象之间的映射操做，提供元素操做管理和事件管理功能。
• virtual dom 渲染算法实现，提供 diff apply render 等方法，该模块接口基本与 virtual-dom 一致，这里特别的地方在于它所 diff 和生成的并非原生 DOM，而是各类模拟了 DOM 接口的 wx element 对象

Service部分

Service部分的实现，Hera和微信小程序采起的了不一样的架构。 Hera的实现较为简洁，跟View部分保持一致，采用了WKWebView，调用-evaluateJavaScript:completionHandler:方法执行js，js回调OC时使用WKScriptMessageHandler。 经过反汇编能够得知这个类在微信中叫WAJSCoreService，js和OC之间的调用是采用JavascriptCore互相调用。

JavascriptCore它首先要加载app-config.json并把这个配置赋给一个全局对象__wxConfig。而后他要加载service.js是SDK基础,再而后他要加载app-service.js，这里面包含了用户编写的js逻辑。最后它发出全局消息 WeixinJSBridge.publish('serviceReady',,);</script>唤起小程序app的初始化。

Service.js中包含的逻辑:

• 跟 view.js 同样的 WeixinJSBridge 兼容模块
• view.js 同样的 Reporter 模块
• appServiceEngine 模块，提供 Page，App，GetApp 接口

Native部分

Native执行的问题比较复杂，由于基本是黑盒，里面发生了什么并不知道。 hera的方案在构建过程就已经跟小程序实际的方案有所区别，会提升维护成本。因此咱们只能靠猜想来实现Native的执行过程。

Native部分就是做为入口，运行环境，跳转，转发消息，实现扩展。包括网络模块/摄像头/tabbar实现的都是扩展。 咱们能够得知的是消息传递的协议。而后只能经过safari来调试webView，根据协议的名称和出入参来猜想协议的内容。

主要的困难点

• 因为压缩后的view.js和service.js基本不具有可读性，而virtual-dom又完全不具有可读性...因此就算猜中了协议，最后也每每是魔改。可维护性极差。
• 工做量不小，由于调试困难，没法阅读。以后随着小程序SDK升级，能用多久也不可知。加上也有各类微逆向的操做，小程序封上任何一个接口，都会致使扑街。可持续性极差。总之很是佩服微店的同窗能把Hera搞出来:)

小程序的性能启发

小程序是颠覆我对Web的固有印象,最初还觉得是相似weex或者rn的调用原生的方式，没想到几乎彻底是运行在WKWebView之上的。

• 采用virtual DOM，操做JS比html性能高不少，由于是diff后再操做dom，不须要所有从新渲染，快不少。
• WKWebView，滑动60fps，在独立于App以外的进程执行。
• 部分逻辑Native化，好比收发网络请求，好比数据持久化。 逐步用native组件来替换h5组件。好比tabbar。
• 重用webView以及提早初始化webView等等技巧。

存在的问题:

• 看消息传递的原理就能发现，传递的过程太长了，尤为是setData:这种传递整个model对象，是两次对象的深拷贝，可能会增长两次json的序列化和反序列化，若是model对象很复杂对性能影响比较大。
• 页面初始化/响应速度/UI细节仍是跟原生有差距。

固然已经比纯web页强不少了。目前来看仍是只适合轻量化的应用。受制于架构以及微信的平台，我的认为是对Web的替代和改善。可是就算在可见的将来，仍是很难跟native抗衡。

现代浏览器和操做系统之间的界限愈来愈模糊。App的"下载/安装"过程自己就是一种妥协。只要小程序的体验足够好,应该没有人会拒绝。