AndroidでViewを自動的に更新するもう一つの方法(非スレッド、非同期処理).

以前はViewを使用させる場合、インタフェースを更新するには常にスレッドを使用してインタフェースを更新していましたが、SDKを見てAPIDemoではあまりスレッドを使用していないことがわかり、別の方法を使用していました.
以前は簡単なゲームを書いたことがありますが、Viewを使って、ページの更新コードは以下の通りです.

public void run() {
			while( drawing )
			{
				try {
					
					//        
					update();
					//        ,      onDraw  
					postInvalidate();
					//       ,    30ms      
					Thread.sleep(30);
					//Log.e(TAG, "drawing");
					
				} catch (InterruptedException e) {
					e.printStackTrace();
				}
			}
		}

 
このようにするのは簡潔に見えますが、プログラムを書く過程で私に迷惑をかけたことがあります.つまり、スレッドの生存周期は完全に自分で責任を負わなければなりません.うっかりすると、このActivityのライフサイクルが終わるはずだったのに、このスレッドはずっとバックグラウンドで実行されていて、リソースをかなり浪費しています.Androidの仮想マシンは、実行中のスレッドを自発的に殺すことはありません.スレッドがまだ存在しているのに、このスレッドを新しく開きたい、エラーを投げ出したい......データ同期の問題など、これらのプロセスの詳細は周到に考慮しなければならない.そうしないと、プログラムが強制的に閉鎖されやすい.
しかし、APIDemoでは、インタフェースを再描画する必要がある場合、onDraw関数の最後にinvalidate()が使用されます.
APIDemoのコードはGraphicsパッケージ内のArcsを参照してください.
主な考え方は以下の通りです.

public void onDraw(Canvas canvas)
	{
		dosomething();
		invalidate();
		Log.v("main", "invaliate");
	}

他の部分は以前と変わらない.このような利点は、図面のスレッド管理をすべてAndroidに任せることであり(Android自体はこの図面を専門に担当するスレッドがある)、上記の問題を心配する必要はありません.再描画プロセスに遅延が必要な場合はpostInvalidateDelayMilliseconds(long delayMilliseconds)を使用し、Thread.sleep(milliseconds)に相当します.かなり使いやすく、Viewを書く過程で不要なイライラが少なくなりました.しかし、データの同期にも問題がある可能性があります.しかし、Handlerを通じて、だからデータの処理をUIスレッドに全部渡してもいいのではないかと思います.そうすれば、同期の問題を簡単に変えることができるのではないでしょうか.Handlerをもっと深く勉強してから実験しなければなりません.
このプロシージャはテール再帰に似ていますが、再帰とは実質的に異なり、invalidate()関数はリクエストの送信を担当するだけで(非スレッドの外でpostInvalidate()を使用すべきです)、関数を実行すると、描画スレッドのリクエストキューにリクエストが追加され、スレッドがこのリクエストを処理するとインタフェースが再描画されます.これは非同期のプロシージャ、invalidate()onDrawは実行されていないので、再帰ではなく、再帰に必要なスタックがなく、爆スタックなどの心配もありません.私の上のコードの后ろにlog文を追加して、Logcatの中でこのmainの文が绝えず更新していることを见ることができます.
これにはAndroidの描画メカニズムの問題も含まれています.つまりHandlerメカニズムです.私は今も漠然とした概念を持っています.もっと勉強してから考えを整理します.総じて、Androidの図面は1つのスレッドによって担当されています.このスレッドにはリクエストキューがあり、このスレッドはキューからリクエストを取り出してインタフェースを描画し続け、UIスレッドの外資系企業図でインタフェースを修正するのは無効です.
简単に见える一言で、触れるものは少なくないでしょう.学問には限りがない...o(∩∩∩)o...ははは