[原创]从华为方舟编译器看一种JavatoC语言解释器的实现
（一）背景介绍
最近网络上流传的华为方舟编译器很火，随着热度的提高，华为也将技术原理做了简单披露。我们来看官方的描述，原文https://baijiahao.baidu.com/s?id=1632292071046828780&wfr=spider&for=pc。此时此刻，这套编译器华为还没有开源。
作为安全行业的从业者，我想大家很清楚安卓下的所谓C语言就是JNI(JAVA Native Interface)。安全开发者为了实现关键的安全防护功能自我保护，我们通常将功能实现在JNI里，然后用NDK编译成so文件，再通过对so加壳或者虚拟机化，进一步自我保护，这样可以极大增强上图提到的“安全性”。上图传达出的第二条信息是，该编译器将java和C（JNI）编译成一套可执行文件，到底是什么可执行文件呢？我们再往下看
什么是干掉虚拟机？我们知道，语言分成编译型语言和解释型语言，前者的典型是C，苹果是ObjectC，编译器将C语言直接编译成机器指令后由CPU执行，后者的典型就是Java语言，即由JVM里的解释器来执行java字节码，这个解释器就是虚拟机的核心之一。
所以我们不妨大胆猜测：所谓“干掉虚拟机”，是指将java代码转换成C代码，即将解释执行转换成编译后执行，由于C的执行速度比Java语言快，因为编译执行总是快于解释执行，从而实现了性能的提升。
上图传达出的信号是：这套编译框架甚至还可以优化java语言的执行效率，也就是java代码的编译优化。
上图所反映的法律和知识产权问题，据说谷歌和华为真正的老板其实是同一群（个）人，不多谈。
所以总结下来：华为的所谓“方舟”编译框架是：输入用户源代码，先将其中java语言进行优化，之后将它转换为C语言（JNI），从而提高执行效率。所以这套编译器的本质，我的猜测是：JAVA to C，或者JAVA to JNI，方舟编译器的本质是，一个基于编译器的语言解释器。
其实国外有很多成熟的JAVA to C/Native编译框架，不论是商用的还是开源的，比如Toba，Vortex，Marmot，IBM High performancefor Java Compiler,TowerJ
,superCede等等，都可以是可以提供大量的借鉴的。搜索java native compiler了解更多。另外国内很多安全厂商，据说几年前就能提供类似的且比较成熟的方案，不排除华为“借鉴”了友商的方案，工程框架确定后，凭借数量众多的工程师和强大的执行力，自身的产业号召力和国家资本的帮助迅速将其商业化和产业化。但是能否如华为宣传的数据如此之漂亮， 实际性能，用户的实际体验究竟能提升多少，作为从业人员，我本人并不那么乐观。而且这种转换很有可能降低系统的稳定性和兼容性。
那么接下来才是本文的重点：作为技术人员，我们要如何实现这套编译器呢？在这里，我提出一种方案，可以完整覆盖上述的所有特性，一样可以实现华为所宣传的方案，希望能抛砖引玉，分享不同的思路的效果。条条大路通罗马。
（二）JAVA语言的编译优化
第一步要实现华为宣称的“一个好的编译器，开发者一行代码都不需要修改，性能提升10%-20%”。
[图片:803510_YRSRSYWH7HQ2CY3.jpg]
绝大部分安卓APP超过99%的代码都是JAVA语言写的，所以对JAVA的优化尤为重要。我们使用soot框架来优化，Soot是什么呢？它是由加拿大麦吉尔大学Sable Reasearch Group维护的，用来优化java程序的一套成熟的框架，这套框架的文档非常之全，可以让新人快速上手。
正如上图所说：java有很多优秀特性，但执行效率不如C/C++，为了优化java执行效率，soot应运而生。
Soot的Github地址是https://github.com/Sable/soot，文档不限于以下https://github.com/Sable/soot/wiki/Tutorials
Soot的原理是什么呢？和LLVM相似，编译框架会将原始代码转换成一种中间语言。由于中间语言相当于一款编译器前端和后端的“桥梁”，无论是学习Soot还是LLVM，透彻了解他们的中间语言无疑是非常必要的工作。 Soot共有4种中间语言：BafBody，GrimpBody ，ShimpleBody 和 JimpleBody，每一种中间语言都可以进行优化。
BafBody：一种字节流形式的java字节码表示方法，易于操作和维护；
Jimple：一种规范的三地址码形式的中间表示；
Grimple：一种更加适合反编译的Jimple表示形式
对于Baf的表示如下所述
Baf是基于栈的表示，是一种较为初级的IR
在Jimple语言中，用的最多的就是statement型语句，这15种如上图所述。我们知道在java字节码中，总共有将近200多种指令，而现在的Jinple却只有15种statement，是不是大大简化了？并不是只有15中，而是其他种的指令要少很多，用到频率低。
那么soot的中间语言Jiimple长什么样的呢？ 我们再看一个例子
这是转换之前的java源代码
这是转换之后的Jimple代码
是不是很容易就能看懂呢？我们可以简单总结一下Jimple的语法特性：
1.使用$开头的局部变量表示的是一个栈内的地址，它不表示一个真实的局部变量。而不以$开头的才是真正的局部变量。以$开头的变量由于不是原java代码里真实的变量，存在于堆中，所以是一种“堆媒介”
2类似int x = (f.bar(21) +a) * 长指令会被分隔成$i4 = $i3 + i0 和 i2 = $i4 * i1这样的三地址形式的指令。 什么是三地址码？就是形如x = y op z 型的指令
3参数值和this指针使用IdentityStmt形式的表达式被分配到一个具体的局部变量中，比如i0 := @parameter0: int; 以及r0:= @this: Foo。进一步讲，由于x := @parameter0符合形如identityStmt下的local := @paramrtern:type可知paramrter0就是第一个参数，local代表局部变量（或者立即数）了
要想继续推进,首先要对jimple代码足够熟悉。
上面的两个表，详细阐述了jimple语法的规范，从上面我们可以看到上面所说的15种statemnt和其他的几种指令，不得不说文档很齐全很细致，比我之前用的JS编译框架esprima好很多。总之只要根据官方提供的手册，可以很清楚搞清楚java和jimple的一一对应关系，自然就熟悉了Jimple语法。
这种形式的中间语言优势很多，因此也是很多自定义优化步骤和自由化工具处理的对象。我们的节点转换器也不例外，就是以Jimple代码为基础进行转换的
如果您熟悉编译器的优化，相信您已经被三地址码这种简洁又规整的形式吸引了。没错，但是soot还提供了一种更加适合编译优化的语言：shimple。它是一种静态单赋值型的语言（SSA），它保证了每一个局部变量只有一个赋值，将极大简化分析。除此之外，他和Jimple还有一个巨大的区别是它还引入了Phi节点，所以它是特别适合用来做优化和分析的一种语言了。但是这里我们不做过多介绍，编译优化,有大量成熟的算法可供借鉴,这里我们不多谈,我们还是选择Jimple作为转换对象.
关于Jimple的语法规范，官网上有详细的文档供查阅。
（三）JAVA to C
现在尝试去实现华为宣传的第二个特性：彻底抛开虚拟机。
[图片:803510_HQSPV9H73454XHD.jpg]
只要能将java字节码由解释器解释执行，转换为编译后直接由CPU执行，是不是自然就实现了上面的功能呢？就“干掉”虚拟机呢？但是怎么转化呢？由于前面已经能够将200多种字节码指令转换成20多种指令，如果我们将这不超过20种指令的JImple，做个等价转换，也就是一个节点（node）的解释器，是不是就可以实现JAVA toC呢？也就是说，首先将java代码进行简化，分成有限的几种指令，接着只要根据每一种指令，转换成JNI语法，最后再编译成so，让原本的java字节码指令转为执行so里的JNI，就实现了从java代码到C代码的转换
转换成JNI后的代码不仅更加安全，还能提高执行效率，和上述完全吻合！
现在我们简单的看一两个转换示例：
假设我们有一个被测试的类，如下所示：
package demo;
public class have_a_try {
public static void main(String[] args) {
System.out.println("Hello World");
return ;
}
}
注意：上传附件及图片大小不得大于30M。
⚠️ 版权声明：
本博客所有内容（含教程、源码、工具）仅供个人技术学习与研究交流使用，严禁商用、倒卖、二次分发及非法用途。
未经作者书面授权，任何组织或个人不得转载、复制或用于其他平台，违者将追究相关责任。
参与讨论
登录后可查看全部回复并参与讨论。
