這是知天氣實(shí)踐中的架構(gòu)搭建方式，建議先下載應(yīng)用【應(yīng)用寶，或騰訊bugly分發(fā)平臺】體驗(yàn)下，以免浪費(fèi)你的時(shí)間O(∩_∩)O~~。

項(xiàng)目的構(gòu)架搭建過程包括MVP的使用，MVP使用中P層的組織，Model層的管理，以及劃分P層和Model層的理解。除了項(xiàng)目的框架部分，結(jié)構(gòu)分包方式也很重要，一個(gè)好的分包方式能讓項(xiàng)目更加清晰，開發(fā)過程也會(huì)更有效率。除此之外，再加上一些第三方開源框架就能很好的搭建出一個(gè)Android應(yīng)用了。

MVP的使用（縱向）

關(guān)于MVP的介紹和優(yōu)點(diǎn)分析的文章很多，可以自行g(shù)oogle。主要分析項(xiàng)目中的應(yīng)用。

MVC

MVC全名是Model View Controller，如圖，是模型(model)－視圖(view)－控制器(controller)的縮寫

MVC是一種軟件設(shè)計(jì)典范，用一種業(yè)務(wù)邏輯、數(shù)據(jù)、界面顯示分離的方法組織代碼，在改進(jìn)和個(gè)性化定制界面及用戶交互的同時(shí)，不需要重新編寫業(yè)務(wù)邏輯。MVC是一種很被廣泛使用的框架，但在Android開發(fā)中，Activity并不是一個(gè)標(biāo)準(zhǔn)的MVC模式中的Controller，它的首要職責(zé)是加載應(yīng)用的布局和初始化用戶界面，并接受并處理來自用戶的操作請求，進(jìn)而作出響應(yīng)。隨著界面及其邏輯的復(fù)雜度不斷提升，Activity類的職責(zé)不斷增加，以致變得龐大臃腫。

MVP

MVP從更早的MVC框架演變過來，與MVC有一定的相似性：Controller/Presenter負(fù)責(zé)邏輯的處理，Model提供數(shù)據(jù)，View負(fù)責(zé)顯示?？梢钥醋鯩VP就是將MVC中Controller更加細(xì)分開來，減少Controller的體積，這很好理解，如果一個(gè)類過于龐大，不妨在將其細(xì)分，除此之外將View和Model的通信隔絕，都通過Presenter來傳遞。

這里箭頭的指向值得是依賴關(guān)系，Model不應(yīng)該依賴上層的邏輯，所以應(yīng)該是單向的。

MVP在Android中的體現(xiàn)

• View:負(fù)責(zé)繪制UI元素、與用戶進(jìn)行交互(在Android中體現(xiàn)為Activity，frament等等)
• Model:負(fù)責(zé)存儲(chǔ)、檢索、操縱數(shù)據(jù)(有時(shí)也實(shí)現(xiàn)一個(gè)Model interface用來降低耦合)
• Presenter:作為View與Model交互的中間紐帶，處理與用戶交互的負(fù)責(zé)邏輯。
• *View interface:需要View實(shí)現(xiàn)的接口，View通過View interface與Presenter進(jìn)行交

使用

上面的框架只是一些理論式的知識，具體的應(yīng)用中還需要更加詳細(xì)的設(shè)計(jì)，如：

• Presenter具體是什么，該怎么和View層交互
• Model層和Presenter怎么劃分，怎么管理
• 對應(yīng)到Android項(xiàng)目中的生命周期是怎樣的
• 不同層之間的通信方式
• 使用中應(yīng)該注意什么

Presenter其實(shí)就是一些普通的類，只是負(fù)責(zé)將View層（Activity等）中的只和當(dāng)前View的業(yè)務(wù)邏輯放在這一層來避免隨著業(yè)務(wù)的增多導(dǎo)致View層過大，如很多應(yīng)用的主界面，然后通過接口來和View交互。生命周期也應(yīng)該和View保持一致。并要注意避免由于持有View的引用而導(dǎo)致View結(jié)束時(shí)內(nèi)存泄露的產(chǎn)生。

Presenter層和Model的劃分問題，經(jīng)常見到的說法是Model層應(yīng)用于封裝與應(yīng)用程序的業(yè)務(wù)邏輯相關(guān)的數(shù)據(jù)以及對數(shù)據(jù)的處理方法，如數(shù)據(jù)的存儲(chǔ)與獲取等。這種說法沒什么問題，但是和Presenter在一起使用的時(shí)候容易讓人迷惑，Presenter也是處理邏輯，Model也是處理邏輯，那應(yīng)該怎么區(qū)別呢，我的理解是看這些邏輯能否被共用，如果能被多個(gè)View或Presenter共用，那這部分邏輯應(yīng)該放到model層，否則應(yīng)該在Presenter。Model由于共用的原因，所以其生命周期應(yīng)該和應(yīng)用的生命周期保持一致，而寫需要一個(gè)管理類ModelManager來統(tǒng)一管理。

對于View層與Presenter層，通過接口的方式進(jìn)行通信，所以View與Presenter是強(qiáng)依賴關(guān)系，是共同存在。而Presenter層與Model層則是通過事件總線庫如EventBus，我是用的Router，主要是用起來更方便。這樣Presenter層與Model層關(guān)系是弱依賴，因?yàn)樗鼈兊纳芷诓煌?，而且一個(gè)Model肯需要對多個(gè)Presenter服務(wù)。

下面是總結(jié)出來的框架圖：

結(jié)合上面的圖在總結(jié)一下，Presenter應(yīng)該是單一職責(zé)的，只用于處理一個(gè)View的邏輯，而一個(gè)View可以有多個(gè)Presenter，以避免如果View中邏輯過多而導(dǎo)致單個(gè)Presenter過于龐大臃腫。而Model層應(yīng)該被共用，以體現(xiàn)其復(fù)用性。

在實(shí)際的使用中應(yīng)該注意的是：

1.不要死板的按照這個(gè)框架，不是任何View都需要一個(gè)Presenter，有些View可能只是個(gè)很簡單的頁面，再去寫個(gè)Presenter就真的為了框架而框架了，這時(shí)候框架對你的開發(fā)起到的反而是阻礙作用。

2.注意Presenter持有View導(dǎo)致的內(nèi)存泄露問題，因?yàn)槎呤菑?qiáng)依賴關(guān)系，所以在View相應(yīng)的生命周期對Presenter進(jìn)行綁定和解綁，也可以通過若引用來持有View對象，但我覺的這是可以自己來避免的，用若引用來處理的方式是一種不好的思想。

MVP搭建的縱向的框架，橫向的分割依據(jù)AOP面向切面的思想，主要是提取出共用方法作為一個(gè)單獨(dú)的Util，這些Util會(huì)在App整體中穿插使用。很多人的App都會(huì)引入自己封裝的Jar包，封裝了包括文件、JSON、SharedPreference等在內(nèi)的常用操作，自己寫的用起來順手，也大幅度降低了重復(fù)作業(yè)。

項(xiàng)目劃分方式

框架搭好后，還需要好的分包方式來管理，我偏向于先根據(jù)模塊劃分，然后在不同的模塊里在再按邏輯劃分。這樣可以很好的使項(xiàng)目模塊化，而且開發(fā)的時(shí)候更方便。

不要畏懼構(gòu)架，也不要過度設(shè)計(jì)，具體過度設(shè)計(jì)的度，可能就需要經(jīng)驗(yàn)了，但不實(shí)踐，永遠(yuǎn)也不會(huì)有這個(gè)經(jīng)驗(yàn)。

知天氣已開源