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