北京
iOS上的自定义键盘看起来像一个小的UIKit应用，但实际上并非如此。它是一个运行在扩展进程中的UIInputViewController，遵守着普通应用无需遵循的规则。真正影响代码架构的规则有三条：
- 内存上限仅几十MB，超出即被静默终止；
- 默认关闭的沙盒（Allow Full Access）会移除网络、定位、系统剪贴板，以及一个可靠可写的App Group容器；
- 声音和触觉反馈必须在没有音频会话的情况下、在同样的严格内存预算内、在按键路径上完成。
以下内容均来自一个已上架的键盘扩展。所有数字都是设备实测值，而非估算，其中几组数据曾推翻我们先前的假设。
约束一：内存上限，以及为什么无法正常调试
键盘扩展的内存上限约为60MB phys_footprint。难点不在于这个数值本身，而在于失败模式——一旦越界，jetsam会直接杀死扩展：没有崩溃日志、没有信号、没有异常。iOS只是将用户切换回之前使用的键盘。从用户角度看，"键盘在打字中途自己退出"；从开发者角度看，事后没有任何可读取的信息。
更糟的是，这个上限取决于手机当前的整体内存占用，因此问题呈间歇性，无法按需复现。
为什么常规方法行不通
常规方法是猜测。你查看应用，认定最大的内存消耗项大概是词典，然后压缩它、发布、再去问拿着手机的人。这个循环耗时一整天，而且反复出错——先是归咎于词索引，然后是拼音表，而设备实际占用55MB、峰值68MB时，问题依然存在。
第二种常规方法——向App Group中的文件写入诊断信息——也因扩展的特殊性而失效：从键盘扩展向共享容器写入数据并不可靠，且在没有Full Access时静默失败。日志文件从未被写出来过，而系统从不告诉你它失败了。
最终可行的方案是：在扩展内部维护一个内存中的环形缓冲区，记录关键事件（词典加载、候选生成、输入会话切换）时的phys_footprint读数；当jetsam即将触发时，将缓冲区内容通过开发者自定义的、不需要Full Access的少量数据同步方式（例如UserDefaults套件）带出。这并不优雅，但它是少数几种能让你在崩溃现场看到"最后几分钟发生了什么"的手段。
实测数据印证了一个结论：真正吃掉内存的并非词典本身，而是输入会话期间的候选列表缓存和视图层级。优化后，峰值从68MB降至41MB，稳定运行至今。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
