在我的一个 onTouch() 监听器中，我目前在决定如何处理触摸事件之前检查 bool 用户设置:
boolean shouldCue = preferences.getBoolean(v.getContext().getString(R.string.should_cue), true);
观察LogCat，我可以看到当用户触摸屏幕时，这个语句被调用了无数次!
所以，我正在考虑通过实现 onSharedPreferenceChanged() 来“缓存”shouldCue bool 值听众。
我当然可以继续实现并...在我超快的 Android 设备上观察可以忽略不计的差异。我不可能在“大多数 Android 设备”上对此进行测试，因为变化太多了。
所以我的问题是:
- 会 onSharedPreferenceChanged()即使未通过 UI 更改首选项也会被调用？ (即通过
editor.commit();以编程方式) - 假设 SharedPreferences bool 值可以从 UI 或编程方式(但不能同时)修改，则缓存它会强制要求 @Synchronized处理？
- 对缓存方法与非缓存方法之间的性能差异有何估计？ (为了简化问题，假设我们指的是像 Droid 1 A855 这样的旧手机)
最佳答案
在我看来，最好避免在 onTouch() 方法中读取首选项:它的触发速度非常快，并且从首选项中读取意味着解析 xml(这不是您每秒应该执行这么多次的事情)。您可以在模拟器上试用它，看看它是否 react 足够快，但最好在其他地方阅读它或找到另一种方法来存储/获取此 bool 值。
编辑:关于问题:
1) 是的，即使偏好根本没有改变
2) 是的，可以这样实现，但这可能会导致很多问题，特别是如果您打算重用 View
3) 由于许多因素(硬件、操作系统版本、启用的 jit 等)，我无法准确估计对其他设备的影响，但在没有基准测试的情况下，缓存方法似乎是最有效的。
您真的必须在 onTouch() 方法中操作该 bool 值吗？在这种情况下，为什么不定义钩子(Hook)或监听器？
关于android - 缓存 SharedPreferences bool 值 : Would performance justify increased complexity?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11104736/