Android架构及四大组件
Android架构及四大组件
- Android架构
-
- Loader层：
- Linux内核层
- 硬件抽象层 (HAL)
- Android Runtime & 系统库
- Framework层
- App层
- Syscall && JNI
- Android四大组件
-
- 活动(activity)
- 服务(Service)
- 广播接收者(Broadcast Receiver)
- 内容提供者(Content Provider)
Android架构
下图为Android的经典分层架构图，从下往上依次分为Linux内核、HAL、系统Native库和Android运行时环境、Java框架层以及应用层这5层架构，其中每一层都包含大量的子模块或子系统。
上图采用静态分层方式的架构划分，但在系统运转过程中，各模块代码运行在不同的进程(线程)中，相互之间进行着各种错终复杂的信息传递与交互流，从这个角度来说此图并没能体现Android整个系统的内部架构、运行机理，以及各个模块之间是如何衔接与配合工作的。为了更深入地掌握Android整个架构思想以及各个模块在Android系统所处的地位与价值，以Android系统启动过程为主线，以进程的视角来诠释Android系统，剖析各个模块功能。
Google提供的5层架构图很经典，但为了更进一步透视Android系统架构，本文更多的是以进程的视角，以分层的架构来诠释Android系统的全貌，阐述Android内部的环环相扣的内在联系。
图解：Android系统启动过程由上图从下往上的一个过程是由Boot Loader引导开机，然后依次进入Kernel、Native、Framework、App。
Loader层：
Boot ROM: 当手机处于关机状态时，长按Power键开机，引导芯片开始从固化在 ROM里的预设代码开始执行，然后加载引导程序到 RAM；
Boot Loader：这是启动Android系统之前的引导程序，主要是检查RAM，初始化硬件参数等功能。
Linux内核层
Android平台的基础是Linux内核，比如ART虚拟机最终调用底层Linux内核来执行功能。Linux内核的安全机制为Android提供相应的保障，也允许设备制造商为内核开发硬件驱动程序。
启动Kernel的swapper进程(pid=0)：该进程又称为idle进程, 系统初始化过程Kernel由无到有开创的第一个进程, 用于初始化进程管理、内存管理，加载Display,Camera Driver，Binder Driver等相关工作；
启动kthreadd进程（pid=2）：是Linux系统的内核进程，会创建内核工作线程kworkder，软中断线程ksoftirqd，thermal等内核守护进程。 kthreadd进程是所有内核进程的鼻祖。
硬件抽象层 (HAL)
硬件抽象层 (HAL) 提供标准接口，HAL包含多个库模块，其中每个模块都为特定类型的硬件组件实现一组接口，比如WIFI/蓝牙模块，当框架API请求访问设备硬件时，Android系统将为该硬件加载相应的库模块。
Android Runtime & 系统库
每个应用都在其自己的进程中运行，都有自己的虚拟机实例。ART通过执行DEX文件可在设备运行多个虚拟机，DEX文件是一种专为Android设计的字节码格式文件，经过优化，使用内存很少。ART主要功能包括：预先(AOT)和即时(JIT)编译，优化的垃圾回收(GC)，以及调试相关的支持。
这里的Native系统库主要包括init孵化来的用户空间的守护进程、HAL层以及开机动画等。启动init进程(pid=1),是Linux系统的用户进程， init进程是所有用户进程的鼻祖。
- init进程会孵化出ueventd、logd、healthd、installd、adbd、lmkd等用户守护进程；
- init进程还启动 servicemanager(binder服务管家)、 bootanim(开机动画)等重要服务
- init进程孵化出Zygote进程，Zygote进程是Android系统的第一个Java进程(即虚拟机进程)， Zygote是所有Java进程的父进程，Zygote进程本身是由init进程孵化而来的。
Framework层
Zygote进程，是由init进程通过解析init.rc文件后fork生成的，Zygote进程主要包含：
- 加载ZygoteInit类，注册Zygote Socket服务端套接字
- 加载虚拟机
- 提前加载类preloadClasses
- 提前加载资源preloadResouces
- System Server进程，是由Zygote进程fork而来， SystemServer是Zygote孵化的第一个进程，System Server负责启动和管理整个Java framework，包含ActivityManager，WindowManager，PackageManager，PowerManager等服务。
- Media Server进程，是由init进程fork而来，负责启动和管理整个C++framework，包含AudioFlinger，Camera Service等服务。
App层
- Zygote进程孵化出的第一个App进程是Launcher，这是用户看到的桌面App；
- Zygote进程还会创建Browser，Phone，Email等App进程，每个App至少运行在一个进程上。
- 所有的App进程都是由Zygote进程fork生成的。
Syscall && JNI
Native与Kernel之间有一层系统调用(SysCall)层，见Linux系统调用(Syscall)原理;
Java层与Native(C/C++)层之间的纽带JNI，见Android JNI原理分析。
Android四大组件
Android 开发的四大组件分别是：活动（activity），用于展示功能；服务（service），后台运行服务，不提供界面呈现；广播接受者（Broadcast Receiver），用于接收广播；内容提供者（Content Provider），支持多个应用中存储和读取数据。四大组件都必须在AndroidManifest.xml配置文件中进行声明。
活动(activity)
Activity是Android的四大组件之一。是用户操作的可视化界面；它为用户提供了一个完成操作指令的窗口。当我们创建完毕Activity之后，需要调用setContentView()方法来完成界面的显示；以此来为用户提供交互的入口。在Android App 中只要能看见的几乎都要依托于Activity，所以Activity是在开发中使用最频繁的一种组件。个Activity通常就是一个单独的屏幕（窗口）。
Activity可以看成是安卓系统的根本，在这个根本上才可以进行其他的工作，因为在安卓系统里运行的所有的程序，它的流程都必须在活动中运行，所有他是最基本的模块。它的作用是一个框架或页面，每个程序都会有一个或多个活动组成。
Activity的生命周期
在Android中会维持一个Activity Stack（Activity栈），当一个新的Activity创建时，它就会放到栈顶，这个Activity就处于运行状态。当再有一个新的Activity被创建后，会重新压人栈顶，而之前的Activity则会在这个新的Activity底下，而且之前的Activity就会进入后台。一个Activity实质上有四种状态：
a.运行中(Running/Active):这时Activity位于栈顶，是可见的，并且可以用户交互。
b.暂停(Paused):当Activity失去焦点，不能跟用户交互了，但依然可见，就处于暂停状态。当一个新的非全屏的Activity或者一个透明的Activity放置在栈顶，Activity就处于暂停状态；这个时候Activity的各种数据还被保持着；只有在系统内存在极低的状态下，系统才会自动的去销毁Activity。
c.停止(Stoped):当一个Activity被另一个Activity完全覆盖，或者点击HOME键退入了后台，这时候Activity处于停止状态。这里有些是跟暂停状态相似的：这个时候Activity的各种数据还被保持着；当系统的别的地方需要用到内容时，系统会自动的去销毁Activity。
d.销毁(Detroyed):当我们点击返回键或者系统在内存不够用的情况下就会把Activity从栈里移除销毁，被系统回收，这时候，Activity处于销毁状态。
android应用中每一个Activity都必须要在AndroidManifest.xml配置文件中声明，否则系统将不识别也不执行该Activity。
服务(Service)
Service是安卓里非常很重要的组件，它的地位和优先级别是与活动相似的，不过Service不能够自己运行，它只能在安卓的后台运行。它的作用就是与安卓的其他组件进行交互，举个简单例子：当我们打开手机上音乐播放器并将它放到后台，此时播放的音乐就是由Service在负责控制。
service（服务）是安卓中的四大组件之一，它通常用作在后台处理耗时的逻辑，与Activity一样，它存在自己的生命周期
服务（Service)是Android中实现程序后台运行的解决方案，它非常适合去执行那些不需要和用户交互而且还要求长期运行的任务。服务的运行不依赖于任何用户界面，即使程序被切换到后台，或者用户打开了另外一个应用程序，服务仍然能够保持正常运行。
不过需要注意的是，服务并不是运行在一个独立的进程当中的，而是依赖于创建服务时所在的应用程序进程。与某个应用程序进程被杀掉时，所有依赖于该进程的服务也会停止运行。另外.也不要被服务的后台概念所迷惑，实际上服务并不会自动开启线程，所有的代码都是默认运行在主线程当中的。也就是说，我们需要在服务的内部手动创建子线程，并在这里执行具体的任务，否则就有可能出现主线程被阻塞住的情况。
- service用于在后台完成用户指定的操作。service分为两种：
（a）started（启动）：当应用程序组件（如activity）调用startService()方法启动服务时，服务处于started状态。
（b）bound（绑定）：当应用程序组件调用bindService()方法绑定到服务时，服务处于bound状态。 - startService()与bindService()区别：
(a)started service（启动服务）是由其他组件调用startService()方法启动的，这导致服务的onStartCommand()方法被调用。当服务是started状态时，其生命周期与启动它的组件无关，并且可以在后台无限期运行，即使启动服务的组件已经被销毁。因此，服务需要在完成任务后调用stopSelf()方法停止，或者由其他组件调用stopService()方法停止。
(b)使用bindService()方法启用服务，调用者与服务绑定在了一起，当启动方销毁时，Service也会自动进行unBind操作，当发现所有绑定都进行了unBind时才会销毁Service。 - 开发人员需要在应用程序配置文件中声明全部的service。
- Service通常位于后台运行，它一般不需要与用户交互，因此Service组件没有图形用户界面。Service组件需要继承Service基类。Service组件通常用于为其他组件提供后台服务或监控其他组件的运行状态。
- 在Service的onCreate回调函数中不可以做耗时的操作，因为 Service的onCreate是在主线程（ActivityThread）中调用的，耗时操作会阻塞UI。如果需要做耗时的操作，需要使用线程和Handler。
- IntentService相比父类Service而言，最大特点是其回调函数onHandleIntent中可以直接进行耗时操作，不必再开线程。其原理是IntentService的成员变量 Handler在初始化时已属于工作线程，之后handleMessage，包括onHandleIntent等函数都运行在工作线程中。IntentService还有一个特点，就是多次调用onHandleIntent函数（也就是有多个耗时任务要执行），多个耗时任务会按顺序依次执行。原理是其内置的Handler关联了任务队列，Handler通过looper取任务执行是顺序执行的。这个特点就能解决多个耗时任务需要顺序依次执行的问题。而如果仅用service，开多个线程去执行耗时操作，就很难管理。
广播接收者(Broadcast Receiver)
在安卓系统中，广播接收者并不是直接就可以看到的，它是程序之间传递信息时的一种机制，作用就是接收或者发送通知。通俗的来说广播接收者更像是一种传递组件，它能够将信息接收，甚至还可以对它进行过滤然后进行响应。
广播是一种广泛运用的在应用程序之间传输信息的机制。而广播接收器是对发送出来的广播进行过滤接受并响应的一类组件。可以使用广播接收器来让应用对一个外部时间做出响应。例如，当电话呼入这个外部事件到来时，可以利用广播接收器进行处理。广播接收器既可以在AndroidManifest.xml中注册，也可以在运行时的代码中使用Context.registerReceive()进行注册。只要是注册了，当事件来临时，即使程序没有启动，系统也在需要的时候启动程序。各种应用还可以通过使用Context.sendBroadcast()将它们自己的Intent广播给其他应用程序。
- 你的应用可以使用它对外部事件进行过滤，只对感兴趣的外部事件(如当电话呼入时，或者数据网络可用时)进行接收并做出响应。广播接收器没有用户界面。然而，它们可以启动一个activity或serice来响应它们收到的信息，或者用NotificationManager来通知用户。通知可以用很多种方式来吸引用户的注意力，例如闪动背灯、震动、播放声音等。一般来说是在状态栏上放一个持久的图标，用户可以打开它并获取消息。
- 广播接收者的注册有两种方法，分别是程序动态注册（在运行时的代码中使用Context.registerReceive()进行注册）和AndroidManifest文件中进行静态注册。
- 动态注册广播接收器特点是当用来注册的Activity关掉后，广播也就失效了。静态注册无需担忧广播接收器是否被关闭，只要设备是开启状态，广播接收器也是打开着的。也就是说哪怕app本身未启动，该app订阅的广播在触发时也会对它起作用。
内容提供者(Content Provider)
内容提供者这个组件是专门为第三方应用而设计的，它非常的灵活，而且相当重要，它会为所有的应用准备一个内容窗口，并且保留数据库、文件，作用就是我们在使用这些第三方软件的时候，可以有效的访问，并且保护里面的数据。
内容提供者组件通过请求从一个应用程序向其他的应用程序提供数据。这些请求由类 ContentResolver 的方法来处理。内容提供者可以使用不同的方式来存储数据。数据可以被存放在数据库，文件，甚至是网络。
在这里涉及到进程通信问题，在Android中自然使用的是binder来进行，但是由于content provider提供的数据量一般都比较大不能够直接进行传递。所以这里采用的是一种叫做 匿名共享内存的方式进行数据传递，在不同的进程中只需要传递一个文件描述符就可以。
- android平台提供了Content Provider使一个应用程序的指定数据集提供给其他应用程序。其他应用可以通过ContentResolver类从该内容提供者中获取或存入数据。
- 只有需要在多个应用程序间共享数据是才需要内容提供者。例如，通讯录数据被多个应用程序使用，且必须存储在一个内容提供者中。它的好处是统一数据访问方式。
- ContentProvider实现数据共享。ContentProvider用于保存和获取数据，并使其对所有应用程序可见。这是不同应用程序间共享数据的唯一方式，因为android没有提供所有应用共同访问的公共存储区。
- 开发人员不会直接使用ContentProvider类的对象，大多数是通过ContentResolver对象实现对ContentProvider的操作。
- ContentProvider使用URI来唯一标识其数据集，这里的URI以content://作为前缀，表示该数据由ContentProvider来管理。
- 通常来说，共享数据直接读取数据库会更简单，但Android官方推荐ContentProvider作为应用程序间共享数据的方式。主要在于两点：
- 封装。对数据进行封装，提供统一的接口，使用者完全不必关心这些数据是在DB，XML、Preferences或者网络请求来的。当项目需求要改变数据来源时，使用我们的地方完全不需要修改。提供了一种跨进程数据共享的方式。
- 数据更新通知机制。因为数据是在多个应用程序中共享的，当其中一个应用程序改变了这些共享数据的时候，它有责任通知其它应用程序，让它们知道共享数据被修改了，这样它们就可以作相应的处理。
ContentResolver接口的notifyChange函数就是用来通知那些注册了监控特定URI的ContentObserver对象，使得它们可以相应地执行一些处理。ContentObserver可以通过registerContentObserver进行注册。
参考：
https://cloud.tencent.com/developer/article/1415759
https://blog.csdn.net/weixin_43910165/article/details/118304372
https://web.phb123.com/pinpai/zixun/19565.html
https://blog.csdn.net/weixin_39601642/article/details/117321212
https://blog.csdn.net/u010755471/article/details/125501154