Toolbox/philosophy

From Android中文网

Android中文网(androidcn.net) 版权申明 : creativecommons licenses
Jump to: navigation, search

目录

[编辑] 设计思想

学习如何在一个新的API上创建应用的过程都是类似的,即便平台本身存在很大差异性。通常,有两个步骤:首先,你学习如何使用API来做你想做的事情;然后,你学习平台的细微差别。还句话说,你首先要学习如何才能够构建应用,然后再学习应该如何来构建它们。

第二个步骤——学习如何正确构建应用——通常需要花费更长的时间,并且通常意味着犯错误并从错误中学习。那不是一个高效率的过程,所以本页和下面的链接就是立足于为你提供相关帮助。

在我们开始之前,还要简短说几句。成功地应用会提供出色的终端用户体验。尽管Android团队已经构造了一个强健的内核系统,但用户更多的体验是来自于与你应用的交互。因此,我们鼓励你花时间来构造出色的用户体验。

出色的用户体验有三个特征:速度快;响应及时以及无缝。当然从早期计算机到现在的计算机,每个平台都曾不只一次地引用过这三个特征。然而,每个平台实现它们的方法不同;下面的信息解释了你的应用如何能够在Android上实现这些特征。

[编辑] 速度快

Android应用应该是快速的。更准确的说他应该是高效的。现在,在计算界中有一个趋势,该趋势假设摩尔定律可以最终解决所有问题。然而对于嵌入式应用而言,Moor定律会变得有些复杂。

摩尔定律没有如同应用于桌面和服务器应用一样真正地应用于移动设备。摩尔定律实际上是关于晶体管密度的定律,它是说每隔一段时间后,你可以在给定的芯片上部署更多电路。对于转面和服务器应用而言,由于性能的提高,这意味着你可以在一块差不多大小的芯片中得到更高的速度。对于类似手机这样的嵌入式应用而言,摩尔定律通常被用于造出更小的芯片。在嵌入式界的趋势是利用这种晶体管密度的增加来造出更小、更节能的芯片,从而使手机更小,电池待机时间更长。象手机这样的嵌入式设备在不断增加,速度远远要慢于桌面系统。对于嵌入式设备而言,摩尔定律意味着更多特性和更好的电池寿命;而速度则是次要因素。

这就是为什么需要写高效的代码:你不能假设手机与桌面系统和服务器一样提速。一般来讲,写快速的代码意味着要是内存分配最小化,代码紧凑,并且避免可能影响性能的语言和编程习惯。在面向对象的术语中,很多类似情况都是发生在方法级,关于实际的代码顺序,循环等。

关于如何写高效的Android代码的文章将会给你提供写快速、高效Android代码的所有信息。

[编辑] 响应及时

你可以写出通过世界上所有性能测试的代码,但是当用户使用它时还是会感到恼火。这就是那些无法及时响应的应用 ——在特定阶段它们会变慢、挂起乃至冻结,或者需要用户等太久才来处理输入。在Android的术语中,不能及时响应的应用会频繁地导致系统弹出“应用没有响应”(ANR)消息。

通常,这种情况发生在你的应用无法响应用户输入时。例如,如果你的应用在一些I/O操作上阻塞了(通常是网络访问),那么应用主线程就无法处理用户的输入事件。一段时间以后,系统会判定你的应用挂起了,并且可以让用户终止它。类似地,如果你的应用在构建一个内存结构或者在计算下一步如何走时花费了太长时间,那么系统也会判定你的程序挂起了。确认计算过程才用了提高效率的技巧是十分重要的,尽管如此,在高效的代码也是需要花时间来运行的。

在这两个例子中,修补方法通常是创建一个子线程,在那里做大部分的工作。这能保持主线程(驱动用户界面抡询的进程)运行,并且防止系统认为你的代码冻结了。由于这种线程通常在class以及完成,你可以把响应问题作为一个class问题。(这一点主要是与基本性能的对比,基本性能主要与方法层面有关)

关于如何构造快速响应的Android应用的文章对此作了更详细的描述。

[编辑] 无缝

即便你的应用速度快并且响应及时,它还可能会惹恼用户。一个一般的例子就是在响应一些时间时弹出UI的背景进程(比如Android Service或者IntentReceiver)。这开起来好像无害,程序员通常认为他们花了大量的实际测试和使用自己的应用,感觉还不错。然而,Android应用模型是明确地为用户在不同进程中任意切换而构造的。这意味着,当你的背景进程弹出UI时,用户可能正在系统其他部分中,做着其他的事情——比如接电话。设想一下如果SMS服务每次收到一个消息时都弹出对话框,马上就会惹恼用户。这就是为什么Android标准对这种事件使用Notification;这样就可以让用户来控制。

这只是一个例子,还有很多例子。例如,如果Activities没有在onPause()或其他方法中正确实现,就会经常导致数据丢失。或者,如果你的应用要把数据暴露给其他应用使用,你应该通过ContentProvider,而不是直接使用全局刻度的原始文件或者数据库。

这写例子的共同之处在于,它们都涉及与系统和其他应用的友好协作。Android系统涉及为将应用看作松散耦合的组件联盟,而不是一堆黑箱代码。这允许作为开发者的你把整个系统看作是更大的组件联盟。这可以允许你整洁、无缝地将你的应用于其他应用集成,并且作为这种好处的回报,你可以自己设计代码。

这是一个组件级概念(与性能和响应性的类和方法级概念相对)。关于如何与Android系统集成的文章提供了写与系统其他部分友好协作代码的小贴士和最佳实践。

Personal tools