这篇文章主要介绍一些小细节的优化技巧，当这些小技巧综合使用起来的时候，对于整个App的性能提升还是有作用的，只是不能较大幅度的提升性能而已。选择合适的算法与数据结构才应该是你首要考虑的因素，在这篇文章中不会涉及这方面。你应该使用这篇文章中的小技巧作为平时写代码的习惯，这样能够提升代码的效率。
通常来说，高效的代码需要满足下面两个规则：
不要做冗余的工作
如果能避免，尽量不要分配内存
在优化App时最难解决的问题之一就是让App能在各种类型的设备上运行。不同版本的虚拟机在不同的处理器上会有不同的运行速度。你甚至不能简单的认为“设备X的速度是设备Y的F倍”，然后还用这种倍数关系去推测其他设备。特别的是，在模拟器上的运行速度和在实际设备上的速度没有半点关系。同样，设备有没有JIT（即时编译，译者注）也对运行速度有重大影响：在有JIT情况下的最优化代码不一定在没有JIT的情况下也最优化。
为了确保App在各设备上都能良好运行，就要确保你的代码在不同档次的设备上都尽可能的优化。
避免创建不必要的对象创建对象从来不是无代价的。在线程分配池里的逐代垃圾回收器可以使临时对象的分配变得廉价一些，但是分配内存总是比不分配更昂贵。
随着你在App中分配更多的对象，你可能需要强制GC（垃圾回收，译者注），为用户体验做一个小小的减压。Android 2.3 中引入的并发GC会帮助你做这件事情，但毕竟不必要的工作应该尽量避免
因此请尽量避免创建不必要的对象，有下面一些例子来说明这个问题：
如果你需要返回一个String对象，并且你知道它最终会需要连接到一个StringBuffer，请修改你的函数签名和实现方式，避免直接进行连接操作，应该采用创建一个临时对象来做这个操作.
当从输入的数据集中抽取出String的时候，尝试返回原数据的substring对象，而不是创建一个重复的对象。你将会 new 一个 String 对象，但是它应该和原数据共享内部的 char[]（代价是如果你只是用原数据中的一小部分，你只需要保存这一小部分的对象在内存中）
一个稍微激进点的做法是把所有多维的数据分解成一维的数组:
一组int数据要比一组Integer对象要好很多。可以得知，两组一维数组要比一个二维数组更加的有效率。同样的，这个道理可以推广至其他原始数据类型。
如果你需要实现一个数组用来存放(Foo,Bar)的对象，记住使用Foo[]与Bar[]要比(Foo,Bar)好很多。(例外的是，为了某些好的API的设计，可以适当做一些妥协。但是在自己的代码内部，你应该多多使用分解后的容易）。
通常来说，需要避免创建更多的临时对象。更少的对象意味者更少的GC动作，GC会对用户体验有比较直接的影响。
选择Static而不是Virtual如果你不需要访问一个对象的值域,请保证这个方法是static类型的,这样方法调用将快15%-20%。这是一个好的习惯，因为你可以从方法声明中得知调用无法改变这个对象的状态。
常量声明为Static Final考虑下面这种声明的方式
staticint intVal =42;
staticString strVal ="Hello, world!";
编译器会使用一个初始化类的函数，然后当类第一次被使用的时候执行。这个函数将42存入intVal，还从class文件的常量表中提取了strVal的引用。当之后使用intVal或strVal的时候，他们会直接被查询到。
我们可以用final关键字来优化：
staticfinalint intVal =42;
staticfinalString strVal ="Hello, world!";
这时再也不需要上面的方法了，因为final声明的常量进入了静态dex文件的域初始化部分。调用intVal的代码会直接使用42，调用strVal的代码也会使用一个相对廉价的“字符串常量”指令，而不是查表。
注意：这个优化方法只对原始类型和String类型有效，而不是任意引用类型。不过，在必要时使用static final是个很好的习惯
避免内部的Getters/Setters像C++等native language,通常使用getters(i = getCount())而不是直接访问变量(i = mCount)。这是编写C++的一种优秀习惯，而且通常也被其他面向对象的语言所采用，例如C#与Java，因为编译器通常会做inline访问，而且你需要限制或者调试变量，你可以在任何时候在getter/setter里面添加代码。