本文档包含一份核对清单,其中介绍了您在将 Firebase 应用发布到生产环境之前应考虑的最佳实践和事项。
发布的一般最佳实践
- 在部署到生产环境之前,请确保您已在 Firebase Local Emulator Suite(适用于受支持的产品)中测试所有更改。全面测试有助于避免代价高昂的错误。 
- 开始为每项支持此功能的服务强制执行 Firebase App Check。App Check 有助于确保只有您的实际应用可以访问您的后端服务和资源。 
- 使用 Firebase Remote Config 发布,安全地逐步发布应用的新功能和更新内容。 
- 如果您尚未设置 Firebase Crashlytics,请先完成设置。Firebase Crashlytics 是一个轻量级的实时崩溃报告解决方案,可帮助您对影响应用质量的稳定性问题进行跟踪、确定优先解决顺序并加以修复。 
了解您的定价方案限额并设置预算提醒
- 确保在进入生产环境后不会达到使用量上限和配额,尤其是在您使用免费 Spark 方案时。考虑升级到随用随付 Blaze 定价方案。 
- 为您的项目设置预算提醒。 - 请注意,预算提醒不是预算上限。当您接近或超过配置的阈值时,系统会向您发送提醒信息,以便您在应用或项目中采取行动。 
- 您可以考虑设置高级提醒和操作,例如为响应提醒而禁用计费的功能。 
 
- 在 Firebase 控制台的特定产品信息中心或“使用情况和结算信息”信息中心内监控您的使用情况。 
确保您的 Firebase 项目和应用遵循最佳实践
无论您是单个开发者还是企业级团队,都务必要确保您的 Firebase 项目、应用和资源受到保护、安全无虞,并且可以随着团队的变化而不断发展。
请记住,Firebase 项目实际上只是一个启用了 Firebase 服务和配置的 Google Cloud 项目。这意味着,Google Cloud 推荐的许多最佳实践也适用于 Firebase。
- 使用不同的 Firebase 项目来开发、测试和生产。 - 尽量避免意外暴露与您的正式版应用相关的项目。详细了解如何设置开发工作流。 
- 保护您的重要项目,尤其是与正式版应用相关的项目。 
- 如果您尚未设置,请考虑设置 Google Cloud 组织并将您的 Firebase 项目添加到其中。 
- 为您的 Firebase 项目添加多个 Owner,尤其是当您的项目不在 Google Cloud 组织中时。详细了解何时以及如何为 Firebase 项目分配 Owner。 
- 以 Google 群组的形式添加项目成员(即“负责人”,英文为“principle”),而不是逐个添加。 - 使用群组可以更轻松地向团队成员批量分配角色,以及管理哪些人有权访问您的 Firebase 项目,尤其是在团队成员轮换或离职时。 
- 向每个项目成员(即“负责人”,英文为“principle”)授予对您的 Firebase 项目和资源的相应访问权限级别。如需了解详情,请参阅使用 Firebase IAM 管理项目访问权限。 
- 确保每个适用的项目成员(即“负责人”,英文为“principle”)设置其偏好设置,以便接收有关特定产品或项目状态(例如结算方案更改或配额限制)的提醒。如需了解详情,请参阅接收 Firebase 提醒。 - 如果您希望特定或其他项目成员接收通知,还可以选择自定义项目的“重要联系人”。这对于确保不仅项目所有者收到有关结算、法律和产品变更的通知特别有帮助。 
- 将您的 Firebase API 密钥限制为仅包含需要在密钥的 API 许可名单中的 API。此外,请查看 Firebase 安全核对清单中有关 API 密钥的信息。 
准备应用中使用的特定服务
在应用中使用的每项产品和服务在实际使用时都可能需要考虑一些特定事项。
Google Analytics
- 为 Google Analytics 定义目标设备条件,以便从应用发布之时开始收集分析数据。 
- 请考虑启用将 Google Analytics 数据导出到 BigQuery 的功能,以便您可以使用 BigQuery SQL 分析数据,也可以导出数据以便在您自己的工具中使用。 
- 将用户属性限制为与整个应用的生命周期相关的信息。您可以创建的用户属性数量有上限,并且这些属性无法归档。 
- 查看您的 Google Analytics 属性和账号的 Google Analytics 角色设置。这些权限与 Firebase 项目 IAM 权限和角色是分开管理的。 
- 确保 Firebase 控制台的项目设置中显示的 App Store ID 和团队 ID(如有必要)正确无误。 
App Check
- 确保 Firebase 控制台的项目设置中您的团队 ID 正确无误。 
- 如果您尚未这样做,请开始为每项支持此功能的服务强制执行 Firebase App Check。App Check 有助于确保只有您的实际应用可以访问您的后端服务和资源。 
Authentication
- 停用您未使用的任何提供方(尤其是匿名身份验证)。 
- 如果您的应用使用 Google 账号登录,请设置个性化的 OAuth 权限请求页面。 
- 自定义您用于 Authentication 电子邮件发送服务的网域和发件人。 
- 如果您使用的是 Identity Platform 短信验证服务,请开始强制执行 Firebase App Check 并配置短信区域政策,以保护您的应用免遭短信滥用。 
- 针对常见的 Authentication 错误在 Apple 平台上实现错误处理机制。 
- 在 Firebase 控制台的项目设置中为应用的签名证书添加版本 SHA-1 哈希。如果您的应用使用电话号码登录或“使用 Google 账号登录”(这需要满足 OAuth 客户端要求),则必须提供 SHA-1 哈希值。 
- 为您的网域添加访问权限控制,以防止未经授权的使用。具体而言,在 Firebase 控制台的 Authentication 部分中允许访问您的生产网域(如果您使用依赖于 Firebase Security Rules 的产品,这一点尤为重要)。 
Cloud Firestore
- 配置您的 Cloud Firestore Security Rules 以防止非预期的数据访问。 
- 在发布 build 中使用 ProGuard 进行代码缩减。如果不使用 ProGuard,Cloud Firestore SDK 及其依赖项可能会增加您的 APK 大小。 
Cloud Messaging
- 请考虑启用将 Cloud Messaging 数据导出到 BigQuery 的功能,以便您可以使用 BigQuery SQL 分析数据,也可以导出数据以便在您自己的工具中使用。 
- 在 Firebase 控制台中针对 Apple 应用上传适用于 Cloud Messaging 的 APNs Auth 密钥。如果使用 APNs 证书,请确保您的生产 APNs 证书已上传。 
Cloud Storage
- 配置您的 Cloud Storage Security Rules 以防止非预期的数据访问。
Crashlytics
- 确保每个适用的项目成员(即“负责人”,英文为“principle”)设置其偏好设置,以便接收有关 Crashlytics 或项目状态(例如结算方案更改或配额限制)的提醒。如需了解详情,请参阅接收 Firebase 提醒。 
- 请考虑启用将 Crashlytics 数据导出到 BigQuery 的功能,以便您可以使用 BigQuery SQL 分析数据,也可以导出数据以便在您自己的工具中使用。 
- (仅限原生 Android 和 iOS)考虑在 Crashlytics 中启用 AI 辅助,以便更快地了解发生崩溃的原因以及如何处理。 
- 上传发布 build 的 dSYM 文件,以便在 Crashlytics 中使用。确保 Xcode 可以自动处理 dSYM 并上传文件。 
- 上传发布 build 的 ProGuard 映射,以便在 Crashlytics 中使用。您可以使用 Firebase CLI 进行上传。 
- 将 Firebase 与 Google Play 相关联,以便更全面地了解您的 Android 应用的健康状况。例如,您可以按 Google Play 轨道过滤应用的崩溃报告,以便让信息中心更有侧重地显示特定 build。 
- 对于以 Android 为目标平台且使用 IL2CPP 的 build,请确保您为希望拥有符号的每个 build 运行上传原生符号,无论是否有任何代码或配置更改。 
Dynamic Links
- Dynamic Links 已废弃,因此我们建议您停止使用该服务。如需了解详情,请参阅弃用常见问题解答。
Firebase ML
Performance Monitoring
- 确保每个适用的项目成员(即“负责人”,英文为“principle”)设置其偏好设置,以便接收有关 Performance Monitoring 或项目状态(例如结算方案更改或配额限制)的提醒。如需了解详情,请参阅接收 Firebase 提醒。 
- 请考虑启用将 Performance Monitoring 数据导出到 BigQuery 的功能,以便您可以使用 BigQuery SQL 分析数据,也可以导出数据以便在您自己的工具中使用。 
Realtime Database
- 配置您的 Realtime Database Security Rules 以防止非预期的数据访问。 
- 确保为扩容做好准备。Realtime Database 的默认配额足够大,能够满足大多数应用的需要,但有些应用可能需要额外的容量。 
- 配置 ProGuard 规则以便与 Realtime Database 搭配使用。 
Remote Config
- 确保不会有任何实验性的 Remote Config 规则影响您的发布版用户,并保证在您的应用中分发相应的服务器和应用内默认值。