前言

2023年到来，今年过年格外早，没几天就要迎新年了，因为是兔年，所以我创建了一个Rabbit为主题的App，里面以兔子为主题而添加各种相关内容，目前仅有十条2023兔年祝福语，后面会增加其他功能，下面，我们看看这个App的样子。

正篇

UI设计

首先，这个App因为这两天才创建的，所以只是UI上看起来和兔子相关，内容并不是很充实。主要是找了一张兔子的图片做App的logo，以及找了几张动态图作为app内部的装饰UI，如下：

内容设计

内部我是利用LottieAnimation去展示动图（让UI忙碌的安卓Lottie动画渲染库（一） - 掘金 (juejin.cn) & 让UI忙碌的安卓Lottie动画渲染库（二） - 掘金 (juejin.cn)），然后使用之前掘友推荐的刘强东写的列表神器BRV（liangjingkanji/BRV: [文档详细] Android上最好的RecyclerView框架, 比 BRVAH 更简单强大 (github.com)），琢磨了半天最后还是没有成功使用库作者推荐的DataBinding方式，我使用RecyclerView中使用BRV去加载10条祝福语。

这是使用作者推荐方式后运行不起来的截图：

看文档上的解决方法依次尝试还是没成功，所以还是采用ViewBinding的方式了。

代码与效果展示

部分XML布局如下，我虽然启用了DataBinding但目前还不会用，所以我也同时启用了ViewBinding：

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

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

    xmlns:app="http://schemas.android.com/apk/res-auto"

    xmlns:tools="http://schemas.android.com/tools">



    <data>



    </data>



    <LinearLayout

        android:layout_width="match_parent"

        android:layout_height="match_parent"

        android:orientation="vertical"

        tools:context=".MainActivity">

       ...

       ...



        <com.airbnb.lottie.LottieAnimationView

            android:id="@+id/rabbit_easter_egg_slider"

            android:layout_width="match_parent"

            android:layout_height="100dp"

            android:layout_gravity="center"

            app:lottie_autoPlay="true"

            app:lottie_fileName="lottie/rabbit_easter_egg_slider.json"

            app:lottie_loop="true"

            app:lottie_repeatMode="restart" />



        <androidx.core.widget.NestedScrollView

            android:layout_width="wrap_content"

            android:layout_height="wrap_content"

            android:layout_gravity="center"

            tools:ignore="SpeakableTextPresentCheck">



            <LinearLayout

                android:layout_width="wrap_content"

                android:layout_height="wrap_content"

                android:orientation="vertical">



            ...

            ...



                <com.airbnb.lottie.LottieAnimationView

                    android:id="@+id/rabbit_2023"

                    android:layout_width="200dp"

                    android:layout_height="200dp"

                    android:layout_gravity="center"

                    app:lottie_autoPlay="true"

                    app:lottie_fileName="lottie/rabbit_2023.json"

                    app:lottie_loop="true"

                    app:lottie_repeatMode="restart" />

            </LinearLayout>



        </androidx.core.widget.NestedScrollView>



        <androidx.recyclerview.widget.RecyclerView

            android:id="@+id/vMainList"

            android:layout_width="match_parent"

            android:layout_height="wrap_content" >

        </androidx.recyclerview.widget.RecyclerView>



    </LinearLayout>

</layout>

我的activity中部分代码如下，很笨拙地使用列表的方式存了10条祝福语，后面还会优化一下并加上复制按钮：

...

...



class MainActivity : AppCompatActivity() {



    private lateinit var binding: ActivityMainBinding

    private var text = arrayOf("兔年！...",

    ...

    ....,

    ....,

    ....")



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        binding = ActivityMainBinding.inflate(layoutInflater)

        setContentView(binding.root)

        window.attributes.softInputMode = WindowManager.LayoutParams.SOFT_INPUT_ADJUST_PAN



        binding.vMainList.linear().setup {

            addType<SimpleModel>(R.layout.item_simple)

            setAnimation(AnimationType.SLIDE_BOTTOM)



            onBind {

                val binding = getBinding<ItemSimpleBinding>() // 使用ViewBinding/DataBinding都可以使用本方法

                binding.tvName.text = getModel<SimpleModel>().name

            }

        }.models = getData()



    }



    private fun getData(): MutableList<Any> {

        // 在Model中也可以绑定数据

        return mutableListOf<Any>().apply {

            for (i in 1..10) {

                val simpleModel = SimpleModel(

                    "$i、${text[i-1]}"

                    , i)

                add(simpleModel)

//            add(SimpleModel())

            }





        }

    }

}

运行后目前只可以滑动查看列表：

项目代码

总之就是这个App目前还非常简陋,但是已经放到了GitHub上了，后续会逐渐添加优化一些功能和代码。

项目地址：ObliviateOnline/RabbitApp: 2023 rabbit app (github.com)

总结

本来是想做一个搜索类的App，结果发现做着做着就偏离了方向，但是本来就是为了新年添个彩头，又是自己弄着玩的，加之看起来还是像那么回事，所以就这么直接发出来献丑了，希望大家喜欢！

前言

在 App 的运营中，活跃度是一个重要的指标，日活/月活……为了提高活跃度，就发明了小红点，然后让强迫症用户“没法活”。

小红点虽然很讨厌，但是为了 KPI，程序员也不得不屈从运营同学的逼迫（讨好），得想办法实现。这一篇，来介绍一个徽标（Badge）组件，能够快速搞定应用内的小红点。

Badge 组件

Badge 组件被 Flutter 官方推荐，利用它让小红点的实现非常轻松，只需要2个步骤就能搞定。

1. 引入依赖

在 pubspec.yaml文件种引入相应版本的依赖，如下所示。

badges: ^2.0.3

2. 将需要使用小红点的组件使用 Badge 作为上级组件，设置小红点的位置、显示内容、颜色（没错，也可以改成小蓝点）等参数，示例代码如下所示。

Badge(

  badgeContent: Text('3'),

  position: BadgePosition.topEnd(top: -10, end: -10),

  badgeColor: Colors.blue,

  child: Icon(Icons.settings),

)

position可以设置徽标在组件的相对位置，包括右上角（topEnd）、右下角（bottomEnd）、左上角（topStart）、左下角（bottomStart）和居中（center）等位置。并可以通过调整垂直方向和水平方向的相对位置来进行位置的细微调整。当然，Badge 组件考虑了很多应用场景，因此还有其他的一些参数：

• elevation：阴影偏移量，默认为2，可以设置为0消除阴影；


• gradient：渐变色填充背景；


• toAnimate：徽标内容改变后是否启用动效哦，默认有动效。


• shape：徽标的形状，默认是原型，也可以设置为方形，设置为方形的时候可以使用 borderRadius 属性设置圆角弧度。


• borderRadius：圆角的半径。


• animationType：内容改变后的动画类型，有渐现（fade）、滑动（slide）和缩放（scale）三种效果。


• showBadge：是否显示徽标，我们可以利用这个控制小红点的显示与否，比如没有提醒的时候该值设置为 false 即可隐藏掉小红点。

总的来说，这些参数能够满足所有需要使用徽标的场景了。

实例

我们来看一个实例，我们分别在导航栏右上角、内容区和底部导航栏使用了三种类型的徽标，实现效果如下。

其中导航栏的代码如下，这是 Badge 最简单的实现方式了。

AppBar(

  title: const Text('Badge Demo'),

  actions: [

    Badge(

      showBadge: _badgeNumber > 0,

      padding: const EdgeInsets.all(4.0),

      badgeContent: Text(

        _badgeNumber < 99 ? _badgeNumber.toString() : '99+',

        textAlign: TextAlign.center,

        style: const TextStyle(

          color: Colors.white,

          fontSize: 11.0,

        ),

      ),

      position: BadgePosition.topEnd(top: 4, end: 4),

      child: IconButton(

        onPressed: () {},

        icon: const Icon(

          Icons.message_outlined,

          color: Colors.white,

        ),

      ),

    ),

  ],

),

内容区的徽标代码如下，这里使用了渐变色填充，动画形式为缩放，并且将徽标放到了左上角，注意如果使用了渐变色那么会覆盖 badgeColor 指定的背景色。

Badge(

  showBadge: _badgeNumber > 0,

  padding: const EdgeInsets.all(6.0),

  badgeContent: Text(

    _badgeNumber < 99 ? _badgeNumber.toString() : '99+',

    textAlign: TextAlign.center,

    style: const TextStyle(

      color: Colors.white,

      fontSize: 10.0,

    ),

  ),

  position: BadgePosition.topStart(top: -10, start: -10),

  badgeColor: Colors.blue,

  animationType: BadgeAnimationType.scale,

  elevation: 0.0,

  gradient: const LinearGradient(

    begin: Alignment.topCenter,

    end: Alignment.bottomCenter,

    colors: [

      Colors.red,

      Colors.orange,

      Colors.green,

    ],

  ),

  child: Image.asset(

    'images/girl.jpeg',

    width: 200,

    height: 200,

  ),

),

底部导航栏的代码如下所示，这里需要注意，Badge 组件会根据内容区的尺寸自动调节大小，底部导航栏的显示控件有限，推荐使用小红点（不用数字标识）即可。

BottomNavigationBar(items: [

  BottomNavigationBarItem(

    icon: Badge(

        showBadge: _badgeNumber > 0,

        padding: const EdgeInsets.all(2.0),

        badgeContent: Text(

          _badgeNumber < 99 ? _badgeNumber.toString() : '99+',

          textAlign: TextAlign.center,

          style: const TextStyle(

            color: Colors.white,

            fontSize: 11.0,

          ),

        ),

        position: BadgePosition.topEnd(top: -4, end: -6),

        animationType: BadgeAnimationType.fade,

        child: const Icon(Icons.home_outlined)),

    label: '首页',

  ),

  const BottomNavigationBarItem(

    icon: Icon(

      Icons.star_border,

    ),

    label: '推荐',

  ),

  const BottomNavigationBarItem(

    icon: Icon(

      Icons.account_circle_outlined,

    ),

    label: '我的',

  ),

]),

总结

本篇介绍了使用 Badge 组件实现小红点徽标组件。可以看到，Badge 组件的使用非常简单，相比我们自己从零写一个 Badge 组件来说，使用它可以让我们省时省力、快速地完成运营同学要的小红点。本篇源码已上传至：实用组件相关代码。

Spotless 是什么？

这是一个代码格式化工具，我们可以定义自己想要的代码规则在需要的时候去应用它，整个过程完全自动且可以应用于整个工程。

Spotless 支持多种语言：c、c++、java、kotlin、python 等等更多，应用广泛的开发语言基本都支持。

插件丰富，支持 Gradle、Maven、SBT。并且有 IDE 插件，如：VS Code、Intellij。

社区活跃，很多优秀的开源贡献者，如：ktlint、ktfmt、prittier 等, Github 上的提交经常是几天前。

为什么要用 Spotless？

编写代码时我们都希望遵循固定的代码风格，我们使用的 IDE 也都有代码格式化功能。但是很遗憾，代码格式化都需要开发者手动触发，所以你肯定会有忘记格式化的时候。
如果你的团队有 code review 的过程，你的小伙伴或许能纠正这些问题，当然，也有可能看不到，某段代码就这样”脏“了。

虽然良好、统一的代码风格并不能提高代码性能，即使代码风格很糟糕代码也能正确编译，且运行结果并无二致。但是当你的代码有良好统一风格时，代码会更美观，有更好的阅读性，小伙伴 code review 时可以完全不用关注代码风格。

而 [Spotless](diffplug/spotless: Keep your code spotless (github.com)) 就是这样一个能让你不用关注代码风格的工具，因为它会自动帮你格式化代码。

项目整合

Gradle 配置

首先在 project build.gradle 中添加 Spotless 插件

classpath "com.diffplug.spotless:spotless-plugin-gradle:$spotless_version"

然后在 project 或 module 的 build.gradle 中做如下配置

apply plugin: 'com.diffplug.spotless'

spotless {

    java{

        target 'src/*/java/**/*.java'

        googleJavaFormat()

    }

    kotlin {

        target 'src/*/java/**/*.kt'

        ktlint('0.43.2')

    }



    format 'misc', {

        target '**/*.gradle', '**/*.md', '**/.gitignore'

    }

    format 'xml', {

        target '**/*.xml'

    }



}

结束了，就是这么简单，你需要的仅仅是去配置你想要的代码规则。具体规则配置请参考 [Spotless GitHub](spotless/plugin-gradle at main · diffplug/spotless (github.com))

Java (google-java-format, eclipse jdt, clang-format, prettier, palantir-java-format, formatAnnotations)



Kotlin (ktfmt, ktlint, diktat, prettier)

Spotless gradle task

使用 Spotless 非常简单，一般我们只需要使用两个 task

./gradlew spotlessCheck

执行 spotlessCheck 可以校验代码风格，如果有问题会报错并列出异常代码的位置

./gradlew spotlessApply

执行 spotlessApply 可以在全工程范围内自动修复代码不合规的地方。不过它只能格式化代码，如果规则需要修改代码，比如要删除某个导入的包是需要手动操作的。

从以上两步操作：配置、执行，可以看到 Spotless 的依赖成本是非常低的，使用也非常简单。它带来的好处在我看来有两点：

• 保证全工程代码风格一致，且是遵循官方代码风格规范


• 开发者编码阶段完全不需要关心代码风格问题，也不会在 review 阶段花时间更正代码风格，只关注业务价值本身

所以如果你或你的团队在关注代码风格问题，那么 Spotless 一定适合你，请尝试使用吧！

对于 Android 开发最关心的就是 java 和 kotlin 了，这两个语言都有非常多的代码规范支持，不过使用较多的是 Java「google-java-format」和 kotlin「ktlint」。随着 kotlin 在 Android 开发的占比增长，kotlin 的代码规范就显得更受关注，并且如果你关注 Google 的官方源码，你会发现 Google 的这些工程大多都是使用 ktlint 约束代码风格，这是因为 ktlin 同时支持 official Kotlin coding conventions 和 Android Kotlin Style Guide 两种风格，Android 开发者可以用 ktlint 方便的遵循 Google 代码风格。

更多 ktlint 内容请关注 [ktlint](Ktlint (pinterest.github.io))。

Android Studio lint 插件

前文提到的 google-java-format、ktlint 是都有 IDE 插件的，可以在 plugins market 中安装。

个人目前开发比较少涉及到 java ，所以 AS 并没有安装 google-java-format,有 java code format 的开发者可以在市场中安装此工具。下面我简单介绍下 AS ktlint 插件的使用体验。

比如此处多了一个空行，ktlint 会醒目标红，鼠标移过去会展示可操作的选项，可以选择 ktlint format 或禁用此规则。

安装插件后 AS 会增加一个菜单 Refactor -> Format With Ktlint，此菜单可以格式化整个文件，就与 AS 的格式化操作一样，你也可以为 Format With Ktlint 指定快捷键，操作会更方便。

在 ktlint 的 gradle 、AS 插件加持下，相信代码风格在开发中不需要特别花时间去处理了。如果代码风格不正确首先是 AS 的 error 醒目提醒，如果看到了可以一键修复。如果看不到，在执行 ./gradlew spotlessApply之后还可以全工程修复，让“脏”代码无所遁形。

Git hooks

上文介绍的配置，可能已经满足很多人了，不过还是有人会觉得，只要是手动操作的内容，那一定会有可能会忘记，有没有不需要手动操作的格式化操作。
有的有的，方案就是本小结标题 Git hooks。Ktlint 官网有一键安装 git hooks的操作，可以参考 [ktlint git hooks](Command line - Ktlint (pinterest.github.io))。

关于 git hooks 是什么可以参考这篇博文： [git hooks 简介与使用](git hooks 简介与使用 - 简书 (jianshu.com))

不过这个需要每个人都要手动去操作，其实我们可以把 git hooks 脚本文件放到我们工程里，然后通过 gradle 将脚本文件拷贝至 .git 目录

首先在项目下新建hooks目录，新建pre-commit文件:

#!/bin/sh

#

# An example hook script to verify what is about to be committed.

# Called by "git commit" with no arguments.  The hook should

# exit with non-zero status after issuing an appropriate message if

# it wants to stop the commit.

#

# To enable this hook, rename this file to "pre-commit".



./gradlew spotlessCheck

result=$?

printf "the spotlessCheck result code is $result"

if [[ "$result" = 0 ]] ; then

    echo "\033[32m

    ....

    ....

    SpotlessCheck Pass!!

    ....

    ....

    \033[0m"

    exit 0

else

    ./gradlew spotlessApply

    echo "\033[31m

    ....

    ....

    SpotlessCheck Failed!!

    代码格式有问题;

    ....

    已经自动调整格式,review代码后再git add . && git commit

    ....

    ....

    \033[0m"

    exit 1

fi

pre-commit 脚本可以根据自己需要作调整，这边仅仅是一个示例。

下一步需要将此文件拷贝至项目目录下 .git/hooks 目录，可以用 gradle 来处理拷贝事件。

task copyHooks(type: Copy) {

    println 'copyHooks task'

    from("hooks") {

        include "**"

    }

    into ".git/hooks"

}

执行此 task 就可以将项目 hooks 目录内容拷贝至 .git

完成上述操作之后，在每次执行 git commit 之前都会先执行 pre-commit，在校验失败后会自动格式化代码，开发者在 reivew 之后再重新提交。

总结

如果你在开发过程中时不时会因为代码格式化问题造成困扰，那 Spotless 及 ktlint 会完全解放你。让你无需关注代码格式的同时也能保证代码风格的一致。

ktlint 的优秀远不止此篇文中所述，这仅仅是一篇指导文，大家可以去探索更适合自己项目的方法。

希望此文能让大家了解 Spotless 并尝试使用，谢谢！

响应式编程

因为 Kotlin Flow 是基于 响应式编程 的实现，所以先了解一下 响应式编程 的概念。

首先看下百度百科解释：

响应式编程是一种面向数据流和变化传播的编程范式。这意味着可以在编程语言中很方便地表达静态或动态的数据流，而相关的计算模型会自动将变化的值通过数据流进行传播。

这个释义很抽象，难以理解。只知道它的核心是：数据流。

如何理解这个数据流，先看下响应式编程 ReactiveX 下的一个框架 RxJava 。

RxJava 是基于响应式编程的实现，它的定义：

RxJava 是 Reactive Extensions 的 Java VM 实现：一个通过使用可观察序列来组合异步和基于事件的程序的库。
它扩展了观察者模式以支持数据/事件序列，并添加了运算符，允许您以声明方式组合序列，同时消除了对低级线程、同步、线程安全和并发数据结构等问题的担忧。

看完这个定义，脑袋中也很模糊。下面从 RxJava 应用的一个简单例子来分析：

   Observable.just(bitmap).map { bmp->

            //在子线程中执行耗时操作，存储 bitmap 到本地

            saveBitmap(bmp)

        }.subscribeOn(Schedulers.io()).observeOn(AndroidSchedulers.mainThread()).subscribe { bitmapLocalPath ->

                //在主线程中处理存储 bitmap 后的本地路径地址

                refreshImageView(bitmapLocalPath)

        }

上面例子中： 将一个 bitmap 存储到本地并返回本地路径，从源数据 bitmap → 存储 btimap 到本地操作 → 获取本地图片路径值刷新UI。其实，就可以把这整个过程中按时间发生的事件序列理解为数据流。

数据流包含提供方（生产者），中介（中间操作），使用方（消费者）：

• 提供方（生产者）：源数据，将数据添加到数据流中；


• 中介（中间操作）：可以修改发送到数据流的值，或修正数据流本身；


• 使用方（消费者）：结果数据，使用数据流中的值。

那么，上面例子中的数据流是：

• 提供方（生产者）：源数据 bitmap；


• 中介（中间操作）：map 操作，存储 btimap 到本地；


• 使用方（消费者）：本地图片路径。

再看下 RxJava 中的数据流解释：

RxJava 中的数据流由源、零个或多个中间步骤组成，然后是数据消费者或组合器步骤（其中该步骤负责通过某种方式消费数据流）：

source.operator1().operator2().operator3().subscribe(consumer);
source.flatMap(value -> source.operator1().operator2().operator3());

在这里，如果我们想象自己在操作符 operator2 上，向左看 source 被称为上游。向右看 subscriber/consumer 称为下游。当每个元素都写在单独的行上时，这一点通常更为明显：

source

  .operator1()

  .operator2()

  .operator3()

  .subscribe(consumer)

这也是 RxJava 的上游、下游概念。

其实，Flow 数据流中参看 RxJava，也可以有这样类似的上游和下游概念：

flow

  .operator1()

  .operator2()

  .operator3()

  .collect(consumer)

了解了 响应式编程 的核心 数据流 后，对 响应式编程 有了初步印象。但是 响应式编程 的实现远不止如此，它还涉及观察者模式，线程调度等。不管原理这些，用它来做开发有什么好处呢？其实，它主要优点是：

• 对于并发编程，线程切换，没有 callback hell，简化了异步执行的代码；


• 代码优雅，简洁，易阅读和维护。

下面看两个业务例子：

     Observable.just(bitmap).map { bmp ->

            //在子线程中执行耗时操作，存储 bitmap 到本地

            saveBitmap(bmp)

        }.map { path ->

            //在子线程中执行耗时操作，上传图片到服务端

            uploadBitmap(path)

        }.subscribeOn(Schedulers.io()).observeOn(AndroidSchedulers.mainThread())

            .subscribe { downloadUrl ->

                //在主线程中处理获取图片下载地址

            }

        //从服务端批量下载文件

        Observable.from(downloadUrls).flatMap { downloadUrl ->

            //下载单个文件，返回本地文件

            Observable.just(downloadUrl).map {url-> downloadResource(url) }

        }.map { file ->

            //对文件解压

            unzipFile(file)

        }.subscribeOn(Schedulers.io()).observeOn(AndroidSchedulers.mainThread())

            .subscribe { folderPath ->

                //拿到文件夹路径

            }

所以 响应式编程 的实现，主要是帮我们解决了 并发编程问题，能用优雅简洁的代码做异步事件处理。

Kotlin 协程 和 Flow，它们结合在一起也实现了 响应式编程。在 Kotlin 环境中，再结合 Android 提供 Lifecycle, ViewModel, Flow 的扩展，能让我们在 Android 中做并发编程，异步事件管理如鱼得水。

Kotlin Flow

Kotlin Flow 就是 Kotlin 数据流，它基于 Kotlin 协程构建。上一篇 Kotlin 协程探索 分析了 协程 的大致原理，知道协程就是 Kotlin 提供的一套线程 API 框架，方便做并发编程。那么 Kotlin 协程 和 Flow （数据流）的结合，和 RxJava 框架就有异曲同工之妙。

下面使用 Kotlin 协程 和 Flow 来实现上面 RxJava 的两个业务例子：

        GlobalScope.launch(Dispatchers.Main) {

            flowOf(bitmap).map { bmp ->

                //在子线程中执行耗时操作，存储 bitmap 到本地

                Log.d("TestFlow", "saveBitmap: ${Thread.currentThread()}")

                saveBitmap(bmp)

            }.flowOn(Dispatchers.IO).collect { bitmapLocalPath ->

                //在主线程中处理存储 bitmap 后的本地路径地址

                Log.d("TestFlow", "bitmapLocalPath=$bitmapLocalPath: ${Thread.currentThread()}")

            }

        }

        //从服务端批量下载文件

        GlobalScope.launch(Dispatchers.Main) {

            downloadUrls.asFlow().flatMapConcat { downloadUrl ->

                //下载单个文件，返回本地文件

                flowOf(downloadUrl).map { url ->

                    Log.d("TestFlow", "downloadResource:url=$url: ${Thread.currentThread()}")

                    downloadResource(url)

                }

            }.map { file ->

                //对文件解压

                Log.d("TestFlow", "unzipFile:file=${file.path}: ${Thread.currentThread()}")

                unzipFile(file)

            }.flowOn(Dispatchers.IO).collect { folderPath ->

                //拿到文件夹路径

                Log.d("TestFlow", "folderPath=$folderPath: ${Thread.currentThread()}")

            }

        }

控制台结果输出：

TestFlow: saveBitmap: Thread[DefaultDispatcher-worker-1,5,main]

TestFlow: bitmapLocalPath=/mnt/sdcard/Android/data/com.wangjiang.example/files/images/flow.png: Thread[main,5,main]



TestFlow: downloadResource:url=https://www.wangjiang.example/coroutine.zip: Thread[DefaultDispatcher-worker-1,5,main]

TestFlow: unzipFile:file=/mnt/sdcard/Android/data/com.wangjiang.example/files/zips/coroutine.zip: Thread[DefaultDispatcher-worker-1,5,main]

TestFlow: downloadResource:url=https://www.wangjiang.example/flow.zip: Thread[DefaultDispatcher-worker-1,5,main]

TestFlow: unzipFile:file=/mnt/sdcard/Android/data/com.wangjiang.example/files/zips/flow.zip: Thread[DefaultDispatcher-worker-1,5,main]

TestFlow: folderPath=/mnt/sdcard/Android/data/com.wangjiang.example/files/zips/coroutine: Thread[main,5,main]

TestFlow: folderPath=/mnt/sdcard/Android/data/com.wangjiang.example/files/zips/flow: Thread[main,5,main]

可以看到，和 RxJava 实现的效果是一致的。首先，使用launch启动一个协程，然后使用源数据创建一个 Flow（数据生产），再经过 flatMapConcat, map 变换（多个中间操作），最后通过collect获取结果数据（数据消费），这其中还包括线程切换：在主线程中启动子线程执行耗时任务，并将耗时任务结果返回给主线程（flowOn 指定了中间操作在 IO 线程中执行）。所以 协程 和 Flow（数据流） 结合，就是 响应式编程 的实现，这对我们来说，使用它可以在 Kotlin 环境中写出优雅的异步代码来做并发编程。

下面再分别来熟悉一下 协程 和 Flow。

协程概念

首先来看一下协程中的一些概念和 API。

CoroutineScope: 定义协程的 scope。

CoroutineScope 会跟踪它使用 launch 或 async 创建的所有协程。您可以随时调用 scope.cancel() 以取消正在进行的工作（即正在运行的协程）。在 Android 中，某些 KTX 库为某些生命周期类提供自己的 CoroutineScope。例如，ViewModel 有 viewModelScope，Lifecycle 有 lifecycleScope。不过，与调度程序不同，CoroutineScope 不运行协程。

Kotlin 提供了为 UI 组件使用的 MainScope：

public fun MainScope(): CoroutineScope = ContextScope(SupervisorJob() + Dispatchers.Main)

为应用程序整个生命周期使用的 GlobalScope:

public object GlobalScope : CoroutineScope {

    /**

     * Returns [EmptyCoroutineContext].

     */

    override val coroutineContext: CoroutineContext

        get() = EmptyCoroutineContext

}

因为是应用程序整个生命周期，所以要慎重使用。

也可以自定义 Scope：

val scope = CoroutineScope(Job() + Dispatchers.Main)

另外，Android KTX 库针对 CoroutineScope 做了扩展，所以在 Android 中通常会使用 Activity 或 Fragment 生命周期相关的 lifecycleScope，和 ViewModel 生命周期相关的viewModelScope 。

public val Lifecycle.coroutineScope: LifecycleCoroutineScope

    get() {

        while (true) {

            val existing = mInternalScopeRef.get() as LifecycleCoroutineScopeImpl?

            if (existing != null) {

                return existing

            }

            val newScope = LifecycleCoroutineScopeImpl(

                this,

                SupervisorJob() + Dispatchers.Main.immediate

            )

            if (mInternalScopeRef.compareAndSet(null, newScope)) {

                newScope.register()

                return newScope

            }

        }

    }

public val ViewModel.viewModelScope: CoroutineScope

    get() {

        val scope: CoroutineScope? = this.getTag(JOB_KEY)

        if (scope != null) {

            return scope

        }

        return setTagIfAbsent(

            JOB_KEY,

            CloseableCoroutineScope(SupervisorJob() + Dispatchers.Main.immediate)

        )

    }



internal class CloseableCoroutineScope(context: CoroutineContext) : Closeable, CoroutineScope {

    override val coroutineContext: CoroutineContext = context



    override fun close() {

        coroutineContext.cancel()

    }

}

启动协程: launch 和 async

启动协程有两种方式：

• launch ：启动一个新的协程，并返回一个 Job，这个 Job 是可以取消的 Job.cancel；


• async ：也会启动一个新的协程，并返回一个 Deferred 接口实现，这个接口其实也继承了Job 接口，可以使用 await 挂起函数等待返回结果。

CoroutineContext: 协程上下文

val scope = CoroutineScope(Job() + Dispatchers.Main)

在 CoroutineScope 中定义了 plus 操作：

public operator fun CoroutineScope.plus(context: CoroutineContext): CoroutineScope =

    ContextScope(coroutineContext + context)

因为 Job 和 Dispatchers 顶层都继承了接口 Element，而 Element 又继承了接口 CoroutineContext:

public interface Element : CoroutineContext

所以 Job() 和 Dispatchers.Main 可以相加。这里 CoroutineScope 的构造方法中是必须要有 Job()，如果没有，它自己也会创建一个 Job()：

public fun CoroutineScope(context: CoroutineContext): CoroutineScope =

    ContextScope(if (context[Job] != null) context else context + Job())

Job 和 CoroutineDispatcher 在 CoroutineContext 中的作用是：

Job：控制协程的生命周期。
CoroutineDispatcher：将工作分派到适当的线程。

CoroutineDispatcher：协程调度器与线程

• Dispatchers.Default：默认调度器，指示此协程应在为 cpu 计算操作预留的线程上执行；


• Dispatchers.Main：指示此协程应在为 UI 操作预留的主线程上执行；


• Dispatchers.IO：指示此协程应在为 I/O 操作预留的线程上执行。

GlobalScope.launch(Dispatchers.Main) {

}

withContext(Dispatchers.IO){

}

.flowOn(Dispatchers.IO)

小结

要使用协程，首先创建一个 scope: CoroutineScope 来负责管理协程，定义scope 时需要指定控制协程的生命周期的 Job和将工作分派到适当线程的CoroutineDispatcher。定义好 scope 后， 可通过 scope.launch启动一个协程，也可以多次使用scope.launch启动多个协程，启动的协程可通过 scope.cancel取消，但它取消的是 scope 启动的所有协程。如果要取消单个协程，需要使用scope.launch返回的 Job 来取消Job.cancel，这个 Job 控制着单个协程的生命周期。当启动协程后，主线程中的任务依然可以继续执行，在执行launch{}时，可以通过 withContext(Dispatchers.IO)将协程的执行操作移至一个 I/O 子线程，子线程执行完任务，再将结果返回主线程继续执行。

简单示例：

    //主线程分派任务

    private val scope = CoroutineScope(Job() + Dispatchers.Main)



    //管理对应的协程的生命周期

    private var job1: Job? = null



    fun exec() {

        //启动一个协程

        job1 = scope.launch {

            //子线程执行耗时任务

            withContext(Dispatchers.IO){



            }

        }

        //启动一个协程

        val job2 = scope.launch {

            //启动一个协程

            val taskResult1 = async {

                //子线程执行耗时任务

                withContext(Dispatchers.IO){



                }

            }

            val taskResult2 = async {

                //子线程执行耗时任务

                withContext(Dispatchers.IO){



                }

            }

            //taskResult1 和 taskResult2 都返回结果才会继续执行

            taskResult1.await() + taskResult2.await()

        }

    }



    fun cancelJob() {

        //取消 job1 对应的协程

        job1?.cancel("cancel job1")

    }



    fun cancelScope() {

        //取消 scope 对应的所有协程

        scope.cancel("cancel scope")

    }

在上面的例子中：

• scope：定义主线程分派任务的 scope 来跟踪它使用 launch 或 async 创建的所有协程；


• job1：管理它对应的协程的生命周期；


• withContext(Dispatchers.IO)：切换到子线程执行耗时任务；


• cancelJob 会取消 job1 对应的协程；


• cancelScope 会取消 scope 启动的所有协程。

Flow 数据流

了解了 Kotlin 协程的一些基础 概念和 API 后，知道了协程的基本使用。接下来，再了解一下 Kotlin Flow 相关的概念和 API。

Kotlin 中的 Flow API 旨在异步处理按顺序执行的数据流。Flow 本质上是一个 Sequence。我们可以像对 Kotlin 中 Sequence 一样来操作Flow：变换，过滤，映射等。Kotlin Sequences 和 Flow 的主要区别在于 Flow 可以挂起。

如果有理解 Kotlin Sequence，那其实很好理解 Kotlin Flow。刚好，在前面一篇 Kotlin 惰性集合操作-序列 Sequence文章中，有分析 Sequence 的原理，这里也可以把 Flow 按照类似的原理进行理解。

val sequenceResult = intArrayOf(1, 2, 3).asSequence().map { it * it }.toList()



 MainScope().launch{

            val flowResult = intArrayOf(1, 2, 3).asFlow().map { it * it }.toList(mutableListOf())

        }

上面 sequenceResult 和 flowResult 的值都是：[1, 4, 9]。

在 Sequence 中，如果没有末端操作，中间操作不会被执行。在 Flow 中也是一样，如果数据流没有数据消费collect ，中间操作也不会被执行。

flowOf(bitmap).map { bmp ->

                //在子线程中执行耗时操作，存储 bitmap 到本地

                saveBitmap(bmp)

            }.flowOn(Dispatchers.Default)

上面代码中，map 操作不会被执行。

一个完整的数据流应该包含：数据生产（ flowOf , asFlow, flow{} ）→ 中间操作（map, filter等）→ 数据消费（collect,asList,asSet等）。下面将分别了解相关操作。

数据流：数据生产

数据生产主要是通过数据源构建数据流。可以使用 Builders.kt 中提供的 Flow 相关扩展方法，如：

intArrayOf(1, 2, 3).asFlow().map { it * it }

val downloadUrl = "https://github.com/ReactiveX/RxJava"

flowOf(downloadUrl).map { downloadZip(it) }

(1..10).asFlow().filter { it % 2 == 0 }

通常使用 flowOf 和 asFlow方法直接构建数据流。它们创建的都是冷流：

冷流：这段 flow 构建器中的代码直到流被收集（collect）的时候才运行。

也可以通过 flow{} 来构建数据流，使用emit方法将数据源添加到数据流中：

    flow<Int> {

            emit(1)

            withContext(Dispatchers.IO){

                emit(2)

            }

            emit(3)

        }.map { it * it }

不管是 flowOf，asFlow 还是 flow{}，它们都会实现接口 FlowCollector：

public fun <T> flow(@BuilderInference block: suspend FlowCollector<T>.() -> Unit): Flow<T> = SafeFlow(block)



internal inline fun <T> unsafeFlow(@BuilderInference crossinline block: suspend FlowCollector<T>.() -> Unit): Flow<T> {

    return object : Flow<T> {

        override suspend fun collect(collector: FlowCollector<T>) {

            collector.block()

        }

    }

}

接口 FlowCollector 提供的 emit 方法，负责将源数据添加到数据流中：

public fun interface FlowCollector<in T> {



    /**

     * Collects the value emitted by the upstream.

     * This method is not thread-safe and should not be invoked concurrently.

     */

    public suspend fun emit(value: T)

}

总结：构建数据流可以使用 Flow 相关扩展方法： flowOf , asFlow, flow{}，它们都是通过接口 FlowCollector 提供的 emit 方法，将源数据添加到数据流中。

数据流：中间操作

中间操作主要修改发送到数据流的值，或修正数据流本身。如 filter, map, flatMapConcat 操作等：

intArrayOf(1, 2, 3).asFlow().map { it * it }.collect{ }



(1..100).asFlow().filter { it % 2 == 0 }.collect{ }



val data = hashMapOf<String, List<String>>(

                "Java" to arrayListOf<String>("xiaowang", "xiaoli"),

                "Kotlin" to arrayListOf<String>("xiaozhang", "xiaozhao")

            )

flow<Map<String, List<String>>> {

                emit(data)

            }.flatMapConcat {

                it.values.asFlow()

            }.collect{ }

中间操作符有很多，根据使用场景大概可分为：

• 转换操作符：简单转换可以使用过滤 filter，映射 map操作，复杂转换可以使用变换 transform操作；


• 限长过渡操作符：在流触及相应限制的时候会将它的执行取消，可以使用获取 take操作，take(2)表示只获取前两个值；


• 丢弃操作符：丢弃流中结果值，可以使用丢弃 drop 操作，drop(2)表示丢弃前两个值；


• 展平操作符：将给定的流展平为单个流，flatMapConcat 与 flattenConcat 操作表示顺序收集传入的流操作，flatMapMerge与flattenMerge操作表示并发收集所有传入的流，并将它们的值合并到一个单独的流，以便尽快的发射值操作，flatMapLatest 操作表示以展平的方式收集最新的流操作；


• 组合操作符：将多个流组合，zip操作表示组合两个流的值，两个流都有值才进行组合操作，combine 操作表示组合两个流最新的值，每次组合的时候都是使用每个流最新的值；


• 缓冲操作符：当数据生产比数据消费快的时候，可以使用缓冲buffer操作，在数据消费的时候可以缩短时间；


• 合并操作符：合并发射项，不对每个值进行处理，可以使用合并conflate 操作，跳过中间值；


• flowOn 操作符：更改流发射的上下文，会将 flowOn操作前的操作切换到 flowOn 指定的上下文Dispatchers.Default，Dispatchers.IO，Dispatchers.Main，也就是指定前面的操作所执行的线程；

上面介绍了主要的操作符的大致使用场景，操作符详细解释可以查看官方文档：异步流。

中间操作符代码示例：

(1..3).asFlow().take(2).collect{

                //收集到结果值 1，2

            }

(1..3).asFlow().drop(2).collect{

                //收集到结果值 3

            }

    private fun downloadVideo(videoUrl: String): Pair<String, String> {

        return Pair(videoUrl, "videoFile")

    }



    private fun downloadAudio(audioUrl: String): Pair<String, String> {

        return Pair(audioUrl, "audioFile")

    }



    private fun downloadImage(imageUrl: String): Pair<String, String> {

        return Pair(imageUrl, "imageFile")

    }

    

  MainScope().launch {

            val imageDownloadUrls = arrayListOf<String>("image1", "image2")

            val audioDownloadUrls = arrayListOf<String>("audio1", "audio2", "audio3")

            val videoDownloadUrls = arrayListOf<String>("video1", "video2", "video3", "video4")

            val imageFlows = imageDownloadUrls.asFlow().map {

                downloadImage(it)

            }

            val audioFlows = audioDownloadUrls.asFlow().map {

                downloadAudio(it)

            }

            val videoFlows = videoDownloadUrls.asFlow().map {

                downloadVideo(it)

            }

            merge(imageFlows, audioFlows, videoFlows).flowOn(Dispatchers.IO).onEach {

                Log.d("TestFlow", "result=$it")

            }.collect()

        }

控制台输出结果：

TestFlow: result=(image1, imageFile)

TestFlow: result=(image2, imageFile)

TestFlow: result=(audio1, audioFile)

TestFlow: result=(audio2, audioFile)

TestFlow: result=(audio3, audioFile)

TestFlow: result=(video1, videoFile)

TestFlow: result=(video2, videoFile)

TestFlow: result=(video3, videoFile)

TestFlow: result=(video4, videoFile)



merge 操作符将多个流合并到一个流，支持并发。类似 RxJava 的 zip 操作

(1..3).asFlow().onStart {

                Log.d("TestFlow", "onStart:${Thread.currentThread()}")

            }.flowOn(Dispatchers.Main).map {

                Log.d("TestFlow", "map:$it,${Thread.currentThread()}")

                if (it % 2 == 0)

                    throw IllegalArgumentException("fatal args:$it")

                it * it

            }.catch {

                Log.d("TestFlow", "catch:${Thread.currentThread()}")

                emit(-1)

            }.flowOn(Dispatchers.IO)

                .onCompletion { Log.d("TestFlow", "onCompletion:${Thread.currentThread()}") }

                .onEach {

                    Log.d("TestFlow", "onEach:$it,${Thread.currentThread()}")

                }.collect()

控制台输出结果：

TestFlow: onStart:Thread[main,5,main]

TestFlow: map:1,Thread[DefaultDispatcher-worker-3,5,main]

TestFlow: map:2,Thread[DefaultDispatcher-worker-3,5,main]

TestFlow: catch:Thread[DefaultDispatcher-worker-3,5,main]

TestFlow: onEach:1,Thread[main,5,main]

TestFlow: onEach:-1,Thread[main,5,main]

TestFlow: onCompletion:Thread[main,5,main]



flowOn 指定 onStart 在主线程中执行（Dispatchers.Main），指定 map 和 catch 在 IO 线程中执行（Dispatchers.IO）

总结：中间操作其实就是数据流的变换操作，与 Sequence 和 RxJava 的变换操作类似。

数据流：数据消费

数据消费就是使用数据流的结果值。末端操作符最常使用 collect来收集流结果值：

 (1..3).asFlow().collect{

                //收集到结果值 1，2，3

            }

除了 collect 操作符外，还有一些操作符可以获取数据流结果值：

• collectLatest：使用数据流的最新值；


• toList 或 toSet等：将数据流结果值转换为集合；


• first：获取数据流的第一个结果值；


• single：确保流发射单个（single）值；


• reduce ：累积数据流中的值；


• fold ：给定一个初始值，再累积数据流中的值。

末端操作符代码示例：

  (1..3).asFlow().collectLatest {

                delay(300)

                //只能获取到3

            }

//转换为 List 集合 [1,2,3]

 val list = (1..3).asFlow().toList()

 //转换为 Set 集合 [1,2,3]

 val set = (1..3).asFlow().toSet()

val first = (1..3).asFlow().first()

//first 为第一个结果值 1

val single = (1..3).asFlow().single()

//流不是发射的单个值，会抛异常

val reduce = (1..3).asFlow().reduce { a, b ->

                a + b

            }

//reduce 的值为6=1+2+3            

val fold = (1..3).asFlow().fold(10) { a, b ->

                a + b

            }

 //fold 的值为16=10+1+2+3     

除了上面这些末端操作符，在末端之前还关联着一些操作符：

• onStart：在数据流结果值收集之前调用；


• onCompletion：在数据流结果值收集之后调用；


• onEmpty：在数据流完成而不发出任何元素时调用；


• onEach：在数据流结果值收集时迭代流的每个值；


• catch ：在收集数据流结果时，声明式捕获异常。

末端关联操作符代码示例：

 (1..3).asFlow().onStart {

                Log.d("TestFlow", "onStart")

            }.map {

                if (it % 2 == 0)

                    throw IllegalArgumentException("fatal args:$it")

                it * it

            }.catch { emit(-1) }.onCompletion { Log.d("TestFlow", "onCompletion") }.onEach {

                Log.d("TestFlow", "onEach:$it")

            }.collect()

            

控制台输出结果：

TestFlow: onStart

TestFlow: onEach:1

TestFlow: onEach:-1

TestFlow: onCompletion

总结：数据流进行数据消费时，可以结合末端操作符输出集合，累积值等，当要监听数据流收集结果值开始或结束，可以使用 onStart 和 onCompletion，当遇到流抛出异常，可以声明 catch进行异常处理。

总结

响应式编程，可以理解为一种面向数据流编程的方式，也就是使用数据源构建数据流 → 修改数据流中的值 → 处理数据流结果值，在这个过程中，一系列的事件或操作都是按顺序发生的。在 Java 环境中，RxJava 框架实现了响应式编程，它结合了数据流、观察者模式、线程框架；在 Kotlin 环境中，Kotlin 协程和 Flow 结合在一起实现了响应式编程，其中协程就是线程框架，Flow 就是数据流。不管是 RxJava 还是 Kotlin 协程和 Flow 的实现的响应式编程，它们的目的都是为了：使用优雅，简洁，易阅读，易维护的代码来编写并发编程，处理异步操作事件。另外，Android LifeCycle 和 ViewModel 对 Kotlin 协程和 Flow 进行了扩展支持，这也对异步事件进行生命周期管理更方便。

参考文档：

• GitHub RxJava：RxJava


• Kotlin Flow 操作符：异步流


• Google Android developer Kotlin Flow ：Android 上的 Kotlin 数据流

下一篇将探索 Kotlin Flow 冷流和热流。

背景说明

原本已经基于系统方案适配了暗黑主题，实现了白/黑两套皮肤，以及跟随系统。后来老板研究学习友商时，发现友商 App 有三套皮肤可选，除了常规的亮白和暗黑，还有一套暗蓝色。并且在跟随系统暗黑模式下，用户可选暗黑还是暗蓝。这不，新的需求马上就来了。

其实我们之前两个 App 的换肤方案都是使用 Android-skin-support 来做的，在此基础上再加套皮肤也不是难事。但在新的 App 实现多皮肤时，由于前两个 App 做了这么久都只有两套皮肤，而且新的 App 需要实现跟随系统，为了更好的体验和较少的代码实现，就采用了系统方案进行适配暗黑模式。

以 Android-skin-support 和系统两种方案适配经验来看，系统方案适配改动的代码更少，所花费的时间当然也就更少了。所以在需要新添一套皮肤的时候，也不可能再去切方案了。那么在使用系统方案的情况下，如何再加一套皮肤呢？来，先看源码吧。

源码分析

以下源码基于 android-31

首先，在代码中获取资源一般通过 Context 对象的一些方法，例如：

// Context.java



@ColorInt

public final int getColor(@ColorRes int id) {

    return getResources().getColor(id, getTheme());

}



@Nullable

public final Drawable getDrawable(@DrawableRes int id) {

    return getResources().getDrawable(id, getTheme());

}

可以看到 Context 是通过 Resources 对象再去获取的，继续看 Resources：

// Resources.java



@ColorInt

public int getColor(@ColorRes int id, @Nullable Theme theme) throws NotFoundException {

    final TypedValue value = obtainTempTypedValue();

    try {

        final ResourcesImpl impl = mResourcesImpl;

        impl.getValue(id, value, true);

        if (value.type >= TypedValue.TYPE_FIRST_INT 

            && value.type <= TypedValue.TYPE_LAST_INT) {

            return value.data;

        } else if (value.type != TypedValue.TYPE_STRING) {

            throw new NotFoundException("Resource ID #0x" + Integer.toHexString(id)                                  											+ " type #0x" + Integer.toHexString(value.type) + " is not valid");

        }

        // 这里调用 ResourcesImpl#loadColorStateList 方法获取颜色

        final ColorStateList csl = impl.loadColorStateList(this, value, id, theme);

        return csl.getDefaultColor();

    } finally {

      	releaseTempTypedValue(value);

    }

}



public Drawable getDrawable(@DrawableRes int id, @Nullable Theme theme) 

        throws NotFoundException {

    return getDrawableForDensity(id, 0, theme);

}



@Nullable

public Drawable getDrawableForDensity(@DrawableRes int id, int density, @Nullable Theme theme) {

    final TypedValue value = obtainTempTypedValue();

    try {

        final ResourcesImpl impl = mResourcesImpl;

        impl.getValueForDensity(id, density, value, true);

      	// 看到这里

        return loadDrawable(value, id, density, theme);

    } finally {

      	releaseTempTypedValue(value);

    }

}



@NonNull

@UnsupportedAppUsage(maxTargetSdk = Build.VERSION_CODES.R, trackingBug = 170729553)

Drawable loadDrawable(@NonNull TypedValue value, int id, int density, @Nullable Theme theme)

        throws NotFoundException {

    // 这里调用 ResourcesImpl#loadDrawable 方法获取 drawable 资源

    return mResourcesImpl.loadDrawable(this, value, id, density, theme);

}

到这里我们知道在代码中获取资源时，是通过 Context -> Resources -> ResourcesImpl 调用链实现的。

先看 ResourcesImpl.java：

/**

 * The implementation of Resource access. This class contains the AssetManager and all caches

 * associated with it.

 *

 * {@link Resources} is just a thing wrapper around this class. When a configuration change

 * occurs, clients can retain the same {@link Resources} reference because the underlying

 * {@link ResourcesImpl} object will be updated or re-created.

 *

 * @hide

 */

public class ResourcesImpl {

    ...

}

虽然是 public 的类，但是被 @hide 标记了，意味着想通过继承后重写相关方法这条路行不通了，pass。

再看 Resources.java，同样是 public 类，但没被 @hide 标记。我们就可以通过继承 Resources 类，然后重写 Resources#getColor 和 Resources#getDrawableForDensity 等方法来改造获取资源的逻辑。

先看相关代码：

// SkinResources.kt



class SkinResources(context: Context, res: Resources) : Resources(res.assets, res.displayMetrics, res.configuration) {



    val contextRef: WeakReference<Context> = WeakReference(context)



    override fun getDrawableForDensity(id: Int, density: Int, theme: Theme?): Drawable? {

        return super.getDrawableForDensity(resetResIdIfNeed(contextRef.get(), id), density, theme)

    }



    override fun getColor(id: Int, theme: Theme?): Int {

        return super.getColor(resetResIdIfNeed(contextRef.get(), id), theme)

    }

  

    private fun resetResIdIfNeed(context: Context?, resId: Int): Int {

        // 非暗黑蓝无需替换资源 ID

        if (context == null || !UIUtil.isNightBlue(context)) return resId



        var newResId = resId

        val res = context.resources

        try {

            val resPkg = res.getResourcePackageName(resId)

            // 非本包资源无需替换

            if (context.packageName != resPkg) return newResId



            val resName = res.getResourceEntryName(resId)

            val resType = res.getResourceTypeName(resId)

          	// 获取对应暗蓝皮肤的资源 id

            val id = res.getIdentifier("${resName}_blue", resType, resPkg)

            if (id != 0) newResId = id

        } finally {

            return newResId

        }

    }



}

主要原理与逻辑：

• 所有资源都会在 R.java 文件中生成对应的资源 id，而我们正是通过资源 id 来获取对应资源的。


• Resources 类提供了 getResourcePackageName/getResourceEntryName/getResourceTypeName 方法，可通过资源 id 获取对应的资源包名/资源名称/资源类型。


• 过滤掉无需替换资源的场景。


• Resources 还提供了 getIdentifier 方法来获取对应资源 id。


• 需要适配暗蓝皮肤的资源，统一在原资源名称的基础上加上 _blue 后缀。


• 通过 Resources#getIdentifier 方法获取对应暗蓝皮肤的资源 id。如果没找到，改方法会返回 0。

现在就可以通过 SkinResources 来获取适配多皮肤的资源了。但是，之前的代码都是通过 Context 直接获取的，如果全部替换成 SkinResources 来获取，那代码改动量就大了。

我们回到前面 Context.java 的源码，可以发现它获取资源时，都是通过 Context#getResources 方法先得到 Resources 对象，再通过其去获取资源的。而 Context#getResources 方法也是可以重写的，这意味着我们可以维护一个自己的 Resources 对象。Application 和 Activity 也都是继承自 Context 的，所以我们在其子类中重写 getResources 方法即可：

// BaseActivity.java/BaseApplication.java



private Resources mSkinResources;



@Override

public Resources getResources() {

    if (mSkinResources == null) {

      	mSkinResources = new SkinResources(this, super.getResources());

    }

    return mSkinResources;

}

到此，基本逻辑就写完了，马上 build 跑起来。

咦，好像有点不太对劲，有些 color 或 drawable 没有适配成功。

经过一番对比，发现 xml 布局中的资源都没有替换成功。

那么问题在哪呢？还是先从源码着手，先来看看 View 是如何从 xml 中获取并设置 background 属性的：

// View.java



public View(Context context, @Nullable AttributeSet attrs, int defStyleAttr, int defStyleRes) {

  	this(context);

  	

    // AttributeSet 是 xml 中所有属性的集合

    // TypeArray 则是经过处理过的集合，将原始的 xml 属性值（"@color/colorBg"）转换为所需的类型，并应用主题和样式

    final TypedArray a = context.obtainStyledAttributes(

            attrs, com.android.internal.R.styleable.View, defStyleAttr, defStyleRes);



    ...

    

    Drawable background = null;

  	

    ...

    

    final int N = a.getIndexCount();

  	for (int i = 0; i < N; i++) {

      	int attr = a.getIndex(i);

      	switch (attr) {

            case com.android.internal.R.styleable.View_background:

                // TypedArray 提供一些直接获取资源的方法

              	background = a.getDrawable(attr);

              	break;

            ...

        }

    }

  

    ...

     

    if (background != null) {

      	setBackground(background);

    }

  

    ...

}

再接着看 TypedArray 是如何获取资源的：

// TypedArray.java



@Nullable

public Drawable getDrawable(@StyleableRes int index) {

    return getDrawableForDensity(index, 0);

}



@Nullable

public Drawable getDrawableForDensity(@StyleableRes int index, int density) {

    if (mRecycled) {

      	throw new RuntimeException("Cannot make calls to a recycled instance!");

    }



    final TypedValue value = mValue;

    if (getValueAt(index * STYLE_NUM_ENTRIES, value)) {

        if (value.type == TypedValue.TYPE_ATTRIBUTE) {

            throw new UnsupportedOperationException(

                "Failed to resolve attribute at index " + index + ": " + value);

        }



        if (density > 0) {

            // If the density is overridden, the value in the TypedArray will not reflect this.

            // Do a separate lookup of the resourceId with the density override.

            mResources.getValueForDensity(value.resourceId, density, value, true);

        }

      	// 看到这里

        return mResources.loadDrawable(value, value.resourceId, density, mTheme);

    }

    return null;

}

TypedArray 是通过 Resources#loadDrawable 方法来加载资源的，而我们之前写 SkinResources 的时候并没有重写该方法，为什么呢？那是因为该方法是被 @UnsupportedAppUsage 标记的。所以，这就是 xml 布局中的资源替换不成功的原因。

这个问题又怎么解决呢？

之前采用 Android-skin-support 方案做换肤时，了解到它的原理，其会替换成自己的实现的 LayoutInflater.Factory2，并在创建 View 时替换生成对应适配了换肤功能的 View 对象。例如：将 View 替换成 SkinView，而 SkinView 初始化时再重新处理 background 属性，即可完成换肤。

AppCompat 也是同样的逻辑，通过 AppCompatViewInflater 将普通的 View 替换成带 AppCompat- 前缀的 View。

其实我们只需能操作生成后的 View，并且知道 xml 中写了哪些属性值即可。那么我们完全照搬 AppCompat 这套逻辑即可：

• 定义类继承 LayoutInflater.Factory2，并实现 onCreateView 方法。


• onCreateView 主要是创建 View 的逻辑，而这部分逻辑完全 copy AppCompatViewInflater 类即可。


• 在 onCreateView 中创建 View 之后，返回 View 之前，实现我们自己的逻辑。


• 通过 LayoutInflaterCompat#setFactory2 方法，设置我们自己的 Factory2。

相关代码片段：

public class SkinViewInflater implements LayoutInflater.Factory2 {

    @Nullable

    @Override

    public View onCreateView(@Nullable View parent, @NonNull String name, @NonNull Context context, @NonNull AttributeSet attrs) {

      	// createView 方法就是 AppCompatViewInflater 中的逻辑

        View view = createView(parent, name, context, attrs, false, false, true, false);

        onViewCreated(context, view, attrs);

        return view;

    }



    @Nullable

    @Override

    public View onCreateView(@NonNull String name, @NonNull Context context, @NonNull AttributeSet attrs) {

        return onCreateView(null, name, context, attrs);

    }



    private void onViewCreated(@NonNull Context context, @Nullable View view, @NonNull AttributeSet attrs) {

      	if (view == null) return;

        resetViewAttrsIfNeed(context, view, attrs);

    }

  

    private void resetViewAttrsIfNeed(Context context, View view, AttributeSet attrs) {

      	if (!UIUtil.isNightBlue(context)) return;

      

      	String ANDROID_NAMESPACE = "http://schemas.android.com/apk/res/android";

      	String BACKGROUND = "background";

      

      	// 获取 background 属性值的资源 id，未找到时返回 0

      	int backgroundId = attrs.getAttributeResourceValue(ANDROID_NAMESPACE, BACKGROUND, 0);

      	if (backgroundId != 0) {

            view.setBackgroundResource(resetResIdIfNeed(context, backgroundId));

        }

    }

}

// BaseActivity.java



@Override

public void onCreate(Bundle savedInstanceState) {

    super.onCreate(savedInstanceState);

    SkinViewInflater inflater = new SkinViewInflater();

    LayoutInflater layoutInflater = LayoutInflater.from(this);

    // 生成 View 的逻辑替换成我们自己的

    LayoutInflaterCompat.setFactory2(layoutInflater, inflater);

}

至此，这套方案已经可以解决目前的换肤需求了，剩下的就是进行细节适配了。

其他说明

自定义控件与第三方控件适配

上面只对 background 属性进行了处理，其他需要进行换肤的属性也是同样的处理逻辑。如果是自定义的控件，可以在初始化时调用 TypedArray#getResourceId 方法先获取资源 id，再通过 context 去获取对应资源，而不是使用 TypedArray#getDrawable 类似方法直接获取资源对象，这样可以确保换肤成功。而第三方控件也可通过 background 属性同样的处理逻辑进行适配。

XML <shape> 的处理

<!-- bg.xml -->

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

    <corners android:radius="8dp" />

    <solid android:color="@color/background" />

</shape>

上面的 bg.xml 文件内的 color 并不会完成资源替换，根据上面的逻辑，需要新增以下内容：

<!-- bg_blue.xml -->

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

    <corners android:radius="8dp" />

    <solid android:color="@color/background_blue" />

</shape>

如此，资源替换才会成功。

设计的配合

这次对第三款皮肤的适配还是蛮轻松的，主要是有以下基础：

• 在适配暗黑主题的时候，设计有出设计规范，后续开发按照设计规范来。


• 暗黑和暗蓝共用一套图片资源，大大减少适配工作量。


• 暗黑和暗蓝部份共用颜色值含透明度，同样减少了工作量，仅少量颜色需要新增。

这次适配的主要工作量还是来自 <shape> 的替换。

暗蓝皮肤资源文件的归处

我知道很多换肤方案都会将皮肤资源制作成皮肤包，但是这个方案没有这么做。一是没有那么多需要替换的资源，二是为了减少相应的工作量。

我新建了一个资源文件夹，与 res 同级，取名 res-blue。并在 gradle 配置文件中配置它。编译后系统会自动将它们合并，同时也能与常规资源文件隔离开来。

// build.gradle

sourceSets {

    main {

        java {

            srcDir 'src/main/java'

        }

        res.srcDirs += 'src/main/res'

        res.srcDirs += 'src/main/res-blue'

    }

}

有哪些坑？

WebView 资源缺失导致闪退

版本上线后，发现有 android.content.res.Resources$NotFoundException 异常上报，具体异常堆栈信息：

android.content.res.ResourcesImpl.getValue(ResourcesImpl.java:321)

android.content.res.Resources.getInteger(Resources.java:1279)

org.chromium.ui.base.DeviceFormFactor.b(chromium-TrichromeWebViewGoogle.apk-stable-447211483:4)

org.chromium.content.browser.selection.SelectionPopupControllerImpl.n(chromium-TrichromeWebViewGoogle.apk-stable-447211483:1)

N7.onCreateActionMode(chromium-TrichromeWebViewGoogle.apk-stable-447211483:8)

Gu.onCreateActionMode(chromium-TrichromeWebViewGoogle.apk-stable-447211483:2)

com.android.internal.policy.DecorView$ActionModeCallback2Wrapper.onCreateActionMode(DecorView.java:3255)

com.android.internal.policy.DecorView.startActionMode(DecorView.java:1159)

com.android.internal.policy.DecorView.startActionModeForChild(DecorView.java:1115)

android.view.ViewGroup.startActionModeForChild(ViewGroup.java:1087)

android.view.ViewGroup.startActionModeForChild(ViewGroup.java:1087)

android.view.ViewGroup.startActionModeForChild(ViewGroup.java:1087)

android.view.ViewGroup.startActionModeForChild(ViewGroup.java:1087)

android.view.ViewGroup.startActionModeForChild(ViewGroup.java:1087)

android.view.ViewGroup.startActionModeForChild(ViewGroup.java:1087)

android.view.View.startActionMode(View.java:7716)

org.chromium.content.browser.selection.SelectionPopupControllerImpl.I(chromium-TrichromeWebViewGoogle.apk-stable-447211483:10)

Vc0.a(chromium-TrichromeWebViewGoogle.apk-stable-447211483:10)

Vf0.i(chromium-TrichromeWebViewGoogle.apk-stable-447211483:4)

A5.run(chromium-TrichromeWebViewGoogle.apk-stable-447211483:3)

android.os.Handler.handleCallback(Handler.java:938)

android.os.Handler.dispatchMessage(Handler.java:99)

android.os.Looper.loopOnce(Looper.java:233)

android.os.Looper.loop(Looper.java:334)

android.app.ActivityThread.main(ActivityThread.java:8333)

java.lang.reflect.Method.invoke(Native Method)

com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:582)

com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1065)

经查才发现在 WebView 中长按文本弹出操作菜单时，就会引发该异常导致 App 闪退。

这是其他插件化方案也踩过的坑，我们只需在创建 SkinResources 之前将外部 WebView 的资源路径添加进来即可。

@Override

public Resources getResources() {

    if (mSkinResources == null) {

        WebViewResourceHelper.addChromeResourceIfNeeded(this);

        mSkinResources = new SkinResources(this, super.getResources());

    }

    return mSkinResources;

}

RePlugin/WebViewResourceHelper.java 源码文件

具体问题分析可参考

Fix ResourceNotFoundException in Android 7.0 (or above)

最终效果图

总结

这个方案在原本使用系统方式适配暗黑主题的基础上，通过拦截 Resources 相关获取资源的方法，替换换肤后的资源 id，以达到换肤的效果。针对 XML 布局换肤不成功的问题，复制 AppCompatViewInflater 创建 View 的代码逻辑，并在 View 创建成功后重新设置需要进行换肤的相关 XML 属性。同一皮肤资源使用单独的资源文件夹独立存放，可以与正常资源进行隔离，也避免了制作皮肤包而增加工作量。

目前来说这套方案是改造成本最小，侵入性最小的选择。选择适合自身需求的才是最好的。

刚刚结束的 2022 年，不少应用都给出了自己的 2022 年度报告。趁着这股热潮，我自己维护的应用《译站》 也来凑个热闹，用 Jetpack Compose 写了个报告页面。效果如下：

效果还算不错？如果需要实际体验的，可以前往 这里 下载翻译后打开底部最右侧 tab，即可现场看到。

制作过程

观察上图，需要完成的有三个难点：

• 闪动的数字


• 淡出 + 向上位移的微件们


• 有一部分微件不参与淡出（如 Spacer）

下面将详细介绍

闪动的数字

在我的上一篇文章 Jetpack Compose 十几行代码快速模仿即刻点赞数字切换效果 中，我基于 AnimatedContent 实现了 数字增加时自动做动画 的 Text，它的效果如下：

诶，既然如此，那实现这个数字跳动不就简单了吗？我们只需要让数字自动从 0 变成 目标数字，不就有了动画的效果吗？

此处我选择 Animatable ，并且使用 LauchedEffect 让数字自动开始递增，并把数字格式化为 0013（长度为目标数字的长度）传入到上次完成的微件中，这样一个自动跳动的动画就做好啦。

代码如下：

@Composable

fun AutoIncreaseAnimatedNumber(

    modifier: Modifier = Modifier,

    number: Int,

    durationMills: Int = 10000,

    textPadding: PaddingValues = PaddingValues(horizontal = 8.dp, vertical = 12.dp),

    textSize: TextUnit = 24.sp,

    textColor: Color = Color.Black,

    textWeight: FontWeight = FontWeight.Normal

) {

    // 动画，Animatable 相关介绍可以见 https://compose.funnysaltyfish.fun/docs/design/animation/animatable?source=trans

    val animatedNumber = remember {

        androidx.compose.animation.core.Animatable(0f)

    }

    // 数字格式化后的长度

    val l = remember {

        number.toString().length

    }



    // Composable 进入 Composition 阶段时开启动画

    LaunchedEffect(number) {

        animatedNumber.animateTo(

            targetValue = number.toFloat(),

            animationSpec = tween(durationMillis = durationMills)

        )

    }



    NumberChangeAnimatedText(

        modifier = modifier,

        text = "%0${l}d".format(animatedNumber.value.roundToInt()),

        textPadding = textPadding,

        textColor = textColor,

        textSize = textSize,

        textWeight = textWeight

    )

}



@OptIn(ExperimentalAnimationApi::class)

@Composable

fun NumberChangeAnimatedText(

    modifier: Modifier = Modifier,

    text: String,

    textPadding: PaddingValues = PaddingValues(horizontal = 8.dp, vertical = 12.dp),

    textSize: TextUnit = 24.sp,

    textColor: Color = Color.Black,

    textWeight: FontWeight = FontWeight.Normal,

) {

    Row(modifier = modifier) {

        text.forEach {

            AnimatedContent(

                targetState = it,

                transitionSpec = {

                    slideIntoContainer(AnimatedContentScope.SlideDirection.Up) with

                            fadeOut() + slideOutOfContainer(AnimatedContentScope.SlideDirection.Up)

                }

            ) { char ->

                Text(text = char.toString(), modifier = modifier.padding(textPadding), fontSize = textSize, color = textColor, fontWeight = textWeight)

            }

        }

    }

}

这样就完成啦~

淡出 + 向上位移的微件们

实际上，这个标题的难点在于“们”这个字，这意味着不但要完成“向上+淡出”的效果，还要有序，一个一个来。

对于这个问题，因为我的需求很简单：所有微件竖着排列，自上而下逐渐淡出。因此，我选择的解决思路是：自定义布局。（这不一定是唯一的思路，如果你有更好的方法，也欢迎一起探讨）。下面我们慢慢拆解：

微件竖着放

这其实是最简单的一步，你可以阅读我曾经写的 深入Jetpack Compose——布局原理与自定义布局（一） 来了解。简单来说，我们只需要依次摆放所有微件，然后把总宽度设为宽度最大值，总高度设为高度之和即可。代码如下：

@Composable

fun AutoFadeInComposableColumn(

    modifier: Modifier = Modifier,

    content: @Composable FadeInColumnScope.() -> Unit

) {

    val measurePolicy = MeasurePolicy { measurables, constraints ->

        val placeables = measurables.map { measurable ->

            measurable.measure(constraints.copy(minHeight = 0, minWidth = 0))

        }

        

        var y = 0

        // 宽度：父组件允许的最大宽度，高度：微件高之和

        layout(constraints.maxWidth, placeables.sumOf { it.height }) {

            // 依次摆放

            placeables.forEachIndexed { index, placeable ->

                placeable.placeRelativeWithLayer(0, y){

                    alpha = 1

                }

                y += placeable.height

            }.also {

                // 重置高度

                y = 0

            }

        }

    }

    Layout(modifier = modifier, content = { FadeInColumnScopeInstance.content() }, measurePolicy = measurePolicy)

}

上面的例子就是最简单的自定义布局了，它可以实现内部的 Composable 从上到下竖着排列。注意的是，在 place 的时候，我们使用了 placeRelativeWithLayer ，它可以调整组件的 alpha（还有 rotation/transform），这个未来会被用于实现淡出效果。

一个一个淡出

到了关键的一步了。我们不妨想一想，淡出就是 alpha 从 0->1，y 偏移从 offsetY -> 0 的过程，因此我们只需要在 place 时控制一下两者的值就行。作为一个动画过程，自然可以使用 Animatable。现在的问题是：需要几个 Animatable 呢？

自然，你可以选择使用 n 个 Animatable 分别控制 n 个微件，不过考虑到同一时刻其实只有一个 @Composable 在做动画，因此我选择只用一个。因此我们需要增加一些变量：

• currentFadeIndex 记录当前是哪个微件在播放动画


• finishedFadeIndex 记录播放完成的最后一个微件的 index，用于检查动画是否结束了

实话说这两个变量或许可以合成一个，不过既然写成了两个，那就先这样写下去吧。

两个状态可以只放到 Layout 里面，也可以放到专门的 State 中，考虑到外部可能要用到（嘿嘿，其实是真的要用到）两个值，我们单独写一个 State 吧

class AutoFadeInColumnState {

    var currentFadeIndex by mutableStateOf(-1)

    var finishedFadeIndex by mutableStateOf(0)

    

    companion object {

        val Saver = listSaver<AutoFadeInColumnState, Int>(

            save = { listOf(it.currentFadeIndex, it.finishedFadeIndex) },

            restore = {

                AutoFadeInColumnState().apply {

                    currentFadeIndex = it[0]; finishedFadeIndex = it[1]

                }

            }

        )

    }

}



@Composable

fun rememberAutoFadeInColumnState(): AutoFadeInColumnState {

    return rememberSaveable(saver = AutoFadeInColumnState.Saver) { AutoFadeInColumnState() }

}

接下来，为我们的自定义 Composable 添加几个参数吧

@Composable

fun AutoFadeInComposableColumn(

    modifier: Modifier = Modifier,

    state: AutoFadeInColumnState = rememberAutoFadeInColumnState(),

    fadeInTime: Int = 1000,  // 单个微件动画的时间

    fadeOffsetY: Int = 100,  // 单个微件动画的偏移量

    content: @Composable FadeInColumnScope.() -> Unit

)

接下来就是关键，修改 place 的代码完成动画效果。

// ...

placeables.forEachIndexed { index, placeable ->

    // @1 实际的 y，对于动画中的微件减去偏移量，对于未动画的微件不变

    val actualY = if (state.currentFadeIndex == index) {

        y + (( 1 - fadeInAnimatable.value) * fadeOffsetY).toInt()

    } else {

        y

    }

    placeable.placeRelativeWithLayer(0, actualY){

        // @2

        alpha = if (index == state.currentFadeIndex) fadeInAnimatable.value else

                    if (index <= state.finishedFadeIndex) 1f else 0f

    }

    y += placeable.height

}.also {

    y = 0

}

相较于之前，代码有两处主要更改。@1 处更改微件的 y，对于动画中的微件减去偏移量，对于未动画的微件不变，以实现 “位移” 的效果； @2 处则设置 alpha 值实现淡出效果，具体逻辑如下：

• 如果是正在动画的那个，alpha 就是当前动画的值，实现渐渐淡出的效果


• 否则，对于已经执行完动画的，alpha 正常为 1；否则为 0（还没轮到它们显示）

接下来，问题在于执行完一个如何执行下一个了。我的思路是这样的：添加一个 LauchedState(state.currentFadeIndex) 使得在 currentFadeIndex 变化时（这表示当前执行动画的微件变了）重新把 Animatable 置0，开启动画效果。动画完成后又把 currentFadeIndex 加一，直至完成所有。代码如下：

@Composable

fun xxx(...){

    LaunchedEffect(state.currentFadeIndex){

        if (state.currentFadeIndex == -1) {

            // 找到第一个需要渐入的元素

            state.currentFadeIndex = 0

        }

        // 开始动画

        fadeInAnimatable.animateTo(

            targetValue = 1f,

            animationSpec = tween(

                durationMillis = fadeInTime,

                easing = LinearEasing

            )

        )

        // 动画播放完了，更新 finishedFadeIndex

        state.finishedFadeIndex = state.currentFadeIndex

        // 全部动画完了，退出

        if(state.finishedFadeIndex >= whetherFadeIn.size - 1) return@LaunchedEffect

        

        state.currentFadeIndex += 1

        fadeInAnimatable.snapTo(0f) // snapTo(0f) 无动画直接置0 

    }

}

到这里，一个 内部子微件依次淡出 的自定义布局已经基本完成了。下面问题来了：在 Compose 中，我们使用 Spacer 创建间隔，但是往往 Spacer 是不需要动画的。因此我们需要支持一个特性：允许设置某些 Composable 不做动画，也就是直接跳过它们。这种子微件告诉父微件信息的时期，当然要交给 ParentData 来做

允许部分 Composable 不做动画

要了解 ParentData，您可以参考我的文章 深入Jetpack Compose——布局原理与自定义布局（四）ParentData，此处不再赘述。

我们添加一个 class FadeInColumnData(val fade: Boolean = true) 和 对应的 Modifier，用于指定某些 Composable 跳过动画。考虑到这个特定的 Modifier 只能用在我们这个布局，因此需要加上 scope 的限制。这些代码如下：

class FadeInColumnData(val fade: Boolean = true) : ParentDataModifier {

    override fun Density.modifyParentData(parentData: Any?): Any =

        this@FadeInColumnData

}



interface FadeInColumnScope {

    @Stable

    fun Modifier.fadeIn(whetherFadeIn: Boolean = true): Modifier

}



object FadeInColumnScopeInstance : FadeInColumnScope {

    override fun Modifier.fadeIn(whetherFadeIn: Boolean): Modifier = this.then(FadeInColumnData(whetherFadeIn))

}

有了这个，我们上面的布局也得做相应的更改，具体来说：

• 需要增加一个列表 whetherFadeIn 记录 ParentData 提供的值


• 开始的动画 index 不再是 0 ，而是找到的第一个需要做动画的元素


• currentFadeIndex 的更新需要找到下一个需要做动画的值

具体代码如下：

@Composable

fun AutoFadeInComposableColumn() {

    var whetherFadeIn: List<Boolean> = arrayListOf()

    // ...



    LaunchedEffect(state.currentFadeIndex){

        // 等待初始化完成

        while (whetherFadeIn.isEmpty()){ delay(50) }

        if (state.currentFadeIndex == -1) {

            // 找到第一个需要渐入的元素

            state.currentFadeIndex = whetherFadeIn.indexOf(true)

        }

        // 开始动画

        //  - state.currentFadeIndex = 0

        for (i in state.finishedFadeIndex + 1 until whetherFadeIn.size){

            if (whetherFadeIn[i]){

                state.currentFadeIndex = i

                fadeInAnimatable.snapTo(0f)

                break

            }

        }

    }



    val measurePolicy = MeasurePolicy { measurables, constraints ->

        // ...

        whetherFadeIn = placeables.map { placeable ->

            ((placeable.parentData as? FadeInColumnData) ?: FadeInColumnData()).fade

        }

        

        // 宽度：父组件允许的最大宽度，高度：微件高之和

        layout(constraints.maxWidth, placeables.sumOf { it.height }) {

            // ...

        }

    }

    Layout(modifier = modifier, content = { FadeInColumnScopeInstance.content() }, measurePolicy = measurePolicy)

}

完成啦！

一点小问题

事实上，整个布局的大体到目前已经趋于完成，不过目前有点小问题：对于 AutoIncreaseAnimatedNumber ，它的动画执行时机是错误的。你可以想象：尽管数字没有显示出来（alpha 为 0），但实际上它已经被摆放了，因此数字跳动的动画已经开始了。对于这个问题，我的解决方案是为 AutoIncreaseAnimatedNumber 额外添加一个 Boolean 参数 startAnim，只有该值为 true 时才真正开始执行动画。

那么 startAnim 什么时候为 true 呢？就是 currentFadeIndex == 这个微件的 Index 时，这样就可以手工指定什么时候开始动画了。

代码如下：

@Composable

fun AutoIncreaseAnimatedNumber(

    startAnim: Boolean = true,

    ...

) {

    // Composable 进入 Composition 阶段，且 startAnim 为 true 时开启动画

    LaunchedEffect(number, startAnim) {

        if (startAnim)

            animatedNumber.animateTo(

                targetValue = number.toFloat(),

                animationSpec = tween(durationMillis = durationMills)

            )

    }



    NumberChangeAnimatedText(

        ...

    )

}

实际使用时

Row(verticalAlignment = Alignment.CenterVertically) {

    AnimatedNumber(number = 110, startAnim = state.currentFadeIndex == 7) // 或者 >=，如果动画时间长于 fadeInTime 的话 

    ResultText(text = "次")

}

完工！

Pager？

如你所想，整体的布局是用 Pager 实现的，这个用的是 google/accompanist: A collection of extension libraries for Jetpack Compose 内的实现。鉴于不是本篇重点，此处略过，感兴趣的可以看下面的代码。

代码

完整代码见 FunnyTranslation/AnnualReportScreen.kt at compose。

如果有用，欢迎 Star仓库 / 此处点赞 / 评论 ~

前言

在Fragment中控制View十分简单，只需要声明+findViewById即可：

class FragmentA : Fragment() {

    private lateinit var imageView: ImageView

    

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {

        super.onViewCreated(view, savedInstanceState)

        imageView = view.findViewById(R.id.imageView)

    }

}

但这样同时也遇到了一个问题：在使用Navigation或者使用replace并addToBackStack进行FragmentA切换到FragmentB时，FragmentA会走到onDestroyView，但不会destory。FragmentA走到onDestroyView时，Fragment对根View的引用会置空，由于imageView被Fragment持有，所以此时imageView并未被释放，从而导致了内存泄漏。

当页面变的复杂时，变量的声明以及赋值也会变成一个重复的工作。比较成熟的框架如Butter Knife通过@BindView注解生成代码，以避免手工编写findViewById代码，同时也提供了Unbinder用以在onDestoryView中进行解绑以防止内存泄漏。不过在Butter Knife的官方文档中提到目前Butter Knife已不再维护，推荐使用ViewBinding作为视图绑定工具：

Attention: This tool is now deprecated. Please switch to view binding. Existing versions will continue to work, obviously, but only critical bug fixes for integration with AGP will be considered. Feature development and general bug fixes have stopped.

在ViewBinding的官方文档中，推荐的写法如下：

class TestFragment : Fragment() {

    private var _binding: FragmentTestBinding? = null

    // 只能在onCreateView与onDestoryView之间的生命周期里使用

    private val binding: FragmentTestBinding get() = _binding!!

    

    override fun onCreateView(

        inflater: LayoutInflater,

        container: ViewGroup?,

        savedInstanceState: Bundle?

    ): View {

        _binding = FragmentTestBinding.inflate(inflater, container, false)

        return binding.root

    }

    

    override fun onDestroyView() {

        super.onDestroyView()

        _binding = null

    }

}

这种方式虽然防止了内存泄漏，但仍然需要手工编写一些重复代码，大部分人甚至可能直接声明lateinit var binding，从而导致更严重的内存泄漏问题。下面我们将介绍两种解放方案：

Fragment基类

如果项目中存在一个BaseFragment的话，我们完全可以将上面的逻辑放在BaseFragment中：

open class BaseFragment<T : ViewBinding> : Fragment() {



    protected var _binding: T? = null

    

    protected val binding: T get() = _binding!!



    override fun onDestroyView() {

        super.onDestroyView()

        _binding = null

    }

}

或者更进一步，将onCreateView的逻辑也放在父类中：

abstract class BaseFragment<T : ViewBinding> : Fragment() {



    private var _binding: T? = null

    protected val binding: T get() = _binding!!



    abstract val bindingInflater: (LayoutInflater, ViewGroup?, Bundle?) -> T



    override fun onCreateView(

        inflater: LayoutInflater,

        container: ViewGroup?,

        savedInstanceState: Bundle?

    ): View {

        _binding = bindingInflater.invoke(inflater, container, savedInstanceState)

        return binding.root

    }



    override fun onDestroyView() {

        super.onDestroyView()

        _binding = null

    }

}

子类使用时：

class TestFragment : BaseFragment<FragmentTestBinding>() {

    

    override val bindingInflater: (LayoutInflater, ViewGroup?, Bundle?) -> FragmentTestBinding

        get() = { layoutInflater, viewGroup, _ ->

            FragmentTestBinding.inflate(layoutInflater, viewGroup, false)

        }

}

不过这种方式由于给基类增加了泛型，所以对于已有项目的侵入性比较高。

生命周期委派

借助Kotlin的by关键字，我们可以将binding置空的任务交给Frament生命周期进行处理，比较简单的版本如下：

class LifecycleAwareViewBinding<F : Fragment, V : ViewBinding> : ReadWriteProperty<F, V>, LifecycleEventObserver {



    private var binding: V? = null



    override fun getValue(thisRef: F, property: KProperty<*>): V {

        binding?.let {

            return it

        }

        throw IllegalStateException("Can't access ViewBinding before onCreateView and after onDestroyView!")

    }



    override fun setValue(thisRef: F, property: KProperty<*>, value: V) {

        if (thisRef.viewLifecycleOwner.lifecycle.currentState == Lifecycle.State.DESTROYED) {

            throw IllegalStateException("Can't set ViewBinding after onDestroyView!")

        }

        thisRef.viewLifecycleOwner.lifecycle.addObserver(this)

        binding = value

    }



    override fun onStateChanged(source: LifecycleOwner, event: Lifecycle.Event) {

        if (event == Lifecycle.Event.ON_DESTROY) {

            binding = null

            source.lifecycle.removeObserver(this)

        }

    }

}

在使用时可以直接通过by关键字，但仍需在onCreateView中进行赋值：

class TestFragment : Fragment() {

    private var binding: FragmentTestBinding by LifecycleAwareViewBinding()

    

    override fun onCreateView(

        inflater: LayoutInflater,

        container: ViewGroup?,

        savedInstanceState: Bundle?

    ): View {

        binding = FragmentTestBinding.inflate(inflater, container, false)

        return binding.root

    }

}

如果想省略onCreateView中的创建ViewBinding的重复逻辑，有两种思路，一个是Fragment构造时传入布局Id，通过viewBinding生成的bind函数创建ViewBinding；另外一种思路则是通过反射调用ViewBinding的inflate方法。两种思路的主要不同就是创建ViewBinding的方式不一样，而核心代码一样，实现如下：

class LifecycleAwareViewBinding<F : Fragment, V : ViewBinding>(

    private val bindingCreator: (F) -> V

) : ReadOnlyProperty<F, V>, LifecycleEventObserver {



    private var binding: V? = null



    override fun getValue(thisRef: F, property: KProperty<*>): V {

        binding?.let {

            return it

        }

        val lifecycle = thisRef.viewLifecycleOwner.lifecycle

        if (lifecycle.currentState == Lifecycle.State.DESTROYED) {

            this.binding = null

            throw IllegalStateException("Can't access ViewBinding after onDestroyView")

        } else {

            lifecycle.addObserver(this)

            val viewBinding = bindingCreator.invoke(thisRef)

            this.binding = viewBinding

            return viewBinding

        }

    }



    override fun onStateChanged(source: LifecycleOwner, event: Lifecycle.Event) {

        if (event == Lifecycle.Event.ON_DESTROY) {

            binding = null

            source.lifecycle.removeObserver(this)

        }

    }

}

然后创建函数返回LifecycleAwareViewBinding即可：

// 1. 通过bind函数

fun <V : ViewBinding> Fragment.viewBinding(binder: (View) -> V): LifecycleAwareViewBinding<Fragment, V> {

    return LifecycleAwareViewBinding { binder.invoke(it.requireView()) }

}

// 使用

class TestFragment : Fragment(R.layout.fragment_test) {

    private val binding: FragmentTestBinding by viewBinding(FragmentTestBinding::bind)

}



// 2. 通过反射的方式

inline fun <reified V : ViewBinding> Fragment.viewBinding(): LifecycleAwareViewBinding<Fragment, V> {

    val method = V::class.java.getMethod("inflate", LayoutInflater::class.java, ViewGroup::class.java, Boolean::class.java)

    return LifecycleAwareViewBinding { method.invoke(null, layoutInflater, null, false) as V }

}

// 使用

class TestFragment : Fragment() {

    private val binding: FragmentTestBinding by viewBinding()

    

    override fun onCreateView(

        inflater: LayoutInflater,

        container: ViewGroup?,

        savedInstanceState: Bundle?

    ): View {

        return binding.root

    }

}

需要注意的是第一种方式使用了Fragment#requireView方法，所以需要将布局id传给Fragment的构造方法（将布局id传给Fragment实际上是借助了Fragment默认的onCreateView实现，虽然不传布局Id、手动实现也可以，但这样实际上和最上面提到的方法差不多了）。

上面的两种思路GitHub中已经有作者实现了，并且考虑了一些边界case以及优化，感兴趣的可以去看看：ViewBindingPropertyDelegate

总结

对于ViewBinding为了防止内存泄漏而出现的模板代码，可以将模板代码提取至基类Fragment中或者借助Fragment的viewLifecycleOwner的生命周期进行自动清理；对于onCreateView中为了创建ViewBinding而出现的模板代码，可以借助Fragment#onCreateView的默认实现以及ViewBinding生成的bind函数进行创建，或者通过反射调用ViewBinding生成的inflate方法创建ViewBinding。