Trinea性能优化之Java(Android)代码优化

本文为Android性能优化的第三篇——Java(Android)代码优化。主要介绍Java代码中性能优化方式及网络优化，包括缓存、异步、延迟、数据存储、算法、JNI、逻辑等优化方式。(时间仓促，后面还会继续完善^_*)

 

目前性能优化专题已完成以下部分：

性能优化总纲——性能问题及性能调优方式

性能优化第四篇——移动网络优化

性能优化第三篇——Java(Android)代码优化
性能优化第二篇——布局优化
性能优化第一篇——数据库性能优化

性能优化实例 
1、降低执行时间
这部分包括：缓存、数据存储优化、算法优化、JNI、逻辑优化、需求优化几种优化方式。
(1). 缓存
缓存主要包括对象缓存、IO缓存、网络缓存、DB缓存，对象缓存能减少内存的分配，IO缓存减少磁盘的读写次数，网络缓存减少网络传输，DB缓存较少Database的访问次数。
在内存、文件、数据库、网络的读写速度中，内存都是最优的，且速度数量级差别，所以尽量将需要频繁访问或访问一次消耗较大的数据存储在缓存中。

 

Android中常使用缓存:
a.  线程池
b.  Android图片缓存，Android图片Sdcard缓存，数据预取缓存
c. 消息缓存
通过handler.obtainMessage复用之前的message，如下：

1	handler . sendMessage ( handler . obtainMessage ( 0 , object ) ) ;

d. ListView缓存

e. 网络缓存
数据库缓存http response，根据http头信息中的Cache-Control域确定缓存过期时间。
f. 文件IO缓存
使用具有缓存策略的输入流，BufferedInputStream替代InputStream，BufferedReader替代Reader，BufferedReader替代BufferedInputStream.对文件、网络IO皆适用。
g. layout缓存
h. 其他需要频繁访问或访问一次消耗较大的数据缓存

 

(2). 数据存储优化
包括数据类型、数据结构的选择。
a. 数据类型选择
字符串拼接用StringBuilder代替String，在非并发情况下用StringBuilder代替StringBuffer。如果你对字符串的长度有大致了解，如100字符左右，可以直接new StringBuilder(128)指定初始大小，减少空间不够时的再次分配。
64位类型如long double的处理比32位如int慢
使用SoftReference、WeakReference相对正常的强应用来说更有利于系统垃圾回收
final类型存储在常量区中读取效率更高
LocalBroadcastManager代替普通BroadcastReceiver，效率和安全性都更高

 

b. 数据结构选择
常见的数据结构选择如：
ArrayList和LinkedList的选择，ArrayList根据index取值更快，LinkedList更占内存、随机插入删除更快速、扩容效率更高。一般推荐ArrayList。
ArrayList、HashMap、LinkedHashMap、HashSet的选择，hash系列数据结构查询速度更优，ArrayList存储有序元素，HashMap为键值对数据结构，LinkedHashMap可以记住加入次序的hashMap，HashSet不允许重复元素。
HashMap、WeakHashMap选择，WeakHashMap中元素可在适当时候被系统垃圾回收器自动回收，所以适合在内存紧张型中使用。
Collections.synchronizedMap和ConcurrentHashMap的选择，ConcurrentHashMap为细分锁，锁粒度更小，并发性能更优。Collections.synchronizedMap为对象锁，自己添加函数进行锁控制更方便。

 

Android也提供了一些性能更优的数据类型，如SparseArray、SparseBooleanArray、SparseIntArray、Pair。
Sparse系列的数据结构是为key为int情况的特殊处理，采用二分查找及简单的数组存储，加上不需要泛型转换的开销，相对Map来说性能更优。不过我不太明白为啥默认的容量大小是10，是做过数据统计吗，还是说现在的内存优化不需要考虑这些东西，写16会死吗，还是建议大家根据自己可能的容量设置初始值。

 

(3). 算法优化
这个主题比较大，需要具体问题具体分析，尽量不用O(n*n)时间复杂度以上的算法，必要时候可用空间换时间。
查询考虑hash和二分，尽量不用递归。可以从结构之法 算法之道或微软、Google等面试题学习。

 

(4). JNI
Android应用程序大都通过Java开发，需要Dalvik的JIT编译器将Java字节码转换成本地代码运行，而本地代码可以直接由设备管理器直接执行，节省了中间步骤，所以执行速度更快。不过需要注意从Java空间切换到本地空间需要开销，同时JIT编译器也能生成优化的本地代码，所以糟糕的本地代码不一定性能更优。
这个优化点会在后面单独用一片博客介绍。

 

(5). 逻辑优化
这个不同于算法，主要是理清程序逻辑，减少不必要的操作。

 

(6). 需求优化
这个就不说了，对于sb的需求可能带来的性能问题，只能说做为一个合格的程序员不能只是执行者，要学会说NO。不过不能拿这种接口敷衍产品经理哦。

 

2、异步，利用多线程提高TPS
充分利用多核Cpu优势，利用线程解决密集型计算、IO、网络等操作。
关于多线程可参考：Java线程池
在Android应用程序中由于系统ANR的限制，将可能造成主线程超时操作放入另外的工作线程中。在工作线程中可以通过handler和主线程交互。

 

3、提前或延迟操作，错开时间段提高TPS
(1) 延迟操作
不在Activity、Service、BroadcastReceiver的生命周期等对响应时间敏感函数中执行耗时操作，可适当delay。
Java中延迟操作可使用ScheduledExecutorService，不推荐使用Timer.schedule;
Android中除了支持ScheduledExecutorService之外，还有一些delay操作，如
handler.postDelayed，handler.postAtTime，handler.sendMessageDelayed，View.postDelayed，AlarmManager定时等。

 

(2) 提前操作
对于第一次调用较耗时操作，可统一放到初始化中，将耗时提前。如得到壁纸wallpaperManager.getDrawable();

 

避免创建不必要的对象

创建对象从来都不应该是一件随意的事情，因为创建一个对象就意味着垃圾回收器需要回收一个对象，而这两步操作都是需要消耗时间的。虽说创建一个对象的代价确实非常小，并且Android 2.3版本当中又增加了并发垃圾回收器机制 ，这让GC操作时的停顿时间也变得难以察觉，但是这些理由都不足以让我们可以肆意地创建对象，需要创建的对象我们自然要创建，但是不必要的对象我们就应该尽量避免创建。

下面来看一些我们可以避免创建对象的场景：

• 如果我们有一个需要拼接的字符串，那么可以优先考虑使用StringBuffer或者StringBuilder来进行拼接，而不是加号连接符，因为使用加号连接符会创建多余的对象，拼接的字符串越长，加号连接符的性能越低。
• 在没有特殊原因的情况下，尽量使用基本数据类来代替封装数据类型，int比Integer要更加高效，其它数据类型也是一样。
• 当一个方法的返回值是String的时候，通常可以去判断一下这个String的作用是什么，如果我们明确地知道调用方会将这个返回的String再进行拼接操作的话，可以考虑返回一个StringBuffer对象来代替，因为这样可以将一个对象的引用进行返回，而返回String的话就是创建了一个短生命周期的临时对象。
• 正如前面所说，基本数据类型要优于对象数据类型，类似地，基本数据类型的数组也要优于对象数据类型的数组。另外，两个平行的数组要比一个封装好的对象数组更加高效，举个例子，Foo[]和Bar[]这样的两个数组，使用起来要比Custom(Foo,Bar)[]这样的一个数组高效得多。

当然上面所说的只是一些代表性的例子，我们所要遵守的一个基本原则就是尽可能地少创建临时对象，越少的对象意味着越少的GC操作，同时也就意味着越好的程序性能和用户体验。

静态优于抽象

如果你并不需要访问一个对象中的某些字段，只是想调用它的某个方法来去完成一项通用的功能，那么可以将这个方法设置成静态方法，这会让调用的速度提升15%-20%，同时也不用为了调用这个方法而去专门创建对象了，这样还满足了上面的一条原则。另外这也是一种好的编程习惯，因为我们可以放心地调用静态方法，而不用担心调用这个方法后是否会改变对象的状态（静态方法内无法访问非静态字段）。

对常量使用static final修饰符

我们先来看一下在一个类的最顶部定义如下代码：

[java]  view plain copy

1. static int intVal = 42;  
2. static String strVal = "Hello, world!";  

编译器会为上述代码生成一个初始化方法，称为<clinit>方法，该方法会在定义类第一次被使用的时候调用。然后这个方法会将42的值赋值到intVal当中，并从字符串常量表中提取一个引用赋值到strVal上。当赋值完成后，我们就可以通过字段搜寻的方式来去访问具体的值了。

但是我们还可以通过final关键字来对上述代码进行优化：

[java]  view plain copy

1. static final int intVal = 42;  
2. static final String strVal = "Hello, world!";  

经过这样修改之后，定义类就不再需要一个<clinit>方法了，因为所有的常量都会在dex文件的初始化器当中进行初始化。当我们调用intVal时可以直接指向42的值，而调用strVal时会用一种相对轻量级的字符串常量方式，而不是字段搜寻的方式。

另外需要大家注意的是，这种优化方式只对基本数据类型以及String类型的常量有效，对于其它数据类型的常量是无效的。不过，对于任何常量都是用static final的关键字来进行声明仍然是一种非常好的习惯。

使用增强型for循环语法

增强型for循环（也被称为for-each循环）可以用于去遍历实现Iterable接口的集合以及数组，这是jdk 1.5中新增的一种循环模式。当然除了这种新增的循环模式之外，我们仍然还可以使用原有的普通循环模式，只不过它们之间是有效率区别的，我们来看下面一段代码：

[java]  view plain copy

1. static class Counter {  
2.     int mCount;  
3. }  
4.   
5. Counter[] mArray = ...  
6.   
7. public void zero() {  
8.     int sum = 0;  
9.     for (int i = 0; i < mArray.length; ++i) {  
10.         sum += mArray[i].mCount;  
11.     }  
12. }  
13.   
14. public void one() {  
15.     int sum = 0;  
16.     Counter[] localArray = mArray;  
17.     int len = localArray.length;  
18.     for (int i = 0; i < len; ++i) {  
19.         sum += localArray[i].mCount;  
20.     }  
21. }  
22.   
23. public void two() {  
24.     int sum = 0;  
25.     for (Counter a : mArray) {  
26.         sum += a.mCount;  
27.     }  
28. }  

可以看到，上述代码当中我们使用了三种不同的循环方式来对mArray中的所有元素进行求和。其中zero()方法是最慢的一种，因为它是把mArray.length写在循环当中的，也就是说每循环一次都需要重新计算一次mArray的长度。而one()方法则相对快得多，因为它使用了一个局部变量len来记录数组的长度，这样就省去了每次循环时字段搜寻的时间。two()方法在没有JIT（Just In Time Compiler）的设备上是运行最快的，而在有JIT的设备上运行效率和one()方法不相上下，唯一需要注意的是这种写法需要JDK 1.5之后才支持。

但是这里要跟大家提一个特殊情况，对于ArrayList这种集合，自己手写的循环要比增强型for循环更快，而其他的集合就没有这种情况。因此，对于我们来说，默认情况下可以都使用增强型for循环，而遍历ArrayList时就还是使用传统的循环方式吧。

多使用系统封装好的API

Java语言当中其实给我们提供了非常丰富的API接口，我们在编写程序时如果可以使用系统提供的API就应该尽量使用，系统提供的API完成不了我们需要的功能时才应该自己去写，因为使用系统的API在很多时候比我们自己写的代码要快得多，它们的很多功能都是通过底层的汇编模式执行的。

比如说String类当中提供的好多API都是拥有极高的效率的，像indexOf()方法和一些其它相关的API，虽说我们通过自己编写算法也能够完成同样的功能，但是效率方面会和这些方法差的比较远。这里举个例子，如果我们要实现一个数组拷贝的功能，使用循环的方式来对数组中的每一个元素一一进行赋值当然是可行的，但是如果我们直接使用系统中提供的System.arraycopy()方法将会让执行效率快9倍以上。

避免在内部调用Getters/Setters方法

我们平时写代码时都被告知，一定要使用面向对象的思维去写代码，而面向对象的三大特性我们都知道，封装、多态和继承。其中封装的基本思想就是不要把类内部的字段暴漏给外部，而是提供特定的方法来允许外部操作相应类的内部字段，从而在Java语言当中就出现了Getters/Setters这种封装技巧。

然而在Android上这个技巧就不再是那么的受推崇了，因为字段搜寻要比方法调用效率高得多，我们直接访问某个字段可能要比通过getters方法来去访问这个字段快3到7倍。不过我们肯定不能仅仅因为效率的原因就将封装这个技巧给抛弃了，编写代码还是要按照面向对象思维的，但是我们可以在能优化的地方进行优化，比如说避免在内部调用getters/setters方法。

那什么叫做在内部调用getters/setters方法呢？这里我举一个非常简单的例子：

[java]  view plain copy

1. public class Calculate {  
2.       
3.     private int one = 1;  
4.       
5.     private int two = 2;  
6.   
7.     public int getOne() {  
8.         return one;  
9.     }  
10.   
11.     public int getTwo() {  
12.         return two;  
13.     }  
14.       
15.     public int getSum() {  
16.         return getOne() + getTwo();  
17.     }  
18. }  

可以看到，上面是一个Calculate类，这个类的功能非常简单，先将one和two这两个字段进行了封装，然后提供了getOne()方法获取one字段的值，提供了getTwo()方法获取two字段的值，还提供了一个getSum()方法用于获取总和的值。

这里我们注意到，getSum()方法当中的算法就是将one和two的值相加进行返回，但是它获取one和two的值的方式也是通过getters方法进行获取的，其实这是一种完全没有必要的方式，因为getSum()方法本身就是Calculate类内部的方法，它是可以直接访问到Calculate类中的封装字段的，因此这种写法在Android上是不推崇的，我们可以进行如下修改：

[java]  view plain copy

1. public class Calculate {  
2.       
3.     private int one = 1;  
4.       
5.     private int two = 2;  
6.   
7.     ......  
8.       
9.     public int getSum() {  
10.         return one + two;  
11.     }  
12. }  

改成这种写法之后，我们就避免了在内部调用getters/setters方法，而对于外部而言Calculate类仍然是具有很好的封装性的。

4、网络优化
更多见 性能优化第四篇——移动网络优化

以下是网络优化中一些客户端和服务器端需要尽量遵守的准则：
a. 图片必须缓存，最好根据机型做图片做图片适配
b. 所有http请求必须添加httptimeout

c. 开启gzip压缩
d. api接口数据以json格式返回，而不是xml或html
e. 根据http头信息中的Cache-Control及expires域确定是否缓存请求结果。

f. 确定网络请求的connection是否keep-alive
g. 减少网络请求次数，服务器端适当做请求合并。
h. 减少重定向次数
i. api接口服务器端响应时间不超过100ms
google正在做将移动端网页速度降至1秒的项目，关注中https://developers.google.com/speed/docs/insights/mobile