缓存SharedPreferences布尔值：性能是否会证明增加的复杂性？

在我onTouch（）的一个听众，我现在决定如何处理触摸事件之前检查布尔用户设置：缓存SharedPreferences布尔值：性能是否会证明增加的复杂性？

boolean shouldCue = preferences.getBoolean(v.getContext().getString(R.string.should_cue), true);

观测logcat的，我可以看到，当用户触摸屏幕时，这一说法被称为无数次！

所以，我想通过实现onSharedPreferenceChanged()监听器来“缓存”shouldCue布尔值。

我当然可以继续实施这个...观察忽略区别在我的超高速Android设备上。我不可能在“大多数Android设备”上测试这个，因为有太多的变化。

所以我的问题是：

即使偏好不是通过UI改变

会onSharedPreferenceChanged()叫？（即以编程方式通过editor.commit();）
假设SharedPreferences布尔值可以从UI或编程方式修改（但不能同时），缓存它的任务@Synchronized要求处理？
有关缓存与非缓存方法之间性能差异的任何估计？（为了简化问题，让我们假设我们指的是像Droid 1 A855这样的旧手机）

来源

2012-06-19 ateiob

你不觉得更好的解决方案是调查为什么它被称为无数次？ – jiduvah

@jiduvah它被称为无数次，因为这是'onTouch（）'的工作方式：在简单的上/下，只有少数这样的调用。但是，如果用户移动手指......你会看到很多。没关系。这是应该的。这个想法是花时间在听众身上。通过设计。 – ateiob

为什么使用onTouch而不是点击？当然，如果听众如此快速地发射，实际上用户不知道他在按什么方式？ – jiduvah

在我看来，最好避免在onTouch（）方法中使用阅读偏好：它的速度真的很快，并从喜好阅读意味着解析XML（这不完全是你应该每秒这么多次）。你可以在模拟器上试试它，看看它是否足够快地反应，但最好是在其他地方读取或找到另一种方法来存储/获取此布尔值。

编辑：关于问题：

1）是的，即使偏好完全没有

2有变化）是可以以这种方式实现，但是这可能会导致很多问题，特别是如果你打算重用视图

3）我不能估计由于许多因素（硬件，操作系统版本，JIT启用等），但没有基准测试，因为在其他设备上的影响，缓存的方法似乎是最有效的。

你真的必须在onTouch（）方法中操作布尔值吗？在这种情况下，为什么不定义钩子或听众？

来源

2012-06-19 16:45:16

+1。换句话说，你推荐缓存。顺便说一句，我没有尝试过，但正如我所提到的，我的Android设备速度非常快，即使在onTouch（）中有阅读偏好，性能也是可以接受的。你能回答上面三个问题中的一个或多个吗？ – ateiob

感谢您解决3个问题。回答你的问题：如果我缓存布尔值（按照我的计划），onTouch（）将不会发生任何操作（甚至是偏好读取）。这是我整个问题的目的。操作将发生在我的OP中提到的'onSharedPreferenceChanged（）'监听器中。 – ateiob

回报：高速缓存就像一个魅力。 ** 1。** onSharedPreferenceChanged（）即使在通过'editor.commit（）'编程改变的首选项时被调用。 ** 2。** @不需要同步处理。 ** 3 **没有注意到显着的性能改进，但知道我使用更正确（优雅）的方法总是很好的。 – ateiob

缓存SharedPreferences布尔值：性能是否会证明增加的复杂性？

回答

相关问题