Android 經常使用開源框架源碼解析 系列 （零）引言

 

1、引言

在使用開源庫以前首先要了解：

 謹慎使用 GPL 協議，GPL 協議規定使用了該開源庫的代碼也必須遵循 GPL 協議，即開源和免費。

 聲明開源協議。同時請你們遵照開源精神，遵照其餘人的勞動成果，若是有借鑑或是部分拷貝其餘開源庫，請在明顯地方聲明感謝！

 

——那什麼是協議呢？ 看一下從網上扒下來的一張示意圖： 

在CooCox 用戶及影響的逐漸增大，CooCox團隊提升了對軟件及代碼協議的重視性，造成了如下一些協議和許可證

    能夠看到各類協議，好比開源許可證GPL、BSD、MIT、Mozilla、Apache和LGPL

 

 

BSD 開源協議

    使用者享有「最大」的使用自由，能夠修改源代碼，能夠將修改後的代碼做爲開源或是專有軟件版權再發布

    以BSD協議代碼爲基礎作二次開發的狀況才享有該「最大」使用權限，但依然要知足三個條件：

•    若是再發布的產品中包含源代碼，則在源代碼中必須帶有原來代碼中的BSd協議
•      若是再發布的只是二進制類庫 /軟件 ，則須要在類庫/軟件的文檔和版權聲明中包含原來代碼中的BSD協議
•      不可使用開源代碼的做者/機構名字和原來產品的名字進行市場推廣

 

BSD代碼優勢：

•    鼓勵代碼開源共享
•      容許使用者修改和從新發布代碼
•    容許BSD代碼在商業軟件開發和發佈、銷售，是企業開源產品的首選協議

 

MIT許可證

    MIT許可協議與BSD 協議相似，做者只想保留版權，屋其餘任何限制。在使用該協議的狀況，發行版裏必須包含原許可協議的生命，不管針對的是二進制 類庫再發布仍是 源代碼的發佈

 

Apache Licence 2.0 開源協議

     著名的Apache 公司的Apache Licence 開源協議也是企業級協議的不可獲取的一類。使用者能夠在須要的時候修改代碼來知足需求並做爲開源 或是 商業產品 發佈/銷售。同BSD協議相似，一樣爲了鼓勵代碼共享和尊重原做者的著做權的狀況下容許代碼的修改再發布，同BSD同樣也須要知足三個條件：

•     須要給代碼的用戶一份Apache Licence
•       若是修改了代碼，須要再被修改的文件中說明
•       在延伸的代碼中（修改和有源代碼衍生的代碼中）須要帶有原來代碼中的協議、商標、專利生命和其餘原來做者規定須要包含的其餘說明
•       若是再發布的產品中包含一個Notice 文件，在該文件中須要帶有APache Licence 。能夠在Notice中增長本身的許可，但不能夠表現爲對Apache Licence構成更改

 

 

GPL 開源協議

    衆所周知的Linux 就是採用了GPL協議。不一樣於BSD協議和Apache Licence等鼓勵代碼重用的許可。GPL的出發點是代碼的開源 / 免費 使用 和 引用/修改/衍生代碼的 開源/無償使用，但不容許修改後和衍生的代碼作爲 逼源的商業軟件發佈和銷售。

    

    GPL協議的主要內容是：只要在一個軟件中使用（「使用」指類庫引用，修改後的代碼或者衍生代碼）GPL協議的產品，則該軟件產品必須也採用GPL協議，便是必須開源和免費。這就是GPL協議的 傳染性。

    

    GPL協議嚴格的要求使用了GPL類庫的軟件產品必須延用GPL協議，因此商業軟件或是對代碼有保密措施要求的部門就不適合 集成/採用作爲類庫 和二次開發的基礎

 

LGPL 許可證

    LGPL是GPL的一個爲主要類庫使用設計的開源協議。LGPL與GPL最大的不一樣就是LGPL容許商業軟件經過類庫引用方式使用LGPL類庫而不須要開源商業軟件的代碼。也就是說使用了LGPL協議的源代碼能夠進行商業通途的發佈和銷售

    須要注意的是修改了LGPL協議的代碼或是衍生，在全部修改的代碼、涉及修改部分的額外代碼及衍生都必須採用LGPL協議。所以LGPL協議的開源代碼很適合作爲第三方類庫被商業軟件引用，但不適合但願以LGPL協議代碼爲基礎，經過修改開衍生的方式作二次開發的商業軟件採用

 

Mozilla 許可證-MPL

    MPL 是The Mozilla Public License 的縮寫。在GPL許可證沒有很好的平衡開發者對源代碼的需求和利用源代碼得到的利益的前提下，MPL作了一些改變：

•      MPL雖然要求對於經MPL許可證發佈的源代碼的修改也要以MPL許可證的方式再許可，以保證其餘人能夠在MPL的條款下共享源代碼。可是，在MPL 許可證中對「發佈」的定義是「以源代碼方式發佈的文件」，這就意味着MPL容許一個企業在本身已有的源代碼庫上加一個接口，除了接口程序的源代碼以MPL 許可證的形式對外許可外，源代碼庫中的源代碼就能夠不用MPL許可證的方式強制對外許可。
•     對軟件專利的態度，MPL許可證不像GPL許可證那樣明確表示反對軟件專利，可是卻明確要求源代碼的提供者不能提供已經受專利保護的源代碼（除非他本人是專利權人，並書面向公衆免費許可這些源代碼），也不能在將這些源代碼以開放源代碼許可證形式許可後再去申請與這些源代碼有關的專利。
  
•     對源代碼的定義

        而在MPL（1.1版本）許可證中，對源代碼的定義是:「源代碼指的是對做品進行修改最優先擇取的形式，它包括:全部模塊的全部源程序，加上有關的接口的定義，加上控制可執行做品的安裝和編譯的‘本來’（原文爲‘Script’），或者不是與初始源代碼顯著不一樣的源代碼就是被源代碼貢獻者選擇的從公共領域能夠獲得的程序代碼。」

•  MPL許可證第3條有專門的一款是關於對源代碼修改進行描述的規定，就是要求全部再發布者都得有一個專門的文件就對源代碼程序修改的時間和修改的方式有描述。
  

 

2、學習開源框架的優勢：

• 系統分析框架源碼底層，祝你快速突破技術瓶頸
• 深刻解讀框架源碼，提高代碼閱讀與分析能力
• 學習更好的設計思路，提升代碼設計及改造能力

 

3、經常使用10大開源框架列表

 

（一）網絡框架：

•     OkHttp   
•     Retrofit

（二）依賴注入：

•     ButterKnife  
•     Dagger2

（三）異步處理：

•     RxJava  
•     EventBus

（四）圖片框架：

•     glide    
•     picasso

（五）性能優化：

•     LeakCanary   
•     BlockCanary

 

切入點：

•     使用原理
•     基本用法
•     使用流程
•     源碼機制
•     源碼核心類
•     區別差別