|
|
知识路径： > 电子商务系统程序设计基础 > 电子商务平台开发基础 > 移动端开发平台技术及其结构 > 移动端开发平台技术及其结构 >
|
被考次数：1次
被考频率：低频率
总体答错率：31%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：4个
|
|
|
|
|
|
|
Android是一个以Linux为基础的开源移动设备操作系统，主要用于智能手机和平板电脑，由Google成立的Open Handset Alliance（OHA，开放手持设备联盟）持续领导与开发中。
|
|
|
|
|
|
基于Linux内核操作系统，Android系统对Linux内核进行了加强。其系统架构如下图所示，采用了分层架构思想，从上到下分为4层，分别为Application（应用层）、Application Framework（应用框架层）、Libraries and Android Runtime（系统库及Android运行时，系统运行库层）和Linux Kernel（Linux内核层），各层采用Software Stack（软件栈）的方式进行构建。
|
|
|
|
|
|
|
|
（1）Android应用层。Android应用层提供的服务即我们常说的应用，它是与用户直接交互的。所有的应用程序（包括原生和第三方）都在应用层上进行构建，如系统自带的日历、通话、短信、浏览器等以及在Android应用商店中下载的游戏、音乐软件等；应用层运行在Android运行时内，并且使用了应用程序框架的类和服务。
|
|
|
|
（2）Android应用框架层。Android应用框架层提供了开发Android应用程序所需的一系列类库，通常是系统API接口，使开发人员可以方便、快速地构建应用整体框架，其具体的模块内容及功能如下：
|
|
|
|
①Activity Manager（活动管理器）。管理各个应用程序活动窗口并为窗口提供交互的接口。
|
|
|
|
②Window Manager（窗口管理器）。管理所有开启的窗口程序。
|
|
|
|
③Content Provider（内容提供者）。提供应用内或应用程序间数据共享功能。
|
|
|
|
④View System（视图）。创建应用程序基本视图组件，如ListView、TextView、WebView等控件。
|
|
|
|
⑤Notification Manager（通知管理器）。用户可以自定义状态栏中的提示信息。
|
|
|
|
⑥Package Manager（包管理器）。应用程序安装进手机后，以包名作为文件夹名进行存储，此API提供诸如应用程序的安装与卸载功能以及提示相关的权限信息。
|
|
|
|
⑦Resource Manager（资源管理器）。提供图片、音视频等非代码资源。
|
|
|
|
⑧Location Manager（位置管理器）。提供位置信息服务。
|
|
|
|
⑨Telephony Manager（电话管理器）。管理所有移动设备功能。
|
|
|
|
|
|
（3）Android系统运行库层。Android系统运行时库层包含两部分内容，一个是系统库，一个是Android运行时。
|
|
|
|
系统库提供了系统功能通过Android应用程序框架层为开发者提供服务，其类库的主要内容包含各种C/C++核心库（如Libc和SSL）、支持音频视频的多媒体库、用于本地数据库支持的SQLite、2D/3D图形处理引擎、外观管理器、数据传输服务（WebKit、SSL）等。另外，Android NDK（Android Native Development Kit，Android原生库）也为开发者提供了直接使用Android系统资源的能力。
|
|
|
|
Android运行时包含核心库与Dalvik虚拟机两部分：
|
|
|
|
①核心库提供了Java SE API的绝大多数功能，并提供Android的核心API，如android.os、android.net、android.util、android.meida等。
|
|
|
|
②Dalvik虚拟机是基于Apache的Java虚拟机，被改进以适应低内存、低处理速度的移动设备环境，负责运行Android应用程序，提供实现进程隔离与线程调试管理、安全和异常管理、垃圾回收等重要功能。
|
|
|
|
（4）Android Linux内核层。Android Linux内核层作为系统架构的最底层借助Linux内核服务实现硬件设备驱动，从而为上层提供诸如进程与内存管理、网络协议栈、电源管理以及驱动程序等功能，同时Linux内核也是硬件与软件之间的抽象层（Hardware Abstract Layer，HAL），它是对硬件设备具体实现的抽象，这样程序开发人员就无须考虑系统底部的实现细节，提高了开发效率。
|
|
|
|
|
|
Android应用程序是由一些松散的组件构成，每个应用程序中都会包含一个配置文件AndroidManifest.xml，主要描述应用程序中所用到的各组件及其相互关系，还包括硬件要求、权限声明等。Android应用程序各组件之间可以调用相互独立的基本功能模块，其中根据功能的不同，可以划分为四类不同的组件，即：
|
|
|
|
|
|
②Service（服务）。后台运行服务，不提供界面呈现。
|
|
|
|
③BroadcastReceiver（广播接收器）。用于接收广播。
|
|
|
|
④ContentProvider（内容提供者）。支持在多个应用中存储和读取数据，相当于数据库。
|
|
|
|
各组件之间是通过Intent来实现消息传递，Intent可以理解为不同组件通信的媒介或者信使。Intent可以启动或停止一个Activity或Service，还可以发起一个广播Broadcast，Android系统中大量使用了Intent，在实际的应用程序开发中也会频繁使用Intent传递信息。
|
|
|
|
（1）Activity（活动）。是Android应用程序核心组件中最基本的一种，也是最常见的组件，是用户和应用程序交互的窗口。通常一个Android应用程序由一个或多个Activity组成，多个Activity之间可以进行相互跳转，例如按下一个Button按钮后，可能会跳转到其他的Activity。与Web网页跳转不同的是，Activity之间的跳转可以有返回值，例如从Activity A跳转到Activity B，那么当Activity B运行结束的时候，有可能会给Activity A一个返回值，这样做在很多时候是非常方便。虽然Android应用程序有多个Activity组成，但是其中却只有一个主Activity。
|
|
|
|
（2）Service（服务）。是一种类似Activity但没有用户界面的组件，运行在后台，相当于操作系统中的一个服务，并且可以和其他组件进行交互。Service也是一种程序，是没有界面的长生命周期的代码，它可以运行很长时间，例如打开一个音乐播放器的程序，这个时候若想上网，再打开一个Android浏览器，歌曲播放并没有停止，而是在后台继续播放，就是由播放音乐的Service进行控制。
|
|
|
|
（3）BroadcastReceiver（广播接收器）。是一种全局监听器，用来接收来自系统或其他应用程序的广播。并作出回应，在Android系统中，当有特定的事件发生时就会产生相应的广播，并通过NotificationManager来通知用户有事件发生。
|
|
|
|
（4）ContentProvider（内容提供者）。主要是实现在不同应用程序之间数据的共享与交换，使得其他应用可以对自身的数据进行增、删、改、查操作（通常结合SQLite使用）。由于Android中的文件、数据库在系统内都是私有的，仅允许被特定的应用程序直接使用，所以ContentProvider类实现了一组标准方法的接口，从而能让其他的应用程序读取或保存ContentProvider提供的各类数据。Android系统使用了许多ContentProvider，例如：联系人资料、通话记录、短信、相册等，一般这些数据都存放于不同的数据库中。
|
|
|
|
|
|
Android开发的常用框架分别为MVC（Model-View-Controller）框架、MVP（Model-View-Presenter）框架和MVVM（Model-View-ViewModel）框架，目前Google主推MVVM开发框架模式。MVC前文已有介绍，在此主要介绍MVP和MVVM框架。
|
|
|
|
（1）MVP（Model-View-Presenter）。MVP模式是目前Android系统非常流行的框架，是从MVC模式演变过来的，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。但是MVP与MVC有着一个重大的区别，如下图所示：在MVP中View并不直接使用Model，二者完全分离以减少耦合，它们之间的通信是通过Presenter（MVC中的Controller）来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过Controller。MVP大大降低了耦合度（Activity不再进行复杂的操作），层级更明显，相对MVC来说MVP更加适用于Android应用的开发。
|
|
|
|
|
|
|
|
.Model（模型）：依然是实体模型（作用与MVC相同）。
|
|
|
|
.View（视图）：在对应的Activity和XML文件中，负责View的绘制以及与用户的交互。
|
|
|
|
.Presenter（交互器／表示器）：负责完成View与Model间的交互和业务逻辑。
|
|
|
|
MVP核心是过一个抽象的View接口（IView）将Presenter与View层进行解耦。Persenter持有该View接口，对该接口进行操作，而不是直接操作View层。这样就可以把视图操作和业务逻辑解耦，从而使得Activity成为真正的View层。
|
|
|
|
虽然MVP使得Android开发变得更简单，但是也存在以下弊端：
|
|
|
|
①Presenter层与View层是通过接口进行交互的，接口粒度不好控制。粒度太小，就会存在大量接口的情况，使代码太过碎版化；粒度太大，解耦效果不好。同时对于界面UI的输入和数据的变化，需要手动调用View层或Presenter层相关的接口，相对来说缺乏自动性、监听性。
|
|
|
|
②MVP是以界面UI和事件为驱动的传统模型，更新UI都需要保证能获取到控件的引用，同时更新UI的时候还要考虑当前是否是UI线程，也要考虑Activity的生命周期。而且数据都是被动地通过UI控件做展示，但是由于数据的时变性，因此更希望数据能转被动为主动，数据能更有活性，由数据来驱动UI。
|
|
|
|
③View层与Presenter层还是有一定的耦合度。一旦View层某个UI元素更改，那么对应的接口就必须得改，数据如何映射到UI上、事件监听接口这些都需要转变。同时，复杂的逻辑业务处理也可能会导致Presenter层代码变得异常臃肿。
|
|
|
|
（2）MVVM（Model-View-ViewModel）。为了解决MPV框架结构的弊端，MVVM框架利用数据绑定（Data Binding）、依赖属性（Dependency Property）、命令（Command）、路由事件（Routed Event）等新特性打造了一个更加灵活高效的架构。Google于2016年正式推出MVVM正式库，目前的Android Studio能够很好的支持在MVVM框架下开发应用程序。
|
|
|
|
作为MVP的升级版，MVVM将Presenter改名为ViewModel（视图模型）。如下图所示，MVVM的核心思想是实现View和Model的双向绑定，当View有用户输入后，ViewModel通知Model更新数据，同理Model数据更新后，ViewModel通知View更新。
|
|
|
|
|
|
|
|
.Model（模型）：和MVP相同，基本就是实体模型（Bean），包括Retrofit的Service。ViewModel可以根据Model获取一个Bean的Observable（RxJava），然后做一些数据转换操作和映射到ViewModel中的一些字段，最后把这些字段绑定到View层上。
|
|
|
|
.View（视图）：View层实现和界面UI相关的工作，开发人员只在XML和Activity或Fragment写View层的代码。View层不做和业务相关的事，Activity不写和业务逻辑相关代码，也不需要根据业务逻辑来更新UI的代码，而更新界面UI通过Binding实现，在ViewModel里面更新绑定的数据源即可，Activity要做的事就是初始化一些控件。Activity可以更新UI，但是更新的UI必须和业务逻辑和数据是没有关系的，只是单纯的根据点击或者滑动等事件更新UI（如根据滑动颜色渐变、根据点击隐藏等单纯UI逻辑），Activity（View层）只是处理UI本身的事件，简单地说：View层不做任何业务逻辑、不涉及操作数据、不处理数据、UI和数据严格分开。
|
|
|
|
.ViewModel（视图模型）：ViewModel层做的事情刚好和View层相反，它只做和业务逻辑和业务数据相关的事，不做任何和界面UI、控件相关的事，ViewModel层不会持有任何控件的引用，不会在ViewModel中通过UI控件的引用去更新UI。ViewModel专注于业务的逻辑处理，操作也都是对数据进行操作，数据源绑定在相应的控件上会自动去更改UI，开发者不需要关心更新UI。
|
|
|
|
|
|
①数据驱动。在常规的开发模式中，数据变化需要更新界面UI的时候，需要先获取UI控件的引用，然后再更新UI。在MVVM中，这些都是通过数据驱动来自动完成，数据变化后会自动更新UI，UI的改变也能自动反馈到数据层，数据成为主导因素。这样MVVM在业务逻辑处理中只要关心数据。对于版本迭代中频繁的UI改动，更新或新增一套View即可。
|
|
|
|
②低耦合度。MVVM框架的分工是非常明确，数据是独立于UI。数据和业务逻辑处于一个独立的ViewModel中，ViewModel只需要关注数据和业务逻辑，不需要和UI或者控件打交道，即便是控件改变了（例如：TextView换成EditText），ViewModel也几乎不需要更改的。
|
|
|
|
③可复用性。一个ViewModel可以复用到多个View中。对于版本迭代中频繁的UI改动，更新或新增一套View即可。
|
|
|
|
MVVM的优点还体现在团队协作、单元测试等方面。总之，Google推进的MVVM开发框架优势非常明显，是今后Android开发框架的主要发展趋势。
|
|
|
