Android图片资源检测插件实现

刺骨的言语ヽ痛彻心扉 2023-10-15 10:21 58阅读 0赞

## 为什么要检测图片资源？ ##

1.  避免不小心把未压缩，不合适的图片资源打入apk中，造成apk过大
2.  图片打入apk前，可以自动化转换，压缩

### 实现思路 ###

1.  思路一：使用gradle在aapt编译期，扫描汇总资源的文件夹，过滤出不符合要求的图片资源，并抛出异常中断编译
2.  思路二：是思路一的进阶。还是在使用gradle在aapt编译期，查找有没有合适的gradle task，提供给我们遍历所有资源的机会

### gradle插件实现 ###

#### gradle插件实现的基础 ####

> 简单对gradle插件实现进行复习

##### 插件搭建 #####

>  *  新建一个模块
>  *  配置好该模块的上传配置（mvn.gradle）
>  *  在build中，对gradleApi进行依赖
>     
>     `apply plugin: 'kotlin' //插件如果使用kotlin实现，需要依赖kotlindependencies { implementation gradleApi() implementation localGroovy() implementation 'com.android.tools.build:gradle:3.4.2'}`
>  *  在main下面新建resources.META-INF.gradle-plugins文件夹
>  *  在该文件夹中创建一个和module同名的.properties文件，在里面配置上你的插件入口类
>     
>     例：
>     
>         implementation-class=com.xxx.checkbigimage.image.ImagePlugin

##### 插件的基本实现 #####

上面讲到要配置一个入口类，这个入口类就是实现了Plugin接口的类，它有一个override fun apply(project: Project)方法，就是我们插件开始执行的地方，相当于main函数，参数project就是整个工程的配置文件

可以使用以下方法，从我们使用插件的地方获取到对插件的配置

> `project.extensions.create("config", Config::class.java)mConfig = project.property("config") as Config`

Config是一个java bean数据类

"config"是我们在build中的配置名称

###### 这样一个简单gradle插件就实现了 ######

### 图片资源检测插件实现 ###

上面说了为什么要实现这样一个插件和该如何实现一个gradle插件，那么下面就具体介绍该插件的实现过程

#### 想要的功能 ####

*  检测和拦截功能
    
     *  检测是否有大小超标的图片
     *  检测是否有宽高超标的图片
     *  拦截非webp资源，并进行提示
 *  自动化压缩
    
     *  自动压缩png，jpg等资源
 *  白名单设置
 *  一些统计功能

#### 实现过程 ####

上面已经说了gradle插件的实现，那么我们就从apply方法开始说起。

###### 瞄准task挂钩 ######

既然是要hock android打包的编译过程，那就要寻找android打包时，合适的task

###### 想hock task，首先应该拿到任务task集合 ######

在android插件编译生成apk的过程中，有好多task都可以生成apk，它们的名字基于Build Types 和 Product Flavor 生成。那么我们怎么拿到具体生成apk的task组呢？

为了解决这个问题。android插件有几个属性，就是我们平常配置的变体（所谓的环境），androd中有三类变体

*  applicationVariants（只适用于 app plugin）
 *  libraryVariants（只适用于 library plugin）
 *  testVariants（app、library plugin 均适用）

这三个对象都是实现了BaseVariant（BaseVariantImpl为实现这个接口的抽象类）接口的类的对象的集合

属性名

属性类型

说明

name

String

Variant 的名字，唯一

description

String

Variant 的描述说明

dirName

String

Variant 的子文件夹名，唯一。可能有不止一个子文件夹，例如 “debug/flavor1”

baseName

String

Variant 输出的基础名字，必须唯一

outputFile

File

Variant 的输出，该属性可读可写

processManifest

ProcessManifest

处理 Manifest 的 task

aidlCompile

AidlCompile

编译 AIDL 文件的 task

renderscriptCompile

RenderscriptCompile

编译 Renderscript 文件的 task

mergeResources

MergeResources

合并资源文件的 task

mergeAssets

MergeAssets

合并 assets 的 task

processResources

ProcessAndroidResources

处理并编译资源文件的 task

generateBuildConfig

GenerateBuildConfig

生成 BuildConfig 类的 task

javaCompile

JavaCompile

编译 Java 源代码的 task

processJavaResources

Copy

处理 Java 资源的 task

assemble

DefaultTask

Variant 的标志性 assemble task

因为我们的插件应该可以应用在主工程或者模块包上的，所以当我们插件运行后，我们要检测当前使用我们插件的模块是主工程，还是模块包

kotlin

复制代码

`val hasAppPlugin = project.plugins.hasPlugin("com.android.application")val variants = if (hasAppPlugin) { (project.property("android") as AppExtension).applicationVariants} else { (project.property("android") as LibraryExtension).libraryVariants}`

###### 找到想要hock的任务 ######

我们想hock住android插件运行的task任务，就需要一个重要的gradle回调

> `project.afterEvaluate{...}`

afterEvaluate该方法就是整个gradle配置文件配置成功后的回调，证明此时配置已检查完毕，所有task已经就绪，已经可以开始按指定顺序运行task了，那么我就需要在这个回调里办事！

> Grade 执行顺序
> 
> 1.  执行setting，检测所有module，为每个模块配置project
> 2.  加载build.properties，生成task执行链表和配置
> 3.  执行某个指定task，然后会先执行该task所依赖的task

配置完成后，开始遍历variants中所有的变体

> `project.afterEvaluate { variants.all { variant -> ... }}`

###### 我们的目标task：mergeResourcesProvider ######

mergeResourcesProvider这个任务就是android插件合并所有module中资源的task，看名字就知道了。

我们可以从变体中获取这个task对象

> `val mergeResourcesTask = variant.mergeResourcesProvider.get()`

那么，我们自己的任务呢？

gradle api提供给我们可以在代码中生成task的方法

> `val mcPicTask = project.task("CheckBigImage${variant.name.capitalize()}")`

使用project.task("taskname")来生成一个我们自己需要执行的task

然后我们编写这个task的逻辑，也是本插件的逻辑

> `mcPicTask.doLast {...}`

variant里面有各种对象，allRawAndroidResources恰好就是我们需要的。它只有3.3以上才会有。

> `val dir = variant.allRawAndroidResources.files`

这个dir对象，就是android所有文件资源的files集合

ok。让我们遍历这个文件list吧！

> `for (channelDir: File in dir) {check(channelDir)}fun check(file: File) { if(file.isDirectory) { check(file)} else { process(file)}}`

如果遇到文件夹，这里是一个递归调用。

如果遇到文件，就可以按照自己的规则处理了。

###### 挂钩mergeResourcesProvider ######

我们task写好后，需要和mergeResourcesProvider挂钩

> `mergeResourcesTask.dependsOn(project.tasks.findByName(mcPicTask.name))`

使mergeResourcesTask依赖我们的mcPicTask，当mergeResourcesTask执行前，就会先执行我们的mcPicTask了！！

> 注意：此处直接使用mergeResourcesTask系统task依赖我们的task，我们的task执行顺序会和mergeResourcesTask原有的依赖混杂在一起，不可控。后面讲一种可控的方法

##### 拦截图片的逻辑 #####

这个逻辑应该实现在上面伪代码process(file:File)方法中

> 1.  首先我们只需要处理图片，所以对参数file进行首轮过滤，只留下后缀名为图片的文件
>     
>         fun isImage(file: File): Boolean { return (file.name.endsWith(Const.JPG) || file.name.endsWith(Const.PNG) || file.name.endsWith(Const.JPEG) || file.name.endsWith(Const.GIF) || file.name.endsWith(Const.WEB_P) ) && !file.name.endsWith(Const.DOT_9PNG)}
> 2.  需要检查图片的宽高的话，可以使用java的原生api
>     
>         val sourceImg = ImageIO.read(FileInputStream(imgFile))if (sourceImg.height > maxHeight || sourceImg.width > maxWidth) { ...
> 3.  需要过滤图片大小的话
>     
>         if (imgFile.length() >= maxSize) { LogUtil.log(SIZE_TAG, imgFile.path, true.toString()) return true}

##### 压缩图片逻辑 #####

> 这里我们只处理普通图片转换为webp的压缩。jpg,png的自压缩原理相同，就不复述了

想压缩转换webp图片，需要用到转换工具

google提供的有一套命令行转换工具：cwebp ，各个平台都有，我们去下载一套，放在我们的主工程文件夹下就可以了

这里需要注意的是：为了方便，如果把cwebp命令行程序放在环境变量下，那么执行命令时，拼接命令时，直接拼接cwebp就好。

如果使用工程目录下的cwebp，执行前，需要在cwebp命令前面拼接它所在的工程目录。

使用

> `project.rootDir.path`

可以获取工程的根目录

###### 如何执行命令行程序呢？ ######

可以使用java的api

> `Runtime.getRuntime().exec(cmd)`

现在可以愉快的转换图片了

> `Tools.cmd("cwebp", "${imgFile.path} -o ${webpFile.path} -m 6 -quiet")`

转换后，记得把原图删掉

> 优化点：
> 
> 1.  有的图片转换后比以前还大，这里需要注意
> 2.  第一次扫描过后的无法优化的图片，可以存在一个text文本当中，第二次执行时，就不要去转换了

###### 系统兼容 ######

在linux系统上，创建和删除文件都需要权限，如果没有权限就会失败。这时需要先判断当前的操作系统是不是linux，如果是，可以执行chmod 755 -R $\{FileUtil.getRootDirPath()\}添加权限

这里可以优化一下，在我们的mcPicTask前面再加一个task，用来添加权限，这个task只对文件夹进行递归添加就可以了，比一个一个文件要来的快。

因为我们不清楚系统的task（mergeResourcesTask）都依赖了哪些，那么如何在依赖上再加依赖，如何插入task呢？

gradle api提供给了我们一个方法，xxx.taskDependencies.getDependencies(xxx)可以获取自己的依赖树

在这里就是

> `(project.tasks.findByName(chmodTask.name) asTask).dependsOn(mergeResourcesTask.taskDependencies.getDependencies(mergeResourcesTask))`

让chmodTask依赖mergeResourcesTask的依赖。假如mergeResourcesTask是A，chmodTask是B。A依赖一个系统的C。那么上面的代码就是让B依赖了C。这时的task图就是 B->C，A->C

接下来我们再把mcPicTask（简称为D）也依赖进来

> `(project.tasks.findByName(mcPicTask.name) as Task).dependsOn(project.tasks.findByName(chmodTask.name) as Task)`

这时就是D->B->C，A->C

最后，回到我们刚刚**拦截图片的逻辑**的最后代码

> `mergeResourcesTask.dependsOn(project.tasks.findByName(mcPicTask.name))`

就变成了A->D->B->C，也就是mergeResourcesTask->mcPicTask->chmodTask->原依赖task，依赖和执行顺序是相反的。

正常的代码就是

> `(project.tasks.findByName(chmodTask.name) asTask).dependsOn(mergeResourcesTask.taskDependencies.getDependencies(mergeResourcesTask))(project.tasks.findByName(mcPicTask.name) as Task).dependsOn(project.tasks.findByName(chmodTask.name) as Task)mergeResourcesTask.dependsOn(project.tasks.findByName(mcPicTask.name))`

###### Tips ######

直接使用mergeResourcesTask.dependsOn(project.tasks.findByName([mcPicTask.name][]))插入task。执行顺序打印

> ......
> 
> Task :app:mainApkListPersistenceDebug UP-TO-DATE
> 
> Task :app:CheckBigImageDebug
> 
> Task :app:generateDebugResValues UP-TO-DATE Task :app:generateDebugResources UP-TO-DATE Task :app:mergeDebugResources
> 
> ......

而使用正规的插入法顺序

> Task :app:mainApkListPersistenceDebug UP-TO-DATE Task :app:generateDebugResValues UP-TO-DATE Task :app:generateDebugResources UP-TO-DATE Task :app:chmodDebug
> 
> Task :app:CheckBigImageDebug
> 
> Task :app:mergeDebugResources

###### gradle版本差异 ######

我们上面的例子，都是基于比较最新的gradle和android gradle tools版本（>3.3），android插件直接提供给了我们allRawAndroidResources，方便无比，直接在merge前遍历它就好了。

那么3.3之前的版本呢？就是我们最初的设想了，在合并完各个module资源后，扫描merge文件夹！这里又有aapt和aapt2的差异

###### 方法一 ######

关掉aapt2

> `android.enableAapt2=false`

在**mergeDebugResources**后，**processDebugResources**前扫描文件夹

前面说过，mergeDebugResources是合并所有module的资源文件到固定目录

那么**processDebugResources**是什么呢？就是处理这些已经合并完成的文件，生成[R.id][]，资源索引之类的文件

那么我们的任务就必须插入到**processDebugResources**前面，而不是**mergeDebugResources**了

###### 方法二 ######

仔细翻了翻MergeResources里面的方法，有一个getResSet和computeResourceSetList看起来有点意思。那么computeResourceSetList中又调用了getResSet。最后发现computeResourceSetList果然可以获取所有文件列表。

> `/*** Computes the list of resource sets to be used during execution based all the inputs.*/@VisibleForTesting@NonNullList<ResourceSet> computeResourceSetList()`

注释也很有意思，有道翻译一下：根据所有输入计算执行期间使用的资源集列表。

鉴于该方法是友元方法，就使用反射获取。

> 因为3.3之后，aapt2是强制开启的，并且aapt2 merge后的文件不是原文件了哦！注意aapt1合并后，还是正常的xxx.png。aapt2合并后的文件扩展名为flat
> 
> 所以，方法一不支持大于3.3的gradle版本。方法二支持。可以平滑过渡到新版本。鉴于新版本的gradle直接提供了allRawAndroidResources这样的方法，所以在3.3以上，直接使用它就可以了

###### allRawAndroidResources和扫描合并文件夹的差异。 ######

allRawAndroidResources提供的是未合并前的资源路径

*  源码依赖的module，编译时，会获取该文件的真实路径
 *  aar依赖的路径，会获取到aar-cache的路径
 *  所以：如果开启自动转换webp功能你会发现：你本地源代码中的png，都转成了webp

扫描合并文件夹，扫描的是编译期merge成功后的文件夹

*  不会影响源代码
 *

##### 优化 #####

1.  已经扫描过的，且确认无法经过webp优化的图片，把这些名称写入一个本地文件，优化扫描速度

## 未来想做的事情 ##

##### 统计 #####

1.  拦截了多少图片
2.  转换了多少图片
    
    3. 统计各个模块的图片资源情况。在合适的时间进行预警

作者：小肥洋  
链接：https://juejin.cn/post/7270509784687853602  
来源：稀土掘金  
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

[mcPicTask.name]: https://link.juejin.cn?target=http%3A%2F%2FmcPicTask.name
[R.id]: https://link.juejin.cn?target=http%3A%2F%2FR.id