SPD之解CQ总结

近段时间一转过来就解Email的CQ，刚好新平台出现很多Exchange的问题，其中比较严重的有三个：1、Exchange导入联系人到了3000左右发生OOM错误；2、Exchange导入联系人不能同步到服务器，只能同步几个人；3、Exchange帐户创建日程，发出邀请，受邀方没有返回邮件告知邀请方。

第一个问题经过代码流程的跟踪定位，打Log，追踪到了是谷歌的Email源码中在同步联系人的过程中，是将所有有变化的联系人(包括添加，修改，删除等变化)一次获得，并将它们保存到一个ByteArrayOutputStream字节数组中，所以当联系人比较多而且带图像内容时，数据量就会很大，达11M左右，所以造成了OOM，尝试使用文件流的方案代替字节流的方式，但是在修改后Exchange服务现在连同步服务器上的内容都不成功了，从之前打的Log中可以猜测谷歌中的Exchange服务上传和下载走的是同一个流程，只是使用的命令不一样而已，这个地方没有做到隔离导致了下载更新失效，同步也失效，这种修改方案是不可行的。

第二个问题流程跟第一个问题差不多，走到最后的流程发现数据格式和返回格式是对的，但是在一次偶然的时候没有将500联系人导入成功，只有370左右，这时候能够同步到服务器成功，因此猜测是服务器对这个同步过程中的网络要求比较高，跟客户沟通他们也有这个情况，所以这算是谷歌Exchange中的一个缺陷。

第三个主要是定位代码的时间比较长，这里面用到了Service和ContentProvider的概念，逐步分析Uri，跟踪定位ContentProvider，最后再根据Service中使用到的方法名一共有几个Service重写了，最后定位到了他返回邮件的时候有调用了Exchange中的方法，但是在同步到服务器的时候，服务器返回了501Http代码，拒绝，但是跟客户在沟通的时候他说Mxx能够返回邮件，跟我用的是一样的Exchange帐号，属于无解了。

总结：调用ContentProvider的时候总是有相应的Uri对应的，要打Log进行分析，查找，在启用服务时，有时候服务比较多的时候，通过看相应的调用到的方法，在相应的服务里会有同名的方法，这个是一个比较快捷的方法定位到相应的服务。最后，使用Cmd命令进行打Log真的会丢失一些，所以稳妥的方法还是用Eclipse或者是用Cmd命令输出Txt文件到磁盘中。