底部导航栏是用户操作频率最高的组件之一，当点击某个Tab时，如果图标能播放一段短小的连续动画，整体体验会明显上一个台阶。实现思路本质上都是帧动画：把动画拆成若干张图片，按固定时间间隔依次切换显示。听起来简单，但一旦图片数量多、尺寸大，就容易出现卡顿、内存飙升甚至OOM的问题。这篇文章就来聊聊几种主流实现方式的原理、优缺点以及优化技巧。
最直接的方式：ImageView逐帧切换
最朴素的做法是用一个线程或Handler定时切换图片资源。在Android平台上，系统提供了现成的AnimationDrawable，把一系列drawable资源按顺序编排，调用start方法就能播放。这种方式实现成本极低，适合图片数量不多、单帧体积可控的场景。
它的原理是把每张图片在动画启动时解码并保存在内存中，播放时只是依次设置到ImageView上。问题也出在这里：如果动画有30帧，每帧都是一张几百KB的PNG，全部解码成Bitmap后内存占用可能达到几十MB，低端机型上很容易触发OOM。因此在采用这种方式之前，必须先控制好帧数和图片尺寸。
<animation-list xmlns:android="http://schemas.android.com/apk/res/android"
android:oneshot="true">
<item android:drawable="@drawable/tab_home_1" android:duration="50" />
<item android:drawable="@drawable/tab_home_2" android:duration="50" />
<item android:drawable="@drawable/tab_home_3" android:duration="50" />
<item android:drawable="@drawable/tab_home_4" android:duration="50" />
<item android:drawable="@drawable/tab_home_5" android:duration="50" />
</animation-list>对应在代码中启动动画非常简单：
ImageView tabIcon = findViewById(R.id.tab_icon); tabIcon.setImageResource(R.drawable.tab_home_anim); AnimationDrawable drawable = (AnimationDrawable) tabIcon.getDrawable(); drawable.start();
需要注意的是，AnimationDrawable的每帧时长最好控制在40到60毫秒之间，也就是大约每秒16到25帧，低于这个频率动画会显得一顿一顿的。另外可以在动画播放结束后通过回调把ImageView恢复为静态图标，避免持续占用资源。
进阶方案：用序列图与属性动画降低内存开销
当帧数较多时，逐帧切换的内存问题就会凸显。一个经典的优化手段是把所有帧合并到一张大的序列图（也叫雪碧图或Sprite Sheet）上，然后利用属性动画不断改变ImageView的裁剪区域，让不同帧轮流露出来。这样只需要一次解码，内存里只有一张大图，切换时也不涉及Bitmap的创建和销毁，性能非常好。
具体做法是通过Matrix或者自定义View的onDraw方法，根据当前动画进度计算偏移量，每次只绘制序列图中的某一个小格。属性动画的插值器可以让帧切换严格按时间轴推进，精度比Handler定时器更高，也不会受到消息队列拥堵的影响。
ValueAnimator animator = ValueAnimator.ofInt(0, frameCount - 1);
animator.setDuration(frameCount * 50); // 每帧50毫秒
animator.addUpdateListener(animation -> {
int frame = (int) animation.getAnimatedValue();
spriteView.setFrameIndex(frame); // 自定义View根据索引裁剪绘制对应帧
});
animator.start();这种方案的代价是需要设计侧配合导出序列图，并且动画帧之间的尺寸必须完全一致。如果后续动画需要频繁修改，重新拼图会比较麻烦。另外序列图的宽高要注意不能超过GPU支持的最大纹理尺寸，一般控制在4096像素以内是安全的。帧数特别多时，可以把序列图拆成多张，分批加载。
更现代的选择：Lottie与矢量动画
如果团队有动效设计资源，强烈建议考虑Lottie。设计师在After Effects中用Bodymovin插件导出JSON文件，客户端直接加载播放即可。它的本质是用矢量绘制替代位图切换，动画文件通常只有几十KB，却能做到接近无损的画质和任意帧率的流畅播放，内存和CPU开销都远低于多张PNG的方案。
对于底部导航栏这种小尺寸图标动画，Lottie的渲染成本几乎可以忽略。它还支持进度控制、循环、速度调节等能力，配合ViewPager的滑动进度做联动动画也十分方便。唯一的门槛是复杂动画可能需要在设计阶段就做好性能约束，比如避免大量图层叠加和模糊效果。
LottieAnimationView tabAnim = findViewById(R.id.tab_lottie);
tabAnim.setAnimation("tab_home.json");
tabAnim.setProgress(0f);
// 播放一次动画，结束后还原为静态态
tabAnim.playAnimation();除了Lottie，APNG和WebP动图也是可选方案。WebP动图在同画质下体积比GIF小很多，Android原生支持解码，用一张文件就能承载整个动画，不需要切图和编排。不过WebP动图的解码在部分老机型上会占用一定CPU，如果是常驻播放的动画需要实际测试帧率表现。
性能优化与工程实践建议
无论选择哪种方案，有几个通用原则必须遵守。第一，动画资源要按需加载，点击Tab时才初始化动画，切换离开后及时释放或复用。如果四个Tab都预加载动画，启动阶段的内存压力会成倍增长。第二，图片解码尽量使用RGB_565格式，在小图标场景下视觉差异几乎看不出来，但内存能省一半。
第三，动画播放期间不要在主线程做解码操作。大图应该提前在子线程解码好缓存起来，或者使用Glide、Coil这类图片库的GIF和帧序列支持，它们内部已经做了解码线程管理和内存缓存。第四，注意动画时长的控制，底部导航栏的切换动画一般在300到600毫秒之间，过长会让人感觉反应迟钝，过短又看不出效果。
最后做一个方案对比总结：帧数少、改动少的简单需求用AnimationDrawable最快；帧数多、追求极致性能用序列图加属性动画；有设计资源、动画复杂度高的用Lottie；懒人方案可以直接上WebP动图。结合自己项目的帧数、包体和人力情况选择合适的路线，就能在保证流畅度的前提下，让底部导航栏的图片动画成为产品体验的加分项。