企业官网建设流程全解析

开机动画这东西，平时没几个人会正眼瞧它，但真到了产品量产、客户验收、展会演示的时候，它往往是第一眼就被盯上的环节。尤其是RK3588这颗芯片，性能强、接口多，在高端盒子、边缘算力设备、商显一体机上遍地都是，客户十有八九会提一句“开机画面能不能换成我们的品牌视频”“动画能不能流畅一点，别跟幻灯片似的”。我前前后后在RK3588平台的Android系统上做过好几轮开机动画定制和帧率优化，踩过的坑不少，但沉淀下来的套路也基本稳定了。这篇东西就把整个思路、代码位置、资源规范以及优化手段整理出来，给正在折腾这块的同行省点时间。

不管你是刚接触Android系统定制的新手，还是已经在别的平台上有过开机动画经验、想快速切换到RK3588的老手，这篇文章都按照“原理—设计—改造—优化—排障”的顺序来拆解。核心就是解决两件事：一是让动画按你想要的样子播出来，二是让它播得够顺够快，不影响系统启动的整体节奏。

1. 开机动画到底是怎么跑起来的

定制开机动画的第一步，不是急着找素材，而是先把Android系统里这套动画机制摸清楚。很多人在网上搜到一堆bootanimation的教程，照着改了一通，结果发现有的平台生效、有的平台不生效，或者改了分辨率画面就糊了，根源就在于没搞懂这套机制在系统里是怎么被拉起、怎么解析、怎么绘制的。

1.1 Bootanimation进程的启动链条

从系统启动的角度看，Android在init进程解析rc脚本的阶段就会根据trigger去拉服务。开机动画服务在AOSP里定义在bootanim.rc中，关键内容大致是：

service bootanim /system/bin/bootanimation class core user root group graphics graphics disabled oneshot

注意看几个关键字段：disabled表示默认不启动，oneshot表示执行一次就退出。真正拉起它的是SurfaceFlinger完成启动后发出去的bootanimtrigger。所以你会看到开机动画的启动时机被设计成“等图形系统就绪之后再播”，而不是内核一上来就播。在RK3588平台上，这个逻辑没有本质变化，但由于芯片方案里往往有自研的硬件合成、快速启动之类的特性，不同厂商SDK可能对trigger时机做了微调，导致动画出现早晚不同。

另外负责播放动画的二进制叫bootanimation，在AOSP里对应的源码路径是frameworks/base/cmds/bootanimation/。而真正决定播放效果的资源包，是/system/media/bootanimation.zip，或者在一些厂商SDK里改名为bootanimation.mp4之类的视频格式。对RK3588这种性能强的平台来说，视频格式的开机动画越来越常见，因为它能承载更高压缩比的素材、色彩表现更好，但代价是解码资源的占用。

1.2 动画资源包的内部结构与打包规范

如果你走的是传统ZIP路线，那么bootanimation.zip内部必须遵守约定格式，否则动画要么不播、要么只播一部分。典型结构如下：

bootanimation.zip ├── desc.txt ├── part0/ │ ├── 00000.png │ ├── 00001.png │ └── ... ├── part1/ │ ├── 00000.png │ └── ... └── part2/

desc.txt是整个动画的“剧本”，每一行都有明确含义。我随便写一个例子：

1080 1920 30 p 1 0 part0 p 0 0 part1

第一行三个数字分别代表显示宽度、显示高度、帧率。第二行p 1 0 part0表示播放part0目录的图片1次，0代表这一轮播放完后的停顿时间（单位是帧数，不是秒）。第三行p 0 0 part1里的第一个0是循环播放的意思，通常最后一段都设置成循环，充当“等待系统启动完成”的占位动画，直到系统发来退出命令。

图片命名必须是纯数字并且按顺序补零，最终从00000开始递增。格式上可以用PNG或JPG，但要注意每个part内部的图片尺寸必须和desc里声明的宽高严格一致，不然很多版本会直接放弃绘制，或者出现黑边、截断。

在RK3588平台上，分辨率通常很高，动不动就是4K的屏。如果素材是4K的一整张渲染图序列，体积会很大，后面我会讲怎么压缩和处理。但前提是先把这套结构吃透，否则优化根本无从谈起。

1.3 系统源码里的播放与绘制循环

bootanimation进程的播放核心是一个循环：读取desc.txt里面的part定义，然后对当前part的图片序列逐帧解码、提交给SurfaceFlinger合成显示。每一帧之间通过usleep之类的机制控时，目标是让实际播放节奏尽量贴近desc里声明的帧率。

这里有个很多人容易忽略的点：bootanimation不只是画图给你看，它还会响应系统的控制消息，比如SERVICE_START、SERVICE_STOP。系统在启动接近完成时会通过属性或Binder通知动画进程退出，动画进程收到通知后就会播放完当前循环的最后一帧，然后释放资源、退出服务。整个开机过程能否“动画与桌面无缝衔接”，就看这个退出时机被触发得准不准。

看源码时重点盯这几个函数：BootAnimation::readyToRun()、BootAnimation::movie()、BootAnimation::android()，前者负责初始化显示资源，movie()是播放ZIP动画的主循环，android()是播放默认Android logo动画的兜底逻辑。定制的时候，如果你的动画不生效，很有可能是走了android()分支而不是movie()分支，原因多半是ZIP包格式不对，或者文件路径没放对。

2. 定制前必须想清楚的设计问题

很多人拿到RK3588的开发板，第一件事就是打开Photoshop疯狂出图，然后直接塞进ZIP包。这种做法在demo阶段没问题，但到了产品阶段往往会翻车。定制开机动画不只是一堆图片的播放，它涉及分辨率适配、色彩空间、字号字体、品牌露出节奏，甚至还要考虑不同开机场景的差异化表现。这些想不清楚，后面优化和适配就是无底洞。

2.1 素材规格与特效选择的取舍

先敲定输出分辨率。对RK3588设备来说，常见的屏幕输出有1080p、2K、4K几种。我建议按照目标屏幕的物理分辨率来制作素材，不要统一做一套4K然后靠系统缩放。虽然RK3588的GPU做缩放不费劲，但开机动画阶段系统服务才刚刚起来，缩放、合成都会增加额外负载，容易在低端内存配置的设备上出现掉帧。如果实在想省事，至少保证素材宽高比和目标屏幕一致，否则黑边问题很难看。

然后是颜色格式。图像编辑软件默认导出RGBA8888的PNG，这对动画包体积来说相当不友好。其实开机动画里大量帧是静态渐变或品牌Logo，色彩的精度要求没那么极端，使用RGB565格式的JPG压缩图，肉眼几乎分辨不出差别，但每一帧的体积可能缩小一半以上。后面优化章节我会详细对比不同格式的实测收益。

再说特效的取舍。RK3588性能强，但开机动画的特效更多是“设计问题”而不是“性能问题”。比如粒子效果、3D翻转、模糊过渡，在30fps的动画里强行做，一是制作成本高，二是在解码负载波动时观感反而更差。我个人的建议是，把视觉重心放在前两秒的品牌露出和最后一秒的过渡收尾上，中间用简洁的循环动效填充，这样既能体现质感，又能降低素材总量的压力。

2.2 动态数据与静态画面的结合策略

有些设备希望在开机动画里显示实时状态，比如“正在启动…”“正在加载用户数据”“系统升级中”，这些文字信息如果做成图片序列，那播放逻辑完全没法动态变化。RK3588平台上的做法通常有两种：

第一种，也是改动最小的一种：在动画末尾的循环part里预留一个镂空区域，然后通过一个独立的系统服务或SurfaceFlinger叠加层去绘制动态文字。但这种方式协调成本高，容易跟动画合成图层打架。

第二种，是直接魔改bootanimation源码，在绘制循环里叠加文字。这个方法我实际用过，虽然要动C++代码，但控制力最强。核心思路是在movie()的循环里识别当前帧，判断是否存在文字区域，如果存在就通过Skia或其他2D绘制接口把字符串画到当前帧的Buffer上，然后再提交合成。这样动画的图片素材可以完全保持静态背景，而文字区域动态渲染，灵活得多。

从产品定义角度，我更推荐后一种方案。因为开机动画里的动态文字往往和系统状态绑定，比如恢复模式、OTA升级、首次开机引导，这些场景的文案和颜色都不一样。如果用图片序列处理，每个场景要出一套图，维护成本高得吓人。编码实现动态文字，一次改造，后面所有场景通吃。

2.3 多屏异显场景下的开机动画布置

RK3588一个非常突出的特性就是多屏异显，经常有设备同时接HDMI主屏、MIPI液晶屏和副屏广告屏。默认的bootanimation只会往主显示设备上画，副屏大概率是黑着的，或者只能显示默认logo。这在一些商显设备、收银设备上是不可接受的。

如果要做多屏开机动画，通常有两个层次。浅层做法是依赖RK方案里的显示驱动配置，让多个显示控制器同时输出同一个图层的信号，这样所有屏幕都能看到画面，代价是各屏内容完全一致，没法差异化。深层做法是修改bootanimation的绘制逻辑，让它感知到系统里存在多个Display，分别创建Surface并各自绘制不同内容。这个改动复杂，但效果最好，比如主屏播品牌视频、副屏播操作指引，甚至可以把副屏做成“开机倒计时+广告位”。

我实测在RK3588上做双屏动画改造，发现最麻烦的不是绘制本身，而是SurfaceFlinger的Display配置和BufferQueue的同步。两个Display的vsync周期可能不一致，如果各自提交的节奏没对齐，会出现一边流畅一边卡顿。后面优化章节我再具体展开怎么处理这类不均衡问题。

3. 从ZIP到MP4：RK3588平台上的动画格式演进

在RK3588平台上，开机动画的格式选择跟以往的低端平台有明显不同。以前为了省CPU，大家老老实实用ZIP加PNG；现在这颗芯片的解码能力很强，硬件视频解码器性能溢出，很多人开始把开机动画做成一段H.264或H.265的MP4。这种做法的优势很直观，但也引入了新的问题。我先对比一下两种方案的适用场景。

3.1 MP4开机动画的源码接入方式

RK3588的Android SDK里，通常在bootanimation源码中会加入针对MP4格式的分支。判断方式很简单，启动时先看/system/media/bootanimation.mp4是否存在，如果存在就调用MediaExtractor和MediaCodec做解码播放。整体流程是：创建解码器、配置ImageReader或Surface作为输出、从MP4里逐帧读取并提交显示。

这里有一个非常容易被坑的点：MediaCodec的启动需要依赖mediaserver或者mediacodec相关服务已经就绪。在开机动画启动这么早的阶段，这些服务未必已经完全跑起来。所以很多厂商SDK的实现里会做“等待解码器可用”的逻辑，如果超时就直接回退到ZIP播放。我之前在某个RK3588的工程版本上就遇到过：MP4动画在冷启动时偶发黑屏，排查到最后是MediaExtractor拿不到解码器实例，服务注册还没完成。

如果你要自己实现MP4分支，我建议把这部分逻辑做成串行探测：先尝试MP4解码，设置一个不超过2秒的超时窗口；超时则释放相关对象并回退到ZIP模式。这样即便解码链路出了问题，也不至于让用户盯着一块黑屏发呆。

3.2 视频编码参数与容器选择的独家建议

做MP4开机动画时，不要直接把剪辑软件默认导出的文件丢进系统里。我踩过不少坑之后总结了一套参数组合，在RK3588上兼容性最好：

编码格式：H.264 High Profile 分辨率：与屏幕物理分辨率一致 帧率：30fps或60fps（根据素材复杂度） 视频码率：10~20Mbps（1080p），20~40Mbps（4K） 关键帧间隔：1秒或2秒 色彩空间：BT.709 容器：MP4，faststart开启 音频轨道：无

有人为了让动画更清晰，把码率拉到50Mbps以上，结果设备启动时存储带宽本来就被占用很大，高码率导致解不出来，画面反而一卡一卡的。码率并不是越高越好，开机动画不是视频比赛，肉眼看着干净、播放稳定才是第一位的。faststart参数也很重要，它把moov元数据前置，解码器可以更早拿到索引信息，避免从头扫描，减少起动延迟。

另一个细节是编码Profile别用Main以外的奇怪变种，H.264 Baseline在某些解码器上对B帧支持不完整，High Profile则要注意参考帧数量设置，数量太大会增加解码器压力。我的经验是refs保持默认2或3就足够，别为了压缩率去改成5以上。

3.3 音频通道：要不要保留开机音效

MP4格式天然支持音频轨，于是很多人顺手就把一段音效塞进了开机动画。从技术上讲，RK3588的AudioFlinger在这个阶段已经能工作，音效可以播出来。但这带来两个潜在问题：一是开机动画退出时，音频流要处理干净，否则会出现“动画停了声音还在”的怪象；二是有一些设备会被要求静音开机，你不能让用户通过设置把系统音量关掉之后，开机还是“嗡”地响一下。

我的建议是，除非产品定义明确要求开机音效，否则一律不要放音频轨。如果真的需要音效，我更推荐在SystemUI或Launcher启动完成的回调里单独播放，这样既不影响开机动画的解码性能，也更容易做音量策略控制，比如“首次开机播放音效，后续开机不播放”。

4. RK3588平台移植与源码级改造

搞清楚了素材和格式，接下来就是真正的源码改造环节。RK3588的Android SDK虽然是基于AOSP做的定制，但在文件路径、编译方式、显示架构上都有一些差异。直接照着高通或全志平台的教程硬搬，很容易遭遇编译不过、显示异常这类问题。这一节我把移植和改造过程里最关键的几个点拆开讲。

4.1 定位bootanimation在厂商SDK中的位置

RK3588的Android SDK一般在device/rockchip/rk3588/目录下存在设备级配置。开机动画服务相关的rc文件有两种存在方式：一种是沿用AOSP的bootanim.rc，另一种是被放在device/rockchip/common/下的公共rc片段里。你可以先用find device/rockchip -name "*bootanim*"去全局搜索，定位到了再操作，别凭记忆去改一个不存在的路径。

编译bootanimation模块本身不复杂，在源码根目录下执行：

source build/envsetup.sh lunch rk3588_userdebug mmm frameworks/base/cmds/bootanimation

生成的二进制在out/target/product/rk3588/system/bin/bootanimation。如果你要替换系统默认的动画包，直接push到/system/media/bootanimation.zip或/system/media/bootanimation.mp4，然后重启验证即可。这是在开发阶段最快速的验证循环，不必每次都打完整固件。

但需要注意，如果厂商SDK对bootanimation做过深度定制，mmm路径可能不在AOSP默认位置。我之前在一个RK3588的行业定制SDK上遇到过，他们的bootanimation源码被挪到了vendor/rockchip/common/bootanimation，而且加了一堆自有接口。遇到这种情况，老老实实先用搜索把源码路径找到，再来做修改，别在错误的地方改了又改，浪费时间。

4.2 自定义解析器的关键实现

如果你想实现动态文字叠加，或者想在动画播放中加入某个特殊事件检测，就必须深入bootanimation的C++代码。这里我给一个最简单的改造示例，用于在播放ZIP动画的每一帧上叠加一行居中的文字。

在bootanimation/BootAnimation.cpp的movie()函数里，你会看到类似这样的代码：

status_t BootAnimation::movie() { // 读取desc并解码当前帧 // 当前帧解码结果在Texture和表面的绘制调用中 }

大致逻辑是每帧拿到一个SkBitmap或类似的图像对象，然后通过OpenGL纹理绘制到屏幕上。为了叠加文字，可以在纹理绘制之前，先把文字画到同一个Bitmap上。关键代码大概长这样：

// 假设当前帧已经解码为SkBitmap frameBitmap SkCanvas canvas(frameBitmap); SkPaint paint; paint.setColor(SK_ColorWHITE); paint.setTextSize(48); paint.setAntiAlias(true); canvas.drawText("正在启动系统...", x, y, paint);

然后把改过的Bitmap上传为纹理，继续走原有的绘制流程。这里有两个地方要特别注意：

第一，每帧都重新绘制文字和抗锯齿计算，CPU开销不小。优化方式是先把文字预先绘制到一个独立的透明图层Bitmap上，每帧拷贝时直接blend上去，这样省去重复的字体渲染开销。RK3588的CPU性能好，但开机动画阶段内核、系统服务都在抢资源，能省一点是一点。

第二，文字内容可能来自属性值。比如状态信息存在sys.boot_progress之类的系统属性里，那么每帧过去都要读取一次属性并判断是否需要更新。属性读取虽然不重，但高频读取会产生 binder 调用开销，建议最多每5帧刷新一次文字内容，而不是每帧都读属性。

4.3 多屏异显动画的具体配置思路

RK3588平台的多屏能力是它被大量商显方案选中的原因之一。在做多屏开机动画时，你可以分成两个层次来处理。

如果只是需要“多个屏幕显示同样内容”，最简单的方式是确认显示驱动里已经配置了HDMI+DSI或HDMI+DP的clone模式。在这种模式下，底层显示控制器会将同一图层复制到多个显示接口，你根本不用改bootanimation的代码，只要主屏上能播，副屏上自然有画面。

如果需要“不同屏幕显示不同内容”，那就得在bootanimation里为每个Display创建独立的渲染线程。大致流程是：

1. 遍历SurfaceFlinger中的Display集合，拿到每个Display的默认Surface；
2. 针对每个Surface创建一个绘制上下文，共享纹理资源但各自独立提交；
3. 驱动不同的播放策略，比如主屏播part0，副屏播part1；
4. 在退出动画时，统一停掉所有渲染线程。

这套方案我实际在RK3588上落地过，最大的问题在主副屏帧率不同步。如果主屏是60Hz、副屏是30Hz，两边的vsync信号不一样，一个线程的播放节奏会对另一个造成干扰。我的解决思路是把两个显示器的vsync事件统一到一个时间基准上，以主屏的vsync为基准，副屏根据其刷新率做等比例抽样。比如主屏每2帧，副屏正好1帧，那么在第二个vsync上触发副屏的帧提交。这样节奏能基本对齐，观感上不会出现明显的错位。

5. 帧率优化实战：把30帧的动画做到纹丝不动

开机动画是用户在设备启动时看到的第一眼，卡顿最容易被感知。而且开机阶段系统负载特殊，CPU、IO、图形栈都在抢资源，帧率波动往往比正常桌面环境下明显得多。这一节把帧率问题的来源、排查手段和优化手段一次性说清楚。

5.1 卡顿是怎么来的：瓶颈拆解

一个开机动画帧要最终显示到屏幕上，要经过“读取素材—解码—上传纹理—合成—显示”这条链路。任何一环慢了，表现在用户眼里就是掉帧。

我先说存储IO。ZIP动画在播放时，每一帧图片都要被读取出来。如果图片没有做压缩，而且设备用的是eMMC或者低速SD卡，大量随机小块读取会让IO成为明显瓶颈。我在测试时见过一种典型情况：动画包里有上千张1080p的PNG，每张平均500KB，读取压力非常大，帧率直接掉到15fps以下。

然后是解码。ZIP里的PNG图片通常是CPU软解，RGBA8888的PNG解码还涉及内存分配和像素格式转换，CPU占用率不低。MP4格式走上硬件解码器后，CPU压力大幅下降，但要小心解码器输出的Buffer和显示合成之间的格式转换。RK3588的VideoDecoder输出一般是NV12或NV21的YUV格式，而开机动画的绘制管线通常处理RGBA，需要做一次格式转换，这同样有开销。

最后是合成与提交。bootanimation最终要通过SurfaceFlinger把画面合成到屏幕上。如果一帧的绘制时间已经接近16ms，再加上合成和vsync等待，30fps的播放节奏很容易出现周期性掉帧。

5.2 可落地的七步优化方案

我这里直接给出一套经过验证的优化路径，按优先级排序，每一步都有明确收益。

第一步：素材格式统一转JPG或WebP。如果不是必须透明通道，绝对不要用PNG。把图片从RGBA8888转成JPG（质量85~90），单帧体积能缩减到原来的五分之一甚至十分之一。WebP在同等质量下体积更小，但部分Android版本的bootanimation不支持WebP解码，需要你确认SDK里的图片解码库是否包含对应格式。

第二步：图片尺寸降到实际显示分辨率。很多人做素材时喜欢用2倍图甚至更高精度，但开机动画不是UI切图，不存在“为了视网膜屏做@2x”的需求。画面显示多大，素材就做多大。4K屏就用3840x2160，1080p屏就用1920x1080，多一像素都是浪费。

第三步：优先选择MP4格式。在RK3588上，只要你的动画内容不是需要动态文字叠加的复杂场景，MP4格式几乎总是比ZIP格式更优。硬件解码让CPU占用大幅降低，帧率稳定性好。这里的关键是别用CBR固定码率，用VBR或CRF配合合理的最大码率，可以减少画面复杂段的马赛克感。

第四步：控制part数量与循环策略。在ZIP场景里，如果动画包含多个part，每次part切换时文件读取路径都要变更，可能带来一次IO抖动。建议把需要顺序播放的内容合并到同一个part里，循环段单独一个part，最多不要超过3个part。

第五步：预读与缓存关键帧。如果素材体积和内存容量允许，可以在动画启动时把part0的所有帧一次性读入内存，后续播放时直接内存读取，彻底绕开IO瓶颈。1080p的JPG一帧按150KB算，30帧总共不到5MB，这个开销完全可接受。4K场景下，我会只缓存前一半的帧，后半段边播边读，平衡内存和IO。

第六步：纹理上传复用。在源码层面，不要每帧都重新创建纹理，而是预分配一个固定大小的纹理对象，每帧只是更新纹理内容。Android的glTexSubImage2D更新局部区域比glTexImage2D重新创建高效得多，这一点在bootanimation的OpenGL实现里可以直接优化。

第七步：与SurfaceFlinger合成策略配合。尽量让动画图层使用RGBA_8888以外的简单格式，减少合成的混合运算。如果素材没有透明通道，本质上可以用不透明图层，这样合成器不需要做alpha blend，省掉一部分GPU开销。在RK3588上，这一项优化有时能直接提升5%到10%的合成效率。

5.3 帧率与掉帧的量化评估方法

优化有没有效果，不能靠“肉眼看着还行”来下结论。我开发了一套简易的评估方法，分享给大家。

首先是在动画播放过程中通过logcat获取关键帧信息。bootanimation原生代码里，每播放一帧可能看不到直接日志，但你可以临时在源码的关键路径上加上调试输出：

static int frameCount = 0; static int64_t lastTime = systemTime(CLOCK_MONOTONIC); frameCount++; int64_t now = systemTime(CLOCK_MONOTONIC); if (frameCount % 30 == 0) { double fps = 30.0 * 1000000000.0 / (now - lastTime); ALOGD("bootanim fps=%f", fps); lastTime = now; }

这段代码会在每30帧统计一次实时帧率，通过logcat抓取输出后，就能直观看到帧率波动。更专业的做法是开启SurfaceFlinger的dumpsys SurfaceFlinger统计，对比动画播放阶段的合成帧数，但那个数据在开机过程中不一定方便抓取，所以源码埋点是最直接的。

另外我还会用高速录像的方式做主观校验：用手机或专业相机对着屏幕录制开机动画，然后逐帧播放录像，统计实际显示的帧间隔。这个方法虽然土，但最能反映真实观感，尤其是排查“理论帧率正常但肉眼看卡顿”的诡异问题时非常有效。

5.4 帧率与系统启动的整体节奏配合

优化帧率不是孤立的目标，还得考虑开机动画与系统启动的整体节奏。一个常见的错误是：为了让动画看起来高大上，做了60秒的循环动画，结果系统启动只需要15秒，用户盯着动画干瞪眼45秒，体验极差。

我的建议是把动画设计成三段式时间轴：第一段是品牌露出（2~3秒），第二段是功能预告或产品信息展示（5~8秒），第三段是无限循环的等待动画。第三段的视觉重心要放在“加载中”之类的状态暗示上，比如轻轻跳动的进度点、缓慢旋转的光环，避免用户产生等待焦虑。

同时，在系统源码层面可以监控系统启动的关键节点，比如sys.boot_completed属性被设为1时，主动缩短动画循环的剩余时间，提前发送退出指令。这样动画不会“硬生生被掐断”，而是能在一个相对自然的循环边界退出，观感上会舒服很多。

6. 常见问题排查实录

定制和优化过程中，我整理了十几个高频问题的定位思路，挑几个最有代表性的写在下面。

6.1 定制后动画完全不显示

排查顺序基本是：先确认动画包路径和文件名是否正确，是不是被放在了/system/media/bootanimation.zip；再确认ZIP包内desc.txt是否符合格式，路径是否小写；然后确认是否走了android()默认分支，这个可以通过logcat里搜bootanimation的日志关键字来判断。

最常见的原因是ZIP打包时把根目录套了一层。用解压软件打开，如果看到的不是desc.txt在最外层，而是有一个跟目录同名的文件夹，那就说明打包结构错了。正确做法是选中desc.txt和part目录，直接压缩，不要包外层文件夹。

cd your_animation_dir zip -0 ../bootanimation.zip -r desc.txt part0 part1

注意用-0表示不压缩，因为图片本身已经压缩过，二次压缩不仅没收益，还会增加解压时的CPU负担。ZIP内的图片建议保持stored模式，解码速度更快。

6.2 动画卡在最后一帧或退出慢

这个现象通常是退出指令和动画循环之间的配合出了问题。系统启动完成通知到达bootanimation进程时，动画可能在某个part的中间，需要播完当前part才能检查退出标志。如果当前part是一个超长的循环段，且源码只在part边界检查退出，那么用户就会看到动画迟迟不退。

解决办法是在源码的帧循环里增加高频退出检查，不要只在part切换时检查。定位到movie()里的主循环，把退出标志的读取放到每一帧的判断逻辑里：

if (exitRequested && currentFrameIndex == someSafePoint) { break; }

这样既不会在播放过程中突然切断动画，又能保证退出动作足够快。

6.3 副屏不显示动画或两边不同步

多屏场景的问题，先检查clone模式是否已经生效。在机器上执行：

dumpsys SurfaceFlinger | grep -A 5 "Display"

查看所有Display的state是否都是ON。如果有一个Display处于DOZE或OFF状态，那动画自然不显示。确认Display都正常后，再去排查前文提到的vsync对齐问题。副屏帧率低、主屏帧率高时，副屏必须做帧抽样，否则会出现副屏比主屏“快”的糟糕体验。

6.4 定制MP4动画后系统启动变慢

很多人以为MP4走硬解会更快，实际上如果其他环节没配合好，启动反而会变慢。比如MediaExtractor去解析MP4容器时需要读取文件元数据，如果文件放在一个还没mount好的分区上，就要做等待，浪费时间。另一个可能是在解码器就绪前反复重试，等待超时时间设得太长。

我建议MP4文件优先放在system分区已经挂载好的路径，或者将等待解码器超时控制在2秒以内。另外检查一下你的MP4是不是有非常长的moov偏移，如果faststart没打开，MediaExtractor可能要扫描整个文件来定位采样表，几百MB的文件扫描一次是非常耗时的。

6.5 OTA升级后动画被还原

这个问题主要集中在不熟悉产品维护流程的工程师身上。很多方案的升级脚本会重新刷写system分区，而你定制好的bootanimation如果直接放在system下，就会被还原掉。解决思路是把动画包放到/data/local/或其他持久化分区，然后修改bootanim.rc或bootanimation源码去优先读取那里。

但要注意权限控制，保证普通用户不能篡改动画文件，否则会带来品牌形象被恶意替换的风险。做法是设定一个系统层级的只读属性标记，动画文件校验通过才允许播放，否则回退到默认动画。

7. 个人经验与收尾技巧

开机动画这个需求的坑不在技术难度，而在项目协作中它往往被当成“小活儿”，一直到量产前才被重视，留给开发者的时间窗口非常紧。所以我的经验是：项目一开始就明确动画格式、分辨率规范、多屏策略，并提前完成一版可用的动画通道，哪怕素材后续再换，也不要让整个渲染链路在最后两周才第一次跑通。

另外一个小技巧：做帧率优化时，不要只盯着bootanimation这一个进程的CPU占用，还要同时观察SurfaceFlinger和surfaceflinger进程的CPU、GPU占用情况。很多时候动画掉帧并不是动画进程本身慢了，而是SurfaceFlinger的合成负载过高，或者GPU频率没有及时拉起来。在RK3588上，你可以通过设置sys.powerhal.video之类的属性来影响调频策略，让GPU在开机动画阶段就保持一个相对高的频率，而不是等负载上来再拉升。具体属性名不同SDK略有差异，以实际平台文档为准。

开机动画的技术栈并不复杂，但涉及的知识面非常杂：图片编码、视频编码、Linux进程、Android图形栈、显示驱动、系统属性，都得懂一点。这也是为什么网上教程很多，但能在一台实际设备上把效果做得干净稳定的并不多。希望这篇东西能让你少走一些弯路，把更多精力花在真正影响产品体验的细节上。