Android进程死亡原因筛查方法

一、进程清理机制：

1. Google原生清理机制【AMS cached清理；LMDK清理】
2. 厂商自身清理机制和模块特殊清理机制

 

二、Log关键字查询：

am_proc_died【events log】                        // 进程有此条日志则表示进程死亡

am_kill   【events log】                           // AMS查杀相关日志

lowmemorykiller 【android_log/main_log/kernel_log】  //lmkd查杀相关日志

 

三、被杀原因标志：

1.AMS cached

08-09 20:14:15.800 2138 2386 I am_kill : [0,13974,com.color0s.digitalwellbeing,995,empty #35]

08-09 20:14:15.868 2138 7372 I am_proc_died: [0,13974,com.color0s.digitalwellbeing,995,19]

2.LMKD

09-11 09:12:51.218 645 645 I killinfo:

[16094,10…………]

09-11 09:12:51.529 2164 8342 I am_proc_died: [0,16094,com.tencent.mm:appbrand1,955,19]

3.AMS cpu

01-15 10:41:55.522 23358 23383 I am_kill : [0,12494,com.tencent.mm:tools,900,excessive cpu 7260 during 300231 dur=339554234 limit=2]

4.自杀

09-11 09:12:32.587 13187 13187 I Process : Sending signal. PID: 13187 SIG: 9

 

四、避免被杀方法：

• 原生ams cached清理

a、提高应用的adj值，如运行前台service，启动service操作。

b、调整AMS cached的配置值（需各项目配置，一般不修改），如例子中的35则说明系统配置的cached数量为64，通过命令dumpsys activity settings | grep -i CUR_MAX_CACHED_PROCESSES查看

（分析结果如：分析为原生AMS cached清理机制，则可回复如下信息：com.color0s.digitalwellbeing进程处于cached，系统cached状态的应用太多，触发原生AMS cached清理机制，杀掉了优先级低的com.color0s.digitalwellbeing，正常的清理策略功能）

• LMKD清理机制

a、提高应用的adj值，如运行前台service，启动service操作。

（分析结果如：需要底层的同事进行处理，分析为原生AMS cached清理机制，则可回复如下信息：请联系底层软件开发组进行处理）

• 原生AMS cpu清理机制

（分析结果如：AMS cpu清理机制是应用自身的代码实现导致，需要负责该应用的同事进行处理，分析为AMS cpu清理机制：若为非三方应用，请联系负责该应用的同事进行处理；若为三方应用，请联系负责三方兼容性的同事进行处理。）

• 进程自杀问题

signal 9的信号，即为应用自杀。

（进程自杀是应用自身的代码逻辑，需要负责该应用的同事进行处理，分析为进程自杀，则可回复类似如下信息：若为非三方应用，请联系负责该应用的同事进行处理；若为三方应用，请联系负责三方兼容性的同事进行处理）