1. 先搞清楚：系统调用到底是"谁在叫谁"
很多 Android 开发者聊到性能优化、卡顿排查时，动不动就冒出一句"这里涉及系统调用，开销很大"。但你要追问一句：系统调用到底是什么？谁在调？被调的是谁？十个人里有八个会卡壳，剩下两个会扔给你一段晦涩的内核源码。
我用一句大白话给你说清楚：系统调用就是 App 里的用户代码，通过内核提供的入口，请内核帮忙干一件用户态干不了的事。
注意两个关键词：一个是"入口"，一个是"干不了"。Android 应用跑在用户态，你写的 Java/Kotlin 代码最终会编译成机器指令，由 CPU 在用户态执行。用户态能做的操作非常有限——算个加法、做个循环、操作自己内存里的变量，这些都没问题。但一旦涉及硬件资源、其他进程的内存、文件系统、网络协议栈，用户态就完全没辙了。因为内核不允许你绕过它直接碰这些核心资源，否则随便一个 App 就能读走银行应用的密码数据，那整个系统就崩了。
所以内核把所有敏感操作封装好，对外暴露统一入口，用户态程序通过一条特殊指令跳进内核态执行，执行完再跳回来。这个"跳进跳出"的过程，就是系统调用。
Android 里最常见的入口是 libc 库。你在 C/C++ 层调open()、read()、write()、socket()，在 Java 层调FileInputStream.read()，最终都会一路透传到 libc 的对应函数，再由 libc 触发那一条特殊指令。
ARM64 架构下，这条指令是svc #0。执行它之前，把系统调用号放进x8寄存器，参数放进x0到x5寄存器，然后一条svc下去，CPU 切到内核态，内核根据x8里的号码找到对应的内核函数，执行完结果写回x0，再切回用户态。
这个流程你可以理解为去政务大厅办事：你（用户态程序）不能直接进库房拿文件（内核资源），只能在窗口（系统调用入口）提交申请单（参数），窗口后面的人（内核）帮你把事办了，再把结果递出来。每个窗口办的事都编了号，ARM64 下open是 56 号，read是 63 号，write是 64 号，这些编号就是系统调用号。
搞清楚了这一点，你再看 Android 开发的很多问题，视角完全不一样。
1.1 用户态与内核态：Android 为什么非要把事情分成两层
你可能想问：为什么非得搞这么麻烦？让 App 直接操作硬件不行吗？
不行，真不行。这里面有两层原因。
第一层是安全。手机是你随身携带的设备，里面存着照片、聊天记录、支付信息。如果任何 App 都能直接访问物理内存、直接读写磁盘扇区，那整个系统毫无隐私可言。内核强制把所有资源访问集中管理，App 想要任何资源都必须经过内核审核，这个审核就是权限机制的基础。
第二层是稳定。如果 App 能直接操作硬件，一个 App 写崩溃了把内存写坏、把文件系统搞乱，整个手机就直接死机重启。有了内核这层隔离，App 最多把自己弄崩溃，内核还在，系统还能把 App 杀掉继续跑。
Android 的 zygote 进程孵化机制、四大组件的进程管理，全建立在这套"用户态 + 内核态"的隔离之上。你杀一个后台 App，本质是向内核发起一个kill()系统调用，内核去终止对应进程。
1.2 Android 里的"翻译官"：libc 与 syscall 指令
接着往下挖一层：Java 层代码是怎么一路走到svc指令的。
举个例子，你在 Java 里写FileInputStream.read(buffer)，这行代码的执行路径是这样的：
FileInputStream.read()是 Java 方法，内部调用IOUtils.read()，最终走到 native 方法。- native 方法对应 ART 虚拟机里的 JNI 实现，调到 libc 的
read()函数。 - libc 的
read()内部把参数设置好，执行svc #0。 - CPU 进入内核态，调用内核的
sys_read()（对应 Android 内核的ksys_read()实现）。 - 内核从文件系统缓存或磁盘驱动读取数据，拷到用户态 buffer。
- 原路返回，你的
read()调用拿到字节数。
中间每一层都是开销。JNI 调用本身比普通 Java 方法调用慢，svc指令比普通指令慢得多。所以 Android 官方一直强调减少主线程的 I/O 操作，因为你每调一次read()，背后都是一整套"用户态切内核态再切回来"的流程。
ARM64 的svc #0设计很有意思。它的开销大约几百纳秒到几微秒不等，取决于内核在做什么。getpid()这种纯粹读取进程信息的，因为有 vDSO（虚拟动态共享对象）优化，甚至不需要真的切内核态就能在用户态完成。这也是为什么你用System.nanoTime()测getpid()耗时会发现它快得不可思议。
1.3 一次 read() 的完整旅程
我把read()的调用过程拆成一张表格，方便你对号入座：
| 环节 | 执行者 | 说明 |
|---|---|---|
| Java 层 | FileInputStream.read() | 调用 native read |
| JNI 层 | ART 的ReadBytes() | 处理数组和偏移 |
| libc 层 | read(fd, buf, count) | 设置寄存器参数 |
| 汇编层 | svc #0 | 陷入内核态 |
| 内核层 | ksys_read() | 根据 fd 找到文件对象 |
| 驱动层 | 对应文件系统实现 | 从 cache/磁盘读取 |
| 返回层 | svc返回用户态 | 结果写入x0寄存器 |
这张表里最容易忽略的是第 5 行。内核拿到 fd，要先检查这个 fd 是否合法、是否属于当前进程、权限是否允许。Android 上很多"文件打不开"的错误，根子都出在这一步。比如你用FileInputStream打开/data/data/你的包名/databases/xxx.db，内核会做严格的我能访问吗检查，一旦不满足就返回EACCES。
2. Binder：Android 系统调用里最特殊的那个
如果说文件系统、网络协议栈的系统调用是"通用课"，那 Binder 就是 Android 专属的"特长生"。
很多人初学 Binder 会陷入源码泥潭，被各种代理、Stub、transact 绕晕。我建议你退一步，先只看一个点：Binder 本质上也是通过系统调用完成的。只是它走的是ioctl()这条路。
ioctl是"设备控制"类系统调用的统称，通过它往驱动发指令。Binder 驱动在 Linux 内核里是 Android 增加的字符设备驱动/dev/binder。App 往 Binder 驱动发消息，做的是ioctl(fd, BINDER_WRITE_READ, &bwr)。这个调用会触发内核里binder_ioctl()，再走到binder_thread_write()/binder_thread_read()。
也就是说，你在 Activity 里bindService()拿到一个 ServiceConnection，背后发生在进程间的数据传递，全都是靠一次次的ioctl系统调用撑起来的。
2.1 为什么 Android 不用纯 SysV IPC
既然 Linux 内核已经有管道、消息队列、共享内存这些进程间通信手段，Google 为什么非得另搞一个 Binder？
核心原因是安全和性能的平衡。传统 SysV 共享内存能做到大吞吐，但没法在共享区域里做精细权限校验；管道和消息队列倒是安全，但每次传递都要拷贝两份数据，性能拉胯。
Binder 走的内核路径做了特殊优化：一次数据拷贝。发送进程把数据写到 Binder 驱动，驱动直接映射到接收进程的地址空间，减少一次用户态拷贝。配合对每个 Binder 事务做身份校验（UID、PID、权限），实现了"一次拷贝 + 完整安全校验 + 支持跨进程"。
你看到的startActivity()最终也是 Binder 调用，系统进程的AMS和你的 App 进程之间就是靠 Binder 传数据。以前面试 Android 岗必问这个问题，我现在面试也还会问：startActivity从发起进程到系统进程，一共发生了哪些系统调用？答上来的候选人通常对系统层面的理解是到位的。
2.2 Binder 在内核里的角色
Binder 驱动在 Android 内核里干的事，我总结成三件：
- 句柄翻译：用户态拿到的是 Binder 句柄，内核维护句柄和底层对象的映射关系。
- 权限校验：每次事务带着调用者信息，内核会检查有没有权限访问目标服务。
- 数据传递：负责把发送进程的用户态 buffer 拷到目标进程，或者做 in-place 映射。
这三件事，每一件都涉及到内核态的调度和管理，所以你频繁做 Binder 调用，系统调用开销非常明显。为什么ActivityManager的接口调用在 tight loop 里会卡顿？因为每次调用都是一整套内核往返，不是普通函数调用那样进了函数体立刻就返回。
2.3 一次跨进程 Binder Call 的系统调用过程
以最常见的startActivity()为例，实际发生的过程是：
- App 进程调用
ActivityManager.getService().startActivity()，这是 Java 层。 - Java 层通过
BinderProxy.transact()进入 JNI。 - JNI 层
android_os_Binder_execTransact()配置binder_transaction_data结构体，把 data 字段指向要发送的 Parcel。 - 对 Binder 驱动执行
ioctl(fd, BINDER_WRITE_READ, &bwr)，这是一个系统调用，陷入内核。 - 内核
binder_ioctl()把发送方的数据放进目标进程的事务队列。 - 目标进程（system_server）被唤醒，从它的 Binder 线程池里取一个线程执行
BINDER_WRITE_READ读操作。 - 读完数据后返回用户态，system_server 处理
startActivity逻辑。 - 处理完再往 App 进程发回一个返回值，同样走
ioctl。
这个过程里，App 进程至少经历了 4 次系统调用：发起写、等待读回调、读返回、处理完成。线程还会被挂起和唤醒，涉及调度器。一次简单的 Activity 跳转，肉眼可见的慢就是这样一层层叠加出来的。
3. 文件访问背后的系统调用链：以 /storage/emulated/0 为例
网上关于 Android 文件路径的讨论一直热度很高，尤其是/storage/emulated/0/Android/data/包名/files/...这种又长又绕的路径，各种无法访问、权限不足的问题不断被搜出来。
这些问题的本质，要从系统调用层面理解。你打开/storage/emulated/0/Android/data/com.tencent.tmgp.sgame/files/pandora/...这类路径时，你的 App 并不是直接访问物理分区上的目录，中间隔了好几层：FUSE（用户空间文件系统）、sdcardfs、内核 vfs、底层文件系统。
3.1 这个路径背后的调用链
正常用户空间进程访问/storage/emulated/0/下的路径，涉及这些系统调用：
| 系统调用 | 作用 |
|---|---|
openat() | 打开目录或文件句柄 |
stat()/fstat() | 获取文件元数据（大小、权限、时间戳） |
getdents() | 读取目录项列表 |
access() | 检查文件可访问性 |
read()/write() | 读写数据 |
fsync() | 把脏数据刷入磁盘 |
Android 的ExternalStorageProvider、媒体库扫描、SAF 文档选择器，全都在走这些调用的变体。很多"文件存在但 App 看不到"的问题，其实就是因为getdents返回目录项时被 FUSE 层按权限过滤掉了，你以为文件没了，其实它还在物理存储上。
我在开发中遇到过一个典型案例：某相册 App 扫不到用户下载目录里的图片，用文件管理器却能直接看到。后来用 strace 跟踪，发现系统调用全部OK，目录列表返回也正常，问题出在 MediaStore 赖以判断的scan_file元数据没更新，FUSE 层的 inode cache 过期了。这就是典型的系统调用层面一切正常，上层协议缓存出错的场景。
3.2 open() 与 access() 的常见误区
很多人会写这样的代码来检查文件是否存在：
File f = new File(path); if (f.exists()) { ... }这段代码最终会走下stat()系统调用。但有三种情况会骗过它：
- FUSE 挂载点的目录本身存在，但子项被隐藏：
stat()返回ENOENT，你以为文件真的不存在，其实是内核层的符号链接或挂载边界问题。 - SELinux 拒绝：
stat()可能返回成功，但紧接着的open()返回EACCES。因为stat走的是路径查找的读取分支，而open需要open权限。 - 符号链接指向的位置无权限：
stat()在没有O_PATH标记时可能返回成功，但实际读文件被拒。
所以生产环境里判断文件是否可读，不要只调exists()，要真正尝试open()一次。这也是为什么 Android 的FileAPI 的canRead()一直不那么可靠——它底层只是做了模式位检查，不是真正去访问文件内容。
3.3 FUSE 与 inotify：很多"玄学"问题的来源
Android 的存储分区前几年做过一次大改，把 fat 格式的 SD 卡模拟成 FUSE 挂载到/storage/emulated/0，后来又改成 sdcardfs 和 FUSE 并存。这个设计导致的结果是：你open("/storage/emulated/0/Download/a.mp3")可能触发不止一次系统调用，还要经过 FUSE 用户空间守护进程。
守护进程（在早期是sdcard，现在是MediaProvider相关的服务）会在用户空间处理文件系统请求，然后把处理结果反馈回内核。也就是说，一次"普通"的文件访问，可能在用户态和内核态之间来回切换两三次，比你在 native 层直接 read 磁盘文件要慢一个数量级。
另一个隐藏点是inotify。很多文件管理器、备份工具依赖inotify监控文件变化，inotify_add_watch()系统调用会注册一个监控点。Android 的 FUSE 层对 inotify 的支持并不完整，某些目录变化事件不会正常上报，这也是很多人觉得"我加了 FileObserver 怎么就是不回调"的原因之一。
FileObserver 底层就是 inotify，但它在 Android 上有个著名 bug：监测/storage/emulated/0/下的目录时，如果目录被一次性创建出很多子文件，事件会丢失。开发文件同步工具时踩过这个坑之后，我都是宁可做轮询也不只依赖 FileObserver，用System.currentTimeMillis()配合目录 mtime（修改时间）做兜底。
4. adb shell 下的系统调用观察实录
知道概念是一回事，真刀真枪去看系统调用又是另一回事。Android 上最直接观察系统调用的工具是strace，但很多人第一次用就发现：设备上根本没有 strace。这里我给你一条完整的操作路径。
4.1 strace 在 Android 上的正确用法
现在的 Android 系统大多不自带 strace，但你可以通过以下方式获得：
- 用 Play 商店或开源仓库下载静态编译的 strace 二进制，常见的有
strace静态编译版，放/data/local/tmp/。 - 通过
adb push推到设备上：
adb push strace /data/local/tmp/ adb shell chmod 755 /data/local/tmp/strace- 然后附着到目标进程：
adb shell su /strace -p PID需要注意，Android 的 SELinux 策略默认会限制ptrace()系统调用，所以 strace 附着进程时经常提示operation not permitted。如果你 root 了设备，执行setenforce 0能解决问题；但生产环境不要轻易关掉 SELinux，有针对性的加 permissive domain 规则更稳妥。
在 Android Studio 的 DDMS 时代，它自带一个类似 strace 的 sysinfo 工具，能对 App 进程做系统调用统计。现在 Android Studio 的 CPU Profiler 里也能看到部分系统调用，但信息粒度很粗。真要精调性能，还是得靠命令行 strace 加参数过滤。
/strace -f -e trace=file -p 1234-f表示跟踪子线程，-e trace=file只显示文件类系统调用，这样能过滤掉大量噪音。如果是分析网络问题，改成-e trace=network。我曾经用这条命令抓到一个第三方 SDK 在后台疯狂扫描文件目录的证据，参数是：
/strace -f -e trace=getdents,openat,stat -p 5678输出会告诉你它到底打开了哪些路径、比对了几次文件、有没有无意义的系统调用重复。这个信息在优化启动耗时和电量消耗时非常有用。
4.2 从 logcat 到 dmesg：怎么找"谁在乱调"
系统调用层面的问题，有些能从 logcat 看到（比如引发-1错误码的open），有些只能从 dmesg 看。比如内核打印SELinux: denied记录，你搜关键字 "avc:" 就能看到是哪条系统调用被拦了。
我处理过一个需要访问共享目录的场景：App 读取一个系统其他应用创建的文件，总是报权限不足。查 logcat 没线索，看 dmesg 发现：
avc: denied { open } for pid=1234 comm="xxx" name="config" dev="dm-3" ino=123 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:system_data_file:s0 tclass=file permissive=0这条信息直接告诉你是 SELinux 策略拒绝的，目标文件的安全上下文是system_data_file，不是你的 App 能打开的类别。搞清楚了之后，要么让文件创建方放对目录（放到/sdcard这类公共区域），要么申请放宽 SELinux 规则，问题很快定位。
这类排查的价值在于：有时候你以为是自己代码逻辑问题，调了半天参数都没用，实际是内核层直接把你拦住了。系统调用这条线不能断。
4.3 一个真实的 SIGSYS 崩溃排查
还有一个很值得说道的情况：App 崩溃在SIGSYS。SIGSYS是非法系统调用信号，一般不会出现在应用开发里，但它一旦出现就很致命，且报错堆栈往往莫名其妙。
我遇到过：App 在某个 Android 10 设备上运行崩溃，异常报告显示SIGSYS (bad system call)。常规的 Java 异常栈根本看不到有效信息，因为崩溃发生在 native 层。后来用strace跟踪，发现进程调用了某个不在白名单里的系统调用号（比如新的faccessat2），而内核配置的内核接口策略没放开，直接发信号杀掉进程。
后来打听到，是某个 SDK 的 native 代码在检测 CPU 架构时用了一个挺新颖的 syscall，型号较旧的设备内核没实现，就触发了 SIGSYS。解决办法是升级内核驱动，或者在 SDK 里做老内核兼容判断。
这类问题，是典型的不看系统调用层就完全没法解的谜案。
5. 开发者必须知道的三类"系统调用坑"
看完了工具，再说说开发中那些最容易踩的坑。大部分开发者不会像系统工程师那样细抠每一条系统调用，但有些坑一旦踩上，排查几周的代价会远超你提前理解系统调用的成本。
5.1 errno 不会说谎：EACCES 与 EPERM 的区别
系统调用失败时，返回值通常是-1，真正的错误原因放在errno里。Android 上最常见也最容易被混淆的，是EACCES（权限不足）和EPERM（操作不允许）。
举个例子，你open("/data/data/other.package/shared_prefs/x.xml")，返回EACCES，说明你没有权限访问其他应用的数据目录，这是权限机制在正常发挥作用。但如果你open("/proc/self/attr/current")试图写文件，返回的可能是EPERM，因为内核明确禁止这种操作，不是因为权限不够，而是操作本身被禁止。
这两个错误的排查方向完全不同。看到EPERM优先级先查 SELinux 是不是把调用卡住了；看到EACCES优先查文件权限、所属 uid/gid（用户ID/用户组ID）、存储是否分区隔离。很多开发者在这上面栽过跟头——明明看权限位是rwxrwxrwx，为什么还是访问失败？因为只看文件模式位根本不够，还要看 SELinux 标签和挂载点的交叉权限。
5.2 32 位与 64 位 syscall 不兼容问题
Android 十年前就普及 64 位系统了，但实际开发里还是有大量历史遗留问题。32 位系统调用号和 64 位系统调用号并不一致，比如sys_open在 32 位里是 5 号，在 64 位里是 56 号。如果你的 native 库是老工具链编出来的，它可能硬编码了 32 位的调用号，在 64 位进程里跑就会调用到一个根本不是 open 的函数上，轻则返回异常，重则 SIGSYS。
这类问题从strace里看特别明显：明明调的是open()，实际发生的系统调用号却对应到另一个函数。排查的方法就是看 strace 输出的调用名和系统调用号是否匹配。如果发现你的 App 只在 64 位设备出问题，第一反应就应该是 look for 硬编码 syscall 号的代码。
5.3 文件描述符耗尽：Too many open files
Android 对进程可打开的文件描述符数量有限制，现代设备一般是 1024 或 10240，具体看内核配置。排查这个问题，也是靠系统调用层面的观察：
adb shell su ls /proc/PID/fd | wc -l # 统计当前进程的 fd 数量 cat /proc/PID/limits # 查看进程的 fd 上限持续增长的 fd 数量绝大多数来自open()和socket()。你可以用 strace 统计：
/strace -f -e trace=openat,close -p PID观察openat和close是否成对出现。如果openat明显多于close，恭喜你找到了泄漏源。我之前排查过一个问题：某个图片加载库在 Android 12 上频繁崩溃，报Too many open files，从ls /proc/PID/fd看大量 fd 指向的路径都是同几张图片。这是因为新版本库调整了缓存策略，缩略图文件的 fd 没有及时释放，最后升级库版本并在代码里显式recycle()解决。
6. 开发中怎么用系统调用视角定位问题
写到这里，我想你大概已经有点感觉了：很多看似复杂、玄学的问题，一旦切换到系统调用视角，思路会清晰很多。下面这套是我总结的实战排查套路，不一定适合所有团队，但确实帮我省下过大量时间。
6.1 优先看 errno，不要猜
遇到文件、网络、进程类的问题，第一反应不要先怀疑上层逻辑，先看系统调用返回的错误码。Java 层抛出的IOException，你去看 message 往往只有一句话，但底层 errno 能告诉你更多。比如ENOSPC（设备上没有空间）和EIO（输入输出错误）都是 I/O 失败，但前者是磁盘满了，后者是硬件或文件系统出问题了，处理方案天差地别。
Android 上adb shell su -c "echo 1 > /proc/sys/kernel/printk"可以临时打开更多内核日志。当 App 抛出异常但信息不够时，去 dmesg 里搜对应的 pid 和路径，经常能找到被 SELinux 拦截或者文件系统报错的具体原因。
6.2 strace 是最后手段，也是最快手段
很多人找我排查问题，上来就问"我的 App 卡死了，有什么工具能定位？"。我建议你先分条件：如果是偶发性问题，先看 logcat；如果很容易复现，直接 strace 抓系统调用是最效率的路径。打开 strace 之后别急着看全部，找这几类：
- 重复执行的
stat/access：多半是代码里反复判断文件是否存在，缓存了事。 - 阻塞过久的
read/write：注意看耗时，如果某次read卡了几秒，多半是磁盘慢或者锁竞争。 - 频繁出现的
open+close：典型的文件打开太多次没复用，可以试试缓存 fd 或改用内存映射。
6.3 善用 atrace 与 perfetto
strace 只能告诉你进程调了什么，不能告诉你这些调用在整体 timeline 上怎么分布。要看全局，用 Android 自带的atrace：
adb shell atrace --async_start -b 4096 sched freq idle binder_driver抓完再 pull 出来用 Perfetto 打开，能直观看到主线程阻塞期间是哪个系统调用占用了 CPU，或者哪个 Binder 事务卡了太久。我曾经在一份 Perfetto 报告中看到，某个 App 启动慢的元凶是一个后台线程在持续做文件扫描，主线程的 Binder 调用被系统进程的锁拖住，这种跨进程的因果链，光看代码是找不到的。
6.4 写 native 代码时，尽量避免频繁系统调用
最后分享一点 engineering 层面的经验：如果你的核心代码要做大量小文件的读写，或者频繁获取时间、进程信息，尽量把多次操作合并成一次大调用。比如把 100 次小的read()合并成 1 次大的 buffer 读取，能明显降低系统调用的次数和上下文切换开销。很多性能敏感的场景，比如视频编码、数据库写盘，都讲究批量提交（batch）。
我自己在写一个日志落盘的组件时，一开始是每行日志调一次write()，后来改成缓冲区满 64KB 才刷一次，耗时直接下降了一个数量级。这背后的原理就是减少了系统调用的频次。
系统调用这条知识线，看起来枯燥，但它把 Android 的权限体系、进程通信、I/O 性能、安全模型全部串在了一起。你在开发中遇到的很多"反直觉"问题，比如数据明明存在但读不到、进程间通信偶尔很慢、native 层莫名崩溃，回到系统调用这一层去思考，往往能找到答案。这篇文章只是把前篇的内容补齐，后面如果有机会，我会继续聊聊内核里具体的 fs 层实现和跨进程调用的性能剖析方法。
