吐槽：iOS要获得联系人所属分组好麻烦-创新互联

最近接触iOS的AddressBook.framework教多，觉得关于联系人这块的API，如果只是读取或者简单的创建，他提供的api还是能满足需要的。但是，如果你需要做一个类似通讯录同步的，那么他的API用起来就稍稍麻烦一点。

   在iOS6以及更低的版本，无法根据一个联系人的ABRecordRef获得他所属于的分组ABGroupRef，Mac上有提供该API，但iOS上目前暂时没有。所以，如果要获取一个联系人的分组，你必须遍历整个通讯录才能得到该联系人所属的分组列表。故，如果你有对于分组处理的大量需求，建立一个某种程度上的分组缓存基本上是免不了的了。如果你还需要去增删改分组，我想，使用起来麻烦是少不了的。

   其次，在新增联系人的时候，如果你想设置他的分组，调用相应API的时候，请注意查看API说明文档，其中有不少要求你操作之前必须先进行相应的保存操作。举个例子：

   我有一个联系人，分组为A，而A在设备上原来不存在。那么我们的理所当然的逻辑就是：

   创建联系人，创建分组A，然后将联系人添加到分组A中，最后保存通讯录的修改。

   实际上，当你在将联系人添加到分组A中之前，你需要先保存通讯录的修改，将联系人刷到数据库之后，你才能成功添加分组！类似的API有很多，你只有查看文档才能知道哪些API调用之前需要保存一下数据库。而我相信，在一般情况下，一个iOS程序员只会去查看头文件里头的注释，而不是API文档；而ABGroup的头文件里头完全没有提到这些事情。只有在我纳闷为啥一直添加分组不成功的时候，走投无路抱着一丝希望去看文档的时候才发现这件事情。

   本来程序员查看文档也是完全正常的事情，问题在于其他的API在头文件中均有对API做出一定程度的说明，而这些明明有坑的API却完全不说明，我只好吐槽了。

   最后友情提示，使用ABAddressBook的API时，请详细翻阅文档，而不是仅查看头文件。因为ABAddressBook.h头文件中的友好的说明和注释，会让你在跳到其他几个头文件的坑的时候死得更惨。

另外有需要云服务器可以了解下创新互联scvps.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。