android架構學習之元件化

2021-09-22 23:08:55 字數 2823 閱讀 3423

新公司的專案採用了元件化,此前對元件化有過一些研究,但是相關的經驗並不多,正好新的專案有實際運用,在此記錄下元件化的學習與實踐之路。網上元件化的文章很多,本人學習組建化的過程也借鑑了網上先輩們的文章。但大多數文章都從底層的細枝末節開始講述,由下而上給人一種這門技術「博大精深」望而生畏的感覺。而我寫這篇文章的初衷就是由上而下,希望別人在閱讀的過程中能夠覺得「元件化原來也就是這幾個東西」的感覺。

1、本文主要內容

2、什麼是元件化

在編碼的過程中,不管在哪個年代,模組分層一定是永恆的主題。首先,軟體是由乙個團隊完成的,為了更好的更有效率的分工,模組分層必不可少。另外,模組分層更是為了減少耦合,易擴充套件同時維護時更省心省力。

例如android的架構圖,相信所有人都看過,從大的方面來講它也是分層的,各層之間通過介面通訊,比如c層和 framework層之間,就定義了很多的jni介面。

元件化,個人的理解就是更加精細一點的模組分層而已,它比模組來說,粒度更小而已,模組一般是指大的功能模組,比如首頁模組、直播間模組。而元件它是一種功能更加單一的模組,例如支付元件等等。

模組化是業務導向,元件化是功能導向。

元件化基礎架構圖

上面是乙個非常基礎的元件化架構圖,圖中從上向下分別為應用層、元件層和基礎層。

基礎層:基礎層很容易理解,其中包含的是一些基礎庫以及對基礎庫的封裝,比如常用的載入,網路請求,資料儲存操作等等,其他模組或者元件都可以引用同一套基礎庫,這樣不但只需要開發一套**,還解耦了基礎功能和業務功能的耦合,在基礎庫變更時更加容易操作。

一般來說,元件之間還需要互相通訊,但為了解耦,元件與元件之間是不能直接呼叫對方的

3、元件化要解決的問題

要實現元件化,需要解決幾個問題:

請大家一定要明白一點,元件化開發,元件就像積木一樣,可以方便整合也可以方便刪除,所以不能直接呼叫元件方法,明白了這點,就知道為什麼要實現2、3、4點了。第1點和第5點只是專案整合問題,有了androidstudio,很好解決

4、元件的單獨除錯及整合

元件的常見的有兩種型別,library以及正常的module,如果元件能被整合到主專案中,它此時就得是library,如果元件要單獨除錯,它此時就得是正常的module。為了滿足此目標,可以新建 gradle.properties,在裡邊新增乙個boolean值

isrunalone=false
定義了 isrunalone 值之後,更改build.gradle檔案,即可以在兩種型別之間自由切換:

if(isrunalone.toboolean())else
當然還有包名,甚至androidmenifest檔案都需要根據型別不同重新設定

if (isrunalone.toboolean())

sourcesetselse }}

元件又是如何被整合到主專案中呢?只要新增依賴即可:

implementation project (':base')

runtimeonly project(':login')

runtimeonly project(':share')

5、元件間通訊元件間的通訊,因為不能直接呼叫,所以只有一條路了,面向介面程式設計。例如現在有兩個元件,登入元件和分享元件,分享元件需要判斷登入狀態,只有登入成功了才能分享,所以登入元件需要向外部提供乙個查詢介面,登入是否成功。

面向介面程式設計,顯示需要先定義乙個介面,判斷是否登入:

boolean islogin();
同時這個介面是需要被多個元件一起使用的,比如登入和分享元件都要使用,那麼這個介面只能定義在乙個基礎的元件當中,然後其它元件依賴基礎元件即可。

介面已經定義,登入元件明顯需要實現此介面。登入元件實現以後,分享元件怎麼用到登入元件的實現呢?

/* */

/* */}

trycatch (exception e)

}} 所以總結一下,定義基礎元件,基礎元件中定義介面,元件實現介面並且註冊,主專案幫助元件實現介面註冊,這樣元件之間的通訊就能完成了。

6、元件介面跳轉

還是相同的原因,為了減少耦合,不能直接呼叫元件的activity,所以為了介面跳轉,只有乙個辦法了,使用arouter開源庫

7、主專案獲取並顯示元件的fragment

其實這和元件間的通訊類似,依然是面向介面程式設計的方式,元件提供實現並註冊即可。

8、總結

元件化並不複雜,本質上就是將模組更細化,更加的單一化而已。

想想as提供的這些功能,本質上也是mk指令碼的變化而已。

今天提供的示例,也只涉及了同程序間的通訊,跨程序通訊還沒有涉及,如果需要ipc,會更加的複雜。當然核心處理思想仍然是一樣的,面向介面程式設計,定義公共元件,所有元件都依賴公共元件即可。

元件化,最深刻的一條就是面向介面程式設計,可擴充套件程度高,希望在日後的工作當中,牢牢記住這一點,一旦涉及跨模組,如何解耦,這非常非常非常重要,面向介面程式設計的思維一定是一種非常好的解決方式。

有其他問題或者技術困惑的夥伴,可以**交流(備註技術交流)

Android元件化架構

元件化架構需要各個元件不僅能夠單獨執行而且也能無縫的整合到主程式中,在這個過程中會遇到以下問題 todo 在專案的根目錄下的gradle.properties檔案中宣告乙個變數ismodule 該變數能對整個專案中所有的gradle檔案生效 代表是否是元件開發模式。gradle.properties...

Android業務元件化之URL Scheme使用

先來個完整的url scheme協議格式 xl goods 8888 goodsdetail?goodsid 10011002通過上面的路徑 scheme host port path query全部包含,基本上平時使用路徑就是這樣子的。1.在androidmanifest.xml中對標籤增加設定s...

Android業務元件化之URL Scheme使用

先來個完整的url scheme協議格式 xl goods 8888 goodsdetail?goodsid 10011002通過上面的路徑 scheme host port path query全部包含,基本上平時使用路徑就是這樣子的。1.在androidmanifest.xml中對標籤增加設定s...