Android WorkManager使用以及源码分析

 更新时间:2023年02月13日 10:36:52   作者:众少成多积小致巨  
WorkManager 是适合用于持久性工作的推荐解决方案。如果工作始终要通过应用重启和系统重新启动来调度,便是持久性的工作。本文主要介绍了Android WorkManager的使用,需要的可以参考一下

1、前言

WorkManager 是适合用于持久性工作的推荐解决方案。如果工作始终要通过应用重启和系统重新启动来调度,便是持久性的工作。由于大多数后台处理操作都是通过持久性工作完成的,因此 WorkManager 是适用于后台处理操作的主要推荐 API。 WorkManager 可处理三种类型的持久性工作:

  • 立即执行:必须立即开始且很快就完成的任务,可以加急。
  • 长时间运行:运行时间可能较长(有可能超过 10 分钟)的任务。
  • 可延期执行:延期开始并且可以定期运行的预定任务。

2、使用

2.1、引用

implementation "androidx.work:work-runtime:2.7.1" //基础使用
implementation "androidx.work:work-multiprocess:2.7.1" //跨进程时引用

2.2 使用

执行一次性任务

Data data = new Data.Builder().putBoolean("is_test", false).build();
WorkManager.getInstance(this).enqueue(
        new OneTimeWorkRequest.Builder(Test.class) // 执行任务一次性任务
                .setInputMerger(NewInputMerge.class) // 输入数据合并策略,这里并没有用,链式处理时,多个上流执行结果合并,作为下流输入数据
                .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 5, TimeUnit.MINUTES) // 重试策略
                .setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST) // 加急处理
                .addTag("test").addTag("huahua") // 标识
                .setInputData(data) // 输入数据
                .setInitialDelay(5, TimeUnit.SECONDS) // 执行延时时间
                .setConstraints(new Constraints.Builder().setRequiresBatteryNotLow(true).build()) // 约束,部分约束只对高版本有效
                .build()
);

执行周期性任务

WorkManager.getInstance(this).enqueue(
        new PeriodicWorkRequest.Builder(Test.class, 2, TimeUnit.HOURS) // 执行周期性任务,周期2小时
                .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 5, TimeUnit.MINUTES)
                .setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST)
                .addTag("test").addTag("huahua")
                .setInputData(data)
                .setInitialDelay(5, TimeUnit.SECONDS) // 首次执行延时时间
                .setConstraints(new Constraints.Builder().setRequiresBatteryNotLow(true).build())
                .build()
);

拥有名字的任务

WorkManager.getInstance(this).enqueueUniqueWork("test", ExistingWorkPolicy.KEEP,
        new OneTimeWorkRequest.Builder(Test.class).build()); // 此种方法会对重复名字的任务进行处理

监听状态

WorkManager.getInstance(this).getWorkInfosByTagLiveData("test").observe(this, 
        new Observer<List<WorkInfo>>() {
            @Override
            public void onChanged(List<WorkInfo> workInfos) {

            }
        });

定义Work代码

public class Test extends Worker {
    public Test(@NonNull Context context, @NonNull WorkerParameters workerParams) {
        super(context, workerParams);
        Data input = getInputData(); // 获取输入数据
        boolean isTest = input.getBoolean("is_test", true);
    }

    @NonNull
    @Override
    public Result doWork() {
        return Result.success();
    }
}

继承使Worker类,实现doWork()方法,此方法是实现任务的主体;doWork()返回的 Result会通知 WorkManager 服务工作是否成功,以及工作失败时是否应重试工作。

  • Result.success():工作成功完成。
  • Result.failure():工作失败。
  • Result.retry():工作失败,应根据其重试政策在其他时间尝试。

配置初始化 不同的版本初始化不同,但是都是通过Provider来进行的,2.6之前是WorkManagerInitializer, 2.6之后是InitializationProvider;这里按照2.7.1的版本来说,老版本有需要留言回复;有两种处理方案

  • 移除默认Provider
  • 按照Provider流程来进行

按照提供初始化流程处理

1.首先注意一个字符串配置:这个很重要,不建议修改

<string name="androidx_startup" translatable="false">androidx.startup</string>

2.提供实现Initializer的类,这个类是被调用的关键

3.移除默认实现

<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    android:exported="false"
    tools:node="merge">
    <meta-data
        android:name="androidx.work.WorkManagerInitializer"
        android:value="androidx.startup"
        tools:node="remove" /> // 这表示移除
</provider>

默认实现Initializer类WorkManagerInitializer,使用的默认configuration

public final class WorkManagerInitializer implements Initializer<WorkManager> {

    private static final String TAG = Logger.tagWithPrefix("WrkMgrInitializer");

    @NonNull
    @Override
    public WorkManager create(@NonNull Context context) {
        Logger.get().debug(TAG, "Initializing WorkManager with default configuration.");
        WorkManager.initialize(context, new Configuration.Builder().build()); // 这里提供Configuration
        return WorkManager.getInstance(context);
    }

    @NonNull
    @Override
    public List<Class<? extends androidx.startup.Initializer<?>>> dependencies() {
        return Collections.emptyList(); // 提供需要执行的其它Initializer
    }
}

4.进行注册自定义实现; 在meta-data数据处理,key为你需要调用的初始化类,value必须为R.sting.androidx_startup这个字符串的值; 如下

<provider
        android:name="androidx.startup.InitializationProvider"
        android:authorities="${applicationId}.androidx-startup"
        android:exported="false"
        tools:node="merge" >
        <meta-data
            android:name="androidx.work.WorkManagerInitializer" // 这里为你的实现的Initializer
            android:value="androidx.startup" /> // 这里必须与R.sting.androidx_startup保持一致
    </provider>

2.3 重要概念

任务标识

  • id : 通过WorkRequest对象getStringId获取,每次添加一次任务,就会得到唯一的id
  • name :任务名字,暂时一次性任务才可以有; 一个任务最多一个名字,而一个名字可以对应多个任务; 同名字任务可以通过定义不同名字冲突来解决
  • tag: 一个任务可以拥有多个tag,一个tag可以对应多个任务

任务类型

  • 一次性任务: 仅仅执行一次, 如果结果返回retry时,按照重试退避政策,进行重试,直至成功
  • 周期性任务: 按照周期执行,无论结果返回什么情况,每次周期内仅仅执行一次

任务链

使用 WorkManager 创建工作链并将其加入队列。工作链用于指定多个依存任务并定义这些任务的运行顺序。使用 WorkManager.beginWith(OneTimeWorkRequest 或 WorkManager.beginWith(List)返回WorkContinuation实例,然后通过其 then(OneTimeWorkRequest)或 then(List)添加任务链,最后使用WorkContinuation.enqueue()进行执行。

任务链先添加的任务为后续任务的先决条件, 也就是前面任务成功了后面任务才会执行

重试退避政策

针对worker执行返回Result.retry()时处理策略, 使用方法setBackoffCriteria设置, 有两个指标,策略和延时时间(允许的最小值,即 10 秒);情况有下面2种

  • 线性LINEAR: 每次失败后重新开启任务时间延时为 延时时间次数倍(延时时间 * n)
  • EXPONENTIAL: 每次失败后重新开启任务时间延时为 延时时间的指数倍(延时时间 * 2^n)

输入合并器

针对一次性任务,且在工作链中,父级工作请求的输出将作为子级的输入传入的场景中使用。输入中会存在相同关键字,这时,输入就会存在冲突

WorkManager 提供两种不同类型的 InputMerger:

  • OverwritingInputMerger:会尝试将所有输入中的所有键添加到输出中。如果发生冲突,它会覆盖先前设置的键。
  • ArrayCreatingInputMerger: 会尝试合并输入,并在必要时创建数组。

冲突解决政策

调度唯一工作时,发生冲突时要执行的操作。可以通过在将工作加入队列时传递一个枚举来实现此目的。

对于一次性工作,您需要提供一个 ExistingWorkPolicy,有4 个选项。

  • REPLACE:用新工作替换现有工作。此选项将取消现有工作。
  • KEEP:保留现有工作,并忽略新工作。
  • APPEND:将新工作附加到现有工作的末尾。此政策将导致您的新工作到现有工作,在现有工作完成后运行。 现有工作将成为新工作的先决条件。如果现有工作变为 CANCELLED 或 FAILED 状态,新工作也会变为 CANCELLED 或 FAILED。如果您希望无论现有工作的状态如何都运行新工作,请改用 APPEND_OR_REPLACE
  • APPEND_OR_REPLACE: 类似于 APPEND,不过它并不依赖于先决条件工作状态。**即使现有工作变为 CANCELLED 或 FAILED 状态,新工作仍会运行。

约束条件

任务执行的先决条件,使用Contraints.Builder()进行构建实例。有一下约束

  • NetworkType : 约束运行工作所需的网络类型。
  • BatteryNotLow : 如果设置为 true,那么当设备处于“电量不足模式”时,工作不会运行。
  • RequiresCharging : 如果设置为 true,那么工作只能在设备充电时运行。
  • DeviceIdle:如果设置为 true,则要求用户的设备必须处于空闲状态,才能运行工作。在运行批量操作时,此约束会非常有用;若是不用此约束,批量操作可能会降低用户设备上正在积极运行的其他应用的性能。
  • StorageNotLow: 如果设置为 true,那么当用户设备上的存储空间不足时,工作不会运行。

还有以下约束,对于>=24的版本有效:

  • setContentUriTriggers方法: 设置触发任务的uri
  • setTriggerContentUpdateDelay方法:设置触发执行的延迟时间
  • setTriggerMaxContentDelay方法:设置处罚执行的最大延时

3、原理

合理分为几个部分来说

  • 1. 约束检测: 约束检测的逻辑以及实现
  • 2. 任务调度: 3种调度器, alarm、greedy、JobScheduler; 用于唤起任务执行
  • 3. 任务执行流程 :请求的包装,任务如何加入调度器,以及调度完成后执行任务详情

这里有需要理解的一个技术点:SettableFuture,实现了ListenableFuture接口,并且增加了下面接口ListenableFuture。这个类在源码中频繁使用

ListenableFuture只有一个方法

void addListener(Runnable listener, Executor executor)

调用了这个方法,这个类才有使用意义;调用之后,表示SettableFuture若完成,则使用executor执行listener

另外一个让我觉得有意思的地方,或者说不同之前future的地方是, SettableFuture未实现Runnable接口,也就是其结果不是来源于自己,来源于调用下面3个方法

    public boolean set(@Nullable V value) // 正常设置结果

    public boolean setException(Throwable throwable) // 执行结果异常

    public boolean setFuture(ListenableFuture<? extends V> future) // 设置执行结果来源,也就是ListenableFuture的执行结果

3.1 约束检测

类图如下

结合源码分析,结论有:

  • WorkConstraintsTracker类:使用入口,构造器传入WorkConstraintsCallback为结果回调,也可以直接调用方法areAllConstraintsMet来判断是否满足约束
  • ConstraintController类:一种约束控制器类,通过OnConstraintUpdatedCallback回调实时结果给WorkConstraintsTracker, 通过ConstraintListener与ConstraintTracker联系
  • ConstraintTracker:实际约束值的检测者,ConstraintListener回调实时传递值与ConstraintController;通过setState触发回调

实际检测技术点,也就是ConstraintTracker实现

3.1.1 StorageNotLowTracker类

存储空间的是否低,根据系统广播来处理

Intent.ACTION_DEVICE_STORAGE_OK // 存储空间够用
Intent.ACTION_DEVICE_STORAGE_LOW // 存储空间很低

初步检测状态:

@Override
public Boolean getInitialState() {
    Intent intent = mAppContext.registerReceiver(null, getIntentFilter());
    if (intent == null || intent.getAction() == null) {
        return true;
    } else {
        switch (intent.getAction()) {
            case Intent.ACTION_DEVICE_STORAGE_OK:
                return true;
            case Intent.ACTION_DEVICE_STORAGE_LOW:
                return false;
            default:
                return null;
        }
    }
}

实时更新通过接收广播信息:

public void onBroadcastReceive(Context context, @NonNull Intent intent) {
    if (intent.getAction() == null) {
        return;
    }

    switch (intent.getAction()) {
        case Intent.ACTION_DEVICE_STORAGE_OK:
            setState(true);
            break;
        case Intent.ACTION_DEVICE_STORAGE_LOW:
            setState(false);
            break;
    }
}

3.1.2 BatteryChargingTracker类

充电状态,同样通过广播来进行处理;

接收广播根据版本不同而不同如下:

    public IntentFilter getIntentFilter() {
        IntentFilter intentFilter = new IntentFilter();
        if (Build.VERSION.SDK_INT >= 23) {
            intentFilter.addAction(BatteryManager.ACTION_CHARGING);
            intentFilter.addAction(BatteryManager.ACTION_DISCHARGING);
        } else {
            intentFilter.addAction(Intent.ACTION_POWER_CONNECTED);
            intentFilter.addAction(Intent.ACTION_POWER_DISCONNECTED);
        }
        return intentFilter;
    }

初始状态:

    @Override
    public Boolean getInitialState() {
        IntentFilter intentFilter = new IntentFilter(Intent.ACTION_BATTERY_CHANGED);
        Intent intent = mAppContext.registerReceiver(null, intentFilter);
        if (intent == null) {
            Logger.get().error(TAG, "getInitialState - null intent received");
            return null;
        }
        return isBatteryChangedIntentCharging(intent);
    }
    
    private boolean isBatteryChangedIntentCharging(Intent intent) {
        boolean charging;
        if (Build.VERSION.SDK_INT >= 23) {
            int status = intent.getIntExtra(BatteryManager.EXTRA_STATUS, -1);
            charging = (status == BatteryManager.BATTERY_STATUS_CHARGING
                    || status == BatteryManager.BATTERY_STATUS_FULL);
        } else {
            int chargePlug = intent.getIntExtra(BatteryManager.EXTRA_PLUGGED, 0);
            charging = (chargePlug != 0);
        }
        return charging;
    }

实时状态:

@Override
public void onBroadcastReceive(Context context, @NonNull Intent intent) {
    String action = intent.getAction();
    if (action == null) {
        return;
    }
    Logger.get().debug(TAG, String.format("Received %s", action));
    switch (action) {
        case BatteryManager.ACTION_CHARGING:
            setState(true);
            break;
        case BatteryManager.ACTION_DISCHARGING:
            setState(false);
            break;
        case Intent.ACTION_POWER_CONNECTED:
            setState(true);
            break;
        case Intent.ACTION_POWER_DISCONNECTED:
            setState(false);
            break;
    }
}

3.1.3 BatteryNotLowTracker类

电量是否低,同样通过广播实时获取状态

    Intent.ACTION_BATTERY_OKAY //电量正常
    Intent.ACTION_BATTERY_LOW //电量低

初始状态:

    @Override
    public Boolean getInitialState() {
        IntentFilter intentFilter = new IntentFilter(Intent.ACTION_BATTERY_CHANGED);
        Intent intent = mAppContext.registerReceiver(null, intentFilter);
        if (intent == null) {
            Logger.get().error(TAG, "getInitialState - null intent received");
            return null;
        }

        int status = intent.getIntExtra(BatteryManager.EXTRA_STATUS, -1);
        int level = intent.getIntExtra(BatteryManager.EXTRA_LEVEL, -1);
        int scale = intent.getIntExtra(BatteryManager.EXTRA_SCALE, -1);
        float batteryPercentage = level / (float) scale;

        return (status == BatteryManager.BATTERY_STATUS_UNKNOWN
                || batteryPercentage > BATTERY_LOW_THRESHOLD); // 这里是小于15%算是低
    }

实时更新:

    @Override
    public void onBroadcastReceive(Context context, @NonNull Intent intent) {
        if (intent.getAction() == null) {
            return;
        }
        Logger.get().debug(TAG, String.format("Received %s", intent.getAction()));
        switch (intent.getAction()) {
            case Intent.ACTION_BATTERY_OKAY:
                setState(true);
                break;
            case Intent.ACTION_BATTERY_LOW:
                setState(false);
                break;
        }
    }

3.1.4 NetworkStateTracker类

网络状态,这个根据版本不同使用也不同

  • 大于等于24时, ConnectivityManager.registerDefaultNetworkCallback(NetworkCallback networkCallback) 来进行监听网络状态变化
  • 小于24时,通过广播ConnectivityManager.CONNECTIVITY_ACTION来进行处理

初始状态:

NetworkState getActiveNetworkState() {
    NetworkInfo info = mConnectivityManager.getActiveNetworkInfo();
    boolean isConnected = info != null && info.isConnected();
    boolean isValidated = isActiveNetworkValidated();
    boolean isMetered = ConnectivityManagerCompat.isActiveNetworkMetered(mConnectivityManager);
    boolean isNotRoaming = info != null && !info.isRoaming();
    return new NetworkState(isConnected, isValidated, isMetered, isNotRoaming);
}          

实时状态: 在回调NetworkCallback或者接收到广播onReceive时,调用getActiveNetworkState得到

3.2 任务调度器

实现Scheduler接口,调度器有3个:

  • SystemJobScheduler: 使用JobSceuler来完成任务唤起;小于23版本时使用
  • SystemAlarmScheduler: 使用Alarm来完成任务唤起;大于等于23版本使用
  • GreedyScheduler:在进程内直接调用,不同android版本均会建立 其实还有一个androidx.work.impl.background.gcm.GcmScheduler,这个实现需要借助google的GCM推送服务来实现,这里用了反射(国内不支持),并且优先于SystemAlarmScheduler

调度器的创建在WorkManagerImpl类

   public List<Scheduler> createSchedulers(
            @NonNull Context context,
            @NonNull Configuration configuration,
            @NonNull TaskExecutor taskExecutor) {

        return Arrays.asList(
                Schedulers.createBestAvailableBackgroundScheduler(context, this), // 可以被系统唤起调用手段
                new GreedyScheduler(context, configuration, taskExecutor, this)); // 进程内调用手段
    }

调度器被调用的逻辑在Schedulers

public static void schedule(Configuration configuration,WorkDatabase workDatabase,List<Scheduler> schedulers) {
        if (schedulers == null || schedulers.size() == 0) {
            return;
        }
        WorkSpecDao workSpecDao = workDatabase.workSpecDao();
        List<WorkSpec> eligibleWorkSpecsForLimitedSlots;
        List<WorkSpec> allEligibleWorkSpecs;
        workDatabase.beginTransaction();
        try {
            eligibleWorkSpecsForLimitedSlots = workSpecDao.getEligibleWorkForScheduling(configuration.getMaxSchedulerLimit()); 
            allEligibleWorkSpecs = workSpecDao.getAllEligibleWorkSpecsForScheduling(MAX_GREEDY_SCHEDULER_LIMIT);

            if (eligibleWorkSpecsForLimitedSlots != null && eligibleWorkSpecsForLimitedSlots.size() > 0) {
                long now = System.currentTimeMillis();
                for (WorkSpec workSpec : eligibleWorkSpecsForLimitedSlots) {
                    workSpecDao.markWorkSpecScheduled(workSpec.id, now); // 进行插槽状态处理,非默认才会被GreedyScheduler进行调度
                }
            }
            workDatabase.setTransactionSuccessful();
        } finally {
            workDatabase.endTransaction();
        }

        if (eligibleWorkSpecsForLimitedSlots != null && eligibleWorkSpecsForLimitedSlots.size() > 0) {
            WorkSpec[] eligibleWorkSpecsArray =
                    new WorkSpec[eligibleWorkSpecsForLimitedSlots.size()];
            eligibleWorkSpecsArray =
                    eligibleWorkSpecsForLimitedSlots.toArray(eligibleWorkSpecsArray);
            for (Scheduler scheduler : schedulers) {
                if (scheduler.hasLimitedSchedulingSlots()) {
                    scheduler.schedule(eligibleWorkSpecsArray);
                }
            }
        }

        if (allEligibleWorkSpecs != null && allEligibleWorkSpecs.size() > 0) {
            WorkSpec[] enqueuedWorkSpecsArray = new WorkSpec[allEligibleWorkSpecs.size()];
            enqueuedWorkSpecsArray = allEligibleWorkSpecs.toArray(enqueuedWorkSpecsArray);
            for (Scheduler scheduler : schedulers) {
                if (!scheduler.hasLimitedSchedulingSlots()) {
                    scheduler.schedule(enqueuedWorkSpecsArray);
                }
            }
        }
    }

GreedyScheduler调度器处理任务正在排队,任务最大限制是200条;其它调度器执行在排队且未被调度器处理的,且和现在调度器已经处理的总和不超过配置中的最大限制,默认是版本23是10,其它版本20

3.2.1 GreedyScheduler调度器

类图:

通过流程分析有以下结论:

  • 延时通过DelayedWorkTracker来处理,其实是通过Handler机制处理,在主Handler中进行
  • 约束通过WorkConstraintsTracker来进行检测,通过自身实现回调WorkConstraintsCallback来处理
  • 满足执行条件的任务,通过WorkManagerImpl进行执行
  • 实现ExecutionListener接口,来检测已经完成的任务,避免重复执行
  • 必须在配置的进程中处理,默认为应用主进程

3.2.2 SystemJobScheduler调度器

类图:

  • SystemJobInfoConverter进行数据转换JobScheduler需要的入参,以及其它数据互相转换
  • SystemJobService负责调用WorkManagerImpl类方法去执行任务;以及任务执行完成的处理
  • 约束由JobScheduler自己内部进行;而这里只需要调用方法即可

这个调度器比较简单,其实现主要通过了JobScheduler的实现,JobScheduler的实现原理这里不做介绍

3.2.3 SystemAlarmScheduler调度器

这个调度器实现就比较复杂了;类图:

  • SystemAlarmService服务,任务各种情况通过启动此服务来处理
  • SystemAlarmDispatcher, 任务各种情况分发处理节点,并回传无任务处理情况,销毁服务
  • CommandHander具体处理各种intent事件,以及内部任务调度完成后收尾(实现了ExecutionListener接口,其意义却不是任务已经执行完成后的处理)
  • ConstraintsCommandHandler:处理了约束情况,使用WorkConstraintsTracker检测当时状态;事件是由*Proxy类广播启动service进而通知的, ConstraintProxyUpdateReceiver控制各种约束广播是否可用
  • Alarms,使用AlramManager机制处理任务延时,并启动服务
  • RescheduleReceiver:开机或者时间事件广播,重启动WorkManager处理剩余任务的;这里只有静态注册,非所有版本有效
  • DelayMetCommandHandler:进行约束实时更新判断,并在满足执行时通过WorkManagerImpl执行任务;在类图中没有表明其实现了WorkTimer.TimeLimitExceededListener(这个是对任务从调度状态到运行状态的一个控制,10分钟未完成状态变化重新处理)
  • 使用了PowerManager.WakeLock保证调度过程中cpu运行

3.3、任务流程

任务流程涉及调度的具体过程,在以下流程图中就会直接从Schedulers方法直接异步执行启动任务;调度过程省略;

3.3.1 enqueue流程

WorkManager调用时,均是先包装成WorkContinuationImpl然后调用其方法enqueue执行;

WorkContinuationImpl: 包含了一个链表,指向了所有依赖的WorkContinuation对象;也记录了任务本身的一些信息和流程状态

流程图

  • WorkerWrapper:handleResult方法后续是对不同结果以及任务类别,对任务数据进行相应处理;其中进行了输入数据的合并;在执行中多个关键点对取消进行校验处理
  • WorkForegroundRunnable:启动前台服务,这个需要在实现Work中提供通知信息(方法getForegroundInfoAsync);如果有加急处理,也是启动前台服务
  • ListenableWorker中,通过setProgressAsync可以设置进度数据;成功时,doWork返回的结果中含有成功数据
  • EnqueueRunnable:enqueueWorkWithPrerequisites方法中对重复任务依据策略进行了处理
  • CancelWorkRunable:iterativelyCancelWorkAndDependents删除了依赖其的任务
  • 中间大量使用SettableFuture来让各个Runnable执行等待其执行的先决条件

3.3.2 cancel流程

取消时,可以通过任务的id、name、tag或者取消所有;不管是哪种调用,都是通过标识获取满足条件的任务id集合,并进行取消;其流程也只是在id集合查询时不同而已

流程图

  • WorkWrapper进行打断时,其流程也就是任务执行时打断处理,在执行过程中多处对打断进行了检测处理
  • 取消时,对调度、执行中的任务分别进行取消;同时同步状态到数据库

4、总结

上面只是大概介绍了常规使用,以及相关类图、流程,代码细节并没有展示。代码中的一些技术点需要至少会用

  • AlarmMananger
  • JobScheduler
  • 电量低、内存不足、充电状态、网络状态检测以及实时更新
  • SettableFuture
  • ......

从代码架构上,也有需要去多思考的地方

  • 各个部分的分离抽象
  • 广播、服务组件的打开关闭、以及服务的销毁、任务执行完毕后的回调收尾等性能的考量
  • 数据库表的设计
  • 不论哪个版本,均有两个调度器去执行任务,他们有可能去处理同一个任务,这带来的复杂度处理逻辑以及优势
  • ......

以上就是Android WorkManager使用以及源码分析的详细内容,更多关于Android WorkManager的资料请关注脚本之家其它相关文章!

相关文章

最新评论