Transactiontoolargeexception cause Analysis

The first two days of testing raised a crash bug, the crash stack is as follows:

Device manufacturer : meizu
device model         : m5 note
android version     : 7.0
Android SDK          : 24
app versionname      : 1.1.2
app versioncode     : 16
App Max  MEM         : 512MB
uuid                 : 864105030589222
Timestamp            : 10-16 14:27:22.880
CurrentThread        : main#1
Totalmem\availmem   : 3796mb\ 1037MB
crash detail        : 

java.lang.RuntimeException:android.os.TransactionTooLargeException:data Parcel size 531500 bytes
At Android.app.activitythread$stopinfo.run (activitythread.java:4112)
At Android.os.Handler.handleCallback (handler.java:836)
At android.os.Handler.dispatchMessage (handler.java:103)
At Android.os.Looper.loop (looper.java:203)
At Android.app.ActivityThread.main (activitythread.java:6519)
At Java.lang.reflect.Method.invoke (Native Method)
At Com.android.internal.os.zygoteinit$methodandargscaller.run (zygoteinit.java:1113)
At Com.android.internal.os.ZygoteInit.main (zygoteinit.java:974)
caused by:android.os.TransactionTooLargeException:data parcel size 531500 bytes
At android.os.BinderProxy.transactNative (Native Method)
At android.os.BinderProxy.transact (binder.java:627)
At android.app.ActivityManagerProxy.activityStopped (activitymanagernative.java:3990)
At Android.app.activitythread$stopinfo.run (activitythread.java:4104)
... 7 More

Although it is obvious that the binder communication caused the collapse, but like the oom problem, the qualitative problem is easy, but the location of the problem is not easy.

The following begins the problem analysis:

1) Analyze the reasons or conditions thrown, check the source Android_util_binder.cpp, see the system layer under what circumstances will throw transactiontoolargeexception,

After the binder driver processing fails, if the transferred parcel volume exceeds 200kb, the transactiontoolargeexception is thrown, so the problem is raised because binder calls

The data transmission is too large, the problem analysis should focus on binder data transmission.

2) analyze the crash stack and find out if the binder call that caused the problem is activitymanagerproxy.activitystopped, which presumably inferred the timing of the problem in activity stopped.

3) online Baidu-related solutions, key words are transactiontoolargeexception activitystopped, the phenomenon of similar problems, causes, solutions are as follows:

• 问题原因：FragmentStatePagerAdapterImplementation is flawed, because its default implementation persists the history of the state data of the historical fragment instance , and after accumulating and saving the data, it eventually leads to a packet volume exceeding the limit of 200KB.
  

See also:https://stackoverflow.com/questions/11451393/what-to-do-on-transactiontoolargeexception

• solution : Override FragmentStatePagerAdapter The SaveState method so that it does not save the state data for the historical fragment instance.

4) The crash point in the project also happens FragmentStatePagerAdapter to be used, the phenomenon is similar, and then immediately apply the program, but no effect.

5) Continue to analyze the problem, in-depth code for white-box analysis, according to the log output and code structure, the final location of the problem is the construction of fragment instance ArrayList to fragment of the constructor,

inside the fragment constructor, the ArrayList is stored as parcelable in the bundle, which is read from the bundle when the fragment is initialized, and is thrown when the amount of data is large. Transactiontoolargeexception.

6) Solution: pass ArrayList to fragment constructor when building fragment instance, no need to read from bundle when fragment is loaded, avoid transactiontoolargeexception, and improve the efficiency of program execution.

7) Summary

Transactiontoolargeexception is often present in binder communication scenarios, leading to the fact that the binder communication packet is too large, and the root cause is the user's understanding and design software problem, because binder communication is designed to

The communication of small-scale data volumes across processes can be seen from their memory settings: The binder space is 1MB maximum and is shared by all processes. If you do not understand the design and application scenarios of binder, and mistakenly use binders for large data transfer, there will be problems.

Transactiontoolargeexception cause Analysis