http://blog.csdn.net/u013278099/article/details/51485476?ref=myread
前言
最近公司的另一個項目又要立項了，作爲公司的唯一安卓工程師任務來了（新來的移動端的老大說項目還是主要你負責，我就負責幫你們安排下進度），聽了這話我是傷心的在這公司不管是幾個還是1個安卓開發都是我來搭建，幹着與工資不符的事情，好的一點是開發沒有人干涉平時也能學習自己想學的東西。
如何選擇app架構（MVC/MVP/MVVM）
最近越來越多的人開始談論架構。我周圍的同事和工程師也是如此。儘管我還不是特別深入理解MVP，但是還是覺得比較牛逼,然後呢也想在公司的項目中去使用它。
項目時間緊迫：快速開發框架（迫不得已）
目前網絡上也有一些針對Android的快速開發框架，下面介紹3個主要的快速開發框架。針對這些快速開發框架，個人認爲可以參考，但並不推薦使用，因爲App整體依賴一個個人維護的框架風險實在太大，框架存在一些學習成本，本身也不一定完全符合App的需求，使用後可能存在代碼的臃腫，還有就是架構限制。
-
Afinal
GitHub項目地址：Afinal
Afinal是一個Android的IOC，ORM框架，內置了四大模塊功能：FinalAcitivity, FinalBitmap, FinalDb, FinalHttp。通過FinalActivity，可以通過註解的方式進行綁定UI和事件。通過FinalBitmap，可以方便的加載Bitmap圖片，而無需考慮OOM等問題。通過FinalDB模塊，通過一行代碼就可以對Android的SQlite數據庫進行增刪改查。通過FinalHttp模塊，可以以Ajax形式請求Http數據。
然而項目從去年就沒有人更新維護了，ioc框架很多人不太喜歡而且性能不好。
-
xUtils3.0
GitHub項目地址：xUtils3.0
- xUtils 支持超大文件(超過2G)上傳，更全面的http請求協議支持(11種謂詞)，擁有更加靈活的ORM，更多的事件註解支持且不受混淆影響…
- xUtils 最低兼容Android 4.0 (api level 14). (Android 2.3?)
-
xUtils3變化較多所以建立了新的項目不在舊版(github.com/wyouflf/xUtils)上繼續維護, 相對於舊版本:
- HTTP實現替換HttpClient爲UrlConnection, 自動解析回調泛型, 更安全的斷點續傳策略.
- 支持標準的Cookie策略, 區分domain, path…
- 事件註解去除不常用的功能, 提高性能.
- 數據庫api簡化提高性能, 達到和greenDao一致的性能.
- 圖片綁定支持gif(受系統兼容性影響, 部分gif文件只能靜態顯示), webp; 支持圓角, 圓形, 方形等裁剪, 支持自動旋轉…
可以看出xUtils3對於快速開發是一個不錯的選擇。
自己從零開始搭建app架構
簡單的看下這三個架構模式：
- MVC：Model-View-Controller，經典模式，很容易理解，主要缺點有兩個：
View對Model的依賴，會導致View也包含了業務邏輯；
Controller會變得很厚很複雜。 - MVP：Model-View-Presenter，MVC的一個演變模式，將Controller換成了Presenter，主要爲了解決上述第一個缺點，將View和Model解耦，不過第二個缺點依然沒有解決。
- MVVM：Model-View-ViewModel，是對MVP的一個優化模式，採用了雙向綁定：View的變動，自動反映在ViewModel，反之亦然。
面對衆多的架構模式你會選擇哪個？
MVC，MVP還是MVVM？
越高級的模式複雜性越高，實現起來也越難。然後搭建項目時也是看項目的需求，別人說好你也有要實用纔好，高效的實現項目的功能纔是最好的架構模式。
那麼，哪一個纔是最好的呢？
個人覺得適合你的纔是最好的，不要去盲目的跟風，大家說mvp好那你就使用咯，沒有實踐就沒有話語權，所以說用哪種架構模式本人不發表任何意見：任何模式的動機都是一樣的，那就是如何避免複雜混亂的代碼，讓執行單元測試變得容易，創造高質量應用程序，開發維護更高效。
在實際項目中思考架構時，也不會想着要用哪種模式，我只思考現階段，以現有的人力資源和時間資源，如何才能更快更好地完成需求，適當考慮下如何爲後期擴展或重構做準備。
我項目中的架構
這是我上一個項目的包架構：
當然咯，是按功能分的包，項目的功能不一樣然後分包也不一樣，但是基本大同小異。
所以確定架構分包的時候那就按你的需求來咯。
從上面可以看出：架構分包的時候我們包括邏輯功能和基礎功能（通用功能）。
基礎功能模塊：
-
日誌管理系統（LogManager）
不管哪個項目都需要自己的一套日誌管理，一是爲了生產調試時能更加高效的查看過濾日誌，二是爲了打包發佈的時候用開關控制日誌是否打印。 （我的日誌用的是凱子哥的：Klog）
- 異常處理(crashManager)
作用：當程序遇見異常情況時我們能夠自定義異常處理，二是程序對不同的機型有不同的反應，那麼測試時候可能沒有發現但是我們可以把捕獲的crash上傳到服務器，便於異常收集和bug修復。
-
utils(工具類)
根據你的項目需求來合理定製你的工具類，將會對你的項目開發速度有很大的提升（反饋，版本校驗更新你肯定能夠用到）
看下我上個項目的工具類：
- permission(權限管理系統)
這功能是絕對項目中需要的，別告訴我你的項目還沒有適配安卓6.0，適配了就肯定會有權限管理，我這裏用的是 安卓6.0權限處理在項目中的實踐,也還可以吧，反正github上的權限管理的開源東西比較多，覺得合適就ok。
哈哈，這樣你的基礎功能都搭建好了，然後就是一些邏輯功能的封裝了。
邏輯功能模塊：
1.封裝自己的application和baseActivity類，最大可能的節省代碼，加入mvp的思想來架構。 2.選擇自己喜歡的網絡請求框架並且適當合理的進行封裝，加快開發的效率。 3.針對帶有滾動控件嵌套有可能產生的滑動衝突，或者顯示不全我們優先自定義一下viewpager,listview,gridview等。 4.封裝listView或者recyclerView打造萬能的適配器，覺得翔哥的封裝的不錯[ 打造萬能的適配器](https://github.com/hongyangAndroid/baseAdapter)。 5.一般的網絡數據格式是json(我們就逗：普通數據json,刷卡交易數據xml),所以呢我json格式的用gson封裝一下,xml格式暫時用的是pull解析後bean對象封裝。 6.數據庫的封裝，對數據苦要求不高的話可以用原生的簡單封裝一下curd就好了，要求高點的話那就用第三方的好了。開發過程中第三方開源庫的抉擇
圖片加載庫：
-
Glide:相比較UIL，glide可以支持gif和短視頻,支持與activity，fragment，application生命週期的聯動,支持 okhttp、Volley
-
Fresco:三級緩存牛逼，對多幀動畫圖片支持更好，如 Gif、WebP
-
UIL：老牌的雖然不再更新維護，但功能強大
根據你的項目需求選擇，熟悉UIL就用它，個人推薦Glide
網絡請求庫：
-
okhttp:
okhttp是高性能的http庫，支持同步、異步，而且實現了spdy、http2、websocket協議，api很簡潔易用，和volley一樣實現了http協議的緩存。 -
retrofit:
簡化了網絡請求流程，同時自己內部對OkHtttp客戶端做了封裝，同時2.x把之前1.x版本的部分不恰當職責都轉移給OkHttp了(例如Log，目前用OkHttp的Interceptor來實現)
-
volley:
volley是一個簡單的異步http庫，僅此而已。缺點是不支持同步，這點會限制開發模式；不能post大數據，所以不適合用來上傳文件。
個人建議使用retrofit，volley的通用性不高（資料最多）。
事件總線庫：
主要用來消息/事件的傳遞，卻能實現組建之間的解耦。
eventBus3.0和otto都是使用註解的方式（@Subscribe、@Produce）來標註方法，Otto更多的使用場景是在主線程中，相對是輕量級的。
如果你對是不是輕量級不關心的話，我覺得兩個差不多，但是還是很多人推薦使用otto。
依賴注入庫：
butterknife8.0：
https://github.com/JakeWharton/butterknife
在任何項目中使用butterknife都是正確且沒有問題的. 非常輕量級的庫，原因是性能高節省代碼，而且不是你們所想的反射機制實現的。
Dagger2：它是不具有動態性的（使用時完全不使用反射）但是生成的代碼的簡潔性和性能都是與手寫的代碼同水準的。
2個都是很棒的，你可以選擇額。
數據庫存儲：
-
LitePal：LitePal是一款開源的Android數據庫框架，它採用了對象關係映射(ORM)的模式，LitePal很“輕”，jar包只有100k不到，使用起來也比較簡單，源碼地址爲LitePal地址,郭神開發的就是牛。
-
greenDAO:greenDAO與LitePal不同，其原理不是根據反射進行數據庫的各項操作，而是一開始就人工生成業務需要的Model和DAO文件，業務中可以直接調用相應的DAO文件進行數據庫操作，從而避免了因反射帶來的性能損耗和效率低下。但是由於需要人工生成model和DAO文件，所以greenDAO的配置就略顯複雜。
greenDAO用起來繁瑣但是效率高點，LitePal用起來簡單，所以你自己選擇吧，個人還是覺得LitePal好用點。
簡單緩存
ASimpleCache:ASimpleCache 是一個爲android制定的 輕量級的 開源緩存框架。輕量到只有一個java文件（由十幾個類精簡而來）。
- 可緩存普通的字符串、JsonObject、JsonArray、Bitmap、Drawable、序列化的java對象，和 byte數據。普通的字符串、JsonObject、JsonArray、Bitmap、Drawable、序列化的java對象，和 byte數據。
- 替換SharePreference當做配置文件
- 可以緩存網絡請求數據，比如oschina的android客戶端可以緩存http請求的新聞內容，緩存時間假設爲1個小時，超時後自動失效，讓客戶端重新請求新的數據，減少客戶端流量，同時減少服務器併發量。
哈哈項目需要的基本架構需要的開源庫都有了，你可以放心的開發了。
總結
其實架構並不是那麼難，也不要別人說怎麼好就怎麼幹，你要相信總有一個東西是適合你的，打個比喻app架構就是蓋房子，磚少就蓋矮點嗎，但是必須保證得結實，就像 框架不一定要強大但是必須健壯具有擴展性。
時間不早了，各位早點休息。
更多的Material Design系列效果，請去star 我的https://github.com/zilianliuxue/AndroidStudy
