Android架构(框架)汇总

Java系统服务: 这部分系统服务又可以分为两种：Java核心系统服务和Java硬件系统服务。
（1）Java核心系统服务是Android系统正常运转的基础，包括大家所熟知的AMS、WMS、PMS等。例如：

 （2）Java硬件服务是为应用提供硬件控制服务，如电话服务、wifi服务、PowerManagerService等。例如：

该两层之前，通过Binder实现进程间通信。允许framework来跨进程边界，来调用Android的系统服务的代码，这使得框架API与Android系统服务能够进行交互。

总结：应用程序---SDK---->系统框架层---Binder IPC--->系统服务层。

以app 获取GPS信息为例：

 

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

Android系统架构开篇：https://zhuanlan.zhihu.com/p/26100298； 此篇是个目录，包含各种引用.比较经典 

Android系统整体架构

主要进程就是sf,sm,ss(ams,wms)

 图解： Android系统启动过程由上图从下往上的一个过程是由Boot Loader引导开机，然后依次进入 -> Kernel -> Native -> Framework -> App，接来下简要说说每个过程

Android系统体系架构分为5层，自顶而下分别是：

• 应用程序框架（Application Framework）
• 进程通信层（Binder IPC）
• 系统服务层（Android System Services）
• 硬件抽象层（HAL）
• Linux内核（Linux Kernel）

1.2 进程通信层（Binder IPC）

进程间通信机制允许framework来跨进程边界，来调用Android的系统服务的代码，这使得框架API与Android系统服务能够进行交互。

1.3 系统服务层（Android System Services）

功能是通过framework APIs与系统服务通信，以实现底层硬件的访问。服务是模块化的.Android包括两类服务：系统服务（如Window Manager，Notification Manager）和媒体服务（包括播放和录制的媒体服务）

1.4 硬件抽象层（HAL）

硬件抽象层（HAL）定义了一个标准接口用于硬件厂商的实现. HAL允许功能实现，而不会影响或修改上层的系统。HAL的实现被打包成模块（.so）文件，并在适当的时候被加载进Android系统。

1.5 Linux内核（Linux Kernel）

个人感觉android 就是在linux 上写了一层 java 服务，然后在service之上写了一层GUI.

Syscall && JNI

• Native与Kernel之间有一层系统调用(SysCall)层，见Linux系统调用(Syscall)原理;
• Java层与Native(C/C++)层之间的纽带JNI，见Android JNI原理分析。

实例分析:

• Application framework, 应用程序框架包括使用android.media API与audio硬件交互的app代码.在内部，这个代码调用相应的JNI类来访问与audio硬件交互的native代码。

• JNI, JNI代码关联android.media调用native代码来访问audio硬件. 

• Native framework, native框架提供一个相当于android.media包的本地框架，调用IPC代理来访问媒体服务器的音频专用的服务。

• Binder IPC, IPC代理可跨进程通信

• Media server，媒体服务包括audio服务，是真正与HAL实现层交互的代码。

• HAL，HAL定义了audio服务调用的标准接口，audio硬件必须正确实现的功能。

• Kernel driver,audio驱动是与硬件和HAL实现的交互。可以使用Linux声音架构(ALSA),开发声音系统(OSS),或者自定义的驱动（HAL与驱动程序无关）。

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
下面引用<老罗的android之旅>

Android专用驱动(binder)
Android硬件抽象层
Android应用程序组件
Android应用程序框架
Android用户界面架构
Dalvik虚拟机

 

四大组件(砖头) Activity -- UI、交互 Service -- 后台计算 Broadcast Receiver  -- 广播 Content Provider -- 数据

Android用户界面架构

窗口管理框架 Window;WindowManagerService;SurfaceFlinger
详见：https://blog.csdn.net/fdsafwagdagadg6576/article/details/11635552

组件设计思想

组件化背景;组件化设计;组件化;支持 一个小实验

基本思想 Everything is component
具体实现;程序由组件组成;组件与进程剥离;组件皆程序入口

程序由组件组成 Activity：前台交互 Service；后台计算 Broadcast Receiver；广播通信 Content Provider；数据封装

组件与进程剥离: 组件关闭时，进程可以继续存在 ;进程关闭时，组件可以继续存在 

组件皆程序入口 Activity -- onCreate Service -- onCreate Broadcast Receiver -- onReceive Content Provider -- onCreate

谁来负责组件的启动和关闭？ 谁来维护组件的状态？ 谁来管理组件运行时所需要的进程？ 组件之间如何进行通信？

Activity Manager Service 启动组件.关闭组件.维护组件状态. 进程管理
Binder 为组件间通信提供支持 ;高效的IPC机制

应用程序消息处理机制 -可以参见handler机制处理文章
，，，，，，，，，，，，，，，，，，，，，，，，，，，，，

略：Android应用程序资源管理框架

代码和资源分离

资源分类 assets& res: animator anim color drawable layout menu raw values xml
Android资源编译 写了很多steps和源码，但是没感觉有什么用