HarmonyOS7 首页 Banner 不要只会 Stack:运营位要先分层再叠放

文章目录
前言
首页 Banner 很容易被写成一个巨大的 Stack:背景放进去,标题放进去,按钮放进去,角标也放进去。视觉稿刚开始能还原,但运营一改文案、一加倒计时,层级就开始互相压。
Stack 不是不能用,它本来就适合做叠层。问题在于,Banner 不是一张图加几行字,它是一个会被频繁运营的入口。
这篇用 HarmonyOS7 写一个首页 Banner。重点不是把效果做得多炫,而是把背景层、内容层、状态层分清楚,让后续改文案、改按钮、加指示点时不至于推倒重来。
为什么这个问题经常被写乱
首页 Banner 不要只会 Stack 这类内容很容易被写成“代码能跑就算讲完了”,但对初学者来说,这恰恰是最不够的地方。真正让人卡住的,往往不是某个组件名记不住,而是不知道这段代码为什么要这样拆、状态为什么要这样放、以后需求变化时应该从哪里改。
所以这篇文章不只想给你一个能跑的例子,更想把背后的判断过程讲清楚。你只要把这个判断过程吃透,后面自己改页面、补需求、查问题时,心里会稳很多。
Banner 先按运营位理解

我写 Banner 前会先问三个问题:
| 问题 | 为什么要问 |
|---|---|
| 是否有多张轮播 | 决定是否需要 Swiper 和当前页状态 |
| 每张图是否有跳转目标 | 决定数据模型里是否要有业务 id 或路由信息 |
| 文案是否会频繁变化 | 决定标题、副标题是否要做截断和安全边距 |
如果只是临时活动图,可以写得简单些。如果是首页固定模块,就不要把所有内容硬编码在 UI 里。
Banner 最容易出问题的地方不是叠层,而是每个人都往里面加一点。先定边界,后面才不会变成杂货铺。
先把页面目标想清楚
在真正写代码之前,先别急着盯着 API。更有用的做法是先想清楚:这个页面到底想解决什么问题,用户最在意的反馈是什么,哪些状态必须一直保持一致。
当你先把这条主线想明白,再回头看组件和状态设计,很多选择都会顺理成章。对小白来说,这一步尤其重要,因为它能帮你从“照着抄”慢慢过渡到“看得懂、改得动”。
完整 ArkUI 示例
下面的例子用 Swiper 处理轮播,用 Stack 处理单张 Banner 内部的背景和文案叠放,再用一个自定义指示点显示当前页。
interface HomeBanner {
id: number
title: string
desc: string
action: string
color: string
}
@Entry
@Component
struct HomeBannerPage {
@State currentIndex: number = 0
private banners: HomeBanner[] = [
{ id: 1, title: 'HarmonyOS7 新课上线', desc: '从 ArkUI 布局到真实项目调优', action: '立即查看', color: '#1E88E5' },
{ id: 2, title: '周末会员日', desc: '精选模板和组件案例限时开放', action: '去领取', color: '#7B1FA2' },
{ id: 3, title: '开发者工具包', desc: '常用页面骨架一次整理好', action: '打开清单', color: '#00897B' }
]
build() {
Column({ space: 12 }) {
Swiper() {
ForEach(this.banners, (item: HomeBanner) => {
Stack({ alignContent: Alignment.BottomStart }) {
Rect()
.width('100%')
.height(156)
.fill(item.color)
.radius(16)
Column({ space: 8 }) {
Text(item.title)
.fontSize(22)
.fontWeight(FontWeight.Bold)
.fontColor(Color.White)
Text(item.desc)
.fontSize(13)
.fontColor('#E8FFFFFF')
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
Button(item.action)
.height(32)
.fontSize(13)
.type(ButtonType.Capsule)
.backgroundColor('#FFFFFFFF')
.fontColor(item.color)
}
.alignItems(HorizontalAlign.Start)
.padding(18)
.width('100%')
}
}, (item: HomeBanner) => item.id.toString())
}
.height(156)
.indicator(false)
.onChange((index: number) => {
this.currentIndex = index
})
Row({ space: 6 }) {
ForEach(this.banners, (item: HomeBanner, index: number) => {
Circle()
.width(index === this.currentIndex ? 18 : 6)
.height(6)
.fill(index === this.currentIndex ? item.color : '#D5D9E2')
}, (item: HomeBanner) => item.id.toString())
}
.justifyContent(FlexAlign.Center)
.width('100%')
}
.padding(16)
}
}

把关键代码一段段拆开
HomeBanner 不只存标题,还存了 id、按钮文案和背景色。真实项目里还可以继续加 targetUrl、trackId、startTime、endTime。数据模型越清楚,UI 越不用猜。
Swiper 只负责轮播行为,单张 Banner 内部才用 Stack。这个边界很重要:轮播容器管“第几张”,Stack 管“这一张里面怎么叠”。
.indicator(false) 关闭默认指示器,是因为很多业务页需要定制指示点样式。这里自己用 Row + Circle 写指示点,状态统一来自 currentIndex,不会出现轮播已经切了但指示点没变的情况。
ForEach 的 key 使用 item.id.toString()。不要用标题当 key,运营改标题后,组件复用关系可能跟着变,调试起来很烦。
真实项目里的几个取舍
Banner 高度建议先固定。图片还没加载出来时,如果高度跟内容走,首页会出现明显跳动。尤其是首屏位置,用户一打开就看到页面抖,体验很差。
按钮点击也不要在 Banner 组件里写一堆跳转判断。更好的方式是把业务 id 或路由信息传出去,由页面或统一跳转方法处理。Banner 保持轻,后面接埋点也更干净。
如果 Banner 自动轮播,要谨慎。很多页面自动轮播会打断用户阅读,尤其是文案比较长的时候。我的习惯是:运营图可以自动轮播,功能入口类 Banner 尽量让用户自己滑。
新手最容易踩的坑
这一类示例最容易让人产生错觉:界面出来了,就以为已经掌握了。其实真正容易出问题的地方,通常都在效果之外,比如状态有没有收拢、失败后怎么兜底、以后要扩展时会不会牵一发动全身。
所以你练这篇内容时,别只看“现在能不能跑”,还要继续看“以后好不好改”。能把这个习惯养起来,你写出来的页面会比单纯照着示例拼出来的页面稳很多。
放进真实项目还要补什么
示例代码的重点是把核心思路讲明白,所以很多工程化细节会故意省掉。真正落到项目里时,你通常还要继续补接口联动、异常处理、边界保护、资源抽离,以及和其他页面状态之间的配合。
写在最后
比较稳的做法是分三步走:先把结构和职责立住,再把真实业务接进去,最后再优化视觉和交互体验。这样改出来的页面不只是“能演示”,而是真的更接近可以长期维护的业务代码。
更多推荐



所有评论(0)