原文地址: http://www.lxweimin.com/p/91c2bb8e6369
Why?(文章最后有驚喜)
我們為什么要把Dagger2,MVP以及Rxjava引入項目中?
- 毫無疑問在Android開發圈中這三個技術是經常被提及的,如此多的文章和開源項目在介紹他們,使用他們,開發者也或多或少的被帶動起來在自己的項目中使用他們,但是使用他們之前我們知道為什么要使用他們,他們能給我們帶來什么好處嗎,還是只是跟隨潮流
其實我們大多數項目中是使用不到他們的,或者說對這些技術的需求不是很大,為什么這么說呢？
大多數的開發者其實都是在開發功能模塊比較少的小項目,對于這些項目來說,其實使用這些技術帶來的好處相對于在開發時的所付出的時間來說其實性價比并不高,因為學習這些會有個學習曲線,并且這些技術并不會讓你的開發速度加快,相反會讓你多寫很多代碼,比如MVP和Dagger都會讓你多寫很多類和接口
所以說我們開發小項目根本是感覺不到這些技術給我們帶來的好處,也會困惑我們為什么要引入這些技術?
那為什么這些技術會這么火呢？
- 其實這些困惑大多出現在一直做功能模塊比較少的小項目的開發者上,只要你做過比較大的項目,隨著代碼的增多你就會遇到代碼的耦合,團隊協作時沖突的解決,類依賴的復雜度等問題,其實這些技術就是來解決這些問題的,所以這些技術大項目用的非常多
這些技術出現是為了解決什么？
- 想靈活運用一個技術,必然要了解這些技術為什么出現,出現是為了解決什么問題
MVP
MVP的文章很多,我這里就不做過多介紹,我個人的理解就是解耦和擴展以及團隊協作,大多數文章都只是介紹了怎么寫MVP接口,我們不懂為什么用他們,就算會寫也只是在做復制粘貼
舉個栗子
我們需要用戶點擊按鈕從網絡獲取一段新聞消息顯示到TextView上,如果都在Activity中做這些事情,OK,非常爽,不用多寫MVP相關的接口和類,啪啪啪一下就寫完了
但是我們現在需求變了,我們要加入緩存,并且不用TextView顯示,使用Toast顯示,現在去改Activity,雖然麻煩,但是沒問題都是你寫的,改改也沒問題,但是這個如果不是你寫的,你現在去改,要把邏輯重新看一遍,在重新修改之前的代碼,如果邏輯一復雜,你重新看一遍邏輯要時間,并且如果改錯的話,會影響之前已經寫好的功能,這完全違背開閉原則
但是我們用MVP去開發,就可以縮小這些問題,我們只需要在Model層加入緩存邏輯,因為Presenter層拿到的是Model的接口,他只關心Model層返回的數據,至于你的接口是怎么實現的,你的數據是從網絡還是數據庫還是本地文件獲取的,根本不必關心
Presenter拿到的也是View的接口,Presenter從Model獲取完數據,返回給View,就完成了他的工作,他根本不用管View是怎么實現的,使用TextView顯示還是Toast顯示,這些都是View的事情,所以他們每層只用把各自的事情做好根本不用管以外的事情
這樣我們就可以把View,Presenter,Model拿給三個不同的人寫,需求一變不會影響整個代碼,將問題最小化,比如UI需求一變我們只用修改View層,出了問題可以馬上定位,并且易于測試
Dagger
Dagger的門檻個人認為在這三個中是最高的,相關的文章也很多,但是都很多只是告訴你該怎么寫這些類,注解該怎么用,很多都沒講為什么不直接new,為什么要把如此簡單的事情弄這么復雜?其實這還是和項目的大小有關,因為它解決的問題就是大項目的需求
舉個栗子
- 我們現在需要一個類叫Car,Car中需要持有一個叫People的對象,People中又需要持有key對象,Ok,這還不簡單
Car car = new Car(new People(new Key()));
- 但是大型項目的實際情況是這樣的
A a = new A();
B b = new B(a);
C c = new C(a,b);
D d = new D(c);
E e = new E(a,b,d);
以上只是舉個例子,構建一個E,還要構建一堆其他的對象,并且其他對象的構建同樣復雜,并且必須按順序構建,而且需要的對象的生命周期都不一樣,有些生命周期可能和Activity一樣,有些可能是單例,所以在構建的時候還要考慮對象聲明周期,考慮對象的來源,在大型項目,這很痛苦,不光用起老火,別人看代碼也和看天書一樣,并且如果一個對象的構建方式發生改變,會影響整個的構建過程以及所關聯的代碼,牽一發而動全身
所以這個時候依賴注入框架就派上用場了,我們只用專注于怎么實現功能,對象的依賴關系和生命周期,都讓它來幫我們管理,一個Inject,它會按照依賴關系幫我們注入我們需要的對象,并且它會管理好每個對象的生命周期,在生命周期還沒結束的情況下是不會重復new的,所以Dagger非常適合大項目,小項目開發者因為項目復雜度低,沒遇到這些問題,所以不會理解為什么要用Dagger,讓簡單的new,變這么復雜
RxJava
提到Rxjava最多人都是用來處理,線程調度,回調地獄,加上
Retrofit又支持Rxjava,所以大部分開發者都只會在請求網絡和需要切換線程的時候用到Rxjava,其實它有一個最重要的特性,它可以讓數據的流向更加直觀,代碼更清晰
舉個栗子
- 比如說一個龐大的項目,一個事件傳遞的整個過程可能要經歷很多方法,方法套方法,每個方法的位置七零八落,一個個方法跳進去看,跳過去跳過來很容易把腦袋弄暈,不夠直觀,但是Rxjava可以把所有邏輯用鏈式加閉包的方式呈現,做了哪些操作,誰在前誰在后非常直觀,邏輯清晰,維護就會非常輕松,就算不是你寫的你也可以很快的了解,你可以把它看作一條河流,整個過程就是對里面的水流做進行加工,懂了這個特性我們才知道在復雜的邏輯中運用Rxjava是多么的重要
結語
學習新技術,我們不應該盲目的跟風,我們如果不知道這個技術為什么出現,出現是為了解決什么,我們也就不知道為什么運用它,我們就算在項目中使用也無法靈活運用,非常淺顯的使用,復制粘貼一些模版代碼,也根本無法擴展自己的思維
這些技術雖然比較適合大項目一點,但是還是建議各位開發者開始使用他們,使用他們能擴展自己的思維,讓自己考慮耦合,擴展,團隊協作之類大項目才會考慮的問題,你如果一直重復的按最簡單的方式寫項目,什么都不考慮,你就算是5年經驗,也只是以第一年的經驗重復5年
最后介紹一個將MVP,Dagger,Retrofit,Rxjava等技術相結合并用于快速開發的框架,如果想搭建一個新項目使用這些技術,改了包名就可以直接使用,包含詳細的文檔,相比于這些技術漫長的學習曲線,我們在實踐中學習他們不是更快嗎？后面我會寫一篇文章,介紹它是怎么將MVP,Dagger相結合并使用到項目中的
Where?
-- The end
