最近一個多月，沒寫部落格，主要是因為公司最近的需求比較勤，在加上有點業餘時間，自己去看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元件間的通訊

。看了介紹，想想看，這不是基於觀察者設計模式設計的嘛，dataBinding、LiveData和ViewModel 這三者是不是解決了mvp的痛點呢！至於LiveData和ViewModel會用很多種用法，比如用LiveData替換RxJava2中的Observable，用LiveData支援Room，如果我們專案中用到了對資料庫的操作，是不是該換Room了，Room使用起來很簡單，我們只關心介面Dao層和如何建立資料庫，利於維護和擴充套件。Android Jetpack新一代架構元件，反正很好用，大家多看看，多運用。都是Google Android工程師寫的，這麼好的程式碼不看，還看什麼程式碼？

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

以上那裡有說的不對，哪裡總結的不對，歡迎大家指出來，互相交流切磋武藝，大家都在江湖漂~

如果可以幫到你，可以掃一掃，讚賞下！