Kotlin开发Android闹钟应用出现空指针异常问题排查

• 冷启动场景下数据库/仓库实例未正确初始化
  这是该类问题最高发的诱因：闹钟触发时如果应用主进程已经被系统后台回收，AlarmReceiver会触发应用进程冷启动，此时如果你通过手动单例、Hilt/Koin等依赖注入框架获取alarmRepository实例，大概率会出现注入流程未完成、拿到未正确绑定数据库的空DAO实例的情况——这类场景下调用查询方法不会抛出初始化异常，只会直接返回null，本质是你拿到的DAO实例指向了一个刚创建的空数据库，而非你存储了实际闹钟数据的业务库。

  验证方法：在var alarm = alarmRepository.getAlarm(intentAlarmId.toLong())代码前加两行日志：第一行打印当前仓库绑定的数据库文件绝对路径，第二行直接调用DAO查询全表闹钟的总条数。如果全表条数为0，且数据库路径和你正常打开主界面时的数据库路径一致，继续排查下一项；如果路径不一致、或者调用全表查询直接抛出未初始化异常，即可确认是该问题。
  修复方案：不要在Receiver中直接依赖全局单例/注入的仓库实例，可在onReceive生命周期中主动触发Application层的数据库初始化逻辑，确保拿到的数据库实例和主进程一致；也可以将闹钟触发后的业务逻辑迁移到前台服务中执行，规避冷启动时依赖注入未完成的问题。

• 数据库被清空/损坏，目标数据已不存在
  未修改业务代码但数据丢失的常见触发场景有三类：
  1. 升级应用时targetSdk提升到31+，未配置Android 12要求的dataExtractionRules，系统自动备份/恢复流程清空了应用私有目录下的数据库文件
  2. 构建Room数据库实例时调用了fallbackToDestructiveMigration()，近期修改过Alarm实体类字段、升级了数据库版本但未编写对应Migration逻辑，Room触发破坏性迁移直接删表重建
  3. 部分国产定制系统的后台清理逻辑会异常清空应用私有数据

  验证方法：将应用从最近任务列表划掉后重新打开主界面，检查ID=1的闹钟是否存在；如果主界面也看不到该闹钟，直接导出data/data/你的应用包名/databases/路径下的db文件，用SQLite客户端打开查看alarm表是否为空、表结构是否和当前实体类一致。
  修复方案：为Room配置数据库损坏回调，异常时尝试恢复备份数据；针对数据库升级编写正确的Migration逻辑，非调试场景不要开启破坏性迁移；按官方要求配置备份规则，排除数据库文件被自动备份流程误删的问题。

• 低概率多进程数据隔离问题
  如果在Manifest中为AlarmReceiver配置了android:process属性使其运行在独立进程，部分国产定制ROM会对同应用多进程做数据隔离，导致独立进程访问到的数据库文件和主进程不一致，查询返回空。

  快速验证方式：在onReceive中手动构建数据库实例：

  val testDb = Room.databaseBuilder(
      context.applicationContext,
      AppDatabase::class.java,
      "你业务中使用的数据库文件名"
  ).build()
  val testAlarm = testDb.alarmDao().getAlarm(1L)
  

  如果手动构建的实例能查到ID=1的闹钟，可100%确认是原有仓库/数据库实例初始化异常导致的问题；如果手动构建的实例依然查不到，即可确认数据库本身已经没有对应数据。

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