值得一提的另一个类是android.util.LruCache<K, V>，这个类是Android 3.1（代号 Honeycomb MR1）引入的，可以在创建时定义缓存的最大长度。另外，还可以通过覆写sizeof()方法改变每个缓存条目计算大小的方式。因为android.util.LruCache只能在Android 3.1及更高版本上使用，如果针对版本低于3.1的Android设备，则仍然必须使用不同的类来实现自己的应用缓存。由于目前的Android 3.1设备占有率不高，这种情况很有可能出现。替代方案是继承java.util.LinkedHashMap覆写removeEldestEntry。LRU（Least Recently Used）缓存先丢弃最近最少使用的项目。在某些应用中，可能需要完全相反的策略，即丢弃缓存中最近最多使用的项目。Android现在没有这种MruCache类，考虑到MRU缓存不常用，这并不奇怪。
当然，缓存是用来存储信息而不是计算结果的。通常，缓存被用来存储下载数据（如图片），但仍需严格控制使用量。例如，覆写LruCache的的sizeof方法不能简单地以限制缓存中的条目数为准则。尽管这里简要地讨论了LRU和MRU策略，你仍可以在缓存中使用不同的替代策略，最大限度地提高缓存命中率。例如，缓存可以先丢弃那些重建开销很小的项目，或者干脆随机丢弃项目。请以务实的态度设计缓存。简单的替换策略（如LRU）可以产生很好的效果，把手上资源留给更重要的问题。
我们用了几个不同的技术优化斐波那契数列的计算。虽然每种技术都有其优点，却没有一个实现是最佳选择。往往最好的结果是结合多种不同的技术，而不是只依赖于其中之一。例如，更快的实现可以使用预计算、缓存机制，甚至采用不同的公式。（提示：当n是4的倍数，会发生什么？）怎样在100毫秒内计算出FInteger.MAX_VALUE？