问题
本文没有特别的知识点，仅仅是记一次 ui 异常的问题排查和解决过程。如果你也遇到过 WrapHeightListView 测量高度异常，高度稍微多一点或是少一点，那么可以看看，可能也是由和本文同样的原因引起的，当然咱也是在充满业务逻辑的代码中排查出了原因。
前段时间测试过来和我说我负责的详情页 ui 有问题。
zhenjing.jpg
怎么可能！我没改代码！不是我！好吧，我真的没改，先来看看啥问题。
wenti1.png
是详情页的点评模块下边突然多出了一块白色的区域。这个是项目中原有的点评模块的代码，这个详情页只是通过添加这个 Fragment 引入进来的。看到这就对测试说，我一会看看下，改好告诉你。
放下新版本的开发工作，回到我们即将上线的分支，开始找问题，心想着是谁又动了这个包含着复杂逻辑的点评列表，也不多进行一下逻辑判断。其实多少有点不情愿去看的，毕竟这个点评的 Fragment 的包含逻辑是这样的：
Fragment(ListView 点评) -> 自适应高度的 ViewPager -> Fragment -> ListView 相关点评
ps: 箭头和括号都代表包含关系，两个 ListView 共用了同一个 Adapter，另外该 Adapter 全品类共用。
奈何测试就认准了问题出在我的页面上。经过一系列的排查 padding，margin 我的表情是这样的
meng.jpg
MMP 都看了几遍了没有问题啊！然后我就找了最近整过点评的同事，有苦咱不能自己吃，我眼睛都快看瞎了！但是结果是悲剧的，虽然怀疑是测量的原因，但是最终并没有找出原因，咱测试也因版本上线紧迫、这个不是必现（当时以为不是必现，现在发现是）、不会影响到业务功能等原因暂时放过一马。
但是还是在我心里搁着呀！最近忙完，又开始捡起这个问题来，所以说有些事情不能催，咱这不是挺上心的么，催了还影响思维！
过程
一、
因为页面的嵌套逻辑过于复杂，简单的打开手机布局边界的功能已经不能给我们提供有效的判断了，所以这回我用了 AndroidStudio 的 Layout Inspector 功能。具体路径在：Tools -> Android -> Layout Inspector。
点击后，可以选择需要分析的应用以及该应用的界面，当然你得先在手机上打开该界面，然后就会为我们生成该界面的快照。
capture1.png
左边是具体的布局列表，中间是直观的目前手机屏幕上的快照，右边是我选中的布局的属性，可以看到我标 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 的问题？
二、
第二步尝试我仅仅是给这个点评列表多添加了一个条目，但是结果让我有较大的收获 …… 嗯，这个间距加大了。
wenti2.png
经过上边步骤一的计算，得到多出来的这部分空白区域高度为 50，翻了一倍，这个就可以排除了自适应高度的 ViewPager 的嫌疑，把问题定位到了 WrapHeightListView，甚至可以说跟我们的 Adapter 里使用的 ViewHolder 的逻辑有关系，毕竟 Adapter 的写法也中规中矩没有复杂的逻辑在里面。
三、
当然顺利到达这个第三步之前，我还对比了 “查看全部点评” 里面的点评列表和我的详情页的区别：
1、两者的 ListView 不一样，一个就是普通的下拉刷新的 ListView，一个是 WrapHeightListView；
2、进入点评列表，当点评的文字较少的时候就有一个明显的隐藏下箭头的过程；
capture2.png
这个逻辑是当点评超过三行的时候，就会显示下箭头，当少于等于三行的时候就隐藏。然后注意到这个箭头的高度加上 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。
网友评论