鸿蒙云相册案例拆解:OBS 签名、重复备份识别与凭据边界
最近阅读了华为云鸿蒙开发实践中心的“用 OBS 打造个人云相册 app”案例。它不是只把图库和云端列表拼在一起,而是把端侧媒体、对象存储认证、重复备份判断和凭据管理放在同一条数据链路里。
这篇笔记按案例公开的页面说明整理,重点记录实现边界和验收方法。本文没有把案例截图当作实际运行结果,也没有使用真实 AK/SK 做测试。
先看清四层职责
案例的应用链路可以拆成四层:
- 页面层负责本地图库、备份记录、云端列表与网格、媒体预览和设置。
- 媒体扫描负责取得相册文件及其元数据,并支持照片、视频筛选和多选。
- 备份服务负责逐文件上传、进度、取消、重复判断和失败处理。
ObsClient负责构造 OBS 请求、完成 Header 认证、列举对象和读取媒体;预览缓存单独管理。
ArkUI 页面不直接拼装 OBS 请求,而是调用备份服务和客户端。OBS 配置、上传记录等放在应用沙箱的 preferences 中,媒体原文件仍由系统相册管理。
OBS Header 签名不是普通的 Authorization
案例采用 OBS 的 Header 签名方式。核心输入包括请求方法、内容头、规范化后的 x-obs-* 请求头和资源路径;随后使用 SK 对签名串计算 HMAC-SHA1,再经过 Base64 编码,最终形成 Authorization: OBS AK:Signature。
这条链路里,任何一项变化都可能让签名失效:
- 请求方法必须参与签名,不能只生成一次认证头后复用到 GET 和 PUT。
x-obs-*请求头要按规范参与规范化,名称和值的处理不能随意省略。- Endpoint、桶名和对象路径必须对应当前请求,不能拿完整对象 URL 代替 Endpoint,也不能把“桶名.Endpoint”的访问域名直接填进配置。
- 设备时间明显偏离标准时间时,可能出现签名或请求校验失败。
遇到 403 时,优先核对区域 Endpoint、桶名、AK/SK、权限和请求时间,再检查实际签名串。只看到“403”就重复提交,通常找不到根因。
重复备份如何判断
云相册最容易出现的问题是同一张照片被反复上传,既浪费时间,也会产生不必要的请求和存储占用。案例把对象键设计成 photo_backup/v2/SHA256(localUri,size,modifiedAt,md5)/safeName,让本地 URI、大小、修改时间和内容摘要共同参与目标定位。
判断是否已备份时,不只看文件名,也不只看上传记录。案例同时结合本地文件信息、MD5 和云端 ETag 做校验,并把备份记录按 Endpoint 和桶隔离。换一个桶或换一套端点时,不能直接复用旧记录。
基础实现采用逐文件上传,显示进度并支持取消;再次发起时继续处理尚未完成的文件。这个行为不能包装成“分片断点续传”:案例明确说明基线没有实现 OBS 分段上传,单文件上传和预览上限均为 64 MiB。超过上限的视频需要另行设计分段上传、合并和失败清理。
预览缓存另有边界:磁盘缓存不超过 128 MiB,缩略图最多 64 张。缓存命中可以改善体验,但缓存不是云端对象本身,也不能代替下载恢复或持久化备份。
凭据和费用的边界
案例把 AK、SK、Endpoint 和桶名放在 App 设置中。密码态输入只隐藏显示,不等于加密;沙箱中的 preferences 仍可能以明文保存密钥。课程测试可以用这种方式降低实现复杂度,正式产品应采用临时授权或受控的密钥代理方案。
配置时还要守住几条底线:
- 使用独立的测试桶,优先采用只具备
ListBucket、PutObject、GetObject最小权限的 IAM 用户。 - 不把 AK/SK 写入源码、聊天、日志、截图或公开问题。
- 桶使用私有访问和 HTTPS,上传时计算
Content-MD5,避免内容与目标对象不一致。 - 40 GB 存储包只在其适用条件下抵扣存储费,不等于公网流量、请求次数和所有超额用量都免费。
一套可执行的验收顺序
准备少量非敏感测试照片和视频,创建私有 OBS 桶,取得正确区域的 Endpoint、桶名和测试凭据,然后按以下顺序检查:
- 在 App 设置中保存四项配置,刷新云端列表,确认请求使用当前区域的 Endpoint。
- 选择一张测试照片上传,检查进度、完成状态和云端对象是否可找到。
- 重复发起同一文件的备份,确认本地信息、MD5 和 ETag 能识别已备份对象。
- 取消一次上传,再次发起,确认未完成文件能继续处理,而不是报告为成功。
- 切换云端列表和网格,打开图片和视频预览;再检查 64 MiB、128 MiB 和缩略图数量限制。
- 故意配置错误区域或缺少权限,确认 403 的排查路径,不把错误当成网络抖动。
- 测试结束后删除测试对象,轮换或撤销测试密钥,并核对桶内历史版本和可能产生的费用。
这套顺序把“界面上看到一张图”和“认证、上传、去重、预览均正确”分开。媒体应用的风险通常不在页面渲染,而在一次请求的签名和一条记录是否对应真实对象。
- 点赞
- 收藏
- 关注作者
评论(0)