Weex在内涵发现页中的工程实践

Posted 2021-04-29 字节跳动技术团队

React-Native和Weex是目前最为火热的两个客户端跨平台解决方案。从去年2016年9月份开始，IES在抖音产品中应用了React Native，中途遇到了很多的问题，尤其是长列表的性能问题一直没能从根本上得到解决。

鉴于Weex在性能方面做过一些针对性的优化并且已在阿里的业务线上得到了规模性的应用，我们决定在内涵段子这个具备800万日活的产品中尝试应用Weex。这样做的主要目的是为了深化对Weex的认识，与React Native进行对比分析，确立IES客户端跨平台方案的下一步研究方向。

一、工程实践

1.1 准备工作

• 开发环境搭建：https://weex.incubator.apache.org/cn/guide/set-up-env.html

• 集成Weex SDK到已有应用：https://weex.incubator.apache.org/cn/guide/integrate-to-your-app.html

• 下载Weex Playground APP：https://weex.apache.org/cn/playground.html Weex Playground APP集成了Weex SDK，它内置了用于展示Weex组件功能的Demo。通过它的扫码功能，还可以加载自己本地Server的Weex代码进行调试（前提是手机和电脑在同一个局域网内）。

1.2 调试

1.2.1 调试环境

在Weex项目中，调试代码的环境有三种：浏览器、Weex Playground APP、自己的应用内。

因为Weex的代码可以同时兼容浏览器、ios和安卓三种运行环境，因此可以在浏览器环境中调试Weex项目代码。在Weex工程中运行npm run dev和npm run serve命令并在浏览器中访问http://localhost:8080即可预览Weex项目效果，如下图所示。但是就目前的状况来讲，Weex对三端的兼容性支持还不是很完善，在浏览器中调试好的代码再放到客户端环境中运行还是有极大的可能会出问题，因此如果最终目标只是想在客户端中运行Weex代码，并不建议通过浏览器来调试。

Weex Playground APP集成了Weex SDK，可以通过它的扫码功能来调试自己的Weex项目代码。项目开始时，如果客户端Weex集成工作还没完成且调试环境还没有准备好，可以使用Weex Playground APP来辅助调试，因为此时项目的主要工作还是编写界面，并不需要客户端扩展功能模块的支持。

项目界面开发完成后，后面阶段的调试工作就需要在自己的应用内进行了，因为此时一般需要客户端扩展的功能模块或组件的支持。例如，获取网络请求通用参数、打点、接收客户端事件消息等。应用内集成了Weex SDK后，在需要调试Weex代码的页面，建议客户端在DEBUG模式下提供刷新页面按钮以方便调试。

1.2.2 DEBUG

在React Native的开发中，可以通过点击开发者菜单中的“Debug JS Remotely”选项来开启JS代码的远程调试。然而在Weex的开发中，开启JS代码远程调试功能的步骤要麻烦一些，需要在应用内集成Weex DevTools工具。由于Weex Playground APP已经集成了Weex DevTools工具，可以使用Weex Playground APP来试验一下如何使用weex-toolkit里面提供的调试工具。

首先，在命令行中运行weex debug命令，该命令会启动一个调试服务器，并同时唤起Chrome浏览器打开调试主页，如下图所示。

然后，打开Weex Playground APP扫描调试主页下方的二维码，即可在应用与调试服务器之间建立socket连接并向调试服务器注册应用信息，如下图所示。

此时，点击上图中的Debugger按钮可以开启javascript代码的远程调试功能，在ChromeDevTools里面对Weex工程的JavaScript代码进行调试；点击Inspector按钮可以查看Weex页面的element属性结构。

如果想使用weex-toolkit提供的调试工具对自己应用内的Weex页面进行调试，必须先在应用内集成Weex DevTools。具体集成方法请参考：集成 DevTools 到 iOS和集成 DevTools 到 android。

1.3 开发

此次Weex应用于内涵的发现页，发现页的UI如下面三张图所示。发现页有以下特征：

• 由热吧和订阅两个列表页组成，通过顶TAB进行切换；

• 热吧和订阅数据一次性加载完毕，无loadmore逻辑，热吧数据大概在200~300条；

• 用户可切换主题：白天模式和夜间模式。

  

1.3.1 组件划分及布局

发现页的页面组成元素比较简单，组件分为轮播图组件、热吧Cell组件以及订阅吧Cell组件。

发现页的文档结构大致如下：

其中值得一提的是实现TAB切换的方式。一般来讲，很容易想到使用vue的条件渲染来实现TAB的切换，如下：

但是这样做会造成TAB切换时列表渲染卡顿，因为热吧列表有200~300条数据，每次切换都重新渲染一次会造成较大的性能消耗。因此，在实现的时候对list采用了绝对定位的布局方式，在TAB切换的时候，将已经渲染好的列表结构在DOM树中保留，只改变列表节点的visibility属性。如下：

1.3.2 客户端支持

(1) 客户端模块

device模块

Method	Description	Parameters	Callback
getCommonNetworkParameters	获取网络请求通用参数	无	commonNetworkParams: Object

event模块

Method	Description	Parameters	Callback
openURL	页面跳转	url:String	无

tracker模块

Method	Description	Parameters	Callback
logEvent	友盟打点	event:String，parameters:Object	无

(2) 客户端事件

Event	Type	Parameters
主题切换	theme	theme：0-白天模式，1-夜间模式
消息红点事件	badge	subscribedBadge：false-不显示红点，true-显示红点
订阅/取消订阅	subscribe	type：false-取消订阅，true-订阅 id：相关吧id
登录状态切换	loginstatus	loginstatus: true-登录，false -退出登录

1.3.3 Weex使用问题总结

如何处理本地图片资源？
Weex image组件不支持本地图片，然而在项目开发过程中经常需要引入一些本地图标文件，例如:

• 关于适配
  Weex代码中的高度和宽度的单位均为px，但是所设置的宽高并不是实际呈现出来的宽高，Weex框架在底层做了针对不同屏幕的适配工作，具体计算公式为 实际高宽 = 代码高宽 * (屏幕宽度 / 750)。所以，在编写界面的时候，最好以宽度为750的设计稿最为标准，否则需要根据计算公式对设计稿上标明的宽高做转换。当需要设置元素的绝对宽高时，需要自行计算。计算时，需要获取以下参数：

• cell组件的appear事件和disappear事件在安卓端引发的性能问题
  在热吧列表，有一个打点需求，就是统计每一个吧Cell的展示时间。为了实现这个打点需求，对每一个吧Cell都监听了appear事件和disappear事件。通过测试发现，当监听了吧Cell的appear事件和disappear事件时，安卓端列表滚动不流畅，会出现明显的卡顿现象。

• slider组件的点击事件在安卓端不触发
  由于Weex提供的slider组件无法满足使用要求，所以基于slider重新封装了一个轮播图组件，结构如下：

• 轮播图组件需要监听点击事件，当在slider组件或slider组件的父组件div上监听点击事件时，在安卓端点击轮播图并不触发点击事件。因此，需要在slider组件的子组件上监听点击事件。 在没有设置loadmoreoffset时，list组件的loadmore事件在安卓端不触发 虽然发现页没有loadmore逻辑，但是在使用weex的过程中对list组件进行了性能测试，使用到了list组件的loadmore功能，因此发现了list组件的loadmore事件在默认情况下不触发的问题。只有显示设置了loadmoreoffset且loadmoreoffset的值大于0时，list组件的loadmore事件才会触发。

• cell组件的scope属性
  使list组件的时候，建议为同种类的cell设置相同的scope属性。Weex内部会缓冲cell，每种类型的cell最多缓冲9个。如果不设置cell的scope属性，weex会认为所有的cell的类型都不一样，会缓冲所有的cell，导致内存占用大。

1.3.4 Weex实现效果

Weex实现的页面操作体验基本上接近原声应用，列表滚动、TAB切换、页面跳转等都十分流畅。效果如下图所示： 

二、实践总结

Weex可以选择使用Vue作为开发框架，开发与调试体验都比较好，接近Web开发体验，但是使用上仍然存在一些问题，例如：

• CSS支持不够完善，有些地方CSS样式的在客户端中的表现与WEB中的不太一致，甚至iOS和安卓端都会存在样式表现的不一致。而且CSS不支持继承，定义CSS样式的时候无法引入变量，这样在实现一些效果的时候十分不方便，例如白天模式和夜间模式；

• 文档资料不够完善；

• 某些内建组件存在使用上的BUG，例如slider组件在安卓手机上无法监听click事件、list组件在没有设置loadmoreoffset的情况下在安卓手机上不触发loadmore事件；

当然，这些使用上的问题都可以解决或通过一定办法去规避。Weex更值得我们关注的问题可能还是list组件的性能问题。在React Native的实践中，我们深受长列表性能问题的困扰，而Weex号称是一套可以构建高性能原声应用的跨平台方案，它在长列表的性能表现上如何呢？我们对此进行了测试和评估，发现Weex在长列表的性能表现上也并不乐观。在列表长度不断增长的时候，Weex的内存占用也是不断增长的，在安卓和iOS上皆是如此。在iOS上，列表在不断向下滚动的过程中，CPU使用率的表现也十分堪忧。以下两张图分别是在列表cell定高和变高下的测试结果【详细测试结果请前往：RN & Weex ListView性能对比评估】：

因此，Weex目前可能更适用于非长列表的场景。由于其体验接近原生应用，比H5要好，可以用于替换端内的一些H5页面或一些需要频繁变动的客户端页面。在这些方面Weex是否可规模投入使用尚待验证，此次在内涵发现页的使用正好可以观察其稳定性。