Android 应用Jit影响卡顿了？

背景

今天在优化列表，把布局层级精简到一层了，然后动画也移除了，在demo中跑已经黑丝一样丝滑了。在我准备收工的时候，在抓一次trace。发现掉帧。

掉帧

掉帧后我当时惊呆了，这什么情况，开发怎么成了玄学一样。

我在掉帧地方（车祸现在）看了下其他线程情况，找到元凶。

Jit thread pool线程一直是绿色的（running）也就是滑动掉帧被这个影响到了？

这是CPU的情况，频率高拉满，有一个核心一直在跑Jit任务，我的妈耶。

查了下文档，大于或等于7.0系统，系统在空闲的时候才会做编译优化。

用户运行应用，此举随后触发 ART 加载 .dex 文件。 如果有 .oat 文件（即 .dex 文件的 AOT 二进制文件），ART 会直接使用该文件。虽然 .oat 文件会定期生成，但文件中不一定会包含经过编译的代码（即 AOT 二进制文件）。 如果 .oat 文件不含经过编译的代码，ART 会通过 JIT 和解释器执行 .dex 文件。 针对任何未根据 speed 编译过滤器编译的应用启用 JIT（也就是说，要尽可能多地编译应用中的代码）。 将 JIT 配置文件数据转储到只有该应用可以访问的系统目录下的文件中。 AOT 编译 (dex2oat) 守护程序通过解析该文件来推进其编译。

那么也就是我的场景下，不一定包含经过编译的代码，aot二进制文件，所以触发了jit。

官方也给方法，让我们主动做这个事情。

adb shell cmd package compile -m speed -f com.debug.android
//等一段时间之后，看你机器的性能，你会看到
succeed

我使用这个命令跑了一次，进行整个应用的编译，经过我多次跑我优化的场景后，在trace中再也没看到jit thread pool的影子，那么，下次如果给大佬们看优化效果的时候，只需要提前执行上面的命令，那岂不是。

如果老板肯加工资，那我一定每个页面都优化一次。

总结

最近一直在优化页面，这次需求我碰过的页面，老页面虽然卡，但是又不是不能用啊。 还是先积累下经验先，等我各种工具都玩熟悉了，知道哪里出问题了，才有优化的动力。