16、多进程与内存：Android多进程模型、进程间通信（Binder/AIDL）、ContentProvider跨进程、内存共享与隔离

说到多进程，很多同学第一反应是「我为什么要用多进程？」。嗯，这个问题我当年也问过自己。直到我在一个视频直播项目里，遇到了OOM——主进程里既有UI渲染，又有视频解码，还有网络请求，内存直接飙到400MB。那时候我才意识到，多进程不是炫技，是保命的手段。

说白了，Android给每个进程分配的内存是有上限的。不同厂商、不同机型，这个值从128MB到512MB不等。你一个进程吃完了，系统就给你一刀——OOM。但如果你把任务拆到多个进程里，每个进程都有自己的独立内存池，那你能用的总内存就翻倍了。

Android多进程模型

Android的多进程，不是你想开就开的。它有一套自己的规则。最常见的开启方式，就是在AndroidManifest.xml里给四大组件（Activity、Service、Receiver、Provider）指定android:process属性。

<!-- 主进程默认不写 -->
<activity android:name=".MainActivity" />

<!-- 单独开一个进程 -->
<service
    android:name=".MusicService"
    android:process=":music" />

<!-- 全局进程，以包名开头 -->
<provider
    android:name=".FileProvider"
    android:process="com.example.app.fileprocess" />

这里有个细节：:music 这种写法，进程名前面会自动加上包名，而且这个进程是私有进程，只有你的App能用。而 com.example.app.fileprocess 这种全路径写法，是全局进程，其他App如果知道名字，也能跟你共享这个进程。

进程间通信：Binder与AIDL

多进程开了，问题也来了——进程之间怎么说话？Android的答案是Binder。Binder是Android独有的IPC机制，它比Linux传统的Socket、管道、共享内存都要轻量，而且天生支持安全校验。

我个人习惯把Binder理解成一个「远程调用系统」。你在进程A调用一个方法，Binder帮你把参数打包，跨进程传到进程B，执行完再把结果传回来。整个过程对开发者来说，就像调用本地方法一样。

而AIDL，就是帮你生成Binder接口代码的工具。你写一个.aidl文件，定义好接口，Android SDK的编译工具会自动生成对应的Java接口和Stub类。

// IMusicService.aidl
package com.example.app;

interface IMusicService {
    void play(String url);
    void pause();
    void stop();
    int getCurrentPosition();
}

然后你在服务端实现这个接口：

public class MusicService extends Service {
    private final IMusicService.Stub binder = new IMusicService.Stub() {
        @Override
        public void play(String url) {
            // 实际播放逻辑
        }

        @Override
        public void pause() {
            // 暂停逻辑
        }

        @Override
        public void stop() {
            // 停止逻辑
        }

        @Override
        public int getCurrentPosition() {
            return mediaPlayer.getCurrentPosition();
        }
    };

    @Override
    public IBinder onBind(Intent intent) {
        return binder;
    }
}

客户端绑定服务后，拿到IBinder，转成接口就能调用了。整个过程，你不需要关心序列化、反序列化、线程切换——Binder全帮你干了。

ContentProvider跨进程

ContentProvider是Android提供的另一种跨进程通信方式，但它更偏向「数据共享」。说白了，就是你把数据库或者文件暴露给其他进程，让它们用URI来增删改查。

我遇到过这样一个场景：App有两个进程，主进程负责UI，后台进程负责下载。下载完成后，后台进程需要通知主进程更新UI。如果用Binder，你得自己定义接口、处理回调。但用ContentProvider，后台进程直接往数据库里插一条记录，主进程通过ContentObserver监听变化，自动刷新——省事多了。

// 提供者定义
public class DownloadProvider extends ContentProvider {
    @Override
    public Cursor query(Uri uri, String[] projection, String selection,
                        String[] selectionArgs, String sortOrder) {
        // 返回下载记录
    }

    @Override
    public int update(Uri uri, ContentValues values, String selection,
                      String[] selectionArgs) {
        // 更新下载状态
        getContext().getContentResolver().notifyChange(uri, null);
        return updatedCount;
    }
}

// 客户端监听
getContentResolver().registerContentObserver(
    Uri.parse("content://com.example.app/download"),
    true,
    new ContentObserver(new Handler(Looper.getMainLooper())) {
        @Override
        public void onChange(boolean selfChange) {
            // 刷新UI
        }
    }
);

ContentProvider的底层其实也是Binder，但它封装了数据模型和观察者模式，用起来更「声明式」。你只需要定义URI和操作，剩下的交给系统。

内存共享与隔离

多进程最大的好处，就是内存隔离。每个进程有自己独立的Dalvik/ART虚拟机、堆内存、栈空间。一个进程OOM了，其他进程不受影响。这在处理大图片、视频解码、WebView等内存大户时特别有用。

但隔离也带来了问题——数据不能直接共享。你不能像单进程那样，定义一个静态变量，两个线程都能读写。跨进程的数据共享，必须走Binder、ContentProvider、或者文件。

Android也提供了一些共享内存的机制：

• MemoryFile：基于ashmem（Android Shared Memory），可以在进程间共享大块内存，适合传输图片、视频帧。
• Bundle：通过Binder传递，适合小数据量，有大小限制（通常1MB以内）。
• SharedPreferences：多进程模式下不推荐，底层是XML文件，并发写入会丢数据。

我记得有一次，一个同事把用户登录信息放在SharedPreferences里，两个进程都去读写。结果用户登录后，后台进程读到的还是旧数据。排查了半天，最后改成用ContentProvider统一管理，才解决。所以，跨进程的数据共享，一定要用系统提供的IPC机制，别自己搞「黑科技」。

知识体系总览

下面这张图，是我对多进程与内存管理的整体理解。你可以把它当作一个思维导图，快速回顾本章的核心内容。

多进程是一把双刃剑。用好了，内存问题迎刃而解；用不好，通信开销、数据同步、生命周期管理会让你焦头烂额。我的建议是：先想清楚你的内存瓶颈在哪，再决定要不要拆进程。不要为了「多进程」而多进程。