Android应用开发者指南：性能优化(2)
性能之谜
前一个版本的文档给出了好多误导人的主张，这里做一些澄清：
在没有JIT的设备上，调用方法所传递的对象采用具体的类型而非接口类型会更高效(比如，传递HashMap map比Map map调用一个方法的开销小，尽管两个map都是HashMap).但这并不是两倍慢的情形，事实上，他们只相差6%，而有JIT时这两种调用的效率不相上下。
在没有JIT的设备上，缓存后的字段访问比直接访问快大概20%。而在有JIT的情况下，字段访问的代价等同于局部访问，因此这里不值得优化，除非你觉得他会让你的代码更易读(对于final ,static，及static final 变量同样适用)
用静态代替虚拟
如果不需要访问某对象的字段，将方法设置为静态，调用会加速15%到20%。这也是一种好的做法，因为你可以从方法声明中看出调用该方法不需要更新此对象的状态。
避免内部的Getters/Setters
在源生语言像C++中，通常做法是用Getters(i=getCount())代替直接字段访问(i=mCount)。这是C++中一个好的习惯，因为编译器会内联这些访问，并且如果需要约束或者调试这些域的访问，你可以在任何时间添加代码。
而在Android中，这不是一个好的做法。虚方法调用的代价比直接字段访问高昂许多。通常根据面向对象语言的实践，在公共接口中使用Getters和Setters是有道理的，但在一个字段经常被访问的类中宜采用直接访问。
无JIT时，直接字段访问大约比调用getter访问快3倍。有JIT时(直接访问字段开销等同于局部变量访问)，要快7倍。在Froyo版本中确实如此，但以后版本可能会在JIT中改进Getter方法的内联。
对常量使用Static Final修饰符
考虑下面类首的声明：
编译器会生成一个类初始化方法
我们改进实现，采用 final关键字：
类不再需要
使用改进的For循环语法
改进for循环(有时被称为“for-each”循环)能够用于实现了iterable接口的集合类及数组中。在集合类中，迭代器让接口调用hasNext()和next()方法。在ArrayList中，手写的计数循环迭代要快3倍(无论有没有JIT)，但其他集合类中，改进的for循环语法和迭代器具有相同的效率。
这里有一些迭代数组的实现：
zero()是当中最慢的，因为对于这个遍历中的历次迭代，JIT并不能优化获取数组长度的开销。
One()稍快，将所有东西都放进局部变量中，避免了查找。但仅只有声明数组长度对性能改善有益。
Two()是在无JIT的设备上运行最快的，对于有JIT的设备则和one()不分上下。他采用了JDK1.5中的改进for循环语法。
结论：优先采用改进for循环，但在性能要求苛刻的ArrayList迭代中，考虑采用手写计数循环。
在私有内部内中，考虑用包访问权限替代私有访问权限
考虑下面的定义：
需要注意的关键是：我们定义的一个私有内部类(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表，或是做大量的算术那样。