Linux（Android）下无IPC实现进程间共享易失性内存只读文件的方案问询

原硬编码物理地址思路的可行性判定 #

这套裸机式的实现思路仅在理论上能走通，在Android/Linux生产环境下存在大量不可规避的问题，不具备落地性：

• 地址冲突风险极高：硬编码的物理地址段可能被内核页表、驱动预留、CMA区域、DMA缓冲区占用，直接触发内核panic；且不同内核版本、不同硬件平台的物理内存布局存在偏移，硬编码地址的兼容维护成本极高。
• 权限门槛无法通过：普通用户态进程没有权限直接映射任意物理内存，默认SELinux策略下/dev/mem设备的访问权限会被严格限制，即使临时放开权限，后续系统安全补丁、版本升级也可能回收权限，稳定性没有保障。
• 内存保护机制冲突：没有内核态的统一内存属性管理，多进程映射时无法避免非预期的写操作、缺页错误，一旦某个进程越界写内存，会直接破坏所有进程的共享数据，甚至触发整机崩溃。
• 时序同步成本高：加载文件的进程和映射文件的进程之间必须做额外的状态同步，否则会出现其他进程访问到未加载完成的内存内容的问题，本质上还是绕不开IPC开销。

常见认知误区澄清 #

基于你之前调研的两个普遍误解

• 关于mmap的懒加载特性：mmap的懒加载是可配置的，映射时加上MAP_POPULATE标志，就会在映射阶段直接把所有对应文件的内容批量读入页缓存，完全跳过缺页中断的开销，不存在“必须等访问才加载”的问题；且只要提前预留连续物理内存，完全可以把文件页绑定到指定的物理内存段，不需要依赖默认的动态内存分配。
• 关于ION的共享逻辑：ION的跨进程共享确实需要通过fd传递句柄，但如果把共享内存节点固定为系统全局可访问的路径，根本不需要跨进程传fd，所有进程直接打开固定路径即可完成映射，没有额外IPC开销。

匹配场景的最优实现方案 #

完全贴合你“连续物理内存单副本、启动阶段预加载、多进程只读访问零IPC、极致读取速度、内存资源受限”的核心要求，可按照以下步骤落地：

1. 预留专属连续物理内存
   在Linux内核启动参数中加入内存预留配置，从系统总内存中扣出0.5G+少量余量的连续内存段，不纳入内核常规内存分配器的管理范围，从根源上避免内存碎片、保证物理地址连续。比如总内存4G的设备，可通过mem=3584M参数预留高地址的512M内存段，专门承载该文件内容。
2. 最小化内存映射通道
   写一个极简的内核misc驱动，把预留的连续物理内存段暴露为固定字符设备，配置SELinux策略允许系统启动阶段的专属服务对该内存段做写操作，所有后续访问仅开放只读权限，同时关闭该段内存的交换、页回收属性，保证内容始终常驻物理内存，不会被换出到存储。
   更轻量的替代方案：直接配置系统CMA区域大小为预留的600M，利用CMA本身的连续内存保障能力，不需要额外编写驱动。
3. 启动阶段预加载文件
   在init启动阶段（早于所有业务进程启动）运行专属的预加载服务，完成两个操作：
   • 一次性把目标0.5G文件的内容读入预留的物理内存段，加载完成后将整段内存的属性改为只读
   • 通过memfd_create把这段内存绑定为固定路径的tmpfs文件，文件大小与目标文件完全一致
4. 业务进程零开销映射
   所有需要访问文件的业务进程，直接通过标准mmap系统调用映射这个固定路径的tmpfs文件，映射参数使用PROT_READ | MAP_SHARED | MAP_POPULATE：
   • 物理内存中仅存在一份文件副本，完全符合内存受限的要求
   • 全程没有任何IPC操作，所有进程仅通过固定文件路径完成映射，没有句柄传递、状态同步的开销
   • 配合连续物理内存的大页映射能力，TLB命中率远高于零散物理页的映射方式，实际读取性能比硬编码物理地址的方案更高
   • 没有硬编码地址的兼容性问题，业务进程完全不需要感知底层物理内存的具体地址，跨版本、跨硬件的适配成本极低

内容的提问来源于stack exchange，提问作者user2251965