写点什么

最后的拯救方案 - 安全模式

  • 2016-07-24
  • 本文字数:1904 字

    阅读完需:约 6 分钟

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

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

天猫安全模式的由来

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

思考:

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

结论:

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

天猫安全模式设计

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

配置后台

  • 统一的配置后台,具备灰度发布机制

客户端能力

  • 在 APP 连续 Crash 情况下具备分级、无感自修复能力
  • 具备同步热修复能力
  • 具备指定触发某项特定功能的能力
  • 具备功能注册能力,可以方便的后期扩展安全模式

数据统计及告警

  • 统一的数据平台
  • 监控告警功能,让你及时发现问题
  • 可以查看热修复成功率等数据

快速测试

  • 优化预发环境下测试
  • 优化每次回归验证安全模式的难度等

天猫安全模式的发展

安全模式到目前为止经历了 4 个大的版本,功能一直在不断的完善,下图介绍了每个版本的主要功能

天猫安全模式的原理

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 的定位以及实际需求的不同,改造安全模式支持定制功能,让接入方来决定具体行为
  • 比如天猫觉得用户主要关心的是功能可用,不关心是否进入安全模式,因此不需要显示一个独立的提示页面,但与其他 APP 沟通时发现,有些 APP 还是很想有这样一个提示页面来告知用户我们做了什么

灰度机制

  • 安全模式最开始的定位只是用于解决启动 crash 问题,但是在与集团内其他 APP 沟通的过程中发现,他们也有需要在 APP 不 crash 的情况下解决问题的需求,直接发布还是很危险的,对灰度机制的需求很迫切,因此我们在 4.0 版本中实现了灰度机制

数据分析

  • 采用集团统一的数据平台,方便接入方查询相关数据,同时为安全模式的改进提供依据

快速测试

  • 针对测试(模拟连续 crash)加入特殊处理,提高测试效率

结语

  • 安全模式目前发展到 V4.0 版本,已上线超过半年时间,很好的保证了天猫 APP 的启动安全,后续我们还会持续对其打磨,让安全模式更好的为 APP 保驾护航。

感谢徐川对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016-07-24 17:412710

评论

发布
暂无评论
发现更多内容

ClkLog埋点分析系统常见问题-埋点集成篇Sec. 1

ClkLog

开源 埋点 用户行为分析 画像 埋点分析

XSKY 亮相中国移动智算存储论坛,共话 AI 存储创新之路

XSKY星辰天合

TON链上的代币开发与小程序开发:模式与要求

区块链软件开发推广运营

dapp开发 区块链开发 链游开发 NFT开发 公链开发

火山引擎谭待:日均10亿tokens是企业AI转型门槛

极客天地

RPA技术简介:RPA概念、应用场景和行业发展趋势

八爪鱼采集器︱RPA机器人

RPA 自动化 RPAxAI

如何利用代理IP提升跨境市场竞争力?

IPIDEA全球HTTP

超八成读者这样阅读,是因为……

脑极体

AI

巧用商品详情数据,制定精准营销策略

Noah

创新引领未来:哈银消金双料大奖彰显数字金融新高度

极客天地

Footprint Analytics 深化 Arbitrum 生态系统数据分析能力

Footprint Analytics

区块链 公链 区块链数据

如何根据API返回值优化商品搜索关键词

技术冰糖葫芦

API Explorer API 测试 API】 API 策略

图解Kafka:Kafka架构演化与升级!

王磊

Gate.io盘前交易:DOGS热潮下抢先交易的新策略

区块链软件开发推广运营

dapp开发 区块链开发 链游开发 NFT开发 公链开发

顶尖选择:5个RPA主流产品性能评测

八爪鱼采集器︱RPA机器人

RPA 自动化 RPAxAI

mac屏幕录像软件:ScreenFlow for mac v10.0.10汉化版

你的猪会飞吗

mac软件下载 mac破解软件下载

大型数字化企业怎么定义?为什么说大型数字化企业更需要堡垒机?

行云管家

数字化 等保

优化财务运营管理,实现企业可持续进步

智达方通

企业管理 全面预算管理 财务管理

怎么都在劝我用通义灵码

阿里云云效

阿里云 云原生 通义灵码

微软 Azure 推出文本到语音虚拟人;英伟达发布 8B 小语言模型,可在 RTX 工作站部署丨 RTE 开发者日报

声网

为什么重写hashCode一定也要重写equals方法?

不在线第一只蜗牛

Java 基础

数业智能心大陆AI大模型,共情陪伴你的心理健康

心大陆多智能体

智能体 AI大模型 心理健康 数字心理

AI驱动的商品计划软件:现代企业运营的核心引擎

第七在线

怎么都在劝我用通义灵码

阿里巴巴云原生

阿里云 云原生 通义灵码

程序员如何选择博客平台?

博客趣

个人博客 博客搭建 博客平台

ETL数据集成丨为什么没有做好ETL的BI工具最终都会失败?

RestCloud

数据处理 BI ETL 数据集成

深度解析RPA的特点、优势及其与AI的结合

八爪鱼采集器︱RPA机器人

RPA 自动化 RPAxAI

扫码填表时,如何快速填充上次提交的内容?

草料二维码

无需多部备用机,云手机方便又便宜!

Ogcloud

云手机 海外云手机 云手机海外版 云手机群控 云手机推荐

最后的拯救方案 - 安全模式_安全_胖纸_InfoQ精选文章