本文转载自微信公众号「咸鱼正翻身」，作者MDove 。转载本文请联系咸鱼正翻身公众号。
前言
这篇文章是一个ASM的实战篇，并没什么什么传统搜到的插桩System.currentTimeMillis()计算方法耗时的实战。而且为项目组件化实现一套服务发现的基础能力。
个人认为组件化是一个项目迭代到一定程度后势必要考虑的问题，不然整个项目势必变成一整坨shishan…
正文
一、组件化
因此当项目足够庞大复杂，需求足够垂直之后，项目整体架构如何演进就变得颇为重要，如果拆分项目就是一个亟待解决的问题。而组件化则是其中较为正确的一种解决方案。
本质的思路：按需求类型维度(或其他的抽象维度)对整个项目进行模块上的拆解，每个模块按照对扩展开放，对修改关闭的原则进行依赖隔离的设计。在如此的指导下项目自然而然的就分而治之，化繁为简，化整为零。这也就是常说的模块化(组件化)。
个人看法：叫组件还是模块，只是抽象的维度的不一样罢了，没什么好纠结的。
组件化的意义对于项目来说在于宏观上的解耦，具体下的内聚。这种思想在设计模块中经常被提到：高内聚低耦合。
这样带来的“好处”也是显而易见的，复杂的工作被拆的足够简单，那么团队的划分便会更科学，执行也会更高效，毕竟只需要负责自己的一亩三分地，“锅也就比较好分了”…
这似乎也是流水线模式下的一种应用吧，是好还是坏，作为打工人的我也不好评判什么，毕竟我也是被流水线上的一员。人生在世又有谁是自愿背上枷锁的呢…
明确组件化的内核和意义，接下来我们就要思考如何去落地。想要彻底拆分和解耦，除了接口上的设计，编译隔离也是必须要考虑的问题。而走到这一步，很多有经验的同学应该意识到这其中的棘手的问题：既然面向的是接口，又是编译隔离，那么如何拿到接口背后的实现呢?
路走到这里，也就该面对服务发现(或者接口发现)的问题了。
二、服务发现
咱们用一张图来描述一下上述环节聊的这些内容：
从图中，我们可以看到这里对组件化的方案，是增加了一个接口层，这层往下都是实现层。为了实现编译隔离，所有的实现层只能依赖接口层，这样对于实现层来说，就无法看到其他模块的实现，也就不会干预到其他模块。
因此如何方便的让模块彼此能够方便的通过服务发现感知到其他模块的实现便尤为重要。
对Java了解比较多的小伙伴应该或多或少的接触过ServiceLoader，这个类便是JDK为我们提供服务发现的能力。今天咱们不去评判ServiceLoader在android中的优劣。毕竟咱们要自己去实现一套…
所以咱们就要基于使用简单的角度来做一个服务发现库。而用到的知识点也就是前段时候一直在聊的ASM~
尾声
由于篇幅原因，所以ASM实战：服务发现将分为多个章节。今天是先聊起因;接下来会进入实战环节，然后基于实战代码，再展开ASM、Plugin、Transform相关的内容。
希望能通过这几篇文章，串成一个完整的知识体系。
