1,對熱修復和外掛化的理解

2，外掛化原理分析

3，模組化實現（好處，原因）

4，熱修復，外掛化

5，專案元件化的理解

答：

什麼是元件化開發？個人理解是一種高內聚低耦合的開發模式。在移動開發裡，它將一個大功能整體進行拆分，分別進行單獨除錯，最後再合併打包
我向大家極力推薦使用元件化。因為無論你使用的是何種語言，開發的是什麼專案，都有可能面對專案迭代中的各種高度耦合，而且隨著開發人員數量的增多或者人員的排程，這種問題會越來越嚴重。最後在開發過程中，你就不得不在各個模組間跳來跳去，再加上AS本身編譯速度那麼慢，豈是一個呵呵能夠代表此刻複雜的心情？元件化就可以比較好的處理了這個問題，你開發A，他開發B，我開發C，我們用的公共庫是同一個，各自獨立開發獨立測試，完事之後再合併，相互不受影響。
每次看別人的文章，都會對比下外掛化跟元件化的區別，沒錯，看上去確實兩者功能差不多，但是我覺得這個沒啥好比較的。拋開demo來說，不是每個人都能理解外掛化的技術原理，出了bug誰來改？反正我是不會改。。。元件化畢竟在原生控制範圍內，只要進行合理的設計即可，換句話說，難度不大。。。

如何進行元件化

這裡扯個淡，請原諒我不喜歡直接用老師這個詞。《師說》中：“師者，所以傳道授業解惑也”。一說到元件化全是馮森林老師，總覺得有點怪怪的，還是直接稱呼oasisfeng比較習慣
之前我們開發過程中，可能不自主的就往元件化這種模式靠近。我在開發一個專案的時候，用到了美恰這個意見反饋SDK，當時就將它抽成一個aar，然後主工程直接startActivity，完事，看起來很方便。但是aar是需要編譯的，這個又回到之前說的那個情況上去了，慢！慢！非常慢！oasisfeng就很牛逼的提供了一個思路：利用狀態位去分別做不同的事情。具體來說就是區分Debug模式和Release模式，在Debug模式下，各個Module作為Application單獨執行，而在Release模式下則作為Library，提供給主App進行依賴。這樣相互沒有影響，非常實用。對我來說，雖然還是需要編譯2次，但是已經不都是整體編譯了，時間也節省一些

在這裡，app就是主工程，modulea就是一個獨立的業務，moduleres就是公共庫

下面是重點，講流程了，也不復雜

1. 定義一個全域性gradle變數，在gradle.properties中定義

   # 是否處於除錯狀態
   isDebug=false

2. 回到我們的modulea的build.gradle中，你要是不放心可以列印下isDebug這個值

   println isDebug.toBoolean()

   隨後我們就通過這個值來處理它的型別，當處於debug的時候，它就是一個獨立的可執行的模組，反之就是一個普通的庫

   if (isDebug.toBoolean()) {
    apply plugin: 'com.android.application'
   }else {
    apply plugin: 'com.android.library'
   }
    
   

   還有就是debug跟release的處理我們需要注意下，作為一個庫跟作為一個獨立工程，他們可能需要載入不同的資原始檔或者類檔案。最直接的一個情況就是我們再debug的時候，可能需要DebugActivity去進行測試，你肯定不希望將這個DebugActivity達到正式版裡面去。這裡展示一下如何根據不同值去載入不同的資原始檔以及如何排除不需要參與打包的類檔案

   sourceSets {
    main {
       if (isDebug.toBoolean()) {
            manifest.srcFile 'src/main/debug/AndroidManifest.xml'
            res.srcDirs = ['src/main/debug/res']
        }
        else {
            manifest.srcFile 'src/main/release/AndroidManifest.xml'
            java {
                //排除java/debug資料夾下的所有檔案
                exclude 'debug/**'
            }
        }
    }
   }

   來看看最終modulea的結構
   
   modulea的結構
   這裡還有一個小技巧

   resourcePrefix "modulea_"

   通過這個設定可以將你的資源名稱進行檢查，如果不滿足字首為"modulea_"，則有紅色波浪線提示
   
   resourcePrefix
3. 回到主工程App的build.gradle中，同樣進行處理，當處於debug的時候，就不去載入modulea，反之則載入

   if (isDebug.toBoolean()) {
    compile project(':moduleres')
   }else {
    compile project(':modulea')
   }

   這裡說明下，modulea中包含moduleres，所以不需要載入這麼多遍

元件與元件之間如何互動

其實說白了也很簡單，我們一般通過隱式呼叫跟顯示呼叫來啟動一個Activity。但是在這裡，不管採用何種呼叫方式，肯定都要在主App中有個地方去維護這個對應關係。但是還有一個問題要考慮，如果引數過多putExtras也是很煩的，而且這個又要找地方儲存需要的變量了。。。。。。提供給大家一個思路，你還記得怎樣實現點選手機瀏覽器裡的連結直接啟動App嗎？是的，只要在data裡配置相應的scheme以及host，或者額外的path什麼的，就可以訪問到指定類了
這裡推薦大家使用ActivityRouter這個庫，在github上有它完整的使用Demo，足以依葫蘆畫瓢實現。簡單的介紹下，ActivityRouter提供了一箇中間件，通過中介軟體解決本地業務元件之間的通訊與元件間直接引用、依賴混亂的問題，它只負責掛接節點，不涉及掛接點具體業務的任何邏輯。

6，描述清點選Android Studio 的build按鈕後發生了什麼

答：

點選Build後（我理解是 Build > Make Module module-name），還能發生什麼，無非是安裝在模擬器或者真機上一個App唄~.沒錯，但是，這個問題的本意一定沒這麼簡單。

gradle外掛

要構建和執行應用，請點選 Run 。Android Studio 使用 Gradle 構建您的應用，會要求您選擇部署目標（模擬器或連線的裝置），然後將您的應用部署至目標。 
我們建立一個Android Application，至少要包含一個application module，並且在build.gradle中設定application 的gradle 外掛：

apply plugin: 'com.android.application'

• 1

這樣，編譯這種module時將才成.apk檔案。 
一個application module不可以依賴另一個application module，只可以依賴library，就是配置 gradle library 外掛的module：

apply plugin: 'com.android.library'

• 1

釋出這樣的module時，得到的將是一個.aar檔案，與.jar檔案相比，aar檔案可以包含一些android相關的東西：比如資原始檔和manifest檔案。

編譯

編譯一個application module或者library檔案，大致可以分為gradle task代表的五個階段： 
1. Preparation of dependecies 在這個階段gradle檢測module依賴的所有library是否ready。如果這個module依賴於另一個module，則另一個module也要被編譯。 
2. Merging resources and processing Manifest 在這個階段之後，資源和Manifest檔案被打包。 
3. Compiling 在這個階段處理編譯器的註解，原始碼被編譯成位元組碼。 
4. Postprocessing 所有帶 “transform”字首的task都是這個階段進行處理的。 

5. Packaging and publishing 這個階段library生成.aar檔案，application生成.apk檔案。

構建過程

 
使用Android Asset Packaging Tool(aapt) ，將AndroidManifest.xml和res下的資源編譯生成R.java檔案，這樣java檔案就可以去引用資源了 - 使用aidl 工具去生成對應的Java interfaces - 將src和通過aapt生成的R.java，.aidl檔案通過javaC命令去生成.class 檔案 - 使用dex tool 將class檔案轉化成Dalvik byte code.這時候要將所有class檔案和第三方的jar包都包括。 - 所有沒有編譯過得圖片和編譯過的圖片,.dex檔案傳給apkbuilder去打包成.apk - 最後採用zipalign tool 打入簽名