2023年5月15日月曜日

[android]app背景處理 with WorkManager

最近開始接觸android 13版之後，發現背景服務已經不能長存了。

總是app退到背景兩分鐘之後，service就會被系統砍掉。不管是不是用start_sticky標記。

android 8~11，使用setforeground的方式處理，已經讓開發者們怨聲載道了。（service啟動之後要在10秒內進行系統提醒channel的建立跟提醒的發送。） 

然後2021年出現了官方的解決方案：WorkManager。當時覺得還能動，剛出現的模組也不一定穩定，就沒留意。

但是現在不同了，service在app退到背景2分鐘之後就被砍了... 只能面對。所以又花了時間處理這部分。實際上沒那麼好解決，幾個要素交互影響不說，也需要測試裝置深眠狀態的反應。
寫下實作的方式，跟處理問題的時候遇到的狀況。有興趣可以參考。

能夠讓app盡可能啟動背景運作的方式

  • Google Cloud Messaging(以下簡稱「GCM」)：假如有架伺服器的話，建議實作。這是權限相當高的動作，有能力啟動app的前景動作。
    要注意的是，GCM在android 12以後(不是很確定版本)不能使app在背景狀態之下啟動前景服務。就算是採用送Broadcast, 經由app在Manifest宣告的BroadcastReceiver觸發的方式，都會送你不能在背景狀態啟動前景服務的例外。
    那這樣不就廢了！？Orz
    目前的解決方案是導入「WorkManager」。
    上面有寫到，GCM有能力啟動app的前景服務。在實驗時發現app在背景狀態，甚至是裝置休眠狀態，裝置收到GCM訊息的當下，Worker會被喚起執行。這樣就有機會實作不容易被中斷的處理了。
  • WorkManager：本文的內容。在Service接近殘廢之後，目前的背景執行解決方案。
    可惜WorkManager也有缺點。因為是背景執行緒，在doWork()裡面不能執行必須在主執行序運作的動作。像是Lifecycle.addObserver，Livedata.addObserver等等...


決定要怎麼使用

基本的使用流程：

  1. 導入模組
  2. 撰寫Worker，定義執行內容
  3. 以Worker建立WorkRequest
  4. 把WorkRequest放進WorkManager  

詳細內容請參考官方文件：

https://developer.android.com/guide/background/persistent/getting-started

 

撰寫Worker

Worker分成兩種：

  • ListenableWorker：可以定義ListenableFuture，取得Worker的執行狀況。預設是在主執行緒執行。要在背景執行緒執行，需要做一些深入調整（主要是在AndroidManifest移除ListenableWorker預設的初始化工具，自行定義Configuration，指定executer為背景執行緒）。本文不研究這部分。
  • Worker：ListenableWorker的子class。預設在背景執行緒執行。缺點是除了模組提供的WorkInfo之外，沒有獲取執行狀況的方法。當然是可以用static singletone的方式暴力處理...

 

建立WorkRequest

WorkRequest有兩種：

  • OneTimeWorkRequest：只執行一次。若是在worker執行完畢回傳Result.Retry();，就會重試。重試的動作間隔是backoff的設計，可以定義linear（固定重試間隔） / exponential（指數增加間隔）
  • PeriodicWorkRequest：可以定義重複的間隔時間（固定間隔，跟每次執行可以跑多久）。最低的重複間隔是15分鐘... 相信有人會覺得不太合用...

WorkRequest可定義setExpedited(...)，代表很重要，系統會儘快執行。會多快並不確定，筆者測試是毫秒等級，夠用了。
可使用constraint限制運作條件（例如是不是連網路，是不是在充電等等）。同時限制多個運作條件，就只有在條件同時滿足的時候才會執行。

 

依worker的管理方式區分

  • UniqueWork：指定一個字串id方便管理。要取代或是維持WorkRequest都使用這個字串做處理。
  • 非UniqueWork：還是可以使用取得WorkInfo的時候，回傳的uuid做處理。只是管理上相對麻煩。如何取得WorkInfo後面會介紹。
  • tag： WorkRequest可以定義tag，這樣在使用workManager.getInfosByTag(...)取得Workinfo的時候，可以用tag來取得同一個tag的所有workRequest的執行狀況。


依照需執行的動作的性質決定。本文只討論UniqueWork，大部分的場景已夠用。

建立Worker的例子：

public class MyWorker extends Worker
{
    Context context;
    // Worker的constructor會提供context。
    public MyWorker(
        Context context,
        WorkerParameters params)
    {
        super(context, params);
        this.context = context;
    }


    @Override
    @NonNull
    public Result doWork()
    {
        try
        {
            setForegroundAsync(getForegroundInfo());
        } catch (Exception e)
        {
            e.printStackTrace();
        }
        ...
    }
    @Override
    @NonNull
    public ForegroundInfo getForegroundInfo()
    {

        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O)
        {
            createChannel();
        }

        Log.d(TAG, "getForegroundInfo");


        String NOTIFICATION_CHANNEL_ID = context.getPackageName();
        NotificationCompat.Builder notificationBuilder = new NotificationCompat.Builder(context, NOTIFICATION_CHANNEL_ID);
        Notification notification = notificationBuilder.setOngoing(true)
            .setSmallIcon(R.drawable.app_logo)
            .setContentTitle("背景執行中")
            .setPriority(NotificationManager.IMPORTANCE_MIN)
            .setCategory(Notification.CATEGORY_SERVICE)
            .build();

        return new ForegroundInfo(0, notification);
    }
    
    @RequiresApi(Build.VERSION_CODES.O)
    private void createChannel()
    {
    // Create a Notification channel
        String NOTIFICATION_CHANNEL_ID = context.getPackageName();
        String channelName = context.getResources().getString("背景執行中");
        NotificationChannel chan = new NotificationChannel(NOTIFICATION_CHANNEL_ID, channelName, NotificationManager.IMPORTANCE_NONE);
        chan.setLightColor(Color.BLUE);
        chan.setLockscreenVisibility(Notification.VISIBILITY_PRIVATE);
        assert notificationManager != null;
        notificationManager.createNotificationChannel(chan);
    }
}
 

建立OneTimeWorkRequest的例子：

OneTimeWorkRequest myWorkRequest = new OneTimeWorkRequest.Builder(MyWorker.class)
    .setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST).build();

把WorkRequest加入WorkManager的例子：

WorkManager workManager = WorkManager.getInstance(context); 
WorkContinuation wc = workManager.beginUniqueWork("myService", ExistingWorkPolicy.REPLACE, myWorkRequest);
wc.enqueue();

取得workManager必須有context。

 

注意點：

  • 每次Worker執行完畢，不管結果是成功，取消，或是重試，下一次的Worker執行都會重新建立一個新的Worker。也就是worker的constructor會被執行。
  • 針對android 11以前的版本的相容性，也就是那個惡名昭彰的「啟動前景服務，10秒內沒有發送系統通知的話，就會直接送你RuntimeException」的規格，
    Worker必須定義「getForegroundInfo(ForegroundInfo)」。
    實作範例請參考 「Support for long-running workers」裡面的實作方式。上面的程式碼也有概略的寫法。
  • 另外，若是要讓Worker長時間執行，建議下指令「setForegroundAsync(getForegroundInfo(progress));」
  • 針對android 12以後的狀況，「setForegroundAsync(getForegroundInfo(progress));」建議使用try / catch包覆，因為有可能會失敗。
    雖然官方Worker模組的2.7版（目前最新版是2.8.1）文件載明「setForegroundAsync()已經棄用」，還是建議寫一下，增加相容性。
  • android官方文件的「Support for long-running workers」裡面的範例程式碼，定義了「private createForegroundInfo()」。雖然這樣不算有問題，不過跟必須定義「getForegroundInfo()」的限制有落差。
    直接定義 「getForegroundInfo()」，然後範例內的
    「setForegroundAsync(createForegroundInfo(progress));」
    改為
    「setForegroundAsync(getForegroundInfo(progress));」
    就ok。

 

 如何取得WorkRequest的Workinfo (uuid，運作狀態等等)

  • 有定義UniqueWork id，可以用專有函式：ListenableFuture< List<WorkInfo> > lf = workManager.getWorkInfosForUniqueWork("myService");
  • 執行workManager.beginUniqueWork之後，以workContinuation.getWorkInfos()取得。以下為範例：
    WorkContinuation workContinuation = workManager.beginUniqueWork("myService", ExistingWorkPolicy.REPLACE, myWorkRequest);
    ListenableFuture< List<WorkInfo> > lf = workContinuation.getWorkInfos();
     

應該有發現取得workinfo的動作，回傳大都是List。這是因為使用WorkManager加入單一或是定時重複work之後，回傳的是「WorkContinuation」結構。前面的範例是直接workContinuation.enqueue()，因為只有一個work要做。

WorkRequest是允許連續動作的。可以設計其他的OneTimeWorkRequest，然後使用workContinuation.then(oneTimeWorkRequest)加入。等到全部都設定完之後，使用wc.getWorkInfos()，回傳的就是整串的workinfo。

這時進行workContinuation.enqueue()加入WorkManager，就可以循序執行一連串的work。
WorkRequest的chaining就不討論了。


 

 

 

投稿者 時刻:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)