文章目录前言为什么这个问题经常被写乱场景资讯列表首屏加载骨架块设计实操步骤先把页面目标想清楚完整示例资讯卡片骨架组件把关键代码一段段拆开容易踩坑的点优化建议骨架组件要轻但不能失真写在最后前言骨架屏不是灰色占位块越多越专业。它应该贴近真实页面结构让用户知道内容正在加载也让页面从加载到完成时不会明显跳动。这篇单独聊通用加载这个场景。重点不是堆 API而是把骨架屏抽成足够小的 ArkUI 构建器让加载态贴近真实页面结构。为什么这个问题经常被写乱页面骨架如何做成组件 这类内容很容易被写成“代码能跑就算讲完了”但对初学者来说这恰恰是最不够的地方。真正让人卡住的往往不是某个组件名记不住而是不知道这段代码为什么要这样拆、状态为什么要这样放、以后需求变化时应该从哪里改。所以这篇文章不只想给你一个能跑的例子更想把背后的判断过程讲清楚。你只要把这个判断过程吃透后面自己改页面、补需求、查问题时心里会稳很多。场景资讯列表首屏加载骨架屏不是把页面涂成一片灰色。它应该告诉用户这里会有标题、这里会有摘要、这里会有列表卡片。资讯、课程、订单、商品列表这类页面如果加载时只放一个转圈用户不知道还要等多久如果骨架结构贴近真实内容等待感会明显降低。我做骨架组件时会控制复杂度。骨架应该是轻量的 UI 片段不应该复制一份完整业务卡片。复制得越像维护成本越高抽得太粗又失去降低跳动的意义。骨架屏不是装饰它是“页面马上会长什么样”的预告。骨架块设计骨架块对应真实内容尺寸建议注意点SkeletonLine标题、摘要12 到 22 vp 高宽度不要全满SkeletonAvatar头像、图标32 到 48 vp圆角贴近真实图形SkeletonCard列表卡片接近真实卡片高度避免加载完成大跳动SkeletonAction按钮32 到 40 vp 高不要太抢眼实操步骤先画真实页面结构再反推骨架块而不是先画灰块。抽出最小单元SkeletonLine复用颜色和圆角。再组合出ArticleSkeletonCard这类业务骨架。加载态和内容态用同一块页面区域切换避免高度差过大。骨架数量与首屏可见内容接近不要一次渲染几十个灰块。接口失败时切到错误态不要让骨架无限显示。先把页面目标想清楚在真正写代码之前先别急着盯着 API。更有用的做法是先想清楚这个页面到底想解决什么问题用户最在意的反馈是什么哪些状态必须一直保持一致。当你先把这条主线想明白再回头看组件和状态设计很多选择都会顺理成章。对小白来说这一步尤其重要因为它能帮你从“照着抄”慢慢过渡到“看得懂、改得动”。完整示例资讯卡片骨架组件interfaceArticleItem{id:numbertitle:stringsummary:stringauthor:string}EntryComponentstruct SkeletonComponentPage{Stateloading:booleantrueStatefailed:booleanfalseprivatearticles:ArticleItem[][{id:1,title:ArkUI 列表加载的几个细节,summary:从骨架屏、空态到错误兜底整理一个更完整的加载体验。,author:编辑部},{id:2,title:HarmonyOS7 页面状态管理实践,summary:用明确状态减少页面闪动和重复判断。,author:技术团队}]BuilderSkeletonLine(widthValue:Length,heightValue:number,radiusValue:number){Blank().width(widthValue).height(heightValue).backgroundColor(#E6EAF0).borderRadius(radiusValue)}BuilderArticleSkeletonCard(){Row({space:12}){this.SkeletonLine(48,48,8)Column({space:10}){this.SkeletonLine(64%,18,4)this.SkeletonLine(92%,14,4)this.SkeletonLine(48%,14,4)}.alignItems(HorizontalAlign.Start).layoutWeight(1)}.padding(14).backgroundColor(#FFFFFF).borderRadius(8)}BuilderArticleCard(item:ArticleItem){Row({space:12}){Text(item.author.substring(0,1)).fontSize(18).fontWeight(FontWeight.Bold).fontColor(#FFFFFF).width(48).height(48).textAlign(TextAlign.Center).backgroundColor(#0A59F7).borderRadius(8)Column({space:6}){Text(item.title).fontSize(16).fontWeight(FontWeight.Medium).maxLines(1).textOverflow({overflow:TextOverflow.Ellipsis})Text(item.summary).fontSize(13).fontColor(#666666).maxLines(2).textOverflow({overflow:TextOverflow.Ellipsis})Text(item.author).fontSize(12).fontColor(#999999)}.alignItems(HorizontalAlign.Start).layoutWeight(1)}.padding(14).backgroundColor(#FFFFFF).borderRadius(8)}privatereload(){this.loadingtruethis.failedfalse}build(){Column({space:12}){Row(){Text(加载示例).fontSize(22).fontWeight(FontWeight.Bold)Blank()Button(this.loading?显示内容:显示骨架).onClick(()this.loading!this.loading)}.width(100%)if(this.failed){Column({space:8}){Text(加载失败).fontSize(18).fontWeight(FontWeight.Medium)Text(网络不稳定请稍后重试。).fontSize(13).fontColor(#666666)Button(重试).onClick(()this.reload())}.alignItems(HorizontalAlign.Start).padding(14).backgroundColor(#FFFFFF).borderRadius(8)}elseif(this.loading){this.ArticleSkeletonCard()this.ArticleSkeletonCard()this.ArticleSkeletonCard()}else{ForEach(this.articles,(item:ArticleItem){this.ArticleCard(item)},(item:ArticleItem)item.id.toString())}}.padding(16).height(100%).backgroundColor(#F5F7FA)}}把关键代码一段段拆开SkeletonLine()是最小单元只关心宽、高、圆角。这样标题线、摘要线、头像占位都能复用同一套灰色样式不需要到处复制backgroundColor。ArticleSkeletonCard()的结构和真实ArticleCard()接近左侧头像右侧三行文字。加载完成后高度变化很小页面不会突然跳动。failed和loading分开处理。骨架只能表示“正在加载”不能拿来表示“加载失败”。接口失败后如果骨架一直转用户会以为还在等。容易踩坑的点骨架和真实内容高度差太大加载完成时页面明显跳动。骨架数量过多反而增加首屏渲染压力。把骨架写成完整业务组件的复制版后续维护两套结构。失败后仍显示骨架没有错误兜底。所有灰块宽度都一样看起来不像真实内容。优化建议骨架屏适合超过短暂等待的页面。如果接口通常几十毫秒返回强行闪一下骨架反而打扰用户。可以设置一个很小的延迟策略请求很快完成就不展示骨架请求超过一定时间再展示。颜色上不要用太重的灰尤其是在浅色背景里。骨架应该低调地暗示结构不应该抢走真实内容的位置感。深色模式下也要单独调整骨架色否则灰块可能过亮。骨架组件要轻但不能失真骨架屏的价值在于降低等待感和布局跳动不是复制一套完整业务 UI。灰块要贴近真实内容结构让用户知道页面马上会出现什么但它又不能和真实卡片完全同步维护否则后面改一次业务卡片就要改两份代码。示例先抽SkeletonLine()作为最小单元再组合成ArticleSkeletonCard()。这样颜色、圆角和尺寸可以复用资讯卡片的左图右文结构也能保留下来加载完成时页面不会明显跳动。写在最后失败态要和加载态分开。骨架只表示“正在加载”接口失败后应该切到错误提示和重试入口。如果骨架无限显示用户会以为还在等待实际已经没有下一步了。