前言
Caused by: android.os.TransactionTooLargeException: data parcel size *** bytes
不是吧？啊sir，上来就给我贴个异常？
在实现业务需求的过程中，A页面跳转到B页面，有可能会需要携带参数过去，当数据量大的时候，就会触发这个异常信息。
在做bitmap携带的时候，这个问题在部分设备上视情况而定，有时会触发，有时不会触发，从而引发对这个现象的深度查阅相关资料。
Intent无法直接携带bitmap，只能通过转ByteArray，然后目标组件去接受这个ByteArray转bitmap。下面贴出示例：
AActivity send:
bitmapByteArray = bitmap?.let {
val stream = ByteArrayOutputStream()
it.compress(Bitmap.CompressFormat.PNG, 100, stream)
stream.toByteArray()
}
val intent = Intent(this, BActivity::class.java).apply {
putExtra("bmp", bitmapByteArray)
// ...
}
startActivity(intent)
BActivity receive:
val bmpByteArray = intent.getByteArrayExtra("bmp")
val bitmap = BitmapFactory.decodeByteArray(bmpByteArray, 0, bmpByteArray.size)
操作系统会将 intent 的基础 Bundle 打包。然后，操作系统会创建新的 Activity，将数据拆包，并将 intent 传递给新的 Activity。
我们建议您使用 Bundle 类为 Intent 对象设置操作系统已知的基元。 Bundle 类针对使用 parcel 进行编组和解组进行了高度优化。
在某些情况下，您可能需要一种机制来跨 Activity 发送复合对象或复杂对象。在这种情况下，自定义类应实现 Parcelable，并提供相应的 writeToParcel(android.os.Parcel, int) 方法。它还必须提供实现 Parcelable.Creator 接口的非空字段 CREATOR ，该接口的 createFromParcel() 方法用于将 Parcel 转回为当前对象。如需了解详情，请参阅 Parcelable 对象的参考文档。
源码解析
/**
* The Binder transaction failed because it was too large.
* <p>
* During a remote procedure call, the arguments and the return value of the call
* are transferred as {@link Parcel} objects stored in the Binder transaction buffer.
* If the arguments or the return value are too large to fit in the transaction buffer,
* then the call will fail and {@link TransactionTooLargeException} will be thrown.
* </p><p>
* The Binder transaction buffer has a limited fixed size, currently 1Mb, which
* is shared by all transactions in progress for the process. Consequently this
* exception can be thrown when there are many transactions in progress even when
* most of the individual transactions are of moderate size.
* </p><p>
* There are two possible outcomes when a remote procedure call throws
* {@link TransactionTooLargeException}. Either the client was unable to send
* its request to the service (most likely if the arguments were too large to fit in
* the transaction buffer), or the service was unable to send its response back
* to the client (most likely if the return value was too large to fit
* in the transaction buffer). It is not possible to tell which of these outcomes
* actually occurred. The client should assume that a partial failure occurred.
* </p><p>
* The key to avoiding {@link TransactionTooLargeException} is to keep all
* transactions relatively small. Try to minimize the amount of memory needed to create
* a {@link Parcel} for the arguments and the return value of the remote procedure call.
* Avoid transferring huge arrays of strings or large bitmaps.
* If possible, try to break up big requests into smaller pieces.
* </p><p>
* If you are implementing a service, it may help to impose size or complexity
* contraints on the queries that clients can perform. For example, if the result set
* could become large, then don't allow the client to request more than a few records
* at a time. Alternately, instead of returning all of the available data all at once,
* return the essential information first and make the client ask for additional information
* later as needed.
* </p>
*/
public class TransactionTooLargeException extends RemoteException {
public TransactionTooLargeException() {
super();
}
public TransactionTooLargeException(String msg) {
super(msg);
}
}
仔细看下Android官方对这个异常的描述，可以得到的信息点有：
- 通过Intent传递或者返回的数据是存放在一个叫做
Binder transaction buffer的缓存区，这个缓冲区的大小为1Mb(Android 28 Platform)，当缓冲区不够用时就会抛出异常 - 如果有
多个数据传递同时进行，是共用缓冲区的1Mb，而不是每一个传输各分配1Mb缓存。这就有可能当多个传输同时进行时，数据大小小于1M还是抛出TransactionTooLargeException异常 - 建议的解决方法就是
尽可能减小传输的数据，至于具体要多少上限也没个具体的数值，也不可能知道，因为并发传输的数量不固定，但是至少可以肯定的是超过1M肯定会抛异常 - 该限制应为1MB，但
因设备而异，从略小于512KB到几乎完全1M，也有可能会更小。
既然提到了Binder通信机制，Activity、Service、Broadcast Receiver 和 Content Provider 四大组件通信的时候，是不是也要谨慎考虑这点呢？
解决方法
既然问题的根源在于传输的数据量太大导致，那解决方法自然而然就是尽可能的减少数据量的传输，提供几个方法，以供参考一下。
1.压缩减少bitmap的size，视情况而定。（不建议，这个大小范围不好界定，压缩还会带来用户体验上的降低）
2.保存在内存中，例如static全局变量，适当的时候记得清空或者置空。
3.保存在文件中，例如本地cache文件，数据库。传递给对方的时候，只传递关键信息（id or path），目标页面再做取出。
4.EventBus postSticky粘性事件。为什么需要粘性事件？不是普通事件？因为目标组件还没创建啊...
以上。
