加推Weex实践之路（上）

TextComponent。JSBridge

JS

Native

Module来完成

依托于Native，借助于前端，演变成大前端的架构，整体结构如下图。我们希望App作为终端，提供容器的能力，做好底层服务，完美融合Weex、Web等跨平台技术。

以下记录了实践中遇到的一些较为重要、常见的问题，及其解决方案，它们贯穿了Weex页面的生命周期。

页面间通信

路由

Weex自身提供的navigator只支持简单的在线资源，而不支持本地文件的加载，同时无法满足动态化的呈现方式和复杂参数传递，需要自行实现一套完整的页面跳转规则。

在大量使用了

Web、Weex

// 打开Web页面
scheme:/web/open");

Weex中发起一次页面跳转的示例：

navigator.openUrl({
  url: "scheme://weex/open",
  params: {
    bundleUrl: "/dist/about.js",
    name: "这是下一个页面所需的参数",
  },
})


// 备注： 而下一个页面只需要在data中声明一个与参数同名的属性来接收具体的参数即可。

反向传值

我们在考虑反向传值的问题时，主要涉及两种场景，一是Weex页面反向传值给Weex页面，二是Native反向传值给Weex页面。我们可以使用Weex提供的基于W3C 规范的

BroadcastChannel

在页面跳转时将

WXModuleKeepAliveCallback

我们有尝试借鉴

BroadcastChannel

我们最后选择使用

fireGlobalEvent

1.Weex添加事件监听
const globalEvent = weex.requireModule("globalEvent");
globalEvent.addEventListener("eventName", (e) => {
  // ...
});


2.原生页面发送事件
weexInstance.fireGlobalEventCallback("eventName", params); // Android


[weexInstance fireGlobalEvent:seventName params:params]; // iOS

代码中的weexInstance，可以理解为一个页面的实例对象，该流程需要在发送监听的页面需要获取上一个

Weex

weexInstance

----

navigator.openUrl({
  url: "scheme://weex/open",
  params: {
    bundleUrl: "/dist/about.js",
    needListen: true,
  },
})

2. 页面配置文件

起初Weex页面导航栏、跳转方式等配置，均在自建Module中进行处理，例如一个页面要设置导航栏，我们需要在mounted方法中加入如下代码：

created () {
    navigator.setTitle("导航栏标题")
    navigator.setItems([{
      title: "按钮",
    }])
}

这种不够工程化、标准化的方式给后期的维护、跨项目移植、架构升级造成了极大的干扰。

我们参考小程序的设计思路进行了优化升级，为每一个需要特有化配置的Weex页面添加一个json格式的配置文件，配置文件包括导航栏的配置、页面级别的配置、跳转的配置等，将配置工程化、标准化。

例如我为about页面添加了配置文件，json文件的类容为：

{
    "navigationBarTitle": "导航栏标题",
    "navigationItems": [{
        "title": "按钮"
    }]
}

打包后的资源文件目录如下，about.js、about.json文件在同级目录：

那么一个完整的页面打开步骤如下：

经过扩展，配置文件变得更加丰富，先前麻烦的跳转处理、弹框等都可以通过配置文件实现，下面是一些常用的属性介绍：

针对于iOS客户端存在页面需要Present等情况，可以设置以下属性：

transition中需定义动画的表达式，Native则需要解析该表达式，并按照表达式执行动画。

按钮样式说明：

{
     "type": "TEXT", // "TEXT", "IMG", "TEXT_IMG"，必传




     "title": "标题", // 文字标题或者




     "image": "刷新", // 是图片地址，图片地址支持本地图片和网络图片




     "textColor": "FFFFFF", // 16进制， 默认为白色，可不传




     "backgroundColor": "", // 16进制， 默认透明色，可不传




     "borderColor": "", // 16进制， 默认无边框，可不传




     "borderWidth": 1, // 默认无边框，可不传




     "cornerRadius": 1, // 默认无圆角，可不传




     "font": 16, // 默认16号字体，可不传
  
      "position": 0, // 默认0，可不传, 0-左侧显示，1-右侧显示  
       
     "imagePosition": 0, // 0-图片在左，文字在右，默认, 1- 图片在右，文字在左,  2-图片在上，文字在下,

4.自定义导航栏

例如满足导航栏分段选择的需求：

Weex对于iOS的支持比较友好，然而Android 端无法显示阴影。 虽然文档有明确指出此问题，但是Android sdk却提供相关方法。也许是阿里的工程师尝试解决，但效果并不理想。比较明显的一点是，如果列表中的item使用阴影， 在列表滑动的时候会把阴影残留在最初绘制的位置。Android的同学一直在尝试解决此问题，最终也没达到一个理想的效果。最后的降级方案是通过图片来替代阴影，以下是Weex官方的注释：

目前仅 iOS 支持 box-shadow 属性，Android 暂不支持，可以使用图片代替。

每个元素只支持设置一个阴影效果，不支持多个阴影同时作用于一个元素。

4. 网络请求

Weex提供了

Stream

因此我们提供了自己的网络请求模块，Weex端调用Native提供的方法，并通过参数来决定请求，一些可选的参数：

请求示例：

// 1. 获取原生Module
const nativeStream = weex.requireModule("nativeStream")


// 2. 设置基本参数
const options = {
  path："/...."，
  method: "POST",
  params: {
    id: "123"
  }
}


// 3. 发起请求
nativeStream.fetch(options, (res) => {
  if (res.code === 0) {
    succesCallback(res)
    return
  }
  failCallback(res)
}

5. 图片加载

标签图片的加载需要客户端提供handler，目前支持远程链接和打包生成的Bundle资源，并不直接支持相册图片以及拍照生成的图片。其对Base64的支持，为我们显示相册图片提供了一种思路。下图表明了Weex页面中选择相册图片、拍照并进行显示的流程：

通过上图我们可以知道，一个简单的图片显示流程，其实并不简单，其中最为关键的是在进行第5步时所选择方案。先上传图片对于程序员而言是最为便捷的方案，但是比较影响用户体验，图片本应该在需要上传的时候进行上传，而非因为技术隘口而干扰业务。

转换为Base64可以提升用户体验，但是却比较影响性能。在iOS端，将一张1M的图片转换为Base64所需要的时间≥45ms，第6、7步所消耗的时间则是30ms左右，这种时间消耗随图片大小以倍数增加。

综上所述，我们设计了一种本地化方案，为每一个添加的图片生成一个唯一性的ID，Native负责图片的存储、加载。

6. 刷新组件

由于Weex所提供的组件形式较单一，且存在交互Bug，我们自实现了一套刷新组件。通过属性来确定刷新的显示与否，并提供相应的接口实现Weex与Native之间的交互。

1.属性

refresh 事件：当 、、 被下拉完成时触发，该事件由原生回调到Weex。

loading 事件：当 、、 被上拉时触发，该事件由原生回调到Weex。

"list"
      c
      :show-refresh="true"
      class="list"
      @refresh="refreshList"
      @loading="loadMoreList">
 

beginRefresh 事件：开始下拉刷新，由Weex调用。

beginLoading 事件：开始上拉刷新，由Weex调用。

endRefresh 事件：结束下拉刷新，由Weex调用。

endLoading 事件：结束上拉刷新，由Weex调用。

this.$refs.list.beginRefresh()
this.$refs.list.endRefresh()

如果不使用该属性，则需要在created或者mounted函数中手动调用刷新的方法以触发下拉刷新，然而在某些Android设备上面出现了白屏的情况。Weex对此做出了解释：

和浏览器不同的是，Weex 的渲染流程是异步的，而且渲染出来的结果都是原生系统中的 View，这些数据都无法被 javascript 直接获取到。因此在 Weex 上，Vue 的 mounted 生命周期在当前组件的 virtual-dom (Vue 里的 VNode) 构建完成后就会触发，此时相应的原生视图未必已经渲染完成。

7. 截屏

Weex中完成截屏，只需要获取到对应的视图层即可，Weex页面在渲染时会为每一个组件生成一个唯一的ID，在JavaScript中更直观的体现是ref，尽管Weex并不存在真正的DOM，但其依然支持ref的使用。具体的做法如下：

// 1. 标签生命ref
"poster">


// 2. 获取到该element，实际上是一个Map
const poster = this.$refs.poster


// 3. 获取Map中对应的ref
saveViewShot({ ref: poster.ref })


// 4. 获取Component
// iOS
WXComponent *component = [weexInstance componentForRef:ref];
// Android
WXComponent component = WXSDKManager.getInstance().getWXRenderManager().getWXComponent(mWXSDKInstance.getInstanceId(), ref);


// 5. 获取View，进行

8. 优雅的弹窗

这是一个很简单的弹框需求，视图渐渐变大最后全屏展示。然而基于Weex现有的能力是无法实现的，第一点：Weex页面默认的布局是从导航栏下面开始的，第二点：路由的跳转方式并不能直接支持此种弹出方式，页面默认是从右向左推出。

为了实现弹框的功能，我们需要四个步骤：

1. Native定义PopView组件

1. Weex搭建页面，并以PopView为基础进行布局

2. 全屏呈现页面并隐藏导航栏

3. 执行动画

原生定义好PopView组件后，Weex页面可以这样布局：

结合第三点所提出的配置文件，我们将2、3步骤的控制放在配置文件当中，最后写出的配置文件为：

{
  navigationBarHidden: true, // 隐藏导航栏
  transition: {
    property:"scale", // popView的尺寸将由(0，0)变为显示大小
    duration: 2, // 动画时间，单位(秒)
  },// 转场显示，并规定popView的显示动画
}

这只是最为简单的例子，更复杂的动画需要客户端支持即可。

五、To Be Continued

以上概括了Weex接入的心路历程，以及在实践中遇到的基本问题，表明了Weex在团队中的运用已经畅通并日趋规范化，但是更深入的性能优化、热更新等需要我们继续前行，以下是下一期文章将涉及的知识点:

热更新

资源预加载

配置文件动态化

Weex资源打包自动化，自动加入终端仓库

加推科学院公众号

mp.weixin.qq.com/s/LxdQ6Eq2R…