深入Android Runtime: 指令优化与Java方法调用

作者简介:dc, 天天P图AND工程师

做一个小试验

先做一个小试验: 在apk的activity中放一个Button和一个TextView,点击Button让结果显示在TextView上。

apk的代码如下:

public class MainActivity extends AppCompatActivity {

    Button button;
    TextView textView;    @Override
    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        textView = findViewById(R.id.text);
        button = findViewById(R.id.button);
        button.setOnClickListener(new View.OnClickListener() {            @Override
            public void onClick(View v) {

                Test test = new Test();
                String s = test.getValue();
                textView.setText(s);

            }
        });
    }
}

其中Test类的代码如下:

public class Test {    
    public String getValue() {        
        return "this is method getValued";
    }
}

试着思考下,文本框显示的结果会是什么?

第1次结果:

如果运行正常,结果会如下(本次测试全部在Android AOSP N上执行):

this is method getValued

进一步试验

接下来,再进一步试验。
我们给apk的PathClassLoader的ClassPath最前面注入一个dex,这个dex仅包含一个class,和之前的Test的包名+类名一致,如下:

public class Test {    public String getValue(){        return "this is method getValue from dex";
    }    public String abc(){        return "this is method abc !!!";
    }
}

这是最简单的热修复原理,猜想一下,这次的结果是什么?

第2次结果

这次的结果会是什么呢?

实际上,在debug版本上,我们能够得到正确的结果:

而在release版本上,结果并不是我们想象的这样,结果如下:

现象解释

为什么会出现这样的现象:明明调用的是getValue方法,为什么返回的是abc方法的结果呢?
要解释这个现象,我们需要对Android虚拟机执行代码的原理有一定的了解。

当我们将Java代码编译成apk时,编译器会用javac将java文件转成class文件,再通过dx将class文件转成dex文件(如果是jack&jill编译器,不会有class生成的过程)。
apk安装时候,PMS会通过installd唤起dex2oat进程对apk进行优化。
当我们启动系统时候,虚拟机先加载BootClassLoader,再加载SystemClassLoader,分别将BOOTCLASSPATH和SYSTEMSERVERCLASSPATH中对应jar包中的class加载起来,。

apk启动时,将会创建一个PathClassLoader,将apk相关及其依赖的library中的class加载到内存。
如果我们往PathClassLoader的clssapath中最开始注入新的jar/dex,在运行时PathClassLoader就会优先加载前面的jar/dex,从而覆盖apk本身的类实现类的替换。

但是我们通常不会注意到虚拟机的机制。

在安装apk时,如果apk是debug版本,会被强制以解释方式执行,此时执行的是字节码,我们看到的字节码是这样的:

即invoke-virtual+methodID的方式执行。这个methodID是存储在apk自身的dex中的,每个dex中都有一个String表和Method表(当然还有Class表等其他表)。
通过String表,可以查到某个index对应的String是什么;通过method表,可以拿到methodID对应的StringID,然后再到String表中查到方法名称。
虚拟机通过方法名称,再从已加载cache中查找方法,如果方法没找到,就从classpath加载并resolve,最终找到对应的method。

那么正常debug版本解释执行时,这个过程是没有任何问题的,包括使用新的类覆盖了旧的类的时候,仍然可以通过自身编译时就决定的methodID拿到正确的方法名,也就可以获取到正确的method并执行。

但是release版本的时候,dex会被优化的。dex2oat根据系统prop中的配置决定进行何种程度的优化,在AOSP N上,默认配置如下:

interpret-only模式的优化,实际上只是dalvik指令级的优化,并不会生成机器码(其他speed之类的优化模式会产生部分机器码,everything模式是完全编译,将所有字节码均优化成机器码),而是会对invoke-virtual这样的指令进行quicken优化,变成invoke-virtual-quick。
优化的目的,是将methodID的查找变成vtable的查找。methodID是dex全局的查找,相比vtable在class内部的查找,效率要高很多,毕竟一个dex中很可能有几万个method,而一个class中的method通常只有几个到几十个。

interpret-only的优化,是基于一个前提,编译时不仅能获取到class的名称,还能获取到class的定义。
因为我们是动态加载了dex,这个dex只有在classloader加载dex时才会被发现,dex2oat编译时只知道apk自身中的class的存在。

dex2oat进行interpret-only优化时,编译依赖是原先的method,导致生成的vtable索引为原先Test类中的方法索引。但是运行的时候,新的Test类由于加上了一个abc的方法,android中的各种String表、method表、vtable等都是按照字母表顺序进行排序,导致abc方法排在Test方法之前,这样原先的vtable索引查到的method就变成了abc方法。

由于vtable索引的变化,就出现了明明是调用的Test方法,可结果跑的是abc方法的奇特现象。

如果我们进行verify-none模式的编译(不进行quicken优化,或者其他能编译成机器码的模式),让其以解释模式运行,就不会有问题。但是如果apk在Manifest中设置了android:vmSafeMode=”true” ,那么无论是否使用了其他模式进行强制编译,apk会始终以interpret-only方式编译,导致问题一直存在。
比如我们使用speed编译,日志中依然是interpret-only:

总结

在进行apk热修复、插件化、动态加载的时候,会经常多个jar/dex包含相同的class,如果class结构因为需要升级出现了变化,会隐藏一些很难解释的坑在里面,务必谨慎。

原文 

https://cloud.tencent.com/developer/article/1354486

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 深入Android Runtime: 指令优化与Java方法调用

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址