wordpress增加主题配置,百度seo排名优化系统,全国城建中心官网入口,北京小程序网站制作地址 笔记45 | 代码性能优化建议[转] 目录 前言避免创建不必要的对象选择Static而不是Virtual常量声明为Static Final避免内部的Getters/Setters使用增强的For循环使用包级访问而不是内部类的私有访问避免使用float类型使用库函数谨慎使用native函数关于性能的误区前言 通常来说… 地址 笔记45 | 代码性能优化建议[转] 目录 前言避免创建不必要的对象选择Static而不是Virtual常量声明为Static Final避免内部的Getters/Setters使用增强的For循环使用包级访问而不是内部类的私有访问避免使用float类型使用库函数谨慎使用native函数关于性能的误区前言 通常来说高效的代码需要满足下面两个原则 a. 不要做冗余的工作 b. 尽量避免执行过多的内存分配操作 在优化App时其中一个难点就是让App能在各种型号的设备上运行。不同版本的虚拟机在不同的处理器上会有不同的运行速度。你甚至不能简单的认为“设备X的速度是设备Y的F倍”然后还用这种倍数关系去推测其他设备。另外在模拟器上的运行速度和在实际设备上的速度没有半点关系。同样设备有没有JIT也对运行速度有重大影响在有JIT情况下的最优化代码不一定在没有JIT的情况下也是最优的。 避免创建不必要的对象 创建对象从来不是免费的。Generational GC可以使临时对象的分配变得廉价一些但是执行分配内存总是比不执行分配操作更昂贵。 随着你在App中分配更多的对象你可能需要强制gc而gc操作会给用户体验带来一点点卡顿。虽然从Android 2.3开始引入了并发gc它可以帮助你显著提升gc的效率减轻卡顿但毕竟不必要的内存分配操作还是应该尽量避免。 因此请尽量避免创建不必要的对象有下面一些例子来说明这个问题 如果你需要返回一个String对象并且你知道它最终会需要连接到一个StringBuffer请修改你的函数实现方式避免直接进行连接操作应该采用创建一个临时对象来做字符串的拼接这个操作。 当从已经存在的数据集中抽取出String的时候尝试返回原数据的substring对象而不是创建一个重复的对象。使用substring的方式你将会得到一个新的String对象但是这个string对象是和原string共享内部char[]空间的。 一个稍微激进点的做法是把所有多维的数据分解成一维的数组: 一组int数据要比一组Integer对象要好很多。可以得知两组一维数组要比一个二维数组更加的有效率。同样的这个道理可以推广至其他原始数据类型。 如果你需要实现一个数组用来存放(Foo,Bar)的对象记住使用Foo[]与Bar[]要比(Foo,Bar)好很多。(例外的是为了某些好的API的设计可以适当做一些妥协。但是在自己的代码内部你应该多多使用分解后的容易。 通常来说需要避免创建更多的临时对象。更少的对象意味者更少的gc动作gc会对用户体验有比较直接的影响。 选择Static而不是Virtual 如果你不需要访问一个对象的值请保证这个方法是static类型的这样方法调用将快15%-20%。这是一个好的习惯因为你可以从方法声明中得知调用无法改变这个对象的状态。 常量声明为Static Final 考虑下面这种声明的方式 static int intVal 42; static String strVal “Hello, world!”; 编译器会使用一个初始化类的函数然后当类第一次被使用的时候执行。这个函数将42存入intVal还从class文件的常量表中提取了strVal的引用。当之后使用intVal或strVal的时候他们会直接被查询到。 我们可以用final关键字来优化 static final int intVal 42; static final String strVal “Hello, world!”; 这时再也不需要上面的方法了因为final声明的常量进入了静态dex文件的域初始化部分。调用intVal的代码会直接使用42调用strVal的代码也会使用一个相对廉价的“字符串常量”指令而不是查表。 Notes这个优化方法只对原始类型和String类型有效而不是任意引用类型。不过在必要时使用static final是个很好的习惯。 避免内部的Getters/Setters 像C等native language通常使用getters(i getCount())而不是直接访问变量(i mCount)。这是编写C的一种优秀习惯而且通常也被其他面向对象的语言所采用例如C#与Java因为编译器通常会做inline访问而且你需要限制或者调试变量你可以在任何时候在getter/setter里面添加代码。 然而在Android上这不是一个好的写法。虚函数的调用比起直接访问变量要耗费更多。在面向对象编程中将getter和setting暴露给公用接口是合理的但在类内部应该仅仅使用域直接访问。 在没有JIT(Just In Time Compiler)时直接访问变量的速度是调用getter的3倍。有JIT时直接访问变量的速度是通过getter访问的7倍。 请注意如果你使用ProGuard你可以获得同样的效果因为ProGuard可以为你inline accessors. 使用增强的For循环 增强的For循环也被称为 for-each 循环可以被用在实现了 Iterable 接口的 collections 以及数组上。使用collection的时候Iterator会被分配用于for-each调用hasNext()和next()方法。使用ArrayList时手写的计数式for循环会快3倍不管有没有JIT但是对于其他collection增强的for-each循环写法会和迭代器写法的效率一样。 请比较下面三种循环的方法 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() 在没有做JIT时是最快的可是如果经过JIT之后与方法one()是差不多一样快的。它使用了增强的循环方法for-each。 所以请尽量使用for-each的方法但是对于ArrayList请使用方法one()。 使用包级访问而不是内部类的私有访问 参考下面一段代码 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它直接访问了外部类中的私有方法以及私有成员对象。这是合法的这段代码也会如同预期一样打印出”Value is 27”。 问题是VM因为Foo和FooInner是不同的类会认为在FooInner中直接访问Foo类的私有成员是不合法的。即使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()函数时它都会调用这些静态方法。这意味着上面的代码可以归结为通过accessor函数来访问成员变量。早些时候我们说过通过accessor会比直接访问域要慢。所以这是一个特定语言用法造成性能降低的例子。 如果你正在性能热区hotspot:高频率、重复执行的代码段使用像这样的代码你可以把内部类需要访问的域和方法声明为包级访问而不是私有访问权限。不幸的是这意味着在相同包中的其他类也可以直接访问这些域所以在公开的API中你不能这样做。 避免使用float类型 Android系统中float类型的数据存取速度是int类型的一半尽量优先采用int类型。 就速度而言现代硬件上float 和 double 的速度是一样的。空间而言double 是两倍float的大小。在空间不是问题的情况下你应该使用 double 。 同样对于整型有些处理器实现了硬件几倍的乘法但是没有除法。这时整型的除法和取余是在软件内部实现的这在你使用哈希表或大量计算操作时要考虑到。 使用库函数 除了那些常见的让你多使用自带库函数的理由以外记得系统函数有时可以替代第三方库并且还有汇编级别的优化他们通常比带有JIT的Java编译出来的代码更高效。典型的例子是Android API 中的 String.indexOf()Dalvik出于内联性能考虑将其替换。同样 System.arraycopy()函数也被替换这样的性能在Nexus One测试比手写的for循环并使用JIT还快9倍。 谨慎使用native函数 结合Android NDK使用native代码开发并不总是比Java直接开发的效率更好的。Java转native代码是有代价的而且JIT不能在这种情况下做优化。如果你在native代码中分配资源比如native堆上的内存文件描述符等等这会对收集这些资源造成巨大的困难。你同时也需要为各种架构重新编译代码而不是依赖JIT。你甚至对已同样架构的设备都需要编译多个版本为G1的ARM架构编译的版本不能完全使用Nexus One上ARM架构的优势反之亦然。 Native 代码是在你已经有本地代码想把它移植到Android平台时有优势而不是为了优化已有的Android Java代码使用。 如果你要使用JNI,请学习JNI Tips 关于性能的误区 在没有JIT的设备上使用一种确切的数据类型确实要比抽象的数据类型速度要更有效率例如调用HashMap map要比调用Map map效率更高。有误传效率要高一倍实际上只是6%左右。而且在JIT之后他们直接并没有大多差异。 在没有JIT的设备上读取缓存域比直接读取实际数据大概快20%。有JIT时域读取和本地读取基本无差。所以优化并不值得除非你觉得能让你的代码更易读这对 final, static, static final 域同样适用。 我的Android征途 转载于:https://www.cnblogs.com/xiangevan/p/10751672.html
