一.EmptyCoroutineContext

    EmptyCoroutineContext代表空上下文，由于自身为空，因此get方法的返回值是空的，fold方法直接返回传入的初始值，plus方法也是直接返回传入的context，minusKey方法返回自身，代码如下：

public object EmptyCoroutineContext : CoroutineContext, Serializable {

    private const val serialVersionUID: Long = 0

    private fun readResolve(): Any = EmptyCoroutineContext



    public override fun <E : Element> get(key: Key<E>): E? = null

    public override fun <R> fold(initial: R, operation: (R, Element) -> R): R = initial

    public override fun plus(context: CoroutineContext): CoroutineContext = context

    public override fun minusKey(key: Key<*>): CoroutineContext = this

    public override fun hashCode(): Int = 0

    public override fun toString(): String = "EmptyCoroutineContext"

}

二.CombinedContext

    CombinedContext是组合上下文，是存储Element的重要的数据结构。内部存储的组织结构如下图所示：

    可以看出CombinedContext是一种左偏(从左向右计算)的列表，这么设计的目的是为了让CoroutineContext中的plus方法工作起来更加自然。

    由于采用这种数据结构，CombinedContext类中的很多方法都是通过循环实现的，代码如下：

internal class CombinedContext(

    // 数据结构左边可能为一个Element对象或者还是一个CombinedContext对象

    private val left: CoroutineContext,

    // 数据结构右边只能为一个Element对象

    private val element: Element

) : CoroutineContext, Serializable {



    override fun <E : Element> get(key: Key<E>): E? {

        var cur = this

        while (true) {

            // 进行get操作，如果当前CombinedContext对象中存在，则返回

            cur.element[key]?.let { return it }

            // 获取左边的上下文对象

            val next = cur.left

            // 如果是CombinedContext对象

            if (next is CombinedContext) {

                // 赋值，继续循环

                cur = next

            } else { // 如果不是CombinedContext对象

                // 进行get操作，返回

                return next[key]

            }

        }

    }

    // 数据结构左右分开操作，从左到右进行fold运算

    public override fun <R> fold(initial: R, operation: (R, Element) -> R): R =

        operation(left.fold(initial, operation), element)



    public override fun minusKey(key: Key<*>): CoroutineContext {

        // 如果右边是指定的Element对象，则返回左边

        element[key]?.let { return left }

        // 调用左边的minusKey方法

        val newLeft = left.minusKey(key)

        return when {

            // 这种情况，说明左边部分已经是去掉指定的Element对象的，右边也是如此，因此返回当前对象，不需要在进行包裹

            newLeft === left -> this

            // 这种情况，说明左边部分包含指定的Element对象，因此返回只右边

            newLeft === EmptyCoroutineContext -> element

            // 这种情况，返回的左边部分是新的，因此需要和右边部分一起包裹后，再返回

            else -> CombinedContext(newLeft, element)

        }

    }



    private fun size(): Int {

        var cur = this

        //左右各一个

        var size = 2

        while (true) {

            cur = cur.left as? CombinedContext ?: return size

            size++

        }

    }



    // 通过get方法实现

    private fun contains(element: Element): Boolean =

        get(element.key) == element



    private fun containsAll(context: CombinedContext): Boolean {

        var cur = context

        // 循环展开每一个CombinedContext对象，每个CombinedContext对象中的Element对象都要包含

        while (true) {

            if (!contains(cur.element)) return false

            val next = cur.left

            if (next is CombinedContext) {

                cur = next

            } else {

                return contains(next as Element)

            }

        }

    }

    ...

}

三.Key与Element

    Key接口与Element接口定义在CoroutineContext接口中，代码如下：

public interface Key<E : Element>



public interface Element : CoroutineContext {

    // 一个Key对应着一个Element对象

    public val key: Key<*>

    // 相等则强制转换并返回，否则则返回空

    public override operator fun <E : Element> get(key: Key<E>): E? =

        @Suppress("UNCHECKED_CAST")

        if (this.key == key) this as E else null

    // 自身与初始值进行fold操作

    public override fun <R> fold(initial: R, operation: (R, Element) -> R): R =

        operation(initial, this)

    // 如果要去除的是当前的Element对象，则返回空的上下文，否则返回自身

    public override fun minusKey(key: Key<*>): CoroutineContext =

        if (this.key == key) EmptyCoroutineContext else this

}

四.CoroutineContext

    CoroutineContext接口定义了协程上下文的基本行为以及Key和Element接口。同时，重载了"+"操作，相关代码如下：

public interface CoroutineContext {

   

    public operator fun <E : Element> get(key: Key<E>): E?



    public fun <R> fold(initial: R, operation: (R, Element) -> R): R



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

        // 如果要与空上下文相加，则直接但会当前对象，

        if (context === EmptyCoroutineContext) this else

            // 当前Element作为初始值

            context.fold(this) { acc, element ->

                // acc:已经加完的CoroutineContext对象

                // element:当前要加的CoroutineContext对象

                

                // 获取从acc中去掉element后的上下文removed，这步是为了确保添加重复的Element时，移动到最右侧

                val removed = acc.minusKey(element.key)

                // 去除掉element后为空上下文(说明acc中只有一个Element对象)，则返回element

                if (removed === EmptyCoroutineContext) element else {

                    // ContinuationInterceptor代表拦截器，也是一个Element对象

                    // 下面的操作是为了把拦截器移动到上下文的最右端，为了方便快速获取

                    // 从removed中获取拦截器

                    val interceptor = removed[ContinuationInterceptor]

                    // 若上下文中没有拦截器，则进行累加(包裹成CombinedContext对象)，返回

                    if (interceptor == null) CombinedContext(removed, element) else {

                        // 若上下文中有拦截器

                        // 获取上下文中移除到掉拦截器后的上下文left

                        val left = removed.minusKey(ContinuationInterceptor)

                        // 若移除到掉拦截器后的上下文为空上下文，说明上下文left中只有一个拦截器，

                        // 则进行累加(包裹成CombinedContext对象)，返回

                        if (left === EmptyCoroutineContext) CombinedContext(element, interceptor) else

                            // 否则，现对当前要加的element和left进行累加，然后在和拦截器进行累加

                            CombinedContext(CombinedContext(left, element), interceptor)

                    }

                }

            }



    public fun minusKey(key: Key<*>): CoroutineContext

    

    ... // (Key和Element接口)

}

1.plus方法图解

    假设我们有一个上下文顺序为A、B、C，现在要按顺序加上D、C、A。

1）初始值A、B、C

2）加上D

3）加上C

4）加上A

2.为什么要将ContinuationInterceptor放到协程上下文的最右端？

    在协程中有大量的场景需要获取ContinuationInterceptor。根据之前分析的CombinedContext的minusKey方法，ContinuationInterceptor放在上下文的最右端，可以直接获取，不需要经过多次的循环。

五.AbstractCoroutineContextKey与AbstractCoroutineContextElement

    AbstractCoroutineContextElement实现了Element接口，将Key对象作为构造方法必要的参数。

public abstract class AbstractCoroutineContextElement(public override val key: Key<*>) : Element

    AbstractCoroutineContextKey用于实现Element的多态。什么是Element的多态呢？假设类A实现了Element接口，Key为A。类B继承自类A，Key为B。这时将类B的对象添加到上下文中，通过指定不同的Key(A或B)，可以得到不同类型对象。具体代码如下：

// baseKey为衍生类的基类的Key

// safeCast用于对基类进行转换

// B为基类，E为衍生类

public abstract class AbstractCoroutineContextKey<B : Element, E : B>(

    baseKey: Key<B>,

    private val safeCast: (element: Element) -> E?

) : Key<E> {

    // 顶置Key，如果baseKey是AbstractCoroutineContextKey，则获取baseKey的顶置Key

    private val topmostKey: Key<*> = if (baseKey is AbstractCoroutineContextKey<*, *>) baseKey.topmostKey else baseKey



    // 用于类型转换

    internal fun tryCast(element: Element): E? = safeCast(element)

    // 用于判断当前key是否是指定key的子key

    // 逻辑为与当前key相同，或者与当前key的顶置key相同

    internal fun isSubKey(key: Key<*>): Boolean = key === this || topmostKey === key

}

1.getPolymorphicElement方法与minusPolymorphicKey方法

    如果衍生类使用了AbstractCoroutineContextKey，那么基类在实现Element接口中的get方法时，就需要通过getPolymorphicElement方法，实现minusKey方法时，就需要通过minusPolymorphicKey方法，代码如下：

public fun <E : Element> Element.getPolymorphicElement(key: Key<E>): E? {

    // 如果key是AbstractCoroutineContextKey

    if (key is AbstractCoroutineContextKey<*, *>) {

        // 如果key是当前key的子key，则基类强制转换成衍生类，并返回

        @Suppress("UNCHECKED_CAST")

        return if (key.isSubKey(this.key)) key.tryCast(this) as? E else null

    }

    // 如果key不是AbstractCoroutineContextKey

    // 如果key相等，则强制转换，并返回

    @Suppress("UNCHECKED_CAST")

    return if (this.key === key) this as E else null

}

public fun Element.minusPolymorphicKey(key: Key<*>): CoroutineContext {

    // 如果key是AbstractCoroutineContextKey

    if (key is AbstractCoroutineContextKey<*, *>) {

        // 如果key是当前key的子key，基类强制转换后不为空，说明当前Element需要去掉，因此返回空上下文，否则返回自身

        return if (key.isSubKey(this.key) && key.tryCast(this) != null) EmptyCoroutineContext else this

    }

    // 如果key不是AbstractCoroutineContextKey

    // 如果key相等，说明当前Element需要去掉，因此返回空上下文，否则返回自身

    return if (this.key === key) EmptyCoroutineContext else this

}

介绍

IntArray

整数数组。在 JVM 平台上，对应 int[]。

Array

Array<T> 表示 T 类型数组。在 JVM 平台上，Array<Int> 对应 Integer[]。

验证

fun main() {

    val one = IntArray(10) { it }

    val two = Array<Int>(10) { it }

}

Decompile

综上，在 JVM 平台上，IntArray 与 Array<Int> 的区别在于对应的类型不同，一个是基础类型 int 数组，另外一个是封装类型 Integer 数组，有装箱开销。

开销差距

一般情况下，看不出差距，只能用放大镜看一下了。

@OptIn(ExperimentalTime::class)

fun main() {



    val duration1 = measureTime {

        case1()

    }

    println(duration1)



    val duration2 = measureTime {

        case2()

    }

    println(duration2)

}



private fun case1() {

    val t = IntArray(10_000_000)

}



private fun case2() {

    val t = Array<Int>(10_000_000) { it }

}

使用场景

• 默认使用 IntArray，基础类型因无装箱开销而性能好，且每个元素都有默认值 0。


• 如果数组需要使用 null 值，使用 Array<Int>。

StackOverflow

高赞回答，一言以蔽之。

1. 背景

最近一个需求改版UI视觉觉得微信朋友圈的边缘高斯模糊挺好看，然后就苦逼吭哧的尝试在Flutter实现了，来看微信朋友圈点击展开的大图效果图：

微信朋友圈高斯模糊效果大概分4部分区域实现，如下图：

居中图片为原始图，然后背景模糊全图是原始图放大cover模式的高斯模糊，在上下两个区域分别是两层单独处理边界的高斯模糊效果特殊处理，因此有时候可以看到微信朋友圈在上下两侧有明显分界线；

2. 实践

在Flutter侧实现高斯模糊比较简单，可以直接使用系统的BackdropFilter函数实现，需要传入一个filter方式，然后对child区域进行模糊过滤；

  const BackdropFilter({

    Key? key,

    required this.filter,

    Widget? child,

    this.blendMode = BlendMode.srcOver,

  }) : assert(filter != null),

       super(key: key, child: child);     

Flutter提供了简化ImageFiltered实现高斯模糊，代码如下：

ImageFiltered(

    imageFilter: ImageFilter.blur(sigmaX: 20, sigmaY: 20),

    child: Image.network(url,fit: BoxFit.cover, height: expandedHeight, width: width),

),

通过此方式，可以非常简约实现全屏高斯模糊～，现在难点是上下边界区域的边界模糊处理，这里需要使用一个ShaderMask组件，在Flutter侧ShaderMask主要是实现渐变过渡能力的；

  const ShaderMask({

   Key? key,

   required this.shaderCallback,

   this.blendMode = BlendMode.modulate,

   Widget? child,

 }) : assert(shaderCallback != null),

      assert(blendMode != null),

      super(key: key, child: child);

其需要shaderCallback回调渐变Shader，共提供3种渐变模式：

• RadialGradient：放射状渐变


• LinearGradient：线性渐变


• SweepGradient：扇形渐变

这里我们需要使用线性渐变LinearGradient从上到下的渐变过渡，代码如下：

             ShaderMask(

              shaderCallback: (Rect bounds) {

                return const LinearGradient(

                  begin: Alignment.topCenter,

                  end: Alignment.bottomCenter,

                  colors: [

                    Colors.transparent,

                    Colors.white,

                    Colors.transparent

                  ],

                ).createShader(bounds);

              },

              child: Image.network(url,

                  fit: BoxFit.cover, height: closeHeight, width: width),

            )

        

就这样实现了？当我运行时候出现如下效果，效果还挺好的：

但是当我把封面图url替换了一个浅色图片，却出现如下效果，中间区域变成了黑色的，看来是我想的简单了：

分析了下Flutter线性过度源码，其将颜色进行过渡，
Color transparent = Color(0x00000000) , 而
Color white = Color(0xFFFFFFFF)，可以看到除了透明度之外，需要保证颜色不要发生大变化，其实我们诉求只是需要将透明度发生渐变即可，因此将Colors.white改为Colors.black,

             ShaderMask(

              shaderCallback: (Rect bounds) {

                return const LinearGradient(

                  begin: Alignment.topCenter,

                  end: Alignment.bottomCenter,

                  colors: [

                    Colors.transparent,

                    Colors.black,

                    Colors.transparent

                  ],

                ).createShader(bounds);

              },

              child: Image.network(url,

                  fit: BoxFit.cover, height: closeHeight, width: width),

            )

      

出现如下效果：

这里颜色貌似符合预期，但是混合模式出现了问题，学过Android开发的一定属性如下这张BlendMode混合模式图片：

ShaderMaster默认的混合模式是BlendMode.modulate，这个我也解释不清楚：这里有一篇相关文章juejin.cn/post/684490…

这里我们将混合模式替换为BlendMode.dstIn：只显示src和dst重合部分，且src的重合部分只有不透明度有用，经过这些操作后，整体效果最后如下所示：

最后奉上完整demo的相关代码:

  Widget buildCover(BuildContext context) {

    double width = MediaQuery.of(context).size.width;

    double expandedHeight = 600;

    double closeHeight = 300;

    const String url =

        'https://img.alicdn.com/imgextra/i2/O1CN01YWcPh81fbUvpcjUXp_!!6000000004025-2-tps-842-350.png';

    return Container(

      height: expandedHeight,

      alignment: Alignment.center,

      child: Stack(

        children: [

          ImageFiltered(

            imageFilter: ImageFilter.blur(sigmaX: 20, sigmaY: 20),

            child: Image.network(url,

                fit: BoxFit.cover, height: expandedHeight, width: width),

          ),

          Container(

            height: expandedHeight,

            alignment: Alignment.center,

            child: ShaderMask(

              shaderCallback: (Rect bounds) {

                return const LinearGradient(

                  begin: Alignment.topCenter,

                  end: Alignment.bottomCenter,

                  colors: [

                    Colors.transparent,

                    Colors.black,

                    Colors.transparent

                  ],

                ).createShader(bounds);

              },

              blendMode: BlendMode.dstIn,

              child: Image.network(url,

                  fit: BoxFit.cover, height: closeHeight, width: width),

            ),

          )

        ],

      ),

    );

  }

3. 总结

通过实践，发现Flutter实现高斯模糊BackdropFilter/ImageFiltered组件，渐变实现方式ShaderMask，此外还需要掌握图形学的BlendMode混合模式，以后在碰到类似需求时候建议直接砍了UI视觉吧～～费劲～～～～

先看一下 ViewModel 中的 ViewModelScope 是何方神圣

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))

        }

可以看到这个是一个扩展方法，

再点击 setTagIfAbsent 方法进去

 <T> T setTagIfAbsent(String key, T newValue) {

        T previous;

        synchronized (mBagOfTags) {

            previous = (T) mBagOfTags.get(key);//第一次肯定为null

            if (previous == null) {

                mBagOfTags.put(key, newValue);//null 存储

            }

        }

        T result = previous == null ? newValue : previous;

        if (mCleared) {//判断是否已经clear了

            // It is possible that we'll call close() multiple times on the same object, but

            // Closeable interface requires close method to be idempotent:

            // "if the stream is already closed then invoking this method has no effect." (c)

            closeWithRuntimeException(result);

        }

        return result;

    }

可以看到 这边 会把 我们的 ViewModel 存储到 ViewModel 内的 mBagOfTags 中

这个 mBagOfTags 是

    private final Map<String, Object> mBagOfTags = new HashMap<>();

这个时候 我们 viewModel 就会持有 我们 viewModelScope 的协程 作用域了。

那..这也只是 表述了 我们 viewModelScope 存在哪里而已，

什么时候清除呢？

先看一下 ViewModel 的生命周期

可以看到 ViewModel 的生命周期 会在 Activity onDestory 之后会被调用。

那...具体哪里调的？

翻看源码可以追溯到 ComponentActivity 的默认构造器内

 public ComponentActivity() {

     /*省略一些*/

        getLifecycle().addObserver(new LifecycleEventObserver() {

            @Override

            public void onStateChanged(@NonNull LifecycleOwner source,

                    @NonNull Lifecycle.Event event) {

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

                    if (!isChangingConfigurations()) {

                        getViewModelStore().clear();

                    }

                }

            }

        });

  }

可以看到内部会通对 Lifecycle 添加一个观察者，观察当前 Activity 的生命周期变更事件，如果走到了 Destory ，并且 本次 Destory 并非由于配置变更引起的，才会真正调用 ViewModelStore 的 clear 方法。

跟进 clear 方法看看

public class ViewModelStore {



    private final HashMap<String, ViewModel> mMap = new HashMap<>();



    /**

     *  Clears internal storage and notifies ViewModels that they are no longer used.

     */

    public final void clear() {

        for (ViewModel vm : mMap.values()) {

            vm.clear();

        }

        mMap.clear();

    }

}

可以看到这个 ViewModelStore 内部实现 用 HashMap 存储 ViewModel

于是在 clear 的时候，会逐个遍历调用 clear方法

再次跟进 ViewModel 的 clear 方法

 @MainThread

    final void clear() {

        mCleared = true;

        // Since clear() is final, this method is still called on mock objects

        // and in those cases, mBagOfTags is null. It'll always be empty though

        // because setTagIfAbsent and getTag are not final so we can skip

        // clearing it

        if (mBagOfTags != null) {

            synchronized (mBagOfTags) {

                for (Object value : mBagOfTags.values()) {

                    // see comment for the similar call in setTagIfAbsent

                    closeWithRuntimeException(value);

                }

            }

        }

        onCleared();

    }

可以发现我们最初 存放 viewmodelScope 的 mBagOfTags

这里面的逻辑 就是对 mBagOfTags 存储的数据 挨个提取出来并且调用 closeWithRuntimeException

跟进 closeWithRuntimeException

 private static void closeWithRuntimeException(Object obj) {

        if (obj instanceof Closeable) {

            try {

                ((Closeable) obj).close();

            } catch (IOException e) {

                throw new RuntimeException(e);

            }

        }

    }

该方法内会逐个判断 对象是否实现 Closeable 如果实现就会调用这个接口的 close 方法，

再回到最初 我们 viewModel 的扩展方法那边，看看我们 viewModelScope 的真正面目

internal class CloseableCoroutineScope(context: CoroutineContext) 

    : Closeable, CoroutineScope {

    override val coroutineContext: CoroutineContext = context



    override fun close() {

        coroutineContext.cancel()

    }

}

可以明确的看到 我们的 ViewModelScope 实现了 Closeable 并且充写了 close 方法，

close 方法内的实现 会对 协程上下文进行 cancel。

至此我们 可以大致整理一下

1. viewModelScope 是 ViewModel 的扩展成员，该对象是 CloseableCoroutineScope，并且实现了 Closeable 接口


2. ViewModelScope 存储在 ViewModel 的 名叫 mBagOfTags 的HashMap中 啊


3. ViewModel 存储在 Activity 的 ViewModelStore 中，并且会监听 Activity 的 Lifecycle 的状态变更，在ON_DESTROY 且 非配置变更引起的事件中 对 viewModelStore 进行清空


4. ViewModelStore 清空会对 ViewModelStore 内的所有 ViewModel 逐个调用 clear 方法。


5. ViewModel的clear方法会对 ViewModel的 mBagOfTags 内存储的对象进行调用 close 方法(该对象需实现Closeable 接口)


6. 最终会会调用 我们 ViewModelScope 的实现类 CloseableCoroutineScope 的 close 方法中。close 方法会对协程进行 cancel。

前言

由于很多应用在启动时需要进行一些初始化事务，导致在启动应用时有一定的空白延迟，在之前我们一般的做法是通过替换 android:windowBackground 的自定义主题，使应用启动时及时显示一张默认图片来改善启动体验。

在Android 12中，官方添加了SplashScreen API，它可为所有应用启用新的应用启动界面。新的启动界面是瞬时显示的，所以就不必再自定义android:windowBackground 了。新启动页面的样式默认是正中显示应用图标，但是允许我们自定义，以便应用能够保持其独特的品牌。下面我们来看看如何使用它。

启动画面实现

其实在Android 12上已经默认使用了SplashScreen，如果没有任何配置，会自动使用App图标。

当然也允许自定义启动画面，在value-v31中的style.xml中，可以在App的主Theme中通过如下属性来进行配置：

<style name="AppTheme" parent="android:Theme.Holo.Light.DarkActionBar">

    <item name="android:windowSplashScreenBackground">@android:color/white</item>

    <item name="android:windowSplashScreenAnimatedIcon">@drawable/anim_ai_loading</item>

    <item name="android:windowSplashScreenAnimationDuration">1000</item>

    <item name="android:windowSplashScreenBrandingImage">@mipmap/brand</item>

</style>

• windowSplashScreenBackground设置启动画面的背景色

• windowSplashScreenAnimatedIcon启动图标。就是显示在启动界面中间的图片，也可以是动画

• windowSplashScreenAnimationDuration设置动画的长度。注意这里最大只能1000ms，如果需要动画时间更长，则需要通过代码的手段让启动画面在屏幕上显示更长时间（下面会讲到）

• windowSplashScreenIconBackground设置启动图标的背景色

• windowSplashScreenBrandingImage设置要显示在启动画面底部的图片。官方设计准则建议不要使用品牌图片。

运行启动应用就可以看到新的启动画面了，如下： 

动画的元素

在Android 12上，显示在启动界面中间的图片会有一个圆形遮罩，所以在设计图片或动画的时候一定要注意，比如上面我的例子，动画其实就没有显示完整。对此官方给了详细的设计指导，如下：

• 应用图标 (1) 应该是矢量可绘制对象，它可以是静态或动画形式。虽然动画的时长可以不受限制，但我们建议让其不超过 1000 毫秒。默认情况下，使用启动器图标。
• 图标背景 (2) 是可选的，在图标与窗口背景之间需要更高的对比度时很有用。如果您使用一个自适应图标，当该图标与窗口背景之间的对比度足够高时，就会显示其背景。
• 与自适应图标一样，前景的 ⅓ 被遮盖 (3)。
• 窗口背景 (4) 由不透明的单色组成。如果窗口背景已设置且为纯色，则未设置相应的属性时默认使用该背景。

启动时长

默认当应用绘制第一帧后，启动画面会立即关闭。但是在我们实际使用中，一般在启动时进行一些初始化操作，另外大部分应用会请求启动广告，这样其实需要一些耗时的。通常情况下，这些耗时操作我们会进行异步处理，那么是否可以让启动画面等待这些初始化完成后才关闭？

我们可以使用 ViewTreeObserver.OnPreDrawListener让应用暂停绘制第一帧，直到一切准备就绪才开始，这样就会让启动画面停留更长的时间，如下：

...

var isReady = false

...



override fun onCreate(savedInstanceState: Bundle?) {

    super.onCreate(savedInstanceState)

    setContentView(R.layout.main_activity)

    ...

    

    val content: View = findViewById(android.R.id.content)

    content.viewTreeObserver.addOnPreDrawListener(

        object : ViewTreeObserver.OnPreDrawListener {

            override fun onPreDraw(): Boolean {

                return if (isReady) {

                    content.viewTreeObserver.removeOnPreDrawListener(this)

                    true

                } else {

                    false

                }

            }

        }

    )

}

这样当初始化等耗时操作完成后，将isReady置为true即可关闭启动画面进入应用。

上面我们提到配置启动动画的时长最多只能是1000ms，但是通过上面的代码可以让启动画面停留更长时间，所以动画的展示时间也就更长了。

关闭动画

启动画面关闭时默认直接消失，当然我们也可以对其进行自定义。

在Activity中可以通过getSplashScreen来获取（注意判断版本，低版本中没有这个函数，会crash），然后通过它的setOnExitAnimationListener来定义关闭动画，如下：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {

    splashScreen.setOnExitAnimationListener { splashScreenView ->

        val slideUp = ObjectAnimator.ofFloat(

            splashScreenView,

            View.TRANSLATION_Y,

            0f,

            -splashScreenView.height.toFloat()

        )

        slideUp.interpolator = AnticipateInterpolator()

        slideUp.duration = 200L

        //这里doOnEnd需要Android KTX库，即androidx.core:core-ktx:1.7.0

        slideUp.doOnEnd { splashScreenView.remove() }

        slideUp.start()

    }

}

加上如上代码后，本来直接消失的启动画面就变成了向上退出了。

这里可以通过splashScreenView可以获取到启动动画的时长和开始时间，如下：

val animationDuration = splashScreenView.iconAnimationDurationMillis

val animationStart = splashScreenView.getIconAnimationStartMillis

这样就可以计算出启动动画的剩余时长。

顺便吐槽一下官网这里代码错了，开始时间也用了iconAnimationDurationMillis来获取，实际上应该是getIconAnimationStartMillis

低版本使用SplashScreen

只能在Android 12上体验官方的启动动画，显然不能够啊！官方提供了Androidx SplashScreen compat库，能够向后兼容，并可在所有 Android 版本上显示外观和风格一致的启动画面（这点我保留意见）。

首先要升级compileSdkVersion，并依赖SplashScreen库，如下：

android {

   compileSdkVersion 31

   ...

}

dependencies {

   ...

   implementation 'androidx.core:core-splashscreen:1.0.0-alpha01'

}

然后在style.xml添加代码如下：

<style name="Theme.App.Starting" parent="Theme.SplashScreen">

    // Set the splash screen background, animated icon, and animation duration.

    <item name="windowSplashScreenBackground">@android:color/white</item>



    // Use windowSplashScreenAnimatedIcon to add either a drawable or an

    // animated drawable. One of these is required.

    <item name="windowSplashScreenAnimatedIcon">@drawable/anim_ai_loading</item>

    <item name="windowSplashScreenAnimationDuration">1000</item>  # Required for

    # animated icons



    // Set the theme of the Activity that directly follows your splash screen.

    <item name="postSplashScreenTheme">@style/AppTheme</item>  # Required.

</style>

前三个我们上面都介绍过了，这里新增了一个postSplashScreenTheme，它应该设置为应用的原主题，这样会将这个主题设置给启动画面之后的Activity，这样就可以保持样式的不变。

注意上面提到的windowSplashScreenIconBackground和windowSplashScreenBrandingImage没有，这是与Android12的不同之一。

然后我们将这个style设置给Application或Activity即可：

<manifest>

   <application android:theme="@style/Theme.App.Starting">

    <!-- or -->

        <activity android:theme="@style/Theme.App.Starting">

...

最后需要在启动activity中，先调用installSplashScreen，然后才能调用setContentView，如下

class MainActivity : ComponentActivity() {



   override fun onCreate(savedInstanceState: Bundle?) {

       super.onCreate(savedInstanceState)

       val splashScreen = installSplashScreen()

       setContentView(R.layout.activity_main)

...

然后在低版本系统上启动应用就可以看到启动画面了。

installSplashScreen这一步很重要，如果没有这一行代码，postSplashScreenTheme就无法生效，这样启动画面后Activity就无法使用之前的样式，严重的会造成崩溃。比如在Activity中存在AppCompat组件，这就需要使用AppCompat样式，否则就会Crash。

最后注意在Android 12上依然有圆形遮罩，所以需要遵循官方的设计准则；但是在低版本系统上则没发现有这个遮罩，而且在低版本上动画无效，只会显示第一帧的画面，所以我对官方说的风格一致保留意见。

现有启动画面迁移

目前市场上的App基本都自己实现了启动页面，如果直接添加SplashScreen，就会造成重复，所以我们需要对原有启动页面进行处理。具体处理还要根据每个App自己的启动页面的实现逻辑来定，这里官方给出了一些意见，大家可以参考一下：将现有的启动画面实现迁移到 Android 12 及更高版本

总结

官方的SplashScreen有点姗姗来迟，不过效果还是不错的，使用起来也非常简单，但是一定要注意版本。虽然Androidx SplashScreen compat库可以向后兼容，但是与Android 12上还是有一些不同。

每天认真洗脸，多读书，按时睡，少食多餐。变得温柔，大度，继续善良，保持爱心。不在人前矫情，四处诉说以求宽慰，而是学会一个人静静面对，自己把道理想通。这样的你，单身也所谓啊，你在那么虔诚地做更好的自己，一定会遇到最好的，而那个人也一定值得你所有等待。

在WebView没有出现之前，如果要访问一个网页只能通过打开手机内的浏览器，通过浏览器来加载网页，但是打开浏览器的同时，也脱离了当前的应用软件，这样就大大的降低了网页与应用软件的交互。随着Android SDK的不断升级，官方提供一个WebView控件，专门用于加载网页并实现交互。那么到底WebView是什么？又该如何使用呢？

什么是WebView？

简单来说WebView是移动端用于加载Web页面的控件。

怎么使用WebView?

1、移动端加载网页方式

A、通过打开浏览器访问网页

String weburl ="http://www.baidu.com/";

Uri uri = Uri.parse(weburl);// weburl网址

Intent intent = new Intent(Intent.ACTION_VIEW, uri);

startActivity(intent);

B、通过WebView打开本地网页

WebView.loadUrl("file:///android_asset/baidu.html");

注意1：本地文件放在assets文件中，assets文件是main的子文件，与res文件同级。
注意2：设置WebView支持加载本地文件。

WebSettings webSettings = webView.getSettings();

// 允许加载Assets和resources文件

webSettings.setAllowFileAccess(true);

C、通过WebView加载网址

webView.loadUrl("http://www.baidu.com/");

加载网址，需要在清单文件中加上网络请求权限

<uses-permission android:name="android.permission.INTERNET"/>

当WebView加载失败时，可以使用webView.reload();来重新加载。
注意：当加载完网页之后，如果发现网页无法点击，这很可能是WebView没有获取焦点。

webView.requestFocus();// 使页面获取焦点，防止点击无响应

2、WebView基本属性设置

WebView提供很多属性，需要通过WebSettings来进行设置，下面是对一些常用属性进行设置。

// 设置WebView相关属性

WebSettings webSettings = webView.getSettings();

// 是否缓存表单数据

webSettings.setSaveFormData(false);

// 设置WebView 可以加载更多格式页面

webSettings.setLoadWithOverviewMode(true);

// 设置WebView使用广泛的视窗

webSettings.setUseWideViewPort(true);

// 支持2.2以上所有版本

webSettings.setPluginState(WebSettings.PluginState.ON);

// 允许加载Assets和resources文件

webSettings.setAllowFileAccess(true);

// 告诉webview启用应用程序缓存api

webSettings.setAppCacheEnabled(true);

// 排版适应屏幕

webSettings.setLayoutAlgorithm(WebSettings.LayoutAlgorithm.NARROW_COLUMNS);

// 支持插件

webSettings.setPluginState(WebSettings.PluginState.ON);

// 设置是否启用了DOM storage AP搜索I

webSettings.setDomStorageEnabled(true);

// 设置缓存，默认不使用缓存-有缓存，使用缓存

webSettings.setCacheMode(WebSettings.LOAD_CACHE_ELSE_NETWORK);

// 是否允许缩放

webSettings.setSupportZoom(false);

// 是否支持通过js打开新的窗口

webSettings.setJavaScriptCanOpenWindowsAutomatically(true);

// 允许加载JS

webSettings.setJavaScriptEnabled(true);

// 隐藏滚动条

webView.setScrollBarStyle(WebView.SCROLLBARS_OUTSIDE_OVERLAY);

3、WebView默认是通过浏览器打开网页，如何使用WebView打开网页？

WebViewClient是WebView的一个重要属性，它不仅仅能够实现WebView打开网页，而且还能够实现URL重构等功能。

// WebView默认是通过浏览器打开url，使用url在WebView中打开

webView.setWebViewClient(new WebViewClient() {

//    // 旧版本

//    @Override

//    public boolean shouldOverrideUrlLoading(WebView view, String url) {

        // 使url在WebView中打开，在这里可以进行重构url

//        webView.loadUrl(url);

//        return true;

//    }



    // 新版本

    @Override

    public boolean shouldOverrideUrlLoading(WebView view, WebResourceRequest request) {

        // 返回false，意味着请求过程中，不管有多少次的跳转请求（即新的请求地址），均交给webView自己处理，这也是此方法的默认处理

        // 返回true，说明你自己想根据url，做新的跳转，比如在判断url符合条件的情况下，我想让webView加载http://baidu.com/

        // 加载Url，使网页在WebView中打开，在这里可以进行重构url

        if(Build.VERSION.SDK_INT>= Build.VERSION_CODES.LOLLIPOP) {

            webView.loadUrl(request.getUrl().toString());

        }

        return true;

    }



    // WebViewClient帮助WebView去处理页面控制和请求通知

    @Override

    public void onLoadResource(WebView view, String url) {

        super.onLoadResource(view, url);

    }



    // 错误代码处理，一般是加载本地Html页面，或者使用TextView显示错误

    @Override

    public void onReceivedError(WebView view, WebResourceRequest request, WebResourceError error) {

        // 当网页加载出错时，加载本地错误文件

//      webView.loadUrl("file:///android_asset/error.html");

    }



    // 页面开始加载-例如在这里开启进度条

    @Override

    public void onPageStarted(WebView view, String url, Bitmap favicon) {

        super.onPageStarted(view, url, favicon);

    }



    // 页面加载结束，一般用来加载或者执行javaScript脚本

    @Override

    public void onPageFinished(WebView view, String url) {

        super.onPageFinished(view, url);

    }

});

4、设置WebView的WebChromeClient属性

WebChromeClient是WebView中一个非常重要的属性，使用它可以监听网页加载的进度，获取网页主题等信息。

// 监听网页加载进度

webView.setWebChromeClient(new WebChromeClient() {

    // 网页Title信息

    @Override

    public void onReceivedTitle(WebView view, String title) {

        super.onReceivedTitle(view, title);

    }



    // 监听网页alert方法

    @Override

    public boolean onJsAlert(WebView view, String url, String message, JsResult result) {

        return super(view, url, message, result);

    }



    // 显示网页加载进度

     @Override

    public void onProgressChanged(WebView view, int newProgress) {

        // newProgress 1-100

    }

});

5、WebView中使用JavaScript

WebView与网页的交互大多数是使用JavaScript来实现

//设置WebView支持JavaScript

WebSettings webSettings = webView.getSettings();

webSettings.setJavaScriptEnabled(true);

6、下载文件监听

// 下载文件

webView.setDownloadListener(new DownloadListener() {

    @Override

    public void onDownloadStart(String url, String userAgent, String contentDisposition, String mimetype, long contentLength) {

        // url下载文件地址

        // 处理下载文件逻辑

    }

});

7、后退与前进

// 返回键监听

@Override

public boolean onKeyDown(int keyCode, KeyEvent event) {

    if (keyCode == KeyEvent.KEYCODE_BACK) {

        if (webView.canGoBack())

            // 判断WebView是否能够返回，能-返回

            webView.canGoBack();

        else

            finish();

        return true;

    }

    return super.onKeyDown(keyCode, event);

}

8、WebView优化-缓存

//设置缓存，默认不使用缓存

webSettings.setCacheMode(WebSettings.LOAD_CACHE_ELSE_NETWORK);//有缓存，使用缓存

webSettings.setCacheMode(WebSettings.LOAD_NO_CACHE);//不使用缓存

前言

在网络速度较慢的场景，一个有趣的加载会提高用户的耐心和对 App 的好感，有些 loading 动效甚至会让用户有想弄清楚整个动效过程到底是怎么样的冲动。然而，大部分的 App的 loading 就是下面这种千篇一律的效果 —— 俗称“转圈”。

本篇我们利用Flutter 的 PathMetric来玩几个有趣的 loading 效果。

效果1：圆环内滚动的球

如上图所示，一个红色的小球在蓝色的圆环内滚动，而且在往上滚动的时候速度慢，往下滚动的时候有个明显的加速过程。这个效果实现的思路如下：

• 绘制一个蓝色的圆环，在蓝色的圆环内构建一个半径更小一号的圆环路径（Path）。
• 让红色小球在动画控制下沿着内部的圆环定义的路径运动。
• 选择一个中间减速（上坡）两边加速的动画曲线。

下面是实现代码：

// 动画控制设置

controller =

  AnimationController(duration: const Duration(seconds: 3), vsync: this);

animation = Tween<double>(begin: 0, end: 1.0).animate(CurvedAnimation(

  parent: controller,

  curve: Curves.slowMiddle,

))

..addListener(() {

  setState(() {});

});



// 绘制和动画控制方法

_drawLoadingCircle(Canvas canvas, Size size) {

  var paint = Paint()..style = PaintingStyle.stroke

    ..color = Colors.blue[400]!

    ..strokeWidth = 2.0;

  var path = Path();

  final radius = 40.0;

  var center = Offset(size.width / 2, size.height / 2);

  path.addOval(Rect.fromCircle(center: center, radius: radius));

  canvas.drawPath(path, paint);

  

  var innerPath = Path();

  final ballRadius = 4.0;

  innerPath.addOval(Rect.fromCircle(center: center, radius: radius - ballRadius));

  var metrics = innerPath.computeMetrics();

  paint.color = Colors.red;

  paint.style = PaintingStyle.fill;

  for (var pathMetric in metrics) {

    var tangent = pathMetric.getTangentForOffset(pathMetric.length * animationValue);

    canvas.drawCircle(tangent!.position, ballRadius, paint);

  }

}

效果2：双轨运动

上面的实现效果其实比较简单，就是绘制了一个圆和一个椭圆，然后让两个实心圆沿着路径运动。因为有了这个组合效果，趣味性增加不少，外面的椭圆看起来就像是一条卫星轨道一样。实现的逻辑如下：

• 绘制一个圆和一个椭圆，二者的中心点重合；
• 在圆和椭圆的路径上分别绘制一个小的实心圆；
• 通过动画控制实心圆沿着大圆和椭圆的路径上运动。

具体实现的代码如下所示。

controller =

      AnimationController(duration: const Duration(seconds: 2), vsync: this);

  animation = Tween<double>(begin: 0, end: 1.0).animate(CurvedAnimation(

    parent: controller,

    curve: Curves.easeInOutSine,

  ))

    ..addListener(() {

      setState(() {});

    });



_drawTwinsCircle(Canvas canvas, Size size) {

  var paint = Paint()

    ..style = PaintingStyle.stroke

    ..color = Colors.blue[400]!

    ..strokeWidth = 2.0;



  final radius = 50.0;

  final ballRadius = 6.0;

  var center = Offset(size.width / 2, size.height / 2);

  var circlePath = Path()

    ..addOval(Rect.fromCircle(center: center, radius: radius));

  paint.style = PaintingStyle.stroke;

  paint.color = Colors.blue[400]!;

  canvas.drawPath(circlePath, paint);



  var circleMetrics = circlePath.computeMetrics();

  for (var pathMetric in circleMetrics) {

    var tangent = pathMetric

        .getTangentForOffset(pathMetric.length * animationValue);



    paint.style = PaintingStyle.fill;

    paint.color = Colors.blue;

    canvas.drawCircle(tangent!.position, ballRadius, paint);

  }



  paint.style = PaintingStyle.stroke;

  paint.color = Colors.green[600]!;

  var ovalPath = Path()

    ..addOval(Rect.fromCenter(center: center, width: 3 * radius, height: 40));

  canvas.drawPath(ovalPath, paint);

  var ovalMetrics = ovalPath.computeMetrics();



  for (var pathMetric in ovalMetrics) {

    var tangent =

        pathMetric.getTangentForOffset(pathMetric.length * animationValue);



    paint.style = PaintingStyle.fill;

    canvas.drawCircle(tangent!.position, ballRadius, paint);

  }

}

效果3：钟摆运动

 钟摆运动的示意图如下所示，一条绳子系着一个球悬挂某处，把球拉起一定的角度释放后，球就会带动绳子沿着一条圆弧来回运动，这条圆弧的半径就是绳子的长度。  这个效果通过代码来实现的话，需要做下面的事情：

• 绘制顶部的横线，代表悬挂的顶点；
• 绘制运动的圆弧路径，以便让球沿着圆弧运动；
• 绘制实心圆代表球，并通过动画控制沿着一条圆弧运动；
• 用一条顶端固定，末端指向球心的直线代表绳子；
• 当球运动到弧线的终点后，通过动画反转（reverse）控制球 返回；到起点后再正向（forward） 运动就可以实现来回运动的效果了。

具体实现的代码如下，这里在绘制球的时候给 Paint 对象增加了一个 maskFilter 属性，以便让球看起来发光，更加好看点。

controller =

        AnimationController(duration: const Duration(seconds: 2), vsync: this);

animation = Tween<double>(begin: 0, end: 1.0).animate(CurvedAnimation(

  parent: controller,

  curve: Curves.easeInOutQuart,

))

  ..addListener(() {

    setState(() {});

  }

  ..addStatusListener((status) {

   if (status == AnimationStatus.completed) {

     controller.reverse();

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

     controller.forward();

   }

 });



_drawPendulum(Canvas canvas, Size size) {

  var paint = Paint()

    ..style = PaintingStyle.stroke

    ..color = Colors.blue[400]!

    ..strokeWidth = 2.0;



  final ceilWidth = 60.0;

  final pendulumHeight = 200.0;

  var ceilCenter =

      Offset(size.width / 2, size.height / 2 - pendulumHeight / 2);

  var ceilPath = Path()

    ..moveTo(ceilCenter.dx - ceilWidth / 2, ceilCenter.dy)

    ..lineTo(ceilCenter.dx + ceilWidth / 2, ceilCenter.dy);

  canvas.drawPath(ceilPath, paint);



  var pendulumArcPath = Path()

    ..addArc(Rect.fromCircle(center: ceilCenter, radius: pendulumHeight),

        3 * pi / 4, -pi / 2);



  paint.color = Colors.white70;

  var metrics = pendulumArcPath.computeMetrics();



  for (var pathMetric in metrics) {

    var tangent =

        pathMetric.getTangentForOffset(pathMetric.length * animationValue);



    canvas.drawLine(ceilCenter, tangent!.position, paint);

    paint.style = PaintingStyle.fill;

    paint.color = Colors.blue;

    paint.maskFilter = MaskFilter.blur(BlurStyle.solid, 4.0);

    canvas.drawCircle(tangent.position, 16.0, paint);

  }

}

总结

本篇介绍了三种 Loading 动效的绘制逻辑和实现代码，可以看到利用路径属性进行绘图以及动画控制可以实现很多有趣的动画效果。

作为一名前端工程师我浪费时间学习了这些技术

不要犯我曾经犯过的错误！

我2015年刚刚开始学习前端开发的时候，我在文档和在线教程上了解到了许多技术，我浪费大量时间去学习这些技术。

在一个技术、库和框架数量不断增长的行业中，高效地学习才是关键。不管你是新的Web开发人员，还是你已经入门前端并有了一些开发经验，都可以了解一下，以下列出的技术，要么是我花费时间学习但从未在我的职业生涯中实际使用过的，要么是2021年不再重要的事情(也就是说，你可以不知道)。

问题

我们在开发过程中，发现后端 API 请求特别慢，于是跟后端抱怨。

“怎么 API 这么慢啊，请求一个接口要十几秒”。

而且这种情况是偶现的，前端开发同学表示有时候会出现，非必现。

但是后端同学通过一顿操作后发现，接口没有问题，他们是通过 postman 工具以及 test 环境尝试，都发现接口请求速度是没有问题的。

“那感觉是前端问题”?

我们来梳理一下问题，如下：

• 后端 API 请求特别慢，而且是偶现的。


• 在 test 环境没有复现。


• postman 工具请求没有复现。

问题解决过程

时间都去哪了？

第一个问题，API 耗费的时间都用来做什么了？

我们打开 Chrome 调试工具。在 network 中可以看到每个接口的耗时。

hover 到你的耗时接口的 Waterful，就可以看到该接口的具体耗时。

可以看到，其耗时主要是在 Stalled，代表浏览器得到要发出这个请求的指令到请求可以发出的等待时间，一般是代理协商、以及等待可复用的 TCP 连接释放的时间，不包括 DNS 查询、建立 TCP 连接等时间等。

所以 API 一直在等待浏览器给它发出去的指令，以上面截图的为例，整整等待了 23.84S，它请求和响应的时间很快（最多也就几百毫秒，也就是后端所说的接口并不慢）。

所以 API 到底在等待浏览器的什么处理？

什么阻塞了请求？

经过定位，我们发现，我们项目中使用 Server-Sent Events（以下简称 SSE）。它跟 WebSocket 一样，都是服务器向浏览器推送信息。但不同的是，它使用的是 HTTP 协议。

当不通过 HTTP / 2 使用时，SSE 会受到最大连接数的限制，限制为 6 次。此限制是针对每个浏览器 + 域的，因此这意味着您可以跨所有选项卡打开 6 个 SSE 连接到 http://www.example1.com，并打开 6 个 SSE 连接到 http://www.example2.com。这一点可以通过以下这个 demo 复现。

复制问题的步骤：

• 访问ssebin.btubbs.com/multi/


• 单击添加计数器6或更多次


• 尝试打开另一个标签到同一地址

结果是，第 6 次之后，SSE 请求一直无法响应，打开新的标签到同一个地址的时候，浏览器也无法访问。

效果图如下：

该问题在 Chrome 和 Firefox 中被标记为“无法解决”。

至于偶现，是因为前端开发者有时候用 Chrome 会打开了多个选项卡，每个选项卡都是同一个本地开发地址，就会导致达到 SSE 的最大连接数的限制，而它的执行时间会很长，也就会阻塞其他的请求，一致在等待 SSE 执行完。

所以解决的方法是什么？

解决方案

简单粗暴的两个方法

• 不要打开太多个选项卡。这样就不会达到它的限制数。（因为我们一个选项卡只请求一个 SSE）。


• 开发环境下，关闭该功能。

使用 HTTP / 2

使用 HTTP / 2 时，HTTP 同一时间内的最大连接数由服务器和客户端之间协商（默认为 100）

这解释了为什么我们 test 环境没有问题，因为 test 环境用的是 HTTP / 2。而在开发环境中，我们使用的是 HTTP 1.1 就会出现这个问题。

那如何在开发环境中使用 HTTP / 2 呢？

我们现在在开发环境，大部分还是使用 webpack-dev-server 起一个本地服务，快速开发应用程序。在文档中，我们找到 server 选项，允许设置服务器和配置项（默认为 'http'）。

只需要加上这一行代码即可。

devServer: {

+  server: 'spdy',

  port: PORT,

}

看看效果，是成功了的。

原理使用 spdy 使用自签名证书通过 HTTP/2 提供服务。需要注意的一点是：

该配置项在 Node 15.0.0 及以上的版本会被忽略，因为 spdy 在这些版本中不会正常工作。一旦 Express 支持 Node 内建 HTTP/2，dev server 会进行迁移。

总结归纳

原本这个问题认为跟前端无关，没想到最后吃瓜吃到自己头上。提升相关技能的知识储备以及思考问题的方式，可能会方便我们定位到此类问题。

充分利用好浏览器的调试工具，对一个问题可以从多个角度出发进行思考。比如一开始，没想到本地也可以开启 HTTP / 2。后来偶然间想搜下是否有此类方案，结果还真有！

本来这篇文章很早就应该写的，一直没(比)有(较)时(懒)间

今天决定把它写完咯

首先表明态度, I think:

网上流传的 ViewModel + LiveData + XXX 的号称 MVVM 的代码设计基本都是假的（fake news :P)

MVVM

首先说一下 MVVM 这种架构模式（或者说设计模式），我对它的认识源于维基百科

我们来看看关于 MVVM 各组件的标准定义

• model: 没啥好说的，跟 MVP MVC 之流大差不差，定义了业务（数据）逻辑和数据的模型


• view: 还是没啥好说的，就是视图层，用户界面


• view-model: 关键在这里，我们所谓的 view-model 其实是从 presenter 胶水演化出来的，暴露视图的公开属性和指令，本质上就是 view 视图对应的一个 model
  
  
  
  • 首先，它是一个 view model，对 model 层暴露来自 view 层的一些公开属性，以及来自 view 层的一些指令（presenter?）
  
  
  • And，binder:
    view-model 区别于 presenter 与 controller，它有一个称之 binder 的东西，作用是处理 view-model 中暴露的视图属性（状态）与视图 UI 的自动同步
  
  
  
  

所以 MVVM 模式下的流转路径应该是这样的：

• view: user input event -> view-model: view property or command


• view-model: handle input, biz model -> model: biz data/logic processing


• model: state chagne events(data) -> view-model: handle biz state


• view-model: ui state update -> binder: handle ui state synching

MVP

ok，我们再来看一下 MVP 是怎么流转的

• view: User input event -> presenter: function (command)


• presenter: biz model -> model: biz data/logic processing


• model: state change events(data) -> presenter: convert biz state


• presenter: biz state/data -> view: refresh ui

仔细对比一下往上流传的基于 Jetpack ViewModel + LiveData 的伪 MVVM（MVP）的流转情况：

1. Activity/Fragemnt -> ViewModel, 这是 view -> presenter


2. ViewModel 调用 model 处理网络请求、数据逻辑、文件 IO 等业务逻辑，这是 presenter -> model


3. 这里我们看一下在 ViewModel 中完成了业务逻辑通知 UI 刷新，通过 LiveData 的 setValue/postValue 更新状态，
   
   view 层通过 viewModel.xxxLiveData.observe(lifecycleOwner) { data -> … }

在最后一个环节，我们对比一下经典的 MVP 模式的写法：presenter 通过持有的 view 接口通知视图变更，view 层在对应的接口实现中完成对 UI 组件的更新

看 ~ 发现了什么

即使是通过 LiveData 观察者模式在 view 层实现对数据的观察，省去了经典 MVP 写法的 view 接口定义和耦合，但是在事件（数据）流转的路径上，依然是走的 MVP 的模式

对比 MVVM 定义的工作流程，不难发现，其中最大的差异在于 binder 这个角色的存在

binder 作为实现数据和 UI 同步的重要组件，同时按照 MVVM 模式的定义，属于 view-model 的内部成员

因此可以得出结论：MVVM 的关键在于，用户事件的流转是单向，从 view 层开始，到 view-model 结束；而这其中的关键在于 binder

Jetpack data-binding

Databinding 就是 Google 爸爸为我们提供的一个官方 binder 实现方案

即：

• MVVM 中的 binder 可以直接使用官方 data-binding 组件来实现


• 不使用 data-binding 组件，自定义处理数据与 UI 的同步的 binder 并在 view-model 中维护，也是规范的 MVVM 写法

DataBinding 分为两个部分

ViewDataBinding：每个被 <layout> 标签包裹的布局都会对应生成一个 ViewDataBinding 的子类作为视图与数据绑定的管理者
Observable/BaseObservable: 实际的 binder 开发接口，需要绑定与 view 层建立绑定关系的数据通过实现此接口并注册成员，即可自动完成监听与同步（实际代码在生成的 XxxLayoutBindingImpl 类中）

关于 DataBinding 的使用及原理，此处不予赘述

MVVM 在实际项目中的落地

sample Activity

class SampleBindingActivity : AppCompatActivity(), ActivityBindingHolder<SampleActivityBinding> by ActivityBinding(R.layout.sample_activity) {



    private val viewModel: SampleViewModel by viewModel()



    override fun onCreate(savedInstanceState: Bundle?) {

        // replace setContentView(), and hold binding instance

        inflateBinding { binding ->

            // init with binding

            binding.initView()

            …

            viewModel.bind(binding)

        }

        …

    }



    private fun SampleActivityBinding.initView() {

        val random = Random()

        btnTest.onClick {

            viewModel.random = random.nextInt(100)

        }

    }

}

sample layout

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

    <data>

        <variable

            name="binder"

            type="package.SampleBinder" />

    </data>



    <androidx.constraintlayout.widget.ConstraintLayout

        android:layout_width="match_parent"

        android:layout_height="wrap_content">



        <androidx.appcompat.widget.AppCompatTextView

            android:id="@+id/tv_nickname"

            android:layout_width="wrap_content"

            android:layout_height="wrap_content"

            android:maxLines="1"

            android:text="@{binder.nickname}"

            android:textSize="12sp"

            app:layout_constraintBottom_toTopOf="parent"

            app:layout_constraintEnd_toEndOf="@id/channel_name"

            app:layout_constraintStart_toStartOf="@id/program_vip" />



        <androidx.appcompat.widget.AppCompatButton

            android:id="@+id/btn_test"

            android:layout_width="0dp"

            android:layout_height="wrap_content"

            app:layout_constraintEnd_toEndOf="parent"

            app:layout_constraintStart_toStartOf="parent"

            app:layout_constraintTop_toBottomOf="@id/tv_nickname" />

    </androidx.constraintlayout.widget.ConstraintLayout>

</layout>

sample view-model

class SampleViewModel : ViewModel() {



    var random: Int by ObservableProperty(0) { binder.nickname = "Nickname_$it" }



    private val model = SampleModel() // biz handler model, network/data/io etc.

    private val binder = SampleBinder() // binder for sync data and view state



    fun bind(binding: ViewDataBinding) {

        binding.setVariable(BR.binder, binder)

    }



    …

}

sample binder

class SampleBinder : BaseObservable() {



    @get:Bindable

    var nickname: String by observableField(BR.nickname, "Nickname")



    …

}

前言

今天继续探索绘制与手势的组合实践，之前在看电子书切换页面时会有一个模拟纸质书籍翻页效果，这是典型的绘制和手势的结合实现的效果，那么今天我们就用Flutter也实现这样的一个效果吧。

原理

大家可以找本书翻页到一半看下效果，从右下角翻到一半时，我们可以将可视区域分为下图A、B、C三部分区域。

A:下一页可视区域。

B：当前页不可视区域，翻的页不可见的区域。

C:当前页可视区域，也就是需要翻的页的可视区域。

原理分解：

我们可以先将A区域和B区域合为一个区域计算，那么根据路径联合C区域自然就可以得到，至于A、B区域区分后面再讲，看下图：



a为手指触摸点，表示翻页右下角位置。【已知】

f为固定书籍右下角位置。【已知】

a点和f已知，连接af,我们令g点为af的中点，过g点连接eh垂直af,为af中垂线， 可得 g = Point((a.x + f.x) / 2, (a.y + f.y) / 2)；

并且知道△egf、△emg、△mfg为三个直角三角形，由直角三角形相似原理可知这三个三角型两两相似，所以，△emg相似△mfg，可知:

em/gm = gm/mf;

em = gm*gm/mf;

因为：gm = f.y-a.y; mf=f.x-g.x;

可得 e = Point(g.x - (pow(f.y - g.y, 2) / (f.x - g.x)), f.y);

同理过g点做fh垂直线可得h点坐标。略...

从上方理论图可知，cdb是一条二阶贝塞尔曲线，控制点为e点， ab和ak为直线线段，接下来我们令n为ag的中点,同理过n点垂直于af连接cj，可知ce等于ef的一半；（可以画辅助线过gf中点垂直af得出）。

所以可得 c = Point(e.x - (f.x - e.x) / 2, f.y);

j点坐标同理。略...

接下来我们看下b点，目前我们已知 a、e、c、j点坐标，现在b点就是ae和cj的相交点。

那么问题来了：

用我们九年义务教育学的数学知识解决以下两个问题。

1、在坐标系中，已知两点（x1,y1）、(x2,y2)坐标，求过这两点直线函数？

2、已知两条直线函数求两条直线的相交点？

我们知道直线函数表达式为：y=kx+b；，假设k为正常值，我们可求得k和b的值，

/// 两点求直线方程

static double towPointKb(Point p1, Point p2,

    {bool isK = true}) {

  /// 求得两点斜率

  double k = 0;

  double b = 0;

  // 防止除数 = 0 出现的计算错误 a e x轴重合

  if (p1.x == p2.x) {

  // k 为无穷大 函数表达式变为 x= 常量。

    k = (p1.y - p2.y) / (p1.x - p2.x-1);

  } else {

    k = (p1.y - p2.y) / (p1.x - p2.x);

  }

  b = p1.y - k * p1.x;

  if (isK)

    return k;

  else

    return b;

}

通过两条直线表达式的k值和b值，我们就可以求出两条直线是否平行、相交、重合等情况，若相交则可求出。

k相同b不同：平行无交点。

k相同b相同：重合。

k不同无论b相不相同，相交必有一交点。

那么就可得出b点坐标：(假设k永不相等)

b = Point((b2 - b1) / (k1 - k2), (b2 - b1) / (k1 - k2) * k1 + b1);

k点坐标同理。略...

绘制

以上AB区域的关键点已经全部得到了，我们将辅助线去掉将这些点连接起来看下效果。

得到AB区域的同时，我们间接的就得到了C区域，

// mPath 为书籍矩形区域

Path mPathC = Path.combine(PathOperation.reverseDifference, mPathAB, mPath);

接下来将AB区域进行区分，再回到上方，坐标图黄色线条部分，我们可以看到d点和i点坐标。

通过原理解析我们可知d点为pe的中点，而p点为cb的中点，那么就可以得出：

p.x = (e.x -c.x)/2; ,d.x = (e.x-p.x)/2;

p.y = (e.y -b.y)/2; ,d.y = (e.y-p.y)/2;

所以可得 d = Point(((c.x + b.x) / 2 + e.x) / 2, ((c.y + b.y) / 2 + e.y) / 2);

i点坐标同理。略...
接下来我们连接d、a、i三角形区域，得到以下图形，

同理通过路径联合我们就可以将AB区域进行分开，

Path mPath1 = Path();

mPath1.moveTo(p.value.d.x, p.value.d.y);

mPath1.lineTo(p.value.a.x, p.value.a.y);

mPath1.lineTo(p.value.i.x, p.value.i.y);

mPath1.close();

Path mPathB = Path.combine(PathOperation.intersect, mPathAB, mPath1);

得到以下图形，

到这里梳理一下，目前我们A、B、C三个path路径区域已经全部得到，剩下的就是填充书籍颜色，接下来我们将画笔设置为填充不同颜色，通过手势不断变化a点坐标看下效果。

是不是有点翻书的意思了，这里有一个问题，书籍的左下角也就是c点坐标在我们翻页的过程中会跑到页面之外，一般书籍都是左侧装订，这里我们希望达到一个真实的翻页效果就需要将c点的x轴最小值设置为书籍最左侧0。

这里涉及到相似图形的数学知识，手指触摸点是在不断变化的，当c点x轴达到临界值固定的时候，我们需要重新计算a点坐标，
见下图，



a是我们真实的手指触碰的坐标,a1则为我们需要计算出来的触碰坐标，从上图可知，△acb相似△a1b1c1,并且acfd区域相似a1c1d1f，那么通过相似原理我们可以得到fb1/fc1 = fb/fc;

从而得到，fb1= fb * fc1/fc;,

已知：

fb = f.x - a.x;

fc1 = size.width;

fc = f.x-c.x;

同理 fd1/fd = fb1/fb; 得到，fd1 = fb1 * fd/fb; 即可得到a1点坐标。

计算代码：

double fc = f.x - cx;

double fa = f.x - a.x;



double bb1 = size.width * fa / fc;



double fd1 = f.y - a.y;

double fd = bb1 * fd1 / fa;



a1 = Point(f.x - bb1, f.y - fd);

这时候我们再来看下效果，

c点坐标被我们设定最小值为书籍最左侧，所以左侧不会被翻出区域，看起来更像真实的翻页效果。

添加阴影

我们可以在灯光下找本书翻页看下阴影效果，差不多是这个样子，这里我将阴影分为三个部分，A区域两个和C区域一个。

我们先添加A左区域的阴影，A左区域的阴影可以认为是从ha方向由h向a进行色值渐变，所以这里我们需要得到A左阴影区域左上角坐标点，也就是ha直线向外延伸固定数值的坐标。

可以理解为数学题表达：

已知ha直线方程式和a点坐标， 以a为圆心，画半径为r（r>0）的圆，

求：此圆和ha直线的相交的坐标。

设交点为坐标xy,可得 x²+y² =r²； y = kx+b;(k、b 、r)已知，最终我们得到一个一元二次方程。会解出两个坐标点，这里我们只需要往外延伸的坐标点就行，具体可以跟a点坐标判断得出，之后我们令double m1 = a.x-p1.x;double n1 = a.y-p1.y;

那么阴影外部曲线就可以用下方代码表示。

pyy1.moveTo(p.value.c.x - m1, p.value.c.y);

pyy1.quadraticBezierTo(p.value.e.x - m1, p.value.e.y - n1,

    p.value.b.x - m1, p.value.b.y - n1);

pyy1.lineTo(p.value.p.x, p.value.p.y);

pyy1.lineTo(p.value.k.x, p.value.k.y);

pyy1.lineTo(p.value.f.x, p.value.f.y);

pyy1.close();

绘制出来看下效果



同理路径联合下：

Path startYY =

    Path.combine(PathOperation.reverseDifference, mPathA, pyy1);

得到:



接下来通过设置画笔属性由a点向p1点进行渐变。

..shader = ui.Gradient.linear(

    Offset(p.value.a.x, p.value.a.y),

    Offset(p.value.p.x, p.value.p.y),

    [Colors.black26, Colors.transparent]

效果：

这里我设置了由 black26，向透明渐变。延伸长度为10的效果，这里可以根据半径和色值调整影深。

A右同理，略...

效果：

接下来我们绘制C区域的阴影，C区域可以看到他是跟eh是平行的，那么我们连接c、j、h、e点,

// 右下

Path pr = Path();

pr.moveTo(p.value.c.x, p.value.c.y);

pr.lineTo(p.value.j.x, p.value.j.y);

pr.lineTo(p.value.h.x, p.value.h.y);

pr.lineTo(p.value.e.x, p.value.e.y);

pr.close();

得到下面效果：

继续与AB区域进行路径联合，

Path p1 = Path.combine(PathOperation.intersect, pr, mPathAB);

得到下面效果：

继续与B区域再次联合，

Path p2 = Path.combine(PathOperation.difference, p1, mPathB);

最终得到我们想要的阴影区域。

接下来就是跟A区域操作一样了，设置线性渐变色和渐变方向，这里渐变方向的坐标点我们为u点和g点，g点已知，主要求u点坐标，u点坐标为af和di直线的相交点。

通过两条直线方程求相交点，得到u点以后，设置渐变色和渐变方向。

核心代码：

// 右下

Path pc = Path();

pc.moveTo(p.value.c.x, p.value.c.y);

pc.lineTo(p.value.j.x, p.value.j.y);

pc.lineTo(p.value.h.x, p.value.h.y);

pc.lineTo(p.value.e.x, p.value.e.y);

pc.close();



Path p1 = Path.combine(PathOperation.intersect, pc, mPathA);

Path p2 = Path.combine(PathOperation.difference, p1, mPathB);



Offset u = Offset(

    PaperPoint.toTwoPoint(p.value.a, p.value.f, p.value.d, p.value.i)

        .x,

    PaperPoint.toTwoPoint(p.value.a, p.value.f, p.value.d, p.value.i)

        .y);

canvas.drawPath(

    p2,

    paint

      ..style = PaintingStyle.fill

      ..shader = ui.Gradient.linear(

          u, Offset(p.value.g.x,p.value.g.y), [Colors.black26, Colors

          .transparent]));

最后得到我们最终的效果。

这里阴影部分可能有些瑕疵，尤其上方a点坐标的处理有点生硬，但是没找到好的方式。以后有时间再优化。

翻页动画、回弹动画

目的： 我们希望可以滑动过程中页码可以自动翻过去，并且误触的情况下不要翻页。

这里我简单的判断当翻过去书籍宽度的3/1就理解为用户想翻页，当手势松开时自动翻过去；

当翻过去书籍宽度小于1/3,理解为用户误触并不想翻页，当手势松开自动回弹回去。

这里判断还可以根据用户滑动的速度进行判断，比如按下和松开之间的时间很快并且有想左滑动的距离，我们就可以判定用户想要翻页，不过这里就需要不断的调试优化达到一个比较理想的交互。

初始化动画

回弹动画，我们希望松开手指时，a点坐标回到和f点重合，这里我们需要在点击或移动的过程中保存当前手指触摸的坐标a，

var move = d.localPosition;

// 临界值书籍以外区域 取消更新

if (move.dx >= size.width ||

    move.dx < 0 ||

    move.dy >= size.height ||

    move.dy < 0) {

  return;

}

currentA = Point(move.dx, move.dy);

...

if ((size.width - move.dx) / size.width > 1 / 3) {

  isNext = false;

} else {

  isNext = true;

}

然后通过动画将a点坐标置位f点；

Point currentA = Point(0, 0);

late AnimationController _controller = AnimationController(

    vsync: this, duration: Duration(milliseconds: 800))

  ..addListener(() {

    if (isNext) {

      /// 不翻页 回到原始位置

      _p.value = PaperPoint(

          Point(

            currentA.x + (size.width - currentA.x) * _controller.value,

            currentA.y + (size.height - currentA.y) * _controller.value,

          ),

          size);

    } else {

      /// 翻页

      _p.value = PaperPoint(

          Point(currentA.x - (currentA.x + size.width) * _controller.value,

              currentA.y + (size.height - currentA.y) * _controller.value),

          size);

    }

  });

翻页，我们希望a点坐标和(-f.x,f.y)重合，也就是f.x为负值，相当也我们书籍彻底翻过去，

这里需要注意的是当a.x<0时，也就是书籍左侧外面区域，这里需要将我们之前设定c值的最小值放开，否则无法彻底翻过去。

只有a.x>0才限制cx坐标点

if (a.x > 0) {

  if (cx <= 0) {

    //   // 临界点

    double fc = f.x - cx;

    double fa = f.x - a.x;

    double bb1 = size.width * fa / fc;

    double fd1 = f.y - a.y;

    double fd = bb1 * fd1 / fa;

    a = Point(f.x - bb1, f.y - fd);

    g = Point((a.x + f.x) / 2, (a.y + f.y) / 2);

    e = Point(g.x - (pow((f - g).y, 2) / (f - g).x), f.y);

    cx = 0;

  }

}

ok,有了这些数据以后，我们看下效果。

填充内容

最后一步，填充内容，模拟书籍嘛，当然不能是这些纯色翻页了，上面我们有了A B C三个路径的区域，接下来就需要对书籍内容Widget进行裁剪，这里我们需要路径裁剪类ClipPath类，

// 裁剪的路径区域 默认组件的矩形区域

final CustomClipper? clipper;



const ClipPath({

  Key? key,

  this.clipper,

  this.clipBehavior = Clip.antiAlias,

  Widget? child,

}) : assert(clipBehavior != null),

     super(key: key, child: child);

     

可以看到构造里有三个参数，除了子组件，clipBehavior是裁剪方式，可以设置抗锯齿等，clipper则是我们的核心裁剪方法，需要实现CustomClipper类里的Path getClip(Size size);方法。

通过它返回一个Path路径，即可将child进行自定义裁剪。

ok, 有了方法，接下来我们开始实现，首先我们将之前A区域的Path路径拿出来，裁剪当前页，通过Stack帧布局加载当前页和下一页内容，下一页内容永远在第一页内容下面，当翻过去动画结束时将下方页置位当前页，刷新第二页数据。

翻页动画结束当前页index+1;

if (status == AnimationStatus.completed) {

  if (!isNext) {

    setState(() {

      currentIndex++;

    });

  }

}

填充内容布局代码：

// 定义电子书数据

List dataList = [

  "第一页数据",

  "第二页数据",

  "第三页数据",

];



GestureDetector(

  child: Stack(

    children: [

      currentIndex == dataList.length - 1

          ? SizedBox()

          // 下一页

          : ClipPath(

              child: Container(

                alignment: Alignment.center,

                color: Colors.blue,

                width: size.width,

                height: size.height,

                child: Text(

                  dataList[currentIndex + 1],

                  style: TextStyle(fontSize: 20),

                ),

              ),

            ),

      // // 当前页

      ClipPath(

        child: Container(

          alignment: Alignment.center,

          width: size.width,

          height: size.height,

          color: Colors.blue,

          child: Text(

            dataList[currentIndex],

            style: TextStyle(fontSize: 20),

          ),

        ),

        clipper: CurrentPaperClipPath(_p),

      ),



      // 最上面只绘制B区域和阴影

      CustomPaint(

        size: size,

        painter: _BookPainter(

          _p,

        ),

      ),

    ],

  ),

  onPanDown: (d) {

    if (currentIndex == dataList.length - 1) {

      ToastUtil.show("最后一页了");

      return;

    }

    isNext = false;

    var down = d.localPosition;

    _p.value = PaperPoint(Point(down.dx, down.dy), size);

    currentA = Point(down.dx, down.dy);

  },

  onPanUpdate: currentIndex == dataList.length - 1

      ? null

      : (d) {

          var move = d.localPosition;



          // 临界值取消更新

          if (move.dx >= size.width ||

              move.dx < 0 ||

              move.dy >= size.height ||

              move.dy < 0) {

            return;

          }

          currentA = Point(move.dx, move.dy);

          _p.value = PaperPoint(Point(move.dx, move.dy), size);



          if ((size.width - move.dx) / size.width > 1 / 3) {

            isNext = false;

          } else {

            isNext = true;

          }

        },

  onPanEnd: currentIndex == dataList.length - 1

      ? null

      : (d) {

          _controller.forward(

            from: 0,

          );

        },

),







/// 当前页区域

class CurrentPaperClipPath extends CustomClipper {

  ValueNotifier p;



  CurrentPaperClipPath(

    this.p,

  ) : super(reclip: p);



  @override

  Path getClip(Size size) {

    ///书籍区域

    Path mPath = Path();

    mPath.addRect(Rect.fromCenter(

        center: Offset(size.width / 2, size.height / 2),

        width: size.width,

        height: size.height));



    Path mPathA = Path();

    if (p.value.a != p.value.f && p.value.a.x > -size.width) {

      print("当前页 ${p.value.a}  ${p.value.f}");

      mPathA.moveTo(p.value.c.x, p.value.c.y);

      mPathA.quadraticBezierTo(

          p.value.e.x, p.value.e.y, p.value.b.x, p.value.b.y);

      mPathA.lineTo(p.value.a.x, p.value.a.y);

      mPathA.lineTo(p.value.k.x, p.value.k.y);

      mPathA.quadraticBezierTo(

          p.value.h.x, p.value.h.y, p.value.j.x, p.value.j.y);

      mPathA.lineTo(p.value.f.x, p.value.f.y);

      mPathA.close();

      Path mPathC =

          Path.combine(PathOperation.reverseDifference, mPathA, mPath);

      return mPathC;

    }



    return mPath;

  }



  @override

  bool shouldReclip(covariant CurrentPaperClipPath oldClipper) {

    return p != oldClipper.p;

  }

}

最终看下效果.

返回上一页

上面只有翻页，没有返回上一页，其实返回上一页也很简单，上面我们实现了回弹动画，这里只需要修改当前a点坐标为为书籍左侧外面，之后调用回弹动画，当前页面-1即可。非常简单。

ElevatedButton(

    onPressed: () {

      setState(() {

    // 表示从页面左侧外面开始回弹

        currentA = Point(-100, size.height - 100);

        currentIndex--;

        // 回弹动画

        isNext = false;

      });

      // _p.value = PaperPoint(currentA, size);

      _controller.forward(

        from: 0,

      );

    },

    child: Text("上一页"))

下面再看下最终效果：

这里示例只是简单的填充了一个Text文本，更多内容也是可以的，毕竟裁剪的是个Widget。

总结

翻页示例可以说是手势和绘制的典型结合，实现过程中也是踩了许多的坑，网上找了很多资料，并且实现原理上也用到了一些初中数学知识，总的来说，过程还是比较曲折的，本篇文章主要讲了我在实现的过程中的一个详细过程及思路，代码目前先不传了，毕竟现在还是有些小问题，后续有时间再优化吧，后续有时间也许会将他优化下，做成一个开源组件，ok，那本篇文章到这里就结束了，希望对你有所帮助～

前言

ViewMode 是我们日常开发中最常用的组件之一，也是实现 MVVM 模式不可缺少的一环，这篇文章将从使用到源码分析以及常见的一些知识点来分析一下 ViewModel

了解 ViewModel

ViewModel 旨在注重生命周期的方式存储和管理界面的相关数据，ViewModel 类可以再发生旋转等配置更改后继续留存。

一般 ViewModel 配合 LiveData / Flow 实现数据驱动，由于 Activity 存在因配置改变而重建的机制，就会造成页面的数据丢失，例如网络数据已经其他数据等，而 ViewModel 可以应对 Activity 应配置而改变的场景，再重建的过程中恢复数据，从而降低用户体验受损。

ViewModel 生命周期如下:

上图说明了 Activity 经历屏幕旋转而后结束的各种生命周期状态，旁边显示的就是 ViewModel 的生命周期了。

ViewModel 的使用

class MyViewModel : ViewModel() {

    private val users: MutableLiveData<List<User>> by lazy {

        MutableLiveData<List<User>>().also {

            loadUsers()

        }

    }



    fun getUsers(): LiveData<List<User>> {

        return users

    }



    private fun loadUsers() {

        // Do an asynchronous operation to fetch users.

    }

}

val model: MyViewModel by viewModels()

model.getUsers().observe(this, Observer<List<User>>{ users ->

   // update UI

})

ViewModel 的创建方式

• 方式1：通过 ViewModelProvider 创建

  ViewModelProvider(this).get(WorkViewModel::class.java)
  

  也可以使用带工厂的创建方式

  ViewModelProvider(this, WorkViewModelFactory()).get(WorkViewModel::class.java)
  
  
  
  class WorkViewModelFactory() : ViewModelProvider.Factory {
  
  
  
      private val repository = WorkRepository()
  
  
  
      override fun <T : ViewModel> create(modelClass: Class<T>): T {
  
          return WorkViewModel(repository) as T
  
      }
  
  }
  

• 方式2：使用 Kotlin by 委托属性，实际上也是使用了 ViewModelProvider

  private val viewModel by viewModels<UserViewModel>()
  

• 方式3：使用 Hilt 进行注入

ViewModel 源码分析

Viewmodel 创建的方法最终都是通过 ViewModelProvider 来完成的，他可以理解为创建 ViewModel 的工具类，在创建的时候需要两个参数：

• ViewModelStoreOwner

  对应着 Activity / Fragment 等持有 Viewmode 的宿主，他们内部通过 ViewModelStore 维持一个 ViewModel 的映射表，ViewModelStore 是实现 ViewModel 作用域和数据恢复的关键。

• Factory

  对于于创建 ViewModel 的工厂，如果没有传采用默认的 NewInstanceFactory 工厂反射创建 VIewModel 的实例。

创建完 ViewModelProvider 工具类后，就可以调用 get 方法来创建 ViewModel 的实例。get 方法会先从映射表 ViewModelStore 中读取缓存，若没有命中，则通过 VIewModel 的工厂创建实例在缓存到映射表中。

ViewModelProvider

//使用默认的工厂创建 ViewModel

public ViewModelProvider(@NonNull ViewModelStoreOwner owner) {

		this(owner.getViewModelStore(), ...NewInstanceFactory.getInstance());

}



//指定工厂

public ViewModelProvider(@NonNull ViewModelStoreOwner owner, @NonNull Factory factory) {

		this(owner.getViewModelStore(), factory);

}

//记录宿主的 viewmodelStore 和 factory

public ViewModelProvider(@NonNull ViewModelStore store, @NonNull Factory factory) {

		mFactory = factory;

		mViewModelStore = store;

}

private static final String DEFAULT_KEY =

            "androidx.lifecycle.ViewModelProvider.DefaultKey";



@NonNull

@MainThread

public <T extends ViewModel> T get(@NonNull Class<T> modelClass) {

    String canonicalName = modelClass.getCanonicalName();

    if (canonicalName == null) {

        throw new IllegalArgumentException("Local and anonymous classes can not be ViewModels");

    }

    //使用 Default_key + 类名作为缓存的 key

    return get(DEFAULT_KEY + ":" + canonicalName, modelClass);

}



/** 通常是 fragment 使用*/

@SuppressWarnings("unchecked")

@NonNull

@MainThread

public <T extends ViewModel> T get(@NonNull String key, @NonNull Class<T> modelClass) {

  //先从 viewModelStore 中获取缓存  

  ViewModel viewModel = mViewModelStore.get(key);



    if (modelClass.isInstance(viewModel)) {

        if (mFactory instanceof OnRequeryFactory) {

            ((OnRequeryFactory) mFactory).onRequery(viewModel);

        }

        return (T) viewModel;

    } 

    //使用 factory 创建 ViewModel

    if (mFactory instanceof KeyedFactory) {

        viewModel = ((KeyedFactory) mFactory).create(key, modelClass);

    } else {

        viewModel = mFactory.create(modelClass);

    }

   //存储到 viewModelStore 中

    mViewModelStore.put(key, viewModel);

    return (T) viewModel;

}

NewInstanceFactory

public static class NewInstanceFactory implements Factory {

    private static NewInstanceFactory sInstance;



    @NonNull

    static NewInstanceFactory getInstance() {

        if (sInstance == null) {

            sInstance = new NewInstanceFactory();

        }

        return sInstance;

    }



 

    @NonNull

    @Override

    public <T extends ViewModel> T create(@NonNull Class<T> modelClass) {

       //反射创建 ViewModel

        try {

            return modelClass.newInstance();

        }....

    }

}

by viewModels

ActivityViewModelLazy

@MainThread

public inline fun <reified VM : ViewModel> ComponentActivity.viewModels(

    noinline factoryProducer: (() -> Factory)? = null

): Lazy<VM> {

    val factoryPromise = factoryProducer ?: {

        defaultViewModelProviderFactory

    }



    return ViewModelLazy(VM::class, { viewModelStore }, factoryPromise)

}

ViewModelLazy

public class ViewModelLazy<VM : ViewModel> (

    private val viewModelClass: KClass<VM>,

    private val storeProducer: () -> ViewModelStore,

    private val factoryProducer: () -> ViewModelProvider.Factory

) : Lazy<VM> {

    private var cached: VM? = null



    override val value: VM

        get() {

            val viewModel = cached

            //如果第一次调用 by viewModels，则先初始化再返回

            return if (viewModel == null) {

                val factory = factoryProducer()

                val store = storeProducer()

                //最终是通过 ViewModelProvider 来创建

                ViewModelProvider(store, factory).get(viewModelClass.java).also {

                    cached = it

                }

            } else {

                //否则直接返回

                viewModel

            }

        }



    override fun isInitialized(): Boolean = cached != null

}

ViewModelStoreOwner

ViewModel 的宿主是 ViewModelStoreOwner 接口的实现类，例如 ComponentActivity，Fragment 等

public interface ViewModelStoreOwner {

    @NonNull

    ViewModelStore getViewModelStore();

}

该接口的实现的责任就是在配置期间保留拥有的 ViewModelStore，并在销毁的时候

此接口实现的责任是在配置更改期间保留拥有的 ViewModelStore 并在此范围将被销毁的时候调用 ViewModelStore.clear()

ComponentActivity

public class ComponentActivity extends androidx.core.app.ComponentActivity implements

        ContextAware,

        LifecycleOwner,

        ViewModelStoreOwner.... {

          

   static final class NonConfigurationInstances {

        Object custom;

        ViewModelStore viewModelStore;

    }      



    //viewmodel 的存储容器

    private ViewModelStore mViewModelStore;

    //创建 viewmodel 的工厂      

    private ViewModelProvider.Factory mDefaultFactory;

          

       @NonNull

    @Override

    public ViewModelStore getViewModelStore() {

        //.....

        ensureViewModelStore();

        return mViewModelStore;

    }

          

    void ensureViewModelStore() {

        if (mViewModelStore == null) {

            //先从配置文件中获取，看能不能获取到 

            NonConfigurationInstances nc =

                    (NonConfigurationInstances) getLastNonConfigurationInstance();

            if (nc != null) {

                mViewModelStore = nc.viewModelStore;

            }

            //如果没有获取到则重新创建 ViewModelStore

            if (mViewModelStore == null) {

                mViewModelStore = new ViewModelStore();

            }

        }

    }

    //重建时保存 viewModelStore

    // ViweModelStore 会被封装为 NonConfigurationInstances 类，然后保存在 NonConfigurationInstances 类的 Object activity 属性中。

   //前一个 NonConfigurationInstances 是 ComponentActivity 中定义的，后一个是 Activity 类中定义的，不是同一个类，不要搞混了哟!       

    public final Object onRetainNonConfigurationInstance() {

        Object custom = onRetainCustomNonConfigurationInstance();

        ViewModelStore viewModelStore = mViewModelStore;

        if (viewModelStore == null) {

            NonConfigurationInstances nc =

                    (NonConfigurationInstances) getLastNonConfigurationInstance();

            if (nc != null) {

                viewModelStore = nc.viewModelStore;

            }

        }

        if (viewModelStore == null && custom == null) {

            return null;

        }



        NonConfigurationInstances nci = new NonConfigurationInstances();

        nci.custom = custom;

        nci.viewModelStore = viewModelStore;

        return nci;

    }              

}

上面代码中的 NonConfigurationInstances 是一个配置文件的实例，当 activity 重建时，最终会调用到 onRetainNonConfigurationInstance() 方法中对 viewModelStore 进行缓存。所以上面才是先尝试从配置文件中获取，最后再创建新的 ViewModelStore。

Fragment

@NonNull

@Override

public ViewModelStore getViewModelStore() {

	return mFragmentManager.getViewModelStore(this);

}

//fragment 中 ViewModel 的映射

private final HashMap<String, ViewModelStore> mViewModelStores = new HashMap<>();



@NonNull

ViewModelStore getViewModelStore(@NonNull Fragment f) {

    return mNonConfig.getViewModelStore(f);

}



 @NonNull

 ViewModelStore getViewModelStore(@NonNull Fragment f) {

 		ViewModelStore viewModelStore = mViewModelStores.get(f.mWho);

 		if (viewModelStore == null) {

       viewModelStore = new ViewModelStore();

       mViewModelStores.put(f.mWho, viewModelStore);

    }

    return viewModelStore;

 }

关于 ViewModel 的一些问题

1. ViewModel 如何实现不同的作用域

   在使用 ViewModelProvider 时，需要传入一个 ViewModelStoreOwner 接口，这个接口的 getViewModelStore 会返回对应的 ViewModelStore 实例。

   对于 Activity 来说，ViewModelStore 是直接保存在成员变量中的。

   对于 Fragment 来说， ViewModelstore 是间接的存储在 FragmentManagerViewModel 中的 map 中。

   这样就实现了不同的 activity 或者 fragment 分别对应不同的 ViewModelStore 实例，进而区分不同的作用域

2. 为什么 Activity 可以再重建后恢复 viewMdoel

   当 Activity 因为配置而发生重建时，我们可以将页面上的数据分为两类：

   1. 配置数据，例如窗口大小，主题资源等，当配置发生改变后，需要重新读取这些配置，因此这些数据在配置改变后就失去了意义，也就没有存在的价值

   2. 非配置数据，这些数据就是一些用户自己的信息，以及页面上显示的数据，这些数据和配置没有关系，如果丢失掉就会造成比较大的用户体验。

   说以，Activity 再重建时支持恢复非配置的数据，整个过程如下：

   1. 重建时保存数据

      Activity 再重建时会调用 retainNonConfigurationInstances 方法，在里面会获取需要保存的数据，例如 fragment ，activity 等数据，最后打包为 NonConfigurationInstances 类，保存在 ActivityClientRecord 中。

      NonConfigurationInstances retainNonConfigurationInstances() {
      
         //activity 中的非配置数据，例如 viewmodelStore 
      
         //该方法需要子类实现 ，例如 ComponentActivity 
      
         Object activity = onRetainNonConfigurationInstance();
      
          //fragment 中的非配置数据
      
          FragmentManagerNonConfig fragments = mFragments.retainNestedNonConfig();
      
          // .....
      
      		//构建 NonConfigurationInstances
      
          NonConfigurationInstances nci = new NonConfigurationInstances();
      
          nci.activity = activity;
      
          nci.fragments = fragments;
      
          return nci;
      
      }
      

   2. 恢复数据

      Activity 重新启动的最后，会通过 ActivityThread 中的 performLaunchActivity() 来完成整个启动过程，再这个方法中会通过类加载器来创建 Activity 对象，并调用 attach 方法为其关联所需要的一些信息。

      我们需要关注的就是 attach 方法：

      final void attach(NonConfigurationInstances lastNonConfigurationInstances //.. ) {
      
        	//.....
      
          mLastNonConfigurationInstances = lastNonConfigurationInstances;
      
      }
      

      最后，数据被保存在了 Activity . mLastNonConfigurationInstances 成员变量中。

   3. 获取数据

      这个我们之前已经分析过了，我们简单回顾一下

      void ensureViewModelStore() {
      
          if (mViewModelStore == null) {
      
             //获取之前保存的数据
      
              NonConfigurationInstances nc =
      
                      (NonConfigurationInstances) getLastNonConfigurationInstance();
      
              if (nc != null) {
      
                  // Restore the ViewModelStore from NonConfigurationInstances
      
                  mViewModelStore = nc.viewModelStore;
      
              }
      
              if (mViewModelStore == null) {
      
                  mViewModelStore = new ViewModelStore();
      
              }
      
          }
      
      }
      
      
      
      @Nullable
      
      public Object getLastNonConfigurationInstance() {
      
        //mLastNonConfigurationInstances 就是 attach 中保存的
      
        return mLastNonConfigurationInstances != null
      
          ? mLastNonConfigurationInstances.activity : null;
      
      }
      

   至此，就完成了 ViewModel 的数据恢复了。

3. Activity 重建的过程

   再 Activity 重建时，系统会执行 Relaunch 重建过程。在这个过程中通过 ActivityClientRecord 来完成信息传递，并销毁 Activity，紧接着马上重建同一个 Activity。

   这些操作都是在 ActivityThread 中完成的：

   private void handleRelaunchActivityInner(ActivityClientRecord r //...) {
   
       final Intent customIntent = r.activity.mIntent;
   
       //处理 onPause
   
       performPauseActivity(r, false, reason, null /* pendingActions */);
   
       //处理 onStop
   
       callActivityOnStop(r, true /* saveState */, reason);
   
       //1
   
       handleDestroyActivity(r.token, false, configChanges, true, reason);
   
   		//2
   
       handleLaunchActivity(r, pendingActions, customIntent);
   
   }
   
   //1
   
   public void handleDestroyActivity(IBinder token, boolean finishing,//...) {
   
       ActivityClientRecord r = performDestroyActivity(token, finishing,
   
                   configChanges, getNonConfigInstance, reason);
   
   }      
   
   ActivityClientRecord performDestroyActivity(IBinder token, boolean finishing,
   
               int configChanges, boolean getNonConfigInstance, String reason) {
   
           ActivityClientRecord r = mActivities.get(token);
   
           if (r != null) {
   
               if (getNonConfigInstance) {
   
                 //调用 activity 的 retainNonConfigurationInstances 方法
   
                 r.lastNonConfigurationInstances
   
                               = r.activity.retainNonConfigurationInstances();
   
              }
   
           }
   
           return r;
   
   }
   
   //2
   
   public Activity handleLaunchActivity(ActivityClientRecord r,
   
               PendingTransactionActions pendingActions, Intent customIntent) {
   
           final Activity a = performLaunchActivity(r, customIntent);
   
           return a;
   
   }
   
   private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
   
          
   
     activity = mInstrumentation.newActivity(
   
                       cl, component.getClassName(), r.intent);
   
     //...
   
     //传递缓存数据以及其他数据
   
     activity.attach(appContext, this, getInstrumentation(), r.token,
   
                           r.ident, app, r.intent, r.activityInfo, title, r.parent,
   
                           r.embeddedID, r.lastNonConfigurationInstances, config,
   
                           r.referrer, r.voiceInteractor, window, r.configCallback,
   
                           r.assistToken);
   
     //....
   
     return activity;
   
   }
   

   上面的代码主要可以分为两部分：

   第一处：再处理 onDestory 逻辑时，调用 retainNonConfigurationInstances() 方法获取非配置数据，并临时保存在 ActivityClientRecord 上。

   第二处：再 Launch 新 activity 的时候通过 attach 方法将数据传到新 activity 中即可

   至此旧的 Activity 数据已经被传递到新的 Activity 中了。

4. ViewModel 的数据在什么时候才会清除

   ViewModel 的数据会在 Activity 非配置变化销毁时清除，具体分为三种情况

   1. 直接调用 finish 或者按返回键退出
   2. 异常退出 Activity，例如内存不足
   3. 强制退出应用

   前两种都属于非配置变更触发的，再 Activity中存在一个 Lifecycle 的监听，当 Activity 进入 Destory 状态时，如果 Activity 不处于配置重建阶段，将调用 viewModelStore.clear() 清除 viewmodel 数据。

   public ComponentActivity() {
   
       Lifecycle lifecycle = getLifecycle();
   
       getLifecycle().addObserver(new LifecycleEventObserver() {
   
           @Override
   
           public void onStateChanged(@NonNull LifecycleOwner source,
   
                   @NonNull Lifecycle.Event event) {
   
               if (event == Lifecycle.Event.ON_DESTROY) {
   
                   // Clear out the available context
   
                   mContextAwareHelper.clearAvailableContext();
   
                   //是否处于配置变更引起的重建
   
                   if (!isChangingConfigurations()) {
   
                       getViewModelStore().clear();
   
                   }
   
               }
   
           }
   
       });
   
   }
   

5. ViewModel 和 onSaveInstanceState 对比

   这两种都是对数据恢复的机制，但是他们针对的场景不同，导致他们的实现原理也不同，进而优缺点也不同

   viewModel：使用常见针对于配置变更中的非配置数据恢复，由于数据是直接存储在内存中的，所以他的读取速度非常快，并且支持存储大数据，但是会收到内存空间的限制

   onSaveInstanceState：针对于应用被系统回收后重建时的数据恢复，由于应用进程坑会在这个过程中消亡，所以不能存在内存中，只能进行持久化存储，并且这种方式的数据传递是通过 Bundle 传递的，会受到 Binder 事务缓冲区的大小限制，只能存储小规模数据。

   这里借用一张大佬的图，来看一下具体的优缺点：

   

总结

到这里，ViewModel 就整个分析完了，如果有任何问题可直接留言评论，谢谢！

前言

Hello 大家早上好，说起 PermissionX，其实我已经有段时间没有更新这个框架了。一是因为现在工作确实比较忙，没有过去那么多的闲暇时间来写开源项目，二是因为，PermissionX 的主体功能已经相当稳定，并不需要频繁对其进行变更。

不过之前一直有朋友在反映，对于 Android 中的一些特殊权限申请，PermissionX 并不支持。是的，PermissionX 本质上只是对 Android 运行时权限 API 进行了一层封装，用于简化运行时权限申请的。而这些特殊权限并不属于 Android 运行时权限的一部分，所以 PermissionX 自然也是不支持的。

但是特殊权限却是我们这些开发者们可能经常要与之打交道的一部分，它们并不难写，但是每次去写都感觉很繁琐。因此经慎重考虑之后，我决定将几个比较常用的特殊权限纳入 PermissionX 的支持范围。那么本篇文章我们就来看一看，对于这几个常见的特殊权限，使用 PermissionX 和不使用 PermissionX 的写法有什么不同之处。

事实上，Android 的权限机制也是经历过长久的迭代的。在 6.0 系统之前，Google 将权限机制设计的比较简单，你的应用程序需要用到什么权限，只需要在 AndroidManifest.xml 文件中声明一下就可以了。

但是从 6.0 系统开始，Android 引入了运行时权限机制。Android 将常用的权限大致归成了几类，一类是普通权限，一类是危险权限，一类是特殊权限。

普通权限指的是那些不会直接威胁到用户的安全和隐私的权限，这种权限和过去一样，只需要在 AndroidManifest.xml 文件中声明一下就可以了，不需要做任何特殊处理。

危险权限则表示那些可能会触及用户隐私或者对设备安全性造成影响的权限，如获取设备联系人信息、定位设备的地理位置等。这部分权限需要通过代码进行申请，并要用户手动同意才可获得授权。PermissionX 库主要就是处理的这种权限的申请。

而特殊权限则更加少见，Google 认为这种权限比危险权限还要敏感，因此不能仅仅让用户手动同意就可以获得授权，而是需要让用户到专门的设置页面去手动对某一个应用程序授权，该程序才能使用这个权限。

不过相比于危险权限，特殊权限没有非常固定的申请方式，每个特殊权限可能都要使用不同的写法才行，这也导致申请特殊权限比申请危险权限还要繁琐。

从 1.5.0 版本开始，PermissionX 对最常用的几个特殊权限进行了支持。正如刚才所说，特殊权限没有固定的申请方式，因此 PermissionX 也是针对于这几个特殊权限一个一个去适配并支持的。如果你发现你需要申请的某个特殊权限还没有被 PermissionX 支持，也可以向我提出需求，我会考虑在接下来的版本中加入。

在过去，我们发布开源库通常都是发布到 jcenter 上的，但是相信大家现在都已经知道了，jcenter 即将停止服务，具体可以参考我的这篇文章 浅谈 JCenter 即将被停止服务的事件 。

目前的 jcenter 处在一个半废弃的边缘，虽然还可以正常从 jcenter 下载开源库，但是已经不能再向 jcenter 发布新的开源库了。而在明年 2 月 1 号之后，下载服务也会被关停。

所以，以后要想再发布开源库我们只能选择发布到其他仓库，比如现在 Google 推荐我们使用 Maven Central。

于是，从 1.5.0 版本开始，PermissionX 也会将库发布到 Maven Center 上，之前的老版本由于迁移价值并不大，所以我也不想再耗费经历做迁移了。1.5.0 之前的版本仍然保留在 jcenter 上，提供下载服务直到明年的 2 月 1 号。

而关于如何将库发布到 Maven Central，请参考 再见 JCenter，将你的开源库发布到 MavenCentral 上吧 。

Android的特殊权限

Android 里具体有哪些特殊权限呢？

说实话，这个我也不太清楚。我所了解的特殊权限基本都是因为需要用到了，然后发现这个权限即不属于普通权限，也不属于危险权限，要用一种更加特殊的方式去申请，才知道原来这是一个特殊权限。

因此，PermissionX 1.5.0 版本中对特殊权限的支持，也就仅限于我知道的，以及从网友反馈得来的几个最为常用的特殊权限。

一共是以下 3 个：

1. 悬浮窗


2. 修改设置


3. 管理外部存储

接下来我就分别针对这 3 个特殊权限做一下更加详细的介绍。

悬浮窗

悬浮窗功能在不少应用程序中使用得非常频繁，因为你可能总有一些内容是要置顶于其他内容之上显示的，这个时候用悬浮窗来实现就会非常方便。

当然，如果你只是在自己的应用内部实现悬浮窗功能是不需要申请权限的，但如果你的悬浮窗希望也能置顶于其他应用程序的上方，这就必须得要申请权限了。

悬浮窗的权限名叫做 SYSTEM_ALERT_WINDOW，如果你去查一下这个权限的文档，会发现这个权限的申请方式比较特殊：

按照文档上的说法，从 Android 6.0 系统开始，我们在使用 SYSTEM_ALERT_WINDOW 权限前需要发出一个 action 为 Settings.ACTION_MANAGE_OVERLAY_PERMISSION 的 Intent，引导用户手动授权。另外我们还可以通过 Settings.canDrawOverlays() 这个 API 来判断用户是否已经授权。

因此，想要申请悬浮窗权限，自然而然就可以写出以下代码：

if (Build.VERSION.SDK_INT >= 23) {

    if (Settings.canDrawOverlays(context)) {

        showFloatView()

    } else {

        val intent = Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION)

        startActivity(intent)

    }

} else {

    showFloatView()

}

看上去也不复杂嘛。

确实，但是它麻烦的点主要在于，它的请求方式是脱离于一般运行时权限的请求方式的，因此得要为它额外编写独立的权限请求逻辑才行。

而 PermissionX 的目标就是要弱化这种独立的权限请求逻辑，减少差异化代码编写，争取使用同一套 API 来实现对特殊权限的请求。

如果你已经比较熟悉 PermissionX 的用法了，那么以下代码你一定不会陌生：

PermissionX.init(activity)

    .permissions(Manifest.permission.SYSTEM_ALERT_WINDOW)

    .onExplainRequestReason { scope, deniedList ->

        val message = "PermissionX需要您同意以下权限才能正常使用"

        scope.showRequestReasonDialog(deniedList, message, "Allow", "Deny")

    }

    .request { allGranted, grantedList, deniedList ->

        if (allGranted) {

            Toast.makeText(activity, "所有申请的权限都已通过", Toast.LENGTH_SHORT).show()

        } else {

            Toast.makeText(activity, "您拒绝了如下权限：$deniedList", Toast.LENGTH_SHORT).show()

        }

    }

可以看到，这就是最标准的 PermissionX 的正常用法，但是我们在这里却用来请求了悬浮窗权限。也就是说，即使是特殊权限，在 PermissionX 中也可以用普通的方式去处理。

另外不要忘记，所有申请的权限都必须在 AndroidManifest.xml 进行注册才行：

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

    package="com.permissionx.app">

    

    <uses-permission android: />



</manifest>

那么运行效果是什么样的呢？我们来看看吧：

可以看到，PermissionX 还自带了一个权限提示框，友好地告知用户我们需要悬浮窗权限，引导用户去手动开启。

修改设置

了解了悬浮窗权限的请求方式之后，接下来我们就可以快速过一下修改设置权限的请求方式了，因为它们的用法是完全一样的。

修改设置的权限名叫 WRITE_SETTINGS，如果我们去查看一下它的文档，你会发现它和刚才悬浮窗权限的文档简直如出一辙：

同样是从 Android 6.0 系统开始，在使用 WRITE_SETTINGS 权限前需要先发出一个 action 为 Settings.ACTION_MANAGE_WRITE_SETTINGS 的 Intent，引导用户手动授权。然后我们还可以通过 Settings.System.canWrite() 这个 API 来判断用户是否已经授权。

所以，如果是自己手动申请这个权限，相信你已经知道要怎么写了。

那么用 PermissionX 申请的话应该要怎么写呢？这个当然就更简单了，只需要把要申请的权限替换一下即可，其他部分都不用作修改：

PermissionX.init(activity)

    .permissions(Manifest.permission.WRITE_SETTINGS)

    ...

当然，不要忘记在 AndroidManifest.xml 中注册权限：

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

    package="com.permissionx.app">

    

    <uses-permission android: />



</manifest>

运行一下，效果如下图所示：

管理外部存储

管理外部存储权限也是一种特殊权限，它可以允许你的 App 拥有对整个 SD 卡进行读写的权限。

有些朋友可能会问，SD 卡本来不就是可以全局读写的吗？为什么还要再申请这个权限？

那你一定是没有了解 Android 11 上的 Scoped Storage 功能。从 Android 11 开始，Android 系统强制启用了 Scoped Storage，所有 App 都不再拥有对 SD 卡进行全局读写的权限了。

关于 Scoped Storage 的更多内容，可以参考我的这篇文章 Android 11 新特性，Scoped Storage 又有了新花样 。

但是如果有的应用就是要对 SD 卡进行全局读写该怎么办呢（比如说文件浏览器）？

不用担心，Google 仍然还是给了我们一种解决方案，那就是请求管理外部存储权限。

这个权限是 Android 11 中新增的，为的就是应对这种特殊场景。

那么这个权限要怎么申请呢？我们还是先来看一看文档：

大致可以分为几步吧：

第一，在 AndroidManifest.xml 中声明 MANAGE_EXTERNAL_STORAGE 权限。

第二，发出一个 action 为 Settings.ACTION_MANAGE_ALL_FILES_ACCESS_PERMISSION 的 Intent，引导用户手动授权。

第三，调用 Environment.isExternalStorageManager() 来判断用户是否已授权。

传统请求权限的写法我就不再演示了，使用 PermissionX 来请求的写法仍然也还是差不多的。只不过要注意，因为 MANAGE_EXTERNAL_STORAGE 权限是 Android 11 系统新加入的，所以我们也只应该在 Android 11 以上系统去请求这个权限，代码如下所示：

if (Build.VERSION.SDK_INT >= 30) {

    PermissionX.init(this)

        .permissions(Manifest.permission.MANAGE_EXTERNAL_STORAGE)

        ...

}

AndroidManifest.xml 中的权限如下：

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

    package="com.permissionx.app">

    

    <uses-permission android: />



</manifest>

运行一下程序，效果如下图所示：

这样我们就拥有全局读写 SD 卡的权限了。

另外 PermissionX 还有一个特别方便的地方，就是它可以一次性申请多个权限。假如我们想要同时申请悬浮窗权限和修改设置权限，只需要这样写就可以了：

PermissionX.init(activity)

    .permissions(Manifest.permission.SYSTEM_ALERT_WINDOW, Manifest.permission.WRITE_SETTINGS)

    ...

运行效果如下图所示：

当然你也可以将特殊权限与普通运行时权限放在一起申请，PermissionX 对此也是支持的。只有当所有权限都请求结束时，PermissionX 才会将所有权限的请求结果一次性回调给开发者。

关于 PermissionX 新版本的内容变化就介绍到这里，升级的方式非常简单，修改一下 dependencies 当中的版本号即可：

repositories {

  google()

  mavenCentral()

}





dependencies {

    implementation 'com.guolindev.permissionx:permissionx:1.5.0'

}

注意现在一定要使用 mavenCentral 仓库，而不能再使用 jcenter 了。

如果你对 PermissionX 的源码感兴趣，可以访问 PermissionX 的项目主页：

github.com/guolindev/P…

vscode好多插件都已经内置了，但是还是有很多憨批不知道，还在傻傻的推荐这些插件来坑萌新。

1. Auto Rename Tag

这个插件是在写html标签的时候可以重命名标签名的，但是现在vscode已经内置了，就不需要再下载这个插件了。只不过默认是关闭的，需要开启。

点击设置，搜索link，把这个勾选上，就可以左右重命名标签了。

在html和vue中可以自动重命名，而jsx中不行，如果有react开发的，那还是继续装上把。

2. Auto Close Tag

这个插件是用来自动闭合html标签的，但是目前vscode已经内置了这个自动闭合标签的功能了，就不需要再下载了，默认是开启的。

3. Bracket Pair Colorizer

这个标签是用来显示多个彩色括号的，但是目前vscode也内置了，所以也不用再下载了，默认是开启的。

如果没有开启，点击设置，搜索Bracket Pair，并勾选上。

4. Guides

这个插件是用来显示代码层级的，但是vscode也已经内置了，默认是关闭的，在上面的配置中，把是否启用括号对指南改成true即可。

5. CSS Peek

这个插件只是用于查找html的外部css样式，对于vue、react等文件是不起作用的，并且目前处于失效中。

6.HTML Snippets

该插件目前已不再维护。

未提到的，欢迎大家补充。

1.SDK无侵入初始化并获取Application

无侵入初始化SDK并获取Application的意思是不需要业务方手动调用SDK的初始化函数。

这个就得利用Android四大基本组件之一ContentProvider了，其执行的时机是位于Application的attchBaseContext()之后，Application的onCreate()之前，无需程序手动调用。

所以我们就可以自定义个ContentProvider完成SDK的自动初始化并获取应用的Application。

class CPDemo : ContentProvider() {

    override fun attachInfo(context: Context?, info: ProviderInfo?) {

        super.attachInfo(context, info)

        //编写SDK初始化逻辑，并获取Application

        val application = context?.applicationContext

    }



    override fun onCreate(): Boolean = true

}

直接重写ContentProvider并在attachInfo执行SDK的初始化逻辑即可。

比较出名的内存泄漏检测库 LeakCanary、Google官方的ProcessLifecycleOwner就使用这个原理。

不过如果每个第三方库都借用ContentProvider来完成无侵入式的初始化，势必造成自定义的ContentProvider过多，直接增加了启动耗时：

为了避免ContentProvider过多的问题，Google官方提供了App Startup库，这个库主要是给SDK提供方实现无侵入初始化使用的：

    implementation("androidx.startup:startup-runtime:1.1.1")

该官方库会将所有用于初始化的ContentProvider合并成一个，减少启动的耗时

基本使用如下：

class CPDemo2 : Initializer<Unit> {

    override fun create(context: Context) {

        //执行初始化逻辑

    }



    override fun dependencies(): MutableList<Class<out Initializer<*>>> = mutableListOf()

}

然后再AndroidManifest中注册：

<provider

    android:name="androidx.startup.InitializationProvider"

    android:authorities="${applicationId}.androidx-startup"

    android:exported="false"

    tools:node="merge">

    <meta-data

        android:name="com.example.gitlinux.CPDemo2"

        android:value="androidx.startup" />

</provider>

更多用法可以参考郭神的文章：Jetpack新成员，App Startup一篇就懂

2.kotlin函数省略返回值类型真的好吗？

经常使用kotlin的程序都知道，kotlin的函数再某些场景下是可以不用显示声明返回值类型，这是为了提高开发效率，比如：

fun test() = ""

对于简单的函数来说，虽然省略了方法的返回类型，但是我们还是能够直接看出这个方法的返回值类型为String，但是方法中调用了其他方法呢，比如：

fun test() =  request()



//随便一个函数，这个函数体中还会调用其他的函数

fun request() = otherFun()



fun otherFun() = "hahaha"

这种情况下，如果我们要知道test()方法的返回值类型必须先通过request()函数再跳转到otherFun才能知道test()方法的返回值类型，这对于程序而言反而降低了开发效率。

所以我认为使用kotlin函数省略返回值类型的场景应该有一个前提：该函数的返回值类型程序能够很容易推断出来（尽量不依赖其他函数）