Gradle多渠道打包實例

版權聲明：

本公衆號發佈的全部文章，均屬於原創，版權歸本公衆號全部。

容許有條件轉載，轉載請附帶底部二維碼。

1、前言

在實際的工做中，當接手的App項目逐漸作大的時候，總有一些緣由須要根據需求對項目作一些定製化的維護，例如：三方合做定製、海外版本之類的。可是一般這種方式定製，其大致的框架都是同樣的，只是根據不一樣的需求點，作部分定製，

本文就這種定製的需求，利用Gradle作一個解決方案。

2、上古時代的作法

曾經，通用的作法是爲不一樣的專版需求，切出一個git branch出來，而後在這個分支上根據需求，對功能進行定製。每次打包的時候，從這個分支切換代碼進行打包、測試、發版。

可是這樣存在一個根本上的問題，若是這種專版需求比較多的時候，對於開發而言，一個小小的改動，將它們手工同步到全部的專版分支上，將是一個噩夢。尤爲是互聯網公司，可能需求每天在變，就會從一個技術活變成一個體力活，而且人工修改，次數多了，不免會有錯漏的時候，爲了保證質量，同時也加劇了測試的難度。

因此，這種方式如今已是不可取的了。那麼，有什麼新的方式嗎？

3、分清需求，再選方案

全部的技術選型，都要依據實際的業務。當框架的複雜度越高，維護起來就越吃力，因此最好的方案就是在現有的需求之上實現，而且保有可擴展的功能，使之在以後的迭代中，也一樣能夠勝任。其實就是選個平衡。

那麼，若是對於專版需求而言，只是修改一些文案，各個頁面的圖片等等，這樣的小改動，徹底能夠經過定製不一樣的productFlavors，而後根據名稱，去新建對應名稱的文件夾，而後替換主項目內，同名的資源文件便可。

實際操做起來，網上已經有大量的例子，而且也不是本文的主題，這裏再也不細說。有興趣的能夠自行查閱文檔。

那麼這種方案的缺陷是什麼呢？

它只能簡單的適應，在不一樣的專版之間，只是替換一下各項資源。若是有更復雜的定製功能，它是無法知足的，例如：不一樣的版本依賴不一樣的SDK。趕上這樣的狀況，會將全部專版須要的jar包、so等打在一塊兒，這樣無形中增大的apk安裝包的體積。

4、不一樣專版，不一樣SDK如何解決？

若是趕上不一樣專版，須要接入不一樣的SDK去實現，這樣的狀況下，一樣能夠經過Gradle來處理這樣的狀況。

簡單的思路：

在主項目以外，經過新建Module（Android Library）的方式，把不一樣專版間須要改動的地方抽取出來。而後將它們與主項目鏈接的地方抽象出來，作成接口去作交互。

也就是說，除了主項目Module以外，其餘的每一個專版做爲一個Module存在在項目中，這樣能夠分別維護本身的定製邏輯，而且全部資源分開來配置，引用的包也是分開的，同事不會增長Apk安裝包的體積。

5、舉個例子

首先，須要把現有的項目拆分，那些功能是能夠容許專版定製的，那些功能是共有的部分。

舉個例子，一個視頻播放的App，須要用戶登陸，進入以後，能夠購買視頻進行播放，那麼這樣一個App，簡單的進行功能上的拆分，能夠拆出以下的流程。

![Uploading gradle_module_444571.png . . .]
](http://upload-images.jianshu....

從上圖能夠看出，除了視頻播放這個功能是通用的，其餘的邏輯都是須要在不一樣的專版之間作定製，可能購買就須要使用不一樣合做方的SDK等等。

把功能拆分出來以後，就能夠開始着手幹了，下面以一個簡單的例子說明一下。

新建一個項目，而且在項目內再新建多個Module。記在，這裏須要選擇Android Library。這種類型的Module，能夠編譯成arr的包，就能夠攜帶佈局文件和so等資源。

用Android Library的方式，新建兩個Module，分別表示國內版本（inland）和海外版本（overseas）。

構建好以後，在不一樣的Module下，分別設定一樣一個Activity，完成以後，項目結構以下。

已經到這一步基本上完成了編碼的工做，後面就須要配置主Module的build.gradle文件了。

主要須要配置的地方，已經紅線標註出來了。

須要制定productFlavors，設定兩個版本須要配置的基本信息。而後在dependencies中爲不一樣的版本，作不一樣的引用，格式就是xxxCompile便可。

由於是個demo，在MainActivity只有一個簡單的按鈕，點擊跳轉到LoginActivity。而這裏用dependencies制定了不一樣版本跳轉的LoginActivity頁面。到這裏就能夠直接使用了。

在AS的Build Variant窗口，選擇須要運行的版本。就能夠在手機上運行不一樣的版本進行調試。

這裏只是簡單的提供思路，具體Gradle每一個字段表示什麼意思。這個仍是須要查看一下文檔，每一個版本的格式可能略有不一樣。

技術以外

這裏的技術難點在於，如何將現有項目拆分，如何把拆分後的模塊，用接口的形式抽象出來。

那麼，在技術以外，還有什麼難點？

1. 須要和產品協調，共有邏輯儘可能不要對專版進行單獨定製。若是必要定製，只是簡單替換資源圖片。

2. 須要和設計協調，在出設圖的時候，對共有部分UI，不要有對專版的定製UI便可。

用多Module的方式重構了項目以後，核心的問題就是在於如何和多方協調不要在共有的部分進行定製，要麼都改，要麼就保持原樣。