Android 設計隨便說說之簡單實踐(消息流動)，android隨便說說

Android 設計隨便說說之簡單實踐(消息流動)，android隨便說說

在上面兩篇分別說明了設計中較為簡單也是很關鍵的實踐點。

第一模塊劃分，它是根據每個模塊所承載的業務，進行劃分，是應用程序一個靜態的描述。

第二合理組合，它是是將每個模塊調動起來，共同實現業務，是一個准動態的說明。

今天主要說明真個應用程序中消息和數據，以及如何循環，是完全動態的。同時也簡單的提到各種設計框架。是終結篇。

我們先拿下載這個業務來說。顯示用戶點擊了界面下載按鈕onClick，然後onClicK調用調度層的onStartDownLoadApp(Item), 而調度層又將指令業務單元模塊下載模塊。調用下載模塊的onStartDown(Item)。從這裡可以看出，消息是一層一層的向下傳遞去。此時下載模塊開始下載到數據，然後上報下載進度downLaodProgress(id, progress)，該方法傳遞了下載項信息（id）和進度信息（progress），並且調用到調度層的downLoadAppProgress（id，progress），調度層的該方法有經一部的調用onUpdateProgress. 從而實現從下載模塊到頁面的一個數據的傳遞。

注意從下載模塊向上報進度的時候，是異步的，因為下載是異步的，所以上報進度需要到主線程裡，所以相對下載來說該消息是異步的才能到主線程。

由上可見，

1  消息的一步步同時下發，而且必然經過調度層。

2  數據的上報也是一層一層上傳，而且必然經過調度層。

當然，還可以舉其他例子，這裡就不在舉例了。總體來說在設計的時候，務必要理清楚消息和數據是如何流動，才能完整的總結出業務模型並且切合到設計中。

設計模型中有MVC，MVP，MVVM。其中MVC有個特征就是不但C可以更新V而且M也可以更新V（圓形的消息流），那麼這樣設計過程中V不但要照顧到C還要照顧到M，而M同樣不但要照顧到C還要照顧到V。這樣顯然是體現了復雜度。但是在大型的web項目中是很常用的。而MVP和MVVM的特征是V只和P（或者VM）相互調用，不被M調用。M只和P（或者VM）相互調用，而和V沒有直接關系。因此在設計中，V和M不必相互照顧。

上面提到的都是比較成熟的設計模型，但是無論那種設計模型都追求的目標是“低耦合，高內聚”，各個模塊相互照應但是有各司其職。照應中需要做到很好的解耦。

設計中常常用的五視圖方法，該方法比較全面，即考慮的周圍的運行環境和關聯模塊，也從動態和靜態描述了程序內部的接口和聯動方式。我用這種方法做過兩次設計。還是很不錯。以上四篇是結合他的理論以及我的實踐一個簡單的總結。

突然想到還有一點沒有談到，就是業務的變化與不變的考慮。這個也是非常重要，設計中要充分的考慮到那些業務會發生變化，如何將變化鎖定在可控的范圍內。這就需要一層接口，通過接口來規范可變的業務實現，及無論業務如何變化，都必須遵守該接口的契約。

完了。