在对《谈谈我对SaaS的理解》一文中谈及到SaaS应用其中一个很明显的缺点，就是依赖互联网，互联网对比区域网有更多的不确定。 不再是局域网或本地的运作方式，获取数据就必须通过互联网，这也带来在一定场景下的麻烦事。可庆的是，在这个时代，网络几乎不成问题。 但在于我SaaS经验而言，还是存在有网络差的情况。
比如：在仓库中需要根据订单进行分拣，目前租户的仓库往往环境较差，网络设备不稳定，每次分拣都需和服务器进行数据交互。 所以在分拣设备中，我们需要实现离线分拣操作，在网络状态良好时再将原来的分拣任务进行同步，当然这里也带来很多技术和交互问题。
对于SaaS离线应用主要解决以下四大问题：
1、本地使用
2、本地存储
3、数据同步及冲突解决
4、数据传输
离线应用技术架构
因我们需要实现离线应用场景不是局限在Web，而多是在分拣端(Android) 。在不同技术体系下，有不同实现的框架，但实现之前我们也必须要理解离线应用技术架构对应解决方案是如何。 参考Google Gears 的架构组件我们定义了：本地离线引擎子系统 和 服务器同步数据子系统。
Gears，原称Google Gears，是一款Google开发的软体，让使用者可以离线浏览。这套软体透过以浏览器扩展的方式添加JavaScript API使得浏览器的脚本能够访问本地的SQLite缓存数据库。所以网页是透过暂存区取得的，而不是从实际的网路上取得。而且，Web相关的程式可以周期性的透过Gears将本地暂存的资料与网络上的资料做同步。如果网路暂时无法使用，这个同步过程将会延后，直到网路恢复为止。因此，Gears的Web相关应用并不是即时的。 由于HTML5能做到的同样的事情，Google已经放弃为Gears增加新功能。并且于2011年底前撤出Google产品线而不再发行。
本地离线引擎子系统，主要包括的模块为：
1、本地数据库。
2、本地数据服务，支持离线与在线数据访问更新的切换。
3、数据同步模块。
4、数据传输模块。
5、网络状态检查模块。
SaaS生鲜配送系统离线分拣解决方案
“离线分拣” 在技术层面是无法实现无网络分拣商品所有互动流程的。这里强调了互动流程，因为在于企业运作而言，每个环节都不能独立存在，一定需要和其他业务领域进行数据交互，分拣完成后第一时间要通知给订单领域及配送领域。
通过业务场景分析，定下“离线分拣”的业务目标，这个非常关键。 “离线分拣”业务目标是解决：仓库内因为物理环境等因素，无线网络会出现不稳定的情况，在此时应最大程度不影响分拣员的分拣工作。
1、本地数据使用
当分拣员获取分拣任务数据，除了在页面展示数据外，也会存储一份新数据覆盖到本地数据库中，当无网络时自动会从本地数据库中查询。以本地数据库为辅，远程数据库为主的策略进行展示。
2、分拣数据同步
分拣数据同步主要需要解决两个问题：
- 增量数据处理。
- 多用户冲突处理策略。
增量数据处理的处理方案比较简单，可选择版本号、时间戳、状态标识等方式。
多用户冲突处理策略主要实现方案是：
- 覆盖策略，后提交者覆盖前提交者。 在分拣中并不可行，不采用此方案。
- 丢弃策略。后提交者发现数据已经更改，则丢弃自己的数据。在分拣中并不可行，不采用此方案。
- 提醒方案。当发生冲突时，则将冲突数据提供给用户，由用户去决定。 在分拣中可行。
- 尽量不冲突。在分拣场景中，分拣员开始分拣前需要提前领取分拣任务，领取分拣任务时会将任务处理“锁定”状态，则最大概率不会发生数据冲突。
3、数据传输模块
通过多线程管理数据传输，触发数据传输场景主要有3种：
- 网络状态恢复时。
- 定时尝试增量数据传输。
- 用户手动点击增量数据传输。
这里的数据传输关键是否采用打包处理：
- 将所有数据全部打包或按规则打包传输。
- 模仿实际操作按照每条数据传输。
每种方案有不同优缺点，考虑到技术方案实现简单且能给用户带来最直接的感受，我们采用了“模仿实际操作按照每条数据传输”，当“服务器同步数据子系统”处理完毕后用户立刻能在页面上看到同步状态，也无需解决打包数据完整性的问题。
4、网络状态检查模块
在实际中此功能必须要增加，需要判断分拣设备网络环境的实际网络情况，往往出现问题了由分拣员判断网络情况都是不可靠的。
这里除了要判断分拣设备到我们服务器的网络环境外，还需要检测下分拣设备到其他外网服务的网络环境，如百度、阿里云等等，根据网络延时的情况进行分级。
除了分拣设备的离线场景，还存在Web端的“离线场景”，而这些更多是H5暂存功能，暂还没有达到分拣设备的复杂业务场景。
对于实现离线应用架构，一定需要结合业务场景去设计方案，毕竟SaaS下没有真正离线的应用，如果有那就不是SaaS应用。