Flutter Engage China 开发者常见问题解答 | 下篇
Flutter / 2021-04-21 18:43:42
再次感谢大家对 Flutter Engage China 活动的关注和积极参与！我们在活动前后收到了很多来自开发者的反馈和问题，Flutter 团队和演讲嘉宾在直播 Q&A 环节中也针对部分问题在第一时间给出回复。现在我们将一些开发者关心的问题和回复整理出来分享给大家，希望对您有所帮助。由于问题数量较多，我们分为上下两期发布，上期的内容已经发布，欢迎大家前往回顾。您也可以观看 Flutter Engage China 视频回顾精彩内容:
Bilibili 视频合集链接
https://www.bilibili.com/medialist/play/ml1214246458/BV1hh411D7mV
为什么 Flutter SDK 集成的内容这么少，写个简单的控件都需要依赖第三方插件，不能多扩展一下控件功能吗？
回答者: 杨天航 (Chris)，Google Flutter 团队工程师
降低二进制文件尺寸。 希望框架里的 API 在不同平台上比较统一。所以如果我们在框架或引擎里加入一些控件的功能的话，会让我们无法去统一 API。 让 Flutter 框架非常模块化，中间有很多模块，很多层级，这样我们可以很容易地进行替换。假如我们把视频播放器控件建立在 Flutter 引擎和框架里，那就很难避免大部分的 Flutter 应用只能选择我们提供的视频播放器 API 的局面。这样其实很不方便，尤其对于那些有不同需求的应用。如果是以现在插件的形式提供视频播放器的话，大家都可以找到合适的解决方案。不同的团队也可以建立自己的插件，这无疑会让大家有更多选择的余地。
Flutter 包体积如何缩减？
回答者: 董韬，Google Flutter 用户体验研究负责人
我们一直在针对这个问题做优化工作。包的精简主要包括两个方面的工作: 第一个方面是 Flutter 团队为全球所有用户做的全局优化。第二个方面是每个 App 团队在自己的 App 内部做的优化。
从第一个方面来讲，我们去年对大的编译过程做了很多优化，主要是在 iOS 端。iOS 端产物的体积已经有了比较显著的缩小。目前来看，想要进一步缩小包产物的话，需要更多的由开发者根据自己 App 的实际情况做一些取舍，以及对 Flutter 引擎做一定的定制。
我们最近也推出了一款工具，在 Dart DevTools 里面，叫做 Code Size Analysis，这个工具可以帮大家可视化包里具体有哪些内容，每个内容占用了多少空间。有的时候您可能会发现，有一些资源或者有一些依赖的库占用了过多的空间。这个工具也会帮您解析 Flutter 引擎里面具体的产物是什么，如果您有计划去对 Flutter 引擎进行定制的话，这些都会是很好的参考数据。
使用分析标签页查看体积信息 https://flutter.cn/docs/development/tools/devtools/app-size#analysis-tab
回答者: 袁辉辉，字节跳动 Flutter 技术负责人
我简单从 App 团队的角度来做一些补充。App 团队想缩小包体积的话，有三个可以做的优化。一个是压缩，主要是我们在代码端和数据端，可以对数据做一些压缩。二是裁剪，您可以看看哪些模块是不使用的，比如说您是国内使用的 App，那就并不需要国际化的一些功能模块，就可以裁剪掉。三是系统级的优化，比如说大的编译由 O3 变 Oz，或者是做指令集头部的一些精简，把 code source map 这样的东西去掉，以及做一些混淆，到了线上之后再通过后台平台还原回来，能使用的手段其实很多的。
我们接下来会加大对外的技术输出，后续我们会把这些技巧再梳理一下分享给大家。
类似微博那种大量音频、视频，以及文本和图片混排导致的性能问题该怎样解决？
回答者: 刘森森，阿里巴巴 UC 客户端团队
这个问题其实可以理解为在这种复杂卡片的场景下，在列表做惯性滚动的时候出现的一些性能问题。这个问题非常典型，实际上在应用层有很多优化手段可以去做。
首先我们可以使用 Flutter 提供的性能分析工具来定位问题，去发现是否在写法上面存在着一些可以优化的地方。比如在列表滚动的时候，是否存在 widget 构建的次数过多，或者构建的层级过深的问题，导致 UI 线程出现卡顿。我们也可以使用 Flutter 提供的 RepaintBoundary，来减少重绘的范围。并且检查是否使用到了 ClipPath 或者 BackdropFilter 这种可能会对 Raster 线程造成一定影响的操作，是否可以尽量去避免。
RepaintBoundary https://api.flutter-io.cn/flutter/widgets/RepaintBoundary-class.html
在优化完写法后，可以去评估使用 SurfaceView 作为 FlutterView 渲染的实现。SurfaceView 从原理上来讲比 TextureView 的性能更好，因为它有独立的渲染管线。从实际测试的效果来看，SurfaceView 的帧率平均有 2~4 帧的提升。它的问题可能存在于混合开发的场景，由于它跟 AndroidView 不兼容，会导致黑屏等兼容性问题。我的建议是，如果是开发一个完整的 Flutter App 的话，优先选用 SurfaceView；如果做混合栈开发的话，需要评估 SurfaceView 是否存在导致兼容性问题的场景，然后尽量去使用 SurfaceView。
如果前两步都没有发现问题的话，可以使用我分享的分帧渲染的思路，也可以减少 UI 和 Raster 线程的绘制耗时。
