本文整理自享学团队直播课《热修复（四）：Android N 混编问题》。 前一篇把「类替换」这条链用反射实现了一遍：补丁 dex 转成一组 Element，插到 PathClassLoader 内部 DexPathList 的 dexElements 数组最前面，类加载按顺序先命中补丁，旧类被顶掉。这套做法在 Android 6.0 上跑通了。但到了 Android 7.0，它可能整个失效：不是代

本文整理自享学团队直播课《热修复（三）：反射实现运行期热修复》。 上一篇把「类替换」这条链的原理走完了：补丁 dex 用反射转成一组 Element，插到 PathClassLoader 内部 DexPathList 维护的 dexElements 数组最前面，类加载按顺序先命中补丁，旧类被顶掉。这一篇不再讲原理，而是亲手用反射写出来HotFix.installPatch 并进行应用测试。 整个

本文整理自享学团队直播课《热修复（二）：dex 补丁热修复原理》。 上一篇我们把这四种主流的方案（QZone、Tinker、AndFix、Robust）的原理讲了一遍。那一篇的核心差异记住这一个就可以了：AndFix 走方法替换（native 层改 ArtMethod），Robust 走字节码插桩，QZone 和 Tinker 走类替换。 类加载方案的核心动作只有一件事： 把补丁 dex 用反射转

本文整理自享学团队直播课《热修复（一）：常用热修复解决方案》。 一、为什么一定要有热修复 线上版本出了逻辑错误，或者直接导致崩溃的 bug，传统做法是重新打包发布一个新版本。这条路的成本并不在打包本身，而在用户什么时候愿意升级。 微信是国内升级率最高的应用之一。可即便是它，一个新版本也要 10 天以上才能覆盖到 50% 的用户。剩下的用户在干嘛？在等，等你下个版本强制更新，或者干脆一直用老版本。你

本文整理自享学团队直播课《Android 插件化(三)：资源加载》。 前面两讲把插件的类和 Activity 都"骗"进来了，但插件的 Activity 跑起来之后，getResources 拿到的还是宿主的资源——图片、字符串、布局全是宿主那套。这一讲要做的就是让插件用自己的 AssetManager 单独加载一份属于插件的资源。 要做到这一点，你得先想通两件事： 上一讲那两个 Hook 点

本文整理自享学团队直播课《Android 插件化(二)：Activity加载》。 上一讲解决的是"插件的类能被加载进来"，这一讲解决的是"插件的 Activity 能真正被启动"。前者靠类加载器，后者靠 Hook——在 Android 启动 Activity 的链路中间安插一个钩子，把"要启动哪个 Activity"这个信息偷偷换一遍，让一个已注册的占坑 Activity 去骗过 AMS 的校验，

本文整理自享学团队直播课《Android 插件化(一)：类加载》。 插件化的第一件事：让宿主把自己没装过的「插件类」加载进来。拆开看，底层动作就三步：用一个 DexClassLoader 去加载插件 APK，反射拿到它内部的 dexElements，再合并进宿主自己的 dexElements。这三步做完，宿主 loadClass 一个插件类，和加载自己的类没有区别。 结论就上面三句，但直接看反射代

主线程最终进入 Looper.loop ，正常运行时这个方法不会返回。既然线程一直停留在循环中，Activity 生命周期、点击事件和界面刷新为什么还能执行？ 关键在于：这些工作本来就由事件循环驱动。 主线程不需要先退出 loop 才能执行回调；回调就在循环处理事件的过程中被调用。空闲时，循环又会进入可唤醒的阻塞等待，避免持续空转。 一、先区分无限循环、忙等、死锁和 ANR 几个词经常被混用