iOS 性能优化面试题 - 启动/卡顿/耗电/崩溃/包瘦身/死锁

iOS 进阶面试题

iOS 基础面试题

iOS APM 监控面试题

AI/LLM 相关面试题

Swift 面试源码系列 这组文章围绕 Swift 语言面试高频问题展开：先给出可以直接用于面试表达的答案，再结合 Swift 源码定位解释背后的实现机制。 推荐阅读路径 如果你是为了面试准备，建议按下面顺序阅读： 1 ARC 与内存管理 理解 Swift 对象生命周期、引用计数、weak/unowned 与 ARC 优化。 2 泛型、协议与派发 串起 Generic Signature、函数派发、Protocol Witness Table、Existential 与动态派发。 3 值语义、COW 与集合 解释 struct 为什么可以高效复制，以及 Array/String/Dictionary 的存储策略。 4 并发、async/await 与 Actor 说明 Swift Concurrency 的任务模型、Actor 隔离和 MainActor。 5 编译流程、Runtime 与元数据 从 AST、SIL、IRGen 到 Runtime Metadata，建立语言机制的源码地图。

解构 Claude Code：AI Agent 的算法思想 这组文章从 Claude Code 的运行机制出发，拆解生产级 AI Agent 的核心算法思想：启动、推理循环、工具调度、权限决策、多 Agent 协调、MCP、钩子、安全、性能、容错与扩展。 推荐阅读路径 前言 为什么写这本书，以及适合哪些读者。 总览 AI Agent 算法思想的全局地图与章节导航。 基础篇 第 1 章 Agent 的本质 从程序到 Agent 的范式跃迁，理解感知-推理-行动循环。 第 2 章 Agent 的骨架：对象模型 梳理 Tool、Message、AppState、QueryEngine 等核心对象。 第 3 章 启动算法与生命周期管理 拆解冷启动、并行预取、分阶段初始化和优雅退出。 推理与工具篇 第 4 章 推理循环算法 解释 QueryEngine、Token 预算、上下文压缩和停止条件。 第 5 章 工具调度算法 深入 BashTool、FileEditTool、AgentTool 与工具反馈闭环。 第 6 章 权限决策算法 拆解分类器架构、危险模式检测、路径验证和拒绝追踪。 第 7 章 状态管理算法 理解响应式 Store、会话持久化、对话恢复和上下文压缩。 协作与扩展篇 第 8 章 多 Agent 协调算法 解释 Swarm 架构、Coordinator 模式、Teammate 机制与容错重连。 ...

一、背景：团队在 AI 辅助开发中的痛点 随着 Claude Code / CodeBuddy 等 AI 编程助手的普及，腾讯体育团队在日常开发中逐渐积累了大量与 AI 协作的经验。但在推广过程中，我们发现了几个反复出现的问题： 1. 重复解释团队上下文 每位同学使用 AI 时，都需要反复告诉它：“我们的路由怎么跳转”、“我们的架构层级是什么”、“Commit 格式应该怎么写”。这些团队共有的知识，每次都要重新解释。 2. 有效方案无法沉淀复用 某位同学花了一下午和 Claude 反复沟通，终于摸索出某类问题的可靠解决方案。但下一位同学面对同样的问题时，却不得不从头再来——AI 不会记住上一位同学的探索成果。 3. 规范依赖自觉，缺乏确定性保障 可以把规范写进 Prompt，但 Agent 是否遵守取决于模型"自律"。关键的验证步骤（如编译检查、commit 格式）需要确定性的工具触发，而不是靠模型"记得做"。 4. 社区能力与企业场景之间存在鸿沟 Claude Code 社区（如 OMC/oh-my-claudecode）提供了优秀的多 Agent 编排、自动规划等能力，但它不了解我们团队的 tRPC/DDD 架构约定、日志规范、代码评审流程等企业特定知识。 二、核心思路：“AI 时代的业务组件” OSC（oh-sports-claudecode）的核心设计理念是： 一个同学与大模型反复沟通，最终沉淀出某类问题的解决方案（知识库 + Skill）；下一个同学直接复用，无需再次摸索，AI 开箱即用地理解我们的业务上下文。 这与"业务组件"的思想完全一致——只是这里的"组件"不是 UI 组件或函数库，而是 AI 可消费的知识与工作流。 传统组件： 团队共享代码 → 减少重复实现 AI 业务组件：团队共享知识 → 减少重复沟通 基于这个思路，OSC 在 oh-my-claudecode (OMC) 开源框架之上，构建了一套适合腾讯体育团队的 AI 工作流体系。 三、架构设计：三层体系 OSC 采用 知识层 → Workflow 层 → 工具层 的三层架构，每一层职责清晰、可独立演进。 ...

Function Calling 2.1 要解决的问题 传统聊天大模型只会说话，没有工具调用能力，这使得大模型： 无法感知环境：无法与外部数据源交互，如通过 API 查询网页、查看用户本地文件、访问远程数据库等等 无法改变环境：无法帮用户实际执行任务，如跑代码、发邮件、上传作业等 2.2 如何解决问题 后端 + LLM 传统方案 工作流程 存在的问题 是否调用工具、调用什么工具由后端负责判断，逻辑复杂且容易误判。 AI 这么智能，为什么不让它来帮我判断？ 调用工具的参数由后端负责构建，难度很大。 AI 这么智能，为什么不让它来帮我生成参数？ 广义的 Function Calling 是指让大模型能够调用外部工具的一种技术实现：先向大模型提供可用函数的列表及说明，由大模型在对话过程中智能判断是否需要调用函数，并自动生成调用所需的参数，最终用文字返回符合约定格式的函数调用请求。 狭义的 Function Calling 特指大模型提供商在模型内部与 API 层面做了支持的一种能力，它最早由 OpenAI 引入： 在模型层面：模型提供商需对大模型进行特别优化，使其具备根据上下文正确选择合适函数、生成有效参数的能力（比如有监督微调、强化学习）。 在 API 层面：模型提供商需额外开放对 Function Calling 的支持（比如 GPT API 中提供了一个 functions 参数）。 Function Calling 方案 基于提示词的 Function Calling 工作流程 System Prompt 示例 System Prompt 示例 # 你的角色 你是一个函数调用助手，我将提供多个函数的定义信息，包括函数名称、作用、参数及参数类型。 # 你的任务 - 根据用户的输入，判断是否需要调用某个函数 - 如果需要，请**严格按照以下格式**输出函数调用指令： json { "name": "函数名", "arguments": { "参数名": "参数值" } } # 函数定义信息 1. **get_weather** - 作用：查询指定城市的天气情况 - 参数： -`city`（string）：城市名称 2. **get_time** - 作用：查询指定城市的当前时间 - 参数： - `city`（string）：城市名称 存在的问题 输出格式不稳定。如调用指令中存在多余自然语言。 容易出现幻觉。模型可能编造并不存在的函数名或参数。 大模型提供商能否对模型进行微调、强化学习，提升大模型在这一方面的能力？ 对开发者依赖度高。函数描述、调用指令格式、提示词逻辑完全由开发者设计。 函数描述、调用指令格式能否由大模型提供商来指定？系统提示词中的"说明与规则"逻辑能否由大模型提供商来兜底？ 上下文冗长，Token 消耗大。为确保调用逻辑正确，往往需要在 system prompt 中加入大量说明与规则。 基于 API 的 Function Calling 工作流程 ...

阅读导航（建议先看） 如果你是第一次接触这套 SDK，建议按下面顺序读： 先看 2 章：理解 commonMain 与双端 actual 的职责边界； 再看 5~6 章：把“主流程 + 双端播放器实现”串起来； 最后看 10 章：按需查 Debug 手册，不必一次读完。 如果你只想快速建立整体认知，优先看 0 + 5 + 9 + 12 四节即可。 0. 这篇写什么 这篇不再重复 KMM 概念，而是聚焦一件事：AIRead 这套 KMM SDK 在工程上到底怎么跑起来。 会重点回答四个问题： 工程目录怎么分层； 核心 API 给了什么能力； 从 start(contentId, sentenceId) 到播放/高亮/回调/重连，链路如何闭环； Android（ExoPlayer）和 iOS（AVPlayer）分别承担了什么。 KMM 基础与平台适配背景放在上一篇：KMM 基础篇。 1. 仓库目录总览 AIRead 仓库根目录： AIRead/ ├── androidApp/ # Android 示例应用（Compose + WebView） ├── iosApp/ # iOS 示例应用（SwiftUI + WKWebView） ├── shared/ # KMM SDK 主模块 ├── gradle/ # 版本目录、发布脚本、wrapper ├── build.gradle.kts ├── settings.gradle.kts ├── gradle.properties └── README.md 先按根目录分工看一眼： ...