本文列出的优化技巧主要是一些微小的性能提升，可能不会给你的程序性能改善产生显著的效果。决定程序整体性能的仍然取决于程序的业务逻辑设计、代码的数据结构和算法，这超出了本文的范围。你需要将这些优化技巧应用到平时的编码过程中，积少成多，也会对性能有很大的影响。
下面是写高效代码的两个基本原则：
1.不要写不需要的代码；
2.不要分配不必要的内存。
android应用程序优化一个非常棘手的问题就是android硬件差异很大。不同的虚拟机、不同的SDK版本。app在不同的设备环境上运行速度和性能自然不同；在有无JIT的设备上也各不相同。因此，为了确保你的app性能在最大范围上的设备都比较高，你应该在最大化的优化你的代码逻辑和性能。
Avoid Creating Unnecessary Objects
创建对象总是有代价的。每个线程的分代GC给临时对象分配一个地址池以降低分配开销，但往往内存分配比不分配需要的代价大。如果你的app创建的对象越来越多，分配的内存也越来越多，就会强制一个周期性的垃圾回收，给用户体验增加小小的停顿间隙。Gingerbread（Android2.3）中提到的并发回收也许有用，但不必要的工作应当是被避免的。
那么，你应该避免产生并不需要的对象实例。下面是一些例子：
1.如果有一个返回String的方法，并且他的返回值常常附加在一个StringBuffer上，改变声明和实现，让函数直接在其后面附加，而非创建一个短暂存在的零时变量。
2. 当从输入的数据集合中读取数据时，考虑返回原始数据的子串，而非新建一个拷贝.这样你虽然创建一个新的对象，但是他们共享该数据的char数组。（结果是即使仅仅使用原始输入的一部分，你也需要保证它的整体一直存在于内存中。）
一个更彻底的方案是将多维数组切割成平行一维数组：
1.int的数组比Integer对象数组要好得多。推而广之，两个平行的int数组要比一个（int,int）型的对象数组高效。这对于其他任何基本数据类型的组合都通用
2.如果需要实现一个容器来存放元组（Foo,Bar），两个平行数组Foo[],Bar[]会优于一个（Foo,Bar）对象的数组。（例外情况是：当你设计API给其他代码调用时，应用好的API设计来换取小的速度提升。但在自己的内部代码中，尽量尝试高效的实现。
通常来讲，尽量避免创建短时零时对象.少的对象创建意味着低频的垃圾回收。而这对于用户体验产生直接的影响。
用静态代替虚拟
如果不需要访问某对象的字段，将方法设置为静态，调用会加速15%到20%。这也是一种好的做法，因为你可以从方法声明中看出调用该方法不需要更新此对象的状态。
Use Static Final For Constants
看看下面类首的声明：
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，也会采用相对开销较小的“字符串常量”（原文：“sring constant”）指令替代字段查找。
注：这种优化仅仅是针对基本数据类型和String类型常量的，而非任意的引用类型。但尽可能的将常量声明为static final是一种好的做法。
Avoid Internal Getters/Setters
在源生语言像C++中，通常做法是用Getters（i=getCount()）代替直接字段访问（i=mCount）。这是C++中一个好的习惯，因为编译器会内联这些访问，并且如果需要约束或者调试这些域的访问，你可以在任何时间添加代码。
而在Android中，这不是一个好的做法。虚方法调用的代价比直接字段访问高昂许多。通常根据面向对象语言的实践，在公共接口中使用Getters和Setters是有道理的，但在类中一个字段经常被访问的话宜采用直接访问。
Use Enhanced For Loop Syntax
改进for循环（有时被称为“for-each”循环）能够用于实现了iterable接口的集合类及数组中。在集合类中，迭代器让接口调用hasNext()和next()方法。
在ArrayList中，手写的计数循环迭代要快3倍（无论有没有JIT），但其他集合类中，改进的for循环语法和迭代器具有相同的效率。
这里有一些迭代数组的实现：
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()不分上下。他采用了JDK1.5中的改进for循环语法。
结论：优先采用改进for循环，但在性能要求苛刻的ArrayList迭代中，考虑采用手写计数循环。
(参见 Effective Java item 46.)
Consider Package Instead of Private Access with Private Inner Classes
考虑下面的类定义：
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”。
但问题是，虚拟机认为从Foo$Inner中直接访问Foo的私有成员是非法的，因为他们是两个不同的类，尽管Java语言允许内部类访问外部类的私有成员，但是通过编译器生成几个综合方法来桥接这些间隙的：
内部类会在外部类中任何需要访问mValue字段或调用doStuff方法的地方调用这些静态方法。这意味着这些代码将直接存取成员变量表现为通过存取器方法访问。之前提到过存取器访问如何比直接访问慢，这例子说明，某些语言约会定导致不可见的性能问题。
如果你在高性能的Hotspot中使用这些代码，可以通过声明被内部类访问的字段和成员为包访问权限，而非私有。但这也意味着这些字段会被其他处于同一个包中的类访问，因此在公共API中不宜采用。
Avoid Using Floating-Point
通常的经验是，在Android设备中，浮点数会比整型慢两倍。
从速度方面说，在现代硬件上，float和double之间没有任何不同。更广泛的讲，double大2倍。在台式机上，由于不存在空间问题，double的优先级高于float。
但即使是整型，有的芯片拥有硬件乘法，却缺少除法。这种情况下，整型除法和求模运算是通过软件实现的，就像当你设计Hash表，或是做大量的算术那样。
Know and Use the Libraries
选择Library中的代码而非自己重写，除了通常的那些原因外，考虑到系统空闲时会用汇编代码调用来替代library方法，这可能比JIT中生成的等价的最好的Java代码还要好。典型的例子就是String.indexOf，Dalvik用内部内联来替代。同样的，System.arraycopy方法在有JIT的Nexus One上，自行编码的循环快9倍。
(参见 Effective Java item 47.)
那即是Java标准库和Android Framework中包含了大量高效且健壮的库函数，很多函数还采用了native实现，通常情况下比我们用Java实现同样功能的代码的效率要高很多。所以善于使用系统库函数可以节省开发时间，并且也不容易出错。
Use Native Methods Carefully
native方法并不是一定比Java高效。最起码，Java和native之间过渡的关联是有消耗的，而JIT并不能对此进行优化。当你分配本地资源时（native堆上的内存，文件说明符等），往往很难实时的回收这些资源。同时你也需要在各种结构中编译你的代码（而非依赖JIT）。
甚至可能需要针对相同的架构来编译出不同的版本：针对ARM处理器的GI编译的native代码，并不能充分利用Nexus One上的ARM，而针对Nexus One上ARM编译的本地代码不能在G1的ARM上运行。
当你想部署程序到存在native代码库的Android平台上时，本地代码才显得尤为有用，而并非为了Java应用程序的提速。(参见 Effective Java item 54.)
Performance Myths
在没有JIT的设备上，调用方法所传递的对象采用具体的类型而非接口类型会更高效（比如，传递HashMapmap比Map map调用一个方法的开销小，尽管两个map都是HashMap）.但这并不是两倍慢的情形，事实上，他们只相差6%，而有JIT时这两种调用的效率不相上下。
在没有JIT的设备上，缓存后的字段访问比直接访问快大概20%。而在有JIT的情况下，字段访问的代价等同于局部访问，因此这里不值得优化，除非你觉得他会让你的代码更易读（对于final ,static，及static final 变量同样适用）
结语
最后：通常考虑的是：先确定存在问题，再进行优化。并且你知道当前系统的性能，否则无法衡量你进行尝试所得到的提升。
这份文档中的每个主张都有标准基准测试作为支持。你可以在code.google.com“dalvik”项目中找到基准测试的代码。
这个标准基准测试是建立在Caliper Java标准微基准测试框架之上的。标准微基准测试很难找到正确的路，所以Caliper帮你完成了其中的困难部分工作。并且当你会察觉到某些情况的测试结果并想象中的那样（虚拟机总是在优化你的代码的）。我们强烈推荐你用Caliper来运行你自己的标准微基准测试。
同时你也会发现Traceview对分析很有用，但必须了解，他目前是不不支持JIT的，这可能导致那些在JIT上可以胜出的代码运行超时。特别重要的，根据Taceview的数据作出更改后，请确保代码在没有Traceview时，确实跑的快了