『壹』 如何終止android Handler 中的消息處理
終止Android Handler 中的消息處理的辦法：
首先你可以放到線程中去執行，這個應該是個耗時操作，放到UI線程中，程序會假死。
然後你可以通過handler去啟動這個線程來執行這個方法，如果取消的話，在發給handler一個消息，讓handler再去停止這個線程。
『貳』 android中handle和線程的關系是什麼
作者：李板溪
鏈接：http://www.hu.com/question/24766848/answer/53037579
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請註明出處。
問題背景，假設你要下載一張美女圖顯示出來。 使用這個問題就可以說明主要的問題了。
好了 上代碼，下載美女圖片，然後顯示在 ImageView 中。 代碼如下：
public class MainActivity extends AppCompatActivity {
public static final String beautyUrl = "http://ww3.sinaimg.cn/large/.jpg";
ImageView mBeautyImageView;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mBeautyImageView = (ImageView)findViewById(R.id.beauty);
mBeautyImageView.setImageBitmap(downloadImage(beautyUrl));
}
@Nullable
public Bitmap downloadImage(String urlString){
try {
final URL url = new URL(urlString);
try(InputStream is = url.openStream()){
return BitmapFactory.decodeStream(is);
}
} catch (IOException e) {
e.printStackTrace();
return null;
}
}
}
然後這樣的一段看似沒有問題的代碼，在 Android 3 以上是會直接報錯的。 主要錯誤原因在
Caused by: android.os.NetworkOnMainThreadException at android.os.StrictMode$AndroidBlockGuardPolicy.onNetwork(StrictMode.java:1147)
為了保證用戶體驗， Android 在 3.0 之後，就不允許在 主線程（MainThread）即 UI線程 中執行網路請求了。 那怎麼辦呢？
好吧，我們暫不考試 Android 提供的一系統組件及工具類， 用純 Java 的方式來解決這個問題。
在新的線程中下載顯示圖片
在新創建的線程中下載顯示圖片如下：
new Thread(new Runnable() {
@Override
public void run() {
mBeautyImageView.setImageBitmap(downloadImage(beautyUrl));
}
}).start();
看起來來錯的樣子，跑起來看看。 啊，又報錯了。
android.view.ViewRootImpl$: Only the original thread that created a view hierarchy can touch its views.
說只能在創建View 層級結構的線程中修改它。 創建它的線程就是主線程。 在別的線程不能修改。 那怎麼辦？
那現在我們遇到的問題是： 下載不能在主線程下載。 更新ImageView 一定要在 主線程中進行。 在這樣的限制下，我們自然而然想去一個解決辦法： 就是在新創建的線程中下載。 下載完成在主線程中更新 ImageView。
但是，怎麼在下載完成之後，將圖片傳遞給主線程呢？這就是我們問題的關鍵了。
線程間通信
我們的通信要求，當下載線程中下載完成時，通知主線程下載已經完成，請在主線程中設置圖片。 純 Java 的實現上面的線程間通信的辦法我暫沒有找到，於是我想到使用 FutureTask 來實現在主線程中等待圖片下載完成，然後再設置。
FutureTask<Bitmap> bitmapFutureTask = new FutureTask<>(new Callable<Bitmap>() {
@Override
public Bitmap call() throws Exception {
return downloadImage(beautyUrl);
}
});
new Thread(bitmapFutureTask).start();
try {
Bitmap bitmap = bitmapFutureTask.get();
mBeautyImageView.setImageBitmap(bitmap);
} catch (InterruptedException |ExecutionException e) {
e.printStackTrace();
}
不過這雖然騙過了 Android 系統，但是雖然系統阻塞的現象沒有解決。 例如我在 get() 方法前後設置了輸出語句：
Log.i(TAG,"Waiting Bitmap");
Bitmap bitmap = bitmapFutureTask.get();
Log.i(TAG,"Finished download Bitmap");
設置了下載時間至少 5 秒鍾之後，輸出如下：
06-27 23:30:18.058 21298-21298/com.banxi1988.androiditc I/MainActivity﹕ Waiting Bitmap 06-27 23:30:23.393 21298-21298/com.banxi1988.androiditc I/MainActivity﹕ Finished download Bitmap
讓主線程什麼事做不做，就在那傻等了半天。然後由於 onCreate沒有返回。用戶也就還沒有看到界面。 導致說應用半天啟動不了。。卡死了。。
查閱了一些資料，沒有不用 Android 的框架層的東西而實現在其他進程執行指定代碼的。
而 Android 中線程間通信就得用到 android.os.Handler 類了。 每一個 Handler 都與一個線程相關聯。 而 Handler 的主要功能之一便是： 在另一個線程上安插一個需要執行的任務。
這樣我的問題就通過一個 Handler 來解決了。
於是 onCreate 中的相關代碼變成如下了：
final Handler mainThreadHandler = new Handler();
new Thread(new Runnable() {
@Override
public void run() {
final Bitmap bitmap = downloadImage(beautyUrl);
mainThreadHandler.post(new Runnable() {
@Override
public void run() {
mBeautyImageView.setImageBitmap(bitmap);
}
});
}
}).start();
看起來很酷的樣子嘛，一層套一層的 Runnable. mainThreadHandler 因為是在 主線程中創建的， 而 Handler創建時，綁定到當前線程。 所以 mainThreadHandler 綁定到主線程中了。
當然 Android 為了方便你在向主線程中安排進操作，在 Activity類中提供了 runOnUiThread 方法。 於是上面的代碼簡化為：
new Thread(new Runnable() {
@Override
public void run() {
final Bitmap bitmap = downloadImage(beautyUrl);
runOnUiThread(new Runnable() {
@Override
public void run() {
mBeautyImageView.setImageBitmap(bitmap);
}
});
}
}).start();
你不用自己創建一個 Handler了。
而 runOnUiThread 的具體實現，也跟我們做得差不多。UI線程即主線程。
public final void runOnUiThread(Runnable action) {
if (Thread.currentThread() != mUiThread) {
mHandler.post(action);
} else {
action.run();
}
}
Handler 與 Loop 簡介
上面說到 每一個 Handler 都與一個線程相綁定。 實際上是，通過 Handler 與 Loop 綁定，而每一個 Loop 都與一個線程想綁定的。 比如 Handler 中兩個主要構造函數大概如下：
public Handler(...){
mLooper = Looper.myLooper();
// ...
}
public Handler(Looper looper,...){
mLooper = looper;
// ...
}
public static Looper myLooper() {
return sThreadLocal.get();
}
然後 Looper 的構造函數如下：
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}
綁定了當前的線程和生成了一個消息隊列。
值得提起的一點是， Looper 類保持了對 應用的主線程的 Looper 對象的靜態應用。
private static Looper sMainLooper; // guarded by Looper.class
public static Looper getMainLooper() {
synchronized (Looper.class) {
return sMainLooper;
}
}
這樣就可以方便你在其他線程中，使用一個綁定到主線程的 Handler，從而方便向主線程安插任務。 例如一般的圖片處理庫即是如此。這樣你只要指定一個 圖片的 url,及要更新的ImageView 即可。 如 Picasso 庫可以用如下代碼的讀取並更新圖片。 Picasso.with(context).load(url).into(imageView);
然後 Handler 可以做的事情還有很多。 因為它後面有 Looper 有 MessageQueue。可以深入了解下。
談一下線程池與 AsyncTask 類
Android 早期便有這個便利的類來讓我們方便的處理 工作線程及主線程的交互及通信。 但是現在先思考一下，我們上面的代碼可能遇到的問題。 比如，我們現在要顯示一個圖片列表。 一百多張圖片。 如果每下載一張就開一個線程的話，那一百多個線程，那系統資源估計支持不住。特別是低端的手機。
正確的做法是使用一個線程池。
final ExecutorService executor = Executors.newCachedThreadPool();
executor.execute(new Runnable() {
@Override
public void run() {
final Bitmap bitmap = downloadImage(beautyUrl);
runOnUiThread(new Runnable() {
@Override
public void run() {
mBeautyImageView.setImageBitmap(bitmap);
}
});
executor.shutdown();
}
});
由於我們是在在一個局部方法中使用了一個線程池。所以處理完了之後應該將線程停止掉。 而我們上面只有一個線程，所以直接在下載完成之後，調用 executor停掉線程池。 那如果執行了多個圖片的下載請求。需要怎麼做呢？ 那就要等他們都完成時，再停止掉線程池。 不過這樣用一次就停一次還是挺浪費資源的。不過我們可以自己保持一個應用級的線程池。 不過這就麻煩不少。
然後 Android 早已經幫我們想法了這一點了。 我們直接使用 AsyncTask 類即可。
於是我們下載圖片並顯示圖片的代碼如下：
new AsyncTask<String,Void,Bitmap>(){
@Override
protected Bitmap doInBackground(String... params) {
return downloadImage(params[0]);
}
@Override
protected void onPostExecute(Bitmap bitmap) {
mBeautyImageView.setImageBitmap(bitmap);
}
}.execute(beautyUrl);
相比之前的代碼簡潔不少。
看一下 AsyncTask 的源代碼，正是集合我們之前考慮的這些東西。
一個全局的線程池
public static final Executor THREAD_POOL_EXECUTOR
= new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE,
TimeUnit.SECONDS, sPoolWorkQueue, sThreadFactory);
一個綁定主線程的 Handler ，在線程中處理傳遞的消息
private static class InternalHandler extends Handler {
public InternalHandler() {
super(Looper.getMainLooper());
}
@SuppressWarnings({"unchecked", "RawUseOfParameterizedType"})
@Override
public void handleMessage(Message msg) {
AsyncTaskResult<?> result = (AsyncTaskResult<?>) msg.obj;
switch (msg.what) {
case MESSAGE_POST_RESULT:
// There is only one result
result.mTask.finish(result.mData[0]);
break;
case MESSAGE_POST_PROGRESS:
result.mTask.onProgressUpdate(result.mData);
break;
}
}
}
小結
Android 提供的 Looper 和 Handler 可以讓我們非常方便的在各線程中安排可執行的任務
『叄』 Android Handler那些事兒，消息屏障IdelHandlerANR
Handler 是Android SDK中用來處理非同步消息的核心類，子線程可以通過handler來通知主線程進行ui更新。
備註：本文源碼截圖 基於Android sdk 28
Handler機制 消息發送主要流程如圖
應用程序啟動後，zygote fork一個應用進程後，和普通java程序一樣，程序會首先執行ActivityThread中的main函數。在main函數中，程序首先會創建Looper對象並綁定到主線程中，然後開啟loop循環。（ps:主線程loop循環不能退出）
在prepareMainLooper方法中，最終會創建Looper，MessageQueue對象 以及創建native層MessageQueue對象。
使用Handler.sendMessageXXX或這 postDedayXXX發送消息後，最終會調用到SendMessageAtTime方法中。
然後調用MessageQueue.enqueueMessage將消息存到消息隊列中。
存入消息後，然後通過調用native方法 喚醒主線程進行消息處理。
當應用程序啟動，做完一些必要工作之後，便會開啟Loop循環，除非系統異常，否則該循環不會停止。loop循環中，主要做兩件事，第一，從消息隊列中取消息。第二，進行消息分發處理。
MessageQueue.next() 方法 通過調用 native方法 nativePollOnce(ptr, nextPollTimeoutMillis)實現無消息處理時，進入阻塞的功能。
當nextPollTimeoutMillis 值為0時，該方法會立刻返回；
當nextPollTimeoutMillis 值為-1時，該方法會無限阻塞，直到被喚醒；
當nextPollTimeoutMillis 值大於0時，該方法會將該值設置為超時時間，阻塞到達一定時間後，返回；
在loop循環中 ，通過調用 msg.target.dispatchMessage(msg) 進行消息的分發處理
使用當前線程的MessageQueue.addIdleHandler方法可以在消息隊列中添加一個IdelHandler。
當MessageQueue 阻塞時，即當前線程空閑時，會回調IdleHandler中的方法；
當IdelHandler介面返回false時，表示該IdelHandler只執行一次，
a，延遲執行
例如，當啟動Activity時，需要延時執行一些操作，以免啟動過慢，我們常常使用以下方式延遲執行任務，但是在延遲時間上卻不好控制。
其實，這時候使用IdelHandler 會更優雅
b，批量任務，任務密集，且只關注最終結果
例如，在開發一個IM類型的界面時，通常情況下，每次收到一個IM消息時，都會刷新一次界面，但是當短時間內， 收到多條消息時，就會刷新多次界面，容易造成卡頓，影響性能，此時就可以使用一個工作線程監聽IM消息，在通過添加IdelHandler的方式通知界面刷新，避免短時間內多次刷新界面情況的發生。
在Android的消息機制中，其實有三種消息: 普通消息、非同步消息及消息屏障。
消息屏障 也是一種消息，但是它的target為 null。可以通過MessageQueue中的postSyncBarrier方法發送一個消息屏障（該方法為私有，需要反射調用）。
在消息循環中，如果第一條消息就是屏障消息，就往後遍歷，看看有沒有非同步消息:
如果沒有，則無限休眠，等待被喚醒
如果有，就看離這個消息被觸發時間還有多久，設置一個超時時間，繼續休眠
非同步消息 和普通消息一樣，只不過它被設置setAsynchronous 為true。有了這個標志位，消息機制會對它有些特別的處理，我們稍後說。
所以 消息屏障和非同步消息的作用 很明顯，在設置消息屏障後，非同步消息具有優先處理的權利。
這時候我們回顧將消息添加到消息隊列中時，可以發現，其實並不是每一次添加消息時，都會喚醒線程。
當該消息插入到隊列頭時，會喚醒該線程；
當該消息沒有插入到隊列頭，但隊列頭是屏障，且該消息是隊列中 靠前的一個非同步消息，則會喚醒線程，執行該消息；
調用MessageQueue.removeSyncBarrier 方法可以移除指定的消息屏障
ANR 即 Application Not Response， 是系統進程對應用行為的一種監控，如果應用程序沒有在規定時間內完成任務的話，就會引起ANR。
ANR類型
Service Timeout : 前台服務20s, 後台服務200s
BroadcastQueue Timeout : 前台廣播 10s，後台廣播60s
ContentPrivider Timeout : 10s
InputDispatching Timeout : 5s
比如，在啟動一個服務時， AMS端通過應用進程的Binder對象創建Service, 在scheleCreateService()方法中 會調用到當前service的onCreate()生命周期函數；
bumpServiceExecutingLocked()方法內部實際上會調用到scheleServiceTimeoutLocked()方法，發送一個ActivityManagerService.SERVICE_TIMEOUT_MSG類型消息到AMS工作線程中。
消息的延時時間，如果是前台服務，延時20s, 如果是後台服務，延時200s;
如果Service的創建 工作在 上訴消息的延時時間內完成，則會移除該消息，
否則，在Handler正常收到這個消息後，就會進行服務超時處理，即彈出ANR對話框。
復雜情況下，可能會頻繁調用sendMessage 往消息隊列中，添加消息，導致消息積壓，造成卡頓，
1，重復消息過濾
頻繁發送同類型消息時，有可能隊列中之前的消息還沒有處理，又發了一條相同類型的消息，更新之前的數據，這時候，可以採用移除前一個消息的方法，優化消息隊列。
2，互斥消息取消
在發送消息時，優先將消息隊列中還未處理的信息已經過時的消息 移除，優化隊列
3，隊列優化-復用消息
創建消息時，優先採用之前回收的消息，避免重復創建對象，引起GC
完~
（如果錯誤或不足，望指出， 大家共同進步）
『肆』 android 進度條，暫停，繼續怎麼弄
Handler和ProgressBar實現進度條的開始，暫停，停止，後退和循環
一，涉及的handler類方法
1，
post(Runnable r)
Causes the Runnable r to be added to the message queue.將要執行的線程對象加到隊列當中
2，
removeCallbacks(Runnable r)
Remove any pending posts of Runnable r that are in the message queue.移除隊列當中未執行的線程對象
3，
postDelayed(Runnable r, long delayMillis)
Causes the Runnable r to be added to the message queue, to be run after the specified amount of time elapses.
將要執行的線程對象放入到隊列當中，待時間結束後，運行制定的線程對象
二，編寫程序
程序效果：實現進度條的開始，暫停，停止，後退和循環
http://blog.csdn.net/superjunjin/article/details/7539844