滑动速度和滑动状态：idle（停止）、drag（手指拖拽）、fling（自由滑动）都是影响流畅度数据的重要因素。
2.2 流畅度指标制定
维基百科 动画定义：一种通过定时拍摄一系列多个静止的固态图像（帧）以一定频率连续变化、运动（播放）的速度（如每秒16张）而导致肉眼的视觉残象产生的错觉——而误以为图画或物体（画面）活动的作品及其影片技术。
列表滑动同理，是 APP 以一定频率（60hz下16.6ms）和不同 offset 计算出一系列静止画面，让肉眼看到滑动动画。
当我们说列表滑动不流畅，是因为频率过低无法让肉眼产生视觉残留，或在时间（画面停留时长）和空间（画面内容）产生跳变，让用户感知到变化的不自然。以此我们可以定义指标如下：
- 时间角度
- 定义平均 FPS：定义一次检测的平均帧率。反应画面平均停留时长。
- 定义 1s 大卡顿次数：平均 1s 内出现占用 3 帧及以上的画面次数。反应画面停留时长跳变
- 空间角度
- offset 跳变值：在画面不掉帧的情况，若其中一个画面出现跳变，甚至花屏或者绿屏会让用户体验到不流畅。在 APP 滑动过程中，画面内容由 offset 决定，而 offset 跳变，和卡顿时长、差值器实现均有关联，现有差值器实现基本基于 D/T 曲线（距离/时间），为此平均 FPS 和 1s 大卡顿次数很大程度上体现了画面跳变，同时考虑到无侵入式检测 offset 的难度问题，暂不考虑 offset 跳变值。
综上，我们定义流畅度指标为平均 FPS 值和 1s 大卡顿次数。
2.3 流畅度检测工具实现
我们从 APP 录屏画面入手，计算流畅度指标值。当我们得到 APP 滑动过程中的录屏数据，可通过每 16.6ms 检测录屏画面是否发生变化，当连续画面未发生变化，则表示发生了卡顿。无变化的连续画面数则表示了卡顿的时长。
为得到目标 APP 录屏数据，检测工具 APP 向系统注册录屏服务，然后在检测工具 APP 的帧回调中不停读取录屏画面，并和上次检测画面 hash 值进行比对。
- 检测工具 APP 和目标 APP 进程隔离，为此目标 APP 发生卡顿并不影响检测工具 APP 的帧回调
- 为保证每次录屏画面读取和 hash 值计算在 16.6ms 内完成，需根据高低端机型调整画面宽高压缩比。
为排除滑动操作对流畅度数值的干扰，我们使用脚本操作检测工具 APP 和目标 APP 的滑动。自动化脚本原理为使用 adb 命令操作手机
点击：adb shell input tap $x $y
滑动：adb shell input swipe $x1 $y1 $x2 $y2 $duration
2.4 检测工具演示
流畅度检测工具 APP 以悬浮框的方式显示，下面为目标检测 APP：
流畅度检测工具界面
2.5 小结和展望
在流畅度指标方面，我们定义了平均 FPS 和 1s 大卡顿次数作为指标，更好的反应了用户体验。 在流畅度检测工具方面，我们实现了无侵入检测工具，支持以下特性：
- 无侵入
- 支持检测第三方 app
- 支持多平台：native，flutter，h5，小程序
- 多维度数据：平均 FPS，平均 1s 大卡帧次数，帧分布直方图，帧分布均方差
- 自动操作，避免人为操作差异
此外，流畅度检测工具还有一些不足之处
- 列表中有视频卡片
- 停止滑动时，若列表中有视频播放，由于画面一直在变化，检测工具无法判断是滑动停止；同时，由于视频 fps 值为 30 左右，会导致流畅度数据偏低
- 如何避免：检测过程中，需保证列表滑动不停止
- 低端机（y67）真实 fps 计算存在偏差
- 为保证低端机上（如 vivo y67）上计算大图像 hash 值在 16ms 以内，录屏画面压缩较大（宽度压缩 100，高度压缩 10），为此在大量空白或者大色块的场景下，无法检测到画面的细微变化，fps 计算存在偏低。
- 如何避免：避免低端机上检测大量空白或大色块的场景
3 原生 Android 长列表优化
Android 原生长列表优化已经非常成熟了，在工具方面有 traceview、blockcanary、DDMS、Android Profile 等。常见优化手段也很多：布局层级优化，过度渲染优化，频繁measure、layout优化，UI 线程耗时方法优化、冗余资源资源加载优化等，这里不再赘述。
除此之外闲鱼使用以下 2 点优化首页
3.1 异步构建视图缓存池
通过工具检测或耗时打印，发现列表初始滑动和 loadmore 时触发 item 视图构建耗时严重（RecyclerView.onCreateViewHolder）
查看首页显示和初始滑动流程，可以发现流程中其他 UI 操作过程和等待用户操作过程均有优化空间。
利用 AsyncLayoutInflater 原理异步构建视图缓存池，优化首页列表流程如下：
其中视图缓存池构建完成的时机在不同机型下不同，可能在列表首屏多卡片构建之前，或构建中，或在用户滑动操作之前完成，或一开始构建就抛出错误停止构建
注意：不能直接使用 AsyncLayoutInflater，AsyncLayoutInflater 在异步构建失败后有一个降级到 UI 线程构建的逻辑，为避免降级逻辑发生导致缓存池在 UI 线程构建，导致页面更加卡顿，需要移除这个降级逻辑：出现异步 inflater 失败，停止缓存池构建。
3.2 ViewDataUnbinder 快速抽离 UI 操作
在卡片数据绑定阶段（RecyclerView.onBindViewHolder），在低端机上耗时较为严重，原因是在卡片数据绑定方法中，而 UI 和非 UI 操作糅合在一起，由于 UI 逻辑必须在 UI 线程执行，最终导致全部逻辑只能在 UI 线程执行。
能想到定义视图数据层，将 UI 和非 UI 操作分离开，然而实际编码发现业务代码改动量大且容易出错，AB 测试逻辑难以实现。那有没有更好的方案，用最少量代码抽离 UI 操作呢？
核心思路：编译期根据视图类自动生成 ViewData 类，并替换视图类实例。ViewData 类和视图类拥有相同的关键方法签名，方法执行时记录视图操作，统一切换到 UI 线程执行视图操作。
具体使用代码样例如下
- 注解视图类
使用 ViewDataAnno 注解视图类，UIMethodAnno 注解 UI 操作方法。
其中注解说明>
- 生成 ViewData 类
- 业务代码修改
- 修改视图变量为 ViewData 类型
- 原视图数据绑定逻辑放置后台线程
3.3 优化结果
闲鱼首页，在恢复内容上屏速度（流畅度降低）后提升流畅度
4 Flutter 复杂长列表优化
flutter 一直以高性能被大家所认知，参考 Flutter 是如何做到性能直逼 native 的?，这也是闲鱼当初选择 flutter 的一个重要原因。而在闲鱼的实际 flutter 页面，如商品详情页和搜索结果页，长列表滑动流畅度体验却不尽人意。
4.1 工具使用和常见优化
做性能优化前，需要理解 flutter 的渲染原理，如 Widget、Element、RenderObject 三棵树结构、Widget 到屏幕显示过程等，可参考 超详解析Flutter渲染引擎， 复杂业务如何保证Flutter的高性能高流畅度？。
针对性能问题，首推官方性能分析工具并结合使用 profile 模式查看性能问题，参考 Flutter Performance 分析工具简介。
Profile 模式只能在真机上运行，不能在模拟器上运行：基本和 Release 模式一致，除了启用了服务扩展和 tracing，以及一些为了最低限度支持 tracing 运行的东西（比如可以连接 observatory 到进程）。命令 flutter run --profile 就是以这种模式运行的，通过 sky/tools/gn --android --runtime-mode=profile 或者 sky/tools/gn --ios --runtime-mode=profile 来 build。因为模拟器不能代表真实场景，所以不能在模拟器上运行 引自：Flutter性能调优、复杂业务保证Flutter的高性能高流畅
4.1.1 检查 widget rebuild 情况
Android Studio 上 View → Tool Windows → Flutter Performance 打开检测 Widget rebuild 情况，可以发现 FDButtonBar 被频繁重建，然而查看视图内容并没有发生变化。查看代码定位到 reducer.dart 中会根据滑动事件更新 state 中的 scrollPercent，进而产生重建。而在详情页中，scrollPercent 在 Widget 构建中并未参与使用。
闲鱼页面中使用了 fish-redux，在 reducer.dart 的方法中返回不同的 state 对象则表示需要重建 widget
// reducer.dart
// 滑动事件监听
static BottomBarState onScroll(BottomBarState state, Action action) {
…
return state.clone()…scrollPercent = scrollPercent;
…
}
4.1.2 使用 fish-redux 性能日志
fish-redux 是闲鱼研发一套在 flutter 上的 redux 框架，闲鱼 APP 中有广泛应用。fish-redux 中自带性能日志，源码查看 performance.dart，若需要打印 profile 或 release 模式下的性能日志，可自行修改源码。
闲鱼详情页滑动时，查看 adb 日志，可以发现大量的滑动广播通知，且存在耗时 1ms 以上事件处理。
11-15 15:03:43.684 27076 27271 I flutter : CommonBuyDetailPage performance: ItemBodyAction.onScrollBroadcast 261
11-15 15:03:43.701 27076 27271 I flutter : CommonBuyDetailPage performance: ItemBodyAction.onScrollBroadcast 1933
11-15 15:03:43.716 27076 27271 I flutter : CommonBuyDetailPage performance: ItemBodyAction.onScrollBroadcast 371
profile 模式下时间日志
因为详情页中存在视图间联动，如标题栏的显示隐藏渐变，问卖家的显示消失均需要根据滑动事件做判断。结合业务逻辑，可以发现，除了问卖家外，其他视图在滑动超出 600 之后，收到滑动事件后不会发生视图内容变化；而问卖家在滑动超出更大的一个值后会永远消失不显示，在一开始未超出这个值时，仅需要判断滑动方向即可。基于以上业务背景，在滑动超出 600 后，若问卖家是不再显示状态，则不发送滑动事件；否则仅在开始滑动的 30 距离内发送事件。
此外，可以利用 fish-redux 的特性：若 reducer.dart 中返回新的 state 对象则表示 widget 重建，检查全部的 reducer.dart 文件内方法实现，排查可能发生的无效 widget 重建。
4.1.3 优化 ClipPath 和 ClipRPath
使用 Timeline 查看渲染线程性能消耗，可以发现有多个 ClipRectLayer 和 ClipRRectLayer。
打开 Debug flag debugDisableClipLayers 和 debugDisablePhysicalShapeLayers 重新检查视图，可以发现部分 ClipRectLayer 是因为图片内容超出视图边界产生，部分 ClipRRectLayer 是因为卡片 Widget 圆角设置以及基于外接纹理的图片控件里设置了 ClipRRect 设置（即便 radius 为0也会设置）
理解原理后，我们对闲鱼图片控件新增参数，支持图片内容圆角设置和图片内容宽高裁剪，使 native 层生成的 Bitmap 已经满足圆角和宽高比要求。同时修复 radius 为0也会设置 ClipRRect 的问题。优化后的 Timeline 图如下：
4.1.4 其他优化建议
flutter 性能优化相关的优秀文章很多，本文不再对类似的排查和优化手段做赘述，这里做下简单汇总：
- widget build 优化
- setState 状态刷新位置尽量放置于视图树的低层级
- Provider 中获取 Model 的方式会影响刷新范围。推荐使用 Selector 或 Consumer 来获取祖先 Model，以维持最小刷新范围
- 对于长列表，避免使用 ListView() 构造函数，推荐使用 ListView.builder 构造函数
- reducer 中，state 对象中的视图数据真正发生变化的时候，新建 state 对象
- 主 isolate 优化 5. 减少或延迟 widget build 中非视图逻辑，如曝光埋点延迟到滑动停止聚合触发 5. 列表 Item 高度可知的情况下，推荐设置 itemExtent，减少滑动中频繁计算列表高度 5. 使用 const 修饰无需变更的 widget 或普通对象 5. 使用 AnimatedBuilder 时，避免在不依赖于动画的 widget 的构造方法中构建 widget 树。动画的每次变动都会重建这个 widget 树。而应该构建子树的那一部分，并将其作为 child 传递给 AnimatedBuilder 5. 避免在动画中剪裁。如果可能，请在动画开始之前预先剪切图像
- Render 线程优化 10. 对于频繁更新的控件（如动画），使用 RepaintBoundary 隔离它，创建单独 layer 减少重绘区域 10. 使用图片替换半透明效果 10. 减少 saveLayer（ShaderMask、ColorFilter、Text Overflow）、clipPath的使用，提升 render 线程性能 10. 避免使用 Opacity widget，尤其是在动画中避免使用。请用 AnimatedOpacity 或 FadeInImage 进行代替 10. 避免使用带换行符的长文本
- 工具推荐 15. 官方 DevTools 工具 15. 利用 Debug flags 排查问题（推荐 Flutter Performance 分析工具简介） 15. 善于利用框架日志，如 fish-redux 性能日志
4.2 列表 element 复用优化
flutter 列表控件划分为可视区域和 Cache 区域，往下滑动时 element 从底部被创建进入底部 Cache 区域后，再进入可视区域，再进去顶部 Cache 区域，最后被销毁。往上滑动逻辑类似。在不使用 keepAlive 的情况下，来回滑动，曾经创建过的 element 需要重新创建。而在我们的业务中，列表 item Widget 结构是接近的，此时如果能根据类型复用 element，就能一定程度的提升性能。
列表控件源码见 sliver_list.dart 中 RenderSliverList.performLayout() element 缓存在 _childElements 数组中，以 index 为索引。源码见 sliver.dart 若 item Widget 结构差异很大，即便复用了 element，Element.updateChild 方法内部最终还是执行了 inflateWidget 方法，对于性能提升就没什么价值了
我们构建 index → ${widget.key} → List<element> 的映射关系：在 widget 创建处建立 index → ${widget.key} 映射，在 element 应该被销毁移除的逻辑处，将 element 缓存至 ${widget.key} 映射的 List<element> 处（注意 renderObject 对象需要从父节点移除）。列表滑动过程中，优先根据映射关系找到缓存中的 element 并使用（注意更新 element.renderObject.parentData 中的 index 值）
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级安卓工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Android移动开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Android）
如何做好面试突击，规划学习方向？
面试题集可以帮助你查漏补缺，有方向有针对性的学习，为之后进大厂做准备。但是如果你仅仅是看一遍，而不去学习和深究。那么这份面试题对你的帮助会很有限。最终还是要靠资深技术水平说话。
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。建议先制定学习计划，根据学习计划把知识点关联起来，形成一个系统化的知识体系。
学习方向很容易规划，但是如果只通过碎片化的学习，对自己的提升是很慢的。
同时我还搜集整理2020年字节跳动，以及腾讯，阿里，华为，小米等公司的面试题，把面试的要求和技术点梳理成一份大而全的“ Android架构师”面试 Xmind（实际上比预期多花了不少精力），包含知识脉络 + 分支细节。
在搭建这些技术框架的时候，还整理了系统的高级进阶教程，会比自己碎片化学习效果强太多。
点击：《Android架构视频+BAT面试专题PDF+学习笔记》即可免费获取~
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。
框架的时候，还整理了系统的高级进阶教程，会比自己碎片化学习效果强太多。
[外链图片转存中…(img-AKKTbCaZ-1710894236974)]
点击：《Android架构视频+BAT面试专题PDF+学习笔记》即可免费获取~
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。
952
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
