关于UnityEngine.PlayerPrefs
我们在做单机游戏的时候，常常需要存储一些游戏数据到本地。
在安卓平台上，这个方法（UnityEngine.PlayerPrefs）内部调用的是SharedPreferences。
SharedPreferences的本质是基于XML文件存储key-value键值对数据，通常用来存储一些简单的游戏配置。其存储位置在/data/data/<包名>/shared_prefs目录下。
它的性能问题比较多，我可以轻松说出它的“几宗罪”。
-
跨进程不安全。由于没有使用跨进程的锁，就算使用 MODE_MULTI_PROCESS，SharedPreferences 在跨进程频繁读写有可能导致数据全部丢失。根据线上统计，SharedPreferences 大约会有万分之一的损坏率。
-
加载缓慢。SharedPreferences 文件的加载使用了异步线程，而且加载线程并没有设置优先级，如果这个时候读取数据就需要等待文件加载线程的结束。这就导致主线程等待低优先线程锁的问题，比如一个 100KB 的 SP 文件读取等待时间大约需要 50 ~ 100ms，并且建议大家提前用预加载启动过程用到的 SP 文件。
-
全量写入。无论是 commit() 还是 apply()，即使我们只改动其中一个条目，都会把整个内容全部写到文件。而且即使我们多次写同一个文件，SP 也没有将多次修改合并为一次，这也是性能差的重要原因之一。
-
卡顿。由于提供了异步落盘的 apply 机制，在崩溃或者其它一些异常情况可能会导致数据丢失。所以当应用收到系统广播，或者被调用 onPause 等一些时机，系统会强制把所有的 SharedPreferences 对象的数据落地到磁盘。如果没有落地完成，这时候主线程会被一直阻塞。这样非常容易造成卡顿，甚至是ANR，从线上数据来看 SP 卡顿占比一般会超过 5%。
-
应用程序。大部分的 I/O 方法都不是原子操作的，文件的跨进程或者多线程写入、使用一个已经关闭的文件描述符 fd 来操作文件，它们都有可能导致数据被覆盖或者删除。事实上，大部分的文件损坏都是因为应用程序代码设计考虑不当导致的，并不是文件系统或者磁盘的问题。
-
文件系统。虽说内核崩溃或者系统突然断电都有可能导致文件系统损坏，不过文件系统也做了很多的保护措施。例如 system 分区保证只读不可写，增加异常检查和恢复机制等。
- 磁盘。手机上使用的闪存是电子式的存储设备，所以资料传输过程可能会发生电子遗失等现象导致数据错误。不过闪存也会使用 ECC、多级编码等方式增加数据的可靠性，一般来说出现这种情况的可能性比较小。
