移动端app容灾

可能很多人对这个概念比较陌生，我们常说的容灾策略，一般都特指服务器端的容灾，那么移动端容灾是个啥！其实跟服务器一样，就是持续保证我们app的可用性，在crash或者anr的时候，能够通过一些手段实现保证后续可用。

本篇不涉及复杂技术，更多的是对方案的探讨，请放心食用！

为什么会有这个概念

其实在笔者角度上看，技术与业务的关系其实是比较单一的，虽然不至于对立，但是一个业务人员看待技术，最关心的可能就是稳定性了，在“老板”角度上看，他其实不太关心所用的技术是什么，但是一定关心这个服务能不能保证自己的业务能不能持续，这也是笔者访谈了几位非技术人员得出的结论，同时在“降本增效”的今天，追求稳定性可能是大部分公司的选择了。还有就是站在长远立场上看，移动端的容灾也慢慢会成为各大公司角逐的一个点。一个由于crash导致而离开的用户，就有可能带走10个相关联客户，在app场景如此，在游戏场景也是，如果打着游戏突然闪退了，肯定是一个非常不好的体验。

本文希望介绍一些移动端的容灾策略，希望能够给各大开发者提供一个启发。

容灾策略

降级

首先是第一个策略，降级，比如app crash的时候，我们采用降级的手段，转移到h5页面

这个方案的特点是 存在两套页面，一个是原生页面，一个是h5页面，大部分公司可能都会同时有这两套ui，一个用于投放app，一个用于h5页面，比如网页还有m站这些。
当主页（也可以是特定activity），跳转到其他页面时，如果发生了crash，就从主页直接打开h5容器，展示h5页面，这个在拼*多app方案上常用

进程多活

android在多进程上给我们提供了很多便捷的地方，只需要在activity或者其他的manifest文件上声明process即可

android:process=":test"

一般我们不做特殊配制的话，activity等就是运行在以包名为名称的进程上。这里的多进程方案有两个

• 
  
• app crash的时候，通过安全气囊机制，重新为用户打开到当前页面，即我们会杀掉原本的进程，重新打开一个新进程，并为用户定位到当前页，可以携带本地的tag或者其他标识进行页面的定位，这个方案可以运用在游戏中，如果crash了立马主动帮用户重开，并提高这部分用户的载入速度！
  

• 
  
• （这也是我最推荐的）app crash/anr的时候，不重新进入原页面，而是通过安全气囊机制，打开一个纯净版的链路这个链路是怎么理解呢？这里特指是业务简单的链路，即满足用户最基本需求的链路。比如说我们有一个商城app，那么下单就是最关键的链路，我们只需要在app crash的时候，打开一个业务最简单的页面，让用户去操作即可，这样就避免二次可能产生的crash！
  

强制升级

如果某个用户在app的crash次数达到一定时，就直接采取强制升级的方案，让用户的app始终保持最新版本，避免由于老版本的影响导致这部分的用户流失。这个方案的实现可直接对接到app内的升级策略

脏数据清除

有一些crash可能是由于用户本地的脏数据引起而导致的，那么我们可以在crash的时候，把这部分数据清除，或者简单来说直接清除所有缓存，这种“重置”操作会一定程度上避免由于脏数据等特定crash的发生，比较适用于线上存在脏数据用户的情况。

安全气囊机制

可以看到，无论是哪一个方案，我们都需要依靠crash/anr检测的机制，才能够实现，没关系，相关的文章早已准备好黑科技！让Native Crash 与ANR无处发泄！，同时也配备了开源库Signal，运用Signal，我们可以实现很多crash后的安全措施，也希望大家运行起来demo，尝试一下各种脑洞大开的方案！

让业务能够持续稳定下去，降低由于异常导致的损失，这是笔者一开始想要实现的，当然，目前我们的库还在不断完善的过程中，也希望广大开发者能够加入进来，一起去探索一个新方向！

最后

当然，一个app好坏大部分责任在于产品的选择，赛道的选择！能否提供一个好的服务给用户，才是决定一款app好坏的标准！我们技术能做的，就是不断突破场景的限制，给产品提供好的工具啦！

本来决定要分享asm相关的，但是在洗澡的过程中发现其实很多对服务器端的容灾策略的思想也是可以在移动端上去进行的，在app的业务迭代过程中，一定会对稳定性造成很多挑战，在各大公司人员缩减的背景下更是如此，所以说，建立一套安全气囊装置，一定会是后面多个公司的探索方向！