Android/iOS 应用版本的维护 2018-12-18 / 2,566 次 / 快抢沙发 / 58

Android/iOS 应用版本的维护，是最基本也是最重要的应用维护的因素之一。

Android/iOS 应用版本的维护，是最基本也是最重要的应用维护的因素之一。我们在一个 Android/iOS 应用上线之前，往往容易忽略其中的一些细节。这些细节很有可能成为以后的隐患之一。

如何确定一个良好的版本信息规范，针对基本的版本号和 Build 号，Android/iOS 开发可以参见这篇文章《推荐的移动应用的版本名称管理规范》，我在这里就不再过多的描述。

建议通过 .txt 或者 .md 格式的文本，放到当前工程根目录底下，跟随 Git 仓库一起不停地更新迭代。

有的时候，用户需要了解当前应用的版本信息，和当前版本更新的内容。我觉得针对应用关于页面，以下几个点应该注意一下：
1.应用关于页面，一定要明确显示应用的版本信息，Build 号可以带上，也可以不带。例如：1.3.0 或者 1.3.0(11)。
2.可以附上当前版本更新的功能，Bug 的修复看情况是否显示给用户。
3.可以附带上最近几个版本的更新信息，Bug 的修复看情况是否显示给用户。

如何设计好 Android/iOS 应用的版本更新机制，是应用版本维护的最重要的基础功能。

Android 应用：

Android 的应用市场众多，各个应用市场，如国内的百度、360、应用宝等互联网应用市场，华为、小米、OPPO、VIVO 设备自带应用市场，还有 Google Play 这种针对国外客户，当然你还得有一个自家的发布渠道。我觉得以下几点需要注意：
1.热更新：目前针对 Android 的热更新技术已经相当成熟了，在应用的第一个版本发布的时候，就应该预埋热更新技术，当然如果是多渠道包，每个包都做热更新的话，就需要多个基准包和差分包，如果能够方便管理起来，可以每个渠道包都做热更新，如果管理起来比较麻烦，可以只做自家渠道包的热更新，将其他渠道包引流到自己渠道包上。热更新能够很好的修复紧急 Bug 更新迭代版本，假若常规更新出现问题，还可以通过热更新来修复常规更新机制，热更新最大的好处在于：能够在很大程度上减少应用升级对于用户的打扰，能够方便快速的修复紧急 bug 和更新新版本！
2.常规更新：常规更新是指采用下载新版本安装包覆盖安装更新的方式，无论是采用：自动检测版本更新、手动检测版本更新、推送版本更新。包括：下载自家服务器上新版本安装包、下载第三方应用市场上的新版本安装包。这个里面需要注意：目前很多国内市场开始要求必须要包含应用市场自家的版本升级 SDK（如：百度/360 等），否则不给于应用上架！我们只能在应用中集成市场要求的版本更新 SDK，如果可以同时包含我们自己的版本更新 SDK，可以在技术上去判断规避，优先从自己的服务器上去更新版本，而不是从对应的市场上更新版本。如果第三方应用市场不要求使用它们市场的版本更新 SDK，我们就用自己的版本更新 SDK，这样可以方便快速收敛版本到我们自己的渠道版本上！注意：有些市场，尤其是 Google Play，应用里面不能包含明显的新版本/版本升级 等字样，同时也严格杜绝任何第三方的版本更新机制，不然的话，很容易造成 Google Play 账号被封，很难受。那我们就不要加入任何常规更新机制了。
3.远程 WebView 页面更新：我们可以在初始版本加入一个可远程控制的 WebView 页面，这个页面可以在合适的时候来推送应用版本的更新。
4.强制更新：强制更新其实是和版本禁用意思差不多，为了能够更好的收敛应用版本，可以对版本过低的应用采取强制更新或者版本禁用。
5.发布渠道：一般情况下，有两个渠道是必须建立的，一个就是自家的应用发布渠道，另外一个是 Google Play，这两个渠道比较特殊，自家的应用发布渠道是为了更好的收敛控制版本，Google Play 是为了能够让国外用户方便下载安装我们的应用。其他两类渠道，设备自带应用商店推荐（Android 设备销量排名前五位）：小米、华为、OPPO、VIVO、三星。互联网应用商店推荐：百度、应用宝、360。
6.发布方式：现在国内最流行的发布方式是：二维码。通过扫描二维码，然后跳转页面进行从自家渠道下载 .apk 包安装，或者跳转到当前设备应用商店或者第三方商店，可以根据不同的场景进行优化，这个是自家服务器 HTML 页面逻辑判断处理。二维码一般放到官方网站、产品外包装、或者其他地方。还有就是直接或者间接访问 HTML 链接页面来安装。国外目前由于没有像中国一样的普及流行微信/QQ 扫码的习惯，不方便使用二维码扫描工具，通常建议直接或者间接访问 HTML 链接页面来安装！另外微信扫描二维码不能直接跳转页面之后点击下载安装应用，我们可以通过结合应用宝的微链接来优化这个过程！另外可以通过提示用户在应用市场下载指定名称的应用。
7.其他：
A.如果你想要更好的收敛版本，版本更新就尽量向自家渠道包靠拢，如果你想用户更快的更新版本，版本更新可以尽量采用以下优先渠道：Android 设备自带应用商店（如小米、华为、OPPO、VIVO） > Android 第三方应用市场（检测到设备上安装了相对应的应用市场助手：如百度设备助手、应用宝、360 设备助手等） > 自家应用渠道（未检测到设备上安装了相对应的应用市场助手）
B.应用签名和包名：请严格保管好应用对应的签名文件和相关信息，防止丢失和过期（一般不容易过期），一旦你的签名文件有问题（丢失或过期），就需要更换签名了，这个时候，很多应用市场可能就不允许你更换签名，它会对比现有市场上的应用签名，发现不同就禁止你提交更新包，即使自家渠道可以更新下载，但是安装的时候，由于签名文件的不同，是无法覆盖的。这种情况下，为了能够让用户更新升级应用，你就只能更换包名了，设备上会显示两个相同的应用，需要一个友好的方式提醒用户不再使用之前旧版本。另外，如果没有特殊情况，所有渠道包的包名和签名文件，一定要保持一致！以保证任何渠道的应用包可以互相覆盖更新迭代！
C.有的时候，可以主动或者被动的利用设备自带的应用商店来进行自动更新。这种方式是能最小的打扰用户，当然需要用户设置了 Wi-Fi 情况下，应用商店新版本自动更新。

iOS 应用：

iOS 的应用市场只有 App Store，或者企业应用自发布的形式，我们需要注意以下几点：
1.热更新：目前针对 iOS 原生开发的热更新技术，可以实际生产使用的只有 JSPatch，而且还面临审核不通过的问题，我们可以在一定程度上使用，同时如果为了更新方便，我们可以采用跨平台开发方案：ReactNative 等方式。
2.常规更新：常规更新是指采用下载新版本安装包覆盖安装更新的方式，这个里面需要注意：目前 iOS App Store 是禁止在页面明文文本包含应用“更新”，也会在一定程度上禁止提示当前应用有最新版本，比如进入应用之后，有弹出提示框提醒。如果用户开启了 App Store 应用 Wi-Fi 情况下自动更新应用，那么应用的更新就变得简单。如果没有，我们可以通过远程推送或者弹出提示框的形式提示有新版本，用户点击下载安装，就跳转到 App Store 应用的界面，当然这个要在一定程度上避免审核被拒。
3.远程 WebView 页面更新：：我们可以在初始版本加入一个可远程控制的 WebView 页面，这个页面可以在合适的时候来推送应用版本的更新。
4.强制更新：强制更新其实是和版本禁用意思差不多，为了能够更好的收敛应用版本，可以对版本过低的应用采取强制更新或者版本禁用。
5.发布渠道：一般情况下，我们只需要发布 App Store 这一个渠道就可以了。另外需要发布测试版的话，可以通过 TestFlight 来实现，可以直接转正式版本上线。有些情况下，我们需要发布企业版本，但是注意，如果你既要发布 App Store 版本，又要发布企业版本，两个版本的 Bundle ID 是不能一样的，推荐在 App Store 版本的 Bundle ID 后面追加上 .enterprise 来区分。
6.发布方式：现在国内最流行的发布方式是：二维码。通过扫描二维码，然后跳转页面到 App Store 应用下载，这个是自家服务器 HTML 页面逻辑判断处理。二维码一般放到官方网站、产品外包装、或者其他地方。还有就是直接或者间接访问 HTML 链接页面来安装。国外目前由于没有像中国一样的普及流行微信/QQ 扫码的习惯，不方便使用二维码扫描工具，通常建议直接或者间接访问 HTML 链接页面跳转到 App Store 页面安装！我们可以通过结合应用宝的微链接来优化这个过程！另外可以通过提示用户在应用市场下载指定名称的应用。

Android & iOS：
A.应用启动到载入第一个稳定页面，这个过程，要保证应用绝对不能 Crash！这个过程如果 Crash 了，诸如热更新、常规更新就不能很好的维持了，除非有一种情况，利用设备自带的应用商店能够在 Wi-Fi 情况下自动安装更新新的应用版本，或者用户手动安装新版本，否则当前的 Crash 版本很难升级到没有问题的新版本，切记！
B.HTML 页面挂载的链接尽量采用 HTTPS/非 IP URL，静态码的二维码。

Android/iOS 前期应用版本维护的整套机制的确定，对应用后期的 Bug 修复、版本更新、版本收敛有非常重要的意义，前期一定要构建好！

上一篇： « macOS 上使用 Jenkins 搭建 Android/iOS 持续集成环境 下一篇： 螃蟹和癌症有什么关系？ »