一文告诉你：闲鱼是怎么面向Flutter做技术体验升级的？

但是随着业务快速迭代，开发者往往会疏忽大意，写出低性能的代码。理想情况是，通过性能分析工具自动定位到问题代码，及时修改。Flutter官方提供了Devtools性能分析工具，它的timeline界面可以逐帧分析应用的UI性能，cpu profiler界面来抓取卡顿过程中的耗时操作。在研发阶段，我们可以使用这个工具来分析本地可以复现的卡顿问题。但是，Devtools的局限性在于：

• 只能用于在出现卡顿问题后去分析，无法做到监控卡顿问题。

• 只能用于线下排查，对于线上反馈卡顿问题，因为没有足够的场景，也无能为力。

为此我们需要建设一个Flutter卡顿工具，用于在线上线下监控定位造成卡顿的耗时函数。实现思路：我们知道release模式下的Dart代码是基于AOT编译的，业务代码和sdk都会编译成平台相关的机器码，所以我们是可以通过信号机制抓取native的堆栈，再通过符号化还原的方式来获取flutter堆栈。

我们通过卡顿工具定位排查出两类造成流畅度低的问题：耗时函数和过度渲染问题。

定位耗时函数

对于耗时函数导致的卡顿问题，可以通过查看堆栈定位到耗时函数。

从调用栈可以看出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实现页面切换的动画。

数据透传

总结

【Android 详细知识点思维脑图（技能树）】

我个人是做Android开发，已经有十来年了，目前在某创业公司任职CTO兼系统架构师。虽然 Android 没有前几年火热了，已经过去了会四大组件就能找到高薪职位的时代了。这只能说明 Android 中级以下的岗位饱和了，现在高级工程师还是比较缺少的，很多高级职位给的薪资真的特别高（钱多也不一定能找到合适的），所以努力让自己成为高级工程师才是最重要的。

这里附上上述的面试题相关的几十套字节跳动，京东，小米，腾讯、头条、阿里、美团等公司19年的面试题。把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。

由于篇幅有限，这里以图片的形式给大家展示一小部分。

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

最后，赠与大家一句话，共勉！

面试题相关的几十套字节跳动，京东，小米，腾讯、头条、阿里、美团等公司19年的面试题。把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。

由于篇幅有限，这里以图片的形式给大家展示一小部分。

[外链图片转存中…(img-erLIjNW2-1643887712390)]

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

最后，赠与大家一句话，共勉！

本文已被CODING开源项目：《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》收录