【共创季稿事节】HarmonyOS 6.1 创新特性适配实战：双镜记忆相机从 6.0 到 6.1 的升级记录

【共创季稿事节】HarmonyOS 6.1 创新特性适配实战：双镜记忆相机从 6.0 到 6.1 的升级记录

HarmonyOS 6.1 的适配不能只停留在"把 SDK 版本号改上去"。对一个真实项目来说，升级更像一次产品能力复盘：哪些能力必须跟着新系统重验，哪些体验可以借 6.1 基线进一步打磨，哪些能力在模拟器上跑得通但必须回到真机确认。

本文以"双镜记忆相机"项目为例，记录一次从 HarmonyOS 6.0 到 HarmonyOS 6.1 的适配方案。这个项目不是单页 Demo，它包含相机拍摄、前后双拍、地图记忆、系统相册导入导出、保险箱、防窥保护、近场分享、AI 图解、视频生成、华为账号和多设备布局。也正因为链路足够长，升级过程里踩到的问题更接近真实应用。

先说明一个口径：本文不是把所有能力都说成 6.1 才首次出现。像 Share Kit 碰一碰、DlpAntiPeep 防窥、Intents Kit 等能力在更早版本已经可用，但项目升级到 6.1.0(23) 后，需要把这些系统级体验放到同一张真机回归表里重验；真正的 6.1 新增和增强特性，以官方版本说明和 API 变更清单为准。本文更关注"围绕 6.1 基线如何把项目能力适配稳"。

双镜记忆相机：从拍照、记忆沉淀到多端分享的一条完整链路

先看项目效果图

适配 6.1 之前，我先把项目核心界面定下来。因为版本升级最后要服务的是体验，不是配置文件本身。下面四张图对应项目的四条主路径：拍摄、相册、地图记忆、隐私保险箱。

效果图 1：拍摄页，承载单拍、双拍、顺序双拍和拍后预览

效果图 2：相册页，照片记录、AI 图解和分享动作在这里汇合

效果图 3：地图记忆页，把照片记录沉淀成可回访的地点线索

效果图 4：隐私保险箱，敏感照片进入独立数据域并叠加认证、防窥策略

先定升级口径：6.1 真机，6.0 保底

项目里没有把 6.0 直接删掉，而是采用了双 product 策略：默认产物对齐 HarmonyOS SDK 6.1.0(23)，模拟器产物继续保留 6.0.2(22)。这样做有两个好处：

• 6.1 真机用于验证 6.1 基线下的增强体验，例如相机、分享、多设备窗口和系统级隐私能力。
• 6.0 simulator 用来保障基础页面、状态流转和非硬件能力不被破坏。

升级不是只改 SDK，设备类型、窗口模式、权限和能力边界都要一起检查

项目根目录的 build-profile.json5 里保留了两个目标：

{
  "name": "default",
  "targetSdkVersion": "6.1.0(23)",
  "compatibleSdkVersion": "6.1.0(23)",
  "runtimeOS": "HarmonyOS"
},
{
  "name": "simulator",
  "targetSdkVersion": "6.0.2(22)",
  "compatibleSdkVersion": "6.0.2(22)",
  "runtimeOS": "HarmonyOS"
}

这里的经验是：升级期不要把"能构建"和"能发布"混成一件事。能构建只能说明语法和依赖没有挡住；能发布还要看真机权限、设备能力、系统弹窗、分享面板、相机并发、隐私能力和多窗口表现。

适配点一：Camera Kit 从"能拍"升级到"先探测再决策"

官方 Camera Kit 的定位很明确：它不是简单拉起系统相机，而是让应用可以控制相机输入、会话和输出，完成预览、拍照、录像以及更多硬件组合能力。双镜记忆相机的核心场景正好需要前后摄协同，因此升级 6.1 时第一件事不是调用 capture，而是重新确认设备能力。

项目里把双拍分成三层：

• 优先尝试前后摄并发。
• 并发信息为空或输出能力不完整时，降级为顺序双拍。
• 顺序双拍也不可用时，保留单拍路径，确保用户至少能完成记录。

相机升级的目标不是炫 API，而是让用户在不同设备上都能完成拍摄闭环

关键代码在 Index.ets：

private safeGetCameraConcurrentInfos(
  cameraManager: camera.CameraManager,
  devices: Array<camera.CameraDevice>
): Array<camera.CameraConcurrentInfo> {
  try {
    return cameraManager.getCameraConcurrentInfos(devices);
  } catch (error) {
    console.error(`Failed to probe concurrent camera infos: ${JSON.stringify(error)}`);
    return [];
  }
}

this.cameraConcurrentProfileCount = concurrentInfos.length;
this.dualCameraSupported = concurrentInfos.length > 0;

真正开启双摄时，还要使用并发受限能力模式：

this.backCameraInput = this.cameraManager.createCameraInput(this.backCameraDevice);
this.frontCameraInput = this.cameraManager.createCameraInput(this.frontCameraDevice);
await this.backCameraInput.open(camera.CameraConcurrentType.CAMERA_LIMITED_CAPABILITY);
await this.frontCameraInput.open(camera.CameraConcurrentType.CAMERA_LIMITED_CAPABILITY);

升级时踩到的坑是：不能假设"有前摄 + 有后摄 = 能并发"。getCameraConcurrentInfos() 返回空时，继续强开并发只会把问题推迟到预览或拍照阶段爆出来。最佳实践是先探测，再选择链路，再把当前状态展示给用户。

适配点二：Share Kit 不只拉系统面板，还要接近场分享

6.1 适配里，分享链路是最容易被低估的。普通系统分享只要能把照片、视频、链接交给目标应用即可；近场分享则要求应用在合适的页面注册监听、构造可分享数据、在无内容或不支持时主动终止。

双镜记忆相机里，公开照片可以走碰一碰/隔空分享，保险箱照片不默认暴露。这个边界很重要：近场能力增强了效率，但不能让隐私内容被"顺手分享"。

近场分享只注册公开内容，保险箱内容继续走解锁后的显式操作

项目里的注册逻辑如下：

private async registerNearbyShareListeners(): Promise<void> {
  let ready = this.knockShareRegistered || this.gesturesShareRegistered;

  if (!this.knockShareRegistered) {
    try {
      harmonyShare.on('knockShare', this.nearbyShareCallback);
      this.knockShareRegistered = true;
      ready = true;
    } catch (error) {
    }
  }

  if (!this.gesturesShareRegistered) {
    try {
      const registry = await this.createSendCapabilityRegistry();
      harmonyShare.on('gesturesShare', registry, this.nearbyShareCallback);
      this.gesturesShareRegistry = registry;
      this.gesturesShareRegistered = true;
      ready = true;
    } catch (error) {
      // 不支持时回退到系统分享
    }
  }

  this.nearbyShareReady = ready;
}

这里的适配经验是：Share Kit 的监听应该跟页面生命周期绑定。进入支持分享的页面时注册，离开页面时注销；没有可分享内容时调用 reject，而不是让系统分享面板空转。

适配点三：隐私保护从"锁住"升级到"看见风险就遮住"

保险箱原本只解决"谁能打开"的问题，HarmonyOS 的防窥能力可以进一步解决"打开后是否安全可见"的问题。官方 DlpAntiPeep 能提供窥视状态，应用可以在检测到非机主注视屏幕时拉起系统级蒙层。

项目里为保险箱详情页接入了三步：

• 进入敏感详情页时检查防窥开关。
• 订阅 dlpAntiPeep 状态变化。
• 状态为 HIDE 时调用系统蒙层遮盖窗口。

保险箱不是只做一次认证，敏感内容展示期间也要持续保护

核心实现：

private async startGalleryAntiPeepProtection(): Promise<void> {
  try {
    const enabled = await dlpAntiPeep.isDlpAntiPeepSwitchOn();
    if (!enabled) {
      this.galleryAntiPeepStatusText = '系统防窥未开启';
      return;
    }

    this.galleryAntiPeepReady = true;
    this.galleryAntiPeepStatusText = '防窥保护已开启';
    if (!this.galleryAntiPeepSubscribed) {
      dlpAntiPeep.on('dlpAntiPeep', this.galleryAntiPeepCallback);
      this.galleryAntiPeepSubscribed = true;
    }

    const currentStatus = dlpAntiPeep.getDlpAntiPeepInfo();
    await this.applyGalleryAntiPeepStatus(currentStatus, false);
  } catch (error) {
    this.galleryAntiPeepStatusText = this.getGalleryAntiPeepErrorText(error.code ?? -1);
  }
}

这部分有两个坑。第一，权限必须在 module.json5 中声明 ohos.permission.DLP_GET_HIDE_STATUS。第二，能力不是所有设备都支持，错误码 801 要按"不支持"处理，而不是按普通失败处理。换句话说，隐私能力要有体验兜底：不支持时不影响保险箱基础认证，支持时再增强防窥。

适配点四：Intents Kit 把"附近记忆"变成系统可理解的能力

HarmonyOS 6.1 的智能体验不只是应用里多一个 AI 按钮，更重要的是让系统入口能理解应用能力。Intents Kit 的价值就在这里：应用把业务功能标准化为意图，系统可以在小艺对话、小艺搜索、小艺建议等入口进行智慧分发。

双镜记忆相机的例子是"附近记忆"。当用户回到曾经拍摄过的地点，系统可以通过位置推荐触发服务，让应用返回附近可回看的记忆内容。

把业务能力配置成意图，系统入口才有机会理解"附近记忆"

配置文件 insight_intent.json：

{
  "insightIntents": [
    {
      "intentName": "GetNearbyAgentLocation",
      "domain": "NearbyRecommendation",
      "intentVersion": "1.0.0",
      "srcEntry": "./ets/insightintents/NearbyAgentLocationIntent.ets",
      "uiAbility": {
        "ability": "EntryAbility",
        "executeMode": [
          "background"
        ]
      }
    }
  ]
}

这里的适配经验是：意图不是页面路由的别名。它应该返回稳定、可解释、可降级的业务结果。附近没有记忆时，要返回清晰的空结果；定位不可用时，要返回可诊断状态；不能为了"接入智能入口"把主应用状态写乱。

适配点五：多设备不是最后补一张平板图

6.1 升级后，项目把 phone、tablet、2in1 都放进配置，同时支持 fullscreen、split、floating 三种窗口模式。这个配置本身不能自动带来好体验，但它会倒逼页面适配：底部导航在宽屏下是否浪费空间，详情页长文案是否溢出，图片网格是否只会横向拉伸。

宽屏不是把手机页放大，而是重新组织导航、列表和详情的关系

module.json5 的配置：

"deviceTypes": [
  "phone",
  "tablet",
  "2in1"
],
"supportWindowMode": [
  "fullscreen",
  "split",
  "floating"
]

这次适配里，多设备验收主要看三点：

• 导航：手机保留底部 Tab，宽屏切换侧边导航。
• 内容：相册、视频、保险箱列表都要有空态和加载态，不能出现大白屏。
• 文案：按钮、卡片、标题必须设置 maxLines、textOverflow 或固定容器宽度，防止 2in1/分屏下挤压变形。

从 6.0 升到 6.1 的踩坑记录

第一类坑是"模拟器假安全"。相机并发、DLP 防窥、碰一碰、隔空分享、Intents 推荐都不能只看模拟器。模拟器能帮我们检查页面和语法，但不能证明设备能力存在。

第二类坑是"权限只写了一半"。例如相机、定位、生物认证、手势、防窥都要在 module.json5 中有清晰声明，且权限 reason 要能解释用户收益。权限弹窗不是审核材料之外的东西，它本身就是产品体验。

{
  "name": "ohos.permission.DETECT_GESTURE",
  "reason": "$string:gesture_permission_reason",
  "usedScene": {
    "abilities": ["EntryAbility"],
    "when": "inuse"
  }
},
{
  "name": "ohos.permission.DLP_GET_HIDE_STATUS",
  "reason": "$string:dlp_antipeep_permission_reason",
  "usedScene": {
    "abilities": ["EntryAbility"],
    "when": "inuse"
  }
}

第三类坑是"能力增强后忘了降级"。越是 6.1 的新体验，越要写清不支持时的结果。双摄并发不支持，就顺序双拍；近场分享不可用，就系统分享；防窥不可用，保险箱认证仍然有效；AI 在线失败，本地图解和原始照片仍然可用。

最终验收不是看某个 API 是否调用成功，而是看用户路径是否闭环

我的 6.1 适配清单

如果把这次经验整理成可复用清单，我会按这个顺序做：

1. 升级 SDK 和 DevEco Studio 后，先确认 targetSdkVersion、compatibleSdkVersion 和 product 分支。
2. 梳理应用依赖的硬件/系统能力，把"模拟器可测"和"必须真机"的能力分开。
3. 对 CameraKit、ShareKit、DLP、Intents 等能力先做支持性探测，再进入业务链路。
4. 每个增强能力都写降级策略，不让新能力成为主流程单点故障。
5. 把 phone、tablet、2in1、split、floating 放进同一张回归表，检查导航、空态、文案和图片比例。
6. 对外部服务能力，例如在线 AI、视频生成、云同步，保留本地状态和重试入口。
7. 最后再做发布材料：权限说明、隐私说明、截图矩阵、README、真机验收记录。

结语

HarmonyOS 6.1 的价值不是"新增了多少 API"，而是让应用能把相机、分享、隐私、智能入口和多设备体验组合成更自然的用户路径。双镜记忆相机这次适配下来，我最大的感受是：升级版本号很快，升级体验很慢；真正能沉淀下来的，是每个能力都有探测、有边界、有降级、有验证。

如果你的项目也准备从 6.0 升级到 6.1，建议不要从"我要接哪个新 API"开始，而是从用户路径倒推：用户在什么设备上、什么场景里、遇到什么失败时，仍然能不能完成任务。这个问题回答清楚，6.1 的新能力才会真正变成体验提升。

官方参考

• HarmonyOS 6.1.0(23) 版本说明
• Camera Kit 简介
• 碰一碰分享
• DlpAntiPeep 防窥保护
• Intents Kit 简介
• 一次开发，多端部署概览