系统相关
首页 > 系统相关> > 进程死亡原因筛查方法

进程死亡原因筛查方法

作者:互联网

进程清理机制:

  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

 

避免被杀方法:

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,正常的清理策略功能)

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

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

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

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

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

标签:09,应用,cached,清理,死亡,筛查,进程,AMS,com
来源: https://www.cnblogs.com/1118zjg/p/16009908.html