P7高级聊完并发和JVM，这篇进入P7+资深——动态加载与热修复。这是P7和P8的分水岭：P7会用框架，P7+能讲清楚Tinker怎么合成dex、Sophix怎么改ART方法入口。
阿里资深岗必问这块。淘宝用Atlas做插件化，支付宝用Sophix做热修复。你只说"用过Tinker"，面试官追三句就露馅。
今天8道题覆盖动态加载全链路，每道给出能深聊三轮的答案。
Q1：DexClassLoader和PathClassLoader区别？
两者都继承BaseDexClassLoader，核心差异在dex来源。
PathClassLoader：加载已安装APK（/data/app/xxx.apk）。系统的AppClassLoader就是PathClassLoader实例，App运行时默认用它加载类。
DexClassLoader：加载任意路径的dex/jar/zip/apk。构造时传dexPath和optimizedDirectory，先把dex优化到私有目录再加载。热修复和插件化用它——修复dex不在安装目录，得靠DexClassLoader加载。
追问：Android 8.0后optimizedDirectory参数废弃，系统自动管理优化目录。以前可以指定目录方便管理，现在目录权限受SELinux限制更严。
Q2：DexClassLoader的加载流程？
完整链路四步：构造时调DexFile.loadDex把dex优化到私有目录（生成odex加速加载）→ 创建DexFile对象 → parent委派给BaseDexClassLoader的DexPathList → findClass遍历dexElements查找类。
追问：热修复为什么能"插桩"？因为dexElements是数组，遍历是顺序查找。把修复dex放数组前面，原dex在后面，ClassLoader先命中修复dex里的类——类被替换了。这就是Qigsaw和Tinker热修复的底层原理。
Q3：Tinker热修复原理？怎么生成补丁？
Tinker用微信团队开源的方案，核心思路是dex差量合并。
补丁生成：编译时保留基线包APK。新版本编译后，bsdiff算法对比新旧dex生成差量patch.dex。patch.dex比全量dex小很多（通常只有几KB到几十KB）。
补丁下发：客户端下载patch.dex + 签名校验信息。
补丁合成：把patch.dex和基线dex合并成完整新dex，替换原classes.dex。合成在后台线程执行，下次启动生效。
追问：Tinker合成dex会不会影响启动速度？第一次合成会——合成过程要读原始dex+patch做合并写文件。Tinker优化策略：合成完缓存结果，后续启动直接加载合成后的dex，不影响速度。但如果用户清除App数据，缓存丢了下次启动得重新合成。
Q4：Tinker资源和so怎么修复？
资源修复：生成patch.apk包含修改的资源文件。用aapt2生成新resources.arsc，通过ResourcePatcher在运行时替换AssetManager的ResourceImpl。本质是Hook AssetManager加新资源路径。
资源ID冲突：Tinker指定新资源使用固定type ID段，避免跟原资源ID碰撞。具体做法：修改aapt的package id分配规则，新资源分配到独立的0x7a段。
so修复：直接替换so文件然后重新加载。但必须在dlopen前替换——已加载的so要先dlclose再重新加载。Android 8.0后dlclose行为有变化，有些so无法安全卸载。
Q5：Sophix和Tinker区别？底层替换原理？
Tinker：dex级替换，补丁合成需要重启App，修复粒度是类级别。补丁体积小（bsdiff差量），但合成耗时。
Sophix：底层替换方案（基于AndFix改进），修改ART的方法结构体把原方法入口指向补丁方法。即时生效不用重启，修复粒度是方法级别。
Sophix底层：在native层操作ART内部数据结构。找到目标方法的ArtMethod结构体，修改其entry_point_from_quick_compiled_code_指向补丁方法编译后的地址。运行时调原方法，ART直接跳补丁代码。
追问：Sophix为什么不会增加方法数？因为它不添加新类新方法——只是修改已有方法的入口指针。dex验证不受影响（类结构没变），不会触发ART的dex verification失败。这是比dex级替换更安全的地方。
Q6：Sophix的限制？什么场景不能修复？
冷启动限制：Application.attachBaseContext里执行的代码，Sophix还没初始化无法修复。要把热修复初始化放到attachBaseContext最前面，但这段代码本身不能修。
新增类限制：Sophix底层替换只能修改已有方法。新增类、新增方法、新增字段——做不到。需要新增类的场景得走Tinker dex级替换。
Android版本兼容：ART在不同Android版本内部结构不一样（ArtMethod布局、GC机制），Sophix要针对每个版本做适配。Android大版本更新时Sophix可能要等适配才能用。
追问：怎么选型？方法级Bug修复用Sophix（即时生效体验好）；新增类或大改动用Tinker（接受重启）；两者结合用效果最好——小Bug即时修，大改动走发版节奏。
Q7：Atlas插件化架构？Bundle机制？
Atlas是阿里开源的插件化框架，淘宝大规模使用。
架构分层：宿主App（Host）、Bundle插件、Launcher。每个Bundle是独立APK结构（有dex、resources、AndroidManifest），可以独立开发编译。
Bundle生命周期：编译AAR → 发布时打APK → 安装时解析 → 运行时按需加载。Bundle可以动态下发（类似App内小程序）。
依赖管理：Bundle间依赖通过Maven管理，宿主声明依赖关系，运行时Launcher按需加载Bundle的ClassLoader和Resource。
追问：Atlas和RePlugin区别？Atlas是动态组件化方案——Bundle有完整APK结构，隔离性强但框架体积大（约1-2MB）。RePlugin是Hook方案——插件通过Hook Instrumentation和ClassLoader实现，框架体积小（约100KB）但隔离性弱。中小项目选RePlugin，大项目（淘宝级别）选Atlas。
Q8：Atlas类隔离和资源共享怎么做？
类隔离：每个Bundle有自己的BundleClassLoader。加载类时先在自己的dex里找，找到直接用；找不到才委派给parent。Bundle之间类天然隔离——A Bundle的类B Bundle看不到。
资源共享：Hook AssetManager的addAssetPath方法，把Bundle的资源路径加入AssetManager。Bundle资源ID和宿主资源共用一个Resources对象，代码里正常用R.id.xxx就行。
资源ID冲突处理：编译期修改aapt工具，给每个Bundle分配不同的资源ID段（package id）。宿主用0x7f，Bundle1用0x71，Bundle2用0x72。运行时不冲突。
追问：Atlas插件动态下发怎么做？服务端下发Bundle APK → 客户端下载到私有目录 → Launcher解析APK创建BundleClassLoader → 注册Bundle路由。用户下次进入对应模块时直接加载已下载的Bundle，无感知更新。
面试Tips：P7+面试动态加载是核心。DexClassLoader和PathClassLoader的区别要能讲清parent委派和dex来源。Tinker要能画出补丁生成→下发→合成→加载全流程。Sophix要能讲出ART方法入口替换的native层实现。Atlas要能对比RePlugin说出架构选型理由。准备这块推荐看Tinker和Atlas的源码，比看博客深入十倍。
下一篇是阿里P8架构师面经，进入系统架构层面——淘宝架构怎么演进的？组件化怎么做？闲鱼Flutter实践踩过什么坑？
搞过热修复的同学评论区报到，你遇到过最离谱的热修复crash是什么？
本系列连载中，关注不迷路，下一篇：阿里P8 Android架构师面试真题
系列简介：Android大厂面经连载，覆盖字节跳动、腾讯、阿里、美团等40+企业，从初级到架构师全岗位覆盖。每篇文章包含真实面试题+详细答案+代码示例，帮你拿到大厂Offer。
