企业官网建设流程全解析

每日一句正能量

那些在兜兜转转的过程中得到的东西，给你打开了一条崭新的人生道路。
你以为是绕远，其实那些额外的经历、遇见的人、偶然学会的技能，最后拼出了你独有的地图。直线是机器的逻辑，曲折是生命的逻辑。

导读

说明：本文中的业务指标来自一个经过脱敏和重新建模的企业案例，用于演示分析方法与工程方案。“留存提升 30%”指实验组 7 日留存率相对对照组提升约 30%，不是提升 30 个百分点，也不代表所有应用接入后都能得到相同结果。

一、为什么电商物流值得用实况窗重做一遍

电商应用中，用户下单后的核心诉求很简单：我的包裹到哪里了，还要多久到？

但在传统实现里，这个问题往往需要用户完成一条很长的路径：

1. 收到一条普通通知；
2. 点击通知进入应用；
3. 等待首页、推荐流和活动资源加载；
4. 打开“我的”；
5. 进入订单列表；
6. 找到目标订单；
7. 再进入物流详情页。

这条路径的问题不只是“多点了几次”。在真实业务中，它会同时引发三类损耗：

• 信息损耗：通知正文只能承载一个时间点，用户无法持续感知物流变化；
• 路径损耗：每多一次页面跳转，都会增加退出概率；
• 信任损耗：状态更新滞后或展示不一致，会让用户重复查询，甚至联系商家客服。

HarmonyOS 6.1 的实况窗提供了一种更符合物流场景的交互方式：应用可将订单或服务的实时变化持续呈现在熄屏、锁屏、状态栏和通知中心，并管理创建、更新和结束等生命周期。对于即时配送、快递运输、打车、排队等“状态持续变化”的业务，这比一次性通知更贴近用户心智。

从产品视角看，实况窗并不是“更漂亮的通知”，而是一个系统级、持续存在、可被动态更新的服务状态入口。用户不必反复打开应用，就能看到当前节点；当需要更多信息时，再点击直达订单详情或地图页面。

二、案例背景：我们到底想解决什么问题

本文以一个日均订单量较高的综合电商应用为例。升级前，物流相关数据存在以下特点：

团队没有把“提高留存”直接设为唯一目标，而是拆成四个更可执行的子目标：

1. 将物流查询路径从 6 步左右缩短到 2～3 步；
2. 提升关键节点的有效曝光，而不是增加无意义通知；
3. 保证应用进程退出后，物流状态仍可被及时更新；
4. 建立从端侧、云端到数据分析的一致状态模型。

这一步非常重要。实况窗是一种系统能力，但最终效果取决于业务状态是否准确、更新节奏是否合理、跳转是否直达。如果只是把普通通知的文案搬进实况窗，用户体验不会发生本质变化。

三、方案总览：订单状态机驱动实况窗生命周期

我们将物流履约过程抽象为以下状态：

WAIT_PICKUP 待揽收 IN_TRANSIT 运输中 ARRIVED_STATION 到达站点 OUT_FOR_DELIVERY 派送中 NEARBY 即将送达 SIGNED 已签收 EXCEPTION 配送异常 CANCELED 已取消

每个状态不直接对应一条通知，而是对应一套展示策略：

这里有三个设计原则。

1. 生命周期必须由业务状态机统一管理

创建、更新和结束实况窗不能散落在多个页面或 ViewModel 中，否则很容易出现：

• 同一订单创建多个实况窗；
• 已签收订单仍停留在锁屏；
• 页面状态与系统展示状态不一致；
• 用户切换账号后仍看到旧订单；
• 灰度开关关闭后无法及时终止展示。

因此，我们在领域层增加DeliveryLiveViewCoordinator，只接受规范化后的物流事件，不直接依赖页面生命周期。

2. 端侧负责体验，云侧负责持续更新

端侧适合处理：

• 用户刚下单后创建实况窗；
• 用户打开应用时纠正状态；
• 点击实况窗后的页面路由；
• 读取本地灰度开关和用户设置。

云侧适合处理：

• 应用进程退出后的物流状态更新；
• 长时间运输期间的节点变化；
• 派送阶段的预计到达时间变化；
• 签收后结束实况窗；
• 异常订单的统一止损。

3. 每个更新都必须可幂等

物流平台、消息队列和推送通道都可能重复投递。更新请求必须带上订单 ID、事件 ID、状态版本号和事件时间。端侧或服务端应拒绝旧版本覆盖新版本。

exportinterfaceDeliveryEvent{orderId:stringeventId:stringstatusVersion:numberstatus:DeliveryStatus eventTime:numberstationName?:stringcourierName?:stringetaMinutes?:number}

四、工程架构：把实况窗隔离在业务适配层

推荐的模块结构如下：

features/delivery ├── domain │ ├── DeliveryStatus.ets │ ├── DeliveryEvent.ets │ └── DeliveryLiveViewPolicy.ets ├── data │ ├── DeliveryRepository.ets │ └── DeliveryEventStore.ets ├── liveview │ ├── DeliveryLiveViewCoordinator.ets │ ├── LiveViewPayloadMapper.ets │ └── LiveViewGateway.ets └── ui ├── DeliveryDetailPage.ets └── DeliveryMapPage.ets

LiveViewGateway封装系统实况窗能力，业务层只关心“创建、更新、结束”三个动作。

下方代码用于说明分层和调用思路。不同 SDK/API Level 的类型名、字段和权限配置可能变化，请以投稿时使用的 HarmonyOS SDK 与官方文档为准。

exportinterfaceDeliveryLiveViewData{orderId:stringtitle:stringcontent:stringprogress?:numberetaText?:stringdeeplink:stringversion:number}exportinterfaceLiveViewGateway{isEnabled():Promise<boolean>create(data:DeliveryLiveViewData):Promise<string>update(liveViewId:string,data:DeliveryLiveViewData):Promise<void>end(liveViewId:string,finalText:string):Promise<void>}

Coordinator 负责状态判断：

exportclassDeliveryLiveViewCoordinator{constructor(privategateway:LiveViewGateway,privatestore:DeliveryEventStore,privatepolicy:DeliveryLiveViewPolicy){}asynconDeliveryEvent(event:DeliveryEvent):Promise<void>{constlatest=awaitthis.store.getLatest(event.orderId)if(latest&&event.statusVersion<=latest.statusVersion){return}awaitthis.store.save(event)if(!awaitthis.gateway.isEnabled()){return}constaction=this.policy.resolve(event,latest)switch(action.type){case'CREATE':constliveViewId=awaitthis.gateway.create(action.data)awaitthis.store.bindLiveView(event.orderId,liveViewId)breakcase'UPDATE':awaitthis.gateway.update(action.liveViewId,action.data)breakcase'END':awaitthis.gateway.end(action.liveViewId,action.finalText)breakcase'IGNORE':break}}}

这层抽象有四个收益：

• 业务逻辑可以单元测试；
• 系统 API 变化时只修改 Gateway；
• 灰度阶段可切换为“普通通知 Gateway”；
• 可以为不同订单类型配置不同策略。

五、创建实况窗：不要下单后立刻无脑创建

并不是每个订单都需要实况窗。我们增加了创建条件：

exportclassDeliveryLiveViewPolicy{shouldCreate(event:DeliveryEvent,user:UserProfile):boolean{if(!user.liveViewEnabled)returnfalseif(event.status===DeliveryStatus.CANCELED)returnfalseif(event.status===DeliveryStatus.SIGNED)returnfalseif(user.isGuest)returnfalsereturn[DeliveryStatus.IN_TRANSIT,DeliveryStatus.ARRIVED_STATION,DeliveryStatus.OUT_FOR_DELIVERY,DeliveryStatus.NEARBY].includes(event.status)}}

具体项目中，还可以增加：

• 订单金额或订单类型；
• 用户是否主动订阅物流提醒；
• 是否为同城即时配送；
• 当前活跃实况窗数量；
• 预计履约时长；
• 系统开关与应用内开关；
• 用户是否处于免打扰时间；
• 业务是否具备正式实况窗权限。

我们的实践是：普通快递在“到达本地站点”后创建，高时效订单在“开始配送”时创建。这样既能减少长时间占用，又能覆盖用户最关心的阶段。

六、更新策略：信息越实时，不代表更新越频繁

物流位置可能每几十秒变化一次，但系统级展示不应该每几十秒更新。过度更新会带来功耗、网络、推送成本和打扰感。

我们采用“事件触发 + 时间窗口 + 变化阈值”的组合策略：

exportfunctionshouldUpdate(previous:DeliveryEvent,current:DeliveryEvent):boolean{if(current.status!==previous.status){returntrue}if(current.etaMinutes!==undefined&&previous.etaMinutes!==undefined&&Math.abs(current.etaMinutes-previous.etaMinutes)>=5){returntrue}if(current.stationName!==previous.stationName){returntrue}consttenMinutes=10*60*1000returncurrent.eventTime-previous.eventTime>=tenMinutes}

派送阶段的更新规则可以更细：

• 配送状态发生变化：立即更新；
• 预计时间变化小于 5 分钟：不更新；
• 距离变化不足业务阈值：不更新；
• 连续更新间隔小于 3 分钟：合并；
• 用户正在物流详情页：优先页面内实时刷新，降低系统更新频率；
• 已签收：立即更新最终状态并结束。

七、通过 Push Kit 远程更新：应用退出后仍保持进度同步

实况窗真正适合物流的原因之一，是它可以通过云端持续更新，而不是依赖应用一直存活。

推荐链路：

物流供应商回调 ↓ 订单履约平台标准化事件 ↓ 消息队列去重、排序 ↓ 实况窗编排服务 ↓ Push Kit 场景化消息 ↓ HarmonyOS 系统更新实况窗

服务端需要保存：

{"orderId":"O202607180001","userId":"U10086","liveViewId":"LV_xxx","pushToken":"token_xxx","statusVersion":18,"lastUpdateTime":1784368800000,"grayGroup":"B"}

云端编排服务不能直接把物流供应商原始状态透传给客户端。不同物流公司的状态码、时间格式和站点名称差异很大，必须先映射到统一领域模型。

例如：

exportfunctionnormalizeCarrierStatus(code:string):DeliveryStatus{constmapping:Record<string,DeliveryStatus>={'PICKED':DeliveryStatus.IN_TRANSIT,'ARRIVE_SITE':DeliveryStatus.ARRIVED_STATION,'DELIVERING':DeliveryStatus.OUT_FOR_DELIVERY,'SIGNED':DeliveryStatus.SIGNED,'FAILED':DeliveryStatus.EXCEPTION}returnmapping[code]??DeliveryStatus.IN_TRANSIT}

八、实况窗 UI：让用户一眼看到“现在”和“下一步”

物流实况窗中，最重要的信息不是品牌口号，而是：

1. 当前状态；
2. 预计送达时间；
3. 当前站点或配送位置；
4. 下一步动作；
5. 点击后的直达入口。

推荐文案：

主标题：订单正在配送 主信息：骑手已到达春华路 辅助信息：预计 18:42 送达 点击动作：查看实时地图

不推荐文案：

主标题：您的宝贝正在飞奔而来 主信息：精彩好物马上送到 辅助信息：点击查看更多惊喜

后者营销感强，却没有回答用户最关心的问题。

设计时还要注意：

• 不显示完整手机号、详细门牌号等敏感信息；
• 不在锁屏上暴露商品名称、价格等隐私信息；
• 异常状态要提供客服或修改地址入口；
• 多订单并行时明确区分订单尾号；
• 文案长度应适配不同显示形态；
• 点击区域必须与文案承诺一致；
• 实况窗结束后，深链仍需能处理订单已签收状态。

九、深链直达：点击后不要再把用户丢到首页

实况窗点击后的路由建议携带最少且安全的业务参数：

myshop://delivery/detail?orderId=O202607180001&source=liveview

路由处理器需要完成：

1. 校验登录状态；
2. 校验订单归属；
3. 校验订单是否存在；
4. 恢复应用导航栈；
5. 直接打开物流详情；
6. 记录来源为liveview；
7. 处理订单已取消或已签收等状态变化。

示例：

exportasyncfunctionhandleDeliveryDeepLink(uri:string):Promise<void>{constparams=parseUri(uri)constorderId=params.get('orderId')if(!orderId){Router.replaceUrl({url:'pages/HomePage'})return}constsession=awaitSessionManager.getCurrent()if(!session.isLoggedIn){Router.pushUrl({url:'pages/LoginPage',params:{redirect:uri}})return}constorder=awaitDeliveryRepository.getOrder(orderId)if(!order||order.userId!==session.userId){Router.replaceUrl({url:'pages/OrderListPage'})return}Router.replaceUrl({url:'pages/DeliveryDetailPage',params:{orderId,source:'liveview'}})}

十、数据实验：如何得到“7 日留存相对提升 30%”

我们采用用户级随机分流，而不是订单级随机分流。原因是同一用户可能有多个订单，如果一个订单进入实验组、另一个进入对照组，会造成体验污染。

实验设计

示例结果：

• 对照组 7 日留存率：24.7%
• 实验组 7 日留存率：32.1%
• 绝对提升：7.4 个百分点
• 相对提升：(32.1% - 24.7%) / 24.7% ≈ 30.0%

这就是标题中“提升 30%”的统计口径。

需要特别强调：留存提升并不全部来自实况窗本身。它通常由多项改造共同贡献：

• 物流数据刷新更及时；
• 点击后页面直达；
• 页面加载性能优化；
• 异常状态解释更清楚；
• 客服入口更容易找到；
• 通知频率得到控制。

因此，正式复盘时应同时记录版本改动，避免把所有提升都归因于单一能力。

十一、埋点模型：至少记录这 12 个事件

liveview_eligible liveview_create_request liveview_create_success liveview_create_fail liveview_update_request liveview_update_success liveview_update_fail liveview_exposure liveview_click liveview_deeplink_success liveview_deeplink_fail liveview_end

公共参数建议包括：

exportinterfaceLiveViewAnalyticsContext{orderIdHash:stringuserGroup:'control'|'experiment'deliveryStatus:stringliveViewTemplate:stringstatusVersion:numbersource:'local'|'push'networkType?:stringosVersion?:stringappVersion:stringtimestamp:number}

不要直接上传手机号、地址、商品名称等敏感信息。订单 ID 也建议哈希或使用分析侧匿名标识。

关键转化漏斗：

符合创建条件 → 创建请求 → 创建成功 → 系统曝光 → 用户点击 → 深链解析成功 → 到达物流详情 → 完成有效查看

“有效查看”可定义为：

• 页面停留超过 3 秒；
• 地图或节点列表成功加载；
• 用户主动展开物流详情；
• 用户未在 1 秒内返回。

十二、灰度发布：从 1% 到 100% 的五个阶段

阶段 0：内部验证

覆盖：

• 开发、测试、产品、客服；
• 多型号设备；
• 锁屏、熄屏、状态栏、通知中心；
• 应用前台、后台、进程退出；
• 登录切换、多订单、取消、退款、签收；
• 网络抖动、重复推送、乱序事件。

阶段 1：1% 白名单灰度

重点观察：

• 创建成功率；
• 更新成功率；
• 深链成功率；
• 崩溃率；
• 用户主动关闭率；
• 客服新增咨询。

阶段 2：5% 随机灰度

验证分流和数据口径，至少运行 2～3 天，避免只看首日波动。

阶段 3：20% 分层灰度

按用户活跃度、订单类型、地区、设备版本分层，检查是否存在特定人群负向效果。

阶段 4：50% 对照实验

形成稳定统计结论，重点观察留存、点击率、物流详情到达率和投诉率。

阶段 5：全量发布

全量不等于关闭监控。仍要保留：

• 服务端总开关；
• 用户级开关；
• 模板级开关；
• 物流公司级开关；
• 订单类型级开关；
• 快速结束现有实况窗的能力。

十三、常见踩坑与修复方案

坑 1：订单签收后实况窗没有结束

原因：签收事件被消息队列延迟，或结束动作只写在详情页。

修复：结束动作放到统一 Coordinator 和云端编排服务；增加超时关闭兜底。

坑 2：旧物流状态覆盖新状态

原因：不同物流节点乱序到达。

修复：引入statusVersion，低版本事件直接丢弃。

坑 3：同一订单重复创建

原因：本地创建成功后未及时持久化liveViewId，重启后再次创建。

修复：以订单 ID 建唯一绑定关系；创建请求增加幂等键。

坑 4：点击后进入首页

原因：冷启动导航栈尚未初始化，路由参数被消费过早。

修复：将深链暂存到启动协调器，待会话和路由准备完成后执行。

坑 5：多账号切换后展示旧订单

原因：账号退出只清理页面缓存，没有结束旧账号实况窗。

修复：退出登录时结束或解绑该账号全部活动实况窗。

坑 6：更新太频繁

原因：把骑手 GPS 位置变化直接映射为实况窗更新。

修复：使用变化阈值、最小间隔和状态聚合。

坑 7：实验数据虚高

原因：实验组只选择高活跃用户，分流不随机。

修复：用户 ID 稳定哈希；实验前比较两组历史活跃度。

坑 8：标题中的“30%”被误解

原因：没有区分相对提升和绝对百分点。

修复：正文明确展示计算公式和原始指标。

坑 9：普通通知与实况窗重复轰炸

原因：两个系统各自独立发送。

修复：建立统一触达策略。实况窗已成功展示时，抑制低价值普通通知。

坑 10：异常配送只显示“异常”

原因：状态模型过于粗糙。

修复：增加可操作信息，例如“地址无法联系”“站点滞留”“天气延迟”，并提供对应入口。

十四、性能与稳定性要求

实况窗接入后，不能以牺牲启动性能和稳定性为代价。

推荐指标：

端侧日志需要包含：

traceId orderIdHash liveViewIdHash eventId statusVersion action result errorCode duration appVersion osVersion

日志要可关联，但不能泄露隐私。

十五、隐私与合规

物流实况窗位于锁屏等高曝光区域，隐私风险比普通应用页面更高。

必须做到：

• 默认不展示完整收货地址；
• 默认不展示完整姓名和手机号；
• 不展示商品敏感信息；
• 用户可在应用内关闭物流实况窗；
• 退出账号后清理关联展示；
• 埋点使用匿名标识；
• 第三方物流数据只保留必要字段；
• 清晰说明物流信息用途；
• 正式发布前完成实况窗权限与设计规范审核；
• 对未成年人、医疗、贵重物品等敏感订单采用更保守文案。

十六、校企实训建议：把它做成一门完整项目课

作为校企合作课程，可以将本案例拆成四周实训。

第一周：产品与状态建模

学生输出：

• 用户旅程图；
• 物流状态机；
• 实况窗创建和结束条件；
• 隐私字段清单；
• 指标定义。

第二周：端侧工程实现

学生完成：

• ArkTS 领域模型；
• Gateway 接口；
• Coordinator；
• 深链路由；
• 本地模拟事件。

第三周：云端更新与灰度

学生完成：

• 模拟物流回调；
• 事件去重；
• 版本排序；
• Push 更新；
• 灰度开关。

第四周：数据分析与答辩

学生提交：

• 漏斗分析；
• A/B 实验报告；
• 异常案例复盘；
• 性能数据；
• 演示视频。

评分可以按“技术实现 40% + 产品体验 25% + 数据分析 20% + 合规与答辩 15%”设计，让学生不仅会调用 API，还能理解企业级上线过程。

十七、上线检查清单

业务

• 状态机覆盖全部物流节点
• 创建条件经过产品确认
• 已签收和已取消能够结束
• 多订单展示策略明确
• 异常状态有可操作入口

技术

• 创建、更新、结束统一封装
• liveViewId持久化
• 事件具备版本号
• 重复事件可幂等
• 乱序事件不会回退
• 冷启动深链可恢复
• 登录切换能清理旧数据
• 云端更新链路可监控
• 应用退出后仍可更新
• 服务端总开关可立即关闭

体验

• 锁屏文案不泄露隐私
• 文案在不同形态下不截断
• 点击后直达对应订单
• 不与普通通知重复打扰
• 更新频率符合用户预期
• 配送异常说明清楚
• 已签收状态不会长期驻留

数据

• 实验按用户分流
• 对照组和实验组基线一致
• 相对提升与百分点区分
• 埋点不含敏感字段
• 漏斗事件可完整关联
• 护栏指标已配置
• 实验周期覆盖工作日和周末

十八、总结

HarmonyOS 6.1 实况窗给电商物流带来的最大价值，不是“多了一个系统展示位”，而是把原本分散在通知、首页、订单列表和物流详情中的信息，重构成一条持续、直达、可感知的服务链路。

在本文案例中，团队通过以下组合改造，使物流查看路径从约 21.4 秒缩短到 7.2 秒，通知点击率从 12.8% 提升到 20.6%，7 日留存率从 24.7% 提升到 32.1%，相对提升约 30%：

• 用统一物流状态机驱动实况窗生命周期；
• 通过 Push Kit 支持应用退出后的远程更新；
• 使用版本号和幂等键解决重复、乱序事件；
• 通过深链直达物流详情，减少无效页面跳转；
• 用合理的更新阈值避免高频打扰；
• 采用用户级随机灰度验证业务效果；
• 建立隐私、监控、回滚和结束兜底机制。

真正优秀的实况窗，不是一直“亮着”，而是在用户需要时，用最短路径提供最可信的信息。

转载自：https://blog.csdn.net/u014727709/article/details/162995131
欢迎 👍点赞✍评论⭐收藏，欢迎指正