标签: android-workmanager

谷歌最近弃用了 IntentService：https ://android.googlesource.com/platform/frameworks/base.git/+/6f8b09029932dfd24945202017639754b00acc2e

IntentService 的文档现在说：

 * @deprecated IntentService is subject to all the
 *   <a href="/preview/features/background.html">background execution limits</a>
 *   imposed with Android 8.0 (API level 26). Consider using {@link androidx.work.WorkManager}
 *   or {@link androidx.core.app.JobIntentService}, which uses jobs
 *   instead of services when running on Android 8.0 or higher.

那么JobIntentService和WorkManager有什么区别，在什么情况下推荐使用哪一个呢？

谷歌在这个页面上甚至没有提到 JobIntentService，他们只提到了 WorkManager：https : //developer.android.com/guide/background

通常有以下Application课程

public class WeNoteApplication extends MultiDexApplication {
    public static WeNoteApplication instance() {
        return me;
    }

    @Override
    public void onCreate() {
        super.onCreate();

        me = this;

在正常情况下，Application的onCreate将永远是入口点之前称为Activity小号的onCreate“。

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        // Normally, it will NOT be null.
        android.util.Log.i("CHEOK", "WeNoteApplication -> " + WeNoteApplication.instance());

但是，如果在启动应用程序时运行以下命令

c:\yocto>adb shell bmgr restore com.yocto.wenote
restoreStarting: 1 packages
onUpdate: 0 = com.yocto.wenote
restoreFinished: 0
done

该应用程序将关闭。如果是，我点击应用程序图标以再次启动。这是怎么回事

1. Application的onCreate未执行！ …

问题背景

目前,我们面临来自Android Vital报告的" 网络使用率过高(背景) ".过去30天是0.04%,但我们只有9%好

• 过去30天 - 0.04%
• 基准 - 优于9%

因为只有超过9%看起来像一个可怕的事情.我们决定认真研究这个问题.

该应用程序是一个笔记应用程序(https://play.google.com/store/apps/details?id=com.yocto.wenote),它提供一个可选的特征-同步应用程序结束后,以背景云英寸

这就是我们在后台执行同步到云的方式.

1. 我们用WorkManager.
2. 在应用程序onPause,计划OneTimeWorkRequest,有约束NetworkType.CONNECTED.工人计划以8秒的延迟开始.
3. 如果失败,我们重试使用BackoffPolicy.LINEAR,延迟时间为1.5小时.
4. 最大重试次数为1次.这意味着,应用程序关闭后应用程序再次重新打开.同步到云进程的最大执行次数为2.
5. 数据的大小各不相同,可以是几KB到几百MB.

其他信息我们如何执行同步

1. 我们正在使用Google Drive REST API.
2. 我们正在从Google Drive App Data文件夹下载zip文件,在本地执行数据合并,然后压缩,并将单个zip文件重新上传回Google Drive App Data文件夹.
3. zip文件大小可以从几KB到几百MB不等.这是因为我们的笔记应用程序支持图像作为附件.

分析

我们唯一的信息是https://developer.android.com/topic/performance/vitals/bg-network-usage.

当应用程序在后台连接到移动网络时,应用程序会唤醒CPU并打开收音机.反复这样做可能会耗尽设备的电池电量.如果应用程序处于PROCESS_STATE_BACKGROUND或PROCESS_STATE_CACHED状态,则认为该应用程序在后台运行.......当Android应用程序在0.10%的电池会话中在后台运行时,每小时发送和接收总计50 MB的总量时,Android vitals认为后台网络使用率过高.

1. 我们启动后台同步作业,在8秒之后Application的onPause.在此期间,应用程序内部或外部PROCESS_STATE_BACKGROUND/ PROCESS_STATE_CACHED？我们怎样才能避免运行中PROCESS_STATE_BACKGROUND/ PROCESS_STATE_CACHED？
2. " 在0.10%的电池续航时间在后台运行 "是什么意思？我们怎能避免这样的？
3. 另一个假设是同步文件太大,并且使用了太多数据.很快,我们注意到这种假设可能不正确.我们注意到根据" 每小时移动网络使用情况(背景) ",数据大小从0MB到5MB.

问题

我的问题是

1. 这种" …

在我的Android应用我有一个运行一个又一个的第一个目的服务是由广播trigerred多意图服务.几天前我遇到了Work Manager,并且非常喜欢Worker和WorkManager类的简单性.工作管理器对常规意图服务的利弊是什么？我现在应该转换到工作经理,考虑到将来我可能不得不写更多的意向服务吗？还有哪个选项可以帮助我轻松测试代码？

由于Worker该类是由framework(WorkerManager)创建的,我们如何使用@Inject字段Worker？

我是新架构组件WorkManager的新手,我通过Retrofit和RxJava进行API调用.

我的用例是从后端获取新帖子,然后显示通知,并更新小部件.

所以来自Worker类的doWork()方法中的代码可能看起来像这样.

@NonNull
  @Override
  public Result doWork() {
    AppDependencies appDependencies = new AppDependencies((Application) getApplicationContext());
    Repository repository = appDependencies.getRepository();

    repository.getNewPosts()
        .flatMap(newPosts -> repository.inserPosts(newPosts).toObservable())
        .doOnError(Timber::e)
        //if success - > return  Result.SUCCESS,
        // -> show notification
        // -> update widget
        // error-> return Result.Failure
        .dontKnowWhatBestNextThing; //blocking or subscribing

    //if we reached here then Retry
    return Result.RETRY;
  }

我的问题是在Worker类中使用RxJava代码的正确方法是什么,因为doWork()方法有一个返回值,所以我必须使Rx代码同步.

如果我使用非阻塞Rx方法,我怎样才能返回值(成功 - 失败 - 重试)

我正在尝试使用架构组件中的WorkManager.我已将compileSdkVersion和targetSdkVersion从27升级到28. gradle sync已成功完成.但是构建时错误不断涌现.由于'android.support:design',android.support库使用的是版本28.0.0-rc02.

我试图添加packagingOptions以排除'proguard/androidx-annotations.pro'.但它没有帮助.但是这次我得到了一个不同的错误信息:

Program type already present: com.google.common.util.concurrent.ListenableFuture

我无法弄清楚出了什么问题.

的build.gradle:

apply plugin: 'com.android.application'

apply plugin: 'kotlin-android'

apply plugin: 'kotlin-android-extensions'

apply plugin: 'io.fabric'

android {
    compileSdkVersion 28
    defaultConfig {
        applicationId "com.apps.test"
        minSdkVersion 16
        targetSdkVersion 28
        versionCode 5
        versionName "1.0"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
        multiDexEnabled true
    }

    signingConfigs {
        release
    }

    buildTypes {
        release {
            signingConfig signingConfigs.release

            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            resValue "bool", "enableFirebase", "true"

        }
        debug {
            minifyEnabled false
            resValue "bool", "enableFirebase", "false"

        }
    }
}

dependencies {
    implementation fileTree(include: ['*.jar'], …

为了从前台服务获取位置，我们最近将 WorkManager 迁移为使用 ForegroundService。我们遵循以下文件来实现这一目标：

https://developer.android.com/topic/libraries/architecture/workmanager/advanced/long-running

以下是变化：

class ... : Worker(appContext, params) {
    val forgroundInfo: ForegroundInfo? = null
        get() {
            val notification = NotificationUtils.getNotificationBuilder(appContext, ...)
                .setContentTitle(...)
                .setContentText(...)
                .setStyle(Notification.BigTextStyle().bigText(...))
                .setSmallIcon(...)
                .setLargeIcon(...)
                .setOngoing(true)
                .build()

            return if (Utils.isAndroid10OrAbove()) {
                ForegroundInfo(
                    FOREGROUND_NOTIFICATION_ID,
                    notification,
                    FOREGROUND_SERVICE_TYPE_LOCATION
                )
            } else {
                ForegroundInfo(FOREGROUND_NOTIFICATION_ID, notification)
            }
        }

    override fun doWork(): Result {
        forgroundInfo?.let { setForegroundAsync(it) }
        
        ...
    }
}

并在 AndroidManifest.xml 中

<service
        android:name="androidx.work.impl.foreground.SystemForegroundService"
        android:foregroundServiceType="location"
        tools:node="merge" />

发布此版本后，我们的应用程序 crashlytics 仪表板充满了以下崩溃：

Fatal Exception: android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{efecaf7 …

有人问过同样的问题，但它们对我不起作用，一开始我使用的是最新版本的工作管理器，即 2.7 alpha 3，但我降级了，因为它只兼容 android 12 预览版 sdk，错误仍然存​​在！
它无法实例化工作人员，因为这些依赖项包含在工作人员的构造函数中，在我添加它们之前它就可以工作，但如果我无法添加它们，则刀柄没有任何好处，所以情况如下：

Manifest 不包含任何与工作管理器相关的配置！

应用类别：

@HiltAndroidApp
class TimelineApp : Application() ,Configuration.Provider{

@Inject
lateinit var workerFactory: HiltWorkerFactory

override fun getWorkManagerConfiguration() =
    Configuration.Builder()
        .setWorkerFactory(workerFactory)
        .build()

}

工人：

@HiltWorker
class DriveSyncWorker @AssistedInject constructor(
    @Assisted val context: Context,
    @Assisted workerParams: WorkerParameters,
    val dependency: StorageHelper,
)

注意到：它没有使用 HiltWorkFactory ！

错误：

E/WM-WorkerFactory: Could not instantiate com.wakaztahir.timeline.utils.workers.DriveSyncWorker
    java.lang.NoSuchMethodException: com.wakaztahir.timeline.utils.workers.DriveSyncWorker.<init> [class android.content.Context, class androidx.work.WorkerParameters]
        at java.lang.Class.getConstructor0(Class.java:2332)
        at java.lang.Class.getDeclaredConstructor(Class.java:2170)
        at androidx.work.WorkerFactory.createWorkerWithDefaultFallback(WorkerFactory.java:95)
        at androidx.work.impl.WorkerWrapper.runWorker(WorkerWrapper.java:244)
        at androidx.work.impl.WorkerWrapper.run(WorkerWrapper.java:136)
        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 …

我已经看过WorkManager的codelab以及这里的一些例子,但是我看到的代码中的所有内容都与在设备上本地工作或上传到服务器有关,而不是下载数据和响应收到的数据.在开发人员指南中,它甚至说,"例如,一个应用程序可能需要不时地从网络上下载新资源",所以我认为这对于这项任务来说是完美的.我的问题是,如果WorkManager可以处理以下场景,如果没有,那么处理它的正确工具是什么:

1. 安排一天在后台运行一次的工作
2. 工作是从REST API进行数据提取(如果可能,将其发布到LiveData对象).
3. 数据返回时,检查它是否比本地数据更新.
4. 通知用户新数据可用.

我的worker类看起来像这样:

public class MyWorker extends Worker {

@NonNull
@Override
public WorkerResult doWork() {
    lookForNewData();
    return WorkerResult.SUCCESS;
}

public void lookForNewData() {
    MutableLiveData<MyObject> liveData = new MutableLiveData<>();

    liveData.observe(lifeCycleOwner, results -> {
        notifyOnNewData(results);
    })

    APILayer.getInstance().fetchData(searchParams, liveData)
}

我的问题当然是LiveData对象无法观察,因为没有活动或片段可以作为其LifecycleOwner.但即使我使用来自API的回调来响应到达的数据,我的工作人员已经发布它是成功的,它可能不会继续回调,对吧？所以我知道这种方法是完全错误的,但是我看不到任何使用WorkManager获取数据的代码

请帮助一个正确的解决方案和一些示例代码或一些链接,如果它可以处理这种工作或其他更合适的话,可以使用WorkManager.