“Guide to app architecture” 的學習筆記
這是一篇我學習ofollow,noindex">谷歌技術部落格 後作的總結，它介紹了通用的應用架構原則和在移動裝置上，可供參考的工程架構的最佳實踐。
專案架構中兩個最基本的原則：
模組分離
在專案架構設計中，模組分離原則是最要的，指根據單一的職責，把不同的功能模組用對應的程式碼封裝起來。這樣做的好處是，在定義好介面和實現其功能後，後續修改時，不需要知道具體實現細節，修改和改進當前模組的程式碼，並且不會對其他模組造成其他影響。
安卓中的activity、fragment是基本的UI元件，這些只會有一些元素的互動和與作業系統互動，當app因系統資源問題回收時，對應的ui檢視會改變，但是我們的資料模組則不應該受到影響。除了UI模組，是安卓系統替我們維護外，其他的模組，應該以最小的單位去封裝，這樣具有明確邊界的模組化程式碼才能讓app更加容易維護和測試。
模型驅動檢視
我們用Model來驅動檢視，且優先使用持久化模型，系統中模型是用來處理資料的，同時它獨立於UI和系統其他元件，它不受系統UI生命週期和其他模組的改變影響。
持久化的Model的有兩個理由：
1.app會隨系統記憶體不足被銷燬，持久化Model可以防止資料的丟失。
2.網路的不穩定，我們需要持久化的model來載入快取
當今，我們有很多專案架構去解決那些問題，具體採用哪種形式，這不是強制的。但是它們有下面幾個共同的特點：
1. Persist data
資料從網路獲取來的，我們需要持久化到本地。使用它們時，優先載入有效快取，這樣能提高資料顯示到螢幕上的速度。同時有部分使用者不是很喜歡用網路資料。
2. Well-defined boundary for each module
每個模組的邊界需要定義清晰，讓其各負其責。 模組大致分成檢視層、ViewModel層、資料業務層。在模組搭建方面，我們可以用Dagger2框架，分單列或者注入的方式來初始物件，用依賴把模組都組合起來。在測試方面，可以Mock模組物件，如我們可以只mock資料業務層，用本地的測試資料模擬網路資料，不用修改ViewModel層的程式碼。
3. Single source of truth
有些資料來自不同的伺服器地址，在他們更新的時候，因為網路關係會產生結構一致但內容不一樣的資料。我們需要把這些來自不同伺服器的資料儲存到同一個地方，之後獲取這些資料的時候，能確保它們的一致性。
4. A little function expose from each module
不要因為只有幾行程式碼, 就隨意在某個模組中加入，或者就把模組的某個介面實現暴漏出來，隨著專案的增大，這些程式碼就會變成技術債，後續維護專案時償還。
以上就是我的總結。
點選這裡 ，可在我的個人部落格上檢視此篇文章。