今天在測試大批量item刷新時候發現的一個有趣的點。基本上基於scroll rect的優化都是從節約item內存開銷為原點出發的，但是對原生功能的支持缺乏適配。比如scroll 里滾動的三個方式中，clamped的源碼實現如下
說白了就是計算位置和content內錨定位置的距離。在高速拖拽時整個Loop Scrollrect 的邏輯無疑是成立的，對象池更新后content大小改變，錨定位置刷新，然后判斷移動距離平移。問題就出在緩速拖拽下。在拖拽速度很低的情況下，動態item尚未生成，滾動位置已經到達底部，此時clamped這種移動方式就會阻止你繼續移動。直接鎖死在原對象池的content錨定位置。但是動態item又需要你移動到錨定區域的邊緣才能界定你需要顯示下層的item,所以進入了一個永遠生成不了剩余item的怪圈。這並不是什么復雜的問題，只需要對clamped移動方式做一個優化，或者直接對動態item的生成機制做一個優化就可以解決。