作者：秦静超(非台)

“  本文次要讲述了淘宝客户端的平安生产，即在阿里内外成熟的技术计划的根底上，淘宝客户端是如何来建设本身的平安生产体系，从研发、构建、公布、应急四个阶段再次推动效率和用户体验一直失去降级。”

平安生产

首先咱们将“客户端平安生产”定义为：为预防客户端研发生命周期过程中产生体验相干的事变，而采取的一系列措施和流动。

为此淘宝客户端建设了“‘研发、构建、公布、应急’一整套规范化流程及平台”。

图 1 平安生产架构图

淘宝客户端平安生产，次要分 四个阶段：研发期、构建期、公布期和应急态，同时积淀开发过程数据，围绕数据线上线下异样复盘，为晋升代码品质、晋升开发能力，进一步欠缺平台做数据反对，从而晋升开发的良好研发环境，保障线上用户应用体验。

• 研发期：这一阶段次要是指开发同学把需要开发的阶段，往往是单模块的开发，这一阶段次要关注模块本身的品质，这一阶段平安生产平台次要通过需要治理、代码分支治理、单测治理、Code Review、测试申请 | 审批，一站式的形式为开发同学提供便当；
• 构建期：这一阶段次要是指开发同学把曾经通过测试的代码，将代码提交到集成区做代码的集成测试，这一阶段平安生产平台次要通过品质卡口、包大小剖析、产物校验来确保集成进来的模块是否满足集成规范（反复的资源文件、代码等或高危的隐衷 API、调试代码等或不合理的组件导出、DEBUG 代码等），通过前置危险剖析，避免危险代码集成；
• 公布期：这一阶段次要在通过测试后公布（灰度、正式）残缺的 APP、配置变更、流动上线下线，这一阶段需关注 APP 稳定性数据、性能数据、业务数据与舆情数据（端到云的监控计划），确保公布的 APP 满足用户的体验要求；
• 应急态：前三个阶段次要是躲避线上危险线，这一阶段则是在线上 APP 无奈满足用户失常应用时所进入的状态，线上外围指标稳定，会触发及时告警，从而通过钉钉疾速组建应急小队，对线上问题进行解决，剖析问题及问题背地的起因，疾速给出解决方案，通过预案回滚、降级解决等伎俩疾速化解线上危险，从而防止危险降级，避免故障产生。

另外为了确保线上 APP 的高可用体验，淘宝端架构专门成立了“端侧日常保障”小组，次要从事版本值班、大促保障、应急解决、复盘优化等工作，从日常工作中一直的发现问题、总结思考、优化流程、改良研发环境，一直把局部须要人工染指的流程自动化、数据化、平台化，从而进步“研发、构建、公布、应急”阶段的研发体验和研发效率，最终把人力从反复的、低效的工作中释放出来，通过过程数据一直优化平安生产平台体验，从而保障下层业务衰弱继续倒退。让开发有更多的工夫和精力从事更高维度的研发工程，晋升开发的成就感。

研发期

研发期次要是开发同学开发为主，这里平台提供了代码覆盖率（单测），外围模块中间件的单测代码覆盖率须要满足 80% 及以上，外围变更须要双人 CR（含 TL），非核心变更须要技术专家及以上 CR。

构建期

品质卡口

随着淘宝业务一直扩张，线上问题时有发生，淘系的场景十分丰盛，本地的测试、Review、Monkey、甚至灰度等伎俩都不能笼罩到所有的场景。但问题一旦到了线上，所破费的老本都急剧减少。

通过对历史线上问题进行一些剖析，发现其中的相当一部分问题，能够通过“动态代码剖析 ”，“ 二进制产物剖析”等办法提前发现，那么为什么不能用技术的伎俩来提前发现问题，阻断它们溜到线上呢。例如：

1. 同名 Category 办法抵触问题, 导致手淘很多性能异样；
2. @{} 初始化没判空问题；
3. oc block 持有 c++ this 指针导致 User After Free 问题；
4. objc_msgSend 发送 alloc 导致内存泄露问题；
5. 一些零碎 api 不再平安，比方 vm_remap；
6. 组件导出；
7. 线程透露；
8. ……

这些问题上线后可能就引起很难定位的问题，然而在代码阶段，通过动态剖析等伎俩就能够阻断他们的产生。因而 客户端品质卡口平台 应运而生，将手淘客户端已有问题扫描工具和规定整合，联合 DevSecOps 卡口设计的凋谢卡口接入平台，造成残缺的客户端线下问题发现、治理推动和集成卡口的能力，缩小线上问题。

技术计划上，在 Android Lint+Spotbugs+Clang Static Analyzer（Android），OCLint（iOS）+Clang Static Analyzer 根底上联合淘系具体平台和具体问题进行改良，以满足淘系的技术需要（如扫描线程原生接口应用，辅助淘系整体线程架构迁徙）。

包大小

包大小是客户端的十分重要的性能指标。从用户视角看，同样的性能和服务，用户偏向于抉择安装包比拟小的 App，能够让用户用更少的流量下载和更新，肯定水平进步用户的下载率和更新降级率，对于推广和新增都会有较为重要的影响；从技术视角看，安装包中的每个文件都在瘦身的范畴，对不同的文件类型，须要有针对性的瘦身计划，所以瘦身是一个大工程，蕴含了很多方面的技术。

Android 采纳了图片压缩（TinyPng，Webp），反复资源合并、shrinkResource 严格模式、分包、Proguard、ARSC 瘦身、下无用代码（代码插桩剖析）、无用业务下线、远端 so、检测 so 调试信息。

iOS 采纳了图片压缩（TinyPng，Webp）、编译优化（不导出符号、oz、lto）、selectorRef 无用资源下线，剔除反复代码、业务下线、共享动静库技术（<iOS9）、Ld 链接器压缩。

产物校验

产物校验产生在 APP 公布前的最初一个环节，次要来剖析本次公布与上一次公布外围变更存在哪些具体的差别，来确保本次公布的正确性。这一环节次要进行了 外围代码变更剖析 （启动、CrashSDK、监控 SDK），须要关注外围代码变更带来的可能的危险； 组件导出剖析 ，避免不必要的组件导出，受到内部攻打； 签名校验，避免签名出错导致 APP 无奈失常上架；等等。

公布期

监控告警

淘系高度重视手机用户的稳定性和性能，通过高可用的度量指标的建设，稳定性和性能的治理，自动化和数据平台的建设，开发了一套系统化的解决方案及平台 EMAS-MOTU, 全方位的晋升手机淘宝稳定性和性能。

变更管控

淘系是一个高频流动经营 APP 集，咱们发现有一些故障是由变更导致的（含流动上线，配置上线等），具备强相关性。因而淘系积淀了变更管控平台，变更管控平台次要作用是监控剖析平台发现的异样数据（Crash、ANR、卡断、透露等）与变更的相关性。

变更管控平台的 外围思路 是为每一次变更产生一个惟一的变更 ID，并在本次变更下发的过程中，将变更 ID 退出到监控信息的变更 ID 集里，当监控信息上报时会带上所有的变更 ID，服务能够对变更 ID 进行聚类分析，通过相关性确认雷同聚类问题是由哪些变更 ID 产生的，并对具体的变更留观或回滚，避免危险降级。

通过准确的变更相干灰度染色数据，管控相干灰度和全量公布，及时卡住异样公布，防止公布引起故障，同时也是进步公布效率的外围伎俩。

应急态

定位

追踪、度量、日志

随着客户端性能一直细化与欠缺，模块化、跨团队的协同开发方式曾经成为了客户端开发规范的开发方式，模块化、跨团队的协同开发方式的诞生极大晋升了客户端交付与部署的效率，但同时能够看到这种模块化、跨团队的架构背地，原先运维与诊断的需要也变得越来越简单。为了适应客户端日益增长的性能需要，需实现面向用户视角的标准化的 DevSecOps 诊断与剖析零碎，包含追踪（Tracing），度量（Metrics），日志（Logging）。

• Tracing：用于记录客户端行为范畴内的信息，它在单次申请的范畴内，解决信息。任何的数据、元数据信息都被绑定到零碎中的单个事务上。例如，用户进入页面，到数据渲染的过程。它是咱们排查客户端问题的利器；
• Metrics：用于记录可聚合的数据。他们具备原子性，每个都是一个逻辑计量单元，或者一个时间段内的柱状图。例如：队列的以后深度能够被定义为一个计量单元，在写入或读取时被更新统计；输出 HTTP 申请的数量能够被定义为一个计数器，用于简略累加；申请的执行工夫能够被定义为一个柱状图，在指定工夫片上更新和统计汇总。例如，从客户端发动的网络申请数，与正确收到网络数据的承受。它是咱们掂量业务宏观品质的利器；
• Logging：用于记录离散的事件。例如，应用程序的调试信息或错误信息。它是咱们诊断问题的根据。

基于追踪（Tracing），度量（Metrics），日志（Logging）的设计准则，淘系借鉴了 OpenTracing 实现了全日志平台 TLog。通过 漏斗模型、比照模型 通过数据横向比照能够疾速发现本身的性能瓶颈，放大范畴，晋升排查效率。

全景定位

淘系是一个高频流动经营 APP 集，咱们发现一些故障是由变更导致的（含流动上线，配置上线等），具备强相关性。因而淘系积淀了全景定位平台，全景定位平台次要作用是监控分析线上的变更。全景定位平台的 外围思路 是当线上危险产生时，全景定位平台会被动去收集线上变更，并按工夫维度出现进去，开发可基于全景定位平台疾速查看线上变更，定位和排查线上危险与变更的相关性，对潜在危险的变更留观或回滚，直至危险打消。

全景定位与变更管控有肯定的相似性，都是对线上变更的监控与剖析，区别在于全景定位次要在危险产生后对变更进行剖析（业务在变动，无奈保障所有的变更都会接入变更管控），变更管控则次要危险产生前打标，危险产生后对变更进行剖析，因而 全景定位是变更管控的一种补充与保障。

复原

“对代码性能不合乎我的项目预期或代码不够强壮导致 App 运行时解体或异样的线上问题进行复原”。复原是淘系应答线上突发问题的重要伎俩，淘系目前对线上不同的场景采纳了不同的复原策略，目前次要复原策略有降级、预案、平安模式。

降级

在淘系简单生态的环境下，大促期间还是会呈现因为各种重资源的业务叠加，导致卡顿，体验显著降落，内存水位暴涨，解体率也会随之飙升。因而从 2018 年开始，尝试开始对重资源、高风险业务，针对不同设施的性能状况进行多维度降级。目标是对用户体验进行分级，实现 “高端设施最炫体验，低端设施晦涩优先，紧急问题疾速降级”（随着工夫的推移，老的设施的软硬件条件，曾经无奈满足所有新技术、新业务的落地，须要有肯定的取舍，从而给每一个设施最佳的用户体验）。

针对不同设施的软硬件不同个性，基于 Listwise-SmartScorer 模型，淘系对客户端设置了高、中、底三个维度，0-100（0 示意设施性能优于市场上支流的 0% 的设施，100 示意设施性能优于市场上支流的 100% 的设施）的动静的设施评分算法。

设施评分是个什么？ 从机器学习的角度来看：它可能是一个分类问题，即设施分为高 / 中 / 低三类，咱们须要辨别这几个类；它可能是一个回归问题，即设施存在一个相对的分，咱们须要去拟合这个分。无论分类还是回归问题，都把设施评分定义为一个相对的值，而在理论体验中，咱们往往说“iPhone X”比“iPhone 8”快，而不是说“iPhone X”90 分，“iPhone 8”70 分，即设施评分是绝对的，同时因为设施的损耗，它的评分也是动静的，基于此，咱们把设施评分定义为一个排序问题。

在设施评分的根底上，实现对立降级平台，业务能够通过“高、中、底”或“0-100”选取相应的设施投放本身业务。

预案

什么是预案？依据评估剖析或教训，对潜在的或可能产生的突发事件的类别和影响水平而当时制订的应急处理计划。预案能够升高可预估或不可预估的危险，缩小损失，而当下面临大多数的危险，都来自于各类变更，还有阿里最重要的大促场景下，大流量所带来的零碎、业务压力。预案有分提前预案和应急预案。

提前预案：也称定时预案，提前预估大促期间的零碎情况与业务情况，为了防止大促的业务峰值影响而进行的缓存预热、机器重启、无限降级、磁盘清理或者业务下线等等，个别对业务无影响或影响可控。

应急预案： 针对可能存在的应急状况，如超出预期的异样流量、零碎依赖超时及不可用、本零碎的非预期不可用等采取的应急伎俩，个别对业务有损，同时可能会带来客诉，资损等，须要对应的技术、业务等兜底，执行须要谨慎。在新增变更中，在 Code Review 环节，对代码有 “可灰度、可监控、可回滚”（稳定性三板斧）要求，即确保代码有应急预案，在线上代码呈现危险时，疾速回滚。

预案和降级的 区别 在于，预案对全副设施采取雷同的策略，而降级是对不同的设施采纳不同的策略。

平安模式

复原场景，（启动阶段）未失常应用网络的解体问题。网络未初始化导致配置无奈下载发挥作用，于是淘系开发了一个平安模式（在间断触发雷同 Crash 后强制进入“平安模式”–Android 轻量级子过程，iOS 进入平安模式代码，用来在对程序复原初始状态（革除历史产生的长久化信息），如有必要会触发配置的下载），为主过程失常启动做必要的保障。如：启动时候因为长久化数据出错，导致 APP 启动间断闪退，这时平安模式能够施展巨大作用，补救配置下发执行前的代码盲区，防止用户只能通过卸载重装 APP 能力解决问题。

总结

客户端平安生产是在淘系较为欠缺的底层基础设施上建设起来的规范化、自动化、数据化的平台。文中波及到的技术点是借鉴了阿里内外泛滥开发、产品、运维等从业人员对历史问题的总结与实现，这里感激参加平安生产小伙伴的致力与付出，同时也感激阿里以外的开发、产品、运维对丰盛客户端技术、改良用户体验的致力与付出。文中更多的是对 APP 不同阶段的问题的思考与解问题的思路，心愿对大家有帮忙。

参考

[1] 挪动研发平台 EMAS:https://www.aliyun.com/produc…

[2] OpenTracing:https://github.com/opentracing

[3] 平安模式：天猫 App 启动爱护实际：https://juejin.cn/post/684490…

关注【阿里巴巴挪动技术】官网公众号，每周 3 篇挪动技术实际 & 干货给你思考！