神奇冻结问题的规避办法
- 先调用广播“MTG_TriggerCloseBtn”再调用 API triggerCloseBtn 是ok的
- 在 “先调用 triggerCloseBtn 后发广播”的逻辑下，如果进入 pl 后，打开chrome终端不输入内容，点击 pl 关闭也是可以的
引用 Android 侧的通报邮件：
Hi，见安。
因近日客诉在展示Mintegral RV后会造成宿主App的WebView不响应（以下统称上述行为），现就整个排查过程及结果作出说明。1.客诉后发现，出现上述行为时，RV的展示流程为Video+Playable(以下统称PL)。
2.当EndCard(以下统称EC)为native兜底及H5时，不会造成上述行为。
3.关闭PL，PL调用SDK的关闭方法后，SDK对加载PL的WebView进行销毁，SDK在执行销毁动作后实际已失去对WebView的控制能力。当出现造成宿主WebView不响应现象时，被销毁的PL WebView输出了Log，内容是大模板下发送关闭广播操作。
4.在跟PL的同学联调后发现，将相关发送广播的代码去掉后，宿主App的WebView行为正常。
5.跟EC的同学确认，EC会对是否是大模板做出判定，RV单Offer展示状态下不会有发送广播行为。
6.测试的同学在测试先播后选模板后确认，发送广播行为在先播后选模板下不会造成上述行为的发生。昨日晚些时候，PL的同学已经对上述问题进行了调整，目前测试宿主App WebView行为已正常，后续还需进行持续观察。
同时由于Android WebView相关机制及不可控性，当WebView执行完Destroy操作之后，如果H5仍有任务执行，被销毁的WebView会一直等候结果直到任务完成，如果任务耗时/需要回调/没有中断机制等等，其它WebView也会跟着一起等待，最终会造成宿主App的WebView不响应任何操作，直到应用重启。建议后续关闭时提前做必要的工作，处理完毕后再通知SDK进行关闭操作，以减少此类意外发生。
SDK端也会持续关注WebView控件的相关改进，如后续Google对此类型问题做出改进亦会同步。
由于前期对遇到此问题的开发者进行了下毒处理，后续麻烦AM及对接同学尝试放开限制，并跟踪开发者是否还会遇到同类型问题。
以上。
PS：非常感谢PL的同学的支持与帮助，对排查过程中提供帮助的同学表示感谢。