从调用栈可以看出channel的调用时数据序列化 和 反序列化比较耗时。通过查看FxImage的代码，了解到resumeImage对应的native实现已经为空，flutter侧其实可以省去这一次channel调用。
定位过度渲染
在自动化阶段上报的数据有大量是如下所示渲染阶段的堆栈，无法定位到业务代码。
这是由于Flutter的刷新机制是中心化、异步的渲染机制， 业务层需要刷新界面元素，framework层会先把需要更新的元素标脏，然后等下一次引擎侧的渲染回调，在这次渲染回调中，对之前收集到的脏元素统一做更新。这样的机制导致在抓取渲染阶段的堆栈有大量的Element.rebuild、update方法，都是flutter framework的函数调用栈，而缺失了业务侧代码，只看这些堆栈并不能帮我们定位到卡顿问题。
我们的思路是:通过增加渲染过程中的脏element信息， 根据标脏的element的复杂程度（我们根据元素的深度、长度、子节点数来计算复杂度） 可以帮助我们检测出是否有代码不规范导致刷新范围过大的问题。
通过这个方案，我们定位到详情页快速提问组件过度渲染问题：
查看脏element信息可以看到，打脏的元素复杂度较高。优化方案：提高build效率，setState刷新数据下沉到叶子节点，将每个标签抽离成LabelStatefulWidget，只做局部刷新。
长列表loadmore优化
通过卡顿工具，我们发现搜索结果页列表滑动加载更多过程中会对整个列表容器打脏重建，造成比较严重的流畅度问题。经过分析发现，因为加载更多数据返回后，追加列表数据后会调用setState，打脏容器widget。并且由于我们有做预加载，在滑到底部前几屏时就去触发加载更多的逻辑，导致打脏重建widget的频率更高。一期我们从业务层入手，预加载更多的数据回来并不去调用setState，而先是保存到内存，等滑到底部再去调用setState，重建列表容器。后面我们从列表容器底层去优化，loadmore时不会打脏重建整个列表容器，容器加载和滑动过程有较大的优化，提升体验比较明显。
优化前如下图，（红色区域表示打脏的widget）可以看到刷新了整个容器。
[图片上传失败…(image-88d1df-1607610735943)]
优化后，仅对新增的卡片做刷新
[图片上传失败…(image-d1416d-1607610735943)]
滚动加载小图
feeds流卡片包含大量的图片，在快速滑动过程中，加载大量图片对于内存和IO都是比较大的考验，影响流畅度，在低端机上尤其明显。优化思路：在快速滚动过程中，只加载尺寸较小的模糊图，等到滚动停止后再渐进式的展示原图，并且在超出屏幕区域不加载原图，优化上屏体验。效果如图：（为了演示效果，这里的用的是缩小5倍的小图）
[图片上传失败…(image-853675-1607610735943)]
小结
在经过优化之后，闲鱼详情页和搜索页流畅度 FPS 提升了 3 个点，低端机大卡顿次数降低一半，中高端机型上流畅度提升到 57 或以上，大卡顿次数接近 0。
详情页线上高可用 fps 数据如下：
线上低端机 fps 曲线，横轴表示帧率区间，绿色为优化版本。曲线分布越靠右，流畅度越好。
线上高端机 fps 曲线。绿色为优化版本
搜索页线上高可用 fps 数据如下：
线上低端机 fps 曲线。绿色为优化版本
线上高端机 fps 曲线。绿色为优化版本
在优化流畅度问题之后，再来看下对于页面加载需要做哪些优化。在优化之前，从搜索关键词到搜索结果展示过程中有较长loading。对于页面的加载速度优化，我们更多的从业务流程开始去找突破口，搜索结果页的打开过程如下：
搜索结果页由Flutter实现，但它是从Native页面点击打开，在混合栈的背景下导致路由拦截到打开容器这一步有一定耗时。我们可以通过 URL 携带预取信息，在 Native 进行跳转导航时同时进行异步并行的数据预取，可以减少页面打开的耗时。同时因为搜索页面的请求RT相对比较高，一般页面进来了，还仍然在等待网络请求回来，所以如果在网络请求回来的时候再去做模板的预加载，大概率会命中。
优化之后的流程如下：
通过一定的并行手段，采用数据预取、模板预加载的方案，我们在Android低端机上将搜索结果页加载时长优化300ms。同时在数据请求时展示骨架屏动画（lottie实现）代替小黄鱼loading，带给用户更好的使用体验。
优化前：
[图片上传失败…(image-45c8ba-1607610735943)]
优化后:
[图片上传失败…(image-e347e6-1607610735943)]
对于详情页的加载优化，我们主要通过下面3个手段做优化：
-
FlutterBoost优化
-
数据透传
-
转场动画
FlutterBoost优化
闲鱼目前还是Native+Flutter的混合开发模式，通过FlutterBoost来处理混合栈页面的映射和跳转。在FlutterBoost的open处理中，会通过startActivity()打开一个新的容器，而详情页的跳转场景中，大部分都是从Flutter页面跳转过来的，其实可以复用之前打开过的容器。针对这样的应用场景，我们在FlutterBoost增加了一个新的特性，在Flutter页面打开一个新的Flutter页面时，可以选择两个Flutter页面共用一个Flutter容器（Activity、ViewController）, 以加快页面打开速度、减少内存消耗，并且支持了Flutter实现页面切换的动画。
数据透传
在搜索结果页跳详情和猜你喜欢跳详情的场景中，详情的部分数据已经可以通过上一个接口拿到，我们可以把这部分数据透传带到详情页，在请求详细数据的过程中，先展示简单的内容，比如主图、标题、价格，等详细数据回来后再更新详情页，带来直出的体验效果。
转场动画
在前面数据透传的基础上，我们又通过转场动画，实现沉浸式页面的切换的效果，进一步地提升用户使用体验。
实现思路：在路由导航过程中通过继承ModalRoute接管buildPage过程，对简化版详情页AnimateDetailPage做动画处理，监听动画状态，当动画完成后，再把详情页DetailPage挂到widget树上。
优化前:
[图片上传失败…(image-155316-1607611144523)]
优化后:
[图片上传失败…(image-f9445-1607611144523)]
尾声
评论里面有些同学有疑问关于如何学习material design控件，我的建议是去GitHub搜，有很多同行给的例子，这些栗子足够入门。
有朋友说要是动真格的话，需要NDK以及JVM等的知识，首现**NDK并不是神秘的东西，**你跟着官方的步骤走一遍就知道什么回事了，无非就是一些代码格式以及原生/JAVA内存交互，进阶一点的有原生/JAVA线程交互，线程交互确实有点蛋疼，但平常避免用就好了，再说对于初学者来说关心NDK干嘛，据鄙人以前的经历，只在音视频通信和一个嵌入式信号处理（离线）的两个项目中用过，嵌入式信号处理是JAVA->NDK->.SO->MATLAB这样调用的我原来MATLAB的代码，其他的大多就用在游戏上了吧，一般的互联网公司会有人给你公司的SO包的。 至于JVM,该掌握的那部分，相信我，你会掌握的，不该你掌握的，有那些专门研究JVM的人来做，不如省省心有空看看计算机系统，编译原理。
一句话，平常多写多练，这是最基本的程序员的素质，尽量挤时间，读理论基础书籍，JVM不是未来30年唯一的虚拟机，JAVA也不一定再风靡未来30年工业界，其他的系统和语言也会雨后春笋冒出来，但你理论扎实会让你很快理解学会一个语言或者框架，你平常写的多会让你很快熟练的将新学的东西应用到实际中。 初学者，一句话，多练。
由于文章篇幅问题复制链接查看详细文章以及获取学习笔记链接：前往我的GitHub
