9102年了，还不知道Android为什么卡？，面试总结

① Andorid 1.0 Dalvik(DVM)+解释器

DVM是Google开发的Android平台虚拟机,可读取.dex的字节码。 上文中所说的从字节码解释成机器码的过程在Java虚拟机中，在Android平台中虚拟机指的就是这个DVM。 在Android1.0时期，程序一边运行，DVM中的解释器（翻译机）一边解释字节码。 可想而知，这样效率绝对低下。一个字，卡。

② Android 2.2 DVM+JIT

其实解决DVM的问题思路很清楚，我们在程序某个功能运行前就解释就可以了。

在Android2.2时期，聪明的谷歌引入了JIT(Just In Time)机制，直译就是即时编译。

举个🌰，我经常去一家餐馆吃饭，老板已经知道我想吃什么菜了，在我到之前就把菜准备好了，这样我就省去了等菜的时间。

JIT就相当于这个聪明的老板，它会在手机打开APP时，将用户经常使用的功能记下来。当用户打开APP的时候立马将这些内容编译出来，这样当用户打开这些内容时，JIT已经将’菜’准备好了。这样就提高了整体效率。

虽然JIT挺聪明的，且总体思路清晰理想丰满，但现实是仍然卡的要死。

存在的问题：

• 打开APP的时候会变慢
• 每次打开APP都要重复劳动，不能一劳永逸。
• 如果我突然点了一盘之前从来没点过的菜，那我只好等菜了，所以如果用户打开了JIT没有准备好的’菜’，就只能等DVM中的解释器去边执行边解释了。

③ Android 5.0 ART+AOT

聪明的谷歌又想到个方法，既然我们能在打开APP的时候将字节码编译成机器码，那么我们何不在APP安装的时候就把字节码编译成机器码呢？这样每次打开APP也不用重复劳动了，一劳永逸。

这确实是个思路，于是谷歌推出了ART来替代DVM，ART全称Android Runtime，它在DVM的基础上做了一些优化，它在应用被安装的时候就将应用编译成机器码,这个过程称为AOT(Ahead-Of-Time)，即预编译。

但是问题又来了，打开APP是不卡了，但是安装APP慢的要死，可能有人会说，一个APP又不是会频繁安装，可以牺牲下这点时间。 但是不好意思，安卓手机每次OTA启动（即系统版本更新或刷机后）都会重新安装所有APP，无奈吧！绝望吧！对，还记得那两年，被安卓版本更新所支配的恐惧吗！

④ Android 7.0 混合编译

谷歌最终祭出了终极大招，DVM+JIT不好，ART+AOT又不好。行，我把他们都混合起来，那总可以了吧！

于是谷歌在Android7.0的时候，发布了混合编译。 即安装时先不编译成机器码，在手机不被使用的时候，AOT偷偷的把能编译成机器码的那部分代码编译了（至于什么是能编译的部分，下文字节码的编译模板详述）。其实就是把之前APP安装时候干的活偷偷的在手机空的时候干了。

如果来不及编译的话，再把JIT和解释器这对难兄难弟叫起来，让他们去编译或实时解释。

不得不佩服谷歌这粗暴的解决问题的方式，这样一来确实Android手机从万年卡顿慢慢的坑中出来了。

⑤ Android 8.0 改进解释器

在Android8.0时期，谷歌又盯上了解释器，其实纵观上面的问题，根源就是这个解释器解释的太慢了！（什么JIT,AOT,老夫解释只有一个字，快）那我们何不让这个解释器解释的快一点呢？ 于是谷歌改进了解释器，解释模式执行效率大大提升。

⑥ Android 9.0 改进编译模板

这个点会在下文字节码的编译模板中详述。

这边简单而言就是，在Android9.0上提供了预先放置热点代码的方式，应用在安装的时候就能知道常用代码会被提前编译。（借用知乎@weishu大神的原话）

2.JNI——Java和C互相调用慢

JNI又称为 Java Native Interface，翻译过来就是Java原生接口，就是用来跟C/C++代码交互的。

如果不做Android开发的可能不知道，Android项目里的代码除了Java,很有可能还有部分C语言的代码。

这个时候有个严重的问题，首先上图 (图片参考方舟编译器原理PPT)：

在开发阶段Java源代码在开发阶段打包成.dex文件，C语言直接就是.so库，因为C语言本身就是编译语言。

在用户手机中，APK中的.dex文件（字节码）会被解释为.oat文件（机器码）运行在ART虚拟机中，.so库则为计算机可以直接运行的二进制代码（机器码），两份机器码要互相调用肯定是有开销的。

下面就来阐述下为什么两份机器码会不同。

这边需要深入理解字节码->机器码的编译过程，在图上虽然都被编译成了机器码，都能被硬件直接调用，但是两份机器码的性能，效率，实现方式相差甚多，这主要是由以下两个点造成的：

• 编程语言不同导致编译出的字节码不同导致编译出的机器码不同。

举个🌰，针对同样是静态语言的C和Java，对int a + b 的运算

C语言可以直接加载内存，在寄存器中计算，这是由于C语言是静态语言，a和b是确定的int对象。

在Java中虽然定义对象我们也要明确的指出对象的类型，例如int a = 0,但是Java拥有动态性，Java拥有反射，代理，谁也不敢保证a在被调用时还是int类型，所以Java的编译需要考虑上下文关系，即具体情况具体编译。

所以连字节码已经不同了，编译出的机器码肯定不同。

• 运行环境不同导致编译出的机器码不同

图中明显看到由Java编译而来的机器码包裹在ART中，ART全称Android RunTime，即安卓运行环境，跟虚拟机差不多是一个意思。而C语言所在的运行环境不在ART中。

RunTime提供了基本的输入输出或是内存管理等支持，如果要在两个不同的RunTime中互相调用，则必然有额外开销。

举个🌰，由于Java有GC（垃圾回收机制），在Java中的一个对象地址不是固定的，有可能被GC挪动了。即在ART环境中跑的机器码中的对象的地址不固定。可是C语言哪管那么多幺蛾子，C就直接问Java要一个对象的地址，但万一这个对象地址被挪动了，那就完蛋了。解决方案有两个：

1. 把这个对象在C里再拷一份。很明显这造成了很大的开销。
2. 告诉ART，我要用这个对象了，GC这个对象的地址你不能动！你先一边呆着去。这样相对而言开销倒是小了，但如果这个地址如果一直不能被回收的话，可能造成OOM。

（此处参考知乎@张铎在华为公布的方舟编译器到底对安卓软件生态会有多大影响？中的回答）

3. 字节码的编译模板——未针对具体APP进行优化

我们举个🌰来理解编译模版，“Hello world”可以被翻译为“你好，世界”，同样也可以被翻译为“世界，你好”，这个差别就是编译模版不同导致的，

①. 统一的编译模版（vm模版）

字节码可以通过不同的编译模版被编译为机器码，而编译模版的不同将直接导致编译完后的机器码性能大相径庭。

在安卓中，ART有一套规定的，统一的编译模版，暂且称为VM模版，这套模版虽算不上差劲，但也算不上优秀。

因为它是谷歌爸爸搞出来的，肯定算不上差劲，但由于没有针对每一个APP进行特定的优化，所以也算不上优秀。

②. vm模版存在的问题

问题就存在于没有针对每一个APP进行优化。

在上文谷歌对于Android2.2的虚拟机优化中已经讲到过，那时候谷歌使用JIT将用户常用的功能记下来(热点代码)，当用户打开APP的时候立马将这些内容编译出来，即优先编译热点代码。

但是到了Android7.0的混合编译时代，由于AOT的存在，这个功能被弱化了，这时JIT记录下的热点代码并非是持久化的。AOT的编译优先级遵循于vm模版，AOT根据模板的内容将一些字节码优先编译为机器码。

那么这个时候就产生了一个问题。

先举个🌰，一家中餐馆的招牌菜是番茄炒蛋，那么番茄炒蛋的备菜肯定很足，但是顾客A特立独行，他偏偏不要吃番茄炒蛋，他每次都点一个冷门的牛排套餐，那这时候只能让顾客等着老板将牛排套餐做完。

如果一个APP的热点代码（如首页），刚好游离于VM模板之外，那么AOT就其实形同虚设了。(比如vm模版优先编译名称不大于15个字符的类和方法，但是首页的类名刚好高于15个字符。此处仅为举例并没有实际论证过）

下面用首页和设置页来举例：由于遵循vm模版，AOT因为某个原因没有优先编译首页部分代码，而转而去编译了不太重要的设置页代码：

上图的流程说明了在特殊情况下，AOT编译实则不起作用，完全是靠解释器和JIT在进行实时编译，整个编译方案退步到了Android2.2时期。

③. 聪明的ART

虽然这个问题存在，但并不是特别严重。因为ART并没有我说的那么笨。在之后应用使用过程中，ART会记录并学习用户的使用习惯（保存热点代码），然后更新针对当前APP的定制化vm模版，不断的补充热点代码，补充定制化模版。

这是不是听起来很熟悉？在手机发布大会上的宣传语“基于用户操作习惯进行学习，APP打开速度不断提高”的部分原理就是这个。

④. 最终大招，一劳永逸

其实要一劳永逸的解决这个问题思路也不难：我们只需要在吃饭前跟老板提前预定想吃啥就行，让老板先准备起来，这样等我们到了就不用等餐了。

在最新的Android9.0版本中，谷歌推出了这个类似提前预定的功能：编译系统支持在具有蓝图编译规则的原生 Android 模块上使用 Clang 的配置文件引导优化 (PGO)。

说人话：谷歌允许你在开发阶段添加一个配置文件，这个配置文件内可指定“热点代码”，当应用安装完后，ART在后台悄悄编译APP时，会优先编译配置文件中指定的“热点代码”。

虽然谷歌支持，但是这块技术对于APP开发人员而言国内资料过于缺乏，普及面不广。笔者先贴上官方链接，以及这篇博客，其中介绍的还是挺详细的。（隔壁Xcode针对PGO都有UI界面了）

三、解决思路

解决思路总结为四个字就是：华为方舟。

方舟的解决思路：

1. 针对虚拟机问题，方舟说：我不要你这个烂虚拟机了，我们裸奔

2. 针对JNI调用问题，方舟说：我们让Java在编译阶段跟C一样直接编译成机器码，干掉虚拟机，跟.so库直接调用，毫无JNI开销问题

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

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

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

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

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V：vip204888 备注Android获取（资料价值较高，非无偿）

尾声

对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。 整理的这些架构技术希望对Android开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。

最后想要拿高薪实现技术提升薪水得到质的飞跃。最快捷的方式，就是有人可以带着你一起分析，这样学习起来最为高效，所以为了大家能够顺利进阶中高级、架构师，我特地为大家准备了一套高手学习的源码和框架视频等精品Android架构师教程，保证你学了以后保证薪资上升一个台阶。

当你有了学习线路，学习哪些内容，也知道以后的路怎么走了，理论看多了总要实践的。

进阶学习视频

附上：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题 （含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）

附上：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题 （含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）

[外链图片转存中…(img-2nlN4Tzt-1711535177003)]

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