Avid Media Composer导出帧率必须匹配项目设置，无法在导出界面修改；新建项目时须选择1080p60等对应格式，素材需手动Conform至项目帧率，否则将导致丢帧、不同步或导出失败。
输出帧率设为 60 并不等于动画就一定流畅——关键在于整个制作链路是否真正支持 60fps 渲染与导出，尤其当涉及预合成、关键帧密度、硬件加速或目标平台限制时，硬填 60 反而会引发丢帧、卡顿或导出失败。
Media Composer 导出时帧率必须匹配项目设置
Media Composer 不允许在导出界面单独修改帧率；它强制继承项目设置中的帧率值。如果你在导出菜单里看到帧率灰显或无法调整，说明你没在项目创建阶段选对基础帧率。
- 新建项目时必须明确选择
1080p60或4K60等带 60 的格式，不能选1080p25后再指望导出改回 60 - 已存在的项目若帧率不对，无法直接修改——只能新建 60fps 项目，再把序列拖入（注意时间码偏移）
- 导入的素材若本身是 30fps 或 24fps，Media Composer 默认做帧重复或插帧处理，但不会自动升频到 60；需手动右键素材 →
Modify → Set Source Settings中启用Conform to Project Frame Rate
Pixel Composer 导出 GIF 时帧率 ≠ 播放速度直觉值
GIF 的“流畅”不取决于数值大，而取决于人眼对单帧停留时间的感知。填 60 在 GIF 场景下反而会导致浏览器强制限速或首帧卡顿，因为多数浏览器对 GIF 帧间隔有最小阈值（通常 ≥ 10ms ≈ 100fps 上限，但实际支持常止步于 20–30fps）。
-
framerate填24～30是安全区间，对应每帧显示约 33–42ms，兼容性好且视觉连贯 - 填
60会生成每帧 ≈ 16.7ms 的 GIF，但 Chrome/Firefox 实际会 clamp 到 20ms（即强制降为 50fps），Safari 更可能四舍五入到 33ms（≈30fps） - 软件内黄色的
preview frame rate仅影响编辑器播放，和导出无关；绿色的animation length是总帧数，也不参与导出速率计算
Compose-Multiplatform 中 AnimatedVisibility 的帧率陷阱
即使 UI 层面设了 60fps 动画，AnimatedVisibility 这类声明式动画组件在频繁开关时极易因状态重建或 recompose 触发过载，导致真实渲染帧率跌破 30fps。
- 避免在循环中高频调用
AnimatedVisibility(visible = isLoading) { ... }，尤其当isLoading来自 mutableStateOf 频繁 emit - 务必用
rememberSaveable缓存可见性状态：var visible by rememberSaveable { mutableStateOf(true) }，否则配置变更（如旋转）会重置动画并打断帧连续性 - 搭配
animateFloatAsState自定义过渡时，检查tween(durationMillis = 300)是否被误设为10——过短持续时间会让 Compose 强制压缩帧间隔，触发丢帧
Android hwcomposer 场景下“设成 60”只是起点
系统层宣称支持 60fps，不代表你的 Compose 页面真能跑满。hwcomposer 合成前的 App 渲染阶段一旦掉帧，合成器只能拿旧帧凑数。
- 用
adb shell dumpsys gfxinfo <package></package>查看Draw/Process/Execute三段耗时，任一段 >16ms 就意味着单帧超时 - 禁用非必要
Modifier.shadow和半透明叠加，这些会触发离屏渲染，大幅增加 GPU 负担 - 列表页慎用
LazyColumn嵌套多层Box+graphicsLayer，每层都可能引入额外合成层，hwcomposer 处理层数越多，越容易 fallback 到 CPU 合成
真正决定流畅度的，从来不是导出界面上那个数字，而是从关键帧采样密度、预合成结构、状态更新节流，到硬件合成通路是否畅通的全链路对齐。填错一个 60 很容易，但让这 60 帧每一帧都准时抵达屏幕，需要逐层验证。特别是 GIF 场景和 Compose 声明式动画，数值越大越容易暴露底层约束。
