# ProcessImageTest

**Repository Path**: tyz/ProcessImageTest

## Basic Information

- **Project Name**: ProcessImageTest
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2025-03-15
- **Last Updated**: 2025-03-15

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 跨进程传图片方案
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](https://github.com/Double2hao/ProcessImageTest)

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

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

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

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