针对google的同步策略，我们以日历为例子，做了一个同步流程的完整调查。调查手段包括阅读文档、实际使用和抓包分析。google日历的文档地址如下，接口参数可到这里查询：https://developers.google.com/google-apps/calendar/overview?hl=zh-TW调查结果与我们的区别及改进建议：
1、完整的同步流程。 google：首先是获取账户信息、acl访问控制信息，接下来是上行按顺序发起修改、发起删除、发起添加，最后是下行，先获取设置，然后获取变更数据。 我们：我们的目前没有账户信息和acl访问控制，上行顺序是删除、修改和添加。下行我们是获取变更数据，少一个获取设置。除了额外的部分，数据交换流程和 google基本类似，删除和修改的顺序相反。 建议：目前顺序基本一致，暂不建议修改。
2、实时同步流程。 google：只有上行，没有下行。双向同步仅限于手动和系统发起的同步。 我们：有上行也有下行。 建议：实时同步去掉下行。因为绝大多数时候服务端并没有新的数据可以更新，下行都是无效请求。
3、更新的推送方式。 google：依赖与推送来告知客户端及时更新数据，基本是秒到。 我们：也依赖推送，但实时性有待提高。 建议：先依赖推送，逐步提高实时性。之前每次同步都双向能一定概率降低时效问题，但是无效请求太多对服务器和客户端的性能有太大的压力，也不能解决实时性 问题。如果客户端对实时性要求很高的，可以考虑增加刷新按钮作为补充。
4、上传数据的方式。 google：日历是逐条上传。 我们：目前是批量上传。 建议：这里我们优于google目前的方式，已经比较优化。
5、下载数据的方式。 google：日历是通过分页获取方式。 我们：在获取之前先通过一个propfind接口来拉取改变，然后再拉取相应的数据。 建议：去掉拉取改变的接口，直接采取分页拉取的方式。通过对比，下一步我们希望参考这个策略来做调整，已经比google优化或者差别不大的就不调整了，其他的也已经在着手。
