河北省建设机械协会网站,织梦软件网站模板下载地址,怎么优化一个网站,wordpress换logo简介#xff1a; 淘宝特价版是集团内应用Flutter技术场景比较多#xff0c;且用户量一亿人以上的应用了。目前我们首页、详情、店铺、我的#xff0c;看看短视频#xff0c;及评价#xff0c;设置等二级页面都在用Flutter技术搭建。一旦Flutter有性能瓶颈#xff0c;重度…简介 淘宝特价版是集团内应用Flutter技术场景比较多且用户量一亿人以上的应用了。目前我们首页、详情、店铺、我的看看短视频及评价设置等二级页面都在用Flutter技术搭建。一旦Flutter有性能瓶颈重度使用Flutter研发的我们该如何做到性能优化 作者 | 余玠 来源 | 阿里技术公众号
一 Flutter页面性能优化的挑战
淘宝特价版是集团内应用Flutter技术场景比较多且用户量一亿人以上的应用了。目前我们首页、详情、店铺、我的看看短视频及评价设置等二级页面都在用Flutter技术搭建。
我们发现使用Flutter经常会遇到性能问题。因为Flutter严格意义上仅是一种“UI渲染框架”它通过异步来来实现子线程渲染UI并且通过Skia保证两端“渲染的一致性”。但子线程执行并渲染且动态库打包这些策略并非“一片通吃”会导致损耗页面打开性能及可交互时长的增加。试想app启动时动态库加载的dynamic binding影响启动时长页面启动时主线程启动了页面但ui渲染却需要等待Flutter的子线程执行并渲染低端机上页面会短暂白屏页面未渲染影响可交互时长虽然fps欺骗性的提高了。
Flutter有性能瓶颈但重度使用Flutter研发的我们是如何做到性能优化的本篇会就基础链路各Flutter页面的优化策略分享我们的实践
二 模块级混合——首页的优化实践
首页最开始是全部采用FlutterDXFlutter面向Flutter的UI动态化框架实现业务实现一切ok但发版的时候测试同学发现首页的启动性能突然比上个版本跌了1s。这个问题是必然的因为Flutter是动态库要延迟加载和绑定同时DXFlutter大量的模板逻辑也会极大消耗性能。
问题很难解当时我们就是否继续全部Flutter但优化引擎和DXFlutter还是回退为Native实现产生了分歧。如果回退Native则首页及搜索的分类tab技术方案都要切回native成本巨大。最终我们根据特价版的现状及经验拍板采用app启动时首页推荐等采用Native实现但搜索实现的其他tab分类继续采用Flutter如此不会对搜索业务研发模式产生影响又能避免Flutter带来启动性能的损耗。
但是该方案会遇到一个技术挑战我们使用的Flutter混合栈FlutterBoost仅支持页面级混合还不支持页面内模块级混合。因为Flutter是单window的设计策略如果模块级混合必然会遇到Flutter页面生命周期的管理及渲染窗口尺寸的一致性问题。
前一个问题是因Flutter是单引擎引起的。当模块切换的时候新模块显示需要连接引擎重新触发渲染否则页面会空白或不可交互。这个在FlutterBoost中早就做了。
后一个问题是单windowFlutter页面上弹框Native页面都会导致页面布局问题。
但模块级混合明显是技术可行的我们在AliFlutter正物、来一等同学的参与下很快就开发出了可以容纳Native、Flutter甚至其他类型如WebView的模块级混合容器。如下图 我们通过一个FlutterWrapperVC基于FlutterBoost解决单引擎渲染问题根据模块可见性切换FlutterEngine和虚拟机保证当前可见的模块能正常渲染并执行底层的Flutter代码然后通过Window大小强制修正解决了单window问题解决布局问题。最后我们也考虑到了模块复用性将这个能力组件化并封装到这里LTaoUIKit。
pod LTaoUIKit 0.0.3.89基于这个方案之后这么改造后首页的启动实践至少提升1s。更重要的是首页的研发就如围棋里建了两眼活出了一片。后面推荐页基于native dxcontainer实现后就直接可以复用之前淘宝等成熟app的优化经验。
后面我们优化RTDX模板打底图标本地化图片压缩多管其下首页启动性能稳稳提升。
同事后面对首页的启动链路做了分步治理并做了较为体系化的治理建设 三 数据预取与FFI——纯Flutter页面的优化实践
上面探讨模块混合Flutter页性能优化本节则讲整个页面均是Flutter实现的优化策略这应该也是大部分Flutter开发者常遇到的。通过这种方式以特价版详情页为例我们在之前的优化结果上又再优化了100多ms以下是具体数据
Android(vivo y67): 80100msiOS(iPhone6): 120~200ms
首先Flutter页面会遇到哪些性能瓶颈从Flutter机制看他其实是个能较好解决“多端一致问题”的“UI渲染框架”虽然提供了通过bridge访问native但Flutter bridge性能极差涉及到了线程切换字符编码等问题后面会讲。所以我们使用Flutter应该避免直接通过Flutter来解决IO等资源访问的工作而且这些工作应尽量放在native侧。
显然app一张页面的启动往往涉及到请求服务端准备渲染数据。同时从路由跳转到通过Engine初始化Native的VC或者activity到Engine构造Rasterrizer还涉及Engine层面的线程等待。这些时间其实可以做不少事情我们可以将服务端数据请求放在这个阶段这就是我们希望做的“数据预取”。
其实“数据预取”在淘宝上已经大规模用了但在Flutter页面上所显示的优越性则会更强因为Flutter页的多线程切换太多了很容易就掉入channel bridge的陷阱。如我们详情页最开始也用了数据预取但数据预取调用是从Flutter发起的性能似乎有提升但并不那么明显。为什么以下是从Flutter发起一个mtop请求的流程图可以从其中一窥究竟 上图UI线程是指Flutter的ui线程并非系统主线程。请求从“开始”处开始兜兜转转要经历2次线程切换等待多次的数据encode和decode造成的性能损耗还是蛮多的分析如下
首先一旦某个情形下设备cpu紧张则Flutter的请求/数据返回会迟迟无法送达到native或者Flutter。其次当数据量大的情形下数据encode和decode也会耗费更多时间。最后页面打开经常遇到Engine和Native之间谁先启动的问题。比如VC启动了这个时候并不能马上就给Flutter发送message因为Flutter Engine可能还没有准备好此时message丢失双方都不知道。这个问题在FlutterBoost中遇到不少。
我们最终通过以下策略来解决
数据预取在Native侧发起在页面路由构造Native VC/Activity时就马上发起mtop等请求。mtop返回的数据优先不通过channel bridge返回给Flutter层而是通过ffi机制供Flutter直接读取。上面native侧必须暂存数据但为避免长久引用造成资源泄漏采用LRU策略缓存数据iOS不能用NSCache猜猜为什么。考虑到有些页面数据可以持久化存储供下次使用我们构造了多级缓存策略。将上面能力全部组件化以供其他业务复用。
详细的设计如下
首先基于ffi和native侧数据预取优化后的数据请求链路如下 右上角之所以还有channel bridge是为解决Native请求返回慢于Flutter页面渲染的情形下的数据刷新。
其次我们构建了多级缓存策略和缓存失效及复用策略以支持部分页面数据的持久化复用提升首屏渲染性能 以缓存复用策略为例我们支持以下策略
激进型第二次请求直接使用上一次缓存数据不再马上刷新数据待缓存自然过期后刷新。该策略适用于页面数据不常变的情形。正常型第二次请求可使用上一次缓存但仍需请求并马上刷新数据。该策略比较普适适合数据变化不频繁的情形。保守型第二次请求不可使用上一次缓存需请求最新数据。适合强实时性的页面数据渲染。
最后我们将这些能力做了封装比如iOS侧我们以单独的SDK集成
pod LTPrefetch 1.0.1.19目前基础链路如详情我的店铺mini详情等都采用了这个方案进行优化启动实践均有了不错的提升。
四 其他优化实践
其他还有很多优化实践。有些是淘系已经实践过的有些是特价版根据Flutter的特点有所改动的。这里不详细说了仅就我们使用过的列个列表
详情从首页借图。资源压缩及本地预置如首页dx模板预置Json压缩及预置图片压缩及预置。数据提前异步加载。如我的页面数据其实在用户登陆的时候就会异步加载并缓存下来然后通过上面的缓存更新策略来更新。优化服务端RT精简协议。其他。
五 最后
其实我们的优化策略更多在上层应用上做了优化UC那边在Flutter Engine层面做了优化后期可以考虑使用他们引擎相信页面打开性能会更上一层楼。
同时上面的ffi及数据预取也可以做的更激进一些。如通过Dart2Native的方式完全实现Json数据的encode和decode本地实现容器访问的本地实现估计还能提升至少50ms的时间。
原文链接
本文为阿里云原创内容未经允许不得转载。
