课后总结3-崩溃优化2

1、崩溃现场

崩溃基本信息
- 进程名、线程名
- 崩溃堆栈和类型
系统信息
- Logcat
  - 由于权限问题获取的Logcat可能只包含App相关的
  - 系统event logcat 记录在/system/etc/event-log-tags中，其对应信息含义如下
    - am_on_resume_called : 生命周期
    - am_low_memory：系统内存不足
    - am_destory_activity：销毁activity
    - am_anr: ANR 以及原因
    - am_kill: APP被杀以及原因
- 机型、厂商、系统、CPU、Linux 版本、ABI（Application binary interface ：应用程序二进制接口）
- 设备状态：是否root、是否是模拟器。有些由Xposed和多开软件造成的，要区别对待
内存信息 --- OOM 、ANR 、虚拟内存耗尽
- 系统剩余内存
  - 关于系统内存状态，读取文件/proc/meminfo
- 应用使用内存
  - 包含Java内存、RSS（Resident Set Size）、PSS（Proportional Set Size）
  - PSS 和 RSS通过/proc/self/smap计算，可以进一步得到例如apk、dex、so等详细的分类统计
  - 虚拟内存，可以通过/proc/self/status得到，通过/proc/self/smap可以得到具体的分布情况，
    - 很多类似OOM、tgkill的问题都是虚拟内存不足导致的
    - Name: com.sample.name //进程名
    - FDSize：800 //当前进程申请的文件句柄个数
    - VmPeak：3004628 KB //当前进程的虚拟内存峰值大小
    - VmSize：2997032 KB //当前进程的虚拟内存大小
    - Threads: 600 //当前进程包含的线程个数
资源信息
- 文件句柄fd。其最大限制可以通过/proc/self/limits获得指示为open files，一般单个进程最大为1024，但是当超过800的时候就比较危险
- 线程数。可以通过/proc/self/status得到指示为Threads，一个线程可能占到2M的虚拟内存，当超过400个线程就比较危险了
- JNI。可以通过DumpReferenceTables统计JNI的引用表，进一步分析是否出现了JNI泄露问题
应用信息
- 崩溃场景
- 记录用户关键操作路径
- 其他自定义信息，音乐类（播放的音乐）、浏览器（打开的网页或视频）
  - 运行时间
  - 是否加载了补丁
  - 是否是全新安装包或升级等信息

2、崩溃分析

确定重点
- 确认严重程度，优先解决对业务有重大影响的
- 确认崩溃基本信息
  - Java崩溃
  - Native崩溃
    - 需要观察signal、code、fault addr等内容，以及崩溃时java的堆栈，常见如下
      - SIGSEGA ：一般是空指针、非法指针造成
      - SIGABRT ：ANR和abort()造成
      - 详细介绍参考崩溃信号介绍
  - ANR
    - 查看日志中iowait、CPU、GC、system server等信息
    - 查看logcat日子，包括system logcat 和 event logcat
查找共性：是否同系统，同机型、同厂商
尝试修复
疑难问题
- 查找可能原因
- 尝试规避
- Hook解决

说明：文章内容摘录自Android 开发高手课程图文数据

课后总结3-崩溃优化2

猜你喜欢