标签：09 应用 cached 清理 死亡 筛查 进程 AMS com
进程清理机制：
- 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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。