Xamarin Android Worker替换JobIntentService适配Android12相关问题

1. Worker重写的DoWork方法内部是否可以使用await关键字？ #

不可以直接使用。
AndroidX WorkManager提供的Worker基类，DoWork方法是同步签名：Xamarin绑定时对应的方法签名为public override Result DoWork()，没有返回Task<Result>的异步重载，你如果强行给方法加async关键字修改返回值会直接编译失败。
就算你绕开编译限制（比如写async void、或者在同步方法里用GetAwaiter().GetResult()阻塞），前者会在遇到第一个await时直接返回，WorkManager会误判任务执行完成，后续逻辑完全脱离调度管控；后者会阻塞WorkManager的工作线程，容易触发线程池饥饿问题，完全不符合异步编程的预期。

2. 要使用await的话，改为继承ListenableWorker是否是更优选择？切换后会不会损失原有能力？ #

是适配异步await场景的标准最优选择，切换后不会损失任何WorkManager提供的核心能力。
ListenableWorker是Worker的直接父类，本身就是为异步工作场景设计的基类：你只需要重写它的StartWork方法，返回ListenableFuture<Result>类型的结果，配合Xamarin提供的Tasks.ToListenableFuture()扩展方法，就能直接写标准的async/await异步逻辑，不需要阻塞任何线程。
能力层面两者完全对齐：

• 同样支持传入工作参数、返回成功/失败/重试三类结果
• 完全兼容WorkManager的所有调度约束（网络状态、充电状态、存储空间要求等）
• 支持链式任务调度、指数退避重试、任务状态观察等所有特性
• 额外比同步Worker多了更灵敏的任务取消回调感知，异步任务的生命周期管控更灵活
  如果是长耗时任务场景，ListenableWorker还支持直接调用setForegroundAsync()方法将工作升级为前台服务，满足Android 12的后台执行限制要求，比同步Worker的适配成本更低。

3. 在Worker的DoWork方法中通过Task.Factory.StartNew(LongRunning)启动长耗时任务，之后立即返回成功结果，该长耗时任务是否会运行至完成？ #

这种写法完全不可靠，任务大概率会被系统提前终止，根本无法保证运行到完成。
核心原因有两个：

1. 生命周期管控断层：一旦你从DoWork方法返回结果，WorkManager会立刻判定当前工作单元执行完成，立即释放持有的唤醒锁、进程保活权重，不会再为你启动的那个长耗时任务提供任何执行保障。
2. Android 12后台管控限制：你启动的LongRunning Task本质是脱离系统调度框架管控的普通后台线程，当应用退到后台、没有任何活跃的前台服务、系统认可的调度任务时，应用进程会被标记为可回收的缓存进程，内存紧张时系统会直接杀死进程，这个脱离管控的任务会直接中断，连执行完成的机会都没有。

不要用这种绕开框架管控的写法，本质和之前直接在Application里起野线程没有区别，甚至比旧的JobIntentService稳定性更差——旧JobIntentService至少会持有服务唤醒锁直到任务执行完成，你这种提前返回的写法连唤醒锁都不会持有，任务被杀的概率更高。
正确处理方式：如果任务总时长在10分钟以内，就用ListenableWorker把整个逻辑包在异步任务里，等任务真正执行完成再返回结果；如果任务时长超过10分钟，就调用setForegroundAsync()把工作升级为前台服务工作，挂前台通知满足系统保活要求。

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