织梦做分类信息网站,云主机软件,网站后缀名,网络营销评价的名词解释原文 http://developer.android.com/guide/practices/design/performance.html 性能优化 Android应用程序运行的移动设备受限于其运算能力#xff0c;存储空间#xff0c;及电池续航。由此#xff0c;它必须是高效的。电池续航可能是一个促使你优化程序的原因#xff0c;即… 原文 http://developer.android.com/guide/practices/design/performance.html 性能优化 Android应用程序运行的移动设备受限于其运算能力存储空间及电池续航。由此它必须是高效的。电池续航可能是一个促使你优化程序的原因即使他看起来已经运行的足够快了。由于续航对用户的重要性当电量耗损陡增时意味这用户迟早会发现是由于你的程序。 虽然这份文档主要包含着细微的优化但这些绝不能成为你软件成败的关键。选择合适的算法和数据结构永远是你最先应该考虑的事情但这超出这份文档之外。 简介 写出高效的代码有两条基本的原则 l 不作没有必要的工作。 l 尽量避免内存分配。 明智的优化 这份文档是关于Android规范的细微优化所以先确保你已经了解哪些代码需要优化并且知道如何去衡量你所做修改所带来的效果好或坏。开发投入的时间是有限的所以明智的时间规划很重要。 (更多分析和笔记参见总结。) 这份文档同时确保你在算法和数据结构上作出最佳选择的同时考虑API选择所带来的潜在影响。使用合适的数据结构和算法比这里的任何建议都更有价值优先考虑API版本带来的影响有助于你找到更好的实现。这在类库代码中更为重要相比应用代码 (如果你需要这样的建议参见 Josh Blochs Effective Java, item 47.) 在优化Android程序时会遇到的一个棘手问题是保证你的程序能在不同的硬件平台上运行。虚拟机版本和处理器各部相同因此运行在之上的速度也大不一样。但这并且不是简单的A比B快或慢并能在设备间做出排列。特别的模拟器上只能评测出一小部分设备上体现的东西。有无JIT的设备间也存在着巨大差异在JIT设备上好的代码有时候会在无JIT的设备上表现的并不好。 如果你想知道一个程序在设备上的具体表现就必须在上面进行测试。 避免创建不必要的对象 对象创建永远不会是免费的。每个线程的分代GC给零时对象分配一个地址池以降低分配开销但往往内存分配比不分配需要的代价大。 如果在用户界面周期内分配对象就会强制一个周期性的垃圾回收给用户体验增加小小的停顿间隙。Gingerbread中提到的并发回收也许有用但不必要的工作应当被避免的。 因此应该避免不必要的对象创建。下面是几个例子 l 如果有一个返回String的方法并且他的返回值常常附加在一个StringBuffer上改变声明和实现让函数直接在其后面附加而非创建一个短暂存在的零时变量。 l 当从输入的数据集合中读取数据时考虑返回原始数据的子串而非新建一个拷贝.这样你虽然创建一个新的对象但是他们共享该数据的char数组。结果是即使仅仅使用原始输入的一部分你也需要保证它的整体一直存在于内存中。 一个更彻底的方案是将多维数组切割成平行一维数组 l Int类型的数组常有余Integer类型的。推而广之两个平行的int数组要比一个int,int型的对象数组高效。这对于其他任何基本数据类型的组合都通用。 l 如果需要实现一个容器来存放元组Foo,Bar两个平行数组Foo[],Bar[]会优于一个Foo,Bar对象的数组。例外情况是当你设计API给其他代码调用时应用好的API设计来换取小的速度提升。但在自己的内部代码中尽量尝试高效的实现。 通常来讲尽量避免创建短时零时对象.少的对象创建意味着低频的垃圾回收。而这对于用户体验产生直接的影响。 性能之谜 前一个版本的文档给出了好多误导人的主张这里做一些澄清 在没有JIT的设备上调用方法所传递的对象采用具体的类型而非接口类型会更高效比如传递HashMapmap比Map map调用一个方法的开销小尽管两个map都是HashMap.但这并不是两倍慢的情形事实上他们只相差6%而有JIT时这两种调用的效率不相上下。 在没有JIT的设备上缓存后的字段访问比直接访问快大概20%。而在有JIT的情况下字段访问的代价等同于局部访问因此这里不值得优化除非你觉得他会让你的代码更易读对于final ,static及static final 变量同样适用 用静态代替虚拟 如果不需要访问某对象的字段将方法设置为静态调用会加速15%到20%。这也是一种好的做法因为你可以从方法声明中看出调用该方法不需要更新此对象的状态。 避免内部的Getters/Setters 在源生语言像C中通常做法是用GettersigetCount()代替直接字段访问imCount。这是C中一个好的习惯因为编译器会内联这些访问并且如果需要约束或者调试这些域的访问你可以在任何时间添加代码。 而在Android中这不是一个好的做法。虚方法调用的代价比直接字段访问高昂许多。通常根据面向对象语言的实践在公共接口中使用Getters和Setters是有道理的但在一个字段经常被访问的类中宜采用直接访问。 无JIT时直接字段访问大约比调用getter访问快3倍。有JIT时直接访问字段开销等同于局部变量访问要快7倍。在Froyo版本中确实如此但以后版本可能会在JIT中改进Getter方法的内联。 对常量使用Static Final修饰符 考虑下面类首的声明 编译器会生成一个类初始化方法clinit,当该类初次被使用时执行这个方法将42存入intVal中并得到类文件字符串常量strVal的一个引用。当这些值在后面被引用时他们通过字段查找进行访问。 我们改进实现采用 final关键字 类不再需要clinit方法因为常量通过静态字段初始化器进入dex文件中。引用intVal的代码将直接调用整形值42而访问strVal也会采用相对开销较小的“字符串常量”原文“sring constant”指令替代字段查找。这种优化仅仅是针对基本数据类型和String类型常量的而非任意的引用类型。但尽可能的将常量声明为static final是一种好的做法。 使用改进的For循环语法 改进for循环有时被称为“for-each”循环能够用于实现了iterable接口的集合类及数组中。在集合类中迭代器让接口调用hasNext()和next()方法。在ArrayList中手写的计数循环迭代要快3倍无论有没有JIT但其他集合类中改进的for循环语法和迭代器具有相同的效率。 这里有一些迭代数组的实现 zero()是当中最慢的因为对于这个遍历中的历次迭代JIT并不能优化获取数组长度的开销。 One()稍快将所有东西都放进局部变量中避免了查找。但仅只有声明数组长度对性能改善有益。 Two()是在无JIT的设备上运行最快的对于有JIT的设备则和one()不分上下。他采用了JDK1.5中的改进for循环语法。 结论优先采用改进for循环但在性能要求苛刻的ArrayList迭代中考虑采用手写计数循环。 (参见 Effective Java item 46.) 在私有内部内中考虑用包访问权限替代私有访问权限 考虑下面的定义 需要注意的关键是我们定义的一个私有内部类Foo$Inner直接访问外部类中的一个私有方法和私有变量。这是合法的代码也会打印出预期的“Value is 27”。 但问题是虚拟机认为从Foo$Inner中直接访问Foo的私有成员是非法的因为他们是两个不同的类尽管Java语言允许内部类访问外部类的私有成员但是通过编译器生成几个综合方法来桥接这些间隙的。 内部类会在外部类中任何需要访问mValue字段或调用doStuff方法的地方调用这些静态方法。这意味着这些代码将直接存取成员变量表现为通过存取器方法访问。之前提到过存取器访问如何比直接访问慢这例子说明某些语言约会定导致不可见的性能问题。 如果你在高性能的Hotspot中使用这些代码可以通过声明被内部类访问的字段和成员为包访问权限而非私有。但这也意味着这些字段会被其他处于同一个包中的类访问因此在公共API中不宜采用。 合理利用浮点数 通常的经验是在Android设备中浮点数会比整型慢两倍在缺少FPU和JIT的G1上对比有FPU和JIT的Nexus One中确实如此两种设备间算术运算的绝对速度差大约是10倍 从速度方面说在现代硬件上float和double之间没有任何不同。更广泛的讲double大2倍。在台式机上由于不存在空间问题double的优先级高于float。 但即使是整型有的芯片拥有硬件乘法却缺少除法。这种情况下整型除法和求模运算是通过软件实现的就像当你设计Hash表或是做大量的算术那样。 了解并使用类库 选择Library中的代码而非自己重写除了通常的那些原因外考虑到系统空闲时会用汇编代码调用来替代library方法这可能比JIT中生成的等价的最好的Java代码还要好。典型的例子就是String.indexOfDalvik用内部内联来替代。同样的System.arraycopy方法在有JIT的Nexus One上自行编码的循环快9倍。 (参见 Effective Java item 47.) 合理利用本地方法 本地方法并不是一定比Java高效。最起码Java和native之间过渡的关联是有消耗的而JIT并不能对此进行优化。当你分配本地资源时本地堆上的内存文件说明符等往往很难实时的回收这些资源。同时你也需要在各种结构中编译你的代码而非依赖JIT。甚至可能需要针对相同的架构来编译出不同的版本针对ARM处理器的GI编译的本地代码并不能充分利用Nexus One上的ARM而针对Nexus One上ARM编译的本地代码不能在G1的ARM上运行。 当你想部署程序到存在本地代码库的Android平台上时本地代码才显得尤为有用而并非为了Java应用程序的提速。 (参见 Effective Java item 54.) 结语 最后通常考虑的是先确定存在问题再进行优化。并且你知道当前系统的性能否则无法衡量你进行尝试所得到的提升。 这份文档中的每个主张都有标准基准测试作为支持。你可以在code.google.com“dalvik”项目中找到基准测试的代码。 这个标准基准测试是建立在Caliper Java标准微基准测试框架之上的。标准微基准测试很难找到正确的路所以Caliper帮你完成了其中的困难部分工作。并且当你会察觉到某些情况的测试结果并想象中的那样虚拟机总是在优化你的代码的。我们强烈推荐你用Caliper来运行你自己的标准微基准测试。 同时你也会发现Traceview对分析很有用但必须了解他目前是不不支持JIT的这可能导致那些在JIT上可以胜出的代码运行超时。特别重要的根据Taceview的数据作出更改后请确保代码在没有Traceview时确实跑的快了。 转载于:https://www.cnblogs.com/aikongmeng/p/3697314.html
