遇到的坑

按官方文档设置完之后，debug运行，或者直接点击Run运行，闪屏页的logo不显示，清掉后台，从桌面点击启动logo才显示，不过设置的windowBackgroud 都是显示正常的，这个问题我调了一天，，，AndroidStudio版本4.2.2

内容来自官方文档 文档地址：点我

如果您之前在 Android 11 或更低版本中实现了自定义初始屏幕，则需要将您的应用迁移到 SplashScreenAPI 以确保它在 Android 12 及更高版本中正确显示。

从 Android 12 开始，系统始终在所有应用的 冷启动和 热启动时应用新的Android 系统默认启动画面。默认情况下，此系统默认启动画面是使用您的应用程序的启动器图标元素和 您的主题（如果它是单色）构建的。windowBackground

如果您不迁移您的应用，您在 Android 12 及更高版本上的应用启动体验将会降级或可能出现意外结果：

• 如果您现有的初始屏幕是使用覆盖 的自定义主题android:windowBackground实现的，则系统会将您的自定义初始屏幕替换为 Android 12 及更高版本上的默认 Android 系统初始屏幕（这可能不是您应用的预期体验）。


• 如果您现有的初始屏幕是使用专用的 实现的，则Activity在运行 Android 12 或更高版本的设备上启动您的应用会导致重复的初始屏幕：显示新的系统初始屏幕 ，然后是您现有的初始屏幕活动。

您可以通过完成本指南中描述的迁移过程来防止这些降级或意外体验。迁移后，新 API 会缩短启动时间，让您完全控制初始屏幕体验，并确保与平台上其他应用程序的启动体验更加一致。

SplashScreen 兼容库

您可以SplashScreen直接使用 API，但我们强烈建议使用 AndroidxSplashScreen兼容库 。compat 库使用SplashScreenAPI，支持向后兼容，并为所有 Android 版本的初始屏幕显示创建一致的外观。本指南是使用 compat 库编写的。

如果您选择直接使用 SplashScreen API 进行迁移，在 Android 11 上并降低您的初始屏幕看起来与以前完全相同；从 Android 12 开始，初始屏幕将具有新的 Android 12 外观。

迁移您的启动画面实施

完成以下步骤，将您现有的初始屏幕实施迁移到适用于 Android 12 及更高版本的新体验。

此过程适用于您从中迁移的任何类型的实现。如果您是从专用迁移Activity，您还应该遵循本文档中描述的最佳实践来调整您的自定义启动屏幕Activity。新的SplashScreenAPI 还减少了由专用启动屏幕活动引入的启动延迟。

使用SplashScreencompat 库迁移后，系统会在所有版本的 Android 上显示相同的初始屏幕。

要迁移初始屏幕：

1. 
   

   在build.gradle文件中，更改您的 compileSdkVersion并将 SplashScreencompat 库包含在依赖项中。

   
   

   build.gradle
   
   
   
   android {
   
      compileSdkVersion 31
   
      ...
   
   }
   
   dependencies {
   
      ...
   
      implementation 'androidx.core:core-splashscreen:1.0.0-beta02'
   
   }
   

   
   


2. 
   

   使用 的父项创建一个主题Theme.SplashScreen，并将 的值设置为 应该使用 postSplashScreenTheme的主题以及可绘制或动画可绘制的主题。其他属性是可选的。Activity``windowSplashScreenAnimatedIcon

   
   

   <style name="Theme.App.Starting" parent="Theme.SplashScreen">
   
      <!-- Set the splash screen background, animated icon, and animation duration. -->
   
      <item name="windowSplashScreenBackground">@color/...</item>
   
   
   
      <!-- Use windowSplashScreenAnimatedIcon to add either a drawable or an
   
           animated drawable. One of these is required. -->
   
      <item name="windowSplashScreenAnimatedIcon">@drawable/...</item>
   
      <!-- Required for animated icons -->
   
      <item name="windowSplashScreenAnimationDuration">200</item>
   
   
   
      <!-- Set the theme of the Activity that directly follows your splash screen. -->
   
      <!-- Required -->
   
      <item name="postSplashScreenTheme">@style/Theme.App</item>
   
   </style>
   

   
   

   如果要在图标下方添加背景颜色，可以使用 Theme.SplashScreen.IconBackground主题并设置 windowSplashScreenIconBackground属性。

   
   


3. 
   

   在清单中，将启动活动的主题替换为您在上一步中创建的主题。

   
   

   <manifest>
   
      <application android:theme="@style/Theme.App.Starting">
   
       <!-- or -->
   
           <activity android:theme="@style/Theme.App.Starting">
   
   ...
   

   
   


4. 
   

   installSplashScreen在调用之前调用启动 活动super.onCreate()。

   
   

   class MainActivity : Activity() {
   
   
   
      override fun onCreate(savedInstanceState: Bundle?) {
   
          // Handle the splash screen transition.
   
          val splashScreen = installSplashScreen()
   
   
   
          super.onCreate(savedInstanceState)
   
          setContentView(R.layout.main_activity)
   
   ...
   

   
   

installSplashScreen返回初始屏幕对象，您可以选择使用它来自定义动画或将初始屏幕保持在屏幕上更长的时间。有关自定义动画的更多详细信息，请参阅 让初始屏幕在屏幕上停留更长时间 和自定义动画以关闭初始屏幕。

使您的自定义启动屏幕活动适应新的启动屏幕体验

在您迁移到适用于 Android 12 及更高版本的新初始屏幕体验后，您的自定义初始屏幕Activity仍然存在，因此您需要选择如何处理它。您有以下选择：

• 保留自定义活动，但阻止其显示


• 出于品牌原因保留自定义活动


• 删除自定义活动，并根据需要调整您的应用程序

阻止自定义 Activity 显示

如果您现有的初始屏幕Activity主要用于路由，请考虑删除它的方法；例如，您可以直接链接到实际活动或移动到带有子组件的单个活动。如果这不可行，您可以使用SplashScreen#setKeepOnScreenCondition 将路由活动保持在原位，但停止渲染。这样做会将初始屏幕转移到下一个活动，并允许平滑过渡。

  class RoutingActivity : Activity() {



    override fun onCreate(savedInstanceState: Bundle?) {

        val splashScreen = installSplashScreen()

        super.onCreate(savedInstanceState)



        // Keep the splash screen visible for this Activity

        splashScreen.setKeepOnScreenCondition { true }

        startSomeNextActivity()

        finish()

     }

   ...

 

保留品牌化的自定义活动

如果您想使用后续启动画面Activity来获得品牌体验，您可以Activity通过自定义关闭启动画面的动画，从系统启动画面过渡到您的自定义启动画面。但是，如果可能的话，最好避免这种情况，并使用新的 SplashScreenAPI 来标记您的启动画面。

移除自定义闪屏Activity

一般来说，我们建议您Activity 完全删除您自定义的启动画面，以避免重复启动画面无法迁移，提高效率并减少启动画面加载时间。您可以使用不同的技术来避免显示多余的闪屏活动。

• 
  

  延迟加载组件、模块或库：避免加载或初始化应用程序启动时不需要的组件或库，并在应用程序需要时加载它们。

  
  

  如果您的应用确实需要某个组件才能正常工作，请仅在真正需要时而不是在启动时加载它，或者在应用启动后使用后台线程加载它。尽量保持你Application onCreate()的轻盈。

  
  

  您还可以受益于使用App Startup 库在应用程序启动时初始化组件。这样做时，请确保仍然加载启动活动所需的所有模块，并且不要在延迟加载的模块变得可用时引入卡顿。

  
  


• 
  

  在本地加载少量数据时创建占位符：使用推荐的主题化方法并保留渲染，直到应用程序准备好。要实现向后兼容的初始屏幕，请按照使初始屏幕在屏幕上停留更长时间中概述的步骤。

  
  


• 
  

  显示占位符：对于持续时间不确定的基于网络的加载，关闭初始屏幕并显示占位符以进行异步加载。考虑将微妙的动画应用于反映加载状态的内容区域。确保加载的内容结构 尽可能匹配骨架结构，以便在加载内容后实现平滑过渡。

  
  


• 
  

  使用缓存：当用户第一次打开您的应用程序时，您可以显示某些 UI 元素的加载指示符（如下例所示）。下次用户返回您的应用时，您可以在加载更新的内容时显示此缓存内容。

前言

倒计时的实现有很多方式，我觉得分享这个技术的关键在于有些官方的，甚至第三方的，也许能帮我实现99%的效果，但是当你从99%优化到100%，哪怕这1%微不足道，但你能从这个过程中得到的东西远远比你想象中的要多。

已有倒计时方案存在的问题

在开发倒计时功能时往往我们会为了方便直接使用CountDownTimer或者使用Handler做延时来实现，当然CountDownTimer内部封装也是使用的Handler。

如果只是做次数很少的倒计时或者不需要精确的倒计时逻辑那倒没关系，比如说我只要倒计时10秒，或者我大概5分钟请求某个接口

但是如果是需要做精确的倒计时操作，比如说手机发送验证码60秒，那使用现有的倒计时方案就会存在问题。可能有些朋友没有注意到这一点，下面我们就来简单分析一下现有倒计时的问题。

1. CountDownTimer

这个可能是用得最多的，因为方便嘛。但其实倒计时每一轮倒计时完之后都是存在误差的，如果看过CountDownTimer的源码你就会知道，他的内部是有做校准操作的。（源码很简单这里就不分析了）

但是如果你认真的测试过CountDownTimer，你就会发现，即便它内部有做校准操作，他的每一轮都是有偏差，只是他最后一次倒计时完之后的总共时间和开始倒计时的时间相比没偏差。

什么意思呢，意思就是1秒，2.050秒，3.1秒......，这样的每轮偏差，导致他会出现10.95秒，下一次12秒的情况，那它的回调中如果你直接做取整就会出现少一秒的情况，但实际是没少的。

这只是其中的一个问题，你可以不根据它的回调做展示，自己用一个整形累加做展示也能解决。但是他还有个问题，有概率直接出现跳秒，就是比如3秒，下次直接5秒，这是实际的跳秒，是少了一次回调的那种。

跳秒导致你如果直接使用它可能会大问题，你可能自测的时候没发现，到时一上线应用在用户那概率跳秒，那就蛋疼了。

2. Handler

不搞这么多花里胡哨的，直接使用Handler来实现，会有什么问题。

因为直接使用handler来实现，没有校准操作，每次循环会出现几毫秒的误差，虽然比CountDownTimer的十几毫秒的误差要好，但是在基数大的倒计时情况下误差会累计，导致最终结果和现实时间差几秒误差，时间越久，误差越大

3. Timer

直接使用Timer也一样，只不过他每轮的误差更小，几轮才有1毫秒的误差，但是没有校准还是会出现误差累计，时间越久误差越大。

自己封装倒计时

既然无法直接使用原生的，那我们就自己做一个。

我们基于Handler进行封装，从上面可以看出主要为了解决两个问题，时间校准和跳秒。自己写一个CountDownTimer

public class CountDownTimer {



    private int mTimes;

    private int allTimes;

    private final long mCountDownInterval;

    private final Handler mHandler;

    private OnTimerCallBack mCallBack;

    private boolean isStart;

    private long startTime;



    public CountDownTimer(int times, long countDownInterval){

        this.mTimes = times;

        this.mCountDownInterval = countDownInterval;

        mHandler = new Handler();

    }



    public synchronized void start(OnTimerCallBack callBack){

        this.mCallBack = callBack;

        if (isStart || mCountDownInterval <= 0){

            return;

        }



        isStart = true;

        if (callBack != null){

            callBack.onStart();

        }

        startTime = SystemClock.elapsedRealtime();



        if (mTimes <= 0){

            finishCountDown();

            return;

        }

        allTimes = mTimes;



        mHandler.postDelayed(runnable, mCountDownInterval);

    }



    private final Runnable runnable = new Runnable() {

        @Override

        public void run() {

            mTimes--;

            if (mTimes > 0){

                if (mCallBack != null){

                    mCallBack.onTick(mTimes);

                }



                long nowTime = SystemClock.elapsedRealtime();

                long delay = (nowTime - startTime) - (allTimes - mTimes) * mCountDownInterval;

                // 处理跳秒

                while (delay > mCountDownInterval){

                    mTimes --;

                    if (mCallBack != null){

                        mCallBack.onTick(mTimes);

                    }



                    delay -= mCountDownInterval;

                    if (mTimes <= 0){

                        finishCountDown();

                        return;

                    }

                }



                mHandler.postDelayed(this, 1000 - delay);

            }else {

                finishCountDown();

            }

        }

    };



    private void finishCountDown(){

        if (mCallBack != null){

            mCallBack.onFinish();

        }

        isStart = false;

    }



    public void cancel(){

        mHandler.removeCallbacksAndMessages(null);

        isStart = false;

    }



    public interface OnTimerCallBack{



        void onStart();



        void onTick(int times);



        void onFinish();



    }



}

思路就是在倒计时开始前获取一次SystemClock.elapsedRealtime()，每轮倒计时再获取一次SystemClock.elapsedRealtime()相减得到误差，根据delay校准。然后使用while循环来处理跳秒的操作，与原生的CountDownTimer不同，这里如果跳了多少秒，就会返回多少次回调。

ThreadLocal作用

对于Android程序员来说，很多人都是在学习消息机制时候了解到ThreadLocal这个东西的。那它有什么作用呢？官方文档大致是这么描述的：

• ThreadLocal提供了线程局部变量


• 每个线程都拥有自己的变量副本，可以通过ThreadLocal的set或者get方法去设置或者获取当前线程的变量，变量的初始化也是线程独立的（需要实现initialValue方法）


• 一般而言ThreadLocal实例在类中被private static修饰


• 当线程活着并且ThreadLocal实例能够访问到时，每个线程都会持有一个到它的变量的引用


• 当一个线程死亡后，所有ThreadLocal实例给它提供的变量都会被gc回收（除非有其它的引用指向这些变量）
  上述中“变量”是指ThreadLocal的get方法获取的值

简单例子

先来看一个简单的使用例子吧：

public class ThreadId {



    private static final AtomicInteger nextId = new AtomicInteger(0);



    private static final ThreadLocal<Integer> threadId = new ThreadLocal<Integer>() {

        @Override

        protected Integer initialValue() {

            return nextId.get();

        }

    };



    public static int get() {

        return threadId.get();

    }

}

这也是官方文档上的例子，非常简单,就是通过在不同线程调用ThredId.get()可以获取唯一的线程Id。如果在调用ThreadLocal的get方法之前没有主动调用过set方法设置值的话，就会返回initialValue方法的返回值，并把这个值存储为当前线程的变量。

ThreadLocal到底是用来解决什么问题，适用什么场景呢，例子是看懂了，但好像还是没什么体会？ThreadLocal既然是提供变量的，我们不妨把我们见过的变量类型拿出来，做个对比

局部变量、成员变量 、 ThreadLocal、静态变量

ThreadLocal存储的变量本质上间接算是Thread的成员变量，ThreadLocal只是提供了一种对开发者透明的可以为每个线程存储同一维度成员变量的方式。

共享 or 隔离

网上有很多人持有如下的看法：
ThreadLocal为解决多线程程序的并发问题提供了一种新思路或者ThreadLocal是为了解决多线程访问资源时的共享问题。
个人认为这些都是错误的，ThreadLocal保存的变量是线程隔离的，与资源共享没有任何关系，也没有解决什么并发问题，这一点看了ThreadLocal的原理就会更加清楚。就好比上面的例子，每个线程应该有一个线程Id，这并不是什么并发问题啊。

同时他们会拿ThreadLocal与sychronized做对比，我们要清楚它们根本不是为了解决同一类问题设计的。sychronized是在牵涉到共享变量时候，要做到线程间的同步，保证并发中的原子性与内存可见性，典型的特征是多个线程会访问相同的变量。而ThreadLocal根本不是解决线程同步问题的，它的场景是A线程保存的变量只有A线程需要访问，而其它的线程并不需要访问，其他线程也只访问自己保存的变量。

原理

我们来一个开放性的问题，假如现在要给每个线程增加一个线程Id，并且Java的Thread类你能随便修改，你要怎么操作?非常简单吧,代码大概是这样

public class Thread{

      private int id;

      

      public void setId(int id){

          this.id=id;

      }

}

那好，现在题目变了，我们现在还得为每个线程保存一个Looper对象，那怎么办呢？再加一个Looper的字段不就好了，显然这种做法肯定是不具有扩展性的。那我们用一个容器类不就好了，很自然地就会想到Map，像下面这样

public class Thread{



      private Map<String,Object> map;

    

     public Map<String,Object> getMap(){

         if(map==null)

            map=new HashMap<>();

         return map;

     }

   

}

然后我们在代码里就可以通过如下代码来给Thread设置“成员变量”了

   Thread.currentThread().getMap().put("id",id);

   Thread.currentThread().getMap().put("looper",looper);

然后可以在该线程执行的任意地方，这样访问：

  Looper looper=(Looper) Thread.currentThread().getMap().get("looper");

看上去还不错，但是还是有些问题：

• 保存和获取变量都要用到字符换key


• 因为map中要保存各种值，因此泛型只得用Object，这样获取时候就需要强制转换（可用泛型方法解）


• 当该变量没有作用时候，此时线程还没有执行完，需要手动设置该变量为空，否则会造成内存泄漏

为了不通过字符串访问，同时省去强制转换，我们封装一个类，就叫ThreadLocal吧，伪代码如下：

  public class ThreadLocal<T> {



    public void set(T value) {

        Thread t = Thread.currentThread();

         Map map = t.getMap();

        if (map != null)

           //以自己为键

            map.put(this, value);

        else

            createMap(t, value);

    }





    public T get() {

        Thread t = Thread.currentThread();

        Map<ThreadLocal<?>,T> map = t.getMap();

        if (map != null) {

            T e = map.get(this);

            return e;

        }

        return setInitialValue();

    }

}

没错，以上基本上就是ThreadLocal的整体设计了，只是线程中存储数据的Map是特意实现的ThreadLocal.ThreadLocalMap。

ThreadLocal与线程的关系如下：

如上图如所示，ThredLocal本身并不存储变量，只是向每个线程的threadLocals中存储键值对。ThreadLocal横跨线程，提供一种类似切面的概念，这种切面是作用在线程上的。

我们对ThreadLocal已经有一个整体的认识了，接下来我们大致看一下源码

源码分析

TheadLocal

   public void set(T value) {

        Thread t = Thread.currentThread();

        ThreadLocalMap map = getMap(t);

        if (map != null)

            map.set(this, value);

        else

            createMap(t, value);

    }

set方法通过Thread.currentThread方法获取当前线程，然后调用getMap方法获取线程的threadLocals字段，并往ThreadLocalMap中放入键值对，其中键为ThreadLocal实例自己。

 ThreadLocalMap getMap(Thread t) {

        return t.threadLocals;

   }

接着看get方法：

public T get() {

        Thread t = Thread.currentThread();

        ThreadLocalMap map = getMap(t);

        if (map != null) {

            ThreadLocalMap.Entry e = map.getEntry(this);

            if (e != null) {

                @SuppressWarnings("unchecked")

                T result = (T)e.value;

                return result;

            }

        }

        return setInitialValue();

    }

很清晰，其中值得注意的是最后一行的setInitialValue方法,这个方法在我们没有调用过set方法时候调用。

private T setInitialValue() {

        T value = initialValue();

        Thread t = Thread.currentThread();

        ThreadLocalMap map = getMap(t);

        if (map != null)

            map.set(this, value);

        else

            createMap(t, value);

        return value;

    }

setInitialValue方法会获取initialValue的返回值并把它放进当前线程的threadLocals中。默认情况下initialValue返回null，我们可以实现这个方法来对变量进行初始化，就像上面TheadId的例子一样。

remove方法，从当前线程的ThreadLocalMap中移除元素。

public void remove() {

         ThreadLocalMap m = getMap(Thread.currentThread());

         if (m != null)

             m.remove(this);

     }

TheadLocalMap

看ThreadLocalMap的代码我们主要是关注以下两个方面：

1. 散列表的一般设计问题。包括散列函数，散列冲突问题解决，负载因子，再散列等。


2. 内存泄漏的相关处理。一般而言ThreadLocal 引用使用private static修饰，但是假设某种情况下我们真的不再需要使用它了，手动把引用置空。上面我们知道TreadLocal本身作为键存储在TheadLocalMap中，而ThreadLocalMap又被Thread引用，那线程没结束的情况下ThreadLocal能被回收吗？

散列函数
先来理一下散列函数吧，我们在之后的代码中会看到ThreadLocalMap通过 int i = key.threadLocalHashCode & (len-1);决定元素的位置，其中表大小len为2的幂，因此这里的&操作相当于取模。另外我们关注的是threadLocalHashCode的取值。

  private final int threadLocalHashCode = nextHashCode();

 private static int nextHashCode() {

        return nextHashCode.getAndAdd(HASH_INCREMENT);

    }

  private static AtomicInteger nextHashCode =

        new AtomicInteger();

   private static final int HASH_INCREMENT = 0x61c88647;

这里很有意思，每个ThreadLocal实例的threadLocalHashCode是在之前ThreadLocal实例的threadLocalHashCode上加 0x61c88647，为什么偏偏要加这么个数呢？
这个魔数的选取与斐波那契散列有关以及黄金分割法有关，具体不是很清楚。它的作用是这样产生的值与2的幂取模后能在散列表中均匀分布，即便扩容也是如此。看下面一段代码：

  public class MagicHashCode {

      //ThreadLocal中定义的魔数

     private static final int HASH_INCREMENT = 0x61c88647;

     

     public static void main(String[] args) {

         hashCode(16);//初始化16

         hashCode(32);//2倍扩容

         hashCode(64);

     }

 

    private static void hashCode(int length){         

        int hashCode = 0; 

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

            hashCode = i*HASH_INCREMENT+HASH_INCREMENT;

             System.out.print(hashCode & (length-1));//求取模后的下标

             System.out.print(" ");

         }

         System.out.println();

     }

 }

输出结果为：

7 14 5 12 3 10 1 8 15 6 13 4 11 2 9 0   //容量为16时

7 14 21 28 3 10 17 24 31 6 13 20 27 2 9 16 23 30 5 12 19 26 1 8 15 22 29 4 11 18 25 0  //容量为32时

7 14 21 28 35 42 49 56 63 6 13 20 27 34 41 48 55 62 5 12 19 26 33 40 47 54 61 4 11 18 25 32 39 46 53 60 3 10 17 24 31 38 45 52 59 2 9 16 23 30 37 44 51 58 1 8 15 22 29 36 43 50 57 0  //容量为64时

因为ThreadLocalMap使用线性探测法解决冲突（下文会看到），均匀分布的好处在于发生了冲突也能很快找到空的slot，提高效率。

瞄一眼成员变量：

       /**

         * 初始容量，必须是2的幂。这样的话，方便把取模运算转化为与运算， 

         * 效率高

         */

        private static final int INITIAL_CAPACITY = 16;



        /**

         * 容纳Entry元素，长度必须是2的幂

         */

        private Entry[] table;



        /**

         * table中的元素个数.

         */

        private int size = 0;



        /**

         * table里的元素达到这个值就需要扩容了

         * 其实是有个装载因子的概念的

         */

        private int threshold; // Default to 0

构造函数：

  ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {

        table = new Entry[INITIAL_CAPACITY];

        int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);

        table[i] = new Entry(firstKey, firstValue);

        size = 1;

        setThreshold(INITIAL_CAPACITY);

  }

firstKey和firstValue就是Map存放的第一个键值对喽。其中firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1)很关键，就是当容量为2的幂时候，这相当于一个取模操作。然后把Entry存储到数组的第i个位置，设置扩容的阈值。

private void setThreshold(int len) {

          threshold = len * 2 / 3;

 }

这说明当数组里的元素容量达到2/3时候就要扩容，也就是装载因子是2/3。
接下来我们来看下Entry

 static class Entry extends WeakReference<ThreadLocal<?>> {

            Object value;

            Entry(ThreadLocal<?> k, Object v) {

                super(k);

                value = v;

            }

        }

就这么点东西，这个Entry只是与HashMap不同，只是个普通的键值对，没有链表结构相关的东西。另外Entry只持有对键，也就是ThreadLocal的弱引用，那么我们上面的第二个问题算是有答案了。当没有其他强引用指向ThreadLocal的时候，它其实是会被回收的。但是这有引出了另外一个问题，那Entry呢？当键都为空的时候这个Entry也是没有什么作用啊，也应该被回收啊。不慌，我们接着往下看。

set方法：

 private void set(ThreadLocal<?> key, Object value) {

            Entry[] tab = table;

            int len = tab.length;

            int i = key.threadLocalHashCode & (len-1);

           //如果冲突的话，进入该循环，向后探测

            for (Entry e = tab[i];

                 e != null;

                 e = tab[i = nextIndex(i, len)]) {

                ThreadLocal<?> k = e.get();

               //判断键是否相等，相等的话只要更新值就好了

                if (k == key) {

                    e.value = value;

                    return;

                }

         

                if (k == null) {

                   //该Entry对应的ThreadLocal已经被回收，执行replaceStaleEntry并返回

                    replaceStaleEntry(key, value, i);

                    return;

                }

            }

            tab[i] = new Entry(key, value);

            int sz = ++size;

            //进行启发式清理，如果没有清理任何元素并且表的大小超过了阈值，需要扩容并重哈希

            if (!cleanSomeSlots(i, sz) && sz >= threshold)

                rehash();

        }

我们发现如果发生冲突的话，整体逻辑会一直调用nextIndex方法去探测下一个位置，直到找到没有元素的位置，逻辑上整个表是一个环形。下面是nextIndex的代码，就是加1而已。

private static int nextIndex(int i, int len) {

            return ((i + 1 < len) ? i + 1 : 0);

}

线性探测的过程中，有一种情况是需要清理对应Entry的，也就是Entry的key为null，我们上面讨论过这种情况下的Entry是无意义的。因此调用
replaceStaleEntry(key, value, i);在看replaceStaleEntry(key, value, i)我们先明确几个问题。采用线性探测发解决冲突，在插入过程中产生冲突的元素之前一定是没有空的slot的。这样在也确保在查找过程，查找到空的slot就可以停止啦。但是假如我们删除了一个元素，就会破坏这种情况，这时需要对表中删除的元素后面的元素进行再散列，以便填上空隙。

空slot：即该位置没有元素
无效slot：该位置有元素，但key为null

replaceStaleEntry除了将value放入合适的位置之外，还会在前后连个空的slot之间做一次清理expungeStaleEntry，清理掉无效slot。

private void replaceStaleEntry(ThreadLocal<?> key, Object value,

                               int staleSlot) {

    Entry[] tab = table;

    int len = tab.length;

    Entry e;



    // 向前扫描到一个空的slot为止，找到离这个空slot最近的无效slot，记录为slotToExpunge

    int slotToExpunge = staleSlot;

    for (int i = prevIndex(staleSlot, len);

         (e = tab[i]) != null;

         i = prevIndex(i, len)) {

        if (e.get() == null) {

            slotToExpunge = i;

        }

    }



    // 向后遍历table

    for (int i = nextIndex(staleSlot, len);

         (e = tab[i]) != null;

         i = nextIndex(i, len)) {

        ThreadLocal<?> k = e.get();



        // 找到了key，将其与无效slot交换

        if (k == key) {

            // 更新对应slot的value值

            e.value = value;

            tab[i] = tab[staleSlot];

            tab[staleSlot] = e;

            //如果之前还没有探测到过其他无效的slot

            if (slotToExpunge == staleSlot) {

                slotToExpunge = i;

            }

            // 从slotToExpunge开始做一次连续段的清理，再做一次启发式清理

            cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);

            return;

        }



        // 如果当前的slot已经无效，并且向前扫描过程中没有无效slot，则更新slotToExpunge为当前位置

        if (k == null && slotToExpunge == staleSlot) {

            slotToExpunge = i;

        }

    }



    // 如果key之前在table中不存在，则放在staleSlot位置

    tab[staleSlot].value = null;

    tab[staleSlot] = new Entry(key, value);



    // 在探测过程中如果发现任何其他无效slot，连续段清理后做启发式清理

    if (slotToExpunge != staleSlot) {

        cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);

    }

}

expungeStaleEntry主要是清除连续段之前无效的slot，然后对元素进行再散列。返回下一个空的slot位置。

 private int expungeStaleEntry(int staleSlot) {

            Entry[] tab = table;

            int len = tab.length;



            // 删除 staleSlot

            tab[staleSlot].value = null;

            tab[staleSlot] = null;

            size--;



            Entry e;

            int i;

            for (i = nextIndex(staleSlot, len);

                 (e = tab[i]) != null;

                 i = nextIndex(i, len)) {

                ThreadLocal<?> k = e.get();

                if (k == null) {

                    e.value = null;

                    tab[i] = null;

                    size--;

                } else {

                   //对元素进行再散列

                    int h = k.threadLocalHashCode & (len - 1);

                    if (h != i) {

                        tab[i] = null;

                        while (tab[h] != null)

                            h = nextIndex(h, len);

                        tab[h] = e;

                    }

                }

            }

            return i;

        }

启发式地清理：
i对应是非无效slot(slot为空或者有效）
n是用于控制控制扫描次数
正常情况下如果log n次扫描没有发现无效slot，函数就结束了。
但是如果发现了无效的slot，将n置为table的长度len，做一次连续段的清理，再从下一个空的slot开始继续扫描。
这个函数有两处地方会被调用，一处是插入的时候可能会被调用，另外个是在替换无效slot的时候可能会被调用， 区别是前者传入的n为实际元素个数，后者为table的总容量。

private boolean cleanSomeSlots(int i, int n) {

    boolean removed = false;

    Entry[] tab = table;

    int len = tab.length;

    do {

        // i在任何情况下自己都不会是一个无效slot，所以从下一个开始判断

        i = nextIndex(i, len);

        Entry e = tab[i];

        if (e != null && e.get() == null) {

            // 扩大扫描控制因子

            n = len;

            removed = true;

            // 清理一个连续段

            i = expungeStaleEntry(i);

        }

    } while ((n >>>= 1) != 0);

    return removed;

}

接着看set函数，如果循环过程中没有返回，找到合适的位置，插入元素，表的size增加1。这个时候会做一次启发式清理,如果启发式清理没有清理掉任何无效元素，判断清理前表的大小大于阈值threshold的话，正常就要进行扩容了，但是表中可能存在无效元素，先把它们清除掉，然后再判断。

private void rehash() {

    // 全量清理

    expungeStaleEntries();

    //因为做了一次清理，所以size可能会变小，这里的实现是调低阈值来判断是否需要扩容。 threshold默认为len*2/3，所以这里的threshold - threshold / 4相当于len/2。

    if (size >= threshold - threshold / 4) {

        resize();

    }

}

作用即清除所有无效slot

private void expungeStaleEntries() {

    Entry[] tab = table;

    int len = tab.length;

    for (int j = 0; j < len; j++) {

        Entry e = tab[j];

        if (e != null && e.get() == null) {

            expungeStaleEntry(j);

        }

    }

}

保证table的容量len为2的幂，扩容时候要扩大2倍

private void resize() {

    Entry[] oldTab = table;

    int oldLen = oldTab.length;

    int newLen = oldLen * 2;

    Entry[] newTab = new Entry[newLen];

    int count = 0;

    for (int j = 0; j < oldLen; ++j) {

        Entry e = oldTab[j];

        if (e != null) {

            ThreadLocal<?> k = e.get();

            if (k == null) {

                e.value = null; 

            } else {

                // 扩容后要重新放置元素

                int h = k.threadLocalHashCode & (newLen - 1);

                while (newTab[h] != null) {

                    h = nextIndex(h, newLen);

                }

                newTab[h] = e;

                count++;

            }

        }

    }



    setThreshold(newLen);

    size = count;

    table = newTab;

}

get方法：

private Entry getEntry(ThreadLocal<?> key) {

    int i = key.threadLocalHashCode & (table.length - 1);

    Entry e = table[i];

    // 对应的entry存在且key未被回收

    if (e != null && e.get() == key) {

        return e;

    } else {

        // 继续往后查找

        return getEntryAfterMiss(key, i, e);

    }

}



private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {

    Entry[] tab = table;

    int len = tab.length;

    // 不断向后探测直到遇到空entry

    while (e != null) {

        ThreadLocal<?> k = e.get();

        // 找到

        if (k == key) {

            return e;

        }

        if (k == null) {

            // 该entry对应的ThreadLocal实例已经被回收，调用expungeStaleEntry来清理无效的entry

            expungeStaleEntry(i);

        } else {

            // 下一个位置

            i = nextIndex(i, len);

        }

        e = tab[i];

    }

    return null;

}

remove方法，比较简单，在table中找key，如果找到了断开弱引用，做一次连续段清理。

private void remove(ThreadLocal<?> key) {

    Entry[] tab = table;

    int len = tab.length;

    int i = key.threadLocalHashCode & (len - 1);

    for (Entry e = tab[i];

         e != null;

         e = tab[i = nextIndex(i, len)]) {

        if (e.get() == key) {

            //断开弱引用

            e.clear();

            // 连续段清理

            expungeStaleEntry(i);

            return;

        }

    }

}

ThreadLocal与内存泄漏

从上文我们知道当调用ThreadLocalMap的set或者getEntry方法时候，有很大概率会去自动清除掉key为null的Entry，这样就可以断开value的强引用，使对象被回收。但是如果如果我们之后再也没有在该线程操作过任何ThreadLocal实例的set或者get方法，那么就只能等线程死亡才能回收无效value。因此当我们不需要用ThreadLocal的变量时候，显示调用ThreadLocal的remove方法是一种好的习惯。

小结

• ThredLocal为每个线程保存一个自己的变量，但其实ThreadLocal本身并不存储变量，变量存储在线程自己的实例变量ThreadLocal.ThreadLocalMap threadLocals中


• ThreadLocal的设计并不是为了解决并发问题，而是解决一个变量在线程内部的共享问题，在线程内部处处可以访问


• 因为每个线程都只会访问自己ThreadLocalMap 保存的变量，所以不存在线程安全问题

首先

想必大家都知道OOM是啥吧，我就不扯花里胡哨的了，直接进入正题。先说一个背景故事，我司app扫码框架用的zxing，在很长一段时间以前，做过一系列的扫码优化，稍微列一下跟今天主题相关的改动：

1. 串行处理改成并发处理，zxing的原生处理流程是通过CameraManager获取到一帧的数据之后，通过DecodeHandler去处理，处理完成之后再去获取下一帧，我们给改成了线程池去调度：

• 单帧decode任务入队列之后立即获取下一帧数据
• 二维码识别成功则停止其他解析任务

3. 为了有更大的识别区域，选择对整张拍摄图片进行解码，保证中心框框没对准二维码也能识别到

现象

当时测试反馈，手上一个很古老的 Android 5.0 的机器，打开扫一扫必崩，一看错误栈，是个OOM。

机器找不到了，我就不贴现象的堆栈了（埋在时光里了，懒得挖了）。

排查OOM三板斧

板斧一、 通过一定手段，抓取崩溃时的或者崩溃前的内存快照

咦，一年前的hprof文件还在？确实被我找到了。。。

从图中我们能获得哪些信息？

1. 用户OOM时，byte数组的 java 堆占用是爆炸的

2. 用户OOM时，byte数组里，有大量的 3M 的byte数组

3. 3M的byte 数组是被 zxing 的 DecodeHandler$2 引用的

板斧二、从内存对照出发，大胆猜测找到坏死根源

我们既然知道了 大对象 是被 DecodeHandler$2 引用的，那么 DecodeHandler$2 是个啥呀？

mDecodeExecutor.execute(new Runnable() {

            @Override

            public void run() {

                for (Reader reader : mReaders) {

                    decodeInternal(data, width, height, reader, fullScreenFrame);

                }

            }

        });

所以稍微转动一下脑瓜子就能知道，必然是堆积了太多的 Runnable，每个Runnable 持有了一个 data 大对象才导致了这个OOM问题。

但是为啥会堆积太多 Runnable 呢？结合一下只有 Android 5.0 机器会OOM，我们大胆猜测一下，就是因为这个机器消费（或者说解码）单张 Bitmap 太慢，同时像上面所说的，我们单帧decode任务入队列之后立即获取下一帧数据并入队下一帧decode 任务，这就导致大对象堆积在了LinkedBlockingDeque中。

OK，到这里原因也清楚了，改掉就完事了。

板斧三、 吃个口香糖舒缓一下心情

呵呵...

解决方案

解决方案其实很简单，从问题出发即可，问题是啥？我生产面包速度是一天10个，一个一斤，但是一天只能吃三斤，那岂不就一天就会多7斤囤货，假如囤货到了100斤地球会毁灭，怎么解决呢？

1. 吃快点，一天吃10斤
2. 少生产点，要么生产个数减少，要么生产单个重量减少，要么二者一起
3. 生产前检查一下吃完没，吃完再生产都来得及，实在不行定个阈值觉得不够吃了再生产嘛。

那么自然而然的就大概知道有哪几种解决办法了：

1. 生产的小点 - 隔几帧插一张全屏帧即可（如果要保留不在框框内也能解码的特性的话）
2. 生产前检查一下吃完没 - 线程池的线程空闲时，才去 enqueue decode 任务
3. 生产单个重量减少 - 限制队列大小
4. blalala

总结

装模作样的总结一下。

这个例子是一年前遇到的，今天想水篇文章又突然想到了这个事就拿来写写，我总结为：线程池调度 + 进阻塞队列单任务数据过大 + 处理任务过慢

线程池调度任务是啥场景？

• 有个 Queue，来了任务，先入队
• 有个 ThreadPool ，空闲了，从 Queue 取任务。

那么，当入队的数据结构占内存太大，且 ThreadPool 处理速度小于 入队速度呢？就会造成 Queue 中数据越来越多，直到 OOM。

扫一扫完美的满足了上面条件

• 入队频率足够高

• 入队对象足够大

• 处理速度足够慢。

在这个例子中，做的不足的地方：

1. 追求并发未考虑机器性能

2. 大对象处理不够谨慎

当然，总结是为了避免未来同样的惨案发生，大家可以想想还会有什么类似的场景吧，转动一下聪明的小脑袋瓜~

未来展望

装模作样展望一下，未来展望就是，以后有空多水水贴子吧（不是多水水贴吧）。

相信这几年负责过上架应用市场的 App 开发，或多或少都躺过上线审核的坑，经历过的各种问题也是千奇百怪，今天就给大家做个汇总，希望可以帮助大家少走弯路，争取做一个“优雅”的客户端开发。

首先，近年来为了 “净化” App 环境、保护用户隐私和优化用户体验，各部委大致出台过如下所示的相关法规：

可能还有一些我不知道的遗漏，那不知道这些法规你是否都听说过，这里举一些常见例子：

• 《互联网用户账号信息管理规定》 的第十二条就是在 App 展示用户 IP 的要求相关条款。


• 《常见类型移动互联网应用程序必要个人信息范围规定》就规定了 App 类目所能获取的权限范围和个人信息索取范围，例如新闻资讯类、浏览器类、安全管理类、应用商店类等无须个人信息，即可使用基本功能服务。

针对上面这个无需权限和个人信息也要提供基本功能服务，如下动图所示，今日头条、知乎和懂车帝就是很好的参考例子，在不同意个人隐私协议的情况下，会有仅浏览的模式，在这个情况下依然可以阅读内容而不是退出 App 。

所以严格意义上讲，现在 App 按照类目的规定，如果你的 App 在某些类目就只能获取对应权限，多了就是违规，而且一些类目必须用户在没有提供权限和同意协议的情况下，也必须提供服务。

• 《互联网弹窗信息推送服务管理规定》里就有： 弹窗推送广告显著标明“广告”，一键关闭，提供取消渠道等。

如下图所示，从意见稿开始之后，基本大部分 App 的启动广告就限制了有效点击范围，产品经理也不能拍着脑袋让你加各种奇奇怪怪的跳转。

• 《个人信息保护法》 这个大家肯定就不会陌生了，我在之前《个人信息保护法》更新究竟是什么 也聊过，其中最主要就是提供个人信息的导出机制和广告推送相关内容。

首先用户必须同意了你才能收集，不同意是不能收集，所以 App 里各式各样的弹出框就来了，这也是目前最常见的“合规方式”。

而导出个人信息的功能普遍是通过邮箱发送实现，事实上目前还有不少 App 没提供类似支持，还有 App 必须提供用户注销功能，这也是现在 App 开发的必选项，另外 App 还需要提供个性化推荐的开关能力，不然也有审核风险，当时有时候只是需要你放个按键。

另外，在《个保法》的提案里也提及了不能以用户不提供个人信息为由不提供服务，当时实际执行往往还是要看应用类目。

而在用户个人信息认定里，设备id （Android ID） 绝对是重灾区 ，因为几乎是个 App 就会使用到设备 ID，特别是接入的各类第三方 SDK 服务里普遍都会获取。

而处理方法也是普通粗旷，用户不同意隐私协议，就不初始化各类 SDK ，当然，有时候你可能还是会遇到某些奇葩的审核，明明你已经做了处理，平台还认定你违规，这时候可能你就需要学会申诉，不要傻傻自己一直摸索哪里还不对。

总的来说上架问题一般是和个人信息隐私相关的问题最多，而常见的问题有：

• 未经用户允许手机个人信息


• 所需信息和服务无关，过度收集


• 未提供导出和删除个人信息的功能服务


• 存在个人信息泄漏风险


• 未明确公布个人信息收集的目的和使用范围

最后这一条也是经常出现问题的点，例如现在会要求你提供哪些 SDK 使用了哪些权限和信息，收集规则是什么用于做什么 ，这也就需要 App 里提供更详细和丰富的隐私政策内容，当然 SDK 提供方也要。

而一般情况下最常见也是最容易触发整改的，就是设备ID，MAC 地址等相关内容，或者说你的 App 其实根本不需要这些也能提供服务，就如前面 《常见类型移动互联网应用程序必要个人信息范围规定》里的要求一样。

这里还有个关键，那就是用户在同意隐私条款时，你不能默认勾选，也就是有需要用户同意☑️的 UI 时，默认时不能选中，需要用户手动勾选同意。

当然，随着审核颗粒度的细化，越来越多奇奇怪怪的问题出现了，例如 Apk 里的资源文件存在安全泄漏问题 ，而解决该问题的有效方法就是：混淆和加固。

加固和混淆也适用于以下相关问题的解决，当然，加固的话建议选用第三方付费服务，免费加固的坑实在太多了。

• 《数据出境安全评估办法》 里针对数据出境也做了要求，其中最直观的例子就是：高德 SDK 无法在以外地区范围服务。

当然，不只是相关法规，平台有时候也有自己的规定和理解，比如有几位群友，先后在小米因为 App 里提供 UI 和商店截图一致被打回，理由是应用截图与应用实际功能不符 ，相信遇到这类问题的兄弟是相当郁闷，因为不一致这个认定其实很主观。

另外小米等平台还有以没通过Monkey 自动化测试为理由拒绝上架 ，一般这种情况推荐自己上传 testit.miui.com ，通过小米自动化测试后在上传审核时把你通过截图作为附加，这样可以解决审核时的扯皮问题。

有时候一些平台也会有安全扫描，例如华为就会扫描同名的包名，然后附上 git 链接告诉你风险 。

另外，华为审核时可能会对你的产品逻辑提出他们的想法，比如空白页面，添加引导，没有客服返回渠道等等。

还有另外一个高风险点就是自启动，相信我，如果你要上架平台，2022 年了就不要再想做什么保活相关的逻辑了。

除此之外，如果平台说你存在问题，尽量想办法要到检测报告，因为有时候一些平台委托的第三方可能会不是很“靠谱“，然后需要你自己出钱区做”二次付费检测“。

除了上面的问题之后，如果你还遇到如下图类似问题，都可以通过一些官方平台的检测如 open.oppomobile.com/opdp/privac… 帮助查找问题，这样也许就可以帮老板省下一笔开销，当然有一些第三方开源平台如 Hegui3.0 和 PrivacySentry 等项目，也可以帮助你解决一些实际问题。

最后，如果关于什么上架审核或者安全合规等问题，欢迎留言评论，也许以后本篇可以作为一个更新集合，继续帮助到更多需要的可怜 App 开发。

前言

热修复到现在2022年已经不是一个新名词，但是作为Android开发核心技术栈的一部分，我这里还得来一次冷饭热炒。

随着移动端业务复杂程度的增加，传统的版本更新流程显然无法满足业务和开发者的需求，
热修复技术的推出在很大程度上改善了这一局面。国内大部分成熟的主流 App都拥有自己的热更新技术，像手淘、支付宝、微信、QQ、饿了么、美团等。

可以说，一个好的热修复技术，将为你的 App助力百倍。对于每一个想在 Android 开发领域有所造诣的开发者，掌握热修复技术更是必备的素质。

热修复是 Android 大厂面试中高频面试知识点，也是我们必须要掌握的知识点。热修复技术，可以看作 Android平台发展成熟至一定阶段的必然产物。
Android热修复了解吗？修复哪些东西？
常见热修复框架对比以及各原理分析？

1.什么是热修复

热修复说白了就是不再使用传统的应用商店更新或者自更新方式，使用补丁包推送的方式在用户无感知的情况下，修复应用bug或者推送新的需求

传统更新和热更新过程对比如下：

热修复优缺点:

• 优点:
  
  
  
  • 1.只需要打补丁包，不需要重新发版本。
  
  
  • 2.用户无感知，不需要重新下载最新应用
  
  
  • 3.修复成功率高
  
  
  
  


• 缺点：
  
  
  
  • 补丁包滥用，容易导致应用版本不可控，需要开发一套完整的补丁包更新机制，会增加一定的成本
  
  
  
  

2.热修复方案

首先我们得知道热修复修复哪些东西？

• 1.代码修复


• 2.资源修复


• 3.动态库修复

2.1:代码修复方案

从技术角度来说，我们的目的是非常明确的：把错误的代码替换成正确的代码。
注意这里的替换，并不是直接擦写dx文件，而是提供一份新的正确代码，让应用运行时绕过错误代码，执行新的正确代码。

想法简单直接，但实现起来并不容易。目前主要有三类技术方案：

2.1.1.类加载方案

之前分析类加载机制有说过:
加载流程先是遵循双亲委派原则，如果委派原则没有找到此前加载过此类，
则会调用CLassLoader的findClass方法，再去BaseDexClassLoader下面的dexElements数组中查找，如果没有找到，最终调用defineClassNative方法加载

代码修复就是基于这点：
将新的做了修复的dex文件，通过反射注入到BaseDexClassLoader的dexElements数组的第一个位置上dexElements[0]，下次重新启动应用加载类的时候，会优先加载做了修复的dex文件，这样就达到了修复代码的目的。原理很简单

代码如下：

public class Hotfix {



    public static void patch(Context context, String patchDexFile, String patchClassName)

                    throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException, InstantiationException, NoSuchMethodException, InvocationTargetException {

        //获取系统PathClassLoader的"dexElements"属性值

        PathClassLoader pathClassLoader = (PathClassLoader) context.getClassLoader();

        Object origDexElements = getDexElements(pathClassLoader);



        //新建DexClassLoader并获取“dexElements”属性值

        String otpDir = context.getDir("dex", 0).getAbsolutePath();

        Log.i("hotfix", "otpdir=" + otpDir);

        DexClassLoader nDexClassLoader = new DexClassLoader(patchDexFile, otpDir, patchDexFile, context.getClassLoader());

        Object patchDexElements = getDexElements(nDexClassLoader);



        //将patchDexElements插入原origDexElements前面

        Object allDexElements = combineArray(origDexElements, patchDexElements);



        //将新的allDexElements重新设置回pathClassLoader

        setDexElements(pathClassLoader, allDexElements);



        //重新加载类

        pathClassLoader.loadClass(patchClassName);

}

private static Object getDexElements(ClassLoader classLoader) throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException {

        //首先获取ClassLoader的“pathList”实例

        Field pathListField = Class.forName("dalvik.system.BaseDexClassLoader").getDeclaredField("pathList");

        pathListField.setAccessible(true);//设置为可访问

        Object pathList = pathListField.get(classLoader);



        //然后获取“pathList”实例的“dexElements”属性

        Field dexElementField = pathList.getClass().getDeclaredField("dexElements");

        dexElementField.setAccessible(true);



        //读取"dexElements"的值

        Object elements = dexElementField.get(pathList);

        return elements;

    }

    //合拼dexElements

    private static Object combineArray(Object obj, Object obj2) {

        Class componentType = obj2.getClass().getComponentType();

        //读取obj长度

        int length = Array.getLength(obj);

        //读取obj2长度

        int length2 = Array.getLength(obj2);

        Log.i("hotfix", "length=" + length + ",length2=" + length2);

        //创建一个新Array实例，长度为ojb和obj2之和

        Object newInstance = Array.newInstance(componentType, length + length2);

        for (int i = 0; i < length + length2; i++) {

                //把obj2元素插入前面

                if (i < length2) {

                        Array.set(newInstance, i, Array.get(obj2, i));

                } else {

                        //把obj元素依次放在后面

                        Array.set(newInstance, i, Array.get(obj, i - length2));

                }

        }

        //返回新的Array实例

        return newInstance;

    }

    private static void setDexElements(ClassLoader classLoader, Object dexElements) throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException {

        //首先获取ClassLoader的“pathList”实例

        Field pathListField = Class.forName("dalvik.system.BaseDexClassLoader").getDeclaredField("pathList");

        pathListField.setAccessible(true);//设置为可访问

        Object pathList = pathListField.get(classLoader);



        //然后获取“pathList”实例的“dexElements”属性

        Field declaredField = pathList.getClass().getDeclaredField("dexElements");

        declaredField.setAccessible(true);



        //设置"dexElements"的值

        declaredField.set(pathList, dexElements);

    }

}

类加载过程如下：

微信Tinker，QQ 空间的超级补丁、手 QQ 的QFix 、饿了 么的 Amigo 和 Nuwa 等都是使用这个方式

缺点：因为类加载后无法卸载，所以类加载方案必须重启App，让bug类重新加载后才能生效。

2.1.2:底层替换方案

底层替换方案不会再次加载新类，而是直接在 Native 层 修改原有类，
这里我们需要提到Art虚拟机中ArtMethod：
每一个Java方法在Art虚拟机中都对应着一个 ArtMethod，ArtMethod记录了这个Java方法的所有信息，包括所属类、访问权限、代码执行地址等。

结构如下：

// art/runtime/art_method.h

class ArtMethod FINAL {

...

 protected:

  GcRoot<mirror::Class> declaring_class_;

  GcRoot<mirror::PointerArray> dex_cache_resolved_methods_;

  GcRoot<mirror::ObjectArray<mirror::Class>> dex_cache_resolved_types_;

  uint32_t access_flags_;

  uint32_t dex_code_item_offset_;

  uint32_t dex_method_index_;

  uint32_t method_index_;



  struct PACKED(4) PtrSizedFields {

        void* entry_point_from_interpreter_;      // 1

        void* entry_point_from_jni_;

        void* entry_point_from_quick_compiled_code_;  //2

  } ptr_sized_fields_;

  ...

}

在 ArtMethod结构体中，最重要的就是 注释1和注释2标注的内容，从名字可以看出来，他们就是方法的执行入口。
我们知道，Java代码在Android中会被编译为 Dex Code。

Art虚拟机中可以采用解释模式或者 AOT机器码模式执行 Dex Code

• 解释模式:
  就是去除Dex Code，逐条解释执行。
  如果方法的调用者是以解释模式运行的，在调用这个方法时，就会获取这个方法的 entry_point_from_interpreter_，然后跳转执行。


• AOT模式:
  就会预先编译好 Dex Code对应的机器码，然后在运行期直接执行机器码，不需要逐条解释执行Dex Code。
  如果方法的调用者是以AOT机器码方式执行的，在调用这个方法时，就是跳转到 entry_point_from_quick_compiled_code_中执行。

那是不是只需要替换这个几个 entry_point_* 入口地址就能够实现方法替换了呢？
并没有那么简单，因为不论是解释模式还是AOT模式，在运行期间还会需要调用ArtMethod中的其他成员字段

AndFix采用的是改变指针指向：

// AndFix/jni/art/art_method_replace_6_0.cpp

void replace_6_0(JNIEnv* env, jobject src, jobject dest) {

    art::mirror::ArtMethod* smeth =

                    (art::mirror::ArtMethod*) env->FromReflectedMethod(src);  // 1



    art::mirror::ArtMethod* dmeth =

                    (art::mirror::ArtMethod*) env->FromReflectedMethod(dest);  // 2

    ...

    // 3

    smeth->declaring_class_ = dmeth->declaring_class_;

    smeth->dex_cache_resolved_methods_ = dmeth->dex_cache_resolved_methods_;

    smeth->dex_cache_resolved_types_ = dmeth->dex_cache_resolved_types_;

    smeth->access_flags_ = dmeth->access_flags_ | 0x0001;

    smeth->dex_code_item_offset_ = dmeth->dex_code_item_offset_;

    smeth->dex_method_index_ = dmeth->dex_method_index_;

    smeth->method_index_ = dmeth->method_index_;



    smeth->ptr_sized_fields_.entry_point_from_interpreter_ =

    dmeth->ptr_sized_fields_.entry_point_from_interpreter_;



    smeth->ptr_sized_fields_.entry_point_from_jni_ =

    dmeth->ptr_sized_fields_.entry_point_from_jni_;

    smeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_ =

    dmeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_;



    LOGD("replace_6_0: %d , %d",

             smeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_,

             dmeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_);

}

缺点：存在一些兼容性问题，由于ArtMethod结构体是Android开源的一部分，所以每个手机厂商都可能会去更改这部分的内容，这就可能导致ArtMethod替换方案在某些机型上面出现未知错误。

Sophix为了规避上面的AndFix的风险，采用直接替换整个结构体。这样不管手机厂商如何更改系统，我们都可以正确定位到方法地址

2.4.3:install run方案

Instant Run 方案的核心思想是——插桩，在编译时通过插桩在每一个方法中插入代码，修改代码逻辑，在需要时绕过错误方法，调用patch类的正确方法。

首先，在编译时Instant Run为每个类插入IncrementalChange变量

IncrementalChange  $change;

为每一个方法添加类似如下代码：

public void onCreate(Bundle savedInstanceState) {

    IncrementalChange var2 = $change;

    //$change不为null，表示该类有修改，需要重定向

    if(var2 != null) {

        //通过access$dispatch方法跳转到patch类的正确方法

        var2.access$dispatch("onCreate.(Landroid/os/Bundle;)V", new Object[]{this, savedInstanceState});

    } else {

        super.onCreate(savedInstanceState);

        this.setContentView(2130968601);

        this.tv = (TextView)this.findViewById(2131492944);

    }

}

如上代码，当一个类被修改后，Instant Run会为这个类新建一个类，命名为xxx&override，且实现IncrementalChange接口，并且赋值给原类的$change变量。

public class MainActivity$override implements IncrementalChange {

｝

此时，在运行时原类中每个方法的var2 != null，通过accessdispatch（参数是方法名和原参数）定位到patch类MainActivitydispatch（参数是方法名和原参数）定位到patch类MainActivityoverride中修改后的方法。

Instant Run是google在AS2.0时用来实现“热部署”的，同时也为“热修复”提供了一个绝佳的思路。美团的Robust就是基于此。

2.2：资源修复方案

这里我们来看看install run的原理即可，市面上的常见修复方案大部分都是基于此方法。

public static void monkeyPatchExistingResources(Context context,

            String externalResourceFile, Collection<Activity> activities) {

    if (externalResourceFile == null) {

            return;

    }

    try {

// 创建一个新的AssetManager

        AssetManager newAssetManager = (AssetManager) AssetManager.class

                        .getConstructor(new Class[0]).newInstance(new Object[0]); // ... 1

        Method mAddAssetPath = AssetManager.class.getDeclaredMethod(

                        "addAssetPath", new Class[] { String.class }); // ... 2

        mAddAssetPath.setAccessible(true);

// 通过反射调用addAssetPath方法加载外部的资源（SD卡资源）

        if (((Integer) mAddAssetPath.invoke(newAssetManager,

                        new Object[] { externalResourceFile })).intValue() == 0) { // ... 3

                throw new IllegalStateException(

                                "Could not create new AssetManager");

        }

        Method mEnsureStringBlocks = AssetManager.class.getDeclaredMethod(

                        "ensureStringBlocks", new Class[0]);

        mEnsureStringBlocks.setAccessible(true);

        mEnsureStringBlocks.invoke(newAssetManager, new Object[0]);

        if (activities != null) {

            for (Activity activity : activities) {

                Resources resources = activity.getResources(); // ... 4

                try { 

// 反射得到Resources的AssetManager类型的mAssets字段

                    Field mAssets = Resources.class

                                    .getDeclaredField("mAssets"); // ... 5

                    mAssets.setAccessible(true);

// 将mAssets字段的引用替换为新创建的newAssetManager

                    mAssets.set(resources, newAssetManager); // ... 6

                } catch (Throwable ignore) {

                    ...

                }



// 得到Activity的Resources.Theme

                Resources.Theme theme = activity.getTheme();

                try {

                    try {

// 反射得到Resources.Theme的mAssets字段

                        Field ma = Resources.Theme.class

                                        .getDeclaredField("mAssets");

                        ma.setAccessible(true);

// 将Resources.Theme的mAssets字段的引用替换为新创建的newAssetManager

                        ma.set(theme, newAssetManager); // ... 7

                    } catch (NoSuchFieldException ignore) {

                            ...

                    }

                        ...

                } catch (Throwable e) {

                    Log.e("InstantRun",

                                    "Failed to update existing theme for activity "

                                                    + activity, e);

                }

                pruneResourceCaches(resources);

        }

        }

/**

*  根据SDK版本的不同，用不同的方式得到Resources 的弱引用集合

*/ 

        Collection<WeakReference<Resources>> references;

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

            Class<?> resourcesManagerClass = Class

                            .forName("android.app.ResourcesManager");

            Method mGetInstance = resourcesManagerClass.getDeclaredMethod(

                            "getInstance", new Class[0]);

            mGetInstance.setAccessible(true);

            Object resourcesManager = mGetInstance.invoke(null,

                            new Object[0]);

            try {

                Field fMActiveResources = resourcesManagerClass

                                .getDeclaredField("mActiveResources");

                fMActiveResources.setAccessible(true);



                ArrayMap<?, WeakReference<Resources>> arrayMap = (ArrayMap) fMActiveResources

                                .get(resourcesManager);

                references = arrayMap.values();

            } catch (NoSuchFieldException ignore) {

                Field mResourceReferences = resourcesManagerClass

                                .getDeclaredField("mResourceReferences");

                mResourceReferences.setAccessible(true);



                references = (Collection) mResourceReferences

                                .get(resourcesManager);

            }

        } else {

            Class<?> activityThread = Class

                            .forName("android.app.ActivityThread");

            Field fMActiveResources = activityThread

                            .getDeclaredField("mActiveResources");

            fMActiveResources.setAccessible(true);

            Object thread = getActivityThread(context, activityThread);



            HashMap<?, WeakReference<Resources>> map = (HashMap) fMActiveResources

                            .get(thread);



            references = map.values();

        }

//遍历并得到弱引用集合中的 Resources ，将 Resources mAssets 字段引用替换成新的 AssetManager

            for (WeakReference<Resources> wr : references) {

                Resources resources = (Resources) wr.get();

                if (resources != null) {

                    try {

                        Field mAssets = Resources.class

                                        .getDeclaredField("mAssets");

                        mAssets.setAccessible(true);

                        mAssets.set(resources, newAssetManager);

                    } catch (Throwable ignore) {

                        ...

                    }

                    resources.updateConfiguration(resources.getConfiguration(),

                                    resources.getDisplayMetrics());

                }

            }

    } catch (Throwable e) {

            throw new IllegalStateException(e);

    }

}

• 在注释1处创建一个新的 AssetManager ，


• 在注释2 和注释3 处通过反射调用 addAssetPath 方法加载外部（ SD 卡）的资源。


• 在注释4 处遍历 Activity 列表，得到每个 Activity 的 Resources ，


• 在注释5 处通过反射得到 Resources 的 AssetManager 类型的 rnAssets 字段 ，


• 注释6处改写 mAssets 字段的引用为新的 AssetManager 。

采用同样的方式，

• 在注释7处将 Resources. Theme 的 m Assets 字段 的引用替换为新创建的 AssetManager 。


• 紧接着 根据 SDK 版本的不同，用不同的方式得到 Resources 的弱引用集合，


• 再遍历这个弱引用集合， 将弱引用集合中的 Resources 的 mAssets 字段引用都替换成新创建的 AssetManager 。

资源修复原理：

• 1.创建新的AssetManager，通过反射调用addAssetPath方法，加载外部资源，这样新创建的AssetManager就含有了外部资源


• 2.将AssetManager类型的mAsset字段全部用新创建的AssetManager对象替换。这样下次加载资源文件的时候就可以找到包含外部资源文件的AssetManager。

2.3：动态链接库so的修复

1.接口调用替换方案：

sdk提供接口替换System默认加载so库接口

SOPatchManager.loadLibrary(String libName) -> System.loadLibrary(String libName)

SOPatchManager.loadLibrary接口加载 so库的时候优先尝试去加载sdk 指定目录下的补丁so，

加载策略如下：

如果存在则加载补丁 so库而不会去加载安装apk安装目录下的so库
如果不存在补丁so，那么调用System.loadLibrary去加载安装apk目录下的 so库。

我们可以很清楚的看到这个方案的优缺点:
优点：不需要对不同 sdk 版本进行兼容，因为所有的 sdk 版本都有 System.loadLibrary 这个接口。
缺点：调用方需要替换掉 System 默认加载 so 库接口为 sdk提供的接口， 如果是已经编译混淆好的三方库的so 库需要 patch，那么是很难做到接口的替换

虽然这种方案实现简单，同时不需要对不同 sdk版本区分处理，但是有一定的局限性没法修复三方包的so库同时需要强制侵入接入方接口调用，接着我们来看下反射注入方案。

2、反射注入方案

前面介绍过 System. loadLibrary ( "native-lib"); 加载 so库的原理，其实native-lib 这个 so 库最终传给 native 方法执行的参数是 so库在磁盘中的完整路径，比如：/data/app-lib/com.taobao.jni-2/libnative-lib.so, so库会在 DexPathList.nativeLibraryDirectories/nativeLibraryPathElements 变量所表示的目录下去遍历搜索

sdk<23 DexPathList.findLibrary 实现如下

可以发现会遍历 nativeLibraryDirectories数组，如果找到了 loUtils.canOpenReadOnly (path)返回为 true, 那么就直接返回该 path, loUtils.canOpenReadOnly (path)返回为 true 的前提肯定是需要 path 表示的 so文件存 在的。那么我们可以采取类似类修复反射注入方式，只要把我们的补丁so库的路径插入到nativeLibraryDirectories数组的最前面就能够达到加载so库的时候是补丁 库而不是原来so库的目录，从而达到修复的目的。

sdk>=23 DexPathList.findLibrary 实现如下

sdk23 以上 findLibrary 实现已经发生了变化，如上所示，那么我们只需要把补丁so库的完整路径作为参数构建一个Element对象，然后再插入到nativeLibraryPathElements 数组的最前面就好了。

• 优点：可以修复三方库的so库。同时接入方不需要像方案1 —样强制侵入用 户接口调用


• 缺点：需要不断的对 sdk 进行适配，如上 sdk23 为分界线，findLibrary接口实现已经发生了变化。

对于 so库的修复方案目前更多采取的是接口调用替换方式，需要强制侵入用户 接口调用。
目前我们的so文件修复方案采取的是反射注入的方案，重启生效。具有更好的普遍性。
如果有so文件修复实时生效的需求，也是可以做到的，只是有些限制情况。

常见热修复框架？

可以看出，阿里系多采用native底层方案，腾讯系多采用类加载机制。其中，Sophix是商业化方案；Tinker/Amigo支持特性较多，同时也更复杂，如果需要修复资源和so，可以选择；如果仅需要方法替换，且需要即时生效，Robust是不错的选择。

总结：

尽管热修复（或热更新）相对于迭代更新有诸多优势，市面上也有很多开源方案可供选择，但目前热修复依然无法替代迭代更新模式。有如下原因：
热修复框架多多少少会增加性能开销，或增加APK大小
热修复技术本身存在局限，比如有些方案无法替换so或资源文件
热修复方案的兼容性，有些方案无法同时兼顾Dalvik和ART，有些深度定制系统也无法正常工作
监管风险，比如苹果系统严格限制热修复

所以，对于功能迭代和常规bug修复，版本迭代更新依然是主流。一般的代码修复，使用Robust可以解决，如果还需要修复资源或so库，可以考虑Tinker。

LinkedList源码解析

目标

• 理解LinkedList底层数据结构


• 深入源码掌握LinkedList查询慢，新增快的原因

1.简介

List 接口的链接列表实现。实现所有可选的列表操作，并且允许所有元素（包括 null ）。除了实现 List 接口外， LinkedList 类还为在列表的开头及结尾 get 、 remove 和 insert 元素提供了统一 的命名方法。这些操作允许将链接列表用作堆栈、队列或双端队列。

特点 :

• 有序性 : 存入和取出的顺序是一致的


• 元素可以重复


• 含有带索引的方法


• 独有特点 : 数据结构是链表，可以作为栈、队列或者双端队列！

2.LinkedList原理分析

双向链表

底层数据结构源码

public class LinkedList<E> {

    transient int size = 0;

    //双向链表的头结点

    transient Node<E> first;

    //双向链表的最后一个节点

    transient Node<E> last;



    //节点类【内部类】

    private static class Node<E> {

        E item;//数据元素

        Node<E> next;//下一个节点

        Node<E> prev;//上一个节点



        //节点的构造方法

        Node(Node<E> prev, E element, Node<E> next) {

            this.item = element;

            this.next = next;

            this.prev = prev;

        }

    } /

            /...

}

2.1 LinkedList的数据结构

LinkedList是双向链表，在代码中是一个Node类。内部并没有数组的结构。双向链表肯定存在一个头节 点和一个尾部节点。node节点类，是以内部类的形式存在于LinkedList中的。Node类都有两个成员变 量:

• prev : 当前节点上一个节点，头节点的上一个节点是null


• next : 当前节点下一个节点，尾结点的下一个节点是null

链表数据结构的特点 : 查询慢，增删快！

• 链表数据结构基本构成，是一个node类


• 每个node类中，有上一个节点【prev】和下一个节点【next】


• 链表一定存在至少两个节点，first和last节点


• 如果LinkedList没有数据，first和last都是为null

2.2 LinkedList默认容量&最大容量

没有默认容量，也没有最大容量

2.3 LinkedList扩容机制

无需扩容机制，只要你的内存足够大，可以无限制扩容下去。前提是不考虑查询的效率。

2.4 为什么LinkedList查询慢，增删快？

LinkedList的数据结构的特点，链表的数据结构就是这样的特点！

• 链表是一种查询慢的结构【相对于数组来说】


• 链表是一种增删快的结构【相对于数组来说】

2.5 LinkedList源码剖析-为什么增删快？

新增add

//想LinkedList添加一个元素

public boolean add(E e){

//连接到链表的末尾

        linkLast(e);

        return true;

        }/

        /连接到最后一个节点上去

        void linkLast(E e){

//将全局末尾节点赋值给l

final Node<E> l=last;

//创建一个新节点 : (上一个节点, 当前插入元素, null)

final Node<E> newNode=new Node<>(l,e,null);

//将当前节点作为末尾节点

        last=newNode;

//判断l节点是否为null

        if(l==null)

//既是尾结点也是头节点

        first=newNode;

        else

//之前的末尾节点，下一个节点时末尾节点！

        l.next=newNode;

        size++;//当前集合的元素数量+1

        modCount++;//操作集合数+1。modCount属性是修改技术器

        }/

        /------------------------------------------------------------------

//向链表中部添加

//参数1，添加的索引位置，添加元素

public void add(int index,E element){

//检查索引位是否符合要求

        checkPositionIndex(index);

//判断当前所有是否是存储元素个数

        if(index==size)//true，最后一个元素

        linkLast(element);

        else

//连接到指定节点的后面【链表中部插入】

        linkBefore(element,node(index));

        }/

        /根据索引查询链表中节点！

        Node<E> node(int index){

// 判断索引是否小于 已经存储元素个数的1/2

        if(index< (size>>1)){//二分法查找 : 提高查找节点效率

        Node<E> x=first;

        for(int i=0;i<index; i++)

        x=x.next;

        return x;

        }else{

        Node<E> x=last;

        for(int i=size-1;i>index;i--)

        x=x.prev;

        return x;

        }

        }/

        /将当前元素添加到指定节点之前

        void linkBefore(E e,Node<E> succ){

        // 取出当前节点的前一个节点

        final Node<E> pred=succ.prev;

        //创建当前元素的节点 : 上一个节点，当前元素，下一个节点

        final Node<E> newNode=new Node<>(pred,e,succ);

        //为指定节点上一个节点重新值

        succ.prev=newNode;

//判断当前节点的上一个节点是否为null

        if(pred==null)

        first=newNode;//当前节点作为头部节点

        else

        pred.next=newNode;//将新插入节点作为上一个节点的下个节点

        size++;//新增元素+1

        modCount++;//操作次数+1

        }

remove删除指定索引元素

//删除指定索引位置元素

public E remove(int index){

//检查元素索引

        checkElementIndex(index);

//删除元素节点，

//node(index) 根据索引查到要删除的节点

//unlink()删除节点

        return unlink(node(index));

        }//根据索引查询链表中节点！

        Node<E> node(int index){

// 判断索引是否小于 已经存储元素个数的1/2

        if(index< (size>>1)){//二分法查找 : 提高查找节点效率

        Node<E> x=first;

        for(int i=0;i<index; i++)

        x=x.next;

        return x;

        }else{

        Node<E> x=last;

        for(int i=size-1;i>index;i--)

        x=x.prev;

        return x;

        }

        }/

        /删除一个指定节点

        E unlink(Node<E> x){

//获取当前节点中的元素

final E element=x.item;

//获取当前节点的上一个节点

final Node<E> next=x.next;

//获取当前节点的下一个节点

final Node<E> prev=x.prev;

//判断上一个节点是否为null

        if(prev==null){

//如果为null，说明当前节点为头部节点

        first=next;

        }else{

//上一个节点，的下一个节点改为下下节点

        prev.next=next;

//将当前节点的上一个节点置空

        x.prev=null;

        }/

        /判断下一个节点是否为null

        if(next==null){

//如果为null，说明当前节点为尾部节点

        last=prev;

        }else{

//下一个节点的上节点，改为上上节点

        next.prev=prev;

//当前节点的上节点置空

        x.next=null;

        }/

        /删除当前节点内的元素

        x.item=null;

        size--;//集合中的元素个数-1

        modCount++;//当前集合操作数+1。modCount计数器，记录当前集合操作次数

        return element;//返回删除的元素

        }

2.6 LinkedList源码剖析-为什么查询慢？

查询快和慢是一个相对概念！相对于数组来说

//根据索引查询一个元素

public E get(int index){

//检查索引是否存在

        checkElementIndex(index);

// node(index)获取索引对应节点，获取节点中的数据item

        return node(index).item;

        }/

        /根据索引获取对应节点对象

        Node<E> node(int index){

//二分法查找索引对应的元素

        if(index< (size>>1)){

        Node<E> x=first;

//前半部分查找【遍历节点】

        for(int i=0;i<index; i++)

        x=x.next;

        return x;

        }else{

        Node<E> x=last;

//后半部分查找【遍历】

        for(int i=size-1;i>index;i--)

        x=x.prev;

        return x;

        }

        }/

        /查看ArrayList里的数组获取元素的方式

public E get(int index){

        rangeCheck(index);//检查范围

        return elementData(index);//获取元素

        }E

        elementData(int index){

        return(E)elementData[index];//一次性操作

        }

这是《Spring Security 进阶》专栏的第三篇文章，给大家介绍一下Spring Security 中内置的加密算法BCrypt，号称最安全的加密算法，究竟有着什么魔力能让黑客闻风丧胆

哈希（Hash）与加密（Encrypt）

哈希（Hash）是将目标文本转换成具有相同长度的、不可逆的杂凑字符串（或叫做消息摘要），而加密（Encrypt）是将目标文本转换成具有不同长度的、可逆的密文。

• 哈希算法往往被设计成生成具有相同长度的文本，而加密算法生成的文本长度与明文本身的长度有关。


• 哈希算法是不可逆的，而加密算法是可逆的。

HASH 算法是一种消息摘要算法，不是一种加密算法，但由于其单向运算，具有一定的不可逆性，成为加密算法中的一个构成部分。

JDK的String的Hash算法。代码如下：

public int hashCode() {

    int h = hash;

    if (h == 0 && value.length > 0) {

        char val[] = value;

        for (int i = 0; i < value.length; i++) {

            h = 31 * h + val[i];

        }

        hash = h;

    }

    return h;

}

从JDK的API可以看出，它的算法等式就是s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]，其中s[i]就是索引为i的字符，n为字符串的长度。

HashMap的hash计算时先计算hashCode(),然后进行二次hash。代码如下：

// 计算二次Hash    

int hash = hash(key.hashCode());



static int hash(int h) {

	h ^= (h >>> 20) ^ (h >>> 12);

	return h ^ (h >>> 7) ^ (h >>> 4);

}

可以发现，虽然算法不同，但经过这些移位操作后，对于同一个值使用同一个算法，计算出来的hash值一定是相同的。

那么，hash为什么是不可逆的呢？

假如有两个密码3和4，我的加密算法很简单就是3+4，结果是7，但是通过7我不可能确定那两个密码是3和4，有很多种组合，这就是最简单的不可逆，所以只能通过暴力破解一个一个的试。

在计算过程中原文的部分信息是丢失了。一个MD5理论上是可以对应多个原文的，因为MD5是有限多个而原文是无限多个的。

不可逆的MD5为什么是不安全的？

因为hash算法是固定的，所以同一个字符串计算出来的hash串是固定的，所以，可以采用如下的方式进行破解。

1. 暴力枚举法：简单粗暴地枚举出所有原文，并计算出它们的哈希值，看看哪个哈希值和给定的信息摘要一致。


2. 字典法：黑客利用一个巨大的字典，存储尽可能多的原文和对应的哈希值。每次用给定的信息摘要查找字典，即可快速找到碰撞的结果。


3. 彩虹表（rainbow）法：在字典法的基础上改进，以时间换空间。是现在破解哈希常用的办法。

对于单机来说，暴力枚举法的时间成本很高（以14位字母和数字的组合密码为例，共有1.24×10^25种可能，即使电脑每秒钟能进行10亿次运算，也需要4亿年才能破解），字典法的空间成本很高（仍以14位字母和数字的组合密码为例，生成的密码32位哈希串的对照表将占用5.7×10^14 TB的存储空间）。但是利用分布式计算和分布式存储，仍然可以有效破解MD5算法。因此这两种方法同样被黑客们广泛使用。

如何防御彩虹表的破解？

虽然彩虹表有着如此惊人的破解效率，但网站的安全人员仍然有办法防御彩虹表。最有效的方法就是“加盐”，即在密码的特定位置插入特定的字符串，这个特定字符串就是“盐（Salt）”，加盐后的密码经过哈希加密得到的哈希串与加盐前的哈希串完全不同，黑客用彩虹表得到的密码根本就不是真正的密码。即使黑客知道了“盐”的内容、加盐的位置，还需要对H函数和R函数进行修改，彩虹表也需要重新生成，因此加盐能大大增加利用彩虹表攻击的难度。

一个网站，如果加密算法和盐都泄露了，那针对性攻击依然是非常不安全的。因为同一个加密算法同一个盐加密后的字符串仍然还是一毛一样滴！

一个更难破解的加密算法Bcrypt

BCrypt是由Niels Provos和David Mazières设计的密码哈希函数，他是基于Blowfish密码而来的，并于1999年在USENIX上提出。

除了加盐来抵御rainbow table 攻击之外，bcrypt的一个非常重要的特征就是自适应性，可以保证加密的速度在一个特定的范围内，即使计算机的运算能力非常高，可以通过增加迭代次数的方式，使得加密速度变慢，从而可以抵御暴力搜索攻击。

Bcrypt可以简单理解为它内部自己实现了随机加盐处理。使用Bcrypt，每次加密后的密文是不一样的。

对一个密码，Bcrypt每次生成的hash都不一样，那么它是如何进行校验的？

1. 虽然对同一个密码，每次生成的hash不一样，但是hash中包含了salt（hash产生过程：先随机生成salt，salt跟password进行hash）；


2. 在下次校验时，从hash中取出salt，salt跟password进行hash；得到的结果跟保存在DB中的hash进行比对。

在Spring Security 中 内置了Bcrypt加密算法，构建也很简单，代码如下：

@Bean

public PasswordEncoder passwordEncoder(){

    return new BCryptPasswordEncoder();

}

生成的加密字符串格式如下：

$2b$[cost]$[22 character salt][31 character hash]

比如：

$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy

\__/\/ \____________________/\_____________________________/

 Alg Cost      Salt                        Hash

上面例子中，$2a$ 表示的hash算法的唯一标志。这里表示的是Bcrypt算法。

10 表示的是代价因子，这里是2的10次方，也就是1024轮。

N9qo8uLOickgx2ZMRZoMye 是16个字节（128bits）的salt经过base64编码得到的22长度的字符。

最后的IjZAgcfl7p92ldGxad68LJZdL17lhWy是24个字节（192bits）的hash，经过bash64的编码得到的31长度的字符。

PasswordEncoder 接口

这个接口是Spring Security 内置的，如下：

public interface PasswordEncoder {

   String encode(CharSequence rawPassword);



   boolean matches(CharSequence rawPassword, String encodedPassword);



   default boolean upgradeEncoding(String encodedPassword) {

      return false;

   }

}

这个接口有三个方法：

• encode方法接受的参数是原始密码字符串，返回值是经过加密之后的hash值，hash值是不能被逆向解密的。这个方法通常在为系统添加用户，或者用户注册的时候使用。


• matches方法是用来校验用户输入密码rawPassword，和加密后的hash值encodedPassword是否匹配。如果能够匹配返回true，表示用户输入的密码rawPassword是正确的，反之返回fasle。也就是说虽然这个hash值不能被逆向解密，但是可以判断是否和原始密码匹配。这个方法通常在用户登录的时候进行用户输入密码的正确性校验。


• upgradeEncoding设计的用意是，判断当前的密码是否需要升级。也就是是否需要重新加密？需要的话返回true，不需要的话返回fasle。默认实现是返回false。

例如，我们可以通过如下示例代码在进行用户注册的时候加密存储用户密码

//将User保存到数据库表，该表包含password列

user.setPassword(passwordEncoder.encode(user.getPassword()));

BCryptPasswordEncoder 是Spring Security推荐使用的PasswordEncoder接口实现类

public class PasswordEncoderTest {

  @Test

  void bCryptPasswordTest(){

    PasswordEncoder passwordEncoder =  new BCryptPasswordEncoder();

    String rawPassword = "123456";  //原始密码

    String encodedPassword = passwordEncoder.encode(rawPassword); //加密后的密码



    System.out.println("原始密码" + rawPassword);

    System.out.println("加密之后的hash密码:" + encodedPassword);



    System.out.println(rawPassword + "是否匹配" + encodedPassword + ":"   //密码校验：true

            + passwordEncoder.matches(rawPassword, encodedPassword));



    System.out.println("654321是否匹配" + encodedPassword + ":"   //定义一个错误的密码进行校验:false

            + passwordEncoder.matches("654321", encodedPassword));

  }

}

上面的测试用例执行的结果是下面这样的。（注意：对于同一个原始密码，每次加密之后的hash密码都是不一样的，这正是BCryptPasswordEncoder的强大之处，它不仅不能被破解，想通过常用密码对照表进行大海捞针你都无从下手），输出如下：

原始密码123456

加密之后的hash密码:$2a$10$zt6dUMTjNSyzINTGyiAgluna3mPm7qdgl26vj4tFpsFO6WlK5lXNm

123456是否匹配$2a$10$zt6dUMTjNSyzINTGyiAgluna3mPm7qdgl26vj4tFpsFO6WlK5lXNm:true

654321是否匹配$2a$10$zt6dUMTjNSyzINTGyiAgluna3mPm7qdgl26vj4tFpsFO6WlK5lXNm:false

BCrypt 产生随机盐（盐的作用就是每次做出来的菜味道都不一样）。这一点很重要，因为这意味着每次encode将产生不同的结果。

前言

个人打算开发个视频编辑的APP，然后把一些用上的技术总结一下，这次主要是APP的底部菜单栏用到了一个自定义View去绘制实现的，所以这次主要想讲讲自定义View的一些用到的点和自己如何去DIY一个不一样的自定义布局。

实现的效果和思路

可以先看看实现的效果

两个页面的内容还没做，当前就是一个Demo，可以看到底部的菜单栏是一个绘制出来的不规则的一个布局，那要如何实现呢。可以先来看看它的一个绘制区域：

就是一个底部的布局和3个子view，底部的区域当然也是个规则的区域，只不过我们是在这块区域上去进行绘制。

可以把整个过程分为几个步骤：

1. 绘制底部布局

    (1) 绘制矩形区域

    (2) 绘制外圆形区域

    (3) 绘制内圆形区域

2. 添加子view进行布局

3. 处理事件分发的区域 (底部菜单上边的白色区域不触发菜单的事件)

4. 写个动画意思意思

1. 绘制底部布局

这里做的话就没必要手动去添加view这些了，直接全部手动绘制就行。

companion object{



    const val DIMENS_64 = 64.0

    const val DIMENS_96 = 96.0

    const val DIMENS_50 = 50.0

    const val DIMENS_48 = 48.0



    interface OnChildClickListener{

        fun onClick(index : Int)

    }



}



private var paint : Paint ?= null  // 绘制蓝色区域的画笔

private var paint2 : Paint ?= null  // 绘制白色内圆的画笔

private var allHeight : Int = 0  // 总高度，就是绘制的范围

private var bgHeight : Int = 0  // 背景的高度，就是蓝色矩阵的范围

private var mRadius : Int = 0  // 外圆的高度

private var mChildSize : Int = 0

private var mChildCenterSize : Int = 0



private var mWidthZone1 : Int = 0

private var mWidthZone2 : Int = 0

private var mChildCentre : Int = 0



private var childViews : MutableList<View> = mutableListOf()

private var objectAnimation : ObjectAnimator ?= null

var onChildClickListener : OnChildClickListener ?= null



init {

    initView()

}



private fun initView(){

    val lp = ViewGroup.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT,

        DimensionUtils.dp2px(context, DIMENS_64).toInt())

    layoutParams = lp



    allHeight = DimensionUtils.dp2px(context, DIMENS_96).toInt()

    bgHeight = DimensionUtils.dp2px(context, DIMENS_64).toInt()

    mRadius = DimensionUtils.dp2px(context, DIMENS_50).toInt()

    mChildSize = DimensionUtils.dp2px(context, DIMENS_48).toInt()

    mChildCenterSize = DimensionUtils.dp2px(context, DIMENS_64).toInt()

    setWillNotDraw(false)



    initPaint()

}



private fun initPaint(){

    paint = Paint()

    paint?.isAntiAlias = true

    paint?.color = context.resources.getColor(R.color.kylin_main_color)



    paint2 = Paint()

    paint2?.isAntiAlias = true

    paint2?.color = context.resources.getColor(R.color.kylin_third_color)

}

上边是先把一些尺寸给定义好（我这边是没有设计图，自己去直接调整的，所以可能有些视觉效果不太好，如果有设计师帮忙的话效果肯定会好些），绘制流程就是绘制3个形状，然后代码里也加了些注释哪个变量有什么用，这步应该不难，没什么可以多解释的。

override fun onMeasure(widthMeasureSpec: Int, heightMeasureSpec: Int) {

    super.onMeasure(widthMeasureSpec, heightMeasureSpec)

    val wSize = MeasureSpec.getSize(widthMeasureSpec)

    // 拿到子view做操作的，和这步无关，可以先不看

    if (childViews.size <= 0) {

        for (i in 0 until childCount) {

            val cView = getChildAt(i)

            initChildView(cView, i)

            childViews.add(cView)

            if (i == childCount/2){

                val ms: Int = MeasureSpec.makeMeasureSpec(mRadius, MeasureSpec.AT_MOST)

                measureChild(cView, ms, ms)

            }else {

                val ms: Int = MeasureSpec.makeMeasureSpec(mChildSize, MeasureSpec.AT_MOST)

                measureChild(cView, ms, ms)

            }

        }

    }



    setMeasuredDimension(wSize, allHeight)

}

这步其实也很简单，就是说给当前自定义view设置高度为allHeight

override fun onDraw(canvas: Canvas?) {

    super.onDraw(canvas)

    // 绘制长方形区域

    canvas?.drawRect(left.toFloat(), ((allHeight - bgHeight).toFloat()),

        right.toFloat(), bottom.toFloat(), paint!!)



    // 绘制圆形区域

    paint?.let {

        canvas?.drawCircle(

            (width/2).toFloat(), mRadius.toFloat(),

            mRadius.toFloat(),

            it

        )

    }



    // 绘制内圆区域

    paint2?.let {

        canvas?.drawCircle(

            (width/2).toFloat(), mRadius.toFloat(),

            (mRadius - 28).toFloat(),

            it

        )

    }

}

最后进行绘制， 就是上面说的绘制3个图形，代码里的注释也说得很清楚。

2. 添加子view

我这里是外面布局去加子view的，想弄得灵活点（但感觉也不太好，后面还是想改成里面定义一套规范来弄会好些，如果自由度太高的话去做自定义就很麻烦，而且实际开发中这种需求也没必要把扩展性做到这种地步，基本就是整个APP只有一个地方使用）

但是这边也只是一个Demo先做个演示。

<com.kylin.libkcommons.widget.BottomMenuBar

    android:id="@+id/bv_content"

    android:layout_width="match_parent"

    android:layout_height="wrap_content"

    android:layout_alignParentBottom="true"

    >



    <ImageView

        android:layout_width="wrap_content"

        android:layout_height="wrap_content"

        android:src="@drawable/home"

        />



    <ImageView

        android:layout_width="wrap_content"

        android:layout_height="wrap_content"

        android:src="@drawable/video"

        />



    <ImageView

        android:layout_width="wrap_content"

        android:layout_height="wrap_content"

        android:src="@drawable/more"

        />



</com.kylin.libkcommons.widget.BottomMenuBar>

override fun onMeasure(widthMeasureSpec: Int, heightMeasureSpec: Int) {

    super.onMeasure(widthMeasureSpec, heightMeasureSpec)

    val wSize = MeasureSpec.getSize(widthMeasureSpec)



    if (childViews.size <= 0) {

        for (i in 0 until childCount) {

            val cView = getChildAt(i)

            initChildView(cView, i)

            childViews.add(cView)

            if (i == childCount/2){

                val ms: Int = MeasureSpec.makeMeasureSpec(mRadius, MeasureSpec.AT_MOST)

                measureChild(cView, ms, ms)

            }else {

                val ms: Int = MeasureSpec.makeMeasureSpec(mChildSize, MeasureSpec.AT_MOST)

                measureChild(cView, ms, ms)

            }

        }

    }



    setMeasuredDimension(wSize, allHeight)

}

拿到子view进行一个管理，做一些初始化的操作，主要是设点击事件这些，这里不是很重要。

override fun onLayout(changed: Boolean, l: Int, t: Int, r: Int, b: Int) {

    if (mChildCentre == 0){

        mChildCentre = width / 6

    }



    // 辅助事件分发区域

    if (mWidthZone1 == 0 || mWidthZone2 == 0) {

        mWidthZone1 = width / 2 - mRadius / 2

        mWidthZone2 = width / 2 + mRadius / 2

    }



    // 设置每个子view的显示区域

    for (i in 0 until childViews.size) {

        if (i == childCount/2){

            childViews[i].layout(mChildCentre*(2*i+1) - mChildCenterSize/2 ,

                allHeight/2 - mChildCenterSize/2,

                mChildCentre*(2*i+1) + mChildCenterSize/2 ,

                allHeight/2 + mChildCenterSize/2)

        }else {

            childViews[i].layout(mChildCentre*(2*i+1) - mChildSize/2 ,

                allHeight - bgHeight/2 - mChildSize/2,

                mChildCentre*(2*i+1) + mChildSize/2 ,

                allHeight - bgHeight/2 + mChildSize/2)

        }

    }



}

进行布局，这里比较重要，因为能看出，中间的图标会更大一些，所以要做一些适配。其实这里就是把宽度分为6块，然后3个view分别在1,3,5这三个左边点，y的话就是除中间那个，其它两个都是bgHeight绘制高度的的一半，中间那个是allHeight总高度的一半，这样3个view的x和y坐标都能拿到了，再根据宽高就能算出l,t,r,b四个点，然后布局。

3. 处理事件分发

可以看出我们的区域是一个不规则的区域，按照我们用抽象的角度去思考，我们希望这个菜单栏的区域只是显示蓝色的那个区域，所以蓝色区域上面的白色区域就算是我们自定义view的范围，他触发的事件也应该是后面的view的事件（Demo中后面的View是一个ViewPager），而不是菜单栏。

// 辅助事件分发区域

if (mWidthZone1 == 0 || mWidthZone2 == 0) {

    mWidthZone1 = width / 2 - mRadius / 2

    mWidthZone2 = width / 2 + mRadius / 2

}

这两块是圆外的x的区域。

/**

 *  判断点击事件是否在点击区域中

 */

private fun isShowZone(x : Float, y : Float) : Boolean{

    if (y >= allHeight - bgHeight){

        return true

    }

    if (x >= mWidthZone1 && x <= mWidthZone2){

        // 在圆内

        val relativeX = abs(x - width/2)

        val squareYZone = mRadius.toDouble().pow(2.0) - relativeX.toDouble().pow(2.0)

        return y >= mRadius - sqrt(squareYZone)

    }

    return false

}

先判断y如果在背景的矩阵中（上面说了自定义view分成矩阵，外圆，内圆），那肯定是菜单的区域。如果不在，那就要判断y在不在圆内，这里就必须用勾股定理去判断。

override fun onTouchEvent(event: MotionEvent?): Boolean {

    // 点击区域进行拦截

    if (event?.action == MotionEvent.ACTION_DOWN && isShowZone(event.x, event.y)){

        return true

    }

    return super.onTouchEvent(event)

}

最后做一个事件分发的拦截。除了计算区域那可能需要去想想，其它地方我觉得都挺好理解的吧。

4. 做个动画

给子view设点击事件让外部处理，然后给中间的按钮做个动画效果。

private fun initChildView(cView : View?, index : Int) {

    cView?.setOnClickListener {

        if (index == childViews.size/2) {

            startAnim(cView)

        }else {

            onChildClickListener?.onClick(index)

        }

    }

}

private fun startAnim(view : View){

    if (objectAnimation == null) {

        objectAnimation = ObjectAnimator.ofFloat(view,

            "rotation", 0f, -15f, 180f, 0f)

        objectAnimation?.addListener(object : Animator.AnimatorListener {



            override fun onAnimationStart(p0: Animator) {

            }



            override fun onAnimationEnd(p0: Animator) {

                onChildClickListener?.onClick(childViews.size / 2)

            }



            override fun onAnimationCancel(p0: Animator) {

                onChildClickListener?.onClick(childViews.size / 2)

            }



            override fun onAnimationRepeat(p0: Animator) {

            }



        })

        objectAnimation?.duration = 1000

        objectAnimation?.interpolator = AccelerateDecelerateInterpolator()

    }

    objectAnimation?.start()

}

注意做释放操作。

fun onDestroy(){

    try {

        objectAnimation?.cancel()

        objectAnimation?.removeAllListeners()

    }catch (e : Exception){

        e.printStackTrace()

    }finally {

        objectAnimation = null

    }

}

5. 小结

其实代码都挺简单的，关键是你要去想出一个方法来实现这个场景，然后感觉这个自定义viewgroup也是比较经典的，涉及到measure、layout、draw，涉及到动画，涉及到点击冲突。

这个Demo表示你要实现怎样的效果都可以，只要是draw能画出来的，你都能实现，我这个是中间凸出来，你可以实现凹进去，你可以实现波浪的样子，可以实现复杂的曲线，都行，你用各种基础图形去做拼接，或者画贝塞尔等等，其实都不难，主要是要有个计算和调试的过程。但是你的形状要和点击区域关联起来，你设计的图案越复杂，你要适配的点击区域计算量就越大。

甚至我还能做得效果更屌的是，那3个子view的图标，我都能画出来，就不用ImagerView，直接手动画出来，这样做的好处是什么呢？我对子view的图标能做各种炫酷的属性动画，我在切换viewpager时对图标做属性动画，那不得逼格再上一层。 为什么我没做呢，因为没有设计，我自己做的话要花大量的时间去调，要是有设计的话他告诉我尺寸啊位置啊这些信息，做起来就很快。我的APP主要是打算实现视频的编辑为主，所以这些支线就没打算花太多时间去处理。

一、简介

了解过协程Flow 的同学知道是典型的冷数据流，而SharedFlow与StateFlow则是热数据流。

• 冷流：只有当订阅者发起订阅时，事件的发送者才会开始发送事件。


• 热流：不管订阅者是否存在，只要发送了事件就会被消费，意思是不管接受方是否能够接收到，在这一点上有点像我们Android的LiveData。

解释：LiveData新的订阅者不会接收到之前发送的事件，只会收到之前发送的最后一条数据，这个特性和SharedFlow的参数replay设置为1相似

二、使用分析

最好的分析是从使用时入手冷流flow，热流SharedFlow和StateFlow热流的具体的实现类分别是MutableSharedFlow和MutableStateFlow

用一个简单的例子来说明什么是冷流，什么是热流。

• 冷流flow:

private fun testFlow() {

    val flow = flow<Int> {

        (1..5).forEach {

            delay(1000)

            emit(it)

        }

    }

    mBind.btCollect.setOnClickListener {

        lifecycleScope.launch {

            flow.collect {

                Log.d(TAG, "testFlow 第一个收集器: 我是冷流：$it")

            }

        }

        lifecycleScope.launch {

            delay(5000)

            flow.collect {

                Log.d(TAG, "testFlow:第二个收集器 我是冷流：$it")

            }

        }

    }



}

我点击收集按钮响应事件后，打印结果如下图：

这就是冷流，需要去触发收集，才能接收到结果。

从上图时间可知flow每次重新订阅收集都会将所有事件重新发送一次

• 热流MutableSharedFlow和

private fun testSharedFlow() {



    val sharedFlow = MutableSharedFlow<Int>(

        replay = 0,//相当于粘性数据

        extraBufferCapacity = 0,//接受的慢时候，发送的入栈

        onBufferOverflow = BufferOverflow.SUSPEND

    )

    lifecycleScope.launch {

        launch {



            sharedFlow.collect {

                println("collect1 received ago shared flow $it")



            }

        }

        launch {

            (1..5).forEach {

                println("emit1  send ago  flow $it")

                sharedFlow.emit(it)

                println("emit1 send after flow $it")

            }

        }

        // wait a 100

        delay(100)

        launch {

            sharedFlow.collect {

                println("collect2 received shared flow $it")

            }

        }

    }



}

第二个流收集被延迟，晚了100毫秒后就收不到了，想当于不管是否订阅，流都会发送，只管发，而collect1能够收集到是因为他在发送之前进行了订阅收集。

三、分析MutableSharedFlow中参数的具体含义

以上面testSharedFlow（）方法中对象为例，上面的配置就是，当前对象的默认配置
源码如下图：

val sharedFlow = MutableSharedFlow<Int>(

    replay = 0,//相当于粘性数据

    extraBufferCapacity = 0,//接受的慢时候，发送的入栈

    onBufferOverflow = BufferOverflow.SUSPEND //产生背压现象后的，执行策略

)

3.1、 reply:事件粘滞数

reply:事件粘滞数以testSharedFlow方法为例如果设置了数目的话，那么其他订阅者不管什么时候订阅都能够收到replay数目的最新的事件，reply=1的话有点类似Android中使用的livedata。

eg:和testSharedFlow方法区别在于 replay = 2

private fun testSharedFlowReplay() {



    val sharedFlow = MutableSharedFlow<Int>(

        replay = 2,//相当于粘性数据

        extraBufferCapacity = 0,//接受的慢时候，发送的入栈

        onBufferOverflow = BufferOverflow.SUSPEND

    )

    lifecycleScope.launch {

        launch {



            sharedFlow.collect {

                println("collect1 received ago shared flow $it")



            }

        }

        launch {

            (1..5).forEach {

                println("emit1  send ago  flow $it")

                sharedFlow.emit(it)

                println("emit1 send after flow $it")

            }

        }

        // wait a minute

        delay(100)

        launch {

            sharedFlow.collect {

                println("collect2 received shared flow $it")

            }

        }

    }



}

按照上面的解释collect2会收集到最新的4，5两个事件如下图：

3.2 extraBufferCapacity：缓存容量

extraBufferCapacity：缓存容量，就是先发送几个事件，不管已经订阅的消费者是否接收，这种只管发不管消费者消费能力的情况就会出现背压，参数onBufferOverflow就是用于处理背压问题

eg:和testSharedFlow方法区别在于 extraBufferCapacity = 2

private fun testSharedFlowCapacity() {



    val sharedFlow = MutableSharedFlow<Int>(

        replay = 0,//相当于粘性数据

        extraBufferCapacity = 2,//接受的慢时候，发送的入栈

        onBufferOverflow = BufferOverflow.SUSPEND

    )

    lifecycleScope.launch {

        launch {



            sharedFlow.collect {

                println("collect1 received ago shared flow $it")



            }

        }

        launch {

            (1..5).forEach {

                println("emit1  send ago  flow $it")

                sharedFlow.emit(it)

                println("emit1 send after flow $it")

            }

        }

        // wait a minute

        delay(100)

        launch {

            sharedFlow.collect {

                println("collect2 received shared flow $it")

            }

        }

    }



}

结果如下图：

优先发送将其缓存起来，testSharedFlow测试中发送与接收在没有干扰（延时之类的干扰）的情况下 是一条顺序链，而设置了extraBufferCapacity优先发送两条，不管消费情况，不设置的话（extraBufferCapacity = 0）这时如果在collect1里面设置延时delay（100），send会被阻塞（因为默认是 onBufferOverflow = BufferOverflow.SUSPEND的策略）

3.3、onBufferOverflow

onBufferOverflow：由背压就有处理策略，sharedflow默认为BufferOverflow.SUSPEND
，也即是如果当事件数量超过缓存，发送就会被挂起，上面提到了一句，DROP_OLDEST销毁最旧的值，DROP_LATEST销毁最新的值

三种参数含义

public enum class BufferOverflow {

    /**

     * 在缓冲区溢出时挂起。

     */

    SUSPEND,



    /**

     * 在缓冲区溢出时删除** *旧的**值，添加新的值到缓冲区，不挂起。

     */

    DROP_OLDEST,



    /**

     * 在缓冲区溢出时，删除当前添加到缓冲区的最新的**值\

*(使缓冲区内容保持不变)，不要挂起。

     */

    DROP_LATEST

}

eg:和testSharedFlowCapacity方法区别在于 多了个delay(100)

• SUSPEND模式

private fun testSharedFlow2() {



    val sharedFlow = MutableSharedFlow<Int>(

        replay = 0,//相当于粘性数据

        extraBufferCapacity = 2,//接受的慢时候，发送的入栈

        onBufferOverflow = BufferOverflow.SUSPEND

    )

    lifecycleScope.launch {

        launch {



            sharedFlow.collect {

                println("collect1 received ago shared flow $it")

                delay(100)

            }

        }

        launch {

            (1..5).forEach {

                println("emit1  send ago  flow $it")

                sharedFlow.emit(it)

                println("emit1 send after flow $it")

            }

        }

        // wait a minute

        delay(100)

        launch {

            sharedFlow.collect {

                println("collect2 received shared flow $it")

            }

        }

    }



}

SUSPEND情况下从第一张图知道collect1都收集了，第二张图发现collect2也打印了两次，为什么只有两次呢？

因为 extraBufferCapacity = 2,等于2，错过了两次的事件发送的接收，不信的话可以试一下extraBufferCapacity = 0，这时候肯定打印了4次，可能有人问为什么是4次呢，因为collect2的订阅者延时了100毫秒才开始订阅，

• DROP_LATEST模式

private fun testSharedFlow2() {



    val sharedFlow = MutableSharedFlow<Int>(

        replay = 0,//相当于粘性数据

        extraBufferCapacity = 2,//接受的慢时候，发送的入栈

        onBufferOverflow = BufferOverflow.DROP_LATEST



    )

    lifecycleScope.launch {

        launch {



            sharedFlow.collect {

                println("collect1 received ago shared flow $it")

                delay(100)

            }

        }

        launch {

            (1..5).forEach {

                println("emit1  send ago  flow $it")

                sharedFlow.emit(it)

                println("emit1 send after flow $it")

            }

        }

        // wait a minute

        delay(100)

        launch {

            sharedFlow.collect {

                println("collect2 received shared flow $it")

            }

        }

    }



}

发送过快的话，销毁最新的，只保留最老的两条事件，我们可以知道1，2，肯定保留其他丢失

要想不丢是怎么办呢，很简单不要产生背压现象就行，在emit中延时delay（200）,比收集耗时长就行。

• DROP_OLDEST模式
  该模式同理DROP_LATEST模式，保留最新的extraBufferCapacity = 2（多少）的数据就行。

四、StateFlow

初始化

val stateFlow = MutableStateFlow<Int>(value = -1)

由上图的继承关系可知stateFlow其实就是一种特殊的SharedFlow,它多了个初始值value

由上图可知：每次更新数据都会和旧数据做一次比较，只有不同时候才会更新数值。

SharedFlow和StateFlow的侧重点

• StateFlow就是一个replaySize=1的sharedFlow,同时它必须有一个初始值，此外，每次更新数据都会和旧数据做一次比较，只有不同时候才会更新数值。


• StateFlow重点在状态，ui永远有状态，所以StateFlow必须有初始值，同时对ui而言，过期的状态毫无意义，所以stateFLow永远更新最新的数据（和liveData相似），所以必须有粘滞度=1的粘滞事件，让ui状态保持到最新。另外在一个时间内发送多个事件，不会管中间事件有没有消费完成都会执行最新的一条.(中间值会丢失)


• SharedFlow侧重在事件，当某个事件触发，发送到队列之中，按照挂起或者非挂起、缓存策略等将事件发送到接受方，在具体使用时，SharedFlow更适合通知ui界面的一些事件，比如toast等，也适合作为viewModel和repository之间的桥梁用作数据的传输。

eg测试如下中间值丢失：

    private fun testSharedFlow2() {

        val stateFlow = MutableStateFlow<Int>(value = -1)



        lifecycleScope.launch {

            launch {



                stateFlow.collect {

                    println("collect1 received ago shared flow $it")

                }

            }

            launch {

                (1..5).forEach {

                    println("emit1  send ago  flow $it")

                    stateFlow.emit(it)

                    println("emit1 send after flow $it")

                }

            }

            // wait a minute

            delay(100)

            launch {

                stateFlow.collect {

                    println("collect2 received shared flow $it")

                }

            }

        }



    }

由下图可知，中间值丢失，collect2结果可知永远有状态

好了到这里文章就结束了，源码分析后续再写。

前言

协程通信三剑客：Channel、Select、Flow，上篇已经分析了Channel的深水区，本篇将会重点分析Select的使用及原理。
通过本篇文章，你将了解到：

1. Select 的引入
2. Select 的使用
3. Invoke函数 的妙用
4. Select 的原理
5. Select 注意事项

1. Select 的引入

多路数据的选择

串行执行

如今的二维码识别应用场景越来越广了，早期应用比较广泛的识别SDK如zxing、zbar，它们各有各的特点，也存在识别不出来的情况，为了将两者优势结合起来，我们想到的方法是同一份二维码图片分别给两者进行识别。
如下：

    //从zxing 获取二维码信息

    suspend fun getQrcodeInfoFromZxing(bitmap: Bitmap?): String {

        //模拟耗时

        delay(2000)

        return "I'm fish"

    }



    //从zbar 获取二维码信息

    suspend fun getQrcodeInfoFromZbar(bitmap: Bitmap?): String {

        delay(1000)

        return "I'm fish"

    }



    fun testSelect() {

        runBlocking {

            var bitmap = null

            var starTime = System.currentTimeMillis()

            var qrcoe1 = getQrcodeInfoFromZxing(bitmap)

            var qrcode2 = getQrcodeInfoFromZbar(bitmap)

            println("qrcode1=$qrcoe1 qrcode2=$qrcode2 useTime:${System.currentTimeMillis() - starTime} ms")

        }

    }

查看打印，最后花费的时间：

qrcode1=I'm fish qrcode2=I'm fish useTime:3013 ms

当然这是串行的方式效率比较低，我们想到了用协程来优化它。

协程并行执行

如下：

    fun testSelect1() {

        var bitmap = null;

        var starTime = System.currentTimeMillis()

        var deferredZxing = GlobalScope.async {

            getQrcodeInfoFromZxing(bitmap)

        }



        var deferredZbar = GlobalScope.async {

            getQrcodeInfoFromZbar(bitmap)

        }



        runBlocking {

            //挂起等待识别结果

            var qrcoe1 = deferredZxing.await()

            //挂起等待识别结果

            var qrcode2 = deferredZbar.await()

            println("qrcode1=$qrcoe1 qrcode2=$qrcode2 useTime:${System.currentTimeMillis() - starTime} ms")

        }

    }

查看打印，最后花费的时间：

qrcode1=I'm fish qrcode2=I'm fish useTime:2084 ms

可以看出，花费时间明显变少了。
与上个Demo 相比，虽然识别过程是放在协程里并行执行的，但是在等待识别结果却是串行的。我们引入两个识别库的初衷是哪个识别快就用哪个的结果，为了达成这个目的，传统的方式是：

同时监听并记录识别结果的返回。

同时监听多路结果

如下：

    fun testSelect2() {

        var bitmap = null;

        var starTime = System.currentTimeMillis()

        var deferredZxing = GlobalScope.async {

            getQrcodeInfoFromZxing(bitmap)

        }



        var deferredZbar = GlobalScope.async {

            getQrcodeInfoFromZbar(bitmap)

        }



        var isEnd = false

        var result: String? = null

        GlobalScope.launch {

            if (!isEnd) {

                //没有结束，则继续识别

                var resultTmp = deferredZxing.await()

                if (!isEnd) {

                    //识别没有结束，说明自己是第一个返回结果的

                    result = resultTmp

                    println("zxing recognize ok useTime:${System.currentTimeMillis() - starTime} ms")

                    //标记识别结束

                    isEnd = true

                }

            }

        }



        GlobalScope.launch {

            if (!isEnd) {

                var resultTmp = deferredZbar.await()

                if (!isEnd) {

                    //识别没有结束，说明自己是第一个返回结果的

                    result = resultTmp

                    println("zbar recognize ok useTime:${System.currentTimeMillis() - starTime} ms")

                    isEnd = true

                }

            }

        }



        //检测是否有结果返回

        runBlocking {

            while (!isEnd) {

                delay(1)

            }

            println("recognize result:$result")

        }

    }

通过检测isEnd 标记来判断是否有某个模块返回结果。
结果如下：

• zbar recognize ok useTime:1070 ms
• recognize result:I'm fish

由于模拟设定的zbar 解析速度快，因此每次都是采纳的是zbar的结果，所花费的时间大幅减少了，该结果符合预期。

Select 闪亮登场

虽说上个Demo结果符合预期，但是多了很多额外的代码、多引入了其它协程，并且需要子模块对标记进行赋值（对"isEnd"进行赋值），没有达到解耦的目的。我们希望子模块的任务是单一且闭环的，如果能在一个函数里统一检测结果的返回就好了。
Select 就是为了解决多路数据的选择而生的。
来看看它是怎么解决该问题的：

    fun testSelect3() {

        var bitmap = null;

        var starTime = System.currentTimeMillis()

        var deferredZxing = GlobalScope.async {

            getQrcodeInfoFromZxing(bitmap)

        }

        var deferredZbar = GlobalScope.async {

            getQrcodeInfoFromZbar(bitmap)

        }

        runBlocking {

            //通过select 监听zxing、zbar 结果返回

            var result = select<String> {

                //监听zxing

                deferredZxing.onAwait {value->

                    //value 为deferredZxing 识别的结果

                    "zxing result $value"

                }



                //监听zbar

                deferredZbar.onAwait { value->

                    "zbar result $value"

                }

            }



            //运行到此，说明已经有结果返回

            println("result from $result useTime:${System.currentTimeMillis() - starTime}")

        }

    }

结果如下：

result from zbar result I'm fish useTime:1079

符合预期，同时可以看出：相比上个Demo，这样写简洁了许多。

2. Select 的使用

除了可以监听async的结果，Select 还可以监听Channel的发送方/接收方 数据，我们以监听接收方数据为例：

    fun testSelect4() {

        runBlocking {

            var bitmap = null;

            var starTime = System.currentTimeMillis()

            var receiveChannelZxing = produce {

                //生产数据

                var result = getQrcodeInfoFromZxing(bitmap)

                //发送数据

                send(result)

            }



            var receiveChannelZbar = produce {

                var result = getQrcodeInfoFromZbar(bitmap)

                send(result)

            }



            var result = select<String> {

                //监听是否有数据发送过来

                receiveChannelZxing.onReceive {

                    value->"zxing result $value"

                }



                receiveChannelZbar.onReceive {

                        value->"zbar result $value"

                }

            }



            println("result from $result useTime:${System.currentTimeMillis() - starTime}")

        }

    }

结果如下：

result from zbar result I'm fish useTime:1028

不论是async还是Channel，Select 都可以监听它们的数据，从而形成多路复用的效果。

在监听协程里调用select 表达式，表达式{}内声明需要监听的协程的数据，对于select 来说有两种场景：

1. 没有数据，则select 挂起协程并等待直到其它协程数据准备完成后再次恢复select 所在的协程。
2. 有数据，则select 正常执行并返回获取的数据。

3. Invoke函数 的妙用

在分析Select 原理之前，需要弄明白invoke函数的原理。
对于Kotlin 类来说，都可以重写其invoke函数。

    operator fun invoke():String {

        return "I'm fish"

    }

如上，重写了SelectDemo里的invoke函数，和普通成员函数一样，我们可以通过对象调用它。

fun main(args: Array<String>) {

    var selectDemo = SelectDemo()

    var result = selectDemo.invoke()

    println("result：$result")

}

当然，可以进一步简化：

fun main(args: Array<String>) {

    var selectDemo = SelectDemo()

    var result = selectDemo()

    println("result：$result")

}

这里涉及到了kotlin的语法糖：对象居然可以像函数一样调用。
作为函数，invoke 当然也可以接收高阶函数作为参数：

    operator fun invoke(block: (Int) -> String): String {

        return block(3)

    }



fun main(args: Array<String>) {

    var selectDemo = SelectDemo()

    var result = selectDemo { age ->

        when (age) {

            3 -> "I'm fish3"

            4 -> "I'm fish4"

            else -> "error"

        }

    }

    println("result：$result")

}

因此，当看到对象作为函数调用时，实际上调用的是invoke函数，具体的逻辑需要查看其invoke函数的实现。

4. Select 的原理

上篇分析过Channel，因此本篇趁热打铁，通过Select 监听Channel数据的变化来分析其原理，为方便讲解，我们先以监听一个Channel的为例。
先从select 表达式本身入手。

    fun testSelect5() {

        runBlocking {

            var starTime = System.currentTimeMillis()

            var receiveChannelZxing = produce {

                //发送数据

                send("I'm fish")

            }



            //确保channel 数据已经send

            delay(1000)

            var result = select<String> {

                //监听是否有数据发送过来

                receiveChannelZxing.onReceive { value ->

                    "zxing result $value"

                }

            }

            println("result from $result useTime:${System.currentTimeMillis() - starTime}")

        }

    }

select 是挂起函数，因此协程运行到此有可能被挂起。

#Select.kt

public suspend inline fun <R> select(crossinline builder: SelectBuilder<R>.() -> Unit): R {

    //...

    return suspendCoroutineUninterceptedOrReturn { uCont ->

        //传入父协程体

        val scope = SelectBuilderImpl(uCont)

        try {

            //执行builder

            builder(scope)

        } catch (e: Throwable) {

            scope.handleBuilderException(e)

        }

        //通过返回值判断是否需要挂起协程

        scope.getResult()

    }

}

重点看builder(scope)，builder 是高阶函数，实际上就是执行了select花括号里的内容，而它里面就是监听数据是否返回。

receiveChannelZxing.onReceive
刚开始看的时候势必以为onReceive是个函数，然而它是ReceiveChannel 里的成员变量：

#Channel.kt

    public val onReceive: SelectClause1<E>

通过上一节的分析可知，关键是要找到SelectClause1 的invoke的实现。

#Select.kt

public interface SelectBuilder<in R> {

    //block 有个入参

    //声明了SelectClause1的扩展函数invoke

    public operator fun <Q> SelectClause1<Q>.invoke(block: suspend (Q) -> R)

}



override fun <Q> SelectClause1<Q>.invoke(block: suspend (Q) -> R) {

    //SelectBuilderImpl 实现了 SelectClause1 的invoke函数

    registerSelectClause1(this@SelectBuilderImpl, block)

}

再看onReceive 的赋值：

#AbstractChannel.kt

final override val onReceive: SelectClause1<E>

    get() = object : SelectClause1<E> {

        @Suppress("UNCHECKED_CAST")

        override fun <R> registerSelectClause1(select: SelectInstance<R>, block: suspend (E) -> R) {

            registerSelectReceiveMode(select, RECEIVE_THROWS_ON_CLOSE, block as suspend (Any?) -> R)

        }

    }

因此，简单总结调用栈如下：

当调用receiveChannelZxing.onReceive{}，实际上调用了SelectClause1.invoke()，而它里面又调用了SelectClause1.registerSelectClause1()，最终调用了AbstractChannel.registerSelectReceiveMode。

AbstractChannel. registerSelectReceiveMode

#AbstractChannel.kt

private fun <R> registerSelectReceiveMode(select: SelectInstance<R>, receiveMode: Int, block: suspend (Any?) -> R) {

    while (true) {

        //如果已经有结果了，则直接返回------->①

        if (select.isSelected) return

        if (isEmptyImpl) {

            //没有发送者在等待，则入队等待，并返回 ------->②

            if (enqueueReceiveSelect(select, block, receiveMode)) return

        } else {

            //直接取出值------->③

            val pollResult = pollSelectInternal(select)

            when {

                pollResult === ALREADY_SELECTED -> return

                pollResult === POLL_FAILED -> {} // retry

                pollResult === RETRY_ATOMIC -> {} // retry

                //调用block------->④

                else -> block.tryStartBlockUnintercepted(select, receiveMode, pollResult)

            }

        }

    }

}

分为4个点，接着来一一分析。
①
select 同时监听多个值，若是有1个符合要求的数据返回了，那么该isSelected 标记为true，当检测到该标记为true时直接退出。
结合之前的Demo，zbar 已经识别出结果了，当select 检测zxing的结果时直接返回。

②

#AbstractChannel.kt

private fun <R> enqueueReceiveSelect(

    select: SelectInstance<R>,

    block: suspend (Any?) -> R,

    receiveMode: Int

): Boolean {

    //构造为Node元素

    val node = AbstractChannel.ReceiveSelect(this, select, block, receiveMode)

    //添加到Channel队列里

    val result = enqueueReceive(node)

    if (result) select.disposeOnSelect(node)

    return result

当select 时，发现Channel里没有数据，说明Channel还没有开始send，因此构造了Node(ReceiveSelect)加入到Channel queue里。当send数据时，会查找queue里是否有接收者等待，若有则调用Node(ReceiveSelect.completeResumeReceive)：

#AbstractChannel.kt

        override fun completeResumeReceive(value: E) {

            block.startCoroutineCancellable(

                if (receiveMode == RECEIVE_RESULT) ChannelResult.success(value) else value,

                select.completion,

                resumeOnCancellationFun(value)

            )

        }

block 被调度执行，最后会恢复select 协程的执行。

③
取出数据，并尝试恢复send协程。

④
在③的基础上，拿到数据后，直接执行block（此时并没有切换线程进行调度）。

小结一下select 原理：

可以看出：

select 本身执行并不耗时，若最终没有数据返回则挂起等待，若是有数据返回则不会挂起协程。

我们从头再捋一下select 配合Channel 的原理：

虽然以Channel为例讲解了select 原理，实际上async等结合select 原理大致差不多，重点都是利用了协程的挂起/恢复做文章。

5. Select 注意事项

如果select有多个数据同时到达，select 默认会选择第一个数据，若想要随机选择数据，可做如下处理：

            var result = selectUnbiased<String> {

                //监听是否有数据发送过来

                receiveChannelZxing.onReceive { value ->

                    "zxing result $value"

                }

            }

想要知道select 还可以监听哪些数据，可查看该数据是否实现了SelectClauseX(X 表示0、1、2）。

以上即为Select 的原理及其使用，下篇将会进入协程的精华部分：Flow的运用，该部分内容较多，可能会分几篇分析，敬请期待。

本文基于Kotlin 1.5.3，文中完整Demo请点击

    本文分析示例代码如下：

launch(Dispatchers.Main) {

  flow {

    emit(1)

    emit(2)

  }.flowOn(Dispatchers.IO).collect {

    delay(1000)



    withContext(Dispatchers.IO) {

      Log.d("liduo", "$it")

    }



    Log.d("liduo", "$it")

  }

}

一.flowOn方法

    flowOn方法用于将上游的流切换到指定协程上下文的调度器中执行，同时不会把协程上下文暴露给下游的流，即flowOn方法中协程上下文的调度器不会对下游的流生效。如下面这段代码所示：

launch(Dispatchers.Main) {

  flow {

    emit(2) // 执行在IO线程池

  }.flowOn(Dispatchers.IO).map {

    it + 1 // 执行在Default线程池

  }.flowOn(Dispatchers.Default).collect {

    Log.d("liduo", "$it") //执行在主线程

  }

}

    接下来，分析一下flowOn方法，代码如下：

public fun <T> Flow<T>.flowOn(context: CoroutineContext): Flow<T> {

    // 检查当前协程没有执行结束

    checkFlowContext(context)

    return when {

        // 为空，则返回自身

        context == EmptyCoroutineContext -> this

        // 如果是可融合的Flow，则尝试融合操作，获取新的流

        this is FusibleFlow -> fuse(context = context)

        // 其他情况，包装成可融合的Flow

        else -> ChannelFlowOperatorImpl(this, context = context)

    }

}



// 确保Job不为空

private fun checkFlowContext(context: CoroutineContext) {

    require(context[Job] == null) {

        "Flow context cannot contain job in it. Had $context"

    }

}

    在flowOn方法中，首先会检查方法所在的协程是否执行结束。如果没有结束，则会执行判断语句，这里flowOn方法传入的上下文不是空上下文，且通过flow方法构建出的Flow对象也不是FusibleFlow类型的对象，因此这里会走到else分支，将上游flow方法创建的Flow对象和上下文包装成ChannelFlowOperatorImpl类型的对象。

1.ChannelFlowOperatorImpl类

    ChannelFlowOperatorImpl类继承自ChannelFlowOperator类，用于将上游的流包装成一个ChannelFlow对象，它的继承关系如下图所示：

    通过上图可以知道，ChannelFlowOperatorImpl类最终继承了ChannelFlow类，代码如下：

internal class ChannelFlowOperatorImpl<T>(

    flow: Flow<T>,

    context: CoroutineContext = EmptyCoroutineContext,

    capacity: Int = Channel.OPTIONAL_CHANNEL,

    onBufferOverflow: BufferOverflow = BufferOverflow.SUSPEND

) : ChannelFlowOperator<T, T>(flow, context, capacity, onBufferOverflow) {

    // 用于流融合时创建新的流

    override fun create(context: CoroutineContext, capacity: Int, onBufferOverflow: BufferOverflow): ChannelFlow<T> =

        ChannelFlowOperatorImpl(flow, context, capacity, onBufferOverflow)

    

    // 若当前的流不需要通过Channel即可实现正常工作时，会调用此方法

    override fun dropChannelOperators(): Flow<T>? = flow

    

    // 触发对下一级流进行收集

    override suspend fun flowCollect(collector: FlowCollector<T>) =

        flow.collect(collector)

}

二.collect方法

    在Kotlin协程：Flow基础原理中讲到，当执行collect方法时，内部会调用最后产生的Flow对象的collect方法，代码如下：

public suspend inline fun <T> Flow<T>.collect(crossinline action: suspend (value: T) -> Unit): Unit =

    collect(object : FlowCollector<T> {

        override suspend fun emit(value: T) = action(value)

    })

    这个最后产生的Flow对象就是ChannelFlowOperatorImpl类对象。

1.ChannelFlowOperator类的collect方法

    ChannelFlowOperatorImpl类没有重写collect方法，因此调用的是它的父类ChannelFlowOperator类的collect方法，代码如下：

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

    // OPTIONAL_CHANNEL为默认值，这里满足条件，之后会详细讲解

    if (capacity == Channel.OPTIONAL_CHANNEL) {

        // 获取当前协程的上下文

        val collectContext = coroutineContext

        // 计算新的上下文

        val newContext = collectContext + context

        // 如果前后上下文没有发生变化

        if (newContext == collectContext)

            // 直接触发对下一级流的收集

            return flowCollect(collector)

        // 如果上下文发生变化，但不需要切换线程

        if (newContext[ContinuationInterceptor] == collectContext[ContinuationInterceptor])

            // 切换协程上下文，调用flowCollect方法触发下一级流的收集

            return collectWithContextUndispatched(collector, newContext)

    }

    // 调用父类的collect方法

    super.collect(collector)

}



// 获取当前协程的上下文，该方法会被编译器处理

@SinceKotlin("1.3")

@Suppress("WRONG_MODIFIER_TARGET")

@InlineOnly

public suspend inline val coroutineContext: CoroutineContext

    get() {

        throw NotImplementedError("Implemented as intrinsic")

    }

    ChannelFlowOperator类的collect方法在设计上与协程的withContext方法设计思路是一致的：在方法内根据上下文的不同情况进行判断，在必要时才会切换线程去执行任务。

    通过flowOn方法创建的ChannelFlowOperatorImpl类对象，参数capacity为默认值OPTIONAL_CHANNEL。因此代码在执行时会进入到判断中，但因为我们指定了上下文为Dispatchers.IO，因此上下文发生了变化，同时拦截器也发生了变化，所以最后会调用ChannelFlowOperator类的父类的collect方法，也就是ChannelFlow类的collect方法。

2.ChannelFlow类的collect方法

    ChannelFlow类的代码如下：

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

    coroutineScope {

        collector.emitAll(produceImpl(this))

    }

    在ChannelFlow类的collect方法中，首先通过coroutineScope方法创建了一个作用域协程，接着调用了produceImpl方法，代码如下：

public open fun produceImpl(scope: CoroutineScope): ReceiveChannel<T> =

    scope.produce(context, produceCapacity, onBufferOverflow, start = CoroutineStart.ATOMIC, block = collectToFun)

    produceImpl方法内部调用了produce方法，并且传入了待执行的任务collectToFun。

    produce方法在Kotlin协程：协程的基础与使用中曾提到过，它是官方提供的启动协程的四个方法之一，另外三个方法为launch方法、async方法、actor方法。代码如下：

internal fun <E> CoroutineScope.produce(

    context: CoroutineContext = EmptyCoroutineContext,

    capacity: Int = 0,

    onBufferOverflow: BufferOverflow = BufferOverflow.SUSPEND,

    start: CoroutineStart = CoroutineStart.DEFAULT,

    onCompletion: CompletionHandler? = null,

    @BuilderInference block: suspend ProducerScope<E>.() -> Unit

): ReceiveChannel<E> {

    // 根据容量与溢出策略创建Channel对象

    val channel = Channel<E>(capacity, onBufferOverflow)

    // 计算新的上下文

    val newContext = newCoroutineContext(context)

    // 创建协程

    val coroutine = ProducerCoroutine(newContext, channel)

    // 监听完成事件

    if (onCompletion != null) coroutine.invokeOnCompletion(handler = onCompletion)

    // 启动协程

    coroutine.start(start, coroutine, block)

    return coroutine

}

    在produce方法内部，首先创建了一个Channel类型的对象，接着创建了类型为ProducerCoroutine的协程，并且传入Channel对象作为参数。最后，produce方法返回了一个ReceiveChannel接口指向的对象，当协程执行完毕后，会通过Channel对象将结果通过send方法发送出来。

    至此，可以知道flowOn方法的实现实际上是利用了协程拦截器的拦截功能。

    在这里之后，代码逻辑分成了两部分，一部分是block在ProducerCoroutine协程中的执行，另一部分是通过ReceiveChannel对象获取执行的结果。

3.flow方法中代码的执行

    在produceImpl方法中，调用了produce方法，并且传入了collectToFun对象，这个对象将会在produce方法创建的协程中执行，代码如下：

internal val collectToFun: suspend (ProducerScope<T>) -> Unit

    get() = { collectTo(it) }

    当调用collectToFun对象的invoke方法时，会触发collectTo方法的执行，该方法在ChannelFlowOperator类中被重写，代码如下：

protected override suspend fun collectTo(scope: ProducerScope<T>) =

    flowCollect(SendingCollector(scope))

    在collectTo方法中，首先将参数scope封装成SendingCollector类型的对象，接着调用了flowCollect方法，该方法在ChannelFlowOperatorImpl类中被重写，代码如下：

override suspend fun flowCollect(collector: FlowCollector<T>) =

    flow.collect(collector)

    ChannelFlowOperatorImpl类的flowCollect方法内部调用了flow对象的collect方法，这个flow对象就是最初通过flow方法构建的对象。根据Kotlin协程：Flow基础原理的分析，这个flow对象类型为SafeFlow，最后会通过collectSafely方法，触发flow方法中的block执行。代码如下：

private class SafeFlow<T>(private val block: suspend FlowCollector<T>.() -> Unit) : AbstractFlow<T>() {

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

        // 触发执行

        collector.block()

    }

}

    当flow方法在执行过程中需要向下游发出值时，会调用emit方法。根据上面flowCollect方法和collectTo方法可以知道，collectSafely方法的collector对象就是collectTo方法中创建的SendingCollector类型的对象，代码如下：

@InternalCoroutinesApi

public class SendingCollector<T>(

    private val channel: SendChannel<T>

) : FlowCollector<T> {

    // 通过Channel类对象发送值

    override suspend fun emit(value: T): Unit = channel.send(value)

}

    当调用SendingCollector类型的对象的emit方法时，会通过调用类型为Channel的对象的send方法，将值发送出去。

    接下来，将分析下游如何接收上游发出的值。

4.接收flow方法发出的值

    回到ChannelFlow类的collect方法，之前提到collect方法中调用produceImpl方法，开启了一个新的协程去执行任务，并且返回了一个ReceiveChannel接口指向的对象。代码如下：

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

    coroutineScope {

        collector.emitAll(produceImpl(this))

    }

    在调用完produceImpl方法后，接着调用了emitAll方法，将ReceiveChannel接口指向的对象作为emitAll方法的参数，代码如下：

public suspend fun <T> FlowCollector<T>.emitAll(channel: ReceiveChannel<T>): Unit =

    emitAllImpl(channel, consume = true)

    emitAll方法是FlowCollector接口的扩展方法，内部调用了emitAllImpl方法对参数channel进行封装，代码如下：

private suspend fun <T> FlowCollector<T>.emitAllImpl(channel: ReceiveChannel<T>, consume: Boolean) {

    // 用于保存异常

    var cause: Throwable? = null

    try {

        // 死循环

        while (true) {

            // 挂起，等待接收Channel结果或Channel关闭

            val result = run { channel.receiveOrClosed() }

            // 如果Channel关闭了

            if (result.isClosed) {

                // 如果有异常，则抛出

                result.closeCause?.let { throw it }

                // 没有异常，则跳出循环

                break

            }

            // 获取并发送值

            emit(result.value)

        }

    } catch (e: Throwable) {

        // 捕获到异常时抛出

        cause = e

        throw e

    } finally {

         // 执行结束关闭Channel

        if (consume) channel.cancelConsumed(cause)

    }

}

    emitAllImpl方法是FlowCollector接口的扩展方法，而这里的FlowCollector接口指向的对象，就是collect方法中创建的匿名对象，代码如下：

public suspend inline fun <T> Flow<T>.collect(crossinline action: suspend (value: T) -> Unit): Unit =

    collect(object : FlowCollector<T> {

        override suspend fun emit(value: T) = action(value)

    })

    在emitAllImpl方法中，当通过receiveOrClosed方法获取到上游发出的值时，会调用emit方法通知下游，这时就会触发collect方法中block的执行，最终实现值从流的上游传递到了下游。

三.flowOn方法与流的融合

    假设对一个流连续调用两次flowOn方法，那么流最终会在哪个flowOn方法指定的调度器中执行呢？代码如下：

launch(Dispatchers.Main) {

    flow {

        emit(2)

      // emit方法是在IO线程执行还是在主线程执行呢？  

    }.flowOn(Dispatchers.IO).flowOn(Dispatchers.Main).collect {

        Log.d("liduo", "$it")

    }

}

    答案是在IO线程执行，为什么呢？

    根据本篇上面的分析，当第一次调用flowOn方法时，上游的流会被包裹成ChannelFlowOperatorImpl对象，代码如下：

public fun <T> Flow<T>.flowOn(context: CoroutineContext): Flow<T> {

    // 检查当前协程没有执行结束

    checkFlowContext(context)

    return when {

        // 为空，则返回自身

        context == EmptyCoroutineContext -> this

        // 如果是可融合的Flow，则尝试融合操作，获取新的流

        this is FusibleFlow -> fuse(context = context)

        // 其他情况，包装成可融合的Flow

        else -> ChannelFlowOperatorImpl(this, context = context)

    }

}

    而当第二次调用flowOn方法时，由于此时上游的流——ChannelFlowOperatorImpl类型的对象，实现了FusibleFlow接口，因此，这里会触发流的融合，直接调用上游的流的fuse方法，并传入新的上下文。这里容量和溢出策略均为默认值。

    根据Kotlin协程：Flow的融合、Channel容量、溢出策略的分析，这里会调用ChannelFlow类的fuse方法。相关代码如下：

public override fun fuse(context: CoroutineContext, capacity: Int, onBufferOverflow: BufferOverflow): Flow<T> {

    ...

    

    // 计算融合后流的上下文

    // context为下游的上下文，this.context为上游的上下文 

    val newContext = context + this.context

    

    ...

}

    再根据之前在Kotlin协程：协程上下文与上下文元素中的分析，当两个上下文进行相加时，后一个上下文中的拦截器会覆盖前一个上下文中的拦截器。在上面的代码中，后一个上下文为上游的流的上下文，因此会优先使用上游的拦截器。代码如下：

public operator fun plus(other: CoroutineDispatcher): CoroutineDispatcher = other

四.总结

    粉线为使用时代码编写顺序，绿线为下游触发上游的调用顺序，红线为上游向下游发送值的调用顺序，蓝线为线程切换的位置。

    本文分析示例代码如下：

launch(Dispatchers.Main) {

    val task = flow {

        emit(2)

        emit(3)

    }.onEach {

        Log.d("liduo", "$it")

    }



    task.collect()

}

一.Flow的触发与消费

    在Kotlin协程：Flow基础原理的分析中，流的触发与消费都是同时进行的。每当调用collect方法时，会触发流的执行，并同时在collect方法中对流发出的值进行消费。

    而在协程中，其实还提供了分离流的触发与消费的操作——onEach方法。通过使用onEach方法，可以将原本在collect方法中的消费过程的移动到onEach方法中。这样在构建好一个Flow对象后，不会立刻去执行onEach方法，只有当调用collect方法时，才会真正的去触发流的执行。这样就实现了流的触发与消费的分离。

    接下来，将对onEach方法进行分析。

1.onEach方法

    onEach方法用于预先构建流的消费过程，只有在触发流的执行后，才会对流进行消费，代码如下：

public fun <T> Flow<T>.onEach(action: suspend (T) -> Unit): Flow<T> = transform { value ->

    action(value)

    return@transform emit(value)

}

    onEach方法是一个Flow接口的扩展方法，返回一个类型为Flow的对象。Flow方法内部通过transform方法实现。

2.transform方法

    transform方法是onEach方法的核心实现，代码如下：

public inline fun <T, R> Flow<T>.transform(

    @BuilderInference crossinline transform: suspend FlowCollector<R>.(value: T) -> Unit

): Flow<R> = flow { // 创建Flow对象

    collect { value -> // 触发collect

        return@collect transform(value)

    }

}

    transform方法也是Flow接口的扩展方法，同样会返回一个类型为Flow的对象。并且在transform方法内部，首先构建了一个类型为Flow的对象，并且在这个Flow对象的执行体内，调用上游的流的collect来触发消费过程，并通过调用参数transform来实现消费。这个collect方法是一个扩展方法，在Kotlin协程：Flow基础原理分析过，因此不再赘述。

    这就是onEach方法实现触发与消费分离的核心，它将对上游的流的消费过程包裹在了一个新的流内，只有当这个新的流或其下游的流被触发时，才会触发这个新的流自身的执行，从而实现对上游的流的消费。

    接下来分析一下流的消费过程。

3.collect方法

    collect方法用于触发流的消费，我们这里调用的collect方法，是一个无参数的方法，代码如下：

public suspend fun Flow<*>.collect(): Unit = collect(NopCollector)

    这里的无参数collect方法是Flow接口的扩展方法。在无参数collect方法中，调用了另一个有参数的collect方法，这个有参数的collect方法在Kotlin协程：Flow基础原理中提到过，就是Flow接口中定义的方法，并且传入了NopCollecor对象，代码如下：

internal object NopCollector : FlowCollector<Any?> {

    override suspend fun emit(value: Any?) {

        // 什么都不做

    }

}

    NopCollecor是一个单例类，它实现了FlowCollector接口，但是emit方法为空实现。

    因此，这里会调用onEach方法返回的Flow对象的collect方法，这部分在Kotlin协程：Flow基础原理进行过分析，最后会触发flow方法中的block参数的执行。而这个Flow对象就是transform方法返回的Flow对象。代码如下：

public inline fun <T, R> Flow<T>.transform(

    @BuilderInference crossinline transform: suspend FlowCollector<R>.(value: T) -> Unit

): Flow<R> = flow { // 创建Flow对象

    collect { value -> // 触发collect

        return@collect transform(value)

    }

}

    通过上面的transform方法可以知道，在触发flow方法中的block参数执行后，会调用collect方法。上面提到transform方法是Flow接口的扩展方法，因此这里有会继续调用上游Flow对象的collect方法。这个过程与刚才分析的类似，这里调用的上游的Flow对象，就是我们在示例代码中通过flow方法构建的Flow对象。

    此时，会触发上游flow方法中block参数的执行，并在执行过程中，通过emit方法将值发送到下游。

    接下来，在transform方法中，collect方法的block参数会被会被回调执行，处理上游发送的值。这里又会继续调用transform方法中参数的执行，这部分逻辑在onEach方法中，代码如下：

public fun <T> Flow<T>.onEach(action: suspend (T) -> Unit): Flow<T> = transform { value ->

    action(value)

    return@transform emit(value)

}

    这里会调用参数action的执行，流在这里最终被消费。同时，onEach方法会继续调用emit方法，将上游返回的值再原封不动的传递到下游，交由下游的流处理。

二.多消费过程的执行

    首先看下面这段代码：

launch(Dispatchers.Main) {

    val task = flow {

        emit(2)

        emit(3)

    }.onEach {

        Log.d("liduo1", "$it")

    }.onEach {

        Log.d("liduo2", "$it")

    }



    task.collect()

}

    根据上面的分析，两个onEach方法会按顺序依次执行，打印出liduo1：2、liduo2：2、liduo1：3、liduo2：3。就是因为onEach方法会将上游的值继续向下游发送。

    同样的，还有下面这段代码：

launch(Dispatchers.Main) {

    val task = flow {

        emit(2)

        emit(3)

    }.onEach {

        Log.d("liduo1", "$it")

    }



    task.collect {

        Log.d("liduo2", "$it")

    }

}

    这段代码也会打印出liduo1：2、liduo2：2、liduo1：3、liduo2：3。虽然使用了onEach方法，但也可以调用有参数的collect方法来对上游发送的数据进行最终的处理。

三.总结

    粉线为代码编写顺序，绿线为下游触发上游的调用顺序，红线为上游向下游发送值的调用顺序，蓝线为onEach方法实现的核心。