一、滿足solid原則
單一職責原則：乙個類只做一種型別責任，當這個類需要承當其他型別的責任的時候，就需要分解這個類，這是解耦的重要步驟
開放封閉原則：對擴充套件開放，對修改關閉，比如使用**模式
裡式替換原則：當乙個子類的例項應該能夠替換任何其超類的例項時，它們之間才具有is-a關係，也就是說不能模糊化類的概念，類的設計一定要嚴謹
介面分離原則：不要強迫使用不需要的介面，也就是說使用多個功能專一的介面比使用乙個總介面要更好
依賴倒置原則：在需要依賴關係的地方盡量依賴介面和抽象類，而不是具體類
二、檢視、資料、邏輯分離
mvc：獲取資料的操作放到model層，xml布局檔案相當於是v層，activity/fragment相當於是c層，所有業務**和介面都放到controller中。雖然把獲取資料抽象出了model層，但c層依然太臃腫，這種模式一般只應用於很簡單業務邏輯不多的介面，優點是寫起來簡單。
mvp：獲取資料的操作放到model層，activity/fragment此時相當於是v層，這是和mvc第乙個不一樣的地方，第二個不一樣的地方是新增了presenter來處理具體的業務邏輯，而v層只負責介面的顯示相關邏輯，瞬間簡潔了不少。當前mvp也有瑕疵，就是如果業務邏輯複雜的話，presenter裡要處理的內容過多，會導致presenter很臃腫，不堪重負。
mvvm：獲取資料的操作放到model層，activity/fragment此時相當於是v層，然後新增了乙個viewmodel層，通過databinding來將viewmodel跟布局檔案進行繫結，從而將填充資料等邏輯直接廢除，缺點是上手較慢一些，因為databinding還是有一定學習成本的。
總結：在實際業務中具體使用哪一種應該根據實際情況來定，如果是很簡單的業務可以用mvc，一般是用mvp或者mvvm更好一些。
三、模組化架構
base：存放介面抽象類util類等基礎的類，只要後期穩定了基本都不需要修改，但是牽一發動全身，一般由架構師或高階程式設計師來維護。base就是最基本的模組，不依賴任何模組。
網路：這裡是存放網路請求用到的一些類，比如網路框架**、網路錯誤處理、新增固定header等，網路層依賴於base層，因為需要base層的一些基類
common：這裡是存放各個業務模組都需要用到的類，常見的比如自定義view，可以在各個業務中復用的時候，可以存放到common層，common模組也依賴於base模組。
四、重要資料內建和快取
五、其他經驗之談
1.我們可以在網路層寫好，debug模式下自動列印出請求引數和返回值，方便開發時進行除錯
2.網路請求時不同的錯誤需要進行區分處理，並且向服務端打點，方便查詢問題
3.base層應該支援在實際介面關閉時取消網路請求，防止做無用操作，節省記憶體開銷
4.如果是mvvm業務結構的話，需要注意的是如果viewmodel持有view的物件時應該使用弱引用的方式，然後應該在view關閉的生命週期中對該持有進行清除操作，防止記憶體洩漏
5.在需要切換同一布局的內容顯示時，為了避免重複的顯示隱藏判斷操作，可以使用tipsview
最後：以上幾點是很重要的經驗，但也不代表考慮了這些點就是最優秀的架構了。實際專案遠比理論複雜，所以我們需要做的是借鑑別人的經驗，來解決自己的實際問題。作者以後有其他的經驗也會更新上去，希望能給大家帶來一些幫助。
App架構設計 介面的設計
安全機制的設計 使用者用密碼登入成功後，伺服器返回token給客戶端 客戶端將token儲存在本地，發起後續的相關請求時，將token發回給伺服器 伺服器檢查token的有效性，有效則返回資料，若無效，分兩種情況 token錯誤，這時需要使用者重新登入，獲取正確的token token過期，這時客戶...
App介面架構設計之談
使用者用密碼登入成功後，伺服器返回token給客戶端 客戶端將token儲存在本地，發起後續的相關請求時，將token發回給伺服器 伺服器檢查token的有效性，有效則返回資料，若無效，分兩種情況 然而，此種驗證方式存在乙個安全性問題 當登入介面被劫持時，黑客就獲取到了使用者密碼和token，後續則...
APP系統架構設計初探
一，體驗的優化。在手機上顯示，速度是乙個非常重要的體驗點，試想，如果您開啟乙個 發現裡面的一直顯示失敗或者是x，稍微做得好一點的，可能是乙個不消失的loading或者是菊花等等，但不管如何，沒能快速的拉取和展示對使用者體驗是乙個極大的挑戰。那麼，手機上的體驗如何做呢？這裡筆者有些小總結 1，減少的大...