问题
本文没有特别的知识点，仅仅是记一次 ui 异常的问题排查和解决过程。如果你也遇到过 WrapHeightListView 测量高度异常，高度稍微多一点或是少一点，那么可以看看，可能也是由和本文同样的原因引起的，当然咱也是在充满业务逻辑的代码中排查出了原因。
前段时间测试过来和我说我负责的详情页 ui 有问题。
怎么可能！我没改代码！不是我！好吧，我真的没改，先来看看啥问题。
是详情页的点评模块下边突然多出了一块白色的区域。这个是项目中原有的点评模块的代码，这个详情页只是通过添加这个 Fragment 引入进来的。看到这就对测试说，我一会看看下，改好告诉你。
放下新版本的开发工作，回到我们即将上线的分支，开始找问题，心想着是谁又动了这个包含着复杂逻辑的点评列表，也不多进行一下逻辑判断。其实多少有点不情愿去看的，毕竟这个点评的 Fragment 的包含逻辑是这样的：
Fragment(ListView 点评) -> 自适应高度的 ViewPager -> Fragment -> ListView 相关点评
ps: 箭头和括号都代表包含关系，两个 ListView 共用了同一个 Adapter，另外该 Adapter 全品类共用。
奈何测试就认准了问题出在我的页面上。经过一系列的排查 padding，margin 我的表情是这样的
MMP 都看了几遍了没有问题啊！然后我就找了最近整过点评的同事，有苦咱不能自己吃，我眼睛都快看瞎了！但是结果是悲剧的，虽然怀疑是测量的原因，但是最终并没有找出原因，咱测试也因版本上线紧迫、这个不是必现（当时以为不是必现，现在发现是）、不会影响到业务功能等原因暂时放过一马。
但是还是在我心里搁着呀！最近忙完，又开始捡起这个问题来，所以说有些事情不能催，咱这不是挺上心的么，催了还影响思维！
过程
一、
因为页面的嵌套逻辑过于复杂，简单的打开手机布局边界的功能已经不能给我们提供有效的判断了，所以这回我用了 AndroidStudio 的 Layout Inspector 功能。具体路径在：Tools -> Android -> Layout Inspector。
点击后，可以选择需要分析的应用以及该应用的界面，当然你得先在手机上打开该界面，然后就会为我们生成该界面的快照。
左边是具体的布局列表，中间是直观的目前手机屏幕上的快照，右边是我选中的布局的属性，可以看到我标 1、2 的布局就是我目前选中的。
从 3 中可以看的我们的 WrapHeightListView 确实是没有 padding 的。借助于这个功能我计算得到多出来的这部分空白区域高度为 25。
所以的确是我们的 WrapHeightListView 测量的高度高了，但是为什么会这样呢？而且这个 ListView 也仅仅是最常见的一种写法：
public class WrapHeightListView extends ListView {
public WrapHeightListView(Context context) {
super(context);
}
public WrapHeightListView(Context context, AttributeSet attrs) {
super(context, attrs);
}
public WrapHeightListView(Context context, AttributeSet attrs, int defStyle) {
super(context, attrs, defStyle);
}
@Override
public void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
int expandSpec = MeasureSpec.makeMeasureSpec(Integer.MAX_VALUE >> 2,
MeasureSpec.AT_MOST);
super.onMeasure(widthMeasureSpec, expandSpec);
}
}
难道是我们的自适应高度的 ViewPager 的问题？
二、
第二步尝试我仅仅是给这个点评列表多添加了一个条目，但是结果让我有较大的收获 …… 嗯，这个间距加大了。
经过上边步骤一的计算，得到多出来的这部分空白区域高度为 50，翻了一倍，这个就可以排除了自适应高度的 ViewPager 的嫌疑，把问题定位到了 WrapHeightListView，甚至可以说跟我们的 Adapter 里使用的 ViewHolder 的逻辑有关系，毕竟 Adapter 的写法也中规中矩没有复杂的逻辑在里面。
三、
当然顺利到达这个第三步之前，我还对比了 “查看全部点评” 里面的点评列表和我的详情页的区别：
1、两者的 ListView 不一样，一个就是普通的下拉刷新的 ListView，一个是 WrapHeightListView；
2、进入点评列表，当点评的文字较少的时候就有一个明显的隐藏下箭头的过程；
这个逻辑是当点评超过三行的时候，就会显示下箭头，当少于等于三行的时候就隐藏。然后注意到这个箭头的高度加上 margin 与上边计算的 25 很接近，这就促使我去看了一下隐藏这个箭头的代码。
//CommentViewHolder bindData 方法中
public void bindData(Data data) {
textView1.post(new Runnable() {
@Override
public void run() {
iconArrow.setVisibility(isMoreThen3Lines(textView1)?View.VISIBLE:View.GONE);
}
});
}
private boolean isMoreThen3Lines(TextView tv) {
//...
}
主要是先前的这位同学希望 textView1 绘制完了，通过 getLayout() 拿到 Layout 的对象（这里应该是 StaticLayout 类），所以把下箭头的显示隐藏逻辑放到了 post 方法中，导致 WrapHeightListView 在 iconArrow 隐藏之前就测量完了，然后后边 iconArrow Gone 掉之后又没有引发重新布局所以有了一开始莫名其妙的问题。
解决
既然已经知道了原因，那么我们第一步就是要去掉那个 post() 方法，然后当TextView.getLayout() 为空的时候自己创建一个 StaticLayout，用于测量TextView 里面的行数。
private boolean isMoreThen3Lines(Context context, TextView tv) {
Layout layout = tv.getLayout();
if (null == layout) {
//这里应该拿出去，只进行一次计算
DisplayMetrics dm = new DisplayMetrics();
((Activity) context).getWindowManager().getDefaultDisplay().getMetrics(dm);
int margin = (int) TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_DIP, 20, dm);
layout = new StaticLayout(tv.getText().toString(), tv.getPaint(), dm.widthPixels - margin,
Layout.Alignment.ALIGN_NORMAL, 1f, 0, false);
}
int lines = layout.getLineCount();
return lines > 3 || (lines > 0 && layout.getEllipsisCount(lines - 1) > 0);
}
最后
看似很简单的问题，结果定位用了那么长的时间，不过通过这个问题，起码咱用好了 AndroidStudio 的 Layout Inspector 功能呀。另外有兴趣的同学可以自己写个 Demo 测试一下，这个问题是必现的。至于之前为啥以为这个情况不是必现的问题，那是因为我司的产品卖的太火热了，一般直接展示点评就好了，所以就轮不到相关点评出来展示异常，2333。
