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