做应用开发这几年我最大的感受是信息展示类页面布局决定体验的底线。在HarmonyOS 6上做界面开发卡片布局已经成了信息流、工作台、数据看板这类场景的事实标准——通过卡片把标题、配图、摘要、操作入口打包成一个个独立的“信息单元”整个界面既不会因为内容太杂而显得凌乱也不会因为元素太少而显得空洞。这篇文章就围绕HarmonyOS 6的ArkTS声明式开发把卡片布局从设计思路、核心参数、完整实现到性能调优一次性讲透。内容基于我实际写过的信息流页面整理适合正在入门HarmonyOS开发、想快速做出有质感的界面的人也适合已经在写业务代码、希望优化卡片细节的开发者。你不需要有多深的UI功底跟着下面的思路走就能搭出一个可复用的卡片组件。1. 卡片布局的整体设计思路1.1 为什么信息展示场景偏爱卡片从用户视角讲卡片做的其实是同一件事视觉分组。人眼在扫描一块屏幕时会下意识通过背景颜色、圆角轮廓、阴影深度来区分内容区块。传统列表用一条细细的分割线把不同条目隔开信息一多就容易看晕卡片则直接给每个内容单元一块“独立的底板”标题、图片、描述、时间作者这些信息被聚合在一块明确的区域里用户不需要费力去分辨哪条文字属于哪条内容扫一眼就能完成定位。这种分组能力在HarmonyOS 6的界面设计中尤为重要。手机屏幕就那么大信息密度和可读性天然是矛盾的。卡片本质上是拿“有限的留白”换“明确的信息边界”让用户能以更低的认知成本读取内容。一个设计合格的卡片从视觉识别到点击操作整个交互链路应该是顺滑且自然的。我甚至可以说信息展示类页面的开发质量很大程度上就体现在卡片细节的打磨上——间距、圆角、阴影、文字层级每一项单独看都不起眼合在一起就是界面“高级感”的由来。1.2 ArkUI下的方案选型List还是Grid还是Scroll在做卡片布局之前先要确定容器骨架。HarmonyOS 6的ArkUI框架里承载多个卡片的主流方案有三种List加ListItem纵向滚动列表每个ListItem内放一张卡片。适合资讯流、消息列表、订单列表这类上下排列的内容有天然的滚动复用机制官方也推荐长列表用List。Grid加GridItem网格布局卡片以两列、三列甚至瀑布流的方式排列。适合商品陈列、功能入口、图片墙这类需要横向铺开的场景。Column包Scroll纯手动排列适合卡片数量固定、不需要滚动性能优化的页面比如个人中心、详情页底部的推荐模块。我的建议是凡是数据量可能动态变化的卡片集合优先上List或Grid别用Column硬排。原因后面讲性能时再细说。如果页面里同时存在多种卡片类型还可以用List嵌套不同样式的ListItem通过判断数据类型来渲染对应的卡片模板这种“异构列表”在实际业务里非常常见。选型的关键不是哪个更高级而是哪个更适合当前的数据规模和交互方式。1.3 一个卡片的视觉构成层次从UI拆解的角度一张卡片通常由四层构成外间距卡片与卡片之间的间隔、容器主体背景色、圆角、阴影、内部内容区内边距和文字图片的排列、点缀元素标签、图标、操作按钮。四个层次是有依赖关系的外间距决定呼吸感容器主体决定视觉重量内容区决定信息可读性点缀元素决定交互引导。实际开发时我习惯先确定外间距和内边距再调圆角和阴影最后才去处理文字样式这样不容易返工。间距和圆角的取值有一定规律可循。HarmonyOS官方设计规范里推荐卡片间距一般取8vp或12vp圆角在12vp到16vp之间内边距取12vp到16vp。这个区间既能保证卡片之间有清晰的边界又不会因为圆角过大而显得过于轻飘。具体取值得看你卡片的承载内容如果卡片里有大图圆角适当缩小到12vp如果卡片以文字为主16vp会让整体更柔和。我见过很多失败案例都是把间距设计稿里的像素值直接搬到代码里完全忽略了vp和px的换算导致真机上卡片挤成一团。HarmonyOS里默认使用vp作为尺寸单位设计稿给的px像素值通常需要除以一个密度系数再填进去。2. 核心组件与布局参数解析2.1 卡片容器的圆角与阴影配置卡片容器本身不需要引入什么特殊组件一个Column、Row或者Stack都可以作为卡片底板关键在于样式参数的组合。HarmonyOS 6的ArkUI里圆角和阴影是卡片视觉的核心常用的写法如下Column() { // 卡片内容区 } .width(100%) .padding(16) .backgroundColor(Color.White) .borderRadius(16) .shadow({ radius: 16, color: rgba(0, 0, 0, 0.06), offsetX: 0, offsetY: 4 })这里有几个细节值得注意。shadow的radius参数控制阴影的模糊半径不是阴影的大小color的透明度决定了阴影的“存在感”透明度建议控制在0.04到0.08之间太浅了阴影等于没有太深了界面会显得脏。offsetX和offsetY控制阴影的偏移方向信息流卡片通常只给向下的偏移营造一种“卡片微微浮起”的效果左右偏移反而会让阴影显得不自然。关于圆角还有一个容易踩的坑如果卡片内部有图片且图片没有单独设置圆角图片会顶在卡片四角直角和圆角形成明显的割裂感。常见的处理方式是把外层卡片的圆角设置为16vp内部图片则用clip设置为跟随容器裁剪或者直接给图片单独设置borderRadius。怎么选取决于你的图片是否铺满卡片内容区。如果图片在卡片最上方我建议给图片单独设置上左、上右的圆角值比卡片圆角略小2vp左右视觉过渡更自然。这套微调逻辑同样适用于底部有操作栏的卡片。2.2 文字排版与截断的细节卡片里文字部分是最容易做糙的地方。很多新手会把标题、摘要、来源、时间全部用默认样式堆上去结果一眼看去全是黑的没有层级。正确的做法是建立一套字号和颜色的梯度。以资讯类卡片为例标题用17fp、中等字重、主文字色摘要用14fp、常规字重、次级文字色来源和时间用12fp、辅助文字色。同一张卡片里字号层级控制在3档以内字色层级控制在3档以内超过这个范围界面就会显得杂乱。文字一多就要考虑截断问题。ArkUI里控制两行截断很简单Text(this.news.title) .fontSize(17) .fontWeight(FontWeight.Medium) .fontColor(#182431) .maxLines(2) .textOverflow({ overflow: TextOverflow.Ellipsis }) .width(100%)注意maxLines和textOverflow必须配套设置否则内容会被直接裁掉而不是优雅地显示省略号。另外如果卡片标题本身是动态数据建议预留两行空间给超长标题一个缓冲。不要为了美观把所有卡片都压成固定高度数据一变就会破版。我能理解固定高度在视觉上很齐整但动态内容场景下固定的行数约束比固定的高度约束更安全。2.3 卡片间距与对齐的体系化间距是卡片布局中最能体现“高级感”的隐形因素。同样一组卡片间距调得好界面看起来就干净间距乱七八糟再好的设计稿也会被写废。我的做法是定义一套间距变量比如spacing_s 8vp、spacing_m 12vp、spacing_l 16vp、spacing_xl 24vp在同一个页面里尽量只取这套变量里的值避免到处写死数字。列表的外间距、卡片的内边距、元素之间的间距都从这套变量里取值界面整体的一致性就能大幅提升。对齐方面卡片内部的文字和图片要有一条统一的视觉左边界。我见过不少卡片标题左边对齐了但图片左边又缩进去了几个像素标签又单独居中导致整个卡片内部看起来是散的。解决方式很简单内容区用一个Column统一承载所有水平排列的元素比如“来源时间”这种行在Column内部也保持同一条左对齐线需要强调的右侧信息用Blank或space-between来推而不是靠嵌套Row反复调margin。这样无论是2倍屏还是3倍屏视觉左边界都能保持一致。3. 实操从零构建一个资讯卡片信息流3.1 数据模型与页面骨架理论说再多不如直接上手。我用一个资讯信息流页面来演示完整的卡片布局实现。先定义数据模型HarmonyOS 6的ArkTS对类型要求比较严格建议把所有卡片数据抽象成一个interfaceinterface NewsItem { id: string; title: string; summary: string; source: string; publishTime: string; tag: string; readCount: number; }页面的整体结构是顶部一个标题栏下面是一个List列表列表每一项是一张新闻卡片。页面组件和列表的框架搭起来之后效果就已经完成了一半。Entry Component struct NewsFeedPage { State newsList: NewsItem[] []; aboutToAppear(): void { this.loadData(); } loadData(): void { this.newsList [ { id: 1, title: HarmonyOS 6 新特性解析, summary: 从布局能力到性能优化几个值得关注的变化, source: 鸿蒙开发者, publishTime: 10分钟前, tag: 技术, readCount: 3200 }, // 更多模拟数据 ]; } build() { Column() { Row() { Text(资讯推荐) .fontSize(22) .fontWeight(FontWeight.Bold) .fontColor(#182431) } .width(100%) .padding({ left: 16, right: 16, top: 12, bottom: 12 }) List({ space: 12 }) { ForEach(this.newsList, (item: NewsItem) { ListItem() { NewsCard({ news: item }) .onClick(() { this.handleCardClick(item); }) } }, (item: NewsItem) item.id) } .width(100%) .layoutWeight(1) .padding({ left: 12, right: 12, top: 4, bottom: 12 }) .scrollBar(BarState.Off) .edgeEffect(EdgeEffect.Spring) } .width(100%) .height(100%) .backgroundColor(#F1F3F5) } }ForEach的第三个参数是key生成器这里用item.id作为唯一key。这个细节很关键如果不给keyArkUI在列表数据更新时可能复用错乱的item导致状态错位和渲染异常。id必须是数据里真正唯一的字段不要用index因为index在增删数据时会变化。我之前因为图省事用index做key结果删除列表中间某条数据后后面所有卡片的内部状态全部串位排查了很久才定位到问题。3.2 卡片的模板实现与样式细节接下来是卡片的实现。我把卡片封装成一个子组件NewsCard方便复用也让页面组件保持干净。这里的新闻卡片包含分类标签、标题、摘要、来源、阅读量、时间。为了演示不同场景下的复用方式我还用Builder做了一层模板封装。Component struct NewsCard { Prop news: NewsItem { id: , title: , summary: , source: , publishTime: , tag: , readCount: 0 }; build() { Column() { this.TagRow(this.news.tag) Text(this.news.title) .fontSize(17) .fontWeight(FontWeight.Medium) .fontColor(#182431) .maxLines(2) .textOverflow({ overflow: TextOverflow.Ellipsis }) .width(100%) .margin({ top: 8 }) Text(this.news.summary) .fontSize(14) .fontColor(#666666) .maxLines(2) .textOverflow({ overflow: TextOverflow.Ellipsis }) .width(100%) .margin({ top: 6 }) Row() { Text(this.news.source) .fontSize(12) .fontColor(#999999) Text(·) .fontSize(12) .fontColor(#999999) .margin({ left: 4, right: 4 }) Text(this.news.readCount.toString() 阅读) .fontSize(12) .fontColor(#999999) Blank() Text(this.news.publishTime) .fontSize(12) .fontColor(#999999) } .width(100%) .margin({ top: 12 }) } .width(100%) .padding(16) .backgroundColor(Color.White) .borderRadius(16) .shadow({ radius: 16, color: rgba(0, 0, 0, 0.06), offsetX: 0, offsetY: 4 }) } Builder TagRow(tag: string) { Text(tag) .fontSize(11) .fontColor(#0A59F7) .backgroundColor(#E8F0FE) .padding({ left: 8, right: 8, top: 3, bottom: 3 }) .borderRadius(4) } }这里我把标签封装成了Builder方法。使用Builder的好处是同一个组件里如果多个位置需要展示带不同参数的标签样式只需要调用TagRow并传入不同参数即可代码不会重复。标签的配色用的是浅蓝底加深蓝字这个组合在白色卡片下清晰度很高而且不会抢占标题的视觉权重。你也可以根据业务主题换配色但原则是一样的标签色和正文色要拉开层次标签本身要弱于标题不能喧宾夺主。关于Prop装饰器不同SDK版本的校验规则略有差异。我这里给Prop成员提供了默认值保证了组件在没有被父组件传参时也不会报错。你在自己项目里遇到编译报错时优先按SDK提示调整装饰器的初始化方式这不是什么大问题但卡住很浪费时间。3.3 点击反馈与跳转交互卡片作为点击入口点击反馈是必不可少的。ArkUI里的onClick默认有自己的按压态效果但默认效果比较生硬更像按钮的反馈不太适合整张卡片。我的做法是给卡片加一个透明度联动点击时卡片整体透明度降到0.9同时阴影稍微收一点模拟一种“被按下去”的物理感受。实际实现有两种方式。简单一点在onClick里通过State维护一个pressed标志位按下置true松开置false再给Column的opacity和shadow绑定这个标志位。复杂一点可以用触摸事件onTouch代替onClick在TouchType.Down、Up、Cancel时分别处理状态。后者更精准因为onClick只有松手才算触发如果用户按住卡片不放onClick还没触发时是没有任何反馈的体验上会有一种“死板”的感觉。用onTouch提前处理按压态交互会跟手很多。跳转方面卡片的onClick里调用router.pushUrl或页面路由跳转即可。如果卡片里还有独立的操作按钮比如“分享”“删除”注意按钮自身的onClick和卡片父容器的onClick可能会同时触发。我实际遇到的情况是点卡片内的“删除”按钮会先触发按钮自身的逻辑紧接着又触发了卡片的跳转逻辑。解决思路是把交互拆分清楚卡片的点击区域不要覆盖到操作按钮上或者对事件做拦截。这块在HarmonyOS里的处理方式和Web端不太一样不能想当然用stopPropagation那一套要以真机实测为准。4. 常见问题与排查技巧实录4.1 圆角失效和阴影显示不正常的排查写卡片布局时圆角和阴影是最容易出问题的两个点。我遇到过几次“圆角没生效”的情况最终定位下来基本都是同一个原因卡片容器自身设置了背景色但内部某个子元素比如铺满全宽的图片没有被裁剪把圆角区域完全盖住了。换句话说圆角其实生效了但被内部的直角元素遮住了视觉。解决办法有两个一是内部图片单独设置圆角二是给内部图片包一层带裁剪的容器用clip(true)让内容跟随容器形状裁剪。阴影显示不正常的典型案例是阴影设了但完全看不见或者阴影出现一个明显的“方块轮廓”。前者的原因是阴影透明度设得太低或者阴影半径太小、偏移太大导致阴影被挤出可视区域后者的原因通常是容器背景色不透明白阴影被强底色覆盖。排查时先把阴影的颜色透明度调到0.2以上确认能看到阴影轮廓后再逐步调回合适的视觉值这样能快速定位是参数问题还是层级问题。这个习惯帮我省了很多反复试参数的时间。4.2 长列表卡顿与LazyForEach的使用很多人在信息流卡片数量超过几十条时会遇到滚动卡顿。原因往往不是卡片样式太复杂而是用了ForEach一次性渲染全部数据。HarmonyOS的ArkUI对长列表有专门的懒加载方案LazyForEach。它只在列表滚动到可视区域附近时才创建对应item的组件配合List的缓存扩展属性能显著降低内存和渲染压力。用LazyForEach需要实现一个IDataSource接口类负责管理数据集合。核心步骤整理如下class NewsDataSource implements IDataSource { private list: NewsItem[] []; private listeners: DataChangeListener[] []; totalCount(): number { return this.list.length; } getData(index: number): NewsItem { return this.list[index]; } registerDataChangeListener(listener: DataChangeListener): void { this.listeners.push(listener); } unregisterDataChangeListener(listener: DataChangeListener): void { const index this.listeners.indexOf(listener); if (index -1) { this.listeners.splice(index, 1); } } addData(item: NewsItem): void { this.list.push(item); this.listeners.forEach(listener { listener.onDataAdd(this.list.length - 1); }); } }然后在List里这样用List({ space: 12 }) { LazyForEach(this.dataSource, (item: NewsItem) { ListItem() { NewsCard({ news: item }) } }, (item: NewsItem) item.id) } .cachedCount(5)LazyForEach的key生成器同样不能省略而且要求key在数据范围内绝对唯一。实际使用中还有一个细节数据更新时不要直接替换整个dataSource而是通过addData、deleteData这类方法触发对应的监听回调。如果整体替换LazyForEach会认为数据发生了大范围变化可能重建大量item反而更卡。cachedCount这个属性可以设置列表在可视区域外提前缓存的item数量我一般取5左右平衡内存和滚动流畅度。4.3 不同屏幕尺寸与折叠屏的适配卡片布局在不同设备上的适配核心是间距和列数的弹性处理。普通手机竖屏下资讯卡片单列展示没有争议但到了平板和折叠屏展开态单列卡片会变得非常宽阅读时视线来回扫动的距离太长。合理做法是让卡片集合的列数根据屏幕宽度动态变化窄屏一列宽屏两列。在ArkUI里可以通过Grid的columnsTemplate动态设置列数或者监听屏幕宽度来做切换。折叠屏的适配还要注意卡片内部的图片比例。折叠态和展开态的屏幕宽高比不同卡片内图片如果写死高度展开后就会拉伸变形。我的建议是图片高度用aspectRatio约束不写死vp让图片自己去适配容器宽度。容器宽度变了高度按比例自动调整图片不会变形卡片高度也会自然伸缩。这套做法在多种折叠形态下基本都能保持稳定。除了宽度适配还要检查卡片左右两侧的间距是否足够折叠屏展开后如果卡片贴着屏幕边缘视觉上会显得很压迫。5. 性能优化与视觉细节打磨5.1 骨架屏与加载状态信息流页面刚进入时数据往往还在加载。如果直接白屏用户会以为页面坏了如果直接显示loading转圈体验又显得粗糙。我在实际项目中更推荐骨架屏方案用一组灰色圆角块模拟卡片的形状和布局数据加载完成后替换成真实卡片。骨架屏的实现并不复杂写一个SkeletonCard组件内部放几个灰色的矩形块分别对应标签、标题、摘要、底部信息行的位置配合透明度动画循环播放视觉上非常自然。骨架屏的圆角要和真实卡片保持一致宽度和Padding也要一致不然加载完成后布局会发生跳动。我见过不少页面骨架屏和真实列表的圆角一个12一个16或者内边距差了4vp切换时整个页面明显抖了一下这种细节相当影响体感。如果你是第一次写骨架屏建议直接从真实卡片的样式复制一份把文字替换成灰色块成功率会高很多。5.2 深色模式下卡片的配色处理HarmonyOS 6的应用普遍要适配深色模式卡片布局在深色模式下最容易翻车的就是阴影和背景色。深色模式下卡片背景不能继续用纯白通常会换成深灰色系的卡片色但阴影如果还用黑色系透明度在深色背景上会完全看不出来。这时候阴影要改为调整卡片与背景的亮度差用比背景更亮一点的卡片色加上1vp左右的边框线让卡片在深色背景中“浮”出来。我这里用资源文件管理颜色的方式来处理把卡片背景色、标题色、副标题颜色都定义成系统资源在resources里分别为浅色模式和深色模式配置不同的值。代码里不要直接用Color.White这种写死的颜色而是用$r(app.color.card_bg)这样的资源引用系统会自动根据当前模式加载对应值。改起来也方便不用在代码里到处找颜色值替换。我之前在浅色模式下把颜色全部写死后来接深色模式的时候翻了两个小时的代码从此再也不敢偷这个懒。5.3 我实测下来的几个心得写卡片布局写到一定量之后我明显感觉有几个原则值得反复强调。第一不要在一个页面上堆超过三种卡片样式。样式多了页面看起来热闹但其实信息层级全被拉平了。信息流页面里核心卡片用一种样式次要内容用相对弱化的样式特殊内容用突出样式三种足以应付绝大多数场景。第二卡片内部的点击热区要足够大。卡片可能只有80vp高但内部文字的点击区域如果只包在文字上用户每次点击都要精确瞄准体验非常差。我习惯把点击事件绑在卡片容器上而不是绑在内部某个Text上。这样整张卡片都是热区加一个按压反馈交互体感会好很多。第三动画别贪多。卡片布局的入场动画、列表的滚动回弹、点击的按压效果加起来不需要很复杂做一两处精的就好。如果每个元素都加动画界面反而显得轻浮。我目前的信息流页面只保留了按压反馈和骨架上屏的渐隐效果用户普遍反馈干净利落。我在实际项目里反复验证过这套卡片布局方案从演示Demo到上线的信息流应用最核心的改动始终围绕间距体系、圆角阴影和文字层级这三件事。如果你正打算在HarmonyOS 6上做信息展示类页面建议先别急着堆功能拿一个最简单的卡片列表把上面这些参数调一遍你会明显感受到界面的变化。我个人还有个习惯每次调完间距和圆角都会把页面切到多设备预览模式看一眼整体节奏哪里挤了哪里松了一眼就能看出来。这个习惯帮我少走了很多返工的弯路你可以试试。