圆桌讨论：大规模移动开发

本文最初发表于 Increment 杂志，经 Increment 官方授权，InfoQ 中文站翻译并分享。

阿迪达斯（Adidas）Runtastic、Eventbrite 和 Citymapper 的工程负责人讨论了应用程序的性能、移动端如何融入其组织结构以及原生与跨平台开发。

嘉宾介绍

Christian Orgler，阿迪达斯 Runtastic 产品工程副总裁。现有 62000 多名员工，43 名移动工程师。

Natlia Gatti，Eventbrite 工程经理。现有 600 多名员工，20 名移动工程师。

Jogre Cohen，Citymapper 产品工程主管。现有 60 多名员工，10 名移动工程师。

贵司如何看待移动业务？

• 阿迪达斯 Runtasic，Chrisian Orgler：

我们认为，移动是我们业务的核心，也就是创造吸引人的运动体验。说到底，你是不可能带着笔记本电脑跑步的。但是，将移动设备与正确的平台结合起来，会使你获得最佳的体验。举例来说，你可以使用我们的应用程序和 Facebook 门户网站，在你的客厅里进行快速锻炼。

随着我们的成长，我们经历了几个阶段，从发布和维护超过 30 个应用程序，到缩减为 4 个伴随网络平台的应用程序，再到 2015 年被阿迪达斯收购后，只专注于两个应用程序，即 adidas Running 和 adidas Training。

• Eventbrite，Natalia Gatti：

我们的原生应用程序使我们能够将用户与全球各地的有趣活动联系起来，并通过利用位置信息、通知、数字钱包等等，提供更加个性化、无缝的体验。移动设备是我们用户的首选平台，大量的参与度、转换率、保留率和登录率等都证明了这一点。

• Citymapper，Jorge Cohen：

Citymapper 的宗旨是帮助人们在城市中导航，因此我们需要高度移动化。这些特性是从移动端开始的，随后适应于 Web。尽管我们能够快速适应新技术，但是我们通常不会采用新的框架，因为新的框架对用户并没有明显的好处。并非每个人都买得起最新的设备，因此我们歇尽全力支持旧的操作系统，让我们的 API 向后兼容，这样，更多的人就可以从我们的服务中获益。五、六年前的 Citymapper 版本现在还可以用！

贵司在移动开发中使用了哪些工具和技术？

• 阿迪达斯 Runtasic，Chrisian Orgler：

我们的构建基础设施使用 fastlane 和 Jenkins 等开源工具，这些都与我们的代码管理系统 Bitbucket 相连。我们的监控工具包括标准的苹果和谷歌控制台仪表板，以及我们自己更为定制的应用性能监控（App Performance Monitoring，APM）工具 New Relic，它与我们的后端服务相连。

发布任何变更前，我们都要经过 alpha 测试（与员工一起）和 beta 测试（与真实用户池），通过 App Center、TestFlight 或 Google Play 根据测试阶段进行分发。由于有数以百万计的活跃用户，我们有时会观察到一些问题，这些问题要求我们在模拟器不够用的情况下重新创建用户的确切硬件和数据环境，所以我们目前正在测试一个第三方远程访问工具，该工具将允许我们选择任何物理设备，并重新创建一个出现问题的确切硬件。在应用程序中，我们把它与 QA 工程师使用的内部调试功能结合起来。

• Eventbrite，Natalia Gatti：

对于 iOS，我们使用苹果自己的开发者工具，比如 Xcode，因为它们减少了与 iOS 更新的摩擦。我们使用 XCTest 框架编写测试，并选择了诸如 fastlane 和 SwiftLint 等社区标准来促进应用程序平台之间的统一。对于 Android，我们使用 Android Studio 和 Kotlin 进行开发，使用 Firebase Test Labs 进行集成测试。为了在 iOS 和 Android 应用程序中共享业务逻辑和工具，我们也建立了仓库。我们依靠 Sentry 来追踪问题和崩溃，依靠 Google Analytics 来追踪应用的使用情况。CircleCI 是我们的持续集成管道，我们使用 Code Climate 来审查代码质量，包括代码覆盖率。

• Citymapper，Jorge Cohen：

基于 Github Actions 和 Bitrise CI，我们使用 fastlane 进行构建和部署，利用 Mixpanel 和 Crashlytics 进行客户端监控，使用定制的 Grafana 仪表板对后端进行监控。我们的 Android 团队 Firebase Test Labs 用于对设备进行测试。近期，我们也开始使用 Point-Free 的 swift-snapshot-testing、Airbnb 的 Showkase 和 Cash App 的 paparazzi 等开源工具进行快照测试组件。通过 Phabricator，我们进行所有的代码审查，并使用特性标志来避免交付未完成的特性。此外，我们也使用了各种工具进行配对编程，主要是 Pop。

移动工程师如何融入贵司的团队结构？

• 阿迪达斯 Runtasic，Chrisian Orgler：

我们的产品工程团队是跨职能设立的，包括移动、后端和 QA 工程师，以及一名产品设计师和经理。受 Spotify 模式的启发，聚集在一起的团队组成一个“部落”，专注于我们的两个应用，或者两个应用中的总体社交体验。我们的部落领导团队由首席设计师和产品、营销和工程负责人组成，负责部落成功实现我们公司的目标。

这种结构有助于支持团队的自主性，并在更广泛的组织内创造一种归属感，但是，当面对的是一些特性或需求，比如单点登录，这些不能由一个部落独立完成，这就可能成为一个挑战。现在，我们关注于以体验为中心，而非单一的应用来调整部落和团队的目标，以便我们能从这种团队结构中获益，同时也能作为工程组织变得更加独立于应用，以体验为导向。

• Eventbrite，Natalia Gatti：

我们的移动工程师分属两个团队，即 iOS 和 Android，他们还包括专门的产品经理和产品设计师。这种结构的优点是更多地关注内部知识共享和支持，允许两个应用程序之间的相互交流以及跨团队的指导。这种结构也使产品团队受益，因为它向他们提供了对每个应用程序的整体视图。但是，这的确需要与拥有后端服务的特性团队进行高度协作和协调，这可能会导致在协调发布和调整路线图时作出妥协和权衡。

• Citymapper，Jorge Cohen：

我们所有的移动工程师都在一个团队中，每个平台都有一个子团队。任何工程师都可以在应用程序的任何部分工作，从而使不同的特性和产品之间能够共享背景。这也意味着我们能够更加灵活地处理优先事项，因为任何工程师都可以跳到任何任务上。有时，当有多个高优先级的项目需求时，这会使项目管理更加困难。如果出现这样的情况，我们可以把一些工程师分配给某些任务，或者重新评估我们的优先事项。

很少有这样的情况，我们会建立临时的特性团队，来帮助我们专注于一个特别具有挑战性的项目，或者快速启动一个新产品。近来我们在 B2B SDK 上做过类似的工作。这些团队是临时性质的，一旦我们解决了这个挑战就会解散。随后，我们通过文档和内部讨论，与团队的其他成员分享关于新特性的知识。

你的移动团队是原生开发还是使用跨平台框架？

• 阿迪达斯 Runtasic，Chrisian Orgler：

虽然我们的开发主要是基于原生平台，但是我们偶尔也会探索、测试和验证针对特定需求的跨平台框架。举例来说，我们使用 React Native 开发了我们的社交媒体源，但是出于几个原因，其中包括稳定性、所需的领域知识以及我们必须采用的变通方法来实现与原生代码的正确互操作性，我们决定过渡回原生开发的社交媒体源。

每个季度，在全公司的“新想法日”上，我们的工程师有时会用诸如 Flutter 这样的跨平台框架来开发内部应用，然后确定这种技术是否适合我们当前的企业规模需求。当前，我们正在对 Kotlin Multiplatform Mobile 进行评估，以共享平台之间的某些特定业务逻辑。

• Eventbrite，Natalia Gatti：

我们的移动团队进行原生开发，因此我们可以提供最好的用户体验，并跟上最新的 iOS 和 Android 更新。尽管这样做会导致工作上的重复，但是我们发现，我们在设计和用户体验方面必须做出的让步，比使用非原生平台要少得多。它还能让我们更快地采用特定于平台的新特性。虽然我们在同一平台的应用程序之间共享了代码，但是我们也在 iOS 和 Android 应用程序之间使用了嵌入式 Web 视图，以提供相同的特性，当特性太难构建或无法产生投资回报时，就会进行原生开发。

• Citymapper，Jorge Cohen：

我们的消费者应用程序是完全原生的，因此我们可以利用每个操作系统的最新特性，iOS 是用 Objective-C 和 Swift 编写的，Android 是用 Java 和 Kotlin 编写的。虽然我们有些屏幕是使用基于 Web 的技术构建的，但是我们通过结合设计、CSS 和 JavaScript，来确保这些屏幕尽可能地具有原生感。我们研究过 Kotlin 多平台和 Swift，用于我们的 B2B SDK 中的跨平台逻辑，但它们感觉还不够成熟。为了应对客户项目结构的不可预测性，我们希望使 SDK 技术尽可能接近平台供应商所使用的技术。

你如何衡量移动应用的性能？

• 阿迪达斯 Runtasic，Chrisian Orgler：

在团队层面上，我们衡量与我们的经验相关的具体性能指标，例如我们的 GPS 跟踪算法需要多长时间调整准确性和速度，并删除异常值以补偿硬件传感器。在应用层面上，我们研究常见的指标，如崩溃和“应用程序无响应”（ANR）率，并将其转化为以用户为中心的指标，如“恼怒用户率”和“无崩溃用户率”，或根据用户发生的时间进行分类，如在跑步或完成锻炼时。我们还测量用户界面的时间、启动速度、应用程序的大小等等，包括新兴市场的一些关键指标，如蜂窝数据的使用和连接速度。

• Eventbrite，Natalia Gatti：

为保证发布后每一个应用程序都能保持稳定，我们使用 Sentry 来监控无崩溃用户会话率，我们的目标是将这个比率控制在 99.6% 以上。对于我们的 iOS 应用程序，我们使用 MetricKit 来监控启动时间和挂起率。对于 Android 系统，我们在 Google Play Console 中测量 ANR 和崩溃率等核心指标。我们的重点是防止流量高峰期出现性能和网络问题。

• Citymapper，Jorge Cohen：

我们主要使用定制的工具来衡量应用程序的启动时间。工程师们每天都在使用这个应用程序，而且我们发现，对缓慢的屏幕感到厌烦是激励我们解决问题的最好方式。我们的应用程序是要在地下、地铁中等场合使用的，网络连接不可靠，所以我们从一开始就针对不太稳定的连接进行优化，缓存相关数据，以确保应用程序可以离线运行。我们的团队还确保让旧版本的应用程序可靠地运行，而且我们几乎从不废弃旧的 API。

在产品开发过程中，你的移动团队如何优先考虑无障碍环境？

• 阿迪达斯 Runtasic，Chrisian Orgler：

我们的 UI/UX 设计师和产品经理通过设计将无障碍环境纳入产品特性开发。近三年来，我们在应用程序的基础方面做了一些改进，比如为屏幕阅读器标注了按钮等用户界面组件，并创建了“轮椅”等专用运动类型，作为参与挑战或虚拟比赛的选项。

• Eventbrite，Natalia Gatti：

我们成立了一个委员会，由 Web 和原生应用程序专家组成，收集用户对无障碍环境问题的反馈意见，并为更大的团队起草指导方针。此外，我们使用 iOS 上的 Accessibility Inspector 和 Android 上的 Accessibility Scanner 来衡量当前的无障碍环境问题。最近，我们专注于解决我们的登录流程，以解决对比度、动态字体和链接等问题。我们现在正计划在我们的持续集成环境中建立无障碍环境测试，这样我们就可以确信我们开发的新特性是无障碍环境。

• Citymapper，Jorge Cohen：

2019 年，我们在一些城市（已有此类数据）增加了无障碍坡道，以支持轮椅使用者。由于我们希望进一步帮助有视觉障碍的人，所以改善 VoiceOver 支持也在我们的产品路线图上。

在移动开发过程或工作流中，有什么出乎意料或独特的东西让你觉得特别有效？

• 阿迪达斯 Runtasic，Chrisian Orgler：

在产品开发团队中，我们给工程师们定义了额外的角色，让他们有机会发展领导能力。举例来说，我们有一个兴趣小组，称为公会，由指定的公会负责人领导，成员通过每周会议和演讲进行知识交流和学习。另外，我们也有一组轮流的发布经理，他们在各开发团队中协作并管理我们两周的发布周期。有了专门的发布经理，使我们的发布过程更加顺畅，提高了我们满足目标发布日期的能力。这已经成为我们工作方式的一个基础部分。

• Eventbrite，Natalia Gatti：

苹果和安卓产品以不同的比例出现在世界各地。了解这些变化有助于我们作为一个全球组织来确定特性和集成的优先次序，并给予我们为每个平台开发的自由，满足我们客户的需求。例如，我们为活动组织者提供的销售点和票据扫描应用程序与一些第三方条码扫描仪、刷卡器和票据打印机集成，这些设备在全球范围的可用性不同。在我们需要优先为这些外设提供平台支持的时候，我们可以根据我们所要支持的地区内移动平台的产品市场匹配来开发集成。

• Citymapper，Jorge Cohen：

许多移动应用程序至少有一个屏幕的广告内容需要经常更换，Citymapper 也不例外。为了在不涉及开发者的情况下保持内容的更新，我们使用了一个定制的 Sketch 插件，使我们的设计师和产品经理能够在不需要编程的情况下构建整个特性屏幕。转移到这个系统后，加快了信息和设计的实验速度，并使移动团队得以专注于更优先的工作。我们的应用程序目前有超过 10 个屏幕是用这个工具建立的。

作者介绍：

Increment 是一本关于团队如何大规模构建和操作软件系统的杂志，该杂志拥有印刷版和数字版。

原文链接：

https://increment.com/mobile/mobile-development-at-scale/