耦合是天然存在的，一个 App 解耦的上限就是业务逻辑上的耦合程度。快手 App 承载的各种业务耦合就非常高，开发人数也经历了两年的快速增长。众多开发者合作开发一个业务间紧密相关的 App，带来了协作和迭代方面各种各样的问题，给基础工具和流程的设计带来了极大的挑战。这些挑战不仅存在于 Native 平台上，也同样威胁着 Flutter。本次分享，我们总结了 Native 平台演进过程中暴露的各种问题，介绍了针对 Flutter 的平台特征，落地的一些提升 App 研发质效的工具和标准。

演讲提纲：

1. App 级别平台组的定位思考

• 减少大规模协作的沟通成本（划分边界，明确接口）
• 维持产品迭代中的可维护性（面向迭代设计）
• 维持统一的质量和代码风格（包括基础用户体验，例如包大小等）

2. 大规模协作需要什么样的工程特性

• Channel 需要进行大量的字符串、类型对应工作（书写易出错，错误被 delay 到运行时）
• 生成代替手写，杜绝手写失误。编译检查代替运行时错误，提前暴露兼容问题。
• 基于gRPC 的公用版本
  • 优点：好维护
  • 缺点：重、对现有数据结构不友好
• 自研纯 Dart 版本
  •  优点：轻量化
  •  缺点：强类型不如 pb
• 基础能力工具化，支持页面栈的强类型化

3. MethodChannelGen

• Channel 需要进行大量的字符串、类型对应工作
• 生成代替手写，杜绝手写失误。编译检查代替运行时错误，提前暴露兼容问题。
• 基于 gRPC 的公用版本
• 自研纯 Dart 版本

4. 强类型的页面跳转（天然的业务边界）

• 原生 Navigator 字符串路由不利于协作（url不可控，入参不明确。需要跨边界沟通，错误被 delay 到运行时）
• IoC 模式，解决组件化依赖+目前接口
  • 学习 Android 官方 static 方法的方式
  • 暴露变化
  • 封装具体实现
• 用代码生成支持 Native-Flutter 和 Flutter-Flutter

5. 组件库维护

• 组件分级制定标准（对开发者提出标准，对使用者明确定位）
  • 有什么级别
  • 为什么分级
    • 稳定性
    • 维护程度
    • 依赖
• 库内容要求概览（物理结构，对照 Pub 私服的搜索和展示说）
• 开发流程闭环
  • 创建 —— 模板工具（降低标准本身的学习沟通成本）
    • 通用模板工具（隔离变化，仿照 Flutter create模板）
    • 定制化的模板
• 开发 —— mr 检查工具（保证后续迭代的质量）
  • 通用模板检查工具，回归构建工具
  • 定制化的模板
• 发布 —— 基于 Pub 的准入检查（最后兜底，保证对外一致）
  • 定制 pub publish
  • 可配置的检查

6. 包大小

• 基于 Pubspec 的依赖分析
• 可视化展示

7. 内存泄漏检查

• Expando 与 GC
• 使用 vmService 分析泄漏

听众收益：

1. 了解快手在大规模协作中的坑和解决办法
2. 了解 Flutter 落地的一些开发效能问题的解法