深入Weex系列（十一）用Weex构建一个完整App的思考

1、前言

经过前面十篇文章，我们学习了Weex的使用、源码及架构分析，对Weex的优缺点和核心能力也有了认识。

为了将大前端进行彻底，我们来思考一个问题： 如何使用Weex构建一个完整的App？ 也就是说App是个壳子，骨架则是Weex。

2、优势

我们先来想下一个完整Weex构建的App有哪些好处，当然在一定程度上可以换句话说是平时Native开发的缺点：

• 动态更新的能力，模块修改或者热修复；
• 更简单的支持A/BTest；
• Apk包小，业务模块可按需下载；
• 降低崩溃率；

试想，平时我们是不是在Native开发中会花费大力气在热修复、A/BTest以及Dex较多时的拆包方案上，同时在发布市场的时候需要等待审核及用户升级率不高的长时间焦灼。

3、实践

一般对于比较难或者大的问题我们会首先进行任务拆解，拆解成若干小问题逐个突破。

我们看下拆解之后的各种小问题：

• 项目链路；
• 协作方式；
• 其它优化；

3.1 项目链路

项目链路就是整个项目开发、测试、打包、灰度、发布等的流程，和传统的Native开发区别并不是很大，有一些需要注意的点。

对开发的版本控制仓库我们需要两个，一个是Android的代码仓库，另一个是Weex的开发仓库；

• Android代码仓库用来做Native组件提供、Weex模块的代码内置及壳App的打包；
• Weex代码仓库就是Vue代码的版本控制；

备注：

• Weex使用Vue代码需要经过编译，最好做一个脚本工具简化步骤；
• 对灰度来说，依赖于发布平台，最好能有一个可视化的操作界面；

3.2 协作方式

协作方式就是一个完整的Weex App需要哪些人，如何分工能使人效最大化？

首先对于简单的Weex使用，Native RD可以自己上手写Weex代码。但是整个App都是Weex构建为了更好的工程化，那么最好分工明确：

• Native同学只负责基础架构，提供各种组件供前端同学来调用；
• 业务部分由前端同学来做；

这种分工的好处是Native和前端同学各自负责自己擅长的工作内容，有利于业务的快速开展。

3.3 其它优化

对于一个完整的Weex App，这块必不可少。毕竟对于纯粹的原生开发，大量开发人员经验丰富，解Bug、调优的套路都有明确的路子。但是一旦完全采用了Weex技术栈，单纯的使用Weex就不够了，需要对Weex的源码非常熟悉，必要的时候加以修改（这点我觉得免不了）。以下列出几点：

• 基础能力需要自己做；
• 测试环节的加强，稳定性、性能的保障；
• 界面显示速度的优化；

务必注意：吃透源码，不满足的时候才能尽情修改。

4、总结

本文总结Weex开发的链路，关于Weex的使用、源码分析、架构设计、优劣等可以参考之前的系列文章。