简介：在移动应用开发中，动效是提升用户体验的关键一环。开发者常面临GIF、帧动画与Lottie等方案的选型困境。PAG（Portable Animated Graphics）作为腾讯开源的动效工作流，采用自研二进制格式与C++渲染内核，支持运行时文字、图片替换，有效解决复杂动效的模板化与跨端一致性问题。本文基于Android平台，从动效方案对比出发，详细介绍PAG的工程接入、播放器使用、性能优化及踩坑记录，帮助开发者在电商、直播等高频动效场景中高效落地，实现流畅稳定的交互体验。
1. 为什么我在Android动效方案里选了PAG
做Android开发这些年，动效需求从来就没断过。早期做启动页、引导页、按钮反馈，我基本都是GIF和帧动画一把梭，后来项目里开始用Lottie，解决了大部分UI动效问题，但真正让我决定把PAG引入工程体系的，是一次直播间的礼物动效需求。产品要一个可以动态更换用户头像和昵称的入场动画，AE那边资源已经做好了，但Lottie对文本和图片的动态替换支持一直不太顺，尤其是这种需要"同一个模板、千人千面"的场景，Lottie实现起来很费劲。后来团队里做iOS的同事提到了PAG，我去翻了一下腾讯开源的这套方案，发现它不仅能做播放器，还支持在运行时直接替换动画里的文字、图片甚至整个图层内容。从那以后，Android端的动效开发我和团队就一直用PAG在做了。
PAG全称Portable Animated Graphics，是一套完整的动效工作流。它的设计思路跟Lottie有点像，都是把AE里做好的动画导出成一种中间格式，然后通过各端的SDK去解析和渲染。不同的是PAG用了一套自研的文件格式和渲染引擎，在动效模板替换、性能表现和覆盖能力上有明显区别。特别是对于Android平台，PAG底层有C++实现的渲染内核，加上OpenGL和Vulkan的硬件加速路径，播放复杂动效的流畅度确实比我之前用Lottie和系统属性动画组合实现要好。我的实际项目里，有一套非常复杂的礼物面板动效，图层超过80个，用PAG在主流中端机型上也能稳定跑满60帧。
如果你也在做Android端动效，无论是电商、直播、短视频还是工具类App，这篇文章里的案例和踩坑记录应该都能帮到你。我会把这套基于Android平台的PAG方案从工程接入、播放器使用到特定业务场景的落地实践完整写一遍，同时把那些官方文档没写透的细节和我们在实战里趟过的坑也一并列出来。
2. PAG到底解决了什么问题：和GIF、Lottie的一次对比
2.1 帧动画和GIF为什么撑不住复杂动效
很多时候我们会下意识地用GIF或帧动画来实现动效，因为它们简单。拿帧动画来说，就是按照设定好的帧率，把一帧一帧的图片依次播放。效果好不好，完全取决于设计师导出了多少张图。一套3秒的动画，24帧每秒，那就是72张图。我见过一些项目，启动动效一套图就占了将近20MB的内存，而且这些图还无法避免地占用了很大的包体空间。GIF的问题更明显，它只有256色，遇到渐变、光影效果就很容易出现色带，边缘还会糊。尺寸一大，文件体积也跟着失控，加载还慢。
如果需求只是简单的转圈、箭头指引，帧动画完全够用而且稳定。可一旦设计稿里出现缓动曲线、3D图层、表达式控制，帧动画和GIF就开始撑不住了。因为你没法用有限张图去平滑表达"由快到慢"这种连续变化，每两帧之间再小也有跳跃感。这也是后端同学老觉得动效"不丝滑"的根本原因。
2.2 Lottie已经很强大，为什么还要PAG
Lottie在Android端的普及度很高，它通过解析AE导出的JSON文件，用代码还原矢量图层，所以包体小、还原度高。我做过的很多UI动效，比如空状态插画、加载动画、按钮反馈，都是用Lottie搞定的，整体体验不错。Lottie的局限在于"运行时替换能力"偏弱。虽然它支持部分色值覆盖，但在文本替换、位图替换上的能力比较有限。真要往动画模板里动态塞一张用户头像，或者实时更换一段文字，Lottie通常得提前在AE里把占位层设计好，再靠代码层层寻找图层去操作，链路易碎，效果也不稳定。
另外Lottie的渲染在复杂图层上也会吃性能。一套包含几十个图层和多个预合成的大动画，Android端解析JSON和首帧渲染的时间明显偏长，低端机上卡顿掉帧是常有的事。我在做礼物面板动效时，Lottie方案连续输出了几版调试，都会出现首帧白屏和掉帧，这才把路线彻底转向了PAG。
2.3 PAG的核心优势：分层结构、模板替换、跨端一致
PAG采用了一种二进制文件格式，它对AE导出的图层结构和关键帧信息做了一套基于BMP预合成的编码存储，渲染时可以直接驱动底层引擎逐帧绘制，不需要像JSON那样逐层读取、逐字段解析。带来的直接感受就是加载速度快、打开大文件也不容易卡。更重要的是PAG支持"编辑"能力，你可以把一个PAG文件看作一个"盒子"，盒子里有文字图层、图片图层、音频图层，运行时直接通过API替换里面的内容。
这对我做的直播场景太关键了。礼物动画模板只需要一套，用户昵称、头像、礼物图标都可以在播放前动态写入。设计师改样式的成本也低，改完AE导出新的.pag，客户端代码一行都不用动。同时由于渲染内核在各端是同一套C++实现，同一份PAG文件在Android、iOS、Web、小程序上的表现是一致的，不会出现"iOS上居中、Android上偏了5个像素"这种跨端还原问题。
| 能力维度 | GIF/帧动画 | Lottie | PAG |
|---|---|---|---|
| 包体占用 | 大 | 小 | 小 |
| 矢量支持 | 不支持 | 支持 | 支持 |
| 复杂动效流畅度 | 中低 | 中 | 高 |
| 运行时文字替换 | 不支持 | 有限支持 | 原生支持 |
| 运行时图片替换 | 不支持 | 有限支持 | 原生支持 |
| 跨端一致性 | 一般 | 一般 | 较好 |
| 设计师工作流 | 导入/导出频繁 | AE插件导出JSON | AE插件导出PAG |
3. Android工程接入：环境配置与SDK初始化
3.1 依赖引入与Gradle配置
PAG在Android端的SDK发布在Maven Central上，引入方式很简单。我的工程是基于Android Studio的Gradle构建，直接在模块的build.gradle（或者现在新版项目里的build.gradle.kts）中添加依赖：
implementation("com.tencent.tav:libpag:4.3.51")这个版本号建议去官方仓库看最新的稳定版。有些项目会把PAG嵌入到自己的源码仓库里维护，但我个人不建议这么做，因为PAG的更新频率不算低，用Maven依赖可以方便地升级。需要注意的是PAG对minSdkVersion有要求，目前版本一般要求API 21以上，如果你的应用需要兼容Android 5.0以下的设备，就得考虑降级方案或者只在高端机型上启用动效。我在一个工具类App里遇到过低版本机型维护的问题，最后的做法是判断Build.VERSION.SDK_INT，小于21的机型直接隐藏动效，因为这部分用户占比已经非常低，不值得为它们牺牲整个动效栈。
如果你的工程开启了资源压缩（shrinkResources）和代码混淆（minifyEnabled），还需要在proguard-rules.pro里加入以下规则，否则Release包会出现找不到PAG类的问题：
-keep class org.libpag.** { *; } -keep class org.extra.** { *; }这个坑我在刚接入时踩过一次，当时Debug包一切正常，一打Release包动效就直接不显示，排查了半天才发现是混淆把PAG的类全部重命名了。
3.2 SDK初始化
PAG在调用任何接口之前需要先初始化SDK，初始化过程其实是在加载一些底层资源，比如字体和色彩管理相关的模块。推荐在Application的onCreate里做，而且要放在所有业务代码之前：
class App : Application() { override fun onCreate() { super.onCreate() PAG.InitSDK(this) } }值得注意的一点是，PAG.InitSDK的耗时非常短，实测基本在几毫秒到十几毫秒之间，不会影响冷启动，所以不用担心在这里做初始化会拖慢App。之前有同事把初始化放到了子线程，结果后续播放的时候偶发崩溃，定位后怀疑是并发初始化导致的线程安全问题，所以后来还是规规矩矩放回了主线程。
3.3 PAG文件的来源与结构
PAG文件的后缀就是.pag，由设计师在AE中安装PAGViewer插件后一键导出。PAGViewer既是一个AE插件，也是一个桌面端预览工具，设计师可以在不打开AE的情况下直接双击.pag文件预览动画效果，非常方便。客户端拿到.pag文件后，一般会有两个存放位置：
- assets目录：适合静态资源，比如内置的加载动画、引导动画；
- 网络下载或远端配置：适合会动态更新的资源，比如节假日活动的主题动效。
assets路径的加载通常这样写：
val pagFile = PAGFile.Load(assets.open("animations/guide.pag"))如果你接收到的是一个文件路径，则使用PAGFile.Load(path)，两者的区别只在于读取方式。这里有一个容易踩的坑：PAGFile.Load从assets加载时，传入的不是assets文件名，而是一个InputStream，所以要注意打开流的方式，如果用assets.open写错路径，SDK会返回一个空指针，表现就是动画加载不出来，但不会直接崩溃，只会留下一大串native层日志。
4. PAGView与PAGPlayer：播放器的核心使用逻辑
4.1 PAGView：最直接的UI组件
PAGView是官方封装的View组件，继承自SurfaceView。它的使用方式很接近传统的ImageView，是我在实际项目里用得最多的入口。创建方式可以直接在XML里声明：
<org.libpag.PAGView android:id="@+id/pag_anim" android:layout_width="200dp" android:layout_height="200dp" />然后在代码中加载：
val pagView = findViewById<PAGView>(R.id.pag_anim) val pagFile = PAGFile.Load(assets.open("animations/like_effect.pag")) pagView.setComposition(pagFile) pagView.setRepeatCount(1) pagView.play()setComposition将PAGFile注入到播放器中，setRepeatCount设置重复播放次数，-1表示无限循环。play()开始播放。这一段简单的逻辑足以覆盖大部分"打开页面播放动效"的场景。PAGView还提供了setProgress(float value)方法，可以手动控制动画进度，这在做拖拽进度反馈时很有用，比如视频编辑里调整转场效果，滑动进度条时动态预览动画帧。
4.2 PAGPlayer：更精细的控制入口
PAGView底层其实也是封装了一个PAGPlayer。如果需要对播放器做更精细的操作，比如把动画渲染到Bitmap上、叠加多个动画、自定义渲染环境，就需要直接操作PAGPlayer。我给大家看一个典型的PAGPlayer拿去复用渲染的例子：
val pagPlayer = PAGPlayer() val pagSurface = PAGSurface.FromSurface(textureView.surfaceTexture!!) pagPlayer.surface = pagSurface pagPlayer.composition = PAGFile.Load(assets.open("animations/avatar_frame.pag")) pagPlayer.setProgress(0.0) pagPlayer.flush()这在一些需要把动效和视频画面混合渲染的编辑类工具里非常常用。PAGPlayer是底层播放器，不依赖View树，所以你可以把动画画面输出到TextureView、SurfaceView甚至离屏渲染的Surface上。这对Android开发者来说意味着极大的灵活性，不过相应的，所有生命周期管理、线程同步都需要自己负责，比直接用PAGView要费更多心思。
4.3 监听器与动画状态回调
PAGView提供了一套监听器，可以监听动画的播放状态：
pagView.addListener(object : PAGView.PAGViewListener() { override fun onAnimationStart(pagView: PAGView?) { super.onAnimationStart(pagView) } override fun onAnimationEnd(pagView: PAGView?) { super.onAnimationEnd(pagView) // 动画播完后做回收或切换业务逻辑 } override fun onAnimationCancel(pagView: PAGView?) { super.onAnimationCancel(pagView) } override fun onAnimationRepeat(pagView: PAGView?) { super.onAnimationRepeat(pagView) } })在实际使用时，需要注意onAnimationEnd回调的时机。如果设置了setRepeatCount(-1)无限循环，onAnimationEnd不会触发，这是正常的，不要在这个坑里折腾太久。另外，如果你的动画播完需要移除View，建议在onAnimationEnd后用Handler.postDelayed做一个短暂延后，原因是onAnimationEnd虽然回调了，但底层渲染的最后几帧可能还没来得及完全绘制，立刻移除View会出现闪一下白屏的视觉BUG，我遇到过两次，后来统一延后200ms再回收，问题就消失了。
5. 案例实战：业务场景里的PAG落地
5.1 首页引导弹窗动效
弹窗动效是PAG最常见的应用场景之一。我有一个实际的首页弹窗需求：弹窗背景是一个缩放加渐变的动画，中间区域要放一个活动的宣传图，弹窗底部有一个动态变化的按钮。
用PAG实现的话，设计师会做一个完整的弹窗动效，其中活动宣传图的位置是一个占位图图层，播放前我把用户当前要展示的图片替换进去：
val pagFile = PAGFile.Load(assets.open("animations/home_popup.pag")) val imageLayer = pagFile.getLayersByEditableIndex(0, PAGLayer.LayerType.Image) if (imageLayer.isNotEmpty()) { val pagImage = PAGImage.FromBitmap(bitmap) imageLayer[0].replaceImage(pagImage) } pagView.setComposition(pagFile) pagView.play()基本逻辑就是通过getLayersByEditableIndex拿到动画文件里的可编辑图层，然后调用replaceImage替换内容。PAG的图层索引是按照AE图层顺序来排列的，所以需要设计师在导出时保证图层顺序固定，否则客户端代码会因为索引错位而替换到错误的内容。这里有一个好的协作习惯：在设计资源交付时，我一般会让设计师把可编辑图层放在AE合成的最上面三层，并且固定命名规则，比如"img_cover""text_name"。这样即使在动画迭代中图层数量变化，只要遵循命名规则，客户端也能正确找到对应的可编辑索引。
5.2 点赞连击的循环动画
点赞动画是直播和社交App里高频使用的动效。它的特点是出现频率高、单个动画短、经常需要快速连续触发。PAG做这个场景非常拿手，我们可以把动画文件循环播放，同时每次触发时把点赞数作为文本替换进去：
val pagFile = PAGFile.Load(assets.open("animations/like_burst.pag")) val textLayers = pagFile.getLayersByEditableIndex(0, PAGLayer.LayerType.Text) if (textLayers.isNotEmpty()) { val textLayer = textLayers[0] as PAGTextLayer textLayer.setText("+1") } pagView.setComposition(pagFile) pagView.setRepeatCount(-1) pagView.play()点赞连击最怕的是内存暴涨。如果每次点击都创建一个新的PAGView，动画结束也不及时释放，很快就会出现OOM。我建议在页面级别维护一个PAGView对象池，比如保存最近使用过的3个实例，触发点赞时从池里取，如果没有再new，播完的动画就重新放回池子复用。实测在持续点击1-2分钟的场景下，内存占用能稳定控制在一个很低的水平。
另外一个经验是，连击数字的动画最好单独做成一个只包含文本层的PAG文件，不叠加其他装饰图层，这样即使是不停地替换文本，性能开销也非常小。装饰性的光效、粒子效果作为背景层做在一个固定的PAG里循环播放，两者叠加，视觉效果和流畅度都会更好。
5.3 礼物面板的文字和头像替换
直播间礼物动画应该算PAG的主场了。我参与的一个项目里有一套豪华礼物动效，整套动画包括：背景光晕、粒子拖尾、礼物主体展示、用户昵称呈现。其中用户昵称是文字图层，用户头像是一个图片占位图层，礼物图标本身也是一个图片占位图层。播放前，要先完成三处替换：
val pagFile = PAGFile.Load(assets.open("animations/gift_super.pag")) // 替换昵称 val textLayer = pagFile.getLayerByName("text_user_name") as? PAGTextLayer textLayer?.setText(userName) // 替换头像 val avatarLayer = pagFile.getLayerByName("img_avatar") as? PAGImageLayer avatarLayer?.replaceImage(PAGImage.FromBitmap(avatarBitmap)) // 替换礼物图标 val giftLayer = pagFile.getLayerByName("img_gift_icon") as? PAGImageLayer giftLayer?.replaceImage(PAGImage.FromBitmap(giftBitmap)) pagView.setComposition(pagFile) pagView.play()注意这里我用的是getLayerByName，这种方式比getLayersByEditableIndex更稳定，因为它不受图层顺序变化影响。前提是设计师在AE里给关键图层命名时要规范，最好和客户端约定好一套命名规范。我实测过，一个包含20多个图层的PAG动画，运行时替换三处内容，整个过程的耗时基本可以忽略，首帧渲染也很顺畅。关键点在于，PAG的图像替换后不需要重新解析整个文件，这和Lottie动一处就重新渲染整个动画的性能差距非常明显。
5.4 聊天列表里的头像动效
聊天气泡里的头像动效，是我做过的一个比较有意思的需求。产品希望用户在聊天时，如果对方正在输入，头像旁边能有一个小的录音波纹动画。这个动画很小，但是出现在RecyclerView列表里，每个聊天对象都可能触发，所以对性能和复用性要求比较高。
这里的实现方案是：列表项的布局里放一个固定大小的PAGView，当收到正在输入的事件时，调用PAGView播放对应的小动画；对方停止输入时，调用stop并重置进度。由于PAGView自身是SurfaceView，如果在滚动列表时频繁创建和销毁，性能损耗会很大。我的做法是，在Adapter的ViewHolder里提前创建好PAGView，并且复用同一份PAGFile实例，不同item之间共享这份文件：
companion object { private var typingPagFile: PAGFile? = null } fun getTypingPagFile(context: Context): PAGFile? { if (typingPagFile == null) { typingPagFile = PAGFile.Load(context.assets.open("animations/typing_wave.pag")) } return typingPagFile }这样每个item只需要setComposition并play，不需要重复加载文件。实测在列表快速滚动的场景下，PAGView不会出现卡顿，与其他UI元素的交互也正常。要注意的是，一个PAGFile实例同时被多个PAGView使用是OK的，因为PAGView内部是线程安全的，但不能同一个PAGView同时播放两个动画，那不是它该干的活。
6. 性能与内存优化：PAG不是拿来就能跑的
6.1 首帧性能为何重要
动效首帧渲染的性能直接决定了用户是否觉得"卡"。PAG虽然底层做了很多优化，但如果动画文件过于复杂，首帧的渲染耗时依然会很明显。我在一个项目中遇到过这种情况：动画文件里有大量模糊滤镜、发光效果，还有好几层预合成，在部分中低端机型上首帧渲染需要500ms以上，用户打开面板时能明显感觉到白了一瞬。
缓解方式有几个思路。第一个是在播放前主动调用一次prepare()或flush()，让SDK提前完成资源的解析和纹理上传，相当于预热。第二个是降低动画首帧渲染的分辨率，在动画对清晰度要求不高的情况下，可以缩小PAGView的宽高，或者给PAGFile设置一个scaleMode和maxScale，别让它在超大画布上渲染再等比缩放到小控件上。第三个是避免在动画播放的同一时刻做大量其他耗时操作，比如网络请求、数据库读取，尽量把非必要操作延后到动画播放间隙。
6.2 PAGFile的缓存策略
PAGFile从assets加载一次的时间虽然总体可控，但在需要频繁展示的场合适时缓存是有收益的。我维护了一个简单的LRU缓存：
object PagCacheManager { private val cache = object : LinkedHashMap<String, PAGFile>(8, 0.75f, true) { override fun removeEldestEntry(eldest: MutableMap.MutableEntry<String, PAGFile>?): Boolean { return size > 10 } } fun getOrLoadFromAssets(context: Context, path: String): PAGFile? { cache[path]?.let { return it } val file = PAGFile.Load(context.assets.open(path)) cache[path] = file return file } }缓存的好处是，用户反复打开同一个动效面板时，不会每次都重新解析文件。但要注意，PAGFile本身是有状态的，如果你在播放前修改了其中的文本或图片图层，同一份PAGFile实例被多个PAGView复用时，上一次的修改会残留。所以在每次setComposition之前，需要调用pagFile.removeAllPAGLayers()或者重置可编辑图层，我习惯用独立的方法做一次"还原到初始状态"的操作。这个细节容易忽略，我在做礼物动画复用时踩过一坑，用户第一次AA的头像，第二次播放时还残留着，最后排查发现就是PAGFile没有重置。
6.3 硬件加速与SurfaceView选型
PAGView默认基于SurfaceView，能在独立线程上渲染，避免阻塞主线程。但SurfaceView也有缺点：它自带一个独立的窗口，无法直接应用View的平移、缩放、旋转等属性动画。如果需要对动效本身做进入动画（比如弹窗缩放），你最好在外层包一个普通的ViewGroup来做这些动画，而不是直接操作PAGView。
PAG还支持在TextureView上渲染，只需要把PAGView替换成PAGTextureView。TextureView可以像普通View一样被变换和叠加，但性能消耗通常比SurfaceView高一些，而且如果不小心在低端机上频繁变更TextureView的尺寸，会引发较明显的掉帧。我的结论是：静态展示、全屏播放用PAGView；需要混在复杂View树里做变换、或者需要和Camera视频流叠加的场景，再用PAGTextureView。
6.4 内存回收与生命周期管理
很多人问我PAG会不会内存泄漏。答案是：如果你不按生命周期管理，任何播放器都会泄漏。PAGView持有native层对象，如果Activity销毁了但PAGView还在播放，就会造成内存泄漏。我的标准写法是在Activity或Fragment的onDestroy时，主动释放：
override fun onDestroy() { super.onDestroy() pagView.stop() pagView.release() }release()会释放PAGView持有的所有资源。如果是在列表项里，ViewHolder被回收时也要注意释放PAGView相关的资源，但因为有复用机制，不能简单地release，最好是调用stop并把progress归零。我这里说的一个可复用的经验是：在一个大型直播App里，我曾经监控过PAG相关对象的内存占用，做了合理的释放后，内存资源占用下降了40%左右。这个收益比较明显，值得在接入之初就做好规划。
7. 踩坑实录：那些年我们追过的PAG问题
7.1 加载PAG文件返回空的排查过程
有一次我遇到了一个非常奇怪的问题：同一个PAG文件，在Debug包能正常播放，但Merge到Release包之后加载回来就是null。一开始我怀疑是混淆，加了混淆规则后依然无效。后来把apk解包，去assets目录里找这个文件，发现文件大小变成了0KB。原因是在配置shrinkResources时，AGP误以为这个.pag文件没有被引用到，直接给删了。当时我们的加载代码是通过字符串拼接的assets路径动态读取的，AGP静态扫描不到这个引用，所以资源优化把它当成了无用资源。
解决方法是在res/raw或者assets的keep规则里显式声明文件不被优化，更省事的做法是关闭shrinkResources对assets的裁剪，或者把PAG文件放到assets/raw子目录下，Android的AAPT2对assets目录的处理会相对保守一些。这个坑最好在项目刚接入PAG时就做好规避，不然Release审计的时候临时排查非常麻烦。
7.2 动效偶发花屏和闪黑
PAGView基于SurfaceView，在某些定制ROM上会出现偶发花屏或者闪黑的情况。我排查下来，多数问题与SurfaceView的Surface被系统回收有关，比如应用切到后台再切回来，SurfaceView的surface状态发生变化，而PAGView没有及时重建渲染上下文。表现就是动画黑屏几秒或者出现颜色错乱。
我的处理方案是监听PAGView所在的Activity/Fragment的onResume和onPause，在onPause时暂停播放，在onResume时判断动画是否应该继续，然后重新play。同时，在自定义PAGView时也可以重写surfaceDestroyed和surfaceCreated，在surface销毁时清理依赖Surface的渲染资源，在surface重新创建时重新绑定。官方SDK后续版本已经优化了一部分，但ROM层的问题总是防不胜防，提前做好生命周期绑定可以避免大部分闪黑。
7.3 文本替换后字体不一致
PAG在文字图层替换时，默认使用PAG文件内嵌的字体信息。如果你在AE里用了某个特殊字体，而客户端本地没有该字体，替换后的文字可能会回退到默认字体，导致画面里的显示效果和设计稿有差异。PAG提供了注册字体的API：
PAGFont.RegisterFont("path/to/custom_font.ttf")需要在替换文字之前调用，让SDK能正确匹配到目标字体。我在做礼物文字特效时，用户昵称一定要用一款指定的圆体字，不注册字体的时候替换出来的文字非常难看，注册之后就跟AE里预览的几乎一致了。这个细节挺容易被忽视，等设计师发现"为什么我设计的字体变了"再来排查，往往要浪费不少时间。
7.4 双击点赞时动画手势冲突
PAGView本身并不拦截点击事件，但它会占用触摸区域。如果你的PAG动画作为一个全屏层盖在页面上，用户会发现点击事件传不下去了。我在做直播间的观众席动画时，礼物动效是全屏展示的，动画播放期间，用户点击屏幕应该能触发点赞，但PAGView把触摸事件拦截了。最简单的处理方式是：在动画播放期间，给PAGView设置setClickable(false)，并让它在触摸事件分发时不消费事件：
pagView.setOnTouchListener { _, _ -> false }或者更直接一点，不让PAGView覆盖整个点击区域，动画结束直接置为GONE。当然这会牵扯到业务交互逻辑的设计，我的建议是：动效播放期间，如果用户需要操作手势，一定不要把PAGView做成一个全屏吸顶的"玻璃罩"，而是让它在视觉上覆盖、在事件上透明。
8. 动效模板化的工程落地：从单案例到组件体系
8.1 把PAG封装成基础组件
当一个项目里的PAG场景越来越多，最好做一次统一封装，而不是每个页面各自new PAGView、各自管理生命周期。我在目前的项目里维护了一个简单的PagAnimView组件，它内部封装了加载、播放、替换、释放这些重复逻辑，对外只暴露几个业务方法。
这个组件内部持有PAGView实例，统一管理onPause和onResume，并且在onDestroy时自动release。对外提供：
fun playAnimation(path: String, repeatCount: Int = 1) fun replaceText(layerName: String, text: String) fun replaceImage(layerName: String, bitmap: Bitmap?) fun setOnAnimEndListener(listener: () -> Unit)统一封装之后，业务侧的调用代码会变得非常简洁，遇到生命周期问题也能在组件层一次性解决，不用每个页面都写一遍。这个封装模式对维护成本高的项目特别有利。
8.2 模板文件与业务配置解耦
动效更新最怕的是发版。如果某个节日动效需要替换，你把PAG文件直接写死在assets里，就意味着必须发版本才能换。我们现在的做法是把PAG文件上传到配置中心，客户端启动时根据配置拉取文件列表，下载到本地缓存目录，再通过路径加载播放。这样设计师的动效更新、运营的活动配置，都不需要客户端发版。
在实现时要注意管理下载文件的版本号和清理策略，避免缓存文件越来越多。我一般会在下载时先判断文件MD5是否变化，没变化就复用旧文件，减少无效流量。文件名称按"动效ID_版本号.pag"命名，替换时直接删除旧版文件。
8.3 多端复用的深远价值
PAG的价值不仅体现在Android端。因为格式和渲染内核统一，同一份PAG文件可以直接用于iOS、Web、小程序。我们团队在引入PAG后，设计师只需要导出一份文件，iOS和Android同时复用，这一下省掉了过去"分别实现两套动效"的重复劳动。在做跨端动效时，PAG的文件格式一致性带来的收益是实打实的。
9. 关于PAG，我最后想说的一点经验
做Android动效这几年，我最大的体会是：选对工具链，比闷头敲代码重要得多。PAG在模板替换、跨端一致性和复杂动效的性能表现上，确实值得投入。我会建议任何要在App里做复杂动效的团队，都去研究一下PAG，而不是一上来就用帧动画或者GIF硬扛。
实际操作中，我最推荐的快速上手路径是：先让设计师安装PAGViewer插件，导出一个示例动画，Android端从assets加载、播放跑通；然后做一次文本或者图片的替换，体会一下PAG的核心能力；最后再考虑缓存和封装的问题。等这套流程跑顺之后，你会发现动效开发和普通UI开发没什么区别，都是一样的规范流程。
如果你正在评估Android端的动效方案，希望这篇基于实际项目经验的内容能从环境搭建、案例设计到坑点排查给你一个完整的参考。我自己在接入过程中也踩了不少不必要的坑，如果这些记录能让你少走几个弯路，那就很值了。
本文还有配套的精品资源，点击获取
