安全模式：天猫 App 启动保护实践

（点击上方的蓝色文字，可快速关注我们）

在App热修复中有一个特殊情况，就是应用在启动阶段crash，根本启动不了，热修复就难以奏效，不过这种情况也能解决。前段时间微信读书分享了他们的启动保护方案，现在天猫也分享了他们的实践，叫做安全模式。本文介绍了天猫安全模式的由来、设计思路、原理和易用性考量等等。

你也可以看看天猫客户端之前分享的内容：

不要写死！天猫App的动态化配置中心实践
天猫App A/B测试实践

引言：天猫客户端用户众多，如何保证天猫App的稳定性是非常重要的任务，而启动阶段的保护是其中关键的一环。

天猫安全模式致力于解决APP启动阶段的crash等问题，同时具备自修复能力、同步热修复能力，是一整套启动保护的解决方案。

天猫安全模式的由来

问题：APP在使用过程中，有时会遇到线上无法修复的启动crash问题，用户无法使用APP

思考：

我们能否避免这样的问题发生？有没有办法让程序自动修复该问题？
我们怎么样能更好的修复同类问题？

结论：

我们需要一个可以保证APP顺利启动并解决重大问题的解决方案 - 安全模式

天猫安全模式设计

天猫安全模式重点放在了解决启动阶段问题上，从配置后台、客户端能力、数据、测试四个方面给出了统一的解决方案，同时也考虑到了不同APP的兼容性问题。

天猫安全模式的原理

APP crash的原因有很多，每个APP设计的方案也有不同，将其所有的异常错误都捕捉到很困难，因此我们换了个方式，完全从用户的角度来思考什么是异常退出，也就是打标记flag方式

如何判断异常退出：

APP启动时记录一个flag值

满足以下条件时，将flag值清空：

APP正常启动10秒
用户正常退出应用
用户主动从前台切换到后台

如果在启动阶段发生异常，则flag值不会清空，通过flag值就可以判断出客户端是否异常退出

每次异常退出，flag值都会+1

安全模式的分级执行策略：

安全模式中根据flag值的大小做了分级执行策略，目前分为两级安全模式，连续crash 2次为一级安全模式，连续crash 3次及以上为二级安全模式

业务线可以在一级安全模式中注册行为，比如某业务要清空缓存数据，这样在进入一级安全模式时，安全模式就会自动调用注册的行为，尝试修复客户端

如果一级安全模式无法修复APP，则会进入二级安全模式，二级安全模式会将APP恢复到初次安装状态，将Document、Library、Cache三个根目录清空

热修复执行策略：

老版本热修复策略：二级安全模式中触发。

问题：连续crash 3次后触发，在有问题的情况下，能打开这么多次APP的用户太少了，我们能不能更快的修复呢？

新版本修复策略：

将热修复从具体的级别中剥离，只要发现配置中需要热修复，APP就会同步阻塞进行热修复，保证修复的及时性

灰度方案：

安全模式制定了简单的灰度策略，灰度时，配置中会同时包含灰度、正式两份配置，也会包含灰度的概率

APP根据特定算法算出自己是否满足灰度条件，如果满足，则使用灰度配置，否则使用正式配置

天猫安全模式在易用性上的思考

最开始时，我们并没有特别考虑易用性问题，因为前两个版本都只有天猫一个接入方，不用考虑差异性问题；但在对接集团其他APP时，发现大家的需求点还是有较大不同的，同时也发现了安全模式存在的不足，因此我们加大了对易用性的考虑，主要体现在以下几点：

接入成本

站在接入方角度，完善文档，重新定义接口，力求接口简单、清晰，降低接入成本

统一配置后台

方便接入方配置信息，利用阿里云的CDN服务搭建统一的配置中心，可按照APP、版本来配置

定制性

考虑到不同APP的定位以及实际需求的不同，改造安全模式支持定制功能，让接入方来决定具体行为
欢迎关注“互联网架构师”，我们分享最有价值的互联网技术干货文章，助力您成为有思想的全栈架构师，只聊架构，不聊其他！打造最有价值的架构师圈子和社区。
长按下方的二维码可以快速关注我们
如想加群讨论学习，请点击右下角的“加群学习”菜单入群。