Android周りのスレッド管理に関する考察

android 課題ストック

自メモ）

今でバックしてるのは
　通信失敗 ＝＞ 即時エラーでTOPメニューに戻る
って流れの奴。

どうもExecuterService系の起動 や executeの段階でエラーになっているよう
＜やったのは
　AndroidがIOSに比べて通信や処理が遅い
　Handler ＝＞ExecutorServiceに置換
ってかんじなんですけど。。。

　HandlerはGUIスレッドにキューイングされるから？かも知れない。

Handler handler = new Handler(getMainLooper());

としないとメインキューでスタックされない認識だったんだけどな。。。

Handler handler = new Handler();

な記述でもコンパイラの最適化次第でそういう動きをするということ？


http://twitter.com/sakura_bird1/status/294295942415400960:twitter:detail:right
http://twitter.com/sakura_bird1/status/294300259188875264:twitter:detail:right

以前

と思ったけど、全然関係なかった(汗

ArrayAdaptorの要素のImageViewに対して

imgView.setImageBitmap(null);

の箇所のコメント

と

やってた箇所と画像DLを

  1. doInBackground の中から更に非同期に画像DL ＝＞同期画像DL
  2. ArrayAdaptorのgetViewの中で非同期に画像DL ＝＞やらない
  3. imageのキャッシュをしてる LruCacheをsynchronizedで囲む

の辺りの対応で落ち着いたようなおちつかないような。。。対処方法イマイチわからん＞＜

Androidは実はスレッド数に制限あるっぽい*1話も聞いたことあるしな。。
そんなに立ち上げている認識は無いけど別プロセスも合計なんかもしれないし。。

な事も考えたけど、上記の対応をしない同じような処理で 動くアプリは動くんだよね。。
だとすると あとは表示してる文字列の影響なのかな。。。ふむ。。



threadid=1: thread exiting with uncaught exception (group=0x4002d560)

ちなみにこのExceptionで検索かけると

  1. UIをHandlerで弄ってないからだよ って言う奴と
  2. ViewPagerとか使ってるからでない？

な奴が出てくるけど

あとException対策でググると

辺りが出てくるんだけど、このExceptionには無力だったorz

まあ今だとこういうネタでないと注目はされないんだろうけど（汗
UIをWebベースで作れると楽だよね。のお話はよく聞く・・

*1:同時最大255？