安卓开发常见面试题，Android热修复技术选择和原理分析(1)，Android开发了解这些自然无惧面试

3. 获取类的静态域的值(sget指令)

4. 非静态field初始化，非静态代码块

5. 热部署解决方案

clinit只能冷启动，init无影响

4. final static预编译规则

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

1. final static域编译规则

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

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

2. final static域优化原理

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

3. 热部署解决方案

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

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

5. 有趣的方法编译

1. 应用混淆方法编译

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

2. 方法内联

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

• 方法没有被其他任何地方引用

• 方法足够简单，比如一个方法的实现就只有一行代码

• 方法只被一个地方引用

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

3. 方法裁剪

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

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

public static void test(Context context){

if(Boolean.FALSE.booleanValue()){

context.getApplicationContext();

}

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

}

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

4. 热部署解决方案

混淆配置文件加上-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表达式可能导致方法的新增或减少

1. 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表达式。

不同点：

1. .class字节码通过invoke-dynamic指令执行Lambda表达式。而.dex字节码中执行Lambda表达式跟普通方法调用没有任何区别。

2. .class字节码中运行时生成新类，.dex字节码中编译期间生成新类。

3. 热部署解决方案

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

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

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

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

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

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

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

2. 类校验阶段访问权限检查

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;

}

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

• static方法

• private方法

• 构造函数

2. 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函数。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）

结语

• 现在随着短视频，抖音，快手的流行NDK模块开发也显得越发重要，需要这块人才的企业也越来越多，随之学习这块的人也变多了，音视频的开发，往往是比较难的，而这个比较难的技术就是NDK里面的技术。
• 音视频/高清大图片/人工智能/直播/抖音等等这年与用户最紧密，与我们生活最相关的技术一直都在寻找最终的技术落地平台，以前是windows系统，而现在则是移动系统了，移动系统中又是以Android占比绝大部分为前提，所以AndroidNDK技术已经是我们必备技能了。
• 要学习好NDK，其中的关于C/C++，jni，Linux基础都是需要学习的，除此之外，音视频的编解码技术，流媒体协议，ffmpeg这些都是音视频开发必备技能，而且
• OpenCV/OpenGl/这些又是图像处理必备知识，下面这些我都是当年自己搜集的资料和做的一些图，因为当年我就感觉视频这块会是一个大的趋势。所以提前做了一些准备。现在拿出来分享给大家。

本文已被CODING开源项目：《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》收录

一个人可以走的很快，但一群人才能走的更远。如果你从事以下工作或对以下感兴趣，欢迎戳这里加入程序员的圈子，让我们一起学习成长！

AI人工智能、Android移动开发、AIGC大模型、C C#、Go语言、Java、Linux运维、云计算、MySQL、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算

droidNDK技术已经是我们必备技能了。

• 要学习好NDK，其中的关于C/C++，jni，Linux基础都是需要学习的，除此之外，音视频的编解码技术，流媒体协议，ffmpeg这些都是音视频开发必备技能，而且
• OpenCV/OpenGl/这些又是图像处理必备知识，下面这些我都是当年自己搜集的资料和做的一些图，因为当年我就感觉视频这块会是一个大的趋势。所以提前做了一些准备。现在拿出来分享给大家。

[外链图片转存中…(img-r0523P8f-1712500192489)]

[外链图片转存中…(img-5mXKZk9T-1712500192489)]

本文已被CODING开源项目：《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》收录

一个人可以走的很快，但一群人才能走的更远。如果你从事以下工作或对以下感兴趣，欢迎戳这里加入程序员的圈子，让我们一起学习成长！

AI人工智能、Android移动开发、AIGC大模型、C C#、Go语言、Java、Linux运维、云计算、MySQL、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算