前言

kotlin-android-extensions 插件是 Kotlin 官方提供的一个编译器插件，用于替换 findViewById 模板代码，降低开发成本

虽然 kotlin-android-extensions 现在已经过时了，但比起其他替换 findViewById 的方案，比如第三方的 ButterKnife 与官方现在推荐的 ViewBinding

kotlin-android-extensions 还是有着一个明显的优点的：极其简洁的 API，KAE 方案比起其他方案写起来更加简便，这是怎么实现的呢？我们一起来看下

原理浅析

当我们接入KAE后就可以通过以下方式直接获取 View

import kotlinx.android.synthetic.main.activity_main.*



class MainActivity : AppCompatActivity() {



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContentView(R.layout.activity_main)

        viewToShowText.text = "Hello"

    }

    

}

而它的原理也很简单，KAE插件将上面这段代码转换成了如下代码

public final class MainActivity extends AppCompatActivity {

   private HashMap _$_findViewCache;



   protected void onCreate(@Nullable Bundle savedInstanceState) {

      super.onCreate(savedInstanceState);

      this.setContentView(1300023);

      TextView var10000 = (TextView)this._$_findCachedViewById(id.textView);

      var10000.setText((CharSequence)"Hello");

   }



   public View _$_findCachedViewById(int var1) {

      if (this._$_findViewCache == null) {

         this._$_findViewCache = new HashMap();

      }

      View var2 = (View)this._$_findViewCache.get(var1);

      if (var2 == null) {

         var2 = this.findViewById(var1);

         this._$_findViewCache.put(var1, var2);

      }

      return var2;

   }



   public void _$_clearFindViewByIdCache() {

      if (this._$_findViewCache != null) {

         this._$_findViewCache.clear();

      }



   }   

}

可以看到，实际上 KAE 插件会帮我们生成一个 _$_findCachedViewById()函数，在这个函数中首先会尝试从一个 HashMap 中获取传入的资源 id 参数所对应的控件实例缓存，如果还没有缓存的话，就调用findViewById()函数来查找控件实例，并写入 HashMap 缓存当中。这样当下次再获取相同控件实例的话，就可以直接从 HashMap 缓存中获取了。

当然KAE也帮我们生成了_$_clearFindViewByIdCache()函数，不过在 Activity 中没有调用，在 Fragment 的 onDestroyView 方法中会被调用到

总体结构

在了解了KAE插件的简单原理后，我们一步一步来看一下它是怎么实现的，首先来看一下总体结构

KAE插件可以分为 Gradle 插件，编译器插件，IDE 插件三部分，如下图所示

我们今天只分析 Gradle 插件与编译器插件的源码，它们的具体结构如下：

1. AndroidExtensionsSubpluginIndicator是KAE插件的入口


2. AndroidSubplugin用于配置传递给编译器插件的参数


3. AndroidCommandLineProcessor用于接收编译器插件的参数


4. AndroidComponentRegistrar用于注册如图的各种Extension

源码分析

插件入口

当我们查看 kotlin-gradle-plugin 的源码，可以看到 kotlin-android-extensions.properties 文件，这就是插件的入口

implementation-class=org.jetbrains.kotlin.gradle.internal.AndroidExtensionsSubpluginIndicator

接下来我们看一下入口类做了什么工作

class AndroidExtensionsSubpluginIndicator @Inject internal constructor(private val registry: ToolingModelBuilderRegistry) :

    Plugin<Project> {

    override fun apply(project: Project) {

        project.extensions.create("androidExtensions", AndroidExtensionsExtension::class.java)

        addAndroidExtensionsRuntime(project)

        project.plugins.apply(AndroidSubplugin::class.java)

    }



    private fun addAndroidExtensionsRuntime(project: Project) {

        project.configurations.all { configuration ->

            val name = configuration.name

            if (name != "implementation") return@all

            configuration.dependencies.add(

                project.dependencies.create(

                    "org.jetbrains.kotlin:kotlin-android-extensions-runtime:$kotlinPluginVersion"

                )

            )

        }

    }

}



open class AndroidExtensionsExtension {

    open var isExperimental: Boolean = false



    open var features: Set<String> = AndroidExtensionsFeature.values().mapTo(mutableSetOf()) { it.featureName }



    open var defaultCacheImplementation: CacheImplementation = CacheImplementation.HASH_MAP

}

AndroidExtensionsSubpluginIndicator中主要做了这么几件事

1. 创建androidExtensions配置，可以看出其中可以配置是否开启实验特性，启用的feature(因为插件中包含views与parcelize两个功能)，viewId缓存的具体实现(是hashMap还是sparseArray)


2. 自动添加kotlin-android-extensions-runtime依赖，这样就不必在接入了插件之后，再手动添加依赖了，这种写法可以学习一下


3. 配置AndroidSubplugin插件，开始配置给编译器插件的传参

配置编译器插件传参

class AndroidSubplugin : KotlinCompilerPluginSupportPlugin {

    // 1. 是否开启编译器插件

    override fun isApplicable(kotlinCompilation: KotlinCompilation<*>): Boolean {

        if (kotlinCompilation !is KotlinJvmAndroidCompilation)

            return false

        // ...    



        return true

    }



    // 2. 传递给编译器插件的参数

    override fun applyToCompilation(

        kotlinCompilation: KotlinCompilation<*>

    ): Provider<List<SubpluginOption>> {

        //...



        val pluginOptions = arrayListOf<SubpluginOption>()

        pluginOptions += SubpluginOption("features",

                                         AndroidExtensionsFeature.parseFeatures(androidExtensionsExtension.features).joinToString(",") { it.featureName })



        fun addVariant(sourceSet: AndroidSourceSet) {

            val optionValue = lazy {

                sourceSet.name + ';' + sourceSet.res.srcDirs.joinToString(";") { it.absolutePath }

            }

            pluginOptions += CompositeSubpluginOption(

                "variant", optionValue, listOf(

                    SubpluginOption("sourceSetName", sourceSet.name),

                    //use the INTERNAL option kind since the resources are tracked as sources (see below)

                    FilesSubpluginOption("resDirs", project.files(Callable { sourceSet.res.srcDirs }))

                )

            )

            kotlinCompilation.compileKotlinTaskProvider.configure {

                it.androidLayoutResourceFiles.from(

                    sourceSet.res.sourceDirectoryTrees.layoutDirectories

                )

            }

        }



        addVariant(mainSourceSet)



        androidExtension.productFlavors.configureEach { flavor ->

            androidExtension.sourceSets.findByName(flavor.name)?.let {

                addVariant(it)

            }

        }



        return project.provider { wrapPluginOptions(pluginOptions, "configuration") }

    }



    // 3. 定义编译器插件的唯一 id，需要与后面编译器插件中定义的 pluginId 保持一致

    override fun getCompilerPluginId() = "org.jetbrains.kotlin.android"



    // 4. 定义编译器插件的 `Maven` 坐标信息，便于编译器下载它

    override fun getPluginArtifact(): SubpluginArtifact =

        JetBrainsSubpluginArtifact(artifactId = "kotlin-android-extensions")

}

主要也是重写以上4个函数，各自的功能在文中都有注释，其中主要需要注意applyToCompilation方法，我们传递了features，variant等参数给编译器插件

variant的主要作用是为不同 buildType，productFlavor目录的 layout 文件生成不同的包名

import kotlinx.android.synthetic.main.activity_main.*

import kotlinx.android.synthetic.debug.activity_debug.*

import kotlinx.android.synthetic.demo.activity_demo.*

比如如上代码，activity_debug文件放在debug目录下，而activiyt_demo文件则放在demo这个flavor目录下，这种情况下它们的包名是不同的

编译器插件接收参数

class AndroidCommandLineProcessor : CommandLineProcessor {

    override val pluginId: String = ANDROID_COMPILER_PLUGIN_ID



    override val pluginOptions: Collection<AbstractCliOption>

            = listOf(VARIANT_OPTION, PACKAGE_OPTION, EXPERIMENTAL_OPTION, DEFAULT_CACHE_IMPL_OPTION, CONFIGURATION, FEATURES_OPTION)



    override fun processOption(option: AbstractCliOption, value: String, configuration: CompilerConfiguration) {

        when (option) {

            VARIANT_OPTION -> configuration.appendList(AndroidConfigurationKeys.VARIANT, value)

            PACKAGE_OPTION -> configuration.put(AndroidConfigurationKeys.PACKAGE, value)

            EXPERIMENTAL_OPTION -> configuration.put(AndroidConfigurationKeys.EXPERIMENTAL, value)

            DEFAULT_CACHE_IMPL_OPTION -> configuration.put(AndroidConfigurationKeys.DEFAULT_CACHE_IMPL, value)           

            else -> throw CliOptionProcessingException("Unknown option: ${option.optionName}")

        }

    }

}

这段代码很简单，主要是解析variant，包名，是否开启试验特性，缓存实现方式这几个参数

注册各种Extension

接下来到了编译器插件的核心部分，通过注册各种Extension的方式修改编译器的产物

class AndroidComponentRegistrar : ComponentRegistrar {

    companion object {

        fun registerViewExtensions(configuration: CompilerConfiguration, isExperimental: Boolean, project: MockProject) {

            

            ExpressionCodegenExtension.registerExtension(project,

                    CliAndroidExtensionsExpressionCodegenExtension(isExperimental, globalCacheImpl))



            IrGenerationExtension.registerExtension(project,

                    CliAndroidIrExtension(isExperimental, globalCacheImpl))



            StorageComponentContainerContributor.registerExtension(project,

                    AndroidExtensionPropertiesComponentContainerContributor())



            ClassBuilderInterceptorExtension.registerExtension(project,

                    CliAndroidOnDestroyClassBuilderInterceptorExtension(globalCacheImpl))



            PackageFragmentProviderExtension.registerExtension(project,

                    CliAndroidPackageFragmentProviderExtension(isExperimental))

        }

    }



    override fun registerProjectComponents(project: MockProject, configuration: CompilerConfiguration) {

        if (AndroidExtensionsFeature.VIEWS in features) {

            registerViewExtensions(configuration, isExperimental, project)

        }

    }

}

可以看出，主要就是在开启了AndroidExtensionsFeature.VIEWS特性时，注册了5个Extension，接下来我们来看下这5个Extension都做了什么

IrGenerationExtension

IrGenerationExtension是KAE插件的核心部分，在生成 IR 时回调，我们可以在这个时候修改与添加 IR，KAE插件生成的_findCachedViewById方法都是在这个时候生成的，具体实现如下：

private class AndroidIrTransformer(val extension: AndroidIrExtension, val pluginContext: IrPluginContext) :

    IrElementTransformerVoidWithContext() {



    override fun visitClassNew(declaration: IrClass): IrStatement {

        if ((containerOptions.cache ?: extension.getGlobalCacheImpl(declaration)).hasCache) {

            val cacheField = declaration.getCacheField() 

            declaration.declarations += cacheField // 添加_$_findViewCache属性

            declaration.declarations += declaration.getClearCacheFun() // 添加_$_clearFindViewByIdCache方法

            declaration.declarations += declaration.getCachedFindViewByIdFun() // 添加_$_findCachedViewById方法

        }

        return super.visitClassNew(declaration)

    }



    override fun visitCall(expression: IrCall): IrExpression {

        val result = if (expression.type.classifierOrNull?.isFragment == true) {

            // this.get[Support]FragmentManager().findFragmentById(R$id.<name>)

            createMethod(fragmentManager.child("findFragmentById"), createClass(fragment).defaultType.makeNullable()) {

                addValueParameter("id", pluginContext.irBuiltIns.intType)

            }.callWithRanges(expression).apply {

                // ...

            }

        } else if (containerHasCache) {

            // this._$_findCachedViewById(R$id.<name>)

            receiverClass.owner.getCachedFindViewByIdFun().callWithRanges(expression).apply {

                dispatchReceiver = receiver

                putValueArgument(0, resourceId)

            }

        } else {

        	// this.findViewById(R$id.<name>)

            irBuilder(currentScope!!.scope.scopeOwnerSymbol, expression).irFindViewById(receiver, resourceId, containerType)

        }

        return with(expression) { IrTypeOperatorCallImpl(startOffset, endOffset, type, IrTypeOperator.CAST, type, result) }

    }

}

如上所示，主要做了两件事：

1. 在visitClassNew方法中给对应的类(比如 Activity 或者 Fragment )添加了_$_findViewCache属性，以及_$_clearFindViewByIdCache与_$_findCachedViewById方法


2. 在visitCall方法中，将viewId替换为相应的表达式，比如this._$_findCachedViewById(R$id.<name>)或者this.findViewById(R$id.<name>)

可以看出，其实KAE插件的大部分功能都是通过IrGenerationExtension实现的

ExpressionCodegenExtension

ExpressionCodegenExtension的作用其实与IrGenerationExtension基本一致，都是用来生成_$_clearFindViewByIdCache等代码的

主要区别在于，IrGenerationExtension在使用IR后端时回调，生成的是IR。

而ExpressionCodegenExtension在使用 JVM 非IR后端时回调，生成的是字节码

在 Kotlin 1.5 之后，JVM 后端已经默认开启 IR，可以认为这两个 Extension 就是新老版本的两种实现

StorageComponentContainerContributor

StorageComponentContainerContributor的主要作用是检查调用是否正确

class AndroidExtensionPropertiesCallChecker : CallChecker {

    override fun check(resolvedCall: ResolvedCall<*>, reportOn: PsiElement, context: CallCheckerContext) {

        // ...

        with(context.trace) {

            checkUnresolvedWidgetType(reportOn, androidSyntheticProperty)

            checkDeprecated(reportOn, containingPackage)

            checkPartiallyDefinedResource(resolvedCall, androidSyntheticProperty, context)

        }

    }

}    

如上，主要做了是否有无法解析的返回类型等检查

ClassBuilderInterceptorExtension

ClassBuilderInterceptorExtension的主要作用是在onDestroyView方法中调用_$_clearFindViewByIdCache方法，清除KAE缓存

private class AndroidOnDestroyCollectorClassBuilder(

    private val delegate: ClassBuilder,

    private val hasCache: Boolean

) : DelegatingClassBuilder() {      

    override fun newMethod(

        origin: JvmDeclarationOrigin,

        access: Int,

        name: String,

        desc: String,

        signature: String?,

        exceptions: Array<out String>?

    ): MethodVisitor {

        val mv = super.newMethod(origin, access, name, desc, signature, exceptions)

        if (!hasCache || name != ON_DESTROY_METHOD_NAME || desc != "()V") return mv

        hasOnDestroy = true

        return object : MethodVisitor(Opcodes.API_VERSION, mv) {

            override fun visitInsn(opcode: Int) {

                if (opcode == Opcodes.RETURN) {

                    visitVarInsn(Opcodes.ALOAD, 0)

                    visitMethodInsn(Opcodes.INVOKEVIRTUAL, currentClassName, CLEAR_CACHE_METHOD_NAME, "()V", false)

                }

                super.visitInsn(opcode)

            }

        }

    }

}

可以看出，只有在 Fragment 的onDestroyView方法中添加了 clear 方法，这是因为 Fragment 的生命周期与其根 View 生命周期可能并不一致，而 Activity 的 onDestroy 中是没有也没必要添加的

PackageFragmentProviderExtension

PackageFragmentProviderExtension的主要作用是注册各种包名，以及该包名下的各种提示

import kotlinx.android.synthetic.main.activity_main.*

import kotlinx.android.synthetic.debug.activity_debug.*

import kotlinx.android.synthetic.demo.activity_demo.*

比如我们在 IDE 中引入上面的代码，就可以引入 xml 文件中定义的各个 id 了，这就是通过这个Extension实现的

总结

本文主要从原理浅析，总体架构，源码分析等角度分析了 kotlin-android-extensions 插件到底是怎么实现的

相比其它方案，KAE使用起来可以说是非常简洁优雅了，可以看出 Kotlin 编译器插件真的可以打造出极简的 API，因此虽然KAE已经过时了，但还是有必要学习一下的

如果本文对你有所帮助，欢迎点赞收藏~

俗话说，无规矩不成方圆，同样的放在代码里也是十分的贴切，所谓在代码里的规矩，指的就是规范，在一定规范约束下的项目，无论是参与开发还是后期维护，都是非常的直观与便捷，不能说赏心悦目，也可以用健壮可维护来表示；毕竟协同开发的项目，每个人都有自己的一套开发标准，你没有一套规范，或者是规范没有落地执行，想想，长此以往，会发生什么？代码堆积如山？维护成本翻倍增加？新人接手困难？等等，所谓的问题会扑面而来。

正所谓规范是一个项目的基石，也是衡量一个项目，是否健壮，稳定，可维护的标准，可谓是相当重要的。我相信，大部分的公司都有自己的一套规范标准，我也相信，很多可能就是一个摆设，毕竟人员的众多，无法做到一一的约束，如果采取人工的检查，无形当中就会投入大量的时间和人力成本，基于此，所谓的规范，也很难执行下去。

介于人工和时间的投入，我在以往的研究与探索中，开发出了一个可视化的代码检查工具，之前进行过分享，《一个便捷操作的Android可视化规范检查》，想了解的老铁可以看一看，本篇文章不做过多介绍,当时只介绍了工具的使用，没有介绍相关功能的开发过程，后续，有时间了，我会整理开源出来，一直忙于开发，老铁们，多谅解。这个可视化的检查工具，虽然大大提高了检查效率，也节省了人力和时间，但有一个潜在的弊端，就是，只能检查提交之后的代码是否符合规范，对于提交之前没有进行检查，也就说，在提交之前，规范也好，不规范也罢，都能提交上来，用工具检查后，进行修改，更改不规范的地方后然后再提交，只能采取这样的一个模式检查。

这样的一个模式，比较符合，最后的代码检查，适用于项目负责人，开发Leader，对组员提交上来的代码进行规范的审阅，其实并不适用于开发人员，不适用不代表着不可用，只不过相对流程上稍微复杂了几步；应对这样的一个因素，如何适用于开发人员，方便在提交代码之前进行规范检查，便整体提上了研发日程，经过几日的研究与编写，一个简单便捷的Android端Git提交专有hook，便应运而生了。

说它简单，是因为不需要编写任何的代码逻辑，只需要寥寥几步命令，便安装完毕，通过配置文件，便可灵活定制属于自己的检查范围。

为了更好的阐述功能及讲述实现过程，便于大家定制自己的开发规范，再加上篇幅的约束，我总结了四篇文章来进行系统的梳理，还请大家，保持关注，今天这篇，主要讲述最终的开发成果，也就是规范工具如何使用，规范这个东西，其实大差不差，大家完全可以使用我自己已经开发好的这套。

这个工具的开发，利用的是git 钩子(hook)，当然也是借助的是Node.js来实现的相关功能，下篇文章会详细介绍，我们先来安装程序，来目睹一下实际的效果，安装程序，只需要执行几步命令即可，无需代码介入，在实际的开发中需要开发人员，分别进行安装。

安装流程

1、安装 Node.js，如果已经安装，可直接第2步：

Node.js中允许使用 JavaScript 开发服务端以及命令行程序，我们可以去官网nodejs.org
下载最新版本的安装程序，然后一步一步进行安装就可以了，这个没什么好说的，都是开发人员。

2、安装android_standard

android_standard是最终的工具，里面包含着拦截代码判断的各种逻辑 ， 在项目根目录下执行如下命令：

npm install android_standard --save-dev

执行完命令后，你会发现，你的项目下已经多了一个目录，还有两个json文件，如下图所示：

node_modules，用来存放下载安装的包文件夹，里面有我们要使用到的功能，其实和Android中lib目录很类似，都是一些提供功能的库。

package.json文件，是配置文件，比如应用的名字，作者，介绍，还有相关的依赖等，和Android中的build.gradle文件类似。

3、创建git配置文件，执行如下命令

node node_modules/android_standard/gitCommitConfig

命令执行成功会返回如下信息：

此命令执行完后，会在项目根目录下创建gitCommitConfig文件，这个文件很重要，是我们执行相关命令的配置文件，内容如下，大家可以根据自己实际项目需要进行更改。

项目下生成gitCommitConfig.android文件，.android是我自己定义的，至于什么格式，等你自己开发的时候，完全可以自定义，是个文件就行。

打开后，文件内容如下，此文件是比较重要的，后续所有的规范检查，都要根据这个文件里的参数来执行，大家在使用的时候，就可以通过这个文件来操作具体的规范检查。

4、更改执行文件，执行如下命令

执行文件，就是需要在上边生成的package.json文件，添加运行程序，使其在git提交时进行hook拦截。

node node_modules/android_standard/package

5、添加git过滤

因为执行完上述命令后，会产生几个文件，而这几个文件是不需要我们上传到远程仓库的，所以我们需要在.gitignore文件里添加忽略，直接复制即可。

/node_modules

package.json

package-lock.json

gitCommitConfig.android

6、后续如果有更新，可命令进行操作：

注：此命令在更新时执行

npm update android_standard --save-dev

7、删除操作

注：后续不想使用了，便可执行如下命令：

npm uninstall android_standard --save-dev

具体使用

通过上述的安装流程，短短几个命令，我们的规范检查便安装完毕，后续只需要通过gitCommitConfig.android文件，来动态的更改参数即可，是不是非常的方便，接下来，我们来实际的操作一番。

关于配置文件的相关参数，也都有注释，一看便知，这里简单针对最后的参数，做一个说明，也就是gitCommand这个参数，true为工具，false为命令方式；true也好，false也好，在主要的功能验证上，没有区别，唯一的区别就是，命令行的方式提交，会有颜色区分，后面有效果。

我们先来看下命令行下的执行效果，当配置文件开关gitCommitSwitch已开，并且gitCommand为false，其他的配置参数，大家可以根据需要进行改动，在代码提交的时候如下效果：

在Android studio中提交代码执行效果

TortoiseGit提交代码执行效果：

目前呢，针对Android端的规范检查，无论是java还是Kotlin，还是资源文件，都做了一定的适配，经过多方测试，一切正常，如果大家的公司也需要这样的一个hook工具，欢迎使用，也欢迎继续关注接下来的相关实现逻辑文章。

好了各位老铁，这篇文章先到这里，下篇文章会讲述，具体的实现过程，哦，忘记了，上篇结尾的遗留组件化还未更新，那就更新完组件化，接着更新这个，哈哈，敬请期待！

引言

对于 Drawable ，一直没有专门记录，日常开发中，也是属于忘记了再搜一下。主要是使用程度有限(仅仅只是shape或者 layer 等冰山一角)，另一方面是 Android 对其的高度抽象，导致从没去关注过细节，从而对于 Drawable 没有真正的理解其设计与存在的意义。

反而是偶尔一次发现其他同学的运用，才明白了自己的狭隘，为此，怀着无比惭愧的心情，写下此篇，与君共勉。

鉴于此，本篇将完整的描述开发中常见各种 Drawable ,以及在工程化项目的背景下，如何更好的运用。总体难度较低，不涉及源码，适合轻松阅读。

来者何人

2022的今天,随便问一个Android开发，Drawable 是什么？

比如我。他(她)肯定会告诉你(鄙视的眼神)，你si不si傻，Drawable 都不知道，Drawable,Drawble，Drawable不就是...😐

不就是经常用来设置的图像吗？🫣(不确定语气,似乎说的不完整)

上述说的有错吗，也没错。嗯，但总觉得差点什么,过于简单？细心的你肯定会觉得没这么简单。

那到底什么是Drawable?

Drawable 表示的是一种可以在Canvas上进行绘制的抽象概念。人话就是 就是指可在屏幕上绘制的图形。

就这？就这？就这？

这说了个啥，水水水，一天就知道水文章？🫵🏼

嗯🧐，在开发角度来看，Drawable 是一个抽象的类，用来表示可以绘制在屏幕上绘制的图形。我们常见有很多种 Drawable ,比如Bitmapxx,Colorxxx,Shapexxx，它们一般都用于表示图像，但严格上来说，又不全是图像。

后半句用人话怎么理解呢？

对于普通的图形或图片，我们肯定没法更改，因为其已经固定了(资源文件)。

但是对于 Drawable，虽然某种程度上也是图形(矢量资源)，但其具备处理或绘制具体显示逻辑的方式。也就是说，这是一个支持修改的图形，比如我们可以把一张图塞给了 BitmapDrawable ,但依然可以做二次调整，比如拉伸一下，改一下位置，给这张图上再添加点别的什么东西。或者也可以理解为这是一个简化版的View，只不过它更简易，目的纯粹。其无法像 View 一样接收事件或者和用户交互，其更像一个绘制板，指哪打哪，仅作为显示使用。

当然除了简单的绘图，Drawable 还提供了很多通用api,使得我们可以与正在绘制的内容进行交互，从而更加完善。

相应的，Drawable 内部其实也有自己的宽高、通过 intrinsicWidth、intrinsicHeight 即可获取。需要注意的是：

• Drawable 的宽高不等于其展示时的大小，我们可以认为 Drawable 不存在大小的概念，因为其用于View背景时，其会被拉伸至View的同等大小。


• 也并不是所有的 Drawable 都有内部宽高,比如，由一个图片所形成的 Drawable ，其相应的宽高也就是图片的宽高,而由颜色所形成的Drawable ,相应的内部也不存在宽高。

Drawable的种类

如下所示，Drawable有如下类型：

好家伙，这也太多了吧，而且后续还会越来越多。

当然这么多，我们一般其实根本不可能全部用上，常见的有如下几种类别：

无状态

• 
  

  BitmapDrawable

  
  

  <<bitmap

  
  

  用于将图片转为BitmapDrawable;

  
  


• 
  

  ShapeDrawable

  
  

  <<shape

  
  

  通过颜色来构造Drawable;

  
  


• 
  

  VectorDrawable

  
  

  <<vector

  
  

  矢量图，Android5.0及以上支持。便于在缩放过程中保证显示质量，以及一个矢量图支持多个屏幕，减少apk大小;

  
  


• 
  

  TransitionDrawable

  
  

  <<transition

  
  

  用于实现Drawable间的淡入淡出效果;

  
  


• 
  

  InsetDrawable

  
  

  <<inset

  
  

  用于将其他Drawable内嵌到自己当中,并可以在四周留出一定的间距。当一个View希望自己的背景比实际的区域小时，可以采用其来实现。

  
  

有状态

• 
  

  StateListDrawable

  
  

  <<selector

  
  

  用于有状态交互时的View设置，比如 按下时 的背景，松开时 的背景，有焦点时的背景灯；

  
  


• 
  

  LevelListDrawable

  
  

  <<level-list

  
  

  根据等级(level)来切换不同的 Drawble。在View中可以通过设置 setImageLevel 更改不同的Drawable ;

  
  


• 
  

  ScaleDrawable

  
  

  <<scale

  
  

  根据不同的等级(level)指定 Drawable 缩放到一定比例;

  
  


• 
  

  ClipDrwable

  
  

  <<clip

  
  

  根据当前等级(level)来裁剪 Drawable ;

  
  

常见的Drawable

BitmapDrawable

常见使用场景

用于表示一张图片，用于设置 bitmap 在 BitmapDrawable 区域内的绘制方式时使用，如水平平铺或者竖直平铺以及扩展铺满。

xml中的标签：

常见的属性有如下：

• 
  

  android:src

  
  

  资源id

  
  


• 
  

  android:antialias

  
  

  开启图片抗锯齿，用于让图片变得平滑，同时抗锯齿也会一定程度上降低图片清晰度，不过幅度几乎无法感知；

  
  


• 
  

  android:dither

  
  

  开启抖动效果，为低像素机型做的自动降级显示，保证显示效果。比如当前图片彩色模式为ARGB8888,而设备屏幕色彩模式为RGB555，此时开启抖动就可以避免图片显示失真；

  
  


• 
  

  android:filter

  
  

  过滤效果。在图片尺寸被拉伸或者压缩时，有助于保持显示效果；

  
  


• 
  

  android:gravity

  
  

  当前图片小于容器尺寸时，此选项便于对图片进行定位,当titleMode开启时，此属性将失效；

  
  


• 
  

  android:mipMap

  
  

  纹理映射开关，主要是为了应对图片大小缩放处理时，Android可以通过纹理映射技术提前按缩小的层级生成图片预存储在内存中，以此来提高速度与图片质量。默认情况下，mipmap文件夹里的默认开启此开关，drawable默认关闭。但需要注意，此开关只能建议系统开启此功能，至于最终是否真正开启，取决于系统。

  
  


• 
  

  android:tileMode

  
  

  用于设置图片的平铺模式，有以下几个值：[disabled、clamp、repeat、mirror]

  
  
  
  
  • disabled (默认值) 关闭平铺模式
  
  
  • clamp 图片四周的像素会扩展到周围区域
  
  
  • repeat 水平和竖直方向上的平铺效果
  
  
  • mirror 在水平和竖直方向的的镜面投影效果
  
  
  
  

示例代码：

val bitmap = BitmapFactory.decodeResource(resources, R.drawable.ic_doge)

val drawable = BitmapDrawable(bitmap).apply {

    setTileModeXY(Shader.TileMode.CLAMP, Shader.TileMode.CLAMP)

    isFilterBitmap = true

    gravity = Gravity.CENTER

    setMipMap(true)

    setDither(true)

}

ivDrawable.background = drawable

<?xml version="1.0" encoding="utf-8"?>

<bitmap xmlns:android="http://schemas.android.com/apk/res/android"

    android:dither="true"

    android:filter="true"

    android:gravity="center"

    android:mipMap="true"

    android:src="@drawable/test"

    android:tileMode="repeat" />

ShapeDrawable

常见使用场景

通过颜色来构造图形，作为背景描边或者背景色渐变时使用，可以说是最常见的一种 Drawable。

xml中的标签：

常见的属性如下：

• 
  

  shape

  
  

  表示图形的形状，如下四个选项：rectangle(矩形)、oval(椭圆)、line(横线)、ring(圆环)

  
  


• 
  

  corners

  
  

  表示shape的四个角的角度，只适用于矩形shape。

  
  
  
  
  • android:radius 为四个角设置相同的角度
  
  
  • android:topLeftRadius 设置左上角角度
  
  
  • android:bottomLeftRadius 设置左下角角度
  
  
  • android:bottomRightRadius 设定右下角的角度
  
  
  
  


• 
  

  gradient

  
  

  用于表示渐变效果，与 标签互斥(其表示纯色填充)

  
  
  
  
  • android:angle 渐变的角度，默认为0,其值必须为45的倍数, 0表示从左向右，90表示从下到上
  
  
  • android:centerX 渐变中心点的横坐标
  
  
  • android:centerY 渐变中心点纵坐标
  
  
  • android:startColor 渐变的起始色
  
  
  • android:centerColor 渐变的中间点
  
  
  • android:endColor 渐变的结束色
  
  
  • android:gradientRadius 渐变半径,仅当android:type=“radial”时有效
  
  
  • android:useLevel 是否使用等级区分，在 StateListDrawable 时有效，默认 false
  
  
  • android:type 渐变类型，linear(线性渐变)、radial(径向渐变)、sweep
  
  
  
  


• 
  

  solid 表示纯色填充

  
  


• 
  

  stroke 用于设置描边

  
  
  
  
  • android:width 描边宽度
  
  
  • android:color 描边颜色
  
  
  • android:dashWidth 描边虚线时的宽度
  
  
  • android:dashGap 描边虚线时的间隔
  
  
  
  

  

  
  


• 
  

  padding

  
  

  用于表示空白，其代表了在View中使用时的空白。但其在shape中并没有什么作用，可以在 layer-list 中进行使用。

  
  


• 
  

  size

  
  

  用于表示 shape 的 固有大小 ，但其不代表shape最终显示的大小。因为对于shape来说，其没有宽/高的概念，因为其最终被设置到View上作为背景时,其会被自动拉伸或缩放。但作为drawable,它拥有着固有宽/高,即通过 getIntrinsicWidth，getIntrinsicHeight 获取。对于某些Drawable而言，比如BitMapDrawable时，其宽高就是图片大小；而对于shape时，其就不存在大小，默认为-1。当然你也可以通过 size 设置大小，但其最终代表的是shape的固有宽高，作为背景时其并不是最终显示时的宽高。

  
  

示例如下：

LayerDrawable

表示一种层次化的集合 drawable ,一般常见于需要多个 Drawable 叠加 摆放效果时使用。

一个 layer-list 中可以包含多个 item ,每个item表示一个 Drawable ,其常用的属性 android:top,left,right,bottom 。相当于相对View的 上下左右 偏移量，单位为像素。此外也可以通过 Drawable 引用一个已有的 Drwable 资源。

xml中的标签：

示例如下:

StateListDrawable

用于为不同的 View状态 引用不同的 Drawable ,比如在View 按下 时，View 禁用 时等。

xml中的标签：

常用的属性如下：

• 
  

  constantSize

  
  

  表示其固有大小是否随着状态而改变。

  
  

  因为每次切换状态时，都会伴随着 Drawable 的改变，如果此时不是用于背景，则如果 Drawable 的固有大小不一致，则会导致StateListDrawable 的大小发生变化。如果此值为 true ,则表示当前 StateDrawable 的固有大小是当前其内部所有 Drawable 中最大值。反之，则根据状态决定;

  
  


• 
  

  android:dither

  
  

  是否开启抖动效果，用于在低质量屏幕上获得较好的显示效果;

  
  


• 
  

  variablePadding

  
  

  表示padding是否随着状态而改变，true表示跟随状态而决定，取决于当前显示的drawable,false则选取drawable集合中padding最大值。

  
  

示例如下：

LevelListDrawable

用于根据不同的等级表示一个 Drawable 集合。

默认等级范围为0,最小为0,最大为10000，可以在View中使用 Drawable 从而设置相应的 level 切换不同的 Drawable。如果这个drawable被用于ImageView 的 前景Drawable,还可以通过 ImageView.setImageViewLevel 来切换。

xml中的标签：

示例代码如下：

在代码中即可通过 setLevel切换。

 view.background.level = 10

 view.background.level = 200

TransitaionDrawable

用于实现两个 Drawable 之间的淡入淡出效果。

xml中的标签：

示例如下：

InsetDrawable

用于将其他 Drawable 内嵌到自己当中，并可以在四周留出一定的间距。比如当某个 View 希望自己的背景比自己的实际区域小时，可以采用这个 Drawable ,当然采用 LayerDrawable 也可以实现。

xml中的标签：

其属性分别如下：

• android:inset 表示四边内凹大小


• android:insetTop 表示顶部内凹大小


• android:insetLeft 表示左边内凹大小


• android:insetBottom 表示底部内凹大小


• android:insetRight 表示右边内凹大小

ScaleDrawable

用于根据等级(level)将指定的 Drawable 缩放到一定比例。

xml中的标签：

相应的属性如下所示：

• 
  

  android:scaleGravity

  
  

  类似于与android:gravity

  
  


• 
  

  android:scaleWidth

  
  

  指定宽度的缩放比例(相对于原drawable缩放了多少)

  
  


• 
  

  android:scaleHeight

  
  

  指定高度的缩放比例(相对于原drawable缩放了多少)

  
  


• 
  

  android:level(minSdk>=24)

  
  

  指定缩放等级,默认为0,即最小,最高10000,此值越大,最终显示的drawable越大

  
  

需要注意的是，当level为0时，其不会显示，所以我们使用ScaleDrawable时，需要在代码中，将 drawable.level 调为1。

示例如下：

<?xml version="1.0" encoding="utf-8"?>

<scale xmlns:android="http://schemas.android.com/apk/res/android"

    android:drawable="@drawable/level2_drawable"

    android:level="1"

    android:scaleWidth="70%"

    android:scaleHeight="70%"

    android:scaleGravity="center" />

ClipDrawable

用于根据当前等级(level)来裁剪另一个 Drawable。

xml中的标签：

具体属性如下：

• 
  

  android:drawable

  
  

  需要裁剪的drawable

  
  


• 
  

  android:clipOrientation

  
  

  裁剪方向,有水平(horizontal)、竖直(vertical) 两种

  
  


• 
  

  android:level(minSdk>=24)

  
  

  设置等级，为0时表示完全裁剪(即隐藏)，值越大，裁剪的越小。最大值10000(即不裁剪,原图)。

  
  


• 
  

  android:gravity

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

  参数	含义
  top	内部drawable位于容器顶部，不改变大小。ps: 竖直裁剪时，则从底部开始裁剪。
  bottom	内部drawable位于容器底部，不改变大小。ps: 竖直裁剪时，则从顶部开始裁剪。
  left(默认值)	内部drawable位于容器底部，不改变大小。ps: 水平裁剪时，则从顶部开始裁剪。
  right	内部drawable位于容器右边，不改变大小。ps: 水平裁剪时，从右边开始裁剪。
  start	同left
  end	同right
  center	使内部drawable在容器中居中，不改变大小。 ps:竖直裁剪时，从上下同时开始裁剪；水平裁剪时，从左右同时开始。
  center_horizontal	内部的drawable在容器中水平居中，不改变大小。 ps:水平裁剪时，从左右两边同时开始裁剪。
  center_vertical	内部的drawable在容器中垂直居中，不改变大小。 ps:竖直裁剪时，从上下两边同时开始裁剪。
  fill	使内部drawable填充满容器。 ps:仅当level为0(0表示ClipDrawable被完全裁剪，即不可见)时,才具有裁剪行为。
  fill_horizontal	使内部drawable在水平方向填充容器。 ps:如果水平裁剪，仅当level为0时，才具有裁剪行为。
  fill_vertical	使内部drawable在竖直方向填充容器。 ps:如果垂直裁剪，仅当level为0时，才具有裁剪行为。
  clip_horizontal	竖直方向裁剪。
  clip_vertical	竖直方向裁剪。

  
  

示例如下：

自定义Drawable

通常情况下，我们往往用不到自定义 Drawable ,主要源于Android已经提供了很多通常会用到的功能，不过了解自定义 Drawable 在某些场景下可以非常便于我们开发体验。

自定义 Drawable 也很简单，我们只需要继承 Drawable 即可，从而实现：

• 
  

  draw()

  
  

  实现自定义的绘制。

  
  

  如果要获取当前 Drawable 绘制的边界大小，可以通过 getBounds() 获取；

  
  

  如果需要获取当前 Drawable 的中心点，也可以通过 getBounds().exactCenterX() ,或者 getBounds().centerX() ,区别在于前者用于获取精确位置；

  
  


• 
  

  setAlpha()

  
  

  设置透明度；

  
  


• 
  

  setColorFilter()

  
  

  设置滤镜效果；

  
  


• 
  

  getOpacity()

  
  

  返回当前 Drawable 的透明度；

  
  

比如画一个类似的 ProgressBar ,因为其是一个 Drawable ,所以可以用作任意的 View。

class CustomCircleProgressDrawable : Drawable(), Animatable {



    private val paint = Paint(Paint.ANTI_ALIAS_FLAG)

    private val rectF = RectF()

    private var progress = 0F

    private val valueAnimator by lazy(LazyThreadSafetyMode.NONE) {

        ValueAnimator.ofFloat(0f, 1f).apply {

            duration = 2000

            repeatCount = Animation.INFINITE

            interpolator = LinearInterpolator()

            addUpdateListener {

                progress = it.animatedValue as Float

                invalidateSelf()

            }

        }

    }



    init {

        paint.style = Paint.Style.STROKE

        paint.strokeWidth = 10f

        paint.strokeCap = Paint.Cap.ROUND

        paint.color = Color.GRAY

        start()

    }



    override fun draw(canvas: Canvas) {

        var min = (min(bounds.bottom, bounds.right) / 2).toFloat()

        paint.strokeWidth = min / 10

        min -= paint.strokeWidth * 3

        val centerX = bounds.exactCenterX()

        val centerY = bounds.exactCenterY()

        rectF.left = centerX - min

        rectF.right = centerX + min

        rectF.top = centerY - min

        rectF.bottom = centerY + min

        paint.color = Color.GRAY

        canvas.drawArc(rectF, -90f, 360f, false, paint)

        paint.color = Color.GREEN

        canvas.rotate(360F * progress, centerX, centerY)

        canvas.drawArc(rectF, -90F, 30F + 330F * progress, false, paint)

    }



    override fun setAlpha(alpha: Int) {

        paint.alpha = alpha

        invalidateSelf()

    }



    override fun setColorFilter(colorFilter: ColorFilter?) {

        paint.colorFilter = colorFilter

        invalidateSelf()

    }



    override fun getOpacity(): Int {

        return PixelFormat.TRANSLUCENT

    }



    override fun start() {

        if (valueAnimator.isRunning) return

        valueAnimator.start()

    }



    override fun stop() {

        if (valueAnimator.isRunning) valueAnimator.cancel()

    }



    override fun isRunning(): Boolean {

        return valueAnimator.isRunning

    }

}

原理也很简单，我们实现了 onDraw 方法，在其中利用 canvas 绘制了两个圆环,其中前者是作为背景，后者不断地利用属性动画进行变化，并且不断旋转 canvas ，从而实现类似进度条的效果。

效果如下：

实践推荐

比如我们现在有这样一个 View ,需要在左上角展示一个文字,背景是张图片，另外还有一个从顶部到下的半透明渐变阴影。

如下图所示：

一般情况下，我们肯定会不假思索的写出如下代码。

上述写法没有问题，但其并不是所有场景的最推荐方式。比如这种样式此时需要在 RecyclerView 中展示呢？

所以，此时就可以利用 Drawable 简化我们的 View 层级，改造思路如下：

如上所示，相对于最开始，我们将布局层级由 3 层降低为了 1 层,对于性能的提升也将指数级上升。

现在有同学可能要问了，你的这个 View 很简单，自定义一个 Drawable 还好说，那 View 很复杂呢？难不成我真要纯纯自定义吗？

要回答这个问题，其实很简单，我们要明确 Drawable 的意义，其只是一个可绘制的图像 。过于复杂的View,我们可以将其拆分为多个层级，然后对于其中纯展示的View,使用 Drawable 降低其复杂度。

从某个角度来说，Drawable也可以是我们自定义View的好帮手。

总结

合理利用 Drawable 会很大程度提高我们的使用体验。相应的，对于布局优化，Drawable 也是一大利器。问题回到文章最开始，如果现在再问你。Drawable 到底是什么? 如何自定义一个 Drawable ? 如何利用其做一些骚操作？我想，这都不是问题。

参考

动画定义

早期的动画片是利用大量图片进行快速切换从而达到一种看似连续的动画效果，这就是最早期的帧动画，利用人的视觉延迟产生的一种连续的效果，其实现在的动画也是这个原理，在同一时间屏幕进行多次有规律的渲染次数，渲染次数越多，动画就越流畅，也就是我们平常说的屏幕刷新率。

本篇文章主旨让大家在使用Flutter动画的过程中游刃有余，不对具体源码进行解析。

• 动画关键属性：动画时长、动画轨迹。

动画其实就是对象在规定的时间内进行的特定规则运动的表现。所以我们需要关心的核心属性就是动画时长和动画轨迹。

理解了动画实现的原理，所谓万变不离其宗，Flutter动画亦是如此，下面首先看下Flutter中使用动画的几个关键类。

动画核心类：

AnimationController 动画控制器

用来设置动画时长、动画开始结束数值、控制开始结束动画等操作。

构造方法以及常用方法：

_controller = AnimationController(

  vsync: this,//设置Ticker 动画帧的回调函数

  duration: const Duration(milliseconds: 2000),// 正向动画时长 //2s

  reverseDuration: const Duration(milliseconds: 2000),// 反向动画时长 //2s

  lowerBound: 0,// 开始动画数值  double类型

  upperBound: 1.0,// 结束动画数值 double类型

  animationBehavior: AnimationBehavior.normal ,// 动画器行为 是否重复动画 两个枚举值

  debugLabel: "缩放动画",// 调试标签 动画过多时方便调式，toString时显示

// _controller.toString;

//输出: AnimationController#9d121(▶ 0.000; for 缩放动画)➩Tween<double>(0.0 → 1.0)➩0.0

); 

// 常用方法：

// 监听动画运动

_controller.addListener(() { });

// 监听动画开始、停止等状态

_controller.addStatusListener((status) {

      // dismissed 动画在起始点停止

      // forward 动画正在正向执行

      // reverse 动画正在反向执行

      // completed 动画在终点停止

      if (status == AnimationStatus.completed) {

        _controller.reverse(); //反向执行 100-0

      } else if (status == AnimationStatus.dismissed) {

        _controller.forward(); //正向执行 0-100

      }

});

// 启动动画

// _controller.forward();//正向开始动画

// _controller.reverse();//反向开始动画

_controller.repeat(); // 无限循环开始动画

vsync参数需要类混入：

SingleTickerProviderStateMixin或TickerProviderStateMixin，如果页面内只有一个动画控制器使用第一个，多个控制器使用第二个。

AnimatedBuilder 实现动画组件核心类

一般情况下，我们需要将需要有动画效果的组件上包裹一层AnimatedBuilder从而监听动画控制器更新数据，内部也是通过有状态部件监听不断刷新页面实现。

构造方法：

const AnimatedBuilder({

  Key? key,

  required Listenable animation,//动画控制器

  required this.builder,// 返回动画

  this.child,// 传递给build的child子组件

})

以上两个组件就可以实现简单的动画效果了，下面我们使用AnimationController和 AnimatedBuilder实现一个简单的缩放动画。使FlutterLogo组件大小不断变化。

// 开启动画

_controller.repeat(); // 无限循环开始动画



Center(

  child:   AnimatedBuilder(

      child: FlutterLogo(),

      animation: _controller,

      builder: (context, child) {

        return Container(

          width: 100 * _controller.value,

          height: 100 * _controller.value,

          child: child,

        );

      }),

)

效果：



可以看到组件通过控制器0-1不断变化，logo大小也发生了变化，也就简单实现了缩放的效果。

注：AnimatedBuilder是实现的局部组件刷新，并不会触发本身的build方法。

Animation<T> 声明动画

以上我们通过控制器实现了简单的缩放动画效果，但是我们发现开始和结束的数据只能是double类型的数字，中间的变化状态是需要我们来进行计算的，如果遇到较为复杂的过渡变化，计算也会同样变得复杂，那么为了解决这个问题，Animation<T>应运而生，该类主要用来声明控制动画运动的数据类，数据为泛型类型，可自定义。

有了这个类，我们就可以实现自定义数据算法的过渡效果，例如颜色的渐变。

Animation一般和Tween配合使用。

Tween<T> 实现声明动画

为对象在开始和结束中间运动时变化的过程类，也称为补间动画，泛型和Animation一致，通过Animation给定泛型，生成Tween类设置动画开始和动画结束数据并调用animate方法设置动画控制器。

一般情况，动画开始和结束我们用0 ~ 1 表示，实际上，我们也可以使用其他数据设置开始和结束数据。例如颜色过渡ColorTween、大小过渡SizeTween、矩形过渡RectTween变化等，而无需关心运动过程中的数值是如何计算的，因为这些官方已经帮我们计算好了。
源码中可以看到，这些扩展的Tween类都实现了lerp方法。

例如颜色渐变实现：

/// 返回0 ～ 1 颜色渐变过程中的色值。

@override

Color? lerp(double t) => Color.lerp(begin, end, t);





static Color? lerp(Color? a, Color? b, double t) {

    ///...略

    // 颜色渐变算法 具体算法可以翻代码自行查看 都是数学知识

      return Color.fromARGB(

        _clampInt(_lerpInt(a.alpha, b.alpha, t).toInt(), 0, 255),

        _clampInt(_lerpInt(a.red, b.red, t).toInt(), 0, 255),

        _clampInt(_lerpInt(a.green, b.green, t).toInt(), 0, 255),

        _clampInt(_lerpInt(a.blue, b.blue, t).toInt(), 0, 255),

      );

}

举例：

// 开始动画

_controller.repeat(reverse: true); // 无限循环开始动画 结束倒放为true

/// 颜色渐变动画

Animation<Color?> animation;// 声明动画，数据为Color颜色

animation = ColorTween(begin: Colors.red, end: Colors.yellow).animate(_controller);// 实现动画，设置动画由红向黄渐变

// Size大小变化

Animation<Size?> animation2;

animation2 = SizeTween(begin: Size(100,50), end:Size(50,100)).animate(cure);

效果：



当然我们也可以自定义补间动画的过程，实现lerp方法，这里就考验你数学知识的掌握了，就不展开了，掌握原理即可。

Curve & CurvedAnimation 动画运动曲线

上面的动画效果虽然实现了复杂过程的变化，但是还缺少我们动画的核心属性，就是运动轨迹，因为上面没有设置，默认的运动轨迹是线性变化的，所以给我们的效果都是非常平稳的。如果实现更为丰富的动画效果，那么Curve应运而生，Curve是一个数值转换器，可以理解为方程式，默认y=x;它可以让我们运动过程不再是匀速变化，而是让运动过程可以拥有加速、减速、越界等变化，并且Curves里内置了非常丰富的运动轨迹可以直接使用。 在之前的文章也有用到过。

CurvedAnimation是Curve类的具体使用，将非线性曲线应用到动画中，使用也非常的简单。只需要将动画控制器赋值给CurvedAnimation,上方Tween的animate方法里设置 CurvedAnimation即可。

代码：

//构造

CurvedAnimation({

  required this.parent,// 动画控制器

  required this.curve,// 正向动画曲线

  this.reverseCurve,// 反向动画曲线

}); 



//自定义运动曲线

CurvedAnimation cure = CurvedAnimation(parent: _controller, curve: Curves.easeIn);



// 使用 将_controller替换为cure

Animation<Color> animation;

animation = Tween<Color>(begin: Colors.black, end: Colors.white).animate(cure);

可以看到下方有非常丰富的曲线效果。


源码注释里有mp4效果演示，想方便了解效果可以看这篇文章。
Flutter 动画曲线Curves 效果一览。

自定义Curves

随便点击去一个Cubic类，实现方法很简单，

从源码中可以看到 Curve里有可以实现两个方法，官方建议实现transformInternal方法，因为transform方法内部直接返回了transformInternal这个方法。

那么实现就很简单了，定义一个类，继承Curves,实现transformInternal方法即可。transformInternal就可以将我们给定的数值转换为我们想要的数值。

class MyCurve extends Curve {

  @override

  double transformInternal(double x) {

    // 自定义变化曲线

    // 默认 y= x; 线性运动

    // y = x的立方。这里可以理解为定义方程 x可以理解为0-1的变化过程

    // y即是返回0-1变化的的自定义算法，无需关心具体的动画运动轨迹是如何计算的。

    return x * x * x;

  }

}

注：Curve只负责0 ~ 1（也就是动画开始 ~ 动画结束）的变化曲线，无论任何数据驱动的动画我们都可以用0 ~ 1来表示运动曲线。具体的过渡算法我们无需关心，那是补间动画需要做的事情，内置的补间动画Flutter已经帮我们算了，使用也非常的方便。

其他 内置常用动画组件的使用

其实在Flutter中还内置了我们常用的动画效果组件，例如平移、渐变、缩放等组件，实现过程原理基本相当，区别是我们不需要自己计算了，直接设置动画器即可。

部分内置动画使用：

1、平移动画 SlideTransition

根据组件自身大小进行平移，接收Offset数据，分别代表自身组件大小的倍数。

// 构造

const SlideTransition({

  super.key,

  required Animation<Offset> position,

  this.transformHitTests = true,

  this.textDirection,//阅读习惯方向

  this.child,

}) 

2、渐变动画 FadeTransition

渐变动画一般指组件透明度渐变效果，接收double类型，0 ～ 1为完全透明 ～ 完全不透明。

const FadeTransition({

  super.key,

  required Animation<double> opacity,

  this.alwaysIncludeSemantics = false,

  super.child,

}) 

3、缩放动画 ScaleTransition

缩放动画接收double数据，0 ～ 1 为最小到最大，可以指定缩放中心。

const ScaleTransition({

  super.key,

  required Animation<double> scale,

  this.alignment = Alignment.center,//缩放中心

  this.filterQuality,//过滤器质量

  this.child,

}) 

4、旋转动画 RotationTransition

旋转动画一般指平面二维的旋转，接收double参数，0 ～1为旋转一圈，同样可指定旋转中心。

const RotationTransition({

  super.key,

  required Animation<double> turns,

  this.alignment = Alignment.center,

  this.filterQuality,

  this.child,

}) 

5、3D旋转动画

3D动画系统没有现成的，需要我们使用矩阵变换自行计算，其实也很简单，通过Matrix4类设置矩阵变换即可，下方为绕y轴进行旋转，范围是0～2pi。

AnimatedBuilder(

    child: child,

    animation: animation,

    builder: (context, child) {

      return Transform(

          alignment: Alignment.center, //相对于坐标系原点的对齐方式

          transform: Matrix4.identity()

            ..rotateX(0)//x轴不变

            ..rotateY(animation.value),//绕y轴旋转，0-2pi

          child: Container(width: 100, height: 100, child: child));

    });

5、组合动画

将上面所有动画效果组合起来也很简单，将以上动画通过子组件进行嵌套即可，最终的子组件为我们动画所需的组件。

核心代码：

animation = Tween(begin: 0.0, end: 1.0).animate(cure);

animation2 = Tween<Offset>(begin: Offset(0.0, 0.0), end: Offset(1.0, 0.0)).animate(cure);

animation3 = Tween(begin: 0.0, end: 1.0).animate(cure);

animation4 = Tween(begin: 0.0, end: pi * 2).animate(cure);



// // 平移

SlideTransitionLogo(

  animation: animation2,

  // 渐变

  child: FadeTransition(

    opacity: animation3,

    // 二维旋转

    child:  RotationTransitionLogo(

     // 缩放

      child: ScaleTransition(

        // 3D旋转

        child: AnimatedBuilder(

            child:  FlutterLogo(),

            animation: animation4,

            builder: (context, child) {

              return Transform(

                  alignment: Alignment.center, //相对于坐标系原点的对齐方式

                  transform: Matrix4.identity()

                    ..rotateX(0)

                    ..rotateY(animation4.value),

                  child: Container(width: 100, height: 100, child: child));

            }),

        scale: animation,

      ),



      animation: animation3,

    ),将

  ),

),

效果：

其实系统内置的还有些其他现成的动画效果，有兴趣的小伙伴可以自己研究下，原理基本相同。

自定义动画效果

自定义动画一般和自绘制结合使用，根据绘制的组件和动画的运动曲线来达到我们想要的效果。下一篇有时间剖析下动画与绘制结合使用的方法与细节。

总结

动画归根结底是让数据不断变化来驱使UI产生变化，重点的就是我们如何处理这个变化过程中的数据，以上是对于Flutter动画使用方面的一些总结，希望对你有所帮助～ 如有疑问，欢迎指正。

再谈SharedPreferences

对于android开发者们来说，SharedPreferences已经是一个有足够历史的话题了，之所以还在性能优化这个专栏中再次提到，是因为在实际项目中还是会有很多使用到的地方，同时它也有足够的“坑”，比如常见的主进程阻塞，虽然SharedPreferences 提供了异步操作api apply，但是apply方法依旧有可能造成ANR。

public void apply() {

    final long startTime = System.currentTimeMillis();



    final MemoryCommitResult mcr = commitToMemory();

    final Runnable awaitCommit = new Runnable() {

            @Override

            public void run() {

                try {

                    mcr.writtenToDiskLatch.await();

                } catch (InterruptedException ignored) {

                }



                if (DEBUG && mcr.wasWritten) {

                    Log.d(TAG, mFile.getName() + ":" + mcr.memoryStateGeneration

                            + " applied after " + (System.currentTimeMillis() - startTime)

                            + " ms");

                }

            }

        };



    QueuedWork.addFinisher(awaitCommit);



    Runnable postWriteRunnable = new Runnable() {

            @Override

            public void run() {

                awaitCommit.run();

                QueuedWork.removeFinisher(awaitCommit);

            }

        };

    // 写入队列

    SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);



    // Okay to notify the listeners before it's hit disk

    // because the listeners should always get the same

    // SharedPreferences instance back, which has the

    // changes reflected in memory.

    notifyListeners(mcr);

}

我们可以看到我们的runnable被写入了队列，而这个队列会在handleStopService() 、handlePauseActivity() 、 handleStopActivity()  的时候会一直等待 apply() 方法将数据保存成功，否则会一直等待，从而阻塞主线程造成 ANR。

@Override

public void handlePauseActivity(ActivityClientRecord r, boolean finished, boolean userLeaving,

    int configChanges, PendingTransactionActions pendingActions, String reason) {

    if (userLeaving) {

        performUserLeavingActivity(r);

    }



    r.activity.mConfigChangeFlags |= configChanges;

    performPauseActivity(r, finished, reason, pendingActions);



    // Make sure any pending writes are now committed.

    if (r.isPreHoneycomb()) {

        // 这里就是元凶

        QueuedWork.waitToFinish();

    }

    mSomeActivitiesChanged = true;

}

谷歌官方也有解释

虽然QueuedWork在android 8中有了新的优化，但是实际上依旧有ANR的出现，在低版本的机型上更加出现频繁，所以我们不可能把sp真的逃避掉。

目前业内有很多替代的方案，就是采用MMKV去解决，但是官方并没有采用像mmkv的方式去解决，而是另起炉灶，在jetpack中引入DataStore去替代旧时代的SharedPreferences。

DataStore

Jetpack DataStore 是一种数据存储解决方案，允许您使用协议缓冲区存储键值对或类型化对象。DataStore 使用 Kotlin 协程和 Flow 以异步、一致的事务方式存储数据。

DataStore 提供两种不同的实现：Preferences DataStore 和 Proto DataStore（基于protocol buffers）。我们这里主要以Preferences DataStore作为分析，同时在kotlin中，datastore采取了flow的良好架构，进行了内部的调度实现，同时也提供了java兼容版本（采用RxJava实现）

使用例子

val Context.dataStore : DataStore<Preferences> by preferencesDataStore(“文件名”)

因为datastore需要依靠协程的环境，所以我们可以有以下方式

读取

CoroutineScope(Dispatchers.Default).launch {

    context.dataStore.data.collect {

        value = it[booleanPreferencesKey(key)] ?: defValue

    }

}

写入

CoroutineScope(Dispatchers.IO).launch {

    context.dataStore.edit { settings ->

        settings[booleanPreferencesKey(key) ] = value

    }

   

}

其中booleanPreferencesKey代表着存入的value是boolean类型，同样的，假设我们需要存入的数据类型是String，相应的key就是通过stringPreferencesKey(key名) 创建。同时因为返回的是flow，我们是需要调用collect这种监听机制去获取数值的改变，如果想要像sp一样采用同步的方式直接获取，官方通过runBlocking进行获取，比如

val exampleData = runBlocking { context.dataStore.data.first() }

DataStore原理

DataStore提供给了我们非常简洁的api，所以我们也能够很快速的入门使用，但是其中的原理实现，我们是要了解的，因为其创建过程十分简单，我们就从数据更新（context.dataStore.edit）的角度出发，看看DataStore究竟做了什么。

首先我们看到edit方法

public suspend fun DataStore<Preferences>.edit(

    transform: suspend (MutablePreferences) -> Unit

): Preferences {

    return this.updateData {

        // It's safe to return MutablePreferences since we freeze it in

        // PreferencesDataStore.updateData()

        it.toMutablePreferences().apply { transform(this) }

    }

}

可以看到edit方法是一个suspend的函数，其主要的实现就是依靠updateData方法的调用

interface DataStore<T> 中：



public suspend fun updateData(transform: suspend (t: T) -> T): T

我们分析到DataStore是有两种实现，我们要看的就是Preferences DataStore的实现，其实现类是

internal class PreferenceDataStore(private val delegate: DataStore<Preferences>) :

    DataStore<Preferences> by delegate {

    override suspend fun updateData(transform: suspend (t: Preferences) -> Preferences):

        Preferences {

            return delegate.updateData {

                val transformed = transform(it)

                // Freeze the preferences since any future mutations will break DataStore. If a user

                // tunnels the value out of DataStore and mutates it, this could be problematic.

                // This is a safe cast, since MutablePreferences is the only implementation of

                // Preferences.

                (transformed as MutablePreferences).freeze()

                transformed

            }

        }

}

可以看到PreferenceDataStore中updateData方法的具体实现其实在delegate中，而这个delegate的创建是在

PreferenceDataStoreFactory中



public fun create(

    corruptionHandler: ReplaceFileCorruptionHandler<Preferences>? = null,

    migrations: List<DataMigration<Preferences>> = listOf(),

    scope: CoroutineScope = CoroutineScope(Dispatchers.IO + SupervisorJob()),

    produceFile: () -> File

): DataStore<Preferences> {

    val delegate = DataStoreFactory.create(

        serializer = PreferencesSerializer,

        corruptionHandler = corruptionHandler,

        migrations = migrations,

        scope = scope

    ) {

       忽略

    }

    return PreferenceDataStore(delegate)

}

DataStoreFactory.create方法中：

  public fun <T> create(

        serializer: Serializer<T>,

        corruptionHandler: ReplaceFileCorruptionHandler<T>? = null,

        migrations: List<DataMigration<T>> = listOf(),

        scope: CoroutineScope = CoroutineScope(Dispatchers.IO + SupervisorJob()),

        produceFile: () -> File

    ): DataStore<T> =

        SingleProcessDataStore(

            produceFile = produceFile,

            serializer = serializer,

            corruptionHandler = corruptionHandler ?: NoOpCorruptionHandler(),

            initTasksList = listOf(DataMigrationInitializer.getInitializer(migrations)),

            scope = scope

        )

}

DataStoreFactory.create 创建的其实是一个SingleProcessDataStore的对象，SingleProcessDataStore同时也是继承于DataStore，它就是所有DataStore背后的真正的实现者。而它的updateData方法就是一切谜团解决的钥匙。

    

override suspend fun updateData(transform: suspend (t: T) -> T): T {

    val ack = CompletableDeferred<T>()

    val currentDownStreamFlowState = downstreamFlow.value



    val updateMsg =

        Message.Update(transform, ack, currentDownStreamFlowState, coroutineContext)



    actor.offer(updateMsg)



    return ack.await()

}

我们可以看到，update方法中，有一个叫 ack的 CompletableDeferred对象，而CompletableDeferred，是继承于Deferred。我们到这里就应该能够猜到了，这个Deferred对象不正是我们协程中常用的异步调用类嘛！它提供了await操作允许我们等待异步的结果。
最后封装好的Message被放入actor.offer(updateMsg) 中，actor是消息处理类对象，它的定义如下

internal class SimpleActor<T>(

    /**

     * The scope in which to consume messages.

     */

    private val scope: CoroutineScope,

    /**

     * Function that will be called when scope is cancelled. Should *not* throw exceptions.

     */

    onComplete: (Throwable?) -> Unit,

    /**

     * Function that will be called for each element when the scope is cancelled. Should *not*

     * throw exceptions.

     */

    onUndeliveredElement: (T, Throwable?) -> Unit,

    /**

     * Function that will be called once for each message.

     *

     * Must *not* throw an exception (other than CancellationException if scope is cancelled).

     */

    private val consumeMessage: suspend (T) -> Unit

) {

    private val messageQueue = Channel<T>(capacity = UNLIMITED)

我们看到，我们所有的消息会被放到一个叫messageQueue的Channel对象中，Channel其实就是一个适用于协程信息通信的线程安全的队列。

最后我们回到主题，offer函数干了什么

    省略前面



do {

    // We don't want to try to consume a new message unless we are still active.

    // If ensureActive throws, the scope is no longer active, so it doesn't

    // matter that we have remaining messages.

    scope.ensureActive()



    consumeMessage(messageQueue.receive())

} while (remainingMessages.decrementAndGet() != 0)

其实就是通过consumeMessage消费了我们的消息。到这里我们再一次回到我们DataStore中的SimpleActor实现对象

private val actor = SimpleActor<Message<T>>(

    scope = scope,

    onComplete = {

        it?.let {

            downstreamFlow.value = Final(it)

        }

        // We expect it to always be non-null but we will leave the alternative as a no-op

        // just in case.



        synchronized(activeFilesLock) {

            activeFiles.remove(file.absolutePath)

        }

    },

    onUndeliveredElement = { msg, ex ->

        if (msg is Message.Update) {

            // TODO(rohitsat): should we instead use scope.ensureActive() to get the original

            //  cancellation cause? Should we instead have something like

            //  UndeliveredElementException?

            msg.ack.completeExceptionally(

                ex ?: CancellationException(

                    "DataStore scope was cancelled before updateData could complete"

                )

            )

        }

    }

) { 

    consumeMessage 实际

    msg ->

    when (msg) {

        is Message.Read -> {

            handleRead(msg)

        }

        is Message.Update -> {

            handleUpdate(msg)

        }

    }

}

可以看到，consumeMessage其实就是以lambada形式展开了，实现的内容也很直观，如果是Message.Update就调用了handleUpdate方法

private suspend fun handleUpdate(update: Message.Update<T>) {

    

    // 这里就是completeWith调用，也就是回到了外部Deferred的await方法

    update.ack.completeWith(

        runCatching {



            when (val currentState = downstreamFlow.value) {

                is Data -> {

                    // We are already initialized, we just need to perform the update

                    transformAndWrite(update.transform, update.callerContext)

                }

    

    ...

最后通过了transformAndWrite调用writeData方法，写入数据（FileOutputStream）

internal suspend fun writeData(newData: T) {

    file.createParentDirectories()



    val scratchFile = File(file.absolutePath + SCRATCH_SUFFIX)

    try {

        FileOutputStream(scratchFile).use { stream ->

            serializer.writeTo(newData, UncloseableOutputStream(stream))

            stream.fd.sync()

            // TODO(b/151635324): fsync the directory, otherwise a badly timed crash could

            //  result in reverting to a previous state.

        }



        if (!scratchFile.renameTo(file)) {

            throw IOException(

                "Unable to rename $scratchFile." +

                    "This likely means that there are multiple instances of DataStore " +

                    "for this file. Ensure that you are only creating a single instance of " +

                    "datastore for this file."

            )

        }

至此，我们整个过程就彻底分析完了，读取数据跟写入数据类似，只是最后调用的处理函数不一致罢了（consumeMessage 调用handleRead），同时我们也分析出来handleUpdate的update.ack.completeWith让我们也回到了协程调用完成后的世界。

SharedPreferences全局替换成DataStore

分析完DataStore，我们已经有了足够的了解了，那么是时候将我们的SharedPreferences迁移至DataStore了吧！

旧sp数据迁移

已存在的sp对象数据可以通过以下方法无缝迁移到datastore的世界

dataStore = context.createDataStore( name = preferenceName, migrations = listOf( SharedPreferencesMigration( context, "sp的名称" ) ) )   

无侵入替换sp为DataStore

当然，我们项目中可能会存在很多历史遗留的sp使用，此时用手动替换会容易出错，而且不方便，其次是三方库所用到sp我们也无法手动更改，那么有没有一种方案可以无需对原有项目改动，就可以迁移到DataStore呢？嗯！我们要敢想，才敢做！这个时候就是我们的性能优化系列的老朋友，ASM登场啦！

我们来分析一下，怎么把

val sp = this.getSharedPreferences("test",0)

val editor = sp.edit()

editor.putBoolean("testBoolean",true)

editor.apply()

替换成我们想要的DataStore，不及，我们先看一下这串代码的字节码

    LINENUMBER 24 L2

    ALOAD 0

    LDC "test"

    ICONST_0

    INVOKEVIRTUAL com/example/spider/MainActivity.getSharedPreferences (Ljava/lang/String;I)Landroid/content/SharedPreferences;

    ASTORE 2

我们可以看到，我们的字节码中存在ALOAD ASTORE这种依赖于操作数栈环境的指令，就知道不能简单的实现指令替换，而是采用同类替换的方式去现实，即我们可以通过继承于SharedPreferences，在自定义SharedPreferences中实现DataStore的操作，严格来说，这个自定义SharedPreferences，其实就相当于一个壳子了。这种替换方式在Android性能优化-线程监控与线程统一也有使用到。

我们来看一下自定义的SharedPreferences操作，这里以putBoolean相关操作举例子

class DataPreference(val context: Context,name:String):SharedPreferences {

    val Context.dataStore : DataStore<Preferences> by preferencesDataStore(name)

   

    override fun getBoolean(key: String, defValue: Boolean): Boolean {

        var value = defValue

        runBlocking {



        }

        runBlocking {

            context.dataStore.data.first {

                value = it[booleanPreferencesKey(key)] ?: defValue

                true

            }

        }

//        CoroutineScope(Dispatchers.Default).launch {

//            context.dataStore.data.collect {

//

//                value = it[booleanPreferencesKey(key)] ?: defValue

//                Log.e("hello","value os $value")

//            }

//        }

        

        return value

    }





    override fun edit(): SharedPreferences.Editor {

       return DataEditor(context)

    }





    inner class DataEditor(private val context: Context): SharedPreferences.Editor {

 



        override fun putBoolean(key: String, value: Boolean): SharedPreferences.Editor {

            CoroutineScope(Dispatchers.IO).launch {

                context.dataStore.edit { settings ->

                    settings[booleanPreferencesKey(key) ] = value

                }

            }

            return this

        }



    



        override fun commit(): Boolean {

            // 空实现即可

        }



        override fun apply() {

           // 空实现即可

        }

    }

}

因为putBoolean中其实就已经把数据存好了，所有我们的commit/apply都可以以空实现的方式替代。同时我们也声明一个扩展函数

StoreTest.kt

fun Context.getDataPreferences(name:String,mode:Int): SharedPreferences {

    return DataPreference(this,name)

}

字节码部分操作也比较简单,我们只需要把原本的 INVOKEVIRTUAL com/example/spider/MainActivity.getSharedPreferences (Ljava/lang/String;I)Landroid/content/SharedPreferences; 指令替换成INVOKESTATIC的StoreTestKt扩展函数getDataPreferences调用即可，同时由于接受的是SharedPreferences类型而不是我们的DataPreference类型，所以需要采用CHECKCAST转换。

static void spToDataStore(

        MethodInsnNode node,

        ClassNode klass,

        MethodNode method

) {

    println("init  ===>  " + node.name+" --"+node.desc + " " + node.owner)





    if (node.name.equals("getSharedPreferences")&&node.desc.equals("(Ljava/lang/String;I)Landroid/content/SharedPreferences;")) {



        MethodInsnNode methodHookNode = new MethodInsnNode(Opcodes.INVOKESTATIC,

                "com/example/spider/StoreTestKt",

                "getDataPreferences",

                "(Landroid/content/Context;Ljava/lang/String;I)Landroid/content/SharedPreferences;",

                false)



        TypeInsnNode typeInsnNode = new TypeInsnNode(Opcodes.CHECKCAST, "android/content/SharedPreferences")

        InsnList insertNodes = new InsnList()

        insertNodes.add(methodHookNode)

        insertNodes.add(typeInsnNode)

        method.instructions.insertBefore(node, insertNodes)

        method.instructions.remove(node)



        println("hook  ===>  " + node.name + " " + node.owner + " " + method.instructions.indexOf(node))

    }



}

方案的“不足”

当然，我们这个方案并不是百分比完美的

editor.apply()

sp.getBoolean

原因是如果采用这种方式apply()后立马取数据，因为我们替换后putBoolean其实是一个异步操作，而我们getBoolean是同步操作，所以就有可能没有拿到最新的数据。但是这个使用姿势本身就是一个不好的使用姿势，同时业内的滴滴开源Booster的sp异步线程commit优化也同样有这个问题。因为put之后立马get不是一个规范写法，所以我们也不会对此多加干预。不过对于我们DataStore替换后来说，也有更加好的解决方式

CoroutineScope(Dispatchers.Default).launch {

    context.dataStore.data.collect {



        value = it[booleanPreferencesKey(key)] ?: defValue

        Log.e("hello","value os $value")

    }

}

通过flow的异步特性，我们完全可以对value进行collect，调用层通过collect进行数据的收集，就能够做到万无一失啦（虽然也带来了侵入性）

总结

到这里，我们又完成了性能优化的一篇，sp迁移至DataStore的后续适配，等笔者有空了会写一个工具库（挖坑），虽然sp是一个非常久远的话题了，但是依旧值得我们分析，同时也希望DataStore能够被真正利用起来，适当的选用DataStore与MMKV。

善用@get/@set: JvmName()注解并搭配setter/getter使用

假设当前存在下面三个类代码：

#Opt1

public class Opt1 {



    private String mContent;



    public String getRealContent() {

        return mContent;

    }



    public void setContent(String mContent) {

        this.mContent = mContent;

    }

}

#Opt2

public class Opt2 {



    public void opt2(Opt1 opt1) {

        System.out.println(opt1.getRealContent());

    }

} 

@Opt3

public class Opt3 {



    public void opt3(Opt1 opt1) {

        System.out.println(opt1.getRealContent());

    }

}

这个时候我想将Opt1类重构成kotlin，我们先看下通过AS的命令Convert Java File to Kotlin File自动转换的结果：

可以看到为了兼容Opt2和Opt3的调用，直接把我的属性名给改成了realContent，kotlin会自动生成getRealContent()和setRealContent()方法，这样Opt2和Opt3就不用进行任何调整了，kotlin这样就显得太过于智能了。

这样看起来没啥问题，但是java重构kotlin，直接把属性名给我改了，并隐式生成了属性的set和get方法，对于java而言不使用的方法会报灰提示或者只有当前类使用AS会警告可以声明成private，但是对于kotlin生成的set、get方法是隐式的，容易忽略。

所以大家在使用Convert Java File to Kotlin File命令将java重构kotlin的结果一定不能抱有百分之百的信任，即使它很智能，但还是一定要细细的看下转换后的代码逻辑，可能还有不少的优化空间。

这个地方就得需要我们手动进行修改了，比如不想对外暴露修改这个字段的set方法，调整如下：

class Opt1 {

    var realContent: String? = null

        private set

}

再比如保持原有的字段名mContent，不能被改为realContent，同时又要保证兼容Opt2和Opt3类的调用不能报错，且尽量避免去修改里面的代码，我们就可以做如下调整：

class Opt1 {

    @get: JvmName("getRealContent")

    var mContent: String? = null

        private set

}  

善用默认参数+@JvmOverloads减少模板代码编写

假设当前Opt1有下面的方法：

public String getSqlCmd(String table) {

    return "select * from " + table;

}

且被Opt2和Opt3进行了调用，这个时候如果有另一个类Opt3想要调用这个函数并只想从数据库查询指定字段，如果用java实现有两种方式：

1. 直接在getSqlCmd()方法中添加一个查询字段参数，如果传入的值为null，就查询所有的字段，否则就查询指定字段：

public String getSqlCmd(String table, String name) {

    if (TextUtils.isEmpty(name)) {

        return "select * from " + table;

    }

    return "select " + name + " from " + table;

}

这样一来，是不是原本Opt2和Opt3对getSqlCmd()方法调用是不是需要改动，多传一个参数给方法，而在日常的项目开发中，有可能这个getSqlCmd()被几十个地方调用，难道你一个个的改过去？不太现实且是一种非常糟糕的实现。

2. 直接在Opt1中新增一个getSqlCmd()的重载方法，传入指定的字段去查询：

public String getSqlCmd(String table，String name) {

    return "select " + name + " from " + table;

}

这样做的好处就是不用调整Opt2和Opt3对getSqlCmd(String table)方法调用逻辑，但是会编写很多模板代码，尤其是getSqlCmd()这个方法体可能七八十行的情况下。

如果Opt1类代码减少即200-400行且不负责的情况下，我们可以将其重构成kotlin，借助于默认参数来实现方法功能增加又不用编写模板代码的效果（如果你的Java类上千行又很复杂，请谨慎转换成kotlin使用下面这种方式）。

@JvmOverloads

fun getSqlCmd(table: String, name: String? = null): String {

    return "select ${if (name.isNullOrEmpty()) "*" else name} from $table"

}

添加默认参数name时还要添加@JvmOverloads注解，这样是为了保证java只传一个table参数也能正常调用。

通过上面这种方式，我们就能保证实现了方法功能增加，又不用改动Opt2、Opt3对于getSqlCmd()方法的调用逻辑，并且还不用编写额外的模板代码，一举多得。

总结

本篇文章主要介绍了在java重构成kotlin过程中比较常用到的两个技巧，最终实现效果是减少对业务逻辑代码的入侵，希望能对你有所帮助。