Delphi 10.2 Tokyo でのスレッド変更

Delphi 10.2 Tokyo のメインスレッド

Delphi 10.2 Tokyo の Android 向けアプリでは Delphi の UI Thread と Android の Java Native Thread の同一化が図られました。

Delphi 10.2 新機能
Android における Delphi と Java のスレッドの統一化： CallInUIThread は非推奨にすべてのコードが、Java UI スレッドで実行されており、スレッド同期の必要はなくなりました。
CheckSynchronize メソッドを呼び出すために使用される ProcessMessages メソッド。これは、Java Native スレッドからコールバックを呼び出されます。かつては、Delphi UI スレッドと Java Native スレッドの 2 つのスレッドがありました。10.2 におけるリファクタリング作業により、1 つのスレッド、Java Native スレッドにだけに絞られました。これは Android からのすべての通知を受け、それらを Delphi イベント ハンドラに転送するようになっています。while サイクルを介してブロックされる一方、イベント ハンドラは実行されず、サイクルから出てしまうことが避けられます。コールバックやイベントは一般的に、アプリケーションのメイン スレッドを保持しているコードがない場合に呼び出されます。

これによって、Android 側にアクセスする度に 一々 CallInUIThread といったヘルパ関数を通す必要が無くなりました。
UI にアクセスする場合、大変便利になったわけですが、その反面、不都合もおきます。

不都合

重たい処理

Delphi UI Thread と Java Native Thread が同一になった事で、Delphi 側でメインスレッドに対してのケアが必要になっています。
たとえば、Delphi UI Thread 内で重たい処理をすると ANR (Application Not Responding) としてアプリを落とされてしまいます。
きちんと、並列処理をしなくてはなりません。

ダイアログ

Android のダイアログは非同期化されています。

FireMonkey モーダル ダイアログ ボックスの使用
メモ： Android は、モーダル ダイアログをサポートしていません。

Berlin までは UI Thread と Java Native Thread は別だったので、Java Native Thread を動かして UI Thread 側でループして待つ、といったことができました（簡易的なモーダルダイアログ化）。
しかし、Tokyo では UI Thread = Java Native Thread なので、ループで待てません（Java Native Thread が固まる事になる）。
ここも、きちんと並列化しないといけないのはもちろん、Berlin から移行するときに気をつけなければいけないポイントとなります。

まとめ

つまり、Tokyo からは普通の Android アプリのように、きちんとスレッドによる並列化をやらないといけない、という事です。
ある意味、普通になったとも言えます。