本篇为整个 Android 轻量插件化系列收尾。作者建议动手实践时不要一开始就追求兼容所有系统版本，而是先把最小 Demo 跑通：工程拆分为宿主、宿主与插件共享的接口、以及插件 APK 三个模块，最终分别产出宿主安装包与插件包，宿主正常安装，插件只需复制到宿主能够读取的位置即可。文章完整走了一遍从加载插件到启动组件的流程，梳理了四大组件各自的对应关系，并特别强调了一个重要认识——不建议从一开始就去做完全透明的插件方案。最后坦率列出了这套方案真正还需要补齐的部分：插件的安全校验、版本管理、类加载器隔离、生命周期的处理以及对不同 Android 版本的兼容，并在结尾对整个系列做了总结。

前面几篇都是围绕单个零件展开，这一篇负责把它们拼装成一个真正像框架的样子。作者主张保持非常小的结构，不要一上来就设计出几十个类，并给出了推荐的工程目录，让插件管理器、插件信息、插件上下文与插件类加载器等几个核心文件各司其职。文中定义了用于描述已加载插件的信息对象，重新梳理了承担统一调度职责的插件管理器，实现了统一启动插件页面的入口，并解释了为什么必须在插件信息中保存包名这一关键字段——它正是后续区分不同插件、对四大组件请求做路由的依据。最终类加载器、资源、上下文与各类代理汇成了一套统一的路由。文章也点明了这种收敛带来的额外好处，同时提醒即便跑得通也别急着拿去生产环境。

前面的 Activity、Service 和广播接收器走的都是同一条路径：系统先启动一个宿主组件，我们再设法把请求转交给插件。内容提供者却不太一样，它经常在进程启动阶段就被系统要求创建，而且还自带一套用于寻址的权限标识机制，因此成为这个轻量插件框架里最值得单独讨论的部分。文章从一个最简单的插件内容提供者入手，给出宿主代理提供者的写法，说明如何依据调用方传来的地址在内部做路由，从而把增改删查等请求分发到对应的插件实现上。随后作者深入解释了为什么它无法像其他组件那样轻易做到对调用方完全透明，并区分了教学版与深度兼容版两种不同力度的实现思路，最后讨论了内容提供者的启动时机，至此四大组件基本形成闭环。

广播接收器是四大组件里代码量最少的一个，但在插件化之后却会出现一条非常明显的分叉：动态注册与清单文件中的静态注册必须分开处理。对于动态注册，插件会自己调用注册方法并传入过滤器，这种情况可以让插件的上下文接管该方法，把注册关系记录下来即可正常工作。真正麻烦的是静态注册，系统只认宿主 APK 自己的清单文件，压根不知道插件 APK 里声明的那些接收器存在，广播到来时自然也不会替它唤起。文章针对这种情况给出了一个尽量轻量的处理办法，并提醒读者注意一个极易被忽略的细节，最后点明广播接收器代理的核心其实并不复杂，关键就在于区分这两种注册方式各自的来源。

在把 Activity 代理理清楚之后，Service 的代理就变得顺理成章。假设插件里有一个实现了统一接口的上传服务，麻烦在于系统根本不知道这个服务的存在。文章的解决办法与 Activity 一脉相承：在宿主的清单文件中注册一个固定的代理服务作为壳，由它接住启动请求后再分派给真正的插件服务实例。作者特别指出，Service 没有 Activity 那样复杂的界面与状态，反而更适合用来理解四大组件代理的基本套路。文中依次展示了代理服务的具体写法、如何为插件构造出可用的运行环境、面对绑定式调用这种场景应当如何处理，以及同一个插件中存在多个服务时该如何管理，最后总结了为什么服务适合作为动手实现的第二个组件。

插件里的代码虽然已经能够加载，但如果直接调用 startActivity 去启动插件中的 Activity，系统依然会报错，原因很简单：插件的 Activity 从来就没有在宿主 APK 的清单文件里注册过。文章据此转向经典的代理思路——在宿主的清单中预先注册一个代理 Activity 作为壳子，让系统照常启动它，再把控制权转交给真正的插件页面。文中详细拆解了这个壳 Activity 具体要做的工作、如何替换 Intent 里携带的目标信息，解释了为什么教学版本可以自行模拟页面的生命周期回调，同时介绍了更贴近工程实际的兼容方案，以及插件页面最终是如何显示出来的。最后客观分析了这种代理设计存在的缺点，帮助读者理解它的适用范围而不是把它当成万能方案。

本文是插件化真正落地的第一步，目标很纯粹：宿主不安装插件 APK，却要能够创建插件里面的 Java 对象。文章先准备了一个简单的插件 APK，其中包含一个返回字符串的入口类，随后引入 DexClassLoader，讲解如何把外部 APK 的路径、优化后的 dex 输出目录与原生库路径一并传入，让宿主进程的类加载器能够真正找到并加载插件中的类。接着说明仅仅加载代码是远远不够的——插件还会使用自己的布局、字符串和图片，因此必须另外解决资源访问的问题，为此需要构造专属于插件的资源对象。在此基础上进一步封装出一个插件上下文，令插件代码可以像平时一样访问资源，并由统一的插件管理器负责持有已加载的插件。最后交代了这一步完成后还缺什么，自然引出后续的组件代理。

这是 Android 轻量插件化系列的开篇。作者不打算直接使用任何一个成熟框架，而是反过来提出一个问题：如果只允许使用 Java 和 Android SDK，能不能自己动手写一个尽量小的插件框架。答案是可以，但前提是接受使用 Android 的部分内部机制，尤其是四大组件的代理，因此这套方案更适合用来理解插件化的底层原理，或者在受控环境中搭建插件系统。文章首先明确了要达成的目标：宿主 App 在不向系统安装插件 APK 的前提下动态加载其中的代码，并让插件的 Activity 能够打开、Service 能够启动、广播接收器能够工作、内容提供者能够访问。随后给出最小的整体架构，解释为什么类加载器必然是第一步、四大组件为什么非得走代理，最后坦率交代了这套方案的能力边界。

雪球作为一个专业的投资社区，聚集了不少乐于分享优质内容的大V，超级鹿鼎公便是作者一直很喜欢的一位。但在手机端认真阅读雪球专栏的体验并不理想，尤其是那些发布较早的文章，往往需要反复翻找很久才能定位。出于这个原因，作者索性把这位博主的专栏文章整理制作成了 epub 格式的电子书，并且为它加上了完整的目录导航，这样一来阅读体验就顺畅了许多。本文把这份自制电子书分享出来，文中还附有使用 Windows 版 Calibre 打开的截图，可以看到排版与目录的实际效果。电子书的下载地址放在网盘中，感兴趣的读者可以自行获取；如果想要其他博主的文章合集，也可以通过邮件联系作者另行制作。

如何判断一个单向链表是否含有环，是 LintCode 第 102 题，也是企业面试中的高频考点。文章先分析有环链表的形态：它有头结点却没有尾结点，内部包含一个把尾结点指回头结点的环状结构，因此遍历永远不会自然停止。由此引出最关键的一个洞察——在环状链表中若让两个指针以不同速度遍历，必然会出现类似田径比赛里的套圈现象，而这正是普通单向链表绝不会具备的特征。解法即经典的快慢指针：fast 每次前进两步、slow 每次前进一步，若任一指针先到达链表尾部则证明无环，若两者在某个位置重新相遇则说明链表有环。文中配有结构示意图和完整的 Java 参考实现。