2. 程式人生 > >Android元件化專案詳細實施方案

Android元件化專案詳細實施方案

阿新 • • 發佈：2019-02-16

1、Android元件化專案

在Android專案元件化之前，我們的專案都是像下圖那樣，一個單一工程下，根據不同的業務分幾個資料夾，把需要的第三方庫依賴下就開始開發了，這樣的程式碼耦合嚴重，牽一髮而動全身，刪除某處程式碼就會到處報錯，如果不解決掉報錯的地方，就沒法編譯打包，而且這樣的程式碼只適合於個人開發，尤其團隊開發合併程式碼的時候那真是一個麻煩，相信大家都會深有體會，如果專案很大的話，修改一點簡單的頁面都要重新編譯，Android編譯速度大家也都見識過，每次打包都很耗時，並且這樣的程式碼想做單元測試也是無從下手。

這裡寫圖片描述

所以Android專案元件化就迫在眉睫了，元件化的方向就是由一個專案工程拆分成若干個模組工程，由App主工程提供統一的入口，每個業務獨立的模組共享專案的Common依賴庫。

這裡寫圖片描述

2、Android元件化專案實施步驟

1）第一步：配置可自動將元件在Application和Library屬性之間切換的方法

我們都知道Android Studio中的Module主要有兩種屬性，分別為 ：

  • application屬性，可以獨立執行的Android程式，也就是我們的APP；

    apply plugin: ‘com.android.application’

  • library屬性，不可以獨立執行，一般是Android程式依賴的庫檔案；

    apply plugin: ‘com.android.library’

當我們在開發單獨元件的時候，這個元件應該處於application模式，而當我們要將單獨元件合併到主工程的時候，就需要將單獨組從application模式改為library模式，也許你可以每次切換的時候都去build.gradle檔案中去修改，但是你的專案要是有十幾個元件的時候，你確定一個個去改？所以我們必須有一種能夠動態切換元件模式的方法，做到一次修改，全域性元件生效，這個問題就需要通過配置Gradle來解決了。

在Android Studio專案的根目錄下有一個gradle.properties 檔案，這個檔案主要用來配置Gradle settings的，例如JVM引數等，想要了解這個檔案的更多作用請檢視http://www.gradle.org/docs/current/userguide/build_environment.html
，我們今天需要關注的是這個檔案的一個特點：我們在gradle.properties 中配置的欄位都可以在build.gradle檔案中直接讀取出來，不用任何多餘的程式碼。

現在我們在gradle.properties添加了一行程式碼，定義一個屬性isModule（是否是元件開發模式，true為是，false為否）：

# 每次更改“isModule”的值後，需要點選 "Sync Project" 按鈕
isModule=true

然後我們在元件的build.gradle檔案中讀出這行程式碼：

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

因為gradle.properties中的資料型別都是String型別，而這裡我們需要的是boolean值，所以這裡要將String轉換為boolean值，如果是‘元件開發模式”就將這個元件應用為application模式，如果不是就將這個元件應用為library模式，也就是一個庫。
這樣我們的第一個問題就解決了，首先我們在gradle.properties中定義一個屬性isModule，然後在每個元件的build.gradle中把這個屬性讀取出來，每當我們需要從元件開發模式和APP整體開發模式轉換時，只需要修改“isModule”的值即可，當然註釋中也說了修改為這個屬性值後，要點選AndroidStudio上的 “Sync Project”按鈕同步下整個專案才能生效。

2）第二步：解決元件AndroidManifest和主工程AndroidManifest合併的問題

每個元件是由不同的成員單獨開發的，這個時候元件就是一個獨立的APP，那麼這個元件就會有自己的“AndroidManifest.xml”，但是Android程式只有一個“AndroidManifest.xml”，當我們要把元件作為Library合併到主工程的時候，元件的“AndroidManifest.xml”和主工程的“AndroidManifest.xml”就會產生衝突，因為他們都有自己實現application類以及一些屬性，還有自己的MAIN Activity，如果直接把張表合併到一起勢必產生衝突。

解決思路就是：每個元件維護兩張表，一張用於元件單獨開發時使用，另一張用於合併到主工程的登錄檔中，每當增加一個Android系統的四大元件時都要同時給兩張表中新增。

我們在上一節講了可自動在元件的Application和Library屬性之間切換的方法，有了這種方法，維護兩張表就很方便了，首先在元件的main資料夾（和java資料夾平級）下建立兩個資料夾，如下圖：

這裡寫圖片描述

然後在每個元件的*build.gradle中新增如下的程式碼：

sourceSets {
    main {
        if (isModule.toBoolean()) {
            manifest.srcFile 'src/main/debug/AndroidManifest.xml'
        } else {
            manifest.srcFile 'src/main/release/AndroidManifest.xml'
            //release模式下排除debug資料夾中的所有Java檔案
            java {
                exclude 'debug/**'
            }
        }
    }
}

這些程式碼的意思是：當在元件開發模式下，元件的登錄檔檔案使用debug資料夾下的，其他情況使用release資料夾下的登錄檔檔案；那麼這兩張表的區別在哪裡呢？

下面的表示debug資料夾中的：

<application
    android:name="debug.CarApplication"
    android:icon="@mipmap/ic_car_launcher"
    android:label="@string/car_name"
    android:supportsRtl="true"
    android:theme="@style/AppTheme">
    <activity
        android:name=".query.QueryActivity"
        android:configChanges="orientation|screenSize|keyboard"
        android:screenOrientation="portrait"
        android:windowSoftInputMode="adjustPan|stateHidden">
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />

            <category android:name="android.intent.category.LAUNCHER" />
        </intent-filter>
    </activity>
    <activity
        android:name=".scan.ScanActivity"
        android:screenOrientation="portrait" />
</application>

下面的表是release資料夾中的：

 <application android:theme="@style/AppTheme">

    <activity
        android:name=".query.QueryActivity"
        android:configChanges="orientation|screenSize|keyboard"
        android:screenOrientation="portrait"
        android:theme="@style/AppTheme"
        android:windowSoftInputMode="adjustPan|stateHidden" />
    <activity
        android:name=".scan.ScanActivity"
        android:screenOrientation="portrait" />

</application>
  1. debug資料夾中登錄檔的標籤中指定了具體application類，而release資料夾中的則沒有，
  2. debug資料夾中登錄檔的標籤中新增一些application屬性，而release資料夾中的則什麼都沒有新增；
  3. debug資料夾中的登錄檔指定QueryActivity為MAIN Activity，也就是要啟動的 Activity，而release資料夾中的則沒有；

3）第三步：解決元件和主工程的Application衝突問題以及元件單獨開發初始化（共享）資料問題

當android程式啟動時，android系統會為每個程式建立一個Application類的物件，並且只建立一個，application物件的生命週期是整個程式中最長的，它的生命週期就等於這個程式的生命週期。在預設情況下應用系統會自動生成Application 物件，但是如果我們自定義了Application，那就需要告知系統，例項化的時候，是例項化我們自定義的，而非預設的。但是我們在元件化開發的時候每一個元件可能都會有一個自己的Application類的物件，如果我們在自己的元件中開發時需要獲取全域性的Context，一般都會直接獲取application物件，但是當所有元件要打包合併在一起的時候就會出現問題，因為最後程式只有一個Application，我們元件中自己定義的Application肯定沒法使用，總不能每次打包的時候都把全域性的application改一遍吧？

解決思路：首先建立一個叫做Common的Library，這個Common庫中主要包含整個專案用到公共基類、工具類、自定義View等，例如BaseActivity、BaseFragment、BaseApplication等，並且我們的每一個元件都要依賴這個Common庫，現在主要講Common庫中的BaseApplication怎麼定義，下面是BaseApplication中的部分程式碼：

    public class BaseApplication extends Application {

        private static BaseApplication sInstance;

        public static Context context;

        public static BaseApplication getIns() {
            return sInstance;
        }

        @Override
        public void onCreate() {
            super.onCreate();
            sInstance = this;
            context = this.getApplicationContext();
            if (isAppDebug(context)) {
                //只有debug模式才會列印日誌
                Logger.init("Demo").logLevel(LogLevel.FULL);
            } else {
                Logger.init("Demo").logLevel(LogLevel.NONE);
            }
        }
    }

因為每個元件都依賴了Common庫，所以每個元件都能夠獲取到BaseApplication.context，但是Android程式預設的是系統自己的Application這個類，要想使用自己的就要繼承Application並且在AndroidManifest.xml中宣告，因此我們先在自己的元件中建立一個元件Application並且繼承於BaseApplication，然後在debug檔案中的AndroidManifest.xml中宣告：

public class CarApplication extends BaseApplication {
    @Override
    public void onCreate() {
        super.onCreate();
        login();
    }
}

這樣我們就可以在元件中使用全域性的Context：BaseApplication.context了，但是還有一個問題，我們在自己的元件中定義了CarApplication，那麼元件合併到主工程後，主工程也有自己的Application，這樣又衝突了，其實這個問題第二節的程式碼就已經寫出來了，我們只是在元件開發時才使用CarApplication，那麼我們在合併到主工程的時候把這個程式碼排除掉不就行了嘛，直接上圖：

這裡寫圖片描述

我們在java資料夾下再建一個debug資料夾，把元件自己的application放在這個資料夾中，然後在build.gradle新增這行程式碼：

這裡寫圖片描述

這樣在合併到主專案時debug資料夾下的java檔案就全部被排除了。並且你可以在元件的Application中做一些初始化的操作，比如登陸，然後把資料儲存下來，供元件使用。

4）第四步：解決library重複依賴以及Sdk和依賴的第三方庫版本號控制問題

重複依賴問題其實在開發中經常會遇到，比如你 compile 了一個A，然後在這個庫裡面又 compile 了一個B，然後你的工程中又 compile 了一個同樣的B，就依賴了兩次。
預設情況下，如果是 aar 依賴，gradle 會自動幫我們找出新版本的庫而拋棄舊版本的重複依賴。但是如果你使用的是 project 依賴，gradle 並不會去去重，最後打包就會出現程式碼中有重複的類了。

Library重複依賴的解決辦法就是給整個工程提供統一的依賴第三方庫的入口，在上一節講解決Application衝突問題時我們建了一個Common庫，這個庫還有一個作用就是用來為整個專案提供統一的依賴第三方庫的入口，我們把專案常用或者必須用到的庫全部在Common庫的build.gradle中依賴進來，例如Android support Library、網路庫、圖片載入庫等，又因為每個元件都要依賴這個Common庫，所以的build.gradle中就不在需要依賴任何其他庫了，這樣我們就有了統一的依賴第三方庫的入口，新增、刪除和升級庫檔案都只需要在Common庫中去處理就好了。

下面是元件build.gradle的依賴配置：

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile project(':common')
}

當元件合併到主專案的時候，其實就是將元件打包成arr包，所以主工程中在元件開發模式下是還是要單獨依賴Common庫，等到合併的時候在去依賴其他元件，Common庫就不用依賴了，下面是主工程build.gradle的依賴配置：

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])

    if (!isModule.toBoolean()) {
        compile project(':alert')
        compile project(':car')
    } else {
        compile project(':common')
    }
}

另外一個問題就是我們每個元件的build.gradle中都要配置一些屬性，例如compileSdkVersion、buildToolsVersion還有defaultConfig等，如果我們需要修改專案的compileSdkVersion版本號，那就麻煩了，那麼多組的build.gradle，每個都要去找到修改一遍，想想都頭疼，所以我們要把這些build.gradle中都要配置的屬性統一起來，類似於java中的靜態常量，一處修改到處生效。首先我們在專案（不是元件的）的build.gradle中定義如下程式碼：

// Define versions in a single place
ext {
// Sdk and tools
buildToolsVersion = localBuildToolsVersion
compileSdkVersion = 23
minSdkVersion = 16
targetSdkVersion = 23
//時間：2017.2.13；每次修改版本號都要新增修改時間
versionCode = 1
versionName = "1.0"
javaVersion = JavaVersion.VERSION_1_8

// App dependencies version
supportLibraryVersion = "23.2.1"
retrofitVersion = "2.1.0"
glideVersion = "3.7.0"
loggerVersion = "1.15"
eventbusVersion = "3.0.0"
gsonVersion = "2.8.0"
}

然後在元件的build.gradle中引用這些值，下面貼出的是Common庫的build.gradle程式碼會和元件的build.gradle有些許差異：

apply plugin: 'com.android.library'

android {
    compileSdkVersion rootProject.ext.compileSdkVersion
    buildToolsVersion rootProject.ext.buildToolsVersion

defaultConfig {
    minSdkVersion rootProject.ext.minSdkVersion
    targetSdkVersion rootProject.ext.targetSdkVersion
    versionCode rootProject.ext.versionCode
    versionName rootProject.ext.versionName
}

buildTypes {
    release {
        minifyEnabled false
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    //Android Support
    compile "com.android.support:appcompat-v7:$rootProject.supportLibraryVersion"
    compile "com.android.support:design:$rootProject.supportLibraryVersion"
    compile "com.android.support:percent:$rootProject.supportLibraryVersion"
    //網路請求相關
    compile "com.squareup.retrofit2:retrofit:$rootProject.retrofitVersion"
    compile "com.squareup.retrofit2:retrofit-mock:$rootProject.retrofitVersion"
    compile "com.github.franmontiel:PersistentCookieJar:$rootProject.cookieVersion"
    //穩定的
    compile "com.github.bumptech.glide:glide:$rootProject.glideVersion"
    compile "com.orhanobut:logger:$rootProject.loggerVersion"
    compile "org.greenrobot:eventbus:$rootProject.eventbusVersion"
    compile "com.google.code.gson:gson:$rootProject.gsonVersion"
    //不穩定的
    compile "com.github.mzule.activityrouter:activityrouter:$rootProject.routerVersion"
    compile "com.jude:easyrecyclerview:$rootProject.easyRecyclerVersion"
}

這樣我們修改compileSdkVersion、buildToolsVersion、defaultConfig的值或者依賴庫檔案的版本號都可以直接在專案的build.gradle檔案中直接修改了，修改完後整個專案也就都改過來了。

5）第五步：跨Module跳轉問題，也是我們最重要的一步了

在元件化開發的時候，我們不能在使用顯示呼叫來跳轉頁面了，因為我們元件化的目的之一就是解決模組間的強依賴問題，元件跟元件之間完全沒有任何依賴，假如現在我從A元件跳轉到B元件，並且要攜帶引數跳轉，這時候怎麼辦呢？而且元件這麼多怎麼管理也是個問題，這時候就需要引入“路由”的概念了。

我在專案中使用了一個開源的“路由”庫，github地址請點選：ActivityRouter，主頁裡會有詳細的介紹，大家可以去了解一下。另外阿里巴巴也開源了一個元件路由，github地址請點選：ARouter；這兩個都是現成拿來就能用的，當然有人可能比較好奇元件Router是什麼原理，自己怎麼開發，這裡有一位作者寫出了詳細的教程，大家可以去學習下：Android路由實現。

接下來我們就講怎麼將路由應用到我們的元件化專案中，首先我們要在專案（不是元件的）的build.gradle中依賴下面的程式碼：

buildscript {
  dependencies {
        classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'
  }
}

為什麼要使用android-apt呢？大家可以看下面的解釋，或者自己去搜索：

這裡寫圖片描述

然後在每個元件的build.gradle中加入下面的程式碼：

apply plugin: 'com.neenbedankt.android-apt'

dependencies {
    compile 'com.github.mzule.activityrouter:activityrouter:1.2.2'
    apt 'com.github.mzule.activityrouter:compiler:1.1.7'
}

接下來是在主工程的AndroidManifest.xml配置

<activity
android:name="com.github.mzule.activityrouter.router.RouterActivity"
    android:theme="@android:style/Theme.NoDisplay">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="demo" /><!--改成自己的scheme-->
    </intent-filter>
</activity>

接下來我們需要在每個元件的java目錄下，宣告這個元件，向下面的程式碼那樣（聲明瞭兩個元件）：

@Module("App")
public class AppModule {
}

@Module("Car")
public class Car { 
}

然後在主工程的Application 中宣告需要新增到主工程中的所有元件：

@Modules({"App", "Car"})
public class DemoApplication extends BaseApplication {

    @Override
    public void onCreate() {
        super.onCreate();
    }
}

到這裡我們的元件和主工程之間的關係就建立起來了，元件的宣告以及新增和刪除就都已經解決了。接下來就是元件之間Activity的跳轉嗎，前面我們做了那麼多都是在為Activity的跳轉做準備。

首先我們在需要跳轉的目標Activity上添加註解：

@Router("main")
public class MainActivity extends Activity {
    ...
}

這樣就可以通過 demo://main來開啟MainActivity了。

這一步就算講完了，至於Router更多進階功能就要靠大家自己去：ActivityRouter 學習了。

6）Module之間的通訊問題

如果在B元件中要通知A元件重新整理列表，就要想辦法解決元件間的通訊問題，這個只要使用EventBus就能解決，並不是什麼複雜問題。

7）資源名衝突問題

因為我們拆分出了很多元件，在合併到主工程的時候就有可能會出現資源名衝突問題，比如A元件和B元件都定義了同一個資源名。這個問題一般很很好解決，我們只需要在元件的build.gradle中新增這樣的程式碼：

resourcePrefix "元件名_"

但是設定了這個屬性後有個問題，所有的資源名必須以指定的字串做字首，否則會報錯，而且resourcePrefix這個值只能限定xml裡面的資源，並不能限定圖片資源，所有圖片資源仍然需要手動去修改資源名。所以我並不推薦使用這種方法來解決資源名衝突，我們專案中解決辦法是增加資源命名規約，只要遵守這個命名規約就能規避資源名衝突問題。

3、Android元件化專案結語

到這裡一個簡單的元件化專案就搭建出來了，元件化相比於單一工程優勢是顯而易見的：
1. 加快編譯速度，提高開發效率
2. 自由選擇開發框架（MVC /MVP / MVVM /）
3. 方便做單元測試
4. 程式碼架構更加清晰，降低專案的維護難度
5. 適合於團隊開發

最後貼出Android元件化Demo地址：請用滑鼠猛擊這裡

相關推薦

Android元件化專案詳細實施方案

1、Android元件化專案 在Android專案元件化之前，我們的專案都是像下圖那樣，一個單一工程下，根據不同的業務分幾個資料夾，把需要的第三方庫依賴下就開始開發了，這樣的程式碼耦合嚴重，牽一髮而動全身，刪除某處程式碼就會到處報錯，如果不解決掉報錯的地方，就沒法編譯打包，而且這樣的程式碼只適合於個人開發，

Android元件化方案實踐與思考

Demo地址：https://github.com/751496032/ComponentDemo 效果圖： 背景 Android從誕生到現在，不知不覺的走過十多個年頭了，也產生了很多App，隨著專案的推進不斷的迭代，而App也從最初的單一功能演變成多工功能，各種業務的錯綜

Android元件化框架專案詳解

簡介 什麼是元件化？ 專案發展到一定階段時，隨著需求的增加以及頻繁地變更，專案會越來越大，程式碼變得越來越臃腫，耦合會越來越多，開發效率也會降低，這個時候我們就需要對舊專案進行重構即模組的拆分，官方的說法就是元件化。 元件化帶來的好處 那麼，採用元件化能帶來什麼好處呢？主要有以下兩點： 1、

迴歸初心：極簡 Android 元件化方案 — AppJoint

Android 元件化的概念大概從兩年前開始有人討論，到目前為止，技術已經慢慢沉澱下來，越來越多團隊開源了自己元件化框架。本人所在團隊從去年開始調研元件化框架，在瞭解社群眾多元件化方案之後，決定自研元件化方案。為什麼明明已經有很多輪子可以用了，卻還是決定要自己造個新輪子呢？

android元件化方案整理

為什麼要元件化？ 在這之前我們先看一個圖，摘自我的腦圖： 所以，一直是需求再推動著我們前進，還有萬惡的產品！！！ 目前的主流方案：主工程多子工程開發模型 所有業務元件不再是mouble而是作為一個子工程,基礎元件可以使moudle,也可以是子工程,該子

Android元件化方案及元件訊息匯流排modular-event實戰

背景 元件化作為Android客戶端技術的一個重要分支，近年來一直是業界積極探索和實踐的方向。美團內部各個Android開發團隊也在嘗試和實踐不同的元件化方案，並且在元件化通訊框架上也有很多高質量的產出。最近，我們團隊對美團零售收銀和美團輕收銀兩款Android App進行了元件化改造。本文主要介紹我們的元

得到App Android元件化方案解析

為什麼要寫這篇文章 元件化已經深得客戶端開發大神們的認可，元件化確實進一步優化了客戶端團隊的開發效率，更適合大團隊分組推進，理解元件化的思想，深入研究元件化的實現方案是很必要的。 在接觸眾多元件化的方案後，自己也萌生了想搭建一套集眾家之所長的元件化方案。

Android元件化方案—阿里路由ARouter的使用

1、為什麼要專案元件化 隨著APP版本不斷的迭代，新功能的不斷增加，業務也會變的越來越複雜，APP業務模組的數量有可能還會繼續增加，而且每個模組的程式碼也變的越來越多，這樣發展下去單一工程下的APP架構勢必會影響開發效率，增加專案的維護成本，每個工程師都要熟悉如此之多的程式碼，將很

Android元件化方案

1、為什麼要專案元件化 隨著APP版本不斷的迭代，新功能的不斷增加，業務也會變的越來越複雜，APP業務模組的數量有可能還會繼續增加，而且每個模組的程式碼也變的越來越多，這樣發展下去單一工程下的APP架構勢必會影響開發效率，增加專案

android studio 搭建元件化專案框架

由於之前專案的冗餘功能和程式碼增多，讓app的執行bug頻出以及維護成本和維護難度的增加。公司領導不得不下定決心重新做一款app，把一些主要的功能從舊的app中剝離出來梳理分類，重新做一款便於維護，耦合性低的app。經過調研公司領導決定搭建元件化專案框架。 由

終極元件化框架專案方案詳解：一個極具參考的元件化專案

熱文導讀 | 點選標題閱讀作者：啊哈啊哈哈https://juejin.im/user/57a2

Android元件化之終極方案

Fragment或View如何支援元件化 距離 Android元件化方案 釋出已經半年有餘，雖說這個方案已經能夠解決一些專案的需求，但是依然不夠完美。很多開發者也在部落格和GitHub中留言甚至發郵件問我，Fragment怎麼辦？

【架構】android元件化方案，讓團隊開發更有效率

剛接到Leader元件化任務的時候，內心是有疑惑的。目前專案中，各種業務交雜在一起，互相跳轉、互相請求資料。分模組的過程必然是痛苦的，需要增加模組之間通的信協議。對於一個5，6人的團隊來說，全都放在一個大模組中似乎也沒啥不好，可以隨心所欲地呼叫，節約思考框架合理性的時間。

Android元件化 -- 完全解耦實踐方案

首先貼上原始碼地址,歡迎frok,歡迎start 原始碼地址 目前,Android 元件化普遍使用於移動開發,但是元件化的初衷是為了解耦程式碼,並行開發效率;小型app似乎會care不到,完全解耦的元件化會在app越來越臃腫的時候帶來很大的提升; 1.元件化

Android模組化專案模組間資料互動解決方案

    之前呢，也做過一個關於模組化業務分離的架構方案，這篇帖子想分享一下關於模組間的資料互動的方案。模組化架構，基礎的可以通過建立多個module來把業務進行區分和程式碼的解耦。為了解耦，讓module可拆卸，可移植，那麼業務模組間是不會有任何的依賴和引用的，在這樣的情況下

Android 元件化方案，從入門到精通。apply plugin: ‘com.android.application’

目錄 8、結束語 1、為什麼要專案元件化 隨著APP版本不斷的迭代，新功能的不斷增加，業務也會變的越來越複雜，APP業務模組的數量有可能還會繼續增加，而且每個模組的程式碼也變

Android元件化之元件通訊

Demo地址：https://github.com/751496032/ComponentDemo 本文是續上一篇Android元件化方案實踐與思考文章一些思考，主要是針對元件間通訊，比如： 每個元件如何初始化各自的資料 Activity間如何跳轉、Fragment例項

Android元件化框架搭建

本篇文章已授權微信公眾號 hongyangAndroid （鴻洋）獨家釋出 背景 當一個專案經過N手人開發，N個產品經理的蹂躪，N長時間的維護，此時一定存在大量程式碼冗餘、業務耦合、專案臃腫，資原始檔大把重複等等，不堪重負。當需要增加新功能或者修改之前某個功能的時候，我相信很多同仁都說只敢

Android元件化探索

文章目錄 元件化的優勢 元件化的步驟 元件化的注意事項 元件化的優勢 元件化簡單的說就是：能任意使用專案中的module來合併一個app. 實際開發中，遇到業務很複雜，且業務線較多時，我們往往會將專案模組化。但

Android元件化框架設計與實踐

轉載自：Android元件化框架設計與實踐 在目前移動網際網路時代，每個 APP 就是流量入口，與過去 PC Web 瀏覽器時代不同的是，APP 的體驗與迭代速度影響著使用者的粘性，這同時也對從事移動開發人員提出更高要求，進而移動端框架也層出不窮。 服務端與移動端對比 上圖顯示的是