第22章多进程架构优化

课程目录第22章多进程架构优化

多进程架构优化：Android多进程通信与内存平衡

说实话，多进程架构这个话题，很多开发者一听就觉得头大。我刚开始接触Android时也觉得，好好的单进程不香吗？干嘛要搞这么复杂？直到我在一个视频直播项目里，遇到了内存暴涨导致OOM的惨痛教训——嗯，那次之后我才真正理解了多进程的价值。

为什么需要多进程？

你想想看，Android给每个应用分配的内存是有上限的。低端机可能只有64MB，高端机也不过512MB左右。当你的应用功能越来越多，比如同时要做视频播放、图片加载、WebView渲染、后台定位……单进程很容易就撑爆了。

多进程的核心好处就两个：

突破内存限制：每个进程独立分配内存，相当于变相扩容
隔离崩溃风险：一个进程挂了，不影响其他进程

我在项目中遇到过最典型的场景：WebView是个内存大户，单独扔到一个进程里，主进程就算被回收了，WebView进程还能继续工作。用户回来时，页面还在，体验好很多。

  核心原则：多进程不是银弹。每增加一个进程，系统开销就增加一份。我个人的习惯是，非必要不拆分，拆了就一定要做好通信设计。

Binder/AIDL：Android多进程通信的基石

多进程之间怎么通信？Android用的是Binder机制。说白了，Binder就是一套跨进程调用（IPC）的框架。你不需要理解底层驱动怎么工作的，但要知道怎么用AIDL定义接口。

来看一个我常用的模板：

// IRemoteService.aidl
interface IRemoteService {
    int add(int a, int b);
    String getProcessInfo();
    void registerCallback(IRemoteCallback callback);
}

// IRemoteCallback.aidl
interface IRemoteCallback {
    void onResult(String data);
}

服务端实现：

public class RemoteService extends Service {
    private final IRemoteService.Stub binder = new IRemoteService.Stub() {
        @Override
        public int add(int a, int b) {
            return a + b;
        }

        @Override
        public String getProcessInfo() {
            return "Process: " + android.os.Process.myPid();
        }

        @Override
        public void registerCallback(IRemoteCallback callback) {
            // 保存回调引用，注意要使用RemoteCallbackList
        }
    };

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

客户端调用：

private IRemoteService remoteService;
private ServiceConnection connection = new ServiceConnection() {
    @Override
    public void onServiceConnected(ComponentName name, IBinder service) {
        remoteService = IRemoteService.Stub.asInterface(service);
        try {
            int result = remoteService.add(3, 5);
            Log.d("TAG", "Result: " + result);
        } catch (RemoteException e) {
            e.printStackTrace();
        }
    }

    @Override
    public void onServiceDisconnected(ComponentName name) {
        remoteService = null;
    }
};

避坑指南：我曾经在回调注册上踩过大坑。直接用List保存跨进程回调对象会导致内存泄漏，因为Binder对象在服务端和客户端是不同实例。一定要用RemoteCallbackList，它会帮你处理跨进程的引用管理。

进程保活与内存占用的平衡艺术

进程保活是个敏感话题。说实话，Android系统越来越严格，从API 26开始后台限制就很强了。我个人的观点是：不要跟系统对着干，而是要学会「顺势而为」。

常见的保活策略对比：

策略	效果	内存开销	推荐度
前台Service（带通知）	高	低（约5MB）	⭐⭐⭐⭐⭐
双进程互相唤醒	中	中（约10MB）	⭐⭐⭐
JobScheduler定时拉活	低	低	⭐⭐⭐⭐
系统广播拉活	低（高版本无效）	低	⭐

我最推荐的方式是前台Service + 合理的内存控制。举个例子：

public class KeepAliveService extends Service {
    @Override
    public void onCreate() {
        super.onCreate();
        // 创建前台通知
        Notification notification = new NotificationCompat.Builder(this, CHANNEL_ID)
                .setContentTitle("服务运行中")
                .setContentText("保持后台稳定运行")
                .setSmallIcon(R.drawable.ic_notification)
                .build();
        startForeground(1, notification);
    }

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        // 控制内存占用：定期清理缓存
        scheduleMemoryCleanup();
        return START_STICKY;
    }

    private void scheduleMemoryCleanup() {
        // 每30分钟检查一次内存，超过阈值就主动释放
        new Handler().postDelayed(() -> {
            ActivityManager am = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
            ActivityManager.MemoryInfo mi = new ActivityManager.MemoryInfo();
            am.getMemoryInfo(mi);
            if (mi.availMem < mi.threshold) {
                // 释放缓存、关闭闲置连接
                LruCache.clear();
                // 通知主进程进行内存回收
                notifyMainProcessToTrim();
            }
            scheduleMemoryCleanup();
        }, 30 * 60 * 1000);
    }
}

注意：不要滥用保活。我曾经见过一个应用开了3个前台Service，结果系统直接把它标记为「耗电大户」，反而更容易被杀死。保活的核心是「低内存占用 + 高用户价值」，让系统觉得杀掉你不划算。

跨进程数据共享方案

多进程之间除了用Binder通信，数据共享也是个头疼的问题。我整理了几种常用方案：

ContentProvider：适合结构化数据共享，自带权限控制
SharedPreferences（不推荐）：多进程读写会出问题，我踩过这个坑
文件共享：适合大文件，注意同步问题
MMKV：腾讯开源的跨进程KV存储，性能比SP好很多
数据库（Room/SQLite）：适合复杂查询，注意连接池管理

我个人最常用的是MMKV，因为它简单高效：

// 初始化（在Application中）
MMKV.initialize(this);

// 进程A写入
MMKV kv = MMKV.defaultMMKV();
kv.encode("user_token", "abc123");
kv.encode("login_time", System.currentTimeMillis());

// 进程B读取
MMKV kv = MMKV.defaultMMKV();
String token = kv.decodeString("user_token", "");
long loginTime = kv.decodeLong("login_time", 0);

如果数据量比较大，我会选择ContentProvider + 数据库的方式。注意要开启数据库的多进程模式：

// 在Room中开启多进程支持
@Database(entities = {User.class}, version = 1, exportSchema = false)
public abstract class AppDatabase extends RoomDatabase {
    public static AppDatabase getInstance(Context context) {
        if (instance == null) {
            instance = Room.databaseBuilder(context, AppDatabase.class, "app.db")
                    .enableMultiInstanceInvalidation() // 关键：多进程支持
                    .build();
        }
        return instance;
    }
}

经验之谈：跨进程数据共享最怕的就是「数据不一致」。我曾经在支付流程中，进程A写入了订单状态，进程B读到的却是旧数据。后来加上了ContentProvider的notifyChange机制，每次数据变更都主动通知监听者，问题就解决了。

多进程架构的核心流程图

下面这张图是我总结的多进程架构设计要点，你可以对照着检查自己的方案：

总结

多进程架构优化，说白了就是一场「资源与稳定性的博弈」。我做了这么多年性能优化，最大的体会是：不要为了炫技而拆分进程，每个进程的引入都要有明确的收益。

最后分享一个我自己的检查清单：

✅ 每个进程的内存占用是否可控？
✅ 跨进程通信是否使用了Binder/AIDL？
✅ 数据共享方案是否考虑了并发问题？
✅ 保活策略是否在用户感知范围内？
✅ 进程崩溃后是否有恢复机制？

嗯，把这些想清楚了，你的多进程架构基本就稳了。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

多进程架构优化：Android多进程通信与内存平衡

为什么需要多进程？

Binder/AIDL：Android多进程通信的基石

进程保活与内存占用的平衡艺术

跨进程数据共享方案

多进程架构的核心流程图

总结