使用JobIntentService调度api调用非常困难，如何正确实现呢？

如何解决使用JobIntentService调度api调用非常困难，如何正确实现呢？

在我从事的应用程序中，我们使用RxJava和Retrofit进行api调用。我们使用MVVM和存储库模式。

我不想将RxJava的一次性调用附加到viewmodel生命周期中，因为例如当我在概览屏幕中下载数据列表时，我决定在api调用完成之前离开该屏幕，并在10秒后返回它，它将中止第一个api调用，并且必须重新开始。 （一旦api调用完成，我会将其缓存在存储库中。）

因此，要解决此问题，我们可以在进行api调用时忽略任何android生命周期，而不必丢弃一次性对象，或者我们生成服务以处理生命周期，因此我们可以在后台进行API调用，并且仍然可以我们可以使用android生命周期来处理api调用。

因此，我们自然是优秀的开发人员，我们希望最大程度地减少编译器警告，而对一次性操作不执行任何操作都会触发警告，因此我们选择使用JobIntentServices进行api调用；启动应用程序后，我们将开始获取作业，以下载数据并将其存储在存储库中的内存缓存中。存储库本身包含一个状态主题（RxJava BehaviorSubject），该主题了解状态“加载”，“成功”和“错误”，并使用该状态主题可以对我们的UI进行建模（加载=微调器，成功=数据概述，错误=一些错误屏幕）。

这就像一个咒语，它不再影响用户的操作，只要此服务处于活动状态，它将下载资源并将其缓存在内存中。一旦用户决定转到概述页面，它就会看到与存储库状态相对应的内容，一旦api调用完成，该状态就会自动更新。

那我的问题是什么？ JobIntentServices令人发指。你知道吗？

• 并发作业数量有限，在我的测试设备上为4
  • 这是设备的最大值，因此另一个应用可以安排很多（长时间运行）的工作，而我的应用将受到此影响
• 排定的作业是FIFO，即使您自己排定多个作业，对它们进行优先级排序的唯一方法是调用它们的顺序。您以后不能将“高优先级”作业加入队列，而该作业应在低优先级作业之前开始。
• JobIntentServices有时会导致随机Given work is not active: JobWorkItem{id=1 intent=Intent { cmp=com.example.jobintenttestapp/.TestJobService1 } dcount=2}崩溃，即使我自己杀死了该应用程序之后（通过在应用程序抽屉中滑动该应用程序）
  • 不幸的是，我无法始终如一地重现此问题

为了测试这种行为的极端性，我创建了一个示例应用程序，该应用程序简单地多次（例如20次）调度6个不同的JobIntentServices，每个调度程序都有一些日志语句，睡眠时间为10秒。从测试应用程序分发这些JobIntentServices并打开自己的应用程序后，我注意到JobIntentService的onCreate或onHandleWork都没有被调用很长时间，因为它首先等待我的测试应用程序。

所以我认为我有以下选择：

• 继续使用JobIntentServices，因为这是他们的本意
• 完全忽略生命周期，不要丢弃我的一次性用品（由于没有杀死应用程序的生命周期挂钩，因此当杀死应用程序进程时，无论如何我的所有网络调用都将终止）
• 改为使用IntentServices（但是在API级别30中已弃用它们，所以这似乎不是一个好主意）
• 使用常规服务

所以我的问题是，对此有何明智的决定？别人如何解决这些问题？我想念什么吗？