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灵魂拷问之原理