现象
- 正文页转发列表中，出现个别item 头像，昵称等点击失效
- 偶现，大概率出现在‘更多热门转发>>’文案下面第一个，偶尔也会是第二个
- 整个item的点击正常，但是点击状态背景色不消失
- 刷新整个列表后正常显示
- 同事说之后滚动多少个之后还会出现这种情况（未验证）
tu.png
代码结构
- 整体列表采用listview控件
- 其中每个item在update方法（adapter.getView()）中更新数据，为头像和昵称等控件绑定了点击事件 setOnClickListener
- 其中 ‘更多热门转发’并没有单独设置itemType，而是在getView方法中根据数据位置判断，进行了对应的view返回。
分析过程
- 点击事件失效，首先怀疑的就是触摸事件被上层拦截，导致元素无法正常收到事件分发。但是通过重写了头像view的onTouchEvent()方法后发现，头像可以正常的收到down,up等事件，也就是没有被拦截，只是setOnClickListener方法失效。
- 通过debug到onTouchEvent方法中，观察设置进入的listener也同样存在，并没有被别处冲掉或是被覆盖等等原因。
- 接下来只能通过源码分析可能的原因
public boolean onTouchEvent(MotionEvent event) {
final float x = event.getX();
final float y = event.getY();
final int viewFlags = mViewFlags;
final int action = event.getAction();
...... //省略
if (clickable || (viewFlags & TOOLTIP) == TOOLTIP) {
switch (action) {
case MotionEvent.ACTION_UP:
mPrivateFlags3 &= ~PFLAG3_FINGER_DOWN;
if ((viewFlags & TOOLTIP) == TOOLTIP) {
handleTooltipUp();
}
...... //省略
boolean prepressed = (mPrivateFlags & PFLAG_PREPRESSED) != 0;
if ((mPrivateFlags & PFLAG_PRESSED) != 0 || prepressed) {
boolean focusTaken = false;
if (isFocusable() && isFocusableInTouchMode() && !isFocused()) {
focusTaken = requestFocus();
}
if (prepressed) {
setPressed(true, x, y);
}
if (!mHasPerformedLongPress && !mIgnoreNextUpEvent) {
removeLongPressCallback();
if (!focusTaken) {
if (mPerformClick == null) {
//onClick方法回调执行的地方
mPerformClick = new PerformClick();
}
if (!post(mPerformClick)) {
performClickInternal();
}
}
}
...... //省略
通过观察源码，可能导致的没有执行onClick的原因出现在 !mHasPerformedLongPress && !mIgnoreNextUpEvent 与 focusTaken两处if语句，虽然不清楚在判断什么，但是如果走不进一定得不到回调。所以这里需要debug源码。
（ps：debug源码过程遇到了一个头痛的问题，就是studio中所使用的编译源码和手机实际中的framework源码不一致，行数对不上，试了模拟器或使用原生的手机均无法解决该问题。当然应该是有办法可以对齐的，我这里使用了一个比较巧妙的办法，就是虽然行数对不上，但是不断的通过观察局部变量的赋值情况来判断当前执行的位置，后续的源码debug中均采用此方法，虽然笨了一些，但是可操作。）
在debug过程中遗憾的是发现这两处条件均没有问题。
那么接下来就是!post(mPerformClick)方法的分析。
- View#post()方法
public boolean post(Runnable action) {
final AttachInfo attachInfo = mAttachInfo;
if (attachInfo != null) {
return attachInfo.mHandler.post(action);
}
// Postpone the runnable until we know on which thread it needs to run.
// Assume that the runnable will be successfully placed after attach.
getRunQueue().post(action);
return true;
}
其实一开始分析到这里的时候当时已经理论应当的认为可以被正常执行了，因为看到无论走到那个分支似乎都会被post到消息队列中去，我甚至又去重新deug了一番handler源码，再加上第一次分析的时候出现了一些状况，导致debug的时候走进了没问题的情况，当时思路就断掉了，这里也不多说了。
转折出现在了再次对该问题进行分析的时候，debug到这里的时候发现attachInfo居然是null。这个就出乎我的意外了，一个view已经正常在显示了，居然没有attachInfo信息，这个时候我加了一些日志，确定了出问题的item当时的isAttachedToWindow()返回了false，而正常的是true.这个差异点也让我去分析了getRunQueue().post(action)的实现，发现如果是这种情况的话，的确不会回调onClick方法。具体大家可以参考 https://www.jianshu.com/p/405a745aa4d0，大神对该方法的分析。这篇文章的问题也与我们的很类似。
- 接下来怎么办，百度呗。https://blog.csdn.net/kl794756707/article/details/52235155
一开始没有直接去分析源码，而是百度了关于listview的item出现mAttachInfo == null的原因，也让我看到了上述文章，在这片文章中我得到了思路。
llistview中，子item的attchinfo赋值发生在了 addViewInLayout方法的调用，调用点在setupChild方法中。
//android.widget.ListView
private void setupChild(View child, int position, int y, boolean flowDown, int childrenLeft,
boolean selected, boolean isAttachedToWindow) {
......//省略
// Respect layout params that are already in the view. Otherwise make
// some up...
AbsListView.LayoutParams p = (AbsListView.LayoutParams) child.getLayoutParams();
if (p == null) {
p = (AbsListView.LayoutParams) generateDefaultLayoutParams();
}
p.viewType = mAdapter.getItemViewType(position);
p.isEnabled = mAdapter.isEnabled(position);
......//省略
if ((isAttachedToWindow && !p.forceAdd) || (p.recycledHeaderFooter
&& p.viewType == AdapterView.ITEM_VIEW_TYPE_HEADER_OR_FOOTER)) {
attachViewToParent(child, flowDown ? -1 : 0, p);
// If the view was previously attached for a different position,
// then manually jump the drawables.
if (isAttachedToWindow
&& (((AbsListView.LayoutParams) child.getLayoutParams()).scrappedFromPosition)
!= position) {
child.jumpDrawablesToCurrentState();
}
} else {
p.forceAdd = false;
if (p.viewType == AdapterView.ITEM_VIEW_TYPE_HEADER_OR_FOOTER) {
p.recycledHeaderFooter = true;
}
addViewInLayout(child, flowDown ? -1 : 0, p, true);
// add view in layout will reset the RTL properties. We have to re-resolve them
child.resolveRtlPropertiesIfNeeded();
}
也就是说我们的出问题的item没有走进addViewInLayout分支，而是走进了上面的条件中。(isAttachedToWindow && !p.forceAdd) 条件没有满足。
接来就是追踪调用链，看看isAttachedToWindow参数的来源。
//android.widget.ListView
private View makeAndAddView(int position, int y, boolean flow, int childrenLeft,
boolean selected) {
......//省略
// Make a new view for this position, or convert an unused view if
// possible.
final View child = obtainView(position, mIsScrap);
// This needs to be positioned and measured.
setupChild(child, position, y, flow, childrenLeft, selected, mIsScrap[0]);
return child;
}
//android.widget.AbsListView
View obtainView(int position, boolean[] outMetadata) {
......//省略
final View scrapView = mRecycler.getScrapView(position);
final View child = mAdapter.getView(position, scrapView, this);
if (scrapView != null) {
if (child != scrapView) {
// Failed to re-bind the data, return scrap to the heap.
mRecycler.addScrapView(scrapView, position);
} else if (child.isTemporarilyDetached()) {
outMetadata[0] = true;
// Finish the temporary detach started in addScrapView().
child.dispatchFinishTemporaryDetach();
}
}
......//省略
return child;
}
一顿分析追踪到了此处，发现了isAttachedToWindow可能为true的地方，这个时候参与进来的有两个函数 isTemporarilyDetached() 和dispatchFinishTemporaryDetach()，
public final boolean isTemporarilyDetached() {
return (mPrivateFlags3 & PFLAG3_TEMPORARY_DETACH) != 0;
}
public void dispatchStartTemporaryDetach() {
mPrivateFlags3 |= PFLAG3_TEMPORARY_DETACH;
notifyEnterOrExitForAutoFillIfNeeded(false);
onStartTemporaryDetach();
}
public void dispatchFinishTemporaryDetach() {
mPrivateFlags3 &= ~PFLAG3_TEMPORARY_DETACH;
onFinishTemporaryDetach();
if (hasWindowFocus() && hasFocus()) {
notifyFocusChangeToInputMethodManager(true /* hasFocus */);
}
notifyEnterOrExitForAutoFillIfNeeded(true);
}
这几个方法是针对view的一个标志位操作，增加/删除/查询。为了验证是这个地方导致的问题，我又重写了view的dispatchStartTemporaryDetach()和dispatchFinishTemporaryDetach()方法，加上了日志，观察确认了此处问题。而且我发现了一个现象，正常的view被滑出屏幕的时候会被调用一次dispatchStartTemporaryDetach，但是有一个view会被回调两次，而当这个view被复用的时候，该view就是出问题的view。并且该view生成的时候会被回调一次dispatchFinishTemporaryDetach(),也就是我们上面的猜想位置，正常的view不会有这个触发，也就是说正常的view当时的child.isTemporarilyDetached()是false。
- 我对比了一下两次调用堆栈来分析。
listview中的item被滑出屏幕，这个时候会被回收进入缓存池，而进入缓存池前会调用该方法，这次是正常的。
出问题的view，当时是第二个item滑出的时候，调用了正常的一次进入缓存池，而又在接下来滑动了一些距离之后，触发了 fillGap -> obtainView的执行，又被调用了第二次。这里的触发点是上述我们分析的地方的上个条件分支。
View obtainView(int position, boolean[] outMetadata) {
......//省略
final View scrapView = mRecycler.getScrapView(position);
final View child = mAdapter.getView(position, scrapView, this);
if (scrapView != null) {
if (child != scrapView) {
// 这里！！！！！！
mRecycler.addScrapView(scrapView, position);
} else if (child.isTemporarilyDetached()) {
outMetadata[0] = true;
// Finish the temporary detach started in addScrapView().
child.dispatchFinishTemporaryDetach();
}
}
......//省略
return child;
}
我debug到第二次触发点，分析这里的scrapView和child两个对象，scrapView是复用的view，也就是刚刚被移除的第二个，child是adapter的getview方法返回的，恰好是 ‘更多热门转发>>’ 标签view，之前说过，这个标签没有独立的itemType，而是和其他的type一样，在代码中判断位置返回的。也是导致listview的复用机制没有返回正确的view的原因。所以 child != scrapView，这个view又被放回到缓存池。直到标签下一个item的view出来的时候，复用了该view，而该view存在child.isTemporarilyDetached()状态，所以被打上了isAttachedToWindow标记，而没有执行了addViewInLayout方法，只是加入了listview中，所以也是数据显示没有问题的原因。
关键代码
上面一顿分析，也比较乱，估计没人看得懂。现在我们整理一下关键代码。
- Listview中滑动时候的逻辑
//android.widget.AbsListView
boolean trackMotionScroll(int deltaY, int incrementalDeltaY) {
......//省略
// 1，这里处理当item滑出屏幕后，将item放入缓存池
if (position >= headerViewsCount && position < footerViewsStart) {
child.clearAccessibilityFocus();
mRecycler.addScrapView(child, position);
}
......//省略
//2 ，这里处理当下一个item将要滑入屏幕前，准备下一个item的视图
final int absIncrementalDeltaY = Math.abs(incrementalDeltaY);
if (spaceAbove < absIncrementalDeltaY || spaceBelow < absIncrementalDeltaY) {
fillGap(down);
}
......//省略
//3， 这里将缓存池中的item，调用detchfromwindow方法
mRecycler.fullyDetachScrapViews();
......//省略
return false;
}
- 加入缓存池逻辑
//android.widget.AbsListView.RecycleBin
void addScrapView(View scrap, int position) {
......//省略
//这里将缓存的item打上PFLAG3_TEMPORARY_DETACH标记
scrap.dispatchStartTemporaryDetach();
......//省略
}
- 将缓存池中view detach逻辑
void fullyDetachScrapViews() {
......//省略
//这里将缓存池中的item，判断存在PFLAG3_TEMPORARY_DETACH标记的，从window中detch
if (view.isTemporarilyDetached()) {
removeDetachedView(view, false);
}
......//省略
}
//android.view.View
void dispatchDetachedFromWindow() {
......//省略
onDetachedFromWindow();
onDetachedFromWindowInternal();
......//省略
}
//android.view.View
protected void onDetachedFromWindowInternal() {
......//省略
//这里清除掉 PFLAG3_TEMPORARY_DETACH标记
mPrivateFlags3 &= ~PFLAG3_TEMPORARY_DETACH;
......//省略
}
- 准备下一个item逻辑
void fillGap(boolean down) {
......//省略
if (down) {
//这里会有判断是不是需要加载好下一个滑入的item。
fillDown(mFirstPosition + count, startOffset);
......//省略
}
private View fillDown(int pos, int nextTop) {
......//省略
View child = makeAndAddView(pos, nextTop, true, mListPadding.left, selected);
......//省略
}
private View makeAndAddView(int position, int y, boolean flow, int childrenLeft,
......//省略
//生成下一个item
final View child = obtainView(position, mIsScrap);
//对item进行初始化并且加入viewgroup当中
setupChild(child, position, y, flow, childrenLeft, selected, mIsScrap[0]);
return child;
}
View obtainView(int position, boolean[] outMetadata) {
......//省略
//从缓存池中根据itemType获取缓存的item。
final View scrapView = mRecycler.getScrapView(position);
//这里将缓存item传入adapter,我们对数据进行更新。
//这里也是我们的问题点，当标签view将要进入时，由于itemType和转发view是同一个，
//导致拿到的scrapView是上一次缓存的转发view，我们在getView方法中自己进行了类型判断，
//所以返回的child是我们新生成的标签view，所以scrapView != child, 又重新放入了缓存池，
//并且被打上了PFLAG3_TEMPORARY_DETACH标记.而返回的标签view，所以标签view的显示逻辑正常。
//当标签的下一个view进入的时候，则复用了该scrapView，并且存在了该PFLAG3_TEMPORARY_DETACH标记，
//导致了setupChild时候没有进行attachToWindow操作。也就是问题view的mAttachInfo==null，
//无法正常执行post操作。
final View child = mAdapter.getView(position, scrapView, this);
if (scrapView != null) {
if (child != scrapView) {
// Failed to re-bind the data, return scrap to the heap.
mRecycler.addScrapView(scrapView, position);
} else if (child.isTemporarilyDetached()) {
outMetadata[0] = true;
// Finish the temporary detach started in addScrapView().
child.dispatchFinishTemporaryDetach();
}
}
......//省略
return child;
}
private void setupChild(View child, int position, int y, boolean flowDown, int childrenLeft,
boolean selected, boolean isAttachedToWindow) {
......//省略
AbsListView.LayoutParams p = (AbsListView.LayoutParams) child.getLayoutParams();
if (p == null) {
p = (AbsListView.LayoutParams) generateDefaultLayoutParams();
}
p.viewType = mAdapter.getItemViewType(position);
p.isEnabled = mAdapter.isEnabled(position);
......//省略
if ((isAttachedToWindow && !p.forceAdd) || (p.recycledHeaderFooter
&& p.viewType == AdapterView.ITEM_VIEW_TYPE_HEADER_OR_FOOTER)) {
//不会执行view的attachwindow
attachViewToParent(child, flowDown ? -1 : 0, p);
if (isAttachedToWindow
&& (((AbsListView.LayoutParams) child.getLayoutParams()).scrappedFromPosition)
!= position) {
child.jumpDrawablesToCurrentState();
}
} else {
p.forceAdd = false;
if (p.viewType == AdapterView.ITEM_VIEW_TYPE_HEADER_OR_FOOTER) {
p.recycledHeaderFooter = true;
}
//会执行view的attachwindow
addViewInLayout(child, flowDown ? -1 : 0, p, true);
child.resolveRtlPropertiesIfNeeded();
}
......//省略
}
总结
1，View#post()方法的实现了解不透彻
2，实现多类型的item，要使用提供itemType方式去做，不然就会出现上面共享缓存问题。就是你这边区分了类型，但是listview不知道啊。
3，在listview 的adapter回调方法中，不要自我想当然的实现一些奇淫巧技。也让我想起了之前一位同事乱改getCount方法导致的一个问题。
