Android Runtime运行linux命令
Init进程是linux环境下非常重要的一个进程,而Zygote进程是Java环境下的第一个进程,所有其他的Java环境下的进程都是由Zygote进程来进行fork的,而init进程在启动Zygote进程之后,初始化Zygote进程之前,会先进行AndroidRuntime的启动和环境建立。 Dalvik是典型的JIT,这种模式下,每次重新启动一个APP进程,都要求Dalvik虚拟机在后台迅
·
Init进程是linux环境下非常重要的一个进程,而Zygote进程是Java环境下的第一个进程,所有其他的Java环境下的进程都是由Zygote进程来进行fork的,而init进程在启动Zygote进程之后,初始化Zygote进程之前,会先进行AndroidRuntime的启动和环境建立。
Dalvik是典型的JIT,这种模式下,每次重新启动一个APP进程,都要求Dalvik虚拟机在后台迅速把字节码进行运行时编译和优化,无形中降低了启动速度。由于是运行时编译,所以代码的执行速度必然受到一定的影响,这也是Android常常被人说“不流畅”的原因之一。而ART则是把字节码在运行前就编译为机器码,即所谓OAT文件(在4.4上,为了兼容Dalvik,它的后缀仍然是.dex)。OAT文件里面是原生机器码,可以在ART的GC等组件的支持下直接执行。运行时少了编译这个环节,直接执行机器码,速度当然可想而知。在我的米1上运行的ART虚拟机,对系统运行速度(流畅度)有非常明显的提升。当然,对于高性能手机而言,其实这种提升目前并不是十分明显。其实受益最大的还是中低端手机或者老手机了。当然,ART也有一个非常严重的弊端,那就是编译速度。因为它需要预编译字节码为机器码,而这个过程总是在第一次启动系统或更新系统的时候进行,就会导致开机速度非常非常非常非常慢,至少在我的老手机上是这样的。普通用户也许愿意在第一次刷机或升级系统时等待个十来分钟二十分钟这样子。
AOT预编译和JIT即时编译相比,有若干项优化技术从理论上就无法实施。换句话说,AOT能做的优化,JIT都能做;但JIT能做的优化,有若干项是AOT做不了的,例如性能分析制导的编译优化、虚函数inlining等等。
> Android Runtime使得直接调用底层Linux下的可执行程序或脚本成为可能,注意权限问题
do_exec("ls /mnt/sdcard"); do_exec("cat /proc/version"); do_exec("rm /mnt/sdcard/1.jpg"); do_exec("/system/bin/sh /mnt/sdcard/test.sh 123");
String do_exec(String cmd) {
String s = "/n";
try {
Process p = Runtime.getRuntime().exec(cmd);
BufferedReader in = new BufferedReader(
new InputStreamReader(p.getInputStream()));
String line = null;
while ((line = in.readLine()) != null) {
s += line + "/n";
}
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
text.setText(s);
return cmd;
}
> 使用Runtime运行linux命令
public boolean execute(String cmd) {
String[] command = new String[] { "sh", "-c", cmd };
Runtime runtime = Runtime.getRuntime();
try {
Process process = runtime.exec(command);
BufferedReader in = new BufferedReader(new InputStreamReader(process.getInputStream()));
String line;
StringBuffer pathBuf = new StringBuffer();
while ((line = in.readLine()) != null) {
pathBuf.append(line);
}
in.close();
} catch (IOException e) {
e.printStackTrace();
return false;
}
return true;
}
Android 资源替换-----Runtime Resource Overlay(RRO)。RRO是在Android5.0后引入的,它能在 apk 运行时,自动加载需要定制的资源,而不加载原有的资源。RRO是在系统层做的,Android出于安全考虑,要想overlay生效必须将生成的overlay apk放到/system/vendor/overlay目录下才会生效。RRO的应用场景主要是在方案开发时用到,上面的例子只是替换了string资源,实际上RRO能支持除了 layout 和 AndroidManifest 外的所有资源定制,在做ROM定制开发时还是非常有用的。曾经测试报了一个google应用字串太长显示不全的问题,但google 应用压根就没有代码,只有apk,当时就是靠RRO来解决该bug的。RRO剥离了代码和资源的共生关系,在方案开发中可以针对不同的显示需求,打包不同的overlay apk,不用每次更改UI资源都去修改原来的应用。
android6.0源码分析之Runtime的初始化- http://blog.csdn.net/yangzhihuiguming/article/details/51697801
android6.0源码分析之Zygote进程分析- http://blog.csdn.net/yangzhihuiguming/article/details/51774080
Dalvik是典型的JIT,这种模式下,每次重新启动一个APP进程,都要求Dalvik虚拟机在后台迅速把字节码进行运行时编译和优化,无形中降低了启动速度。由于是运行时编译,所以代码的执行速度必然受到一定的影响,这也是Android常常被人说“不流畅”的原因之一。而ART则是把字节码在运行前就编译为机器码,即所谓OAT文件(在4.4上,为了兼容Dalvik,它的后缀仍然是.dex)。OAT文件里面是原生机器码,可以在ART的GC等组件的支持下直接执行。运行时少了编译这个环节,直接执行机器码,速度当然可想而知。在我的米1上运行的ART虚拟机,对系统运行速度(流畅度)有非常明显的提升。当然,对于高性能手机而言,其实这种提升目前并不是十分明显。其实受益最大的还是中低端手机或者老手机了。当然,ART也有一个非常严重的弊端,那就是编译速度。因为它需要预编译字节码为机器码,而这个过程总是在第一次启动系统或更新系统的时候进行,就会导致开机速度非常非常非常非常慢,至少在我的老手机上是这样的。普通用户也许愿意在第一次刷机或升级系统时等待个十来分钟二十分钟这样子。
AOT预编译和JIT即时编译相比,有若干项优化技术从理论上就无法实施。换句话说,AOT能做的优化,JIT都能做;但JIT能做的优化,有若干项是AOT做不了的,例如性能分析制导的编译优化、虚函数inlining等等。
> Android Runtime使得直接调用底层Linux下的可执行程序或脚本成为可能,注意权限问题
do_exec("ls /mnt/sdcard"); do_exec("cat /proc/version"); do_exec("rm /mnt/sdcard/1.jpg"); do_exec("/system/bin/sh /mnt/sdcard/test.sh 123");
String do_exec(String cmd) {
String s = "/n";
try {
Process p = Runtime.getRuntime().exec(cmd);
BufferedReader in = new BufferedReader(
new InputStreamReader(p.getInputStream()));
String line = null;
while ((line = in.readLine()) != null) {
s += line + "/n";
}
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
text.setText(s);
return cmd;
}
> 使用Runtime运行linux命令
public boolean execute(String cmd) {
String[] command = new String[] { "sh", "-c", cmd };
Runtime runtime = Runtime.getRuntime();
try {
Process process = runtime.exec(command);
BufferedReader in = new BufferedReader(new InputStreamReader(process.getInputStream()));
String line;
StringBuffer pathBuf = new StringBuffer();
while ((line = in.readLine()) != null) {
pathBuf.append(line);
}
in.close();
} catch (IOException e) {
e.printStackTrace();
return false;
}
return true;
}
Android 资源替换-----Runtime Resource Overlay(RRO)。RRO是在Android5.0后引入的,它能在 apk 运行时,自动加载需要定制的资源,而不加载原有的资源。RRO是在系统层做的,Android出于安全考虑,要想overlay生效必须将生成的overlay apk放到/system/vendor/overlay目录下才会生效。RRO的应用场景主要是在方案开发时用到,上面的例子只是替换了string资源,实际上RRO能支持除了 layout 和 AndroidManifest 外的所有资源定制,在做ROM定制开发时还是非常有用的。曾经测试报了一个google应用字串太长显示不全的问题,但google 应用压根就没有代码,只有apk,当时就是靠RRO来解决该bug的。RRO剥离了代码和资源的共生关系,在方案开发中可以针对不同的显示需求,打包不同的overlay apk,不用每次更改UI资源都去修改原来的应用。
android6.0源码分析之Runtime的初始化- http://blog.csdn.net/yangzhihuiguming/article/details/51697801
android6.0源码分析之Zygote进程分析- http://blog.csdn.net/yangzhihuiguming/article/details/51774080
更多推荐
已为社区贡献14条内容
所有评论(0)