搞了半天終于把HarmonyOS那套ArkTS里的層疊布局Stack整明白了。前幾天有個剛轉鴻蒙開發(fā)的朋友問我一個頭像右上角的紅色角標怎么用原生組件放上去我第一反應就是這玩意不就是給Stack準備的嗎層疊布局在ArkTS的布局體系里地位有點像PS里的圖層面板能把一個個組件按Z軸方向堆起來做到你壓我、我蓋你還不影響各自的位置計算。這篇就把我從零踩到順的全過程寫下來從基礎語法到懶人式對齊方法再到各種坑的排查一次說清楚。如果你正要開始寫HarmonyOS應用或者已經(jīng)在用Column、Row排布界面但總覺得差點意思這篇文章都值得花十分鐘看完。內(nèi)容不搞虛的全部以可運行的ArkTS代碼和真實界面效果為準尤其會重點講熱搜里常被問到的那個問題Stack里的子組件怎么控制自己在底部上方100的位置水平居中。1. 布局體系里的“疊羅漢”層疊布局解決什么問題1.1 先看懂ArkTS的布局家族正式開始之前先花兩分鐘把ArkTS里這些布局容器捋一遍。做過Android的同學應該能看出它們跟傳統(tǒng)ViewGroup的對應關系理解了這個后面學什么布局都快。ArkTS聲明式UI里常用的容器布局有這么幾類Column線性縱向排列、Row線性橫向排列、Flex彈性布局可以換行類似CSS的flex、Grid網(wǎng)格布局適合九宮格這種規(guī)整格子、RelativeContainer相對定位容器以及今天的主角Stack層疊布局。它們的分工很明確Column和Row解決的是“排隊”問題讓元素一個挨一個排Flex解決“空間分配”問題一行放不下就換行剩下的空間按比例瓜分Grid解決“對齊格子”的問題列數(shù)固定格子規(guī)整。一旦需求變成“兩個組件需要重疊在一起”比如圖片上方蓋一行半透明文字、角標壓在圖標右上角沒一個容器能優(yōu)雅地接住這活只有Stack能辦。1.2 Stack的核心能力Z軸上的自由Stack的核心思路其實特別樸素它的子組件不橫向排、不縱向排而是全部默認從左上角開始重疊后加入的子組件會蓋在先加入的子組件上面形成一個Z軸方向的堆疊。理解這一點的時候我建議你把它類比成桌面上堆了一摞便簽紙。最先放的那張在最底下后放的往上蓋最上面那張只有你能看到全部內(nèi)容下面的全被擋住了一部分。Android里叫FrameLayoutWeb里用position: relative加z-index也能實現(xiàn)類似效果ArkTS里就是Stack。剛開始用Stack的人容易犯一個糊涂以為子組件放在Stack里就只能左上角疊在一起沒法控制各自的位置。其實Stack本身提供了兩種位置控制手段一個管全局、一個管個體稍后第3節(jié)會細講。你只要記住Stack負責把子組件切換成“可重疊”的模式至于每個組件具體待在哪完全可以通過屬性單獨指定自由度比線性布局高得多。2. 環(huán)境準備與一個最簡層疊案例2.1 開發(fā)環(huán)境快速搭建先確認一下你手上的開發(fā)環(huán)境。目前主流方案是使用DevEco Studio版本建議4.0及以上對應的HarmonyOS SDK版本最好在API 9以上這樣聲明式UI的ArkTS支持才完整寫起來也順手。新建項目的時候注意選擇一個帶UIAbility的Empty Ability模板ArkTS代碼寫在entry模塊的pages目錄下。一個最小的ArkTS頁面其實就是一個被Entry裝飾的struct組件里面由build方法描述UI結構。如果你之前寫過Flutter或者SwiftUI這套寫法的上手成本幾乎為零如果只寫過Android XML布局也沒關系多寫幾次就習慣了。我強烈建議初學階段不要開預覽器看效果直接在模擬器或者真機上跑因為Stack的層級關系在預覽器里有時候會有渲染時序問題看著是錯位的真機上跑反而是正常的免得被工具誤導。2.2 從零手寫第一個Stack頁面直接看代碼。下面這個例子是Stack最經(jīng)典的演示三個不同顏色、不同尺寸的正方形疊在一起感受一下默認的層級效果。Entry Component struct StackDemo { build() { Stack() { Column() .width(240) .height(240) .backgroundColor(#FF6B6B) Column() .width(160) .height(160) .backgroundColor(#4ECDC4) Column() .width(90) .height(90) .backgroundColor(#FFE66D) } .width(100%) .height(100%) .alignContent(Alignment.Center) } }代碼里我特意把三個Column的寬高設成了240、160、90三檔背景色也不一樣。運行一下你就明白Stack的行為模式了三個子組件默認重疊對齊對齊方式由Stack自身的alignContent屬性決定這里我設成了Alignment.Center所以三者都水平垂直居中先寫的紅色塊在底層最后寫的黃色塊在最上層所以黃色塊完整可見綠色塊露出四周紅色塊只露出一圈邊框每個子組件的位置互不影響不存在線性布局那種擠壓和占位問題。這個Demo雖然短但已經(jīng)把Stack的核心機制演示透了。接下來的所有復雜效果本質(zhì)都是在“多個子組件疊放”的基礎上加上尺寸、位置、事件的精確控制。3. 控制子組件位置的兩種姿勢整體對齊與個體對齊3.1 容器級對齊alignContent先講那個管全局的參數(shù)alignContent。這個屬性掛在Stack根節(jié)點上決定所有子組件的“默認排隊位置”。它的取值范圍就是Alignment那一組枚舉常見的有枚舉值實際效果Alignment.TopStart所有子組件默認對齊到左上角Alignment.Top所有子組件默認對齊到頂部水平居中Alignment.TopEnd所有子組件默認對齊到右上角Alignment.Start所有子組件默認對齊到左側垂直居中Alignment.Center所有子組件默認水平垂直居中Alignment.End所有子組件默認對齊到右側垂直居中Alignment.BottomStart所有子組件默認對齊到左下角Alignment.Bottom所有子組件默認對齊到底部水平居中Alignment.BottomEnd所有子組件默認對齊到右下角實操里我的經(jīng)驗是先把整個Stack的alignContent設為某個基準位置比如一個全屏的Stack通常設成Alignment.Center或者Alignment.Bottom這樣大多數(shù)子組件不需要單獨設置位置只有少數(shù)元素再用alignSelf做微調(diào)。要注意alignContent只是一個“默認值”邏輯不是強制鎖死。意思就是子組件如果自己帶了alignSelf或者margin、position之類的屬性那以它自己的為準。所以別擔心設了容器級對齊后所有兒子就只能擠在一個角落了后面還有手段解放它們。3.2 子組件級對齊alignSelf再講那個管個體的屬性alignSelf。這個屬性讓單個子組件在Stack內(nèi)部單獨調(diào)整自己的對齊方式完全不用管兄弟組件。用法是在子組件鏈式調(diào)用里加一個.alignSelf()Stack({ alignContent: Alignment.Center }) { Column() .width(200) .height(200) .backgroundColor(#FF6B6B) Text(右下角標簽) .alignSelf(Alignment.BottomEnd) .margin({ right: 16, bottom: 16 }) .fontSize(14) .fontColor(Color.White) .backgroundColor(#33000000) .padding({ left: 8, right: 8, top: 4, bottom: 4 }) .borderRadius(4) } .width(100%) .height(200)注意這里Stack容器整體alignContent設了Center但第二個子組件Text通過alignSelf(BottomEnd)把自己定位到了右下角還加了margin進一步偏移。這就是Stack真正靈活的地方全局統(tǒng)一局部自由互不干擾。實戰(zhàn)里alignSelf最好用的場景就是做角標。比如一個卡片右上角的“HOT”標簽整個卡片放在一個居中Stack里標簽自己alignSelf到TopEnd再margin調(diào)整距離邊緣的間距幾行代碼搞定不用嵌套一堆容器。3.3 熱搜實戰(zhàn)底部上方100居中的寫法下面進入很多初學者問了無數(shù)遍的實戰(zhàn)題Stack里的一個子組件要相對整個Stack的水平方向居中同時垂直方向距離底部100。別小看這個問題熱搜里反復出現(xiàn)“鴻蒙 stack布局子組件怎么控制自己在底部上方100的位置居中”說明卡在這的人真不少。先給答案最簡單的寫法Entry Component struct BottomButtonDemo { build() { Stack() { // 背景層可以是任意內(nèi)容 Column() .width(100%) .height(100%) .backgroundColor(#F1F3F5) // 這個按鈕就是目標水平居中距離底部100 Button(我知道了) .width(200) .height(48) .alignSelf(Alignment.Bottom) // 先放到水平居中、底部對齊 .margin({ bottom: 100 }) // 再往上推100 } .width(100%) .height(100%) } }拆解一下思路Stack對齊系統(tǒng)里Alignment.Bottom本身就是“水平居中底部對齊”所以直接alignSelf(Bottom)就完成了水平居中這一半。然后想做到“距離底部100”就在子組件的margin里把bottom設為100相當于讓按鈕整體往上抬了100。兩步合起來就是底部上方100且水平居中。很多人想不明白的點在于是用margin還是position。在Stack里最簡單有效的偏移方式就是margin它會參與布局計算真機上對尺寸自適應也更友好。position屬性也能用但它會把元素變成絕對定位后續(xù)父容器尺寸變化時容易出現(xiàn)超出邊界的情況初學階段建議優(yōu)先用margin。如果還想更精細一點比如按鈕要求距離底部100同時還要距離右側20可以連續(xù)疊加先.alignSelf(Alignment.BottomEnd), 再.margin({ right: 20, bottom: 100 })。但注意一旦alignSelf用了End水平方向就不再是居中而是靠右了二者是不可兼得的“方向組合”。所以要先想清楚自己要的是靠哪邊。4. 層疊布局的高頻應用場景4.1 右上角角標電商列表的未讀紅點Stack在真實項目中最常見的用途就是角標類需求。拿電商應用舉例商品列表每個格子的右上角經(jīng)常會有一個“滿減”標簽或者未讀紅點。這種UI結構天然就是“原內(nèi)容 覆蓋物”的關系用線性布局寫會麻煩到懷疑人生用Stack寫就是兩三行的事。Entry Component struct BadgeDemo { build() { Stack({ alignContent: Alignment.Center }) { // 商品圖底板 Column() .width(120) .height(120) .backgroundColor(#DEE2E6) .borderRadius(12) // 右上角紅點 Column() .width(16) .height(16) .backgroundColor(#FA5252) .borderRadius(8) .alignSelf(Alignment.TopEnd) .margin({ top: 6, right: 6 }) } .width(100%) .height(100%) } }這里我假裝商品底圖是一個灰色色塊紅點通過alignSelf(TopEnd)跑到右上角再用margin把紅點往里收6避免貼邊太緊。你把這個紅點換成Text標簽里面塞數(shù)字或者“NEW”就是一個標準的加號角標。做角標的時候有個細節(jié)值得注意角標內(nèi)容變化時比如從9變成99它的寬度會自動撐開但因為alignSelf加margin的寫法不會影響容器其他兄弟組件所以整體布局不會晃動這一點比用線性布局里做fixed寬高的方案穩(wěn)得多。4.2 懸浮按鈕與底部操作欄另一個高頻場景是做頁面的懸浮操作區(qū)。比如一個視頻播放頁面返回按鈕、點贊按鈕、評論輸入框經(jīng)常要懸浮在播放器內(nèi)容上。這種界面用Stack就是天然解背景放視頻層前景放操作層互不打擾。Entry Component struct FloatActionDemo { build() { Stack() { // 模擬視頻區(qū)域 Column() .width(100%) .height(100%) .backgroundColor(#212529) // 頂部返回按鈕 Button(返回) .backgroundColor(#66000000) .fontColor(Color.White) .alignSelf(Alignment.TopStart) .margin({ left: 16, top: 16 }) // 底部操作欄 Row() { Text(點贊) Text(評論) Text(分享) } .width(100%) .justifyContent(FlexAlign.SpaceAround) .backgroundColor(#66000000) .fontColor(Color.White) .padding({ top: 10, bottom: 10 }) .alignSelf(Alignment.Bottom) } .width(100%) .height(100%) } }從上面這段可以看到Stack不僅能容納單個組件里面嵌套一個Row再放整行操作欄也完全沒問題。也就是說Stack的層級能力完全可以搭載一行內(nèi)部有復雜布局的區(qū)塊它只負責“這行整體待在我這個容器底下”不負責管行內(nèi)元素的排列。這種做法比用絕對坐標定位的寫法省心在一點不同屏幕尺寸下Stack的百分比寬高依然生效懸浮按鈕的位置不會因為機型尺寸變化而跑偏。4.3 圖片文字疊加封面卡片圖片上蓋文字基本是內(nèi)容類應用的家常便飯。頭條、抖音、購物車里的商品卡都在玩這個套路一張封面圖底下蓋一層半透明漸變或者一塊深色遮罩再放標題和價格。實現(xiàn)上仍然是Stack整個卡片只有一層結構Entry Component struct CoverCardDemo { build() { Stack() { // 圖片占位實際開發(fā)換成Image組件 Column() .width(100%) .height(200) .backgroundColor(#343A40) // 底部信息遮罩層 Column() .width(100%) .height(60) .backgroundColor(#AA000000) .alignSelf(Alignment.Bottom) // 白色文字 Text(這是一條測試標題長度隨意觀察換行效果) .fontSize(16) .fontColor(Color.White) .alignSelf(Alignment.BottomStart) .margin({ left: 12, right: 60, bottom: 20 }) } .width(100%) .height(200) .borderRadius(12) .clip(true) } }這里上方遮罩和文字都在Stack里遮罩通過alignSelf(Bottom)固定在底部區(qū)域文字通過BottomStart加margin對齊到左下角right留了60的空間給可能存在的價格標簽。最后那個.clip(true)很重要它讓Stack裁剪掉超出圓角范圍的子組件不然蓋上的遮罩會把父容器的圓角給“頂?shù)簟毙Ч浅３蟆?.4 頭像與在線狀態(tài)徽章最后一個高頻場景是社交應用里幾乎人人見過的頭像加狀態(tài)點。頭像底部對齊在線狀態(tài)點壓到頭像右下角稍微露出半個身位。Entry Component struct AvatarDemo { build() { Stack() { // 頭像外層白圈 Column() .width(72) .height(72) .backgroundColor(#FFFFFF) .borderRadius(36) // 頭像內(nèi)層圖 Column() .width(64) .height(64) .backgroundColor(#ADB5BD) .borderRadius(32) // 在線狀態(tài)點 Column() .width(18) .height(18) .backgroundColor(#40C057) .borderRadius(9) .alignSelf(Alignment.BottomEnd) .margin({ right: 2, bottom: 2 }) } .width(100%) .height(100%) } }這個例子的重點是那個狀態(tài)點它比頭像本身小一圈而且刻意露出棋子邊兒這種效果在線性布局里做會很別扭你需要算各種偏移量。但在Stack里就是alignSelf到右下角再margin往外挪一點點即可和實際設計稿的對齊意圖非常匹配。5. 避坑指南布局重疊、事件穿透與性能5.1 布局重疊不是bug但要注意層級搜“布局重疊”這個詞的人很多是因為在Stack里發(fā)現(xiàn)子組件疊到不想疊的地方以為出bug了。其實這不是錯誤而是Stack的設計目的。真正該做的是明確每個子組件的層級順序和位置。Stack的子組件層級規(guī)則很簡單先寫的在下后寫的在上而zIndex屬性可以顯式調(diào)整。比如有兩個按鈕疊在一起想讓紅色的永遠蓋在藍色上面在紅色按鈕上加一個.zIndex(2)藍色設.zIndex(1)層級關系就鎖死了。實際項目里層級沖突最容易出現(xiàn)在“同一個Stack里既有背景元素又有交互元素”的場景。我的習慣是把背景類元素放在最前面交互元素隨后最后用zIndex控制覆蓋關系避免因為多個元素同時集中在某個區(qū)域導致點擊目標被兄弟組件擋住。5.2 事件命中與穿透控制比層級更隱蔽的坑是事件穿透。Stack里上層組件如果設置成了透明背景或者背景色接近全透明它雖然看不見但依然會攔截點擊事件。也就是說你放了一個全屏透明層在頂部下面所有按鈕都會點不動但界面上根本看不到原因。解決辦法是使用hitTestBehavior屬性。ArkTS里對它有三種主流的取值取值行為HitTestMode.Default默認模式組件自身響應事件并且阻止事件傳遞給底部兄弟組件HitTestMode.Block組件自身不響應事件但依然阻斷事件向下傳遞HitTestMode.Transparent組件自身嘗試響應事件同時透傳給下層組件HitTestMode.None組件完全不參與事件命中測試事件直接穿過它命中底層組件做了一個懸浮評分彈層時經(jīng)常需要半透明遮罩后面的內(nèi)容不可點那遮罩就設Default如果是一個純裝飾的引導層要既能響應點擊關閉又讓點擊事件穿透到底層那就用Transparent。這個調(diào)起來需要結合具體交互設計去試但知道有這些選項排查問題時就快多了。5.3 尺寸約束、百分比與自適應邊界Stack雖然“自由”但它對子組件的尺寸仍然有約束。子組件如果沒設置寬高會盡量跟隨內(nèi)容大小如果設置了百分比寬高參考的是Stack自身的尺寸如果子組件的固定尺寸超過了Stack容器就會發(fā)生溢出。實際開發(fā)里我見過不少新手在Stack里放了固定寬度300的組件但容器只有200寬真機上部分內(nèi)容被切掉或者莫名其妙把別的組件頂出區(qū)域。這種時候優(yōu)先檢查的是子組件是否設置了合理的最大寬度、容器是否設置了.clip(true)以及用的是不是百分比寬高。自適應場景下建議優(yōu)先用百分比和margin/dimension配合少寫死px數(shù)值。比如一個卡片要適配不同手機寬度把卡片寬度設成90%角標的位置用alignSelf加margin控制這樣任何屏幕尺寸下都能保持相對位置一致不會因為某一端過窄導致界面元素跑出屏幕。5.4 不要濫用Stack什么時候換FlexStack雖然好用但不是什么場景都適合。如果一個頁面里幾乎都是依次排列的內(nèi)容比如表單頁、設置頁、縱向列表頁用Column或者List才是正解硬用Stack去疊反而會讓布局層級變得復雜維護成本直線上升。給一個簡單的判斷標準如果界面元素之間沒有“重疊”需求并且需要響應式換行或按比例分配空間那就別用Stack如果元素之間天然存在壓蓋關系、需要Z軸層疊、需要某個元素懸浮在其他內(nèi)容之上那Stack就是最佳選擇。還有就是性能。Stack本身并不重但如果一個頁面里嵌套了十幾層Stack每層還都帶了復雜的子組件那渲染壓力會比同等結構的Column大不少。我的習慣是控制層級深度能用一層Stack加alignSelf解決的問題絕不用三層嵌套。這不是Stack的問題是所有容器布局的通用原則。6. 進階Stack與其他布局的搭配與狀態(tài)聯(lián)動6.1 頁面路由棧與Stack布局的區(qū)別講到這里順便厘清一個概念ArkTS里的頁面路由棧router棧和Stack布局是兩碼事。路由棧管的是頁面之間的跳轉每個頁面是獨立的路由實例從一個頁面跳到另一個頁面靠的是router.pushUrl。而Stack布局是在同一個頁面內(nèi)部管的是組件和組件的疊放。這兩個概念在鴻蒙開發(fā)里都帶“?！弊值珜蛹壨耆煌f別混。在頁面上看不到“路由棧”這個組件你是操作不了它的顯隱的反過來Stack布局也沒有能力去控制頁面跳轉它只負責組件排版。把它們弄混是不少初學者寫了好幾天之后才反應過來的事。如果看到有些人把多個“頁面內(nèi)容”直接塞進同一個Stack里用狀態(tài)變量控制顯示和隱藏那一定要小心這屬于“偽頁面切換”頁面之間沒有獨立生命周期狀態(tài)管理也容易亂不如直接用路由棧來得干凈。6.2 配合Flex/Grid實現(xiàn)復雜面板Stack的另一個高價值用法是在復雜面板里作為“局部層疊容器”和其他布局嵌套。最常見的就是一個Grid網(wǎng)格每個格子內(nèi)部再用Stack去疊角標或者一個Flex流式標簽區(qū)域每個標簽做一個小型Stack來展示刪除按鈕。比如做一個九宮格圖片上傳組件熱搜里也經(jīng)常有人搜“android 九宮格布局”每格的右上角放一個刪除按鈕就可以在Grid的item構造里用一個Stack包住圖片和刪除按鈕。這樣外層Grid負責網(wǎng)格排布內(nèi)層Stack負責“圖片刪除鍵”的層疊關系職責清晰不會互相污染。Grid() { ForEach(this.imageList, (item: string) { GridItem() { Stack({ alignContent: Alignment.Center }) { // 假圖片實際是Image(item) Column() .width(100%) .height(100%) .backgroundColor(#E9ECEF) // 右上角刪除按鈕 Text(×) .fontSize(18) .fontColor(Color.White) .backgroundColor(#FA5252) .borderRadius(10) .width(20) .height(20) .textAlign(TextAlign.Center) .alignSelf(Alignment.TopEnd) .margin({ top: 4, right: 4 }) .onClick(() { this.imageList this.imageList.filter((v: string) v ! item) }) } } }, (item: string) item) } .columnsTemplate(1fr 1fr 1fr) .rowsTemplate(1fr 1fr 1fr) .columnsGap(8) .rowsGap(8) .width(100%) .height(260)這套組合方式在內(nèi)容型應用里幾乎天天用。它繼承了Grid的整齊排布優(yōu)點又疊加了Stack的層疊能力兩者配合得當代碼可讀性和UI還原度都很好。6.3 狀態(tài)管理下的層疊刷新細節(jié)最后提一個和狀態(tài)管理相關的細節(jié)。Stack里的子組件顯隱切換如果依賴的是狀態(tài)變量那么狀態(tài)變化的觸發(fā)方式會影響層級刷新效果。比如你在Stack里放了一個loading蒙層用一個布爾變量控制它是否顯示。當網(wǎng)絡請求開始時把變量設為true請求結束時設為false。這時候要注意Stack并不會因為你改變一個狀態(tài)變量就“重新分配”所有子組件的位置它只會更新那些真正依賴該狀態(tài)的節(jié)點的可見性、尺寸、內(nèi)容等。所以只要你沒有改其他子組件的數(shù)據(jù)兄弟組件的位置基本不會跳動。但如果你的狀態(tài)變量里存的是一個數(shù)組比如列表數(shù)據(jù)并且你直接修改了數(shù)組某個元素就可能觸發(fā)包含該元素的組件的重新測量和繪制。如果組件剛好在Stack里且尺寸是自適應內(nèi)容那布局就會重新計算。這一機制本身沒問題但如果發(fā)現(xiàn)某些堆疊組件“莫名抖動”先排查一下是不是父組件或者兄弟組件的某個狀態(tài)被無意間更新了。我建議把“遮罩層”“懸浮層”這類組件的顯隱和業(yè)務數(shù)據(jù)狀態(tài)分開維護盡量讓它們只依賴一兩個專門的布爾變量不要和列表、表單數(shù)據(jù)混在同一個大對象里。這樣狀態(tài)刷新時影響范圍最小不是所有數(shù)據(jù)變了都需要重新計算整個Stack的布局。Stack這個布局在ArkTS里的地位我用一句話總結就是它解決的是你無法用線性容器解決的“疊放”需求但它的靈活性也意味著你需要有更明確的層級意識和尺寸控制能力。上面的內(nèi)容是我在實際項目中反復試出來的幾乎每個示例都在真機上跑過。尤其是alignSelf加margin這套組合方式學會之后鴻蒙界面里能擋住你的布局難題十之八九都能化解。如果你在某一步踩了坑建議先回到這一篇文章把第3節(jié)的兩種對齊方式重新吃透再去看第5節(jié)的避坑場景。很多看起來玄乎的布局問題本質(zhì)上就是對“整體對齊”和“個體對齊”這兩個概念沒分清楚。搞定了這兩個點Stack用起來就順暢多了。