OK、まず第一に、あなたがやっているようにビジーループで遅延を実装しないでください. 私はそれがどこから来たのかを見ることができます - Palm Pilot は組み込みの sleep() 関数を持たない単一プロセスのデバイスだったと推測していますが、マルチプロセス デバイスでは、そのようなビジー ループは単に全体をもたらします。プロセッサーをひざまずかせます。バッテリーが消耗し、通常のシステム タスクが正常に実行されなくなり、他のプログラムの速度が低下したり、完全に停止したり、デバイスが応答しなくなったり、手が熱くなったりすることさえあります。
探している呼び出しは Thread.sleep() です。スリープ中に発生する割り込み例外をキャッチするように設定する必要があります。
第 2 に、Android (またはほとんどすべての最新の GUI システム) などのイベントベースのユーザー インターフェイスでは、UI スレッドでスリープ状態になりたくありません。また、他の投稿者が言及しているように、デバイス全体がフリーズし、ANR (Activity Not Responding) クラッシュが発生します。最も重要なことは、これらの小さなフリーズがユーザー エクスペリエンスを完全に台無しにすることです。
(例外: ユーザーがおそらく気付かないほど短い間隔でスリープしている場合は、それを回避できます。1/4 秒はおそらく問題ありませんが、状況によってはアプリケーションが不安定になる可能性があります。)
残念ながら、ループ ベースのアプリケーションをイベント ベースのシステムに移植する場合、目的を達成するためのクリーンで洗練された方法はありません。
つまり、適切な手順は、UI スレッドでハンドラーを作成し、それに遅延メッセージを送信することです。遅延メッセージはアプリケーションを「起動」し、遅延後に実行しようとしていたことを実行するようにトリガーします。
このようなもの:
View gameBoard; // the view containing the main part of the game
int gameState = 0; // starting
Handler myHandler;
public void onCreate(Bundle oldState) {
super.onCreate(oldState);
...
gameBoard = findViewById(R.layout.gameboard);
myHandler = new Handler();
...
}
public void onResume() {
super.onResume();
displayStartingScreen();
myHandler.postDelayed(new Runnable() {
gotoState1();
}, 250);
}
private void gotoState1() {
// It's now 1/4 second since onResume() was called
displayNextScreen();
myHandler.postDelayed(new Runnable() {
gotoState2();
}, 250);
}
...