Android开发高手课之崩溃优化

作者: 小菜鸟程序媛 | 来源:发表于2019-02-21 15:23 被阅读21次

    《Android开发高手课》是极客时间上为数不多的质量高的课程,通过学习确实让我开拓了眼界,之前对于Android的优化可能仅仅停留在基础的阶段,通过对这个课程的学习,确实了解了更多的监测手段以及优化手段。

    Android两种崩溃

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

    Native崩溃捕获

    1. 编译端. 编译c/c++代码时,需要将带符号信息的文件保留下来
    2. 客户端. 捕获到崩溃时,将收集到尽可能多的有用信息写入日志,然后选择合适的时机上传到服务器
    3. 服务端. 读取客户端上报的日志文件,寻找适合的符号文件,生成可读的c/c++调用栈
    image.png

    BreakPad是目前Native崩溃中最成熟的方案

    选择合适的崩溃服务

    1. 腾讯Bugly: 除了有crash数据还有运营数据
    2. UC 啄木鸟:可以捕获Java、Native异常,被系统强杀的异常,ANR,Low Memory Killer、killProcess。技术深度以及捕获能力强
    3. 网易云捕:继承便捷,访问快,捕获以及上报速度及时,支持实时报警,提供多种报警选项,可以自定义参数。
    4. Google的Firebase
    5. crashlytics:服务器在国外,访问速度慢,会丢掉数据
    6. 友盟:crash之后会在再次启动的时候上报数据,所以不能立即获得这部分信息

    客观的衡量崩溃

    1. UV崩溃率:崩溃造成的用户影响范围,UV崩溃率 = 发生崩溃的UV / 登录UV
    2. 异常率UV异常率 = 发生异常退出或崩溃的UV / 登录UV
    3. PV崩溃率
    4. 启动崩溃率
    5. 重复崩溃率

    使用安全模式:天猫App启动保护实践来解决启动崩溃的问题

    检测应用ANR异常的方法

    1. 使用FileObserver监听 /data/anr/trace.txt的变化。很多高版本的系统没有这个权限
    2. 监控消息队列的运行时间,无法准确判断是否会出现ANR,而且也无法得到完整的ANR日志。

    应用退出情况总结

    1. 主动自杀 Process.killProcess、exit()等
    2. 崩溃 出现了Java或Native崩溃
    3. 系统重启
    4. 被系统杀死,被low memory killer或用户从后台任务中移除
    5. ANR

    在应用启动的时候设定标志,在主动自杀或崩溃(单独统计)后更新日志,下次启动检查该标志就能确认运行期间是否发生过异常退出,通过这个检测,可以反映ANR、low memory killer、系统强杀、死机、断电等其他无法正常捕获到的异常。

    崩溃现场的信息采集

    崩溃信息

    1. 进程名、线程名。崩溃是发生在前台进程还是后台进程,是否发生在UI线程
    2. 崩溃堆栈和类型

    系统信息

    1. Logcat:系统的event logcat会记录App运行的一些基本情况,在文件 /system/etc/event-log-tags中
    2. 机型,系统,厂商,CPU,ABI,Linux版本等
    3. 设备状态,是否root,是否是模拟器等

    内存信息

    1. 系统剩余内存:对于系统内存状态,可以读取/proc/meminfo
    2. 应用使用内存:包括java内存,RSS,PSS
    3. 虚拟内存:可以通过/proc/self/status得到,通过/proc/self/maps文件可以得到具体的分布情况

    资源信息

    1. 文件句柄fd:文件句柄限制通过/proc/self/limits获得,一般单个进程允许打开的最大文件句柄个数是1024,超过800个比较危险
    2. 线程数,超过400个比较危险
    3. JNI

    应用信息

    1. 崩溃场景,发生的Activity或Fragment
    2. 关键操作路径
    3. 其他自定义信息

    获取Logcat方法

    1. 通过logcat命令获取
      优点:非常简单,兼容性好。
      缺点:整个链路比较长,可控性差,失败率高,特别是堆破坏或者堆内存不足时,基本会失败。
    2. hook liblog.so实现。通过hook liblog.so 中__android_log_buf_write 方法,将内容重定向到自己的buffer中。
      优点:简单,兼容性相对还好。
      缺点:要一直打开。
    3. 自定义获取代码。通过移植底层获取logcat的实现,通过socket直接跟logd交互。
      优点:比较灵活,预先分配好资源,成功率也比较高。
      缺点:实现非常复杂

    获取Java 堆栈

    native崩溃时,通过unwind只能拿到Native堆栈。我们希望可以拿到当时各个线程的Java堆栈

    1. Thread.getAllStackTraces()
      优点:简单,兼容性好。
      缺点:
      a. 成功率不高,依靠系统接口在极端情况也会失败。
      b. 7.0之后这个接口是没有主线程堆栈。
      c. 使用Java层的接口需要暂停线程
    2. hook libart.so
      通过hook ThreadList和Thread的函数,获得跟ANR一样的堆栈。为了稳定性,我们会在fork子进程执行。
      优点:信息很全,基本跟ANR的日志一样,有native线程状态,锁信息等等。
      缺点:黑科技的兼容性问题,失败时可以用Thread.getAllStackTraces()兜底

    扩展阅读

    1. Android 平台 Native 代码的崩溃捕获机制及实现
    2. master - breakpad/breakpad - Git at Google

    相关文章

      网友评论

        本文标题:Android开发高手课之崩溃优化

        本文链接:https://www.haomeiwen.com/subject/vhbryqtx.html