view measure

view 自身有一个高度是自己的内容和自己的配置的属性决定的，内容就是自己的背景，drawabe，文字大小等自己画的画，属性就是minWith，minHeight。抛开其他的，view是希望自己的这些内容显示出来的，所以期望一个最小的大小，这个大小咱们先记为"大小1"，但是Android 的测量过程view的大小是受父视图给的一个大小限制的，其实可以理解为，父视图"最大"也只能这么大，子视图太大了，也显示不出来，所以子视图就别超过父视图给你的大小了。这个父视图最大能有多大呢？这是有屏幕的大小减去父视图的margin 再减去 padding，剩下的才是给子视图的。这个剩下的大小咱们记为"大小2"。那么如果自己的期望(match_parent)是和父视图的大小相匹配那么最终view的大小就是"大小2"，如果自己的期望(wrap_content)是能包裹自己的内容就可以了那么自己的大小就是"大小1与大小2的最小值"。因为剩余的屏幕空间不够了，所以就取最小值。view自己说的不算 所以自己的大小总有一个期望：尽量能显示自己的内容，毕竟自己画的画。所以view中有一个getSuggestedMinimumWidth 函数，就是期望至少能把自己的背景给显示出来（如果被继承了，那就是view 期望自己的哪个部分被显示出来，描述不准确也许不是背景，就是那么个意思）。以上说的都是match_parent和wrap_content的模式。所以android 的测量流程应该是：传给view一个限定大小，然后view根据自己的期望模式才计算出自己最终的大小。这样我感觉才符合人的正常思维逻辑，而不是通过在父视图中通过 getChildMeasureSpec（）计算一个MeasureSpec 传给子veiw的measure()再进行计算。这样理解起来不太直观。因为正常人都已经在xml中配置了期望了，你又在getChildMeasureSpec计算中给我修改了。这样不直观。应该把getChildMeasureSpec，这里的逻辑迁移到View中计算最终结果处。比较自己的模式和父模式再得出一个新的模式再传给子view感觉又点多余。

所以这样的逻辑才好理解，从屏幕大小开始，一路传下去，减去每一层的margin和pading，剩下的就是下一层允许的最大值，下一层要是配置了match_parent,就是剩余的大小，下一层要是配置了，wrap_content 就是剩余大小和自己内容大小的最小值。

那要是自己设置了绝对大小，那跟测量就没关系了，就是自己设置的大小，那要是自己是unspecial模式，那跟传进来的大小也没关系了，就是自己，内容的大小（待定）