第15章 洞察与趋势：解读 Flutter 2020 年第二季度调查结果

我们从 Flutter 2020 年第二季度调查中学到了什么 重点关注代码示例、应用性能和编写软件包 JaYoung Lee 2020年7月22日 · 9 分钟阅读 rss_feed 分享到 X 分享到 Bluesky 分享到 LinkedIn 每个季度，Flutter 团队都会开展一次为期约十天的调查，倾听大家使用 Flutter 的体验。每次调查既包含帮助我们跟踪各项指标长期趋势的常规问题，也包含收集即时反馈的新问题，这有助于我们把精力集中在重要的领域上。 沿袭这一传统，我们在 2020 年 5 月发起了第九次季度调查。尽管当前世界形势充满挑战，十天里我们仍收到了近 8,000 份回复，非常感谢大家的参与。首先要高兴地告诉大家：参与调查的用户中 94% 对 Flutter 表示满意，其中 57% 表示非常满意，创历史新高！看到大家如此喜爱我们一起打造的这个框架，我们深感谦卑与荣幸。 本季度调查涵盖了许多话题，以下是一些亮点！ 57% 的受访者对 Flutter 非常满意，总体满意度达 94%。 Flutter 的普及 本季度我们特别想了解专业开发者是如何选择 Flutter 的，因此设计了一些问题来深入探究。我们的假设是：个人使用与工作使用之间存在重叠，我们希望验证这一点并加深理解。 总体而言，46% 的受访者在将 Flutter 用于个人项目之后，才决定（或说服管理层）在工作项目中采用 Flutter 我们发现，46% 的受访者是在个人项目中使用过 Flutter 之后，才决定采用它（或说服管理层采用）。这意味着 Flutter 的普及主要源于良好的个人使用体验，进而延伸到了工作场景中的探索。如下图所示，这一现象在不同类型的环境中相当一致，即使在代理公司或企业工作的受访者中，也约有半数表示是他们自己决定或说服管理层采用 Flutter 的。 我们认为，这反映了 Flutter 在真正使用者——也就是你们——中间的吸引力。 在各类公司/组织中，决定采用或说服管理层采用 Flutter 的受访者比例都保持较高水平 如果你也想说服他人采用 Flutter，可以参考 Nubank 的技术博客和相关视频，了解他们如何评估 Flutter 及其他技术并最终选择 Flutter。Nubank 是亚洲以外最大的数字银行，拥有超过 2,000 万客户，他们对 Flutter 的独立技术评估非常值得一读。 代码示例 在上一次调查中，用户告诉我们示例代码是最有用的学习资源，甚至超过视频、文章或演示。本季度的调查中，我们想进一步了解应该投入开发哪些类型的示例代码。 调查中，我们请用户回忆最近一次搜索示例代码的经历，并询问相关细节，例如在哪里找到了最有用的示例代码。结果发现 Stack Overflow 是最常见的来源（26%），其次是 GitHub（17%）。 Stack Overflow 是人们找到有用示例代码的最常见渠道（26%），其次是 GitHub（17%）。 在这一部分的最后，我们提出一个问题：如果只能提供一种示例代码，哪种更有用——数量多但规模小的示例，还是数量少但规模大的示例？ 总体结果显示，大多数用户（68%）希望有更多示例，哪怕它们比较小。这一结果直接指导我们：当 API 文档、cookbook、教程等文档中缺少代码示例时，优先补充多个简短的示例。 受访者表示“数量更多但规模更小的示例”更有用。在实际调查问题中，“{受访者选择的资源}”会被替换为他们最近找到示例代码的具体渠道（如 Stack Overflow）。 对于不同渠道（如 Stack Overflow 或 API 文档）的示例代码，用户偏好是否有所不同？按渠道拆分来看，所有类别的偏好仍然都是“更多但更小的代码示例”。 在各类资源中，选择“更多但更小的代码示例”的受访者比例都保持较高水平。 有趣的是，如上图所示，对于那些用户用来寻找灵感或查看高质量应用实例的资源（如 GitHub 或 YouTube），偏好“更少但更大的应用示例”的用户比例有所上升。这一结果或许对规划学习材料的 Flutter 社区讲师有所帮助。 Flutter 应用性能 Flutter 在移动和桌面设备上编译为机器码，可实现与系统原生框架相当的性能。尽管如此，Flutter 团队仍在持续改进各项性能指标，包括渲染速度、功耗、内存占用和应用体积。得益于此，对 Flutter 移动端性能表示满意的用户比例从 2019 年第三季度的 85% 提升到本季度的 92%。 92% 的用户对 Flutter 的移动端性能表示满意。此数据不含 9.2% 选择“经验不足，无法回答”的用户，以及 2.3% 选择“什么是 release mode 或 profile mode？”的用户。 本季度，我们想进一步了解：与使用 Android 和 iOS 原生框架构建应用的开发者相比，用户如何看待 Flutter 的应用性能。这些问题面向有 Android 和 iOS 开发实操经验的用户。 虽然 Flutter 开发者总体上对性能和资源占用感到满意，但应用体积是最有改进空间的地方：有 Android 或 iOS 开发经验的开发者中有 11–13% 认为这方面“不可接受”。我们已经做了一些改进，但这说明还有工作要做。我们希望通过优化编译器和拆分 AOT 产物来进一步压缩应用体积。 与 Android 原生相比，Flutter 应用性能的可接受程度。 与 iOS 原生相比，Flutter 应用性能的可接受程度。 我们还了解到，用户对 Flutter 应用内存占用的满意度略低于对速度和功耗的满意度。为此，我们正在改进内存性能（尤其是图片内存占用），同时大力投入更好的工具、测试和文档。团队正在改进 DevTools 的界面，以及关于调试内存、应用体积和能耗问题的文档。 编写软件包 Flutter 开发者可以使用 pub.dev 上的软件包快速构建应用，而不必事事从零开始。虽然 pub.dev 上已有超过 10,000 个兼容 Flutter 的软件包，但其中只有一小部分由 Google Flutter 团队直接维护。因此，Flutter 的生态系统在设计上就高度依赖社区贡献。 我们致力于打造良好的开发环境，支持软件包作者创建和维护高质量软件包。就在本周，我们根据之前的反馈，对 pub.dev 网站进行了全面改版。 现在，我们的用户体验研究人员想了解是什么驱动软件包作者发布和维护软件包。今年早些时候，我们与众多软件包作者进行了交流，基于这些发现，我们在本次调查中加入了定量问题，进一步探索这个领域。 调查的主要发现是：大多数软件包作者出于利他动机发布软件包，但维护软件包则主要是因为自身需求。例如，82% 的作者发布软件包是因为希望其他用户从中受益，但出于同样原因而维护软件包的作者只有 58%。另一方面，66% 的作者发布软件包是为了自己使用，而正是这个原因促使 70% 的作者持续维护它们。 82% 的作者发布软件包是因为希望其他用户受益 而“让他人受益”只能驱动 58% 的作者去维护他们的软件包 这让我们意识到，我们还可以提供更多支持。让软件包作者了解某个软件包可能给社区带来多大的影响，也许对他们有帮助。例如，你可能想知道会有多少 Flutter 用户受益于一个通知插件。（目前，你可以在 flutter/flutter 仓库中通过“would be a good package”标签查看等待作者认领的潜在软件包。）另外，你可能还想知道哪些软件包明确在寻求贡献，以便轻松找到需要帮助的软件包。感谢大家的反馈，我们会在未来的 pub.dev 版本中考虑在这方面开展工作。 我们还发现可以在学习方面提供更好的支持，因为许多用户指出，学习机会是他们维护软件包的动力之一。学习如何编写文档、从同行开发者那里了解改进方向、学习如何管理开源项目，都属此类。基于这些发现，我们将继续营造一种环境，让你在为社区做贡献的同时提升自己。 结语 我们希望这一系列文章能持续体现我们对大家反馈的重视。每个季度我们都会花费大量时间分析和消化你们的回复。来自用户研究、工程和产品管理团队的许多同事会逐一阅读每条自由评论——虽然无法一一回复，但你们的需求和意见每天都在影响着我们的决策。 我们会继续坚持根据调查反馈来制定决策这一传统。请大家继续参与并分享想法。特别感谢参与第二季度调查的 7,883 位用户，是你们帮助我们形成了本文分享的洞察。 Flutter 的 UX 研究团队也在开展各类用户体验研究，让大家的 Flutter 使用体验更加愉悦。例如，上个季度我们联系并采访了软件包作者，了解他们发布和维护软件包的体验。如果你有兴趣参与这类研究，请注册报名，我们会考虑邀请你参加未来的研究。