如何合理的规避移动端App的频繁更新

    

app频繁更新莫过于以下两点：

1. 修复线上bug；
2. 敏捷开发、频繁迭代；

那么要解决频繁更新的问题，我们就从这两点进行分析：

首先，频繁修复线上bug，反映出两个问题。第一、发版前测试环节是否充分考虑各种应用场景，回归测试是否充分覆盖每一个功能点；第二、非致命性bug是否有必要进行发版修复，过于频繁却价值较低的升级，有时令人对一款APP的好感度直线降低，甚至卸载了事。

那么如何解决以上两点问题呢？

第一点，在发版前测试人员的测试工作固然重要，但是开发人员提交高质量的代码也是至关重要的，这里高质量的代码并非指资深程序员才能写出的代码，我们可以将其理解为思路清晰、结构合理、开发人员完成第一遍编码工作后，应该结合功能应用场景，产品流程进行自我测试，代码优化，在时间充裕的情况下，尽可能的给代码进行详细的注释说明；团队在条件允许的情况下，每个产品周期进行一次Code Review，交叉审视。有能力的开发人员，在自己工作之余，可以帮助其他同事检查代码，发现问题。往往这样的一套流程走下来，开发人员自身就会发现很多bug。这样一来到达测试人员手里的版本是一个完整度较高，bug较少的测试版本，从而减少了一些并非测试人员测试范围的工作（例如功能缺失、UI不符等），增加了测试人员对重点功能以及各个场景的测试时间，从多年的工作经验能看出，当发版在即的时候，时间不够充裕的时候，测试和产品往往会迫于无奈在某些并不完美的功能上进行妥协，甚至由于时间原因，根本无法进行回归测试。这样就增加了发布版本线上出现bug的几率。我想只要遵守以上几点，线上bug出现的几率会大幅降低，从而减少版本的频繁更新。

第二点，当我们发现线上版本出现一些bug时候，首先应该对bug进行排查，分析bug所能造成的影响，如果并非是致命性的bug，是否可以考虑在下一次版本升级中进行更新。

以上两点是从开发到测试以及版本发布流程的管理角度出发，那如何从技术的角度去减少产品的更新频次又或者是在用户无感的情况下进行更新呢？

首先app类产品，是用户需要装载到手机上的应用程序，所以app安装包的更新是用户所能感知的，那么我们如何去减少用户的感知又能做到app的升级呢？

第一：app的开发模式，现在比较的主流模式是混合开发模式，这样的模式将应用主体使用原生开发，我们可以理解为房子的框架，但是框架内所载内容实际是由我们的浏览器引擎对服务器上的内容页面进行渲染的，所以这样的开发模式可以使得开发人员对服务器上的内容进行更新而无需用户对应用进行升级，然而这样的方案并非完美，众所周知，当浏览器对页面内容以及js脚本进行渲染时，是需要从远端拉取对应数据进行渲染的，这样的一个等待会大大降低用户在app上的使用体验，所以业内又衍生出了一种技术，离线更新，也就是在用户并未打开页面的时候，对页面进行离线包下载，当用户打开页面时，先从离线包中进行加载，这样大大提高了页面加载的速度。

第二：app的热更新技术，当程序主体需要发生更新的时候，我们就只有选择发布升级包让用户进行安装吗？当然不是，对于一些修改量小的bug，我们可以选择热更新的方式对应用进行Bug修复。

第三：选择合适的开发框架，目前业界出现了诸多混合式开发框架，他们的开发语言，以及开发习惯都是参照或是直接使用前端开发的模式，旨在于帮助更多前端开发人员也能进行app的开发，并且做到一套代码多端输出。从目前来看，混合式开发主要有Weex(已被阿里技术团队多次运用)，ReactNative(FaceBook主推的混合式开发框架，使用局部更新技术，效率更高，目前美团有在使用)，这两大主流框架占据了混合式开发的大壁江山，但相对于原生开发，还是会略逊一筹。那么有没有比原生性能更高的混合式开发框呢，又能更好的兼容android,ios两端呢？google在不久前推出了flutter开发框架，flutter框架的渲染性能是可以与原生媲美的，并且他两端的适配能力要强于Weex与ReactNative，因为flutter是基于底层代码进行直接绘制，并非使用浏览器引擎进行渲染，或者转换为原生代码在进行渲染。所以选择一个合适的开发框架，也是减少升级版本过程中产生时间、人力投入的不二选择。

以上是我对技术方面避免产品升级的一些看法，但并非是代表依照上面所推荐的就是最好的方法，我们应该结合实际情况，以及管理技术相搭配的方式进行合理的选择更甚。

敏捷开发、频繁迭代是app给用户良好体验，以及增加用户可玩性的一个策略，但频繁的更新亦能给用户带来负面的影响。所以在产品升级等方面，多结合以上提到的几点，能用技术解决的，竟可能的少让用户升级，产品周期的规划，也应该结合一些科学的分析，进行合理的安排。