android动画帧率_Android性能优化-你的lottie动画今天跳帧了吗？

问题现象

底部tab，现在大家都很熟悉了，点击一个tab 就切换一个fragment，现在主流的做法渐渐演变成点击底部tab的时候

对应的icon要做一些动画。通常而言，我们在做类似动画时往往依赖的是lottie这个动画库(别问为什么，问就是不会做，做的烂)。然而在实际开发中，我们发现如果这个动画稍微复杂一些，就会出现不易察觉的丢帧现象。往往表现在：

第一次点击tab的时候，因为涉及到对应fragment的初始化(可能会有一些耗时操作)，所以会导致 该lottie动画 有一点点丢帧的现象，看上去就好像一个本应该执行10帧的动画 只执行了不到10帧。

怎么证明这个动画执行的不完美？

比如说 我们可以 打印一下这个动画的执行过程

mLottieAnimationView.addAnimatorUpdateListener(new ValueAnimator.AnimatorUpdateListener() {

@Override

public void onAnimationUpdate(ValueAnimator animation) {

Log.v("wuyue", "onAnimationUpdate ===" + animation.getAnimatedFraction());

}

});

复制代码

第一次执行动画时，注意这一次执行动画的时候会伴随着对应的fragment的初始化。

第二次执行动画时，往往fragment都初始化完毕了。

我们可以明显的看出来，第一次的动画执行 步骤少了许多，也就是说有很多frame，也就是有很多帧，是没有展示到的。

如果你的动画足够精细和复杂 那是可以肉眼看出来的动画不完美。 如果你的动画做的不够精细，那往往肉眼看不出来，可能要通过我这种方法打印日志才能看的出来。

lottie做了什么？为什么动画执行丢帧？

上述的现象其实不难推测，因为fragment第一次初始化的时候可能会消耗一些系统资源，或者说这个fragment的代码写的不够好，本身会导致主线程卡顿。

可是为什么主线程卡顿会导致lottie动画没有完美执行？难道lottie有什么魔法？还能主动探测帧率自动降频操作？带着这些疑问，

我们来翻一翻源码，看看lottie到底做了什么。

我们这里稍微解释一下

public interface FrameCallback {

/**

* Called when a new display frame is being rendered.

*

* This method provides the time in nanoseconds when the frame started being rendered.

* The frame time provides a stable time base for synchronizing animations

* and drawing. It should be used instead of {@link SystemClock#uptimeMillis()}

* or {@link System#nanoTime()} for animations and drawing in the UI. Using the frame

* time helps to reduce inter-frame jitter because the frame time is fixed at the time

* the frame was scheduled to start, regardless of when the animations or drawing

* callback actually runs. All callbacks that run as part of rendering a frame will

* observe the same frame time so using the frame time also helps to synchronize effects

* that are performed by different callbacks.

*

* Please note that the framework already takes care to process animations and

* drawing using the frame time as a stable time base. Most applications should

* not need to use the frame time information directly.

*

*

* @param frameTimeNanos The time in nanoseconds when the frame started being rendered,

* in the {@link System#nanoTime()} timebase. Divide this value by {@code 1000000}

* to convert it to the {@link SystemClock#uptimeMillis()} time base.

*/

public void doFrame(long frameTimeNanos);

}

复制代码

这个回调里面的doFrame方法 你就把他理解成 每次界面绘制完一帧的时候，就会回调一次这个接口。那么在这个回调方法里面，我们计算一下和前一次回调的时间差，就可以知道这个界面绘制是否卡顿，这是目前主流app做帧率检测的方案。

那么lottie 拿到这个回调到底要做什么呢？

到这里就真相大白了，回头再细细品味一下，可以想到lottie对动画的优化也是到了一定境界了，他没有粗暴的让动画每一帧都去执行，而是根据doFrame 来决定执行哪一帧，避免对整个ui系统 增加负担。如果系统运行正常，那么动画就完美执行，系统运行有掉帧的情况，那么就跳过一些帧，尽快让动画执行完毕。

问题怎么修复？

其实整个问题有两个修复方案：

用systrace来做监控，看看到底第一次初始化fragment的时候 是卡在哪里了，直接修复问题的本质。这种修复方案更加彻底，但是美中不足的是需要一定的时间，且如果你本身对这块代码不熟悉，建议不要在项目临近发布的时候采用这种修复方案

既然是fragment第一次初始化的时候才会有这种问题，那我们稍微延迟一下第一次动画的执行时机，让他在fragment初始化完毕以后再去执行动画不就行了？

代码如下：

@Override

public void onResume() {

super.onResume();

//确保当fragment 初始化完毕以后 主动调用一下 tab切的动画

if (mIsFirstInitFlag ) {

((MainActivity) getActivity()).playForumLottieAnim();

mIsFirstInitFlag = false;

}

}

复制代码

关于找一找教程网

本站文章仅代表作者观点，不代表本站立场，所有文章非营利性免费分享。

本站提供了软件编程、网站开发技术、服务器运维、人工智能等等IT技术文章，希望广大程序员努力学习，让我们用科技改变世界。

[Android性能优化-你的lottie动画今天跳帧了吗？]http://www.zyiz.net/tech/detail-116116.html