寄Android开发Gradle你需要知道的知识
这个大兄弟总结得好,老是看到别人说自己整理的才是自己的。你说这些文章啊,人家都写得这么详细这么6了,咱们还写干嘛。
补充几个自己想说的
1、AndroidStudio导入项目一直卡在Building gradle project info
实际上是因为你导入的这个项目使用的gradle与你已经拥有的gradle版本不一致,导致需要下载该项目需要的gradle版本,然后下载不下来,就是会一直卡住,直至下载完成
上文的大兄弟提供了两种方式:
1、网速好或者科学上网的时候,由它自己去下载,不过下载时间有长有短,不能保证。
2、当你在公司被限网速的时候,当然也是我最常用的,就是把你最近常用项目的gradle-wrapper.properties文件替换掉你要导入项目的该文件,基本上我是这样解决的,当然有时候也会遇到替换掉报错的情况,不过比较少。
第二种也是我常用的解决方式,解决步骤就是
1.随便找一个你能运行的as项目
2.打开gradle-wrapper.properties,文件目录:项目/gradle/wrapper/gradle-wrapper.properties
3.复制distributionUrl这一整行的内容,eg: distributionUrl=https://services.gradle.org/distributions/gradle-4.4-all.zip
4.打开你要导入的项目的gradle-wrapper.properties,具体步骤与步骤2相同
5.把步骤3复制的内容,替换你要导入的项目的gradle-wrapper.properties文件的distributionUrl这一行
6.再重启as,导入项目就可以了
然后有的时候,会出现app build gradle failed,就是下图的地方出现小红叉
这种情况,我一般会直接去这个网站直接下载对应的包下载下来
然后不用解压,直接放到下图文件夹下就可以了,后面的\gradle-4.4-all\9br9xq1tocpiv8o6njlyu5op1这个路径,你在building的时候虽然卡住,但是他会自动创建的。
2、compileSdkVersion, minSdkVersion 和 targetSdkVersion的选择
compileSdkVersion, minSdkVersion 和 targetSdkVersion的选择
compileSdkVersion
首先是它们的作用,compileSdkVersion 告诉 Gradle 用哪个 Android SDK 版本编译你的应用。使用任何新添加的 API 就需要使用对应 Level 的 Android SDK。
需要注意的是,如果使用 Support Library ,那么使用最新发布的 Support Library 就需要使用最新的 SDK 编译。
例如:implementation 'com.android.support:appcompat-v7:27.1.1'
此时compileSdkVersion 就必需至少是 27(大版本号要一致)。通常,新版的 Support Library 随着新的系统版本而发布,它为系统新增加的 API 和新特性提供兼容性支持。
minSdkVersion
minSdkVersion 是应用可以运行的最低要求。minSdkVersion 是 Google Play 商店用来判断用户设备是否可以安装某个应用的标志之一。
在开发时 minSdkVersion 也起到一个重要角色:lint 默认会在项目中运行,它在你使用了高于 minSdkVersion 的 API 时会警告你,帮你避免调用不存在的 API 的运行时问题。如果只在较高版本的系统上才使用某些 API,通常使用运行时检查系统版本的方式解决。
请记住,你所使用的库,如 Support Library 或 Google Play services,可能有他们自己的 minSdkVersion 。你的应用设置的 minSdkVersion 必需大于等于这些库的 minSdkVersion 。例如有三个库,它们的 minSdkVersion 分别是 4, 7 和 9 ,那么你的 minSdkVersion 必需至少是 9 才能使用它们。在少数情况下,你仍然想用一个比你应用的 minSdkVersion 还高的库(处理所有的边缘情况,确保它只在较新的平台上使用),你可以使用 tools:overrideLibrary 标记,但请做彻底的测试!
当你决定使用什么 minSdkVersion 时候,你应该参考当前的 Android 分布统计,它显示了最近 7 天所有访问 Google Play 的设备信息。他们就是你把应用发布到 Google Play 时的潜在用户。最终这是一个商业决策问题,取决于为了支持额外 3% 的设备,确保最佳体验而付出的开发和测试成本是否值得。
targetSdkVersion
三个版本号中最有趣的就是 targetSdkVersion 了。 targetSdkVersion 是 Android 提供向前兼容的主要依据,在应用的 targetSdkVersion 没有更新之前系统不会应用最新的行为变化。这允许你在适应新的行为变化之前就可以使用新的 API (因为你已经更新了 compileSdkVersion 不是吗?)。
targetSdkVersion 所暗示的许多行为变化都记录在 VERSION_CODES 文档中了,但是所有恐怖的细节也都列在每次发布的平台亮点中了,在这个 API Level 表中可以方便地找到相应的链接。
例如,Android 6.0 变化文档中谈了 target 为 API 23 时会如何把你的应用转换到运行时权限模型上,Android 4.4 行为变化阐述了 target 为 API 19 及以上时使用 set() 和 setRepeating() 设置 alarm 会有怎样的行为变化。
由于某些行为的变化对用户是非常明显的(弃用的 menu 按钮,运行时权限等),所以将 target 更新为最新的 SDK 是所有应用都应该优先处理的事情。但这不意味着你一定要使用所有新引入的功能,也不意味着你可以不做任何测试就盲目地更新 targetSdkVersion ,请一定在更新 targetSdkVersion 之前做测试!你的用户会感谢你的。
注意,这段是来源于慕课网,但是我怀疑他们是直接百度翻译的官方文档。很明显的名义不通顺。大概意思应该是说,当我们把compileSdkVersion版本更新到了更高版本之后,我们就可以用更高版本里新增加的api了。但是只要我们的targetSdkVersion没更新到更高版本,就不会受到更高版本的新特性的阻碍。比如说,我们把compileSdkVersion设置为23,这时候我们可以使用23的新api,但是只要targetSdkVersion低于23,仍然不受运行时权限新特性的阻碍。(Android
6.0(API23)时安卓加入了运行时权限,都知道的吧?)
综合来看
如果你按照上面示例那样配置,你会发现这三个值的关系是:
minSdkVersion <= targetSdkVersion <= compileSdkVersion
这种直觉是合理的,如果 compileSdkVersion 是你的最大值,minSdkVersion 是最小值,那么最大值必需至少和最小值一样大且 target 必需在二者之间。
理想上,在稳定状态下三者的关系应该更像这样:
minSdkVersion (lowest possible) <=
targetSdkVersion == compileSdkVersion (latest SDK)
用较低的 minSdkVersion 来覆盖最大的人群,用最新的 SDK 设置 target 和 compile 来获得最好的外观和行为。
MethodHandle.invoke and MethodHandle.invokeExact are only supported starting with Android O (–min-api 26)
Could not target platform: ‘Java SE 10’ using tool chain: ‘JDK 8 (1.8)’.
3、comileSdkVersion 和buildToolsVersion区别
comileSdkVersion 和buildToolsVersion区别
CompileSdkVersion:是告诉gradle 用哪个SDK版本来编译,和运行时要求的版本号没有关系;使用任何新添加的 API 就需要使用对应 Level 的 Android SDK。
buildToolsVersion: android构建工具的版本,在SDK Manager中安装选择版本,buildToolsVersion的版本需要>=CompileSdkVersion; 高版本的build-tools 可以构建低版本编译的android程序;
4、Android Studio gradle插件版本和gradle版本对应关系
Android Studio gradle插件版本和gradle版本对应关系
5、多渠道打包以及配置Gradle
6、导入一个项目,项目gradle4.4 as3.1而我gradle3.3 as2.3
导入一个项目,项目gradle4.4 as3.1而我gradle3.3 as2.3
7、手把手教你一步步用批处理程序打包你的android App
gradlew clean && gradlew assembleRelease
ping -n 15 127.0.0.1>nul