第一章 Adnroid体系与系统架构

Android体系与系统架构

1.1 Google生态系统

1.2 Android系统架构

1.2.1 Linux

1.2.2 Dalvik和ART

1.2.3 Framework

1.2.4 Standard libraries

1.2.5 Application

1.3 Android App 组件框架

1.3.1 Android四大组件是如何协同工作

1.3.2 应用运行上下问对象

1.4 Adnroid系统源代码目录和系统目录(略)

1.2 Android系统架构

Android系统架构的经典示意图

它将Android大致分为四层:

  1. Linux Kernel 内核层
  2. 库和运行时 (Libraries + Android RunTime)
  3. FrameWork层
  4. 应用层 Applications

Android的体系架构鼓励系统组件的重用,共享组件间的数据,并且定义组件间的访问权限控制。可以说这些层次结构既是相互独立又是相互关联的。
第一章 Adnroid体系与系统架构_第1张图片
- Linux
Linux层,*Andorid最底层最核心的部分,包含了Android系统的核心服务,包括硬件驱动、进程管理、安全系统等等*
- Dalvik and ART
Dalvik包含了一整套的Adnroid运行环境虚拟机,每个App都会分配Dalvik虚拟机来确保相互之间不受干扰,并保持独立。 Dalvik的特点是运行时编译。
ART: 在Android 5.X的版本开始,ART模式已经取代了DalvikART采用的是安装时编译,以后运行时就不用编译了。
当让了,对在其虚拟机环境中运行的大部分APP来讲,他们都运行着相同的代码。
- Application Framework
第一章 Adnroid体系与系统架构_第2张图片
应用框架层
Framework层为我们程序开发提供了非常方便的API,
我们可以称Framework层才真正是Java语言实现的层,在这层里定义的API都是用Java语言编写。但是又因为它包含了JNI的方法,JNI用C/C++编写接口,根据函数表查询调用核心库层里的底层方法,最终访问到Linux内核。
那么Framework层的作用就有2个。
1.用Java语言编写一些规范化的模块封装成框架,供APP层开发者调用开发出具有特殊业务的手机应用。
2.用Java Native Interface调用core lib层的本地方法,JNI的库是在Dalvik虚拟机启动时加载进去的,Dalvik会直接去寻址这个JNI方法,然后去调用。
2种方式的结合达到了Java方法和操作系统的相互通信。

简单的介绍下Framework层部分框架的功能:
Activity Manager
用来管理应用程序生命周期并提供常用的导航回退功能。

Window Manager
提供一些我们访问手机屏幕的方法。屏幕的透明度、亮度、背景。

Content Providers
使得应用程序可以访问另一个应用程序的数据(如联系人数据库), 或者共享它们自己的数据。

View System
可以用来构建应用程序, 它包括列表(Lists),网格(Grids),文本框(Text boxes),按钮(Buttons), 甚至可嵌入的web浏览器。

Notification Manager
使得应用程序可以在状态栏中显示自定义的提示信息。

Package Manager
提供对系统的安装包的访问。包括安装、卸载应用,查询permission相关信息,查询Application相关信息等。

Telephony Manager
主要提供了一系列用于访问与手机通讯相关的状态和信息的方法,查询电信网络状态信息,sim卡的信息等。

Resource Manager
提供非代码资源的访问,如本地字符串,图形,和布局文件(Layout files )。

Location Manager
提供设备的地址位置的获取方式。很显然,GPS导航肯定能用到位置服务。

XMPP
可扩展通讯和表示协议。前身为Jabber,提供即时通信服务。例如推送功能,Google Talk。

………等等

  • Standard libraries

    这里包含的是Adnroid中的一些标准库。
  • Application
    What Android Is
    第一章 Adnroid体系与系统架构_第3张图片

1.3 Android App 组件框架

四大组件: Activity 、Service、ContentProvider、 BroadCastReciever .

1.3.1 Android四大组件是如何协同工作

Intent
Activity作为人机交换的第一界面,负责向用户展示信息和处理结果,而这些信息的来源可以通过资源获取,也可以通过ContentProvider来获取其他应用的信息,或者Service从后台获取,当然了也可以是通BroadCastReciever获取到的广播信息。
组件和组件之间通过Intent通信、传递信息、交换数据,形成了各自独立又紧密联系的关系。

1.3.2 应用运行上下问对象

context
Android系统的上下文对象,即在Context中。
Activity Service Application 都继承自Context。
Android应用程序辉仔如下所示的时间点创建应用上下文Context。
- 创建Application
- 创建Activity
- 创建Application

从中我们可以看出,创建Context的时机就是在创建Context实现类的时候。

当应用程序第一次运行时,Android系统都会创建一个Application对象,同时创建Application Context对象,所有的组件都共同拥有这样一个Context对象,这个应用上下文对象贯穿整个应用进程的生命周期,为应用全局提供了功能和环境支持。

而创建Activity和Service时,系统也会为他们提供运行时的上下文环境,即创建Activity实例、Service实例的Context对象。

所以,我们可用直接在Activity中直接通过this的方式获取Context对象,而在匿名内部类中,就必须使用 XXXActivity.this的方式才可以获取Context对象。

当然 你也可以通过getApplicationContext()方法获取整个APP的Context对象,但是通过getApplicationContext()获取到的Context是整个应用的上下问对象,这个与某个组件的上下文对象在某些时候还是有区别的。

1.4 Adnroid系统源代码目录和系统目录
源码目录啥的暂时略过吧,目前也钻研不懂,等回头有精力了再来膜拜。

你可能感兴趣的:(android,linux,kernel,系统架构)