跨进程传图片方案

1. 直接intent传bitmap
2. 使用文件读写
3. intent传递自定义binder，binder中传递image
4. 使用网络传输

直接intent传bitmap

优势

1. 使用简单

劣势

1. 相关代码可能有侵入性，必须在四大组件中接收。
2. intent传递数据的总大小是1MB，其中还包括启动四大组件相关的信息。因此使用intent传递的图片不宜超过500KB，甚至应该更小，因为还可能会传递其他数据。 如果通过此方案传递大图片，必须先压缩后传输。开发者需要自己评估业务场景是否适用，毕竟很多场景不适合让图片质量下降。

如果intent传递的数据超过1MB时，就会报错TransactionTooLargeException。

使用文件读写

优势

1. 使用相对简单
2. 一定程度上可以避免逻辑耦合的问题，对于单独的模块来说只需要负责“读”或者“写”。

劣势

1. 需要自己控制读写的时机。
2. 读写操作相比直接传递效率更低，耗时更长。

intent传递自定义binder，binder中传递image

优势

1. 效率相对最高
2. 传递图片没有大小限制

劣势

1. 使用相对麻烦，需要自定义aidl
2. 相关代码可能有侵入性，必须在四大组件中接收。

使用网络传输

这个方案比较特殊，只有特殊场景才会使用。

一般存在两种情况：

1. 两个进程都与服务端通信，一个进程传输，一个进程接收。 如果是图片上传和下载的场景可以使用，但是效率肯定没有直接传输高。
2. 两个进程一个作为服务端，一个作为客户端。 这个方案的关键在于这个“作为服务端的进程”，需要这个进程本身就是某种图片服务的提供者，且通过网络来对其他进程或模块提供服务度。

intent通过binder传递bitmap的Demo

有兴趣的读者可以自行看下Demo：

github地址 https://github.com/Double2hao/ProcessImageTest

intent通过binder传递bitmap的原理

bitmap在native层传递的时候会有两种方案：

1. 直接将图片写入进程的缓冲区。 缓冲区是进程在初始化的时候就已经申请了的，并且大小是一定的。因此如果写入的大小超过了缓冲区的大小，就会报错。
2. 使用共享内存，将共享内存的fd，也就是文件描述符写入缓冲区。 这样的好处就是传递图片的大小不会受限制。

intent直接传递bitmap对应方案1，intent通过binder传递bitmap对应方案2。

为什么intent传递bitmap不默认使用共享内存？

个人理解，缓冲区的大小是进程创建的时候就申请好的，如果能保证不超出缓冲区大小的情况下使用缓冲区，不需要再另外申请共享内存肯定是最好的。 如果默认就使用共享内存，而缓冲区资源又没人用的话，就造成了资源浪费。

因此如果开发者自己认为需要传递大文件的话，就使用共享内存，默认不使用。