背景
为了降低app的卡顿率，项目做了一次优化，将首页的的滑动控件viewPager改成了viewPager2，前者是一次性加载所有的布局文件，后者只会加载目标页面的布局文件，减少了计算和绘制的时间。在开发完后，发现了一个很奇怪的bug。如左图所示，右图是正常图片，看了各控件的展示，发现内部控件的宽高为0。
结论
先说结论，经过长时间的排查比对，发现问题ConstraintLayout布局上，只要它的子控件设置了paddingStart和paddindEnd，就会显示不正常，解决方法就是替换成paddingLeft和paddingRight，就没问题了。
排查过程
布局显示不正常，根据我的开发经验， 很可能是跟上编舞者绘制节奏，所以我加了一个post()方法，给他一个单独的绘制时间，结果不如我意，还是原样。调用requestLayout()和invalidate()，也都没有效果。
经验不顶用，只能从问题本身出发，这次优化的改动是改成viewPager2,它内部是通过recycleView实现的，那会不会recycleView做了什么处理？这个view起先试隐藏的，满足条件后才会展示。我研究了viewPager2的源码以及recycleView的源码，发现它做的仅仅是缓存，对于addView并没有干预，这个线索又断了.....。
<com.view.widget.LastReadView
android:id="@+id/last_read_view"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_gravity="bottom|end"
android:layout_marginStart="@dimen/dp_12"
android:layout_marginEnd="@dimen/dp_12"
android:layout_marginBottom="@dimen/dp_14"
android:minHeight="@dimen/dp_68"
android:visibility="gone"
tools:visibility="visible" />我再试着从布局本身出发，我想到了三种方案，都能解决这个问题。
1.将lastReadView的根布局改成merge标签。
2.在获取到数据后inflateView，然后addView。
3.将LastReadView继承自FrameLayout（原先继承ConstraintLayout）。
虽然问题解决了，但是真正原因是什么呢？好奇心驱动着我继续向前探索。我想研究ConstraintLayout的源码，发现本地sdk内尽然找不到源码，于是想到到外网上找，终于功夫不负有心问，找到了androidx.constraintlayout.core包的源码，从头看了一遍，大致意思懂了，还是没有找到答案。它在和我捉迷藏嘛，还躲的这么深，最后只能用最笨的办法，穷举法。写demo，把变量一个一个去掉，代码一行一行比对，发现了当我把paddingStart和paddingEnd全部改成对应的paddingLeft和paddingRight时，可以正常显示了，终于找到了元凶，这一刻内心的喜悦溢于言表，不枉我周末花的大半天时间。
为什么paddingStart会导致测量出错，这个原因肯定是藏在源码里，我现在还没找到答案，如果有知道原因的好心人，请留言，我也会继续探索真正的原因。
