SharedPreference的get操作对性能有什么影响？
SharedPreferences的get方法在Android平台上一般被认为是线程安全的。它们使用内部锁机制，以确保在多线程环境中对SharedPreferences实例的读取操作是串行化的。这意味着同时对同一个SharedPreferences实例的读取操作会被同步执行，一次只允许一个线程进行读取。
然而，在标准的get操作（如getBoolean, getString, getInt等）中，并不会有显著的"阻塞"。当我们谈论阻塞时，通常是指等待一个数量有限的资源，比如文件写入。由于读取操作通常不涉及对共享资源的修改，因此它们可以相对快速地完成，并且通常不会在性能上成为一个瓶颈。
不过，需要注意的是，如果一个线程在进行写操作commit()或者apply()时，想要确保读取到最新的值，其他线读取操作可能会等待写操作完全完成。commit()是同步执行并立即写入磁盘的，所以它会阻塞调用线程直到写操作完成，而apply()是异步执行的，不会阻塞调用线程，但也需要等待实际的磁盘写操作在后台完成。
如果读操作需要等待正在发生的写操作，那么就可能出现短暂的等待时间。但是，由于SharedPreferences通常是用来存储轻量级的配置数据，并且设计上也有一定的内存缓存机制，所以这种等待通常不会对应用程序的响应能力造成显著影响。在正常情况下，读取操作非常快，而不会造成用户可感知的阻塞。
然而，如果你的应用在一个高频的读/写环境中使用SharedPreferences，或者你正在操作大量数据，建议重新评估你的用例，考虑使用其他数据存储方案，比如SQLite数据库，它可以更好地处理高频率、高容量的数据操作，并提供更复杂的查询支持。
参考资料
Android 性能优化篇之SharedPreferences使用优化
https://juejin.cn/post/7110618131000721416
SharedPreferences灵魂拷问之原理