有时活动包括一些片段时，活动需要完全重新创建片段内容， 如果sportFragmentManager.fragments没有清晰的历史片段

    val fragments = sportFragmentManager.fragments
    val transaction = sportFragmentManager.beginTransaction()
    for (frag in fragments){
        transaction.remove(frag)
    }
    transaction.commitAllowingStateLoss()

几次重新创建片段活动将发生(调试使用tooLargeTool)

 W/ActivityStopInfo: Bundle stats:
 W/ActivityStopInfo:   android:viewHierarchyState [size=2304]
 W/ActivityStopInfo:     android:views [size=2256]
 W/ActivityStopInfo:   android:support:fragments [size=519072]
 W/ActivityStopInfo: PersistableBundle stats:
 W/ActivityStopInfo:   [null]

此异常通常在应用程序被发送到后台时抛出。

因此，我决定使用数据片段模式来完全绕过onSavedInstanceState生命周期。我的解决方案还处理复杂的实例状态并尽快释放内存。

首先，我创建了一个简单的片段来存储数据:

package info.peakapps.peaksdk.logic;
import android.app.Fragment;
import android.app.FragmentManager;
import android.os.Bundle;

/**
 * A neat trick to avoid TransactionTooLargeException while saving our instance state
 */

public class SavedInstanceFragment extends Fragment {

    private static final String TAG = "SavedInstanceFragment";
    private Bundle mInstanceBundle = null;

    public SavedInstanceFragment() { // This will only be called once be cause of setRetainInstance()
        super();
        setRetainInstance( true );
    }

    public SavedInstanceFragment pushData( Bundle instanceState )
    {
        if ( this.mInstanceBundle == null ) {
            this.mInstanceBundle = instanceState;
        }
        else
        {
            this.mInstanceBundle.putAll( instanceState );
        }
        return this;
    }

    public Bundle popData()
    {
        Bundle out = this.mInstanceBundle;
        this.mInstanceBundle = null;
        return out;
    }

    public static final SavedInstanceFragment getInstance(FragmentManager fragmentManager )
    {
        SavedInstanceFragment out = (SavedInstanceFragment) fragmentManager.findFragmentByTag( TAG );

        if ( out == null )
        {
            out = new SavedInstanceFragment();
            fragmentManager.beginTransaction().add( out, TAG ).commit();
        }
        return out;
    }
}

然后在我的主活动上，我完全绕过了保存的实例周期，并将责任推迟到我的数据片段。不需要对片段本身使用这个，因为它们的状态会自动添加到Activity的状态中):

@Override
protected void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);

    SavedInstanceFragment.getInstance( getFragmentManager() ).pushData( (Bundle) outState.clone() );
    outState.clear(); // We don't want a TransactionTooLargeException, so we handle things via the SavedInstanceFragment
}

剩下的就是弹出保存的实例:

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(SavedInstanceFragment.getInstance(getFragmentManager()).popData());
}

@Override
protected void onRestoreInstanceState(Bundle savedInstanceState) {
    super.onRestoreInstanceState( SavedInstanceFragment.getInstance( getFragmentManager() ).popData() );
}

详情:http://www.devsbedevin.net/avoiding-transactiontoolargeexception-on-android-nougat-and-up/

这不是一个确定的答案，但它可能有助于阐明TransactionTooLargeException的原因，并帮助确定问题。

虽然大多数答案涉及大量的数据传输，但我看到这个异常是在大量滚动和缩放以及反复打开ActionBar旋转菜单后偶然抛出的。崩溃发生在点击操作栏。(这是一个自定义地图应用程序)

唯一被传递的数据似乎是从“输入分派器”到应用程序的触摸。我认为这不能合理地在“事务缓冲区”中接近1 mb。

我的应用程序运行在一个四核1.6 GHz设备上，使用3个线程进行重载，为UI线程保留一个空闲内核。此外，该应用程序使用android:largeHeap，有10 mb未使用的堆剩余，并有100 mb的空间留下增长堆。所以我不认为这是资源问题。

崩溃之前总是有这样几句话:

W/InputDispatcher( 2271): channel ~ Consumer closed input channel or an error occurred.  events=0x9
E/InputDispatcher( 2271): channel ~ Channel is unrecoverably broken and will be disposed!
E/JavaBinder(28182): !!! FAILED BINDER TRANSACTION !!!

它们不一定按这个顺序打印，但(据我所知)发生在同一毫秒。

为了清楚起见，堆栈跟踪本身与问题中相同:

E/AndroidRuntime(28182): java.lang.RuntimeException: Adding window failed
..
E/AndroidRuntime(28182): Caused by: android.os.TransactionTooLargeException

深入研究android的源代码会发现这些行:

企业/ / core / jni / cpp android_util_Binder。依据:

case FAILED_TRANSACTION:
    ALOGE("!!! FAILED BINDER TRANSACTION !!!");
    // TransactionTooLargeException is a checked exception, only throw from certain methods.
    // FIXME: Transaction too large is the most common reason for FAILED_TRANSACTION
    //        but it is not the only one.  The Binder driver can return BR_FAILED_REPLY
    //        for other reasons also, such as if the transaction is malformed or
    //        refers to an FD that has been closed.  We should change the driver
    //        to enable us to distinguish these cases in the future.
    jniThrowException(env, canThrowRemoteException
            ? "android/os/TransactionTooLargeException"
                    : "java/lang/RuntimeException", NULL);

对我来说，这听起来像是我可能碰到了这个未记录的特性，其中事务失败是因为其他原因，而不是事务被TooLarge。他们应该把它命名为TransactionTooLargeOrAnotherReasonException。

在这个时候我没有解决这个问题，但如果我发现有用的东西，我会更新这个答案。

更新:原来我的代码泄露了一些文件描述符，其中的数量在Linux中是最大的(通常是1024)，这似乎触发了异常。所以这毕竟是一个资源问题。我通过打开/dev/zero 1024次来验证这一点，结果在UI相关的操作中出现了各种奇怪的异常，包括上面的异常，甚至还有一些SIGSEGV异常。显然，在整个Android系统中，打开文件/套接字失败并不是很干净的处理/报告。

I have also lived TransactionTooLargeException. Firstly I have worked on understand where it occurs. I know the reason why it occurs. Every of us know because of large content. My problem was like that and I solved. Maybe this solution can be useful for anybody. I have an app that get content from api. I am getting result from API in first screen and send it to second screen. I can send this content to second screen in successful. After second screen if I want to go third screen this exception occurs. Each of my screen is created from Fragment. I noticed that when I leave from second screen. It saves its bundle content. if this content is too large this exception happens. My solution is after I got content from bundle I clear it.

class SecondFragment : BaseFragment() {

    lateinit var myContent: MyContent

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        myContent = arguments?.getParcelable("mycontent")
        arguments?.clear()
    }

有这么多地方TransactionTooLargeException可以发生——这里是Android 8的一个新情况——当有人开始输入EditText时，如果内容太大，就会崩溃。

它与AutoFillManager (API 26中新增)和StartSessionLocked()中的以下代码相关:

    mSessionId = mService.startSession(mContext.getActivityToken(),
            mServiceClient.asBinder(), id, bounds, value, mContext.getUserId(),
            mCallback != null, flags, mContext.getOpPackageName());

如果我理解正确的话，这调用了自动填充服务——在绑定器中传递AutofillManagerClient。当EditText有很多内容时，它似乎会引起TTLE。

在EditText的xml布局声明中添加android:importantForAutofill="noExcludeDescendants"。或者在代码中:

EditText et = myView.findViewById(R.id.scriptEditTextView);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    et.setImportantForAutofill(View.IMPORTANT_FOR_AUTOFILL_NO_EXCLUDE_DESCENDANTS);
}

第二种糟糕的解决方法可能是重写performClick()和onWindowFocusChanged()方法来捕获TextEdit子类本身的错误。但我不认为这是明智的……

如果您需要调查哪个包裹导致了崩溃，您应该考虑尝试TooLargeTool。

(我发现这是@Max Spencer在接受答案下的评论，这对我的情况很有帮助。)