Uber 是全球最大的网约车公司，可将数百万用户从一个地点送达另一个地点，同时还支持送餐、医疗运输和货运物流服务。访问的简易性对于其成功至关重要；当用户改用新设备时，他们希望能够顺畅过渡，而无需重新登录 Uber 应用或通过基于短信的动态密码验证。这种频繁的设备更换既带来了挑战，也为提高用户留存率提供了机会。

为了保持用户连续性，Uber 的工程师求助于恢复凭据功能。在美国，每年有 40% 的人更换智能手机，因此该功能是一项必不可少的工具。在评估用户需求和进行代码原型设计后，他们开始在 Uber 乘客版应用中支持恢复凭据。为了验证恢复凭据有助于消除重新登录带来的不便，Uber 团队成功开展了一项为期 5 周的 A/B 实验。该集成减少了手动登录次数，如果将这一效果推广到 Uber 庞大的用户群，预计每年可减少 400 万次手动登录。

通过“恢复凭据”功能消除登录过程中的繁琐环节

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

“有些用户不会每天使用 Uber 应用，但他们希望在需要时该应用能正常运行。”Uber 的 Android 工程师 Thomás Oliveira Horta 说道。当您在新 Android 手机上打开应用准备约车时，却发现自己处于已退出登录的状态，这可能会让您感到不快，甚至不想再使用该应用。

借助恢复凭据，工程师们成功弥合了这一差距。该 API 会在旧设备上生成一个唯一令牌，当用户在标准初始配置流程中恢复应用数据时，该令牌会无缝且静默地转移到新设备。此过程利用了 Android 操作系统的原生备份和恢复机制，可确保安全传输恢复密钥以及应用的数据。这种简化的方法可确保账号转移简单又安全，符合 Uber 的安全要求，无需任何额外的用户输入或开发开销。

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

“在 Uber 的乘客应用中采用‘恢复凭据’功能后，我们开始看到用户持续使用该功能，”Thomás 说道。在当前推出阶段，平均每天有 10,000 名唯一身份用户通过“恢复凭据”功能登录，他们在首次在新设备上打开应用时获得了流畅的体验。我们预计，一旦向整个用户群推出该功能，这一数字将翻一番。”

实现方面的注意事项

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

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

选择“恢复凭据”入口点

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

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

解决服务器端挑战

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

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

管理恢复凭据生命周期

Uber 的工程师在管理后端凭据密钥时面临着多项挑战，在后端工程师 Ryan O’Laughlin 的专业支持下，他们解决了这些问题：

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

Uber 的工程师通过制定基于新凭据注册和凭据使用情况的服务器端密钥删除规则，解决了这些难题。

该功能在短短两个月的开发和测试过程中就从设计阶段进入了交付阶段。之后，为期 5 周的 A/B 实验（用于向用户验证该功能）顺利进行，并取得了无可否认的成果。 

通过“恢复凭据”功能防止用户流失

通过在新设备上免去手动登录的麻烦，Uber 留住了可能因在新设备上放弃登录流程而流失的用户。客户便利性的提升体现在多项改进中，虽然乍一看这些改进可能微不足道，但对于 Uber 的庞大用户群而言，其影响是巨大的：

• 手动登录（短信动态密码、密码、社交账号登录）次数减少了 3.4%。
• 对于需要短信动态密码的登录，费用降低了 1.2%。
• Uber 的访问率（成功到达应用主屏幕的设备所占的百分比）提高了 0.575%。
• 完成行程的设备数量增加了 0.614%。

如今，“恢复凭据”功能已成为 Uber 乘客应用的标准功能，试用组中超过 95% 的用户已注册。

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

“恢复凭据”功能带来的巨大影响

在未来几个月内，Uber 计划扩大“恢复凭据”功能的集成范围。根据试用结果，他们估计这项变更每年可减少 400 万次手动登录。通过简化应用访问流程并消除一个关键痛点，他们正积极打造更满意、更忠诚的客户群，每次乘车都能让客户更满意。

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

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

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

如果您刚开始使用 Credential Manager，可以参阅我们的官方文档、Codelab 和示例，以获取集成方面的帮助