iOS 面试 | 如果要存储用户的账号密码，你会选择什么方案？

直接回答

我会选择官方的 KeyChain 服务，因为用户的账号密码属于敏感数据，删除 App 后 KeyChain 中的数据依然保留，并且可以通过 iCloud 同步。这样，当用户下一次安装时，仍然可以读取到相关数据。

拓展：常见的持久化方案有哪些？

Key-Value 类存储方案

这一类存储方案通过 Key 来读写数据

1. NSUserdefault

   • 特点 ：支持基本数据类型（NSString、 NSArray，NSNumber，NSData，NSDate， NSDictionary），也支持自定义对象（但是要实现 NSCoding 协议，以便进行归档和解档）。它的写操作不是实时的，而是有一个写入 runloop（当然是为了减少 I/O成本啦）
   • 适用数据：App 配置信息，用户偏好设置以及简单的数据，这些数据都是不敏感的

2. MMKV：NSUserDefault（Pro Max版）

   • 特点：原理是 mmap 内存映射，提供一块内存地址给 App 读写，由系统负责将数据写到文件中，crash 也不怕数据丢失；序列化用到的是 protobuf 协议，性能和空间上都有不错的表现
   • 适用数据：读写频繁、性能要求高、不敏感的数据

3. NSKeyedArchiver： NSUserDefault 加密版

   • 特点：加密存储，支持自定义对象（也是要实现 NSCoding 协议， 还要实现 encode 和 decode 两个方法），
   • 适用数据：数据敏感的，比较复杂的自定义对象数据

数据库类型的存储方案

数据库都支持自定义类型的对象

1. 原生 Sqlite：最原始的数据库

   • 特点：C 语言 API，使用繁琐
   • 适用数据：什么数据都行，只要你不怕麻烦，也不考虑维护成本

2. CoreData：Apple 对 Sqlite 的封装数据库

   • 特点：用 Sqlite 进行存储，学习成本高，性能差，
   • 使用数据：不建议使用

3. FMDB：使用最广的数据库

   • 特点：用 OC 语法对 Sqlite 进行封装，更加面向对象。它是线程安全的。
   • 适用数据：数据量比较大的数据

4. Realm：自建搜索引擎（而不是封装 sqlite）

   • 特点：MVCC 数据库，更直观易用，更轻量级
   • 使用数据：不太稳定，谨慎使用

5. WCDB：微信封装的 sqlite

   • 特点：优化了 sqlite 源码，性能更好，上手成本低，功能齐全。而且，微信自己也在用这个数据库，在数亿用户量下遇到的性能、数据损坏问题更多，做的优化更多。强推。而且用了 WCDB 后迁移到 FMDB 成本也比较低。

参考文档

iOS数据持久化设计：从缓存策略讲起，还讲了内存缓存