前言

做屏幕录制时，最容易被忽略的一层，是捕获源尺寸和目标输出尺寸并不总是一致。手机长屏录到 16:9 视频，平板横屏录到固定比例画布，或者应用自己指定了一组输出宽高，这几种情况都会让画面进入缩放、裁切、留边三选一的处理过程。

鸿蒙 6 这一轮在 Media Kit 里把这件事收进了录屏策略，新增了屏幕捕获填充模式的 C API，同时引入了配套的填充模式枚举和策略对象。相关能力已经进入 6.0 的新增特性列表，OH_AVScreenCapture_CaptureStrategy 也从 API version 20 开始可用。

这类能力一旦开放，录屏页面的控制粒度会高很多。项目可以继续沿用原来的输出宽高，也可以针对直播、教学录屏、UI 演示、游戏录制分别做策略切换。文档里的录屏最佳实践还专门提到，屏幕宽高设置不当会导致录制视频出现黑边，这个提醒本身已经说明，输出尺寸和填充方式是联动关系。

一、填充模式真正影响的是什么

这次新增能力的抓手很明确，录屏策略对象 OH_AVScreenCapture_CaptureStrategy 用来承接策略设置，填充模式通过 OH_AVScreenCapture_StrategyForFillMode 配进去，再交给 OH_AVScreenCapture_SetCaptureStrategy 挂到录屏实例上。6.0 的新增能力里已经点名提到，屏幕录制新增支持通过 C API 设置目标区域内捕获画面的填充模式。

放到实际效果上，填充模式主要在解决一个问题，录制出来的画面到底优先铺满目标区域，还是优先保住完整内容。工程上可以把它理解成两种思路。第一种追求铺满，目标区域里尽量不留空，代价通常是边缘会被裁掉。第二种追求完整，原始内容尽量全保留，代价通常是上下或左右会出现黑边。这个判断和视频、图片里常见的 cover 与 contain 很接近，录屏场景只是在系统底层把它做成了策略开关。相关 API 的命名和文档里对黑边风险的提示，已经能支撑这种工程化理解。

这件事在比例差异明显的场景里最容易看出来。举个实际的例子，捕获源如果是 2340×1080，目标输出是 1920×1080，源画面更宽。铺满思路下，系统会优先保住目标区域被完整覆盖，横向超出的部分会被裁掉，左右边缘各损失一部分画面。完整保留思路下，系统会先把宽度缩进目标区域，最终得到大约 1920×886 的有效画面，上下各留出接近 97 像素的黑边。这部分是按常见填充逻辑做出来的计算推导，用来帮助开发时预估效果，比直接到真机上盲试更省时间。支持填充模式和录屏宽高自定义这两个前提，都已经在当前文档里列出来了。

二、代码里最关键的是策略对象和调用时序

这组能力的接入路径已经很清楚。先创建录屏实例，再创建 OH_AVScreenCapture_CaptureStrategy，然后把填充模式写进策略对象，再把策略对象挂到录屏实例上。相关指南和录屏写文件示例都已经出现了 OH_AVScreenCapture_CreateCaptureStrategy() 和 OH_AVScreenCapture_SetCaptureStrategy(capture, strategy) 这套写法，说明策略对象已经进入正式使用路径。

代码里最需要控制的是时序。SetCaptureStrategy 应该放在真正开始录屏之前，尽量和其他录屏前置配置放在一起处理。录屏写文件的文档片段里，策略设置和屏幕 ID 回调这类动作都处在开始录屏前的准备阶段。把策略设置拖到启动之后再做，后面排查效果异常时会很麻烦。

下面这段代码把核心配置流程收了一遍，重点放在填充模式和策略绑定，不再塞过多无关逻辑：

#include <multimedia/player_framework/native_avscreen_capture.h>

int32_t ConfigureFillMode(struct OH_AVScreenCapture *capture,
                          OH_AVScreenCapture_FillMode mode)
{
    if (capture == NULL) {
        return -1;
    }

    OH_AVScreenCapture_CaptureStrategy *strategy =
        OH_AVScreenCapture_CreateCaptureStrategy();
    if (strategy == NULL) {
        return -1;
    }

    OH_AVSCREEN_CAPTURE_ErrCode ret =
        OH_AVScreenCapture_StrategyForFillMode(strategy, mode);
    if (ret != AV_SCREEN_CAPTURE_ERR_OK) {
        // 这里按项目约定补资源清理
        return ret;
    }

    ret = OH_AVScreenCapture_SetCaptureStrategy(capture, strategy);
    if (ret != AV_SCREEN_CAPTURE_ERR_OK) {
        // 这里按项目约定补资源清理
        return ret;
    }

    // 后续再进入 Init、StartScreenCapture 等流程
    return AV_SCREEN_CAPTURE_ERR_OK;
}

这段代码里最重要的点有三个。第一，填充模式的配置对象和录屏实例分开管理。第二，填充模式先写入策略对象，再整体挂到录屏实例。第三，策略配置完成后再进入真正的初始化和启动流程。录屏示例文档已经明确给出了策略对象创建和绑定的写法，Release() 用来销毁录屏实例、释放资源这一点也已经在写文件示例里点出来了。

三、适配时别只看设备类型，先看内容和输出比例

填充模式这件事，表面上像设备适配，真正落地时先看内容。游戏录屏、短视频录屏、横屏直播，这几类场景更容易接受边缘裁切，画面铺满通常更重要。教程演示、表单录屏、后台管理系统录屏、UI 走查视频，这些场景对边缘内容更敏感，留边通常更稳。鸿蒙当前文档已经把录屏能力往文件输出、码流输出、自定义场景、矩形区域录制这些方向展开了，说明录屏早就不只是单一的系统全屏录像能力，应用自己要做的取舍会越来越多。

设备尺寸当然也要看，但不需要把规则写得太复杂。手机长屏转标准横屏视频时，比例差异最明显，裁切或黑边至少会出现一种。平板和大屏设备录到固定比例视频时，留边的概率更高。应用如果本身支持自定义输出宽高，最先该做的事不是切模式，而是先把目标宽高设置得合理一些。录屏最佳实践里已经直接提醒过，屏幕宽高设置不当会让视频出现黑边，这比一上来就堆设备分支更有用。

项目里如果准备把这件事做成用户可选项，界面层只需要把选择解释清楚就够了。给用户一个完整保留内容和画面优先铺满的切换入口，比一口气讲清楚所有比例细节更有效。技术上只要把填充模式切换收回到同一个策略构建流程里，后面维护成本不会高。API 6.0 已经把这套能力做成标准策略配置，项目没必要自己再做一套裁剪和补边算法。

四、排查方式

这类功能最怕的情况是，接口已经接了，画面也录出来了，但不同设备效果不一致。处理这类问题时，优先排查三件事。第一，目标输出宽高是不是设置得过于激进。第二，填充模式是不是和当前内容类型不匹配。第三，策略是不是在录屏开始前就已经挂上去了。当前文档已经明确指出宽高设置不当会带来黑边，录屏示例也把策略设置放在开始录屏前的配置阶段，这两点先看，能省掉很多无效调试。

性能上也别把事情想得太重。填充模式多了一层策略配置，开发成本几乎不会成为瓶颈，真正影响录制流畅度的还是分辨率、帧率、编码参数和设备本身的吞吐能力。高分辨率录屏时，如果设备边跑边发热、帧率开始掉，优先先降输出分辨率，再看是否要调整填充策略。录屏 API 这条线本身已经同时覆盖文件写入、码流输出和自定义场景，说明系统把录屏能力铺得很完整了，应用侧更值得花时间的地方还是录制参数组合。

如果项目里有比较重的录屏功能，建议把填充模式、输出宽高、录屏场景一起提成一份集中配置。这样做有两个好处。第一，排查黑边和裁切问题时更容易看出是哪一组参数组合导致的。第二，后面如果新设备形态再变化，或者项目要补更多录屏入口，配置层能直接复用。OH_AVScreenCapture_CaptureStrategy 本身就是给这类策略收口用的，继续把逻辑分散到多个业务模块里，后面会越来越乱。

总结

鸿蒙 6 API 20 这一轮把屏幕捕获填充模式正式收进了 Media Kit 的录屏策略体系，相关 C API、策略对象和填充模式枚举都已经进了当前能力范围。项目里真正要处理的核心问题很明确，录制画面在目标区域里到底追求铺满，还是追求完整。只要输出宽高和捕获源比例不一致，这个问题就绕不过去。

工程上更稳的做法也很清楚。策略对象统一创建，填充模式统一配置，开始录屏前把策略挂好。业务层按内容类型去选模式，参数层把输出宽高和录制场景一起收口。这样做下来，黑边、裁切和设备差异都会更容易控住，后面的录屏体验也会稳很多。