编写高效的android代码.doc

编写高效的android代码.doc

ID:49528462

大小:43.50 KB

页数:13页

时间:2020-03-02

编写高效的android代码.doc_第1页
编写高效的android代码.doc_第2页
编写高效的android代码.doc_第3页
编写高效的android代码.doc_第4页
编写高效的android代码.doc_第5页
资源描述:

《编写高效的android代码.doc》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库

1、虽然如此说,但似乎并没有什么好的办法:Android设备是嵌入式设备。现代的手持设备,与其说是电话,更像一台拿在手中的电脑。但是,即使是“最快”的手持设备,其性能也赶不上一台普通的台式电脑。这就是为什么我们在书写Android应用程序的时候要格外关注效率。这些设备并没有那么快,并且受电池电量的制约。这意味着,设备没有更多的能力,我们必须把程序写的尽量有效。本章讨论了很多能让开发者使他们的程序运行更有效的方法,遵照这些方法,你可以使你的程序发挥最大的效力。简介对于占用资源的系统,有两条基本原则:·不要做不必要的事·不要分配不必要的内存所有下面的内容都遵照这两个原则。

2、有些人可能马上会跳出来,把本节的大部分内容归于“草率的优化”(xing:参见[TheRootofAllEvil]),不可否认微优化(micro-optimization。xing:代码优化,相对于结构优化)的确会带来很多问题,诸如无法使用更有效的数据结构和算法。但是在手持设备上,你别无选择。假如你认为Android虚拟机的性能与台式机相当,你的程序很有可能一开始就占用了系统的全部内存(xing:内存很小),这会让你的程序慢得像蜗牛一样,更遑论做其他的操作了。Android的成功依赖于你的程序提供的用户体验。而这种用户体验,部分依赖于你的程序是响应快速而灵活的,还是

3、响应缓慢而僵化的。因为所有的程序都运行在同一个设备之上,都在一起,这就如果在同一条路上行驶的汽车。而这篇文档就相当于你在取得驾照之前必须要学习的交通规则。如果大家都按照这些规则去做,驾驶就会很顺畅,但是如果你不这样做,你可能会车毁人亡。这就是为什么这些原则十分重要。当我们开门见山、直击主题之前,还必须要提醒大家一点:不管VM是否支持实时(JIT)编译器(xing:它允许实时地将Java解释型程序自动编译成本机机器语言,以使程序执行的速度更快。有些JVM包含JIT编译器。),下面提到的这些原则都是成立的。假如我们有目标完全相同的两个方法,在解释执行时foo()比ba

4、r()快,那么编译之后,foo()依然会比bar()快。所以不要寄希望于编译器可以拯救你的程序。避免建立对象世界上没有免费的对象。虽然GC为每个线程都建立了临时对象池,可以使创建对象的代价变得小一些,但是分配内存永远都比不分配内存的代价大。如果你在用户界面循环中分配对象内存,就会引发周期性的垃圾回收,用户就会觉得界面像打嗝一样一顿一顿的。所以,除非必要,应尽量避免尽力对象的实例。下面的例子将帮助你理解这条原则:·当你从用户输入的数据中截取一段字符串时,尽量使用substring函数取得原始数据的一个子串,而不是为子串另外建立一份拷贝。这样你就有一个新的String

5、对象,它与原始数据共享一个char数组。·如果你有一个函数返回一个String对象,而你确切的知道这个字符串会被附加到一个StringBuffer,那么,请改变这个函数的参数和实现方式,直接把结果附加到StringBuffer中,而不要再建立一个短命的临时对象。一个更极端的例子是,把多维数组分成多个一维数组。·int数组比Integer数组好,这也概括了一个基本事实,两个平行的int数组比(int,int)对象数组性能要好很多。同理,这试用于所有基本类型的组合。·如果你想用一种容器存储(Foo,Bar)元组,尝试使用两个单独的Foo[]数组和Bar[]数组,一定比

6、(Foo,Bar)数组效率更高。(也有例外的情况,就是当你建立一个API,让别人调用它的时候。这时候你要注重对API借口的设计而牺牲一点儿速度。当然在API的内部,你仍要尽可能的提高代码的效率)总体来说,就是避免创建短命的临时对象。减少对象的创建就能减少垃圾收集,进而减少对用户体验的影响。使用本地方法当你在处理字串的时候,不要吝惜使用String.indexOf(),String.lastIndexOf()等特殊实现的方法(specialtymethods)。这些方法都是使用C/C++实现的,比起Java循环快10到100倍。使用实类比接口好假设你有一个HashM

7、ap对象,你可以将它声明为HashMap或者Map:MapmyMap1=newHashMap();HashMapmyMap2=newHashMap();哪个更好呢?按照传统的观点Map会更好些,因为这样你可以改变他的具体实现类,只要这个类继承自Map接口。传统的观点对于传统的程序是正确的,但是它并不适合嵌入式系统。调用一个接口的引用会比调用实体类的引用多花费一倍的时间。如果HashMap完全适合你的程序,那么使用Map就没有什么价值。如果有些地方你不能确定,先避免使用Map,剩下的交给IDE提供的重构功能好了。(当然公共API是一个例外:一个好的API常常会牺牲一

8、些性能)用

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。