Android 如何处理 TransactionTooLargeException

What to do on TransactionTooLargeException

提问by Ixx

I got a TransactionTooLargeException. Not reproducible. In the docs it says

我得到了一个TransactionTooLargeException. 不可重现。在文档中它说

The Binder transaction failed because it was too large.

During a remote procedure call, the arguments and the return value of the call are transferred as 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 TransactionTooLargeException will be thrown.

...

There are two possible outcomes when a remote procedure call throws 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).

...

Binder 事务因为太大而失败。

在远程过程调用期间，调用的参数和返回值作为存储在 Binder 事务缓冲区中的 Parcel 对象传输。如果参数或返回值太大而无法放入事务缓冲区，则调用将失败并抛出 TransactionTooLargeException。

...

当远程过程调用抛出 TransactionTooLargeException 时，有两种可能的结果。客户端无法将其请求发送到服务（很可能是因为参数太大而无法放入事务缓冲区），或者服务无法将其响应发送回客户端（很可能是如果返回值是太大而无法放入事务缓冲区）。

...

So somewhere I'm passing or receiving arguments which exceed some unknown limit. Where?

所以我在某处传递或接收超过某个未知限制的参数。在哪里？

The stacktrace doesn't show anything useful:

堆栈跟踪没有显示任何有用的信息：

java.lang.RuntimeException: Adding window failed
at android.view.ViewRootImpl.setView(ViewRootImpl.java:548)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:406)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:320)
at android.view.WindowManagerImpl$CompatModeWrapper.addView(WindowManagerImpl.java:152)
at android.view.Window$LocalWindowManager.addView(Window.java:557)
at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:2897)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2245)
at android.app.ActivityThread.access0(ActivityThread.java:139)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1262)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:4977)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
at dalvik.system.NativeStart.main(Native Method)
Caused by: android.os.TransactionTooLargeException
at android.os.BinderProxy.transact(Native Method)
at android.view.IWindowSession$Stub$Proxy.add(IWindowSession.java:569)
at android.view.ViewRootImpl.setView(ViewRootImpl.java:538)
... 16 more
android.os.TransactionTooLargeException
at android.os.BinderProxy.transact(Native Method)
at android.view.IWindowSession$Stub$Proxy.add(IWindowSession.java:569)
at android.view.ViewRootImpl.setView(ViewRootImpl.java:538)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:406)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:320)
at android.view.WindowManagerImpl$CompatModeWrapper.addView(WindowManagerImpl.java:152)
at android.view.Window$LocalWindowManager.addView(Window.java:557)
at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:2897)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2245)
at android.app.ActivityThread.access0(ActivityThread.java:139)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1262)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:4977)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
at dalvik.system.NativeStart.main(Native Method)

It seems to be related with views? How is this related to remote procedure call?

它似乎与视图有关？这与远程过程调用有什么关系？

Maybe important: Android version: 4.0.3, Device: HTC One X

可能很重要：Android 版本：4.0.3，设备：HTC One X

采纳答案by Durairaj Packirisamy

I encountered this issue, and I found that when there huge amount of data getting exchanged between a service and an application,(This involves transferring lots of thumbnails). Actually data size was around 500kb, and the IPC transaction buffer size is set to 1024KB. I am not sure why it exceeded the transaction buffer.

我遇到了这个问题，我发现当服务和应用程序之间交换大量数据时，（这涉及传输大量缩略图）。实际数据大小约为 500kb，IPC 事务缓冲区大小设置为 1024KB。我不确定为什么它超出了事务缓冲区。

This also can occur, when you pass lot of data through intent extras

当您通过 Intent Extras 传递大量数据时，也会发生这种情况

When you get this exception in your application, please analyze your code.

当您在应用程序中遇到此异常时，请分析您的代码。

1. Are you exchanging lot of data between your services and application?
2. Using intents to share huge data, (for example, the user selects huge number of files from gallery share press share, the URIs of the selected files will be transferred using intents)
3. receiving bitmap files from service
4. waiting for android to respond back with huge data (for example, getInstalledApplications() when the user installed lot of applications)
5. using applyBatch() with lot of operations pending

1. 您是否在服务和应用程序之间交换大量数据？
2. 使用intents共享大量数据，（例如，用户从gallery share press share中选择了大量文件，所选文件的URIs将使用intents传输）
3. 从服务接收位图文件
4. 等待 android 响应大量数据（例如，当用户安装大量应用程序时，getInstalledApplications()）
5. 使用 applyBatch() 和许多待处理的操作

How to handle when you get this exception

遇到此异常时如何处理

If possible, split the big operation in to small chunks, for example, instead of calling applyBatch() with 1000 operations, call it with 100 each.

如果可能，将大操作拆分为小块，例如，不要用 1000 个操作调用 applyBatch()，而是用每个 100 个操作调用它。

Do not exchange huge data (>1MB) between services and application

不要在服务和应用程序之间交换大量数据（>1MB）

I dont know how to do this, but, Do not query android, which can return huge data :-)

我不知道该怎么做，但是，不要查询 android，它可以返回大量数据:-)

回答by sulai

If you need to investigate which Parcel is causing your crash, you should consider trying TooLargeTool.

如果您需要调查导致崩溃的 Parcel，您应该考虑尝试使用TooLargeTool。

(I found this as a comment from @Max Spencer under the accepted answer and it was helpful in my case.)

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

回答by mvds

This is not a definitive answer, but it may shed some light on the causes of a TransactionTooLargeExceptionand help pinpoint the problem.

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

Although most answers refer to large amounts of data transferred, I see this exception being thrown incidentally after heavy scrolling and zooming and repeatedly opening an ActionBar spinner menu. The crash happens on tapping the action bar. (this is a custom mapping app)

尽管大多数答案都涉及传输的大量数据，但我看到在大量滚动和缩放并反复打开 ActionBar 微调菜单后偶然抛出了此异常。崩溃发生在点击操作栏时。（这是一个自定义地图应用程序）

The only data being passed around seem to be touches from the "Input Dispatcher" to the app. I think this cannot reasonably amount to anywhere near 1 mb in the "Transaction Buffer".

唯一传递的数据似乎是从“输入调度程序”到应用程序的触摸。我认为这在“交易缓冲区”中不可能达到接近 1 mb 的任何地方。

My app is running on a quad core 1.6 GHz device and uses 3 threads for heavylifting, keeping one core free for the UI thread. Furthermore, the app uses android:largeHeap, has 10 mb of unused heap left and has 100 mb of room left to grow the heap. So I wouldn't say it is a resource issue.

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

The crash is always immediately preceded by these lines:

崩溃总是紧跟在这些行之前：

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 !!!

Which are not neccesarily printed in that order, but (as far as I checked) happen on the same millisecond.

哪些不一定按该顺序打印，但（据我检查）发生在同一毫秒内。

And the stack trace itself, for clarity, is the same as in the question:

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

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

Delving into the source code of android one finds these lines:

深入研究android的源代码，发现以下几行：

frameworks/base/core/jni/android_util_Binder.cpp:

框架/基础/核心/jni/android_util_Binder.cpp：

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);

To me it sounds like I'm possibly hitting this undocumented feature, where the transaction fails for other reasons than a Transaction being TooLarge. They should have named it TransactionTooLargeOrAnotherReasonException.

对我来说，这听起来像是我可能遇到了这个未记录的功能，其中交易失败的原因不是交易太大。他们应该给它命名TransactionTooLargeOrAnotherReasonException。

At this time I did not solve the issue, but if I find something useful I will update this answer.

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

update:it turned out my code leaked some file descriptors, the number of which is maximized in linux (typically 1024), and this seems to have triggered the exception. So it was a resource issue after all. I verified this by opening /dev/zero1024 times, which resulted in all kinds of weird exceptions in UI related actions, including the exception above, and even some SIGSEGV's. Apparently failure to open a file/socket is not something which is handled/reported very cleanly throughout Android.

更新：原来我的代码泄露了一些文件描述符，在linux中数量最大化（通常为1024），这似乎触发了异常。所以这毕竟是一个资源问题。我通过打开/dev/zero1024次来验证这一点，导致UI相关操作中出现各种奇怪的异常，包括上面的异常，甚至一些SIGSEGV。显然，打开文件/套接字失败并不是在整个 Android 中都非常干净地处理/报告的事情。

回答by IK828

The TransactionTooLargeExceptionhas been plaguing us for about 4 months now, and we've finally resolved the issue!

这个TransactionTooLargeException问题已经困扰我们大约 4 个月了，我们终于解决了这个问题！

What was happening was we are using a FragmentStatePagerAdapterin a ViewPager. The user would page through and create 100+ fragments (its a reading application).

发生的事情是我们FragmentStatePagerAdapter在 a中使用了a ViewPager。用户将翻阅并创建 100 多个片段（它是一个阅读应用程序）。

Although we manage the fragments properly in destroyItem(), in Androids implementation of FragmentStatePagerAdapterthere is a bug, where it kept a reference to the following list:

尽管我们在 中正确管理了片段destroyItem()，但在 Android 的实现中FragmentStatePagerAdapter存在一个错误，它保留了对以下列表的引用：

private ArrayList<Fragment.SavedState> mSavedState = new ArrayList<Fragment.SavedState>();

And when the Android's FragmentStatePagerAdapterattempts to save the state, it will call the function

当 AndroidFragmentStatePagerAdapter尝试保存状态时，它会调用该函数

@Override
public Parcelable saveState() {
    Bundle state = null;
    if (mSavedState.size() > 0) {
        state = new Bundle();
        Fragment.SavedState[] fss = new Fragment.SavedState[mSavedState.size()];
        mSavedState.toArray(fss);
        state.putParcelableArray("states", fss);
    }
    for (int i=0; i<mFragments.size(); i++) {
        Fragment f = mFragments.get(i);
        if (f != null && f.isAdded()) {
            if (state == null) {
                state = new Bundle();
            }
            String key = "f" + i;
            mFragmentManager.putFragment(state, key, f);
        }
    }
    return state;
}

As you can see, even if you properly manage the fragments in the FragmentStatePagerAdaptersubclass, the base class will still store an Fragment.SavedStatefor every single fragment ever created. The TransactionTooLargeExceptionwould occur when that array was dumped to a parcelableArrayand the OS wouldn't like it 100+ items.

如您所见，即使您正确管理FragmentStatePagerAdapter子类中的片段，基类仍然会Fragment.SavedState为曾经创建的每个片段存储一个。在TransactionTooLargeException当阵列转储到会发生parcelableArray和OS不希望它超过100项。

Therefore the fix for us was to override the saveState()method and notstore anything for "states".

因此，我们的解决saveState()方法是覆盖该方法，而不是为"states".

@Override
public Parcelable saveState() {
    Bundle bundle = (Bundle) super.saveState();
    bundle.putParcelableArray("states", null); // Never maintain any states from the base class, just null it out
    return bundle;
}

回答by Yazon2006

For those who bitterly disappointed in search of answer of why the TransactionTooLargeException apears, try to check how much information you save in instance state.

对于那些在寻找 TransactionTooLargeException 出现原因的答案时非常失望的人，请尝试检查您在实例状态中保存了多少信息。

On compile/targetSdkVersion <= 23 we have only internal warningabout large size of saved state, but nothing is crashed:

在 compile/ targetSdkVersion <= 23 我们只有关于大尺寸保存状态的内部警告，但没有任何崩溃：

E/ActivityThread: App sent too much data in instance state, so it was ignored
    android.os.TransactionTooLargeException: data parcel size 713856 bytes
    at android.os.BinderProxy.transactNative(Native Method)
    at android.os.BinderProxy.transact(Binder.java:615)
    at android.app.ActivityManagerProxy.activityStopped(ActivityManagerNative.java:3604)
    at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3729)
    at android.os.Handler.handleCallback(Handler.java:751)
    at android.os.Handler.dispatchMessage(Handler.java:95)
    at android.os.Looper.loop(Looper.java:154)
    at android.app.ActivityThread.main(ActivityThread.java:6044)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)

But on compile/targetSdkVersion >= 24 we have real RuntimeException crashin this case:

但是在 compile/ targetSdkVersion >= 24 上，在这种情况下我们有真正的 RuntimeException 崩溃：

java.lang.RuntimeException: android.os.TransactionTooLargeException: data parcel size 713860 bytes
    at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3737)
    at android.os.Handler.handleCallback(Handler.java:751)
    at android.os.Handler.dispatchMessage(Handler.java:95)
    at android.os.Looper.loop(Looper.java:154)
    at android.app.ActivityThread.main(ActivityThread.java:6044)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)
 Caused by: android.os.TransactionTooLargeException: data parcel size 713860 bytes
   at android.os.BinderProxy.transactNative(Native Method)
   at android.os.BinderProxy.transact(Binder.java:615)
   at android.app.ActivityManagerProxy.activityStopped(ActivityManagerNative.java:3604)
   at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3729)
   at android.os.Handler.handleCallback(Handler.java:751) 
   at android.os.Handler.dispatchMessage(Handler.java:95) 
   at android.os.Looper.loop(Looper.java:154) 
   at android.app.ActivityThread.main(ActivityThread.java:6044) 
   at java.lang.reflect.Method.invoke(Native Method) 
   at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865) 
   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755) 

What to do?

该怎么办？

Save data in local database and keep only id's in instance state which you can use to retrieve this data.

将数据保存在本地数据库中，并仅将 id 保留在可用于检索此数据的实例状态中。

回答by Vaiden

This exception is typically thrown when the app is being sent to the background.

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

So I've decided to use the data Fragment method to completely circumvent the onSavedInstanceStaelifecycle. My solution also handles complex instance states and frees memory ASAP.

所以我决定使用data Fragment的方法来完全规避onSavedInstanceStae生命周期。我的解决方案还处理复杂的实例状态并尽快释放内存。

First I've created a simple Fargment to store the data:

首先，我创建了一个简单的 Fargment 来存储数据：

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;
    }
}

Then on my main Activity I circumvent the saved instance cycle completely, and defer the respoinsibilty to my data Fragment. No need to use this on the Fragments themselves, sice their state is added to the Activity's state automatically):

然后在我的主要活动中，我完全绕过了保存的实例周期，并将责任推迟到我的数据片段。无需在 Fragment 本身上使用它，因为它们的状态会自动添加到 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
}

What's left is simply to pop the saved instance:

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

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

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

Full details: http://www.devsbedevin.net/avoiding-transactiontoolargeexception-on-android-nougat-and-up/

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

回答by Ojonugwa Jude Ochalifu

There isn't one specific cause of this problem.For me, in my Fragment class I was doing this:

这个问题没有一个具体的原因。对我来说，在我的 Fragment 类中，我是这样做的：

public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
    super.onCreateView(inflater, container, savedInstanceState);
    View rootView = inflater.inflate(R.layout.snacks_layout, container); //<-- notice the absence of the false argument
    return rootView;
}

instead of this:

而不是这个：

View rootView = inflater.inflate(R.layout.softs_layout, container, false);

回答by 3c71

It is important to understand that the transaction buffer is limited to 1 MB, regardless of device capabilities or app. This buffer is used with every API calls you make and is shared amongst all transactions an app is currently running.

无论设备功能或应用程序如何，事务缓冲区都限制为 1 MB，了解这一点很重要。此缓冲区用于您进行的每个 API 调用，并在应用程序当前运行的所有事务之间共享。

I believe it also holds some specific object like parcels and such (Parcel.obtain()), so it's important to always match every obtain()with a recycle().

我相信它也包含一些特定的对象，如包裹等(Parcel.obtain())，因此始终将每个对象obtain()与recycle().

This error can easily happen on API calls returning a lot of data, even though the returned data is less than 1 MB (if other transactions are still running).

返回大量数据的 API 调用很容易发生此错误，即使返回的数据小于 1 MB（如果其他事务仍在运行）。

For example, the PackageManager.getInstalledApplication()call returns a list of all apps installed. Adding specific flags allows to retrieve a lot of extra data. Doing so is likely to fail, so it's recommended not to retrieve any extra data and retrieve those on a per-app basis.

例如，PackageManager.getInstalledApplication()调用返回所有已安装应用程序的列表。添加特定标志允许检索大量额外数据。这样做很可能会失败，因此建议不要检索任何额外的数据并在每个应用程序的基础上检索这些数据。

However the call may still fail, so it's important to surround it with a catchand be able to retry if necessary.

然而，调用可能仍然失败，因此用 a 包围它catch并在必要时能够重试是很重要的。

As far as I know, there's no work-around to such issue except retrying and making sure to retrieve as little information as possible.

据我所知，除了重试并确保检索尽可能少的信息外，没有解决此类问题的方法。

回答by Siddharth

I too got this exception on a Samsung S3. I suspect 2 root causes,

我在三星 S3 上也遇到了这个异常。我怀疑有两个根本原因，

1. you have bitmaps that load and take up too much memory, use downsizing
2. You have some drawables missing from the drawable-_dpi folders, android looks for them in drawable, and resizes them, making your setContentView suddenly jump and use a lot of memory.

1. 您有位图加载并占用太多内存，请使用缩小尺寸
2. drawable-_dpi 文件夹中缺少一些可绘制对象，android 在可绘制对象中查找它们并调整它们的大小，使您的 setContentView 突然跳转并使用大量内存。

Use DDMS and look at your heap as you play your app, that will give you some indication on which setcontentview is creating the issue.

使用 DDMS 并在您播放应用程序时查看您的堆，这会给您一些关于哪个 setcontentview 正在创建问题的指示。

I copied all the drawables across all folders to get rid of problem 2.

我复制了所有文件夹中的所有可绘制对象以解决问题 2。

Issue is resolved.

问题已解决。

回答by Makvin

Add this to your Activity

将此添加到您的活动中

@Override
protected void onSaveInstanceState(Bundle oldInstanceState) {
    super.onSaveInstanceState(oldInstanceState);
    oldInstanceState.clear();
}

It works for me hope also it will help you

它对我有用，希望它也能帮助你