學習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官方的解決方案。