开源项目，这样使用才稳

版权声明：

本公众号发布的所有文章，未特殊署名，均属于原创，版权归本公众号所有。

转载请参阅公众号的：《转载授权》。

一、前言

在公司的项目中，或多或少都会使用到一些开源的项目。但是在开源项目的选择上，就需要格外的慎重了。

如果只是个人处于学习或者练手的目的，使用的一些比较新颖的开源项目，这个完全随自己，想怎么使用就怎么使用。但是如果是在公司的商业项目上，就需要格外慎重了，因为商业项目第一个重点要求，就是一定要能保证稳定。

本篇文章，就如何选择在商业项目中使用的开源库，做一个介绍。

二、正确的使用开源项目

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 去决定的，但是这并不影响我们了解自己维护的项目中，使用到的开源项目，不仅更有利于我们在工作中更快速的发现问题。阅读优秀的开源项目，是提高技术能力非常快的一个手段。

推荐阅读：