[[382121]]

本文轉載自微信公眾號「咸魚正翻身」，作者MDove 。轉載本文請聯系咸魚正翻身公眾號。  

前言

這篇文章是一個ASM的實戰篇，并沒什么什么傳統搜到的插樁System.currentTimeMillis()計算方法耗時的實戰。而且為項目組件化實現一套服務發現的基礎能力。

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

正文

一、組件化

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

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

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

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

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

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

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

路走到這里，也就該面對服務發現(或者接口發現)的問題了。

二、服務發現

咱們用一張圖來描述一下上述環節聊的這些內容：

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

因此如何方便的讓模塊彼此能夠方便的通過服務發現感知到其他模塊的實現便尤為重要。

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

所以咱們就要基于使用簡單的角度來做一個服務發現庫。而用到的知識點也就是前段時候一直在聊的ASM~

尾聲

由于篇幅原因，所以ASM實戰：服務發現將分為多個章節。今天是先聊起因;接下來會進入實戰環節，然后基于實戰代碼，再展開ASM、Plugin、Transform相關的內容。

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