WebView渲染表单时触发TransactionTooLargeException致应用崩溃

从你提供的堆栈可以直接锁定触发链路：

at android.os.servertransaction.PendingTransactionActions$StopInfo.run
at android.app.IActivityManager$Stub$Proxy.activityStopped

本次崩溃根本不发生在页面跳转、保存实例状态的时机，而是发生在Activity被完全停止、向系统AMS上报停止状态的Binder调用环节。系统在发起这次调用时，会把当前Activity关联的所有待持久化状态打包成Parcel通过Binder传输；由于单进程共享的Binder事务缓冲区总大小硬限为1MB，且缓冲区会被进程内所有排队的跨进程事务共同占用，不需要凑满1MB的单条Parcel，只要总占用超过阈值，就会抛出TransactionTooLargeException。

无自定义存值场景下的常见触发源 #

你确认未在onSaveInstanceState中手动写入自定义大体积数据，结合WebView渲染表单的业务场景，占用Parcel体积的来源基本可以锁定为以下几类：

• WebView的自动状态持久化：WebView会在Activity状态保存阶段，自动把当前页面的表单填充内容、滚动位置、JS运行上下文、已加载的静态资源片段打包到系统状态Bundle里。带大量已填充文本、内嵌图片资源的复杂表单，仅这部分自动生成的数据就可能达到数百KB的体量，和你当前堆栈里603KB的Parcel大小完全匹配。
• View层级的默认状态保存：所有默认开启了saveEnabled属性的View，会在状态保存阶段自动把自身的文本内容、滚动位置、选中状态打包到Bundle里。包含长文本输入框、大内容滚动容器的表单页面，自动生成的状态数据会进一步放大总体积。
• Binder缓冲区的共享挤占：如果应用切到后台时已经有多个排队等待传输的Binder事务（比如定位SDK、推送SDK的跨进程回调），这些事务会预先占用缓冲区配额。哪怕本次Activity停止上报的Parcel只有600KB，加上其他事务的占用总量超过1MB阈值，就会直接触发崩溃，这也是为什么单条Parcel远没到1MB就崩溃的核心原因。

排查与修复方案 #

• 定位大体积数据来源：重写Activity的onSaveInstanceState方法，在调用完super.onSaveInstanceState()后，遍历Bundle里的所有键值对，逐条目计算对应数据的实际大小，把体积超过10KB的条目打印出来，重点核查嵌套在android:viewHierarchyState节点下的WebView相关状态数据。
• 裁剪非必要的状态持久化：针对WebView组件直接调用webView.setSaveEnabled(false)，关闭WebView的自动状态打包逻辑，避免整页表单内容被塞入系统状态Bundle；对不需要持久化状态的动态表单组件，同样调用setSaveEnabled(false)关闭View自带的状态保存能力，从源头降低状态包体积。
• 兜底规避事务超限：Activity停止逻辑的消息是通过主线程Handler分发的，可以通过自定义Handler Callback拦截该类消息，在状态打包完成后、实际发起Binder调用前，检查总Parcel的预估大小，对超过阈值的非必要状态做裁剪，避免触发超限崩溃。

内容的提问来源于stack exchange，提问作者Prachi Shah