如何成为Android高手

若立志成为 Android 高手 ，如有耐心， “ 一瓶一钵足矣 ” 。

　　 “ 天下事有难易乎？为之，则难者亦易矣；不为，则易者亦难矣。人之为学有难易乎？学之，则难者亦易矣；不学，则易者亦难矣。 ” 想成为 Android 高手？这可不是想象中写几行代码 那么容易的事情，但也不是不可实现。

 

　　如何做？

　　 1 ，学会懒惰！奇怪吧？但是，你一定也听说过和感受过这个世界某种程度上是由懒人推动的，生命在于懒惰，懒人创造世界。当然，懒惰也是真的傻傻的呆在 那里什么都不做，而是说要善于想出做事情的更好的方式，这样就可以节约大量的时间，也就有更多的机会懒惰了，同事也懒出了境界。在 Android 中如何懒 惰？《如何成为 Android 高手》一文就如何在 Android 中学会懒惰和朋友们进行了分享。

没搞错吧？竟然让程序开发人员学会懒惰？程序开发人员可能是世界上最为忙碌的一类人啦！对，没错，学会懒惰！正因为程序开发人员忙碌，正因为程序开发人员可能会在客户无限变化的需求之下没日没夜的加班，所以要学会懒惰，这样，你就可以把更多的时间浪费在美好的事物身上！

如何懒惰：

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 搜索引擎上搜索到很多优秀的程序代码。这样做并不是鼓励大家整天等着让别人为你编写代码，而是你可以 “ 站在伟人的肩 膀上 ” ，充分发扬 “ 拿来主义 ” ，聪明地应用别人的程序代码可以节省你大量的时间。

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 （别找我，我会来找你的）。

　　 2 ，精通 Android 体系架构、 MVC 、常见的设计 模式、控制反转（ IoC ）：这一点难吗？ “ 学之，则难者亦易矣；不学，则易者亦难矣。 ”

　　 3 ，编写可重用、可扩展、可维护、灵活性高的代码： Android 应用程序开发 的使用纯粹面向对象的 Java 作为开发语言，自然也就继承了关于 Java 关于面向对象的优秀想思想，如何做？《如何成为 Android 高手》一文就如何在 Android 中编写可重用、可扩展、可维护、灵活性高的代码和朋友们进行了分享。

　　 4 ，高效的编写高效的代码：高效的编写代码和编写高效的代码好像天生就是死敌。似乎开发速度上去了，程序的执行效率就下去了；程序的执行效率上去，开发速度就下去了。如何解决 二者的忙着，请听《如何成为 Android 高手》一文想大家娓娓道来。

　　 5 ，学会至少一门服务器端开发技术 ：没搞错吧，成为 Android 高手还需要学习 服务端开发技术？对，需要！《如何成为 Android 高手》一文就该问题和大家进行了分享。

　　 “ 蜀之鄙，有二僧：其一贫，其一富。贫者语于富者曰： " 吾欲之南海，何如？ " 富者曰： " 子何恃而往？ " 曰： " 吾一瓶一钵足矣。 " 富者曰： " 吾数年来欲 买舟而下，犹未能也。子何恃而往！ " 越明年，贫者自南海还，以告富者，富者有惭色。西蜀之去南海，不知几千里也，僧富者不能至，而贫者至之，人之立志，顾 不如蜀鄙之僧哉 ”

　　若立志成为 Android 高手，如有耐心， “ 一瓶一钵足矣 ” 。

Android 一出生就被打上了富二代的胎记，不仅仅是因为诞生于当今的网络 霸主 Google ，更主要还有一个空前强大和壮观的开放手机 联盟 OHA （ Open Handset Alliance ）提供全力的支持。 OHA 是什么？ OHA 涵盖了中国移动、 T-Mobile 、 Sprint 等移动运营商，包括 HTC 、 Motolora 、三星等手机制造商，有 Google 为代表的手机软件 商，还有 Inter 、 Nvidia 为标志的底层硬件厂商和 Astonishing Tribe 等商业运作公司，该组织声称组织的所有成员都会基于 Android 来开发新的手机业务。

　　但是，要成为 Android 高手并不是一件容易的事情。并不是很多人想象的能够飞快的写出几行漂亮的代码去解决一些困难的问题就是 Android 高手 了。真正的 Android 高手需要考虑的问题远远不是写些漂亮的代码就足够的。下面是成为一名真正的 Android 高手必须掌握和遵循的一些准则：

1 ，学会懒惰

2 ，精通 Android 体系架构、 MVC 、常见的设计模式、控制反转（ IoC ）

1 ，请看某个著名的 IT 公司一则招聘信息的其中一条要求： “ 熟悉 Android 系统架构及相关技术， 1 年以上实际 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 模式。
3 ，设计模式和 IoC( 控制反转 )

毫无疑问， Android 的之所以能够成为一个开放的气象万千的系统，与设计模式的精妙应用是分不开的，只要你稍微用心观察，就会发现在 Android 中到处都是 A 设计模式或者设计模式的联合运用，一下的设计模式是您想游刃有余的驾驭 Android 必须掌握的：

l Template Method 模式

l Factory Method 模式

l Observer 模式

l Abstract Factory 模式

l Adapter 模式

l Composite 模式

l Strategy 模式

l State 模式

l Proxy 模式

l Bridge 模式

l Iterator 模式

l Mediator 模式

l Façade 模式

Android 框架魅力的源泉在于 IoC ，在开发 Android 的过程中你会时刻感受到 IoC 带来的巨大方便，就拿 Activity 来说，下面的函数是框架调用自动调用的：

protected void onCreate(Bundle savedInstanceState) ；

不是程序编写者主动去调用，反而是用户写的代码被框架调用，这也就反转了！当然 IoC 本身的内涵远远不止这些，但是从这个例子中也可以窥视出 IoC 带来的 巨大好处。此类的例子在 Android 随处可见，例如说数据库的管理类，例如说 Android 中 SAX 的 Handler 的调用等。有时候，您甚至需要自己 编写简单的 IoC 实现，上面展示的多线程现在就是一个说明。

3 ，编写可重用、可扩展、可维护、灵活性高的代码

4 ，高效的编写高效的代码

5 ，学会至少一门服务器端开发技术

可能有朋友会问：学习 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 是为移动互联而生的，两者达到了完美的契合。

 

 

三：编写可重用、可扩展、可维护、灵活性高的代码

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 ，但是在一般的类中，你应该直接访问变量。

将成员变量缓存到本地

访问成员变量比访问本地变量慢得多，下面一段代码：

Java 代码

1 for (int i = 0; i < this.mCount; i++)   

2     dumpItem(this.mItems[i]);  


最好改成这样：

Java 代码

3 int count = this.mCount;   

4 Item[] items = this.mItems;   

5 for (int i = 0; i < count; i++)   

6     dumpItems(items[i]);  


（使用 "this" 是为了表明这些是成员变量）

另一个相似的原则是：永远不要在 for 的第二个条件中调用任何方法。如下面方法所示，在每次循环的时候都会调用 getCount() 方法，这样做比你在一个 int 先把结果保存起来开销大很多。

Java 代码

7 for (int i = 0; i < this.getCount(); i++)   

8     dumpItems(this.getItem(i));  


同样如果你要多次访问一个变量，也最好先为它建立一个本地变量，例如：

Java 代码

9 protected void drawHorizontalScrollBar(Canvas canvas, int width, int height) {   

10     if (isHorizontalScrollBarEnabled()) {   

11         int size = mScrollBar.getSize(false);   

12         if (size <= 0) {   

13             size = mScrollBarSize;   

14         }   

15         mScrollBar.setBounds(0, height - size, width, height);   

16         mScrollBar.setParams(computeHorizontalScrollRange(),computeHorizontalScrollOffset(),computeHorizontalScrollExtent(), false);   

17         mScrollBar.draw(canvas);   

18     }   

19 }  



这里有 4 次访问成员变量 mScrollBar ，如果将它缓存到本地， 4 次成员变量访问就会变成 4 次效率更高的栈变量访问。

另外就是方法的参数与本地变量的效率相同。

使用常量

让我们来看看这两段在类前面的声明：

Java 代码

20 static int intVal = 42;   

21 static String strVal = "Hello, world!";  


必以其会生成一个叫做 <clinit> 的初始化类的方法，当类第一次被使用的时候这个方法会被执行。方法会将 42 赋给 intVal ，然后把一个指向类中常量表的引用赋给 strVal 。当以后要用到这些值的时候，会在成员变量表中查找到他们。

下面我们做些改进，使用 “final" 关键字：

Java 代码

22 static final int intVal = 42;   

23 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 一种可接受的用法：

Java 代码

24 public class Foo {   

25     int mSplat;   

26     static Foo mArray[] = new Foo[27];   

27   

28     public static void zero() {   

29         int sum = 0;   

30         for (int i = 0; i < mArray.length; i++) {   

31             sum += mArray[i].mSplat;   

32         }   

33     }   

34   

35     public static void one() {   

36         int sum = 0;   

37         Foo[] localArray = mArray;   

38         int len = localArray.length;   

39         for (int i = 0; i < len; i++) {   

40         sum += localArray[i].mSplat;   

41         }   

42     }   

43   

44     public static void two() {   

45         int sum = 0;   

46         for (Foo a: mArray) {   

47             sum += a.mSplat;   

48         }   

49     }   

50 }  



在 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() 方法获取 枚举变量的整数值会更好一些，举例来说，将：

Java 代码

51 for (int n = 0; n < list.size(); n++) {   

52     if (list.items[n].e == MyEnum.VAL_X)// do stuff 1  

53     else if (list.items[n].e == MyEnum.VAL_Y)// do stuff 2  

54 }  



替换为 :

Java 代码

55 int valX = MyEnum.VAL_X.ordinal();   

56 int valY = MyEnum.VAL_Y.ordinal();   

57 int count = list.size();   

58 MyItem items = list.items();   

59 for (int n = 0; n < count; n++) {   

60     int valItem = items[n].e.ordinal();   

61     if (valItem == valX)// do stuff 1  

62     else if (valItem == valY)// do stuff 2  

63 }  



会使性能得到一些改善，但这并不是最终的解决 之道。

将与内部类一同使用的变量声明在包范围内

请看下面的类定义：

Java 代码

64 public class Foo {   

65     private int mValue;   

66     public void run() {   

67         Inner in = new Inner();   

68         mValue = 27;   

69         in.stuff();   

70     }   

71   

72     private void doStuff(int value) {   

73         System.out.println("Value is " + value);   

74     }   

75   

76     private class Inner {   

77         void stuff() {   

78             Foo.this.doStuff(Foo.this.mValue);   

79         }   

80     }   

81 }  



这其中的关键是，我们定义了一个内部类 (Foo$Inner) ，它需要访问外部类的私有域变量和函数。这是合法的，并且会打印出我们希望的结果 "Value is 27" 。

问题是在技术 上来讲（在幕后） Foo$Inner 是一个完全独立的类，它要直接访问 Foo 的私有成员是非法的。要跨越这个鸿沟，编译器需要生成一组方法：

Java 代码

82 static int Foo.access$100(Foo foo) {   

83     return foo.mValue;   

84 }   

85   

86 static void Foo.access$200(Foo foo, int value) {   

87     foo.doStuff(value);   

88 }  



内部类在每次访问 "mValue" 和 "doStuff" 方法时，都会调用这些静态方法。就是说，上面的代码说明了一个问题，你是在通过接口方法访问这些成 员变量和函数而不是直接调用它们。在前面我们已经说过，使用接口方法（ getter 、 setter ）比直接访问速度要慢。所以这个例子就是在特定语法下面 产生的一个 “ 隐性的 ” 性能障碍。

通过将内部类访问的变量和函数声明由私有范围改为包范围，我们可以避免这个问题。这样做可以让代码运行 更快，并且避免产生额外的静态方法。（遗憾的是，这些域和方法可以被同一个包内的其他类直接访问，这与经典的 OO 原则相违背。因此当你设计公共 API 的时候应该谨慎使用这条优化原则）

避免使用浮点数

在奔腾 CPU 出现之前，游戏 设计者做得最多的就是整数运算。随着奔腾的到来，浮点运算处理器成为了 CPU 内置的特性，浮点和整数配合使用，能够让你的游戏运行得更顺畅。通常在桌面电脑上，你可以随意的使用浮点运算。

但是非常遗憾，嵌入式处理器通常没有支持浮点运算的硬件，所有对 "float" 和 "double" 的运算都是通过软件 实现的。一些基本的浮点运算，甚至需要毫秒级的时间才能完成。

甚至是整数，一些芯片有对乘法的硬件支持而缺少对除法的支持。这种情况下，整数的除法和取模运算也是有软件来完成的。所以当你在使用哈希表或者做大量数学运算时一定要小心谨慎。 ”