Flutter AndroidAlarmManager静态回调无法读取SharedPreferences等本地存储数据求解

云上老周

2026-10-7

问题根因

该问题既不是框架Bug，也不是插件不支持，是AndroidAlarmManager的固有特性导致：
AndroidAlarmManager触发回调时，会启动一个完全独立的新Flutter引擎实例，和App前台运行的主引擎属于不同进程，二者的存储空间默认不互通，且新引擎默认没有完成插件初始化。目前常用的SharedPreferences、GetStorage默认都是单进程存储方案，自然读不到主进程写入的数据，其他未初始化的插件也无法正常调用。
Flutter本身支持应用被杀死后的后台任务执行，只需适配不同引擎/进程的初始化逻辑即可；AlarmManager也支持调用其他插件，只要补全初始化逻辑即可正常使用。

可行解决方案

方案1（推荐，改造成本最低）：直接通过AndroidAlarmManager的传参能力传递所需数据，完全规避跨进程读存储的问题
修改定时任务注册逻辑，新增params参数传入分类值：

await AndroidAlarmManager.periodic(
  timeInterval,
  20,
  term,
  // 新增参数传递选中的分类
  params: <String, dynamic>{'category': categoryScheduled},
);

同步修改回调方法接收参数：

static term(int id, Map<String, dynamic>? params) async {
  int pageNumber = 0;
  // 直接读取传入的分类值，无需调用存储插件
  var query = params?['category'] ?? 'nature';
  // 后续网络请求、更换壁纸的原有逻辑保持不变
  // ...
}

方案2（适合必须读取本地存储的场景）：更换支持多进程的存储方案，补全回调初始化逻辑
1. 回调方法第一行先完成Flutter绑定初始化，确保插件可以正常加载：
```
static term() async {
  // 必须放在方法第一行执行
  WidgetsFlutterBinding.ensureInitialized();
  // 原有逻辑保持不变
  // ...
}
```
2. 将默认单进程的存储插件替换为支持多进程的方案，比如适配多进程场景的SharedPreferences衍生插件，不要使用默认版SharedPreferences和GetStorage。