學習Android時總結之談
作為比mobile系統更簡捷的操作系統，Android提供了更好的機制來增強程序的安全性，Android具有嚴格的類型安全檢查功能，它幾乎能找出程序中所有的語法問題，這點大大的幫助了開發人員，下面就談一談學習Android感想。
有了framework后，我們不用面對赤裸裸的OS API，做一些重復而繁雜的事情。但天下沒有免費的午餐，在Android中，下層是Linux的核，但上層的java做的framework把這一切封裝的密不透風。
以消息處理為例，在MFC中，我們可以用PreTranslateMessage等東東自由處理消息。在C#中，Anders Hejlsberg老大說了，他為我們通向底層開了一扇“救生窗”，但很遺憾，在學習Android中，這扇窗戶也被關閉了（至少我現在沒發現...）。
在學習Android時，你想處理一些消息（比如：Keydown之類的...），你必須尋找Activity為你提供的一些重載函數（比如 onKeyDown之類的...）或者是各式各樣的listener（比如OnKeyDownListner之類的...）。這樣做的好處是顯而易見的，越多的自由就會有越多的危險和越多的晦澀，條條框框畫好了，用起來省心看起來省腦，這是一個設計良好的framework應該提供的享受。
對于我目前的工程而言，我沒有什么BT的需求在當前API下做不到的，google的設計ms還是很nice的。但世界是殘酷的，有的時候我們還是必須有機制提供消息的分發和處理的。
因為有的工作是不能通過直接調用來同步處理的，同時也不能通過Activity中內嵌的消息分發和接口設定來做到，比如說事件的定時觸法，異步的循環事件的處理，高耗時的工作等等。
在Android中，它提供了一些蠻有意思的方式來做這件事情（不好意思，我見不多識不廣，我沒見過類似玩法，有見過的提個醒 && 嘴下超生^_^）。它有一個android.os.Handler的類，這個類接受一個Looper參數，顧名思義，這是一個封裝過的，表征消息循環的類。
默認情況下，Handler接受的是當前線程下的消息循環實例，也就是說一個消息循環可以被當前線程中的多個對象來分發，來處理（在UI線程中，系統已經有一個Activity來處理了，你可以再起若干個Handler來處理...）在實例化一個 handlerInstance之后，你可以通過sendMessage等消息發送機制來發送消息，通過重載handleMessage等函數來分發消息。
但是！該handlerInstance能夠接受到的消息，只有通過handlerInstance.obtainMessage構造出來的消息（這種說法是不確切的。你也可以手動new一個Message，然后配置成該handlerInstance可以處理的，我沒有跟進去分析其識別機制，有興趣的自己玩吧^_^）。
也就是說A, B, C, D都可以來處理同一線程內的消息分發，但各自都只能處理屬于自己的那一份消息，這抹殺了B想偷偷進入A領地，越俎代庖做一些非份之事的可能（從理論上看。
B還是有可能把消息偽裝的和A他們家的一樣，我沒有嘗試挑戰一下google的智商，有BT需求的自行研究^_^）。這樣做，不但兼顧了靈活性，也確保了安全性，用起來也會簡單，我的地盤我做主，不用當心傷及無辜，左擁右抱是一件很開心的事情。
很顯然，消息發送者不局限于自己線程，否者只能做一些定時，延時之類的事情，豈不十分無趣。在實例化Handler的時候，Looper可以是任意線程的，只要有Handler的指針，任何線程也都可以sendMessage（這種構造方式也很有意思。
你可以在A線程里面傳B線程的Looper來構造 Handler，也可以在B線程里構造，這給內存管理的方法帶來很大的變數...）。但有條規則肯定是不能破壞的，就是非UI線程，是不能觸碰UI類的。
在不同平臺上有很多解決方式（如果你有多的不能再多的興趣，可以看一下很久很久以前我寫的一個，不SB不要錢）。我特意好好跟了一下android中的AsyncQueryHandler類，來了解google官方的解決方案。
【編輯推薦】
