我们在设计这个工具的 API 时斟酌了非常长的时间，既要保证功能的强大，也要保证接口的精简，一行调用背后隐藏着很多功能。
这一套缓存机制能对滑动起多大影响呢？除了肉眼能明显的感知到外，我还做了个小测试：
一个有 54 个内容和高度不同 cell 的 table view，从头滑动到尾，再从尾滑动到头，iOS8 系统下，iPhone6，使用 Time Profiler 监测算高函数所花费的时间：
未使用缓存API、未使用估算，共花费 877 ms：
使用缓存API、开启估算，共花费 77 ms：
测试数据的精度先不管，从量级上就差了一个数量级，说实话自己也没想到差距有这么大- -
同时，工具也顺手解决了-preferredMaxLayoutWidth的问题，在计算高度前向 contentView 加了一条和 table view 宽度相同的宽度约束，强行让 contentView 内部的控件知道了自己父 view 的宽度，再反算自己被外界约束的宽度，破除“鸡生蛋蛋生鸡”的问题，这里比较 tricky，就不展开说了。下面说说利用 RunLoop 预缓存的实现。
