libpag在鸿蒙系统中使用PAGPlayer.flush导致应用冻结问题分析

问题背景

在鸿蒙系统Beta3版本上，开发者在使用libpag库进行动画渲染时遇到了一个严重问题：当通过displaySync的on('frame')回调调用PAGPlayer.flush方法时，会导致应用程序完全冻结。这个问题在使用Flutter框架结合鸿蒙外接纹理实现时尤为明显。

问题现象

开发者观察到以下典型现象：

1. 动画能够正常播放一段时间
2. 当关联的Texture组件被移除或隐藏时（如被其他组件覆盖、透明度设为0等）
3. 几秒钟后应用程序完全冻结，无法响应任何操作

技术分析

通过分析崩溃堆栈和日志，我们发现问题的根源在于鸿蒙系统的图形渲染管线：

1. 堆栈分析：崩溃发生在OpenGL的glDrawElements调用之后，整个调用链从PAGPlayer.flush开始，经过多层渲染管线，最终在系统层的BufferQueue::RequestBuffer处发生阻塞。

2. 错误日志：在应用冻结前，系统会输出关键错误信息："NativeWindowRequestBuffer: API failed, please check RequestBuffer function ret:40601000"，这表明图形缓冲区的请求出现了问题。

3. 对比分析：与视频播放器的实现对比发现，当Texture组件不可见时，视频播放器能够正确处理缓冲区获取失败的情况（当OH_NativeWindow_GetBufferHandleFromNative返回nullptr时直接返回），而libpag当前实现中没有类似的保护机制。

根本原因

综合各种线索，可以确定问题的根本原因是：

当关联的Texture组件不可见时，鸿蒙系统会回收或禁用相关的图形缓冲区资源。此时如果继续尝试通过PAGPlayer.flush进行渲染，系统无法提供有效的缓冲区，导致渲染管线在RequestBuffer处无限等待，最终造成应用冻结。

解决方案建议

针对这个问题，我们建议从以下几个方向进行解决：

1. 资源状态检查：在调用flush前，应检查关联的Surface资源是否仍然有效。可以参考视频播放器的实现，在获取不到有效缓冲区时及时终止渲染流程。

2. 生命周期管理：当Texture组件被移除或隐藏时，应主动释放相关的PAGSurface资源，避免继续尝试渲染。

3. 错误处理增强：在渲染管线中添加更多的错误检查和恢复机制，特别是对系统API调用返回值的检查。

4. 异步超时机制：对于可能阻塞的系统调用，添加超时机制，避免无限等待。

技术实现细节

对于开发者而言，在现有代码中可以采取以下临时解决方案：

1. 在使用PAGPlayer.flush前，先检查关联的Texture组件是否仍然可见和有效。

2. 监听Texture组件的生命周期事件，在组件即将被移除时暂停动画渲染。

3. 考虑使用try-catch块包裹flush调用，捕获可能的异常情况。

总结

这个问题揭示了在鸿蒙系统上进行高性能图形渲染时需要特别注意的资源管理问题。通过合理的资源状态检查和错误处理，可以避免类似的应用程序冻结问题。对于libpag库的长期维护，建议增加对鸿蒙系统的适配层，更好地处理系统特有的图形资源管理机制。