XComponent TEXTURE 模式详解

XComponent 是鸿蒙给原生渲染留的那扇门：ArkUI 页面里嵌一块由 C 或 C++ 全权掌控的表面。它有两种工作模式，TEXTURE 模式是移植工程用得最多的一种，值得单独讲透。

▍两种模式的差别
SURFACE 模式下应用拿到独立的 native window，自己 EGL 建上下文画上去；TEXTURE 模式下原生内容作为纹理参与 ArkUI 合成，位置、裁剪、圆角都跟普通组件一致，可以和 ArkUI 控件叠放混排。桌面移植大多选 TEXTURE：菜单浮层、工具栏、对话框用 ArkTS 画，主画布用 native 纹理，一层应用两种技术各展所长。

▍生命周期纪律
TEXTURE 表面不是一次创建永久有效。页面切换、窗口模式变化、深浅色切换都可能触发销毁重建。native 侧要在表面创建回调里初始化图形资源、在销毁回调里释放，中间的绘制请求要么排队要么丢弃。真实工程的血泪：表面已销毁但绘制线程还在往旧表面提交缓冲，症状是无声黑屏或随机崩溃，日志几乎无线索。

▍首帧与纹理消费
TEXTURE 模式的内容要经系统合成器消费才可见，首帧黑屏问题多发于此。个别机型纹理消费侧慢热，首帧提交后需要连续多次强制刷新才真正上屏——Air 系列在某机型上实测过连续四轮刷新才能稳定出首帧。判断黑屏是没画还是没消费，靠的是渲染侧提交计数与画面是否出现的对比证据。

▍坐标与尺寸
组件尺寸变化通过回调通知 native，密度换算要自己算对：组件给的可能是物理像素或 vp，两套单位混算是坐标偏移类 bug 的头号来源。旋转与折叠态变化时宽高对调，布局参数要即时跟随。

▍实践建议
把 XComponent 封装成独立的渲染宿主模块，生命周期、尺寸、输入三路回调统一管理，别让业务代码直接碰表面句柄。这一层封装好，后面接 GTK、Qt 还是引擎直连都是即插即用。

有疑问欢迎在本板块直接发帖，我们会逐条回复。