前语

工作中我们遇见过许多项目,或许每个项目的优点你都想借鉴,每个项目的缺点你总想优化。但许多时分,牵一发而动全身,所以持续采用了不变应万变的战略。

怎样才是现代Android最佳实践的方法,每个人都有自己的标准和答案。

本次环境为Android Studio Giraffe2022.3.1

考虑的一些方面

组件化,模块化,下降代码耦合,事务耦合

组件化的层级与模块区分每个公司可能需求不一样,见过的好的模块层级能够是以下几个层级,参照下面的部分描绘:

yangchong211/YCAppTool: 组件化综合案例,组件分层为:根底公共组件,功用组件,事务组件,主工程。 (github.com)

  • 主工程(壳工程代码,多favor,debug助手等):

    • 除了一些全局装备和主 Activity 之外,不要包括太多的事务代码。有的也叫做空壳app,首要是依靠事务组件进行运转。
  • 事务组件(首要是事务层拆分的组件):

    • 最上层的事务,每个组件表示一条完好的事务线,彼此之间相互独立。原则上来说:各个事务组件之间不能有直接依靠!关于测试的时分,需求依靠多个事务组件的功用进行集成测试的时分。能够运用app壳进行多组件依靠办理运转。
  • 功用组件(分为服务组件和中台组件):

    • 该案例中分为,登录注册组件,分享组件,付出组件,Hybrid组件等等。同时注意,可能会触及多个事务组件对某个功用组件进行依靠!
  • 根底组件(分为东西组件和视图组件,这部分彻底和事务无关):

    • 支撑上层事务组件运转的根底事务服务。此部分组件为上层事务组件提供根本的功用支持。根底组件库中首要有,网络恳求,图片加载,通信机制,东西类,自定义控件等等。

本工程中的估计规划为:

new android #1 我这样考虑的新建项目
为了层级清晰,将对应模块放在了对应层级的子目录,后边模块多的时分也便于区分。

new android #1 我这样考虑的新建项目

gradle版别办理TOML文件

项目采用koltin版别的gradle脚本, 常见的方法之一在settings.gradle.kts中运用versionCatalogslibs能够换成你喜欢的姓名,乃至同级别你能够创立多个,只需姓名不一样就行。

include(":app")
include(":hideapi")
pluginManagement {
    repositories {
        mavenLocal()
        mavenCentral()
        gradlePluginPortal()
    }
}
dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
            val agp = "7.2.0"
            val appcompat = "1.4.1"
            library("build-android", "com.android.tools.build:gradle:$agp")
            library("androidx-appcompat", "androidx.appcompat:appcompat:$appcompat")
        }
    }
}

另外一种是运用toml文件,在gradle目录下libs.version.toml文件办理依靠

new android #1 我这样考虑的新建项目
文件内容能够包括version,libraries,plugins,bundles
new android #1 我这样考虑的新建项目
更具体的阐明,运用规则参照 Sharing dependency versions between projects (gradle.org)官方文档

运用自定义plugin削减模块内容

由于我们拆分的层级和模块,数量可能许多,每个模块的gradle脚本很大概率呈现大量相同的模板内容,一不小心还可能不一致。比如:


apply plugin: 'com.android.library' 
apply plugin: 'kotlin-android' 
android { 
    // lots of boilerplate
} 
tasks.withType(KotlinCompile).configureEach { 
    kotlinOptions { 
        jvmTarget = JavaVersion.VERSION_11 
     } 
}

现在能够考虑一种新的方法

plugins {
    id("newandroid.android.application")
}

为了完成这个目标,新建一个build-logic文件夹,里边定义了特定于本项目的约定插件,用于为通用模块装备保留单一的现实来历。大致结构如下:

new android #1 我这样考虑的新建项目
核心是在build.gradle.kts中注册自定义插件的完成类;

new android #1 我这样考虑的新建项目

运用根目录下的build.gradle.kts削减装备的一种方法

除了上面运用自定义的plugin方法削减装备,另一种方法是能够在根目录下的build.gradle.kts增加如下内容。

new android #1 我这样考虑的新建项目

子模块作为app调试的才能

如果是groovy脚本,过去我通常运用gradle properties属性控制,如果为true,就 apply buildAsApp.gradle 文件方法,可是运用kts格局,apply文件后会呈现找不到一些引用值。所以解决方案可能在同一个kts文件下判别。然后设置对应的Manifest和源码目录。

最后

  • 技能永远在前进,没有最好的方案。不断汲取优点改善加以运用便是好的。
  • 代码库房/new-android (github.com),还没想好首要工程内容,后边会慢慢增加模块代码。