echo " "
}
APP_ARGS=save "$@"

Collect all arguments for the java command, following the shell quoting and substitution rules

eval set – $DEFAULT_JVM_OPTS $JAVA_OPTS $GRADL{E}_{O}PTS"\ddot{-}Dorg.gradle.appname=$APP_BASE_NAME"" -classpath "“$CLASSPATH\ddot{"}org.gradle.wrapper.GradleWrapperMain"$APP_ARGS”

exec “$JAVACMD""$@”

主要干了这几件事

1. 设置 APP_HOME
2. 配置默认的 JVM 选项
3. 设置 CLASSPATH 路径，即指定 gradlew-wrapper.jar 路径
4. 检查 JAVA 环境配置等

1.2、命令大全

执行 ./gradlew --help gradle 会为我们输出帮助信息：(这里只列出了部分，更多可以自己敲命令去看看)

PS D:\workspace\GradleDemo> ./gradlew --help

To see help contextual to the project, use gradlew help

USAGE: gradlew [option…] [task…]

-?, -h, --help Shows this help message.
-b, --build-file Specify the build file. [deprecated]
–build-cache Enables the Gradle build cache. Gradle will try to reuse outputs from previous builds.
-c, --settings-file Specify the settings file. [deprecated]
–configuration-cache Enables the configuration cache. Gradle will try to reuse the build configuration from previous builds. [incubating]
–configuration-cache-problems Configures how the configuration cache handles problems (fail or warn). Defaults to fail. [incubating]
–configure-on-demand Configure necessary projects only. Gradle will attempt to reduce configuration time for large multi-project builds. [incubating]
–console Specifies which type of console output to generate. Values are ‘plain’, ‘auto’ (default), ‘rich’ or ‘verbose’.
–continue Continue task execution after a task failure.
-D, --system-prop Set system property of the JVM (e.g. -Dmyprop=myvalue).
-d, --debug Log in debug mode (includes normal stacktrace).
–daemon Uses the Gradle daemon to run the build. Starts the daemon if not running.
–export-keys Exports the public keys used for dependency verification.
-F, --dependency-verification Configures the dependency verification mode. Values are ‘strict’, ‘lenient’ or ‘off’.
–foreground Starts the Gradle daemon in the foreground.
-g, --gradle-user-home Specifies the Gradle user home directory. Defaults to ~/.gradle
-I, --init-script Specify an initialization script.
-i, --info Set log level to info.
-p, --project-dir

这些命令也是可以简写的，例如 --help 可以简写为 -?、-h

1.3、命令格式

gradle 命令的整体格式如下：

gradle [taskName…] [–option-name…]

2 gradle 常见命令

根据命令的功能目的，Gradle 命令大致可以分为下图的这些类型。

2.1 gradle 自身相关

2.1.1 查看 gradle 版本

查看 gradle 版本一般我们都是直接看项目中的 gradle.property 文件，里面的 distributionUrl 参数。除了这种方式，我们还可以通过gradle 命令查看： 输入：

./gradlew -version
//or
./gradlew -v

输出：

---

Gradle 8.0

Build time: 2023-02-13 13:15:21 UTC
Revision: 62ab9b7c7f884426cf79fbedcf07658b2dbe9e97

Kotlin: 1.8.10
Groovy: 3.0.13
Ant: Apache Ant™ version 1.10.11 compiled on July 10 2021
JVM: 17.0.8 (Amazon.com Inc. 17.0.8+7-LTS)
OS: Mac OS X 13.0.1 x86_64

2.1.2 gradle 版本升级

1、直接修改工程 gradle/wrapper/gradle-wrapper.properties 文件的 distributionUrl修改 gradle 版本 2、File>Project Structure 修改 AndroidGradle Plugin Version 和 Gradle 的版本然后 apply 3、使用命令行输入命令升级

./gradlew wrapper --gradle-version xxx

2.1.3 列出某个命令将要执行的所有任务（并不是真的执行它）

./gradlew xxx --dry-run

其中xxx就是要执行的命令，我们在学习的时候可以通过这个命令来快速的查看某个命令将要执行哪些任务。也方便快速对比相似功能的命令在执行过程中有哪些差异。

2.2 编译命令

2.2.1 编译打包

./gradlew build
//or
./gradlew assemble

这两个命令都是编译并输出全部类型的包。他们之间差别在于，build 命令是包含了 assemble 命令的全生命周期的，从上面的 task --all 命令说明也可以看出。下面的这个图可以更直观的反映：

分别执行 ./gradlew assemble --dry-run 和 ./gradlew assemble --dry-run命令，把输出结果进行对比。差别就是 build 命令会在 assemble 之后执行额外的 check 任务

2.2.2 编译 debug 包

./gradlew assembleDebug
//or
//反映
./gradlew installDebug

两个任务前面步骤一致，最后一步不一样，分别是执行 :app:assebmleDebug 和 :app:installDebug

2.2.3 编译 release 包

./gradlew assembleRelease
//or
./gradlew installRelease

两个任务前面步骤一致，最后一步不一样，分别是执行 :app:assebmleRelease 和 :app:installRelease

2.2.4 编译并打印日志

./gradlew assembleDebug --info
//or
./gradlew assembleRelease --info

加上 --info，编译日志会更完整，方便定位问题。

2.3 清除命令

./gradlew clean

等同于 Build > Clean Project，会清除构建目录下的产物

2.4 卸载命令

./gradlew uninstallDebug
//or
./gradlew uninstallRelease

这个命令是直接卸载连接设备上的当前项目安装包，跟 adb 指定包名进行卸载一样

2.5 调试命令

当我们使用 gradle 进行打包报错时，调试命令就可以帮我们更方便的定位出问题原因

2.5.1 编译并输出堆栈日志

./gradlew assembleDebug --stacktrace
//or
./gradlew assembleDebug -s

或者可以在参数前加上 --full 输出更详细的日志信息

./gradlew assembleDebug --full-stacktrace
//or
./gradlew assembleDebug --full-s

2.5.2 设置日志级别

Gradle 的日志分级

Level	作用
ERROR	错误
WARNING	警告
LIFECYCLE	生命周期
INFO	信息
DEBUG	调试
TRACE	跟踪

日志过滤

过滤命令	作用
-q 或 -quiet	只显示 ERROR 和 WARNING 日志
–i 或 --info	显示 INFO 及以上日志
-d 或 --debug	显示 DEBUG 及以上日志

示例：

./gradlew assembleDebug -e

2.6 任务相关命令

2.6.1 查看项目 gradle task

./gradlew tasks //只列出关键的 task
//or
./gradlew tasks --all //所有的 task 都将列出

这个命令将列出项目所有要执行的 task，并且会有这个 task 的相应说明信息(这里只截取了一部分)

2.6.2 执行 Task

./gradlew
//or
./gradlew ::

可以在 AndroidStudio 右边栏的 Gradle 菜单下选择 Tasks 执行也是一样的效果

2.7 依赖查看命令

依赖查看命令可以让我们更清晰的了解引入的依赖库，解决因为依赖导致的错误或者剔除一些不需要的依赖

./gradlew app:dependencies //输出 app 模块依赖树
//or
./gradlew dependencies > xxx.txt //输出依赖树到 xxx.txt 文件

依赖关系树后面有的会跟(*)``(c)有的又没有，代表如下意义：

1. * :表示该依赖项已被标记为被选中的版本。这意味着它是根据解析规则中的约束条件被选择的版本，而不是默认的最新版本。这通常是由于在项目的构建配置中明确指定了依赖项的版本或者存在其他依赖项对其版本有限制的情况。
2. c :表示该依赖项是由于冲突解决而被强制选择的版本。当项目中存在多个依赖项，它们对同一依赖的版本有不同的要求时，Gradle 将尝试解决这些冲突。如果无法找到满足所有依赖项的版本，Gradle 将选择一个版本并标记为冲突（conflict）。(c) 标记表示该依赖项是由于冲突解决而被强制选择的版本。

举个例子：

假设项目 A 依赖于库 X 的版本 1.0，而项目 B 依赖于库 X 的版本 2.0。这两个项目都作为依赖项添加到同一个项目 C 中。现在，项目 C 需要同时满足项目 A 和项目 B 的依赖。

Gradle 将尝试解决这个冲突，它会检查是否有一个版本可以同时满足项目 A 和项目 B 的依赖。如果存在满足所有依赖项的版本，Gradle 将选择该版本，并将其标记为被选中的版本 (*)。

然而，如果无法找到满足所有依赖项的版本，Gradle 将不得不做出一个决策。在这种情况下，Gradle 会选择一个版本，并将其标记为冲突 (c)。这表示所选的版本是为了解决冲突而被强制选择的，可能无法完全满足所有依赖项的要求。

2.8 性能相关命令

2.8.1 使用本地缓存版本离线编译

./gradlew assembleDebug --offline

也可以在AndroidStudio 侧边栏可视化开启关闭。差别在于，如果没开启离线编译，每次编译的时候都会去检查版本，对于没指定版本号或者动态版本号的依赖每次都会以最新的版本进行编译。

2.8.2 构建缓存

./gradlew assembleDebug --build-cache //开启
./gradlew assembleDebug --no-build-cache //不开启

2.8.3 配置缓存

./gradlew assembleDebug --configuration-cache //开启
./gradlew assembleDebug --no-configuration-cache //不开启

2.8.4 并行构建

./gradlew assembleDebug --parallel //开启
./gradlew assembleDebug --no-parallel //不开启

性能相关的这几个命令执行效果，和直接在 gradle.properties 中配置效果是一样的。

2.8.5 编译性能报告

./gradlew assembleDebug --profile

会在项目目录的 build > reports > profile 路径下生成报告文件

./gradlew assembleDebug --scan

会生成更详细的在线报告，首次执行会邮箱验证授权，完成后会输出一个链接。

2.9 动态传参命令

./gradlew assembleDebug -PisTest=true

build.gradle 中通过如下方式获取参数值

if(project.hasProperty(“isTest”)){
// do something
}else{
// do something else
}

通过 hasProperty 来获取命令行的参数

project.getProperty(“isTest”)

上面的方式都是判断参数是否存在，那么怎么获取参数的值呢？

if(project.hasProperty(“isTest”)){
println(“hasProperty isTest yes”)
if(Boolean.valueOf(project.getProperty(‘isTest’)){
println(“property isTest true”)
}else{
println(“property isTest false”)
}
}else{
println(“hasProperty isTest no”)
}

获取参数的数据类型需要基本数据类型转换成对应的类型，即 XXX.valueOf(getProperty('key'))。通过动态参数，我们可以在打包过程中做一些差异化的构建。

二、依赖管理和版本决议

在我们的开发中，经常会遇到各个模块中引入了相同的三方库，但是三方库版本又各不相同。有时候只是升级了一下某个依赖库存，结果运行就各种报错了。这部分课程将介绍一下 Gradle 的依赖管理方式和版本决议机制，弄明白 Gradle 是怎么把三方库引入到项目中的。在遇到同库不同版本的时候又是怎样决定使用哪个版本的。

1、依赖管理

不使用 maven 方式接入三方库，我们一般都是直接导入 jar 包或者 aar 包。替换版本的时候又重新去导入新的版本的 jar 或者 aar。遇到导入了相同 jar 或者 aar 的时候还出现冲突编不过。如果我们基于 Gradle 来开发项目，则可以依靠 Gradle 比较灵活方便的对依赖库版本进行管理。下图是 Gradle 工作的大致示意图：

构建过程中，Gradle 会先从本地检索，找不到就挨个从远端找依赖库，然后缓存到本地。 我们也可以通过以下方式，开启离线编译，对于未指定版本号或者使用动态版本号的依赖使用本地的版本进行编译

1.1 声明依赖

1.1.1 配置 maven 和依赖信息

声明 maven 依赖包含两部分：

• 仓库配置 我这里是在 gradle 8.0 的环境下演示的。配置信息在 projetc > settings.gradle 下，低版本配置信息一般在 project > build.gradle 下

pluginManagement {
repositories {
//指定 maven 仓库的地址
maven { url “https://www.jitpack.io” }
google()
//maven 官方仓库地址
mavenCentral()
//自定义 gitlab 仓库作为 maven 地址
maven {
url “https://gitee.com/monkeies/maven/raw/master”
}
//本地 maven 仓库地址
maven {
url uri(“/Users/pandaq/WorkSpace/AndroidProjects/Aizhong/Maven/”)
}
//http 地址需要配置 allowInsecureProtocol = true
maven {
url ‘http://xxx.xxx.xxx/xxx/’
allowInsecureProtocol = true
}
}
}

• 依赖库配置 依赖库的配置信息在各个 module 的 build.gradle 下

implementation ‘com.airbnb.android:lottie:6.1.0’

1.1.2 依赖类型

• 本地模块依赖
• 本地二进制文件依赖
• 远端二进制文件依赖

dependencies {
// Dependency on a local library module
implementation project(‘:mylibrary’)
// Dependency on local binaries
implementation fileTree(dir: ‘libs’, include: [‘*.jar’])
// Dependency on a remote binary
implementation ‘com.example.android:app-magic:12.3’ }

1.2 远端仓库

1.1.1 中我们配置的 repositories ，里面的 url 就是依赖项上川岛远端仓库的 url，远端仓库起一个桥梁的作用，把开发者和依赖库作者连接起来。开发者、远端仓库、依赖库开发者三者关系大概如下图所示：

1. 左侧是我们项目的开发过程，通过声明依赖库信息和配置远端仓库地址，从而找到我们想要的 Lib；
2. 中间为远端仓库，包含了丰富的 library/组件/插件；
3. 右侧是 Lib 组件的开发者，把代码通过 aar/jar的形式打包到远端仓库提供给使用方；

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数HarmonyOS鸿蒙开发工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年HarmonyOS鸿蒙开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上HarmonyOS鸿蒙开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新

如果你觉得这些内容对你有帮助，可以添加VX：vip204888 （备注鸿蒙获取）

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！**

因此收集整理了一份《2024年HarmonyOS鸿蒙开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
[外链图片转存中…(img-K7QXtUbB-1712656991185)]
[外链图片转存中…(img-aKJTq3fL-1712656991186)]
[外链图片转存中…(img-naicfP5K-1712656991186)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上HarmonyOS鸿蒙开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新

如果你觉得这些内容对你有帮助，可以添加VX：vip204888 （备注鸿蒙获取）
[外链图片转存中…(img-4qq3nGbP-1712656991186)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！