Uber 是全球最大的网约车公司，为数百万用户提供出行服务，同时还提供外卖、医疗运输和货运物流服务。访问的便捷性对其成功至关重要；当用户切换到新设备时，他们希望能够顺畅过渡，而无需重新登录 Uber 应用或通过基于短信的动态密码进行身份验证。这种频繁的设备更换既带来了挑战，也为提高用户留存率提供了机会。

为了保持用户连续性，Uber 的工程师求助于“恢复凭据”功能，这是在每年有 40% 的美国人更换智能手机的时代必不可少的工具。在评估用户需求和进行代码原型设计后，他们便在Uber 乘客应用中引入了“恢复凭据”支持。为了验证恢复凭据有助于消除重新登录时的阻碍，Uber 团队进行了为期五周的 A/B 实验，并取得了成功。集成后，手动登录次数有所减少，如果将这一趋势推广到 Uber 庞大的用户群，预计每年可减少 400 万次手动登录。

借助“恢复凭据”消除登录阻碍

过去，我们曾尝试使用常规数据 备份 和 BlockStore 等解决方案在新设备上恢复账号，但这些解决方案都需要直接在源设备和目标设备之间共享身份验证令牌。由于令牌信息非常敏感，因此这些解决方案仅在一定程度上用于预先填充目标设备上的登录字段，并减少登录流程中的一些阻碍。通行密钥也用于提供安全快速的登录方法，但由于其用户发起性质，因此对顺畅的设备过渡的影响有限。

“有些用户不会每天使用 Uber 应用，但他们希望在需要时能够正常使用该应用，”Uber 的 Android 工程师 Thomás Oliveira Horta 说道。当您打开应用以在新 Android 手机上叫车时，却发现自己已退出登录，这可能会带来不愉快的体验，让用户感到反感。

借助“恢复凭据”，工程师们能够弥合这一差距。该 API 会在旧设备上生成一个唯一令牌，当用户在标准入职流程中恢复应用数据时，该令牌会顺畅地静默移动到新设备。此过程利用了 Android OS 的原生备份和恢复机制，确保恢复密钥与应用数据一起安全传输。这种简化的方法保证了简单安全的账号转移，满足了 Uber 的安全要求，而无需任何额外的用户输入或开发开销。

注意 ：“恢复密钥”和通行密钥使用相同的底层服务器实现。但是，在数据库中保存它们时，您必须区分它们。这种区分至关重要，因为用户创建的通行密钥可以直接由用户管理，而恢复密钥则由系统管理，并且对用户界面隐藏。

“在 Uber 的乘客应用中采用‘恢复凭据’后，我们开始看到持续的使用情况，”Thomás 说道。在当前的发布阶段，平均每天有 10,000 位独立用户 使用‘恢复凭据’登录，并且他们在首次在新设备上打开应用时获得了顺畅的体验。我们预计，一旦将发布范围扩大到整个用户群，这一数字将翻一番 。”

实现方面的注意事项

“按照示例代码和文档，在 Android 端进行少量调整后，集成非常简单，”Thomás 说道。“我们的应用已使用 Credential Manager 来处理通行密钥，后端只需要进行一些小的调整。因此，我们只需要将 Credential Manager 依赖项更新到最新版本，即可访问新的 Restore Credentials API。我们通过相同的通行密钥创建流程创建了一个恢复密钥，当我们的应用在新设备上启动时，应用会尝试静默检索通行密钥，从而主动检查此密钥。如果找到恢复密钥，系统会立即使用该密钥自动让用户登录，从而绕过任何手动登录。”

在整个开发过程中，Uber 的工程师在实现过程中遇到了一些挑战，从选择正确的入口点到管理后端凭据生命周期。

选择“恢复凭据”入口点

工程师在选择要用于恢复的“恢复凭据” 入口点 时，仔细权衡了完美顺畅的用户体验与实现简单性之间的权衡。最终，他们优先考虑了提供理想平衡的解决方案。

“这可以在应用启动期间或设备恢复和设置期间在后台进行，使用 BackupAgent，”Thomás 说道。“后台登录入口点对用户来说更顺畅，但它在后台操作方面带来了挑战，并且需要使用 BackupAgent API，这会导致像 Uber 这样庞大的代码库的复杂性增加。”他们决定在 首次应用启动 期间实现该功能，这比手动登录快得多。

解决服务器端挑战

在与后端 WebAuthn API 集成期间，出现了一些服务器端挑战，因为它们的设计假定始终需要用户验证，并且所有凭据都将列在用户的账号设置中；这些假设都不适用于非用户管理的“恢复凭据”密钥。

Uber 团队通过对 WebAuthn 服务进行细微更改解决了此问题，创建了新的凭据类型，以区分通行密钥和“恢复凭据”并对其进行适当处理。

管理“恢复凭据”生命周期

Uber 的工程师在管理后端凭据密钥时面临着一些挑战，后端工程师 Ryan O’Laughlin 提供了专门的支持：

• 防止孤立密钥：一个重大挑战是定义删除已注册公钥的策略，以防止它们成为“孤立”密钥。例如，卸载应用会删除本地凭据，但由于此操作不会向后端发出信号，因此会在服务器上留下一个未使用的密钥。
• 平衡密钥生命周期：密钥需要一个足够长的“存留时间 (TTL)”来处理极端情况。例如，如果用户进行备份和恢复，然后手动从旧设备退出登录，则密钥会从该旧设备中删除。但是，密钥必须在服务器上保持有效，以便新设备仍可以使用它。
• **支持多台设备**：由于用户可能有多台设备（并且可以从任何设备启动备份和恢复），因此后端需要支持每个用户的多个“恢复凭据”（每台设备一个）。

Uber 的工程师通过根据新凭据注册和凭据使用情况建立服务器端密钥删除规则来应对这些挑战。

该功能在快速的两个月开发和测试过程中从设计到交付。之后，为期五周的 A/B 实验（验证用户功能的时间）顺利进行，并取得了无可否认的结果。 

借助“恢复凭据”防止用户流失

通过消除新设备上的手动登录，Uber 保留了那些可能在新设备上放弃登录流程的用户。客户便捷性的提升体现在各种改进中，虽然乍一看可能微不足道，但如果以 Uber 的用户群规模来看，其影响是巨大的：

• 手动登录（短信动态密码、密码、社交登录）减少 3.4%。
• 需要短信动态密码的登录费用减少 1.2%。
• Uber 的访问率（成功进入应用主屏幕的设备百分比）提高 0.575%。
• 完成行程的设备数量增加 0.614%。 

如今，“恢复凭据”正朝着成为 Uber 乘客应用的标准 部分迈进，试用组中超过 95% 的用户 已注册。

在设置新设备期间，用户可以从备份中恢复应用数据和凭据。选择 Uber 进行恢复并且后台进程完成后，应用会在新设备首次启动时自动让用户登录。

“恢复凭据”的无形但巨大的影响

在接下来的几个月里，Uber 计划扩大“恢复凭据”的集成范围。根据试用结果，他们估计此更改每年将减少 400 万次手动登录。通过简化应用访问并消除一个关键痛点，他们正积极打造一个更满意、更忠诚的客户群，一次行程一次行程地积累。

“集成 Google 的 RestoreCredentials 使我们能够提供用户在新设备上期望的顺畅的‘开箱即用’体验，”Uber 首席产品经理（核心身份）Matt Mueller 说道。“这直接转化为可衡量的收入增长，证明减少登录阻碍是提高用户互动度和留存率的关键。”

准备好提升应用的登录体验了吗？

了解如何借助“恢复凭据”在切换设备时提供顺畅的登录体验，并阅读博文中的更多内容。在 Android Studio Otter 的最新 Canary 版中，您可以验证集成，因为新功能有助于模拟备份和恢复机制。

如果您是 Credential Manager 的新手，可以参阅我们的官方 文档、Codelab 和 示例，以获取集成方面的帮助