进程篇—进程整理(转)

一、概括

系统启动架构图:

上图在Android系统-开篇中有讲解,是从Android系统启动的角度来分析,本文是从进程/线程的视角来分析该问题。

1.1 父进程

在所有进程中,以父进程的姿态存在的进程(即图中的浅红色项),如下:

  • kthreadd进程: 是所有内核进程的父进程
  • init进程 : 是所有用户进程的父进程(或者父父进程)
  • zygote进程 : 是所有上层Java进程的父进程,另外zygote的父进程是init进程。

1.2 重量级进程

在Android进程中,有3个非常重要的进程(即图中的深紫色项),如下:

  • system_server:是由zygote孵化而来的,是zygote的首席大弟子,托起整个Java framework的所有service,比如ActivityManagerService, PowerManagerService等等。
  • mediaserver:是由init孵化而来的,托起整个C++ framework的所有service,比如AudioFlinger, MediaPlayerService等等。
  • servicemanager:是由init孵化而来的,是整个Binder架构(IPC)的大管家,所有大大小小的service都需要先请示servicemanager。

二、进程

Android进程从大类来划分,可分为内核进程和用户进程。

2.1 kthreadd子进程

kthreadd进程(2号进程),是Linux系统的内核进程,是所有内核进程的鼻祖。

由Kthreadd孵化出来的内核守护进程,这些进程位于系统启动架构图中的kernel的深蓝色块。下面列举常见的内核进程:

进程名 解释
ksoftirqd/0  
kworkder/0:0H  
migration/0  
watchdog/0  
binder  
rcu_sched  
perf  
netns  
rpm-smd  
mpm  
writeback  
system  
irq/261-msm_iom  
mdss_dsi_event  
kgsl-events  
spi  
therm_core:noti  
msm_thermal:hot  

内核进程都不存在子进程与子线程,并且所有内核进程的用户都是root.

每个内核进程的作用,后续再补上

2.2 init子进程

init进程(1号进程),是Linux系统的用户空间进程,或者说是Android的第一个用户空间进程。

下面列举常见的由init进程孵化而来的用户进程:

进程名 进程文件 作用
zygote /system/bin/app_process Java界的第一个进程,分32位和64位
servicemanager /system/bin/servicemanager Binder的守护进程
media /system/bin/mediaserver 多媒体服务的进程
ueventd /sbin/ueventd uevent守护进程
healthd /sbin/healthd 电池的守护进程
logd /system/bin/logd log的守护进程
adbd /sbin/adbd adbd进程(Socket IPC)
lmkd /system/bin/lmkd lowmemorykiller守护进程
console /system/bin/sh 控制台
vold /system/bin/vold volume守护进程
netd /system/bin/netd network守护进程
debuggerd /system/bin/debuggerd 用于调试程序异常退出
debuggerd64 /system/bin/debuggerd64 用于调试程序异常退出
ril-daemon /system/bin/rild Radio Interface Layer的守护进程
installd /system/bin/installd 安装的守护进程
surfaceflinger /system/bin/surfaceflinger UI帧相关的进程
 

servicemanager,作为Binder架构的一个大管家,所有注册服务、获取服务,都需要经过servicemanager,更多关于servicemanager查看Binder系列文章。

2.3 Zygote子进程

Zygote本身是一个Native的应用程序,刚开始的名字为“app_process”,运行过程中,通过系统调用将自己名字改为Zygote。是所有上层Java进程的父进程,android系统中还有另一个Zygote64进程,用于孵化64位的应用进程。

在图中的红色线,便是Zygote fork出来的进程,所有的App进程都是由Zygote fork产生的。

下面列举Zyogte进程孵化的部分子进程

进程名 解释
system_server Java framework的各种services都依赖此进程
com.android.phone 电话应用进程
android.process.acore 通讯录进程
android.process.media 多媒体应用进程
com.android.settings 设置进程
com.android.wifi Wifi应用进程

三、线程

3.1 Zygote 子线程

adb shell终端,输入:

ps -t | grep -E "NAME| 497 "

解释: -E "NAME| 497 " 是输出时能多显示NAME的那一行,方便查看每一列代表的具体含义,497是Zygote的进程号。

共享父进程的地址空间的便是子线程,即VSIZE必然相同,否则就是子进程,如下图:

图中红色圈起来的便是子线程,其他都是子进程。

可见Zygote的子线程如下:

线程名 解释
ReferenceQueueD 引用队列的守护线程
FinalizerDaemon 析构的守护线程
FinalizerWatchd 析构监控的守护线程
HeapTrimmerDaem 堆整理的守护线程
GCDaemon 执行GC的守护线程

这5个线程都是与虚拟机息息相关的线程,之后所有由Zygote直接或间接孵化的子进程,都会包含这5个线程,那么就在其线程说明中,不再重复,而是以“用于GC”的字样来表示。后续有空会专门针对Android的虚拟机展开讨论。

3.2 system_server 子线程

Java Framework中的service都运行在system_server进程中,system_server内的子线程很多,统计了下自己身边的手机有system_server有122个线程。下面列举部分子线程:

线程名 解释
system_server 包含4个此同名线程
Heap thread poo 异步的HeapWorker, 包含5个
Signal Catcher 捕捉Kernel信号,比如SIGNAL_QUIT
JDWP 虚拟机调试的线程
ReferenceQueueD 用于GC
FinalizerDaemon 用于GC
FinalizerWatchd 用于GC
HeapTrimmerDaem 用于GC
GCDaemon 用于GC
android.fg 前台的Looper线程
android.ui UI的Looper线程
android.io IO的Looper线程
android.display display的Looper线程
ActivityManager AMS线程
PowerManagerSer PMS线程
PackageManager PKMS线程
watchdog 看门狗线程
RenderThread 渲染线程
Binder_ IPC线程, 包含16个
CpuTracker 统计进程CPU信息
PerformanaceCont system_server专有
FileObserver system_server专有
WifiMonitor system_server专有
UEventObserver system_server专有
Thread_ 普通线程,包含若干个
AsyncTask # 异步任务,包含若干个

ActivityManagerService线程是一个ServerThread线程。进程结构体task_struct的comm字段是一个长度为16的char型,故进程名最长为15个字符。

3.3 mediaserver 子线程

mediaserver 子线程,如下:

线程名
mediaserver
ApmTone
ApmAudio
ApmOutput
Safe Speaker Th
AudioOut_2
FastMixer
AudioOut_4
FastMixer
AudioOut_6
Binder_1
Binder_2

每个线程的作用,后续再补上

3.4 app 子线程

此处以settings为例

线程名 解释
com.android.settings settings进程
Heap thread poo 异步的HeapWorker, 包含5个
Signal Catcher 捕捉Kernel信号,比如SIGNAL_QUIT
JDWP 虚拟机调试的线程
ReferenceQueueD 用于GC
FinalizerDaemon 用于GC
FinalizerWatchd 用于GC
HeapTrimmerDaem 用于GC
GCDaemon 用于GC
Binder_1 用于IPC
Binder_2 用于IPC
pool-m-thread-n 线程池m中的第n个线程,包含若干个
AsyncTask #1 异步任务
RenderThread 渲染线程
WifiManager 管理wifi的线程

一般地,每个apk都会产生2或3个Binder线程,Apk运行的Activity或service都会产生2个Binder线程。

关于Binder问题

  • 主线程是由 Zygote母体生成的;
  • 线程池:首次创建第一个Binder线程A,然后监听BR_SPAWN_LOOPER事件,收到后创建第二个Binder线程B,线程B继续监听BR_SPAWN_LOOPER事件,收到后创建第三个Binder线程C。总共创建3个Bindr线程,这是Binder协议决定。根据系统处理器数目以及应用程序的负载强度,线程池的线程数目可以动态调整,这是Binder优化需要考虑的。

四、进程统计

下面以一台基于Android 5.1.1的手机为例,统计以“父进程”作为PPID的进程个数统计表:

父进程 个数 解释
0 2 分别为init, kthreadd
init 55 用户进程
kthreadd 303 内核进程
zygote64 41 64位zygote
zygote 3 32位zygote
qseecomd 1 高通安全执行环境
adbd 2 打开了2个adb窗口
sh 2 分别为ps, grep

图中zygote64/zygote/qseecomd/adbd的父进程都是init进程,而sh的父进程是adbd,而adb和qseecomd的父进程都是init进程。

手机总计:407个进程,1575个线程。(该数据仅供参考,让大家对手机当前的进程和线程的数量级有个大概的感观)

转自:http://gityuan.com/2015/12/19/android-process-category/

时间: 2024-10-11 03:55:11

进程篇—进程整理(转)的相关文章

操作系统之进程篇(1)

1.进程介绍: 1.1 进程模型: 进程是一个程序的实际执行,包含了程序计数器的状态,寄存器和变量等等! 程序可以看成是一个状态的序列,程序在不同时刻呈现出不同的状态,而这种状态的前后交替过程可以看成是程序的执行过程.概念上来说,每个程序有自己的虚拟CPU,但在现实中CPU在不同的进程间来回切换,又称这种切换为伪并行! 进程和程序差别看似微小,实际上却是十分精妙; 可以将计算机执行程序的过程看成一次有趣的烹饪过程.食谱就是程序,厨师就是CPU,而食材是输入,得到的输出是鲜美可口的美食. 当厨师在

Linux进程管理知识整理

Linux进程管理知识整理 1.进程有哪些状态?什么是进程的可中断等待状态?进程退出后为什么要等待调度器删除其task_struct结构?进程的退出状态有哪些? TASK_RUNNING(可运行状态) TASK_INTERRUPTIBLE(可中断等待状态) TASK_UNINTERRUPTIBLE(不可中断等待状态) TASK_STOPPED(进程被其它进程设置为暂停状态) TASK_TRACED(进程被调试器设置为暂停状态) TASK_DEAD(退出状态) 进程由于所需资源得不到满足,从而进入

进程篇(1: 进程运行环境)--请参照本博客“操作系统”专栏

2014年5月30日  下午1:40:59 1. Unix 进程执行环境: 1.1 终止处理程序: ISO C 规定,一个程序可以登记多达32个函数,这些函数将由exit自动调用.我们称这些函数为终止处理程序(exit handler),并调用atexit函数来登记这些函数.该函数的原型如下: 1 #include <stdlib.h>2 3 int atexit(void (*function)(void)); exit调用这些终止程序的顺序与他们登记时的顺序相反(先登记后调用).同一个函数

操作系统之进程篇(3)

1. 信号量机制的缺陷问题: 在上面的生产者消费者实例中,信号量的工作机制如下(我们以生产者的代码为例): 1 down(&empty); 2 down(&mutex); 3 enter_item(item); 4 up(&mutex); 5 up(&full); 如果交换1号和2号语句,变成: 1 down(&mutex); 2 down(&empty); 那么可能会出现下面的情形: mutex变成0,此时empty == 0,那么生产者阻塞; 此时消费者

操作系统之进程篇(2)

进程间通信(InterProcess Communication,IPC): 进程通信中遇到的三个问题: a) 进程之间如何进行信息的传递? b) 多个进程在执行自己的核心代码时如何能够不相互影响? c) 当进程之间出现相互依赖关系时,如何才能合理的调度进程的执行顺序! 1. 竞争情形: 当两个或多个进程同时读写某个共享资源的时候,程序运行的最终结果由各个进程的具体执行的情况所决定! 如何避免竞争情形的出现,那么我们首先引入关键代码区的定义: 程序中访问共享内存或其他共享资源的代码区被称为关键代

进程篇(4: 基本进程控制:其他相关控制)--请参照本博客“操作系统”专栏

1. 更改进程的用户ID和组ID:为什么我们要更改用户ID和组ID的呢? 在UNIX系统中,特权是基于用户和组ID的.当用户需要增加特权,或要访问某个当前没有能力访问的文件时,我们需要更改自己的权限,以让新的ID具有合适的特权或访问权限.与此类似,当程序需要降低其特权或阻止对某些资源的访问时,也需要跟换用户ID或组ID;一般而言,在设计应用程序时,我们总是试图使用"最小特权"模型.依照此模型,我们的程序应当值具有为完成特定的任务所需要的最小特权. NAME getuid, geteui

进程篇(2: C程序的存储空间布局)--请参照本博客“操作系统”专栏

1.  C程序的存储空间布局: C 程序由下面几个部分组成: 正文段(即是代码段): 这是由CPU执行的机器指令部分.通常,正文段是可以共享的,并常常是可读的,以防止程序因为意外原因而修改自身的代码! 初始化数据段(即数据段): 它包含了程序中需要明确的赋初值的变量. 非初始化数据段(bss段):在程序开始执行之前,内核将此段中的数据初始化为0或空指针. 栈.自动变量以及每次函数调用时所需保存的信息都存放在此段中.每次调用函数时,返回地址以及调用者的环境信息(如某些寄存器的值)都存放在栈中.然后

操作系统之进程篇(4)--经典进程间通信(IPC)问题

1. 哲学家进餐问题: 问题描述: 五个哲学家在一个圆桌上进餐,每人的面前放了一盘意大利面,两个盘子之间有一个叉子,但是由于盘子里面的面条十分光滑,需要两个叉子才能进行就餐行为.餐桌的布局如下图所示: 假设哲学家的生活中只有两个活动:吃饭和思考[吃饭维持自身之生存,思考探究生存之意义],当然这样的哲学家在现实之中是不存在的.当一个哲学家在殚精竭虑之时,饥饿感随之而来,这是他会拿起左右手边的两个叉子来想享用这俗世之中的美味.酒足饭饱之后,又"躲进小楼成一统,管他春夏与秋冬"去了.问题是:

进程篇(3: 基本进程控制:进程的退出)--请参照本博客“操作系统”专栏

1. exit函数: 进程的五种正常的结束方式: 在main函数中执行return语句,这等效于exit; 调用exit函数.此函数由ISO C定义,其操作包括运行各终止处理程序,然后关闭所有标准I/O流等. 调用_exit或_Exit函数,ISO C定义了_Exit函数,目的是为了为进程提供一种无需运行终止处理程序和信号处理程序而终止的方法.并不处理标准I/O流! 进程的最后一个线程在其启动例程中执行返回语句,然后该进程以终止状态0返回. 进程的最后一个线程调用pthread_exit函数.