App 进程都被杀了外卖进度为什么还能继续更新做外卖进度实时展示的时候最开始的思路很简单App 里开个轮询每隔几秒请求一次进度接口然后更新实况窗。跑了一段时间发现问题用户把 App 杀了轮询停了实况窗就不动了。用户看着进度条卡在那里还以为外卖不送了。这时候才意识到本地更新依赖 App 进程进程死了就停了。要让实况窗在 App 不存活的时候还能更新得把更新链路转移到服务端用 Push 来推。一、本地更新和远程更新有什么区别先把概念理清楚类型更新方式App 存活时App 被杀后本地更新App 进程轮询正常更新停了远程更新服务端 Push正常更新继续更新本地更新就是 App 自己在跑进程活着就能更新。远程更新是服务端通过 Push Kit 把新状态推给系统系统直接更新实况窗不需要 App 进程活着。二、实况窗的三个阶段一个完整的实况窗生命周期分三个阶段阶段操作谁来做创建创建 LiveView生成 IDApp 做更新更新进度状态本地 or 远程结束停止 LiveView本地 or 远程创建阶段肯定是 App 做的因为用户在 App 里下单点开始配送。更新和结束阶段可以本地也可以远程。App 活着的时候本地更新没问题。App 被杀了就得靠远程 Push 更新。这段代码解决什么问题创建实况窗。文件liveview/LiveViewManager.ets用途创建实况窗接入位置用户下单后import{liveViewManager}fromkit.LiveViewKit;asynccreateDeliveryLiveView(orderId:string){constoptions{liveViewType:delivery,title:外卖配送中};constresultawaitliveViewManager.createLiveView(options);constliveViewIdresult.liveViewId;// 把 ID 存到服务端后面远程更新要用awaitthis.saveLiveViewIdToServer(orderId,liveViewId);}这里最关键的就是创建完的 LiveView ID一定要存到服务端。后面服务端要靠这个 ID 来更新对应的实况窗。三、LiveView ID 和订单 ID 为什么不能混用很多人搞混了LiveView ID 是系统生成的实况窗 ID订单 ID 是业务自己的订单 ID。这两个不是一回事。服务端要更新实况窗得用 LiveView ID不是订单 ID。你把订单 ID 传给服务端服务端不知道更新哪个实况窗。正确的做法是创建的时候把 LiveView ID 和订单 ID 绑定存到服务端。服务端更新的时候根据订单 ID 找到对应的 LiveView ID再用这个 ID 更新。四、远程更新的完整链路远程更新的完整链路是这样的服务端业务状态变化骑手取餐了服务端通过 Push Kit 发消息系统收到 Push更新实况窗用户看到进度变了。整个过程不需要 App 进程活着。系统直接帮你更新了。API 26 还支持实况窗通过 Push 下载网络图片。比如骑手位置、商品图片都可以直接推过去。五、结束阶段为什么要一致还有个容易踩的坑结束阶段不一致。情况问题服务端订单完成了实况窗还在显示配送中用户手动关了实况窗服务端还在继续推正确的做法是服务端订单完成了要远程停止实况窗。用户手动关了也要通知服务端不要再推了。不然就会出现订单都结束了实况窗还在转。六、几个容易踩的坑第一个坑LiveView ID 和订单 ID 混用。服务端找不到要更新的实况窗。第二个坑只存客户端状态。App 杀了状态就丢了。第三个坑App 被杀后仍依赖本地更新。轮询停了实况窗不动。第四个坑服务端已经结束但实况窗仍存在。订单都完成了进度条还在转。第五个坑更新频率超过限制。推太频繁系统限流。这次做实况窗最大的体会是实况窗不是 App 里的一个组件是系统级的东西。App 活着的时候本地更新App 死了就要靠服务端远程推。创建、更新、结束三个阶段的状态一定要一致不然就会出现各种对不上的情况。