今天在测试大批量item刷新时候发现的一个有趣的点。基本上基于scroll rect的优化都是从节约item内存开销为原点出发的，但是对原生功能的支持缺乏适配。比如scroll 里滚动的三个方式中，clamped的源码实现如下
说白了就是计算位置和content内锚定位置的距离。在高速拖拽时整个Loop Scrollrect 的逻辑无疑是成立的，对象池更新后content大小改变，锚定位置刷新，然后判断移动距离平移。问题就出在缓速拖拽下。在拖拽速度很低的情况下，动态item尚未生成，滚动位置已经到达底部，此时clamped这种移动方式就会阻止你继续移动。直接锁死在原对象池的content锚定位置。但是动态item又需要你移动到锚定区域的边缘才能界定你需要显示下层的item,所以进入了一个永远生成不了剩余item的怪圈。这并不是什么复杂的问题，只需要对clamped移动方式做一个优化，或者直接对动态item的生成机制做一个优化就可以解决。