Android P中android.intent.action.SIM_STATE_CHANGED广播触发后进程被杀死

你遇到的是Android P（API 28）后台进程管控收紧带来的典型问题——系统启动你的广播接收器进程后，直接判定它为空进程（无活跃组件支撑），还没等onReceive()执行就将其回收了。

问题核心分析 #

从日志里的Killing 3334:com.testapp/u0a36 (adj 906): empty #9可以明确：系统是以「空进程」的理由杀死应用的。Android P对后台进程的优先级判定更严格，当进程仅由静态注册的广播接收器启动，且没有其他活跃组件（比如前台Activity、前台Service、绑定服务等）时，系统会认为这个进程没有持续存活的必要，会快速触发回收机制。

可行解决方案 #

针对这个问题，你可以尝试以下几种方案来规避：

• 改用动态广播注册：
  在应用的长期存活组件（比如主Activity、后台Service）中动态注册广播接收器。这样广播触发时，进程本身处于活跃状态，系统不会轻易将其标记为空进程回收。示例代码：

  private BroadcastReceiver simStateReceiver = new BroadcastReceiver() {
      @Override
      public void onReceive(Context context, Intent intent) {
          // 处理SIM状态变化的逻辑
      }
  };
  
  @Override
  protected void onResume() {
      super.onResume();
      IntentFilter filter = new IntentFilter();
      filter.addAction("android.intent.action.SIM_STATE_CHANGED");
      registerReceiver(simStateReceiver, filter);
  }
  
  @Override
  protected void onPause() {
      super.onPause();
      unregisterReceiver(simStateReceiver);
  }
  

• 用前台Service配合监听：
  如果需要后台持续监听SIM状态，可创建一个前台Service（必须显示通知），在Service内部动态注册广播接收器。前台Service的进程优先级远高于普通后台进程，系统不会轻易回收。

• 轻量化onReceive()逻辑：
  确保onReceive()里只做最基础的逻辑分发，绝对不要执行耗时操作（比如网络请求、本地数据库批量写入）。如果有耗时任务，立即通过WorkManager或IntentService异步处理，避免阻塞广播接收器的执行流程——否则系统可能因进程响应缓慢提前触发回收。

• 避免单独为广播接收器开进程：
  检查Manifest中是否给广播接收器设置了android:process属性单独开进程，这种孤立进程的优先级极低，几乎一定会被系统快速回收。

额外提示 #

虽然android.intent.action.SIM_STATE_CHANGED属于允许静态注册的广播（不在Android O+的隐式广播限制列表中），但Android P及以上的后台管控逻辑对「仅由静态广播启动的空进程」容忍度极低，所以动态注册+活跃组件的组合是更可靠的实现方式。

内容的提问来源于stack exchange，提问作者Susheel Tickoo