Android系统架构与四大组件

2016年1月15日 3点热度 0条评论 来源: Tyssen

本篇博文主要讲解Android的系统架构。

对于Android开发者来说,有必要了解一下Android应用程序是如何运行的。

Android是一个移动操作系统,它大致分为四层,即Linux内核层,库和运行时,Framework层和应用层。Android的体系架构鼓励系统组件重用,共享组件数据,并且定义组件的访问控制权限。可以说,这些层次结构即是相互独立,又是相互关联的。

一  Android系统架构

1.Linux层

Linux层,Android最底层的最核心的部分。每一个Android的应用程序都是运行在Dalvik虚拟机中。每个App都会分配Dalvik虚拟机来保证互相之间不受干扰。并保持独立。它的特点是运行时编译。而在Android 5.X版本开发,ART模式已经取代了Dalvik,ART采用的是安装时就进行编译,以后运行时就不用编译了。当然,对在其虚拟机内运行的大部分App来说,他们都运行着同样的代码。

2.Framework

Framework层包含编写Android应用程序所需要的各种框架类。比如 Activity Managet,window Manager,Content Providers,View System等等。

  3.标准库

标准库就是开发者在开源环境中可以使用的开发库。

  4.Application

Android SDK App 包含 Android manifest,Dalvik classes,Resource bundle.Android NDK App 除了包含和Android SDK App同样的内容外,还包含Libraries与JNI.

 

二  Android组件架构

上面我们讲了Android系统架构,而在应用层,Android的App组件架构,通常就是我们所说的Android四大组件。指的是Activity,BroadcastReiver,ContentProvider和Service,他们是组成Android App的最基本元素。

 

四大组件中,除了BroadcastReiver以外,其他三种组件都必须在Android manifest中注册,对于BroadcastReiver既可以在manifest文件中注册,也可以通过代码来实现。在调用方式上,Activity,Service和阿里需要借用Intent,而ContentProvider则无需借助Intent。

 

Activity 是一种 展示型组建,用于向用户直接地展示一个界面,并且可以接受用户的输入信息从而进行交互。Activity是最重要的一种组件,对于用户来说,Activity就是一个Android应用的全部,这是因为其他三大组件对用户来说都是不可感知的。Activity的启动由Intent触发,其中Intent可以分为显示Intent和隐式Intent.显示Intent可以明确地指向一个Activity组件,隐BroadcastReiverIntent则指向一个或多个目标Activity组件。当然,也可能没有任何一个Activity组件可以处理这个隐BroadcastReiver的Intent。一个Activity组件可以具有特定的启动模式。关于Activity的启动模式与生命周期,我会在下一篇博文里讲述。同一个Activity组件在不同的启动模式下会有不同的效果。Activity组件可以停止,在实际开发中通过Activity的finish方法来结束一个Activity的运行。由此看来,Activity组件的主要作用是展示一个界面并和用户交互,塔扮演的是一种前台界面的角色。

 

Service 是一种计算型组件,用户在后台执行一系列的计算任务。由于Service组件工作在后台,因此用户无法直接感受它的存在。Service 组件和Activity 组件略有不同,Activity组件只有一种运行模式,即Activity处于启动模式,但是 Service组件却有两种状态:启动状态与绑定状态。当 Service组件处于启动状态,这个时候,Service内部可以做一些后台计算,并且不需要和外界直接交互。尽管Service组件使用执行后台计算的,但是它本身是运行在主线程中的,因此耗时的后台计算仍然需要在单独的线程中去完成。当Service组件处于绑定状态时,这个时候,Service内部同样可以进行后台计算,但是处于这种状态时,外界可以很方便地和Service组件进行通信。Service组件也是可以停止的,停止一个Service稍微复杂,需要灵活采用stopService 和 unBindService这两个方法才能完全停止一个Service组件。

 

BroadcastReiver 是一种消息型组件,用于在不同的组件乃至不同的应用之间进行消息传递,BroadcastReiver 同样无法被用户感知,因为它工作在系统内部。BroadcastReiver也叫广播,广播注册有两种方式: 静态注册和动态注册。静态注册是指在AndroidManifest中注册广播,这种广播在应用安装时会被系统解析,此种形式的广播不修要应用启动就可以接收到广播。动态注册广播需要通过Context.registerReceiver() 来实现,并且不需要的时候,要通过Context.unRegisterReceiver来解除广播。此种形态的广播必须要应用启动才能住岑并接收广播,因为应用不启动就无法注册广播,无法注册广告,就无法接收到相应的广播。在实际开发中通过Context的一系列send 方法来发送广播,被发送的广播就会被系统发送给感兴趣的广播接收者。发送和接收过程的匹配时通过广播接收者的<intent-filter>来描述的。可以发现,BroadcastReceiver 组件可以用来实现低耦合的观察者模式,观察者和被观察者之间可以没有任何耦合。由于BroadcastReceiver的特性,它不适合用来执行耗时的操作。BroadcastReceiver 组件一般来说,不需要停止,它也没有停止的概念。

 

ContentProvider 是一种数据共享型组件,用于向其他组件乃至其他App共享数据。和BroadcastReceiver一样,ContentProvider同样无法被用户感知。对于一个ContentProvider组件来说,她的内部需要实习增删改查四种操作,在它的内部,维持着一份数据集合,这个数据集合既可以通过数据库来实现,也可以通过采用任何其他类型实现,比如List和Map.ContentProvider 对数据集合的具体实现并没有任何要求。需要注意的是,ContentProvider的内部insert,delete,update和query方法需要做好线程同步处理,因为这几个方法是在线程池中调用的,另外ContentProvider组件也不需要手动停止。

 

今天讲的主要都是理论,比较枯燥,但也让我们从整体上认识了Android的系统结构。接下来的四篇博文,我会从每个组件的应用以及底层实现原理进行讲解。第一次写博文,肯定有缺憾,望海涵。

 

 

  

     

   

 

    原文作者:Tyssen
    原文地址: https://blog.csdn.net/Tyssen/article/details/50524704
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系管理员进行删除。