直播礼物特效资源减法：体积砍一半，肉眼看不出差

有一个更根本的问题：如果资源本身就很重，再好的运行时优化也是被动救火。

一个全屏动效从几百 KB 做到几 MB，绝大多数情况不是因为“这个效果一定需要那么多数据”，而是导出时没有认真做减法。本篇系统拆解资源侧能做哪些减法——从图像压缩、粒子精简、分辨率策略，到时长裁剪和自动化 工具链，目标是：同一个礼物，视觉几乎无差，体积和解码成本砍到原来的一半。

一、先摸清底数：你的资源由什么组成

不同格式的资源构成差异很大，减法的方向也不同：

动手之前，先把资源解开看看里面究竟是什么。SVGA 本质是 zip，直接改扩展名解压；VAP 是 MP4 容器，用 ffprobe 看码流信息；PAG 用官方 PAGViewer 查各图层类型。

# 查看 VAP 文件的码率和分辨率
ffprobe -v error -select_streams v:0 \
  -show_entries stream=width,height,bit_rate,codec_name \
  -of default=noprint_wrappers=1 gift.mp4
 
# 解开 SVGA 看内部位图
cp gift.svga gift.zip && unzip gift.zip -d gift_contents/
ls -lh gift_contents/images/  # 看各帧位图体积

摸清构成之后，才知道主要矛盾在哪——是位图太多、码率太高，还是分辨率开得过大。

二、图像压缩：PNG 换 WebP，体积直降 40–60%

礼物特效示例：球场跑车

SVGA 和 PAG 内嵌的位图通常是 PNG。PNG 无损但体积大，换成 WebP 质量几乎感知不到差异，体积普遍能降 40%–60%。

批量转换脚本：

import os
from PIL import Image
 
def png_to_webp(src_dir, quality=85):
    """
    把目录下所有 PNG 转成 WebP。
    quality=85 是经验值：肉眼无差，体积约为原来的 40%。
    对粒子/光效等高透明度图层可适当降到 80；
    对主角色细节丰富的图层可提高到 90。
    """
    for fname in os.listdir(src_dir):
        if not fname.lower().endswith('.png'):
            continue
        src_path = os.path.join(src_dir, fname)
        dst_path = src_path.replace('.png', '.webp')
        img = Image.open(src_path).convert('RGBA')
        img.save(dst_path, 'WEBP', quality=quality, method=6)
        src_size = os.path.getsize(src_path)
        dst_size = os.path.getsize(dst_path)
        ratio = dst_size / src_size * 100
        print(f"{fname}: {src_size//1024}KB → {dst_size//1024}KB ({ratio:.0f}%)")
 
png_to_webp('./gift_contents/images/')

两个注意点：一是 SVGA 播放器端要确认支持 WebP 内嵌图（主流 SVGA 库都支持，老版本需升级）；二是对主角色细节层用 quality=85~90，对背景光 晕/粒子层可以降到 75–80，分层控制效果比统一一刀切更好。

三、视频类格式降码率：VAP 用 H.265，码率砍 30–50%

VAP 的体积主要是视频码率。H.264 换 H.265（HEVC）在同等视觉质量下码率能降 30%–50%，而现代移动端几乎全面支持 H.265 硬解。

# 用 ffmpeg 把 H.264 VAP 重新编码为 H.265，同时保留 alpha 通道
# -crf 28 对应较高压缩率，视觉质量尚可；礼物类内容通常 26-30 之间取值
# -preset slow 换取更高压缩效率（离线处理不怕慢）
ffmpeg -i input_vap.mp4 \
  -c:v libx265 -crf 28 -preset slow \
  -tag:v hvc1 \
  -movflags +faststart \
  output_vap_h265.mp4

降码率的补充策略： - 降帧率：礼物入场动效通常是一次性播放，30fps 足够，没必要 60fps；循环动效才需要考虑 60fps。 - 缩分辨率：后面单独讲。 - 两遍编码（2-pass）：对码率要求精准控制时用 -pass 1/-pass 2，比 CRF 更稳定。

四、分辨率降采样：按设备而不是按设计稿

礼物特效示例：粉樱跑车

设计稿通常是 1080p 甚至 2K 出图，但：

礼物特效在屏幕上实际占多大？全屏礼物在 720p 屏幕上就是 720p，用 1080p 资源完全浪费。

低端机屏幕分辨率本来就低（720p 居多），给它塞 1080p 资源，解码多花一倍内存，显示还会被缩小。

按档位输出三套分辨率：

import subprocess
 
def export_by_tier(src_mp4, output_dir):
    """
    HIGH  → 1080p（旗舰机）
    MID   → 720p（中端机）
    LOW   → 540p（低端机，配合上一篇的 DeviceTier 检测）
    """
    tiers = {
        'high': ('1920x1080', '28'),
        'mid':  ('1280x720',  '30'),
        'low':  ('960x540',   '32'),
    }
    for tier, (scale, crf) in tiers.items():
        out = f"{output_dir}/gift_{tier}.mp4"
        subprocess.run([
            'ffmpeg', '-i', src_mp4,
            '-vf', f'scale={scale}',
            '-c:v', 'libx265', '-crf', crf, '-preset', 'slow',
            '-tag:v', 'hvc1', '-movflags', '+faststart',
            out
        ], check=True)
        size_kb = os.path.getsize(out) // 1024
        print(f"{tier}: {out} ({size_kb}KB)")

客户端根据上一篇的 detectTier() 结果选对应分辨率的资源 URL，简单直接。

五、粒子减法：减哪些、怎么判断

粒子效果是最容易“越加越多”的地方——设计师加一批星星、再叠一层光点、再给个拖尾……每一层单独看都好看，叠在一起体积暴涨，低端机 GPU 也扛不住。

减粒子的判断框架：

遮挡测试：把某一粒子层单独关掉，整体视觉有没有明显变化？如果几乎看不出来，这层可以删。

密度减半测试：粒子数量减半（每隔一帧删一个），光效感是否还在？大多数情况下保留 60% 的粒子数已经和 100% 几乎无差。

尺寸优先于数量：少量大粒子的视觉冲击力往往强于大量小粒子，同时 GPU 绘制 call 更少。

在 After Effects 里，粒子层的 Particles/sec 参数直接控制密度，可以边预览边调；导出 PAG/SVGA 后再用上面的 ffprobe/解包方式验证体积变化。

六、时长精简：入场 + 循环分离

很多礼物动效把“入场动画”和“循环动画”打在一个文件里，总时长 6–8 秒。但实际使用时，入场只播一次，循环才是常态。如果把整段打成一个文件：

文件体积 = 入场体积 + 循环体积，两者都要下载和缓存；

循环部分如果只有 2 秒但被打包进 6 秒文件，每次循环都要重新加载整个文件。

正确做法：拆成两个文件，分别加载。

gift_enter.svga   ← 入场动画，播一次
gift_loop.svga    ← 循环动画，无缝循环

拆分逻辑：入场文件只包含从初始状态到“稳定态”的关键帧，循环文件是稳定态的无缝循环段，首尾帧必须相同（或足够接近）才能无缝衔接。

循环段通常只需要 1.5–3 秒，体积相应也只有原来的 20%–40%，大幅降低循环播放的内存驻留。

七、自动化工具链：让减法可重复

礼物特效示例：极光小镇

上面这些步骤如果每次手动做，效率极低。把它们串成一个脚本，变成可重复的流水线：

import os
import subprocess
from PIL import Image
 
def optimize_gift(src_dir, out_dir, tier='mid'):
    """
    一键优化礼物资源包：
    1. PNG → WebP（自动按图层类型选质量）
    2. MP4 降码率 + 按档位降分辨率
    3. 输出优化前后体积对比报告
    """
    os.makedirs(out_dir, exist_ok=True)
    original_total = 0
    optimized_total = 0
 
    scale_map = {'high': '1920x1080', 'mid': '1280x720', 'low': '960x540'}
    crf_map   = {'high': '26',        'mid': '28',       'low': '30'}
 
    for fname in os.listdir(src_dir):
        src_path = os.path.join(src_dir, fname)
        original_total += os.path.getsize(src_path)
 
        if fname.lower().endswith('.png'):
            dst_path = os.path.join(out_dir, fname.replace('.png', '.webp'))
            img = Image.open(src_path).convert('RGBA')
            # 背景/光效层用 quality=80，主角色层用 quality=88
            quality = 80 if 'bg' in fname.lower() or 'particle' in fname.lower() else 88
            img.save(dst_path, 'WEBP', quality=quality, method=6)
 
        elif fname.lower().endswith('.mp4'):
            dst_path = os.path.join(out_dir, fname)
            scale = scale_map.get(tier, '1280x720')
            crf   = crf_map.get(tier, '28')
            subprocess.run([
                'ffmpeg', '-i', src_path,
                '-vf', f'scale={scale}',
                '-c:v', 'libx265', '-crf', crf, '-preset', 'slow',
                '-tag:v', 'hvc1', '-movflags', '+faststart',
                '-y', dst_path
            ], check=True, capture_output=True)
 
        else:
            # 其他文件原样复制
            import shutil
            dst_path = os.path.join(out_dir, fname)
            shutil.copy2(src_path, dst_path)
 
        optimized_total += os.path.getsize(dst_path)
 
    ratio = optimized_total / original_total * 100
    print(f"\n优化结果: {original_total//1024}KB → {optimized_total//1024}KB ({ratio:.0f}%)")
    print(f"体积节省: {(original_total-optimized_total)//1024}KB")

接入 CI 流程后，每次设计师提交新资源，自动跑这个脚本输出优化版本和对比报告，不再依赖人工记得做减法。

八、效果验证：眼睛看 + 数据量

减法做完之后，验证分两步：

视觉验证： 在同一台设备上并排对比原版和优化版，在正常观看距离和正常播放速度下，肉眼几乎感知不到差异才算通过。不要用静帧对比——动态播放时人眼对细节的感知阈值比静帧宽松很多。

数据验证： 把上一篇的 FrameMonitor 和内存监控跑一遍，确认： - 掉帧率没有因为格式转换引入新问题（比如 WebP 解码在极老设备上反而更慢）； - 峰值内存按预期下降； - 解码耗时没有异常增加（H.265 在极老机型上硬解支持有限，需要兜底检测）。

特别注意 H.265 的兼容性：Android 5.0 以上理论支持，但极老的 SoC 可能没有 H.265 硬解单元，这时会回落到软解，比 H.264 还慢。可以在 createDecoder() 里检测解码器是否为硬件实现，如果只找到软解器就切回 H.264 资源。

总结

资源减法的六个操作按效果排序：

1. PNG → WebP：改动最小，体积直降 40–60%，优先做；

2. 分辨率按档位：配合运行时降级，一次输出三套；

3. H.264 → H.265：VAP 类视频格式码率降 30–50%；

4. 粒子密度减半：视觉几乎无差，GPU 负载显著下降；

5. 入场/循环拆分：循环段体积只需原来 20–40%；

6. 自动化工具链：让减法变成流程，而不是偶尔想起来才做。

运行时优化解决“特效在设备上跑得好不好”，资源减法解决“特效进设备之前就不重”。两者结合，才是完整的低端机优化闭环。