即时加载程序设计应用

有一个玩家聊天的玩家气泡模块，这个模块可以通过一个特定接口构建起来。

最糟糕的情况就是把聊天数据包括玩家名字玩家头像和头衔存到数据库表中，然后数据一起返回通过接口构建起一个个气泡

可能这是最坏的情况了

程序设计人员，设计一种封装的思想去应用

在一个公共作用域内有一个json表存放的是所有玩家的头像名字头衔。

每个气泡收到的信息只需要说话内容，和玩家特有不重复id，和一个是否查看标记足够了

然后气泡自己的逻辑进行对其余的信息头像 名字头衔加载

这个逻辑应该设计为怎么样的呢

气泡先从公开表中查询是否有这个人的信息，如果有那么就加载本地，没有就进行发送封包获取，获取存表里面

这时候就分出两种设计理念

第一种是发送封包后用循环定时器去过一段时间轮询一下，查到信息返回给公开表了然后读取数据删除轮询。

第二种是发送封包后再加一个公开表，这个公开表存放没有进行初始化等待中的气泡，每次服务端返回数据就进行一次查询未初始化表，如果返回值相等那么就剔除，不相等就继续等待初始化。

两种后续逻辑去对比第一种虽然简单但是不够优美所以采用第二种。

这就是即时加载的应用逻辑思路了