iOS之优雅解决开源库存在的问题

在开发过程中，最爽的就是使用第三方开源库了。但如果碰到系统升级，开源库还未适配新的系统或者存在某些异常Bug，那怎么办呢？就直接放弃不使用吗？这要是在预研阶段那还好，可找找其它替代品。但如果已经使用一段时间，代码中已经对库产生依赖，这时在极度紧张的开发时间里，再去找替代品，将原来的代码全部改掉，那不仅对开发人员是件痛苦的事，给测试同学也带来了巨大的工作量，甚至可能导致新功能上线的延期。

因此，如果不是不可解决的致命问题，为了让现有项目正常进行，并且不给团队带来额外的麻烦，那么，在开源库作者更新版本前，开发哥先解决掉开源库存在的问题是较优的选择，是有道德的做法。

那么，怎样修改第三方开源库呢？首先，原则上我们不应该直接修改开源库源码，因为会给库的后期维护带来不可知的麻烦；再则，稍微有点追求的开发哥基本上都使用Cocoapods来管理第三方库了，直接修改源码也是不允许的。

所以，如果不直接修改源码，我们有优雅的方式吗？有，这还得感谢OC的动态特性。当我们找到开源库Bug的根源，就可以hook根源所在方法把问题解决掉。同时，在hook替换原方法实现的过程中，可能会用到开源库中私有方法，怎么办呢？哈哈，有类别这个好东西。我们对该类声明一个类别，将私有函数暴露出来就可以使用（通过编译）了。

只要利用好上述两点，就可以在不修改开源库源码的原则下，优雅地解决了其存在的问题了。

正好，因前几个月发现了网易开源的一个导航栏库：KMNavigationBarTransition，测试它的Demo中，发现它利用OC的动态特性有显著的优点，优于我之前的方案ConfigurableNaviController，于是想在近期版本使用起来，但碰上新系统iOS11发布，验证中发现它未适配iOS11，导航栏动画有严重缺陷。

由于不想就此放弃，也受它机智利用OC动态性的启发，想到了上述方法，以其人之道还治其人之身，解决了其未适配iOS11的问题。如果想一窥其中详情，或者之前使用了KMNavigationBarTransition，也需解决iOS11的适配问题，可参考KMNavigationBarTransitionPatch。