Android/iOS 应用版本的维护 2018-12-18 / 285 次 / 快抢沙发 /

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

本文是 AppX 系列中的一篇。AppX 系列是 @ifeegoo 个人移动互联网学习、工作和生活的提炼与总结的文章系列。更多内容请关注:
AppX @ifeegoo https://www.ifeegoo.com/appx.html

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 设备销量排名前五位):小米华为OPPOVIVO三星。互联网应用商店推荐:百度应用宝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 修复、版本更新、版本收敛有非常重要的意义,前期一定要构建好!

打赏
本博客所有文章如无特别注明均为原创。复制或转载请以超链接形式注明转自ifeegoo 的个人博客,原文地址《Android/iOS 应用版本的维护
上一篇: « 下一篇:

> 添加新评论

Copyright © ifeegoo 的个人博客 Time is limited, less is more! / 粤ICP备15109713号-1 / Theme by Hang & Ben / WordPress / 知识共享许可协议