mengtnt的Blog

普通人用小龙虾可以做什么

2026-04-16T06:57:51+00:00

开场白

Hacker News 上有个挺火的讨论，80 多条评论，一群人围着 OpenClaw 这个 AI Agent 工具聊得热火朝天。

我花了一晚上爬完了所有评论，发现一个有意思的现象：同样是 AI 助手，有人拿它当管家，有人拿它当秘书，还有人拿它当学习伴侣。

今天这篇文章，我就把 HN 上大家讨论最热烈的使用场景整理出来，挑出TOP 3 最佳场景，每个场景都给你分析清楚利弊。

看完你就知道，这只”小龙虾”到底能帮你干啥。

TOP 1：Obsidian 笔记自动化 ⭐⭐⭐⭐⭐

这是 HN 上提及频率最高的场景，没有之一。

场景长什么样？

想象一下这个工作流：

你白天在 Obsidian 里写了几篇笔记，可能是读书笔记、会议记录、或者学习笔记。晚上睡觉前，你什么都不用做，OpenClaw 会自动：

拉取你私有 GitHub 仓库里的 Obsidian 更新
解析新增的笔记内容
用 LLM 提取关键知识点，生成闪卡（Flashcards）
把闪卡自动导入 Anki 或你的间隔重复系统
第二天早上，你打开闪卡 App，昨天学的内容已经变成可以复习的卡片了

有位叫 dsiegel2275 的用户是这么说的：

“我每晚让 OpenClaw 拉取私有 GitHub 仓库的 Obsidian 笔记更新，然后运行’创建闪卡’skill 提取有用的闪卡用于间隔重复练习。第二天打开闪卡 App 时，已经有昨天课程的新卡片可以复习了。”

更进阶的玩法是自动汇总：日报 → 周报 → 月报，全自动生成。

技术实现

Git 同步 + Markdown 解析 + LLM 提取知识点
通过 API 将闪卡插入 Anki 或自定义系统
可选：自动提醒复习

利 ✅

真正的”无感”学习：你只管写笔记，剩下的交给它
知识沉淀自动化：不再担心笔记写完就吃灰
间隔重复无缝衔接：学习曲线更平滑

弊 ❌

需要一定的技术基础：得会配置 Git 仓库、API keys
闪卡质量依赖 LLM：有时候提取的知识点不够精准
初期设置耗时：有用户反馈配置需要 20~30 步

适合谁？

重度 Obsidian 用户
有持续学习习惯的人
愿意花时间搭建自动化工作流的技术爱好者

TOP 2：信息摘要与每日简报 ⭐⭐⭐⭐

这是第二个热门场景，多位用户分享。

场景长什么样？

你每天关心 Hacker News、Twitter 上的某些话题，但没时间一条条刷。OpenClaw 可以：

定时抓取你指定的信息源（HN、Twitter、RSS 等）
根据你的兴趣主题筛选内容
用 LLM 生成摘要
在固定时间（比如每天早上 8 点）把简报发送到你的 Telegram/Slack/Discord

用户 lizardking 说：

“我让它每晚扫描 Hacker News 和 Twitter 上我感兴趣的主题，摘要故事和讨论。这是一个很棒的每日摘要。”

还有个叫 jameson 的用户用它来：

“在预定时间总结 Top 10 Hacker News 或发送每日笑话。”

更智能的是，它可以条件触发——只有当有重要内容时才通知你，避免信息过载。

技术实现

RSS/爬虫 + LLM 摘要 + 定时任务（Cron）
支持条件触发（仅在有重要内容时通知）

利 ✅

信息过载的解药：你只看摘要，不用刷原始信息流
个性化筛选：只关注你真正关心的话题
时间可控：固定时间推送，不打断工作流

弊 ❌

可能错过上下文：摘要再精准，也可能漏掉重要细节
Token 消耗大：处理大量文本，成本不低
误判风险：AI 可能把重要内容判定为”不重要”

适合谁？

信息焦虑症患者
需要追踪多个信息源的专业人士
想节省刷社交媒体时间的任何人

TOP 3：邮件管理与自动化 ⭐⭐⭐⭐

第三个热门场景，尤其是对于商务人士。

场景长什么样？

你的邮箱每天收到几十上百封邮件，OpenClaw 可以帮你：

监控特定发件人或主题的邮件
自动分类和整理到不同文件夹
从发票 PDF 中提取数据，录入成本跟踪表
草稿回复邮件（需要你确认后再发送）

用户 zsiddique 分享：

“我有自动化处理 incoming 邮件并执行任务。对于某些类型的邮件和问题，我已经有心理公式，现在交给 AI 处理。它可以快速回复，有时我会发现它偏离轨道（AI 数学还是有问题），但这些都是需要快速响应的事情。”

还有个很实用的场景是日历检查：

“我让它检查 Outlook 日历，告诉我是否有任何 1:1 会议对方已经拒绝（因为 Outlook 不清晰显示这个，我经常到会才发现对方取消了）。” — superfrank

技术实现

IMAP/邮件 API + 规则引擎 + LLM 分类
PDF 解析（发票等）
与日历 API 集成

利 ✅

减少重复劳动：分类、整理、提取数据，全自动
不错过重要邮件：优先级排序，重要邮件优先处理
快速响应：草稿自动写好，你只需要确认

弊 ❌

隐私风险：邮件包含敏感信息，需谨慎授权
AI 可能理解偏差：尤其是复杂语境下的邮件
配置复杂：不同邮件服务商 API 不同，需要分别配置

适合谁？

邮件量大的商务人士
需要处理大量发票/报销的创业者
经常开会、需要日历管理的职场人

其他值得关注的场景

除了 TOP 3，还有一些场景也值得提一下：

场景	热度	一句话描述
个人任务管理	⭐⭐⭐⭐	语音消息添加待办，像对真人助理说话
家庭自动化	⭐⭐⭐	Home Assistant 崩溃了？让机器人重启它
代码开发部署	⭐⭐⭐	记下一个 App 想法，几分钟后就部署好了
语言学习	⭐⭐⭐	日语学习 + Obsidian + Anki 一体化
健康数据追踪	⭐⭐	卡路里追踪、天气监控、心理健康提醒

有个场景我觉得特别有意思——心理健康支持：

“一个记录你最近做的酷事的 agent，并主动提醒你，帮助你从更宏观的角度看问题，对我生活中因各种原因倾向于更负面认知模式的人很有帮助。” — piazz

这只小龙虾，还能当你的情绪管家。

用户怎么说？

正面评价

“便利性是能够在购物时要求它做某事，并让它自动测试等。” — BeetleB

“真正的解锁是保持在一个上下文中，不会迷失在琐碎细节的长尾中。” — ryanmcgarvey

“我有 GitHub 和 Vercel 连接，这意味着我可以记下一个小生产力 App 的想法，几分钟后它就出现并部署好了。” — ryanmcgarvey

负面评价

“初始设置比我想象的要耗时。OpenClaw 设置和配置是 20~30 步的情况，需要很多 API keys。” — godot

“潜力巨大。现实是令人沮丧和不可靠的。当它工作时，你真的很喜欢它。” — BeetleB

“Token 使用量不合理。要么使用更聪明的模型（成本更高），要么使用更便宜的模型（有时会陷入循环）。” — jameson

“OpenClaw 正好处于 prompt injection 致命三要素中。OpenClaw 实例能够重置你的账户密码听起来非常可怕。” — tcoff91

核心争议：为什么不用脚本 + Cron？

这是整个讨论里最核心的争议点。

支持 Agent 的人说：

“写一个脚本和 crontab 条目需要更多努力，而 OpenClaw 开箱即用。”
“老板可能甚至不知道 Bash 是什么，更不用说 crontab 了。”
“是的，但我现在不需要问你（开发者）了。”

支持脚本的人说：

“如果我可以 prompt AI 在几分钟内写一个实际的确定性脚本来解决问题，然后永远运行它，为什么要把它委托给非确定性 AI？”
“我更喜欢如果它不按预期工作时有东西可以调试。”
“那将是有效的，如果设置定时 AI 任务真的需要任何技术知识，但它不需要。ChatGPT 让你在 UI 中原生安排任务。”

我的看法

这其实不是二选一的问题。核心业务用脚本，边缘任务用 Agent，可能是更务实的选择。

总结：小龙虾适合你吗？

适合使用 OpenClaw 的场景

非技术用户需要自动化但不想学习脚本
快速原型和实验性项目
个人助理类任务（提醒、摘要、简单查询）
学习/实验Agent 技术和多 Agent 系统

不适合的场景

关键业务流程（需要确定性）
高价值/高风险操作（银行、密码等）
大规模生产环境（成本不可控）
需要审计/合规的场景

最佳实践建议

沙箱运行：在 VPS 或容器中运行，限制访问权限
渐进式授权：从低风险任务开始，逐步增加权限
监控与审计：记录所有操作，定期检查
混合架构：核心业务用脚本，边缘任务用 Agent
成本控制：设置 Token 预算，使用便宜模型处理简单任务

最后说两句

HN 上有位用户预测：

“我敢打赌几年后这将成为标准做法。” — bryan0

另一位说：

“这是一个很棒的工具。想象一下拥有你自己的管家，除了可靠性与可负担性还没有达到做任何严肃事情的程度。” — jameson

AI Agent 还在早期阶段，但它已经在改变一些人的工作方式了。

关键是找到适合你的场景，从小处开始，逐步扩展。

这只小龙虾能帮你干啥，最终取决于你想让它干啥。

Claude 三种 Agent 架构全解析：SDK vs Teams vs Managed 如何选择

2026-04-12T00:00:00+00:00

Claude 三种 Agent 架构全解析：SDK vs Teams vs Managed 如何选择

引言

Anthropic 最近连续发布了三个与 Agent 相关的重磅产品：Agent SDK、Agent Teams 和 Managed Agents。这一系列动作标志着 Claude 正式从”对话模型”进化为”Agent 平台”。

对于开发者而言，这三个产品代表了三种截然不同的 Agent 构建范式。选择错误的架构可能导致数周的开发工作付诸东流。本文基于实际项目经验，深入剖析三种架构的技术细节、优缺点和适用场景，帮助你在项目中做出正确的选择。

一、三种架构概览

特性	Agent SDK	Agent Teams	Managed Agents
控制粒度	最高	中等	最低
开发工作量	最大	中等	最小
状态管理	自己实现	共享 Task List	平台托管
错误处理	自己实现	部分自动	平台自动
适合场景	核心业务	长任务协作	简单任务

二、Agent SDK：完全控制的代价

2.1 架构原理

Agent SDK 是最早发布的方案，它提供了一套底层 API，让你自己编写完整的 agent loop。你需要处理：

Token 计数和截断
工具调用和结果解析
错误重试和回退
无限循环检测
中间状态持久化

2.2 代码示例

from anthropic import Agent

class MyAgent:
    def __init__(self):
        self.agent = Agent(
            model="claude-sonnet-4-20260514",
            tools=[search_tool, code_tool],
            max_iterations=50
        )
        self.state = {}
    
    async def run(self, goal: str) -> str:
        # 70% 的代码是防御性编程
        try:
            # Token 超限检测
            if self.token_count > 180000:
                await self.truncate_context()
            
            # 调用 Agent
            result = await self.agent.run(goal)
            
            # 无限循环检测
            if self.iteration_count > self.max_iterations:
                raise AgentLoopError("Too many iterations")
            
            # 持久化中间结果
            await self.save_state()
            
            return result
            
        except ToolError as e:
            # 工具失败重试
            return await self.retry_with_backoff(e)
        except TokenLimitError:
            # Token 超限处理
            return await self.compress_and_continue()

2.3 实际踩坑经验

坑 1：Token 超限

Claude 的 context window 虽然大，但复杂任务很容易超限
必须实现智能截断策略：优先保留最近的消息和关键工具结果
建议设置软限制（180k）而非硬限制（200k）

坑 2：工具调用失败

网络波动、API 限流、工具超时都会导致失败
必须实现指数退避重试
对于幂等操作可以重试，非幂等操作需要补偿机制

坑 3：无限循环

Agent 可能陷入”调用工具→失败→再调用”的死循环
需要检测重复的工具调用模式
设置最大迭代次数并强制终止

2.4 优缺点

优点：

完全控制 Agent 行为
可以针对业务场景深度优化
不受平台配额限制

缺点：

业务逻辑只占 30%，70% 是 harness 代码
开发周期长，维护成本高
需要深厚的工程经验

三、Agent Teams：共享状态的协作范式

3.1 架构原理

Agent Teams 的核心创新是共享 Task List。与传统子 Agent 的”fire-and-forget”模式不同：

所有 Agent 共享同一个任务列表
Agent A 发现的问题可以直接添加到 Task List
Agent B 实时看到并可以接手处理
任务状态对所有 Agent 可见

3.2 代码示例

from anthropic import AgentTeam

# 创建共享任务列表
team = AgentTeam(
    model="claude-sonnet-4-20260514",
    agents=[
        Agent(name="researcher", tools=[search_tool]),
        Agent(name="coder", tools=[code_tool]),
        Agent(name="reviewer", tools=[review_tool])
    ],
    shared_state=True  # 关键：启用共享状态
)

# 所有 Agent 可以看到彼此的任务
await team.run("""
完成以下项目：
1. 调研最新的 Agent 框架
2. 实现核心功能
3. 代码审查和优化
""")

# Agent A (researcher) 可以在任务列表中添加新任务：
# "发现依赖库 X 有安全问题，需要升级到 Y 版本"
# Agent B (coder) 会立即看到并处理

3.3 与传统子 Agent 的对比

传统子 Agent 模式：
主 Agent → 子 Agent A (独立执行，返回结果)
        → 子 Agent B (独立执行，返回结果)
        
问题：子 Agent 之间无法通信，A 发现的问题 B 不知道

Agent Teams 模式：
共享 Task List:
- [✓] 调研框架 (Agent A 完成)
- [→] 实现功能 (Agent B 进行中)
- [!] 发现安全问题 (Agent A 添加，等待处理)
- [ ] 代码审查 (Agent C 待处理)

优势：所有 Agent 实时看到完整上下文

3.4 实际踩坑经验

坑 1：任务冲突

多个 Agent 可能同时处理同一个任务
需要实现任务锁或状态标记
建议设置”认领”机制

坑 2：状态同步延迟

共享状态不是完全实时的
关键决策前需要显式同步
避免依赖毫秒级一致性

3.5 优缺点

优点：

适合长任务、多阶段项目
Agent 之间可以自然协作
人类可以随时介入查看进度

缺点：

共享状态增加复杂度
不适合完全独立的并行任务
调试难度较高

四、Managed Agents：企业级稳定 Agent 的加速器

4.1 架构原理

Managed Agents 不是为”简单任务”设计的玩具，而是为企业降低 Agent 开发成本、提升稳定性而生的生产级方案。

核心理念：让企业专注于业务逻辑，而非基础设施。

你需要做的：

定义业务 goal
提供领域 tools（API、数据库、内部系统）
平台处理所有工程复杂性

harness、memory、子 Agent 编排、错误恢复、状态持久化全部由平台托管。

4.2 代码示例

from anthropic import ManagedAgent

# 企业级 Agent：客户服务自动化
customer_agent = ManagedAgent(
    model="claude-sonnet-4-20260514",
    goal="""处理客户咨询，包括：
    1. 查询订单状态
    2. 处理退换货申请
    3. 解答常见问题
    4. 升级复杂问题到人工客服""",
    tools=[
        order_lookup_tool,      # 内部订单系统 API
        refund_tool,            # 退款系统 API
        knowledge_base_tool,    # 企业知识库
        ticket_escalation_tool  # 工单系统
    ],
    memory_config={
        "type": "persistent",  # 持久化记忆
        "retention_days": 90   # 客户对话保留 90 天
    },
    compliance_config={
        "data_residency": "EU",  # 数据驻留要求
        "audit_logging": True    # 审计日志
    }
)

# 生产环境部署
await customer_agent.deploy(
    environment="production",
    scaling_policy="auto",  # 自动扩缩容
    sla_target=99.9         # SLA 目标
)

4.3 企业级优势

1. 稳定性保障

平台级错误恢复：自动重试、fallback、熔断
状态持久化：Agent 崩溃后可从中断点恢复
版本管理：Agent 配置可版本化、回滚
监控告警：内置性能监控和异常告警

2. 开发成本大幅降低

无需编写 harness 防御代码（节省 70% 开发量）
无需处理 token 管理、错误重试、无限循环检测
无需搭建监控、日志、追踪系统
小团队也能构建生产级 Agent

3. 企业合规支持

数据驻留控制（GDPR 合规）
审计日志（金融、医疗行业要求）
访问控制和权限管理
PII 数据自动脱敏

4. 可扩展性

自动扩缩容应对流量峰值
多区域部署降低延迟
与企业现有系统无缝集成

4.4 实际踩坑经验

坑 1：初期配置复杂度高

企业级功能需要详细配置（合规、审计、权限）
建议：从最小可行配置开始，逐步迭代

坑 2：自定义逻辑受限

核心循环逻辑由平台管理
非常规需求可能需要切换到 SDK
建议：80% 标准化流程用 Managed，20% 特殊场景用 SDK

坑 3：供应商锁定风险

深度依赖平台特性后迁移成本高
建议：关键业务逻辑保持模型无关，tools 层抽象化

4.5 优缺点

优点：

开发成本降低 70%+（无需 harness 代码）
生产级稳定性（平台级错误恢复、监控）
企业合规开箱即用
小团队也能构建复杂 Agent

缺点：

核心逻辑控制力较弱
深度定制需求受限
存在供应商锁定风险

4.6 适用场景

强烈推荐：

企业客户服务 Agent
内部知识库问答系统
标准化业务流程自动化
需要合规审计的场景（金融、医疗）

不推荐：

需要完全控制 Agent 行为的场景
非常规、实验性 Agent 设计
预算极其有限的小项目

五、选型建议：实战中的混搭策略

基于实际项目经验，推荐的架构选择策略：

5.1 核心业务 → Agent SDK

场景： 支付处理、用户数据操作、关键业务流程

理由：

需要完全控制错误处理
业务逻辑复杂，需要深度优化
不能接受平台配额限制

# 核心支付流程必须用 SDK
class PaymentAgent:
    def __init__(self):
        # 自定义重试、补偿、审计日志
        self.retry_policy = ExponentialBackoff(max_retries=5)
        self.audit_log = AuditLogger()
    
    async def process_payment(self, order):
        # 100% 控制力
        pass

5.2 跨平台分发 → 传统子 Agent 并行

场景： 同时发布到微信公众号、Twitter、博客

理由：

各平台完全独立
不需要共享状态
并行执行效率最高

# 完全独立的任务，用传统子 Agent
tasks = [
    publish_to_wechat(article),
    publish_to_twitter(article),
    publish_to_blog(article)
]
await asyncio.gather(*tasks)

5.3 长任务复盘 → Agent Teams

场景： 项目开发、代码重构、内容创作

理由：

任务周期长，需要多阶段协作
可能需要人类中途介入
共享状态便于追踪进度

# 长周期项目用 Teams
project_team = AgentTeam(
    agents=[planner, executor, reviewer],
    shared_state=True
)
await project_team.run("重构用户认证模块")

5.4 内部杂事 → Managed Agents

场景： 数据清洗、日志分析、简单报告

理由：

任务简单标准化
开发效率优先
可以接受平台限制

# 简单任务用 Managed
await ManagedAgent(
    goal="整理昨天的错误日志",
    tools=[log_tool]
).run()

六、接入自定义模型能力

虽然 Anthropic 的三种架构默认使用 Claude 模型，但在实际生产中，你可能需要：

降低成本：用廉价模型处理简单任务
特定能力：某个模型在特定领域表现更好
数据合规：使用本地部署模型
避免供应商锁定：保持架构的模型无关性

6.1 SDK 架构：完全灵活的模型接入

SDK 的最大优势是可以无缝切换任意模型提供商。

方案 A：通过 OpenRouter 统一接入

OpenRouter 提供统一的 API 格式，支持 100+ 模型：

from openai import OpenAI

# OpenRouter 兼容 OpenAI SDK
client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key="YOUR_OPENROUTER_KEY"
)

class MultiModelAgent:
    def __init__(self):
        self.client = client
        self.model_router = {
            "complex": "anthropic/claude-sonnet-4",
            "simple": "google/gemini-3-flash-preview",
            "code": "deepseek/deepseek-coder-v2",
            "local": "local/llama-3-70b"  # 本地模型
        }
    
    async def run(self, goal: str, complexity: str = "medium"):
        model = self.model_router.get(complexity, "complex")
        
        response = self.client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": goal}],
            tools=self.tools,
            tool_choice="auto"
        )
        
        return self.parse_agent_response(response)

优点：

一个 API 接入所有模型
按实际使用付费，无需预充值
自动 fallback 机制

成本对比（每 1M tokens）：

模型	输入	输出	适用场景
Claude Sonnet 4	$3	$15	核心业务
Gemini 3 Flash	$0.075	$0.3	简单任务
DeepSeek Coder	$0.14	$0.28	代码生成
Llama 3 70B (本地)	$0	$0	数据敏感

方案 B：本地模型部署（Ollama/vLLM）

from openai import OpenAI

# 本地 Ollama 服务
local_client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"
)

class HybridAgent:
    def __init__(self):
        # 云端 Claude 处理复杂任务
        self.cloud_client = Anthropic(api_key="...")
        # 本地模型处理敏感数据
        self.local_client = local_client
    
    async def process_sensitive_data(self, data: str):
        # 敏感数据不出本地
        response = self.local_client.chat.completions.create(
            model="llama3:70b",
            messages=[{"role": "user", "content": data}]
        )
        return response.choices[0].message.content
    
    async def complex_reasoning(self, goal: str):
        # 复杂推理用 Claude
        return await self.cloud_client.messages.create(
            model="claude-sonnet-4-20260514",
            max_tokens=4096,
            messages=[{"role": "user", "content": goal}]
        )

方案 C：模型路由策略

class SmartRouter:
    def __init__(self):
        self.models = {
            "claude": AnthropicClient(),
            "gemini": GeminiClient(),
            "local": OllamaClient()
        }
    
    def select_model(self, task: dict) -> str:
        # 根据任务特征选择模型
        if task.get("sensitive"):
            return "local"
        elif task.get("complexity", 0.5) > 0.8:
            return "claude"
        elif task.get("type") == "code":
            return "claude"  # 或 deepseek
        else:
            return "gemini"  # 便宜够用
    
    async def run(self, task: dict):
        model = self.select_model(task)
        return await self.models[model].run(task)

6.2 Agent Teams：有限的模型自定义

Agent Teams 目前仅支持 Claude 模型，但可以通过以下方式变通：

# 变通方案：外部模型作为"工具"
from anthropic import AgentTeam
import requests

def call_local_model(query: str) -> str:
    """作为工具调用的本地模型"""
    response = requests.post(
        "http://localhost:11434/api/generate",
        json={"model": "llama3", "prompt": query}
    )
    return response.json()["response"]

team = AgentTeam(
    model="claude-sonnet-4-20260514",
    agents=[
        Agent(name="researcher", tools=[search_tool]),
        # 本地模型作为工具被 Claude 调用
        Agent(name="local_processor", tools=[call_local_model])
    ]
)

限制：

主模型必须是 Claude
其他模型只能作为工具被调用
无法让某个 Agent 完全使用非 Claude 模型

6.3 Managed Agents：不支持自定义模型

Managed Agents 完全绑定 Claude 模型，无法切换。

应对策略：

简单任务用 Managed + Claude（省心）
需要自定义模型的任务降级为 SDK 架构
在 SDK 层实现模型路由，Managed 层只处理标准化流程

6.4 实战建议：混合模型架构

class ProductionAgentSystem:
    """生产环境的混合模型架构"""
    
    def __init__(self):
        # 1. SDK 层：核心业务，支持任意模型
        self.core_agent = SmartRouter()
        
        # 2. Teams 层：协作任务，用 Claude
        self.project_team = AgentTeam(
            model="claude-sonnet-4-20260514",
            agents=[...]
        )
        
        # 3. Managed 层：简单任务，用 Claude
        self.simple_tasks = [
            ManagedAgent(goal="日志分析", ...),
            ManagedAgent(goal="数据清洗", ...)
        ]
    
    async def dispatch(self, task: dict):
        if task.get("requires_custom_model"):
            return await self.core_agent.run(task)
        elif task.get("long_running"):
            return await self.project_team.run(task)
        else:
            return await self.simple_tasks[0].run()

成本优化效果（月处理 100 万 tokens）：

策略	纯 Claude	混合模型
月成本	~$10	~$3
性能	100%	95%+
灵活性	低	高

七、架构对比总结

维度	SDK	Teams	Managed
开发时间	2-4 周	1-2 周	1-2 天
控制力	★★★★★	★★★☆☆	★☆☆☆☆
维护成本	高	中	低
适合团队	资深工程师	中级工程师	任何开发者
配额限制	无	中等	严格

结语

Anthropic 发布的三个 Agent 产品，不是让你三选一，而是提供了一套完整的工具箱：

SDK 是手术刀——精确、强大，但需要高超技艺
Teams 是协作平台——适合团队作战的长周期项目
Managed 是自动化工具——简单任务的首选

明智的开发者会根据场景混搭使用：核心业务用 SDK 保证控制力，跨平台任务用并行子 Agent 提升效率，长周期项目用 Teams 便于协作，日常杂事用 Managed 节省精力。

记住：架构没有银弹，只有取舍。选择最适合你当前场景的方案，而不是最酷的方案。

本文基于实际项目经验总结，欢迎交流讨论。

Sora 退场，Seedance 进场

2026-04-03T07:45:35+00:00

摘要：2026 年初，OpenAI 宣布暂停 Sora 的公开服务，而字节跳动旗下的 Seedance 2.0 却正式开启企业级公测。这一”一退一进”的背后，折射出中美两国在 AI 视频生成领域的不同战略选择。本文从技术瓶颈与成本、版权合规、地缘竞争三个维度，深度剖析两种商业化路径的底层逻辑。

引言：冰火两重天的 2026

2026 年 3 月，AI 视频生成赛道上演了一幕颇具戏剧性的”换角戏”。

一边是曾被寄予厚望的 OpenAI Sora 悄然宣布”暂停服务”，官方声明中仅以”技术迭代与安全检查”为由，未透露复出时间表。另一边，字节跳动旗下的 Seedance 2.0 在武汉高调宣布开启企业级公测，火山引擎”2026 Force Link AI 创新巡展”现场人头攒动，API 申请通道瞬间涌入数千家企业认证主体。

这一”一退一进”，绝非偶然。它背后折射出的是中美两国在 AI 视频生成领域的不同战略判断、不同合规路径，以及不同商业化节奏。

本文将从三个核心维度展开分析：大模型视频能力的技术瓶颈与成本结构、版权与肖像权的合规策略、中美科技竞争背景下的产业博弈。

一、技术瓶颈与成本：理想很丰满，现实很骨感

1.1 视频生成的”算力黑洞”

AI 视频生成被业内戏称为”算力黑洞”。与文本生成（LLM）和图像生成（Diffusion）不同，视频生成需要同时处理时间维度的一致性和空间维度的细节，这对算力提出了指数级增长的需求。

根据公开数据，生成一段60 秒 1080p 的视频，Sora 需要消耗约12,000 个 A100 GPU 小时的算力资源。即使按批发价计算，单次生成的算力成本也高达30-50 美元。这还不包括模型训练、推理优化、存储带宽等隐性成本。

Seedance 2.0 的定价策略则更为”务实”。根据火山引擎公布的公测政策，企业用户生成一段2 分钟科幻短片的成本约为330 元人民币（约 45 美元）。看似与 Sora 相近，但 Seedance 提供了分层计费和并发优化机制：

计费维度	Sora（暂停前）	Seedance 2.0
基础生成	按秒计费，无折扣	按 Token 计费，量大从优
并发限制	单账户 5 并发	企业认证 10 并发，可扩容
定制功能	不开放	需 100 万保证金 + 保底协议
退款机制	无	保证金期满可返还

这种差异反映了两种不同的成本转嫁策略：Sora 试图通过统一高价覆盖所有用户，而 Seedance 则通过”保证金 + 分层”将成本压力转移给有支付能力的企业客户。

1.2 技术瓶颈的”天花板效应”

2025 年下半年，多家 AI 实验室内部评估报告显示，当前视频生成模型在以下方面遭遇瓶颈：

长视频一致性：超过 3 分钟的视频，角色面部特征漂移率超过 15%
物理规律模拟：复杂流体力学、光影反射等场景仍有明显瑕疵
多镜头叙事：场景切换时的连贯性不足，需要人工后期修补

OpenAI 内部人士透露，Sora 暂停服务的核心原因之一是技术迭代遇到瓶颈。在达到”工业可用”标准之前，继续开放服务只会消耗大量算力却无法产生商业回报。

反观字节跳动，其策略更为”渐进式”。Seedance 2.0 明确限制视频时长（公测版单段不超过 5 分钟），并禁用真人人脸生成，从而规避了最耗算力和最易引发争议的场景。这种”先做减法，再做加法”的策略，使得 Seedance 能够在可控成本下实现商业化闭环。

二、版权问题：中美不同的合规”护城河”

2.1 美国的”诉讼驱动”模式

Sora 的暂停，版权诉讼是重要诱因之一。

2025 年 12 月，好莱坞编剧工会（WGA）与美国演员工会（SAG-AFTRA）联合发起集体诉讼，指控 Sora 在训练过程中使用了未经授权的影视作品片段。诉讼文件显示，OpenAI 无法提供完整的训练数据来源清单，这成为其”致命软肋”。

此外，多位知名导演（包括诺兰、卡梅隆等）公开表态，认为 AI 生成视频”侵犯了人类创作者的署名权与改编权”。在法律压力与舆论压力的双重夹击下，OpenAI 选择了”以退为进”。

2.2 中国的”预审 + 水印”模式

相比之下，Seedance 2.0 的合规策略更为”前置化”：

训练数据白名单：字节跳动宣布其训练数据全部来自”已授权内容库”，包括抖音、西瓜视频、即梦平台等自有生态，以及与部分影视公司的合作协议。
C2PA 水印技术：所有生成视频自动嵌入不可见数字水印，可追溯生成时间、生成主体、使用模型版本等信息。这符合欧盟《AI 法案》的透明度要求，也为未来可能的版权纠纷提供证据链。
真人肖像”双锁”机制：公测版默认禁用真人人脸生成。企业如需解锁，需缴纳100 万元保证金并签署《肖像权合规承诺书》，一旦违规，保证金全额扣除并承担法律责任。

这种”预审 + 水印 + 保证金”的三重机制，实质上是将合规成本内部化，让企业用户成为版权保护的”第一责任人”。

2.3 合规成本的”隐性门槛”

值得注意的是，Seedance 的合规策略虽然降低了法律风险，但也抬高了市场准入门槛。

100 万元保证金对于大型影视公司而言可能只是”九牛一毛”，但对于中小微内容创作者、独立工作室而言，却是难以逾越的门槛。这导致 Seedance 的公测用户结构呈现明显的”头部集中”特征——目前通过企业认证的客户中，超过 60% 为注册资本超过 1000 万元的企业。

这种策略的长期影响尚待观察：它可能促进内容产业的”集约化”，也可能抑制创新生态的”多样性”。

三、中美竞争：AI 视频赛道的”地缘博弈”

3.1 技术封锁与”去美化”供应链

2025 年以来，美国对华 AI 芯片出口管制持续收紧。NVIDIA A100/H100 等高端 GPU 的对华出口基本冻结，这直接影响了中国 AI 企业的训练效率与推理成本。

在此背景下，Seedance 2.0 选择了一条”差异化竞争”路线：

模型架构优化：采用华为昇腾 910B 等国产芯片进行推理加速，降低对 NVIDIA 生态的依赖。
应用场景聚焦：优先落地于短视频、电商营销、教育培训等”轻量级”场景，而非好莱坞级别的”重工业”制作。
市场区域选择：国际推广首选东南亚、拉美等”非敏感”市场，暂时避开欧美监管高压区。

3.2 数据生态的”护城河效应”

字节跳动的核心优势在于其庞大的内容生态。抖音、今日头条、西瓜视频等平台每天产生数亿条视频内容，这为 Seedance 提供了得天独厚的训练数据与应用场景。

相比之下，OpenAI 的数据来源更为”分散”。虽然其拥有 GPT 系列模型的文本数据优势，但在视频领域的”原生数据”积累远不如字节跳动。这也是 Sora 在”多镜头叙事一致性”上表现不如 Seedance 的原因之一。

3.3 商业化节奏的”战略耐心”

OpenAI 作为私营公司，面临来自微软等投资方的盈利压力。Sora 的高成本与低回报，使其在商业上难以持续。暂停服务，某种程度上是”止损”的理性选择。

字节跳动则展现出更强的”战略耐心”。Seedance 2.0 的公测政策明确表示，2026 年内不以盈利为目标，而是以”生态培育”和”场景验证”为核心。这种”先占市场，再谈盈利”的策略，与中国互联网行业的传统打法一脉相承。

四、结论与展望：谁能笑到最后？

Sora 的退场与 Seedance 的进场，并非简单的”胜负之分”，而是两种不同发展阶段、不同市场环境、不同战略选择的体现。

4.1 短期判断（2026-2027）

Seedance 将占据中国市场主导地位，尤其在短视频、电商、教育等垂直场景。
Sora 可能在 2027 年以”企业版”形式回归，但定价将大幅提高，面向高端影视制作市场。
开源模型将填补中低端市场空白，如 Stability AI 的 Stable Video、Meta 的 Movie Gen 等。

4.2 长期展望（2028 及以后）

技术融合：文本、图像、视频、音频的”多模态一体化”将成为标配，单一模态模型将被淘汰。
监管趋同：中美欧三方将在 AI 版权、水印、溯源等方面形成”最低共识”，跨境合规成本下降。
成本下降：随着芯片效率提升与模型优化，视频生成成本有望下降1-2 个数量级，个人创作者将成为主力用户。

4.3 给从业者的建议

不要押注单一模型：多模型冗余部署，降低供应链风险。
关注合规前置：版权、肖像、水印等合规成本应纳入预算。
深耕垂直场景：通用视频生成竞争惨烈，垂直场景（如医疗、法律、工业）仍有蓝海。

结语

AI 视频生成的”黄金时代”才刚刚开始。Sora 的退场不是终点，Seedance 的进场也不是终点。真正的赢家，将是那些能够平衡技术、成本、合规三者关系的玩家。

对于内容创作者而言，这是一个最好的时代——工具从未如此强大；这也是一个最坏的时代——规则从未如此复杂。

唯有拥抱变化者，方能立于不败之地。

Harness 设计

2026-03-31T08:28:18+00:00

Harness 设计：构建长时间运行的应用程序开发框架

本文是阅读 Harness 框架这篇文章后，做的一些简单的摘要总结，再配合着最近泄漏的 claud code 源码，Anthropics 真是给广大开发者送福利了。

过去几个月里，我们一直在研究两个相互关联的问题：如何让 Claude 产出高质量的前端设计，以及如何让它在无需人工干预的情况下构建完整的应用程序。这项工作源于我们早期在前端设计技能和长时运行编码 Agent 框架上的努力。通过提示词工程和框架（Harness）设计，我们能够将 Claude 的性能提升到远超基准线的水平，但这两者最终都遇到了瓶颈。

为了突破瓶颈，我们寻求了一种新颖的 AI 工程方法，该方法横跨了两个完全不同的领域：一个由主观审美定义，另一个由可验证的正确性和可用性定义。受生成对抗网络（GANs）的启发，我们设计了一个由 生成器(Generator) 和 评估器(Evaluator) Agent 组成的多智能体结构。构建一个能够可靠且具备审美能力地对输出进行评分的评估器，意味着首先要开发一套标准，将诸如“这个设计好吗？”之类的主观判断转化为具体的、可量化的术语。随后，我们将这些技术应用到了长时运行的自主编码中，并借鉴了早期框架工作的两个教训：将构建任务分解为可处理的代码块，以及使用结构化的“成品”在不同 Session 之间传递上下文。最终结果是一个三智能体架构——计划者（Planner）、生成器（Generator）和评估器（Evaluator）——它能在长达数小时的自主编码 Session 中构建出功能丰富、视觉精美的全栈应用。

“框架（Harness）的设计对长时运行的 Agent 编码有效性有着实质性影响。”

为什么 Agent 的实现会失败？

我们之前已经证明，Harness 的设计对长时运行 Agent 编码的有效性有着实质性影响。在早期的实验中，我们使用一个初始 Agent 将产品规格书分解为任务列表，再由一个编码 Agent 逐一实现功能，最后通过转移成品来跨 Session 携带状态。开发者社区也得出了类似的见解，例如使用钩子或脚本让 Agent 处于持续迭代循环中的方法。

但一些核心问题依然存在。对于更复杂的任务，Agent 随着时间的推移仍容易“跑偏”。在分析这个问题时，我们观察到了两种常见的失败模式。

1. 连贯性丢失与“上下文焦虑”

首先是模型在长任务中往往会丧失连贯性。随着上下文窗口被填满，一些模型还会表现出“上下文焦虑”——当它们认为接近上下文限制时，会过早地试图收尾工作。上下文重置（Context Resets）——即完全清空上下文窗口并启动一个全新的 Agent，配合携带前序状态和后续计划的结构化移交——可以同时解决这两个问题。

这与单纯的“压缩”（Compaction）不同。压缩保留了连贯性，但没有提供“干净的底板”，这意味着上下文焦虑依然可能存在。重置则提供了一个干净的起点，代价是移交制品必须包含足够的信息，以便下一个 Agent 能够无缝接手。

2. 自我评价的盲目性

第二个问题是自我评价。当被要求评价自己产出的工作时，Agent 往往会自信地赞美自己——即使在人类观察者看来，质量明显平庸。这在设计等主观任务中尤为严重，因为这里不存在像软件测试那样的二进制校验。

将“干活的 Agent”与“评价的 Agent”分开，是解决这一问题的强力杠杆。这种分离本身并不能立即消除各种宽容；评估器依然是一个倾向于对 LLM 生成内容表现慷慨的大模型。但将一个独立的评估器调校得“挑剔且多疑”，要比让一个生成器批判自己的工作容易得多。一旦这种外部反馈存在，生成器就有了一个具体的迭代目标。

前端设计：让主观质量变得可量化

我们首先在前端设计上做了实验，因为自我评价问题在这里最为明显。如果没有干预，Claude 通常会倾向于安全、可预测的布局，这些布局在技术上可行，但在视觉上平庸。

我为前端设计编写了四个评估标准：

设计质量：设计是否感觉是一个连贯的整体而非零件的堆砌？色彩、排版、布局、意向等细节是否结合并创造了独特的氛围和身份？
原创性：是否有自定义决策的证据？人类设计师应该能识别出刻意的创意选择。
精致性：技术执行力，包括层级、间距一致性、色彩和谐度、对比度。
功能性：独立于审美的可用性。

我们特别强调了设计质量和原创性，因为 Claude 本身在工艺和功能性上的得分通常很高。标准中明确惩罚了高度通用的“AI 垃圾（AI slop）”模式，迫使模型在审美上进行更多冒险。

扩展到全栈编码：三智能体协作

基于这些发现，我将这种受 GAN 启发的模式应用到了全栈开发中。系统包含以下三种角色：

计划者 (Planner)：将模糊的指令（1-4 句话）扩展为完整的产品规格（Spec）。它专注于产品背景和高层技术设计，而不是详细的实现细节。
生成器 (Generator)：采用“冲刺（Sprint）”模式，每次只根据 Spec 开发一个特定功能。它还拥有 Git 权限用于版本控制。
评估器 (Evaluator)：这是核心。它使用 Playwright MCP 像真实用户一样点击运行中的应用，测试 UI、API 端点和数据库状态。如果任何一项标准低于阈值，冲刺即宣告失败，生成器会收到详细的 Bug 反馈。

在每次执行前，生成器和评估器会协商一份 冲刺合约 ：在写代码前双方便达成共识，确定“完成”的定义。

实验：从 20 分钟到 6 小时的质变

我们让模型尝试创建一个“2D 复古游戏制作工具”。

框架	运行时间	总成本	结果质量
单模型 (Solo)	20 分钟	$9	布局浪费空间，流程死板，且游戏引擎库是坏的。
全套 Harness	6 小时	$200	极其精美，功能包含精灵编辑、动画系统、AI 辅助设计。最重要的是，真的可以玩。

这种差异是立竿见影的。全套 Harness 构建的应用具备了一致的视觉特征和极高的完成度。评估器通过 Playwright 进行了极其细致的测试，例如：“矩形填充工具在鼠标抬起时未能触发”、“FastAPI 路由冲突”等细微 Bug 均被捕捉并修复。

简单化与未来演进

随着 Claude Opus 4.6 等更强模型的推出，我们可以开始精简框架。每增加一层复杂度，其实都是对模型“在这个环节做不到”的假设。当模型变强，这些假设就会过期。

例如，Opus 4.6 已经可以原生处理长时间的连贯任务，不再需要强行切碎成多个子任务。但我们依然保留了计划者和评估器，因为它们能提供核心的价值提升。

结语：工具的终极意义

随着模型能力的提升，有趣的设计空间并不会因为模型变强而消失，而是向更高阶的自动化迈进。AI 工程师的挑战在于通过不断寻找新的组合，利用 Harness 突破模型本身的能力边界。

正如我们所看到的，它不是在替你写代码，它是在帮你构建属于你自己的生产力引擎。

OpenClaw 效率提升实战

2026-03-28T07:37:12+00:00

告别繁琐：我是如何利用 OpenClaw 打造个人博客发布“自动驾驶”系统的

在数字化写作的今天，博客发布依然是许多创作者的重要阵地。今天，我想深入分享一下我是如何利用 OpenClaw 彻底重构我的博客发布流程，将原本需要一整天的开发调试工作，压缩到寥寥数次对话即可搞定的全过程。

一、提出问题：那些被浪费在“发布”上的时间

我刚开始写博客的时候，发布流程可以用“支离破碎”来形容。我比较喜欢 Obsidian 工具来作为我的写作工具，我的博客时基于 GitHub + Jekyll 的静态博客系统，但每次从写作的灵感形成文章，并且到 GitHub 上的正式上线，都要经历一段极其乏味的“手工折磨”：

元数据（Frontmatter）的格式地狱：

Jekyll 博客需要严格的 YAML 头信息，包括 title, date, layout 等。在 Obsidian 里，我更习惯随心所欲地组织内容，这意味着每次发布前，我得手动计算当前的 ISO 时间戳，核对文件名格式，稍有不慎，博客引擎就会因为解析错误而拒绝编译。

图片附件的搬运工：

这是流程中最耗时的部分。Obsidian 的图片通常保存在专门的附件文件夹中。发布时，我必须：

手动找到这些图片。
复制到博客项目的 images 文件夹。
在 Markdown 里将相对路径（或是 Wikilinks 格式）手动修改为博客项目的路径（如 /images/my_photo.png）。
如果遇到同名图片，还得小心翼翼地重命名并更新所有引用。

版本控制的重复劳动：

最后，我得切换到终端，输入那套已经滚瓜烂熟却毫无生趣的命令：git add ., git commit -m "update", git push。如果遇到远程仓库有更新，还得处理冲突。

之前我都是通过写过 Shell 脚本来做这些枯燥的发布工作，但脚本的维护成本极高：路径配置、异常处理、逻辑扩展……每当我想增加一个小功能时，都得面对那一坨凌乱的代码重新调试。有时候发布一篇文章的心理负担，甚至盖过了写作本身的乐趣。

二、重点介绍：OpenClaw + Obsidian 的配置全过程

这就是本文的核心所在。我整个过程一行 shell 脚本都没写。而是在带娃去游乐场用手机做出来的过程。下面就介绍下如何通过 OpenClaw 的 Skill-Creator 打造了一个名为 blog-publisher 的智能技能。

1. 技能构思：描述即开发

在 OpenClaw 中，我不需要编写繁琐的逻辑判断。我只需要以人类的语言告诉它：

“创建一个叫 blog-publisher 的技能。它需要能自动搜寻 Obsidian 里的文章，处理图片迁移，自动生成 Frontmatter，最后执行 Git 提交并推送到 nas 分支。如果推送失败，要自动执行强制推送。”

这种“描述即开发”的模式，直接跳过了传统编程中的语法纠结，让我能专注于业务逻辑本身。

2. 核心逻辑配置：多技能联动

我的 blog-publisher 技能并不是孤立存在的，它巧妙地调用了 OpenClaw 已有的生态：

Obsidian 联动：利用 obsidian-official-cli 技能，通过命令行与我的笔记库直接对话，实现毫秒级的文章检索。
环境韧性：我为技能配置了严格的 git pull 预处理。这意味着无论我在哪台设备上工作，OpenClaw 都能保证我面对的是最新的代码。

3. 细节配置：脚本化注入

为了追求极致的稳定性，我让 OpenClaw 为该技能生成了一个 Python 核心脚本 publish.py。这个脚本专门负责最棘手的图片处理逻辑：

正则扫描：自动识别 Markdown 中的 ![]() 和 [[]] 格式引用。
冲突检测：如果目标 images 文件夹已存在同名图片，脚本会自动采用 MD5 或计数器方案重命名，并反向更新 Markdown 中的链接。
路径重写：统一将路径前缀修正为 /images/。

4. 严格规范：执行命令的“洁癖”

在配置过程中，我利用 OpenClaw 对技能进行了微调，强制要求所有的 Git 提交必须经过我的审查确认，这种严格的规范确保了博客仓库提交记录的整洁，避免了 AI 生成随机提交信息的混乱。

三、使用感受：效率的“降维打击”

回顾今天使用 OpenClaw 的整个过程，最让我震撼的是其带来的生产力释放。

1. 从“天”到“分钟”的飞跃

以往如果要从零开发这样一套完整的、具备健壮图片处理和异常重试逻辑的发布系统，即使是资深开发者，从编写核心代码、处理各种特殊字符路径的 Corner Case，到最终在服务器上稳定运行，起码需要投入一整天的时间和精力。

但在 OpenClaw 中，我仅仅花费了不到一百个提示词（Prompt）进行沟通和微调，它就完美地生成了文档、脚本并完成了打包。这种效率提升不是百分之几，而是量级（Order of Magnitude）的跨越。

2. 真人案例：游乐场里的“自动驾驶”发布

最不可思议的场景发生在今天下午：我正带着孩子在游乐场玩耍，坐在喧闹的长椅上休息。就在这时，我通过手机端的 Telegram 客户端，像聊天一样给 OpenClaw 发送了指令：“把 OpenClaw 效率提升实战这篇文章发布。”

几秒钟后，OpenClaw 向我反馈：

✅ Obsidian 同步完成。
✅ 找到文章并生成 Frontmatter。
✅ 自动处理了文中的 Mermaid 图表。
✅ 脚本成功将更改推送到 nas 分支。

整个过程，我手机的亮屏时间不到一分钟，而背后却完成了一系列复杂的开发运维动作。文章现在已静静地躺在我的 GitHub 博客仓库中，等待着全球读者的访问。

四、结语：工具的终极意义

OpenClaw 给我带来的不仅仅是时间上的节省，更是一种“掌控感”。它消除了技术琐碎带来的焦虑，让我能重新回到创作的本质。如果你也觉得自己的工作流中有太多繁琐的手工环节，不妨尝试把它们交给 OpenClaw。它不是在替你写代码，它是在帮你构建属于你自己的生产力引擎。

如何用 Metal 做视频帧合流渲染

2024-10-01T02:00:19+00:00

背景

最近在做远程控制的功能，使用的技术方案是远程控制的鼠标数据流和桌面画面视频流分开传输。这样观看端就需要把鼠标的画面和桌面的画面进行合并渲染。如果在数据层面做利用 FFmpeg 框架就可以实现两路视频流的合并。这个可能在直播场景比较适合，由于视频会议对实时性要就比较高，用户在远程控制时，延时忍受度较低，所以为了体验就采用了客户端端在渲染时，来合并两路流进行显示。

这里就引申到本文讨论的话题了，在 iOS 平台用 Metal 如何来渲染两路视频流到一个视图上？

1. Metal 是如何渲染图形的

首先我们先看下图形如何通过GPU显示出来的。下面是一个简单的示意图。渲染过程通过 CPU 给 GPU 发送相应的渲染指令，然后把数据拷贝到 GPU 中，用 GPU 渲染上屏。从上图的过程可以看出，图形渲染的过程 CPU 负责组装指令，而 GPU 负责上屏渲染这个过程。那Metal 其实就是封装了 GPU 图形化的接口，方便开发者调用 GPU 的能力。整个渲染过程和大多数图形框架 OpenGL Vulkan 基本相似，我们来看下这个流程。

代码上配置的 GPU 指令，这个配置过程是在 CPU 中执行的，有兴趣可以看下官方文档。下图是 Metal 框架中可以配置的命令的种类。上图中位块命令编码器（Blit Command Encode）是用于处理数据传输和图像处理的操作。它允许开发者高效地在 GPU 上执行内存拷贝、图像缩放、图像转换等任务。计算命令编码器(Compute Command Encoder)用于编码在 GPU 上执行计算内核的命令。可以执行通用计算，例如图像处理、机器学习或任何并行化的任务。而我们做图形渲染主要关心的是渲染编码器(Render Command Encoder)如何使用的，渲染编码器需要配置的有顶点坐标数据、纹理数据、采样信息、深度信息然后发送到 GPU中，从此图中也可以看出来，除了图形处理外，同时 Metal 还可以做机器学习相关的计算。
下面看下渲染指令的配置过程，下图就描述了一个渲染指令的创建过程其中可以看到 Vertex Function 和 Fragment Function 就是 GPU 可以被编程的核心，通过注入顶点和片段着色器就可以利用 GPU 自定义渲染的逻辑。Metal 会把这些指令编译优化后，配置到 GPU中。
最后就开始执行 Metal 的渲染，下图就是渲染出最终图形这个过程中 GPU 需要执行的各个阶段，也就是我们常说的渲染管道 PipLine。渲染管道的流程就是从上面我们配置的数据和自定义的渲染逻辑，然后计算出相应位置的像素点位信息，经过深度和模版测试(本质上就是对深度信息、透明度、以及叠加视图进行裁剪和融合操作)，渲染到缓冲区，最终根据屏幕的刷新率渲染上屏。

上述就是 Metal 渲染 Pipline 的基本描述，有兴趣可以下载官方示例代码。从上面的配置过程可以看出，开发 Metal 渲染要做的两件事情，在 CPU 中配置渲染的 GPU 指令，通过框架提供的可编程PipLine，编写自定义的 Shader 给 GPU，执行定制化的渲染。

2. WebRTC 的渲染架构

在我们开始写视频合流的逻辑时，先来看下我们音视频会议用的 WebRTC 框架，是如何使用 Metal 来渲染的？下图是 WebRTC Metal 渲染的类图。从上图看还是比较简单的，获取解码后的视频数据帧，传递给 RTCMTLVideoView 后，RTCMTLVideoView 通过 DisplayLink 定时器指定渲染帧率，然后根据视频帧的不同颜色格式，分发给不同的 Render 渲染器执行渲染。

然后我们鼠标合流的过程可以用下面的流程图描述下。

流程图中鼠标渲染的逻辑也很简单，在渲染视频帧的时候，发现相应时间点有鼠标帧过来时，就通过 Metal 合流的方式渲染上屏。下面我们就详细来看下 Metal 渲染上屏的代码。

3. Metal 渲染示例代码

3.1 渲染管道配置

开发 Metal 渲染的代码，先看下 CPU 如何配置渲染管道这个过程，下面是一个示例代码。

- (nonnull instancetype)initWithMetalKitView:(nonnull MTKView *)mtkView
{
    self = [super init];
    if(self)
    {
        _device = mtkView.device;

        NSURL *imageFileLocation = [[NSBundle mainBundle] URLForResource:@"background"
                                                           withExtension:@"tga"];
        
        _texture = [self loadTextureUsingAAPLImage: imageFileLocation];

        // Set up a simple MTLBuffer with vertices which include texture coordinates
        static const AAPLVertex quadVertices[] =
        {
            // Pixel positions, Texture coordinates
            { {  250,  -250 },  { 1.f, 1.f } },
            { { -250,  -250 },  { 0.f, 1.f } },
            { { -250,   250 },  { 0.f, 0.f } },

            { {  250,  -250 },  { 1.f, 1.f } },
            { { -250,   250 },  { 0.f, 0.f } },
            { {  250,   250 },  { 1.f, 0.f } },
        };

        // Create a vertex buffer, and initialize it with the quadVertices array
        _vertices = [_device newBufferWithBytes:quadVertices
                                         length:sizeof(quadVertices)
                                        options:MTLResourceStorageModeShared];

        // Calculate the number of vertices by dividing the byte length by the size of each vertex
        _numVertices = 6;

        /// Create the render pipeline.
        // Load the shaders from the default library
        id<MTLLibrary> defaultLibrary = [_device newDefaultLibrary];
        id<MTLFunction> vertexFunction = [defaultLibrary newFunctionWithName:@"vertexShader"];
        id<MTLFunction> fragmentFunction = [defaultLibrary newFunctionWithName:@"samplingShader"];

        // Set up a descriptor for creating a pipeline state object
        MTLRenderPipelineDescriptor *pipelineStateDescriptor = [[MTLRenderPipelineDescriptor alloc] init];
        pipelineStateDescriptor.label = @"Texturing Pipeline";
        pipelineStateDescriptor.vertexFunction = vertexFunction;
        pipelineStateDescriptor.fragmentFunction = fragmentFunction;
        pipelineStateDescriptor.colorAttachments[0].pixelFormat = mtkView.colorPixelFormat;

        NSError *error = NULL;
        _pipelineState = [_device newRenderPipelineStateWithDescriptor:pipelineStateDescriptor
                                                                 error:&error];

        NSAssert(_pipelineState, @"Failed to create pipeline state: %@", error);

        _commandQueue = [_device newCommandQueue];
    }

    return self;
}

通过上面的代码可以看出，主要是在配置顶点向量和着色器函数。我们画如下的图来看下顶点坐标是如何定义的。可以看出来中心点是 (0,0) 。因为我们视频帧只用了 2D 坐标，如果 3D 坐标的话，坐标系如下。 Metal 渲染使用的是左手坐标系，如果是OpenGL右手坐标系，Z 轴就是反向的，个人感觉左手更符合人的直觉。

这里我们要注意的配置渲染顶点坐标的类型，用的 MTLPrimitiveTypeTriangle。MTLPrimitiveTypeTriangleStrip 和 MTLPrimitiveTypeTriangle 是 Metal 框架中用于指定图形渲染顶点数据类型的枚举值。它们之间的主要区别在于如何处理顶点数据以形成三角形。

MTLPrimitiveTypeTriangle 这种类型表示独立的三角形。在绘制时，每三个顶点组成一个三角形。因此如果你有 N 个三角形，你需要提供 3 * N 个顶点。每个三角形的顶点之间没有共享，所有的三角形都是独立的。
MTLPrimitiveTypeTriangle，这种类型表示对三角形顶点做适当裁剪。在绘制时，第一个三角形由前两个顶点和第三个顶点组成，之后的每个新顶点都会与前两个顶点一起形成一个新的三角形。这样绘制 N 个三角形只需要 N + 2 个顶点，效率更高，因为可以减少顶点数据的传输。

MTLPrimitiveTypeTriangle 用于独立三角形，而 MTLPrimitiveTypeTriangleStrip 用于通过共享顶点来高效地绘制一系列相连的三角形。选择哪种类型取决于你的具体需求和数据结构。下面的这个顶点坐标类型就是完整的三角形模式，后面可以看到我们实际项目中用的是 MTLPrimitiveTypeTriangleStrip ，因为视频帧是 2D 平面比较简单，可以用4个顶点代表一个正方形。

3.2 渲染命令提交

提交渲染命令给 GPU 的的过程中。看下面的示例代码。

- (void)drawInMTKView:(nonnull MTKView *)view
{
    // Create a new command buffer for each render pass to the current drawable
    id<MTLCommandBuffer> commandBuffer = [_commandQueue commandBuffer];
    commandBuffer.label = @"MyCommand";

    // Obtain a renderPassDescriptor generated from the view's drawable textures
    MTLRenderPassDescriptor *renderPassDescriptor = view.currentRenderPassDescriptor;

    if(renderPassDescriptor != nil)
    {
        _viewportSize.x = view.bounds.size.width;
        _viewportSize.y = view.bounds.size.height;
        id<MTLRenderCommandEncoder> renderEncoder =
        [commandBuffer renderCommandEncoderWithDescriptor:renderPassDescriptor];
        renderEncoder.label = @"MyRenderEncoder";

        // Set the region of the drawable to draw into.
        [renderEncoder setViewport:(MTLViewport){0.0, 0.0, _viewportSize.x, _viewportSize.y, -1.0, 1.0 }];

        [renderEncoder setRenderPipelineState:_pipelineState];

        [renderEncoder setVertexBuffer:_vertices
                                offset:0
                              atIndex:0];

        [renderEncoder setVertexBytes:&_viewportSize
                               length:sizeof(_viewportSize)
                              atIndex:AAPLVertexInputIndexViewportSize];

        // Set the texture object.  The AAPLTextureIndexBaseColor enum value corresponds
        ///  to the 'colorMap' argument in the 'samplingShader' function because its
        //   texture attribute qualifier also uses AAPLTextureIndexBaseColor for its index.
        [renderEncoder setFragmentTexture:_texture];

        // Draw the triangles.
        [renderEncoder drawPrimitives:MTLPrimitiveTypeTriangle
                          vertexStart:0
                          vertexCount:6];

        [renderEncoder endEncoding];

        // Schedule a present once the framebuffer is complete using the current drawable
        [commandBuffer presentDrawable:view.currentDrawable];
    }

    // Finalize rendering here & push the command buffer to the GPU
    [commandBuffer commit];
}

[renderEncoder drawPrimitives:MTLPrimitiveTypeTriangle vertexStart:0 vertexCount:_numVertices];这里就可以看到我们提交给 GPU 的顶点向量的类型为 MTLPrimitiveTypeTriangle ，所以正方形的话需要2个三角形来表示。这里还有个注意点，我们顶点向量传递的是实际像素的话，需要额外传递下 _viewportSize ，因为我们之后片段着色器用到的顶点位置其实都是相对位置，不是实际的像素位置，主要是为了方便纹理贴图时，计算纹理位置。之后我们也会讲到。

3.3 数据传递

内存数据传输，例如 [texture replaceRegion:region mipmapLevel:0 withBytes:image.data.bytes bytesPerRow:bytesPerRow]; 给片段着色器传递数据，本质上就是 CPU 把内存的数据给 GPU 的内存。这里要注意颜色格式问题，一定要约定好像素的格式，MTLPixelFormatBGRA8Unorm 表示的32位的纹理数据。不然数据拷贝的时候会因为格式问题导致拷贝的数据 GPU 无法处理。

- (id<MTLTexture>)loadTextureUsingAAPLImage: (NSURL *) url {
    
    AAPLImage * image = [[AAPLImage alloc] initWithTGAFileAtLocation:url];
    NSAssert(image, @"Failed to create the image from %@", url.absoluteString);
    MTLTextureDescriptor *textureDescriptor = [[MTLTextureDescriptor alloc] init];
    // Indicate that each pixel has a blue, green, red, and alpha channel, where each channel is
    // an 8-bit unsigned normalized value (i.e. 0 maps to 0.0 and 255 maps to 1.0)
    textureDescriptor.pixelFormat = MTLPixelFormatBGRA8Unorm;
    
    // Set the pixel dimensions of the texture
    textureDescriptor.width = image.width;
    textureDescriptor.height = image.height;
    
    // Create the texture from the device by using the descriptor
    id<MTLTexture> texture = [_device newTextureWithDescriptor:textureDescriptor];
    
    // Calculate the number of bytes per row in the image.
    NSUInteger bytesPerRow = 4 * image.width;
    
    MTLRegion region = {
        { 0, 0, 0 },                   // MTLOrigin
        {image.width, image.height, 1} // MTLSize
    };
    
    // Copy the bytes from the data object into the texture
    [texture replaceRegion:region
                mipmapLevel:0
                  withBytes:image.data.bytes
                bytesPerRow:bytesPerRow];
    return texture;
}

上面是纹理数据配置的代码，我们讲下纹理坐标位置，纹理本质就是贴图，因为图片都是2D的，所以一般都是用 float2 向量定义的。float2 这种变量是 SIMD （单指令多数据结构）代表的就是2维的平面向量(x,y)。下图就是纹理坐标的定义。纹理坐标都是用相对位置计算的，这样着色时方便和顶点向量位置进行计算，尤其涉及到缩放和位移时，相对位置的优势体现出来。

3.4 着色器的编写

下面就是顶点着色器和片段着色器代码编写了。

我们就可以看下顶点着色器如何工作了，下面是顶点着色器代码。

typedef struct {
      float2 position;
      float2 texcoord;
} Vertex;

typedef struct {
      float4 position[[position]];
      float2 texcoord;
} RasterizerData;

 vertex RasterizerData vertexPassthrough(const device Vertex * verticies[[buffer(0)]],
                                   unsigned int vid[[vertex_id]]) {
      RasterizerData out;
      const device Vertex &v = verticies[vid];

      // Get the viewport size and cast to float.
      float2 viewportSize = float2(*viewportSizePointer);

       // To convert from positions in pixel space to positions in clip-space,
       //  divide the pixel coordinates by half the size of the viewport.
       // Z is set to 0.0 and w to 1.0 because this is 2D sample.
      out.position = vector_float4(0.0, 0.0, 0.0, 1.0);
      out.position.xy = pixelSpacePosition / (viewportSize / 2.0);
      out.texcoord = v.texcoord;

      return out;
 }

先来看几个概念，float4 position [[position]]; 这个是属性限定的语法结构，顾名思义就是这个属性限定它的使用方式。position 代表就是从顶点向量中获取到的裁剪空间位置，用来输出裁剪空间的位置信息给片段着色器。如何理解裁剪空间位置，裁剪的过程其实就是把我们定义好的顶点向量构成三角形，然后根据传递的视图实际像素大小，进行像素插值裁剪，然后计算出相应的位置。例如下面这个顶点着色器函数 vertexPassthrough ，其中定义的变换输出的结构 Varyings out; 这个变量的值赋值是通过 const device Vertex &v = verticies[vid]; 而这里面的 vid 本质上就是实际屏幕的像素位置，比如你的屏幕是320 px，采样的时候就会从 0 到 320 计算三角形实际的位置，然后赋值给 out。这里也可以看到实际像素都做了相对位置的变换，方便之后使用。

顶点着色器的输出，就是片段着色器的输入。VertexIn in [[stage_in]]; 表示该变量是顶点着色器的输出，传入已经插值裁剪好的像素点位，给片段着色器使用，以便于给每个点位分配颜色值。

fragment float4
samplingShader(RasterizerData in [[stage_in]],
               texture2d<half> colorTexture [[ texture(0) ]])
{
    constexpr sampler textureSampler (mag_filter::linear,
                                      min_filter::linear);

    // Sample the texture to obtain a color
    const half4 colorSample = colorTexture.sample(textureSampler, in.textureCoordinate);

    float4 out = float4(colorSample);
    // return the color of the texture
    return out;
}

上面 texture2d colorTexture [[ texture(0) ]] 这个属性限定符的作用，从我们在管道中配置的片段着色器数据的索引，例如：``` [renderEncoder setFragmentBuffer:_kernelSizeBuffer offset:0 atIndex:0]; ``` 这个就是获取我们这个配置的纹理数据。然后读取纹理中颜色值渲染到相应的顶点坐标位置。至此整个渲染过程就完成了。

4. 视频流混合的过程

渲染的基本流程梳理完成后，那我们看下鼠标纹理数据如何渲染到视频上的，其中核心就是设置鼠标的顶点坐标和纹理数据，以及在 Shader 中融合鼠标纹理和视图画面的纹理。我们先看下 WebRTC 视频帧顶点向量的定义。

float values[16] = {
-coordX, -coordY, cropLeft, cropBottom,
coordX, -coordY, cropRight, cropBottom,
-coordX,  coordY, cropLeft, cropTop,
coordX,  coordY, cropRight, cropTop};

其中 coordX ，coordY 这些都是裁剪过的视频帧的坐标位置，在 WebRTC 中这些顶点向量都是用相对位置来表示。所以我们在设置鼠标的顶点位置时，也用相对位置如下：

- (BOOL)setupTexturesForMouseFrame:(nonnull RTCMouseCursorFrame *)incomingFrame {
  MTLTextureDescriptor *textureDescriptor = [MTLTextureDescriptor new];
    textureDescriptor.textureType = MTLTextureType2D;
    textureDescriptor.width = width;
    textureDescriptor.height = height;
    textureDescriptor.pixelFormat = MTLPixelFormatBGRA8Unorm;
    textureDescriptor.usage = MTLTextureUsageShaderRead;
    _cursorTexture = [_device newTextureWithDescriptor:texDescriptor];
    if (!_cursorTexture) {
      RTCLogError(@"[RND]MTLRender:%p Failed to create cursor texture", self);
      return NO;
    }
    // 纹理数据
    [_cursorTexture replaceRegion:MTLRegionMake2D(0, 0, width, height)
                      mipmapLevel:0
                        withBytes:[mouseFrameBuffer.rgbaData bytes]
                      bytesPerRow:mouseFrameBuffer.stride];
    
    // 顶点数据的相对位置
    float blendRect[4] = {left,top,right,bottom};
    memcpy((float *)_cursorBlendRectBuffer.contents, blendRect, sizeof(blendRect));
    return YES;
}

然后下面就是融合的片段着色器。

fragment half4 fragmentColorBlend(
        Varyings in[[stage_in]], texture2d<float, access::sample> textureY[[texture(0)]],
        texture2d<float, access::sample> textureCbCr[[texture(1)]],
        texture2d<float, access::sample> textureBlend[[texture(3)]],
        constant float4 &blendRect [[buffer(2)]], // (left, top, right, bottom)
        constant int &enableBlend [[buffer(3)]]) {
      constexpr sampler s(address::clamp_to_edge, filter::linear);
      constexpr sampler blendSampler(address::clamp_to_edge,
                                             filter::linear);
      float y;
      float2 uv;
      y = textureY.sample(s, in.texcoord).r;
      uv = textureCbCr.sample(s, in.texcoord).rg - float2(0.5, 0.5);

      float4 video = float4(y + 1.403 * uv.y, y - 0.344 * uv.x - 0.714 * uv.y, y + 1.770 * uv.x, 1.0);
      float4 out;
      if (enableBlend == 1 && in.texcoord.x >= blendRect.x && in.texcoord.x <= blendRect.z && in.texcoord.y >= blendRect.y && in.texcoord.y <= blendRect.w) {
        float factorW = blendRect.z - blendRect.x;
        float factorH = blendRect.w - blendRect.y;
        float2 blendTextureCoordinate = float2((in.texcoord.x - blendRect.x)/factorW,(in.texcoord.y - blendRect.y)/factorH);
        float4 blendResult = textureBlend.sample(blendSampler, blendTextureCoordinate);
        out = float4(mix(video.rgb, blendResult.rgb, blendResult.a), 1.0);
      } else {
        out = video;
      }
      return half4(out);
  }

融合的方法很简单。这里我们用了个取巧的方式，直接把鼠标的顶点相对位置存储到了片段着色器的 buffer 中。然后在片段着色器执行时，从 buffer 读取鼠标上下左右的顶点 blendRect，只要判断鼠标的顶点落入到了 blendRect 区域中。就从鼠标纹理中 textureBlend 获取相应的颜色值，通过向量运算返回融合的纹理数据。这里需要注意是纹理采样的数据都是2维的向量。但是片段着色器输出的是4维的向量分别表示 (r,g,b,a)，这个过程中要注意向量的定义，避免赋值造成的错误。

5. 总结

通过上面的分享基本可以了解用 Metal 如何把画面渲染上屏了。可以看到正是 Metal 框架的封装，才让我们很容易的利用 GPU 的资源渲染画面。虽然视频处理 Metal 渲染往往是 2D，但是了解其工作原理，对于我们做 3D 方面的渲染还是很有借鉴意义。当然如果要做 3D 渲染工作，其实还有很多复杂的工作要做，例如配置顶点向量的法线，光照以及纹理材质的深度的融合等等。这个过程往往会交给 3D 引擎来做，建模师只需要把模型配置好，加载模型后引擎来解析这些数据配置给 GPU。

VisionPro所需的SwiftUI

2024-03-02T02:00:19+00:00

1. 背景

在我们开发 Vision Pro 开发之前，先大致了解下 SwiftUI 框架是非常有必要的，不然很多系统的新特性苹果往往只会提供 SwiftUI 的演示代码，甚至有些 API 只能 SwiftUI 才能使用。所以想要更好的适配 Vision Pro 最好的方式是用 SwiftUI 进行开发。

SwitUI 几个特点相比大家都有所耳闻：声明式编程、数据驱动、自适应布局。我们来看下数据驱动的 UI 框架一个经典的公式。

这个公式就一目了然了，UI 的展示就是数据状态的一个函数映射，所有的数据驱动的 UI 框架都遵循这个原则。那么 SwiftUI 的框架又是什么样子的呢？下面针对 SwiftUI 几个重要特征的由来做个介绍，限于篇幅详情的学习可以参看官方文档

2. DSL语法

struct ContentView: View {
    
    var body: some View {
        Text("Hello world")
        Image(systemName: "shareplay")
        .foregroundColor(.white)
        .frame(width: 28,height: 28)
    }
}

对于熟悉 Swift 语言，但是初次接触 SwiftUI 的同学来说，上面的语法大概率会有下面的疑惑：“为啥 body 这个函数没有 return 任何变量？” 假如说我们把上面的这段代码，改为下面的形式，相信做过 iOS 开发的同学一眼都能看明白。

struct ContentView: View {
    
    var body: some View {
        let textView = Text("Hello world")
        let imageView = Image(systemName: "shareplay")
        .foregroundColor(.white)
        .frame(width: 28,height: 28)
        let container = View()
        container.addSubView(textView)
        container.addSubView(imageView)
        return container
    }
}

其实这种语法就是 SwifUI 描述视图布局的领域专用语言 (DSL)，在编译时就会把这种 DSL 转换成我们上面可以看懂的视图布局方式。DSL 的好处就是简化语法，只需要描述问题即可不用提供问题的解决过程，然后框架层会自动生成解决问题的繁琐代码。这看起来其实有点类似数据库的 SQL 语句，只要描述下我要解决的问题即可，大大节省了代码量，让代码可读性也变的更好。

那么就有下个疑问了，SwiftUI 这种 DSL 语法是如何构建的呢？答案是通过 ViewBuilder 构建出来的。要了解 ViewBuilder 这里我们就需要了解 Swift 语言标记语法了，何为标记语法？说白了就是可以帮我们在语法树中插入一段我们自定义的代码，方便我们简化代码的结构，我简单的用下面的图示表示。

其中图 1 就代表正常的语法树，而图 2 就代表我们自定义的语法树，标记语法就相当于给了我们一个能力，把语法树上的一个节点替换成我们自定义的语法树的内容。

public protocol View {

    /// The type of view representing the body of this view.
    ///
    /// When you create a custom view, Swift infers this type from your
    /// implementation of the required ``View/body-swift.property`` property.
    associatedtype Body : View

    /// The content and behavior of the view.
    ///
    /// When you implement a custom view, you must implement a computed
    /// `body` property to provide the content for your view. Return a view
    /// that's composed of built-in views that SwiftUI provides, plus other
    /// composite views that you've already defined:
    ///
    ///     struct MyView: View {
    ///         var body: some View {
    ///             Text("Hello, World!")
    ///         }
    ///     }
    ///
    /// For more information about composing views and a view hierarchy,
    /// see <doc:Declaring-a-Custom-View>.
    @ViewBuilder @MainActor var body: Self.Body { get }
}

上面这段代码就是 body 的声明，可以看出来这个函数传递的参数是一个 ViewBuilder 。然后 SwiftUI 通过 ViewBuilder 的能力重新构造语法树，从而把添加视图的过程给实现了。ViewBuilder 是通过 Swift 语言中 ResultBuilder 这个标记语法能力构建的，ResultBuilder 是 Swift 语言提供给开发者构建自定义 DSL 的能力。而 ResultBuilder 这个语法又是从 FunctionBuilder 延伸出来的，他们的演化历史简单的表述如下：

function builder --> result builder --> view builder

如果你想要详细了解苹果标记语法的能力，建议你观看 apple result builder 这个 WWDC 的视频会有详细的讲解，这里不再赘述。

通过上面的分析过程，我们其实可以归纳出，支持高阶函数的语言，本质上构建这种语法应该都不困难。在前端开发看来，SwiftUI 这种 DSL 是他们很早就具备的能力，例如 React 和 VUE 都有自己定义的 DSL。并且像 google 的跨平台框架 Flutter 也是用的声明式的标记语法实现的，还有最近华为的纯血鸿蒙系统，前端 UI 构建也采用了声明式的框架。可见声明式的 UI 框架还是非常受欢迎的。

3. 视图树

下面我们就来看下 SwiftUI 的视图树是如何通过上述的 DSL 构建的。

3.1 链式语法

我们来看一个简单的例子如下：

Text("Hello")
.padding()
.backgound(Color.blue)

我们再来看下这段代码，我们把链式调用的位置交换了下，代码如下：

Text("Hello") 
.background(Color.blue) 
.padding()

来看下两段代码运行的结果：左一就是第一段代码生成的视图，右一是第二段代码的视图。

为什么会不同呢？分析这个视图的构建过程，SwiftUI 的视图构建是一个递归的过程，根据视图树上面所有子视图的尺寸决定视图的大小，再根据链式调用自下而上的构建相应的视图，每个链式操作其实都会创建一个子视图，第一段代码的构建过程如下：可以看出来确定完视图大小后，会先放置 .backgound 这个子视图，然后再放置它的子视图 .padding 和 .color，最后的 .text 是属于 .padding 的子视图，所以自然背景色范围就比较广。下图就是第二段代码的构建过程。可以看出来是先构建了 .padding 这个子视图，然后再放置 .backgound 子视图，自然背景就被裁剪掉了。 每个链式调用本质上就是创建一个子视图，然后自下而上构建视图的 ，记住这个构建规则，对于你写 SwiftUI 的代码会有很大的帮助。那我们可以自定义链式语法的函数么？这就涉及到另一个概念「修饰器」，下面我们来看下。

3.2 修饰器 (ViewModifer)

修饰器相当于给视图增加了扩展能力。下面就是扩展视图背景的一个例子。

enum BGType:Int {
    case clear = 0
    case glass = 1
    case meterial = 2
    case pureColor = 3
}

extension View {
func dtBackgroundEffect(
        effectType:BGType = .clear
    ) -> some View {
        self.modifier(
            dtBackgroundEffectModifier(effectType: effectType)
        )
    }
}

private struct dtBackgroundEffectModifier: ViewModifier {
    var effectType:BGType = .clear
    func body(content: Content) -> some View {
        switch effectType {
        case .clear:
            content.background(.clear)
        case .glass:
            content
                .glassBackgroundEffect(displayMode: .always)
        case .meterial:
            content
                .background(.regularMaterial)
        case .pureColor:
            content
                .background(Color(uiColor: UIColor.dt_color(withHexString: "29231F")))
        }
    }
}

这段代码的 switch case 语法给修饰器创建了不同的视图，这样调用的地方就只要一行代码 Text("name").dtBackgroundEffect(effectType:effect) 就可以了，避免了写大量这种重复的代码，对于代码复用这种方式非常有用。不过看到这里你可能会有疑问，扩展视图能力类似下面这样的写法不是也可以么？

extension View {
func dtBackgroundEffect(
        effectType:BGType = .clear
    ) -> some View {
        var effectType:BGType = .clear
        switch effectType {
        case .clear:
            return self.background(.clear)
        case .glass:
            return self
                .glassBackgroundEffect(displayMode: .always)
        case .meterial:
            return self
                .background(.regularMaterial)
        case .pureColor:
            return self
                .background(Color(uiColor: UIColor.dt_color(withHexString: "29231F")))
        }
    }
}

这段代码初看没啥问题，但是编译的话就会报错 Function declares an opaque return type 'some View', but the return statements in its body do not have matching underlying types 。从编译报错里面可以明确看出，虽然返回的都是 some View 但是 Swift 语言对类型检测非常严格的，我们来看下 Background 定义。

@inlinable public func background<S>(_ style: S, ignoresSafeAreaEdges edges: Edge.Set = .all) -> some View where S : ShapeStyle

这里返回的 some view 类型会有一个传递的模版参数 S 的定义，如果模版类型不一致的话 Swift 就会认为他们类型本质上不一样的。如何来解决这个问题，其实我们只要增加 ViewBuilder 标记语法，用如下的方式就可以编译通过了。

extension View {
@ViewBuilder
func dtBackgroundEffect(
        effectType:BGType = .clear
    ) -> some View {
        var effectType:BGType = .clear
        switch effectType {
        case .clear:
            self.background(.clear)
        case .glass:
            self
                .glassBackgroundEffect(displayMode: .always)
        case .meterial:
            self
                .background(.regularMaterial)
        case .pureColor:
            self
                .background(Color(uiColor: UIColor.dt_color(withHexString: "29231F")))
        }
    }
}

这里就可以看出来 ViewBuilder 其实会重新组装我们的 View 成为一个确定的类型，就不会报错了。那么问题来了，ViewModifer 和用普通的 Extension Function 来扩展有什么大的区别呢？这里简单描述下用法的区别。

如果你代码重用的部分比较复杂，涉及到很多条件创建不同的 View，这时候就适合 ViewModifer ，因为在性能方面，ViewModifier它可以利用 SwiftUI 的优化机制，避免不必要的视图层次重建。而我们自定义的扩展就没这个能力了。
如果你定义的方法只用在特定的一个 View 上，不需要大量的重用，并且扩展相对比较简单，其实就没必要使用 ViewModifer。

像上面这种需要用 switch case 来创建各种不同的视图来修饰的话，就比较适合用 ViewModifer 了，视图树的构建方式讲到这里，那么数据如何驱动这些视图渲染呢？下面就开始分析下 SwiftUI 的状态管理。

4. 状态管理

我们先来看下面这段代码，SwiftUI 是如何映射数据状态到视图树上面的?

@state var showChinese = false
Text(showChinese ? "你好" : "Hello")
.padding()
.backgound(showChinese ? Color.red : Color.blue)

我简单的画了一个数据和视图树的依赖关系图。

从上面的代码可以看出，模型是通过 @state 这种语法来映射到 SwiftUI 的视图树上的，那么 @state 的作用我们下面来简单分析下。

4.1 数据驱动的标记语法

SwiftUI 中@state 这种语法，其实属于属性包装器 (Property Wrapper),也是 Swift 语言的一个语法特性。如果想要详细了解这个语法的话，可以参看官方文档。它的作用就是当标记的数据有变化时，通知视图树来刷新 UI。

类似这种属性包装器的语法，SwiftUI 还有很多个，@State @StateObject @Binding @ObservedObject 。记住这些语法都是用来做数据驱动 UI 使用的。至于这些属性包装器具体如何使用，下面列出来了一些规则可供参考。

初始化属性如果属性无法在声明时进行初始化，而是需要接收父节点的数据，应该考虑使用 @Binding 或 @ObservedObject，而不是 @State 或 @StateObject。
普通属性 vs. 属性包装器尽可能在视图中使用普通属性，当仅需将值传递到视图中时，不需要使用属性包装器。
@State 当视图需要对一个值进行读写访问，并且该值作为本地的私有视图状态时，应该使用 @State。
@Binding 当视图需要对一个值进行读写访问，但该值不属于视图本身，而是由外部传递进来时，应该使用 @Binding。
@StateObject 和 @ObservedObject 当视图需要以对象的形式拥有状态，并且这个状态是本地私有的视图状态时，应该使用 @StateObject。当需要从外部传入一个对象时，应该使用 @ObservedObject。

注意:上面这样原则其实是 iOS17 之前需要遵守的，之后语法有了相应的更新，使用起来会更加的简单。等下我们就会讲到 iOS17 带来的更新。

在我们定义模型对象时，还有个重要的概念要讲 Identifiable Protocol （身份协议）。因为 SwiftUI 所有的视图树都是值类型，不同于 UIKit 每个 UIView 在内存中都有唯一的地址。而 SwiftUI 中的 View 是和映射的模型绑定到一起，框架是依靠模型的不同来确定是否为不同的视图，而如何确定模型的身份就是靠 Identifiable Protocol 这个协议，我们我就拿官网的示例代码展示下，Identifiable 作用。

enum Animal { case dog,cat }

struct Pet:Identifiable {
    var name:String
    var kind:Animal
    var id: UUID { UUID() }
    var dataBaseID:Int
}

struct FavoritePets: View {
    var pets:[Pet]
    var body: some View {
        List {
            ForEach(pets) {
                PetView {$0}
            }
        }
    }
}

上面这个方式构建的 SwiftUI 的视图会出现一个问题，每次向 pets 中添加新的模型时，整个列表都会刷新，所有的视图重新创建了。再看下面的代码。

struct FavoritePets: View {
    var pets:[Pet]
    var body: some View {
        List {
            ForEach(pets,id:.\dataBaseID) {
                PetView {$0}
            }
        }
    }
}

如果在创建视图时，改成上面的实现方式，给一个确定的 id 例如 dataBaseID 是一个持久化到数据库中。就不会出现上述的问题，所以我们在实现模型的 Identifiable 协议时，一定要牢记他就是对应 SwiftUI 的视图。

如果想要详细了解数据如何驱动视图树的原理，建议参看苹果 WWDC 揭开 SwiftUI 的神秘面纱。

4.2 iOS17 之后的变化

为什么要讲 iOS17 之后 SwiftUI 的变化呢？因为 visionOS 使用的 SwiftUI 就是 iOS17 之后的。我们来看下对比 iOS17 前后状态驱动语法的变化。

iOS17 之前

类型	根状态	子状态
值类型	@State	@Binding
引用类型	@StateObject	@ObservedObject

iOS17 之后

类型	根状态	子状态
值类型	@State	@Binding
引用类型	@State	@Bindable

从上面可以看出来 iOS17 之后 SwiftUI 状态绑定的用法更简单了。iOS17 之前如果你想要一个全局的数据源，驱动 UI 变化需要写下面的代码？

import SwiftUI
import Combine

// 1. 定义全局数据源
class GlobalData: ObservableObject {
    @Published var counter: Int = 0
    static let shared = GlobalData() // 单例对象
}

struct ContentView: View {
    // 2. 订阅数据变化
    @ObservedObject var globalData = GlobalData.shared
    
    var body: some View {
        VStack {
            Text("Counter: \(globalData.counter)")
            Button("Increment") {
                GlobalData.shared.counter += 1 // 修改全局数据源的值
            }
        }
    }
}

iOS17 之后的 Swift 语法有个重大更新，就是支持了宏。然后在 SwiftUI 中，新增了 @Observable 宏定义，开发者完全不用使用 Combine 框架的数据绑定能力了，只需要简单的写下面的代码：

@Observable
class GlobalData {
    var counter: Int = 0
    static let shared = GlobalData() // 单例对象
}

再使用 iOS17 之后 SwiftUI 为 View 新增的 environment API，创建 View 的时候简单的调用 ContentView.environment(self.GlobalData.shared)，然后视图就可以用下面的代码监听数据变化。

extension View {
    @available(iOS 17.0, macOS 14.0, tvOS 17.0, watchOS 10.0, *)
    public func environment<T>(_ object: T?) -> some View where T : AnyObject, T : Observable
}
struct ContentView: View {
    // 订阅数据变化
    @Environment(GlobalData.self) private var globalData: GlobalData
    
    var body: some View {
        VStack {
            Text("Counter: \(globalData.counter)")
            Button("Increment") {
                GlobalData.shared.counter += 1 // 修改全局数据源的值
            }
        }
    }
}

那如果说我们创建的 Model 某些属性不需要监听怎么办？比较好的方式定义为 let 常量，如果说需要变量存储中间状态可以使用 @ObservationIgnored 这种标记语法。

@Observable
class GlobalData {
    var counter: Int = 0
    @ObservationIgnored private var tempValue = false
    static let shared = GlobalData() // 单例对象
}

这样当 tempValue 变化时就不会触发通知，对控制 UI 频繁刷新很有用途。

5. 总结

如果上面说的这些能力都掌握的话，开发 SwiftUI 基本就没什么问题了。虽然说 SwiftUI 可以大大节省 UI 的开发量。但是开发过程中遇到的棘手问题就是调试。在 UIKit 所有的 UIView 都有内存地址，来确定某个视图什么时候创建、销毁、以及放置到那里。所以 UIKit 调试的时候，只要看下内存地址就很方便定位是那个视图，但是 SwiftUI 中的视图 View 你无法打印内存地址，就像上文说的你只能跟踪他的模型状态，但是在 Debug 过程中，往往视图的变化堆栈不会有模型变化的堆栈，在调试一些 UI 层级问题时就会遇到很多问题。

灵动岛按钮交互事件原理探究

2024-01-01T02:00:19+00:00

问题背景

苹果 WWDC2023 Widgets 增加了新的交互能力，iOS17 以前 Widgets 只能展示，无法响应 UI 上所有的按钮事件，只能跳转到主 App 中。iOS17 之后，通过这个新的交互能力，就可以实现 Widgets 上面的按钮点击事件。如果感兴趣可以看下苹果的WWDC视频和官方文档，下面会简单的介绍下苹果实现灵动岛 (LiveActivity Widget) 上按钮响应的方式和开发的过程中遇到的问题。

1. 灵动岛如何增加按钮响应事件

根据苹果的 Widgets 的逻辑，也就是我们写的所有 SwiftUI 的代码会放在 Widgets Extension 的进程中，但是在 SwiftUI 代码中所有的异步事件都无法执行，例如按钮事件、下载事件等等。可以看下在 Widgets Extension 中编写下面的代码，print("test") 这行代码是没法执行的。

DynamicIslandExpandedRegion(.bottom) {
    Button("Start") {
        print("test")
    }
}

猜测苹果在 Extension 进程中，把所有异步事件注册的能力给拔除了。

那 iOS17 之后灵动岛的 Widgets 又是怎么来响应异步事件呢？苹果是用 Intent 的方式来执行的，这样需要注册一个 Intent 类，然后来执行事件的代码。示例中按钮注册的代码如下：

DynamicIslandExpandedRegion(.bottom) {
    Button(intent: ConfigurationAppIntent()) {
        Image(systemName: "plus.circle.fill")
    }
}

在接收的模块需要实现一个 Intent 的类，如下：

struct ConfigurationAppIntent: WidgetConfigurationIntent {
    static var title: LocalizedStringResource = "Configuration"
    static var description = IntentDescription("This is an example widget.")
    
    func perform() async throws -> some IntentResult {
        ShareData.updateButtonStatus()
        return .result()
    }
}

按照上述的方式，按钮点击时，就可以执行 updateButtonStatus 这个方法了，下面是 updateButtonStatus 这个方法执行的逻辑，就是在共享的 group 中存储数据，然后主进程就可以读取数据的变化了。

public struct ShareData {
    static let appGroup = "com.mengtnt.myGroup"
    
    private static var currentActivity: Activity<DynamicIslandAttributes>? = nil
    
    public static func value() -> Int {
        guard let result = UserDefaults(suiteName: appGroup)?.value(forKey: "value") as? Int else {
            return 0
        }
        return result
    }
    
    public static func updateButtonStatus() {
        var result = value()
        result += 1
        UserDefaults(suiteName: appGroup)?.setValue(result, forKey: "value")
    }
}

这里展示下运行效果。

2. 遇到事件无响应的问题

由于钉钉都是基于 Framework 开发的，并不是全源码编译。所以这里模拟了钉钉的方式，写了如下的工程。所有的 Intent 和 LiveActivity 的代码都放到了一个叫 Appintent 的 Framework 下。然后相应的类引用这个 Framework，这个工程中任何源码都没改动。

然后神奇的一幕就发生了，灵动岛上的按钮事件没有任何反应。并且相应的代码也不会调用。效果如下:

然后推测是不是用 Framework 的方式，苹果把 Intent 的代码调用给裁剪掉了，然后用 hopper 分别打开了两种方式下生成的最终产物，分别搜索按钮响应事件调用的 updateButtonStatus 方法.

然后通过 hopper 跳转到调用的函数地址，就会发现调用的函数都是 Intent 类的 perform 方法。所以 Intent 类的 perform 方法其实都已经 link 到了目标 Target 中，只是两种方式生成的符号地址不一样而已。

所以应该不是先前的猜测，用 Framework 的方式执行的目标代码应该没有被裁剪。那么执行的代码都生成了，又会是什么原因造成按钮事件无响应呢？

3. 找出 Intent 调用的真相

然后就继续对比了下全源码编译的产物和 Framework 方式编译的最终产物。发现全源码编译在 Extension Target 下面多了这个文件夹 MetaData.appintents，但是 Framework 方式并没有。

打开这个文件，发现里面有一个 extract.actionsdata 的 json 文件，里面注册了一个 mangledTypeName 名字。

{
    "generator": {
        "name": "xcode-tools",
        "version": "15.0"
    },
    "enums": [],
    "queries": {},
    "autoShortcuts": [],
    "version": 1,
    "entities": {},
    "negativePhrases": [],
    "actions": {
        "ConfigurationAppIntent": {
            "outputFlags": 0,
            "isDiscoverable": true,
            "typeSpecificMetadata": [],
            "requiredCapabilities": [],
            "effectiveBundleIdentifiers": [],
            "parameters": [],
            "systemProtocolMetadata": [
                "com.apple.link.systemProtocol.WidgetConfiguration",
                {
                    "empty": {}
                }
            ],
            "descriptionMetadata": {
                "searchKeywords": [],
                "descriptionText": {
                    "key": "This is an example widget."
                }
            },
            "mangledTypeNameByBundleIdentifier": {},
            "title": {
                "key": "Configuration"
            },
            "identifier": "ConfigurationAppIntent",
            "systemProtocols": [
                "com.apple.link.systemProtocol.WidgetConfiguration"
            ],
            "authenticationPolicy": 0,
            "presentationStyle": 0,
            "mangledTypeName": "22DynamicIslandExtension22ConfigurationAppIntentV",
            "availabilityAnnotations": {
                "LNPlatformNameWildcard": {
                    "introducedVersion": "*"
                }
            },
            "openAppWhenRun": false
        }
    },
    "shortcutTileColor": 14
}

mangled type name 又是什么，简单的讲就是编译器根据用户的代码生成的特殊符号，里面包含了很多信息例如类型、接收的参数，返回类型，模板的情况等等。如果感兴趣可以详细了解 Swift 语言关于 mangled type 的原理。说白了 mangledTypeName 就是在编译器 link 的时候，方便获取函数调用的真正地址。用 hopper 打开，搜索定义的符号名称 22DynamicIslandExtension22ConfigurationAppIntentV。这个名字正是前面看到的 Intent 类的地址符号。

通过此 mangledTypeName 就可以找到类相应的内存地址，从而找到执行的 perform 方法。

那通过同样的方式，就寻找了下 Framework 方式下的 Extension 的产物，然后使用 hopper 打开，寻找相应的 Intent 类的符号，发现为 9AppIntent013ConfigurationaB0V，如下图，这里可以看出来这个符号是带有 Framework 名称 AppIntent。

然后用类似的方式，在 Extension Target 下面创建了 metadata.appintents 文件夹，然后配置了如下数据：

{
    "generator": {
        "name": "xcode-tools",
        "version": "15.0"
    },
    "enums": [],
    "queries": {},
    "autoShortcuts": [],
    "version": 1,
    "entities": {},
    "negativePhrases": [],
    "actions": {
        "ConfigurationAppIntent": {
            "outputFlags": 0,
            "isDiscoverable": true,
            "typeSpecificMetadata": [],
            "requiredCapabilities": [],
            "effectiveBundleIdentifiers": [],
            "parameters": [],
            "systemProtocolMetadata": [
                "com.apple.link.systemProtocol.WidgetConfiguration",
                {
                    "empty": {}
                }
            ],
            "descriptionMetadata": {
                "searchKeywords": [],
                "descriptionText": {
                    "key": "This is an example widget."
                }
            },
            "mangledTypeNameByBundleIdentifier": {},
            "title": {
                "key": "Configuration"
            },
            "identifier": "ConfigurationAppIntent",
            "systemProtocols": [
                "com.apple.link.systemProtocol.WidgetConfiguration"
            ],
            "authenticationPolicy": 0,
            "presentationStyle": 0,
            "mangledTypeName": "9AppIntent013ConfigurationaB0V",
            "availabilityAnnotations": {
                "LNPlatformNameWildcard": {
                    "introducedVersion": "*"
                }
            },
            "openAppWhenRun": false
        }
    },
    "shortcutTileColor": 14
}

运行后，果然按钮事件可以响应了，和全源码编译的运行结果一模一样。

4. 总结

通过上面的尝试，我们可以总结出来苹果 Intent 的运行原理，其实有点像 patch 原理，把异步事件响应的代码，用 metaData.appintents 中定义的符号地址替换，用户运行时就执行了 metaData.appintents 中定义的 action 方法。

其实苹果在开发者文档的中描述过 Intent 的大致执行过程，但是具体的实现方式并没有描述。

通过进一步验证了，把 Intent 类放到了主 App 的 Target 中，编译后，在主进程的 Target 中同样会生成一个 metaData.appintents，然后运行后，事件响应的代码就在主进程的空间中执行了。

所以总结下，Widgets 的整个生命周期的事件循环，本质上都是系统托管的。然后如何执行用户的异步事件呢？就像上面说的，在编译 Widgets 代码的时候，会根据注册的异步事件，然后生成 Intent 类的符号地址，然后会把此符号地址放到 metaData.appintents 文件夹下 extract.actionsdata 这个 json 文件中。当异步事件调用时，系统就会替换为 Intent 类注册的 perform 方法。不过发现 xcode 在编译 Widgets Extension 时，如果 Target 源码中没有 Intent 这个类就不生成调用地址的符号数据了，从而造成使用 Framework 这种方式，无法响应异步事件，不知道是苹果特意这样设计的，还是给我们开发者埋的小惊喜😂。

视频帧处理

2023-06-17T03:01:06+00:00

当我们做美颜、虚拟背景、虚拟人偶等功能时，一般都是需要对 iOS 相机帧进行前置处理。如果做过 iOS 开发的话，很快可以写出来下面的处理过程代码。

- (void)captureOutput:(AVCaptureOutput *)captureOutput
didOutputSampleBuffer:(CMSampleBufferRef)sampleBuffer
       fromConnection:(AVCaptureConnection *)connection {
    CVPixelBufferRef pixelBuffer = CMSampleBufferGetImageBuffer(sampleBuffer);
    CVPixelBufferRef resultPixelBuffe = [self handler:pixelBuffer];
    [self renderPixbuffer:resultPixelBuffe];
}

上面的代码看起来没啥问题，不出意外应该也可以顺利的运行起来。下面我们就逐步来看会遇到什么问题。

视频卡顿问题

当你写的代码运行的时间比较久时，手机发烫性能下降时会发现延时感非常强烈，看到的自己的画面很可能是5秒之前的画面。主要的原因就是性能下降时，手机的硬件处理速度下降，相机的视频帧的采集速度和处理速度不能匹配，造成了视频帧堆积引起的问题。

上图很形象的展示了这个过程，系统相机采集帧的线程队列优先级往往比较高，当遇到我们的帧处理线程时。相当于高速公路上的汽车突然来到了省道上，如果系统性能比较好时，高速公路不繁忙那么自然不会拥堵，当系统性能下降时很容易遇到上图示例展示的拥堵，这时候用户看到的视频帧自然就会延时的很厉害。

线程的优化

既然遇到了拥堵问题，那我们怎么优化呢？第一个想到的是，不要卡主系统相机采集线程的回调，通过设置另一个线程队列来处理我们的视频帧，自然会写出下面的代码。

_frameQueue = dispatch_queue_create("org.dingtalk.cameravideocapturer.video", DISPATCH_QUEUE_SERIAL);
// 提升视频帧处理线程队列的优先级，
dispatch_set_target_queue(_frameQueue, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0));
- (void)captureOutput:(AVCaptureOutput *)captureOutput
didOutputSampleBuffer:(CMSampleBufferRef)sampleBuffer
       fromConnection:(AVCaptureConnection *)connection {
    CVPixelBufferRef pixelBuffer = CMSampleBufferGetImageBuffer(sampleBuffer);
    CVBufferRetain(pixelBuffer);
   dispatch_async(self.frameQueue, ^{
     CVPixelBufferRef resultPixelBuffe = [self handler:pixelBuffer];
     [self renderPixbuffer:resultPixelBuffe];
     CVBufferRelease(pixelBuffer);
   }
}

这种想法是没有问题的，但是现实很残酷，虽然你切换了处理线程，并且也提升了线程的优先级，相当于吞吐量增加了。但是遇到性能下降时，尤其像美颜、虚拟背景处理视频帧花费的时间会比较长。会造成的问题是，有大量的视频帧囤积到内存中，然后等待你的 frameQueue 队列去处理。如果观察内存的变化情况就如下图：

并且在手机发烫，CPU 性能下降时，每帧视频处理时长会越来越长，导致内存不断增加形成恶性循环，最终的结果就是 OOM 程序崩溃。为何内存会囤积到内存中，等待 frameQueue 线程队列执行呢？这就涉及到我们使用的一个操作 dispatch_async。下面展示下 dispatch_async 的源码实现。

void 
dispatch_async(dispatch_queue_t queue, dispatch_block_t block)
{
    struct dispatch_continuation_s contin;
    dispatch_continuation_init(&contin, block, 0, queue, 0, 0);
    _dispatch_async_f(queue, &contin, NULL, NULL, NULL, DISPATCH_INVOKE_ASYNC_BIT, 0);
}
DISPATCH_NOINLINE
static void
_dispatch_async_f(dispatch_queue_t dq, dispatch_continuation_t dc, 
    void *ctxt, dispatch_function_t func, void *dc_func, 
    uint64_t dc_data, uint64_t dc_flags)
{
    // ...
    dq->dq_items_tail->do_next = dc;
    dq->dq_items_tail = dc;

    if (slowpath(dq->dq_width == 1)) {
        // 如果是串行队列,直接执行任务或唤醒runloop
        _dispatch_queue_push_list(dq);
    }
    // 如果是并发队列,直接将任务添加到队列尾部
}

我们总结下，dispatch_async 主要做了下面两个事情。

如果 dq 是串行队列,它会直接执行 dc 中的任务或唤醒 runloop 来执行任务。
如果 dq 是并发队列,它只会简单地将 dc 添加到队尾,等待后续被线程查找并执行。

可以看出 dispatch_async 的主要工作是将任务加入队列,并根据队列类型来决定是否直接执行任务。所以当我们定义一个串行队列时。本质上就是不停的往队列中放置数据，如果放置的队列中有大数据，而我们又没做相应的丢弃操作，就很容易引起内存堆积问题。

丢帧优化

为了防止上述的 OOM 的情况，最容易想到的就是对堆积的队列做丢帧的处理。可以通过设置丢帧的间隔，比如设置0.1秒间隔，如果处理不完就丢弃掉后面来的视频帧，可以写如下的代码。

_processSemaphore = dispatch_semaphore_create(1);
- (void)captureOutput:(AVCaptureOutput *)captureOutput
didOutputSampleBuffer:(CMSampleBufferRef)sampleBuffer
       fromConnection:(AVCaptureConnection *)connection {
    CVPixelBufferRef pixelBuffer = CMSampleBufferGetImageBuffer(sampleBuffer);
    CVBufferRetain(pixelBuffer);
   patch_async(self.frameQueue, ^{
       if (dispatch_semaphore_wait(self.processSemaphore,  dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.1 * NSEC_PER_SEC))) != 0){
            CVBufferRelease(pixelBuffer);
            return;
     }
     CVPixelBufferRef resultPixelBuffe = [self handler:pixelBuffer];
     [self renderPixbuffer:resultPixelBuffe];
     CVBufferRelease(pixelBuffer);
    dispatch_semaphore_signal(self.processSemaphore);
   }
}

上述的代码，可以用下图形象的展示:

这里相当于给高速公路设置了一个分流站，不合格的车辆直接当场扔掉(这样有点残暴，当然这里只是假设)。似乎用这种方式可以解决内存堆积问题。我们的程序用这种方式继续运行，会带来另一个问题。虽然内存不会持续增加了，但是内存会出现过山车的情况忽上忽下。如果用 instument 观察就如下面的现象。

这种情况虽然不至于让程序很快崩溃，但是也是在危险的边缘不停的试探，一旦一次触发到底线还是会崩溃的。那我们如何解决呢。

缓存队列

从上面的代码可以看到，之所以形成了过山车内存的问题，并不是采集问题引起的。因为采集线程已经做了丢帧的操作。我们把问题用下图描述。

可以看出主要原因是处理线程完成后，在渲染时由于采集和渲染在同一个 framequeue 线程中，会造成我们最开始描述的视频帧拥堵问题。那我们如何解决这个问题，和上面描述的优化逻辑一样，首先要把采集的线程和渲染线程分离开，然后再做丢帧的操作。这里我们可以通过增加一个缓存队列来做，实现代码如下：

CVBufferRetain(pixelBuffer);
CVPixelBufferRef willDropPixelBuffer = NULL;
[self.pixelBuffersLock lock];
if (self.pixelBuffers.count >= kRTCMaxDropPixBufferFrame) {
    willDropPixelBuffer = (__bridge CVPixelBufferRef)[self.pixelBuffers objectAtIndex:0];
    [self.pixelBuffers removeObjectAtIndex:0];
}
    [self.pixelBuffers addObject:(__bridge id)pixelBuffer];
    [self.pixelBuffersLock unlock];
if (willDropPixelBuffer != NULL) {
    CVBufferRelease(willDropPixelBuffer);
}

那为何采集的时候通过设置 0.1 秒的时间间隔来丢帧，而渲染要通过缓存队列来丢帧呢？其实本质上一样的，只是丢弃帧的逻辑不太一样而已，因为相机采集的帧回调的数据比较多，通过时间间隔丢帧可以更好的控制帧率，防止画面抖动太厉害。而渲染时就没必要这么精准的控制，通过丢弃过老的帧来防止内存抖动问题就可以了。然后我们优化后视频帧的整个处理过程就如下图所示：

我们总结下，解决视频帧处理遇到的问题，主要通过下面两个手段来防止：

分离相机帧采集的线程队列和渲染的队列 (frameQueue、renderQueue)，防止采集线程处理慢时造成渲染线程被卡住。
在两个线程队列切换时，增加数据丢帧逻辑防止内存 OOM。

最终改造后的流程图如下：

改造之前和改造之后，用 Instument 观察内存的抖动情况，可以明显的看到区别。

总结

上述虽然描述的是视频帧的处理优化过程。其实所有大的内存数据管道化处理时，都应该遵循下面的基本原则：

各个功能模块分别用不同的线程来处理，这样彼此互相独立不会相互影响数据的处理过程，避免拥塞卡顿问题。
在功能线程切换时传递的内存大数据，通过设置缓存 Buffer 避免引起内存问题，防止内存过多造成 OOM。

下面我们看下业界比较优秀的 WebRTC 音视频数据的处理过程，如下图所示:

WebRTC 的视频采集、混合、编码、发送的过程，都是分别使用不同线程，并且都有相应的 Buffer 做缓存操作，非常符合上面我们视频帧优化的整个过程。所以我们在做这种大内存数据处理时尤其要铭记上面提到的两个原则。

重构

2023-03-20T06:18:02+00:00

重构是一个老生常谈的问题，并且也有大量的书籍介绍重构的方法。那如何重构代码？如何保证重构的代码不出问题？重构后的代码如何防止腐化？我先贴出来 ChatGPT 如何回答的，来感受下她的强大。

如何重构代码

提取方法：如果你有一段过长或过于复杂的代码，可以将其提取为独立的方法，使其更易读且可重复使用。

重命名变量和方法：使用描述性的名称命名变量和方法，使代码更容易理解。

移除重复代码：查找重复的代码块，并将其提取为可重复使用的方法。

简化条件语句：如果条件语句过于复杂，将其分解为更小、更易处理的部分。

使用更好的数据结构：如果使用的数据结构效率低下或不能满足需求，考虑使用更好的数据结构。

将代码分解成模块：将代码分解成具有特定职责的较小模块，每个模块都有自己的一组测试。

移除无用代码：查找不再使用的代码，并将其删除以简化代码库并使其更易维护。这些只是重构代码的几个示例。关键在于不断寻找改进代码的方法，使其随着时间推移更易维护。

ChatGPT 上的回答和很多书籍和教程中讲的大同小异，其实有时候描述文字会很抽象。这里我拿自己经历的一个例子说明。当然不是 ChatGPT 给的例子😂。

简单功能的开发

这是很常见的成员列表页面展示功能。我们先看第一个版本的写法。


classDiagram
class MemberListViewController {
  -MemberListView view
  -loadView()
}

class MemberListView{ 
  -renderView(List<MemberData> data)
}

class MemberData {
  -String name
  -Int status
}

MemberListViewController *-- MemberListView: 1..1

MemberListView ..> MemberData: 1..*

下面用伪代码的方式展示下，调用的流程。

MemberListViewController::loadView(){
  RequestData(){ data in
    List<MemberData> dataList = List<MemberData>(data)
    view.render(dataList)
  }
}
MemberListViewController *vc = MemberListViewController()
vc.loadView()

其实这种 UI 开发的逻辑再简单不过了，获取数据然后把数据渲染到相应的 UI 组件上。我们下面来看下功能的发展过程。

臃肿类的形成

随着此功能设计了不同的应用场景，例如从场景A进去应该获取服务A的数据然后展现，从场景B进去获取服务B的数据… 先来看如果按照原来的逻辑，需要写类似下面的大量代码。

switch condition {
    case A:
      RequestAData(){ data in
        List<MemberData> dataList = List<MemberData>(data)
        view.render(dataList) 
      }
    case B:
      RequestBData(){ data in
        List<MemberData> dataList = List<MemberData>(data)
        view.render(dataList)
      }
  }

这时候你就会发现 Switch Case 中越来越多的数据请求和渲染代码。随着应用的场景越来越多，会发现 MemberListViewController 类变的越来越大。这时候如何重构?

这里就要用到重构的一个重要原则：职责单一。优化代码就是把 MemberListViewController 大的类拆分，此类负责渲染视图，不要再负责数据请求了，网络请求相似的功能内聚到另外一个类中MemberListDataInteractor ，专门处理数据获取，这样可以减少单个类的大小，方便阅读。

classDiagram

class MemberData {
  -String name
  -Int status
}

class MemberListDataInteractor { 
  - List<MemberData> dataList 
  - requestData(callback(List<MemberData> list))
}

class MemberListViewController {
  -MemberListView View
  -MemberListDataInteractor interactor
  -loadView()
}

class MemberListView{ 
  -View listView 
  -renderView(List<MemberData> data)
}

MemberListViewController *-- MemberListView: 1..1

MemberListViewController *-- MemberListDataInteractor: 1..1

MemberListDataInteractor *-- MemberData: 1..*

这个时候的调用过程可能是这样的。如下的伪代码：

MemberListViewController::loadView() {
  interactor.requestData() { List<MemberData> list in
    MemberListView.renderView(list)
  }
}
MemberListViewController::loadView() {
  interactor.requestData() { List<MemberData> list in
    MemberListView.renderView(list)
  }
}
MemberListViewController *vc = MemberListViewController()
vc.loadView()

这个其实就是典型的 MVC 的结构，视图渲染、数据模型、模型组装分开，核心就是内聚不同的功能。有时候想一想阅读代码就跟我们看文章一样，如果不分段落，直接一个1000字的段落，相信很多人都不愿意看。职责单一原则的目标就是让人更愿意阅读你的代码，第一眼不至于被吓到。

重复代码的优化

随着功能的演化，用户的界面越来越复杂，需要大量的数据频繁的渲染到视图上。就会发现有大量视图渲染组装的代码。这类代码的特点是相似度很高，只是渲染到不同的视图上而已。这时候重构的另一个重要原则DRY，不要写重复的代码，就发挥作用了，我们只需要把重复的代码再抽象出一层，就可以减少大量相似的代码。这个类可以叫做 MemberListDataPresentor,专门用来组装视图。只要简单的增加 MemberViewModel 这种数据结构映射到 MemberListView 这种视图上，然后 MemberListDataPresentor 就负责数据组装。我们来看下这种结构。

classDiagram

class MemberData {
  -String name
  -Int status
}

class MemberViewModel {
  -List<MemberData> dataList
}

class MemberListDataPresentor { 
  -MemberListDataInteractor interactor 
  - bind(MemberViewModel model,MemberListView view)
}

class MemberListViewController {
  -MemberListView View
  -MemberListDataPresentor presentor
  - loadView()
}

class MemberListView{ 
  -View listView 
  -renderView(MemberViewModel data)
}

MemberListDataPresentor *-- MemberViewModel : 1..1

MemberViewModel *-- MemberData: 1..*

MemberListView *-- MemberViewModel: 1..1

MemberListViewController *-- MemberListDataPresentor: 1..1

这样使用的时候只要 MemberListDataPresentor 组装好数据，就不必再调用渲染了，可以直接通过 MemberViewModel 映射到 MemberListView 上了。可以看到下面伪代码的调用过程。

interactor.loadAllUserData() { List<MemberData> list in
  presentor.bindData(list,listView)
}

这其实就是 MVVM 的架构进化的过程。DRY 原则就是不要写重复的代码，就像写文章一样，千篇一律的文字没人愿意看一个道理。我们继续来看这个功能发展的情况。

大量的耦合

随着功能越来越复杂，会发现 MemberListDataPresentor 这个类调用的接口会越来越多，既需要调用 MemberListDataInteractor 大量的请求接口来获取数据，同时也需要组装各种 Model 的数据，势必会造成大量接口暴露。这种各种复杂关系的调用，使阅读起越来越难。这时候软件工程的一个最好有的原则：任何工程问题，都可以通过增加一个中间层来解决。我们这里就需要增加工具类解耦，解耦的本质通过工具类拆分。使得依赖关系变为如下结构。

classDiagram

MemberListDataPresentor ..> ColdObserval

MemberListDataInteractor ..> ColdObserval

MemberListViewController ..> ColdObserval

有大量接口依赖的类，互相直接调用就可以用类似的方式。

presentor.addObserval() { result in
    // bind data
}
interactor.postMessage();

其实这就是使用观察者模式来拆分。观察者模式的好处就是解耦，减少接口依赖，这样我们想要定义不同的 presentor 类时，也不必依赖各种具体的 interactor，只需要监听消息即可。例如 WebRTC 中重要的线程工具类 TaskQueue ，就是一个很好的解耦的拆分的工具。把编解码，采集，传输很好的解耦分离开。有了这个铺垫，我们最后来看下如何扩展功能。

扩展新功能

试想下我们需要在 MemberListViewController 视图上增加新功能，不仅仅是显示 MemberListView 这一种视图，还能插入各种其他业务视图。

正是因为有了工具类的拆分，这样所有的类都没有任何的依赖，不用暴露新接口，扩展就很容易了。具体可以通过代理模式来横向拆分。定义要扩展的代理类 Plugin，我们新功能只要实现 Plugin 定义的接口函数，就可以横向扩展所有的功能。我们看下类结构。

classDiagram

class MemberListViewPlugin { 
  -View subView 
  -loadView()
}

class MemberListDataInteractorPlugin { 
  -List<MemberData> dataList 
  -requestData()
}

class MemberListDataPresentorPlugin { 
  -List<MemberData> dataList 
  -bindData()
}

MemberListDataPresentor *-- MemberListDataPresentorPlugin : 1..*

MemberListDataInteractor *-- MemberListDataInteractorPlugin : 1..*

MemberListView *-- MemberListViewPlugin : 1..*

然后我们的插件调用过程就如下：

MemberListDataPresentorPlugin *presentorPlugin = MemberListDataPresentorPlugin()
presentor.registPlugin(presentorPlugin);
MemberListDataInteractorPlugin *interactorPlugin = MemberListDataInteractorPlugin()
interactor.registPlugin(interactorPlugin)

这样每次增加新功能时，不需要更改原来的 MemberListDataPresentor、 MemberListDataInteractor 任何代码，只需要添加插件的实现就可以了。这其实就是很多软件插件的架构模式。

我们从上面这个例子里可以看到代码的演变，如何从 MVC 到 MVVM 再到最后插件化，这些过程让代码结构更加清晰容易阅读，防止代码腐化。

重构的回顾

我们总结下上述的重构过程中几个关键的节点。

当你发现一个类越来越大。

超过了1000行代码了，一定是需要拆分功能了。
当你开发功能时，发现需要原来的类大量更改接口才能实现，我们就需要用工具类来解耦。
当添加新功能时，需要频繁更改一个类时。

这时候就需要用代理模式的插件来扩展你的类，这样就可以避免大量的修改逻辑，保证代码稳定性。例如我们经常看到的一些可插拔的插件系统，都是通过这种方式实现的。
性能优化的代码太多时尤其注意，尽量不要暴露出来，因为性能优化的代码往往可读性比较差。

对于优化性能的代码，重构的时候我这里，尽量封装成内部的函数，而不要暴露给外部使用。比如定义了一个 Cache 资源的类，为了优化内存，这种最好不要把API暴露在外面，在内部消化最好。
发现无用的功能代码及时的删除，防止进一步防止腐化

不及时删除的后果，会发现新功能调用以前移除的功能类的方法，这时候你想删除老功能代码时，你会发现欲哭无泪。

对比 ChatGPT 重构的总结，总体原则一样，但是会更加具体一点。最后我想讲下关于重构代码时，如何保证稳定性的一些原则。我总结起来就是小步快走，保证稳定。在重构的过程中允许一定的冗余代码，增加灰度能力，当发现问题时可以及时回滚，等待重构的代码测试没问题了再删除。

很多优秀的开源项目的代码不仅对代码的性能，也对代码的质量和可维护性要求很高，阅读起来就像欣赏优美的诗篇。屎山一样的代码从来不会有伟大的作品。我相信每个优秀的程序员，都不愿意把自己的代码变成屎山，但是罗马也不是一天能建成的，学会重构是必备的技能。