整个app的时机就是基于事件驱动来设计的。

举例：当app更新时，这时，服务端向客户端推一个更新事件过来（推，不一定指的是推送，可以是websocket，也可以是心跳去检测）。
然后客户端收到这个事件后，就可以去处理更新了。处理更新的方式可以为：先询问后端是否有更新——> 更新

如下图为APP应用列表的设计。可以先简单理解为九宫格的一个应用列表

其功能包含：

1. 动态添加应用
2. 删除应用
3. 更新应用

难点如何只在有变更的时候，才去请求服务端，获得最近的变更数据，否则都加载本地缓存中的数据。

因此我们选择了事件驱动的方式，服务端判断有更新了之后，下发到客户端一个事件。收到事件的客户端才会去请求服务端，查看最近的变更数据。并保存到本地缓存中。

如下图为应用列表的流程图。

工作台 (1).png

• 检查是否有更新事件：基于事件驱动，直接检查本地缓存中是否存在“检查应用列表更新”的事件。
• 请求服务器检查工作台中有变更的应用列表：接收到事件后，请求服务器检查应用列表是否有变更，将返回已变更应用的详细信息。
• app客户端加载应用列表的时候，是从本地缓存中加载的。所以在有应用有变更的情况下，应该更新本地的缓存。