本文根据红橙Darren 的直播课程《Android Framework 学习启动篇》系列整理，三讲分别讲必备前提条件、Android Framework 简介与怎么入手学习。 ImageView 设置 android:adjustViewBounds="true" 后，宽度铺满屏幕、高度按图片比例自适应，看起来只是一个布局小问题。可一旦图片尺寸、scaleType、maxWidth/maxHei

一、问题与结论 原生 JNI 的 API 数量有限，麻烦集中在边界状态：方法签名要手写字符串，引用所有权靠手动维护，C++ 异常不能越过 JNI 入口，自己创建的 native 线程还要先挂载到 JVM。任何一处漏掉，错误都可能推迟到运行时才出现，表现为 NoSuchMethodError、引用泄漏、std::terminate，或者拿不到可用的 JNIEnv*。 fbjni 不替换原有 JNI

本文整理自享学团队直播课《热修复（四）：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 的校验，