前兩天測試提了一個crash的bug，崩潰棧如下：
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
雖說一眼就看出是binder通訊引發的崩潰，但就如同OOM問題，定性問題容易，但定位問題卻不容易。
下面開始問題分析：
1) 分析拋出的原因或條件，查看源碼android_util_binder.cpp，查看系統層在什么情況下會拋出TransactionTooLargeException，下圖中可知
在binder驅動處理失敗后，如果傳輸的parcel體積超過200kb，則會拋出TransactionTooLargeException，因此引發該問題的原因是binder調用
傳輸的數據太大導致，問題分析重點應側重binder數據傳輸。
2) 分析崩潰棧，找出引發該問題的binder調用是ActivityManagerProxy.activityStopped，從中大概推知問題的發生時機在Activity stopped的時候。
3) 網上百度相關的解決方案，關鍵詞是TransactionTooLargeException activityStopped，現象類似的問題、原因、解決方案如下：
問題原因：FragmentStatePagerAdapter的實現有缺陷，因為其默認實現會持續保存歷史Fragment實例的狀態數據歷史，在逐漸地積累、保存數據后，最終導致發送的數據包體積超過限制200KB 。
參見：https://stackoverflow.com/questions/11451393/what-to-do-on-transactiontoolargeexception
- 解決方案：重寫
FragmentStatePagerAdapter的saveState方法，使其不保存歷史Fragment實例的狀態數據。
4) 工程中崩潰點也恰巧使用了FragmentStatePagerAdapter，現象也類似，然后立即應用該方案，但沒有效果。
5）繼續分析該問題，深入代碼進行白盒分析，根據日志輸出和代碼結構，最后定位問題原因是構建Fragment實例時傳遞ArrayList給Fragment的構造函數，
在Fragment的構造函數內部將該ArrayList作為Parcelable存放在Bundle，以供該Fragment初始化時從bundle中讀取, 在數據量比較大時，就會拋出TransactionTooLargeException。
6) 解決方案：構建Fragment實例時傳遞ArrayList給Fragment的構造函數，在Fragment被加載時無需從Bundle中讀取，這樣可避免TransactionTooLargeException，又提高程序執行效率。
7) 總結
TransactionTooLargeException經常出現在binder通信的場景中，導致其出現的直接原因是binder通信的數據包過大，而根本原因是使用者的理解和設計軟件問題，因為binder通信的設計初衷是
跨進程的小規模數據體量的通信，從其內存設置就可看出：binder空間最大是1MB，而且是被所有進程共享。如果不理解binder的設計和適用場景，錯誤地將binder用於大數據量傳輸，那就會出現問題。