本文转载自微信公众号《咸鱼翻身》，作者MDove。转载本文请联系闲鱼正翻车公众号。前言本文为ASM的实战文章，没有传统搜索system.currentTimeMillis()计算方法的耗时实战。并为项目组件化实现一套服务发现的基础能力。我个人认为组件化是一个项目迭代到一定程度后必须要考虑的问题，否则整个项目难免会变成一整堆石山……文1.组件化所以当项目庞大复杂的时候并且要求足够垂直，项目的整体架构是怎样的？演进变得相当重要，拆分项目是一个亟待解决的问题。组件化是比较正确的解决方案之一。基本思想：根据需求类型维度（或其他抽象维度），将整个项目以模块为基础进行拆解，每个模块按照对扩展开放，对修改关闭的原则进行设计。在这样的引导下，项目自然而然地分而治之，化繁为简，化整为零。这就是常说的模块化（componentization）。个人观点：称其为组件或模块，只是抽象维度不同而已，没什么好担心的。组件化对于项目的意义在于宏观层面的解耦和具体层面的内聚。这个思想在设计模块中经常被提及：高内聚低耦合。由此带来的“好处”也是显而易见的。如果把繁杂的工作拆解得足够简单，团队的分工就会更科学，执行起来也会更有效率。毕竟，你只需要负责自己的一亩三分地。更容易打分”……这好像是流水线模式下的应用，好与不好，作为一个工人，我不喜欢去评判什么，毕竟我也是一员流水线，这世上谁会自愿背负枷锁……明确了组件化的核心和意义之后，我们就需要思考如何实现，要想彻底拆分解耦，除了接口设计，编译隔离也必须要考虑到这一点，很多有经验的同学应该意识到了一个棘手的问题：既然是面向接口，编译隔离，那么如何获取接口背后的实现呢？面临服务发现（或接口发现）的问题).2.ServiceDiscovery我们用一张图来描述上面对话的内容：从图中可以看出，这里的组件化解决方案是增加一个接口层，这一层就是实现层。为了实现编译隔离，所有的实现层只能依赖接口层，使得实现层看不到其他模块的实现，也不会干扰其他模块。因此，让模块通过服务发现方便地感知其他模块的实现就显得尤为重要。对Java比较了解的朋友应该或多或少接触过ServiceLoader。这个类就是JDK为我们提供服务发现的能力。今天我们就不去评判android中ServiceLoader的优劣了。毕竟我们要自己实现一套……所以我们要从易用性的角度来做一个服务发现库。而用到的知识点就是前段时间一直在讲的ASM。由于篇幅原因，ASM实战：服务发现将分为多个章节。今天先说起因；然后进入实战环节，接下来根据实战代码，展开ASM、Plugin、Transform相关的内容。希望通过这些文章，串起一个完整的知识体系。
