若立志成为Android高手,如有耐心,“一瓶一钵足矣”。 1,学会懒惰!奇怪吧?但是,你一定也听说过和感受过这个世界某种程度上是由懒人推动的,生命在于懒惰,懒人创造世界。当然,懒惰也是真的傻傻的呆在那里什么都不做,而是说要善于想出做事情的更好的方式,这样就可以节约大量的时间,也就有更多的机会懒惰了,同事也懒出了境界。在Android中如何懒惰?《如何成为Android高手》一文就如何在Android中学会懒惰和朋友们进行了分享。 2,精通Android体系架构、MVC、常见的设计模式、控制反转(IoC):这一点难吗?“学之,则难者亦易矣;不学,则易者亦难矣。”
一:学会懒惰 没搞错吧?竟然让程序开发人员学会懒惰?程序开发人员可能是世界上最为忙碌的一类人啦!对,没错,学会懒惰!正因为程序开发人员忙碌,正因为程序开发 人 员可能会在客户无限变化的需求之下没日没夜的加班,所以要学会懒惰,这样,你就可以把更多的时间浪费在美好的事物身上! “轮子理论”,也即“不要重复发明轮子”,这是西方国家的一句谚语,原话是:Don't Reinvent the Wheel。“不要重复发明轮子 ”意思是企业中任何一项工作实际上都有人做过,我们所需要做的就是找到做过这件事情的人。拿到软件领域中就是指有的项目或功能,别人已经做过,我们需要用的时候,直接拿来用即可,而不要重新制造。 2,Inventing the Wheel(发明轮子)。 二:精通Android体系架构、MVC、常见的设计模式、控制反转(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()快。所以不要寄希望于编译器可以拯救你的程序。 避免建立对象
哪个更好呢?
(使用"this"是为了表明这些是成员变量)
同样如果你要多次访问一个变量,也最好先为它建立一个本地变量,例如:
这里有4次访问成员变量mScrollBar,如果将它缓存到本地,4次成员变量访问就会变成4次效率更高的栈变量访问。 另外就是方法的参数与本地变量的效率相同。 使用常量 让我们来看看这两段在类前面的声明
必以其会生成一个叫做<clinit>的初始化类的方法,当类第一次被使用的时候这个方法会被执行。方法会将42赋给intVal,然后把一个指向类中常量表的引用赋给strVal。当以后要用到这些值的时候,会在成员变量表中查找到他们。 下面我们做些改进,使用“final"关键字:
现在,类不再需要<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一种可接受的用法:
在zero()中,每次循环都会访问两次静态成员变量,取得一次数组的长度。
替换为:
会使性能得到一些改善,但这并不是最终的解决之道。 将与内部类一同使用的变量声明在包范围内 请看下面的类定义:
这其中的关键是,我们定义了一个内部类(Foo$Inner),它需要访问外部类的私有域变量和函数。这是合法的,并且会打印出我们希望的结果"Value is 27"。 问题是在技术上来讲(在幕后)Foo$Inner是一个完全独立的类,它要直接访问Foo的私有成员是非法的。要跨越这个鸿沟,编译器需要生成一组方法:
通过将内部类访问的变量和函数声明由私有范围改为包范围,我们可以避免这个问题。这样做可以让代码运行更快,并且避免产生额外的静态方法。(遗憾的是,这些域和方法可以被同一个包内的其他类直接访问,这与经典的OO原则相违背。因此当你设计公共API的时候应该谨慎使用这条优化原则) 避免使用浮点数 在奔腾CPU出现之前,游戏设计者做得最多的就是整数运算。随着奔腾的到来,浮点运算处理器成为了CPU内置的特性,浮点和整数配合使用,能够让你的游戏运行得更顺畅。通常在桌面电脑上,你可以随意的使用浮点运算。 但是非常遗憾,嵌入式处理器通常没有支持浮点运算的硬件,所有对"float"和"double"的运算都是通过软件实现的。一些基本的浮点运算,甚至需要毫秒级的时间才能完成。 甚至是整数,一些芯片有对乘法的硬件支持而缺少对除法的支持。这种情况下,整数的除法和取模运算也是有软件来完成的。所以当你在使用哈希表或者做大量数学运算时一定要小心谨慎。 ” 五,学会至少一门服务器端开发技术 |
|