其他分享
首页 > 其他分享> > 关于gradle多渠道打包的命名

关于gradle多渠道打包的命名

作者:互联网

使用gradle多渠道打包也不是什么新鲜事了,配置productFlavors就完事了,再写点buildConfigField什么的,似乎也就可以用了。

用确实是可以用,但遇上某天想改打包出来的名字就很尴尬了,不知道怎么改。

使用

本来在build.gradle有这样的配置:

android {
    productFlavors {
        jinxin_bcca {
            manifestPlaceholders = [CHANNEL_VALUE: "bcca"]
            buildConfigField "String", "BCCA_HOST", '"222.182.202.98"'
            buildConfigField "int","BCCA_PORT",'9529'
            buildConfigField "int","DEVICE_TYPE",'0x00000631'
        }
        jinxin_bcca_debug {
            manifestPlaceholders = [CHANNEL_VALUE: "bcca_debug"]
            buildConfigField "String", "BCCA_HOST", '"39.105.93.18"'
            buildConfigField "int","BCCA_PORT",'9529'
            buildConfigField "int","DEVICE_TYPE",'0x00000601'
        }
    }
}

然后加一段配置代码:

            applicationVariants.all { variant ->
                variant.outputs.all { output ->
                    if (variant.buildType.name.equals('release')) {
                        outputFileName = "BeoneGateway3_V${defaultConfig.versionName}_${variant.productFlavors[0].getName()}.apk"
                    } else if (variant.buildType.name.equals('debug')) {
                        outputFileName = "BeoneGateway3_V${defaultConfig.versionName}_debug.apk"
                    }
                }
            }

这样使用了很长一段时间,这样打包出来的apk文件会被这段代码重新命名。一直以来,虽然不知道这段代码的具体语法,但是大概能揣摩每个变量的意思…也仅限于此。

摸索

后面稍微了解一下groovy语言,发现和java相当类似,那么又重新从语言的角度来看之前这段配置代码,于是改成了这样:

    applicationVariants.all { variant ->
        variant.outputs.all { output ->
            if (variant.buildType.name.equals('release')) {
                outputFileName = "SmartStreamGateway_V${defaultConfig.versionName}_${variant.getFlavorName()}.apk"
            } else if (variant.buildType.name.equals('debug')) {
                outputFileName = "SmartStreamGateway_V${defaultConfig.versionName}_${variant.getFlavorName()}_debug.apk"
            }
        }
    }

并且也知道其中的variant其实就当于fori循环中的i一样,相当于一个形参,而{…}这一段就是一个闭包。更重要的是,gradle本身就是一个框架,其中也包含着各种类各种方法,这里的applicationVariants.all来自于定义:

public interface DomainObjectCollection<T> extends Collection<T> {

    /**
     * Executes the given action against all objects in this collection, and any objects subsequently added to this
     * collection.
     *
     * @param action The action to be executed
     */
    void all(Action<? super T> action);

    /**
     * Executes the given closure against all objects in this collection, and any objects subsequently added to this collection. The object is passed to the closure as the closure
     * delegate. Alternatively, it is also passed as a parameter.
     *
     * @param action The action to be executed
     */
    void all(Closure action);
}

这是一个实打实的Java接口。

“Groovy编译器产生的字节码和Java编译器产生的字节码是完全一样的。这就等于说,Groovy能够完全使用各种Java API。” ----《Groovy入门经典》

有了这种认知,改配置代码其实就和改Java代码一样了。

常用到的一些方法在接口BaseVariant中:

public interface BaseVariant {

    @NonNull
    String getName();

    @NonNull
    String getDescription();

    @NonNull
    String getDirName();

    @NonNull
    String getFlavorName();

    @NonNull
    BuildType getBuildType();

    @NonNull
    ProductFlavor getMergedFlavor();

    @NonNull
    List<ProductFlavor> getProductFlavors();

    @NonNull
    List<SourceProvider> getSourceSets();

    @NonNull
    String getApplicationId();

    void buildConfigField(@NonNull String type, @NonNull String name, @NonNull String value);

    void resValue(@NonNull String type, @NonNull String name, @NonNull String value);
}

那么问题来了,现在我想以自己定义的一些值作为文件名,而且不能体现在ProductFlavor的名称中,因为这些值类似于"192.168.0.1",而这种命名不能用在这里。

在上面的方法中有个叫getDescription的函数,本来以为在实现类中应该会有相应的setDescription方法,但事实证明想多了…通过源码一路查找BaseVariantImpl–>BaseVariantData–>AndroidArtifactVariantData–>InstallableVariantData–>ApkVariantData:

public abstract class ApkVariantData extends InstallableVariantData {
    @Override
    @NonNull
    public String getDescription() {
        final GradleVariantConfiguration config = getVariantConfiguration();

        if (config.hasFlavors()) {
            StringBuilder sb = new StringBuilder(50);
            StringHelper.appendCapitalized(sb, config.getBuildType().getName());
            StringHelper.appendCapitalized(sb, config.getFlavorName());
            sb.append(" build");
            return sb.toString();
        } else {
            return StringHelper.capitalizeWithSuffix(config.getBuildType().getName(), " build");
        }
    }
}

发现这个方法是返回的“固定值”,类似于“buildType FlavorName build"这样的形式。于是死心。

还是得找找ProductFlavor类里有没有可以用来作为命名变量的东西,但与上面的ApkVariantData类似,许多值是返回的既定值,并不能自行定义,除了…类似buildConfigField这样的…

发现

回头看最开始使用多渠道时,使用productFlavors时的场景,其中使用buildConfigField来定义一些运行时的常量,以便在各个渠道时各自对应。

    productFlavors {
        jinxin_bcca {
            manifestPlaceholders = [CHANNEL_VALUE: "bcca"]
            buildConfigField "String", "BCCA_HOST", '"222.182.202.98"'
            buildConfigField "int","BCCA_PORT",'9529'
            buildConfigField "int","DEVICE_TYPE",'0x00000631'
        }
        jinxin_bcca_debug {
            manifestPlaceholders = [CHANNEL_VALUE: "bcca_debug"]
            buildConfigField "String", "BCCA_HOST", '"39.105.93.18"'
            buildConfigField "int","BCCA_PORT",'9529'
            buildConfigField "int","DEVICE_TYPE",'0x00000601'
            setVersionName("0.888")
        }
    }

首先找到ProductFlavor这个类里的方法,其继承关系如图:
productFlavor
在BaseConfigImpl中是明确可以拿到同buildConfigField定义的值的:

public abstract class BaseConfigImpl implements Serializable, BaseConfig {
    private final Map<String, ClassField> mBuildConfigFields = Maps.newTreeMap();
    
    @Override
    @NonNull
    public Map<String, ClassField> getBuildConfigFields() {
        return mBuildConfigFields;
    }
}

而buildConfigField其实也是一个方法,在BaseFlavor中:

public abstract class BaseFlavor extends DefaultProductFlavor implements CoreProductFlavor {

    public void buildConfigField(
            @NonNull String type, @NonNull String name, @NonNull String value) {
        ClassField alreadyPresent = getBuildConfigFields().get(name);
        if (alreadyPresent != null) {
            String flavorName = getName();
            if (BuilderConstants.MAIN.equals(flavorName)) {
                logger.info(
                        "DefaultConfig: buildConfigField '{}' value is being replaced: {} -> {}",
                        name,
                        alreadyPresent.getValue(),
                        value);
            } else {
                logger.info(
                        "ProductFlavor({}): buildConfigField '{}' "
                                + "value is being replaced: {} -> {}",
                        flavorName,
                        name,
                        alreadyPresent.getValue(),
                        value);
            }
        }
        addBuildConfigField(new ClassFieldImpl(type, name, value));
    }
}

那么理论上所有在这一系列定义的public方法,其实都可以在build.gradle中的productFlavors中实用,比如这样:

    productFlavors {
        jinxin_bcca_debug {
            manifestPlaceholders = [CHANNEL_VALUE: "bcca_debug"]
            buildConfigField "String", "BCCA_HOST", '"39.105.93.18"'
            buildConfigField "int","BCCA_PORT",'9529'
            buildConfigField "int","DEVICE_TYPE",'0x00000601'
            setVersionName("0.888")
        }
    }

因为DefaultProductFlavor中定义了此方法:

//DefaultProductFlavor.java
    @NonNull
    public ProductFlavor setVersionName(String versionName) {
        mVersionName = versionName;
        return this;
    }

最终可以使用下面的函数拿到设定的值也就是0.888:

${variant.getProductFlavors()[0].getVersionName()}

其他方法也是类似。

对BuildConfigField而言,理论上是可以这样操作的:

            buildConfigField "String", "CUSTOM", '"测试用"'//定义
            
            variant.getProductFlavors()[0].getBuildConfigFields().get("CUSTOM").getValue()//取值

但实际操作中在某种情况下会出现异常,编译器会认为get到的东西为null(哪怕实际编译后并不为null):

Cannot invoke method getValue() on null object
结果

所以经过权衡,干脆使用VersionNameSuffix:

    productFlavors {
        jinxin_bcca_debug {
            manifestPlaceholders = [CHANNEL_VALUE: "bcca_debug"]
            buildConfigField "String", "BCCA_HOST", '"39.105.93.18"'
            buildConfigField "int","BCCA_PORT",'9529'
            buildConfigField "int","DEVICE_TYPE",'0x00000601'
            setVersionNameSuffix("192.168.0.1")
        }
    }

只要不与variant.getVersionName()同时使用即可,因为setVersionNameSuffix会让variant.getVersionName()返回VersionNameSuffix(有点坑)。那么最终打包可以这么使用了:

    applicationVariants.all { variant ->
        variant.outputs.all { output ->
            if (variant.buildType.name.equals('release')) {
                outputFileName = "SmartStreamGateway_V${defaultConfig.versionName}_${variant.getFlavorName()}_${variant.getProductFlavors()[0].getVersionNameSuffix()}.apk"
            } else if (variant.buildType.name.equals('debug')) {
                outputFileName = "SmartStreamGateway_V${defaultConfig.versionName}_${variant.getFlavorName()}_${variant.getProductFlavors()[0].getVersionNameSuffix()}_debug.apk"
            }
        }
    }

最终输出的文件名(在debug状态下)是:

SmartStreamGateway_V0.60_jinxin_bcca_debug_192.168.0.1_debug.apk

最好以后能想到更好的办法,不然会因为强迫症发作而疯掉。

标签:String,name,variant,buildConfigField,gradle,debug,多渠道,打包,NonNull
来源: https://blog.csdn.net/ifmylove2011/article/details/101209123