2024年Android最新深入解析：Android热修复技术选择和原理(1)，2024年最新面试时需要准备的内容

2401_84563465

于 2024-05-14 17:27:48 发布

阅读量714

点赞数 7

分类专栏：程序员文章标签： android 面试学习

本文链接：https://blog.csdn.net/2401_84563465/article/details/138862963

版权

程序员专栏收录该内容

186 篇文章 0 订阅

订阅专栏

作者2013年从java开发，转做Android开发，在小厂待过，也去过华为，OPPO等大厂待过，18年四月份进了阿里一直到现在。

参与过不少面试，也当面试官面试过很多人。深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长，而且极易碰到天花板技术停滞不前！

我整理了一份阿里P7级别的最系统的Android开发主流技术，特别适合有3-5年以上经验的小伙伴深入学习提升。

主要包括阿里，以及字节跳动，腾讯，华为，小米，等一线互联网公司主流架构技术。如果你想深入系统学习Android开发，成为一名合格的高级工程师，可以收藏一下这些Android进阶技术选型

我搜集整理过这几年阿里，以及腾讯，字节跳动，华为，小米等公司的面试题，把面试的要求和技术点梳理成一份大而全的“ Android架构师”面试 Xmind（实际上比预期多花了不少精力），包含知识脉络 + 分支细节。

Java语言与原理；
大厂，小厂。Android面试先看你熟不熟悉Java语言

高级UI与自定义view；
自定义view，Android开发的基本功。

性能调优；
数据结构算法，设计模式。都是这里面的关键基础和重点需要熟练的。

NDK开发；
未来的方向，高薪必会。

前沿技术；
组件化，热升级，热修复，框架设计

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

我在搭建这些技术框架的时候，还整理了系统的高级进阶教程，会比自己碎片化学习效果强太多，CodeChina上可见；

当然，想要深入学习并掌握这些能力，并不简单。关于如何学习，做程序员这一行什么工作强度大家都懂，但是不管工作多忙，每周也要雷打不动的抽出 2 小时用来学习。

不出半年，你就能看出变化！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

在native层面替换，把ArtMethod方法作为整体进行替换，实时生效，但同时也会带来诸多限制：

访问权限的问题

方法调用时的权限检查
同名包下的权限问题（设置新类的ClassLoader为原来类就可以了，通过反射进行设置）
反射调用非静态方法产生的问题

及时生效带来的限制

以下两种情况是不适用的：

引起了原有的类中发生结构变化的修改(字段，方法增加减少)，改成以冷启动支持
修复了的非静态方法会被反射调用，改成以冷启动方式支持

编译期和语言特性的影响

1. 内部类编译

静态内部类/非静态内部类的区别
内部类和外部类互相访问

外/内部类为了访问内/外部类私有的域/方法，编译器会自动为内部类生成access$数字编号相关方法，JVM规范，好像是提供了一个静态方法

热部署解决方案

一个外部类如果有内部类，把所有的method/field的私有访问权限改成protected或public或者默认访问权限。

同时把内部类所有的method/field的私有访问权限改成protected或public或者默认访问权限。

2. 匿名内部类编译

匿名内部类编译命名规则(access$**)
热部署解决方案

应该极力避免插入一个新的匿名内部类。当然如果匿名内部类是插入到外部类的末尾，那么是允许的。

3. 有趣的域编译

静态field，非静态field
静态field初始化，静态代码块（不支持<clinit>方法的热部署，只能冷启动生效）

静态代码块和静态域初始化在clinit中的先后关系就是两者出现在源码中的先后关系

以下三种情况都会尝试去加载一个类：

创建一个类的对象(new-instance指令)
调用类的静态方法(invoke-static指令)
获取类的静态域的值(sget指令)
非静态field初始化，非静态代码块
热部署解决方案

clinit只能冷启动，init无影响

4. final static预编译规则

final static修饰的基本类型或String常量类型，没有被编译到clinit方法中

final static域编译规则

final static修饰的原始类型和String类型域(非引用类型)，并不会被编译在clinit方法中，而是在初始化执行initSFields方法时得到了初始化赋值。

final static修饰引用类型，初始化仍在clinit方法中

final static域优化原理

final static引用类型没有得到优化，只是基本数据类型和String类型域(非引用类型)

热部署解决方案

修改 final static 基本类型或者 String 类型域(非引用类型域)，由于在编译期间引用到基本类型的地方被立即数替换，引用到 String 类型(非引用类型)的地方被常量池索引 ID 替换，所以在热部署模式下，最终所有引用到该 final static 域的方法都会被替换。实际上此时仍然可以执行热部署万案。

修改 final static 引用类型域，是不允许的，因为这个 field 的初始化会被编译到 clinit 万法中，所以此时没法走热部署。

5. 有趣的方法编译

应用混淆方法编译

项目如果应用了混淆方法编译，可能导致方法内联和裁剪，最后可能导致method的新增或减少。

方法内联

以下几种可能导致方法被内联掉：

方法没有被其他任何地方引用
方法足够简单，比如一个方法的实现就只有一行代码
方法只被一个地方引用

可能导致只能走冷启动方案

方法裁剪

可能导致只能走冷启动方案

如果让该参数不被裁剪，不让编译器在优化的时候认为引用了一个无用的参数就好了，这里介绍一种最有效的方法：

public static void test(Context context){

if(Boolean.FALSE.booleanValue()){

context.getApplicationContext();

}

Log.d(“BaseBug”,“test”)

}

这里不能使用基本类型，必须使用包装类Boolean，因为如果使用基本数据类型if语句可能也会被优化掉。

热部署解决方案

混淆配置文件加上-dontoptimize项就不会去做方法内联和裁剪，proguard-android-optimize.txt 或者 proguard-android.txt，两者的区别就是后者应用了 -dontoptimize 这一项配置而前者没有应用。

混淆库给热部署带来的影响主要在optimization阶段

optimzation step： -dontoptimize(热补丁模式下)

preverification step： -dontpreverify

混淆库对反射的处理(proguard.jar)，shrinking阶段，obfuscation阶段

6. switch case语句编译

packed-switch，sparse-switch指令

可能导致资源替换不全

热部署解决方案：反编译->资源ID->替换->回编译

7. 泛型编译

泛型擦除，类型擦除与多态的冲突和解决，泛型类型转换

热部署解决方案

如果由 B extends A 变成了 B extends A<Number>,那么就可能会新增对应的桥接方法，此时新增了方法，只能走冷部署，如果要避免，那就避免类似上面的那种修复。

泛型的系统注解

8. Lambda表达式编译

Lambda表达式可能导致方法的新增或减少

Lambda表达式的编译规则

函数式接口具有两个主要特征：**它是一个接口，这个接口具有唯一的抽象方法；我们将同时满足这两个特性的接口称为函数式接口。**比如java.lang.Runnable和java.util.Comparator，函数式接口和匿名内部类的区别如下：

关键字this，匿名类的this关键字指向匿名内部类，而Lambda表达式的this关键字指向包围Lambda表达式的类。
编译方式，Java编译器将Lambda表达式编译成类的私有方法，使用Java7的invokeddynnamic字节码指令来动态绑定这个方法。Java编译器将匿名内部类编译成外部类$数字编号的新类。

编译器间自动生成私有静态的lambda$main$**(*)方法，这个方法的实现其实就是Lambda表达式里面的逻辑。

invokedynamic指令执行Lambda表达式

比较与匿名内部类的区别，发现并没有在磁盘上生成外部类$数字编号的新类

invokedynamic指令执行时实际上回去调用java/lang/invoke/LambdaMetafactory的metafactory静态方法。**这个静态方法实际上会在运行时生成一个函数式接口的具体类。**然后具体类会调用Test的私有静态lambda$main$**(*)方法。

我们可以通过添加- Djdk.internal . lambda .dumpProxyClasses 这个虚拟机运行参数，那么运行时会将生成的新类的 .class 内窑输出到一个文件中。

Sun/Oracle Hotspot VM和Android虚拟机解释Lambda表达式的异同点

上面的方式是Sun/Oracle Hotspot VM解释.class文件中lambda表达式的方式，**Android虚拟机首先通过javac把源代码编译成.class，然后再通过dx工具优化成适合移动设备的dex字节码文件。**Android中如果要使用Java8的语言特性，需要使用新的Jack工具类来替换掉就的工具类编译。细节见书籍。

很明显可以看到.dex字节码文件和.class字节码文件对Lambda表达式处理的异同点：

共同点：编译期间都会为外部类合成一个static辅助方法，该方法内部逻辑实现Lambda表达式。

不同点：

.class字节码通过invoke-dynamic指令执行Lambda表达式。而.dex字节码中执行Lambda表达式跟普通方法调用没有任何区别。
.class字节码中运行时生成新类，.dex字节码中编译期间生成新类。
热部署解决方案

打补丁是通过反编译为smail然后跟新APK跟基线APK进行差异对比，得到最后的补丁包。

新增一Lambda表达式，会导致外部类新增一个辅助方法，所以此时不支持走热部署方案。如果Lambda表达式中访问非静态field/method，就会持有外部类的引用。

增加或减少一个Lambda表达式会导致类方法比较错乱，所以会导致热部署失败。

修改一个Lambda表达式，可能导致新增field，所以此时也导致热部署失败。

9. 访问权限检查对热替换的影响

类加载阶段父类/实现接口访问权限检查

一个类的加载过程，必须经历resolve,link,init三个阶段，父类或实现接口权限控制检查主要发生在link阶段。

类校验阶段访问权限检查

10. <clinit>方法

由于补丁热部署的特殊性，不允许类结构变更以及不允许变更<clinit>方法，所以补丁工具如果发现了以上几种限制情况，只能走冷启动。可能有时候在源码层上来看并没有新增或减少method和 field，但是实际上由于要满足 Java 各种语法特性的需求，所以编译器会在编译期间自动合成一些method 和 field时,最后就有可能触发了这几个限制情况。

小结

重点讲解了影响热替换热修复的一些重要的编译器问题。但是热修复还有个比较大的问题，由于是在运行期发生了变动，如果我们修改了某个方法的逻辑，就会导致它在修复前后的逻辑不一致，这就会引发一些诡异的错误。**因此热替换方式的热修复只适用于修复一些简单的BUG，如果要做一些功能方面的更新，不建议采用。**热部署修复方案的根本原理是基于native层方法的替换，所以当类结构变化时，如新增减少类method/field在热部署模式下会受到限制，修复了的非静态方法会被反射调用也会受到限制。

冷启动代码修复

现有的一些冷启动实现方案

| | Tinker | QQ空间 |

| — | — | — |

| 原理 | 提供dex差量包，整体替换dex的方案。差量的方式给出patch.dex，然后将patch.dex与应用的class.dex合并成一个完整的dex，完整的dex加载得到dexFile对象作为参数构建一个Element对象然后整体替换掉旧的dex Element数组。 | 为了解决Dalvik下的unexpected dex problem异常而采用插桩的方式，单独放一个帮助类在独立的dex中让其他类调用，阻止了类被打上CLASS_ISPREVERIFIED标志从而规避问题的出现。最后加载补丁dex得到dexFile对象作为参数构建一个Element对象插入到dex Elements数组的最前面 |

| 优点 | 自研dex差异算法，补丁包很小，dex merge成完整的dex，Dalvik不影响类加载性能，Art下也不存在必须包含父类/引用类的情况 | 没有合成整包，产物比较小，比较灵活 |

| 缺点 | dex合并内存消耗在vm heap上，容易导致OOM，最后导致dex合成失败 | Dalvik下影响类加载性能，Art下类地址写死，导致必须包含父类/引用类，最后补丁包很大 |

Tinker的dex merge操作是在Java层面进行的，所有对象的分配都是在java heap上完成的，可能发生申请的java heap超过vm heap规定的大小，进程发生OOM导致进程被杀死合成失败，如果在JNI层面进行C++ new/malloc申请的内存，分配在native heap，native heap的增长并不受vm heap大小的限制，只受限于RAM，如果RAM不足，也会导致进程被杀死导致闪退。在JNI层面进行dex merge，从而避免OOM提高合并成功率。

QQ空间的解决方案

问题来源

如果我们把要修复的QzoneActivityManager类打包成一个dex文件，插入到所有的dex文件的最前面，

1. ModuleManager在classes.dex中

2. QzoneActivityManager在patch.dex

ModuleManager引用了QzoneActivityManager，但是发现这两个类不在同一个dex文件中，于是问题就出现了

解决方案

dex在转换为odex(dexopt)的代码中的一段，在安装apk的时候，class.dex会被虚拟机(dexopt)优化成odex文件，然后才拿去执行

//DexPrepare.cpp

First, try to verify it.

if (doVerify) {

if (dvmVerifyClass(clazz)) {

Set the “is preverified” flag in the DexClassDef. We
do it here, rather than in the ClassObject structure,
because the DexClassDef is part of the odex file.

assert((clazz->accessFlags & JAVA_FLAGS_MASK) ==

pClassDef->accessFlags);

((DexClassDef*)pClassDef)->accessFlags |= CLASS_ISPREVERIFIED;

verified = true;

} else {

// TODO: log when in verbose mode

ALOGV(“DexOpt: ‘%s’ failed verification”, classDescriptor);

}

虚拟机在启动的时候，会有许多的启动参数，其中一项就是verify选项，当verify选项被打开的时候，上面doVerify变量为true，那么就会执行dvmVerifyClass进行类的校验，如果dvmVerifyClass校验类成功，那么这个类会被打上CLASS_ISPREVERIFIED的标志，那么具体的校验过程是什么样子的呢？

//DexVerify.cpp

bool dvmVerifyClass(ClassObject* clazz)

{

int i;

if (dvmIsClassVerified(clazz)) {

ALOGD(“Ignoring duplicate verify attempt on %s”, clazz->descriptor);

return true;

}

for (i = 0; i < clazz->directMethodCount; i++) {

if (!verifyMethod(&clazz->directMethods[i])) {

LOG_VFY(“Verifier rejected class %s”, clazz->descriptor);

return false;

}

for (i = 0; i < clazz->virtualMethodCount; i++) {

if (!verifyMethod(&clazz->virtualMethods[i])) {

LOG_VFY(“Verifier rejected class %s”, clazz->descriptor);

return false;

}

return true;

}

验证clazz->dvmIsClassVerified方法，directMethods包含了以下方法：

static方法
private方法
构造函数

clazz->virtualMethods

虚函数=override方法

概括一下就是如果以上方法中直接引用到的类(第一层级关系，不会递归进行搜索)和clazz都在同一个dex中的话，那么这个类就会被打上CLASS_ISPREVERIFIED

因为dex在优化的过程中会进行class的校验，给每一个class打上了一个CLASS_ISPREVERIFIED的标签，在调用的时候会根据该标签判断所在的class是否是同一个dex如果不是会抛出异常导致程序停止。所以我们需要防止类被打上CLASS_ISPREVERIFIED。

最终的解决方案是在所有类的构造函数里面插入了一段代码：代码如下

if (ClassVerifier.PREVENT_VERIFY) {

System.out.println(AntilazyLoad.class);

}

其中AntilazyLoad类会被打包成单独的hack.dex，这样当安装apk的时候，classes.dex内的类都会引用一个在不相同dex中的AntilazyLoad类，这样就防止了类被打上CLASS_ISPREVERIFIED的标志了，只要没被打上这个标志的类都可以进行打补丁操作。

然后在应用启动的时候加载进来.AntilazyLoad类所在的dex包必须被先加载进来,不然AntilazyLoad类会被标记为不存在，即使后续加载了hack.dex包，那么他也是不存在的，这样屏幕就会出现茫茫多的类AntilazyLoad找不到的log。

所以Application作为应用的入口不能插入这段代码。（因为载入hack.dex的代码是在Application中onCreate中执行的，如果在Application的构造函数里面插入了这段代码，那么就是在hack.dex加载之前就使用该类，该类一次找不到，会被永远的打上找不到的标志)

其中

class ClassVerifier{

public static boolean PREVENT_VERIFY=false;//false防止代码被执行,提高性能

}

之所以选择构造函数是因为他不增加方法数，一个类即使没有显式的构造函数，也会有一个隐式的默认构造函数。

空间使用的是在字节码插入代码,而不是源代码插入，使用的是javaassist库来进行字节码插入的。

虚拟机在安装期间为类打上CLASS_ISPREVERIFIED标志是为了提高性能的，我们强制防止类被打上标志会影响性能.（5.0以下）

但是插桩会给类加载效率带来比较严重的影响，熟悉Dalvik虚拟机开发的都知道，一个类的加载阶段通常有三个阶段：

dvmResolveClass
dvmLinkClass
dvmInitClass：在类解析完并尝试初始化类的时候执行，这个方法主要完成父类的初始化，当前类的初始化，静态变量的初始化赋值等操作。

可以看到如果类没被打上CLASS ISPREVERIFIED/CLASS ISOPTIMIZED 的标志，那么类的校验和优化都在类的初始化阶段进行。那么类的校验和优化都将在类的初始化阶段进行。正常情况下类的校验和优化都仅在 APK 第一次安装执行 dexopt 操作的时候进行，类的校验任务实际上是很重的，因为会对类的所有方法中的所有指令都进行校验，单个类加载时类校验耗时并不多，但是如果是在同一时间点加载大量类的情况下，这种耗时就会被放大。

性能影响

插桩导致所有的类都非preverify，从而导致校验和优化操作都会在类加载时触发，平均每个类的校验和优化的耗时并不长，但是应用刚启动的时候一般会同时加载大量的类，容易导致用户白屏。

QFix的解决方案

与QQ空间采用的native hook方式不同，不会去hook某个系统方法，而是从navie层直接调用，有如下注意点：

dvmResolveClass的第三个参数fromUnverifiedConstant必须为true。
在APK多dex的情况下，dvmResolveClass第一个参数referrer类必须跟需要打包的类在同一个dex中，但是它们两个类不需要存在任何引用关系，任何一个在同一个dex中的类作为referrer都可以。
referrer类必须提前加载。

但是QFix的方案有它独特的缺陷，由于是在dexopt后绕过的，dexopt会改变原有的很多逻辑，许多odex层面的优化会固定字段和方法的访问偏移，这会导致比较严重的bug。比如可能导致方法调用错乱。

但是上面两种方案都是侵入应用打包，我们的需求是冷启动模式是热部署模式的补充方案，所以这两种方案使用的应该是同一套补丁，我们的需求是无侵入打包又能做热部署模式的补充解决方案。

如何解决Dalvik虚拟机下类的pre-verify问题，如果一个类中直接引用到的所有非系统类都和该类在同一个dex中的话，那么这个类就会被打上CLASS_ISPAREVERIFIED标志，具体判定代码可见虚拟机中的verifyAndOptimizeClass函数。

腾讯三大热修复方案如何解决该问题：

QQ空间的处理方式是在每个类中插入一个来自其他dex的hack.class，由此让所有类都无法满足pre-verified条件。

缺点：入侵打包流程，添加臃肿代码，不优雅，无法新增public函数。

Tinker的方式是合成全量的dex文件，这样所有类都在全量dex中解决，从而消除类重复而带来的冲突。

粒度过细，实现起来较为复杂，性能消耗比较严重，时空代价转换的性价比不高（dex占apk比例不高）

QFix的方式是获取虚拟机中的某些底层函数，提前解析所有补丁类。以此绕过Pre-verify检查。

需要获取底层虚拟机函数，不够稳定可靠，无法新增public函数。

Robust解决方案(实时生效)

在打基础包时插桩，在每一个方法前插入一段ChangeQuickRedirect静态变量的逻辑，插入过程对业务开发完全透明。加载补丁时，从补丁包中读取要替换的类以及具体替换的方法实现，新建ClassLoader加载补丁dex。当changeQuickRedirect不为null的时候，可能会执行到accessDispatch从而替换掉之前老的逻辑，达到fix的目的。

public static ChangeQuickRedirect u;

protected void onCreate(Bundle bundle) {

//为每个方法自动插入修复逻辑代码，如果ChangeQuickRedirect为空则不执行

if (u != null) {

if (PatchProxy.isSupport(new Object[]{bundle}, this, u, false, 78)) {

PatchProxy.accessDispatchVoid(new Object[]{bundle}, this, u, false, 78);

return;

}

super.onCreate(bundle);

…

}

Robust的核心修复源码如下：

public class PatchExecutor extends Thread {

@Override

public void run() {

…

applyPatchList(patches);

…

}

/**

应用补丁列表

protected void applyPatchList(List patches) {

…

for (Patch p : patches) {

…

currentPatchResult = patch(context, p);

…

}

/**

核心修复源码

protected boolean patch(Context context, Patch patch) {

…

//新建ClassLoader

DexClassLoader classLoader = new DexClassLoader(patch.getTempPath(), context.getCacheDir().getAbsolutePath(),

null, PatchExecutor.class.getClassLoader());

patch.delete(patch.getTempPath());

…

try {

patchsInfoClass = classLoader.loadClass(patch.getPatchesInfoImplClassFullName());

patchesInfo = (PatchesInfo) patchsInfoClass.newInstance();

} catch (Throwable t) {

…

}

…

//通过遍历其中的类信息进而反射修改其中 ChangeQuickRedirect 对象的值

for (PatchedClassInfo patchedClassInfo : patchedClasses) {

…

try {

oldClass = classLoader.loadClass(patchedClassName.trim());

Field[] fields = oldClass.getDeclaredFields();

for (Field field : fields) {

if (TextUtils.equals(field.getType().getCanonicalName(), ChangeQuickRedirect.class.getCanonicalName()) && TextUtils.equals(field.getDeclaringClass().getCanonicalName(), oldClass.getCanonicalName())) {

changeQuickRedirectField = field;

break;

}

…

try {

patchClass = classLoader.loadClass(patchClassName);

Object patchObject = patchClass.newInstance();

changeQuickRedirectField.setAccessible(true);

changeQuickRedirectField.set(null, patchObject);

} catch (Throwable t) {

…

}

} catch (Throwable t) {

…

}

return true;

}

其实我感觉Robust的方案虽然有侵入性，增加代码体积等的缺点，但是感觉这种方式是兼容率最好的方案。也不会受Android版本的更新影响。

Sophix的解决方案

新的全量dex方案(Dalvik)

在原先基线包里的dex中，去掉补丁包dex中也有的类，这样基线包dex里就只包含不变的类了。而这些不变的类在要用拿到补丁中的新类会自动找到补丁dex，补丁包中的新类在需要用到不变的类时也会找到基线包dex的类。基线包里面不使用补丁类的类仍旧可以按原来的逻辑做odex，最大程度的保证了dexopt的效果。对dex的结构也不用进行破坏性重构。

所以问题就变成了如何在基线包dex中去掉补丁包中包含的所有类，dalvik中dex的文件结构可以查看这里

解决方法

我们要做的并不是把某个类的所有信息都从你dex移除，因为这么做，可能会导致dex的各个部分都发送变化，从而需要调整大量的offset，这么就变得费时费力了。我们需要做的仅仅是使得解析这个dex的时候找不到这个类的定义就可以了。因此只需要移除定义的入口，对于类的具体内容不进行删除，这样可以最大限度的减少offset的修改。

Dalvik下采用自行研发的全量dex方案
在Art下本质上虚拟机已经支持多dex的加载，我们要做的仅仅是把补丁dex作为dex(classes.dex)加载而已。

最后

总而言之，成功是留给准备好的人的。无论是参加什么面试，都要做好充足的准备，注意好面试的礼仪和穿着，向面试官表现出自己的热忱与真诚就好。即使最后没有过关，也要做好经验的总结，为下一次面试做好充足准备。

这里我为大家准备了一些我在面试后整理的面试专题资料，除了面试题，还总结出了互联网公司Android程序员面试涉及到的绝大部分面试题及答案，并整理做成了文档，以及系统的进阶学习视频资料分享给大家，希望能帮助到你面试前的复习，且找到一个好的工作，也节省大家在网上搜索资料的时间来学习。

毕竟不管遇到什么样的面试官，去面试首先最主要的就是自己的实力，只要实力够硬，技术够强，就不怕面试拿不到offer！

为什么某些人会一直比你优秀，是因为他本身就很优秀还一直在持续努力变得更优秀，而你是不是还在满足于现状内心在窃喜！希望读到这的您能点个小赞和关注下我，以后还会更新技术干货，谢谢您的支持！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

ex移除，因为这么做，可能会导致dex的各个部分都发送变化，从而需要调整大量的offset，这么就变得费时费力了。我们需要做的仅仅是使得解析这个dex的时候找不到这个类的定义就可以了。因此只需要移除定义的入口，对于类的具体内容不进行删除，这样可以最大限度的减少offset的修改。

Dalvik下采用自行研发的全量dex方案
在Art下本质上虚拟机已经支持多dex的加载，我们要做的仅仅是把补丁dex作为dex(classes.dex)加载而已。

最后

毕竟不管遇到什么样的面试官，去面试首先最主要的就是自己的实力，只要实力够硬，技术够强，就不怕面试拿不到offer！

[外链图片转存中…(img-y9RHZvvH-1715678845124)]

[外链图片转存中…(img-Nga9c3Uo-1715678845124)]

为什么某些人会一直比你优秀，是因为他本身就很优秀还一直在持续努力变得更优秀，而你是不是还在满足于现状内心在窃喜！希望读到这的您能点个小赞和关注下我，以后还会更新技术干货，谢谢您的支持！

[外链图片转存中…(img-X7jWNsi7-1715678845125)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

2401_84563465

关注

7
点赞
踩
11

收藏

觉得还不错? 一键收藏
0
评论
2024年Android最新深入解析：Android热修复技术选择和原理(1)，2024年最新面试时需要准备的内容

总而言之，成功是留给准备好的人的。无论是参加什么面试，都要做好充足的准备，注意好面试的礼仪和穿着，向面试官表现出自己的热忱与真诚就好。即使最后没有过关，也要做好经验的总结，为下一次面试做好充足准备。这里我为大家准备了一些我在面试后整理的面试专题资料，除了面试题，还总结出了互联网公司Android程序员面试涉及到的绝大部分面试题及答案，并整理做成了文档，以及系统的进阶学习视频资料分享给大家，希望能帮助到你面试前的复习，且找到一个好的工作，也节省大家在网上搜索资料的时间来学习。
复制链接

扫一扫