原文鏈接：kyleduo.com
RecyclerView和StaggeredGradLayoutManager可以方便的實(shí)現(xiàn)瀑布流效果未玻，但是在使用中會(huì)遇到一個(gè)問題：如果使用ItemDecoration設(shè)置offset祭饭，在觸發(fā)動(dòng)畫之后薇芝，如果一個(gè)item從一個(gè)span移動(dòng)到另一個(gè)span（比如插入一條數(shù)據(jù)）喘落，會(huì)出現(xiàn)位置偏移的情況煤痕。
上圖中紅色虛線的位置是Item原本應(yīng)該在的位置念逞。（忽略下面的文字）
出現(xiàn)這個(gè)偏移的原因碾局，是RecyclerView會(huì)緩存child的offset灵再，當(dāng)span發(fā)生變化時(shí)肋层，又沒有更新，所以使用了動(dòng)畫之前的offset翎迁。
我們可以通過設(shè)置offset的左右值相等栋猖，來(lái)規(guī)避這個(gè)問題。但是規(guī)避終歸并沒有解決這個(gè)問題汪榔。這篇文章就來(lái)尋找一種方便的解決方法掂铐。
保存和更新
offset存儲(chǔ)在RecyclerView.LayoutParams.mDecorInsets這個(gè)屬性中，后文也是用mDecorInsets來(lái)表示揍异。
和它關(guān)聯(lián)的全陨，還有mInsetsDirty這個(gè)變量，用來(lái)標(biāo)記是否需要更新mDecorInsets衷掷。
mDecorInsets在RecyclerView.getItemDecorInsetsForChild方法中被更新賦值辱姨，這個(gè)方法在measureChild和measureChildWithMargins中調(diào)用。RecyclerView.getItemDecorInsetsForChild方法會(huì)判斷mInsetsDirty標(biāo)記位是否為true戚嗅，如果為false將直接使用緩存的值而不重新計(jì)算雨涛。
布局流程
RecyclerView的布局流程分為三步完成，對(duì)應(yīng)三個(gè)方法：
dispatchLayoutStep1dispatchLayoutStep2dispatchLayoutStep3
動(dòng)畫統(tǒng)一在dispatchLayoutStep3中執(zhí)行懦胞，動(dòng)畫的起始值和結(jié)束值分別在dispatchLayoutStep1和dispatchLayoutStep3中儲(chǔ)存替久。而
dispatchLayoutStep2是真正對(duì)子View進(jìn)行布局的地方，也就是這個(gè)方法確定了動(dòng)畫的結(jié)束值躏尉。
dispatchLayoutStep2中調(diào)用LayoutManager.onLayoutChildren方法進(jìn)行真正的布局蚯根，StaggeredGridLayoutManager.onLayoutChildren最終調(diào)用fill方法。
fill方法中更新span胀糜，并調(diào)用measureChildWithDecorationsAndMargin方法進(jìn)行測(cè)量颅拦，而這個(gè)方法，就最終調(diào)用前文說(shuō)的RecyclerView.getItemDecorInsetsForChild方法獲取mDecorInsets教藻。
定位問題
你可能注意到了距帅，既然是先設(shè)置span，后獲取mInsetsDirty括堤，那怎么會(huì)出現(xiàn)偏差呢碌秸？
問題出在dispatchLayoutStep1中绍移，這個(gè)方法包含這樣的邏輯：
private void dispatchLayoutStep1() {
// ......
if (mState.mRunPredictiveAnimations) {
// ......
// temporarily disable flag because we are asking for previous layout
mLayout.onLayoutChildren(mRecycler, mState);
// ......
}
// ......
}
processAdapterUpdatesAndSetAnimationFlags也就是說(shuō)當(dāng)滿足mRunPredictiveAnimations時(shí)，會(huì)調(diào)用一次onLayoutChildren方法讥电，兒dispatchLayoutStep2中登夫，還會(huì)無(wú)條件的再調(diào)用一次這個(gè)方法，這就導(dǎo)致onLayoutChildren在一次布局流程中被調(diào)用兩次允趟，而第二次調(diào)用時(shí)恼策，更新了span，但是使用了緩存的mDecorInsets潮剪，也就造成了偏差涣楷。
dispatchLayoutStep1會(huì)調(diào)用processAdapterUpdatesAndSetAnimationFlags方法，這個(gè)方法最終會(huì)調(diào)用RecyclerView.ViewHolder.offsetPosition這個(gè)方法抗碰，這個(gè)方法中會(huì)將mInsetsDirty設(shè)置為true狮斗。所以在dispatchLayoutStep1中第一次調(diào)用onLayoutChildren時(shí)，就會(huì)更新mDecorInsets的值弧蝇，而第二次進(jìn)來(lái)的時(shí)候碳褒，就不會(huì)了。
通過調(diào)試看疗，分別在設(shè)置span時(shí)和getItemDecorInsetsForChild中打印log沙峻，然后在index==1的位置插入一條數(shù)據(jù)，可以得到如下結(jié)果：
1247341404是第一條數(shù)據(jù)两芳，因?yàn)闆]有變化摔寨，所以第一次layout也沒有更新
mDecorInsets。1247341072是新添加的數(shù)據(jù)怖辆，因?yàn)榈谝淮蝜ayout使用的是舊數(shù)據(jù)是复，所以并不包含這一條，而在第二次layout時(shí)獲取到
mDecorInsets竖螃。觀察1247341250這條數(shù)據(jù)淑廊，第一次layout時(shí)span為1，第二次時(shí)變?yōu)?特咆，但是沒更新
mDecorInsets季惩，所以出現(xiàn)了偏差。
解決問題
既然知道了問題所在坚弱，下面我們就解決它蜀备。既然第二次onLayoutChildren時(shí)使用了緩存才導(dǎo)致mDecorInsets沒有更新关摇，那么我們就強(qiáng)制設(shè)置mInsetsDirty為true荒叶，這樣在fill方法中就會(huì)更新了。很遺憾RecyclerView并沒有提供public方法在做這件事输虱，那就只有使用反射了些楣。
StaggeredGridLayoutManager lm = new StaggeredGridLayoutManager(2, StaggeredGridLayoutManager.VERTICAL) {
private Method markItemDecorInsetsDirty = null;
private boolean reflectError = false;
@Override
public void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) {
if (markItemDecorInsetsDirty == null && !reflectError) {
try {
markItemDecorInsetsDirty = RecyclerView.class.getDeclaredMethod("markItemDecorInsetsDirty");
markItemDecorInsetsDirty.setAccessible(true);
} catch (NoSuchMethodException e) {
e.printStackTrace();
reflectError = true;
}
}
// 更新條件
if (markItemDecorInsetsDirty != null && state.willRunSimpleAnimations()) {
// noinspection TryWithIdenticalCatches
try {
markItemDecorInsetsDirty.invoke(mRecyclerView);
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
e.printStackTrace();
}
}
super.onLayoutChildren(recycler, state);
}
// 7.28 更新
@Override
public void requestSimpleAnimationsInNextLayout() {
super.requestSimpleAnimationsInNextLayout();
if (markItemDecorInsetsDirty != null) {
// noinspection TryWithIdenticalCatches
try {
markItemDecorInsetsDirty.invoke(mRecyclerView);
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
e.printStackTrace();
}
}
}
};
我們反射調(diào)用markItemDecorInsetsDirty這個(gè)方法標(biāo)記dirty，即可強(qiáng)制更新。但是我們并不想每次layout的時(shí)候都強(qiáng)制更新愁茁，這樣效率太低了蚕钦。所以還要判斷state.willRunSimpleAnimations()，這個(gè)標(biāo)記表示將執(zhí)行ItemAnimator動(dòng)畫鹅很，也就是只有當(dāng)觸發(fā)動(dòng)畫時(shí)嘶居，才強(qiáng)制更新。這樣就解決問題了促煮。
并不是只有修改數(shù)據(jù)時(shí)才會(huì)出現(xiàn)這個(gè)問題邮屁，當(dāng)使用
GAP_HANDLING_MOVE_ITEMS_BETWEEN_SPANS這個(gè)策略時(shí)，填充GAP時(shí)也會(huì)觸發(fā)動(dòng)畫菠齿，所以也會(huì)有這個(gè)問題佑吝。使用上面的標(biāo)記位即可涵蓋這兩種情況，并不會(huì)有多余調(diào)用绳匀。
7月28日更新
StaggeredGridLayoutManager在檢查GAP時(shí)芋忿，有兩種情況，一種是執(zhí)行動(dòng)畫移動(dòng)child疾棵，另一種是需要重新layout戈钢。上面的邏輯只包含第一種情況，第二種情況需要再添加一些代碼是尔。已經(jīng)更新到上面的代碼塊兒里了逆趣。
因?yàn)槿绻?code>checkForGaps方法返回true，調(diào)用的
onLayoutChildren為三個(gè)參數(shù)的私有方法嗜历，而不是我們覆寫的方法宣渗，所以不能在通過覆寫判斷標(biāo)記為實(shí)現(xiàn)。但是checkForGaps返回true之前梨州，一定會(huì)調(diào)用requestSimpleAnimationsInNextLayout方法（只在這個(gè)地方調(diào)用痕囱，所以也不會(huì)有額外性能損耗），而且這個(gè)方法是public的暴匠，所以我們可以覆寫這個(gè)方法鞍恢，在里面標(biāo)記mInsetsDirty為true。
總結(jié)
我們?cè)陂喿x源碼每窖，尤其是像RecyclerView這種邏輯復(fù)雜的類時(shí)帮掉，因?yàn)榇a量很大，邏輯分支多窒典，不要逐行閱讀蟆炊，否則一不小心就會(huì)“迷失”。正確的做法是在閱讀前先進(jìn)行思考瀑志，拆成多個(gè)子功能逐個(gè)分析涩搓，比如Measure/Layout污秆，Touch事件，Animation等等昧甘，每個(gè)子功能找到一個(gè)入口良拼，按照調(diào)用關(guān)系去分析，比如Touch事件和布局相關(guān)功能可以在onXxx回調(diào)方法中開始充边。
我在解決這個(gè)問題時(shí)庸推，就是從Animation這個(gè)點(diǎn)切入，因?yàn)閯?dòng)畫是notifyXxx方法觸發(fā)的浇冰，所以自然就找到了入口予弧，然后按照調(diào)用路徑去尋找最終影響動(dòng)畫的各個(gè)因素。
當(dāng)然閱讀源碼時(shí)不能光看代碼湖饱，合理的斷點(diǎn)和調(diào)試也是必不可少的掖蛤。畢竟最初編寫代碼的人，也一定不是一氣呵成寫完井厌，也是按照功能點(diǎn)逐步填充這個(gè)類的蚓庭。不要把自己當(dāng)成閱讀者，而要延著代碼的邏輯思考問題仅仆。
