24
如何成为Android高手第三篇
避免建立对象 世界上没有免费的对象。虽然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代码 [...]
24
如何成为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()快。所以不要寄希望于编译器可以拯救你的程序。
24
如何成为Android高手第一篇
若立志成为Android高手，如有耐心，“一瓶一钵足矣”。 “天下事有难易乎？为之，则难者亦易矣；不为，则易者亦难矣。人之为学有难易乎？学之，则难者亦易矣；不学，则易者亦难矣。”想成为Android高手？这可不是想象中写几行代码那么容易的事情，但也不是不可实现。 如何做？ 1，学会懒惰！奇怪吧？但是，你一定也听说过和感受过这个世界某种程度上是由懒人推动的，生命在于懒惰，懒人创造世界。当然，懒惰也是真的傻傻的呆在那里什么都不做，而是说要善于想出做事情的更好的方式，这样就可以节约大量的时间，也就有更多的机会懒惰了，同事也懒出了境界。在Android中如何懒惰？《如何成为Android高手》一文就如何在Android中学会懒惰和朋友们进行了分享。 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） 3，编写可重用、可扩展、可维护、灵活性高的代码 4，高效的编写高效的代码 5，学会至少一门服务器端开发技术 一：学会懒惰 没搞错吧？竟然让程序开发人员学会懒惰？程序开发人员可能是世界上最为忙碌的一类人啦！对，没错，学会懒惰！正因为程序开发人员忙碌，正因为程序开发人员可能会在客户无限变化的需求之下没日没夜的加班，所以要学会懒惰，这样，你就可以把更多的时间浪费在美好的事物身上！ 如何懒惰： 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 [...]
25
The Froyo Code Drop
[This post is by Jean-Baptiste Queru, who moves truck-loads of source code in and out of the Googleplex. — Tim Bray] Today is one of those days that has my heart racing; we’ve just released the source code for Android 2.2. This is a big step forward for the entire Android ecosystem. Please don’t melt [...]
25
Android Market Problem
Earlier today we had a brief outage in Android Market. For a period of about thirty minutes, some users were unable to find any apps. The problem was detected and corrected, and we believe the user experience is now back to normal. We apologize for the outage.
25
Exercising Our Remote Application Removal Feature
[This post is by Rich Cannings, Android Security Lead. — Tim Bray] Every now and then, we remove applications from Android Market due to violations of our Android Market Developer Distribution Agreement or Content Policy. In cases where users may have installed a malicious application that poses a threat, we’ve also developed technologies and processes [...]
24
Hands-on at OSCON
This year at OSCON we and O’Reilly are co-presenting Android Hands-on. The event is on the evening of Wednesday, July 21 after the Expo-hall reception. Led by Google Android experts, the Hands-on will run from 7:00 pm-10:00 pm, and will be intense, technical, and structured. The goal is that you leave the room with foundation [...]
22
Future-Proofing Your App
[This post is by Reto Meier AKA @retomeier, who wrote the book on Android App development. — Tim Bray] As a developer, I’m excited by Android’s potential as a single development platform that can make my apps available on a wide range of devices. From smartphones to televisions, Android is now being used on an [...]
16
Game Development for Android: A Quick Primer
[This post is by Chris Pruett, an outward-facing Androider who focuses on the world of games. — Tim Bray] If you attended Google I/O this year, you might have noticed the large number of game developers showing off their stuff in the Android part of the Developer Sandbox. Unity, EA, Com2Us, Polarbit, Laminar Research, and [...]
13
Blogging Round the World
It seems that once or twice a week, I run across an Android-developer-oriented site that I hadn’t previously noticed. There are already a few aggregators and directories, and I think we’re going to need more. But for the moment, here are three pieces of bloggy Android goodness, from Florida, Odessa (Ukraine!), and Sydney. What they [...]