從MVP架構設計,引發的一些思考
最近一個多月,沒寫部落格,主要是因為公司最近的需求比較勤,在加上有點業餘時間,自己去看Kotlin和React了。這幾天有人跟我說mvp這個架構不會用,甚至看不太懂,即使網上有很多介紹,部落格,也看不透。這些人大部分是工作了2年左右時間,大家感覺自己的技術還是不行,在公司看些老程式碼,改改bug,技術沒有啥提升。聽到這些,我最近有了些思考。於是寫寫,與大家共勉!
先說下mvc,從android一開始,我們新建一個工程時,它就是一個mvc,然後我們會根據不同的業務,不同的功能,新建不同的package。這樣寫沒啥毛病。但是在寫程式碼的時候,毛病就來了。比如對Recyclerview泛型構建基類、封裝不理解,或者不會。甚至一個一個去寫Adapter,碰到多種不同Type的佈局,然後一個一個去寫,判斷不同的Type。在比如對網路層的封裝,壓根不利於擴充套件,封裝網路層喜歡放到一個工具類裡面,當做一個工具類來看。這種程式碼很多人寫過,我當初也寫過。但是我現在看來,這種寫法比較low,比如要增加一個下載的功能,或者要更換一個網路庫,是不是要動以前的程式碼,甚至要動很多。舉了兩個簡單例子,我相信很多人都碰到過、寫過,我當初寫過這種程式碼。為什麼會這樣,因為很多中小公司,android開發人員1-3個人,就別談程式碼ReView了,有個技術總監對Android有深入的學習,有經驗還好些,旁邊有人帶你,會好很多。但是也有很多技術總監是不會android的。現在想想,以上兩個例子的程式碼維護起來,看起來,或者離職了,留給別人看,不都是一個個“坑”。像這種型別的程式碼還有很多例子,時間久了,app的業務量多了,程式碼還怎麼寫下去,維護下去?是否可以考慮下重構下別人寫的程式碼,或者一些基類可以自己寫,多考慮下程式碼如何擴充套件?如何封裝?是否可以採用設計模式?如果碰到程式碼風格亂來,只能欲哭無淚了!
在說下Android的mvp架構設計,我們都知道mvp架構設計,是為了解決mvc的痛點,隨著業務增加,Activity會有很多的程式碼,會很臃腫,與後臺的互動會越來越多,與Model層的耦合性很高,更加不利於單元測試。於是有人提出了mvp的架構設計,mvp中的Presenter就解決了這個問題,與後臺的互動,業務的處理交給Presenter,Activity顯示下資料就行,Activity和Model層沒有了直接的聯絡。利於維護,也利於單元測試。但是在設計mvp時,會有很多問題,一、Activity需要實現View層的介面,Presenter對這個又要持有引用(是為了解決View層中的介面回調出來,顯示資料)。如果Activity退出了怎麼辦,Presenter對這個Activity持有引用,會不會造成記憶體洩漏呢?二、多個Presenter怎麼解決?因為一個Activity可能會涉及到多個業務邏輯處理。三、mvp中會很多的類介面,怎麼處理? 以上幾個問題,我之前的部落格有介紹,具體的怎麼解決,我在這不闡述,因為涉及到的知識點比較多!
說了下mvc和mvp,是不是該說下mvvm呢,mvvm對於mvp來說,是為了解決mvp的痛點,p層去回撥v層的介面,一是介面類多,二是生命週期難以控制。於是Google出了DataBinding繫結資料,在也不需要那麼多的類介面了。Android Jetpack架構元件又有了LiveData和ViewModel,簡單介紹下LiveData和ViewModel,LiveData是一個可被觀察的資料持有者類。與常規的Observable不同,LiveData能意識到應用程式元件的生命週期變化, 這意味著它能遵守Activity、Fragment等元件的生命週期。這種意識確保LiveData只更新處於活躍狀態的應用程式元件Observer。ViewModel從字面上理解的話,我們也能想到它肯定是跟檢視(View)以及資料(Model)相關的。 正像它字面意思一樣,它是負責準備和管理和UI元件(Fragment/Activity)相關的資料類,也就是說ViewModel是用來管理UI相關的資料的。同時ViewModel還可以用來負責UI元件間的通訊
mvc、mvp、mvvm三者如何選型呢?這三者沒有那個不好,只不過是隨著業務的增加,某架構設計缺點突出來了。如果一些工具類、針對部分使用者群少或者app的業務量少。這些型別的app完全可以用mvc。如果後臺與業務邏輯互動比較多,app更新比較頻繁,那就得考慮用mvp了,比如電商型別的app。至於mvvm呢,列表展示資料比較多,比如新聞媒體型別的app。
總結下,上面描述了一些問題,主要是為了總結和我的一些思考,很多人對泛型看不懂、不理解,泛型不會靈活運用。編譯時註解和執行時註解不會,反射用的少。比如常用的設計模式,觀察者設計模式、介面卡設計模式、靜態和動態代理設計模式等等,這些設計模式能看懂簡單的例子,但是不太會用到專案中。介面不會靈活運用。常用資料結構看不懂,不會,比如棧、堆、連結串列、佇列。多執行緒不太理解。列舉的這些知識點,其實每個app都會用到,我們每天敲程式碼,也會碰到和運用。如果這些不會,大家趕快去補補基礎的知識,在看看別人優秀的app,優秀成型的架構,看看別人怎麼設計的。看懂了,然後自己敲敲程式碼,自己多多體會。寫一些開源的東西,然後自己維護,不單單要運用到公司的app中。知識點運用起來,才會對知識點有更深的理解。學的東西,一定要多運用!
谷歌官方架構元件的sample,現在谷歌官方的simple,很多都是用Kotlin寫的,正好學習下Kotlin。看看Google工程師寫的程式碼、設計思路,還有程式碼風格,一個專案經過不同的人開發,有的人程式碼風格low,命令亂來,沒有統一的規範,我認為程式設計師程式碼要有自己的風格,形成敲程式碼的一種習慣。
https://github.com/googlesamples/android-architecture-components
這小子(輝哥)寫的部落格,講的視訊不錯,android整個知識體系都有,而且思路很清晰,講解的視訊基本上都是專案上運用到的。ndk、資料結構都有講。我從17年下半年和18年上半年他講的視訊,我幾乎每集都看了,很不錯的!
https://www.jianshu.com/u/35083fcb7747
在推薦我經常看的部落格JessYan和Tamic,列出了簡書的,人家還有掘金、公眾號,大家感興趣,可以關注!
https://www.jianshu.com/u/1d0c0bc634db
https://www.jianshu.com/u/3bbb1ddf4fd5
以上那裡有說的不對,哪裡總結的不對,歡迎大家指出來,互相交流切磋武藝,大家都在江湖漂~
如果可以幫到你,可以掃一掃,讚賞下!
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20181217091729610.png)