有使用者在 GrapheneOS 上遇到 OsmAnd 明显比其他 Android 设备慢，滚动地图时卡顿。排查到最后，落在 GrapheneOS 默认给所有应用启用的加固内存分配器上。把这个应用单独的加固分配器关掉再重启，速度恢复。整个过程没有改系统，只是动了一个按应用切换的开关。
先把边界说清。GrapheneOS 官方文档确认了分配器切换机制，没有公布加固分配器本身的性能损耗数字。慢的解释属于使用者推断，官方未确认。
慢在哪一步
加固分配器在每次申请和释放内存时多做安全检查，代价落在调用频率上。OsmAnd 滚动地图时反复申请和释放小块内存，一屏刷新就是成千上万次，安全检查的开销被这个频率放大。兼容模式把它切回 Android 标准的 Scudo，检查没了，速度就回来了。
开关在哪，怎么试
长按应用图标进应用信息，打开 Exploit protection。里面可以给单个应用开兼容模式，把它从加固分配器切回 Android 标准的 Scudo 分配器，各项保护也能按应用单独关。关掉加固内存分配器，强制停止，重启应用，对比操作响应。
它只影响这一个应用，系统其他部分不动。
顺手要看的另外两个机制
Network 权限。GrapheneOS 提供按应用粒度的网络开关，能拦住直接和间接的网络访问，比基于数据包的防火墙更彻底。地图类应用表现异常时，先确认这个开关没被关掉，慢的原因可能是数据取不回来。
exec spawning。官方文档说它会带来更高的冷启动时间和更高的初始内存占用，除启动阶段外不影响运行时性能。启动变慢是正常代价，别和运行卡顿混在一起判断。
内存标记。官方问答提到，官方 WireGuard 应用在启用内存标记时被检测出非法内存访问，Mullvad 应用通过了同一项测试。加固选项确实能在真实应用上暴露问题，开发者要主动在 GrapheneOS 上测。
关掉它有代价
加固分配器挡的是内存破坏类漏洞的利用。关掉它，等于把这个应用对这一类攻击的防护降回 Android 默认水平。要不要关，看具体应用更怕什么，日常地图可以关，处理敏感数据的应用不建议关。
开发者的排障有先后。先用系统跟踪或 Android Studio Profiler 记录滚动时的分配速率和 CPU 占用，再对比开与关加固分配器的分配耗时和帧时间。确认是分配器开销之后才动代码，减少热路径上的频繁小对象分配，用对象池和缓冲区复用。改完在 GrapheneOS 上复测，尤其是内存标记和加固分配器同时开的组合。
这么默认开是有理由的。GrapheneOS 的取向是默认严格，遇到不兼容再按应用放开，兼容模式和单项关闭都是这条思路留下的口子。代价由用户按应用权衡，哪个应用值得多担一点风险，自己定。
常见问题
所有应用都会变慢吗。不会。分配密集的应用容易撞上，日常工具多数感觉不到差别。
系统整体流畅、单个应用慢，还有别的可能吗。有。先按应用信息里的 Exploit protection 和 Network 权限挨个排除，再回头看应用自身。
这套只对 GrapheneOS 有意义吗。原理上有参考价值，任何默认开启强化分配器的系统都有类似权衡，值得在自己的目标平台上量一遍。
应用信息里还有别的开关吗。有，网络权限、存储空间范围、传感器权限在同一层级，排查时一起过一遍，别只盯分配器。