背景
开发iOS端的快捷回复工具，技术选型只有一条路：Keyboard Extension（第三方输入法）。我们在开发聊天宝输入法时，遇到了iOS系统对键盘扩展的多重限制，本文记录关键的技术约束与产品侧的应对策略。
iOS Keyboard Extension 的核心限制
2.1 沙箱隔离
Keyboard Extension 运行在一个独立于主应用的沙箱进程中。这个沙箱有以下关键限制：
- 无法访问网络：Extension 本身无法直接发起网络请求（必须通过 App Groups 共享主应用的网络能力）
- 无法访问其他 App 的界面：无法读取或写入其他应用（如微信、淘宝）的文本框
- 内存上限：iOS 13+ 限制 Keyboard Extension 内存使用为 48MB，超出会被系统强制终止
- 无法访问系统剪贴板以外的数据：Extension 只能通过剪贴板传递数据
2.2 网络请求的特殊处理
Extension 无法直接访问网络，需要借助 App Groups 机制：
- 主应用负责与服务器通信，下载/更新话术库
- 通过 App Groups 的 UserDefaults 共享话术数据
- Extension 读取本地缓存的话术进行展示
// App Groups 共享数据
let sharedDefaults = UserDefaults(suiteName: "group.com.liaotianbao.app")
// 主应用写入话术数据
sharedDefaults?.set(encodedData, forKey: "phrases_data")
// Extension 读取话术数据
let cachedData = sharedDefaults?.data(forKey: "phrases_data")
2.3 发送消息的实现路径
这是最核心的约束：键盘扩展无法直接操作其他 App 的文本框。发送消息需要借助剪贴板：
// 将话术内容写入系统剪贴板
UIPasteboard.general.string = phraseContent
用户端操作流程：
- Extension 显示话术列表
- 用户点击话术
- 内容写入剪贴板（后台静默完成）
- 通过辅助视图引导用户点击"粘贴发送"或使用快捷手势
产品侧的优化：将"复制+粘贴+发送"三步简化为点击话术后的"一键发送"体验，引导用户通过快捷手势完成最终发送。
2.4 内存优化策略
话术库可能包含大量数据（图文+文件），而 Extension 内存上限仅 48MB。我们采用了以下策略：
| 优化策略 | 说明 |
|---|---|
| 按需加载 | 仅加载当前分类和搜索结果，不一次性加载全量话术 |
| 图片缩略缓存 | 使用缩略图预览，点击后显示原图（节省内存） |
| LRU淘汰 | 内存紧张时自动清理不常用话术缓存 |
| 延迟加载 | 图片/视频延迟到点击前一刻才加载 |
与 Android 实现路径的对比
| 维度 | iOS Keyboard Extension | Android Service |
|---|---|---|
| 交互模式 | 键盘内面板 | 悬浮球 / 侧边栏 |
| 发送方式 | 剪贴板写入 + 用户操作 | 直接操作目标文本框 |
| 网络访问 | 需通过 App Groups 中转 | 直接网络请求 |
| 内存上限 | 48MB（硬性限制） | 无明确限制 |
| 后台刷新 | 受 iOS 后台机制限制 | 可自定义后台服务 |
| 实现复杂度 | 高 | 中 |
开发避坑指南
坑1：完全访问权限的用户教育 很多用户在首次添加输入法时会拒绝"完全访问"，导致话术无法同步。需要在产品内引导用户理解：此权限仅用于从聊天宝服务器拉取话术数据，不会上传用户聊天内容。
坑2：iOS 后台刷新机制 iOS 后台刷新不保证实时性，话术同步存在 10-30 秒延迟。产品侧通过增量同步 + 主动拉取机制，在用户打开键盘时主动触发一次同步检查。
坑3：内存超限崩溃 图片话术是内存杀手。必须严格控制缩略图尺寸（建议 200x200 以内），并设置合理的缓存上限。线上曾因一批高分辨率图片话术导致大量用户键盘崩溃。
结语
iOS Keyboard Extension 开发本质上是在苹果定义的严格约束下寻找最优解。聊天宝输入法用技术手段最大程度弥补了系统限制带来的体验损失，最终在话术同步、分类管理、图文支持三个维度做到了与 PC 端一致的产品能力。
