Weex工具链的奥秘

导读	在2017年1月12日 Weex Conf 2017上，来自阿里的卜道依据Weex开发中的痛点介绍了Weex的打包和插件机制，一样来自阿里的归影介绍了Weex的调试工具Devtools，共同揭秘了Weex的工具链。本文是卜道和归影关于Weex工具链实践的分享整理。

Weexpack与插件机制

Weex开发中的痛点

Weex提供了一个高效的引擎，可是开发者仅有这个SDK是不够的，咱们还须要更完善的类库和强大的调试工具，遇到问题能够用工具来解决，复杂的场景须要用工具来消解其复杂度，把复杂问题简单化。

Weex工具链

Pack一键打包，适合纯前端的开发者创建Weex应用，不须要关心native的具体作法。Devtools主要解决Weex代码的调试问题。插件机制可以让开发者从Weex市场安装插件到本地的工程中, 以搭积木的方式开发app。IDE还在持续建设中。

Weex SDK支持的扩展方式

Module是一些非UI的特定功能，sendHttp、openURL等能够做为module来扩展。Component是一些UI控件，RichText、DatePicker等能够做为component来扩展。Adapter/Handler是SDK内置的一些适配器接口，没有指定具体的实现，能够根据本身APP的状况选择合适的实现来做为功能的扩展，例如图片加载器等。

插件机制

示意图最上方是市场，市场中会有开发者发布的不少的可复用的插件。中间是咱们的应用，与OS进行通讯的是SDK，基于SDK有一个APP Framework（应用容器，包括了一些页面控制逻辑，解析插件的配置文件），Plugin Framework插件容器是插件安装的target，插件既能够从市场下载安装，也能够从本地或者github安装。插件是上述SDK的三种扩展方式的封装，能够调动native的接口，具备和native通讯的能力，极大地扩展了应用的能力，扩展了Weex应用的边界。

插件到插件容器的映射

左侧是插件结构的示意图，配置文件为Plugin.xml，里面配置了插件的组成和相应平台须要安装的资源、源码及依赖，安装到了Plugin Framework中后，映射为了右侧的相应文件，分别对应到android平台和IOS平台。

打包及插件相关命令

左图是打包命令，Weexpack create建立一个新工程，包括必要的目录和一些配置文件，Weexpack platform add/remove用来安装或者移除应用模版，它的参数是相应平台的应用模板， Weexpack plugin add/remove用来安装和移除插件，参数为插件名，它是打包流程的一个可选项。右图是插件开发者的一些命令，经过Weexpack plugin create建立插件，配置好相关命令，经过publish发布。

插件的安装使用

打包及插件机制应用示例

 

上图案例中的插件是一个复杂插件，咱们设置了其对其它插件的依赖关系，Weex-gcanvas插件提供基础的绘图能力，Weex-chart基于其所依赖的Weex-gcanvas进一步提供图表的能力。具体的步骤如上图所示。

 

Weex-gcanvas安装怎么完成的？首先，插件在plugin.xml定义了其依赖关系以及须要暴露的接口；而后，咱们的工具会根据plugin.xml的配置去维护几个文件——config.xml和build.gradle, 若是涉及权限或者其余资源相应的也会去修改AndroidManifest， 源码和资源会被复制到插件容器对应的目录中。

插件机制的优势

• 按需打包，插件能够按需灵活配置打包，app彻底自主；
• 独立升级，插件可独立升级，支持细粒度的版本控制；
• 支持二次开发，插件能够二进制库或者源码形式发布，方便二次开发；
• 流程自动化，提供完善的命令行工具，自动合并代码、资源及编译脚本；
• 面向定制，可按需定制本身的插件仓库和平台模板；
• 集成一键打包，插件工具和打包工具完全打通，下降开发app的门槛。

展望——插件化的Weex APP

 

若是插件市场已经有了不少插件，功能很丰富，前端的开发者只须要写最熟悉的业务逻辑就能生成应用；而native开发者也能参与开发发布Plugin和Framework中来。

调试工具Devtools

Weex的调试需求

做为前端的开发者，须要哪些功能？在逻辑方面，最重要的，咱们须要断点调试js，最好能直接在we文件里打断点；在渲染方面，须要能够查看dom层级结构(前端)/native view层级结构(native端)的工具；在优化方面，能不能看到native的各类网络加载信息，如加载bundle的信息和时间，或者JS运行时的堆快照(heap snapshot)等等。

Weex Devtool主要功能

上图是Weex Devtool提供的主要功能。Debugger能够远程调试Weex源码，可呈现原始的we代码结构并打断点。Inspector展现渲染节点的层级结构，可随时切换dom tree和native view tree，能够高亮某一个节点。

远程调试

 

在解决问题以前须要抽象问题，一个客观事实是若是想在Chrome里面调试JS，那这个JS必须运行在Chrome的运行时里面。Weex现有的流程归纳为用户写的业务代码运行在native的运行时（android是V8，IOS是JSCore）里面，由这些运行时和JS的worker负责与native渲染引擎的通讯。那么，问题抽象为若是要实现远程的运行时——Chrome，并实现运行时和native渲染引擎的通讯。运行时环境哪家强？显然是worker，基于worker的前端是浏览器解决多线程的一种技术手段。今天用到的是其灵活和隔离性，一个worker能够很方便的建立和销毁，并且它又有比较好的独立性，因此是一个比较好的运行时环境。通讯方面，利用一种计算RPC的方式，制定本身的协议，并经过这个协议与native的渲染引擎进行通讯。优化方面，Weex加载Bundle的方式是直接加载Bundle的运行源码，调试时没办法打断点，因此调试工具作了一个中间层，将Bundle包装成一个函数并将其放在一个JS文件里面，利用Chrome的运行时去加载这个文件。还原成源码中打断点，即提供一个Sourcemap。

Inspector原理

 

Inspector是模仿Chrome的Inspector制做的。Chrome的调试工具是一个Web APP，是纯前端技术写出来的APP。其数据是Chrome经过remote debug protocol协议发送给Devtool工具，这些数据一部分来自渲染引擎，另一部分来自V8引擎。对于前端来讲，不管是渲染引擎仍是V8都在一个Chrome里面，可是对于Weex的场景并非这样的。Weex的JS是运行在Chrome的运行时里面，渲染是在手机native端，调试这些调试信息须要经过Chrome的V8来获取，并且只能给到原生的Devtool。而咱们的层级信息须要手机的native端给到，因此只能本身作了一个extension页面去承载和表现这部分的数据。

总体架构

 

分三层：最上层是Devtool的前端；中间是Node Server，主要负责RPC消息转发、维持session多实例管理的功能；最下层是Native Inspector。这些RPC是须要在native端安插内应的，即android和IOS的Native Inspector模块，它会截获自己Weex的SDK应该发给native runtime的全部信息，而后将这些信息转发给远程的Weex调试工具。

困境和展望

最大的困境是调试体验太分离，由于分为两个界面，而且一部分的功能须要extension提供。可是，Weex Devtool 1.0.0已经正在开发，逐步完善解决这些问题。

原文来自：https://yq.aliyun.com/articles/68947?spm=5176.100239.bloglist.131.pn6omB

本文地址： http://www.linuxprobe.com/weex-tools.html