为一篇讲解 HarmonyOS7 首页 Banner 设计的技术文章绘制一张手绘笔记风信息图。主题是

前言

首页 Banner 很容易被写成一个巨大的 Stack:背景放进去,标题放进去,按钮放进去,角标也放进去。视觉稿刚开始能还原,但运营一改文案、一加倒计时,层级就开始互相压。

Stack 不是不能用,它本来就适合做叠层。问题在于,Banner 不是一张图加几行字,它是一个会被频繁运营的入口。

这篇用 HarmonyOS7 写一个首页 Banner。重点不是把效果做得多炫,而是把背景层、内容层、状态层分清楚,让后续改文案、改按钮、加指示点时不至于推倒重来。

为什么这个问题经常被写乱

首页 Banner 不要只会 Stack 这类内容很容易被写成“代码能跑就算讲完了”,但对初学者来说,这恰恰是最不够的地方。真正让人卡住的,往往不是某个组件名记不住,而是不知道这段代码为什么要这样拆、状态为什么要这样放、以后需求变化时应该从哪里改。

所以这篇文章不只想给你一个能跑的例子,更想把背后的判断过程讲清楚。你只要把这个判断过程吃透,后面自己改页面、补需求、查问题时,心里会稳很多。

Banner 先按运营位理解

为这篇 HarmonyOS7 首页 Banner 文章绘制一张手绘流程图,展示写 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)
  }
}

为这篇讲解 HarmonyOS7 Banner 的技术文章绘制一张手绘框架图,表达完整的 Banne

把关键代码一段段拆开

HomeBanner 不只存标题,还存了 id、按钮文案和背景色。真实项目里还可以继续加 targetUrltrackIdstartTimeendTime。数据模型越清楚,UI 越不用猜。

Swiper 只负责轮播行为,单张 Banner 内部才用 Stack。这个边界很重要:轮播容器管“第几张”,Stack 管“这一张里面怎么叠”。

.indicator(false) 关闭默认指示器,是因为很多业务页需要定制指示点样式。这里自己用 Row + Circle 写指示点,状态统一来自 currentIndex,不会出现轮播已经切了但指示点没变的情况。

ForEach 的 key 使用 item.id.toString()。不要用标题当 key,运营改标题后,组件复用关系可能跟着变,调试起来很烦。

真实项目里的几个取舍

Banner 高度建议先固定。图片还没加载出来时,如果高度跟内容走,首页会出现明显跳动。尤其是首屏位置,用户一打开就看到页面抖,体验很差。

按钮点击也不要在 Banner 组件里写一堆跳转判断。更好的方式是把业务 id 或路由信息传出去,由页面或统一跳转方法处理。Banner 保持轻,后面接埋点也更干净。

如果 Banner 自动轮播,要谨慎。很多页面自动轮播会打断用户阅读,尤其是文案比较长的时候。我的习惯是:运营图可以自动轮播,功能入口类 Banner 尽量让用户自己滑。

新手最容易踩的坑

这一类示例最容易让人产生错觉:界面出来了,就以为已经掌握了。其实真正容易出问题的地方,通常都在效果之外,比如状态有没有收拢、失败后怎么兜底、以后要扩展时会不会牵一发动全身。

所以你练这篇内容时,别只看“现在能不能跑”,还要继续看“以后好不好改”。能把这个习惯养起来,你写出来的页面会比单纯照着示例拼出来的页面稳很多。

放进真实项目还要补什么

示例代码的重点是把核心思路讲明白,所以很多工程化细节会故意省掉。真正落到项目里时,你通常还要继续补接口联动、异常处理、边界保护、资源抽离,以及和其他页面状态之间的配合。

写在最后

比较稳的做法是分三步走:先把结构和职责立住,再把真实业务接进去,最后再优化视觉和交互体验。这样改出来的页面不只是“能演示”,而是真的更接近可以长期维护的业务代码。

Logo

讨论HarmonyOS开发技术,专注于API与组件、DevEco Studio、测试、元服务和应用上架分发等。

更多推荐