性能之谜

前一个版本的文档给出了好多误导人的主张，这里做一些澄清：

在没有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修饰符

考虑下面类首的声明：

编译器会生成一个类初始化方法<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.)

性能之谜

前一个版本的文档给出了好多误导人的主张，这里做一些澄清：

在没有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修饰符

考虑下面类首的声明：

编译器会生成一个类初始化方法<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.)