近期，着手对bugly上的anr 处理，记录下优化的方向。

借用网上的一张图：

这里的anr 问题是属于主线程的call 耗时操作。需要使用trace 来获取发生anr前一些列的耗时方法调用时间，再次梳理业务，才可能解决。

问题1
java 调用栈：

从调用栈中发现onActivityResult()执行对游戏侧的初始化会造成anr。

因靠打印是不准确，存在多线程抢占cpu的缘故，因此考虑通过获取trace来记录方法的真正执行时间。

记录oppo渠道包的冷启动到登录页面的sample trace文件，总览trace中存在的耗时点：这里查看主线程中执行方法。

淡绿色是app中的代码，长方形占用面积越大，越耗时。

查看onActvityResult的逻辑执行时间：

发现Show_GLView()执行耗时最多，其中NativeInit（）函数中调用若干方法，游戏C++层初始化了一大堆的逻辑。

问题2

anr发生的调用栈

通过调用栈oppo渠道中发现onResume执行对渠道初始化发生anr。

通过trace,来看下onResume中执行时间：

发现，onResume中初始化聚合渠道任务初始化，耗时100多毫秒。该任务可能并不是真正引起anr的真凶，可能是onActivityResult（）耗时过多，间接导致onResume()过程中被系统判定anr。

方案优化

耗时任务的解决有三种方式：

• 将耗时任务放到异步线程中执行
• 将耗时任务 lazy延后策略执行或者 提前选择空闲时间执行。

当界面1 跳转其他界面2后，当界面2调用finish（）销毁时:

先执行界面2的onStop()–>界面1的onActivityResult()->界面1的onResume()–>界面2的onstop()–>界面2的onDestroy()。

尝试将nativeInit（）和Show_GLView_Two() 放到onActvivityResult()和onResume（）之后执行。为了不阻塞onResume（）执行，利用hanlde的空闲机制：

在onActivityResult之后执行空闲任务：

Onresume 之后添加延迟任务：

按照以上调整逻辑，再次编译渠道包，来看下优化效果

优化效果

查看onActivityResult（）中onResume（）执行时间：

同时也反馈给游戏侧c++层的同事，初始化根据业务，进行延迟、异步等操作细分调用时间。

资料借鉴：

• https://www.zhihu.com/tardis/bd/art/552305686?source_id=1001