剛接觸Android布局時幾乎所有人學(xué)的第一個容器就是線性布局LinearLayout。它把子View按水平或垂直方向排成一條直線看起來沒有任何門檻但實(shí)際寫起來兩個按鈕寬度為什么不一致layout_gravity設(shè)了沒反應(yīng)嵌套一多就卡這類問題就算寫了三五年代碼的人也會踩。這篇文章我打算把線性布局從設(shè)計(jì)邏輯、屬性原理、權(quán)重計(jì)算到真實(shí)頁面搭建、排錯方法完整過一遍既適合剛?cè)腴T的新手也適合那些被gravity和weight折磨到懷疑人生的開發(fā)者。1. 為什么是線性布局設(shè)計(jì)邏輯與適用邊界1.1 它解決的到底是什么問題線性布局解決的核心問題只有一句話讓一組子View按照先后順序?qū)R排列。垂直排列就是從上往下一個個排水平排列就是從左往右一列列排。這里的對齊不是說隨便擺而是系統(tǒng)自動按順序計(jì)算每個子View的位置開發(fā)者只需要告訴它方向、尺寸、權(quán)重剩下的坐標(biāo)計(jì)算全部交給框架。這個邏輯和生活中排隊(duì)很像大家按順序站成一列每個人的位置由前面的人決定。對應(yīng)到Android里父布局記錄前一個View的結(jié)束位置把它當(dāng)作下一個View的起始位置中間再留出margin、padding等空隙。LinearLayout默認(rèn)不會重疊子View也不會自由擺放這也是它名字里線性二字的由來。很多人覺得線性布局太簡單不值得深究但從實(shí)際項(xiàng)目看它依然是出現(xiàn)頻率最高的基礎(chǔ)布局之一。原因很現(xiàn)實(shí)很多界面天然就是一行一行或者一列一列排下來的用LinearLayout寫起來最短最直白。尤其在不同屏幕尺寸下配合權(quán)重能做到漂亮的自適應(yīng)這是其他布局很難替代的。1.2 為什么它依然值得認(rèn)真學(xué)現(xiàn)在ConstraintLayout被官方主推很多人直接從約束布局入門導(dǎo)致對LinearLayout的底層邏輯一知半解。這里我想說一個觀點(diǎn)LinearLayout是理解Android測量與布局機(jī)制的最佳入口沒有之一。原因在于LinearLayout的行為足夠簡單可預(yù)期非常適合用來學(xué)習(xí)measure、layout這兩個核心階段。你設(shè)置一個wrap_content系統(tǒng)怎么量設(shè)置match_parent系統(tǒng)怎么量設(shè)置weight后又發(fā)生了什么變化——這些在LinearLayout里很容易通過實(shí)驗(yàn)觀察。把這一套搞明白后面再看ConstraintLayout、FrameLayout很多概念都是相通的。從實(shí)際開發(fā)效率角度看線性布局也不是能被完全替代的。登錄頁面的縱向排列、底部按鈕的一行平分、列表項(xiàng)里左側(cè)圖標(biāo)右側(cè)文字的經(jīng)典結(jié)構(gòu)用LinearLayout寫出來代碼量少可讀性高配合layout_weight做比例分配尤其方便。與其盲目追求少嵌套而把所有布局都強(qiáng)行改成約束布局不如先確認(rèn)線性布局在這個場景下是不是更直接的答案。1.3 哪些場景應(yīng)該繞開線性布局不是萬能鑰匙。一旦界面需要自由定位、層疊覆蓋、復(fù)雜網(wǎng)格時硬用LinearLayout就會堆出一大串嵌套。我見過最夸張的案例是一個簡單的四宮格開發(fā)者用三個橫向LinearLayout嵌在一個垂直LinearLayout里每行再套兩個子LinearLayout代碼寫了上百行測量時系統(tǒng)層層計(jì)算打開頁面有明顯卡頓。這種場景顯然應(yīng)該用GridLayout或者ConstraintLayout。不過嵌套本身也不是洪水猛獸兩三層的線性布局性能完全沒問題真正要警惕的是超過四層的深度嵌套。因?yàn)槊看蝝easure都是從父到子遞歸調(diào)用層級越深調(diào)用次數(shù)越多遇到復(fù)雜布局很容易掉幀。我自己的選擇標(biāo)準(zhǔn)很簡單內(nèi)容排列符合線性順序就用LinearLayout需要按行列網(wǎng)格就考慮GridLayout需要自由約束、百分比定位、復(fù)雜對齊就上ConstraintLayout。每種布局都有它的生態(tài)位沒必要神化某一個。2. 核心屬性全拆解從orientation到weightSum2.1 orientation與寬高尺寸LinearLayout最根上的屬性是android:orientation、android:layout_width和android:layout_height。orientation只有兩個值horizontal和vertical默認(rèn)值是horizontal。這個默認(rèn)值是個經(jīng)典坑很多人寫LinearLayout時忘了聲明orientation結(jié)果發(fā)現(xiàn)子View全部橫著排跟直覺里的應(yīng)該豎著排完全相反。尺寸方面match_parent表示占滿父容器剩余空間wrap_content表示包住內(nèi)容也可以寫具體dp值。線性布局有一個很重要的特性在主軸方向也就是orientation指定的方向上子View的layout_width或layout_height會直接影響后面的權(quán)重計(jì)算。很多權(quán)重不生效的假象根源就是子View在主軸方向上用了wrap_content導(dǎo)致初始尺寸不為零分掉了一部分空間。副軸方向通常簡單一些。垂直布局時副軸是水平方向子View寬度可以match_parent也可以wrap_content再配合layout_gravity控制對齊。水平布局時副軸是垂直方向子View高度一般wrap_content再用gravity控制垂直居中。還要區(qū)分兩個尺寸概念margin和padding。margin是當(dāng)前View與外部兄弟節(jié)點(diǎn)或父容器之間的間距padding是當(dāng)前View內(nèi)部內(nèi)容與自身邊框之間的間距。兩者在測量時的計(jì)算方式不同margin會占用父容器的剩余空間padding則在布局內(nèi)部被消耗掉。2.2 gravity與layout_gravity的混淆點(diǎn)這兩個屬性是新手重災(zāi)區(qū)幾乎每周都會有人因?yàn)檫@個寫錯布局。android:gravity是加在LinearLayout父容器上的控制的是所有子View內(nèi)容在容器內(nèi)的對齊方式android:layout_gravity是加在子View上的控制的是這個子View在父容器內(nèi)的對齊方式。名字長得像作用對象完全不同。舉一個具體對比在垂直LinearLayout里放一個TextViewTextView寬度是wrap_content。如果給LinearLayout設(shè)置gravitycenter_horizontal那么TextView會水平居中如果給LinearLayout設(shè)置gravitybottom容器里的TextView會被壓在底部。但如果給TextView本身設(shè)置layout_gravitycenter_horizontal同樣會居中——看起來結(jié)果一樣實(shí)際原理不同。一個是父容器統(tǒng)一指揮所有子View一個是子View單獨(dú)表達(dá)位置訴求。還有一個經(jīng)常被忽略的點(diǎn)在LinearLayout的主軸方向上layout_gravity往往無效。垂直布局時子View垂直方向的位置已經(jīng)被排列順序決定了你寫layout_gravitycenter_vertical基本沒用水平布局時layout_gravitycenter_horizontal也不起作用。想要在主軸方向偏移只能用布局嵌套或者margin來做。2.3 weight與weightSum的定位權(quán)重是LinearLayout區(qū)別于其他布局的最核心能力它的作用可以概括為一句話讓子View按比例瓜分剩余空間。這里的關(guān)鍵詞是剩余而不是整體。后面我會專門講計(jì)算公式現(xiàn)在先建立一個整體印象。weightSum表示父容器聲明出來的總權(quán)重值。默認(rèn)情況下系統(tǒng)把所有子View的weight值相加作為總分母。如果手動指定weightSum分配比例就以這個數(shù)字為準(zhǔn)。給人的感覺像是人為規(guī)定了整個空間分成多少份再讓各個子View申領(lǐng)其中的幾份。一個典型場景底部兩個按鈕想平分寬度?？梢园褍蓚€Button都放在一個水平LinearLayout里寬度都設(shè)0dpweight都設(shè)為1父容器不聲明weightSum系統(tǒng)自動算出總權(quán)重為2每個按鈕分到一半。如果想做成第一個按鈕占四分之一第二個按鈕占四分之三就把第一個weight設(shè)為1第二個設(shè)為3總權(quán)重為4。如果容器里還混著沒有weight的子View那些View先按照layout_width或layout_height占據(jù)原始尺寸剩下的空間才交給設(shè)置了weight的View去分。這個機(jī)制很容易讓人困惑但理解了公式后一切都會變得清晰。2.4 divider與基線對齊divider相關(guān)屬性常被忽略但很實(shí)用。android:divider指定一個Drawable作為分割線android:showDividers控制顯示位置取值有none、beginning、middle、end支持用豎線分隔多個值。如果列表項(xiàng)之間需要一條細(xì)線不用額外畫View直接在LinearLayout里配一個shape Drawable就能搞定。使用divider時有幾個細(xì)節(jié)容易出錯。第一showDividers默認(rèn)是none只設(shè)divider不設(shè)showDividers什么都不會顯示。第二divider的尺寸和方向要匹配水平LinearLayout里的分割線通常是一個寬1dp、高match_parent的矩形垂直LinearLayout里的分割線則相反。第三dividerPadding不是每個方向都生效在水平LinearLayout里設(shè)置dividerPadding改的是分割線上下兩端的間距而不是左右間距。baselineAligned是另一組關(guān)于文字基線的屬性。默認(rèn)值為true表示水平LinearLayout里的子View按文字基線對齊。如果你在水平方向排了一個TextView和一個EditText希望它們的文字底邊對齊而不是頂部對齊用這個屬性就可以實(shí)現(xiàn)。baselineAlignedChildIndex可以指定以第幾個子View的基線為基準(zhǔn)。但實(shí)際項(xiàng)目里基線對齊很容易造成用起來莫名其妙的偏移尤其是混入Button、ImageView這種沒有明確文本基線的控件時我會直接關(guān)掉baselineAligned改用layout_gravitycenter_vertical保持視覺居中。3. 權(quán)重機(jī)制深入公式、案例與常見坑3.1 剩余空間分配公式的手算過程要真正搞懂weight必須做一次手算。假設(shè)父容器是一個水平LinearLayout總寬度為200dp里面有兩個Button。按鈕A設(shè)置layout_width100dpweight1按鈕B設(shè)置layout_width50dpweight1。系統(tǒng)第一遍測量時先按照每個子View的layout_width算出原始尺寸A占100dpB占50dp兩者合計(jì)150dp。父容器總寬200dp剩余空間就是200減150等于50dp。接著開始分配剩余空間總權(quán)重是1加1等于2A分到50乘以二分之一等于25dpB也分到25dp。最終A寬125dpB寬75dp?？吹竭@里你應(yīng)該明白了權(quán)重不是在原始寬度上按比例縮放而是在剩余空間上按比例分配。所以兩個子View即使weight完全相同如果原始尺寸不同最終寬度也完全不同。這就是為什么很多人寫了weight之后發(fā)現(xiàn)怎么還不是均分的原因。如果你想讓兩個子View嚴(yán)格等比正確做法是把它們的主軸尺寸都設(shè)為0dp。此時A原始尺寸是0B原始尺寸也是0剩余空間等于父容器總寬200dp總權(quán)重為2A和B各分到100dp真正實(shí)現(xiàn)了五五分。3.2 wrap_content與0dp的經(jīng)典糾葛很多人在使用weight時保留layout_widthwrap_content期望達(dá)到按比例分配的效果結(jié)果發(fā)現(xiàn)內(nèi)容更長的那個View明顯更寬。這仍然是公式在起作用。我們再來算一個例子父容器寬300dp兩個TextView左邊內(nèi)容實(shí)際寬80dp右邊內(nèi)容實(shí)際寬20dp兩者weight都為1。第一遍測量后左邊原始尺寸80右邊原始尺寸20剩余空間200。按權(quán)重分配后兩邊各得到100。于是左邊最終寬度是180右邊最終寬度是120。表面上看兩個View的weight都是1但寬度比是3比2而不是1比1。內(nèi)容越長原始尺寸越大差距越明顯。解決套路非常簡單只要你想在主軸方向按權(quán)重精確分配就把主軸方向上的layout_width或layout_height設(shè)置為0dp。0dp消除了原始尺寸這個變量讓剩余空間成為唯一決定性因素。反過來如果你希望先讓View按照內(nèi)容自適應(yīng)、再用權(quán)重處理多余空間那就要有意保留wrap_content并利用上面的公式做混合布局。3.3 weightSum的使用邊界與兩個大坑weightSum的常見用法是規(guī)定剩余空間的分母。比如有三個按鈕我希望B占剩余空間的一半A和C只按內(nèi)容顯示?？梢越o父容器設(shè)android:weightSum2給B設(shè)置android:layout_weight1A和C不設(shè)weight。這樣剩余空間先減去A和C的原始寬度剩余值乘以二分之一歸B。這個寫法很適合做自適應(yīng)間距比寫死dp值優(yōu)雅得多。但兩個坑必須記住。第一個如果所有子View的weight之和大于weightSum系統(tǒng)不會報錯表現(xiàn)是子View們按各自權(quán)重?fù)屨汲龇帜傅姆蓊~最終比例可能完全失控。第二個如果weightSum設(shè)得很大而某個子View的weight也很大的時候這個View可能會把剩余空間全部吃掉其他子View被壓縮到最小甚至消失。排查這類問題最直接的辦法是把weightSum先刪掉觀察默認(rèn)情況下的比例確認(rèn)無誤后再把總和帶進(jìn)去。如果刪掉后一切正常加回來就出問題那一定是weightSum與子View總權(quán)重不匹配。3.4 測量過程中到底發(fā)生了什么雖然普通開發(fā)者不需要精通View的measure源碼但知道基礎(chǔ)流程能幫你少踩很多坑。LinearLayout在onMeasure階段會做兩次測量。第一次測量先按照子View的layout_width或layout_height、margin等計(jì)算出每個子View的原始尺寸得到剩余空間如果檢測到有子View設(shè)置了weight并且剩余空間不為0就會觸發(fā)第二次測量把新計(jì)算出來的尺寸賦給對應(yīng)子View。這正是weight在wrap_content下不夠精確的根本原因第二次測量不是從零開始而是在第一次wrap_content結(jié)果的基礎(chǔ)上疊加剩余空間的分配。也就是說原本內(nèi)容決定尺寸的結(jié)果被保留了一部分權(quán)重只能分配到剩余的那部分。還有一個隱蔽問題如果你給某個子View設(shè)置weight0它不參與分配但如果同時把它主軸方向上的尺寸也寫成0dp它的原始尺寸就是0最終可能完全不顯示。遇到這種情況要么給一個具體寬度要么把尺寸改回wrap_content。4. 從零搭建一個真實(shí)界面完整實(shí)操過程4.1 目標(biāo)場景描述為了讓前面這些概念落到實(shí)處我模擬一個非常典型的界面登錄表單頁。頁面從上到下依次是標(biāo)題、手機(jī)號輸入框、密碼輸入框、性別選項(xiàng)行、底部按鈕行、提示文本。這個頁面只用LinearLayout就能完成同時能練到orientation、gravity、layout_gravity、weight、margin、divider等幾乎全部基礎(chǔ)屬性。4.2 第一版搭建垂直骨架我先寫根節(jié)點(diǎn)LinearLayout方向設(shè)成vertical讓所有內(nèi)容按從上到下的順序排列。為了讓界面不頂?shù)狡聊贿吘壗o根布局設(shè)置16dp的padding。輸入框之間用marginTop來分隔而不是加入一堆空的View占位?？誚iew占位是新手很常見的壞習(xí)慣它會讓布局層級變多而且維護(hù)起來很痛苦一個margin就能解決的事完全沒必要引入新節(jié)點(diǎn)。下面是第一版的XML骨架LinearLayout xmlns:androidhttp://schemas.android.com/apk/res/android android:layout_widthmatch_parent android:layout_heightwrap_content android:orientationvertical android:padding16dp TextView android:idid/tv_title android:layout_widthwrap_content android:layout_heightwrap_content android:text歡迎登錄 android:textSize24sp / EditText android:idid/et_phone android:layout_widthmatch_parent android:layout_heightwrap_content android:hint請輸入手機(jī)號 android:inputTypephone android:layout_marginTop16dp / EditText android:idid/et_password android:layout_widthmatch_parent android:layout_heightwrap_content android:hint請輸入密碼 android:inputTypetextPassword android:layout_marginTop16dp / /LinearLayout這里有兩個細(xì)節(jié)值得說明。第一個TextView寬度用wrap_content因?yàn)闃?biāo)題文字撐開就夠了不需要占滿整行這樣點(diǎn)擊區(qū)域只在文字周圍不會誤觸整行。第二個EditText寬度用match_parent因?yàn)檩斎肟蛳ＭM量寬方便用戶點(diǎn)擊和輸入。4.3 第二版加入性別選項(xiàng)行接下來加一行性別選項(xiàng)用水平LinearLayout容納兩個RadioButton。父容器寬度設(shè)wrap_content這樣只是包住內(nèi)容不占滿整行。兩個RadioButton之間用marginStart隔開。LinearLayout android:layout_widthwrap_content android:layout_heightwrap_content android:orientationhorizontal android:layout_marginTop16dp RadioButton android:idid/rb_male android:layout_widthwrap_content android:layout_heightwrap_content android:text男 / RadioButton android:idid/rb_female android:layout_widthwrap_content android:layout_heightwrap_content android:text女 android:layout_marginStart16dp / /LinearLayout我在這里用了marginStart而不是marginLeft這是Android官方推薦的做法目的是兼容從右往左排列的語言區(qū)域。中文環(huán)境下兩者效果一致但從代碼規(guī)范角度新項(xiàng)目最好統(tǒng)一使用Start和End。RadioButton默認(rèn)自帶一定的內(nèi)邊距所以不需要額外加太多間距。4.4 第三版用權(quán)重做底部按鈕行經(jīng)典的登錄頁底部通常會放登錄和注冊兩個按鈕各占一半寬度。如果直接把兩個Button寬度寫成match_parent第一個Button會占滿一行第二個只能另起一行。正確寫法是把它們放進(jìn)一個水平LinearLayout里寬度match_parent兩個Button的寬度都設(shè)為0dp再分別設(shè)置weight1。LinearLayout android:layout_widthmatch_parent android:layout_heightwrap_content android:orientationhorizontal android:layout_marginTop24dp Button android:idid/btn_login android:layout_width0dp android:layout_heightwrap_content android:layout_weight1 android:text登錄 / Button android:idid/btn_register android:layout_width0dp android:layout_heightwrap_content android:layout_weight1 android:text注冊 / /LinearLayout這里特別提醒兩個Button之間不要只在一個按鈕上添加marginEnd因?yàn)檫@樣會導(dǎo)致兩側(cè)剩余空間分配時出現(xiàn)微小偏差視覺上兩個按鈕寬度會差1到2dp。如果真的需要按鈕之間的間距正確做法是給兩個Button分別設(shè)置左右margin并且讓它們的橫向margin值加起來一致或者用一個固定寬度的Space控件作為間隔。最省心的方案是直接不設(shè)間距用背景色或分割線來區(qū)分。4.5 第四版加一條分割線和提示信息在性別選項(xiàng)和按鈕行之間如果想加一條水平分割線可以用divider。先定義一個shape Drawable文件divider_h.xmlshape xmlns:androidhttp://schemas.android.com/apk/res/android android:shaperectangle size android:height1dp / solid android:color#DDDDDD / /shape然后在任意LinearLayout中啟用android:dividerdrawable/divider_h android:showDividersmiddle android:dividerPadding8dp注意這個divider如果用在水平LinearLayout里高度必須設(shè)置為1dp但寬度要足夠參考實(shí)際需求如果用在一個垂直LinearLayout里shape的寬度要設(shè)為match_parent高度保持1dp。大部分人不顯示分割線的原因都是忘了寫showDividers因?yàn)槟J(rèn)值是none。提示信息我放在底部寬度match_parent文字用gravityend靠右顯示。這里用gravity而不是layout_gravity是因?yàn)門extView已經(jīng)占滿整行需要控制的是文字在控件內(nèi)部的位置。如果寫成layout_gravityend由于控件本身寬度已經(jīng)等于父容器寬度沒有任何剩余空間屬性會被忽略。4.6 運(yùn)行效果與調(diào)整實(shí)錄把上述頁面跑起來后最典型的問題是輸入法彈出后頁面被頂上去底部按鈕被軟鍵盤遮擋。這個問題的根因不在LinearLayout而是Activity的軟鍵盤模式。在Manifest里給當(dāng)前Activity設(shè)置android:windowSoftInputModeadjustResize并且把根布局替換成ScrollView包裹就能在多數(shù)情況下避免遮擋。這里要特別說明ScrollView本身不是布局容器思維它只允許一個直接子View。通常做法是ScrollView下面直接掛一個垂直LinearLayout作為唯一子View再在這個LinearLayout里放內(nèi)容。同時ScrollView需要設(shè)置fillViewporttrue否則當(dāng)內(nèi)容高度不足時內(nèi)部LinearLayout不會自動撐滿全屏背景色或底部內(nèi)容的位置會和預(yù)期不符。另外在調(diào)試過程中我發(fā)現(xiàn)標(biāo)題TextView一開始用了match_parent加上gravitycenter_horizontal等價于文字居中但整個標(biāo)題區(qū)域會占據(jù)一整行寬度導(dǎo)致點(diǎn)擊標(biāo)題時整個屏幕寬度范圍都是響應(yīng)區(qū)域。后來改成wrap_content加layout_gravitycenter_horizontal讓控件只包住文字本身點(diǎn)擊區(qū)域更合理。5. 常見問題與排查技巧實(shí)錄5.1 layout_gravity設(shè)了沒反應(yīng)這個問題的出現(xiàn)頻率非常高。報錯形式通常是在垂直LinearLayout里給子View設(shè)了layout_gravitycenter_vertical但位置紋絲不動。首先要理解LinearLayout的layout_gravity只在副軸方向生效。垂直布局的副軸是水平方向所以center_horizontal、start、end這些有效而center_vertical屬于主軸方向基本無效。水平布局則相反layout_gravitycenter_horizontal無效center_vertical才有效。除了方向問題還有兩個容易踩的原因。第一個是控件尺寸已經(jīng)占滿了父容器的剩余空間比如寬度match_parent沒有剩余空間自然無法對齊。第二個是屬性寫錯了位置layout_gravity是子View的屬性而不是父容器的屬性很多人寫在LinearLayout節(jié)點(diǎn)上當(dāng)然不會對子View產(chǎn)生任何效果。檢查時可以先在調(diào)試階段加上不同背景色確認(rèn)剩余空間是否存在再判斷方向問題。5.2 權(quán)重沒有按預(yù)期比例分布權(quán)重問題九成出在layout_width或layout_height與weight的組合上。前面反復(fù)強(qiáng)調(diào)過只有0dp加weight才能實(shí)現(xiàn)純粹的按比例分配。如果發(fā)現(xiàn)weight為2的按鈕只比weight為1的按鈕多了一丁點(diǎn)寬度幾乎可以斷定那個按鈕的寬度是wrap_content內(nèi)容大小把權(quán)重效果稀釋了。另一個隱蔽坑是父容器在主軸方向上的尺寸是wrap_content。如果你給垂直LinearLayout高度設(shè)為wrap_content那么子View們拿到的剩余空間天然就是0因?yàn)楦溉萜鞯母叨鹊扔谒凶覸iew高度之和。此時子View就算寫了weight也不會生效。把父容器改成match_parent或固定高度效果立刻出現(xiàn)。weightSum不匹配也會引發(fā)詭異現(xiàn)象。當(dāng)子View的總權(quán)重大于weightSum時比例會失真當(dāng)總權(quán)重小于weightSum時剩余空間分不完留出一段空白。排查思路是去掉weightSum用默認(rèn)總權(quán)重跑一遍看比例是否正常。5.3 嵌套過多導(dǎo)致卡頓或?qū)挾葻o限撐大LinearLayout層層嵌套帶來的問題有兩個一是性能二是布局計(jì)算的不確定性。在measure階段每一層都要遞歸調(diào)用子View的測量方法層級越深調(diào)用次數(shù)越多。如果頁面上有列表列表項(xiàng)里再嵌套五層LinearLayout滾動時卡頓會非常明顯。優(yōu)化方式不只是改成ConstraintLayout這一條路。很多嵌套可以用單個LinearLayout加weight解決。比如左側(cè)圖標(biāo)、中間文字、右側(cè)箭頭這類經(jīng)典列表項(xiàng)一個水平LinearLayout就能搞定沒必要再包一層相對布局。真正復(fù)雜到自由定位、百分比約束的時候再考慮ConstraintLayout也不遲。寬度無限撐大這個問題也常見于水平LinearLayout某個子View內(nèi)容非常長且子View寬度是wrap_content系統(tǒng)會優(yōu)先滿足它的測量需求導(dǎo)致這個子View把父容器寬度不斷撐大直到超出屏幕。解決辦法是給這個子View設(shè)置layout_width0dpweight限制它在父容器寬度范圍內(nèi)分配空間或者使用android:maxWidth限制最大寬度。5.4 divider不顯示或顯示位置不對如果你配好了divider卻什么都沒出現(xiàn)檢查順序如下。第一確認(rèn)showDividers不是none必須設(shè)置為beginning、middle、end或者組合。第二確認(rèn)Drawable的尺寸方向與LinearLayout方向匹配。水平LinearLayout需要寬度很小的分割線垂直LinearLayout需要高度很小的分割線。如果是shape寬度或高度至少要有一個確定值。第三確認(rèn)Drawable的可見性solid顏色不能是純透明。如果divider出現(xiàn)了但位置奇怪多半是dividerPadding的方向理解錯了。在水平LinearLayout中dividerPadding調(diào)整的是分割線上下兩端的間距在垂直LinearLayout中調(diào)整的是左右兩端的間距。很多人在水平布局里想調(diào)整左右間距卻設(shè)置dividerPadding自然沒有效果。5.5 基線對齊造成意外偏移baselineAligned默認(rèn)是true在水平排列的多個純TextView場景下通常符合直覺。但一旦混入Button、EditText、ImageView基線參考點(diǎn)就很難控制。Button文本默認(rèn)垂直居中EditText有自己的文字內(nèi)邊距ImageView完全沒有基線概念系統(tǒng)最終只能強(qiáng)行找某個子View的基線來對齊于是整個組件組出現(xiàn)肉眼可見的偏移。我比較推薦的替代方案是先用gravitycenter_vertical讓組件在副軸方向居中如果必須讓兩段文字底部對齊就給他們設(shè)置相同的高度再用gravitybottom內(nèi)部對齊。這樣比依賴baselineAligned穩(wěn)定得多。當(dāng)然理解baselineAligned仍然有必要因?yàn)椴簧俚谌娇丶?nèi)部會默認(rèn)使用它出了問題要知道去android:baselineAlignedfalse關(guān)閉。5.6 我說一個一直有效的排查習(xí)慣寫了很多年布局我慢慢養(yǎng)成了一個固定習(xí)慣每寫一個LinearLayout之前先在腦子里把主軸方向想清楚然后問自己三個問題。第一子View在主軸方向需不需要按比例分配空間如果需要就堅(jiān)定地使用0dp加weight。第二副軸方向要對齊到什么位置用父容器的gravity還是子View自己的layout_gravity第三父容器在主軸方向是否有剩余空間如果沒有權(quán)重寫了也白寫。這三步想清楚大部分布局異常都能在寫代碼之前避免。另一個小技巧是調(diào)試時給LinearLayout和子View都加上臨時背景色用色塊直觀觀察每個控件實(shí)際占用的空間邊界比盯著屬性文件猜快得多。問題修復(fù)后再把背景色刪掉。這套方法陪伴了我很長時間遇到再復(fù)雜的布局問題我都會先回到這一步。