一、版本发布

1.1 测试发布

1.2 发布 Checklist

  • APP 图标
  • 版本号
  • 编译号
  • ASO关键字
  • 故事板
  • 更新日志
  • 功能是否全部完成
  • Bug 是否全部修复
  • 开发截止时间
  • UAT开始时间
  • UAT过审时间
  • 提交市场时间
  • 正式上线时间
  • 是否需要服务器扩容
  • 是否需要 CDN 支持
  • 是否需要运维支持
  • 所有渠道已准备
  • 所有三方平台服务已准备
  • 新增接口列表
  • 变更接口列表
  • 安装包大小
  • 增量包大小
  • 产品已确认
  • 设计已确认
  • 测试已确认
  • 后端已确认
  • 前端已确认
  • 移动端已确认

二、版本更新

2.1 更新引导

版本更新分为强制更新和非强制更新两种。强制更新适用于需要修复线上严重 Bug 情况，对用户使用体验影响较大。

当一个新的版本上线的时候，往往需要考虑四种情况。把新用户、老用户和新版本、老版本做交叉匹配。

版本/用户 新用户 老用户
新版本 正常引导 告知更新
老版本 向下兼容 保留服务

往往新用户、新版本是最容易的，反正都是新的，自然很多东西不用考虑之前的情况。但是老用户在新版本上，就需要考虑很多情况。

一般来说，新增一个功能对于老用户来说也是没问题的，因为老用户也没接触过，所以可以当新用户处理。但修改一个功能时，则需要非常谨慎地去看待老用户的兼容问题。比如某个健身应用需要用户选择自己的身份，学生、白领、老人等等。

如果某个需求是在新版本上删除某个角色时，则需要考虑这些选择了这个身份的老用户该怎么处理，是映射到一个新的角色上，还是让这部分用户再选一次，这就需要有设计和考量。同样，针对新用户在老版本上，一般是需要保留老版本已有功能的正常运行，如果实在不能向下兼容或者因为某个重要新增功能，希望用户尽快到新应用上，那么需要相对强的提醒引导用户升级，直到老版本比例足够低的时候，才可以考虑放弃老版本的服务提供。

2.2 更新方式

每次打开应用时都需要检测服务端是否有新版本，如有更新则提示用户采用增量更新，而不是下载整个安装包覆盖更新。

  • Android 点击更新启动后台下载，下载完成后提示安装；
  • iOS 点击后进入 App Store（苹果应用商店审核不允许弹出更新提示框，请确保审核完成并发布之后再打开更新提示）。

2.3 更新内容

更新内容通常包括新增（New）、优化（Updated）和修复（Fixed）三种。

  • 新增（New）：代表新功能；
  • 优化（Updated）：代表功能优化；
  • 修复（Fixed）：代表问题修复。

2.4 更新帮助

可以通过故事板和引导层来帮助用户体验更新内容。

  • 故事板作用于本地没App重新下载后的第一次打开，本地有App且更新完版本后的第一次打开；
  • 引导层是写死在某一个版本号的，当用户本地有App且更新完版本后第一次打开，进入到首页的时候显示。