android进程按优先级从低到高分为五类:

1 空进程:没有持有任何活动应用组件的进程,最低优先级,保留空进程的唯一理由是为了提供一种缓存机制,缩短应用下次运行时的启动时间。空进程在系统资源紧张时会被首先清除,但为了提高Android系统应用程序的启动速度,Android系统将会将空进程保存在系统内存中,在用户重新启动该程序时,空进程会被重新使用。

2 后台进程:不包含任何已经启动的服务,没有用户可见的Activity的进程。系统资源紧张时,系统将优先清除用户长时间没有看到的后台进程。

3 服务进程:使用 startService() 方法启动正在运行的服务且不属于可见或前台进程。

4 可见进程:可见但非活动进程,部分程序界面能够被用户看见,却不在前台与用户交互,不影响界面事件的进程。极少数的情况下,Android系统会为了保证前台进程的资源而清除可见进程。

5 前台进程:与用户交互的活动进程,优先级最高

android进程简介:

kthreadd进程: 是所有内核进程的父进程,2号进程

init进程 : 是所有用户进程的父进程(或者父父进程),1号进程

init进程是被kernel中的kernel_init函数通过execve系统调用进行的初始化。

init进程的代码位置:system/core/init/init.c 

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

system_server:是由zygote孵化而来的,是zygote的首席大弟子,托起整个Java framework的所有service,比如ActivityManagerService, PowerManagerService等等。

mediaserver:是由init孵化而来的,托起整个C++ framework的所有service,比如AudioFlinger, MediaPlayerService等等。android新版改名为audioserver

servicemanager:是由init孵化而来的,是整个Binder架构(IPC)的大管家,所有大大小小的service都需要先请示servicemanager。

android 服务进程 查看手机 安卓进程和服务_android 服务进程 查看手机

Kthreadd子进程名(都是内核进程,用户都是root)

解释

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



init子进程名

进程文件

作用

zygote

/system/bin/app_process

Java界的第一个进程,分32位和64位

servicemanager

/system/bin/servicemanager

所有的服务都要最终注册在这个进程中,有它来进行管理这些服务。

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

用于调试程序异常退出

rild

/system/bin/rild

发短信,打电话等应用,会和rild进行通信,而rild再和baseband模块进行通信,从而实现发短信,打电话功能。

installd

/system/bin/installd

安装的守护进程

surfaceflinger

/system/bin/surfaceflinger

UI帧相关的进程



zygote子进程名

解释

system_server

Java framework的各种services都依赖此进程

com.android.phone

电话应用进程

android.process.acore

通讯录进程

android.process.media

多媒体应用进程

com.android.settings

设置进程

com.android.wifi

Wifi应用进程



Zygote子线程名

解释

ReferenceQueueD

引用队列的守护线程

FinalizerDaemon

析构的守护线程

FinalizerWatchd

析构监控的守护线程

HeapTrimmerDaem

堆整理的守护线程

GCDaemon

执行GC的守护线程

这5个线程都是与虚拟机息息相关的线程,之后所有由Zygote直接或间接孵化的子进程,都会包含这5个线程。

Java Framework中的service都运行在system_server进程中,system_server内的子线程很多,统计了下自己身边的手机有system_server有122个线程。ActivityManagerService线程是一个ServerThread线程。进程结构体task_struct的comm字段是一个长度为16的char型,故进程名最长为15个字符。下面列举部分子线程:

线程名

解释

system_server

包含4个此同名线程

Heap thread poo

异步的HeapWorker, 包含5个

Signal Catcher

捕捉Kernel信号,比如SIGNAL_QUIT

JDWP

虚拟机调试的线程

ReferenceQueueD

用于GC

FinalizerDaemon

用于GC

FinalizerWatchd

用于GC

HeapTrimmerDaem

用于GC

GCDaemon

用于GC

Binder_

IPC线程, 包含16个

Thread_

普通线程,包含若干个

AsyncTask #

异步任务,包含若干个

RenderThread

渲染线程,可以包含若干个

ActivityManager

ActivityManagerService线程

PerformanaceCont

system_server专有

FileObserver

system_server专有

CpuTracker

统计进程CPU信息

PowerManagerSer

system_server专有

PackageManager

system_server专有

watchdog

system_server专有

WifiMonitor

system_server专有

UEventObserver

system_server专有



AudioPolicyService和AudioFlinger在libaudioflinger库中,驻留于mediaserver系统进程中;

AudioTrack、AudioRecorder在libmedia库中,应用进程。

media server子线程名

mediaserver

ApmTone

ApmAudio

ApmOutput

Safe Speaker Th

AudioOut_2

FastMixer

AudioOut_4

FastMixer

AudioOut_6

Binder_1

Binder_2

app子线程

线程名

解释

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问题

1主线程是由 Zygote母体生成的;

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