需求描述：

跳转商品列表界面选择商品后，需要将选择的商品数据返回上一个界面

通常从一个Activity返回数据到上一个Activity，我们一般都是在finish之前setResult，将要返回的数据存储在Intent中。


问题：

代码写好之后发现选择某个商品之后点击可以正常返回，但是当选择多个商品或者其他商品时，点击返回时没有任何反应，界面还是可以操作没有卡死，也没有崩溃日志，就是界面变得有些卡顿反应慢


分析问题：

在使用git对比之前的代码之后发现，商品数据对应的Bean对象里新增了一个Bitmap对象，然后这个Bitmap又自动实现了Parcelable，而这个Bitmap对象只是临时存储用的，并不需要序列化传递数据，想起来Intent传递数据是有大小限制的，而Bitmap通常都比较大，所以导致Activity无法正常关闭；之所以有个商品可以选择返回，是因为那个Bitmap刚好比较小没有超过限制大小。


解决问题：

解决的办法就是把不需要的Parcelable的Bitmap对象给取消序列化和反序列化，再试了一下就没问题了


其他问题：

Intent最大能传递多大数据？

传 512K 以下的数据的数据可以正常传递。

传 512K~1024K 的数据会出错，闪退。

传 1024K 以上的数据会报错：TransactionTooLargeException

考虑到 Intent 还包括要启动的 Activity 等信息，实际可以传的数据略小于 512K

如果需求就是要传递这个Bitmap怎么办？

1、可以考虑先把这个Bitmap转为图片保存到本地，然后在需要显示的时候再从本地获取转为Bitmap

2、使用static静态变量保存数据


TransactionTooLargeException官方解释：

大概意思就是Binder在序列化、反序列化数据过程中，是缓存在Binder transaction buffer内存中，它对数据大小有限制，目前是1M，而且是所有地方共用的，我们在传输数据中要避免大量的列表数据 或者 较大的Bitmap



/**
 * 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 传递数据时的大小限制