这只是小程序用户体验优化的一个小小案例，优化方案也需要根据各位读者自己的实际情况具体问题具体分析。
0x00 源起
发布的线上版本
这张动图展示的是我们正式发布的小程序“相生一课”点击课程列表项进入课程详情页的加载过程。从点击跳转到最终显示出页面需要 5-6 秒时间。这简直令人发指有没有？大 boss 发话了，用户体验第一位，必须立刻、马上改掉。
嗯，于是我们马上开始排查。
0x01 排查步骤
由于小程序的开发基本是参照官方文档进行操作的，到目前为止也没有什么第三方工具，前端导致瓶颈的可能性被我们暂时排除了。所以我们的第一怀疑目标就到了网络接口上。
1. 接口数据排查
小程序上需要获取到服务器数据以后再进行视图的填充和渲染，网络请求接口返回数据过慢，会导致从跳转到页面显示的过程变慢。
在微信 web 开发工具中打开调试页面，查看 network 标签页。我们发现这个页面共请求了 6 个接口（下图中前两个接口是其他页面的），其中有 2 个返回的数据量比较大，耗时也比较长。
课程详情页面
- 课程章节列表，返回 12.7KB 数据，耗时 834ms。
- 课程详情内容，返回 10.2KB 数据，耗时 332 ms。
接口确实很慢。
这两个接口都返回了 10KB 以上的数据，需要考虑减少数据返回。
课程详情内容
现在课程详情内容确实比较多，这需要从内容运营人员那边入手，技术上暂时无法调整了。
课程章节列表
我们发现服务端接口本身似乎是支持分页的，但是现在小程序是一次性获取了所有的课程章节数据。解决方案有了：调整产品的交互方式，章节列表分页加载，可以滑动到底部加载更多，减少每次接口请求获取的数据量，加快接口返回。
2. 业务代码排查
接口上发现了部分问题，可是不对呀。从点击到页面显示等待了 5-6 秒。所有接口就算串行请求也不过 2 秒多，一定还有其他原因。
于是，我们开始检查小程序上的代码实现。
检查接口的请求处理逻辑
进入这个页面发起了 6 个接口请求，如果请求不是以异步的形式发起，那么在同步请求的情况下，所有数据的获取时间会是每个接口返回的时间叠加。如果没有在请求数据返回时就显示相应的视图，而是所有数据都返回时才更新页面。这两点都会造成界面显示出来的时间过长，是用户觉得慢。
以异步形式发起请求
小程序官方提供的网络请求 API 本身是以异步形式执行请求的。大部分小程序开发者应该是以这种方式裸跑的。
我们对其进行了简单封转，每个请求返回 Promise 对象，这样代码书写上多个请求可以组合。书写上确实方便了，但错误使用对导致打包在一起的请求中，返回时间最长的那个会成为瓶颈。
经排查，这 6 个接口是分开异步请求的。
一个接口返回数据以后就处理其相应的视图逻辑
前端视图是需要数据进行渲染的，相关性强的数据可以归到一组。这是接口设计的依据之一，一组数据通过一个接口返回。
从产品设计上看，课程基础数据、课程详情内容、课程章节列表是这个页面最主要的数据，并且这 3 块数据在视图上有明显的区分。
- 页面顶部显示的是课程基础数据。数据量少，接口很快就返回了。
- 课程详情占用一块独立的区域，在第一屏可以看得到。数据量比较大，接口返回耗时。
- 课程章节列表占用一块独立的区域，在第一屏看不到。数据量比较大，接口返回耗时。
我们可以在课程基础数据返回时先显示课程的基础数据；接着课程详情返回时再显示课程详情；但滑动到课程章节区域时，在进行加载并显示。
通过产品设计上的改进，极大缩短了用户看到页面内容的时间。
产品设计修改
然后我去倒了杯水，继续...
3. 更进一步
进入课程详情页面的时间确实加快了，但是优先显示了课程基础信息，课程详情的加载还是非常地慢，并且大大超出了接口返回时间。更严重的是，课程详情加载过程中，点击页面上的按钮暂时没有响应。知道课程详情加载完，才出现按钮点击的响应。
这说明主线程发生了阻塞。请求都是异步发起的，莫非请求返回以后的处理出现了阻塞？我们定位到了这两行代码：
var weappDetail = getApp().httpReplace(weapp_detail);
WxParse.wxParse('article', 'html', weappDetail, self, 5);
课程详情内容是富文本格式的，小程序上使用第三方 WxParse 组件进行渲染，在小城官方没有出 <rich-text /> 组件前一直是富文本解析与显示的首选方案。经测试这行代码的处理耗时近 3 秒。
罪魁祸首找到了，我们考虑很多方法来优化，最后打算换官方 <rich-text /> 来试一下。没想到这一试就停不下来了。
直接上效果图：
产品设计修改
是不是如丝般顺滑？我们也一下子变得自信起来！
<rich-text /> 使用注意事项：
-
<img />标签显示的图片是原图大小，可能超出屏幕显示区域。这个为<img />加上 style 就可以解决了。 - 暂时不支持
<video />等标签。这从产品、内容上考虑解决方案。 -
<rich-text />是基础库 1.4.0 以后开始支持的，需要做低版本的兼容。 -
<rich-text />中的图片无法单独点击放大查看。
目前就这些，其他问题也请读者进行反馈。
WxParse之所以这么慢，可能是因为我们要渲染的富文本内容太多了，并且其中有大量图片。少量富文本内容时还是可以的。
0x02 总结
这篇文章中发现的小程序加载慢的原因有：
- 网络接口返回数据慢
- 接口响应慢
- 数据传输量过大
- 多个接口没有异步获取数据
- 网络接口数据返回后没有在合理时机更新视图
- 数据解析慢
相应的解决方案：
- 优化接口反应速度
- 减少接口返回数据量
- 列表数据分页加载
- 产品设计上减少必须内容
- 分成多个接口
- 编码时使用异步方式请求接口
- 优化产品的显示逻辑，做相应编码调整
- 使用合适的富文本组件
0x03 写在最后
以上提到的产品用户体验的优化，技术层面可以提升，产品设计层面也可以提升。作为技术人虽然可能比较擅长从技术层面出发，对于产品层面也是应该学习和思考的。
如果你看完本文有收获，欢迎关注微信公众号：非典型程序员（ID：up2048），更多技术干货等你一起学习与交流。
- EOF -
网友评论