Google自從2014推出Android Studio之後就宣佈在來年結束對Eclipse Android開發工具的支持，所以這裏直說使用Android Studio對於Android項目的構建。
對於Android 開發者來說 Gradle 是一個強大的工具，它提供便捷的方式幫助開發者構建APP，下面是維基上對Gradle的解釋
Gradle是一個基於Apache Ant和Apache Maven概念的項目自動化建構工具。它使用一種基於Groovy的特定領域語言來聲明項目設置，而不是傳統的XML。當前其支持的語言限於Java、Groovy和Scala，計劃未來將支持更多的語言。
通俗的理解：
- Gradle是一種構建工具,它可以幫你管理項目中的差異,依賴,編譯,打包,部署......,你可以定義滿足自己需要的構建邏輯,寫入到build.gradle中供日後複用.
- Gradle不是一種編程語言,它不能幫你實現軟件中的任何實際功能
Android APP 從編譯，打包流程又是怎樣的呢？流程如下圖：
概述如下：
1.使用AAPT（Android資源打包工具）打包工程的資源文件(res文件夾下的文件)，通過AAPT打包成R.java類(資源索引表)，以及.arsc資源文件。
2.如果有aidl，通過aidl工具，打包成java接口類
3.R.java和aidl.java通過java編譯成想要的.class文件。
4.源碼class文件和第三方jar或者library通過dx工具打包成dex文件。dx工具的主要作用是將java字節碼轉換成Dalvik字節碼，在此過程中會壓縮常量池，消除一些冗餘信息等。
5.apkbuilder工具會將所有沒有編譯的資源，.arsc資源，.dex文件打包到一個完成apk文件中中。
6.簽名，5中完成apk通過配置的簽名文件(debug和release都有)，jarsigner工具會對齊簽名。得到一個簽名後的apk,signed.apk
7.zipAlign工具對6中的signed.apk進行對齊處理，所謂對齊，主要過程是將APK包中所有的資源文件距離文件起始偏移爲4字節整數倍，這樣通過內存映射訪問apk文件時的速度會更快。對齊的作用主要是爲了減少運行時內存的使用。
Android 打包相關細節很多這裏我想着重說一下我認爲與開發相關較多的幾個知識點：
代碼混淆
1.ProGuard是什麼
ProGuard是ADT r8開始被默認集成到了Android SDK中用於壓縮，優化，混淆代碼的工具。主要作用是可以移除代碼中無用的類，字段，方法和屬性。同時混淆代碼增加反編譯的難度。
2.ProGuard技術的功能
- 壓縮 移除無效的類、屬性、方法等
- 優化 優化編譯後的字節碼，移除無用的指令
- 混淆 使用無意義的字母替換類名、屬性名、方法名
- 預檢測 在Java平臺上將編譯後的代碼再次做檢測
3.ProGuard的工作原理
這裏主要說一下EntryPoint。EntryPoint可以理解爲一種標誌，它是在ProGuard過程中不會被處理的類或者方法，在壓縮的過程,ProGuard會從上述的EntryPoint中開始遍歷搜索出哪些類和類的成員在使用（被標記爲EntryPoint的類和方法有些是在使用的而且這些是我們在混淆文件中配置不希望被混淆的類和方法，有些是沒有使用的）。對於那些沒有被使用的類和成員，就會在壓縮階段被丟棄。然後在接下來的優化步驟中，那些非EntryPoint的類，方法都會被設置爲private，static或者final，而且不使用的參數都會被移除。接着在混淆的步驟中，ProGuard會對非EntryPoint的類和方法進行重命名。最後就會對代碼進行預檢測，以便保證穩定性。
ProGuard可以減小APP體積，優化性能以及提高安全性和穩定性的工具，它不是必須的但是是官方極度推薦使用的。
Jenkins
Jenkins是一個開源軟件項目，是基於Java開發的一種持續集成工具，用於監控持續重複的工作，旨在提供一個開放易用的軟件平臺，使軟件的持續集成變成可能。Jenkins的功能包括：
1、持續、自動地構建/測試軟件項目。
2、監控軟件開放流程，快速問題定位及處理，提示開放效率。
使用Jenkins可以實現Android打包的自動化，大大減少開發人員隨時打包的煩惱，它的好處不僅僅是這些，誰用誰知道，哈哈。
Git
Git是 Linus Torvalds 開發的一個開放源碼的版本控制軟件, 是一個快速的分佈式版本控制系統，擁有強大的分支管理。
有一定開發經驗的人相信對Git都不會太陌生，這裏主要說一下Git的四種的工作流：
1.fork/clone
它有一個公開的中央倉庫，其他貢獻者可以Fork（克隆）這個倉庫作爲你自己的私有倉庫，開源項目維護者可以直接往中央倉庫push代碼，而代碼貢獻者只能將代碼push到自己的私有倉庫，只有項目維護者接受代碼貢獻者往中央倉庫發起的pull request纔會真正合入。
這種模式比較適合大型項目的開發，保證項目代碼的質量以及穩定，易於維護。
2.clone
這種工作方式跟svn類似，它只有一個master分支，開發者會先把遠程的倉庫克隆到本地，之後的修改和提交都在本地操作，直到在某個合適的時間點將本地的代碼合入到遠程master。這種工作流比較適合小團隊，因爲小團隊可能不會太多的協作和合流的動作。
在開發者提交自己的修改到master前，需要先fetch在master的新增提交，rebase自己的提交於master的最新版本。
這樣做的意思是在說，『我要把自己的修改加到別人已經完成的修改之上』。如果本地修改和上游提交有衝突，Git會暫停rebase過程，給你手動解決衝突的機會。
3.feature
這種工作流關注功能開發，不直接往master提交代碼保證它是穩定並且乾淨的，而是從master拉取feature分支進行功能開發，團隊成員根據分工拉取不同的功能分支來進行不同的功能開發，這樣就可以完全隔離開每個人的工作。當功能開發完成後，會向master分支發起Pull Request，只有審覈通過的代碼才真正允許合入master，這樣就加強了團隊成員之間的代碼交流，也就是我們常說的Code Review。
4.Gitflow
Gitflow是很多團隊會採用的工作流，它會相對複雜一點，但它非常適合用來管理大型項目的發佈和維護。master和develop分支在整個開發週期是一直存在的，master分支可以被視爲穩定的分支，而develop分支是相對穩定的分支，特性開發會在feature分支上進行，發佈會在release分支上進行，而bug修復則會在hotfix分支上進行。
我們團隊目前對Gitflow的一些實踐：
- master：主分支，不允許直接往這個分支提交代碼，只允許release分支往這個分支發起merge request進行合流，發佈完成後合併release分支並打tag
- release：發佈分支，發佈完成後發起merge request向master進行合流
- test：測試分支，用於迴歸測試，bug修復，結束之後向release發起merge request進行合流
- develop：開發分支，用於日常開發，包括代碼優化、功能性開發，結束之後合併到test
- feature：特性分支，從develop分支拉取，用於下個迭代版本的功能特性開發，功能開發完畢合併到develop分支
大家可能會發現我們這個跟標準的Gitflow工作流有些差別，其實也沒有什麼標準不標準的，前面說到要結合團隊的實際情況，我們團隊對於目前所採用的工作方式都是達成共識的，所以有一些差異並沒有關係。關於git工作流，只有選用最合適自己團隊的工作流纔能有效的提高開發效率，上面提到的一些工作流模式都有各自的適用場景，如何選用適合自己團隊的工作流得結合團隊成員的實際情況，看團隊成員對於工作流的理解程度，還有對於工作流的執行程度。
以上就是對於項目構建一些自己想要記錄的。
參考文檔：
https://www.jianshu.com/p/2a7474ee3527
https://blog.csdn.net/binbinqq86/article/details/81033707