哈喽小伙伴们！是不是经常遇到「为什么onResume里拿不到View宽高」这种崩溃瞬间？或者自定义个按钮总画歪、TextView宽度超屏？今天咱就以「老友唠嗑」的姿势扒一扒Android View到底怎么「长」到屏幕上的——绘制流程这事儿kan似复杂，但拆开来真没那么玄乎！

先从「谁启动了绘制」说起吧

咱dou知道Activity里调setContentView就Neng显示界面但你有没有好奇过：* setContentView背后到底发生了啥？*

简单说啊——当你在Activity.onCreate里写下setContentView时并不是立刻就把布局画到屏幕上了！这背后有俩关键角色：DecorView和ViewRootImpl。

DecorView是什么？它是Android界面Zui顶层的「大容器」——不管你 setContentView 塞什么布局进去,Zui终dou会被装进DecorView这个「壳子」里 ；而 ViewRootImpl 则是连接 DecorView 和系统窗口 的「桥梁」,它会牵头完成整个绘制流程~

害,说白了就是: * setContentView只是把布局文件解析成 View 树,真正让 View「显形」,得靠 ViewRootImpl 喊一句「开始画吧！」*

第一幕：Measure——给 View「量体裁衣」

咱先打个比方:假如你要Zuo件衣服,裁缝会告诉你「Zui多Zuo170cm高」或者「就Zuo165cm」,你得根据这些要求算出衣服Zui终尺寸——这就是 Measure 阶段要干的事: 计算 View 的宽高~

主角登场：MeasureSpec

说到 Measure ,绕不开一个词叫「MeasureSpec」,它其实就是父布局给子 View 的「尺寸约束说明书」,里面包含俩信息: - Mode : 三种可Neng—— - EXACTLY:「就按这个尺寸来!」对应 layoutwidth/height = matchparent或具体数值； - ATMOST:「Zui多这么大,别超!」对应 wrapcontent； - UNSPECIFIED:「随便你长多大!」hen少见,一般是 ScrollView 这种需要子 View 自由发挥高度的时候才用. - Size : Mode对应的具体数值.

举个栗子🌰:Ru果TextView设置了android:layout_width="wrap_content",父LinearLayout宽300dp—那父布局给TextView的MeasureSpec就是AT_MOST模式+Size=300dp. TextView会根据自己文本内容算宽度,但绝对不会超过300dp~

Measure 的核心步骤

父布局遍历子 View:从根节点DecorView开始,一层一层往下遍历所有子 View.

计算子 View 的 MeasureSpec:父布局会根据自己拿到约束+子 View 的 LayoutParams ,算出该给子 View 什么 MeasureSpec ——这点hen重要!不是子 View 想多大就多大,全kan父 layout 的脸色😒.

子 View 调用 onMeasure:每个子 View 根据拿到 MeasureSpec ,计算自己Zui终宽高.

等等!这里有个超常见坑!默认 onMeasure 的实现不一定靠谱!

kankan官方源码里view默认 onMeasure : java protected void onMeasure { setMeasuredDimension, widthMeasureSpec), getDefaultSize, heightMeasureSpec)); } 这里 getDefaultSize Ru果遇到 ATMOST模式时,返回值居然是 suggestedMinimumWidth !也就是说:Ru果不重写 onMeasure , wrapcontent 和固定大小没区别?!

害我当初自定义一个圆形ProgressBar时吃过大亏!设成wrap_content结果还是占满全屏…后来才发现必须重写onMeasure算直径😓~

第二幕：Layout——给 View「安个家」

测完尺寸还不够啊!得告诉view:「你该往左挪5px?还是往上靠20dp?住几号房间? ——这就是 Layout阶段:确定view在父布局中的位置~

Layout 的核心秘密

Layout阶段Zui关键函数叫 view.layout ——这四个参数是什么意思?kan名字dou知道:l=left,t=top,r=right,b=bottom.而我们常用 getHeight/getWidth,本质上就是 b-t 和 r-l !

哦!原来如此!所以只有等 layout执行完后,mBottom/mTop这些字段才有值,才Neng拿到正确宽高~那问题来了:什么时候执行 layout ?

Activity生命周期 vs Layout时机

肯定有人试过在Activity.onResume里写Log.d);结果打印出来全是"width=0" ——为啥?kan流程图Zui清楚!:

scss ActivityThread.handleResumeActivity → Activity.onResume → WindowManager.addiew → VieoRootImpl.setVie → requestLayout → scheduleTraversals → Choreographer回调→ performTraversals → measure→ layout→ draw...

kan到没?onResume执行完之后,vie才开始measure/layout/draw,所以此时getWidth肯定拿不到有效值!这点我踩过N次坑…后来干脆记一句话:想拿vie宽高?要么用post,要么等GlobalLayoutListener回调!

第三幕：Draw——给 Vie「化妆上色」

终于到Zui后一步啦～经过 measure算大小(layout定位置后,vie就要把自己「画到Canvas画布上显示出来啦～ Draw过程分五步走,,按顺序来哦!:

Draw步骤大揭秘

1.先画背景):不管是不是纯色背景图还是渐变,先铺底—不然内容会跟背景叠在一起乱套; 2.再画自己):自定义vie就在这里发力啦!想画圆? drawCircle;想写字? drawText;就连TextView默认也是在这里把文本画上去滴; 3.接着画孩子):Ru果当前vie是ViewGroup,就得遍历所有子vie调用它们 draw,顺序按添加先后—后加进去 child会覆盖前面 ; 4.然后画装饰):比如说滚动条呀焦点高亮框之类小配件; 5.Zui后补个焦点效果):万一当前vie获得焦点了得标个记不是～

举个生活化例子🌰:假设现在要 Draw一个带图标的按钮—先是灰色背景),接着画上图标),没有孩子所以跳过dispatchDraw,Zui后加个按下时变蓝效果)～完美✨~

Vie vs VieGroup :绘制差异在哪?

hen多人搞不清Vie和ViewGroup绘制区别—其实特简单!: - Vie:只需要负责自己 onDraw,因为没有孩子嘛; - ViewGroup:除了调用自身 onDraw ,还必须重写 dispatchDraw 遍历所有 child.draw.不然你的LinearLayout放俩按钮只会显示第一个!

那些年我们踩过の坑 & 解决办法

唠了这么多理论,,来点实战技巧吧～dou是血泪教训!:

Q1 : onXXX生命周期中如何安全获取 vie宽高?

A:永远别在 onCreate/onStart/onResume直接 getWidth/getHeight !必为零!!推荐两种办法: ① vie.post{public void run{//这里拿宽高Neng成功}}) —原理hen简单 post把任务扔到主线程消息队列尾部,,等 measure/layoutdou干完才执行; ② view.getViewById.addOnGlobalLayoutListener{...}) —监听全局 layout变化,,第一次回调时就Neng拿到正确值~不过记得用完注销 listener哦不然会内存泄漏!.

Q2 : invalidate 和 requestLayout 有啥区别?

A:前者只管重绘内容后者管重新测量+重新布局+重绘.打比方:textview.setText后只需invalidate,因为文字变化只影响 draw;但Ru果你setText之后又 setLayoutParams,那就必须调用 requestLayout,否则新宽度不会生效—因为LayoutParams变了属于 measure阶段管辖范围呀!.

Q3 :为什么 ScrollVie裹着 ListVie总显示不全/高度错误?

A:本质原因 ScrollVie对子 Vie测量时给出 Mode=UNSPECIFIED ! ListVie接到这种指令后为省资源直接返回自身item高度*item总数导致整个列表超长…解决办法要么给ListVie固定高度要么重写ListVie onMeaure强制按实际item数算高度~

Zui后一下吧～Android Vie绘制流程一句话概括就是:

由 VeiwRootImpl牵头 -> measure算好身材 -> layout安准位置 -> draw画上妆容->Zui终显示在屏幕上.中间穿插着各种约束条件与生命周期小陷阱,,只要摸清楚每个环节顺序与原理,,不管自定义控件还是解决兼容问题douNeng游刃有余啦～

怎么样??这次唠明白没??以后再遇到 view相关bug可别慌哦!,照着这个思路一步步排查肯定Neng找到问题所在!!哈哈~

---