Android之旅[1] - Architecture - android

本文只要是阅读Anatomy-Physiology-of-an-Android的随笔记录。

Anatomy意为解剖，是一种静态视角。Physiology意为生理，是一种动态视角。原文就是通过这两种角度来分析Android的。

Android基于Linux但并不是Linux？

1. 没有本地窗口系统

2. 没有Glibc

3. 并不包括Linux有的Utilities

原文给出的回答并不能算是一个令人信服的理由。删除去掉一些东西，就变形了么？肯定不是啥，掉落只手，那还是人。Android并不是Linux应该从它新添加的部分谈起。Android利用Java语言提供了一个崭新的应用开发环境，有它自己的概念，这才是区别于Linux的不同之处。

为什么选择Linux？

1. 内存和进程管理

2. Permissions-based安全模型

3. 驱动模型

4. 共享库

5. 开源许可

6. 网络栈

Linux的进程和线程都是fork出来的，轻量级，对嵌入式设备有一定的优势。安全模型就是Linux的用户、用户组和其他用户的权限分配，给每个应用进程就是一个用户，分配一个用户ID，它拥有自己的资源，都是文件，通过Linux的访问控制来控制应用的系统访问。驱动模型为各种外围设备定义了统一的驱动框架。Linux的共享库就是so文件，提供了模块复用的能力，降低内存需求。当然最重要的是它是开源的，GPL协议。

Android进行的扩展:

1. Alarm

2. Ashmem

3. Binder 应用和服务之间经常需要进行通信和共享数据，而他们分布在不同的进程空间中。传统的IPC机制有很大的处理负担，还可能存在安全漏洞。

4. 电源管理 Android运行时使用的是电池，电池的容量有限

5. Low Memery Killer

6. Kernal Debugger

7. Logger

Android在底层最重要的改进是Ashmem和Binder。一个用来解决共享内存，一个用来解决进程间通信。Ashmem同Linux自带的mmap区别在于允许更细粒度的内存控制。Binder与其说它解决进程间通信，不如说是Android版的RPC，它制定了一套协议来在C/S模式下进行跨进程的通信访问。Low Memery Killer在电量不足时，杀掉一些不重要的进程，也是为了节省电量。

Binder背后的设计缘由：

• 以驱动的方式提供IPC

• 通过共享内存提高性能

• 每一个进程都有一个线程库来处理Binder请求

• 引用计数，并且这个引用计数是可以跨越进程的

• 支持同步调用

PM（Power Management）背后的设计缘由：

• 基于标准的Linux电源管理

• 更加激进的电源管理策略

• 组件通过wake locks来请求持续供电

• 支持多种不同的wake locks

wake lock是一种锁，可以带有超时，当组件持有锁时，设备就不能休眠。

http://blog.csdn.net/hzdysymbol/article/details/4004791

本地库:

• Bionic Libc是一个专门针对嵌入式设备定制的C库，拥有更快的速度和较少的内存足迹（约200K）。不用GPL Lisence（BSD），实现了一个更小更快的pthread。

• 并不全面支持POSIX。

• 与Gnu Libc (glibc)是不兼容的。

• 所有的本地代码都需要在bionic上重新编译

• 功能库

Webkit

• 基于开源的WebKit: http://webkit.org

• 渲染页面

• 完全的CSS, Javascript, DOM, AJAX支持

• Support for single-column and adaptive view rendering

现在有很多应用通过内嵌一个浏览器核心，通过网页来设计UI。

多媒体框架

• 基于PacketVideo OpenCORE

• 支持标准的音频和视频

• 支持软/硬件解码器插件

SQLite

• 轻量级的事务数据存储

• 大多数数据平台的后端

• 本地服务

区别于系统服务，是用C++实现的一些系统核心服务。在应用框架层存在对应的Java服务访问接口。

Surface Flinger

• 合成并渲染各种Surface（找不到一个合适的翻译，表面？），最后放入显式设备的帧缓存中

• 能够合成2D和3D的Surface，以及来自多个应用的Surface

• Surface通过Binder IPC来传递

• 可以使用OpenGL ES和2D硬件加速

• 使用page-flip的双缓冲

Audio Flinger

• 管理所有的音频输出设备 (earpeace, speaker, bluetooth)

• 将多路音频流处理成PCM输出

• 将音频路由到正确的输出设备

• 硬件抽象层 Hardware Abstraction Libraries

• User space C/C++ library layer

• Not all components have standardized kernel driver interfaces 内核驱动模型不支持

• Kernel drivers are GPL which exposes any proprietary IP 保护公司产权

• Android has specific requirements for hardware drivers

• Defines the interface that Android requires hardware“drivers” to implement

• Separates the Android platform logic from the hardware interface

• 运行时动态加载需要的类库，so文件

Android Runtime

Dalvik虚拟机

• Androidʼs custom clean-room implementation virtual machine

• Provides application portability and runtime consistency

• Runs optimized file format (.dex) and Dalvik bytecode

• Java .class / .jar files converted to .dex at build time

• Designed for embedded environment

• Supports multiple virtual machine processes per device

• Highly CPU-optimized bytecode interpreter

• Uses runtime memory very efficiently

Core Platform Services

Activity Manager
Package Manager
Window Manager
Resource Manager
Content Providers
View System

Hardware Services

• Provide access to lower-level hardware APIs

• Typically accessed through local Manager object

LocationManager lm = (LocationManager)Context.getSystemService(Context.LOCATION_SERVICE);

Telephony Service
Location Service
Bluetooth Service
WiFi Service
USB Service
Sensor Service

Runtime Walkthrough

1. Similar to most Linux-based systems at startup, the

bootloader loads the Linux kernel and starts the init process.

2. Init starts Linux daemons, including:

• USB Daemon (usbd) to manage USB connections

• Android Debug Bridge (adbd) to manage ADB connections

• Debugger Daemon (debuggerd) to manage debug processes requests (dump memory, etc.)

• Radio Interface

3. Init process starts the zygote process:

• A nascent process which initializes a Dalvik VM instance Zygote初始化Dalvik VM

• Loads classes and listens on socket for requests to spawn VMs

• Forks on request to create VM instances for managed processes

• Copy-on-write to maximize re-use and minimize footprint

4. Init starts runtime process:

• Initializes Service Manager – the context manager for Binder that handles service registration and lookup

• Registers Service Manager as default context manager for Binder services

5. Runtime process sends request for Zygote to start System Service

• Zygote forks a new VM instance for the System Service process and starts the service

6. System Service starts the native system servers, including:

• Surface Flinger

• Audio Flinger

7. Native system servers register with Service Manager as IPC service targets

8. System Service starts the Android managed services （Core Platform Services & Hardware Services）

9. Android managed Services register with Service Manager

After system server loads all services, the system is ready…Each subsequent application is launched in itʼs own process

Layer Interaction

There are 3 main flavors of Android layer cake:

• App -> Runtime Service -> lib (Directly) 比如Location Services

• App -> Runtime Service -> Native Service -> lib ( native service) 比如Audio

• App -> Runtime Service -> Native Daemon -> lib (native daemon) 比如ARIL，Telephony

Android之旅[1] - Architecture

更多相关文章

随机推荐