iOS状态恢复与User Defaults、SQLite的区别及相关API疑问
我目前了解的内容：
- 应用被挂起时，内存空间不会释放，但代码执行暂停，恢复时内存中的变量和对象会保留。
- 若应用长时间挂起或系统需要释放内存，操作系统可能终止应用，此时所有内存和数据都会被释放，下次启动需从头开始。
- 实现状态保存与恢复功能后，通过
encodeRestorableState方法保存的数据，即便应用被终止，恢复时仍可获取。 - 未实现该功能时，应用挂起或终止前未保存的数据会丢失，下次启动回到主屏幕从头开始。
我的困惑：
这些说明暗示状态恢复方法的主要作用是跨应用生命周期保存状态，尤其是应用被完全终止并从内存移除时。毕竟临时挂起后恢复的话，内存里的变量和对象还在。
那application(_:shouldRestoreSecureApplicationState:)到底有什么用？已经有User Defaults和SQLite这类工具了，真的需要它吗？还是说它只是现有工具之上的一个内置层？
关于application(_:shouldRestoreSecureApplicationState:)的作用与价值
这个方法是iOS应用状态恢复机制里专门处理敏感临时状态的钩子，和User Defaults、SQLite的定位完全不同：
场景针对性极强
它负责处理应用被系统终止后，重启时需要恢复的临时敏感信息——比如用户正在填写的密码输入框内容、未提交的敏感表单数据这类不需要持久化存储（或不适合长期存在本地）的内容。而User Defaults适合存非敏感配置项，SQLite用于存储大量结构化持久数据，三者使用场景完全不重叠。与系统生命周期深度绑定
状态恢复是系统主动触发的流程：应用即将被系统终止时，系统会自动调用相关编码方法保存状态；应用重启时，系统会自动检查是否有可恢复的状态，再触发恢复逻辑。你不需要手动判断“应用是不是被系统杀了”“要不要恢复状态”，系统已经帮你完成了这些逻辑判断，只需实现数据的编码和解码即可。而User Defaults或SQLite需要你手动控制存储、读取时机，比如进入后台时手动存数据，重启时手动读取，逻辑更繁琐。自带安全特性
这个方法针对敏感数据设计，系统会把这类状态数据存在加密存储区域，且设备重启后，这些安全状态数据会被自动清除——刚好符合敏感临时数据的需求：既需要在应用被系统终止后恢复，又不能长期留在本地带来安全风险。而User Defaults默认存储不加密（需额外处理），SQLite也需要手动实现加密逻辑，成本更高。并非现有工具的上层包装
它是iOS原生状态恢复框架的一部分，和User Defaults、SQLite是完全独立的机制。状态恢复保存的数据是临时的、与应用上次运行状态强绑定的，用户主动退出应用后，这些恢复数据会被系统自动删除；而User Defaults和SQLite的数据是持久化的，除非手动删除，否则会一直留在设备上。
总结来说，这个方法的核心价值是：帮你快速实现敏感临时状态的自动恢复，适配系统生命周期，同时自带安全存储特性，这些都是User Defaults和SQLite做不到（或需要额外大量开发）的。
内容的提问来源于stack exchange，提问作者AlanSTACK
