Android零基础入门第2节：Android 系统架构和应用组件那些事

 继上一期浅谈了Android的前世此生，这一期一块儿来大体回顾一下Android 系统架构和应用组件。

 

1、Android 系统架构

Android系统的底层创建在Linux系统之上，该平台由操做系统、中间件、用户界面和应用软件4层组成，它采用一种被称为软件叠层（Software Stack）的方式进行构建。这种软件叠层结构使得层与层之间相互分离，明确各层的分工。这种分工保证了层与层之间的低耦合，当下层的层内或层下发生改变时，上层应用程序无须任何改变。

Android的系统架构和其余操做系统同样，采用了分层的架构。从架构图看，Android分为四个层，从高层到低层分别是应用程序层（Applications）、应用程序框架层（Application Framework ）、系统运行库层（Libraries和Android Runtime）和Linux内核层（Linux Kernel），以下图所示：

01 应用程序层

应用程序层是一个核心应用程序的集合，全部安装在手机上的应用程序都属于这一层。该层不只包括系统内置的应用也包括用户本身安装的应用，例如email 客户端，SMS 短消息程序，日历，地图，浏览器，联系人管理程序，QQ，微信，淘宝，美团等。

该层全部的应用程序都是使用Java 语言编写的，这也是本次主要总结整理的内容。

02 应用程序框架层

开发人员也能够彻底访问核心应用程序所使用的API框架。该应用程序的架构设计简化了组件的重用，任何一个应用程序均可以发布它的功能块而且任何其它的应用程序均可以使用其所发布的功能块（不过得遵循框架的安全性）。一样，该应用程序重用机制也使用户能够方便的替换程序组件。

隐藏在每一个应用后面的是一系列的服务和系统，其中包括：

1)丰富而又可扩展的视图（Views），能够用来构建应用程序， 它包括列表（List）、网格（Grid）、文本框（Text）、按钮（Button)， 甚至可嵌入web浏览器。

2)内容提供者（Content Providers），使得应用程序能够访问另外一个应用程序的数据（如联系人数据库），或者共享它们本身的数据。

3)资源管理器（Resource Manager），提供非代码资源的访问，如本地字符串、图形、和布局文件（Layout files ）。

4)通知管理器 （Notification Manager），使得应用程序能够在状态栏中显示自定义的提示信息。

5)活动管理器（Activity Manager），用来管理应用程序生命周期并提供经常使用的导航回退功能。

应用程序框架除了可做为应用程序开发的基础以外，也是软件复用的重要手段，任何一个应用程序均可发布它的功能模块——只要发布时遵照了框架的约定，那么其余应用程序就可以使用这个功能模块。

03 系统运行库层

系统运行库层包含了系统库及Android运行时。

系统库

Android包含一套被不一样组件所使用的C/C++库的集合。通常来讲，Android应用开发者不能直接调用这套C/C++库集，但能够经过它上面的应用程序框架来调用这些库。

下面列出一些核心库：

1)系统C库：一个从BSD系统派生出来的标准C系统库（libc），而且专门为嵌入式 Linux设备调整过。

2)媒体库：基于PacketVideo的OpenCORE，这套媒体库支持播放和录制许多流行的音 频和视频格式，以及查看静态图片。主要包括MPEG四、H.26四、MP三、AAC、AMR、JPG、PNG等多媒体格式。

3)Surface Manager：管理对显示子系统的访问，并能够对多个应用程序的2D和3D图 层提供无缝整合。

4)LibWebCore：一个全新的Web浏览器引擎，该引擎为Android浏览器提供支持，也为WebView提供支持，WebView彻底能够嵌入开发者本身的应用程序中。

5)SQLite：供全部应用程序使用的功能强大的轻量级关系数据库。

6)OpenGL ES：该库可使用硬件3D加速(若是可用)或者使用高度优化的3D软加速。

7)FreeType：位图（Bitmap）和矢量（Vector）字体显示。

8)SGL：底层的2D 图形引擎。

Android运行时（Android Runtime）

Android运行时由两部分组成：Android核心库集和ART。其中核心库集提供了Java语言核心库所能使用的绝大部分功能，而虚拟机则负责运行Android应用程序。

Android 5.0之前的Android运行时由Dalvik虚拟机和Android核心库集组成，但因为Dalvik 虚拟机采用了一种被称为JIT （Just-in-time）的解释器进行动态编译并执行，所以致使Android App运行时比较慢;而ART模式则是在用户安装App时进行预编译（Ahead-of-time，简称AOT）的，将本来在程序运行时的编译动做提早到应用安装时，这样使得程序在运行时能够减小动态 编译的开销，从而提高Android App的运行效率。

反过来，因为ART须要在安装App时进行AOT处理，所以ART须要占用更多的存储空 间，应用安装和系统启动时间会延长很多。

除此以外，ART还支持ARM、x86和MIPS架构，而且能彻底兼容64位系统，Android必然会带来更好的用户体验。

04 Linux内核层

Android系统主要基于Linux2.6内核开发，Linux内核层为Android设备的各类硬件提供了底层的驱动，如显示驱动、音频驱动、照相机驱动、蓝牙驱动、电源管理驱动等。

Linux 内核也同时做为硬件和软件栈之间的抽象层。

 

2、Dalvik虚拟机和ART模式

01 Dalvik虚拟机

经过JavaSE部分的学习，咱们知道JavaSE 程序使用的虚拟机叫Java Virtual Machine，简称JVM。而Android 应用虽然使用Java 语言开发，可是使用的虚拟就是Dalvik Virtual Machine，简称DVM。

Dalvik是Google公司本身设计的用于Android平台的虚拟机，它能够简单地完成进程隔离和线程管理，而且能够提升内存的使用效率。每个Android应用程序在底层都会对应一个独立的Dalvik虚拟机实例，其代码在虚拟机的解析下得以执行。Dalvik 通过优化，容许在有限的内存中同时运行多个虚拟机的实例，而且每个Dalvik 应用做为一个独立的Linux 进程执行。

不少人都认为Dalvik虚拟机是一个Java虚拟机，由于Android开发的编程语言偏偏是 Java语目，可是这种说法并不许确。Dalvlk虚拟机并非按照Java虚拟机的规范来实现的，二者不兼容，并且也有不少不一样之处。下面经过一个图来进行对比说明，以下图所示。

从上图能够看出，Java虚拟机和Dalvik虚拟机主要有两大区别：一是它们编译后的文件不一样；二是它们基于的架构不一样。具体以下：

 编译后的文件不一样

Java虚拟机运行的是.class字节码文件，而Dalvik虚拟机运行的则是其专有的.dex文件。 在Java程序中Java类会被翻译成一个或者多个字节码文件（.class ）而后打包到.jar文件，以后Java虚拟机会从相应的.class文件和.jar文件中获取相应的字节码。Android程序虽然也是使用Java语言进行编程，可是在翻译成.class文件后，还会经过工具将全部的.class文件转换成一个.dex文件，而后Dalvik虚拟机从其中读取指令和数据，最后的.odex是为了在运行过程当中进一步提升性能而对.dex文件进行的进一步优化，能加快软件的加载速度和开启速度。

 基于的架构不一样

Java虚拟机是基于栈的架构，你们知道，栈是一个连续的内存空间，取出和存人的速度比较慢；而Dalvik基于寄存器的架构，寄存器是CPU上的一块缓存，寄存器的存取速度要比从内存中存取的速度快不少，这样就能够根据硬件最大限度地优化设备，更适合移动设备的使用。

须要说明的是，Android系统下的Dalvik虚拟机默认给每个应用程序最多分配16 MB 内存，若是Android加载的资源超过这个值，就会报出OutOfMemoryError异常，所以必定要注意这个问题。

02 ART模式

ART模式英文全称为Android Runtime，是谷歌Android 4.4系统新增的一种用运行模式。与传统的Dalvik模式不一样，ART模式能够实现更为流畅的安卓系统体验，只有在Android 4.4以上系统中采用此模式。

在4.4 系统以前，Android 系统在Linux 的底层下构筑Dalvik 一层的虚拟机，经过其能够更好适应多样的硬件架构，开发者只须要按一套规则进行应用即可，无需由于不一样的硬件架构而处理与底层的驱动关系，从而大大提升开发的效率，但由于应用均是运行在Dalvik 虚拟机中，所以应用程序每次运行的时候，一部分代码都须要从新进行编译，这过程须要消耗必定的时间和下降应用的执行效率，最明显的即是拖延了应用的启动时间和下降了运行速度。

ART 模式最大的做用就是提高了Android 系统流畅度，相比Dalvik 模式中出现的耗电快、占用内存大、即便是旗舰机用久了也会卡顿严重等现象，ART 模式中这种问题获得了很好的解决，经过在安装应用程序时，自动对程序进行代码预读取编译，让程序直接编译成机器语言，免去了Dalvik 模式要时时转换代码，实现高效率、省电、占用更低的系统内存、手机运行流畅。

 

3、Android应用组件

Android四大组件分别是：

活动（Activity）： 用于表现功能。

服务（Service）： 后台运行服务，不提供界面呈现。

广播接收器（BroadcastReceiver）：用于接收广播。

内容提供者（Content Provider）： 支持在多个应用中存储和读取数据，至关于数据库。

01 Activity

Android中，Activity是全部程序的根本，全部程序的流程都运行在Activity之中，Activity能够算是开发者遇到的最频繁，也是Android 当中最基本的模块之一。在Android的程序当中，Activity 通常表明手机屏幕的一屏。若是把手机比做一个浏览器，那么Activity就至关于一个网页。在Activity当中能够添加一些Button、Check box等控件。能够看到Activity概念和网页的概念至关相似。

通常一个Android 应用是由多个Activity 组成的。这多个Activity之间能够进行相互跳转，例如，按下一个Button按钮后，可能会跳转到其余的Activity。和网页跳转稍微有些不同的是，Activity 之间的跳转有可能返回值，例如，从Activity A 跳转到Activity B，那么当Activity B运行结束的时候，有可能会给Activity A一个返回值。这样作在不少时候是至关方便的。

当打开一个新的屏幕时，以前一个屏幕会被置为暂停状态，而且压入历史堆栈中。用户能够经过回退操做返回到之前打开过的屏幕。能够选择性的移除一些没有必要保留的屏幕，由于Android会把每一个应用的开始到当前的每一个屏幕保存在堆栈中。

02 Service

Service 是android 系统中的一种组件，它跟Activity 的级别差很少，可是他不能本身运行，只能后台运行，而且能够和其余组件进行交互。Service 是没有界面的长生命周期的代码。Service是一种程序，它能够运行很长时间，可是它却没有用户界面。

这么说有点枯燥，来看个例子。打开一个音乐播放器的程序，这个时候若想上网了，那么，打开Android浏览器，这个时候虽然已经进入了浏览器这个程序，可是，歌曲播放并无中止，而是在后台继续一首接着一首的播放。其实这个播放就是由播放音乐的Service进行控制。固然这个播放音乐的Service也能够中止，例如，当播放列表里边的歌曲都结束，或者用户按下了中止音乐播放的快捷键等。

Service 能够在和多场合的应用中使用，好比播放多媒体的时候用户启动了其余Activity这个时候程序要在后台继续播放，好比检测SD 卡上文件的变化，再或者在后台记录地理信息位置的改变等等，总之服务嘛，老是藏在后头的。

03 BroadcastReceiver

在Android 中，Broadcast是一种普遍运用的在应用程序之间传输信息的机制。而BroadcastReceiver 是对发送出来的Broadcast进行过滤接受并响应的一类组件。可使用BroadcastReceiver 来让应用对一个外部的事件作出响应。

这是很是有意思的，例如，当电话呼入这个外部事件到来的时候，能够利用BroadcastReceiver 进行处理。例如，当下载一个程序成功完成的时候，仍然能够利用BroadcastReceiver 进行处理。BroadcastReceiver不能生成UI，也就是说对于用户来讲不是透明的，用户是看不到的。BroadcastReceiver经过NotificationManager 来通知用户这些事情发生了。BroadcastReceiver 既能够在AndroidManifest.xml 中注册，也能够在运行时的代码中使用Context.registerReceiver（）进行注册。只要是注册了，当事件来临的时候，即便程序没有启动，系统也在须要的时候启动程序。各类应用还能够经过使用Context.sendBroadcast（） 将它们本身的Intent Broadcasts广播给其余应用程序。

04 Content Provider

Content Provider 是Android提供的第三方应用数据的访问方案。

在Android中，对数据的保护是很严密的，除了放在SD卡中的数据，一个应用所持有的数据库、文件等内容，都是不容许其余直接访问的。Android固然不会真的把每一个应用都作成一座孤岛，它为全部应用都准备了一扇窗，这就是Content Provider。应用想对外提供的数据，能够经过派生Content Provider类， 封装成一枚Content Provider，每一个Content Provider都用一个uri做为独立的标识，形如：content://com.xxxxx。全部东西看着像REST的样子，但实际上，它比REST 更为灵活。和REST相似，uri也能够有两种类型，一种是带id的，另外一种是列表的，但实现者不须要按照这个模式来作，给id的uri也能够返回列表类型的数据，只要调用者明白，就无妨，不用苛求所谓的REST。

 

今天就先到这里，下一期将初步总结分享Android环境搭建，若是有问题欢迎留言一块儿探讨，共同成长！

此文章版权为微信公众号分享达人秀全部，若转载请备注出处，特此声明！