一：学会懒惰
没搞错吧？竟然让程序开发人员学会懒惰？程序开发人员可能是世界上最为忙碌的一类人啦！对，没错，学会懒惰！正因为程序开发人员忙碌，正因为程序开发人员可能会在客户无限变化的需求之下没日没夜的加班，所以要学会懒惰，这样，你就可以把更多的时间浪费在美好的事物身上！
如何懒惰：
1，Don’t Reinvent the Wheel（不要重复发明轮子）。
2，Inventing the Wheel(发明轮子)。
1 ，Don’t Reinvent the Wheel（不要重复发明轮子）。
“轮子理论”，也即“不要重复发明轮子”，这是西方国家的一句谚语，原话是：Don’t Reinvent the Wheel。“不要重复发明轮子 ”意思是企业中任何一项工作实际上都有人做过，我们所需要做的就是找到做过这件事情的人。拿到软件领域中就是指有的项目或功能，别人已经做过，我们需要用的时候，直接拿来用即可，而不要重新制造。
Android号称是首个为移动终端打造的真正开放和完整的移动软件。Android发布后不久Google公司就发布了操作系统核心（Kernel）与部分驱动程序的源代码，到目前位置除了Google Map等Google公司的核心组件没有开放源代码外，Android基本完成了完全的开源，这就极大的促进了Android的普及和移植。受到Android开放行为和开源精神的影响，在世界各地，有成千上万的程序员喜欢和别人分享自己的聪明才智和自己编写的代码。你可以在Google的Android讨论组或者Google搜索引擎上搜索到很多优秀的程序代码。这样做并不是鼓励大家整天等着让别人为你编写代码，而是你可以“站在伟人的肩膀上”，充分发扬“拿来主义”，聪明地应用别人的程序代码可以节省你大量的时间。
下面笔者为大家介绍几个通用的类，这些类来自笔者平日的收集，如果你能把它们加入到你自己的类库中，迟早你会发现自己在进行Android开发的时候受益无穷：
2 ，Inventing the Wheel(发明轮子)。
发明轮子？不错，发明轮子！我们不仅要发明轮子，更要成为努力成为世界上发明轮子的主导力量，唯有这样，才能谈的上中华名族软件大业的真正强大。在Android，要发明轮子，就是我们要主动的是解决一些世界上他人未解决的难题或者创造新的编程框架或者对Android进行深度的改造以适合自己的业务发展需要。Google发布了Android后不久，中国移动便投入了大量的人力和物力，在Android的基础上创建融入自己业务并开发、封装了新的功能的和框架的OMS，这是Android中发明轮子的一个非常重要的例子。可能你会说，这发明轮子也太难了吧，别急，我们慢慢来，开发一个框架特定领域的框架吧！你可能会一脸无辜的说，开发一个框架是说的那么容易吗？当然不是啦。但是也并非不可能，首先，我们分析一下框架的魅力的源泉，看看Spring、Struts等Java EE框架，在看看.NET框架，当然也可以看看发展的如火如荼、层出不穷的PHP框架，她们的强大和魅力的源泉都在于：IoC(Inversion of Control)。
Don’t call us, we’ll call you（别找我，我会来找你的）。我们下面就自己发明一个轮子的模型，实际展示一个框架最初核心的类，让你一饱眼福：
二：精通Android体系架构、MVC、常见的设计模式、控制反转（IoC）
1，请看某个著名的IT公司一则招聘信息的其中一条要求：“熟悉Android系统架构及相关技术，1年以上实际Android平台开发经验；”，里面非常明确的说道要求熟练Android系统架构，这从某种程度上说明了对Android体系架构的理解的重要性，下面我们看看Android体系结构图，该图源自Android的文档：
很明显，上图包含四个主要的层次：
Linux Kernel：负责硬件的驱动程序、网络、电源、系统安全以及内存管理等功能。
Libraries和Android Runtime：Libraries：即C/C++函数库部分，大多数都是开放源代码的函数库，例如WebKit，该函数库负责Android网页浏览器的运行，例如标准的C函数库Libc、OpenSSL、SQLite等，当然也包括支持游戏开发2D SGL和3D OpenGL | ES，在多媒体方面有MediaFramework框架来支持各种影音和图形文件的播放与显示，例如MPEG4、H.264、MP3、AAC、AMR、JPG和PNG等众多的多媒体文件格式。Android的Runtime负责解释和执行生成的Dalvik格式的字节码。
Application Framework（应用软件架构），Java应用程序开发人员主要是使用该层封装好的API进行快速开发。
Applications:该层是Java的应用程序层，Android内置的Google Maps、E-mail、即时通信工具、浏览器、MP3播放器等处于该层，Java开发人员开发的程序也处于该层，而且和内置的应用程序具有平等的位置，可以调用内置的应用程序，也可以替换内置的应用程序。
上面的四个层次，下层为上层服务，上层需要下层的支持，调用下层的服务，这种严格分层的方式带来的极大的稳定性、灵活性和可扩展性，使得不同层的开发人员可以按照规范专心特定层的开发。
Android应用程序使用框架的API并在框架下运行，这就带来了程序开发的高度一致性，另一方面也告诉我们，要想写出优质高效的程序就必须对整个Application Framework进行非常深入的理解。精通Application Framework，你就可以真正的理解Android的设计和运行机制，也就更能够驾驭整个应用层的开发。
2 ，Android的官方建议应用程序的开发采用MVC模式。何谓MVC？先看看下图
MVC是Model,View,Controller的缩写，从上图可以看出MVC包含三个部分：
1.模型（Model）对象：是应用程序的主体部分，所有的业务逻辑都应该写在该层。
2.视图（View）对象：是应用程序中负责生成用户界面的部分。也是在整个MVC架构中用户唯一可以看到的一层，接收用户的输入，显示处理结果。
3.控制器（Control）对象：是根据用户的输入，控制用户界面数据显示及更新Model对象状态的部分，控制器更重要的一种导航功能，想用用户出发的相关事件，交给M哦得了处理。
Android鼓励弱耦合和组件的重用，在Android中MVC的具体体现如下：
1) 视图层（View）：一般采用XML文件进行界面的描述，使用的时候可以非常方便的引入，当然，如何你对Android了解的比较的多了话，就一定可以想到在Android中也可以使用JavaScript+HTML等的方式作为View层，当然这里需要进行Java和JavaScript之间的通信，幸运的是，Android提供了它们之间非常方便的通信实现。
2) 控制层（Controller）：Android的控制层的重任通常落在了众多的Acitvity的肩上，这句话也就暗含了不要在Acitivity中写代码，要通过Activity交割Model业务逻辑层处理，这样做的另外一个原因是Android中的Acitivity的响应时间是5s，如果耗时的操作放在这里，程序就很容易被回收掉。
3) 模型层（Model）：对数据库的操作、对网络等的操作都应该在Model里面处理，当然对业务计算等操作也是必须放在的该层的。
3 ，设计模式和IoC(控制反转)
毫无疑问，Android的之所以能够成为一个开放的气象万千的系统，与设计模式的精妙应用是分不开的，只要你稍微用心观察，就会发现在Android中到处都是A设计模式或者设计模式的联合运用，以下的设计模式是您游刃有余的驾驭Android所必须掌握的：
1. Template Method模式 ：(模板模式)
定义一个操作中算法的骨架，而将一些步骤延迟到子类中。不改变算法的结构而重新定义它的步骤。
2. Factory Method模式：(工厂模式)
FactoryMethod是一种创建性模式,它定义了一个创建对象的接口,但是却让子类来决定具体实例化哪一个类.当一个类无法预料要创建哪种类的对象或是一个类需要由子类来指定创建的对象时我们就需要用到Factory Method 模式了.简单说来,Factory Method可以根据不同的条件产生不同的实例,当然这些不同的实例通常是属于相同的类型,具有共同的父 类.Factory Method把创建这些实例的具体过程封装起来了,简化了客户端的应用,也改善了程序的扩展性,使得将来可以做最小的改动就可以加入新的待创建的类. 通常我们将Factory Method作为一种标准的创建对象的方法,当发现需要更多的灵活性的时候,就开始考虑向其它创建型模式转化
3. Observer模式：(观测者模式)
observer模式定义对象间的一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。JDK里提供的observer设计模式的实现由java.util.Observable类和java.util.Observer接口组成。从名字上可以清楚的看出两者在Observer 设计模式中分别扮演的角色：Observer是观察者角色，Observable是被观察目标(subject)角色。
4. Abstract Factory模式：(抽象工厂模式)
为创建一组相关或相互依赖的对象提供一个接口，而且无需指定它们的具体类。大致意思是说：我们在创建这些对象的时候，并不需要指定它们的具体类，这些具体类的对象是由工厂对象负责实例化的。
5. Adapter模式：(适配器模式)
把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。
6. Composite模式：(合成模式)
定义： 将对象组合成树形结构以表示“整体—部分”的层次结构。Composite模式使单个对象和组合对象的使用具有一致性。
合成模式将对象组织到树结构中，可以用来描述整体和部分的关系。合成模式可以使客户端将单纯的元素和复合的元素同等看待。
注意：用文件系统来理解合成模式可以说是个很好的方式。
7. Strategy模式：(策略模式)
定义一系列算法，把他们封装起来，并可相互替换，使算法可独立于使用他的客户而变化。
8. State模式：(声明模式)
定义一系列算法，把他们封装起来，并可相互替换，使算法可独立于使用他的客户而变化。
State模式主要解决的是在开发中时常遇到的根据不同的状态需要进行不同的处理操作的问题,而这样的问题,大部分人是采用switch-case语句进行处理的,这样会造成一个问题:分支过多,而且如果加入一个新的状态就需要对原来的代码进行编译。State模式采用了对这些不同的状态进行封装的方式处理这类问题,当状态改变的时候进行处理然后再切换到另一种状态,也就是说把状态的切换责任交给了具体的状态类去负责.同时,State模式和Strategy模式有很多相似的地方,需要说明的是两者的思想都是一致的,只不过封装的东西不同:State模式封装的是不同的状态,而Stategy模式封装的是不同的算法。
9. Proxy模式：(代理模式)
定义为其他对象提供一种代理以控制这个对象的访问。
Proxy代理模式是一种结构型设计模式，主要解决的问题是：在直接访问对象时带来的问题，比如说：要访问的对象在远程的机器上。在面向对象系统中，有些对象由于某些原因（比如对象创建开销很大，或者某些操作需要安全控制，或者需要进程外的访问），直接访问会给使用者或者系统结构带来很多麻烦，我们可以在访问此对象时加上一个对此对象的访问层,这个访问层也叫代理。Proxy模式是最常见的模式，在我们生活中处处可见，例如我们买火车票不一定非要到火车站去买，可以到一些火车票的代售点去买。寄信不一定是自己去寄，可以把信委托给邮局，由邮局把信送到目的地，现实生活中还有很多这样的例子，就不一一列举了。
10. Bridge模式：(桥梁模式)
定义 : 将抽象和行为划分开来,各自独立,但能动态的结合.
桥梁模式的用意是 “将抽象化(Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化”。这句话有三个关键词，也就是抽象化、实现化和脱耦。
11. Iterator模式：(迭代器模式)
定义：提供一个方法顺序访问一个聚合对象的各个元素，而又不暴露该对象的内部表示。
这个模式在java的类库中已经实现了，在java中所有的集合类都实现了Conllection接口，而Conllection接口又继承了Iterable接口，该接口有一个iterator方法，也就是所以的集合类都可以通过这个iterator方法来转换成Iterator类，用Iterator对象中的hasnext方法来判断是否还有下个元素，next方法来顺序获取集合类中的对象。
12. Memento 模式：（备忘录模式）
定义：在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样就可以将该对象恢复到原先保存前的状态。
在程序运行过程中，某些对象的状态处在转换过程中，可能由于某种原因需要保存此时对象的状态，以便程序运行到某个特定阶段，需要恢复到对象之前处于某个点时的状态。如果使用一些公有接口让其它对象来得到对象的状态，便会暴露对象的实现细节。
13. Facade模式：(外观模式)
定义：为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
Facade外观模式，是一种结构型模式，它主要解决的问题是：组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。在这里我想举一个例子：比如，现在有一辆汽车，我们（客户程序）要启动它，那我们就要发动引擎（子系统1），使四个车轮（子系统2）转动。但是实际中我们并不需要用手推动车轮使其转动，我们踩下油门，此时汽车再根据一些其他的操作使车轮转动。油门就好比系统给我们留下的接口，不论汽车是以何种方式转动车轮，车轮变化成什么牌子的，我们要开走汽车所要做的还是踩下油门。
14. Mediator 模式: (中介者模式)
定义：用一个中介者对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用，从而使其耦合松散，而且可以独立的改变他们之间的交互。
15. Chain of Responsibility模式 : (责任链模式)
定义: 为了避免请求的发送者和接收者之间的耦合关系，使多个接受对象都有机会处理请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
Struts2、tomcat的过滤器采用的模式（过滤器是它们的核心机制）
16. Command模式 : (命令模式)
定义：将一个请求封装为一个对象，从而使你不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
Commad模式是一种对象行为模式，它可以对发送者(sender)和接收者(receiver)完全解耦(decoupling)。（”发送者” 是请求操作的对象，”接收者” 是接收请求并执行某操作的对象。有了 “解耦”，发送者对接收者的接口一无所知。）这里，”请求”(request)这个术语指的是要被执行的命令。Command模式还让我们可以对 “何时” 以及 “如何” 完成请求进行改变。因此，Command模式为我们提供了灵活性和可扩展性。
17. Builder模式 : (建造者模式)
定义：将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。
建造模式是一步一步创建一个复杂的对象,它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们，用户不知道内部的具体构建细节。
18. Prototype模式 （原型模式）
通过给出一个原型对象来指明所要创建的对象类型，然后用复制这个原型对象的办法创建出更多的同类型对象。
在java的类库中已经实现了这一模式，只要你定义的类实现了Cloneable接口，用这个类所创建的对象可以做为原型对象进而克隆出更多的同类型的对象。
19. Singleton 模式: (单例模式) —–最简单的模式
定义：保证一个类只有一个实例，并提供一个访问它的全局访问点。
20. Visitor模式 : (访问者模式)
定义：表示一个作用于某对象结构中各元素的操作。它可以使你不修改各元素类的前提下定义作用于这些元素的新操作，也就是动态的增加新的方法。
21. FlyWeight模式：（享元模式）
定义：运用共享技术有效地支持大量细粒度对象。
也就是说在一个系统中如果有多个相同的对象，那么只共享一份就可以了，不必每个都去实例化一个对象。在Flyweight模式中，由于要产生各种各样的对象，所以在Flyweight(享元)模式中常出现Factory模式。Flyweight的内部状态是用来共享的,Flyweight factory负责维护一个对象存储池（Flyweight Pool）来存放内部状态的对象。Flyweight模式是一个提高程序效率和性能的模式,会大大加快程序的运行速度。
22.Decorator 模式： （装饰模式）
定义：动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式比生成子类更为灵活。
也就是说：动态地给对象添加一些额外的功能。它的工作原理是：创建一个始于Decorator对象（负责新功能的对象）终止于原对象的一个对象的“链”。例如，我们要为超市的收银台设计一个打印票据的程序，有的需要打印票据的头信息，有的需要打印票据的页脚信息，有的只需要打印票据的内容。如果针对每一种情况都修改一次程序，势必会很麻烦。这时我们可以考虑使用Decorator模式。
23. Ioc 模式：(控制反转模式)
IoC是一种用来解决组件（实际上也可以是简单的Java类）之间依赖关系、配置及生命周期的设计模式，其中对组件依赖关系的处理是IoC的精华部分。IoC的实际意义就是把组件之间的依赖关系提取（反转）出来，由容器来具体配置。这样，各个组件之间就不存在hard-code的关联，任何组件都可以最大程度的得到重用。运用了IoC模式后我们不再需要自己管理组件之间的依赖关系，只需要声明由容器去实现这种依赖关系。就好像把对组件之间依赖关系的控制进行了倒置，不再由组件自己来建立这种依赖关系而交给容器（例如PicoContainer、Spring）去管理。
Android框架魅力的源泉在于IoC，在开发Android的过程中你会时刻感受到IoC带来的巨大方便，就拿Activity来说，下面的函数是框架调用自动调用的：
protected void onCreate(Bundle savedInstanceState) ；
不是程序编写者主动去调用，反而是用户写的代码被框架调用，这也就反转了！当然IoC本身的内涵远远不止这些，但是从这个例子中也可以窥视出IoC带来的巨大好处。此类的例子在Android随处可见，例如说数据库的管理类，例如说Android中SAX的Handler的调用等。有时候，您甚至需要自己编写简单的IoC实现，上面展示的多线程现在就是一个说明。
三：编写可重用、可扩展、可维护、灵活性高的代码
Android应用程序的开发是使用Java编写，在架构上使用MVC，鼓励组件之间的若耦合。开发出编写可重用、可扩展、可维护、灵活性高的代码需要经历遵循以下原则：
l ” 开-闭”原则(OCP)： 一个软件实体应当对扩展开放，对修改关闭。这个原则说的是，在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。换言之，应当可以在不必修改源代码的情况下改变这个模块的行为。
l 里氏代换原则（LSP） ：一个软件实体如果使用的是一个基类的话，那么一定使用于其子类，而且它根本不能察觉出基类对象和子类对象的区别。
l 依赖倒转原则(DIP)：要依赖于抽象,不要依赖于具体。
l 接口隔离原则（ISP）：使用多个专门的接口比使用单一的总接口要好。一个类对另外一个类的依赖性应当是建立在最小的接口上的。
l 合成/聚合复用原则（CARP）：又称合成复用原则(CRP),就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。简而言之就是：要尽量使用合成/聚合，尽量不要使用继承。
l 迪米特法则（LoD）：又称最少知识原则（LKP），就是说一个对象应当对其他对象尽可能少的了解。狭义的迪米特法则是指如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用.如果其中一个类需要调用另一个类的方法的话,可以通过第三者转发这个调用.。广义的迪米特法则是指一个模块设计得好坏的一个重要的标志就是该模块在多大的程度上将自己的内部数据与实现有关的细节隐藏起来。信息的隐藏非常重要的原因在于,它可以使各个子系统之间脱耦,从而允许它们独立地被开发,优化,使用阅读以及修改.。
灵活的使用设计模式可以在面对千变万化的业务需求是编写出可重用、可扩展、可维护、灵活性高的代码。
当然，由于Android是运行在移动设备上的，而移动设备的处理能力是有限的，所以有时间必须在编写可重用、可扩展、可维护、灵活性高的代码与高效的代码之间做出适当的平衡。
四：高效的编写高效的代码
高效快速的编写代码和编写高效率执行的代码很多时候都是对立的死敌，很多时候，你想快速的开发，代码的执行效率往往就会慢下来；你想编写高效的代码，开发速度就会慢下来。
不重复发明轮子和发明新的轮子是高效的编写高效的代码的正确是道路。
关于高效的代码，下面网络的一篇文章，直接转载（不知道是哪位哥们写的）如下：
“现代的手持设备，与其说是电话，更像一台拿在手中的电脑。但是，即使是“最快”的手持设备，其性能也赶不上一台普通的台式电脑。
这就是为什么我们在书写Android应用程序的时候要格外关注效率。这些设备并没有那么快，并且受电池电量的制约。这意味着，设备没有更多的能力，我们必须把程序写的尽量有效。
本文讨论了很多能让开发者使他们的程序运行更有效的方法，遵照这些方法，你可以使你的程序发挥最大的效力。
对于占用资源的系统，有两条基本原则：
1. 不要做不必要的事
2. 不要分配不必要的内存
所有下面的内容都遵照这两个原则。
有些人可能马上会跳出来，把本节的大部分内容归于“草率的优化”（xing:参见[The Root of All Evil]），不可否认微优化（micro-optimization。xing:代码优化，相对于结构优化）的确会带来很多问题，诸如无法使用更有效的数据结构和算法。但是在手持设备上，你别无选择。假如你认为Android虚拟机的性能与台式机相当，你的程序很有可能一开始就占用了系统的全部内存（xing:内存很小），这会让你的程序慢得像蜗牛一样，更遑论做其他的操作了。
Android的成功依赖于你的程序提供的用户体验。而这种用户体验，部分依赖于你的程序是响应快速而灵活的，还是响应缓慢而僵化的。因为所有的程序都运行在同一个设备之上，都在一起，这就如果在同一条路上行驶的汽车。而这篇文档就相当于你在取得驾照之前必须要学习的交通规则。如果大家都按照这些规则去做，驾驶就会很顺畅，但是如果你不这样做，你可能会车毁人亡。这就是为什么这些原则十分重要。
当我们开门见山、直击主题之前，还必须要提醒大家一点：不管VM是否支持实时（JIT）编译器（xing:它允许实时地将Java解释型程序自动编译成本机机器语言，以使程序执行的速度更快。有些JVM包含JIT编译器。），下面提到的这些原则都是成立的。假如我们有目标完全相同的两个方法，在解释执行时foo()比bar()快，那么编译之后，foo()依然会比bar()快。所以不要寄希望于编译器可以拯救你的程序。
避免建立对象
世界上没有免费的对象。虽然GC为每个线程都建立了临时对象池，可以使创建对象的代价变得小一些，但是分配内存永远都比不分配内存的代价大。
如果你在用户界面循环中分配对象内存，就会引发周期性的垃圾回收，用户就会觉得界面像打嗝一样一顿一顿的。
所以，除非必要，应尽量避免尽力对象的实例。下面的例子将帮助你理解这条原则：
当你从用户输入的数据中截取一段字符串时，尽量使用substring函数取得原始数据的一个子串，而不是为子串另外建立一份拷贝。这样你就有一个新的String对象，它与原始数据共享一个char数组。
如果你有一个函数返回一个String对象，而你确切的知道这个字符串会被附加到一个StringBuffer，那么，请改变这个函数的参数和实现方式，直接把结果附加到StringBuffer中，而不要再建立一个短命的临时对象。
一个更极端的例子是，把多维数组分成多个一维数组。
int数组比Integer数组好，这也概括了一个基本事实，两个平行的int数组比(int,int)对象数组性能要好很多。同理，这试用于所有基本类型的组合。
如果你想用一种容器存储(Foo,Bar)元组，尝试使用两个单独的Foo[]数组和Bar[]数组，一定比(Foo,Bar)数组效率更高。（也有例外的情况，就是当你建立一个API，让别人调用它的时候。这时候你要注重对API借口的设计而牺牲一点儿速度。当然在API的内部，你仍要尽可能的提高代码的效率）
总体来说，就是避免创建短命的临时对象。减少对象的创建就能减少垃圾收集，进而减少对用户体验的影响。
使用本地方法
当你在处理字串的时候，不要吝惜使用String.indexOf(), String.lastIndexOf()等特殊实现的方法（specialty methods）。这些方法都是使用C/C++实现的，比起Java循环快10到100倍。
使用实类比接口好
假设你有一个HashMap对象，你可以将它声明为HashMap或者Map:
Map myMap1 = new HashMap();
HashMap myMap2 = new HashMap();
哪个更好呢？
按照传统的观点Map会更好些，因为这样你可以改变他的具体实现类，只要这个类继承自Map接口。传统的观点对于传统的程序是正确的，但是它并不适合嵌入式系统。调用一个接口的引用会比调用实体类的引用多花费一倍的时间。
如果HashMap完全适合你的程序，那么使用Map就没有什么价值。如果有些地方你不能确定，先避免使用Map，剩下的交给IDE提供的重构功能好了。(当然公共API是一个例外：一个好的API常常会牺牲一些性能）
用静态方法比虚方法好
如果你不需要访问一个对象的成员变量，那么请把方法声明成static。虚方法执行的更快，因为它可以被直接调用而不需要一个虚函数表。另外你也可以通过声明体现出这个函数的调用不会改变对象的状态。不用getter和setter
在很多本地语言如C++中，都会使用getter（比如：i = getCount()）来避免直接访问成员变量（i = mCount）。在C++中这是一个非常好的习惯，因为编译器能够内联访问，如果你需要约束或调试变量，你可以在任何时候添加代码。
在Android上，这就不是个好主意了。虚方法的开销比直接访问成员变量大得多。在通用的接口定义中，可以依照OO的方式定义getters和setters，但是在一般的类中，你应该直接访问变量。
将成员变量缓存到本地
访问成员变量比访问本地变量慢得多，下面一段代码：
for (int i = 0; i < this.mCount; i++)
dumpItem(this.mItems[i]);
最好改成这样：
int count = this.mCount;
Item[] items = this.mItems;
for (int i = 0; i < count; i++)
dumpItems(items[i]);
（使用”this”是为了表明这些是成员变量）
另一个相似的原则是：永远不要在for的第二个条件中调用任何方法。如下面方法所示，在每次循环的时候都会调用getCount()方法，这样做比你在一个int先把结果保存起来开销大很多。
for (int i = 0; i < this.getCount(); i++)
dumpItems(this.getItem(i));
同样如果你要多次访问一个变量，也最好先为它建立一个本地变量，例如：
protected void drawHorizontalScrollBar(Canvas canvas, int width, int height) {
if (isHorizontalScrollBarEnabled()) {
int size = mScrollBar.getSize(false);
if (size <= 0) {
size = mScrollBarSize;
}
mScrollBar.setBounds(0, height - size, width, height);
mScrollBar.setParams(computeHorizontalScrollRange(),computeHorizontalScrollOffset(),computeHorizontalScrollExtent(), false);
mScrollBar.draw(canvas);
}
}
这里有4次访问成员变量mScrollBar，如果将它缓存到本地，4次成员变量访问就会变成4次效率更高的栈变量访问。
另外就是方法的参数与本地变量的效率相同。
使用常量
让我们来看看这两段在类前面的声明：
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>方法，因为在成员变量初始化的时候，会将常量直接保存到类文件中。用到intVal的代码被直接替换成42，而使用strVal的会指向一个字符串常量，而不是使用成员变量。
将一个方法或类声明为”final”不会带来性能的提升，但是会帮助编译器优化代码。举例说，如果编译器知道一个”getter”方法不会被重载，那么编译器会对其采用内联调用。
你也可以将本地变量声明为”final”，同样，这也不会带来性能的提升。使用”final”只能使本地变量看起来更清晰些（但是也有些时候这是必须的，比如在使用匿名内部类的时候）（xing:原文是 or you have to, e.g. for use in an anonymous inner class）
谨慎使用foreach
foreach可以用在实现了Iterable接口的集合类型上。foreach会给这些对象分配一个iterator，然后调用 hasNext()和next()方法。你最好使用foreach处理ArrayList对象，但是对其他集合对象，foreach相当于使用 iterator。
下面展示了foreach一种可接受的用法：
public class Foo {
int mSplat;
static Foo mArray[] = new Foo[27];
public static void zero() {
int sum = 0;
for (int i = 0; i < mArray.length; i++) {
sum += mArray[i].mSplat;
}
}
public static void one() {
int sum = 0;
Foo[] localArray = mArray;
int len = localArray.length;
for (int i = 0; i < len; i++) {
sum += localArray[i].mSplat;
}
}
public static void two() {
int sum = 0;
for (Foo a: mArray) {
sum += a.mSplat;
}
}
}
在zero()中，每次循环都会访问两次静态成员变量，取得一次数组的长度。
retrieves the static field twice and gets the array length once for every iteration through the loop.
在one()中，将所有成员变量存储到本地变量。
pulls everything out into local variables, avoiding the lookups.
two()使用了在java1.5中引入的foreach语法。编译器会将对数组的引用和数组的长度保存到本地变量中，这对访问数组元素非常好。但是编译器还会在每次循环中产生一个额外的对本地变量的存储操作（对变量a的存取）这样会比one()多出4个字节，速度要稍微慢一些。
综上所述：foreach语法在运用于array时性能很好，但是运用于其他集合对象时要小心，因为它会产生额外的对象。
避免使用枚举
枚举变量非常方便，但不幸的是它会牺牲执行的速度和并大幅增加文件体积。例如：
public class Foo {public enum Shrubbery { GROUND, CRAWLING, HANGING }}
会产生一个900字节的.class文件(Foo$Shubbery.class)。在它被首次调用时，这个类会调用初始化方法来准备每个枚举变量。每个枚举项都会被声明成一个静态变量，并被赋值。然后将这些静态变量放在一个名为”$VALUES”的静态数组变量中。而这么一大堆代码，仅仅是为了使用三个整数。
这样:
Shrubbery shrub = Shrubbery.GROUND;会引起一个对静态变量的引用，如果这个静态变量是final int，那么编译器会直接内联这个常数。
一方面说，使用枚举变量可以让你的API更出色，并能提供编译时的检查。所以在通常的时候你毫无疑问应该为公共API选择枚举变量。但是当性能方面有所限制的时候，你就应该避免这种做法了。
有些情况下，使用ordinal()方法获取枚举变量的整数值会更好一些，举例来说，将：
for (int n = 0; n < list.size(); n++) {
if (list.items[n].e == MyEnum.VAL_X)// do stuff 1
else if (list.items[n].e == MyEnum.VAL_Y)// do stuff 2
}
替换为:
int valX = MyEnum.VAL_X.ordinal();
int valY = MyEnum.VAL_Y.ordinal();
int count = list.size();
MyItem items = list.items();
for (int n = 0; n < count; n++) {
int valItem = items[n].e.ordinal();
if (valItem == valX)// do stuff 1
else if (valItem == valY)// do stuff 2
}
会使性能得到一些改善，但这并不是最终的解决之道。
将与内部类一同使用的变量声明在包范围内
请看下面的类定义：
public class Foo {
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);
}
private class Inner {
void stuff() {
Foo.this.doStuff(Foo.this.mValue);
}
}
} 这其中的关键是，我们定义了一个内部类(Foo$Inner)，它需要访问外部类的私有域变量和函数。这是合法的，并且会打印出我们希望的结果”Value is 27″。
问题是在技术上来讲（在幕后）Foo$Inner是一个完全独立的类，它要直接访问Foo的私有成员是非法的。要跨越这个鸿沟，编译器需要生成一组方法：
static int Foo.access$100(Foo foo) {
return foo.mValue;
}
static void Foo.access$200(Foo foo, int value) {
foo.doStuff(value);
}
内部类在每次访问”mValue”和”doStuff”方法时，都会调用这些静态方法。就是说，上面的代码说明了一个问题，你是在通过接口方法访问这些成员变量和函数而不是直接调用它们。在前面我们已经说过，使用接口方法（getter、setter）比直接访问速度要慢。所以这个例子就是在特定语法下面产生的一个“隐性的”性能障碍。
通过将内部类访问的变量和函数声明由私有范围改为包范围，我们可以避免这个问题。这样做可以让代码运行更快，并且避免产生额外的静态方法。（遗憾的是，这些域和方法可以被同一个包内的其他类直接访问，这与经典的OO原则相违背。因此当你设计公共API的时候应该谨慎使用这条优化原则）
避免使用浮点数
在奔腾CPU出现之前，游戏设计者做得最多的就是整数运算。随着奔腾的到来，浮点运算处理器成为了CPU内置的特性，浮点和整数配合使用，能够让你的游戏运行得更顺畅。通常在桌面电脑上，你可以随意的使用浮点运算。
但是非常遗憾，嵌入式处理器通常没有支持浮点运算的硬件，所有对”float”和”double”的运算都是通过软件实现的。一些基本的浮点运算，甚至需要毫秒级的时间才能完成。
甚至是整数，一些芯片有对乘法的硬件支持而缺少对除法的支持。这种情况下，整数的除法和取模运算也是有软件来完成的。所以当你在使用哈希表或者做大量数学运算时一定要小心谨慎。 ”
五，学会至少一门服务器端开发技术
可能有朋友会问：学习Android应用程序开发为什么还需要学习学会至少一门服务器端开发技术呢？答案如下：一方面Android号称是首个为移动终端打造的真正开放和完整的移动软件。作为一种移动终端，必须与服务器端结合才能发挥巨大的作用。简言之，需要：云端+云的方式。Android是为移动互联网时代量身打造的，移动互联网时代的服务模式是“手机终端+互联网络+应用软件”，移动互联网时代应用技术之一的Android只是用于开发移动终端软件，而服务端技术用于开发互联网络应用，所以未来移动互联网时代软件的主流应用模式将是“手机客户端+互联网络应用服务端”，这种模式要求做移动互联网开发的程序员不但要掌握像Android这样的手机终端软件技术还要掌握开发互联网络应用的服务器端技术。目前，软件企业普遍存在这样的问题，做移动互联网开发Android终端软件的程序员不了解web应用技术，而做web应用的程序员不了解移动终端技术，这样就导致了客户端与服务端在衔接上出现了问题。目前的现状是：既掌握移动互联网Android终端技术，又掌握web应用技术的程序员比较稀缺，随着中国步入移动互联网时代，企业对这种移动互联网时代综合性人才的需求很旺盛。如果不了解web应用技术，最终会遇到了技术和发展的瓶颈；另一方面，Google联合OHA推出的真正优势之一也在于和和互联网结合，Google的用意之一也是想开辟新的终端去使用Google的优势服务。
服务器端开发技术目前主流的有Sun的Java EE、微软的.NET，开源的以PHP和MySQL为代表的LAMP体系，我们该选择哪一种呢？从理论上讲，很多人倾向于选择Java EE，毕竟它们都是使用Java作为开发语言的，但是很多人面对Java EE众多的框架就望而生畏，其实在学习Java EE的时候可以从Struts入手，随着业务的需求逐步深入。当然，选择微软的.NET也行，毕竟该技术体系也占有很大 市场份额。其实，笔者认为，选择LAMP可以是会获得最高的“性价比”的，一方面PHP是现在Web方面的主流语言，大多数新型的网站尤其是创业性质的网站一般都会选用PHP作为服务端开发语言，另一方面，前面也说过，Android是为移动互联而生的，两者达到了完美的契合。
