一、前言
在公司的项目中，或多或少都会使用到一些开源的项目。但是在开源项目的选择上，就需要格外的慎重了。
如果只是个人处于学习或者练手的目的，使用的一些比较新颖的开源项目，这个完全随自己，想怎么使用就怎么使用。但是如果是在公司的商业项目上，就需要格外慎重了，因为商业项目***个重点要求，就是一定要能保证稳定。
本篇文章，就如何选择在商业项目中使用的开源库，做一个介绍。
二、正确的使用开源项目
2.1 使用成熟稳定的开源项目
既然商业项目，主要是以稳定为主，那么在选择开源项目上，就需要以成熟稳定为前提条件。
对于一些常用的技术，就那么多种类，网络请求、ORM、图片加载等。找一些明星项目，总是不会错的，这个相信大家都懂。
那么，正常来说，如何选择一个相对稳定的开源项目呢?
1、Github 上的热度
一个开源项目，在 Github 上的 Start 数和 Fork 数，就可以从侧面反应出它的热度。
2、issues 和***更新时间
一个开源项目的 issues ，可以表达很多正在使用它的人碰到的问题，以及作者的回复和有没有得到解决。当然，作者回复的速度和比例也是一个参考。
而***更新时间也反应出这个项目是否有人在积极维护。
3、正在使用它的商业项目
一个优秀的开源项目，注定不是你首先发现的。在你考虑是否将其集成到公司的商业项目的时候，一定也有其他人如此考虑了。所以有什么公司的项目，正在使用它，也是一个稳不稳定的标识。
4、使用稳定版本
Github 上的开源项目，也是在不停的维护和改进迭代的，所以如果需要使用，一定要使用它打了 Tag 标签的版本，这样才能***限度的保持稳定可用。
5、开源协议
并非所有的开源项目都是可以随便使用的。在使用前一定要阅读开源许可协议，看它是否能允许你随便使用在商业项目中。
不过 Github 上的开源项目，大多数限制并不严格。除了 GPL 协议需要额外注意，它规定使用它的项目也必须遵循 GPL 协议，也就是也必须开源，这肯定不适用商业项目。
2.2 了解背后的原理
如果决定使用这个开源项目，一定要理解其原理，这个其实在实际开发开发中，你修改一段别人维护的代码，也需要结合上下文，理解它代码的原理和逻辑，才能保证修改它不会引发其他的问题。
使用开源项目也正是如此，仅仅会用它是不够的，决定是否将它引入的人，一定要对它的原理有足够的了解，不能仅仅停留在 API 的使用上。
在使用前，扒开源码看本质，不是说一定要事无巨细的了解它所有的细节，但是主体的业务线，原理是什么，使用中需要注意什么，在什么场景下可能会出现问题。这些都是需要了解清楚的，避免出现问题而措手不及。
2.3 不要改动源码
大多数情况下，开源项目不可能永远满足我们的需求，有时候我们可能需要对开源项目进行一些定制修改。
那么，***是对其进行扩展而不是直接去修改它的源码。
对于一些真正的明星开源项目，实际上已经设计封装的很好了，如果想要扩展，也非常的简单。例如，OkHttp，如果你在请求响应的时候想做一些额外的操作，只需要增加一个拦截器即可。
而不改动源码的原因也非常的简单，开源项目一般都是会持续维护和更新的，在不修改源码的情况下，之后再进行升级就非常的简单，这里也推荐直接使用 Gradle 远程依赖的方式去集成(一定要明确指定版本号)，这样大多数情况下，升级基本上就是改一个版本号的事情。可也不排除会有接口上的变动，但是一般这样的变动，也会提供升级指南之类的帮助文档。
2.4 视情况决定引入方式
有时候需要的一些小的开源项目，并非功能强大的明星项目，可能只是一个 UI 效果。
一些开源项目，为了功能上的大而全，可能会集成一些我们不需要的额外功能。而假如我们需要的只是这个开源项目中，很小的一部分，其实是可以考虑将其相关代码类拷贝出来，单独维护的。
这个的前提是此开源项目的耦合性太高了，导致内部太多的类相互引用，这样的情况下，我们只需要将我们关注的代码拷贝出来，进行简单的修改解耦，即可直接使用。这样的方式可以适当减少方法数和 dex 的大小。
而如果开源项目本身耦合并不严重，实际上依然推荐使用 Gradle 远程依赖的方式引入，在最终打包的时候，只需要开启 shrinkResources 即可，它会将一些项目内没有用到的资源移除掉，从而不用担心方法数和安装包大小的问题。
2.5 使用前需要进行封装
优秀的开源项目，其实已经封装的非常好了，可能最终到使用者这边，只需要一行代码即可搞定。
但是哪怕是再好的封装，我依然建议在使用前对其进行一层封装，哪怕是最简单的封装也可以。
对开源库进行封装后使用，一个根本性的好处就是，接口统一。哪怕有一天，随着业务的增长或者技术的迭代，之前的开源库已经没有办法满足现在的需求了，需要对整个项目的该库进行替换。这个时候如果有一层封装，那么替换起来只需要修改业务的接口实现类即可，而不是需要整个项目进行代码替换。
有些人可能会想了，我接手这个项目的时候，前人已经是在直接使用这个开源项目了，现在我需要替换它，不是依然需要全文进行代码替换吗?
这样的问题其实非常的常见，那么如果遇上这样的问题，实际上我们既然已经要移除它了，完全可以在项目内建立与它包名类名都相同的同名类文件，然后根据它对外的接口，去实现它。这样我们只需要处理两个库之间，接口使用的差异即可，其实也可以达到快速替换的效果。
但是，也有人说了，这样是不是就可以不封装了?反正最终替换的时候，处理两个库接口的差异即可。其实并不是这样的，提前封装是为了更优雅更从容的替换，有时候不同库的使用方式，去处理它们的差异会让我们的代码非常的混乱和不可读。就像在修改之前，自己给自己制定了一系列的规则去束缚自己一样，所以提前封装，把规则掌控在自己手里。
所以，如果可以，封装一层再进行使用。
2.6 实时关注更新
开源项目必然是会保持更新的，在使用过程中，如果碰到问题，可以去看看最近的提交以及 issues，看看有没人碰到与你相同的问题，或者可能你的问题已经在***版得到解决。
三、结语
在商业项目中，使用那个开源项目大多数情况下都是项目 Leader 去决定的，但是这并不影响我们了解自己维护的项目中，使用到的开源项目，不仅更有利于我们在工作中更快速的发现问题。阅读优秀的开源项目，是提高技术能力非常快的一个手段。
【本文为51CTO专栏作者“张旸”的原创稿件，转载请通过微信公众号联系作者获取授权】
