ユーザーインターフェイススレッド

リンクを編集
出典: フリー百科事典『ウィキペディア（Wikipedia）』

ユーザーインターフェイススレッド (英: user-interface thread) とは、アプリケーションソフトウェアのグラフィカルユーザーインターフェイス (GUI) におけるメインスレッドのことを指す。UIスレッドと表記されることもある。本項では、GUIでのマルチスレッドに関するデザインパターンを記載する。ユーザーインターフェイススレッドは、Javaではイベントディスパッチスレッド、Adobe Flashではprimordial workerと呼ばれる。

歴史的経緯[編集]

GUIアプリケーションにおいて、応答性を維持するためには、基本的にフレームの描画およびユーザー応答（さまざまなユーザー入力に対するアクション）はできるかぎり高いフレームレートで処理しないといけない[注釈 1]。例えば60fps (frames per second) の場合、1フレームの処理を1/60秒=約16ミリ秒以内に完了する必要がある。しかし、たとえどれほどプロセッサの性能が向上したとしても、I/O処理や画像・動画のデコード、通信接続の確立など、完了までに長時間かかってしまう処理は必ず存在する。そういったものを含めて、すべての処理を1つのスレッドだけで実行すると、長時間かかる処理を実行している間はフレーム描画やユーザー応答の処理ができないため、UIの反応がなくなってしまう（ハングアップ、フリーズ）[1][2]。長時間かかる処理の途中に、フレーム描画やユーザー応答に関わるメッセージ処理をときどき挟みながら、長時間かかる処理を少しずつ進める、という方法もあるが[3][4][5]、スマートでないうえに適用限界がある。応答性の低下を防ぐためにマルチスレッド化が必要だが、それをどのようにしてソフトウェアの構造設計に持ち込むか、ということに関して、歴史的には1980年代から色々と議論があった。

例えば、JavaのAWTでは、1996年の最初の時点では、単純にスレッド間でデータ共有型のマルチスレッドになっていた。しかし、データ共有するには、ロックをかけないといけないが、親コンポーネントから子コンポーネントを呼んだり、コールバックで子から親を呼んだり、アプリケーションからGUIライブラリを呼んだり、GUIライブラリからアプリケーションをコールバックしたりと、双方向に呼び出すことが多く、異なるスレッド間で双方向に呼び合うときは、ロックの順番に注意を払う必要がある。これはソフトウェアが非常に複雑になる原因となってしまう。また、ロック順序のミスが引き起こすデッドロックは常にではなくたまに発生したりすることの多いバグ（時間的確率要因が関与する偶発性のあるバグ）であり、バグ取りが大変になるという問題があった[6]。

そこで、1997年のJavaのSwingからは、UIの操作は全てメインのUIスレッドであるイベントディスパッチスレッドから操作しなくてはならない、というルールを設けた。そして、2006年の Java 6 から、UIスレッドで重い処理をすることを避けるために、ワーカーデザインパターン（後述）を採用した javax.swing.SwingWorker を搭載した。

現在[いつ?]では、多くのUIライブラリが、UIスレッドに操作を限定することと、ワーカーデザインパターンの組み合わせを採用している。

GUIの描画に関しては、UIスレッドが実行するケースもあれば、UIスレッドとは別の専用レンダリングスレッドが実行するケースもある[7][8]。

アプリケーションのメインスレッドは基本的にUIスレッドと同一・等価だが、特殊なケースとして、メインスレッドとUIスレッドが異なるケースもある[9][10]。

UIスレッドへの委譲[編集]

UIスレッドではないサブスレッドでの処理の進捗や完了を画面表示する場合などは、処理の途中でユーザーインターフェイス要素の操作が必要となる。そういった場面では、サブスレッドからUIスレッドに操作を依頼（委譲）することが、まず必要である。

Java[編集]

Javaの場合は、以下の方法で、UIスレッドに委譲できる。J2SE 1.3以降ではどちらもEventQueueのメソッドが呼び出される実装となっている。

同期処理は、処理が完了するまで待つ。

委譲される処理は、java.lang.Runnableインターフェイスのrun()メソッドの実装として記述する。

他のライブラリ[編集]

.NETでは処理の委譲にデリゲートが使用されることが多い。

ワーカーデザインパターン[編集]

Java[編集]

javax.swing.SwingWorker を継承して、実装できる。A→B→Cと処理が進むとき、Bが重い処理とすると、Bを SwingWorker.doInBackground() で、Cを SwingWorker.done() で処理する。

実装例： 

SwingWorker<Document, Void> worker = new SwingWorker<Document, Void>() {
    @Override
    public Document doInBackground() throws IOException {
        return loadXML(); // 重い処理
    }

    @Override
    public void done() {
        try {
            Document doc = get();
            display(doc);
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
};
worker.execute();

doInBackgound() の戻り値を done() の SwingWorker.get() で取り出せる。done() はUIスレッドで動作するが、doInBackgound() はUIスレッドとは別のスレッドで動作する。上記例では、done() の中で読み込んだ XML の表示を行う。

Groovy[編集]

上記の例を Groovy で書く場合は、groovy.swing.SwingBuilder に doLater(), doOutside(), edt() があり、下記のようによりシンプルに書ける。 

doOutside {
    def doc = loadXML() // 重い処理
    edt { display(doc) }
}

他のライブラリ[編集]

同一インスタンスのワーカーを2回以上実行したときに、それは、逐次処理するべきなのか、並列処理するべきなのかという議論があり、UIライブラリによって様々であるが、Androidにおいては、2009年9月のAndroid 1.6までは逐次処理、2009年11月のAndroid 2.0からは並列処理、2011年2月のAndroid 3.0からはデフォルトは逐次処理と、色々と変遷した[12]。並列処理にすると使うときにバグを生みやすくなると言うのが、逐次処理に戻した理由である。なお、ワーカー自体が逐次処理であっても、複数のワーカーインスタンスを作り、別々に実行すれば並列に処理できる。

Android 11以降はandroid.os.AsyncTaskは非推奨 (deprecated) となり、java.util.concurrentまたはKotlinコンカレンシーユーティリティの使用が推奨されている。

.NET言語では、TPLとコルーチンをバックエンドに利用した非同期処理の糖衣構文async/awaitも用意されている。async/awaitを使うことで、重い処理（I/Oのような完了時間が予測できない処理）はいったんサブスレッドに委譲しておき、その処理の完了を受けて後続処理を再開するようなコードを簡潔に記述できる。

タイマー[編集]

UIスレッドで呼び出されるタイマーも多くのライブラリで備わっている。

脚注[編集]

注釈[編集]

  1. ^ 必要となるフレームレートは、アプリケーションの用途やモニターのリフレッシュレートなどの環境によっても異なる。VRでは120fpsなど、さらに高いフレームレートが要求される。
  2. ^ WinRTにおける同期版のCoreDispatcher.Invoke()メソッドはWindows 8プレビュー版で実装されていたものの、最終的に製品版では削除された[11]。
  3. ^ Looper.getMainLooper()で得たLooperを使って作成したHandlerのpost(Runnable)などを利用することもできる。

出典[編集]

  1. ^ Preventing Hangs in Windows Applications - Win32 apps | Microsoft Docs
  2. ^ アプリの応答性を維持する | Android デベロッパー | Android Developers
  3. ^ Idle Loop Processing | Microsoft Docs
  4. ^ DoEvents function (Visual Basic for Applications) | Microsoft Docs
  5. ^ Application.DoEvents Method (System.Windows.Forms) | Microsoft Docs
  6. ^ Multithreaded toolkits: A failed dream?
  7. ^ スレッド モデル - WPF .NET Framework | Microsoft Docs
  8. ^ UI スレッドの応答性の確保 - UWP applications | Microsoft Docs
  9. ^ プロセスとスレッドの概要 | Android デベロッパー | Android Developers
  10. ^ アノテーションによるコード検査の改善 | Android デベロッパー | Android Developers
  11. ^ Fixing CoreDispatcher.Invoke – How to Invoke Method in UI Thread in Windows 8 Release Preview - Mikael Koskinen
  12. ^ AsyncTask | Android Developers

関連項目[編集]

外部リンク[編集]

「https://ja.wikipedia.org/w/index.php?title=ユーザーインターフェイススレッド&oldid=87985194」から取得