如何提升Android的运行效率?在Android 4.4将用ART运行时替代Dalvik来提升效率

Android开发中存在的效率问题

目前,Android开发过程中普通的程序员拿不到真机测试,无法判断运行效率。一个嵌入式开发程序员可能都知道模拟器和真机的环境差距还是很大的,今天为大家分析一下运行效率。首先我们清楚的是在硬件方面官方已经考虑使用ARM9系列的CPU,工作频率在195MHz到220MHz之间,代表为TI OMAP 850,飞思卡尔等。由于使用了运行效率高的Linux内核,在内存占用和多任务方面还是比较强劲的,但是面临的问题为Java开发API。官方为什么没有像Symbian和Windows Mobile那样提供两种语言开发可能主要是时间问题。未来可能会加入的,不然不像Google的作风。当然真机发布时还有很多周边设备的驱动等问题的编写。
既然使用了运行效率低的Java,程序员就要考虑代码效率了,优化代码是很重要的事情,在Java方面主要用在企业和手机游戏,我们都清楚Java内存分配new后不用自己delete,有GC帮助资源回收。但是Java的异常处理还是和C无法相比,稳定性可能最重要的,毕竟未来的厂商生产时会自己定制GPhone硬件,造成运行兼容性等问题。Java的跨平台越来越差了,目前冒出的Dalvik会如何呢?尽管Sun CEO表示希望Android和JME兼容但从目前的代码中看很多都是重复的图形库居多。
程序员抵制的主要是优化代码运行,如分配局部临时变量时的位置、在算法方面少用递归,线程同步等问题。

在Android 4.4将用ART运行时替代Dalvik来提升效率

Android操作系统已逐渐成熟,谷歌开始将注意力转向一些底层组件,其中之一是负责应用程序运行的Dalvik运行时,谷歌已经花了两年时间开发更快执行效率更高、更省电的ART运行时。可能你还没有意识到,新的ART运行时是Android 4.4系统最大的一次革新。

 

ART是“Android Runtime”的缩写,顾名思义,它是安卓系统赖以生存的底层运行环境。

在过去,安卓的底层代码由Dalvik Java虚拟机运行,Dalvik依靠一个Just-In-Time(JIT)编译器去向硬件“解释”App字节码,代码和硬件打交道时平白无故多出一个解释过程,这一机制并不高效,被看作安卓运行效率低下的“毒瘤”。不过,Dalvik虚拟机让应用能更容易在不同硬件和架构上运行,是安卓系统普及的功臣。

 

而新的ART则完全改变了这套做法,其处理应用程序执行的方式完全不同于Dalvik,在应用安装时,ART就直接把代码预编译成机器语言,这一机制叫Ahead-Of-Time (AOT)编译。和Dalvik相比,经过ART编译后的应用从根本上省略了解释字节码这个过程,运行起来更有效率、耗电更少、占的内存也更低。

当然,预编译也带来了两个问题,一个是应用占用的存储空间将会更大,另一个是这个过程也会让应用安装耗时更长。预编译的App体积至少会大20%,安装时间则要看App本身的复杂程度。不过,App的安装过程只有一次,相信大部分人是能忍受这个时间的。

实际上,谷歌早在Android 4.2的时候就已经开展了新运行环境“ART”的测试,现在ART运行环境已经在Android 4.4中开放测试了,用户可以在开发者选项中找到“Select runtime”,然后选择“Use ART”并重启即可。

开发实例FAQ:

:现在实现一个在线实时的视频监控,实时接收网络H264数据,然后解码显示,显示的时候是用ImageView来显示的,但是发现当全屏显示时,会耗费较大的时间,导致显示延时。 我解码出来的是320*240的图片,然后显示的时候是用imageView.setImageBitmap(bitmap),在布局文件中我设置长宽fill_parent,我手机是800*480的,系统在绘制时会自动进行拉升,定位后发现耗费的时间出现在此处。 请问有没有其他的办法可以提升效率绘制图片的,例如windows mobile有directshow,或者能否使用opengl来绘制,我看做3D游戏赛车是全屏的,效率还不错。

:1.解码的时候就解成你屏幕大小的; 2,用surfaceview来完成

此条目发表在 安卓开发 分类目录,贴了 , , , , , 标签。将固定链接加入收藏夹。

发表评论