内部测试、分阶段发布与正式发布
先发布到内部测试轨道,再推广到封闭测试和开放测试,随后使用分阶段发布比例逐步推向正式环境,并监控崩溃率。
内部测试、分阶段发布与正式发布 是 CoddyKit 上的免费 React Native Academy 课时。 这是第 4 节课,共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 React Native Academy 学习路径的一部分,你的进度在网页和 CoddyKit 应用中同步。 React Native Academy 课程共包含 4 节课。
四种发布轨道
Google Play Console 提供四种发布轨道,构成渐进式发布流程。内部测试可以立即覆盖最多 100 名测试人员,无需审核。封闭式测试(alpha)面向特定的受邀名单。开放式测试(beta)允许任何人公开选择加入。正式版面向您所选国家或地区的所有用户。每种轨道都充当一道安全关卡——您可以在每个阶段验证质量,然后再进入下一阶段。
// Release track comparison:
// Internal Testing:
// Testers: up to 100 (by email/Google Group)
// Availability: Instant (no Google review)
// Visibility: Hidden from public
// Best for: Team + QA testing
// Closed Testing (Alpha):
// Testers: Specific invite list (no limit)
// Availability: After brief automated check
// Visibility: Hidden from public
// Best for: Beta test with partners/selected users
// Open Testing (Beta):
// Testers: Anyone who opts in
// Availability: Visible public beta badge
// Best for: Community feedback before launch设置内部测试
成功构建应用后,内部测试是您的第一站。创建内部测试版本,上传 AAB,并通过电子邮件或 Google 群组添加测试人员。测试人员会收到一封包含选择加入链接的电子邮件——他们必须点击链接,然后在 Play 商店中找到该应用并安装。内部测试版本会在发布几分钟内送达测试人员(正式版处理可能需要数小时)。在继续发布之前,请务必先在此处验证核心流程均能正常运行。
// Internal testing setup:
// Testing > Internal testing > Testers tab
// > Create email list: 'Core Team'
// > Add emails:
// alice@yourcompany.com
// bob@yourcompany.com
// qa@yourcompany.com
// Share the opt-in link with testers:
// 'Join the test at this link: [opt-in URL]'
// Testers click link, then search for the app on Play Store
// App appears with an 'Internal' badge
// Tester checklist:
// [ ] Sign up flow works
// [ ] Core feature performs correctly
// [ ] No crashes in main paths创建封闭式测试轨道
在公开发布前,封闭式测试(alpha)适合规模更大的受邀群体,例如 beta 用户、影响者或合作伙伴。创建版本的方式与内部测试相同:上传相同或更新后的 AAB,填写版本说明并发布。您可以在“测试人员”标签页中通过电子邮件列表添加测试人员。您可以拥有多个封闭式测试轨道,并为其配置不同设置(例如,一个轨道用于功能测试,另一个轨道用于本地化测试)。
// Create a closed testing release:
// Testing > Closed testing > Create new track
// Track name: 'Alpha'
// Add testers:
// Testers > Create email list: 'Alpha Testers'
// Or: Add a Google Group email
// (all group members become testers automatically)
// Promote an internal build to closed testing:
// Testing > Internal testing > Releases
// Select the release > Promote release
// > Closed testing > Confirm开放式测试(公开 Beta)
开放式测试会向任何选择加入 beta 计划的 Play 商店用户提供您的应用。应用的 Play 商店详情页上会显示“加入 Beta 版”按钮。Beta 用户会在应用上看到“Beta”标签,他们的评价也会与正式版评价分开。您可以通过开放式测试,在公开发布正式版之前,从您没有的设备配置中获取更广泛的真实使用反馈和崩溃数据。
// Open testing setup:
// Testing > Open testing > Create new release
// Set the percentage of users who can join (optional)
// The opt-in URL for beta is shareable:
// 'Try our beta at: play.google.com/store/apps/...
// (scroll down and click Join the beta)'
// Benefits of open testing:
// - Real crash data from diverse devices
// - Public rating separate from production
// - Community can submit feedback
// - Validates localization on regional devices
// Tip: Announce the beta on social media
// to quickly gather a large tester pool发布到正式环境
从开放式测试(或内部测试)发布到正式环境是关键步骤。转到测试 > 开放式测试,找到您的版本,然后点击发布版本 > 正式版。首次发布到正式环境会触发Google 审核(通常需要 1–3 个工作日)。后续更新的审核速度会更快。审核完成后,应用会出现在 Play 商店搜索结果以及目标国家或地区的商店详情页中。
// Promote to production:
// Testing > Open testing (or Internal)
// > Select release > Promote release
// > Production > Next
// Set initial rollout percentage:
// 10%, 20%, 50%, or 100%
// (for first launch, 100% is fine — you have no existing users)
// For updates to existing apps:
// Use staged rollout starting at 10–20%
// to catch issues before full deployment
// Review timeline:
// First submission: 3-7 business days
// Updates: Usually 1-3 business days
// (faster if no new permissions or policy changes)分阶段发布到正式环境
分阶段发布会先向一部分现有用户发布更新,而不是一次性向所有用户发布。请从 5%–20% 开始,并监控崩溃率、ANR 率和负面评价。如果 24–48 小时后各项指标良好,再提高比例。如果发现严重错误,请立即停止发布——已经收到更新的用户仍会保留该更新,但在您修复并重新提交期间,不会有新用户收到更新。
// Staged rollout steps:
// Production > Create new release
// Upload new .aab (versionCode must be higher)
// Write release notes: 'Fixed startup crash on Android 13.'
// > Review release
// > Start rollout to production
// Set rollout percentage: 10%
// Monitor for 24-48 hours:
// Android vitals > Crash rate and ANR rate
// If stable: increase to 20%, 50%, 100%
// Production > Manage rollout > Update rollout percentage
// If broken: halt rollout
// Production > Manage rollout > Halt rollout使用 Android Vitals 监控崩溃
Play Console 中的Android Vitals会显示正式版用户的实时崩溃率和 ANR(应用无响应)率。Google 会将这些指标与您所在类别中的类似应用进行比较。如果您的崩溃率高于不良行为阈值(通常约为 1.09%),Play Console 可能会在您的商店详情页上添加警告标记,并降低您的搜索排名。请在“崩溃”部分调查所提供的堆栈跟踪信息,以确定修复优先级。
// Android Vitals > Crashes and ANRs
// Shows:
// Crash rate: 0.47% (Good)
// ANR rate: 0.12% (Good)
// Core vitals: All passing
// Crash cluster view:
// Each distinct crash signature grouped
// Tap a cluster to see:
// - Full stack trace
// - Affected devices
// - Android versions affected
// - Number of affected users
// - First/last occurrence
// Export traces to integrate with Sentry or Crashlytics
// for richer crash context (user actions before crash)管理评分和评价
回复用户评价表明您重视质量;修复用户报告的问题后,通常还能将负面评价转为正面评价。在 Play Console 中,转到增长 > 评分和评价即可查看并回复评价。筛选视图可让您按版本(有助于检测回归问题)、星级和国家或地区查看评价。来自特定版本的负面评价可以帮助您确定回归问题出现的时间。
// Review response best practices:
// 1-star review: 'App crashes on startup'
// Your reply:
// 'Hi, we are sorry to hear about the crash!
// This was fixed in version 1.2.3 released yesterday.
// Please update and let us know if the issue persists.
// You can also reach us at support@yourapp.com.'
// 4-star: 'Great app but missing dark mode'
// Your reply:
// 'Thank you for the feedback! Dark mode is on our
// roadmap for the next update (v1.3). Stay tuned!'
// Tip: Prioritize recent 1- and 2-star reviews版本号递增策略
如果 versionCode 不高于上次上传的构建版本,Play Console 会拒绝上传。一种简单的策略是每次上传都将其递增 1。如果您同时维护多个发布渠道(内部测试、beta、正式版),可以预留不同的范围:例如,1000–1099 用于内部测试,2000–2099 用于正式版。EAS Build 可以通过 eas.json 中的 autoIncrement: true 标志自动递增 versionCode。
// Auto-increment with EAS:
// eas.json
{
'build': {
'production': {
'android': {
'buildType': 'app-bundle',
'autoIncrement': true // EAS increments versionCode
}
}
}
}
// Manual strategy in app.json:
// Before each production build:
// Increment android.versionCode by 1
// Update version string if user-facing change
// Current: { 'version': '1.2.3', 'versionCode': 15 }
// Next: { 'version': '1.2.4', 'versionCode': 16 }使用 Firebase Crashlytics 深入分析崩溃
Android Vitals 显示汇总的崩溃数据,而 Firebase Crashlytics提供更丰富的上下文:崩溃前用户执行的操作序列、您添加的自定义日志消息、用户设备信息以及非致命错误跟踪。请将 Crashlytics 与 @react-native-firebase/crashlytics 集成。在关键操作前记录自定义键,这样收到崩溃报告时,您就能准确知道用户当时正在进行什么操作。
import crashlytics from '@react-native-firebase/crashlytics';
// Log custom keys for crash context
async function loadUserProfile(userId) {
crashlytics().setUserId(userId);
crashlytics().setAttribute('screen', 'ProfileScreen');
crashlytics().log('Fetching user profile...');
try {
const profile = await api.getUserProfile(userId);
crashlytics().log('Profile loaded successfully');
return profile;
} catch (error) {
// Log non-fatal error and rethrow
crashlytics().recordError(error);
throw error;
}
}完成发布和商店展示
达到 100% 发布比例后,您的应用就已完全上线,并会被 Google Play 的搜索算法编入索引。应用完全传播到各个地区并能通过搜索发现,可能需要24–48 小时。请监控您的获取指标:商店详情页访问者、安装转化率,以及自然安装与付费安装来源。上线周的安装量峰值结合留存数据,可以告诉您应用兑现商店详情页承诺的效果如何。
// Post-launch monitoring checklist:
// Day 1-3:
// [ ] Crash rate < 1.09% (Play benchmark)
// [ ] ANR rate < 0.47%
// [ ] Check ratings for immediate feedback
// [ ] Verify deep links work from the live listing
// Week 1:
// [ ] Install count vs impressions (conversion rate)
// [ ] D1 retention (users returning next day)
// [ ] Revenue if paid/IAP
// Ongoing:
// [ ] Respond to all 1- and 2-star reviews within 24h
// [ ] Monitor Android vitals weekly
// [ ] Release updates with new features and fixes快速检查
测试您对本课 React Native 移动开发概念的理解。
课程回顾
在本课中,您学习了:四种 Play Console 发布轨道(内部、封闭、开放、正式版)如何形成质量关卡流程、分阶段发布如何帮助您限制更新发布时的影响范围,以及如何使用 Android Vitals 和 Crashlytics 监控崩溃率。您还了解了如何回复评价,以及如何通过 EAS 自动递增 versionCode。接下来是综合项目:规划并构建一个完整的 React Native 应用。
用 AI 导师学习 JavaScript — 免费
在浏览器中编写并运行真实代码,获得全天候 AI 导师的即时帮助,并在网页或应用中继续学习。
- 课程
- 30
- 课程
- 120
常见问题解答
「内部测试、分阶段发布与正式发布」课时是免费的吗?
是的 — 「内部测试、分阶段发布与正式发布」的完整文本可在网页上免费阅读。要进行交互式练习(内置代码编辑器和全天候 AI 导师)并解锁 React Native Academy 课程的其余内容,请升级到 CoddyKit PRO。 React Native Academy 课程共包含 4 节课。
「内部测试、分阶段发布与正式发布」这节课中我会学到什么?
先发布到内部测试轨道,再推广到封闭测试和开放测试,随后使用分阶段发布比例逐步推向正式环境,并监控崩溃率。 你通过在浏览器中直接运行的动手代码来练习 React Native Academy,全天候 AI 导师会在你学习这节课的过程中回答你的问题。
学习 React Native Academy 需要有经验吗?
无需任何先前经验。CoddyKit 上的 React Native Academy 课程适合初学者到高级学习者,你可以从这里开始或从头开始,按照自己的节奏学习。 这是第 4 节课,共 4 节。
「内部测试、分阶段发布与正式发布」课时需要多长时间?
大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动,所以你能稳步进步,并在网页和应用中从离开的地方继续。
我能在这节 React Native Academy 课中编写并运行代码吗?
能。每节 React Native Academy 课都包含内置代码编辑器,你可以在浏览器中直接编写并运行真实代码,并获得即时 AI 反馈 — 无需本地设置。
此课程中的所有课时
- 创建密钥库并为 AAB 签名
- 设置 Play Console 商店页面
- 内容分级、政策与隐私
- 内部测试、分阶段发布与正式发布