【移动应用开发技术】技术解读：美团外卖Android Crash治理之路

【移动应用开发技术】技术解读：美团外卖AndroidCrash治理之路!

【本文转载自美团技术团队微信公众号，作者：维康少杰晓飞，转载和授权请联系原作者】

Crash率是衡量一个App好坏的重要指标之一。如果你忽略了它的存在，它就会得寸进尺，愈演愈烈，最后造成大量用户的流失，进而给公司带来无法估量的损失。本文讲述美团外卖Android客户端团队在将App的Crash率从千分之三做到万分之二过程中所做的大量实践工作，抛砖引玉，希望能够为其他团队提供一些经验和启发。

面临的挑战和成果

面对用户使用频率高，外卖业务增长快，Android碎片化严重这些问题，美团外卖AndroidApp如何持续的降低Crash率，是一项极具挑战的事情。通过团队的全力全策，美团外卖AndroidApp的平均Crash率从千分之三降到了万分之二，最优值万一左右(Crash率统计方式：Crash次数/DAU)。

美团外卖自2013年创建以来，业务就以指数级的速度发展。美团外卖承载的业务，从单一的餐饮业务，发展到餐饮、超市、生鲜、果蔬、药品、鲜花、蛋糕、跑腿等十多个大品类业务。目前美团外卖日完成订单量已突破2000万，成为美团点评最重要的业务之一。美团外卖客户端所承载的业务模块越来越多，产品复杂度越来越高，团队开发人员日益增加，这些都给App降低Crash率带来了巨大的挑战。

Crash的治理实践

对于Crash的治理，我们尽量遵守以下三点原则：

由点到面。一个Crash发生了，我们不能只针对这个Crash的去解决，而要去考虑这一类Crash怎么去解决和预防。只有这样才能使得这一类Crash真正被解决。

异常不能随便吃掉。随意的使用try-catch，只会增加业务的分支和隐蔽真正的问题，要了解Crash的本质原因，根据本质原因去解决。catch的分支，更要根据业务场景去兜底，保证后续的流程正常。

预防胜于治理。当Crash发生的时候，损失已经造成了，我们再怎么治理也只是减少损失。尽可能的提前预防Crash的发生，可以将Crash消灭在萌芽阶段。

常规的Crash治理

常规Crash发生的原因主要是由于开发人员编写代码不小心导致的。解决这类Crash需要由点到面，根据Crash引发的原因和业务本身，统一集中解决。常见的Crash类型包括：空节点、角标越界、类型转换异常、实体对象没有序列化、数字转换异常、Activity或Service找不到等。这类Crash是App中最为常见的Crash，也是最容易反复出现的。在获取Crash堆栈信息后，解决这类Crash一般比较简单，更多考虑的应该是如何避免。下面介绍两个我们治理的量比较大的Crash。

NullPointerException

NullPointerException是我们遇到最频繁的，造成这种Crash一般有两种情况：

对象本身没有进行初始化就进行操作。

对象已经初始化过，但是被回收或者手动置为null，然后对其进行操作。

针对第一种情况导致的原因有很多，可能是开发人员的失误、API返回数据解析异常、进程被杀死后静态变量没初始化导致，我们可以做的有：

对可能为空的对象做判空处理。

养成使用@NonNull和@Nullable注解的习惯。

尽量不使用静态变量，万不得已使用SharedPreferences来存储。

考虑使用Kotlin语言。

针对第二种情况大部分是由于Activity/Fragment销毁或被移除后，在Message、Runnable、网络等回调中执行了一些代码导致的，我们可以做的有：

Message、Runnable回调时，判断Activity/Fragment是否销毁或被移除;加try-catch保护;Activity/Fragment销毁时移除所有已发送的Runnable。

封装LifecycleMessage/Runnable基础组件，并自定义Lint检查，提示使用封装好的基础组件。

在BaseActivity、BaseFragment的onDestory()里把当前Activity所发的所有请求取消掉。

IndexOutOfBoundsException

这类Crash常见于对ListView的操作和多线程下对容器的操作。

针对ListView中造成的IndexOutOfBoundsException，经常是因为外部也持有了Adapter里数据的引用(如在Adapter的构造函数里直接赋值)，这时如果外部引用对数据更改了，但没有及时调用notifyDataSetChanged()，则有可能造成Crash，对此我们封装了一个BaseAdapter，数据统一由Adapter自己维护通知，同时也极大的避免了ThecontentoftheadapterhaschangedbutListViewdidnotreceiveanotification，这两类Crash目前得到了统一的解决。

另外，很多容器是线程不安全的，所以如果在多线程下对其操作就容易引发IndexOutOfBoundsException。常用的如JDK里的ArrayList和Android里的SparseArray、ArrayMap，同时也要注意有一些类的内部实现也是用的线程不安全的容器，如Bundle里用的就是ArrayMap。

系统级Crash治理

众所周知，Android的机型众多，碎片化严重，各个硬件厂商可能会定制自己的ROM，更改系统方法，导致特定机型的崩溃。发现这类Crash，主要靠云测平台配合自动化测试，以及线上监控，这种情况下的Crash堆栈信息很难直接定位问题。下面是常见的解决思路：

尝试找到造成Crash的可疑代码，看是否有特异的API或者调用方式不当导致的，尝试修改代码逻辑来进行规避。

通过Hook来解决，Hook分为JavaHook和NativeHook。JavaHook主要靠反射或者动态代理来更改相应API的行为，需要尝试找到可以Hook的点，一般Hook的点多为静态变量，同时需要注意Android不同版本的API，类名、方法名和成员变量名都可能不一样，所以要做好兼容工作;NativeHook原理上是用更改后方法把旧方法在内存地址上进行替换，需要考虑到Dalvik和ART的差异;相对来说NativeHook的兼容性更差一点，所以用NativeHook的时候需要配合降级策略。

如果通过前两种方式都无法解决的话，我们只能尝试反编译ROM，寻找解决的办法。

我们举一个定制系统ROM导致Crash的例子，根据Crash平台统计数据发现该Crash只发生在vivoV3Max这类机型上，Crash堆栈如下：

我们发现原生系统上对应系统版本的AbsListView里并没有UpdateBottomFlagTask类，因此可以断定是vivo该版本定制的ROM修改了系统的实现。我们在定位这个Crash的可疑点无果后决定通过Hook的方式解决，通过源码发现AsyncTask$SerialExecutor是静态变量，是一个很好的Hook的点，通过反射添加try-catch解决。因为修改的是final对象所以需要先反射修改accessFlags，需要注意ART和Dalvik下对应的Class不同，代码如下：

美团外卖App用上述方法解决了对应的Crash，但是美团App里的外卖频道因为平台的限制无法通过这种方式，于是我们尝试反编译ROM。

AndroidROM编译时会将framework、app、bin等目录打入system.img中，system.img是Android系统中用来存放系统文件的镜像(image)，文件格式一般为yaffs2或ext。但Android5.0开始支持dm-verity后，system.img不再提供，而是提供了三个文件system.new.dat，system.patch.dat，system.transfer.list，因此我们首先需要通过上述的三个文件得到system.img。但我们将vivoROM解压后发现厂商将system.new.dat进行了分片，如下图所示：

上面的配置就可以将App代码(包括第三方库)里所有的Intent.getXXXExtra调用替换成IntentUtil类中的安全版实现。当然，并不是所有的异常都只需要catch住就万事大吉，如果真的有逻辑错误肯定需要在开发和测试阶段及时暴露出来，所以在IntentUtil中会对App的运行环境做判断，Debug下会将异常直接抛出，开发同学可以根据Crash堆栈分析问题，Release环境下则在捕获到异常时返回对应的默认值然后将异常上报到服务器。

依赖库的问题

AndroidApp经常会依赖很多AAR，每个AAR可能有多个版本，打包时Gradle会根据规则确定使用的最终版本号(默认选择最高版本或者强制指定的版本)，而其他版本的AAR将被丢弃。如果互相依赖的AAR中有不兼容的版本，存在的问题在打包时是不能发现的，只有在相关代码执行时才会出现，会造成NoClassDefFoundError、NoSuchFieldError、NoSuchMethodError等异常。

如图所示，order和store两个业务库都依赖了platform.aar，一个是1.0版本，一个是2.0版本，默认最终打进APK的只有platform2.0版本，这时如果order库里用到的platform库里的某个类或者方法在2.0版本中被删除了，运行时就可能发生异常，虽然SDK在升级时会尽量做到向下兼容，但很多时候尤其是第三方SDK是没法得到保证的，在美团外卖AndroidAppv6.0版本时因为这个原因导致热修复功能丧失，因此为了提前发现问题，我们接入了依赖检查插件Defensor。

网络层统一处理API脏数据

客户端的很大一部分的Crash是因为API返回的脏数据。比如当API返回空值、空数组或返回不是约定类型的数据，App收到这些数据，就极有可能发生空指针、数组越界和类型转换错误等Crash。而且这样的脏数据，特别容易引起线上大面积的崩溃。

最早我们的工程的网络层用法是：页面监听网络成功和失败的回调，网络成功后，将JSON数据传递给页面，页面解析Model，初始化View，如图所示。这样的问题就是，网络虽然请求成功了，但是JSON解析Model这个过程可能存在问题，例如没有返回数据或者返回了类型不对的数据，而这个脏数据导致问题会出现在UI层，直接反应给用户。

从图上可以看出，重构后的网络层负责请求网络和数据解析，如果存在脏数据的话，在网络层就会发现问题，不会影响到UI层，返回给UI层的都是校验成功的数据。这样改造后，我们发现这类的Crash率有了极大的改善。

大图监控

上面讲到大对象是导致OOM的主要原因之一，而Bitmap是App里最常见的大对象类型，因此对占用内存过大的Bitmap对象的监控就很有必要了。

我们用AOP方式Hook了三种常见图片库的加载图片回调方法，同时监控图片库加载图片时的两个维度：

加载图片使用的URL。外卖App中除静态资源外，所有图片都要求发布到专用的图片CDN服务器上，加载图片时使用正则表达式匹配URL，除了限定CDN域名之外还要求所有图片加载时都要添加对应的动态缩放参数。

最终加载出的图片结果(也就是Bitmap对象)。我们知道Bitmap对象所占内存和其分辨率大小成正比，而一般情况下在ImageView上设置超过自身尺寸的图片是没有意义的，所以我们要求显示在ImageView中的Bitmap分辨率不允许超过View自身的尺寸(为了降低误报率也可以设定一个报警阈值)。

开发过程中，在App里检测到不合规的图片时会立即高亮出错的ImageView所在的位置并弹出对话框提示ImageView所在的Activity、XPath和加载图片使用的URL等信息，如下图，辅助开发同学定位并解决问题。在Release环境下可以将报警信息上报到服务器，实时观察数据，有问题及时处理。

资源重复检查

在之前的文章《美团外卖Android平台化架构演进实践》中讲述了我们的平台化演进过程，在这个过程中大家很大的一部分工作是下沉，但是下沉不完全就会导致一些类和资源的重复，类因为有包名的限制不会出现问题。但是一些资源文件如layout、drawable等如果同名则下层会被上层覆盖，这时layout里view的id发生了变化就可能导致空指针的问题。

为了避免这种问题，我们写了一个Gradle插件通过hookMergeResource这个Task，拿到所有library和主库的资源文件，如果检查到重复则会中断编译过程，输出重复的资源名及对应的libraryname，同时避免有些资源因为样式等原因确实需要覆盖，因此我们设置了白名单。同时在这个过程中我们也拿到了所有的的图片资源，可以顺手做图片大小的本地监控，如下图所示：

止损

尽管我们在前面做了那么多，但是Crash还是无法避免的，例如，在灰度阶段因为量级不够，有些Crash没有被暴露出来;又或者某些功能客户端比后台更早上线，而这些功能在灰度阶段没有被覆盖到;这些情况下，如果出现问题就需要考虑如何止损了。

问题发生时首先需要评估重要性，如果问题不是很严重而且修复成本较高可以考虑在下个版本再修复，相反如果问题比较严重，对用户体验或下单有影响时就必须要修复。修复时首先考虑业务降级，主要看该部分异常的业务是否有兜底或者A/B策略，这样是最稳妥也是最有效的方式。

如果业务不能降级就需要考虑热修复了，目前美团外卖AndroidApp接入的热修复框架是自研的Robust，可以修复90%以上的场景，热修成功率也达到了99%以上。如果问题发生在热修复无法覆盖的场景，就只能强制用户升级。强制升级因为覆盖周期长，同时影响用户的体验，只在万不得已的情况下才会使用。

展望

Crash的自我修复

我们在做新技术选型时除了要考虑是否能满足业务需求、是否比现有技术更优秀和团队学习成本等因素之外，兼容性和稳定性也非常重要。但面对国内非富多彩的Android系统环境，在体量百万级以上的的App中几乎不可能实现毫无瑕疵的技术方案和组件，所以一般情况下如果某个技术实现方案可以达到0.01‰以下的崩溃率，而其他方案也没有更好的表现，我们就认为它是可以接受的。但是哪怕仅仅十万分之一的崩溃率，也代表还有用户受到影响，而我们认为Crash对用户来说是最糟糕的体验，尤其是涉及到交易的场景，所以我们必须本着每一单都很重要的原则，尽最大努力保证用户顺利执行流程。

实际情况中有一些技术方案在兼容性和稳定性上做了一定妥协的场景，往往是因为考虑到性能或扩展性等方面的优势。这种情况下我们其实可以再多做一些，进一步提高App的可用性。就像很多操作系统都有“兼容模式”或者“安全模式”，很多自动化机械机器都配套有手动操作模式一样，App里也可以实现备用的降级方案，然后设置特定条件的触发策略，从而达到自动修复Crash的目的。

举例来讲，Android3.0中引入了硬件加速机制，虽然可以提高绘制帧率并且降低CPU占用率，但是在某些机型上还是会有绘制错乱甚至Crash的情况，这时我们就可以在App中记录硬件加速相关的Crash问题或者使用检测代码主动检测硬件加速功能是否正常工作，然后主动选择是否开启硬件加速，这样既可以让绝大部分用户享受硬件加速带来的优势，也可以保障硬件加速功能不完善的机型不受影响。还有一些类似的可以做自动降级的场景，比如：

部分使用JNI实现的模块，在SO加载失败或者运行时发生异常则可以降级为Java版实现。

RenderScript实现的图片模糊效果，也可以在失败后降级为普通的Java版高斯模糊算法。

在使用Retrofit网络库时发现OkHttp3或者HttpURLConnection网络通道失败率高，可以主动切换到另一种通道。

这类问题都需要根据具体情况具体分析，如果可以找到准确的判定条件和稳定的修复方案，就可以让App稳定性再上一个台阶。

特定Crash类型日志自动回捞

外卖业务发展迅速，即使我们在开发时使用各种工具、措施来避免Crash的发生，但Crash还是不可避免。线上某些怪异的Crash发生后，我们除了分析Crash堆栈信息之外，还可以使用离线日志回捞、下发动态日志等工具来还原Crash发生时的场景，帮助开发同学定位问题，但是这两种方式都有它们各自的问题。

离线日志顾名思义，它的内容都是预先记录好的，有时候可能会漏掉一些关键信息，因为在代码中加日志一般只是在业务关键点，在大量的普通方法中不可能都加上日志。动