HarmonyOS 3DGS 滤镜切换实战：效果创建、参数管理与资源释放

HarmonyOS 3DGS 滤镜切换实战：效果创建、参数管理与资源释放

实际项目里，滤镜实例最容易出现的问题不是"接口不会调用"，而是状态分散、异步结果乱序、失败后没有回退。切换滤镜时画面稳定且旧效果被释放，需要把能力边界、生命周期、数据责任和验收证据放进同一条工程链路，而不是把所有逻辑堆在页面点击事件里。

本文围绕一个可落地目标展开：切换滤镜时画面稳定且旧效果被释放。示例强调职责分层和可验证结果，并明确区分官方能力与工程封装；最终结论以目标 SDK 的编译记录和真机测试数据为准。

1. 这篇文章解决什么

• Spatial Recon Kit 提供复古、漫画、黑白 bit 与颜色编辑等 3DGS 风格化效果
• 调用效果前仍需加载 GSPlugin.PLUGIN_ID
• 效果参数与效果实例应分开保存，便于撤销和复用
• 滤镜不可用时应回退原始渲染而不是阻塞整个场景

完成接入后，读者应能回答四个问题：能力是否适用于当前版本和设备；一次请求由谁拥有；失败后从哪里重试；怎样证明结果确实可用。这四个问题比单独展示一段 API 调用更接近真实交付。

文章不会把宣传页上的能力名称直接翻译成代码，而是先确认官方资料能证明什么，再把项目必须自行实现的控制器、状态和存储责任单独列出。这样既能迁移工程方法，也能避免把示例封装误认成系统原生接口。

2. 先确认能力边界

检查项	接入前要确认	不满足时的处理
SDK 与系统版本	项目编译版本、运行设备版本和 API 起始版本一致	隐藏入口或走旧版本方案
设备与区域	官方支持范围覆盖目标用户	给出明确不可用提示
生命周期	请求归属页面、Ability 或长期服务	退出后取消或忽略旧结果
数据责任	输入来源、保存位置和清理策略明确	不启动不可回收任务
验收方式	有可重复步骤和失败样例	不把界面出现当完成

边界检查应该发生在业务动作之前。若能力不可用，持续重试只会制造更多日志和资源消耗，正确行为是降级到已有路径并说明限制。

还要区分"效果能力"和"参数枚举"的起始版本。官方 spatialRender 参考中，四类 3DGS 效果从 API 21 开始提供；RetroEffectParams 等参数枚举从 API 23 开始提供。Spatial Recon 当前面向中国大陆，支持 Phone、Tablet、PC/2in1 和 TV，不支持模拟器。因此，开发阶段至少要准备一台满足系统版本的真机，不能把预览器画面当作滤镜验收结论。

效果	effectId	典型参数	官方约束示例
复古像素	RETRO_EFFECT_ID	COLOR_NUM、PIXEL_SIZE、BLEND_ENABLED、CURVE	颜色数大于 0；像素尺寸不小于 1；曲线范围 [0, 1]
漫画线稿	COMIC_EFFECT_ID	LINE_THRESHOLD、线条颜色	阈值范围 [0, 1]，默认值 0.2
黑白点阵	OBRA_DINN_EFFECT_ID	NOISE_STRENGTH、THRESHOLD、前景色、背景色	噪声强度与阈值范围均为 [0, 1]
颜色编辑	COLOR_EDITING_EFFECT_ID	曝光、对比度、色温、色调、饱和度、自然饱和度	曝光推荐范围 [-5, 5]

这些范围不是 UI 滑杆的装饰信息，而是业务校验的来源。页面层可以把连续值映射成滑杆，Service 层仍要再次钳制参数，避免恢复旧配置或跨端同步时把越界值直接传给渲染层。

3. 把流程画成可检查的状态机

本文采用的五个关键检查点是：默认无滤镜首帧 → 四类效果逐一切换 → 连续快速切换十次 → 非法参数回退 → 页面退出后无异步写入。每一步都要有明确输入与输出，后一步只能消费前一步已经确认的结果。网络响应、回调触发或命令退出码只能证明某一步发生过，不能自动代表最终业务成功。

空间能力通常不支持用一个布尔值描述全过程。初始化、可交互、局部降级和致命失败要分开，否则页面会把可恢复问题误判为整页不可用。

export type WorkflowStage =
  | 'idle'
  | 'checking'
  | 'running'
  | 'degraded'
  | 'succeeded'
  | 'failed'

export interface GSFilterControllerState {
  requestId: string
  stage: WorkflowStage
  message: string
  retryable: boolean
  updatedAt: number
}

状态对象只保存页面真正需要的结果，不保存 Context、组件实例或底层句柄。这样页面重建后仍能读取稳定状态，也降低了生命周期泄漏风险。

4. 用分层结构隔离平台能力

推荐把职责拆成四层：ArkUI 页面：呈现进度与错误；空间控制器：管理场景和任务生命周期；Spatial Recon / ArkGraphics 3D：执行空间能力；资源层：模型、清单与缓存。页面只负责用户输入和展示，控制器负责顺序、去重与状态，平台适配器只包装官方接口，数据层负责持久化和缓存。

export interface PlatformAction<Input, Output> {
  check(input: Input): Promise<void>
  execute(input: Input): Promise<Output>
  release(): Promise<void>
}

export class GSFilterController<Input, Output> {
  private generation: number = 0
  private state: GSFilterControllerState = {
    requestId: '', stage: 'idle', message: '', retryable: false, updatedAt: Date.now()
  }

  constructor(private readonly action: PlatformAction<Input, Output>) {}

  async run(requestId: string, input: Input): Promise<Output | null> {
    const current: number = ++this.generation
    this.update(requestId, 'checking', '正在检查运行条件', false)
    try {
      await this.action.check(input)
      this.update(requestId, 'running', '任务执行中', false)
      const output: Output = await this.action.execute(input)
      if (current !== this.generation) return null
      this.update(requestId, 'succeeded', '任务已完成', false)
      return output
    } catch (error) {
      if (current === this.generation) {
        this.update(requestId, 'failed', this.toMessage(error), true)
      }
      return null
    }
  }

  private update(requestId: string, stage: WorkflowStage, message: string, retryable: boolean): void {
    this.state = { requestId, stage, message, retryable, updatedAt: Date.now() }
  }

  private toMessage(error: Object): string {
    return error instanceof Error ? error.message : '未知错误'
  }
}

generation 用来阻止旧任务覆盖新任务。它不是取消底层操作的替代品，但能保证页面只接受当前世代的结果。若平台接口支持取消，还应在适配器的 release() 中执行真正的资源回收。

5. 按官方调用顺序创建并配置效果

滤镜接入不能只调用 createEffect()。官方顺序是先通过场景资源工厂加载 GSPlugin.PLUGIN_ID，再用对应 effectId 创建效果，设置属性后把效果追加到相机的 effects 列表。下面以复古效果为例，省略场景文件加载和异常映射代码：

import { Scene, Camera, Effect } from '@kit.ArkGraphics3D'
import { spatialRender } from '@kit.SpatialReconKit'

export async function attachRetroEffect(
  scene: Scene,
  camera: Camera
): Promise<Effect> {
  const resourceFactory = scene.getResourceFactory()
  await resourceFactory.loadPlugin({
    pluginId: spatialRender.GSPlugin.PLUGIN_ID
  })

  const effect = await resourceFactory.createEffect({
    effectId: spatialRender.GSPlugin.RETRO_EFFECT_ID
  })
  effect.setPropertyValue(spatialRender.RetroEffectParams.COLOR_NUM, 8)
  effect.setPropertyValue(spatialRender.RetroEffectParams.PIXEL_SIZE, 4)
  effect.setPropertyValue(spatialRender.RetroEffectParams.BLEND_ENABLED, true)
  effect.setPropertyValue(spatialRender.RetroEffectParams.CURVE, 0.25)

  camera.effects.append(effect)
  return effect
}

这里把 Effect 返回给上层，是为了让控制器明确持有当前效果，而不是每次切换都盲目追加。项目应根据所用 SDK 的实际类型签名调整 import 与资源工厂调用；示例表达的是官方要求的先后关系和参数名，不代表已经完成真机编译。

切换时先创建新效果，配置成功后再替换相机效果列表，最后释放旧引用。若新效果创建失败，保留旧效果或恢复无滤镜渲染，避免画面进入"旧效果已移除、新效果未就绪"的空档。

export class ActiveEffectSlot {
  private current?: Effect

  replace(camera: Camera, next: Effect): void {
    const previous = this.current
    camera.effects.clear()
    camera.effects.append(next)
    this.current = next
    previous?.destroy()
  }

  clear(camera: Camera): void {
    const previous = this.current
    camera.effects.clear()
    this.current = undefined
    previous?.destroy()
  }
}

destroy() 是否适用于项目当前 SDK 对象，应以实际 API 声明为准；如果效果对象由场景统一管理，就改为调用对应资源释放接口。关键不是某个固定方法名，而是把"当前效果归谁持有、何时从相机解绑、何时释放底层资源"写成同一条生命周期契约。

参数校验同样要靠近业务边界。例如复古效果可在 Service 层执行 COLOR_NUM > 0、PIXEL_SIZE >= 1、CURVE 位于 [0, 1] 的校验。这样即使参数来自历史缓存、跨设备同步或外部配置，也不会绕过页面滑杆的限制。

6. 生命周期与重复操作

页面退出、窗口切换或场景销毁后，旧异步结果不能继续写入已经失效的节点。使用任务世代号或显式 dispose 标记，是比单纯 try/catch 更重要的保护。

更稳的做法是让控制器拥有一次操作的完整生命周期：开始前去重，运行中禁止重复副作用，结束后释放资源，页面退出时使当前世代失效。需要持久化的状态交给 Service 或 Repository，不要寄希望于页面对象一直存在。

export class RequestGuard {
  private readonly running: Set<string> = new Set()

  begin(requestId: string): boolean {
    if (this.running.has(requestId)) return false
    this.running.add(requestId)
    return true
  }

  finish(requestId: string): void {
    this.running.delete(requestId)
  }
}

在 finally 中调用 finish()，可以保证成功和失败都释放占用。对于下单、删除、授权等有副作用的动作，还需要服务端或数据层幂等键，不能只依赖内存集合。

6.1 用不可变配置描述一次滤镜选择

不要把 UI 上的四个滑杆值直接散落到效果对象中。更容易维护的方式，是先形成一个不可变配置快照，再由适配器完成"配置 → 官方属性"的映射。撤销、重做、保存预设和问题复现都可以复用同一份数据。

export type FilterKind = 'none' | 'retro' | 'comic' | 'obraDinn' | 'colorEditing'

export interface RetroFilterConfig {
  kind: 'retro'
  colorNum: number
  pixelSize: number
  blendEnabled: boolean
  curve: number
}

export interface ComicFilterConfig {
  kind: 'comic'
  lineThreshold: number
  lineColor: number[]
}

export type FilterConfig =
  | { kind: 'none' }
  | RetroFilterConfig
  | ComicFilterConfig

export function normalizeRetro(input: RetroFilterConfig): RetroFilterConfig {
  return {
    ...input,
    colorNum: Math.max(1, Math.round(input.colorNum)),
    pixelSize: Math.max(1, Math.round(input.pixelSize)),
    curve: Math.min(1, Math.max(0, input.curve))
  }
}

FilterConfig 使用可辨识联合类型后，ArkTS 编译器能根据 kind 收窄参数，避免漫画效果误读复古参数。生产代码还应补齐黑白点阵和颜色编辑配置，并将颜色数组长度、数值范围写入校验器。

6.2 切换必须满足"准备、提交、清理"三阶段

一次稳定切换可以拆成三个阶段：第一阶段创建并配置候选效果，但不触碰当前画面；第二阶段检查请求世代仍然有效，然后一次性提交到相机；第三阶段解绑并释放旧效果。任何错误发生在提交之前，当前画面都不应变化。

export class AtomicFilterSwitcher {
  private generation: number = 0
  private active?: Effect

  async switchTo(camera: Camera, createNext: () => Promise<Effect>): Promise<boolean> {
    const requestGeneration = ++this.generation
    let candidate: Effect | undefined
    try {
      candidate = await createNext()
      if (requestGeneration !== this.generation) {
        candidate.destroy()
        return false
      }

      const previous = this.active
      camera.effects.clear()
      camera.effects.append(candidate)
      this.active = candidate
      candidate = undefined
      previous?.destroy()
      return true
    } finally {
      candidate?.destroy()
    }
  }

  dispose(camera: Camera): void {
    ++this.generation
    camera.effects.clear()
    this.active?.destroy()
    this.active = undefined
  }
}

这段实现解决两个常见竞态：较慢的旧请求不会覆盖较新的选择；候选效果在创建后、提交前失效时也能释放。若当前 SDK 使用场景资源管理器统一销毁，应把 destroy() 替换成适配器的释放方法，状态机本身无需改变。

6.3 参数预设只保存业务数据

预设持久化应只保存 FilterConfig，不要序列化 Effect、Scene、Camera 或 Context。读取预设后先做 schemaVersion 迁移和范围校验，再创建新的效果实例。这样升级 SDK、切换设备或场景重建时，不会把已经失效的底层句柄带回来。

建议至少保存 schemaVersion、filterKind、标准化后的参数和 updatedAt。删除预设时只删除业务记录；当前正在使用的效果仍由 AtomicFilterSwitcher 的生命周期负责，避免数据层反向控制渲染对象。

7. 失败处理表

风险	复现方式	修复方向
重复创建效果导致资源堆积	连续切换四类效果并观察内存	替换前保存旧引用，绑定新效果后再释放旧对象
快速点击让旧请求覆盖新选择	100ms 间隔连续点击十次	使用 generation 丢弃过期回调，只提交最后一次选择
参数越界导致结果异常	传入 CURVE=1.2 或 PIXEL_SIZE=0	Service 层按官方范围拒绝或钳制，回退上一个有效值
页面退出后仍更新场景	创建过程中立即返回上一页	页面销毁时使任务世代失效，并清空相机效果列表

排查时先找第一个真实失败点：能力检查失败就不要继续看页面渲染；平台执行成功但页面没更新，再检查状态映射；页面显示成功而服务端或文件不存在，则回到最终结果回读。

8. 性能、隐私与日志

日志只记录 requestId、阶段、耗时、可公开错误码和脱敏资源标识。账号令牌、证书密码、完整个人数据、原始文件内容都不应进入日志。高频回调要聚合后更新 UI，避免每次回调都触发重绘。

性能优化要先建立基线。记录相同设备、相同版本、相同输入下的首帧、完成耗时、峰值内存或失败率，再修改并复测。不同条件下的两个数字不能直接作为结论。

对于需要联网、跨设备或访问本地敏感资源的能力，还要把权限说明、用户授权、数据保存期限和清理入口写进实现清单。能力关闭或权限被撤销后，控制器应立即停止新增任务，并让已有任务进入可解释的降级状态，而不是在后台反复请求。

滤镜性能测试应固定同一份 3DGS 资源、相机位姿、分辨率和运行时长。分别记录无滤镜、复古、漫画、黑白点阵、颜色编辑五组数据，关注首帧耗时、切换耗时 P50/P95、稳定帧率、峰值内存和十次切换后的内存回落。若只记录"看起来流畅"，无法判断优化是否有效，也无法发现旧效果未释放造成的缓慢增长。

推荐把一次切换日志压缩为一行结构化事件：requestId、fromKind、toKind、createMs、commitMs、releasedPrevious、resultCode。不要记录模型原始路径、账号信息或完整参数文件。发生问题时，先按 requestId 串起创建和释放事件，再查看同一时间窗口的 Profiler 数据。

9. 页面如何呈现状态

checking 阶段显示轻量提示；running 展示真实进度或不确定进度；degraded 保留已经可用的内容并提供局部重试；failed 给出可执行的下一步；succeeded 仍应允许用户核对最终结果。

@Component
export struct WorkflowStatusCard {
  @Prop state: GSFilterControllerState

  build() {
    Column({ space: 8 }) {
      Text(this.state.message).fontSize(16).maxLines(2)
      if (this.state.stage === 'running') {
        Progress({ value: 40, total: 100, type: ProgressType.Linear })
      }
      if (this.state.retryable) {
        Text('可重试').fontColor('#0A59F7')
      }
    }
    .width('100%')
    .padding(16)
  }
}

示例中的进度值不是业务真实值。若底层没有精确进度，就使用不确定进度样式，不要制造虚假的百分比。

10. 最小验收清单

1. 默认无滤镜首帧：记录输入、环境、预期与实际结果。
2. 四类效果逐一切换：记录输入、环境、预期与实际结果。
3. 连续快速切换十次：记录输入、环境、预期与实际结果。
4. 非法参数回退：记录输入、环境、预期与实际结果。
5. 页面退出后无异步写入：记录输入、环境、预期与实际结果。

此外还要验证快速重复点击、页面返回、横竖屏或窗口变化、应用切后台、权限被拒绝和资源被清理等路径。交付记录应逐项填写目标设备、环境版本、运行证据和结论，缺少证据的项目保持"待复测"状态。

验收结果不要只填"通过"。每条用例至少记录测试设备、系统/API 版本、3DGS 资源标识、操作次数、期望效果、实际效果、耗时和内存差值。连续十次切换后，若峰值内存持续单调增长且退出页面后不回落，应先检查相机 effects 列表与旧效果释放路径，而不是继续调低画质参数。

一个可执行的通过标准示例是：最后一次点击选择与最终画面一致；越界参数不会进入渲染层；创建失败时仍保留上一个有效画面；页面退出后不再提交异步结果；再次进入页面能够根据业务配置重新创建效果。具体耗时和内存阈值应根据目标设备基线制定，不能照搬示例数字。

11. 常见误区

把接口返回当成最终成功。 最终结果可能还要保存、回读或由另一个组件消费，应验证真正的业务产物。

把所有逻辑写进页面。 页面重建后状态丢失，资源释放和重复请求都会变得难以控制。

失败后无限重试。 版本、权限、配置和资源不存在不会通过重试恢复，应先分类错误。

只验证顺利路径。 真正暴露工程问题的往往是取消、重复、超时、退出和部分成功。

这些误区可以用代码评审清单提前拦截：页面是否直接持有平台句柄、是否存在无上限重试、是否缺少 requestId、是否把回调触发当成最终完成、是否记录了敏感原文。只要其中一项为"是"，就应在进入设备验收前先修正职责边界。

12. 从空项目接入到首个滤镜的操作顺序

如果项目第一次接入 Spatial Recon，可以按下面的顺序推进。顺序本身就是排障边界：当前一步没有稳定结果时，不要提前叠加下一层业务逻辑。

第一步：确认依赖与运行环境

先核对编译 SDK、设备系统版本、Kit 依赖和支持区域。3DGS 效果与参数枚举的起始 API 不完全相同，项目的最低兼容版本应根据真正使用的参数确定。模拟器不在该能力的验证范围内，应提前准备真机和一份已知可加载的 3DGS 资源。

第二步：只完成原始场景加载

先不添加任何滤镜，只加载资源、创建相机并显示稳定首帧。记录首帧耗时、场景节点数量和基线内存。如果这个阶段已经黑屏或资源加载失败，问题属于场景加载链路，与滤镜参数无关。

第三步：加载插件并创建单一效果

加载 GSPlugin.PLUGIN_ID 后，只创建一个使用默认参数的复古效果。先验证 createEffect() 返回、相机列表绑定和画面变化，再开放参数调节。这样能把"插件未加载""effectId 错误"和"参数越界"拆成不同问题。

第四步：加入参数模型与校验

把 UI 输入转换成 FilterConfig，在 Service 层标准化数值，然后才调用 setPropertyValue()。不要让页面保存底层 Effect，也不要让资源适配器读取页面组件状态。复古效果可先开放颜色数、像素尺寸和曲线三个参数，稳定后再扩展布尔混合开关。

第五步：实现原子切换

引入 AtomicFilterSwitcher，保证候选效果准备完成后才替换当前效果。为每次切换生成世代号，连续点击时只允许最后一次请求提交。候选效果失败时保留旧画面，候选效果过期时立即释放。

第六步：补齐四类效果映射

把 effectId 和参数应用逻辑集中在一个工厂中，页面只传 FilterKind 与配置。工厂必须对未知类型抛出明确错误，不能默默回退成另一个滤镜，否则问题会被误判为参数无效。

export interface ResourceFactoryAdapter {
  create(effectId: string): Promise<Effect>
}

export class FilterEffectFactory {
  constructor(private readonly resources: ResourceFactoryAdapter) {}

  async create(config: FilterConfig): Promise<Effect | undefined> {
    if (config.kind === 'none') return undefined
    if (config.kind === 'retro') {
      const normalized = normalizeRetro(config)
      const effect = await this.resources.create(
        spatialRender.GSPlugin.RETRO_EFFECT_ID
      )
      effect.setPropertyValue(spatialRender.RetroEffectParams.COLOR_NUM, normalized.colorNum)
      effect.setPropertyValue(spatialRender.RetroEffectParams.PIXEL_SIZE, normalized.pixelSize)
      effect.setPropertyValue(spatialRender.RetroEffectParams.BLEND_ENABLED, normalized.blendEnabled)
      effect.setPropertyValue(spatialRender.RetroEffectParams.CURVE, normalized.curve)
      return effect
    }
    throw new Error(`暂未实现的滤镜类型: ${config.kind}`)
  }
}

ResourceFactoryAdapter 是项目自定义适配器，用于屏蔽不同 SDK 版本中资源工厂类型签名的差异。适配器初始化时加载一次插件，业务工厂不应在每次滑杆变化时重复加载。

第七步：最后再加预设、撤销和动画

预设保存的是经过标准化的业务配置；撤销栈保存前后两个配置快照；过渡动画只负责 UI 反馈，不参与资源创建。把这些增强能力放到基础切换通过之后，可以避免动画结束、效果创建和页面销毁三套回调互相覆盖。

13. 按现象定位故障的检查顺序

现象一：createEffect() 直接失败

依次检查插件是否加载成功、effectId 是否来自 GSPlugin、系统与参数 API 版本是否满足、场景资源工厂是否属于当前 Scene。不要先改 UI，也不要用无限重试掩盖确定性的配置错误。

现象二：接口成功但画面没有变化

确认效果是否追加到了真正用于渲染的 Camera，当前渲染管线是否仍引用该相机，以及 effects 列表是否在后续初始化代码中被清空。随后使用一组差异明显的默认参数排除"效果存在但视觉变化太弱"。

现象三：快速切换后显示了旧选择

在日志中比较每次请求的 generation、开始时间和提交时间。如果较早请求在较晚请求之后提交，说明过期检查位置太早。检查应紧挨相机列表修改之前执行，而不是只在网络或资源加载之前执行一次。

现象四：切换次数越多越卡

先记录每轮切换后的相机效果数量，再看旧 Effect 是否仍被集合、闭包、页面状态或定时器引用。若列表始终只有一个但内存仍增长，继续查看资源释放接口和异步候选对象；若列表数量增长，优先修复追加而不替换的问题。

现象五：返回页面后偶发崩溃

重点检查 Scene、Camera 与 Effect 的销毁顺序。页面退出时先让 generation 失效，阻止新提交；随后解除相机效果；最后释放效果与场景相关资源。异步回调进入时再次判断任务是否有效，不能只依赖页面销毁时的一次标记。

现象	第一检查点	第二检查点	可观测证据
创建失败	插件与 effectId	API 与设备版本	错误码、插件加载结果
无视觉变化	Camera 绑定	参数是否有效	effects 数量、参数快照
旧选择覆盖	generation	提交时序	requestId 时间线
内存增长	旧引用	候选对象释放	切换后内存与对象数量
退出崩溃	销毁顺序	过期回调	生命周期日志、异常栈

14. 代码评审与长期维护要点

评审这类功能时，先看资源所有权，再看画面效果。Scene、Camera、Effect 分别由谁创建、谁持有、谁释放，应能从类结构直接回答。若一个页面点击事件同时负责插件加载、参数换算、效果创建、持久化和错误提示，后续增加第二种滤镜时几乎必然出现重复逻辑。

参数常量应来自官方枚举，不要在业务层复制字符串。业务配置可以有自己的字段名，但适配器中必须存在唯一映射点。SDK 升级后，只需要验证映射和资源释放行为，不必修改每个页面。

测试代码至少覆盖三类纯逻辑：参数标准化、配置到属性的映射、generation 过期规则。真机测试覆盖场景资源、渲染结果、性能和生命周期。纯逻辑与真机能力分开后，日常改动能用快速测试先拦截大部分回归，再把设备时间留给真正依赖渲染环境的检查。

版本升级时建立一张迁移表，记录 SDK 版本、最小系统 API、使用的 effectId、参数枚举、默认值、范围和释放接口。对比官方文档后再更新适配器，最后重跑四类效果、快速切换、返回页面和内存回落用例。这样一次平台升级不会演变成全工程盲查。

15. 总结

HarmonyOS 3DGS 滤镜切换实战：效果创建、参数管理与资源释放的重点，是围绕"切换滤镜时画面稳定且旧效果被释放"建立完整链路。先核对官方能力边界，再把任务放进独立控制器，通过稳定 requestId、显式状态、输入校验、生命周期保护和最终结果回读，让页面展示与真实结果保持一致。

参考资料

• 华为开发者联盟：文档中心
• 华为开发者联盟：文档中心

验证边界：本文依据公开官方资料核对能力方向与工程限制；示例中的控制器、状态机和数据封装属于可迁移的工程设计。设备适配、编译结果与性能阈值需要在目标 SDK 和真机环境中复测，并以实际运行记录为准。

CSDN-SERIES:HARMONYOS-BATCH-003-R1