断网之后,你的应用会发生什么(以及如何继续工作)

WiFi突然断了。你正在应用里填一张表单——已经填了一半,花了五分钟。接下来会发生什么?

如果你的应用只支持联网使用,故事是这样的:页面重新加载或刷新,你的数据全部消失,你只能重新来过。然后你关掉应用,再也不会打开它。

如果你的应用是离线优先设计,故事就完全不同了:你继续打字,数据是安全的。等WiFi恢复(三分钟后,或者三天后),一切自动同步。这就是”离线优先”设计的核心:应用在没有网络连接的情况下依然能工作,把你的更改保存在本地,一旦重新联网就立刻同步。

大多数应用搭建工具会跳过离线支持,因为这样开发更简单。但离线优先并不复杂——它只是需要用心设计。这也正是一个用户愿意反复打开的应用,和一个被卸载的应用之间的差别。

应用断网后到底会发生什么?

当应用断网时,它要么继续正常工作,要么彻底不能用——没有中间状态。而断网其实并不罕见:飞机上没有网络,隧道里没有信号,偏远地区的活动场地信号时断时续,家里的路由器凌晨三点重启导致WiFi失灵,用手机热点上网时流量用完了。

在所有这些情况下,你的应用要么能用,要么不能用。

我们曾经做过一个自由职业者时间追踪应用。它一断网就崩溃。有一位自由职业者(在没有信号的工地上使用这个应用)干脆不用了——他转而用铅笔和纸,因为至少铅笔在哪里都能用。三个月后,我们加上了离线模式,他又回来了,再也没离开过。

原理其实很简单:断网时把工作保存在本地,联网后再同步。仅此而已。

离线场景有哪些不同类型?

需要考虑的离线场景有三种:主动离线、意外离线和”龟速”离线——每一种都需要不同的应对方式。

主动离线——用户主动选择离线工作。他们正在飞机上,或者知道当地WiFi不好,提前就打算好之后再同步。这种最容易开发:只需把草稿保存在本地,联网后再推送出去。

意外离线——网络突然掉线,用户正做到一半。如果这时候被硬生生打断,他们会很恼火。技术上的解决方法一样(本地保存草稿),但体验上要更贴心:让用户知道应用依然能用,并在重新联网时告诉他们。

龟速离线——有网络,但慢到几乎等于没有。一位客户填完表单点了提交,结果等了20秒提交才完成。这段时间里,他们会以为出了故障,于是又点了一次提交(于是你就多了一条重复数据)。这是最难测试的一种情况,但解决方式很老实:要么明确显示正在处理中(一个加载动画),要么允许用户离开页面而不丢失草稿。

该如何向搭建工具提出离线模式的需求?

要分开一项一项地提,而不是当成一个大功能笼统地提——离线优先是一种设计理念,而不是一个单一的开关。以下是五个可以直接提给搭建工具的具体需求:

本地保存草稿:“当有人填写表单或写笔记时,把内容保存到他们的手机/浏览器里。如果他们刷新页面,表单内容应该还在。” 测试方法:填点内容,关掉浏览器标签页,重新打开,内容应该还在。
离线也能工作:“如果没有网络,应用应该显示已有的数据,让用户能读取和修改,并把这些更改排队,等网络恢复后自动同步。” 测试方法:关掉WiFi,尝试做点有意义的操作,然后重新打开WiFi,观察数据是否自动同步。
安静地同步:“同步更改时,不要弹出大对话框。用一个小提示,比如顶部显示”保存中…“,完成后自动消失。如果保存失败,把更改留在本地,稍后再重试。”
诚实展示数据状态:“告诉用户哪些数据是最新的(刚从服务器同步过来的),哪些只是本地数据(还没同步)。用一个小图标或标签来标注——不用做得吓人,老实说明就好。”
核心流程优先支持本地操作:“用户来这里主要想做的事情(查看预订、写笔记、记录时间)应该能离线完成。锦上添花的功能(搜索全部历史记录、拉取实时价格)可以要求联网。“

真实案例

婚礼策划师做了一个管理婚礼来宾回复(RSVP)的应用。她会打印名单,在活动现场走动时逐一勾选回复情况。但场地的WiFi很差。她提出了离线优先的需求:把清单保存在本地,回家后再同步。现在这已经是她的主力工具——即使手机有信号,应用也不用等数据加载就能用。她非常喜欢这个功能。

一位课堂老师用一款应用追踪学生的学习进度。她经常在信号不稳定的教室间来回走动时丢失编辑内容。有了离线模式,她可以随意操作,之后再同步,不用在手机和工作之间做取舍。就这一个改动,信任感直线上升。

一位保险理赔员在现场填写事故报告(有些偏远地区没有信号)。原来的应用要求联网才能提交。我们加上了离线草稿功能。现在他填完表,离线状态下也能提交,等开车回去的路上自动同步。再也不用”回到家才能提交”了。

这三个例子本来都可以用”换个更好的WiFi”来解决,但现实世界不是这样运作的。离线优先带来的信任感提升,远比同步速度的提升更重要。

离线优先会让应用更快吗?

会的——离线优先的应用体验起来更快,因为你不用等服务器响应。你打字,应用立刻在本地保存(瞬间完成),然后在后台同步。没有加载动画,没有等待。即使有网络,体验也会更流畅,因为服务器不再是瓶颈。

一个只支持联网的应用,每次更改都必须等服务器确认。敲一个键 → 发起网络请求 → 服务器校验 → 返回结果 → 显示给用户。这在正常情况下没问题,但在网络慢(或者服务器响应慢的移动端场景)下,每一次操作都会卡顿。

打造离线优先需要付出什么成本?

离线优先需要在前期多花一些开发时间。你的搭建工具需要考虑:

本地存储:如何把数据保存在手机/浏览器里,确保应用崩溃时数据不会丢失。这不难,但必须是有意为之的设计。
冲突处理:如果用户离线时修改了某个字段,而在同步之前,别人(或者另一台设备)也修改了同一个字段,该以哪个为准?通常以联网端的版本为准(更新),但要提醒用户,而不是让他们措手不及。举个真实例子:两台手机离线状态下编辑同一条笔记,两者都重新联网——后同步的一方胜出,先同步的用户会看到提示”你的版本已过时,这是最新版本”。
过期数据:如果用户离线了三天,应用应该在他们重新联网时默默刷新所有数据,还是先问一下?先问更稳妥——旧数据上可能挂着尚未同步的更改。

这些问题确实需要花心思考虑清楚,但实际做起来比想象中简单。

回报是:用户会真正信任这个应用。一个离线优先的应用不会找借口(“你需要联网才能使用”),也不会丢失你的工作成果。这一点非常重要。

如何测试应用是否支持离线使用?

不需要真的坐飞机去测试——手机的飞行模式就是最好的测试场。步骤如下:

打开应用并填点内容:做点日常操作(填表单、加笔记)。
切换到离线状态:打开飞行模式或关掉WiFi。
继续操作:再尝试做同样的事。如果应用拒绝响应,说明离线优先还没做到位;如果能正常操作,说明做得不错;如果体验让人困惑,可以要求搭建工具加一个清晰的”你已离线”提示。
重新联网:关闭飞行模式。
检查同步情况:你的更改是否自动同步了?如果需要手动点”同步”按钮或刷新页面才能看到更新,说明还没完全做好。

最好的离线应用,会让你几乎感觉不到自己在离线状态——你只会注意到:应用照样能用。

你搭建的应用真的需要支持离线使用吗? 如果答案是”我的用户网络不稳定,或者他们所在的地方经常没有信号”,那么答案是肯定的。如果答案是”他们一直都有稳定的WiFi”,那你暂时可以不用考虑这个功能。但一旦有人说”我的工作成果丢了”,你就会希望自己当初早点提出这个需求。