Android学习之——优化篇(转)

最新推荐文章于 2017-02-08 10:23:45 发布

月影飞烟

最新推荐文章于 2017-02-08 10:23:45 发布

阅读量290

点赞数

分类专栏： android

android 专栏收录该内容

11 篇文章 0 订阅

订阅专栏

一、高级优化

上篇主要从初级优化的方式，本篇主要将从程序运行性能的角度出发，分析各种常用方案的不足，并给出对象池技术、基础数据类型替换法、屏蔽函数计算三种能够节省资源开销和处理器时间的优化策略。

目前普遍采用的优化方案有：

· 优化循环，通过重新组织重复的子表达式来提高循环体的运行性能

· 减少使用对象的数量来提高运行性能

· 缩减网络传输数据来缩短等待时间等

本篇学习另外三种性能优化的策略：

1. 采用对象池技术，提高对象的利用率

Java 中创建和释放对象会占用相当大的资源，采用对象池技术，用来提高对象的利用率

例如：游戏中敌机处理方式：方法一是游戏载入关卡时候，为每架敌机创建一个对象，这种方案中创建对象的资源开销巨大，因此严重影响手机游戏的运行性能。方法二是游戏进程中，动态创建敌机对象，被击毁以后将对象设置为null并由System.gc() 回收。

游戏性能损耗主要在创建和释放对象，而不创建对象又无法实现逻辑功能，因此要尽量避免对象的创建和释放。

解决方案：根据需求先创建一定量的对象，在需要的创建对象的时候从对象池中申请空闲对象，释放对象时把对象释放回池中，以有效避免由创建和释放对象带来的性能损失

上例中需求是敌机不超过5架，所以可以使用如下代码：

<span style="font-family:Microsoft YaHei;">Enemy[5] enemy = new Enemy[5];
for(int i = 0; i<5;i++){
	enemy[i] = new Enemy();
}</span>

在类Enemy 里增加标志属性used 和带参数的 reset 方法使对象可重置到初始状态，在载入游戏关卡的时候初始化对象池，在需要创建对象的时候从对象池获取一个未被使用的对象并使用 reset 方法初始化，需要释放对象的时候只需将标志位修改以供下次使用。

2. 局部使用基本数据类型代替对象，节省资源开销

3. 用简单的数值计算代替复杂的函数计算，节省处理器时间

二、 Android 高效开发

两个基本原则：不要做不必要做的事情；尽可能的节省内存的使用。

1. 尽可能的避免创建对象。如下优化案例：

· 从原始输入数据中提取字符串时，试着从原始字符串返回一个子字符串，而不是创建一份副本。你将会创建一个新的字符串对象，但是它和你的原始数据共享数据空间。

· 如果你有一个返回字符串的方法，你应该知道无论如何返回的结果是StringBuffer，改变你的函数的定义和执行，让函数直接返回而不是通过创建一个临时的对象。

· 一个 Int 类型数组要比一个 Integer 类型的数组要好，但同样也可以归纳这样一个原则，两个 Int 类型的数组要比一个 (int, int) 对象数组的效率高得多。其他基础数据类型也是如此。

· 两个平行的 Foo[] 和 Bar[] 要比一个(Foo,Bar) 对象数组的效率高得多

一般来说，我们应该尽可能地避免创建短期的临时对象。越少的对象创建意味着越少的垃圾回收，这样提高你程序的用户体验质量。

2. 使用自身方法

当处理字符串的时候，不要犹豫，尽可能多地使用诸如： String.indexOf()、String.lastIndexOf() 这样对象自身带有的方法。因为这些方法是用C/C++ 来实现的，比Java 循环来的快10~100 倍

3. 使用虚拟优于使用接口

假设你有一个 HashMap 对象，你可以申明它是一个 HashMap 或者只是一个 Map，如下：

<span style="font-family:Microsoft YaHei;">Map myMap1 = new HashMap();
HashMap myMap2 = new HashMap();</span>

一般来说明智的做法是使用 Map，因为它允许你改变 Map 接口执行上面的任何东西，。相对于通过具体的引用进行虚拟函数的调用，通过接口引用来调用会花费2倍以上的时间。

4. 使用静态优于使用虚拟

如果你没有必要去访问对象的外部，那么就使你的方法成为静态。它会被更快的调用，因为它不需要一个虚拟函数导向表。调用这个方法不会改变对象的状态。

5. 尽可能避免使用内在的Get，Set 方法

虚方法的调用会产生很多代价，比实例属性查询的代价还要多。我们应该在外部调用时使用 Get 和 Set 函数，但是在内部调用时，我们应该直接调用。

6. 缓冲属性调用

for(int i = 0; i < this.mCount; i++){
	dumpItem(this.mItems[i]);
}

应该这样写：

<span style="font-family:Microsoft YaHei;">int count = this.mCount;
for(int i = 0; i < count; i++){
	dumpItem(this.mItems[i]);
}</span>

一个相似的原则就是：绝不在一个 For 语句中第二次调用一个类的方法。

7. 申明 Final 常量

static String strVal = "100";
static final String strVal = "100";

不加 final 编译器会调用一个类初始化方法 <clinit>，这个方法为strVal 在类文件字符串常量表中提取一个引用。加了final就不会调用，因为这些常量直接写入了类文件静态属性初始化中，这个初始化直接由虚拟机来处理。

将一个类或者方法申明为“final” 并不会带来任何执行上的好处，它能够进行一定的最优化处理。如果编译器知道一个Get 方法不能被子类重载，那么它就该把函数设置成 Inline

8. 慎用增强型 For 循环语句

在其他收集器里面，增强型 for 循环相当于 iterator 的使用。

9. 避免列举类型

10. 通过内联类使用包空间

11. 避免浮点类型的使用

嵌入式的处理器通常不支持浮点数的处理，因此所有的 float 和 double 操作都是通过软件进行的，一些基本的浮点数的操作就需要花费毫秒级的时间。

三、Android UI 优化

1. RelativeLayout 和 LinearLayout 在资源利用上，前者占用更少的资源而达到相同的目的。

RelativeLayout 需要注意的是内部是通过多个View 之间的关系确定的框架，所以当其中一个View 因为某些需要调用 GONE 来完全隐藏掉以后，会影响与其相关联的Views。解决方案是使用 alignWithParentIfMissing属性来解决类型的问题。

2. <viewStub />此标签可以使 UI在特殊情况下，直观效果类似于设置 View 的不可见性，但是更大的意义在于被这个标签所包裹的 View 在默认状态下不会占用任何内存空间。 viewStub 通过 include 从外部导入 View 元素。用法是通过 android:layout 来指定所包含的内容。默认情况下， ViewStub 所包含的标签都属于 visibility = GONE。 viewStub 通过方法 inflate() 来召唤系统加载其内部的 View。

<span style="font-family:Microsoft YaHei;"><ViewStub
	android:inflatedId="@+id/subTree"
	android:layout="@layout/mySubTree"
	android:layout_width="120dp"
	android:layout_height="40dp" /></span>

<include />:可以通过这个标签直接加载外部的xml到当前结构中，是复用 UI 资源的常用标签。

<requestFocus /> 标签用于指定屏幕内的焦点View 。用法是将标签至于 View 标签内部

<span style="font-family:Microsoft YaHei;"><EditText
	android:layout="@layout/mySubTree"
	android:layout_width="120dp"
	android:layout_height="40dp">
	<requestFocus />
</EditText></span>

<merge /> 标签：优化 UI 结构时起到很重要的作用。目的是通过删减多余或者额外的层级，从而优化整个 Android Layout 的结构。

四、图片优化

1. 图片压缩

图片缩小的操作是删除部分像素点，小图放大则要人为地添加一些像素点。图片放大不总是成倍的。在移植到不同的手机时可以先用菜单画布界面 getWith() 以及 getHeight() 取得当前手机屏幕的宽度和高度，如果当前图片不够满屏显示就对图片进行放大，相反则缩小。也可以自定义屏幕显示图片的大小，如在屏幕上显示多张图片的缩略图，使图片方式的显示更加丰富。

2. 减少图片容量

· 将多张图片集成到一张图片上。因为省去了多张图片的文件头、文件结束数据块等，而且合并了调色板

· 减少图片的颜色数

转自: http://www.eyeandroid.com/thread-8110-1-1.html