凯发娱乐赌场在线-凯发娱乐旗舰厅-凯发国际娱乐欢迎您
当前位置:官网首页 > 新闻资讯 > 行业新闻 >
新闻资讯

Android 高质量开发之崩溃优化

作者:发布时间:2019-08-05 09:19

前言

开发人员碰到 APP 崩溃什么办?不少人会说根据 Log,找到闪退的代码,捕获异常,“消化”掉了所有 Java 崩溃。至于程序是否会出现其他异常表现,那是上帝要管的事情。是的,这种方法对于紧急情况下不失为一种解决办法,但闪退的真相是什么?是否从根源上解决问题呢?

一、崩溃

崩溃率是衡量一个应用质量高低的基本指标,那么,该怎样客观地衡量崩溃这个指标,以及又该如何看待和崩溃相关的稳定性。

Android 的两种崩溃:

Java 崩溃

Native 崩溃

简单来说,Java 崩溃就是在 Java 代码中,出现了未捕获异常,导致程序异常退出。那 Native 崩溃一般都是因为在 Native 代码中访问非法地址,也可能是地址对齐出现了问题,或者发生了程序主动 Abort,这些都会产生相应的 Signal 信号,导致程序异常退出。

1.1 崩溃的收集

“崩溃”就是程序出现异常,而一个产品的崩溃率,跟我们如何捕获、处理这些异常有比较大的关系。对于很多中小型公司来说,可以选择一些第三方的服务。目前各种平台也是百花齐放,包括阿里的友盟、的Bugly、云捕、Google 的 Firebase 等等。要懂得借力!

1.2 ANR

崩溃率是不是就能完全等价于应用的稳定性呢?答案是肯定不行。处理了崩溃,我们还会经常遇到 ANR这个问题。

出现 ANR 的时候,系统还会弹出对话框打断用户的操作,这是用户非常不能忍受的。

ANR处理方法:

使用 FileObserver 监听 /data/anr/traces.txt 的变化。非常不幸的是,很多高版本的 ROM,已经没有读取这个文件的权限了。这个时候你可能只能思考其他路径,海外可以使用 Google Play 服务,而国内微信利用Hardcoder框架向厂商获取了更大的权限。也可以将手机 ROOT 掉,然后取得 traces.txt 文件。

1.3 应用退出

除了常见的崩溃,还有一些会导致应用异常退出的情况,例如:

主动自杀。Process.killProces____it 等

崩溃。出现了 Java 或 Native 崩溃

系统重启。系统出现异常、断电、用户主动重启等,我们可以通过比较应用开机运行时间是否比之前记录的值更小

被系统杀死。被 low memory killer 杀掉、从系统的任务管理器中划掉等

ANR

我们可以在应用启动的时候设定一个标志,在主动自杀或崩溃后更新标志,这样下次启动时通过检测这个标志就能确认运行期间是否发生过异常退出。对应上面的五种退出场景,我们排除掉主动自杀和崩溃这两种场景,希望可以监控到剩下三种的异常退出,理论上这个异常捕获机制是可以达到 100% 覆盖的。

通过这个异常退出的检测,可以反映如 ANR、low memory killer、系统强杀、死机、断电等其他无法正常捕获到的问题。当然异常率会存在一些误报,比如用户从系统的任务管理器中划掉应用。对于线上的大数据来说,还是可以帮助我们发现代码中的一些隐藏问题。

根据应用的前后台状态,我们可以把异常退出分为前台异常退出和后台异常退出。“被系统杀死” 是后台异常退出的主要原因,当然我们会更关注前台的异常退出的情况,这会跟 ANR、OOM 等异常情况有更大的关联。二、崩溃处理

我们每天工作也会遇到各种各样的疑难问题,“崩溃”就是其中比较常见的一种问题。解决问题跟破案一样需要经验,我们分析的问题越多越熟练,定位问题就会越快越准。当然这里也有很多套路,比如对于 “案发现场” 我们应该留意哪些信息?怎样找到更多的 “证人” 和 “线索” ? “侦查案件” 的一般流程是什么?对不同类型的 “案件” 分别应该使用什么样的调查方式?

要相信 “真相永远只有一个”,崩溃也并不可怕。

2.1 崩溃现场

崩溃现场是我们的“第一案发现场”,它保留着很多有价值的线索。现在可以挖掘到的信息越多,下一步分析的方向就越清晰,而不是去靠盲目猜测。

崩溃信息

从崩溃的基本信息,我们可以对崩溃有初步的判断。进程名、线程名。崩溃的进程是前台进程还是后台进程,崩溃是不是发生在 UI 线程。

崩溃堆栈和类型。崩溃是属于 Java 崩溃、Native 崩溃,还是 ANR,对于不同类型的崩溃关注的点也不太一样。特别需要看崩溃堆栈的栈顶,看具体崩溃在系统的代码,还是 APP 代码里面。

关键字:FATAL FATAL EXCEPTION: main

Process: com.cchip.csmart, PID: 27456

java.lang.NullPointerException: Attempt to invoke virtual method "void android.widget.TextView.setText" on a null object reference

at com.cchip.alicsmart.activity.SplashActivity$1.handleMessage

at android.os.Handler.dispatchMessage

at android.os.Looper.loop

at android.app.ActivityThread.main

at java.lang.reflect.Method.invoke

at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run

at com.android.internal.os.ZygoteInit.main

系统信息

系统的信息有时候会带有一些关键的线索,对我们解决问题有非常大的帮助。

Logcat。这里包括应用、系统的运行日志。由于系统权限问题,获取到的 Logcat 可能只包含与当前 APP 相关的。其中系统的 event logcat 会记录 APP 运行的一些基本情况,记录在文件 /system/etc/event-log-tags 中。//system logcat:

10-25 17:13:47.788 21430 21430 D dalvikvm: Trying to load lib ...

//event logcat:

10-25 17:13:47.788 21430 21430 I am_on_resume_called: 生命周期

10-25 17:13:47.788 21430 21430 I am_low_memory: 系统内存不足

10-25 17:13:47.788 21430 21430 I am_destroy_activity: 销毁 Activty

10-25 17:13:47.888 21430 21430 I am_anr: ANR 以及原因

10-25 17:13:47.888 21430 21430 I am_kill: APP 被杀以及原因

机型、系统、厂商、CPU、ABI、Linux 版本等。通过采集多达几十个维度,这对寻找共性问题会很有帮助。

内存信息

OOM、ANR、虚拟内存耗尽等,很多崩溃都跟内存有直接关系。如果把用户的手机内存分为“2GB 以下”和“2GB 以上”两个区,就会发现“2GB 以下”用户的崩溃率是“2GB 以上”用户的几倍。

系统剩余内存。关于系统内存状态,可以直接读取文件 /proc/meminfo。当系统可用内存很小时,OOM、大量 GC、系统频繁自杀拉起等问题都非常容易出现。

应用使用内存。包括 Java 内存、RSS、PSS,我们可以得出应用本身内存的占用大小和分布。PSS 和 RSS 通过 /proc/self/smap 计算,可以进一步得到例如 apk、dex、so 等更加详细的分类统计。

虚拟内存。虚拟内存可以通过 /proc/self/status 得到,通过 /proc/self/maps 文件可以得到具体的分布情况。有时候我们一般不太重视虚拟内存,但是很多类似 OOM、tgkill 等问题都是虚拟内存不足导致的。Name: com.xmamiga.name // 进程名

FDSize: 800 // 当前进程申请的文件句柄个数

VmPeak: 3004628 kB // 当前进程的虚拟内存峰值大小

VmSize: 2997032 kB // 当前进程的虚拟内存大小

Threads: 600 // 当前进程包含的线程个数

一般来说,对于 32 位进程,如果是 32 位的 CPU,虚拟内存达到 3GB 就可能会引起内存申请失败的问题。如果是 64 位的 CPU,虚拟内存一般在 3~4GB 之间。当然如果我们支持 64 位进程,虚拟内存就不会成为问题。Google Play 要求 2019 年 8 月一定要支持 64 位,在国内虽然支持 64 位的设备已经在 90% 以上了,但是商店都不支持区分 CPU 架构类型发布,普及起来需要更长的时间。

资源信息

有的时候会发现应用堆内存和设备内存都非常充足,还是会出现内存分配失败的情况,这跟资源泄漏可能有比较大的关系。

文件句柄 fd。文件句柄的限制可以通过 /proc/self/limits 获得,一般单个进程允许打开的最大文件句柄个数为 1024。但是如果文件句柄超过 800 个就比较危险,需要将所有的 fd 以及对应的文件名输出到日志中,进一步排查是否出现了有文件或者线程的泄漏。opened files count 812:

0 - /dev/null

1 - /dev/log/main4

2 - /dev/binder

3 - /data/data/com.xmamiga.sample/files/test.config

...

线程数。当前线程数大小可以通过上面的 status 文件得到,一个线程可能就占 2MB 的虚拟内存,过多的线程会对虚拟内存和文件句柄带来压力。根据我的经验来说,如果线程数超过 400 个就比较危险。需要将所有的线程 id 以及对应的线程名输出到日志中,进一步排查是否出现了线程相关的问题。 threads count 412:

1820 com.xmamiga.crashsdk

1844 ReferenceQueue_______>系统崩溃常常令我们感到非常无助,它可能是某个 Android 版本的 Bug,也可能是某个厂商修改 ROM 导致。这种情况下的崩溃堆栈可能完全没有我们自己的代码,很难直接定位问题。能做的有:

查找可能的原因。通过上面的共性归类,我们先看看是某个系统版本的问题,还是某个厂商特定 ROM 的问题。虽然崩溃日志可能没有我们自己的代码,但通过操作路径和日志,可以找到一些怀疑的点。

尝试规避。查看可疑的代码调用,是否使用了不恰当的 API,是否可以更换其他的实现方式规避。

Hook 解决。这里分为 Java Hook 和 Native Hook。它可能只出现在 Android 7.0 的系统中,参考 Android 8.0 的做法,直接 catch 住这个异常。

如果做到了上面说的这些,以上大部分的崩溃应该都能解决或者规避,大部分的系统崩溃也是如此。当然总有一些疑难问题需要依赖到用户的真实环境,这些需要具备类似动态跟踪和调试的能力。三、总结

崩溃攻防是一个长期的过程,我们尽可能地提前预防崩溃的发生,将它消灭在萌芽阶段。作为技术人员,我们不应该盲目追求崩溃率这一个数字,应该以用户体验为先,如果强行去掩盖一些问题往往更加适得其反。我们不应该随意使用 try catch 去隐藏真正的问题,要从源头入手,了解崩溃的本质原因,保证后面的运行流程。在解决崩溃的过程,也要做到由点到面,不能只针对这个崩溃去解决,而应该要考虑这一类崩溃怎么解决和预防。