学校网站建站,seo推广主要做什么,科技 公司 响应式 网站,做aa视频网站原文地址#xff1a;http://android.xsoftlab.net/training/articles/perf-tips.html
本篇文章主要介绍那些可以提升整体性能的微小优化点。它与那些能突然改观性能效果的优化手段并不属于同一类。选择正确的算法与数据结构必然是我们的第一总则#xff0c;但是这不是我们这…原文地址http://android.xsoftlab.net/training/articles/perf-tips.html
本篇文章主要介绍那些可以提升整体性能的微小优化点。它与那些能突然改观性能效果的优化手段并不属于同一类。选择正确的算法与数据结构必然是我们的第一总则但是这不是我们这篇文章要介绍的。你应该将这篇文章所提及的知识点作为编码的日常习惯这可以提升常规代码的执行效率。
下面是书写代码的基本准则
绝不要做你不需要的工作。如果可以不申请内存就不要申请要合理复用已有的对象。
另一个较复杂的问题就是被优化过的APP肯定是要运行在各种类型的硬件平台上。不同版本的虚拟机运行在不同的处理器上肯定会有不同的运行速度。需要特别说明的是在模拟器上测试很少会得知其它设备的性能。在不同设备上还有一个很大的不同点就是有没有JIT(JIT的意思是即时编译器):在JIT设备上运行的最优代码并不总在没有JIT设备上有效。
为了确保APP可以在各类设备上运行良好要确保代码在各个版本的平台上都是高效的。
避免创建不必要的对象
创建对象绝不是没有成本的。虽然分代垃圾收集器可以使临时对象的分配成本变得很低但是内存分配的成本总是远高于非内存分配的成本。
随着更多对象的生成你可能就开始关注垃圾收集器了。虽然Android 2.3中出现的并发收集器可能会帮到你但是不必要的工作总是应该避免的。
因此要避免创建不需要的对象。下面的示例可能会帮到你
如果你有个返回字符串的方法该方法所返回的字符串总是被接在一个StringBuffer对象后面。那么就可以更改此方法的实现方式让该字符串直接跟在StringBuffer的后面返回。这样就可以避免创建那些临时性的变量。当从字符串中提取子串时应该尝试返回原始数据的子串而不是创建一个副本。子串将会创建一个新的String对象但是它与char[]共用的是同一数据。采用这种方式的唯一不足就是虽然使用了其中的一部分数据但是剩余的数据还都保留在内存中。
一条更为先进的法则就是将多维数组转换为平行数组使用
int数组的效率要比Integer数组的效率高的多。如果你需要实现一个用于存储(Foo,Bar)对象的数组要记得使用两个平行的Foo[]Bar[]数组这要比单一的(Foo,Bar)数组效率好太多。
通常来说要尽量避免创建那些生命周期很短的临时变量。更少的对象创建意味着更低频率的垃圾回收这会直接反应到用户体验上。
首选静态
如果不需要访问对象的属性那么就可以将方法设置为静态方法。这样调用将会增加15%-20%的速度。这还是一个好的习惯因为这样可以告诉其它方法一个信号它们更改不了对象的状态。
使用常量
请先考虑以下声明
static int intVal 42;
static String strVal Hello, world!;
编译器会产生出一个类的实例化方法名为 clinit它会在类首次被用到的时候执行。该方法会将值42存到intVal中并将字符串常量表中的引用赋给strVal。当这些值被引用之后其它属性才可以访问它们。
我们可以使用”final”关键字来改进一下
static final int intVal 42;
static final String strVal Hello, world!;
这样的话类就不需要再调用 clinit方法因为常量的初始化工作被移入了dex文件中。代码可以直接引用intVal为42的值并且访问strVal也会直接得到字符串”string constant” 这样可以省去了查找字符串的过程。 Note: 这样优化手段仅仅适用于基本数据类型以及字符串常量不要作用其它类型。 避免内部的get\set方法
像C这种本地语言通常都会使用get方法来访问属性。这对C来说是一个非常好的习惯并且C#、Java等面向对象语言也广泛使用这种方式因为编译器通常会进行内联访问并且如果你需要限制访问或者调试属性的话只需要添加代码就可以。
不过这在Android上并不是个好习惯。方法调用的开销是非常大的。虽然为了遵循面向对象语言提供get、set方法是合理的但是在Android中最好是可以直接访问对象的字段。
在没有JIT的设备中直接访问对象字段的速度要比通过get方法访问的速度快3倍。在含有JIT的设备中这个效率会达到7倍之多。
注意如果你使用了ProGuard那么就有了一个两全其美的结果因为ProGuard会直接为你进行内联访问。
使用增强for循环
增强for循环可用于实现了Iterable接口的集合或数组。在集合内部迭代器需要实现接口方法hasNext()以及next()。
有以下几种访问数组的方式
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不能够对每次访问数组长度的开销进行优化。
one()方法是稍快点的。它将一切元素放入了本地变量这样避免了每一次的查询。只有数组的长度提供了明显的性能提升。
two()方法是最快的。它使用了增强for循环。
所以应当在默认情况下使用增强for循环。 Tip: 也可以查看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);}
}
上面的代码定义了一个内部类它可以直接访问外部类的私有成员以及私有方法。这是正确的这段代码将会打印出我们所期望的”Value is 27”。
这里的问题是VM会认为Foo$Inner直接访问Foo对象的私有成员是非法的因为Foo和Foo$Inner是两个不同的类虽然Java语言允许内部类可以直接访问外部类的私有成员(PS:虚拟机与语言是两种互不干扰的存在)。为了弥补这种差异编译器专门为此生成了一组方法
/*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()方法时会调用上面这些静态方法。上面的代码归结为你所访问的成员属性都是通过访问器方法访问的。早期我们说通过访问器访问要比直接访问慢很多所以这是一段特定语言形成的隐性性能开销示例。
避免使用浮点型
一般来说在Android设备上浮点型要比整型慢大概2倍的速度。
在速度方面float与double并没有什么区别。在空间方面double是float的两倍大。所以在桌面级设备上假设空间不是问题那么我们应当首选double而不是float。
还有在对待整型方面某些处理器擅长乘法不擅长除法。在这种情况下整型的除法与取模运算都是在软件中进行的如果你正在设计一个哈希表或者做其它大量的数学运算的话这些东西应该考虑到。
使用本地方法要当心
使用本地代码开发的APP并不一定比Java语言编写的APP高效多少。首先它会花费在Java-本地代码的转换过程中并且JIT也不能优化到这些边界。如果你正在申请本地资源那么对于这些资源的收集能明显的感觉到困难。除此之外你还需要对每一种CPU架构进行单独编译。你可能甚至还需要为同一个CPU架构编译多个不同的版本为G1的ARM处理器编译的代码不能运行在Nexus One的ARM处理上为Nexus One的ARM处理器编译的代码也同样不能运行在G1的ARM处理器上。
本地代码在这种情况下适宜采用当你有一个已经存在的本地代码库你希望将它移植到Android上时不要为了改善Java语言所编写的代码速度而去使用本地代码。
如果你需要使用本地代码那么应该读一读JNI Tips. Tip: 相关信息也可以查看Josh Bloch 的 Effective Java第54条。 性能误区
在没有JIT的设备中通过具体类型的变量调用方法要比抽象接口的调用要高效这是事实。举个例子通过HashMap map调用方法要比Map map调用方法要高效的多开销也少虽然这两个实现都是HashMap。事实上速度并不会慢2倍这么多真实的不同大概有6%的减缓。进一步讲JIT会使两者的差别进一步缩小。
在没有JIT的设备上通过缓存访问属性要比反复访问属性要快将近20%的速度。在JIT的设备中属性访问的花销与本地访问的花销基本一致所以这不是一项有多少价值的优化手段除非你觉得这样做的话代码更易读(这对static,final,常量同样适用)。
经常估测
在开始优化之前要确保你有个问题需要解决要确保你可以精准测量现有的性能否则将不能观察到优化所带来的提升。
基准点由Caliper的微型基准点框架创建。基准点很难正确获得所以Caliper将这份很难处理的工作做了甚至是在你没有在测量那些你想测量的地方的时候它也在工作。我们强烈的推荐你使用Caliper来创建自己的微型基准点。
你可能还发现Traceview非常有助于提升性能不过你应该意识到Traceview工作的时候JIT并没有开启。这会错误的认为JIT会将损失掉的时间弥补回来。这尤其重要根据Traceview所更改的结果会使实际代码运行的更快。
有关更多提升APP性能的工具及方法请参见以下文档
Profiling with Traceview and dmtracedumpAnalyzing UI Performance with Systrace
