调用Android原生相机时Java旧版App后台进程被杀死该如何解决？

1. PhenotypeProcessReaper组件说明 #

PhenotypeProcessReaper是谷歌移动服务（GMS）中的内置组件，负责管理Phenotype框架的实验配置刷新逻辑，该框架广泛用于谷歌系服务的A/B测试、灰度功能下发、配置动态更新。

2. 进程被杀的根本原因 #

你捕获的日志已经明确给出了触发原因：

2021-11-18 22:19:54.906 9177-9762/es.myapp I/PhenotypeProcessReaper: Memory state is: 400
2021-11-18 22:19:54.906 9177-9762/es.myapp I/PhenotypeProcessReaper: Killing process to refresh experiment configuration
2021-11-18 22:19:54.906 9177-9762/es.myapp I/Process: Sending signal. PID: 9177 SIG: 9

• 日志中的Memory state is: 400对应Android系统内存状态常量ADJ_MEM_FACTOR_LOW，说明当时设备内存处于较低水平，满足了PhenotypeProcessReaper杀进程刷新配置的触发条件
• 直接触发原因不是系统主动回收后台进程，而是Phenotype框架需要刷新实验配置，选择了处于后台状态的你的应用进程杀死，以完成配置更新

你在调用相机时应用退到后台，刚好命中了该组件的进程选择策略，所以出现了稳定复现的被杀现象。

3. 修复建议 #

• 架构层面的必做优化 #

你当前正在开发的通用状态持久化方案是正确的修复方向，原有依赖静态变量存储核心业务数据的架构本身就不符合Android平台设计规范：Android系统会在内存不足时主动回收后台进程，无论是否存在PhenotypeProcessReaper的影响，静态变量存储的数据都有丢失风险。
具体优化点：

• 核心业务流程的状态数据禁止仅存在静态变量中，每走到关键业务节点就同步将状态持久化到本地数据库或SharedPreferences，调用相机前必须完成当前全量状态的落盘操作
• 重写调用相机的对应Activity的onSaveInstanceState方法，将临时运行状态存入Bundle，应用返回恢复时优先从onCreate的入参、onRestoreInstanceState回调中读取状态恢复
• 在Application的启动逻辑中增加进程重建判断，每次进程启动时优先从持久化存储中恢复核心业务状态到内存，再执行后续业务逻辑

• 针对性规避方案 #

  • 先确认问题触发范围：如果仅在搭载GMS服务的设备上复现，无GMS服务的安卓设备无此问题，即可完全确定是该组件导致
  • 排查应用中集成的谷歌系SDK：包括Firebase、谷歌广告、谷歌地图、谷歌登录等组件，此类SDK普遍依赖Phenotype框架做配置下发，可尝试将相关SDK升级到最新正式版，部分版本已经优化了配置刷新的杀进程逻辑，也可查询对应SDK的开发文档，关闭不必要的动态实验配置开关，可降低该场景的触发概率

内容的提问来源于stack exchange，提问作者Ricardo Aveledo