關於Android架構那些事

標籤：

　　剛開始，因為業務比較趕，我們也沒有進行比較好的頂層設計，對代碼的要求也是最低要求——完成功能開發就行了。這種短期設計也就造成了我們代碼的擴充性幾乎為零，稍微添加一點新功能，都要大動幹戈。在後台系統架構從TCP轉為HTTP時，這些缺點則被放大到極致……所以，我們只有重構了。近一個月來，我工作的重心便是好好規劃和設計我們項目的代碼結構，同時分享給我們的Android組並予以實行。因為研究了很多的架構，其中有Android相關的，也有非Android相關的，但凡稍稍對我設計架構有點點協助的，我都翻了一遍。甚至還去瞭解了，微博的一些項目架構資訊~

　　然而在這個過程中，我發現，其實Android並沒有像Java後台開發那樣有著比較穩定的架構，可以直接套用，基本都是各有各的看法和規則。目前碰到的討論最多的也就是所謂的MVC、MVP、MVVM這類的MVX架構。為了我們的中心思想做鋪墊，那我們來一個個分析一下這些所謂的名門正派到底是不是真的如我們想的那樣。

　　一、MVC那些事

　　我們先來看看MVC，因為MVC經常在Android開發中被提起。我們就先來看看MVC這種結構，通常情況下，也就是你面試的時候回答關於MVC的問題時，用到的答案。

　　MVC 通訊方式，是環形方式，如下左圖所示：View 傳送指令到 Controller；Controller 起到不同層面間的組織作用，用於控制應用程式的流程。它處理事件並作出響應。“事件”包括使用者的行為和資料 Model 上的改變；Model 將新的資料發送到 View，使用者得到反饋，所有通訊都是單向的。

　     　          

理論上，還是挺合理的，但實際上，我們很容易就發現了他們耦合的比較深。通常一個改動，基本三大層級都要有改動，因為他們的觸發具有很強的連貫性。更具體的情況，就是如果你是真的寫代碼而不是停在理論上，實際上MVC這種結構更應該用上右圖去描述，也就是V的外部串連都是雙向的，因為M有需要更改V的需求，同時Controller也有。

　　好，我們現在移步到Android，假設我們套用MVC這種架構去處理Android的問題，顯然，那一堆XML就是View，而Activity便是所謂的Controller，Model便是我們定義的那些資料對象。但是顯然Android裡面XML作為View層簡直弱得有點螳臂當車的感覺，除了設定點屬性，幾乎不能做任何邏輯操作。所以，通常我們都會為了增強View的功能，而把Activity+XML作為View層。然而實際上，這樣一個組合已經遠遠超過了View的能力範圍了，因為Activity通常也要承擔很多邏輯操作，即所謂的Controller的職責……Now we are totally mixed up！因為你已經無法準確分層了。因為MVC的套路主要是應用在強View的開發模式下的，比如案頭應用，因為只要View足夠強才能發揮MVC的威力，顯然Android原生不具備這個能力，除非你自己寫一套View架構，這裡說的不是那些什麼注入的工具類，那些只是幫你減少代碼量而已，並沒有從根本上解決這個問題，這裡的View架構，是一套增強Android原生View的架構。

　　所以，顯然原生MVC並不適合直接使用到開發過程中，這裡加個原生MVC是針對於“那個標準答案”而言的，因為如果如果你衍生，修正過了就另當別論了~

　　二、MVP那些事

　　MVP可以說就是從MVC衍生過來，因為有問題就解嘛。既然MVC不夠好，那我們就修正它！於是MVP就出來（雖然最初MVP也是如同MVC一樣都是應用案頭應用的…）。如下左圖所示：

                                      

　　MVP 通訊方式：各部分之間的通訊，都是雙向的；這裡View 與 Model 不發生聯絡，全都通過 Presenter （你喜歡也可以叫Controller~）傳遞。這種結構便非常適合Android的View層，因為MVP結構中View 非常薄，不部署任何商務邏輯，基本屬於”被動視圖”（Passive View），即沒有任何主動性，當然也就意味著 Presenter會非常的非常厚，所有邏輯都部署在那裡。而實際上，我們使用的時候，則更趨於上右圖，因為既然Presenter已經責任重大，再多點也沒什麼事，反而更好統一管理……於是我們便就把Model的能力也削弱一點，也就是Model層完全被動提供資料，類資料庫模式。

　　我個人認為升級到MVP其實已經挺好的了，至少結構上已經比MVC要更清晰一些了，唯一的問題是我們Presenter有點過重了，還是有改進的地方，我們會在後文一一道來。

　　三、MVVM那些破事

　　為什麼用MVVM那些“破事”呢？因為我們發現至少目前，我沒有看到一篇比較正常的關於MVVM在Android上的分析。因為現在Android裡面現在一提到MVVM就是Dagger，好像Dagger=MVVM一樣……但其實不是這樣的，Dagger類工具，僅僅是為了實現View和Model的自動雙向繫結而已，也就是本來應該調用view.setXXX去把Model的值賦給View去展示，現在不用了（這個“不用了”，僅僅是說程式員不用顯性寫這段代碼而已……），所以MVVM中所謂的View-Model可以說就是Presenter，只是由於我們有了資料的雙向繫結工具後，就使得中的Presenter與View的聯絡變成虛線了，而與Model保持雙向串連，Model則與View綁定在一起。所以，與其說MVVM是MVP的最佳化，不如說是對MVC的最佳化。MVP和MVVM僅僅是通過兩種不同的方式去最佳化MVC——MVP選擇繼續分層，而MVVM選擇減少分層。也許，你看完上面可能對這些所謂的MVX依然沒什麼特別的感受。從分割線開始，我們便開始更深入地思考我們遇到的這些問題~

 　　無論是MVC，MVP還是MVVM，他們更像是一種軟體開發的思想而不是一種模式。因為如果你把他定義為模式，你會發現他們在移動端，移動端有分IOS，Android和WP等，還有web端，PC端等實現的方式總是有一定的區別。就比如MVC，有些實現的是一種順時針的方案，有些則會把mv隔離，全接在C上。就如同我上面舉的例子一樣，可能有些人會覺得，不對吧，不是另外一張圖嗎？但是當他們繼續依賴搜尋引擎的時候，他們就會淩亂了，因為有各種邏輯架構圖而且各有各的道理，最要命的是沒有人會說哪個是錯誤的。事實上，從你開始尋找他們的模版開始就已經誤入歧途了。

　　只有把這些所謂的架構看作是問題的一種解決思想時，我們才可以基於不同平台，不同的業務需求等現實而具體的問題去實現這種思想。說白了就是，馬克思主義指導思想很好，但必須要符合中國國情。我們基於以上新的思想再回過頭去看看我們之前碰到的問題，是不是很明朗？就比如MVC，無論它有多少中變種，它們都是為了更好地實現MVC分層解偶的理念而已。　　大家去網上搜一下android MVVM，有沒有感覺幾乎都涉及databinding，然後再介紹一番databinding的用法……然後就沒了（稍微補充一下，這個問題你用google又會稍好一點~）。而很顯然，基於我們建立立的思想，這些博文可以完全是片面且誤人子弟的。因為databinding只是為了實現mvvm這種思想的一個環節的一個工具而已，那就是幫你把view和model綁定起來，如果沒有這個工具，你要去實現mvvm的思想，你自己也會寫一個binding的Util類去做這件事。其次，綁定完成後，就要操作跟業務息息相關的ViewModel。如果簡單，那我們為何需要如此複雜的實現？(大家都知道，我們有些頁面其實真的挺簡單的，簡單到你都不好意思說是你做了~)。如果商務邏輯複雜，你依然需要別的思想去分解這個龐然大物。 　　說這些，既是為了能夠讓大家多一個角度去看待這些所謂的模式。同時，也是想提醒大家不要太依賴網上的那些搜尋，這其中既包括部落格也包括github。因為Real大神真的很少，偽大神遍地都是。我們搜尋盡量以參考為主，copy為輔。而不是反過來~這裡順便舉個例子，如果哪位同學用過itemtouchhelper，並且還網上搜過，你就會發現，整個宇宙就那一個例子（你一搜就知道…），而實際上，只要看一下ItemTouchHelper的源碼，你就會發現完全有更友好的辦法~ 　　我們迴歸正題，那就是所有的軟體架構以及開發思想，都是為了四個目的：Maintainable、Testable、Flexible 、Independent。也就是，使軟體在滿足需求的基礎上能夠更好地維護、測試、擴充以及相對獨立。　　 好維護意味著代碼結構清晰，便於理解和修改； 　　好測試意味著模組相對獨立，耦合度低，外部依賴都是保持引用； 　　好的擴充意味著介面規範，可以隨時延伸業務； 　　相對獨立意味著與外部系統能相對獨立地運行狀態；　　其他都好理解，但是什麼叫好的獨立性？我們假設IOS也是用java開發的，你如何讓你這一套代碼能夠平滑的從Android遷移到iOS？你是不是得定義一個比較好的視圖介面以及一些別的涉及到系統API的介面，當遷移到IOS，你只要去實現這些介面就可以讓代碼正常的運行在IOS系統上。其實說白了就是要把自己的APP當做一個獨立系統去開發，就是假設外部依賴都有可能改變，不僅僅是指後台，甚至還包括系統本身。我們都要能夠應付得來。　　本來想繼續寫下去的，但是我想，結還是把我的一張PPT放上來作為結束語，讓大家慢慢體會吧。因為思想到實踐總是會因為實際的環境而有所差異，但是，核心的那些主旨永遠都不會變~             

 

關於Android架構那些事