java - AndroidX Work Library 正在取消操作，看似没有原因

Question

我正在与 AndroidX Work Dependency 合作尝试运行一些后台服务操作。截至发布此问题时，我当前正在运行最新的稳定版本 2.2.0。

我在后台运行的实际操作是一项相当重的 CPU 操作，因为它在我的一个库 ( here ) 中使用一些压缩代码，并且可能需要 3-30 分钟，具体取决于大小和相关视频的长度。

这是我构建和运行工作请求的代码:

    public static void startService(){
        //Create the Work Request
        String uniqueTag = "Tag_" + new Date().getTime() + "_ChainVids";
        OneTimeWorkRequest.Builder builder = new OneTimeWorkRequest.Builder(CompleteVideoBackgroundService.class);
        Constraints.Builder constraints = new Constraints.Builder();
        constraints.setRequiredNetworkType(NetworkType.CONNECTED);
        builder.setConstraints(constraints.build());
        builder.setInitialDelay(1, TimeUnit.MILLISECONDS);
        builder.addTag(uniqueTag);
        Data inputData = new Data.Builder().putString("some_key", mySerializedJSONString).build();
        builder.setInputData(inputData);
        OneTimeWorkRequest compressRequest = builder.build();

        //Set the Work Request to run
        WorkManager.getInstance(MyApplication.getContext())
                .beginWith(compressRequest)
                .enqueue();
    }

然后它会触发运行所有后台服务操作的此类:

public class MyServiceSampleForStackoverflow  extends Worker {

    private Context context;
    private WorkerParameters params;

    public MyServiceSampleForStackoverflow(@NonNull Context context, @NonNull WorkerParameters params){
        super(context, params);
        this.context = context;
        this.params = params;
    }

    /**
     * Trimming this code down considerably, but the gist is still here
     */
    @NonNull
    @Override
    public Result doWork() {
        try {
            //Using using a hard-coded 50% for this SO sample
            float percentToBringDownTo = 0.5F;
            Uri videoUriToCompress = MyCustomCode.getVideoUriToCompress();
            VideoConversionProgressListener listener = (progressPercentage, estimatedNumberOfMillisecondsLeft) -> {
                float percentComplete = (100 * progressPercentage);
                //Using this value to update the Notification Bar as well as printing in the logcat. Erroneous code removed
            };
            String newFilePath = MyCustomCode.generateNewFilePath();
            //The line below this is the one that takes a while as it is running a long operation
            String compressedFilePath = SiliCompressor.with(MyApplication.getContext()).compressVideo(
                    listener, videoUriToCompress.getPath(), newFilePath, percentToBringDownTo);
            //Do stuff here with the compressedFilePath as it is now done
            return Result.success();
        } catch (Exception e){
            e.printStackTrace();
            return Result.failure();
        }
    }
}

偶尔，没有任何规律或理由，工作人员会在没有我告诉它的情况下随机停止。发生这种情况时，我会看到以下错误:

Work [ id=254ae962-114e-4088-86ec-93a3484f948d, tags={ Tag_1571246190190_ChainVids, myapp.packagename.services.MyServiceSampleForStackoverflow } ] was cancelled
    java.util.concurrent.CancellationException: Task was cancelled.
        at androidx.work.impl.utils.futures.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:1184)
        at androidx.work.impl.utils.futures.AbstractFuture.getDoneValue(AbstractFuture.java:514)
        at androidx.work.impl.utils.futures.AbstractFuture.get(AbstractFuture.java:475)
        at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:284)
        at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:764)

当这种情况随机发生时，我实际上只是盯着我的手机，根本不与它互动。我不想运行其他应用程序，也不想占用 CPU 做其他事情。我从来没有看到自己的任何堆栈跟踪，也没有明显的直接问题或原因。

因此，问题是，这里发生了什么，在没有任何挑衅的情况下随机停止 Worker 服务？ 为什么会随机停止操作？

谢谢大家。

编辑 1

• 我确实测试了删除网络约束要求线，认为这可能会导致问题，并且我确实看到它甚至在那之后发生，所以我不认为这就是问题。

• 我正在 Google Pixel 3、API 28、Android 9 上进行测试，但我测试过的任何其他设备(无论 API 级别如何(最低支持为 21))都显示了相同的问题。

编辑 2

• 我尝试通过让类扩展 ListenableWorker 而不是 Worker 来重写该类以使用异步方法，但这并没有解决问题。

Answer 1

您很可能面临以下两个问题之一。

首先，假设您的后台服务运行时间超过 10 分钟可能需要 3-30 分钟，具体取决于相关视频的大小和长度，您可以遇到由 WorkManager 代码强加的硬时间限制。

在 docs here他们说:系统指示您的应用程序出于某种原因停止您的工作。如果超过 10 分钟的执行期限，就会发生这种情况。

这似乎是最有可能的，但另一个问题可能与概述的 Android 后台限制有关 here其中详细介绍了与面向 Android 8.0 或更高版本的应用相关的更改。正如您在编辑中提到的，您正在 Google Pixel 3、API 28、Android 9 上进行测试，这可能是直接相关的。

就解决方案而言，最简单的解决方案(尽管是一个令人沮丧的解决方案)是告诉用户他们需要将应用程序保持在前台。这至少可以避免 10 分钟的间隙。

另一种选择是利用 API 29 中引入的新 Bubble API。文档为 here您可能感兴趣的文档部分是这样的:当气泡展开时，内容 Activity 会经历正常的进程生命周期，导致应用程序成为前台进程。制作一个小型化的“扩展” View 并在应用程序关闭时由用户扩展该 View 是绕过 10 分钟计时器的一个很好的替代解决方案。