android.os.AsyncTaskの正しい使い方

メディアチーム

android.os.AsyncTaskの正しい使い方

メディアチーム

2019.07.08

IT技術

AsyncTaskについて思うこと

Androidアプリ開発が、一般に広く普及してから「約10年」ほどが経ちました。

数々のリファレンスが生まれては、内容が古いまま残されている記事が散見されるようになってきました。

そんな中で、このタイトルにある "AsyncTask"という非同期処理用クラス をとてもよく見かけます。

APIレベル3以降から使われている非同期処理を担当するクラスの代表で、2019年6月段階では特別にgradleファイルを編集して別途ライブラリを追加する必要がないため、「下手にアプリサイズを増やさず、簡単に実装しやすい」という印象を持ちます。

今でこそRxJavaやRxKotlin、Android Architecture Componentsに提唱されるLiveData、最近正式採用化されたcoroutinesに取って代わることも多いようです。

しかし、古くから存在するようなActivityやFragmentには、未だに存在し、かつ、昔のノウハウのまま実装されてしまっているものを時折現場で見かけます。

ここでは、筆者が個人的に開発・リリース・運用を続けているTwitterクライアントを例に、AsyncTaskについて再考していきます。

AsyncTaskの「良い点」と「悪い点」

AsyncTaskの良い点

導入が楽、かつ学習コストが低い（古くからリファレンスが存在するため）
Rxやcoroutinesなどのようにライブラリを追加することなく、AndroidSDKが標準で提供してくれている
処理時間がそんなにかからない非同期処理などに使いやすい
使い方さえ間違わなければ手軽

AsyncTaskの良くないところ

"This AsyncTask class should be static or leaks might occur” 警告を起こしがち
ActivityやFragmentなどの画面から呼ばれる事例が多い
ActivityやFragmentが死んで(onDestroy)もAsyncTaskが生きたままになり、GCされずメモリリークが起きる
しかもAsyncTask内でTextViewなどのViewのUIを操作するというアンチパターンなリファレンスが多い
画面回転時などIllegal State Exceptionが起きる（Activityの再生成が行われてAsyncTaskが行き場を失い起きる）

警告について

AsyncTaskを実装したコードをAndroid Studioで開いた場合、下記のような警告が出ていることがあります。

1This AsyncTask class should be static or leaks might occur...

どのようなコードで上記の警告が出るかというと…

1class TimeLineFragment() : ListFragment() {
2    private var isSwipeRefresh = false
3    private var mSwipeRefreshLayout: SwipeRefreshLayout? = null
4
5    //(中略)
6
7    fun getHomeTimeLineTweet() {
8        val paging = Paging()
9        paging.count = GET_MENTION_TWEET_NUM
10
11        val task = object : AsyncTask<Void, Void, List<Status>>() {
12            override fun onPreExecute() {
13
14            }
15
16            override fun doInBackground(vararg params: Void): List<twitter4j.Status>? {
17                try {
18                    return twitter!!.getMentionsTimeline(paging)
19                } catch (e: TwitterException) {
20                    e.printStackTrace()
21                }
22
23                return null
24            }
25
26            override fun onPostExecute(result: List<twitter4j.Status>?) {
27                if (result != null) {
28                    mAdapter!!.clear()
29                    for (status in result) {
30                        mAdapter!!.add(status)
31                    }
32                } else {
33                    showToast(getString(R.string.failed_to_load_timeline))
34                }
35                //くるくる消す
36                mSwipeRefreshLayout!!.clearAnimation() // ここでUIの操作が行われている
37                mSwipeRefreshLayout!!.isRefreshing = false
38            }
39        }
40        task.execute()
41    }

このように、AsyncTaskを匿名クラスとして利用し、なおかつ内部でUIに対する変更を加えている場合に起こります。

この場合、Fragment（あるいはActivity）が破棄されしまっても、AsyncTaskが生き残ってしまった場合に、UI部品（ここではSwipeRefreshLayout）への参照が残ったままとなり、メモリリークを起こす可能性があります。

非同期タスクは、あくまでも裏側で実行されていて、処理の完了には時間がかかることが想定されています。

処理が完了する前にUIコンポーネントが不要になり破棄する必要がある状況になると、本来はUIオブジェクトを破棄するべきところなのに非同期タスクが参照を握っているために破棄されない…といった事が起こります。

つまり、UIリソースが解放できなくなります。

こういったコードはどのように修正すればいいのでしょうか？

AsyncTaskのポイントまとめ

ポイントを一旦下記にまとめます

AsyncTaskをnon-staticな内部的なクラスにせず、inner classにするか、別クラスにする
WeakReferenceを利用する　←ここが重要！
RefreshCallBackインターフェイスを準備する
APIの取得・更新処理などが終わった時にUI側に結果を返す時に用いる

コードの修正

まず、AsyncTaskをディレクトリごと切ります。

パッケージ右クリック → New → Package

今回は、そのパッケージ名を「asynctask」とします。

そのディレクトリで、New → Kotlin File/Classを選択（Javaで開発されている方は以下より.javaに置き換えてください）

たとえば、ホーム・タイムラインを取得するためのクラスであれば「GetHomeTimeLineAsyncTask」と命名して保存。

1GetHomeTimeLineAsyncTask.kt
2class GetHomeTimeLineAsyncTask(var twitter: Twitter, var paging: Paging, refreshCallback: RefreshCallback) : AsyncTask<Void, List<Status>?, List<Status>?>() {
3
4    private val refreshCallbackReference: WeakReference<RefreshCallback> = WeakReference(refreshCallback)
5
6    override fun doInBackground(vararg params: Void?): List<twitter4j.Status>? {
7        try {
8            val timeline = twitter.getHomeTimeline(paging)
9            // publishProgressを呼ばないとonProgressUpdateは呼ばれないみたい
10            publishProgress(timeline)
11            return timeline
12        } catch (e: TwitterException) {
13            e.printStackTrace()
14        }
15        return listOf()
16    }
17}

AsyncTaskの継承は、doInBackgroundメソッドさえ継承していればOKです。

ポイントとなるのは

1private val refreshCallbackReference: WeakReference<RefreshCallback> = WeakReference(refreshCallback)

RefreshCallBack、これはインターフェイス(interface)として作ります。

このJavaが、最初から持つWeakReferenceが重要です。

1RefreshCallBack.kt
2interface RefreshCallback {
3    fun addListItem(statusList : List<twitter4j.Status>?)
4    fun refreshCompleted()
5    fun progressUpdate(progress: List<twitter4j.Status>?)
6}

twitter4jを利用しているので、twitter4jをデータモデルと捉えてください。

このRefreshCallBackを利用してFragmentへ参照を返します。

1TimeLineFragment.kt
2class TimeLineFragment() : Fragment(),
3        SwipeRefreshLayout.OnRefreshListener,
4        RefreshCallback { // RefreshCallBackを実装
5
6        // 略
7
8    /*
9     * @return List<Status>?
10     * タイムラインを取得し、callbackに返す
11     */
12    fun reloadTimeLine() {
13        val paging = Paging()
14        paging.count = 200
15        GetHomeTimeLineAsyncTask(twitter, paging, this).execute()
16    }
17
18
19}

あとは、呼び出し元となるTimeLineFragmentにてRefreshCallbackインターフェイスの下記3メソッドを経由して、UIの更新処理などを行います。

1/*
2 * RefreshCallBack#addListItem
3 * GetHomeTimeLineAsyncTaskのonPostExecuteがなされた時に呼ばれる
4 */
5override fun addListItem(statusList: List<Status>?) {
6    timeLine = statusList
7    timeLine?.let {
8        if (it.isEmpty()) {
9            Snackbar.make(view!!, getString(R.string.failed_to_load_timeline), Snackbar.LENGTH_SHORT).show()
10        }
11    }
12}
13
14/**
15 * RefreshCallBack#refreshCompleted
16 * 非同期タスクが終了したらする動き
17 * GetHomeTimeLineAsyncTaskのonPostExecuteがなされた時に呼ばれる
18 */
19override fun refreshCompleted() {
20    recyclerTweetViewAdapter = TweetAdapter(activity!!.applicationContext, timeLine)
21    recyclerView.apply {
22        adapter = recyclerTweetViewAdapter
23        adapter?.notifyDataSetChanged()
24        mProgressBar.visibility = ProgressBar.INVISIBLE
25    }
26    mSwipeRefreshLayout.isRefreshing = false
27}
28
29/**
30 * RefreshCallBack#progressUpdate
31 * 非同期タスクが進行中の時
32 * GetHomeTimeLineAsyncTask#onProgressUpdate(vararg values: Int?)
33 */
34override fun progressUpdate(progress: List<Status>?) {
35    progress?.forEach {
36        mProgressBar.progress++
37    }
38}
39
40/**
41 * swipeRefresh
42 **/
43override fun onRefresh() {
44    mProgressBar.visibility = ProgressBar.VISIBLE
45    reloadTimeLine()
46}

※onRefreshメソッドに関してはSwipeRefreshを使う上で実装しています。

WeakReferenceを経由して参照を渡すことで、非同期タスクがUIリソースの解放を遮らないようにします。

最終的なAsyncTask

最終的にAsyncTaskは、以下のようになります

1class GetHomeTimeLineAsyncTask(var twitter: Twitter, var paging: Paging, refreshCallback: RefreshCallback) : AsyncTask<Void, List<Status>?, List<Status>?>() {
2
3    private val refreshCallbackReference: WeakReference<RefreshCallback> = WeakReference(refreshCallback)
4
5    override fun doInBackground(vararg params: Void?): List<twitter4j.Status>? {
6        try {
7            val timeline = twitter.getHomeTimeline(paging)
8            // publishProgressを呼ばないとonProgressUpdateは呼ばれない
9            publishProgress(timeline)
10            return timeline
11        } catch (e: TwitterException) {
12            e.printStackTrace()
13        }
14        return listOf()
15    }
16
17    override fun onPostExecute(result: List<twitter4j.Status>?) {
18        super.onPostExecute(result)
19        val callBack = this.refreshCallbackReference.get()
20        callBack?.let {
21            it.addListItem(result)
22            it.refreshCompleted()
23        }
24    }
25
26    override fun onProgressUpdate(vararg values: List<twitter4j.Status>?) {
27        val callback = this.refreshCallbackReference.get()
28        callback?.let {
29
30            values[0]?.let { it1 -> it.progressUpdate(it1) }
31        }
32    }
33}

AsyncTaskでよく使うメソッド

個人的にAsyncTaskでよく使うメソッドは上記で書いた

doInBackground（必須の継承メソッド）
onPostExecute（オプショナルだがよく使うメソッド）
onProgressUpdate（オプショナルだがよく使うメソッド2）

となります。

onProgressUpdateに関してはアプリのユーザーにデータの読み込み情報を表示するProgressBarなどの表示のためによく使います。

また、onProgressUpdateメソッドは、doInBackgroundメソッドでpublishProgressメソッドを呼ぶ必要がある点も注意しましょう。

AsyncTaskの使い方まとめ

AsyncTask を使うなら WeakReference と CallBackインターフェイスを介することでメモリリークを防ぐ
AsyncTask#onProgressUpdate が動作するには AsyncTask#doInBackground で pubishProgress() を呼ぶ必要がある
呼び出し元の Fragment では RefreshCallBack を介して、UIの処理を行えば良い

これらの対応により、メモリリークの危険性は低減され、見通しの良いコードが出来上がるはずです。

1This AsyncTask class should be static or leaks might occur...

筆者自身、よく見かけるAndroid Studioからの警告もこのようにして撲滅できました。

古くから動くAndroidアプリの保守開発を行っている皆様、もしAsyncTaskが存在してAndroid Studioから警告されている場合は上記の対応で修正を試みてはいかがでしょうか？

こちらの記事もオススメ！

2020.08.14スマホ技術特集Android開発Android開発をJavaからKotlinへ変えていくためのお勉強DelegatedPropert...

2020.07.17ライトコード的「やってみた！」シリーズ「やってみた！」を集めました！（株）ライトコードが今まで作ってきた「やってみた！」記事を集めてみました！※作成日が新し...

ITフリーランスのエンジニア専門エージェント

技術力で世の中をもっと面白くエンジニア積極採用中！

ライトコードでは、エンジニアを積極採用中！

ライトコードでは、エンジニアを積極採用しています！社長と一杯しながらお話しする機会もご用意しております。そのほかカジュアル面談等もございますので、くわしくは採用情報をご確認ください。

採用情報へ

メディアチーム

「好きを仕事にするエンジニア集団」の（株）ライトコードです！ライトコードは、福岡、東京、大阪、名古屋の４拠点で事業展開するIT企業です。現在は、国内を代表する大手IT企業を取引先にもち、ITシステムの受託事業が中心。いずれも直取引で、月間PV数1億を超えるWebサービスのシステム開発・運営、インフラの構築・運用に携わっています。システム開発依頼・お見積もり大歓迎！また、現在「WEBエンジニア」「モバイルエンジニア」「営業」「WEBデザイナー」を積極採用中です！インターンや新卒採用も行っております。以下よりご応募をお待ちしております！ https://rightcode.co.jp/recruit