代码质量监控和崩溃问题一体化管理的探索和实践
Posted Qunar技术沙龙
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了代码质量监控和崩溃问题一体化管理的探索和实践相关的知识，希望对你有一定的参考价值。
代码质量监控对于任何一个中大型项目来说都是不可或缺的一部分，我们没有办法保证在多人参与的项目里每个人写的代码都是健壮可靠的，自测和 QA 阶段可以在一定程度上帮助我们发现一些明显的问题，但仍然避免不了一些严重的问题遗漏到线上出现大量崩溃这种情况，这种问题一直困扰着我们。当我们的项目上线之后，如何合理的分配管理并且保证每一个线上崩溃问题都能够得到很好的关注和解决，也是一个比较头疼的问题，单纯的靠人工来安排解决问题的方式远远不能满足我们对一个优质工程的需求，所以我们机票业务线一直在思考如何让这些问题能够得到更好的解决，代码质量监控和崩溃问题一体化管理方案（下文简称"一体化方案"）就是我们解决这类问题的一个突破和尝试，今天在这里和大家分享一下我们是如何进行一体化方案的探索和实践的。
为了能够自动地监控和管理开发阶段和项目上线后出现的一些问题，我们总结了一套一体化的管理方案：
整个方案的核心是围绕我们的 Bumblebee 监控平台来实施的。
在开发阶段，我们会通过质量检查机制来监控项目质量，发现项目中存在的一些待解决的质量问题分配到每一个责任人的名下，一旦项目上线后，监控平台还会继续跟踪线上项目，通过线上问题处理机制过滤出待解决的线上问题，并同是追踪到具体的责任人名下，督促相关人员尽快解决对应的问题。同时，我们会在解决问题的过程中分析这些问题发生的原因和规律，并从中总结出检查规则强化到监控平台的检查机制中，从而继续进行这样的良性循环不断提高整个工程项目的质量。这就是一体化管理方案的核心内容。整个一体化方案中的核心环节就是开发阶段质量检查机制和项目上线后问题跟踪过滤机制，接下来详细地介绍这些环节的细节和实现。
在开发阶段的质量监控跟踪主要分为四个模块：
● 监控启动入口
● 生成监控任务
● 监控任务执行
● 代码质量检查
目前我们的监控启动入口主要有三个。
监控平台会对代码仓库进行监控，一旦代码仓库的内容发生了变化会主动执行一次监控检查任务。
开发同学可以通过监控平台的节目上配置相关的参数来主动执行一次监控检查任务。
监控平台还会定时进行监控任务对月版代码进行扫描。
下面是监控启动入口的详细流程：
当我们的开发往代码仓库提交代码的时候，我们会通过代码仓库上注册的 Web Hooks 来主动调起 Jenkins 来执行一次监控任务，我们只需要在 Web Hooks 上配置好对应的链接。这是第一种启动方式。 当我们的开发主动在监控平台界面上操作时也会调起后台的 Jenkins 来执行对应的检查操作，这里我们是通过 Jenkins 的 Api 来主动实施监控的，有兴趣的同学可以自行了解这块的内容， 第三种启动方式就是通过一个定时任务来调起监控，定时任务也是可以通过 Jenkins 的日程表来控制的，只要配置好这些内容，就可以很方便的来操作我们的监控任务了。
当我们通过监控入启动监控之后，会自动生成一个监控任务，整个监控任务的执行包括注入，启动执行器和监听执行任务，监听执行任务会添加一个全局的监控，一旦这个过程中发生了任何阻断都会被记录下来发送给对应的责任人。整个执行监控任务的核心部分就是插件注入了，我们会通过脚本，将集成了一套完整的代码质量检查，分析，报告，责任分配等的 gralde 插件注入到整个项目工程中，插件注入和执行的流程如下：
监控平台通过加载注入脚本，修改整个项目工程的构建配置，把插件注入到项目中，并且再次通过脚本执行插件中的监控任务，并在检查任务中加载检查规则和配置每个任务的依赖关系，最后再进行真正的代码质量检查，最后将检查的内容通过报表和 Issue 的方式通知到对应责任人，整个检查环节就结束了。那么整个检查环节的重点就是检查规则的使用和内容了，让我们来看看检查规则模块。
在介绍检查规则之前，需要简单地介绍下检查规则是如何使用的，这里就必须提到抽象语法树这个概念。
我们通过抽象语法树把整个项目工程构建成一个树，通过将检查规则遍历到树的每一个节点上来实现潜在问题的检查，最终达到检查的目的。
下面是我们的检查规则：
检查规则主要分为两部分，分别是自定义规则和集成的静态代码扫描工具的规则。 自定义规则的目的主要解决三个问题：
● 潜在引发崩溃的问题
● 可优化的性能问题
● 开发规范问题
潜在的可能引起崩溃的问题包括一些针对性解决线上问题固化出来的检查规则，总结和发现的一些严重代码问题得到的规则和预防其他可能出现的问题的规则，这些规则帮助我们针对性的解决一些线上发生过的问题避免再次遗漏，预防一些容易被忽略的低级问题一起其他潜在引发崩溃的原因等，这些规则都是可以自行定义的 。
当然我们的 自定义规则可以通过对应的工程打成相应的依赖包集成到依赖仓库，也可以把一些通用的重要的规则直接集成到 gradle 插件中，通过各个业务线自行定义配置和开发加载规则都是没有问题的。最终我们通过自定义的检查规则消灭了包括序列化问题，空指针，无法找到资源文件等潜在崩溃问题和可优化的点和规范等。 另一个部分就是集成现有一些静态代码扫描工具里的规则，包括 lint，findbugs，pmd，fireline 等里的规则，都是可以通过各个工程进行自行配置的，通过这些规则提前发现一些包括空指针，无用资源，内存泄露等等问题。通过这些检查规则，最终达到针对线上崩溃做具体的检查方案，进一步减少线上崩溃，保证开发规范，优化 App 性能的目的。开发阶段的监控检查的核心内容基本都介绍完了，下面再为大家详细介绍下项目上线后的问题监控跟踪环节。
当我们的项目上线之后，监控平台会继续监控项目在线上的一个状态。
监控平台通过定时任务来获取线上的崩溃信息，通过对这些内容进行分类，过滤去重，反混淆等来得到我们等目标问题，同时生成 Issues 来跟进问题状态，同时通过定位严重程度来分配责任人，然后再把所有的问题汇总生成监控报表发送给所有参与项目的开发，最终再通过监控平台来跟进线上问题。
在整个线上问题跟踪的环节里最核心的内容就是对线上问题进行过滤，接下来为大家详细地介绍线上问题过滤的具体内容：
监控平台根据问题的类型主要有两种过滤的方式，第一种是针对 ANR 问题进行过滤，第二种是针对 OOM，Exceptions 这些问题进行过滤。ANR 因为稍微有些不同，很多 ANR 可能都是由于同一个问题造成的，比如在主线程上进行 IO 操作等，所以我们会先根据页面对 ANR 进行聚合，之后再在每个页面上再次根据原因进行聚合，最后过滤出我们的目标 ANR。 另一类过滤则是针对 OOM 和 Exceptions 进行过滤，对于这类问题，我们会先根据配置的一些过滤名单和引发问题的源来对这类问题做一个简单的过滤，得到真正属于我们业务线的崩溃，然后再对这写问题进行聚合，把属于同一个崩溃源的崩溃整理成一个，之后对这些问题进行反混淆和自动分配，最终再追责到具体的责任人名下，督促其尽快解决问题，同时还会记录这些问题的解决状态，最终达到自动化管理的目的。这就是我们线上问题跟踪过滤的主要内容。
为了让大家能够更切实地感受一体化方案的具体内容，我在这里为大家简单地展示一个案例。我们曾需要用 Fresco 做预加载处理，这里就要用到 Image Pipeline，但当时用同学没有仔细看文档：
在从 Bitmap 缓存中获取资源的时候保存了资源的引用，结果到线上直接就引起大量的崩溃，我们根据这个问题产生的原因总结了一条规则，当从 Image Pipeline 的 Bitmap 缓存中取值的时候检测取到的值的引用范围，并查找出违规使用的代码，并且通过将这条新的规则加入到监控平台的检查规则中避免这类问题再次发生。这样细节性的问题其实很多的存在于我们的代码中，我们不可能每一个这样的细节都通过人工 Diff 或者是 QA 测试给规避，所以针对这类的问题我们都可以通过事先制作规则来进行规避，并且这些规则都是可以在各个业务线被调用的，这样可以更大幅度地帮助避免同样的问题再次发生。当然，这只是一体化方案一个最普通简单的实践，随着监控平台的不断强化，功能会变得越来越强大。
一体化方案的内容和运用都是围绕整个监控平台来完成的，上面的例子为大家简单介绍了方案在业务线的一个使用案例，总结下来大致如下：
监控平台在开发阶段通过检查规则和规范找到项目中潜在的问题，不规范的代码以及性能待调优的点，通过对这些问题进行解决达到优化代码质量的目的。同时，当项目上线后，再次通过线上问题跟踪机制，对收集到的崩溃问题进行过滤和分配，同时对问题的状态进行跟踪记录，并通过对这些问题进行分析，生成新的规则和解决方案，再次强化到质量监控平台，通过这样一个个良性的循环，让我们的监控平台在一体化管理方案下变得越来越强大，同时让项目的质量也变得越来越健壮，最终达到我们最初的目的。
一场 React Native 技术大会即将举办，欢迎参加！
《YMFE Conf 2017: React Native 应用与实践技术大会》 将会于十月中旬在北京举办，届时将有各知名互联网公司移动前端技术达人们来分享交流 React Native 在各自公司的应用与实践。大会门票目前正在火热开售中，扫描下方二维码浏览YMFE CONF官网并购票。
扫码浏览 YMFE CONF 官网
扫码购买 YMFE CONF 门票
以上是关于代码质量监控和崩溃问题一体化管理的探索和实践的主要内容，如果未能解决你的问题，请参考以下文章