- 直接intent传bitmap
- 使用文件读写
- intent传递自定义binder,binder中传递image
- 使用网络传输
- 使用简单
- 相关代码可能有侵入性,必须在四大组件中接收。
- intent传递数据的总大小是1MB,其中还包括启动四大组件相关的信息。因此使用intent传递的图片不宜超过500KB,甚至应该更小,因为还可能会传递其他数据。 如果通过此方案传递大图片,必须先压缩后传输。开发者需要自己评估业务场景是否适用,毕竟很多场景不适合让图片质量下降。
如果intent传递的数据超过1MB时,就会报错TransactionTooLargeException。
- 使用相对简单
- 一定程度上可以避免逻辑耦合的问题,对于单独的模块来说只需要负责“读”或者“写”。
- 需要自己控制读写的时机。
- 读写操作相比直接传递效率更低,耗时更长。
- 效率相对最高
- 传递图片没有大小限制
- 使用相对麻烦,需要自定义aidl
- 相关代码可能有侵入性,必须在四大组件中接收。
这个方案比较特殊,只有特殊场景才会使用。
一般存在两种情况:
- 两个进程都与服务端通信,一个进程传输,一个进程接收。 如果是图片上传和下载的场景可以使用,但是效率肯定没有直接传输高。
- 两个进程一个作为服务端,一个作为客户端。 这个方案的关键在于这个“作为服务端的进程”,需要这个进程本身就是某种图片服务的提供者,且通过网络来对其他进程或模块提供服务度。
有兴趣的读者可以自行看下Demo:
bitmap在native层传递的时候会有两种方案:
- 直接将图片写入进程的缓冲区。 缓冲区是进程在初始化的时候就已经申请了的,并且大小是一定的。因此如果写入的大小超过了缓冲区的大小,就会报错。
- 使用共享内存,将共享内存的fd,也就是文件描述符写入缓冲区。 这样的好处就是传递图片的大小不会受限制。
intent直接传递bitmap对应方案1,intent通过binder传递bitmap对应方案2。
个人理解,缓冲区的大小是进程创建的时候就申请好的,如果能保证不超出缓冲区大小的情况下使用缓冲区,不需要再另外申请共享内存肯定是最好的。 如果默认就使用共享内存,而缓冲区资源又没人用的话,就造成了资源浪费。
因此如果开发者自己认为需要传递大文件的话,就使用共享内存,默认不使用。