Android应用开发以及设计思想深度剖析(2)

特别声明：本系列文章https://www.360docs.net/doc/d8358744.html,著作权所有，转载请注明出处。作者系https://www.360docs.net/doc/d8358744.html, 资深Android技术顾问吴赫老师。本系列文章交流与讨论:@宋宝华Barry

Android的系统设计，与别的智能手机操作系统有很大区别，甚至在以往的任何操作系统里，很难找到像Android这样进行全面地系统级创新的操作系统。从创新层面上来说，Android 编程上的思想和支持这种应用程序运行环境的系统，这种理念本身就是一种大胆的创新。整个Android系统，实际主要目的，就是打造一个功能共享的世界。

功能共享最重要的交互，于是Android创造出一种Intent和IntentFilter配合的低耦合的交互模型，Intent只是一种描述要完成什么工作跨进程的结构体，而最终如何解析这些Intent 并完成其响应，是由IntentFilter来进行换算，最终是由用户来决定如何完成。

而在Intent这种超级交互消息之上，Android进一步把应用程序的实现逻辑拆分成多种特殊的实现：

T Activity：带显示与交互能力的部分

T Service：不带显示与交互能力的部分

T Content Provider：在功能交互之外，提供数据交互能力的部分

T Broadcast Receiver：用来处理广播交互的部分

这四种功能上的拆分，也体现了Android设计者在设计上抽象思绪能力，即便是随着Android 迅猛发展，目前已经到了4.1这么功能丰富、用户体验良好的状态，我们编程也还是与这四种功能组件打交道，可以满足我们任何的编程时所需要的任何行为。

而这四种基本组件组成部分，使Android应用程序反倒成了一个―空壳子‖。静态上看，应用程序只是一种包装这些功能的容器；从运行态来看，所谓的应用程序，也只是承载某些功能的进程。

1.1 所谓的Android应用程序

我们从前面的例子中看到，无论是编写的代码，还是最后生成的.apk文件，都是没有所谓的应用程序的。应用程序本身是一种虚无的概念，只是一种以zip格式进行压缩的一个文件，一种容器而已。

如我们前面的Helloworld的例子里所看到的那样，其实一个应用程序里最重要的一个配置文件就是AndroidManifest.xml文件。一个最简单的项目，除了基本的代码与UI资源，也会需要有个AndroidManifest.xml文件。甚至一些极端一点的例子，我们去市场上下载一些

什么主题包、插件包、权限包之类的.apk文件，解压开，这时可以发现这样的.apk文件里，连代码都没有，只有一些图片之类的文件。

于是，我们可以得到Android里关于应用程序的第一个印象，作为Android应用程序的载体，.apk文件只是一种进行包装与传输的格式，而每个.apk文件必然包含一个AndroidManifest.xml文件，由这一文件来描述该.apk文件提供的内容。当然，我们在稍后会看到，这一文件里，还会包含一些权限控制的信息。

我们可以给我们的应用程序创建两个一模一样的图形界面，直接从我们的前面的HelloWorld 开始下手，比如将HelloWorld.java在Eclipse里拷贝到HelloAgain.java（这样可以减少改代码的麻烦）。这时可以得到两个界面的应用程序，然后我们再把我们的AndoridManifest.xml文件，改成如下的样子：

package="org.lianlab.hello"

android:versionCode="1"

android:versionName="1.0">

android:label="@string/app_name">

android:label="@string/app_name">

这时我们编译、安装到Android设备（或者是虚拟机）里，这时再打开主界面查看安装过的应用程序，这时是不是发生了什么很奇怪的现象？这时界面上会出现两个叫Helloworld的应用程序。我们这时如果在设备里去―设置‖à ―应用程序‖，我们仍只看到一个应用程序。

通过对AndroidManifest.xml的小恶作剧，我们可以看到Android应用程序的第二个特点，就是没有所谓的主入口（即我们点击的图标时触发的执行效果）。应用程序在安装完成后，只是通过AndroidManifest.xml来决定在系统上应该表现成什么样子。

如果希望应用程序可以表现不如此变态，这时，我们可以回到AndroidManifest.xml里，把标签删掉，这时应用程序的表现就正常了。

到目前为止，我们就已经接触了android编程里的两个概念，一个是Activity，另一个是Intent （而我们AndroidManifest.xml文件里的Intent Filter实际是辅助Intent的）。Android毕竟是种图形界面的编程环境，我们常见的应用程序里，可能绝大部分只会与这两种概念打交道。而两者的概念组合，就很容易体现出Android应用程序在编程上的―无界化‖思想。

1.2 Android世界里的共享

作为一个智能手机操作系统，其用户可能在功能上有各种各样的功能组合。比如最简单的打电话，则后续动作会有保存联系人，同时需要给联系人拍照做来电大头贴。又比如需要来了个短信通信用户到某个地方干什么事情，这时，用户需要打开地图，搜索一下地址，然后还有可能需要定位到那个位置。

用户在主界面里点击相应功能的应用程序之后，就可能有非常多的功能性的组合，因为用户的想法是不可预估的。我们当然也可以限制用户当前菜单下可以干什么事情，但这样就失去了智能系统的意义。

我们也可以假设用户都会按一个―Home‖键回到主界面，这时原来的执行的程序就会被锁定当前状态，用户重新打开另外一个应用程序，操作完再按―Home‖键可以退回到原来的应用程序。通过这种―应用程序‖到―Home‖到―应用程序‖的循环，我们也可以达到我们想要达到的目的。但这时，出于交互性的考虑，我们也还是需要有限地提供一些交互手段，比如―短信‖应用程序里包含地址信息，一点击可以直接打开―地图‖进行后续操作，但这些有限交互是可以在系统设计阶段被固化。这时，我们是不是就得到了我们想要的能够应付用户任何操作组合的系统？是的，恭喜您，您得到了iPhone的设计思路。但此时的用户交互流程则被改变成这个样子：

这种解决问题的办法也不是不可以，但需要很固化的设计，应用程序的行为比较受限。虽然通过横扫全世界的iPhone证明了这样的设计可能是比较合乎用户体验之道的（不容易出错），但这样的解决思路从系统设计角度来看，并不是很灵活。另外一个麻烦是必须要有苹果级设计功底的―Home‖键，山寨货则用不了多久就会因为键盘失灵而失效。当然即使苹果级设计，iPhone里的―Home‖键还是会失效，于是又不得不在屏幕上加上触摸的Home手势。

作为开源系统的Android，当然不可能基于iOS的交互思路来解决问题，何这种交互时多了一步不停要回到主界面这一步。在Android的设计里，最重要的是能够解决一个应用程序之间进行交互的问题，然后可以实现我们想要在Android系统里完成某种操作时，可以享受从一路顺畅完成的快感。

Android的解决之道，则是将传统意义上的应用程序，细化成一个个完成某项功能的部分，这种功能部分，在Android世界里被称为Activity。Activity都应该被设计成可以独立地被执行以解决某个问题，当它完成或是用户选择退出执行时，又会自动跳回到调用这一Activity

的界面，当然这时跳回的位置肯定是另外一个Activity。当然，在一个Android系统里有可

能存在无限多的Activity，在他们进行跳转切换时，我们就需要一种很灵活的消息传输机制（因为我们必须兼容系统里所有可能的互相调用的情况）。而且这种传输机制还必须能够跨进程，不然，我们所有的涉及Activity互相调用部分都必须在同一进程里完成。于是，Android 系统里又有了Intent，用于解决交互通信。

这样的编程模型也需要有一定前提，那就是我们Application概念必须被弱化，我们不能有main函数入口（如果系统执行依赖main作入口，则不能实现Activity之间互相调用了，所有的Activity执行之前，必须先通过main入口来初始化环境）。出于这样的设计，所以Application必须只是一个容器，将各种不同的Activity实现包装起来加载到系统里。

当然，将功能拆分成一个个的单一功能界面之后，我们需要有种机制可以将用户一路点击过去历史记录下来，当用户处理完时，可以退回到他们之前操作过的界面，这次就可以由多个应用程序组合出像是在用同一个应用程序的效果。有了Activity，有了Activity之间起到调用作用的Intent，这时所有界面间操作变得有点像是函数调用一样，于是我们可以找函数调用时的基本数据结构—栈来帮忙，发生调用时，需要退出的Activity及其状态压栈，当从调用退出时则进行栈的弹出操作，这时我们的Activity管理就演变成如下图所示的简单栈管理。

有了这样的概念，于是我们响应用户点击操作的问题便迎刃而解，我们在设计应用程序时，不再是设计一个复杂的功能实现，而是实现一组完成单项功能的实现，也就是Activity。然后这些Activity，只会通过用户点击来驱动它们之间是如何进行交互的。比如，我们前面看到的地图、搜索、定位三个功能，虽然它都会被包装到同一个地图的应用程序里，但在实现上会是地图、搜索、定位三个不同的Activity。

因为现在我们的界面上的互相调用，已经变成了一种函数式的调用，这样，整个手机上的功能都被切分成各个单一的小功能，而真正要在Android系统上完整地实现某复杂个操作，则会提交由用户的点击来组合生成。这样的复杂功能，则已经不是一个编程上的概念了，在

Android系统里，这种需要完成什么事情的操作被抽象成一个虚拟的概念Task。比如我们前面提到的打电话加拍大头贴的操作组合，就构成一个Task，这一Task需要由Launcher.apk，Contacts.apk，Gallery.apk来协同完成。

如果我们有两个能够提供同样功能的Activity，这种执行模式的灵活性表现得会更加明显。比如中间打电话的功能，我们系统里有三个Activit（CallScreen, SipPhone, Dialer）都可以完成电话呼叫的功能，这时执行上的路径则会有三种可能性，会在进行跳转时弹出圣对话框由用户来选择：

通过Activity的这种可以动态被用户选择的特点，当用户对某一功能不满意时，完全就有可能通过下载另一个能实现这种功能的应用程序进行替换，甚至可以自己写一个。事实上，Android系统里除了系统状态条与锁屏界面之后，没有任何的不可被替换的功能，这也是Android设备总是会长得千奇百怪的原因之一。

到这时，我们就可以看到Activity之所以会不被称为Window的原因，它也是单个界面或是MVC里的Controller实现部分那么简单，Activity这个名字代表的是某种单一交互功能上的实现。这种功能的实现将在系统里通过Intent串接起来，构成了一个在功能上具备极大可拓展性的系统。基于这样的特点，Android也就被称作是―无边界‖系统，因为它在功能上延展不再受限于系统的能力，而只受限于智商与创意。

这就是Android世界里的功能共享。

在这种功能共享模型之下，可能还是会有一些微调的需求：

1. 我们有一些情况下不宜使用这种栈式Activity管理，比如我们写一个需要注册的应用程序，注册完开始使用，然后再按退出，我们又会一步步退回到注册填个人信息的界面，

在AndroidManifest.xml里面定义很简单，就是通过指定Intent对象的Action，Data，Type，和Category这四个成员变量来指定。比如：

android:configChanges="orientation" >

...

当我们的某个Activity，发送了一个Intent，其Action是‖android.intent.action.VIEW‖，data 又是以file:///开始的URI指定的内容（也就是文件类型），这时上面例子里的PlayerActivity 就会成为播放时的候选项。

我们可以继续修改我们前面的HelloWorld的例子，我们新建一个Intent，将Action设

成‖android.intent.action.VIEW‖（可以通过Intent.ACTION_VIEW这个预变量来转义），data 使用某个文件―file:///sd-ext/Movies/test.mp4‖，这时就会匹配到我们上面的定义：

public void onClick(Viewv) {

Intent request = new Intent(Intent.ACTION_VIEW);

request.putData(―file:///sd-ext/Movies/test.mp4‖);

startActivity(request);

finish();

}

当然，我们并不一定需要代码来进行这样的测试，我们也可以使用设备上的am命令来完成。要完成与上面的点击操作一样的功能，也可以通过adb来执行这条命令：

$adb shell am start –aandroid.intent.action.VIEW –d file:///sd-ext/Movies/test.mp4

在我们具体写代码过程中，我们可以根据需求来定义我们所需要的，可以将过滤规则写得很细，也可以写得很粗，让我们的Activity有更多地被执行到的机会。在这些规则里，可能最重要的规则，就是我们前面也示范过的：

这两行规则，将使用我们的应用程序可以被主界面所收集，使用户可以在主界面里点击运行这个Activity。

有了Activity，我们就可以构建基于功能共享而实现所谓应用程序，而有了Intent，使用我们在共享时所受的限制可以变得更小。而且，由于是简单化的单窗口模式，再加上一些在性能设计上的精细设计，于是我们的Android系统便有了良好的人机交互体验。

1.4 编程角度的应用程序

光有Activity与Intent，并不是Android应用程序编程时的全部。应用程序除了有人机交互界面之外，有可能还需要使用到一些不直接与人交互而在后台长期运行操作；我们还需要有某种机制，能够提供数据共享，并且在数据共享时能使用统一的访问机制；最后，我们可能还需要处理以广播方式发送的消息，广播与Intent不同之处在于一到多的方式传播，同时消息只在某个时间段内有效。

事实上，我们的Android编程，是被包装成四个不同的类型，同时通过Intent将这些类包装起来，以解决我们上面提到的，在编写图形应用程序里可能遇到的问题的：

l Intent: 全局性的、松散的消息传递机制

l Activity：带图形界面的，可以与用户进行交互的逻辑实现。

l Service: 不带图形界面的，不直接与用户交互的代码。一般会被用于在后台做些什么事情，比如监听网络、下载、拷贝文件等。（这可能是一般的Android工程师觉得没有必要实现的部分，笔者在讲解Android应用程序相关的课程时，就常有问及，Actiivity会进入到后台，然后有可能被杀死掉，这样的问题如何解决？实际上Activity只解决交互，需要在后台时还需要继续执行的代码，需要用Service来实现。只自己可访问的Service，可以使用简单的本地Service，而需要提供给别的进程来访问的情况下，我们需要通过AIDL编写Remote Service。Service的实现，我们在后台再详细说明，因为Android系统的核心Framework，本身就是由大量这样的Remove Service来组成的。）

l Content Provider: 提供数据层共享，以CRUD(Create Read Update Delete)方式进行数据访问来统一化数据读写指口一种模型。如果使用了Sqlite做后台的数据支持（实际上相当于应用程序MVC模型里的Model部分被Sqlite延展开来），我们可以通过ContentProvider 来各系统内的其他部分提供数据源，当然系统本身也给我们提供了大量这样的ContentProvider，像Setting里的设置的值、联系列表、多媒体文件扫描结果等。（这种数据层上的共享机制，也是应用程序编程上需要加强的技巧之一，因为有了Content Provider，我们则有可能使用Cursor式进行访问，这时我们就可以使用CursorAdapter来自动化地处理数据源。）

l Broadcast Receiver：处理广播类消息的监听器，从而可以给应用程序提供广播式的信息处理，同时也提供系统消息的广播式分发。比如，Android会将一些系统事件广播出来，像电话振铃、电量状态变化、网络状态变化等，我们需要能够处理这样的事件，电话振铃时

我们写的多媒体播放器就应该静音、电量过低时需要保存状态等。对我们应用程序而言，广播方式也是一种很好的通信机制，我们不需要写一个循环通知所有的Activity、Service我们状态发生了改变，而只需要发一个广播，则所有关心这一事件的部分都可以收到。

这些功能实体，都是我们通过Java代码根据不同的基类（Service、ContentProvider、BroadcastReceiver）派生出相应的子类，再加以具体实现。这样的功能实现不需要自己去创建这个对象，会通过AndroidManifest.xml里的定义，由系统按执行的需要自动创建。有了这些不同的功能实体，我们最后的应用程序，实际上就成了这个样子：

而我们的所有代码，从运行态行为来看，都不再是直接的互相调用关系，而是全部都通过Intent来进行彼此之间的交互。而这样的交互，也不再是传统式地自己陪自己玩，而是会进入到一个大的功能集合体时，提供功能给系统内其他应用程序所使用，而自己也会调用其他部分的代码。

当然，随着Android版本变更，Android系统又新增了一些新的概念，比如针对多窗口功能的Fragment、针对于使用异步机制操作Cursor的Loader等。但万变不离其宗，这些Android 的核心原理则一直如此。

总结一下Android编程思想，我们就会知道其实在Android整个生态环境最重要的元素，应用程序，反倒是Android编程上最不重要的。所谓的Android编程，就是要通过编写一个个的Activity、Service、Content Provider、Broadcast Receiver实现，通过功能上的共享与数据上的共享进一步丰富用户可用的功能。当用户可以通过Market或自己下载取得我们封装到.apk文件里的实现之后，这些功能就会无缝地被Intent整合到了一起。

从Android这个编程原则来看，我们可以看到，如果我们使用某种Java执行环境，将Android 应用程序的这些组成部分的支持都加入进来，我们也可以得到一个Android兼容的环境。的确如此，已经有人在打这方面的主意，有将Android环境移植到Windows环境里的BlueStack商业解决方案，也有号称兼容Android应用程序，通过一个类似于JAVA ME的

虚拟机环境来支持Android应用程序的BlackBerryOS。但我们可以再来看看Android的真正的支持环境，我们可以看到，Android有其独特的特性，也不是那么容易被取代。