Android アプリはすべて、メインスレッドを使用して UI オペレーションを処理しますこのメインスレッドから長時間実行オペレーションを呼び出すと、フリーズして応答しなくなる可能性があります。たとえば、アプリがメインスレッドからネットワーク リクエストを行った場合、アプリの UI はネットワーク レスポンスを受信するまでフリーズされます。Java を使用している場合は、追加のバックグラウンド スレッドを作成して、メインスレッドが UI の更新を処理しながら長時間実行オペレーションを処理できます。
このガイドでは、Java プログラミング言語を使用するデベロッパーが、スレッドプールを使用して Android アプリで複数のスレッドをセットアップして使用する方法を説明します。また、スレッドで実行するコードを定義する方法と、スレッドで実行するコードを定義する方法と、これらのスレッドのいずれかとメインスレッドとの間で通信を行う方法についても説明します。
同時実行ライブラリ
スレッド化の基本と、その基礎となるメカニズムを理解することは重要です。ただし、これらのコンセプトに対する高レベルの抽象化や、スレッド間でデータを受け渡すためのすぐに使えるユーティリティを提供する、一般的なライブラリが多数あります。これらのライブラリには、Java プログラミング言語向けの Guava と RxJava、Kotlin ユーザーに推奨されるコルーチンが含まれています。
スレッド化のルールに変更はありませんが、実際のところ、アプリと開発チームに最適な方法を選択する必要があります。
例の概要
このトピックの例では、アプリ アーキテクチャ ガイドに基づいて、ネットワーク リクエストを行い、その結果をメインスレッドに返します。これにより、アプリはその結果を画面に表示します。
具体的には、ViewModel
がメインスレッドのデータレイヤーを呼び出してネットワーク リクエストをトリガーします。データレイヤーは、ネットワーク リクエストの実行をメインスレッドから移動し、コールバックを使用して結果をメインスレッドにポストバックします。
ネットワーク リクエストの実行をメインスレッドから移動するには、アプリに他のスレッドを作成する必要があります。
複数のスレッドを作成する
スレッドプールは、キューから並列にタスクを実行するスレッドのマネージド コレクションです。既存のスレッドがアイドル状態になると、それらのスレッドで新しいタスクが実行されます。スレッドプールにタスクを送信するには、ExecutorService
インターフェースを使用します。ExecutorService
は、Android アプリ コンポーネントであるサービスとは関係ありません。
スレッドの作成にはコストがかかるため、スレッドプールの作成はアプリの初期化時に 1 回だけにしましょう。ExecutorService
のインスタンスを Application
クラスまたは依存関係インジェクション コンテナに保存してください。次の例では、バックグラウンド タスクの実行に使用できる 4 つのスレッドのスレッドプールを作成します。
public class MyApplication extends Application {
ExecutorService executorService = Executors.newFixedThreadPool(4);
}
予想されるワークロードに応じてスレッドプールを構成する方法は他にもあります。詳細については、スレッドプールの構成をご覧ください。
バックグラウンド スレッドで実行する
メインスレッドでネットワーク リクエストを送信すると、レスポンスを受信するまでスレッドは待機(ブロック)します。スレッドがブロックされるため、OS は onDraw()
を呼び出せなくなり、アプリがフリーズし、ANR(アプリケーション応答なし)ダイアログが発生する可能性があります。代わりに、このオペレーションをバックグラウンド スレッドで実行しましょう。
リクエストを行う
まず、LoginRepository
クラスを調べて、ネットワーク リクエストがどのように行われているのか確認しましょう。
// Result.java
public abstract class Result<T> {
private Result() {}
public static final class Success<T> extends Result<T> {
public T data;
public Success(T data) {
this.data = data;
}
}
public static final class Error<T> extends Result<T> {
public Exception exception;
public Error(Exception exception) {
this.exception = exception;
}
}
}
// LoginRepository.java
public class LoginRepository {
private final String loginUrl = "https://example.com/login";
private final LoginResponseParser responseParser;
public LoginRepository(LoginResponseParser responseParser) {
this.responseParser = responseParser;
}
public Result<LoginResponse> makeLoginRequest(String jsonBody) {
try {
URL url = new URL(loginUrl);
HttpURLConnection httpConnection = (HttpURLConnection) url.openConnection();
httpConnection.setRequestMethod("POST");
httpConnection.setRequestProperty("Content-Type", "application/json; charset=utf-8");
httpConnection.setRequestProperty("Accept", "application/json");
httpConnection.setDoOutput(true);
httpConnection.getOutputStream().write(jsonBody.getBytes("utf-8"));
LoginResponse loginResponse = responseParser.parse(httpConnection.getInputStream());
return new Result.Success<LoginResponse>(loginResponse);
} catch (Exception e) {
return new Result.Error<LoginResponse>(e);
}
}
}
makeLoginRequest()
は同期しており、呼び出し元のスレッドをブロックします。ネットワーク リクエストのレスポンスをモデル化するために、独自の Result
クラスが用意されています。
リクエストをトリガーする
ViewModel
は、ユーザーがボタンなどをタップしたときにネットワーク リクエストをトリガーします。
public class LoginViewModel {
private final LoginRepository loginRepository;
public LoginViewModel(LoginRepository loginRepository) {
this.loginRepository = loginRepository;
}
public void makeLoginRequest(String username, String token) {
String jsonBody = "{ username: \"" + username + "\", token: \"" + token + "\" }";
loginRepository.makeLoginRequest(jsonBody);
}
}
上のコードでは、ネットワーク リクエストを行うときに LoginViewModel
がメインスレッドをブロックしています。インスタンス化したスレッドプールを使用して、実行をバックグラウンド スレッドに移動できます。
依存関係インジェクションを処理する
まず、依存関係注入の原則に従い、LoginRepository
はコードを実行し、スレッドを管理していないので、ExecutorService
ではなく、エグゼキュータのインスタンスを取得します。
public class LoginRepository {
...
private final Executor executor;
public LoginRepository(LoginResponseParser responseParser, Executor executor) {
this.responseParser = responseParser;
this.executor = executor;
}
...
}
エグゼキュータの execute() メソッドは Runnable を受け取ります。Runnable
は run()
メソッドを持つ単一抽象メソッド(SAM)インターフェースであり、呼び出されるとスレッド内で実行されます。
バックグラウンドで実行
ではここで、実行をバックグラウンド スレッドに移動してレスポンスを無視する、makeLoginRequest()
という別の関数を作成してみます。
public class LoginRepository {
...
public void makeLoginRequest(final String jsonBody) {
executor.execute(new Runnable() {
@Override
public void run() {
Result<LoginResponse> ignoredResponse = makeSynchronousLoginRequest(jsonBody);
}
});
}
public Result<LoginResponse> makeSynchronousLoginRequest(String jsonBody) {
... // HttpURLConnection logic
}
...
}
execute()
メソッド内で、バックグラウンド スレッドで実行するコードブロック(この例では同期ネットワーク リクエスト メソッド)を含む新しい Runnable
を作成します。内部的には、ExecutorService
が Runnable
を管理し、使用可能なスレッドで実行します。
考慮事項
アプリ内のどのスレッドも、メインスレッドを含む他のスレッドと並行して実行できるため、コードがスレッドセーフであることを確認してください。この例では、スレッド間で共有される変数には書き込まず、代わりに不変のデータを渡しています。各スレッドが独自のデータ インスタンスを操作し、同期の複雑さがなくなるため、この方法をおすすめします。
スレッド間で状態を共有する必要がある場合は、ロックなどの同期メカニズムを使用して、スレッドからのアクセスに注意する必要があります。これはこのガイドの範囲外です。一般的に、スレッド間で可変状態は可能な限り共有しないようにしてください。
メインスレッドと通信する
前のステップでは、ネットワーク リクエストのレスポンスを無視しました。結果を画面に表示するには、LoginViewModel
がそれを認識している必要があります。そのためには、コールバックを使用します。
関数 makeLoginRequest()
は、非同期で値を返せるように、パラメータとしてコールバックを受け取る必要があります。結果を示すコールバックは、ネットワーク リクエストが完了するか、失敗するたびに呼び出されます。Kotlin では高階関数を使用できます。ただし、Java で同じ機能を使用するには、新しいコールバック インターフェースを作成する必要があります。
interface RepositoryCallback<T> {
void onComplete(Result<T> result);
}
public class LoginRepository {
...
public void makeLoginRequest(
final String jsonBody,
final RepositoryCallback<LoginResponse> callback
) {
executor.execute(new Runnable() {
@Override
public void run() {
try {
Result<LoginResponse> result = makeSynchronousLoginRequest(jsonBody);
callback.onComplete(result);
} catch (Exception e) {
Result<LoginResponse> errorResult = new Result.Error<>(e);
callback.onComplete(errorResult);
}
}
});
}
...
}
ViewModel
はコールバックを実装する必要があります。結果に応じて異なるロジックを実行できます。
public class LoginViewModel {
...
public void makeLoginRequest(String username, String token) {
String jsonBody = "{ username: \"" + username + "\", token: \"" + token + "\" }";
loginRepository.makeLoginRequest(jsonBody, new RepositoryCallback<LoginResponse>() {
@Override
public void onComplete(Result<LoginResponse> result) {
if (result instanceof Result.Success) {
// Happy path
} else {
// Show error in UI
}
}
});
}
}
この例では、コールバックは呼び出し元のスレッド(バックグラウンド スレッド)で実行されます。つまり、メインスレッドに戻るまで、UI レイヤを変更したり、UI レイヤと直接通信したりすることはできません。
ハンドラを使用する
Handler を使用して、別のスレッドで実行するアクションをキューに登録できます。アクションを実行するスレッドを指定するには、スレッドの Looper を使用して Handler
を作成します。Looper
は、関連するスレッドのメッセージ ループを実行するオブジェクトです。Handler
を作成したら、post(Runnable) メソッドを使用して、対応するスレッドでコードブロックを実行できます。
Looper
には、メインスレッドの Looper
を取得するヘルパー関数 getMainLooper() が含まれています。この Looper
を使用して Handler
を作成することで、メインスレッドでコードを実行できます。これは頻繁に行う作業であるため、ExecutorService
を保存した場所に Handler
のインスタンスを保存することもできます。
public class MyApplication extends Application {
ExecutorService executorService = Executors.newFixedThreadPool(4);
Handler mainThreadHandler = HandlerCompat.createAsync(Looper.getMainLooper());
}
柔軟性が高くなるため、リポジトリにハンドラを挿入することをおすすめします。たとえば、今後、別の Handler
を渡して、別のスレッドでタスクをスケジュール設定することになる可能性があります。常に同じスレッドに返信する場合は、次の例に示すように、Handler
をリポジトリ コンストラクタに渡すことができます。
public class LoginRepository {
...
private final Handler resultHandler;
public LoginRepository(LoginResponseParser responseParser, Executor executor,
Handler resultHandler) {
this.responseParser = responseParser;
this.executor = executor;
this.resultHandler = resultHandler;
}
public void makeLoginRequest(
final String jsonBody,
final RepositoryCallback<LoginResponse> callback
) {
executor.execute(new Runnable() {
@Override
public void run() {
try {
Result<LoginResponse> result = makeSynchronousLoginRequest(jsonBody);
notifyResult(result, callback);
} catch (Exception e) {
Result<LoginResponse> errorResult = new Result.Error<>(e);
notifyResult(errorResult, callback);
}
}
});
}
private void notifyResult(
final Result<LoginResponse> result,
final RepositoryCallback<LoginResponse> callback,
) {
resultHandler.post(new Runnable() {
@Override
public void run() {
callback.onComplete(result);
}
});
}
...
}
また、より柔軟性が必要な場合は、各関数に Handler
を渡します。
public class LoginRepository {
...
public void makeLoginRequest(
final String jsonBody,
final RepositoryCallback<LoginResponse> callback,
final Handler resultHandler,
) {
executor.execute(new Runnable() {
@Override
public void run() {
try {
Result<LoginResponse> result = makeSynchronousLoginRequest(jsonBody);
notifyResult(result, callback, resultHandler);
} catch (Exception e) {
Result<LoginResponse> errorResult = new Result.Error<>(e);
notifyResult(errorResult, callback, resultHandler);
}
}
});
}
private void notifyResult(
final Result<LoginResponse> result,
final RepositoryCallback<LoginResponse> callback,
final Handler resultHandler
) {
resultHandler.post(new Runnable() {
@Override
public void run() {
callback.onComplete(result);
}
});
}
}
この例で、リポジトリの makeLoginRequest
の呼び出しに渡されたコールバックは、メインスレッドで実行されます。つまり、コールバックから UI を直接変更したり、LiveData.setValue()
を使用して UI と通信したりできます。
スレッドプールを構成する
前述のサンプルコードで示したように、事前に定義された設定で Executor ヘルパー関数のいずれかを使用して、スレッドプールを作成できます。また、スレッドプールの詳細をカスタマイズする場合は、ThreadPoolExecutor を直接使用してインスタンスを作成します。次の詳細を構成できます。
- 初期と最大のプールサイズ。
- キープアライブ時間と時間単位。キープアライブ時間とは、スレッドがシャットダウンするまでにアイドル状態のままでよい最長時間です。
Runnable
タスクを保持する入力キュー。このキューは、BlockingQueue インターフェースを実装する必要があります。アプリの要件に合わせて、使用可能なキュー実装から選択できます。詳細については、ThreadPoolExecutor クラスの概要をご覧ください。
プロセッサコアの合計数、1 秒のキープアライブ時間、入力キューに基づいてスレッドプール サイズを指定する例を次に示します。
public class MyApplication extends Application {
/*
* Gets the number of available cores
* (not always the same as the maximum number of cores)
*/
private static int NUMBER_OF_CORES = Runtime.getRuntime().availableProcessors();
// Instantiates the queue of Runnables as a LinkedBlockingQueue
private final BlockingQueue<Runnable> workQueue = new LinkedBlockingQueue<Runnable>();
// Sets the amount of time an idle thread waits before terminating
private static final int KEEP_ALIVE_TIME = 1;
// Sets the Time Unit to seconds
private static final TimeUnit KEEP_ALIVE_TIME_UNIT = TimeUnit.SECONDS;
// Creates a thread pool manager
ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
NUMBER_OF_CORES, // Initial pool size
NUMBER_OF_CORES, // Max pool size
KEEP_ALIVE_TIME,
KEEP_ALIVE_TIME_UNIT,
workQueue
);
...
}