移动应用离线支持可以理解为应用在网络连接不稳定时能够优雅响应的能力。在移动设备相对较新的技术背景下，出现了新的问题，例如网络连接正常或异常、高延迟和低带宽。这些问题出现的时间并不长，刚接触移动开发的工程师对它们了解不多。此外，创建一个可以适应不同网络条件的移动应用程序还可能包括以下要求：在网络调用失败的情况下显示适当的错误消息。允许应用程序在“访客模式”下使用，其中某些功能仅在用户登录时可用。在UI上清楚地显示断开连接的消息（连接模式/离线模式）。在网络连接丢失的情况下禁用某些控件。它还允许用户在没有网络连接的情况下查询和操作数据（离线数据访问）。在不同的网络连接条件下测试应用程序！从可用性的角度来看，以上所有几点都非常重要，但有一点特别复杂，即“离线数据访问”。应用可能需要支持多种不同的离线数据访问场景或级别，下面我会一一说明。本地缓存的应用程序可以在没有网络连接的情况下显示信息，但在连接到网络时需要刷新数据。实现这一点需要数据在移动设备上有一定程度的持久性，通常需要一段时间。缓存中数据的刷新有3种不同的“策略”，接下来我会一一分析。Network-first总是尝试从服务器获取数据，如果从服务器获取不到数据，则转而从本地缓存获取数据。如果您特别希望始终显示最新、更新的信息，则此策略会非常有用。本地优先级在指定时间内根本不会从网络上获取数据，而是通过本地缓存获取。如果您的应用程序可以毫无风险地接受显示缓存数据，那么这种方法适合您。另一方面，这种方式的用户体验更好，因为通常没有延迟。混合/智能这种方法在从服务器获取数据之前从本地缓存返回结果。您可以选择等待服务器通知，也可以在后台轮询服务刷新本地缓存数据。这种机制可以在性能和用户体验之间取得很好的平衡，并且仍然定期刷新本地缓存，避免了向用户显示“过时”数据的风险。另外，通过某种服务端缓存的支持，可以有效弥补本地缓存的不足。就像HTTP缓存一样，当需要从服务器获取数据时，客户端可以通过发送一个“修订号”来确认数据是否已经更新。服务器会检查客户端发送的修订号是否与服务器上的数据一致，并根据结果通知客户端不需要更新数据，或者返回最新的数据。样例场景性能和用户体验的提升使得本地缓存在很多场景下都有用，而这个用处的关键条件是数据不需要实时展示。将数据保存在本地缓存中的时间越长，这种方法就越有益。例如用户感兴趣的地区或联系人等，这类信息非常有用，但更新频率不高，因此是使用本地缓存的理想应用场景。本地队列一旦应用程序失去了网络连接，服务器请求可以被放入本地队列以备后处理。这种方法允许用户启动即发即弃操作，并等待它们被服务器成功处理（如果它们已被处理）以通知操作已完成。在本地队列上处理多个操作时，需要考虑以下问题：应该通知用户操作已排队。用户很可能想知道队列的实际状态，哪些操作已经完成，哪些操作还在等待？对于仍在队列中的操作，手动撤消或重试的能力可能非常重要。一旦这些操作被发送到服务器，用户就想知道最终的处理结果（成功或失败）。操作进入队列后，用户可能需要重新启动整个流程，因此需要中断操作。当消费者进行审计或调查等现场工作以及发送报告时，本地队列是个好主意。如果这些操作不需要更新记录，只需要插入新记录，那么整个实现就会简单很多，不需要并发管理，也不需要冲突处理。示例场景本地队列帮助您执行操作而无需等待结果，这对于库存检查或审计等操作非常重要，允许用户无需等待网络连接或发送报告即可使用应用程序。数据同步通过使用本地缓存和队列，您可以保持设备和服务器数据的更新，这就是所谓的“同步”。有几种方法可以实现数据同步。保持移动数据更新在这种情况下，您需要使您的移动应用程序数据保持同步。有两种方法可以实现这一要求：如上所述使用本地缓存，或者从服务器请求最新的更改。这些最后的更改，也称为“增量”，允许移动应用程序重建服务器的当前状态。为了能够查询最新更新，您需要使用一些审计字段，例如“UpdatedOn”、“CreatedOn”和“DeletedOn”。第二种场景，数据在设备上没有被修改，所以不需要处理任何冲突，所以服务器上的数据总是正确的。保持服务器数据更新可以通过使用本地队列来实现，但仅靠队列是不够的。如果当我的请求发送到服务器时，服务器上的数据状态与我尝试修改时相比发生了变化怎么办？如果请求的执行被延迟，比如网络连接断开时，可能会导致并发冲突增加。在这种情况下，开发人员（或用户）必须决定如何“合并”服务器和应用程序之间的更改。对于每一次数据冲突，合并的方式有以下几种：设备端保留版本服务端保留版本同时保留两个版本的合并记录的操作，往往是移动开发者通过自动化实现的。至于使用哪种算法，是由应用的业务规则决定的。一旦出现无法完全自动化的情况，就会提示用户做出决定。这种保持移动端和服务器端数据同时更新的方式也称为双向同步。您可能已经猜到，该策略是上述两种技术的结合，是目前描述的场景中最完整、规模最大的一个。但是请注意，虽然创建支持双向同步的应用程序很诱人，但它是迄今为止最复杂的场景。问题不仅在于它的复杂性，正如我在本文中已经提到的，并不总是需要双向同步。示例场景双向同步为移动应用程序带来全新级别的用户体验，使用双向同步的关键要求之一是让团队或组中的所有用户了解其他人的最新活动。这方面的一个示例是需要显示更新、评论或状态更改的最新状态的协作应用程序。可以想象，如果有一个协作通讯录，每个团队成员都可以随时更新里面的联系方式。考虑为您创建的移动应用程序添加对离线场景的支持可以大大改善用户体验，但是如何选择合适的支持级别然后实现此功能并不是一件容易的事。我在下面列出了一些您在计划向您的应用程序中添加离线功能时应该考虑的问题。数据大小在本地缓存数据时，请注意存储数据的大小。尝试在缓存的数据量和由此产生的用户体验改进之间取得良好的平衡非常重要。如果数据量非常大（比如保存一个完整的Sharepoint网站内容），你可能要考虑提供一个选项让用户选择缓存哪些数据以供离线阅读。数据存储必须对数据的存储方式和存储位置做出明智的选择。此数据是否包含敏感信息？如果是这样，则在保存数据时需要对其进行加密。一旦选择加密数据，请务必将用于解密的密钥存储在安全的地方，考虑使用操作系统的功能来执行此操作。另请注意，在某些平台上，您的应用程序代码可以被读取（或反映），因此请考虑混淆您的代码。***，但不是微不足道的，确保你有一些机制来远程擦除设备上的数据。移动设备管理(MDM)平台等工具可以帮助您做到这一点，但也可以通过应用程序本身来完成。电池使用如果您计划使用轮询机制或后台作业（作业），请务必仔细考虑电池使用情况。某些操作和网络功能会快速耗尽您的电池并损害您的用户体验。在开始耗电操作之前，您可以检查电池状态、设备是否正在充电等。数据应用程序您可能需要查询和操作数据（添加、修改、删除），这取决于您的应用程序的需要。在有一定复杂度的场景下，使用数据库作为持久化机制是一个不错的选择。要选择合适的数据库，需要考虑以下一些问题：平台支持：我的应用程序的每个版本都可以使用这个数据库吗？？(iOS,Android,Web,hybridapplications,etc...)选择关系型数据库或NoSQL数据库技术通过ORM的支持，对象模型可以方便的映射到数据库中的数据大小支持同步协议（如CouchDB)下面我们将一些类库和数据库一一分析，这对于我们实现离线功能非常实用。使用类库和数据库SQLiteSQLite是一个开源的关系型数据库，非常适合在移动设备上使用。它使用单个文件来保存数据，因此持久化管理非常简单。它对同步和冲突解决没有多大作用，但它是一个用于缓存和排队信息的易于使用的选项。它支持主要的移动平台，如iOS、Android、Xamarin和WindowsPhone。SQLCypher上面说到，如果你缓存或者排队的数据非常敏感，你需要在保存数据的同时进行加密。SQLCypher是加密SQLite数据库的一个非常强大的选项。支持所有主流移动平台，但该类库需要付费。它有多个版本，具体取决于安全级别和支持的功能。CouchbaseMobileCouchbase，原名Membase，是一个开源的分布式NoSQL数据库。特别适用于离线应用场景，因为它可以通过CouchbaseMobile和一个额外的同步网关进行数据的双向同步。支持Xamarin、PhoneGap等主流移动平台，提供本地文件加密。MeteorMeteor是一个开源平台，用于创建具有内置实时更新功能的Web应用程序。Meteor基于开源的Node.js平台和MongoDB创建。它提供了一种发布-订阅机制，可以在每个连接中将数据变化实时传递给客户端。它通过PhoneGap和Cordova等混合工具支持所有移动平台。结论一旦用户开始期望从他们的个人应用程序获得与企业应用程序相同水平的用户体验，就不能忽视离线支持。能够为用户提供良好的线下场景支持，将大大提升移动应用的用户体验，对员工的工作效率也至关重要。在设备本地存储数据时请注意安全问题，并尽量不要低估您的应用程序可能对用户电池消耗产生的影响。
