從Service到WorkManager
前言
關(guān)于Service，想必大家都太熟悉了，今天我們就再回顧下它的使用、概念、區(qū)別、變更歷史等等。
概念和使用
Service 是一種可在后臺執(zhí)行長時間運行操作而不提供界面的應(yīng)用組件
兩種啟動方式：
- startService() 生命周期為：onCreate() -> onStartCommand() -> onDestory()
- bindService() 生命周期為：onCreate() -> onBind() -> onUnBind() -> onDestory()
其中要注意的是onStartCommand方法的返回值，有三種常量：
1) START_NOT_STICKY，終止服務(wù)后，除非除非有待傳遞的掛起 Intent，否則系統(tǒng)不會重建服務(wù)。
2) START_STICKY，終止服務(wù)后，會自動重新服務(wù)并調(diào)用 onStartCommand()，但不會重新傳遞最后一個 Intent。
3) START_REDELIVER_INTENT，終止服務(wù)后，會重建服務(wù)，并通過傳遞給服務(wù)的最后一個 Intent 調(diào)用 onStartCommand()。
當(dāng)然，最后要使用的話還要在清單文件中注冊：
- <service android:enabled=["true" | "false"]
- android:exported=["true" | "false"]
- android:icon="drawable resource"
- android:isolatedProcess=["true" | "false"]
- android:label="string resource"
- android:name="string"
- android:permission="string"
- android:process="string" >
- . . .
- </service>
Service與子線程
關(guān)于Service，我的第一反應(yīng)是運行在后臺的服務(wù)。
關(guān)于后臺，我的第一反應(yīng)又是子線程。
那么Service和子線程到底是什么關(guān)系呢?
Service有兩個比較重要的元素：
- 長時間運行。Service可以在Activity被銷毀，程序被關(guān)閉之后都可以繼續(xù)運行。
- 不提供界面的應(yīng)用組件。這其實解釋了后臺的意義，Service的后臺指的是不和界面交互，不依賴UI元素。
而且比較關(guān)鍵的點是，Service也是運行在主線程之中。
所以運行在后臺的Service和運行在后臺的線程區(qū)別還是挺大的。
- 首先，所運行的線程不同。Service還是運行在主線程，而子線程肯定是開辟了新的線程。
- 其次，后臺的概念不同。Service的后臺指的是不與界面交互，子線程的后臺指的是異步運行。
- 最后，Service作為四大組件之一，控制它也更方便，只要有上下文就可以對其進行控制。
當(dāng)然，雖然兩者概念不同，但是還是有很多合作之處。
Service作為后臺運行的組件，其實很多時候也會被用來做耗時操作，那運行在主線程的Service肯定不能直接進行耗時操作，這就需要子線程了。
開啟一個后臺Service，然后在Service里面進行子線程操作，這樣的結(jié)合給項目帶來的可能性就更大了。
Google也是考慮到這一點，設(shè)計出了IntentService這種已經(jīng)結(jié)合好的組件供我們使用。
IntentService
IntentService 是一個繼承自Service，自帶工作線程和Handler，并且線程任務(wù)結(jié)束后自動銷毀的一個類。
源碼很簡單：
- @Override
- public void onCreate() {
- super.onCreate();
- //創(chuàng)建新線程并start
- HandlerThread thread = new HandlerThread("IntentService[" + mName + "]");
- thread.start();
- mServiceLooper = thread.getLooper();
- //創(chuàng)建新線程對應(yīng)的handler
- mServiceHandler = new ServiceHandler(mServiceLooper);
- }
- @Override
- public void onStart(@Nullable Intent intent, int startId) {
- //service啟動后發(fā)送消息給handler
- Message msg = mServiceHandler.obtainMessage();
- msg.arg1 = startId;
- msg.obj = intent;
- mServiceHandler.sendMessage(msg);
- }
- private final class ServiceHandler extends Handler {
- public ServiceHandler(Looper looper) {
- super(looper);
- }
- @Override
- public void handleMessage(Message msg) {
- //handler收到消息后調(diào)用onHandleIntent方法
- onHandleIntent((Intent)msg.obj);
- stopSelf(msg.arg1);
- }
- }
弊端
之前也說了，Service這些特性確實給了我們更多的可能性，我們可以在后臺靜默下載項目需要的東西、可以發(fā)心跳包、可以處理一些數(shù)據(jù)。
但是，也正是因為后臺無感知的特性，也帶來了隱私方面的隱患和弊端。
App可以在后臺操作用戶數(shù)據(jù)，下載應(yīng)用無關(guān)的文件等等。
所以Google為了保護用戶隱私，在Android8.0開始，限制了后臺Service。
后臺和前臺Service
這就涉及到Service的分類了。
如果從是否無感知來分類，Service可以分為前臺和后臺。前臺Service會通過通知的方式讓用戶感知到，后臺有這么一個玩意在運行。
比如音樂類APP，在后臺播放音樂的同時，可以發(fā)現(xiàn)始終有一個通知顯示在前臺，讓用戶知道，后臺有一個這么音樂相關(guān)的服務(wù)。
在Android8.0，Google要求如果程序在后臺，那么就不能創(chuàng)建后臺服務(wù)，已經(jīng)開啟的后臺服務(wù)會在一定時間后被停止。
所以，建議使用前臺Service，它擁有更高的優(yōu)先級，不易被銷毀。使用方法如下：
- startForegroundService(intent);
- public void onCreate() {
- super.onCreate();
- Notification notification = new Notification.Builder(this)
- .setChannelId(CHANNEL_ID)
- .setContentTitle("主服務(wù)")//標(biāo)題
- .setContentText("運行中...")//內(nèi)容
- .setSmallIcon(R.mipmap.ic_launcher)
- .build();
- startForeground(1,notification);
- }
- <!--android 9.0上使用前臺服務(wù)，需要添加權(quán)限-->
- <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
那后臺任務(wù)該怎么辦呢?官方建議使用 JobScheduler 。
JobScheduler
任務(wù)調(diào)度JobScheduler，Android5.0被推出。(可能有的朋友感覺比較陌生，其實他也是通過Service實現(xiàn)的，這個待會再說)
它能做的工作就是可以在你所規(guī)定的要求下進行自動任務(wù)執(zhí)行。比如規(guī)定時間、網(wǎng)絡(luò)為WIFI情況、設(shè)備空閑、充電時等各種情況下后臺自動運行。
所以Google讓它來替代后臺Service的一部分功能，使用：
首先，創(chuàng)建一個JobService：
- public class MyJobService extends JobService {
- @Override
- public boolean onStartJob(JobParameters params) {
- return false;
- }
- @Override
- public boolean onStopJob(JobParameters params) {
- return false;
- }
- }
然后，注冊這個服務(wù)(因為JobService也是Service)
- <service android:name=".MyJobService"
- android:permission="android.permission.BIND_JOB_SERVICE" />
最后，創(chuàng)建一個JobInfo并執(zhí)行
- JobScheduler scheduler = (JobScheduler) getSystemService(Context.JOB_SCHEDULER_SERVICE);
- ComponentName jobService = new ComponentName(this, MyJobService.class);
- JobInfo jobInfo = new JobInfo.Builder(ID, jobService)
- .setMinimumLatency(5000)// 任務(wù)最少延遲時間
- .setOverrideDeadline(60000)// 任務(wù)deadline，當(dāng)?shù)狡跊]達到指定條件也會開始執(zhí)行
- .setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED)// 網(wǎng)絡(luò)條件，默認(rèn)值NETWORK_TYPE_NONE
- .setRequiresCharging(true)// 是否充電
- .setRequiresDeviceIdle(false)// 設(shè)備是否空閑
- .setPersisted(true) //設(shè)備重啟后是否繼續(xù)執(zhí)行
- .setBackoffCriteria(3000，JobInfo.BACKOFF_POLICY_LINEAR) //設(shè)置退避/重試策略
- .build();
- scheduler.schedule(jobInfo);
簡單說下原理：
JobSchedulerService是在SystemServer中啟動的服務(wù)，然后會遍歷沒有完成的任務(wù)，通過Binder找到對應(yīng)的JobService，執(zhí)行onStartJob方法，完成任務(wù)。具體可以看看參考鏈接的分析。
所以也就知道了，在5.0之后，如果有需要后臺任務(wù)執(zhí)行，特別是需要滿足一定條件觸發(fā)的任務(wù)，比如網(wǎng)絡(luò)電量等等情況，就可以使用JobScheduler。
有的人可能要問了，5.0之前怎么辦呢?
可以使用GcmNetworkManager或者BroadcastReceiver等處理部分情況下的任務(wù)需求。
Google也是考慮到了這一點，所以將5.0之后的JobScheduler和5.0之前的GcmNetworkManager、GcmNetworkManager、AlarmManager等和任務(wù)相關(guān)的API相結(jié)合，設(shè)計出了WorkManager。
WorkManager
WorkManager 是一個 API，可供您輕松調(diào)度那些即使在退出應(yīng)用或重啟設(shè)備后仍應(yīng)運行的可延期異步任務(wù)。
作為Jetpack的一員，并不算很新的內(nèi)容，它的本質(zhì)就是結(jié)合已有的任務(wù)調(diào)度相關(guān)的API，然后根據(jù)版本需求等來執(zhí)行這些任務(wù)，官網(wǎng)有一張圖：
所以WorkManager到底能做什么呢?
- 1、對于一些任務(wù)約束能很好的執(zhí)行，比如網(wǎng)絡(luò)、設(shè)備空閑狀態(tài)、足夠存儲空間等條件下需要執(zhí)行的任務(wù)。
- 2、可以重復(fù)、一次性、穩(wěn)定的執(zhí)行任務(wù)。包括在設(shè)備重啟之后都能繼續(xù)任務(wù)。
- 3、可以定義不同工作任務(wù)的銜接關(guān)系。比如設(shè)定一個任務(wù)接著一個任務(wù)。
總之，它是后臺執(zhí)行任務(wù)的一大利器。
參考
https://developer.android.google.cn/guide/components/services#Lifecycle
http://gityuan.com/2017/03/10/job_scheduler_service/
本文轉(zhuǎn)載自微信公眾號「碼上積木」，作者碼上積木。轉(zhuǎn)載本文請聯(lián)系碼上積木公眾號。
