iOS第三方开源库的吐槽和备忘
做iOS开发总会接触到一些第三方库，这里整理一下，做一些吐槽。
目前比较活跃的社区仍旧是Github，除此以外也有一些不错的库散落在Google Code、SourceForge等地方。由于Github社区太过主流，这里主要介绍一下Github里面流行的iOS库。
首先整理了一份 (大概600个repos)
除了逛一下每日/每月流行之外，也可以到 来看一下整个iOS Repos的排名。
下面是一些比较流行的第三方库：
HTTP
相比较之下, 是目前最优秀的一个了：轻量、易用、使用者多、开发者有在积极维护。在AFN出现之前，这个角色是由ASIHTTPRequest扮演的，只是到现在年久失修了。关于AFN和ASI的对比，这里有一篇不错的文章 。除此之外， 和 也有一定的使用者。
Socket
无疑是目前封装得最完善的Socket库了：支持异步TCP/UDP，支持GCD，Objective-C接口封装。。目前没有发现可以与之相比的同类产品。。
JSON
算是第三方中最优秀的一个了：性能很高，文件少。在JSONKit之前，SBJson非常非常流行，但是SBJson性能够差，只是由于历史原因仍然存在在某些工程里面。如果工程只需要支持iOS5以上的系统，那就可以放弃那些第三方Json库了，直接用系统提供的NSJSONSerialization，性能比第三方的好，又是官方API。。
XMPP
现在做个实时聊天，XMPP协议算是很成熟的方案了。 一个很不错的选择，可以直接和OpenFire服务器打交道。项目不大人手不多的话，可以看看这个。
基础工具类
算是一个不错的工具包，提供各种比如编码、加密、字符串处理等等东西，还提供了一些不错的自定义控件，并且文档非常齐全。
框架
过去有很多人再用 ，这个东西太大太重，文档又少，到头来连Facebook都停止维护了。作为替代品nimbus现在流行了开来，关键在于它文档齐全。国内有个MVC框架叫 ，号称是顶级框架并且功能超过 ，有兴趣的可以看一下。 把响应式编程这种上流的东西带了过来，值得试一试。。
数据存储
还是挺多人(比如我)喜欢直接跟SQLite打交道的，这方面 封装的很不错。如果用CoreData来做存储的，可以用一下 。
图像处理
无疑是这方面的集大成者了。用OpenGL ES2.0来实时处理图片和视频流，性能和功能都是顶尖的。
开发和调试工具
看上去是一个不错的调试工具，可以在电脑浏览器上远程调试iOS程序、查看试图层次、网络等等。 是个Log工具，号称是可以提供企业级Log，使用者也挺多。
为了了解一下目前第三方库的普及程度，下面列举一些知名App对第三方库的依赖。
网易新闻
Garageband
(json-framework)
iWork三套件
Pinterest
多看阅读
(Google)
淘宝
(json-framework)
微信
QQ
ASIHTTPRequest
FMDB
CocoaAsyncSocket
JSONKit
MBProgressHUD
OpenUDID
SBJson
SVPullToRefresh
百度地图
微博
人人
可以看到，这些大型的App的依赖都很混乱，所以稍微解释一下。这些大公司都有一个iOS团队来协同开发，团队成员的水平也参差不齐。有时由于历史原因，例如某个App的某个组件依赖了ASIHttpRequest，但之后的新人改用了AFNetworking，就造成上面这种比较混乱的库依赖关系。这就造成难以维护、代码冗余等问题了。所以，引入一个第三方库一定要慎重考虑，如果可能，尽量自己开发和实现相应的功能，第三方库尽量只作为参考。 小团队或者个人开发者可以不必过多考虑，开发速度优先。
最后吐槽一下cocoapods。
一个语言的流行总伴随着第三方库的丰富，相应的也会出现依赖库管理的工具。cocoapods之于ObjC,就像maven/gradle 之于java、gem之于ruby那样。 cocoapods基本上是创建在在github社区上的，开源并且社区活跃。除了用github上的中央仓库外，也可以自己搭建私服什么的随便乱搞。
但就我来说，不推荐使用cocoapods，吐槽如下：
1.像maven这样的工具，是为了管理庞大的第三方库依赖、控制版本、构建工程等等而产生的，很难想象一个依赖了上百个jar包的web项目不用包管理构建会变成什么样。。但是，iOS开发是客户端的开发啊，如果真有一个工程依赖了那么多第三方工具，这个App能保持稳定吗。。通常情况下一个iOS工程不会有那么多包依赖。
2.按常理来看，一个人的手头不可能有太多的工程同时进行，也不太可能一天之内创建N个App来发布。cocoapods能节省的重复工作量，还不如它带来麻烦多。。
3.修改和调试不便。如果某个第三方库需要少量修改才能实现需求，用cocoapods来处理会比较麻烦。
关于第三方库，同样也不推荐过多使用，吐槽如下：
1.消耗时间，一个开源库，拿过来需要仔细考察代码质量，确认是否足够可靠。如果出现问题，需要仔细审查开源库的内部实现。如果这些工作太消耗时间，还不如自己实现。
2.可维护性差。一旦遇到系统升级、API更换，第三方库不能确保不出问题。当出问题后也难以找到人来维护。如果跟进第三方库的改变，仍然容易出现新问题。
3.法律问题。。大公司需要仔细审查许可协议，小公司各种不怕那就没问题。。