进程死亡原因筛查方法
作者：互联网
进程清理机制：
- Google原生清理机制【AMS cached清理；LMDK清理】
- 厂商自身清理机制和模块特殊清理机制
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的信号，即为应用自杀。
（进程自杀是应用自身的代码逻辑，需要负责该应用的同事进行处理，分析为进程自杀，则可回复类似如下信息：若为非三方应用，请联系负责该应用的同事进行处理；若为三方应用，请联系负责三方兼容性的同事进行处理）
标签：09,应用,cached,清理,死亡,筛查,进程,AMS,com 来源： https://www.cnblogs.com/1118zjg/p/16009908.html