LalaAndroidの安定性管理

著者について
HuolalaのシニアクライアントエンジニアであるKelvinは、現在、Android側でのHuolalaAppのパフォーマンスの最適化とAPM関連の作業を担当しています。

アプリのクラッシュはユーザーにとって最悪のエクスペリエンスであり、プロセスの中断、アプリのレピュテーションの低下、アプリのアンインストール、ユーザーのチャーン、注文のチャーンなどにつながります。関連データによると、Androidアプリのクラッシュ率が0.4％を超えると、アクティブユーザーは大幅に減少します。統計によると、2021年初頭のクラッシュ率は5％です。ユーザーのフィードバックや苦情を見つけて解決するために多くの研究開発時間が費やされています。クラッシュ管理は緊急です。昨年の多くの実践的なガバナンスにより、アプリのクラッシュ率は0.02％に減少し、安定しました。他のチームに経験とインスピレーションを提供したいと思い、ここでいくつかの結論と共有を行います。

業界標準

「2020モバイルアプリケーションパフォーマンス管理ホワイトペーパー|クラウドに耳を傾ける基調講演」によると

パフォーマンス	優れた価値	パス値	範囲	業界の基準値
クラッシュ率（％）	<= 0.1	0.6 0.6	> = 1	0.5

クラッシュ率のガバナンス目標は0.03％に設定されています。

ガバナンス前の全体的な状態

アプリのクラッシュ率は5％以上と高くなっています。製品の継続的な反復により、複雑さが増し続け、クラッシュ率の削減に大きな課題が生じます。対処しながら、レガシーCrahをクリーンアップする必要があります。新しいクラッシュ。クラッシュの部分は2つの部分に分かれています。クラッシュのネイティブ部分は72％にも達します。クラッシュのこの部分は、主にFlutter、サードパーティのマップ、サードパーティのSDKから発生しますが、解決が困難です。Java部分での多くのクラッシュは時間内に解決されておらず、多くのレガシーの歴史的債務があり、それらのほとんどは一般的な解決策を持っています。

クラッシュガバナンス手法

一般的なクラッシュに対処する方法

クラッシュ統計プラットフォームのスタックによると、ユーザーログ、操作パスの位置付けと解決
共通点、モデル、ブランド、システムバージョン、ページ、ユーザー操作などを見つけて、問題の解決に役立てます
シーンを再現するには、通常、再現できるかどうかを簡単に解決でき、オフラインまたは実際のクラウドマシンで再現できます。

その他の処理方法

クラッシュ率の高いモジュールのビジネスの並べ替え、調査、および再構築を実行します
サードパーティのSDKと通信して、問題をアップグレードおよび解決し、SDKの使用方法を変更します

クラッシュガバナンスの実践

由于内部的统计平台建设比较晚，我们只能获取到近期的Crash率变化，可以看到Crash率明显收敛。

代码重构

为应对需求的频繁变化、提高研发效率，货拉拉首页、确认下单页等使用Flutter和小程序实现，而这部分是用户使用率最高的页面，代码量庞大而且复杂。在线上环境中产生了大量的Crash，大部分的Crash为偶发，线下环境无法复现，从堆栈情况很难定位问题的根源，修改起来有可能涉及到多端，各端都需要进行回归校验。经过综合分析，我们决定梳理逻辑，让最重要的这部分代码回归原生，重构上线之后Crash率明显下降，由原来的5%下降到0.5%，稳定性大幅提高。

三方SDK和Native崩溃处理

这部分的Crash处理使我们从Crash率由千分位降低到了0.05%。在初期我们很容易解决了java部分的Crash，然而第三方sdk和Native的Crash居高不下，有很长一段时间我们通过提交工单，咨询对接方等形式并没有办法得到解决。对于有些crash，我们升级了sdk发现crash量反而增加，又需要降级回旧版本。对于有些crash，堆栈信息却跟这个sdk没有关系。针对这些部分的崩溃通常用以下两种方式解决：

查看Api的调用存在问题（调用时机，调用顺序，传入参数，调用的线程或者进程等）
沟通解决，（在没有一对一开发对接的情况下，尝试提工单咨询），将Crash的堆栈发送给第三方SDK进行处理

我们两组Crash量最高的为例：

2.1 第三方VMP线程监控内存情况并关闭App导致

Crash统计平台上有大量的Native崩溃SIGSEGV(SEGV_MAPERR)、SIGABRT和SIGSEGV(SEGV_ACCERR)等，堆栈通常为系统级别的so内部（libgui.so、libGLES_mali.so和libc.so等），从抓取的堆栈中我们无法得知问题根源。我们已知的信息是Vivo手机Android10，Android11崩溃率极高，为此我们病急乱投医式进行了几种尝试：

错误堆栈中有出现硬件加速相关的so，我们尝试关闭了整个的硬件加速功能
进行大量的内存泄露治理、线程治理
降低手机帧率
联系手机厂商

多次尝试无果之后，在一次的用户日志对比中发现部分bug存在相同的日志

咨询第三方SDK后得知VMP监控，对应用进程的/proc/pid/mem和/proc/self/task/pid/mem文件监控，如果文件被操作则会退出App，退出方式可能存在问题，导致地图sdk中捕获native崩溃时出现二次崩溃，在将这部分bug处理之后我们的崩溃率降低到0.1%左右，native部分的Crash堆栈没有这部分Crash参杂，堆栈信息更加明确，问题也容易定位一些。

2.2 地图使用

地图是货拉拉应用中必不可少的组件，在用户下单过程中都会用到，贯穿整个主流程。地图部分的crash绝大部分为native，并且有些是特定品牌机型独有的crash。我们将Crash反馈给SDK方，开发人员根据堆栈定位问题，经过多次分析导致Crash的原因一部分是sdk导致，另一部分是我们调用不合理的导致。SDK内部的原因通过升级解决，crash呈收敛趋势。调用不合理部分主要是因为销毁时机不正确导致，我们对各个地图使用场景进行排查修复，在几个版本修复之后总体Crash率降低到了0.05%。

OOM治理

OutOfMemoryError是指内存溢出，也是一类难以解决的Crash，通常上报的堆栈信息，用户日志等都没有太多的参考价值，往往内存已经在其他位置增加到内存溢出的临界点，而上报的位置很可能不存在内存问题，而引起内存溢出主要的原因有：内存泄漏，引用大对象，内存抖动，线程使用不合理等。

3.1 内存泄漏

主要是用LeakCanary进行检测，通常Activity的泄漏会显得比较严重，因为它承载了整个页面的控件、数据等，Activity无法回收也会导致这部分对象无法回收。

常见引起Activity泄漏的原因

Handler，Thread等匿名内部类隐式持有外部类导致
注册的监听器未及时反注册：EventBus，广播
单例对象持有Activity：货拉拉App中有一个页面管理会持有Activity对象，有一部分页面添加之后没有移除造成了大量内存泄漏的场景
网络请求，异步任务：由于早期网络部分封装的不好，网络请求没有与页面的生命周期绑定，在弱网或者用户关闭页面较快的情况下会出现内存泄漏。
Context使用Application就可以的时候使用了Activity：例如，Toast，第三方SDK

3.2 线程治理

当线程超过系统设置的上限，也会导致OOM的发生，报错：pthread_create (1040KB stack) failed: Out of memory。通常处理方式如下：

对App内部线程池进行统一，对于随意使用的异步任务统一改为使用线程池或者RxJava
检查App内Timer，HandlerThread类的合理使用
沟通内部其他团队的SDK中增加线程代理，统一使用App端的线程池，避免线程的随意使用
分析合理可以替换的线程或者线程池进行插桩替换处理

3.3 大对象处理

通常App中图片都是占用内存的大户，bitmap的管理是内存治理中非常重要的环节。对于这里的处理，我们首先是将图片加载统一使用Glide，再将App中的原生加载图片替换成Glide。

另外，通过MAT工具，筛选、排序大对象，对头部大对象进行优化：

原本在同一个SharePreference的数据拆分到多个，使用完毕进行回收。
某个类中持有一个非常大的数据，而并不是经常用到，可以放入数据库或者文件中。

3.4 内存抖动

其实针对这部分的优化，我们只是对检测到的、比较严重的、不合理的内存增长进行了优化。通过AndroidStudio的Profiler，我们发现内存出现锯齿状的增长，或者GC频率极高的情况，对着部分不合理的对象分配进行分析和解决。

这里举两个例子：

a.自定义View的onDraw方法中创建对象

b.设置监听布局变化，再改变控件的大小，位置等。在改变这个view显示状态时又会出发监听，这里就会不断的执行，造成了内存的疯狂增长，GC频率提高，在一些测试机上十几秒就回进行一次GC。

View.getViewTreeObserver().addOnGlobalLayoutListener(() -> {

    //改变view的大小，位置等

    int[] view1Location = new int[2];

    view1.getLocationOnScreen(view1Location);

    int[] view2Location = new int[2];

    view2.getLocationOnScreen(view2Location);

});
复制代码

解决的方式主要有两种：

1.对象复用：对于onDraw中的使用场景可以将对象作为一个成员变量，其他情况考虑是否可以建立对象池

2.增加条件：在达到某种条件下才允许创建对象的逻辑，比如第二个例子中，由于业务原因无法移除监听，我们增加了一些条件，只有少量情况才会执行创建的逻辑。

4.常规Crash

这部分问题通常根据堆栈和用户手机的相关情况很容易定位到问题，不过不能只是修改出问题的那行代码，更不可以随意的进行try catch，需要找到问题的本质，可能这个问题的还会导致其他的一系列问题。比方说：

点击事件的某一行出现了空指针，发现是数据为空导致，数据是从前一个页面的网络接口传递过来，而接口数据为空是因为传入的设备id为空。那么此时我们只在点击事件这里做判空肯定是不够的，需要将设备id为空的原因找到，否则这整个链路都会出现crash或者业务异常。

4.1 空指针NullPointerException

空指针虽然上报的量不大，但却是我们统计到出现次数最多的bug。通常是对象本身没做初始化或者对象被回收的情况下使用该对象导致：

代码逻辑分支引起，没走到初始化的位置，却走了相应的调用逻辑。
服务端接口返回数据异常，数据库查询数据异常
一些postDelay或者异步回调，回调时也能被回收，可能导致空指针
静态变量被回收

通常解决空指针不能直接在代码基础上增加判空处理，应当寻找真正导致对象为空的原因进行规避，常见的解决方式有：

做好判空或者使用kotlin语言
使用注解@NonNull和@Nullable
存在异步任务应当适时停止异步任务或者移除监听回调（例如，页面销毁停止网络请求，移除页面内的postDelay任务）
静态变量做好管理，可以本地持久化

4.2 索引越界IndexOutofBoundsException

常见原因：

字符串拼接，截取索引不正确，SpannableString 索引设置异常
ListView，RecyclerView或者ViewPager中数据变化没有通知Adapter数据发生变化
多线程情况下使用不安全的集合

解决方式：

字符串，SpannableString有关索引操作，应当先判断好字符串长度
多线程场景下应当用安全的形式访问集合或者使用线程安全的集合

4.3 系统原因产生的bug

对于这类bug，触发的原因很难查到，我们需要找到堆栈中的关键字、系统版本、机型进行分析，解决方案通常是规避调用或者hook的方式解决。例如下面的bug，关键字“autofill”，版本Android10，对应于Android10的自动填充功能。

错误名称和堆栈信息

android.os.RemoteException Remote stack trace: at com.android.internal.util.Preconditions.checkCollectionElementsNotNull

简要分析

上面的错误日志涉及到跨进程，分为三段来看会清晰一些。

App进程中ActivityThread的mH接收到Message进行处理handleRequestAssistContextExtras，再调用ActivityTaskManagerService的aidl方法reportAssistContextExtras

进入到ActivityTaskManagerService.reportAssistContextExtras新建FillRequest的时构造中调用Preconditions.checkCollectionElementsNotNull抛出异常，异常信息发送回我们App进程。

Preconditions类异常抛出的位置

调用验证

通过对源码查看，mH中handleRequestAssistContextExtras的调用只有一处，发出这个message的也只有一处。通过hook，确定用户在使用自动填充功能时，会调用这里。

解决方案

设置关闭EditText控件的自动填充功能

Edittext的自动填充引起的Bug_乂星人的博客-CSDN博客_android edittext 自动填充

4.4 其他Crash较多的bug

android.app.RemoteServiceException Context.startForegroundService() did not then call Service.startForeground()

Android8.0启动服务适配问题，App内部和SDK中都有闪退出现，排查App中所有的Service进行适配处理。

android.content.ActivityNotFoundException No Activity found to handle Intent

这个是我们App中js回调安卓跳转页面的方法，由于页面未找到导致的闪退。另外我们发现业务中由

JavaScriptInterface回调安卓端再进行页面的一些操作和发出的Eventbus事件引发了许多莫名其妙的小bug，为此我们将JavaScriptInterface中的回调尽可能都抛回主线程中执行，减少了因子线程操作UI和多线程执行不安全的问题。

com.google.gson.stream.MalformedJsonException

由于后端数据或者本地数据库问题导致数据的解析异常，统一使用了Json解析工具，对异常进行捕获处理

Crash预防和辅助工具

灰度发布

货拉拉的打包发布系统支持持续集成、灰度发布、构建统计、配置下发、强升普升弱升、内测分发等功能，灰度发布支持设置设备ID、数量、百分比、版本号、品牌型号、网络制式、时间、系统版本、业务城市、定位城市等非常灵活。

灰度系统的主要作用：

尽早的获得用户的反馈，完善产品功能
暴露存在的Crash问题、产品设计问题，及时修改，缩小影响面

货拉拉目前的版本发布会严格按照灰度策略进行逐步放量，在业务需要时会增加对灰度的范围设置例如：城市、品牌型号、版本号等。对于风险较大的需求，我们可能会专门安排一个灰度版本进行发布，最大可能的缩小影响范围。

应用配置系统

通过货拉拉的打包发布系统进行配置下发，同时这个配置支持灰度发布，可以像App发布灰度一样下发，对于一些业务可以通过配置下发，控制功能的参数，功能的开关，进行业务降级，修改AB实验等。

例如，我们在线上环境中有些H5页面使用了离线包，其他部门对网关进行切换，导致离线包出现跨域问题，无法访问页面。我们通过配置下发及时关闭离线包功能，业务降级为在线网页。

代码质量相关措施

建立Code Review 制度

保证代码的可读性和风格一致性：便于其他成员对代码的理解，增强维护性
发现错误：代码中出现错误很难避免，而这些错误在另外一个人眼中可能很容易被发现
发现设计问题：检查代码中的设计不合理，避免后续维护、迭代困难
健壮性检查：检查代码的健壮性，是否有潜在的安全问题，性能风险等
互相学习：阅读他人的代码也可以从中吸取经验

增加模块Owner

模块内代码主要由Owner开发实现，Owner会比较熟悉，并且能够保证代码的一致性。
Owner可以更好的review其他开发者的代码

业务串讲、思维导图

让团队内部成员熟悉业务模块和流程
利于团队内沟通、学习

代码扫描：不符合团队规范的代码无法提交

保证代码的规范
保证代码的一致性

热修复

当App已经大面积发布，而Crash会导致大量用户无法使用、闪退、主流程无法执行等，我们会考虑热修复。如果没有热修复技术，那么我们只能重新发布App版本，甚至需要进行强制升级，会造成极差的用户体验。

日志系统

货拉拉的日志系统分为两类：

实时日志：用户在使用App时产生日志通过上传策略上报到我们平台，支持日志等级筛选、TAG筛选和搜索等常用功能。

离线日志：根据用户ID等进行推送用户进行上报，或者用户主动进行上报。

ログシステムにより、ログレベルやログ時間などに応じて、現在のユーザーの使用シナリオや操作パスを知ることができ、シーンの再現に便利で、クラッシュを解決するための鋭いツールの1つです。

要約する

昨年、アプリの主要モジュールをリファクタリングし、サードパーティのSDKを管理し、いくつかの特別なガバナンスを実施しました。クラッシュ率は5％以上から0.02％に減少しました。安定性の向上により、ユーザーは大幅に減少しました。フィードバックの問題とユーザーからの苦情。Androidアプリに関連する苦情とフィードバックの数が昨年4月の12件から今年4月に2件に減り、より多くのユーザーを維持し、ユーザーが注文を正常に完了できるようになりました。いくつかのガバナンス原則を要約します。

あるケースから別のケースへ、ポイントから表面へ、問題から問題のクラスを導入または分類するための推論は、特別なガバナンスを実行します。
本質を探し、問題の根本を見つけることは、盲目的に捕まえようとして、回避することを判断することではありません。
時間内に解決します。クラッシュの問題は、グレースケールとフルボリュームの後ではなく、開発とテストのプロセスで可能な限り時間内に解決する必要があります。
防止に重点を置き、新進段階でのクラッシュを排除し、コードレビュー、モジュール分割、技術的なクロストークなどの対策を実行します。
アクセスを制御し、モジュール、SDK、および新技術の導入を厳密に制御して、導入のリスクを軽減します

クラッシュガバナンスは一度だけではなく、長期的なガバナンスと長期的なメカニズムの確立が必要です。一方、新しいテクノロジーやクロスプラットフォームテクノロジーについては、これらのテクノロジーの適用を直接放棄するのではなく、ビジネスが許す限り、既存の予防策を勇気を持って使用する必要があります。

参照リンク：

Umeng + U-APMモバイルアプリケーションパフォーマンスエクスペリエンスレポート：Androidのクラッシュ率が0.32％に達し、OPPO、Huawei、VIVOがうまくクラッシュしましたモバイルアプリケーションパフォーマンスレポートアーカイブ|クラウドモバイルパフォーマンスの標準値と定義
を聞く基調講演-ナゲット

業界標準

ガバナンス前の全体的な状態

クラッシュガバナンス手法

クラッシュガバナンスの実践

代码重构

三方SDK和Native崩溃处理