前言
最近公司的另一個項目又要立項了,作爲公司的唯一安卓工程師任務來了(新來的移動端的老大說項目還是主要你負責,我就負責幫你們安排下進度),聽了這話我是傷心的在這公司不管是幾個還是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