APP中的用户类

做APP，涉及到用户登录的，就避免不了用户的信息本地化，更有甚者是持久化存储。
当用户登录之后，会生成多个用户属性，比如用户的昵称，头像，身份token等，在APP中多处可能都用到用户的基本信息，比如头像和昵称，是不是在每次用到的时候都需要请求一次呢，那当然不是必要的，下面介绍下曾经在工作中遇到的几个方案：

1.用户登录之后，使用单例实例化用户类，属性赋值，属性修改。单例保证当前类有且只有一个对象被实例化，相当于在APP中出现一个大家都能沟通的对象，A可以从这个对象获取想要的属性值，并且修改了某个属性，此时B也来了，B直接可以取到A修改完成的属性值，保持A和B拿到信息的一致性。那么此时又遇到一个问题，当APP被杀死后再次被打开，此时用户的信息从哪来，有两种方案：

方案A:把用户的身份标识token使用持久化存储的方式存到本地，NSKeyedArchiver，NSUserDefaults，Core Data，以及数据库，都可以用，然后当用户打开APP的时候，用存储的token再去请求用户的信息，并实例化赋值，这时候需要考虑到后端对于token的一个设计方案，如果随时可变，那就得考虑存储其他的身份标识。

方案B：本地持久化存储用户所有的属性，相当于把用户对象存储到本地，当用户登录之后存储用户所有的属性。是不是感觉比A
方案更好使，但此时遇到一个很麻烦的事情，当用户的属性被修改之后，用户单例对象的值修改了，但是本地的持久化存储没有修改啊，然后再封装一个方法，每次修改用户属性之后，调用一次保存方法，保证单例对象和本地存储的数据是一致的，甲修改了单例对象的昵称属性，忘记了存储怎么办。为了解决这个问题，我们引入一个不会忘记替我们做存储工作的概念，使用监听单例属性的方式，当监听到属性值发生变化的时候，自动执行本地持久化存储的修改就可以了。

使用方案B之后，你就会发现一个单例对象非常的繁重，既有用户属性赋值的代码，还有监听者的代码，还有持久化存储的代码，可以用但是不专业，那么此时有一个替你去管理单例对象属性的它出现了：
一个单例对象的管理者-manager，manager负责观察监听单例对象的属性的变动，负责将修改后的值持久化存储到本地，是不是显得更加高级。

此时有可能你会发现一个管理者直接去执行存储工作，是不是不大公平，然后你就会创建一个工具类，编写一个类方法，专门做本地持久化存储的工作，你的管理者告诉工具类存一下，好了，工具类给你存了就。

存储的流程结束了，那么取用的时候怎么办呢，单例对象初始化时需要manager去获取持久化存储的内容，然后给单例对象赋值。至此，一个完整的带有本地存储的用户类完成。