Android組件化

Android組件化的優缺點

組件化開發的優勢：系統級的控制力度細化到組件級的控制力度。一個複雜系統的構建最後就是組件集成的結果。每一個組件都有本身獨立的版本，能夠獨立的編譯、測試、打包和部署。

產品組件化後可以實現完整意義上的按需求進行產品配置和銷售，用戶能夠選擇使用那些組件，組件之間能夠靈活的組建。

配置管理、開發、測試、打包、發佈徹底控制到組件層面。這樣在一個組件小版本進行升級若是對外提供的接口沒有發生任何變化，其餘組件徹底不須要再進行測試。

組件化開發的缺點：組件化對開發人員和團隊管理之提出了更高水平的要求。相對於傳統的開發模式，要求開發人員對業務有更深層次上的理解，劃分好每一個組件。

Android項目開發方式

簡單開發模型

所謂簡單開發模型是最基礎的開發方式，工程中沒有所謂的模塊，沒有規劃，以下圖

開發過程當中每每是在一個界面中存在着大量的業務邏輯，而業務邏輯中充斥這各類網絡請求，數據操做等行爲，整個項目中沒有所謂的模塊的概念，項目的基本組成單位不是模塊，而是方法級的。

單工程開發模型

這種開發模型已經有了明確的模塊劃分，而且經過邏輯上的分紅出現了較好的結構，這種模型一般用於早期產品的快速開發，團隊規模較小的狀況下。開發模型結構以下：

 

隨着產品的迭代，業務愈來愈複雜，隨之帶來的是項目結構複雜度的極度增長，此時咱們面臨着幾個問題：

實際業務變化很是快，可是工程以前的業務模塊耦合度過高，牽一髮而動全身。

對工程所作的任何修改都必需要編譯整個工程。

功能測試和系統測試每次都要全量測試。

團隊協同開發存在較多的衝突，不得不花費更多的時間去溝通和協調，而且在開發過程當中，任何覺得成員沒辦法專一於本身的功能點，影響開發效率。

不能靈活的對工程進行配置和組裝。

 面臨以上問題，單線程開發模型已經不能知足團隊須要了，咱們要使用新的開發模型。

主工程多組件開發模型

藉助組件化這一思想，咱們在"單工程"模型的基礎上，將業務中層中的各業務抽取出來，封裝成相應的業務組件，將基礎庫中各部分抽取出來，封裝組成基礎組件，而主工程是一個可運行的app，做爲各業務組件的入口（主工程也被稱爲殼程序）。這些組件或以jar形式呈現，或以aar的形式呈現。主工程經過以來的方式使用組件所提供的功能。

 

 

（須要注意的是在實際的項目中，業務組件之間會產生通訊，也會有依賴管理）

不管是jar仍是aar,本質上都是Library,他們不能脫離主工程而單獨的運行.當團隊中成員共同參與項目的開發時,每一個成員的開發設備中必須至少同時具有主工程和各自負責組件,不難看出經過對項目實行組件化,每一個成員能夠專一本身所負責的業務,並不影響其餘業務,同時藉助穩定的基礎組件,能夠極大減小代碼缺陷,於是整個團隊能夠以並行開發的方式高效的推動開發進度.

不但如此,組件化能夠靈活的讓咱們進行產品組裝,要作的無非就是根據需求配置相應的組件,最後生產出咱們想要的產品.這有點像玩積木,經過不一樣擺放,咱們就能獲得本身想要的形狀.

對測試同窗而言,能有效的減小測試的時間:原有的業務不須要再次進行功能測試,能夠專一於發生變化的業務的測試,以及最終的集成測試便可.

到如今爲止,咱們已經有效解決了」單工程開發模型」中一些問題,對於大部分團隊來講這種已經能夠了,可是該模型仍然存在一些能夠改進的點:每次修改依賴包,就須要從新編譯生成lib或者aar.好比說小顏同窗接手了一個項目有40多個組件,在最後集成全部組件的時候,小顏同窗發現其中某組件存在問題,爲了定位和修改該組件中的問題,小顏同窗不斷這調試該組件.因爲在該模型下,組件不能脫離主工程,那麼意味着,每次修改後,小顏同窗都要在漫長的編譯過程當中等待.更糟糕的是,如今離上線只有5小時了,每次編譯10分鐘,爲改這個bug,編譯了20次,恩….什麼也不用幹了,能夠提交離職報告了

如何解決這種每次修改組件都要連同主工程一塊兒編譯的問題?下面咱們來看主工程多子工程開發模型是如何解決該問題的.

 

主工程多子工程開發模型

該種開發模型在」主工程多組件」開發模型的基礎上作了改進,其結構圖以下:

 

不難發現,該種開發模型在結構上和」主工程多組件」並沒有不一樣,惟一的區別在於:全部業務組件再也不是mouble而是做爲一個子工程,基礎組件可使moudle,也能夠是子工程,該子工程和主工程不一樣:Debug模式下下做爲app,能夠單獨的開發,運行,調試;Release模式下做爲Library,被主工程所依賴,向主工程提供服務.

 

在該種模型下,當小顏同窗發現某個業務組件存在缺陷,會如何作呢?好比是基礎組件2出現問題,因爲在Debug模式下,基礎組件2做爲app能夠獨立運行的,所以能夠很容易地對該模塊進行單獨修改,調試.最後修改完後只須要從新編譯一次整個項目便可.

 

不難發現該種開發模型有效的減小了全編譯的次數,減小編譯耗時的同時,方便開發者進行開發調試.

 

對測試同窗來講,功能測試能夠提早,而且可以及時的參與到開發環節中,將風險降到最低.