1、场景和需求：
在一个或多个商场有N个大屏幕，比如电梯口的导购屏 ，广场的互动屏，我们可以使用ivx来制作一个屏幕内部的内容，比如图文展示，交互游戏等等，但由于屏幕内容需要动态更新，因此，我们希望有一个统一的后台可以让用户自己去控制，而不需要每次手动去线下更新。
2、方案总览
为了要能够动态更新屏幕的内容，并且支持每个屏幕的内容可以灵活的定义，我们建议制作一个统一的“壳案例”，这个案例里使用一个网页组件（iframe）动态去加载其他内容案例。这个壳案例，每10分钟 - 30分钟，动态去后台查询内容案例是否有更新，如果有更新，则自动刷新网页组件，获取到最新的内容案例。
当我们在线下部署时，我们给每个可案例添加一个url参数，比如id。比如，我们的壳案例的地址是 www.ivx.cn/screenshow, 那我们在线下部署时，将每个屏幕进行人工的编号，比如，某个屏幕的编号是33， 那么我们就在这个屏幕的浏览器中加载 www.ivx.cn/screenshow?id=33, 这样就可以在刷新的时候，动态去加载id为33的这个内容案例了。
当然，我们也可以使用ip来鉴别每个线下设备，但由于大多数商场中的屏幕设备，都不可能有一个固定的ip，因此，我们使用url参数来定位每个设备的方法更加通用和保险。
3、基本数据结构
我们先来举一个最简单数据结构例子，如下图所示：
假设我们一共有N台设备，我们通过url参数的方法，给他们定义了ID为1 - N （这个id是我们自己定义的，可以根据自己的规则去设置），然后，我们制作一个后台管理案例，添加一个对应表格，即每个id对应的内容案例的url是什么。然后，在每个客户端部署壳案例，将id作为url参数。这个壳案例唯一的内容是一个全屏的网页组件，其url地址是动态从后台查询获取的。
每10分钟到30分钟，（这个频率建议不要超过10分钟，否则后台会有比较大的压力），壳案例自动根据自己的url参数中的id，去后台查询内容案例是否有更新，如果有更新，则重新根据最新的url刷新网页组件，如果没有更新，则不进行任何操作。
另一种适合更多屏幕的方案如下：
我们可以首先把商场的屏幕进行分类，然后给每一个类型的屏幕定义一个对应的url，由于在很多场景下，许多屏幕的内容是一致的，因此，为了方便管理，我们不需要一个一个屏幕去配置内容url，只需要做好分类，针对每个分类去统一更新内容即可。
4、客户自动更新逻辑
尽管我们可以使用socket主动向客户端推送更新消息，但由于每个客户端都是长期开机状态，且我们的客户端数量可能非常多，socket的连接在这种场景下并不能保证100%稳定。因此，自动更新的逻辑，我们还是建议从客户端主动去服务端查询拉取。在大多数情况下，我们并不需要每个客户端的更新非常实时，因此这个拉取的时间间隔建议不要小于10分钟，一般建议30分钟，这样对服务端的压力最小。
拉取更新的实现逻辑可以是这样：
1、每次用户在后台界面更新了某个id 或者某个类别的url地址之后，后台表格会自动记录这条数据的更新时间（数据库的默认字段）
2、客户端第一次请求服务端获取内容url时，服务端同时返回当前内容url的更新时间，客户端收到后，将更新时间存在cookie里；
3、客户端每隔一段时间去服务端查询当前id对应的url是否更新，查询时将cookie里存的上一次更新时间作为服务参数发过去；
4、服务端判断收到的某id或某类型的客户端请求中的更新时间与数据库中存的更新时间是否一致，如果一致，就返回不需要更新，客户端不做任何处理；
5、如果不一致，服务端就返回最新的url地址以及更新时间（注意，这个url地址可以和之前的一样，也可以不一样，但无论是否一致，都代表内容已更新），客户端收到后，使用最新的url去刷新iframe（即网页组件的url属性）即可。
6、当客户端刷新url内容时，顺便将最新返回的更新时间更新至cookie里，用于下一次的查询判断。
一个简单的demo：
