同步状态和消息推送，几乎是每个app或者设备都需要的，设计一个省流量，能简化两端逻辑，能应对业务增长的框架尤为重要。
我认为，以下方法不够好：
1.每一个状态都设计一个消息，导致每增加一个状态，服务端都需要改动。
2.每次上线后都请求一次所有类型的最新的消息。
3.最新的消息只推送一次就完事。
第一个缺点已经说了，解决的方法是设计一个通用的消息结构和存储模型，集存储、转发、推送于一身。
第二个方法，一个是消息太多，不可能每个都有更新，所以没必要每次都请求。而发送的请求带来没必要带宽的浪费和处理的压力，尤其在移动互联网情况下，掉线太多，浪费的带宽和cpu也是成倍增加。
解决方法，类似日志式的方法，设备的每次变化都对应一个日志，让设备依次重放每个日志，如果状态具有唯一性，那么可以删除这个状态旧的日志，保留新的日志。
第三个问题，在完成日志式的改造后，让每个日志对应一个数字，日志越新，数字越大，设备或者app只需要请求更新的日志即可。推送不再丢失消息，也不会重复消息。
另外，考虑到日志太多，可能会导致同步缓慢，所以应该将日志分类，将一些紧急的状态变化分为一类，将一些不是很重要的消息，又分为一类，这时候存在两份不同的日志序列，按需请求即可。