外贸网站用wordpress,wordpress数据文件,广告模板制作,电商型网站前言
出于多端投放和开放生态的考虑#xff0c;闲鱼开始接入整个阿里小程序体系。闲鱼在9月份迅速上线了第一个小程序鱼塘小程序#xff0c;由于刚接触不熟悉小程序体系#xff0c;整体性能上有比较大的优化空间#xff0c;主要表现在以下问题#xff1a;
小程序加载慢闲鱼开始接入整个阿里小程序体系。闲鱼在9月份迅速上线了第一个小程序鱼塘小程序由于刚接触不熟悉小程序体系整体性能上有比较大的优化空间主要表现在以下问题
小程序加载慢低端 Android 机Android vivo Y67上首屏时间接近6s滚动卡顿在 iPhone 7P 上滚动帧率平均在 40fps 左右滚动多屏数据之后 Tab 点击切换慢在 iPhone 7P 上切换 Tab 等待时间 3-5 秒瞬时帧率低于 30fps 小程序由于其逻辑和渲染分离的架构特点除传统 H5 优化手段之外还有其他不同点。本篇文章主要分析小程序构架对渲染的影响以及鱼塘小程序下具体优化手段。
小程序架构
在分析具体优化 Case 之前我们先看下小程序架构先要了解架构才能清楚如何去优化具体的业务代码。阿里小程序采用支付宝小程序的架构这里引用一张支付宝小程序页面生命周期图。 目前市场上所有小程序都采用逻辑worker和渲染webview分离的方式。这样带来的好处是
能够满足对于外部应用管控的诉求由于业务逻辑没有运行在 webview 上所以无法通过浏览器的API直接操作渲染动作意味着不能通过脚本做一些动态化操作。所有渲染相关操作都是通过 axml 来定义外部应用进行更改都需要通过平台审核。多个页面可以共享同一个 JS 运行环境整个小程序生命周期可以共享全局应用上下文接近 App 的开发体验。页面渲染与业务逻辑分开执行不会出现 JS 逻辑执行导致渲染卡住的情况有利于提升整体渲染性能。
但是这样也会造成一个显而易见的问题页面性能强依赖 webview 和 worker 的通信效率
webview 和 worker 之间的通信是异步的。这意味着当我们调用 setData 时数据变更不会立即体现到页面渲染上而是需要从 worker 异步传输到 webview 。数据传输时需要序列化为字符串然后通过 evaluateJavascript 方式传输数据大小会影响传输性能。
小程序逻辑和渲染分离的架构造成它与传统 H5 性能优化方式上的一些差异。小程序性能优化可以参考看下官方推荐的一些性能优化建议简单来讲需要特别注意 setData 操作的频次和传输数据接下来我们结合鱼塘小程序具体案例一块探讨下。
业务层优化
鱼塘小程序是一个类似兴趣圈子下的内容聚合场景用户在这里可以无限加载浏览内容还会点击 Tab 切换浏览不同维度的内容。我们需要重点考虑小程序加载流畅度、滚动顺滑度以及 Tab 点击切换时候界面响应速度。之前版本的鱼塘小程序在低端 Android 机Android vivo Y67上首屏时间接近6s在 iPhone 7P 上滚动帧率平均在 34fps - 60fps点击 Tab 切换瞬时帧率在 30fps 左右下面针对几个具体 Case 讨论解决方案。
加载慢
『BEFORE』 『AFTER』 问题表现
从打开小程序到最终渲染出来经历了短暂的白屏
原因分析
加载整体耗时包括小程序容器初始化、数据请求以及请求结果返回到渲染需要针对每个时期做优化
优化手段
引入小程序实例保活机制降低小程序启动耗时将数据请求提前至 page.onLoad 中请求阶段加入闲鱼 Loading 提示通过交互减少用户焦虑感首屏数据离线化在首屏数据到达前预渲染在容器测请求提前至与小程序实例启动并行或更前将首屏数据进行拆分初始化只 setData 可见视图对应的数据
滚动卡顿
『BEFORE』 『AFTER』 问题表现
页面滚动掉帧感明显粘手度低
原因分析
由于需要监听页面滚动距离触发顶部 Bar 显示Page 层监听了 onScroll 事件并在回调中频繁的调用 setData加载下一页 Feeds 的请求回调中解析数据时多次调用 setDataFeeds 卡片内部监听了组件的 onAppear 和 onDisappear 事件并在回调中调用 setData目的是为了不重复发送曝光埋点
优化手段
针对小程序 webview 和 worker 通信的机制我们需要减少 setData 的调用频率与传输数据大小。
优化了 onScroll 回调逻辑改为只有在部分时机滚动距离在一定范围内下才会触发 setData且只做局部渲染加载下一页 Feeds 的请求回调优化了数据解析逻辑只调用一次 setData并参考官方优化建议使用 $spliceData 渲染长列表将 setData 的数据大小进行优化只传输会影响视图的相关数据不再监听组件 onAppear 和 onDisappear 事件改为监听组件的 onFirstAppear 事件只有第一次 Appear 的时候才执行曝光操作
Tab 切换响应慢
『BEFORE』 『AFTER』 问题表现
加载几页 Feeds 后切换 Tab 开始出现明显卡顿需等待 3-5 秒部分 Android 机器上更为严重偶尔会 Crash
原因分析
Tab 切换时在短时间内做了太多事情切换 Tab Current 状态、销毁 Feeds 列表、展示 Loading 动画、发起数据请求 - 渲染新列表这样高并发大面积的内容更新导致小程序视图层数据消费阻塞从而产生卡顿感。
优化手段 将 Tab 切换时的任务拆解开分四个阶段进行 切换 Tab Current 状态执行 Tab 切换动画在 Tab 切换动画完成后将页面滚动到 Tab 刚好 Sticky 住的位置销毁 Feeds 列表展示 Loading 动画发起数据请求 - 渲染经过这样的拆解将之前的『高并发大面积』转换成了『分阶段可控制』的更新方式随之带来的就是界面上的流畅
容器层优化
小程序容器通过离线缓存、数据预加载、小程序保活等机制来优化整体性能。然而在富交互场景中webview 上的控件渲染会遇到很多性能瓶颈目前阿里小程序支持在 webview 中内嵌 native 组件来提升整体性能鱼塘小程序中有大量视频内容场景使用的 video 组件就是 native 原生组件。这类组件脱离 webview 线程之外渲染但是由于是覆盖在 webview 之上所以在 webview 内无论怎样修改 z-index 都无法将元素覆盖在原生组件之上。
为了解决这个问题小程序框架同学又设计了 cover-view 它可以覆盖在 native 组件之上比如视频上方的播放按钮就可以用 cover-view 盖上去。最终线上鱼塘小程序通过同层渲染 video 组件之后用户侧体验有比较大的提升。
总结与展望
经过优化之后目前线上鱼塘小程序相比之前版本有显著提升 针对这个业务场景下的小程序依然有很多可以继续优化空间例如我们将每个鱼塘实例化独自小程序这样可以针对每个鱼塘小程序去进行保活等。此外在小程序性能优化相关上我们认为可以在研发阶段提供一个包含性能告警的容器通过监听 setData 的调用频率与传输数据大小对开发者一些可能会影响性能的代码写法进行提示。未来我们会持续在闲鱼小程序生态建设上发力整合集团研发资源建立闲鱼小程序研发全链路最佳实践提供外部服务商入驻开发三方小程序的良好体验。 iPhone 11 Pro、卫衣、T恤等你来抽马上来试试手气 https://www.aliyun.com/1111/2019/m-lottery?utm_contentg_1000083877
原文链接 本文为云栖社区原创内容未经允许不得转载。
