本文翻译自Android Developer Training:https://developer.android.google.cn/training/articles/perf-tips.html
本文是 Zhengjt 原创,发表于http://zhengjt.com,请阅读原文支持原创:link
说到代码性能优化,选择合适的算法和数据结构应该永远是我们首先要考虑的,我们在此并不讨论这个。本文讨论的是可以提升app整体性能的代码优化方法,它们可能并不总能那么显著地提升整个app的性能,但是你可以将这些技巧融入你的编程习惯中,从而使你写出更高效的代码。
对于写出更高效的代码,有两个基本原则:
- 避免做你不需要做的事情
- 避免分配多余的内存
你必须对Android代码的每一个细节做优化的一个原因是:你的代码将运行在多种多样的硬件设备上。不同的处理器,不同虚拟机,不同的运行速度。你甚至不能简单地说一个设备肯定比另一个设备快。对于不同的设备来说,是否有JIT会造成很大的不同,对有JIT设备优化得最好的代码并不一定适合于没有JIT的设备。
为了确保你的app能够在跨平台多设备上都表现得都很好,需要保证在所有层级上优化你的代码。
避免创建不必要的对象
对象的创建从来都不是免费的,它需要消耗系统的资源。
当应用程序内存中的对象达到一定数量时,系统将强制开始进行GC,这时设备会发生短暂卡顿,从而影响用户体验。 在Android 2.3中引入了并行垃圾收集器有助于缓解这个问题,但我们应该总是要避免不必要的内存分配。
因此,应避免创建不需要的对象实例。 以下是一些样例建议:
-
如果你的方法返回一个String,而这个返回的String总是要拼接成一个StringBuffer,那么,你应该改变的方法签名和返回,在方法中直接拼接StringBuffer,而不是创建一个生命周期很短的临时String变量。
-
当你需要从输入数据中提取字符串的时候,使用substring而不是创建一个输入数据的拷贝,这样你将创建一个String对象,但是这个String对象将和输入数据共享常量char字符数组。(这样做的代价是如果你只需要提取输入数据的一小部分,最终你也必须在内存中保留整个输入数据)
有个更激进的想法是:用一维的数组替换多维数组
-
int数组比Integer要高效得多,两个元素一一对应的int数组依然比一个
Object<int,int>
数组高效得多。对于其他基本类型来说也是这样的。 -
如果你需要一个元祖
tuples(Foo,Bar)
对象,记住使用两个平行的元素一一对应的Foo[]
和Bar[]
将总是比创建一个Object<Foo, Bar>
数组来的高效得多。(有一个例外是,当你设计API提供给其他代码调用的时候,为了实现良好的规范,你应该对这个优化做妥协)
一般来说,要尽量避免创建短期的临时变量,这样能够减少影响用户体验的垃圾收集器的GC的频率。
使用Static替代Virtual
如果你的方法不需要访问对象的成员字段,那将其设置为static,这样的话方法的调用速度会提升15%~20%。同时这也是良好的代码实践,因为你能够通过static修饰符知道这个方法不会改变对象的状态。
使用Static Final修饰常量
考虑如下在一个类的顶部的两个声明:
static int intVal = 42;
static String strVal = "Hello, world!";
编译器生成了一个初始化方法叫<clinit>
,当变量第一次被引用的时候会调用这个方法。这个方法存储了intVal和42、strVal和"Hello, world!"的对应关系。当这两个变量被引用的时候,系统通过成员字段域查找来得到这两个变量的值。
我们可以使用关键字final来改变这种状况:
static final int intVal = 42;
static final String strVal = "Hello, world!";
这样这个类就不需要<clinit>
方法了,因为常量直接被编译到dex文件中,被引用的intVal将直接被替换成42,strVal也被直接替换成字符串常量,而不需要查找成员字段域。
避免内部的Getters/Setters访问器
在类似C++的语言中,使用Getters/Setters而不是成员字段是通用的代码实践。这个对C++来说很好的实践也经常被应用于其他面向对象语言比如C#和Java,因为编译器总是能够内联优化代码,而如果你需要限制或者调试成员字段,你可以在任何时候更改Getters/Setters内的代码来实现。
然而,对Android来说,这并不是一个好主意。方法的调用比成员字段域查找要昂贵得多。公开的接口是有必要按照面向对象的法则声明getters和setters的,但是在类内部,你应该总是直接使用成员字段本身。
没有JIT的时候,直接的成语变量访问会比使用一个不必要的getter方法快3倍,如果有JIT,那么会快7倍(有JIT的时候访问成员字段和访问局部变量几乎是同等的低消耗)。
使用增强的循环语法(for-each)
增强的循环语法(有时候也常常叫做for-each循环)可以被任何实现了Iterable接口的对象集合使用。当循环ArrayList的时候,一个手写的计数循环会比for-each循环快3倍左右(无论是否有JIT),但是对其他集合collections来说,for-each循环几乎和使用iterator循环来得一样快。
对于数组循环来说,有以下几种选择:
static class Foo {
int mSplat;
}
Foo[] mArray = ...
public void zero() {
int sum = 0;
for (int i = 0; i < mArray.length; ++i) {
sum += mArray[i].mSplat;
}
}
public void one() {
int sum = 0;
Foo[] localArray = mArray;
int len = localArray.length;
for (int i = 0; i < len; ++i) {
sum += localArray[i].mSplat;
}
}
public void two() {
int sum = 0;
for (Foo a : mArray) {
sum += a.mSplat;
}
}
zero()是最慢的,因为JIT不能优化通过循环的每次迭代获得数组长度一次的成本,即每一次循环都需要计算一遍mArray.length。
one()更快一些。它将所有内容都放到局部变量中,避免重复计算。但是只有len的计算优化了性能。
对于没有JIT的设备,two()是最快的,并且与具有JIT的设备无法区分。 它使用了Java1.5版本中引入的增强型for循环语法。
因此,对于ArrayList循环,如果你对性能非常敏感的话,可以考虑一个手写的计数循环。除此之外,您应该默认使用增强型for循环。
提示:另请参见Josh Bloch的《 Effective Java》第46条。
考虑使用包替代私有内部类对外部类的私有域的访问
考虑以下声明:
public class Foo {
private class Inner {
void stuff() {
Foo.this.doStuff(Foo.this.mValue);
}
}
private int mValue;
public void run() {
Inner in = new Inner();
mValue = 27;
in.stuff();
}
private void doStuff(int value) {
System.out.println("Value is " + value);
}
}
这里我们定义一个私有内部类(Foo$Inner),它直接访问外部类中的私有方法和私有实例字段。 对于Java语言语法来说,这是合法的,代码打印“Value is 27”符合预期。
但是问题是虚拟机认为从Foo$Inner直接访问Foo的私有成员是非法的,因为Foo和Foo$Inner是两个不同的类,即使Java语言允许内部类访问外部类的私有成员。 为弥合这个差距,编译器生成了几个合成方法:
/*package*/ static int Foo.access$100(Foo foo) {
return foo.mValue;
}
/*package*/ static void Foo.access$200(Foo foo, int value) {
foo.doStuff(value);
}
内部类代码在需要访问mValue字段或调用外部类中的doStuff()方法时调用这些静态方法。 这意味着,上面的代码会归结为通过访问器方法访问成员字段的情况。 前面我们讨论了访问器如何比直接字段访问慢,所以这是一个因为特定语言语法导致“隐形”性能问题的例子。
如果你在对性能要求严格的场景中使用这样的代码,你可以通过改变内部类访问的字段和访问的访问的权限为包访问,而不是私有访问,从而避免上述开销。 但是这意味着字段可以被同一个包中的其他类直接访问,所以你不应该在公共API中使用它——因此最佳的方法是使用包替代私有内部类对外部类的私有域的访问。
避免使用Float
根据经验,浮点数在Android设备上比整数慢两倍。
在速度方面,在更现代的硬件上float和double几乎没有区别。 在存储空间方面,double是Float的2倍大。 和PC一样,假设存储空间不是问题,你应该偏向使用double。
此外,即使对于整数,一些处理器具有硬件乘法,但是缺少硬件除法。 在这种情况下,整数除法和模数运算会在软件中执行,想想你在设计一个哈希表或做大量的数学计算(这将消耗大量的系统资源)——因此我们也应该尽量避免除法运算或者将它转换成乘法运算。
熟悉和使用库
使用系统库代码,除了有那些我们熟知的好处之外,记住,系统可以使用底层汇编方法优化代码。 这里典型的例子是String.indexOf()和相关的API,Dalvi使用了一个内联的内在替换(提高了性能)。 类似地,System.arraycopy()方法比使用JIT的Nexus One上的手写的编码循环快大约9倍。
提示:另见Josh Bloch的《Effective Java》,第47条。
谨慎使用Native方法
使用Android NDK开发具有Native代码的应用程序不一定比使用Java语言编程更有效。首先,存在与Java代码转换的相关成本,并且JIT不能跨越这些边界进行优化。如果您分配了本机资源(本机堆上的内存,文件描述符或任何内容),那么安排这些资源的及时回收会更加困难。你还需要编译你想要运行的每个架构的代码(而不是依赖一个JIT)。你甚至可能需要为你认为相同的架构编译多个版本:为G1中的ARM处理器编译的Native代码不能充分利用Nexus One中的ARM,而为Nexus One中的ARM编译的代码将不能在G1上的ARM上运行。
Native代码主要用于当你有一个现有的Native代码库,你想要移植到Android,而不是用于“加速”使用Java语言编写的Android应用程序的部分。
如果你确实需要使用Native代码,你应该阅读我们的JNI提示。
提示:另见Josh Bloch的《Effective Java》第54条。
性能神话
在没有JIT的设备上,通过具有确切类型的变量而不是接口调用方法稍微更高效些。(例如,使用HashMap声明map会比使用Map声明map来的更高效,即使在这两种情况下映射的都是HashMap对象)这里的区别并不会夸张到一种比另一种慢两倍这么大,实际差异更像是慢6%这么多。 此外,有JIT的话,这两者的效率几乎相同。
在没有JIT的设备上,缓存成员字段访问比重复访问成员字段快约20%。 使用JIT,成员字段访问成本大约与本地字段访问成本相同,因此这不是一个值得优化的地方,除非你觉得它使你的代码更容易阅读。 (对于 final, static和static final修饰的成员字段也是如此)。
比较优化效果
在开始优化之前,请确保您有一个需要解决的问题。 确保您可以准确地衡量您现有的绩效,否则您将无法衡量您尝试的替代方案的优势。
您也可能发现Traceview对于分析有用,但是重要的是要意识到它当前禁用了JIT,这可能导致它错误地将时间归因于使用JIT可能提升性能的代码。 在进行Traceview数据建议的更改后,确保生成的代码在没有Traceview的情况下运行更快时尤其重要。
网友评论