Android基礎知識：項目架構基礎概述

一、前言

前段時間因爲工做須要，學習了關於組件化和插件化架構相關的知識。查閱了不少Android開發架構的資料，組件化本身寫了個簡單的Demo而且開始了原有項目的改造，插件化本身也嘗試了滴滴的VirtualAPK框架。這篇記錄一下架構方面的相關知識總結以及本身學習後對模塊化、組件化和插件化這三化概念的理解。具體的搭建組件化方法能夠看我寫的這篇文章。Android組件化入門：一步步搭建組件化架構。

二、MVC、MVP、MVVM

2.1 MVC

Model-View-Controller，即模型－視圖－控制器。Model負責獲取數據，View負責界面展現，Controller負責交互控制，是最經典的架構模式。例如Android中的ListView就是MVC運用的典型例子。界面裏的ListView是View，Adapter是Controller，數據集合是Model，Model和View經過Adapter這個Controller聯繫起來。MVC架構使得代碼之間分工明確，下降了代碼耦合性，提升了代碼重用性。可是MVC中View和Controller聯繫太過緊密，Android開發中每每把Activity充當Controller的角色，使得Activity的代碼過於龐大。

2.2 MVP

Model-View-Presenter，和MVC相似，Model負責獲取數據，View負責界面展現，Presenter做爲中間調度者，負責交互邏輯控制。在MVP中Model和View間沒有任何聯繫，全靠Presenter進行傳遞控制，使得Model和View徹底的隔離，而且Presenter還能夠重用。Android開發中使用MVP將控制邏輯從Activity中轉移到Presenter中，大大減輕了Activity的負擔，讓Activity單純的充當View的角色。

2.3 MVVM

Model-View-ViewModel，仍是和以前的相似，Model負責獲取數據，View負責界面展現，而ViewModel成爲了View和Model溝通的橋樑，經過數據綁定技術實現了數據與界面的雙向綁定，數據有變更了通知界面更新，界面數據有改動通知數據也修改。Android中經過Google官方推出的DataBinding上來實現數據的雙向綁定，MVVM模式進一步下降了代碼耦合性。

三、模塊化

關於模塊化，我第一次接觸Module是在開始使用Android Studio的時候，相比原來使用Eclipse的時候多了這樣一個Module的概念，這個Module就是模塊。

在剛開始學習開發的時候或者開發一個單一功能應用的時候，由於功能簡單，因此項目架構也能夠很簡單，或者說也不須要什麼架構，所有寫在一個模塊裏問題也不大，並且用這種方式開發上手快，開發效率高，沒有這樣那樣的設計模式，啥也不用管，拿起鍵盤就是碼，簡單粗暴，對新手而言十分的友好。

單一模塊項目

模塊化

可是一旦項目的業務功能稍微複雜一些，或者是多人協做開發，這種簡單粗暴的方式就不行了，開發效率直線降低，全部功能的代碼耦合在一塊兒，簡直是一團亂麻，多人開發面對不是本身寫的代碼更是噩夢，這樣開發不只耦合度高，並且代碼冗餘也會很高。因此Android開發者按照原前後端的項目開發方法，開始使用MVC的分層架構進行開發，這樣讓代碼結構更加清晰，耦合度和冗餘也大大下降。在MVC使用了一段時間以後又相繼出現了MVP、MVVM等適合移動端的分層架構方式，這些架構的出現讓複雜項目的開發也變得僅僅有條，各層代碼分工明確，邏輯清晰，項目開發效率也有顯著提升。可是光光這樣還不夠，單模塊的項目架構在迭代久了以後，代碼量變大，變得十分臃腫。因此不只要將代碼分層，還須要根據業務邏輯將單模塊項目拆分紅多個業務模塊，抽出公共模塊和基礎模塊。這樣多模塊的開發就是模塊化。在開發中修改一行代碼就能引入Module或者剔除Module，也是很是的靈活方便。

引入不一樣模塊

模塊化的開發進一步下降了代碼的耦合，每一個模塊各司其職，解決了單個模塊的臃腫問題。多人開發過程當中，每一個人負責不一樣模塊，分工明確，效率也會提升。這種多模塊加分層架構解決了項目開發中的大部分問題，也最簡單常見的架構模式。

模塊化多個模塊

四、組件化

在模塊化開發了一段時間以後，隨着項目業務的增長，模塊愈來愈多，又會出現一些問題。例如：

• 因爲模塊太多使得每次調試都要編譯整個項目，編譯速度太慢。
• 項目運行依賴於全部模塊，模塊間如有衝突，使開發這這沒法專一於單個模塊的功能。
• 多個項目要使用一個模塊時，沒法對業務模塊進行靈活的組裝

組件化很好的解決了這些問題。經過一個APP空殼工程，將多個組件組裝成一個應用。組件化爲單個組件配置了單獨的啓動入口Activity，使得單個組件既能夠做爲application單獨運行，又能夠做爲library引入項目。這樣在多人開發時，每一個開發者只須要專一於本身組件的功能問題，調試時只須要調試單個組件，只編譯一個組件大大提升了編譯速度，提高了開發效率。並且還能夠將一些經常使用組件打成aar包進行單獨版本維護，在其餘項目須要時直接引入就行。 組件化其實和模塊化有點相似，我以爲能夠這樣理解，組件化就是模塊化的一個升級增強版，組件化比起模塊化更加的靈活，耦合度更低，並且單個組件能夠獨立運行，沒必要每次編譯整個項目，提升了開發效率。

組件化

組件化工程

組件能夠做爲單獨應用運行

五、插件化

插件化技術的產生也是相似，因爲業務進一步複雜，項目規模進一步的變大，模塊越也來越多，耦合度變高，而且有時候需求要求再也不是單獨的應用，可能要接入其餘應用的業務功能，並且太多個組件接入應用會使得應用的體積變得很大，並且編譯時間也會變的很長。還有Android中655536方法的限制，模塊增多代碼增多方法很容易就超過65536個，並且應用也會佔用很大內存。因此插件化技術應運而生，插件化技術從本質上來講是一種動態加載技術。插件化中存在宿主APK和插件兩個概念，宿主APK就是指先被安裝到手機中的APK，插件指通過處理的APK、so、dex等文件，插件能夠被宿主進行加載。插件化的應用一開始加載到內存的只有宿主應用，當使用到其餘插件時纔會加載對應插件到內存中，減小了內存的佔用。如今不少大廠都早已推出了本身的插件化框架，例如VirtualApk、RePlugin等等。

插件化

六、總結

內容自己比較簡單，就是基礎概念的總結。對於開發架構的選擇來講，沒有最好的架構只有最合適的架構，規模大業務多的項目不選擇好合適的架構，項目開發將沒法順利進行，功能單一內容簡單的項目也不必什麼技術架構都往項目裏上，徒增開發成本。只有使用最合適本身項目的架構才能保證項目開發能快速、高效、順利的進行。