Android架構之App組件化方案詳細實踐與總結

2021-02-14 開發者全社區

相關閱讀:

吊炸天!74款APP完整源碼!

【乾貨】最新阿里Android面試題總結(附答案)

論讀Android源碼的重要性——Hook技術之View點擊劫持

1、Android組件化項目

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

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

2、Android組件化項目實施步驟1)第一步:配置可自動將組件在Application和Library屬性之間切換的方法

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

當我們在開發單獨組件的時候,這個組件應該處於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>

debug文件夾中註冊表的標籤中指定了具體application類,而release文件夾中的則沒有,

debug文件夾中註冊表的標籤中添加一些application屬性,而release文件夾中的則什麼都沒有添加;

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)) {                    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中定義如下代碼:

ext {    buildToolsVersion = localBuildToolsVersion    compileSdkVersion = 23

   minSdkVersion = 16

   targetSdkVersion = 23    versionCode = 1

   versionName = "1.0"

   javaVersion = JavaVersion.VERSION_1_8     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.buildToolsVersiondefaultConfig {    
     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配置

<activityandroid: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" />    </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

參考文章: 

1. http://www.cnblogs.com/chenxibobo/p/6187954.html 
2. https://kymjs.com/code/2016/10/18/01/ 
 3. http://www.open-open.com/lib/view/open1481772233714.html 
4. https://zhuanlan.zhihu.com/p/23388989 
 5. https://zhuanlan.zhihu.com/p/23147164?refer=moduth

原文:http://blog.csdn.net/guiying712/article/details/55213884

Java和Android大牛頻道

歡迎關注我們,一起討論技術,掃描和長按下方的二維碼可快速關注我們。或搜索微信公眾號:JANiubility。

公眾號:JANiubility

相關焦點

  • Android徹底組件化方案實踐
    而實際上組件化的目標之一就是降低整體(app)與器官(組件)的依賴關係,缺少任何一個器官app都是可以存在並正常運行的。頭和胳膊可以單獨存在嗎?左圖也沒有說明白,其實答案應該是肯定的。每個器官(組件)可以在補足一些基本功能之後都是可以獨立存活的。這個是組件化的第二個目標:組件可以單獨運行。組件化和插件化可以都用右圖來表示嗎?
  • Android徹底組件化方案實踐,附Demo
    而實際上組件化的目標之一就是降低整體(app)與器官(組件)的依賴關係,缺少任何一個器官app都是可以存在並正常運行的。頭和胳膊可以單獨存在嗎?左圖也沒有說明白,其實答案應該是肯定的。每個器官(組件)可以在補足一些基本功能之後都是可以獨立存活的。這個是組件化的第二個目標:組件可以單獨運行。
  • Android組件化和插件化的概念
    一、什麼是組件化和插件化 組件化: 就是將一個app分成多個模塊,每個模塊都是一個組件(Module),開發的過程中我們可以讓這些組件相互依賴或者單獨調試部分組件等,但是最終發布的時候是將這些組件合併成一個apk,這就是組件化開發。
  • Android組件化架構 - 5. 數據存儲 & GreenDao,Room
    組件化存儲Android原生的存儲體系是全局的,在組件化的開發中,五種原生的存儲方式是完全通用的;比較值得介紹的是兩個主流的資料庫框架GreenDao,RoomGreenDao是目前眾多orm資料庫中最穩定,速度最快,編寫體驗最好的框架,並且支持RxJava, 支持sqlcipher資料庫加密另外還有一個比較常用的資料庫框架realm
  • Android徹底組件化(二)-Demo發布
    今年6月份開始,我開始負責對「得到app」的android代碼進行組件化拆分,在動手之前我查閱了很多組件化或者模塊化的文章,雖然有一些收穫,但是很少有文章能夠給出一個整體且有效的方案,大部分文章都只停留在組件單獨調試的層面上,涉及組件之間的交互就很少了,更不用說組件生命周期、集成調試和代碼邊界這些最棘手的問題了。
  • 架構組件之 ViewModel | 中文教學視頻
    更多詳細內容介紹,請訪問以下文檔連結> 架構組件的官方開發者文檔:https://developer.android.google.cn/arch> ViewModel 的文檔: https://developer.android.google.cn/topic/libraries/
  • App工程搭建:幾種常見Android代碼架構分析
    本文先分析幾個當今比較流行的android軟體包,最後我們汲取其中覺得優秀的部分,搭建我們自己的通用android工程模板。1. 微盤微盤的架構比較簡單,我把最基本,最主幹的畫了出來:第一層:com.sina.VDisk:com.sina(公司域名)+app(應用程式名稱) 。
  • Android 架構組件 - 讓天下沒有難做的 App
    其中 Architecture 部分的組件(Android Architecture Components,以下簡稱 AAC)組合起來形成了一套完整的架構解決方案,在沒有更好的方案被發明出來之前,我們姑且把 AAC 當做 Android 架構領域的最佳實踐,它的出現一定程度上避免了很多不必要的輪子。官方給出的架構指導非常明確地表達出了每個架構組件的位置:
  • Android插件化系列三:技術流派和四大組件支持
    第二代VirtualApk, Small(林光亮),RePlugin為了同時達到插件開發的低侵入性(像開發普通app一樣開發插件)和框架的穩定性,在實現原理上都是趨近於選擇儘量少的hook,並通過在manifest中預埋一些組件實現對四大組件的插件化。第三代VirtualApp,Atlas在這一代中,插件兼容性,穩定性提升到更高的層次。同時,容器化框架的概念越來越流行。
  • IM開發乾貨分享:有贊移動端IM的組件化SDK架構設計實踐
    本文由有贊技術團隊原創分享,原題「有贊 APP IM SDK 組件架構設計」,即時通訊網收錄時有修訂和改動,感謝原作者的無私分享。1、引言本文主要以Android客戶端為例,記錄了有贊旗下 App 中使用自研 IM,並將IM提煉成組件化SDK的設計思路。
  • Android組件化架構 - 3. 組件間跳轉 & ARouter路由
    但是組件化中,兩個功能模塊是不存在直接依賴關係的(通過baseModule間接依賴),那麼包裝intent時就會發現引用不了其他module中的activity類(xxx.class)。隱式跳轉這裡還有個安全隱患,其他app也可以通過隱式intent跳轉到我們的activity,需要清單文件中設置exported=false,確保只有自己的app能啟動組件;隱式跳轉是原生的,和廣播一樣,範圍是整個Android系統都能收到,是否有更好的方式呢2.
  • Android學習(四) — 組件(一)
    vertical子組件垂直排列layout_widthlayout_heightmatch_parent組件佔滿父布局wrap_parent組件根據子組件大小自適應布局大小gravitycenter子組件居中top子組件置頂bottom子組件置底right
  • 最詳細的 NavigationDrawer 開發實踐總結
    Toolbar 開發實踐總結》一文,發布後大家反饋很好,最近又奮筆疾書,熬出此文,個人感覺D_clock同學寫起這類文章是越來越6,與他交流後得知:他雖寫博客文章不久,但提筆之前,也是用心觀察了很多優秀博文的寫法,其文章很多細節都花了不少心思打磨,這份用心也非常值得稱讚。
  • 最詳細的 Toolbar 開發實踐總結
    "        android:title="@string/menu_notifications"        app:showAsAction="ifRoom" />    <item        android:id="@+id/action_item1"        android:title="@string/item_01"        app:showAsAction
  • Hybrid APP架構設計思路
    本文將從以下幾個方面闡述Hybrid app架構設計的一些經驗和思考。通訊作為一種跨語言開發模式,通訊層是Hybrid架構首先應該考慮和設計的,往後所有的邏輯都是基於通訊層展開。但是,在實際的項目中,將整個app所有界面都使用H5來開發也有不妥之處,根據經驗,以下情形還是使用Native界面為好:關鍵界面、交互性強的的界面使用Native因H5比較容易被惡意攻擊,對於安全性要求比較高的界面,如註冊界面、登陸、支付等界面,會採用Native來取代H5開發,保證數據的安全性,這些頁面通常UI變更的頻率也不高。
  • 從零開始學Android架構(一)——什麼是設計模式?
    除了Android,我們還可以從Github或者其他的開源項目或者文章中學習各種優秀的架構思路,如分層架構,微內核架構,插件化架構等等。我會通過幾篇文章,來講解我對架構的理解,文章主要為三個主題,分別介紹什麼是架構,什麼是框架,什麼是設計模式。架構,框架,設計模式,這三點,是從項目的整體到代碼的細節粒度不斷縮小的過程。
  • Android官方架構組件:Lifecycle詳解&原理分析
    Paging:分頁庫的設計美學Android官方架構組件Navigation:大巧不工的Fragment管理框架Android官方架構組件Lifecycle:生命周期組件詳解&原理分析概述在過去的谷歌IO大會上,Google官方向我們推出了 Android Architecture Components,其中談到Android組件處理生命周期的問題,
  • Android 新架構組件: WorkManager
    熱文導讀 | 點擊標題閱讀歡迎加入Java和Android架構知識星球
  • Android四大組件知識點總結
    詳細介紹:onCreate():第一個調用的方法,通常在該方法中加載布局文件、初始化資源、註冊事件與BroadcastReceiver等較重的任務。android:theme=」@android:style/Theme.Dialog」談談onSaveInstanceState()方法?何時會調用?
  • Android架構學習資料
    Android架構學習資料整理,總有一個適合你連結可以點擊閱讀原文獲取個人最近在嘗試