[[198246]]

一、前言

在公司的項目中，或多或少都會使用到一些開源的項目。但是在開源項目的選擇上，就需要格外的慎重了。

如果只是個人處于學習或者練手的目的，使用的一些比較新穎的開源項目，這個完全隨自己，想怎么使用就怎么使用。但是如果是在公司的商業項目上，就需要格外慎重了，因為商業項目***個重點要求，就是一定要能保證穩定。

本篇文章，就如何選擇在商業項目中使用的開源庫，做一個介紹。

二、正確的使用開源項目

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專欄作者“張旸”的原創稿件，轉載請通過微信公眾號聯系作者獲取授權】

戳這里，看該作者更多好文