基于weex的有赞无线开发框架

出于对开发效率和动态化的要求，无线端的开发框架也一直在更新，从 Hybrid、结构化 Native View、React Native、Weex，再到如今正在大受关注的 Flutter。什么样的框架才是适合本身的团队？不只要有技术追求，并且要考虑实际业务须要。最近，有赞移动选择了 weex 做为无线开发框架，搭建了从开发、Debug、构建、发布、数据一个闭环的流程。本文将对此进行分享。

1、什么是 weex

Weex 是阿里巴巴开源的一套构建高性能、可扩展的原生应用跨平台开发方案。首先总结一下 weex 的特色：

1. 页面的开发目前支持Rax和Vue

   Weex 也不是只支持 Vue 和 Rax，你也能够把本身喜欢的前端框架集成到 Weex 中，有一个文档扩展前端框架描述了如何实现，可是这个过程仍然很是复杂和棘手，你须要了解关于 js-native 之间通讯和原生渲染引擎的许多底层细节。

2. 一次编写，三端（Android、iOS、前端）运行

   前提是都集成了 weex sdk，另外视觉表现作不到彻底同样，有的会有一些差别，须要作一下适配。因此写 weex 页面的时候，若是支持三端，便须要在三端都进行自测。

3. UI 的绘制经过 native 的组件，JavaScript 逻辑在 JS 引擎里运行，二者经过 JavaScriptCore 通讯

   weex 里使用组件都须要在 native 端注册，这样 weex 里才可使用，运行的时候经过注册时记录的 map 进行查找。weex sdk 内置注册了一些基础的组件，包括 list、text、input 等。WXJSCoreBridge 封装了 JavaScriptCore 实现 native 和 js 之间的通讯。

4. 支持 Native 扩展

   能够将 native 的 UI 组件封装成 component，将 native 的逻辑代码封装成 module。从而在 weex 里能够进行使用。这里的 natiev UI 组件包括 modal、webview、image 等，这里的 native 逻辑代码包括 storage、network 等。

5. 每一个 weex 页面会被打包成一个 js 文件，weex sdk 将 js 文件渲染成一个 view
   weex 的打包经过 webpack，将每一个页面打包成独立的一个 js 文件，weex sdk 会将 js 进行解析，将 UI 部分绘制成一个 view, 再绑定 view 的事件与 js 代码绑定。

2、为何要使用weex进行无线开发

1. 效率问题

1）开发的人力成本

若是不算 web 端，一个页面原本须要 Android 和 iOS 2 我的开发；使用 weex 后只须要 1 个开发页面。

2）开发的编译速度

随着项目渐渐变得庞大，Android 项目一次编译须要 2-3 分钟，机器很差的还须要 10 分钟，iOS 可能会快一点，也须要 1-2 分钟。使用 weex 后，界面修改，只须要十几秒。

3）测试效率

提测以后，发现 bug，修复完成，测试总须要从新下载一个包进行安装；使用 weex 后，跟原生无关的 bug，只要测试重启 App 就能够进行验证。

2. 动态化

weex 页面最后打包完是一个 js 文件，只要能作到动态下发 JavaScript，那即可以实现动态化，能够热修复，甚至能够热部署，彻底替换或者新增页面。

3. 成熟度

在 2016 年阿里双十一中，Weex 在阿里双十一会场中的覆盖率接近 99%，页面数量接近 2000，覆盖了包括主会场、分会场、分分会场、人群会场在内几乎全部的阿里双十一会场业务。阿里双十一主会场秒开率97%，所有会场页面达到 93%。
2016 年 12 月 15 日，阿里巴巴宣布将移动开源项目 Weex 捐赠给 Apache 基金会开始孵化。
2017 年，weex 在阿里业务里增加以下图，来自 WeexConf 2018。

4. 接入成本

通过实践，一个移动端开发，一周时间就能够开始进行使用 weex 进行业务开发。

3、如何使用 weex 进行无线开发

weex 实际上是一套方案，各个流程不少东西须要本身建设，把它建设得让小伙伴能够以较小成本开始使用 weex，把它建设得融入已有的系统。这方面，咱们目前作了下面这几个方面，还任重道远。

1. 开发工具 zweex-toolkit

这是一个脚手架工具，基于 weex 官方的 weex-toolkit，用于新建 weex 工程，目前只支持 vue。

随着页面的增多，业务的复杂，工程会慢慢变得庞大，每次运行的时候若是所有页面都运行起来比较慢。为了解决这个问题，使用 zweex-toolkit 建立建的工程模板支持运行的时候，支持只运行指定目录下的页面，只要在 npm start 后加上参数便可，如：

npm run start hi,helloworld

这样就表示只运行 hi 目录下和 helloworld 下的页面。
另外，咱们支持：

• 新增页面zweex page
• 开启调试zweex debug

2. ZanWeex SDK 的实现

官方 weex sdk 作的事情，就是输入一个 js 文件，而后返回一个view。考虑到每一个应用的路由和个性化的须要，这一点，ZanWeex SDK 没有作其余工做，也仍是返回了一个view，业务方能够根据本身的须要将view添加到本身想要展现的地方。ZanWeex SDK 作的事情主要有以下几方面：

1）支持下发配置，支持动态化，能够完成整个页面的替换

weex 页面打包后的结果是一个 js 文件，因此能够进行下发进行动态更新，那么就须要有一份配置，来关联页面路由和 js 文件的关系，因而咱们设计了这样的数据结构：

h5：页面路由地址，能够直接使用发布平台生成的 h5 地址

js：打包后的 js 文件地址

version：支持的最低 App 版本，由于新页面若是须要 native 扩展，那就须要发布新版本进行支持

md5：为了校验完整性，咱们在配置里添加每一个 js 文件的 md5。

2）支持多模块独立配置，互不影响
一个App里会有多个模块，每一个模块可能由独立的团队进行负责，因此为了减小耦合，咱们将配置独立，每一个模块能够独立管理本身的配置，独立接入weex，不依赖于宿主App。

3）预加载页面模板，支持页面模板缓存和配置缓存

• 若是没有缓存，每次都从服务端拉取页面模板，那么是不可能达到秒开的，跟没有作缓存的H5页面就区别不大了。咱们SDK会预加载页面模板到本地，打开过的页面会缓存到内存。这样渲染的时间就更接近原生的渲染时间了。

4）支持开发时的hot reloading，前端开发般的体验

• 若是没有hot reloading，那么每次修改完页面，都得退出页面从新进入。为了省去这个操做，hot reloading是必须的。
• weex 工程里本地开发时候，经过webpack-dev-server来启动一个websocket，zan weex sdk 打开一个weex页面后，去与它创建链接。webpack-dev-server将工程的编译状态发送给ZanWeex SDK，当接收到渲染完成的指令时，就从新渲染页面，从而达到 hot reloading的目的。

5）支持页面的适配，提供环境变量
ZanWeex SDK 会提供如下四个变量共 weex 页面使用，方便完成页面配置。

• 容器的高度：weex.config.yzenv.viewHeight
• 容器的宽度：weex.config.yzenv.viewWidth
• 状态栏高度：weex.config.yzenv.statusBarHeight
• 底部栏高度（针对iPhone X，其余为0)：weex.config.yzenv.bottomHeight

6）开发阶段日志的查看
在开发阶段，weex sdk 源码里输出的日志以及 js 里经过 console.log 输出的日志，还有 js 运行的报错，都只能经过 XCode 和 Android Studio 进行查看。这对于一个只了解一端的开发人员是很是不方便的。因而咱们作了一个入口，在打开 weex 页面的时候，会显示该入口，点击便可查看所输出的日志。

7）参数传递
正向传参：从 A 页面跳转到 B 页面，参数传递是开发过程确定会碰见的一个场景。SDK 对外提供的渲染接口 renderByH5 的参数包括 url，params，data。业务方进行渲染的时候，能够将参数直接跟在 url 后面，或者经过 params、data 传入，不一样方式，取的方式也不同：

• url 后面的参数，会传入 data，weex 页面里直接在 data 里定义参数就会自动赋值；
• params的参数，在 weex 页面里能够经过 weex.config.name 来获取；
• data 传入的参数，获取方式同第一种。
• 反向传参：从 B 页面返回到 A 页面的时候，携带参数返回也是很常见的一个场景。SDK 提供了统一的存储类 ZParamStorage 来临时存储参数。页面 B 要返回的时候先把数据存入存储区，A 页面显示的时候再从存储区获取，而后清空存储区。
• 非跳转的参数传递：weex 页面之间，能够采用 BroadcastChannel 进行传参，weex 与 native 之间的传递能够经过本身封装 Module 进行实现。

3. 页面的开发

前面有提到，weex 的页面目前能够采用 vue 或者 Rax 编写。对于 Vue 和 Rax 的语法这里不作陈述。这里主要总结了容易在实际开发中卡住小伙伴的几个问题。

1）如何判断一个页面是否用 weex 来实现？

能够认为全部的新页面均可以采起 weex 来开发，区别在于这个页面使用的 native 能力有多少。能够经过自定义 Module 来调用 native 的能力，经过自定义 component 来使用 native 的组件；

2）何时须要自定义 Module？

• 须要原生的能力的时候，好比：

  • 要调用系统选择图片的接口
  • 调用打电话、发短信的功能
  • 打开其余应用

• 调用已有的业务逻辑，好比：

  • 加密、解密逻辑
  • 登陆逻辑

3）何时须要自定义 component？

• 若是一个组件已经使用 native 实现，为了保持统一一致，那么能够将原有的组件封装成 component
• 若是一个组件不能使用 weex 实现，好比地图组件、超长图显示等

4）多个弹层的布局如何实现？

weex 页面渲染的层级，是从上而下的，越在下面的布局，显示越上层。因此要做为弹层的布局，就把它放到最下面。

5）页面的动画如何实现？

官方 weex sdk 已经封装了 animation 的 module 能够直接使用，复杂的动画可使用 BindingX 实现。

6）weex 的代码如何复用？

代码均可以抽离出组件。

• 做为一个 UI 组件，抽离成一个组件，向外暴露属性参数和事件接口；
• 做为独立的 js 函数，抽离成一个 js 供其余页面引入；
• css 样式也能够抽离成一个 css 文件，供其余页面引入；
• 若是包含多个组件形式，能够经过 mixins 来引入。

4. 构建和打包平台

咱们开发了以项目为单位的构建平台：

• 每一个项目能够添加多个分支，能够是不一样仓库的分支。由于一个项目有多是跨团队跨模块的，可是须要一块儿发布。
• 构建经过 webpack 构建，构建以后，支持发布线下存储和线上 cdn

咱们还开发了以应用为单位的 weex 发布平台：

• 这里的应用是一个抽象概念，不是传统的“应用”，能够理解成模块
• 业务方能够在构建平台构建完成后，一键跳转到发布平台进行发布，除了须要第一次填写最低支持的版本号，其余均无需操做。
• 发布平台支持灰度发布、全量发布和回滚。
• 发布平台会展现 weex 在端上的使用状况，渲染时间、渲染错误、下载时间等

4、遇到的问题以及解决方案

在开发过程当中，不少问题，能够经过阅读源码来解决，好比：

• 使用 iconfont 的时候，是否已支持缓存?

  答：已支持，包括内存缓存和文件缓存，内存缓存使用 familyname 来作 key，文件缓存使用 md5(url) 来作本地文件名

• module实现的函数能不能返回参数？

  答：module 的函数氛围 UIThread 和 JSThread，JSThread 对于 js 线程来讲是同步的，支持直接返回参数；UIThread 对于 JS 线程来讲是异步的，不支持直接返回参数，只能使用 callback

另外，不少常见的问题，咱们已经在 ZanWeexSDK 进行了解决，包括实现动态化、多模块的支持、缓存管理、Hot Reloading、日志查看、页面适配、参数传递等。

此外，还会有一些常见的问题，在此罗列一下：

1. 配置的更新机制是怎样的？更新失败，如何打开 weex 页面？

   答： 配置的更新接口开放给业务方调用，由业务方决定何时调用更新接口；SDK 里作了三种处理，来尽可能保证配置能够更新成功：

   1）配置接口拉取失败后，会有三次重试；

   2）网络从无网变成有网时，sdk 会检查配置是否已拉取，若是未拉取就主动拉取

   3）容许业务方内置配置和 js 文件，当拉取失败后，SDK里会从内置配置里读取

2. 配置的版本管理是怎样的？

   答：配置每次发布的时候，都会指定该发布支持的 App 最低版本号。每次请求，会携带 App 版本号，服务端只会返回符合该版本号的最新配置。

3. 支持不支持屏幕旋转？

   答：答案是支持的。旋转以后，屏幕变成了横屏，weex 就按照横屏的尺寸来渲染，问题是只要你写的页面符合这种变化就能够了，跟 native 来实现页面没有什么区别。

5、将来还要继续作的事情

1. 组件库的建设
2. 性能统计，好比帧率、内存、CPU
3. 配置和js文件的增量更新、推送更新
4. 降级处理