[[382121]]

本文轉(zhuǎn)載自微信公眾號「咸魚正翻身」，作者M(jìn)Dove 。轉(zhuǎn)載本文請聯(lián)系咸魚正翻身公眾號。  

前言

這篇文章是一個ASM的實戰(zhàn)篇，并沒什么什么傳統(tǒng)搜到的插樁System.currentTimeMillis()計算方法耗時的實戰(zhàn)。而且為項目組件化實現(xiàn)一套服務(wù)發(fā)現(xiàn)的基礎(chǔ)能力。

個人認(rèn)為組件化是一個項目迭代到一定程度后勢必要考慮的問題，不然整個項目勢必變成一整坨shishan…

正文

一、組件化

因此當(dāng)項目足夠龐大復(fù)雜，需求足夠垂直之后，項目整體架構(gòu)如何演進(jìn)就變得頗為重要，如果拆分項目就是一個亟待解決的問題。而組件化則是其中較為正確的一種解決方案。

本質(zhì)的思路：按需求類型維度(或其他的抽象維度)對整個項目進(jìn)行模塊上的拆解，每個模塊按照對擴(kuò)展開放，對修改關(guān)閉的原則進(jìn)行依賴隔離的設(shè)計。在如此的指導(dǎo)下項目自然而然的就分而治之，化繁為簡，化整為零。這也就是常說的模塊化(組件化)。

個人看法：叫組件還是模塊，只是抽象的維度的不一樣罷了，沒什么好糾結(jié)的。

組件化的意義對于項目來說在于宏觀上的解耦，具體下的內(nèi)聚。這種思想在設(shè)計模塊中經(jīng)常被提到：高內(nèi)聚低耦合。

這樣帶來的“好處”也是顯而易見的，復(fù)雜的工作被拆的足夠簡單，那么團(tuán)隊的劃分便會更科學(xué)，執(zhí)行也會更高效，畢竟只需要負(fù)責(zé)自己的一畝三分地，“鍋也就比較好分了”…

這似乎也是流水線模式下的一種應(yīng)用吧，是好還是壞，作為打工人的我也不好評判什么，畢竟我也是被流水線上的一員。人生在世又有誰是自愿背上枷鎖的呢…

明確組件化的內(nèi)核和意義，接下來我們就要思考如何去落地。想要徹底拆分和解耦，除了接口上的設(shè)計，編譯隔離也是必須要考慮的問題。而走到這一步，很多有經(jīng)驗的同學(xué)應(yīng)該意識到這其中的棘手的問題：既然面向的是接口，又是編譯隔離，那么如何拿到接口背后的實現(xiàn)呢?

路走到這里，也就該面對服務(wù)發(fā)現(xiàn)(或者接口發(fā)現(xiàn))的問題了。

二、服務(wù)發(fā)現(xiàn)

咱們用一張圖來描述一下上述環(huán)節(jié)聊的這些內(nèi)容：

從圖中，我們可以看到這里對組件化的方案，是增加了一個接口層，這層往下都是實現(xiàn)層。為了實現(xiàn)編譯隔離，所有的實現(xiàn)層只能依賴接口層，這樣對于實現(xiàn)層來說，就無法看到其他模塊的實現(xiàn)，也就不會干預(yù)到其他模塊。

因此如何方便的讓模塊彼此能夠方便的通過服務(wù)發(fā)現(xiàn)感知到其他模塊的實現(xiàn)便尤為重要。

對Java了解比較多的小伙伴應(yīng)該或多或少的接觸過ServiceLoader，這個類便是JDK為我們提供服務(wù)發(fā)現(xiàn)的能力。今天咱們不去評判ServiceLoader在android中的優(yōu)劣。畢竟咱們要自己去實現(xiàn)一套…

所以咱們就要基于使用簡單的角度來做一個服務(wù)發(fā)現(xiàn)庫。而用到的知識點(diǎn)也就是前段時候一直在聊的ASM~

尾聲

由于篇幅原因，所以ASM實戰(zhàn)：服務(wù)發(fā)現(xiàn)將分為多個章節(jié)。今天是先聊起因;接下來會進(jìn)入實戰(zhàn)環(huán)節(jié)，然后基于實戰(zhàn)代碼，再展開ASM、Plugin、Transform相關(guān)的內(nèi)容。

希望能通過這幾篇文章，串成一個完整的知識體系。