LoxodonFramework——Preferences（应用配置）一

应用配置

Preference比较通用的翻译是偏好设置或者首选项，这里用LF文档中的翻译，反正意思大差不差。

主要是用于存储一些客户端本地的持久化数据，比如上次登录的账号，新手教程进度之类的，或者游戏里玩家的设置，音乐音效的开关和大小之类的。

Preference没有限制存储单机游戏存档，但是如果存档不是靠一个SaveDataMgr之类的来管理（在LF里应该属于一个服务）我会觉得很难受，哪怕你就是封装一下Preferences呢。

Preferences

Preferences是一个抽象类，它有两个子类，PlayerPrefsPreferences和BinaryFilePreferences。前者是作为默认的应用配置使用，对Unity的PlayerPrefs进行了扩展和封装。后者是把数据存储成二进制文件保存在persistentDataPath路径。

Preferences不是唯一的，它有一个静态的字典类型的cache，通过名字访问不同的应用配置。这个好处是如果游戏允许多账号登录，那可以对每一个账号保存一份应用配置。同时提供了一个全局配置的接口，就是单纯封装了一个名字为“_GLOBAL_“的应用配置。

Preferences对多应用配置的创建使用了工厂模式，接口为IFactory（注意和服务容器的IFactory不是同一个，服务容器的IFactory是ServiceContainer的内部接口），有一个抽象类的实现AbstractFactory。在继承Preferences的同时需要实现子类对应的具象Factory。

AbstractFactory要求提供一个加密器（IEncryptor）和序列化器（ISerializer），主要是在创建应用配置的时候作为参数传入Preferences。二者其实都是可选的，如果需要实现其他的应用配置，可以根据需求来选择。

PlayerPrefsPreferences

PlayerPrefsPreferences是对Unity的PlayerPrefs的扩展，具体来说就是把PlayerPrefs不支持的类型都转为字符串再存储。同时提供了数据加密的支持。

根据上文，PlayerPrefsPreferences的数据加密和类型转换实际上都依赖于加密器和序列化器，它本身只负责对字段进行存储、读取、移除的操作，也就是封装了一下PlayerPrefs的API，再加上对数组序列化的支持。

PlayerPrefsPreferences中包含一个字符串数组keys来存储通过该类保存到PlayerPrefs的key。因为PlayerPrefs可能被其他逻辑引用，如果不保管key，在全部移除的时候就只能生硬地DeleteAll，这样必然会影响其他的逻辑。同时这个操作也保证了上文提到的多应用配置的实现。

性能疑点：PlayerPrefsPreferences对SetArray的操作是把数组中的每一项都先用序列化器编码成字符串后再用数组分隔符'|'拼接成一个长字符串。但其实只要加一层class包装，JSONUtility就可以序列化数组或者列表。为了测试二者性能，我去掉了JsonTypeEncoder中对IList的限制，对一个数组同时使用SetArray和SetObject（它最终会调用到JsonTypeEncoder），结果显示后者的耗时是前者的一半，二者序列化后的长度也几乎没区别。因此我感觉这里对数组的序列化是一个吃力不讨好的做法。然而SetArray又不是直接调用的序列化器进行操作，都没法通过扩展修改这段逻辑。除非新写一个类继承PlayerPrefsPreferences并且重写SetArray的操作。

说到这里不免得想要扩展开来说两句。解析LF之前的代码都能发现它的高扩展性，代码风格也是简洁易读。而看到SetArray的实现我总觉得跟整体的简洁风格有点不搭，本着“大佬肯定有自己的考虑”这样的想法做了测试，但是结果就是SetArray性能不如直接用JSONUtility。

BinaryFilePreferences

BinaryFilePreferences是把数据放在字典中，保存时先以“字段数、键、值、键、值……”的顺序转成二进制数据再写入到文本中。保存文件的地址在persistentDataPath/{Preferences.Name}/prefs.dat。由于不同应用配置是通过不同的文件夹区分的，因此这里没有对key进行处理。

其他部分跟PlayerPrefsPreferences没有区别，Set\GetArray的实现也一致（性能问题自然也一样）。就不再多赘述了。

声明

该文章只作为本人学习框架的梳理思路用，一切以官方文档为准。如有错误还请指正。