Lambda

这个估计算是一个非常有历史感的话题了，Lambda相关的文章，也有很多了，为啥还要拿出来炒炒冷饭呢？主要是最近有对Lambda的内容进行字节码处理，同时Lambda在java/kotlin/android中，都有着不一样是实现，非常有趣，因此本文算是一个记录，让我们一起去走进lambda的世界吧。当然，本文以java/kotlin视角去记录，在android中lambda的处理还不一样，我们先挖个坑，看看有没有机会填上，当然，部分的我也会夹杂的一起说！

最简单的例子

比如我们常常在写ui的时候，设置一个监听器，就是这么处理

view.setOnClickListener(v -> {

    Log.e("hello","123");

});

编译后的字节码

 INVOKEDYNAMIC onClick()Landroid/view/View$OnClickListener; [

      // handle kind 0x6 : INVOKESTATIC

      java/lang/invoke/LambdaMetafactory.metafactory(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;

      // arguments:

      (Landroid/view/View;)V, 

      // handle kind 0x6 : INVOKESTATIC

      这里就是我们要的方法

      类名.lambda$myFunc$0(Landroid/view/View;)V, 

      (Landroid/view/View;)V

emmm，密密麻麻，我们先不管这个，这里主要是INVOKEDYNAMIC的这个指令，这里我就不再重复INVOKEDYNAMIC的由来之类的了，我们直接来看，INVOKEDYNAMIC指令执行后的产物是啥？

生成产物类

首先产物之一，肯定是setOnClickListener里面需要的一个实现OnClickListener的对象对吧！我们都知道INVOKEVIRTUAL会在操作数栈的执行一个消耗“对象”的操作，这个从哪里来，其实也很明显，就是从INVOKEDYNAMIC执行后被放入操作数栈的。

当然，这个生成的类还是比较难找的，可以通过以下明=命令去翻翻

java -Djdk.internal.lambda.dumpProxyClasses 类路径

当然，在AS中也有相关的生成类，在intermediates/transform目录下，不过高版本的我找不到在哪了，如果知道的朋友也可以告诉一下

调用特定方法

我们的产物类有了，但是我们也知道，lambda不是生成一个对象那么简单，而是要调用到里面的闭包方法，比如我们本例子就是

v -> {

    Log.e("hello","123");

}

那么我们这个产物的方法在哪呢？
回到INVOKEDYNAMIC指令的里面，我们看到

      java/lang/invoke/LambdaMetafactory.metafactory(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;

      // arguments:

      (Landroid/view/View;)V, 

      // handle kind 0x6 : INVOKESTATIC

      类名.lambda$myFunc$0(Landroid/view/View;)V, 

      (Landroid/view/View;)V

    ]

INVOKEVIRTUAL android/view/View.setOnClickListener (Landroid/view/View$OnClickListener;)V

这里有很多新的东西，比如LambdaMetafactory（java创建运行时类），MethodHandles等，相关概念我不赘述啦！因为有比我写的更好的文章，大家可以观看一下噢！
ASM对匿名内部类、Lambda及方法引用的Hook研究

我这里特地拿出来

INVOKESTATIC 类名.lambda$myFunc$0(Landroid/view/View;)V

这里会在生成的产物类中，直接通过INVOKESTATIC方式（当然，这里只针对我们这个例子，后面会继续有说明，不一定是通过INVOKESTATIC方式）方法是lambda$myFunc$myFunc0，我们找下这个方法，可以看到，还真的有，如下

 private static synthetic lambda$myFunc$0(Landroid/view/View;)V

   L0

    LINENUMBER 14 L0

    LDC "hello"

    LDC "123"

    INVOKESTATIC android/util/Log.e (Ljava/lang/String;Ljava/lang/String;)I

    POP



}

这个方法就是lambda要执行的方法，只不过在字节码中包装了一层。

至此，我们就能够大概明白了，lambda究竟干了些什么

java lambda vs Koltin lambda

java lambda

我们刚刚有提到，生成的产物方法不一定通过INVOKESTATIC的方式调用，这也间接说明了，我们的lambda的包装方法，不一定是static，即不一定是静态的。

我们再来一文，

Lambda 设计参考

简单来说，java lambda按照情况，生成的方法也不同，比如当前我们的例子，它其实是一个无状态的lambda，即当前块作用域内，就能捕获到所需要的参数，所以就能直接生成一个static的方法

这里我们特地说明了块作用域，比如，下面的方法，setOnClickListener里面的lambda也依赖了一个变量a，但是他们都属于同一个块级别（函数内），

void myFunc(View view){

    int a = 1;

    view.setOnClickListener(v -> {

        Log.e("hello","123" +a );

    });

}

生成依旧是一个static方法

 private static synthetic lambda$myFunc$0(ILandroid/view/View;)V

   L0

    LINENUMBER 15 L0

    LDC "hello"

    NEW java/lang/StringBuilder

    DUP

    INVOKESPECIAL java/lang/StringBuilder.<init> ()V

    LDC "123"

    INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;

    ILOAD 0

    INVOKEVIRTUAL java/lang/StringBuilder.append (I)Ljava/lang/StringBuilder;

    INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;

    INVOKESTATIC android/util/Log.e (Ljava/lang/String;Ljava/lang/String;)I

    POP



}

但是，如果我们依赖当前类的一个变量，比如

类属性

public String s;



void myFunc(View view){

   

    view.setOnClickListener(v -> {

        Log.e("hello","123" +s);

    });

}

此时就生成一个当前类的实例方法，在当前类可以调用到该方法

  private synthetic lambda$myFunc$0(Landroid/view/View;)V

   L0

    LINENUMBER 15 L0

    LDC "hello"

    NEW java/lang/StringBuilder

    DUP

    INVOKESPECIAL java/lang/StringBuilder.<init> ()V

    LDC "123"

    INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;

    ALOAD 0

    GETFIELD com/example/suanfa/TestCals.s : Ljava/lang/String;

    INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;

    INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;

    INVOKESTATIC android/util/Log.e (Ljava/lang/String;Ljava/lang/String;)I

    POP

}

同时我们也看到，这种方式会引入ALOAD 0，即this指针被捕获，因此，假如外层类与lambda生命周期不同步，就会导致内存泄漏的问题，这点需要注意噢！！同时我们也要注意，并不是所有lambda都会，像上面我们介绍的lambda就不会！

kotlin lambda

这里特地拿kotlin 出来，是因为它有与java层不一样的点，比如同样的代码，lambda依赖了外部类的属性，生成的方法还是一个静态的方法，而不是实例方法

var s: String = 123

fun test(view:View){

    view.setOnClickListener {

        Log.e("hello","$s")

    }

}

字节码如下

不一样的点，选择多一个外部类的参数

private final static test$lambda-0(Lcom/example/suanfa/TestKotlin;Landroid/view/View;)V

   L0

    ALOAD 0

    LDC "this$0"

    INVOKESTATIC kotlin/jvm/internal/Intrinsics.checkNotNullParameter (Ljava/lang/Object;Ljava/lang/String;)V

   L1

    LINENUMBER 11 L1

    LDC "hello"

    ALOAD 0

    GETFIELD com/example/suanfa/TestKotlin.s : Ljava/lang/String;

    INVOKESTATIC java/lang/String.valueOf (Ljava/lang/Object;)Ljava/lang/String;

    INVOKESTATIC android/util/Log.e (Ljava/lang/String;Ljava/lang/String;)I

    POP

   L2

    LINENUMBER 12 L2

    RETURN

   L3

    LOCALVARIABLE this$0 Lcom/example/suanfa/TestKotlin; L0 L3 0

    LOCALVARIABLE it Landroid/view/View; L0 L3 1

    MAXSTACK = 2

    MAXLOCALS = 2

}

同样的，同一块作用域的，也当然是静态方法

fun test(view:View){

    val s = "123"

    view.setOnClickListener {

        Log.e("hello","$s")

    }

}

如下，比起依赖了外部类的属性，没有依赖的话，自然也不用把外部类对象当作参数传入

  private final static test$lambda-0(Ljava/lang/String;Landroid/view/View;)V

   L0

    ALOAD 0

    LDC "$s"

    INVOKESTATIC kotlin/jvm/internal/Intrinsics.checkNotNullParameter (Ljava/lang/Object;Ljava/lang/String;)V

   L1

    LINENUMBER 11 L1

    LDC "hello"

    ALOAD 0

    INVOKESTATIC java/lang/String.valueOf (Ljava/lang/Object;)Ljava/lang/String;

    INVOKESTATIC android/util/Log.e (Ljava/lang/String;Ljava/lang/String;)I

    POP

   L2

    LINENUMBER 12 L2

    RETURN

   L3

    LOCALVARIABLE $s Ljava/lang/String; L0 L3 0

    LOCALVARIABLE it Landroid/view/View; L0 L3 1

    MAXSTACK = 2

    MAXLOCALS = 2

}

因此，我们可以通过这两个差异，可以做一些特定的字节码逻辑。

总结

lambda的水还是挺深的，我们可以通过本文，去初步了解一些lambda的知识，同时我们也需要注意，在android中，也为了兼容lambda，做了一定的骚操作，比如我们常说的d8会对desuger做了一些操作等等。同时android的生成产物类，也会做单例的优化，这在一些场景会有不一样的坑，我们之后再见啦！

下面是正文。

最近考研出成绩了，大家考得怎么样？分享一个自己考研失败后，入职国企的故事。

1、考研失败

我是工作了3年后才参加考研的。

老家成都，本科毕业于帝都某所以能歌善舞著称的985学校，哲学专业。

大学选专业时家里人不懂，自己全凭爱好，第一志愿就是哲学。上学时有多快乐，毕业时就多难找工作。

侥幸自己选修过大数据课程，并且听说程序员工资还不错，通过校招加入了隔壁省的一家制造业当程序员。

公司管吃管住，工资1w出头，干了2年，感觉到了危机。自己羞于靠关系上位，但技术上，计算机知识太薄弱也发展有限，于是就想趁着还年轻，考个计算机硕士，提升一下自己。

在工作的第3年决定考研，边工作边考研，压力真是不小。让本来就是学渣的我，从研究生考场走出来就知道了最终的结果：没戏了。

成绩出来后，果然不出所料。

2、加入国企

知道初试成绩以后我难过了几天，认真思考了一下自己的未来发展：旁边的帝都我也回不去了，又不甘心留在这个小城市，于是决定回老家成都发展。

毕业后一直在私企，总是听说国企好、央企不错，所以我这次投简历也想试一下。正好看到一篇讲程序员国企的文章：值得程序员加入的173家国企汇总，网友：这下彻底躺平了，于是就按照文中的思路，找到了成都的一些所谓不错的国企投递试试。

成功加入后发现：真香！

• 
  

  福利真 ** 好！和其它公司谈薪酬，别人都是能压多低压多低，来这家国企，竟然还说我工作年限够长，在我期望的基础上加了3k。六险二金更不用说，平时的各种生活保障也是非常到位。不夸张的说，从私企转到国企的我，有一种刘姥姥进大观园的感觉。

  
  


• 
  

  真卷！**是谁告诉我国企适合养老的？**这比我以前在私企工作强度大多了好嘛？而且我第一次听说部门平均加班时长影响个人绩效这种规则。

  
  


• 
  

  技术上不激进。可能对于程序员来说，不停的学习新技术是一种常态，但是在这家国企，基本都是传统老技术，我打开代码还看到了我们领导1997年写的头文件。当然，你也可以认为这是一种不好的事。这里的技术对我来说，够了。

  
  


• 
  

  同事关系很融洽。我人生中第一次去按摩店找技师，是女同事带我去的，谁能信！不过必须说一句，成都的按摩店是真正规啊！技师可真有劲。

  
  

去年回来工作快1年了，我现在对于考研已经释怀了。听说我们部门今年招人开始硕士起步了，**有时候我还挺庆幸自己去年没考研成功的，**不然即使上了研究生，我这实力，也不一定能进入现在的单位了。

3、写在最后

现在回过头来看，有一个不同的体会：考研是一件好事，但如果本身不是沉迷于科研事业，而是更想赚钱的话，有好的工作机会也别错过。

另外，多关注有用的信息很重要，有时候别人的一番话，可能就需要自己经历几年的曲折才能总结出来。

大家有任何程序员求职问题，欢迎在评论区和我交流~

Flutter中包含大量的动画组件和自定义动画方式，所以，在合适的场景下选择合适的动画实现方式就成了决定代码质量好坏的一个重要因素。

动画选择决策树

Flutter中的动画从广义上来讲可以分为两类，一类是基于绘制的动画（Drawing-based animations），另一类是基于代码的动画（Code-based animations）。

下面这个决策树，是Flutter动画选择的总纲，这里梳理了不同的动画的作用场景和功能，我们来看下它具体的实现。

首先，我们需要区分是使用CustomPainter，或者是使用Lottie、Flare这种第三方库，这一类的动画很容易区分——如果你第一感觉，这个动画我做不了，那它大概率就是了。

接下来，就是区分是使用「显示动画」还是「隐式动画」。

简单的说，它们的区别如下：

• 隐式动画：不用循环播放、不用随时中断、不用多个动画协同，它实现的是一种状态到另一种状态的改变


• 显示动画：需要自己控制动画过程

最后，就是看现有组件是否满足需求，如果不行，那么就需要自定义相应的动画。

这就是整个动画决策树的执行过程。它们的开发难度，如下所示。

下面我们就具体来分析下不同的动画实现。本文首先介绍显示动画和隐式动画。

Implicit Animations——隐式动画

在Flutter中，很多常用组件都有其自带的隐式动画版本，例如下图所示的这些组件。

这些组件在Flutter中被称之为隐式动画Widget，下面以AnimatedContainer为例，来看下Implicit Animations的使用。

隐式动画有一个特点，那就是它们都是以「Animated」开头。

基本使用

AnimatedContainer的使用非常简单，甚至和普通的Container没有太大的区别，代码如下所示。

AnimatedContainer(

  margin: EdgeInsets.only(top: 20),

  width: size,

  height: size,

  decoration: BoxDecoration(

    color: color,

    borderRadius: BorderRadius.circular(radius),

  ),

  curve: Curves.easeIn,

  duration: Duration(milliseconds: 300),

),

当通过setState函数改变AnimatedContainer中的属性时，AnimatedContainer会经过一段动画效果，然后再完成相应的改变。在隐式动画中，你依然可以定义Curve和Duration等参数，但是你无法控制动画，即动画的执行和结束，是由属性改变来驱动的。

使用场景

Implicit Animations可以非常方便的使Widget具有动画效果而不需要写很多额外的动画代码，结合FutureBuilder或者StreamBuilder，甚至不用写setState，下面这个例子就演示了如何将Implicit Animations和FutureBuilder结合起来使用，代码如下所示。

FutureBuilder(

  future: future,

  builder: (context, snapshot) {

    var width = .0;

    switch (snapshot.connectionState) {

      case ConnectionState.none:

      case ConnectionState.waiting:

      case ConnectionState.active:

        width = .0;

        break;

      case ConnectionState.done:

        width = 100.0;

        break;

    }

    return AnimatedContainer(

      width: width,

      duration: Duration(seconds: 1),

      curve: Curves.easeIn,

      child: Image.asset('images/logo.png'),

    );

  },

),

通过FutureBuilder的各种状态回调，就可以设置不同的Widget，并在FutureBuilder完成并显示正常的Widget时，产生一个动画效果，而不是非常生硬的出现。

TweenAnimationBuilder

TweenAnimationBuilder是自定义隐式动画的方式，借助它，你可以给一个指定的Widget作用一个动画效果，一个简单的示例代码如下所示。

TweenAnimationBuilder(

  tween: Tween<double>(begin: 0, end: 48),

  onEnd: (){}

  duration: Duration(seconds: 1),

  builder: (BuildContext context, double size, Widget child) {

    return IconButton(

      iconSize: size,

      color: Colors.blue,

      icon: child,

    );

  },

  child: Icon(Icons.aspect_ratio),

)

借助TweenAnimationBuilder，就可以将一个指定的Tween作用于builder中的Widget，builder中的第二个参数，就是Tween所指定的参数的类型，通过TweenAnimationBuilder，就可以在Widget参数变化的时候产生动画效果。

TweenAnimationBuilder的builder中如果有不变的Child Widget，可以放在TweenAnimationBuilder的child属性中，因为builder在产生动画时会重建，所有不变的Widget，都可以放在TweenAnimationBuilder的child中，再通过builder的第三个参数来传递这个Widget，以避免重建。

通常我们在开发中，会借助Transform来完成动画效果，在builder中，根据Tween返回的数值，使用不同的Transform来修改动画状态。

TweenAnimationBuilder中的begin，只在第一次使用，后面更新时，只看end的值，例如10-30，修改end为50，实际变化是30-50。如果不传begin，那么默认和end相等。

Explicit Animations——显示动画

与隐式动画不同，显示动画给了开发者对动画过程的完全掌控，开发者可以根据自己的需要来控制动画，Flutter中内置了很多显示动画，如下所示。

显示动画也有一个很明显的特点，那就是它们都以「Transition」结尾。

基本使用

以RotationTransition为例，下面来演示下如何使用Flutter中的显示动画。

显示动画是通过AnimationController来进行驱动的，所以，使用显示动画的第一步，就是需要创建AnimationController。有了AnimationController之后，就可以通过控制AnimationController的状态来控制动画的驱动过程，整个代码如下所示。

AnimationController controller;



@override

void initState() {

  super.initState();

  controller = AnimationController(vsync: this, duration: Duration(seconds: 2))..repeat();

}



@override

void dispose() {

  controller.dispose();

  super.dispose();

}



@override

Widget build(BuildContext context) {

  return Center(

    child: GestureDetector(

      onTap: () {

        if (controller.isAnimating) {

          controller.stop();

        } else {

          controller.repeat();

        }

      },

      child: RotationTransition(

        turns: controller,

        child: FlutterLogo(

          size: 100,

        ),

      ),

    ),

  );

}

与隐式动画相比，显式动画通过AnimationController来获取动画的行进状态和参数，从而让调用者能够控制动画的行进过程。

显式动画可以实现隐式动画的所有功能，但是比隐式动画多了管理动画生命周期的工作

当Flutter内置显示动画不能满足开发者的需求时，Flutter提供了AnimatedBuilder和AnimatedWidget来让开发者对显示动画进行自定义。

AnimatedWidget

前面提到的都是Flutter中使用动画的最基本方式，但实际上，Flutter提供了很多关于动画的封装组件，可以让开发者更加方便的使用动画，这就是AnimatedWidget。AnimatedWidget也有很多实现类，如图所示。

AnimatedWidget是实现自定义显示动画的另一种方式，它可以将一些动画的逻辑以Widget的形式封装起来，从而让build函数中的代码逻辑更加清晰，下面是AnimatedWidget的示例代码。

@override

Widget build(BuildContext context) {

  return Stack(

    children: <Widget>[

      AnimWidget(animation: controller),

      Center(child: FlutterLogo(size: 100)),

    ],

  );

}



class AnimWidget extends AnimatedWidget {

  const AnimWidget({

    Key? key,

    required Animation<double> animation,

  }) : super(key: key, listenable: animation);



  @override

  Widget build(BuildContext context) {

    Animation<double> animation = listenable as Animation<double>;

    return Container(

      decoration: BoxDecoration(

        gradient: RadialGradient(

          colors: const [Colors.red, Colors.transparent],

          stops: [0, animation.value],

        ),

      ),

    );

  }

}

那么这种方式和之前直接使用AnimationController和Tween有什么区别呢？细心的读者可能已经发现了，AnimatedWidget不需要自己去监听动画的回调，也不需要通过setState来刷新动画，这些操作，AnimatedWidget已经封装好了，这就是AnimatedWidget的作用。

AnimatedBuilder

AnimatedBuilder是一个特殊的AnimatedWidget，它可以直接指定一个动画作用于Widget上，而不需要重新创建一个自定义的AnimatedWidget，它可以帮助开发者处理动画的监听，当一个Widget Tree中有一些需要动画的Widget，也有一些不需要动画的Widget时，用AnimatedBuilder可以很方便的避免非动画Widget的重绘，所以说，AnimatedBuilder可以更加方便的给一个Widget增加动画效果。

AnimatedBuilder与其它的显示动画一样，也是通过AnimationController驱动的，借助AnimatedBuilder，开发者可以根据需要，自己创建Animation并控制它，下面的代码演示了如何通过控制RadialGradient的stop属性来控制RadialGradient的显示大小，从而形成动画效果，代码如下所示。

@override

Widget build(BuildContext context) {

  return AnimatedBuilder(

    animation: controller,

    builder: (context, widget) {

      return Stack(

        children: <Widget>[

          Container(

            decoration: BoxDecoration(

              gradient: RadialGradient(

                colors: [Colors.red, Colors.transparent],

                stops: [0, controller.value],

              ),

            ),

          ),

          Center(child: FlutterLogo(size: 100))

        ],

      );

    },

  );

}

上面的代码演示了如何使用AnimatedBuilder，实际上非常简单，与使用内置的显示动画的过程基本一致。

在使用AnimatedBuilder的过程中，需要尽可能多的将需要动画的部分和不需要动画的部分区分开来，这样可以避免多余的重绘，从而提高动画性能，例如上面的代码，可以将FlutterLogo和Stack放置在最外层，这样只需要让RadialGradient产生动画就可以了，代码如下所示。

@override

Widget build(BuildContext context) {

  return Stack(

    children: <Widget>[

      AnimatedBuilder(

        animation: controller,

        builder: (context, widget) {

          return Container(

            decoration: BoxDecoration(

              gradient: RadialGradient(

                colors: [Colors.red, Colors.transparent],

                stops: [0, controller.value],

              ),

            ),

          );

        },

      ),

      Center(child: FlutterLogo(size: 100))

    ],

  );

}

AnimatedBuilder接收了一个animation，在child中，可以直接使用这个animation的值，其它都和普通的AnimatedWidget类似。

实际上，AnimatedBuilder就是AnimatedWidget的子类，所以在本质上，这两种实现自定义显示动画的方式想相同的，开发者可以根据自己的喜好来选择相应的方式来创建自己的显示动画。

AnimateWidget负责组件的抽离，可以看出组件中杂糅了动画逻辑。而AnimatedBuilder恰好相反,它不在意组件是什么，只是将动画抽离达到复用简单。

Flutter中的显示动画和隐式动画，几乎可以解决大部分我们平时在开发中遇到的动画场景，借助动画选择决策树，我们可以对动画的选择了如指掌，剩下的工作，就是对动画进行拆解，分而治之。

扫码功能都用过吧，打开扫码功能后都会有类似封面图的效果。其实就是一个自定义View的遮罩，话不多说，今天这篇我们就来讲解如何实现一个扫面框动效。

首先，我们先分析下动效的组成，有利于待会拆分实现：

1. 四周类似角标的白线


2. 角标框住的浅白色背景


3. 一条由上而下由快到慢移动的扫描线

一经分析，其实非常简单，整体效果就是由这几个简单的元素组成。接下来我们就创建一个ScanView继承自View来实现这个动效。（由于代码古老，这里使用Java）

public final class ScanView extends View {



private Paint paint, scanLinePaint,reactPaint;//三种画笔

private Rect frame;//整个区域



public ScanView(Context context) {

    this(context, null);

}



public ScanView(Context context, AttributeSet attrs) {

    this(context, attrs, 0);

}



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

    super(context, attrs, defStyleAttr);

    initPaint()

}



private void initPaint() {

    /*遮罩画笔*/

    paint = new Paint(Paint.ANTI_ALIAS_FLAG);

    paint.setColor(color);

    paint.setAlpha(CURRENT_POINT_OPACITY);

    paint.setStyle(Paint.Style.FILL);



    /*边框线画笔*/

    reactPaint = new Paint(Paint.ANTI_ALIAS_FLAG);

    reactPaint.setColor(reactColor);

    reactPaint.setStyle(Paint.Style.FILL);

    

    /*扫描线画笔*/

    scanLinePaint = new Paint(Paint.ANTI_ALIAS_FLAG);

    scanLinePaint.setStyle(Paint.Style.FILL);

    scanLinePaint.setDither(true);

    scanLinePaint.setColor(scanLineColor);

}

}

三种画笔初始化完成接下来就是使用画笔在画布上绘制效果图了，重写onDraw()方法

public void onDraw(Canvas canvas) {

   //绘制取景边框

   drawFrameBounds(canvas, frame);

   //绘制遮罩

   drawMaskView(canvas, frame);

   //绘制扫描线

   drawScanLight(canvas, frame);

}

再来分析，边框的四个角其实拆开来看，就是两条线组成，或者说是两个填充的矩形框垂直相交组成，那么四个角就可以按照这个思路完成，遮罩其实就是一个矩形框。

//绘制四个角，注意是外线而不是内线

private void drawFrameBounds(Canvas canvas, Rect frame) {

    // 左上角

    canvas.drawRect(frame.left - corWidth, frame.top, frame.left, frame.top + corLength, reactPaint);

    canvas.drawRect(frame.left - corWidth, frame.top - corWidth, frame.left + corLength, frame.top, reactPaint);

    // 右上角

    canvas.drawRect(frame.right, frame.top, frame.right + corWidth,frame.top + corLength, reactPaint);

    canvas.drawRect(frame.right - corLength, frame.top - corWidth, frame.right + corWidth, frame.top, reactPaint);

    // 左下角

    canvas.drawRect(frame.left - corWidth, frame.bottom - corLength,frame.left, frame.bottom, reactPaint);

    canvas.drawRect(frame.left - corWidth, frame.bottom, frame.left + corLength, frame.bottom + corWidth, reactPaint);

    // 右下角

    canvas.drawRect(frame.right, frame.bottom - corLength, frame.right + corWidth, frame.bottom, reactPaint);

    canvas.drawRect(frame.right - corLength, frame.bottom, frame.right  + corWidth, frame.bottom + corWidth, reactPaint);

}



//绘制遮罩

private void drawMaskView(Canvas canvas, Rect frame) {

     canvas.drawRect(frame.left, frame.top, frame.right, frame.bottom, paint);

}

到此，我们还剩最后一个扫描线的动画效果，这条线其实就是一张图片，首先需要将图片以Bitmap形式绘制在扫描区域内，然后通过ValueAnimator来控制图片Y坐标点，这样就能达到图片上下移动的效果，至于由快到慢的效果是添加了插值器，这里使用内置的DecelerateInterpolator，同学们可以根据自己想要的效果自己搭配。

if (valueAnimator == null) {

    valueAnimator = ValueAnimator.ofInt(frame.top, frame.bottom-10);//图片Y坐标取值范围

    valueAnimator.setDuration(3000);//单次动画时间3秒

    valueAnimator.setInterpolator(new DecelerateInterpolator());//由快到慢插值器

    valueAnimator.setRepeatMode(ValueAnimator.RESTART);//重复动画

    valueAnimator.setRepeatCount(ValueAnimator.INFINITE);//无限次数

    valueAnimator.addUpdateListener(new ValueAnimator.AnimatorUpdateListener() {

        @Override

        public void onAnimationUpdate(ValueAnimator animation) {

            scanLineTop = (int) animation.getAnimatedValue();//当前时刻获取的Y值

            invalidate();//刷新视图

        }

    });

    valueAnimator.start();

}

到此就可以实现封面的效果，甚至可以添加别的酷炫效果，只要你敢想敢做。

总结

其实一些动效看似很复杂，但通过认真分析，我们可以将其拆分成多个简单的小块，将每个小块实现后再逐个拼装，最后达到完整的效果。本节主要是通过自定义View实现，用到绘制矩形框（drawRect），属性动画（ValueAnimator），两者使用也是非常简单。另外需要注意动画的使用和释放，避免导致不必要的内存泄漏。

好了，以上便是本篇所有内容，希望对大家有所帮助！

当今移动应用开发，常常需要使用各种集合类型来存储和操作数据。Kotlin 提供了 Collection KTX 扩展库，为我们操作集合提供了非常方便的 API。在本篇文章中，我们将介绍 Collection KTX 中包含的所有扩展函数，让你的集合操作变得更加高效、简单、易读。

除了 Collection KTX，Kotlin 还提供了许多其他扩展库，例如 Android KTX、Coroutines、Serialization KTX 等，它们都可以大大简化我们的开发流程。在接下来的文章中，我们还将为您介绍这些扩展库的详细信息，让你的 Kotlin 开发之路更加畅通无阻

使用

dependencies {

    implementation "androidx.collection:collection-ktx:1.2.0"

}

用法合集

Collection 扩展函数

• filterNot()：过滤掉指定元素后的新 Collection。


• filterNotNull()：过滤掉 null 元素后的新 Collection。

List 扩展函数

• sorted()：按自然顺序排序后的新 List。


• sortedBy()：按指定方式排序后的新 List。


• sortedDescending()：按自然顺序降序排序后的新 List。


• sortedByDescending()：按指定方式降序排序后的新 List。


• distinct()：去重后的新 List。


• distinctBy()：按指定方式去重后的新 List。


• minus()：删除指定元素后的新 List。


• plus()：添加指定元素后的新 List。


• drop()：去掉前几个元素后的新 List。


• dropWhile()：去掉符合指定条件的元素后的新 List。


• take()：前几个元素组成的新 List。


• takeWhile()：符合指定条件的元素组成的新 List。


• partition()：按指定条件分隔后的 Pair。


• groupBy()：按指定方式分组后的 Map。


• associate()：按指定方式关联后的新 Map。


• associateBy()：按指定方式关联键后的新 Map。


• associateWith()：按指定方式关联值后的新 Map。


• zip()：按指定方式组合后的新 List。

MutableList 扩展函数

• removeLast()：移除最后一个元素，并返回该元素。


• removeFirst()：移除第一个元素，并返回该元素。


• move()：将指定元素移动到新位置。

Set 扩展函数

• minus()：删除指定元素后的新 Set。


• plus()：添加指定元素后的新 Set。


• partition()：按指定条件分隔后的 Pair。


• groupBy()：按指定方式分组后的 Map。


• associate()：按指定方式关联后的新 Map。


• associateBy()：按指定方式关联键后的新 Map。


• associateWith()：按指定方式关联值后的新 Map。

MutableSet 扩展函数

• remove()：移除指定元素，并返回是否移除成功。


• retainAll()：仅保留符合指定条件的元素。


• addAll()：添加指定元素后的新 MutableSet。

Map 扩展函数

• minus()：删除指定键对应的元素后的新 Map。


• plus()：添加指定键值对后的新 Map。


• partition()：按指定条件分隔后的 Pair。


• filterKeys()：按指定条件过滤键后的新 Map。


• filterValues()：按指定条件过滤值后的新 Map。


• mapKeys()：按指定方式映射键后的新 Map。


• mapValues(): 按指定方式映射值后的新map

MutableMap 扩展函数

• remove()：移除指定键对应的元素，并返回该元素。


• putAll()：添加指定键值对后的新 MutableMap。


• putIfAbsent()：仅在指定键不存在时添加指定键值对。


• compute()：更新指定键对应的元素，并返回更新后的值。


• computeIfAbsent()：仅在指定键不存在时更新该键对应的元素。


• computeIfPresent()：仅在指定键存在时更新该键对应的元素。

Iterable 扩展函数

• reduceOrNull()：对所有元素进行指定操作，如果为 null 则返回 null。


• reduceIndexedOrNull()：对所有元素进行指定操作，同时考虑元素的索引，如果为 null 则返回 null。


• foldOrNull()：对所有元素进行指定操作并给定初始值，如果为 null 则返回 null。


• foldIndexedOrNull()：对所有元素进行指定操作并给定初始值，同时考虑元素的索引，如果为 null 则返回 null。

ListIterator 扩展函数

• previousOrNull()：返回上一个元素，如果不存在则返回 null。

Sequence 扩展函数

• reduceOrNull()：对所有元素进行指定操作，如果为 null 则返回 null。


• reduceIndexedOrNull()：对所有元素进行指定操作，同时考虑元素的索引，如果为 null 则返回 null。


• foldOrNull()：对所有元素进行指定操作并给定初始值，如果为 null 则返回 null。


• foldIndexedOrNull()：对所有元素进行指定操作并给定初始值，同时考虑元素的索引，如果为 null 则返回 null。


• distinct()：去重后的新 Sequence。


• distinctBy()：按指定方式去重后的新 Sequence。


• filterNotNull()：过滤掉 null 元素后的新 Sequence。


• filterNot()：过滤掉指定元素后的新 Sequence。


• partition()：按指定条件分隔后的 Pair。


• sorted()：按自然顺序排序后的新 Sequence。


• sortedBy()：按指定方式排序后的新 Sequence。


• sortedDescending()：按自然顺序降序排序后的新 Sequence。


• sortedByDescending()：按指定方式降序排序后的新 Sequence。


• take()：前几个元素组成的新 Sequence。


• takeWhile()：符合指定条件的元素组成的新 Sequence。


• zip()：按指定方式组合后的新 Sequence

了解工具的尿性

工具的职责就是提高工作效率

1. 使用 Collection KTX 可以大大简化集合操作的代码，使代码更加简洁易读，同时可以提高代码的可维护性


2. 在使用集合时，应该尽可能使用 Kotlin 标准库中的函数和 Collection KTX 中的扩展函数，而不是手写循环或通过 Java API 进行操作，这可以减少代码量和提高代码可读性。


3. 了解不同的集合类型及其特性，选择合适的集合类型可以使代码更加高效。例如，如果需要频繁添加或删除元素，则应该使用可变集合类型。


4. 避免频繁进行集合类型的转换，因为这会导致性能降低。如果需要对集合进行不同的操作，可以考虑使用不同的集合类型来解决。


5. 尽量避免对空集合进行操作，因为这可能会导致空指针异常。在使用 Collection KTX 时，可以使用非空断言或者空安全操作符来处理可能为空的集合。

当然使用时也要注意，kotlin 的扩展函数让代码的可读性要求增高了少，所以用的使用为了能保证团队的统一，因该注意：

1. 对于代码中的扩展函数，应该在函数名称中体现其作用，以便其他开发者更容易理解代码。例如，“find”函数可以改名为“findFirstOrNull”或“findLastOrNull”。


2. 在使用 Collection KTX 时，应该注意性能问题。某些操作可能会导致性能下降，例如对大型集合进行循环和操作，因此应该考虑使用 Sequence 和 Flow 来提高性能。


3. 避免重复操作。使用 Collection KTX 可以使代码更加简洁和易读，但是不应该过度使用，如果某个操作已经通过一个函数实现了，就不要再手动写同样的操作。

22年10月，喜提二胎，同时儿子还不到两岁，工作中已经苦练写作基本功了，很难有心力在工作外写东西。

但作为一个技术从业者，定期写技术博客和总结规划，是确保高效工作的好习惯。工作已经十年了，越来越认可“选择比努力更重要”。

多数人都不喜欢思考，经常用战术上的勤奋掩饰自己战略上的懒惰，我也是如此，人生才如此被动。

本文不仅会分享自己在2022年所作出的重大人生选择及2023年的规划，还会在字里行间反思自己从高考后一些重大选择的得失。希望自己能以此洗心革面、痛改前非和开启新生，也希望能给有缘人在人生选择上有一些参考。

自我简介

本节主要是流水账的自我回顾，枯燥而乏味，建议读者有选择地看，或者跳过看后面的总结及规划哈~

从小爱学习

我出生于广西一个瑶族自治县的农村家庭，虽然家庭很不富裕，但童年回忆起来还是有很多快乐。但在青少年时期，父母吵闹较多，邻里关系不和，让看似阳光开朗的我，其实在内心已经种下了忧郁的种子，即使成年后，远离家乡，也时常会做相关的噩梦。‘

从小我就喜欢学习，记得小学一二年级，我经常6点多就到学校，有时周末也去学校，还被人笑话，但成绩只有数学还可以。直到四年级，我才开始获得奖状，印象中四至六年级的班主任，总是让我感觉自己很优秀，于是我的成绩真的变好了。

求学之路

初中，通过二婶大姐的帮助，把我安排到了县城最好中学的农村班，开始了住校的生活。初二开始，经常能考全班第一，全校前30。虽然中考不是很好，但还是考上了市里最好的高中。

从高二开始，成绩不时能考全班第一。高考虽然自我感觉发挥不好，但总分还是能排到全校应届第10，全广西一千六百多名。

由于家庭不富裕，高考后我优先考虑读军校，这样大学几年不会让家里负担过重。但因为各种原因，提前批我居然录取上。

于是我就来到了当时随手填的大学及专业，大一时发现可以选拔在校国防生，毕业后和军校生一样直接派到部队任职。于是大二时，我通过选拔加入了国防生队伍。

大学四年的成绩不是很好，因此没有资格保研。但我心中还是很想读研的，但因为国防生的身份，清华不允许报考，丧失了动力后自然考不上，这也成了后来我主动离开部队的原因之一。

军旅生涯

毕业后，我被分配到了北京军区某部的作战部队，在基层连队体验了一个多月后，就被派到南京某军校进行学习培训。军校培训期满后，我回到了北京的部队，开始了指挥军官的工作。

同多数国防生一样，我对基层部队的生活很不适应，被冻晕过几次，加上单位不同意我报考国防大学的研究生，我在13年底提出了复员转业申请。整体还算顺利，提出申请两个多月后，审批就通过了，然后我就离开了部队。

虽然从军入伍有减轻家庭负担的考虑，但离开部队后我还是会经常梦回连队，内心依然很向往部队的工作，也许还有壮志未酬，更有愧疚之情。即使不在部队了，我相信在国防建设上，还是有很多我可以参与的。

离开部队后，我全身心地投入了考研，因为计算机专业考公务员的岗位比较多，所以我选择了跨专业考清华的计算机专业。但没想到我专业课差得太多，只过了国家线，虽有一些院校联系我调剂，但我还是放弃了。

工作履历

然后，我就准备找C++相关的工作，通过大二时就认识的国防生朋友，内推到了一个做3G&4G 通信卡的外企gemalto，正式开启了程序员的生活。

由于做嵌入式操作系统的开发比较乏味，所以我们主动参与了一个小组的 Android 开发工作，学得差不多后，我们都先后离开了外企，他去了360做安卓开发，我去了搜狐做RN开发。

从搜狐开始，我从RN入门大前端，逐步掌握了react web开发、node 中间层或后端开发、vue web 开发、flutter 或 uni-app 跨端开发、PHP、Java、Go和Ruby后端开发。

从2017下半年开始，我的工作主要是管理团队和推进重点项目，团队最多时接近30人，职能上不仅管理过前端、安卓和iOS，也负责过设计团队。

疫情开始的半年多时间，尝试过在线教育创业，后来因为进展不符合预期和需要结婚生娃，在20年下半年入职了美团的前端基建团队。

回顾2022年

2022年初，因为老婆怀上了二胎，我终于做出了两个人生非常重要的选择：一是离开北京；二是从管理者向技术专家转变。

离京的选择

现在想想，有时选对城市，比选对行业或公司都重要。从2007年来到北京上大学，到2022年挥别北京，转眼间，我已经在北京度过了15个春秋。

离开北京时，我居然没有一丝伤感，仔细一想，15年来自己都没有真正考虑过要留在北京。虽然2007年时，就把户口迁到了北京。因为入伍地是北京，离开部队后，只要找到国企接收，也能把户口留在北京。但当时报考的是清华计算机深圳分院，索性就把户口迁回老家了。

21年12月底，父母都在北京，于是全家在北京过了年，但父亲还是不适应北京的气候，春节后就回老家了。而我亲弟在上海，老家只有我爸和爷爷，出了意外不能及时回到他们身边处理，加上老婆怀上了二胎，未来两个孩子的户口及上学问题，使得我不得不考虑离京的问题。

因为我所在的团队，在上海也有很多研发，有时我也需要去上海出差，加上我弟、堂妹、表姐和表弟等都在上海，所以当时优先考虑去上海，这样也不需要换部门或公司。

但由于年初上海的疫情比较严重且排外严重，同时上海离老家还是太远，看到公司在深圳也有岗位，聊了两个部门都有意向后，我选择了深圳，代价是需要换个部门，绩效和调薪都会受影响。选择深圳还有另外一个考虑，去上海的话，至少要缴满一年社保才能有户口，而深圳只需要缴满一个月即可。

三月底发起活水申请并逐步交接工作，四月中旬我就来到了深圳，五一后就把全家接到深圳安定了下来，6月初就办理好了全家的户口迁移。

当时在知乎上，反复看了深圳、上海、广州和北京的城市对比。对我来说，还是深圳最适合我。相比北京，深圳空气质量好很多，我老婆来了深圳后皮肤变好了很多，还有深圳的政务办事效率很高，日常生活很方便。

回想在北京时，早上我得六点前开车上班，否则不知道被五环堵到什么时候，下班时我得八点半前走，否则不知道什么时候可以离开望京。来到深圳后，我就住在公司附近，出门到工位不到10分钟就可以了，有了更多工作时间和关注生活。

回顾城市的选择，我真的很后悔没有早点来到深圳，若不是因为老婆执意要离开北京，因为22年初申请到了工作居住证，很有可能我下半年就在北京买房继续麻木地北漂了。

工作的选择

2022年，全世界所有的互联网公司都不好过，裁员消息层出不穷。作为一个即将35岁的大龄码农，我也是危机感满满，做好了随时被裁的心理建设。

对我来说，留在原部门原团队是最保险的，也是最好的：之前的工作以管理沟通为主，比较得心应手，领导们也比较认可，绩效和调薪也都有保障，同时负责的基本是中后台技术项目或前端基建项目，如组件库、物料管理、提效工具等，既有技术深度又有较好的工作节奏。

但因为原部门不能在深圳放团队，所以我只能通过活水到在深圳有岗位的团队，结合自己长远的职业规划，我选择了人工智能方向的前端团队。虽然团队只有十人上下，但可以做的事情却很有技术深度，同时团队的学历也比较好，60%都是硕士，还有一个是北大的硕士。

来到新团队后，我先加入近期很火的人工智能创作项目，使用 vite2 + vue3 从0开发了一个以图片处理为主要功能的web应用，经常加班赶项目进度，业余时间自学图形渲染。

然而，来到深圳不到半个月，就有一个前端伙伴要离职了，需要开发维护他从零开发的渲染引擎，工作难度比较大加上来深圳后因为燥热一直休息不好，我萌生了先辞职休息一段时间，再重新找工作的想法。

期间虽然没有好好准备面试，抱着了解招聘行情的心态，也和腾讯、字节、虾皮及一些传统行业的公司聊了聊，能拿到offer的基本是管理岗，传统行业一般是大前端总监，管理五十人以上团队，直接向CTO或CEO汇报。

虽然没有调薪，但领导们多次挽留，并给我争取了一些股票，特别是我的直接leader，相当nice，可以让我选择自己想做的事情，并允许我休个长假调整身心，所以我选择留了下来。

做出这个选择的考虑：一是管理岗可遇不可求，毕业后80%的工作都是管理，技术沉淀不够；二是web端的图形渲染和AI推理技术门槛高且非常有趣，并且近几年的人才缺口大，以后即使做管理，招不到人时，自己也得能搞定。

休假回来后：在业务支持上，我调整到了模型训练和管理相关的中后台项目，便于更好地掌握AI应用开发相关的知识技能；在研发提效上，我基于在前端基建团队的建设成果，修订了我们团队的前端工程规范和推进了项目的工程改造；在技术产出上，我主导了web推理引擎的立项，从零实现了 WebAssembly 计算方案，推进了在人脸验证和智能创作等项目的落地。

在新的团队，因为少了很多管理相关的会议，让我有了更多的机会和时间，结合项目需要，系统学习图形渲染和AI应用开发相关的知识技能。

过去的一年，因为两个孩子比较小需要更多精力放在家庭，同时也因为变换城市和岗位，还有新冠的影响，工作产出应该只达到了我预期的70%。但很幸运，让我遇见了一个很好的团队，有了领导的信任和优秀的伙伴们，相信新的一年，我一定会收获满满。

2023年规划

2023年，我首先要养成三一习惯：每周跑一十公里强体魄、每周看一好书启智慧、每周做一公益得快乐。

其次，在生活上，我要好好研究做饭和带娃。虽然我很想为公司的外卖业务贡献力量，但是对孩子们来说，能选择的很少，而且安全和营养都不好保证。生娃养娃容易，但教好孩子很不容易，童年的创伤，我相信一定可以在养育孩子的过程中治愈。同时，带娃也能帮助我理解一些人工智能相关的理论，现在感觉模型训练和教小孩真的很相似~

最后，在工作上：上半年，我要带领小伙伴们进一步完善Web推理引擎，同时提供一系列面向web应用研发同学的AI入门教程；下半年，我将从提升模型部署易用性出发，规划并建设一个全端的AI推理系统。

记得前一两年很多人都跟风面向单Activity开发，顾名思义，就是整个项目只有一个Activity。一个Activity里面装着N多个Fragment，再给Fragment加上转场动画，效果和多Activity跳转无异。其实想想还比较酷，以前还需要关注多个Acitivity之间的生命周期，现在只需关注一个，但还是需要对Fragment的生命周期进行关注。

其实早在六七年前GitHub上就有单Activity的开源库Fragmentation，后来谷歌也出了一个库Navigation。本来以为官方出品必为经典，当时跟着官方文档一步一步踩坑，最后还是放弃了该方案。理由大概如下：

1. 需要创建XML文件,配置导航关系和跳转参数等


2. 页面回退是重新创建，需要配合livedata使用


3. 貌似还会存在卡顿，一些栈内跳转处理等问题

而Github上Fragmentation库已经停止维护，所幸的是再lssuse中发现了一个基于它继续维护的SFragmentation，于是正是开启了面向单Activity的开发。

提供了可滑动返回的版本

dependencies {

	//请使用最新版本

	implementation 'com.github.weikaiyun.SFragmentation:fragmentation:latest'

	//滑动返回，可选

	implementation 'com.github.weikaiyun.SFragmentation:fragmentation_swipeback:latest'

}

由于是Fragment之间的跳转，我们需要将原有的Activity跳转动画在框架初始化时设置到该框架中

Fragmentation.builder() 

    //设置 栈视图 模式为 （默认）悬浮球模式  SHAKE: 摇一摇唤出  NONE：隐藏， 仅在Debug环境生效

    .stackViewMode(Fragmentation.BUBBLE)

    .debug(BuildConfig.DEBUG)

    .animation(

        R.anim.public_translate_right_to_center,  //进入动画

        R.anim.public_translate_center_to_left,  //隐藏动画

        R.anim.public_translate_left_to_center,  //重新出现时的动画

        R.anim.public_translate_center_to_right  //退出动画

    )

    .install()

因为只有一个Activity，所以需要在这个Activity中装载根Fragment

loadRootFragment(int containerId, SupportFragment toFragment)

但现在的APP几乎都是一个页面多个Tab组成的怎么办呢？

loadMultipleRootFragment(int containerId, int showPosition, SupportFragment... toFragments);

有了多个Fragment的显示，我们需要切换Tab实际也很简单

showHideFragment(ISupportFragment showFragment);

是不是使用起来很简单，首页我们解决了，关于跳转和返回、参数的接受和传递呢？

//启动目标fragment

start(SupportFragment fragment)

//带返回的启动方式

startForResult(SupportFragment fragment,int requestCode)

//接收返回参数

override fun onFragmentResult(requestCode: Int, resultCode: Int, data: Bundle?) {

    super.onFragmentResult(requestCode, resultCode, data)

}

//返回到上个页面，和activity的back（）类似

pop()

对于单Activity而言，我们其实也可以注册一个全局的Fragment监听，这样就能掌控当前的Fragmnet

supportFragmentManager.registerFragmentLifecycleCallbacks(

    object : FragmentManager.FragmentLifecycleCallbacks() {

        override fun onFragmentAttached(fm: FragmentManager, f: Fragment, context: Context) {

            super.onFragmentAttached(fm, f, context)

        }

        override fun onFragmentCreated(

            fm: FragmentManager,

            f: Fragment,

            savedInstanceState: Bundle?

        ) {

            super.onFragmentCreated(fm, f, savedInstanceState)

        }

        override fun onFragmentStarted(fm: FragmentManager, f: Fragment) {

            super.onFragmentStarted(fm, f)

        }

        override fun onFragmentResumed(fm: FragmentManager, f: Fragment) {

            super.onFragmentResumed(fm, f)

        }

        override fun onFragmentDestroyed(fm: FragmentManager, f: Fragment) {

            super.onFragmentDestroyed(fm, f)

        }

    },

    true

)

接下来我们看看Pad应用。对于手机应用来说，一般不会存在局部页面跳转的情况，但是Pad上是常规操作。

如图，点击左边列表的单个item，右边需要显示详情，这时候再点左边的其他item，此时的左边页面是保持不动的，但右边的详情页需要跳转对应的页面。使用过Pad的应该经常见到这种页面，比如Pad的系统设置等页面。这时只使用Activty应该是不能实现的，必须配合Fragment，左右分为两个Fragment。

但问题又出现了，这时候点击back怎么区分局部返回和整个页面返回呢？

//整个页面回退，主要是用于当前装载了Fragment的页面回退

_mActivity.pop()

//局部回退，被装载的Fragment之间回退

pop()

如下图，这样的页面我们又应该怎么装载呢？

可以分析，页面最外面是一个Activty,要实现单Activity其内部必装载了一个根Fragment。接着这个根Fragment中使用ViewPage和tablayout完成主页框架。当前tab页要满足右边详情页的单独跳转，还得将右边页面作为主页面，以此装载子Fragment才能实现。

总结

单Activity开发在手机和平板上使用都一样，但在平板上注意的地方更多，尤其是平板一个页面可能是多个页面组成，其局部还能单独跳转的功能，其中涉及到参数回传和栈的回退问题。使用下来，我还是觉得某些页面对硬件要求很高的使用单Activity会出现体验不好的情况，有可能是优化不到位。手机应用我还是使用多Activity方式，平板应用则使用该框架实现单Activity方式。

• 什么是结构化并发？


• 说好的异常传播为啥失效了？


• 怎么还有async不抛异常的问题？

1 结构化并发(Structured Concurrency)

1.1 java的"离散性并发"

kotlin 的Coroutine是【结构化并发】，与结构化并发对应的方式是【fire and forget 】姑且称之为【离散性并发】吧，可能不太准确。一个例子解释下离散性并发，java里我们开启一个线程之后，是不具备跟踪管理这个线程的能力的。如下

    public void javaThreadFun() {

        Thread thread = new Thread(new Runnable() {

            @Override

            public void run() {

                //do some work

            }

        });

        thread.setName("child-thread");

        thread.start();

    }

这个例子中,调用javaThreadFun（）方法所在的线程，创建并启动child-thread线程之后两个线程没有明确的父子关系，avaThreadFun（）方法所在的线程不能天然的感知在自己线程里启动的"子线程"，子线程发生异常之后也不会影响到自己。如果父线程要取消中止在自己线程里启动的那些线程也没有现成的方式去供使用。总之，层级关系管理上很离散。

1.2 kotlin 协程的的结构化并发

kotlin的协程天然的具备父协程管理取消子协程、子协程的异常失败影响父协程或者父协程感知子协程错误和失败的能力。如下示例

      GlobalScope.launch {

            val parentJob = launch {

                val childJob = launch {

                    delay(1_000)//子任务做一些事情

                    throw NullPointerException() //会导致父协程任务和兄弟协程任务都会被取消

                }

                delay(5_000)

            }

        }

• childJob失败抛出异常，会影响到父job，进而父job会取消掉其所有的子job。


• 另外，父job也会等待所有的子任务结束后自己才会结束。

与传统的相比

• 有跟踪：在协程左右域里启动协程会作为该协程的子协程，该协程会跟踪这些协程的状态。而不是像线程那些开启之后就忘记没有跟踪。父协程的结束也是要在所有子协程都完成之后自己才会完成，颇有家长负责制的感觉。


• 可取消：取消父协程也会，把其子协程一并取消掉。如上图，取消掉parent-job会导致从属于他的所有子协程取消。


• 能传播：这特性体现在，子协程发生异常，会通知其父协程，父协程会取消掉自己所有的子协程然后再向上传递直到根协程，或者supervisorJob.(这个下文我们会展开分析)

2 取消机制

2.1 父协程的取消会取消子协程

这一章节我们展开聊下Kotlin协程的取消机制，上一节我们提到，父协程/作用域的取消也会取消其子协程我们看个例子。

 GlobalScope.launch {

        val mParentJOb: Job = this.launch {

            val child1Job: Job = this.launch {

                this.launch {

                    delay(300)

                }.invokeOnCompletion { throwable ->

                    println("child1Job 执行完毕，收到了${throwable}")

                }

                val child2Job = this.launch {

                    delay(500)

                }.invokeOnCompletion { throwable ->

                    println("child2Job 执行完毕，收到了${throwable}")

                }

            }

            delay(100)

        }

        mParentJOb.invokeOnCompletion { throwable ->

            println("mParentJOb 执行完毕，收到了${throwable}")

        }

        println("发起取消 mParentJOb")

        mParentJOb.cancel()

    }.join()

运行结果：

发起取消 mParentJOb

child1Job 执行完毕，收到了kotlinx.coroutines.JobCancellationException: StandaloneCoroutine was cancelled; job=StandaloneCoroutine{Cancelling}@100b06de

child2Job 执行完毕，收到了kotlinx.coroutines.JobCancellationException: StandaloneCoroutine was cancelled; job=StandaloneCoroutine{Cancelling}@100b06de

mParentJOb 执行完毕，收到了kotlinx.coroutines.JobCancellationException: StandaloneCoroutine was cancelled; job=StandaloneCoroutine{Cancelled}@100b06de

2.2 兄弟协程取消不影响

private suspend fun brotherCoroutine() {

    coroutineScope {

        launch {

            delay(500)

            println("is running")

        }

        launch {

            delay(100)

            cancel()

        }.invokeOnCompletion {

            println("job2 is canceled")

        }

    }

}

这似乎没有什么可解释的，某个协程的取消并不会影响到其兄弟协程。

2.3 携程的取消是协作式的

协程的取消是协作式的体现在，对取消的通知需要主动的需要主动嗅探感知做出处理。举个例子

private suspend fun coroutineCanceling() {

    coroutineScope {

        val job = launch {

            var i = 0

            while (true) {//1

                println(" is running ${i++}")

            }

        }

        job.invokeOnCompletion {

            println("job is completion ${it}")

        }

        delay(50)

        job.cancel()

    }

}

会发现上面这个段代码并不能被取消，原因就是协程并没有感知到自己已经被取消了。这一点跟java thead interrupt机制类似，需要我们感知取消。感知取消的方式有

• 可以使用CoroutineScope.isActive（）的方法check是否已经被取消做出反应,代码一处可改成while (isActive)


• 所有的suspend方法内部也会感知cancel。比如delay()方法就是一个suspend方法。

2.4 做好善后取消

协程取消后我们可能会做一些诸如回收资源的动作，但在一个已经处于取消状态的协程里再调用suspend方法就抛出CancellationException异常。此时我们要使用 withContext(NonCancellable) 做取消后的工作

private suspend fun handleCanceling() {

    coroutineScope {

        val job = launch {

            try {

                delay(100)//do Something

            } finally {

                withContext(NonCancellable) {

                    delay(100)

                }

            }

        }

        job.invokeOnCompletion {

            println("job is completion ${it}")

        }

        delay(50)

        job.cancel()

    }

}

另外，还有特别注意的一点是，被取消的协程会向外抛出异常如果使用try-catch捕获但不抛出异常CancellationException，会影响到异常的传播，也就破坏了协程的异常传播机制，具体下一节异常传播机制展开。

2.5 kotlin协程的父子结构

看下面这段代码，思考一个问题，2处字符串会被打印出出来吗，为什么？

private suspend fun parentChildStructTest() {

    coroutineScope {

       val job1 =  launch {

         val job2 =  launch(Job()) {//1

                delay(500)

                println("job2 is finish")//2

            }

            delay(100)

            this.cancel()

        }

    }

}

不会打印，不知道你有没有答对。

不是说好的，取消父协程的时候会取消掉其子协程吗？而且子协程里还调用了delay()方式，也会响应取消。问题的关键点在于，job1和job2的父子结构被破坏了。示例代码里1处传入了一个Job对象，此时job2的父层级已经变成了传入的job对象。我们稍加改造下，这里只是为了理解，不建议这么用，会发现job2可以被取消了。

private suspend fun parentChildStructTest() {

    coroutineScope {

        val job1 = launch {

            val j = Job()

            val job2 = launch(j) {

                delay(500)

                println("job2 is finish")

            }.invokeOnCompletion {

                println("job2 OnCompletion $it")

            }

            delay(100)

            j.cancel() //1

        }

    }

}

新协程的context的组成有两个公式

parentContext = scopeContext + AddionalContext(launch方法传入的context)



childContext = parentConxtext + job(新建)

(图来自[Roman Elizarov])

• 新协程的context是【parent context】和【新建job】的相加操作而来。


• 【parent context】是由父层级的context和传入的参数context相加操作而来。


• 子协程的job会和父层级中context的job建立一个父子关系。

当我们使用coroutineScope.launch(Job()){}传入了一个job实例的时候，其实子协程的job和传入的job实例建立了父子结构，破坏了原本的父子结构。

3 异常传播机制

3.1 异常的传播

private suspend fun destroyCoroutineScope() {

    coroutineScope {

        launch {

            launch {

                delay(500)

                throw NullPointerException()

            }.invokeOnCompletion {

                println("job-1 invokeOnCompletion $it")

            }



            launch {

                delay(800)

            }.invokeOnCompletion {

                println("job-2 invokeOnCompletion $it")

            }

        }.invokeOnCompletion {

            println("job-parent completion $it")

        }

    }

}

• 子job异常后，传播到父协程，父协程会取消到自己所有的子协程，然后再往上传播


• 如果是一个取消异常(CancellationException)并不会被取消协程，父协程的处理器会忽略他。也就是在子协程上抛出异常之后，父协程接收到不会做处理。

3.2 监督作用域异常传播（Supervision）

基本表现：使用supervisorScope启动的子协程发生异常时，不影响父协程和兄弟协程。

private suspend fun supervisorJobTest() {

    supervisorScope {

        launch {

            delay(100)

            throw NullPointerException()

        }

        launch {

            delay(800)

            println("job 2 is running")

        }

    }

}

如上代码，supervisor范围内第一个job抛出异常后，并不会影响第二个job；把错误异常控制在范围内。

• SupervisorCoroutine的子协程发生了异常之后不会影响父协程自身，也不会向上传播。


• 如果 CoroutineContext没有设置CoroutineExceptionHandle，最终异常会传播到ExceptionHandler

但其他的结构化并发特性仍然存在

• 当父协程取消，他的协程也被取消。


• 子协程取消不影响父协程。


• 父协程抛出异常，子协程也会被取消。


• 父协程要等所有子协程完成后才结束。

简单的讲，监督协程具备单向传播的特性，即子协程的异常和取消不影响父协程，父协程的异常和取消会影响子协程

两种方式:

• 构建CoroutineScope时传入SupervisorJob()


• 使用supervisorScope{}产生

注意：

监督协程中的每一个子作业应该通过异常处理机制处理自身的异常。如果不处理异常会被吞掉。

3.3 CoroutineExceptionHandler

用于捕获协程执行过程中未捕获的异常，被用来定义一个全局的异常处理器。

• 不能恢复异常,只是打印、记录、重启应用。


• 只能在【根作用域】或者【supervisorScope的直接子协程】启动协程是传入才生效。

举个例子

suspend fun coroutineExceptionHandlerTest() {

    supervisorScope {

        val handler = CoroutineExceptionHandler { _, _ -> println("handleException in coroutineExceptionHandler") }

        launch(handler) {

            delay(100)

            throw NullPointerException()

        }

    }

}  

3.4 浅看源码

主从作用域和协作作用域的表现区别上文已经讲到了，通常我们构建一个协程作用域两种方式

val scope = CoroutineScope(Job())

val supervisorJob = CoroutineScope(SupervisorJob())

• CourotineScope()方法(没错这是个方法)，通过传入Job()SupervisorJob生成的对象最终获得主从作用域和协同作用域。

  supervisorScope { scope -> xx }

  coroutineScope { scope ->xx  }

• 通过supervisorScope()或者coroutineScope()构建作用域。

private class SupervisorCoroutine<in T>(

    context: CoroutineContext,

    uCont: Continuation<T>

) : ScopeCoroutine<T>(context, uCont) {

    override fun childCancelled(cause: Throwable): Boolean = false

}



private class SupervisorJobImpl(parent: Job?) : JobImpl(parent) {

    override fun childCancelled(cause: Throwable): Boolean = false

}

两种作用域在代码上的区别是 fun childCancelled(cause: Throwable) 方法的实现不同，监督作用域直接返回fasle表示不处理子协程的错误异常。让其自己处理

//JobSupport

    private fun cancelParent(cause: Throwable): Boolean {

        ... 

        return parent.childCancelled(cause) || isCancellation //1

    }



    private fun finalizeFinishingState(state: Finishing, proposedUpdate: Any?): Any? {

      ...

       val handled = cancelParent(finalException) || handleJobException(finalException)//2

       if (handled) (finalState as CompletedExceptionally).makeHandled()

      ...

    }

源代码中的核心逻辑，

• 1处的parent.childCanceled的值的最终来源其实就是我们实现的childCancelled方法的返回值


• 2处当我们是一个监督作用域起cancelParent的返回值为false，这种情况下代码就会执行后半句handleJobException()，这半句的内部其实最终是执行了我们设置的CoroutineExceptionHandler。


• 2处cancelParent除了在我们监督作用域的时候返回fasle，在根协程下会返回fasle，这也就是为什么CoroutineExceptionHandler设置在根协程下生效的原因。

代码很多细节不展开有兴趣的自行研究。

4 异常传播需注意问题

4.1 supervisorScope的孙子协程

private suspend fun childChildSupervisorJob() {

    supervisorScope { // SupervisorCouroutine

        launch {  // ScopeCoroutine

           val job1 =  launch {

                delay(100)

                throw NullPointerException()

            }

           val job2 = launch {

                delay(800)

                println("job 2 is running")

            }.invokeOnCompletion {

                println("job2 is completion $it")

            }

        }

    }

}

• 看上面这个例子job1抛出空指针异常后，job2会不会受影响。


• 是正常的coroutineScope而非supervisorScope，因此supervisorScope的“孙子协程”不遵循互不影响原则

4.2 注意不要破坏父子结构

private suspend fun textSupervisorJob() {

    supervisorScope {

        launch(SupervisorJob()) {//1

            launch {

                delay(100)

                throw NullPointerException()

            }

            launch {

                delay(800)

                println("job 2 is running")

            }.invokeOnCompletion {

                println("job2 is completion $it")

            }

        }

    }

}

• job1抛出异常也会影响job2,原因1处虽然传入了SupervisorJob，但是这个实例其实是作为父context的job传入的，真是job1和job2的parentContext还是job类型，而不是SupervisorJob。具体原理可以看2.5小节

5 关于async的误会

通常构建一个协程除了使用CoroutineScope.launch{}还会使用CoroutineScope.async{}。

经常看到这种说法，async方式启动的协程返回一个Deferred对象，当调用deffered的await()方法的时候才会抛出异常

private suspend fun asyncSample() {

    val h = CoroutineScope(CoroutineExceptionHandler { _, _ -> println("发生了异常") })

    val d = h.launch {

        async {

            delay(100)

            throw NullPointerException()

        }

        launch { //job2

            delay(500)

            println("job 2 is finish")

        }

    }.join()

}

这个例子没有调用await()，实际发现也会立马抛出异常，导致jo2都没执行完。跟我们认为的不一样。

实际情况是这样的：当async被用作构建根协程（由协程作用域直接管理的协程）或者监督作用域直接管理协程时，异常不会主动抛出，而是在调用.await()时抛出。其他情况不等待await就会抛出异常。

6 总结

本文梳理了Kotlin的协程的取消和异常传播处理机制。机制的设置总的来说是服务于结构化并发的。本文应该能让我们了解掌握以下问题才算合格

• kotlin协程结构化并发的特性


• 协程的context是怎么来的？怎么构成的？父协程的context和协程的parentContext是同一个概念吗？


• kotlin的协程是怎么传播的？主从作用域监督作用域的区别？怎么实现


• async方式启动的协程要await()的时候才抛出异常？

预期

当前安卓的所有proto都生成在一个module中，但是其实业务同学需要的并不是一个大杂烩， 只需要其中他们所关心的proto生成的类则足以。所以我们希望能将这样一个大杂烩的仓库打散，拆解成多个module。

buf.yaml

Protobuf是Protocol Buffers的简称，它是Google公司开发的一种数据描述语言，用于描述一种轻便高效的结构化数据存储格式，并于2008年对外开源。Protobuf可以用于结构化数据串行化，或者说序列化。它的设计非常适用于在网络通讯中的数据载体，很适合做数据存储或 RPC 数据交换格式，它序列化出来的数据量少再加上以 K-V 的方式来存储数据，对消息的版本兼容性非常强，可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。开发者可以通过Protobuf附带的工具生成代码并实现将结构化数据序列化的功能。

在我司proto相关的都是由后端大佬们来维护的，然后这个协议仓库会被android/ios/后端/前端 依赖之后生成对应的代码，然后直接使用。

而proto文件中允许导入对于其他proto文件的依赖，所以这就导致了想要把几个proto转化成一个java-library工程，还需要考虑依赖问题。所以由
我们的后端来定义了一个buf.yaml的数据格式。

version: v1

name: buf.xxx.co/xxx/xxxxxx

deps:

  - buf.xxxxx.co/google/protobuf

build:

  excludes:

    - setting

breaking:

  use:

    - FILE

lint:

  use:

    - DEFAULT

name代表了这个工程的名字，deps则表示了他依赖的proto的工程名。基于这份yaml内容，我们就可以大概确定一个proto工程编译需要的基础条件。然后我们只需要一个工具或者插件来帮助我们生成对应的工程就够了。

模板工程

现在我们基本已经有了一个单一的proto工程的输入模型了，其中包含工程名依赖的工程还有对应文件夹下的proto文件。然后我们就可以基于这部分输入的模型，生成出第一个模板工程。

plugins {

    id 'java-library'

    id 'org.jetbrains.kotlin.jvm'

    id 'com.google.protobuf'

}





java {

    sourceCompatibility = JavaVersion.VERSION_1_8

    targetCompatibility = JavaVersion.VERSION_1_8

}



sourceSets {

    def dirs = new ArrayList<String>()

    dirs.add("src/main/proto")

    main.proto.srcDirs = dirs

}



protobuf {

    protoc {

        if (System.getProperty("os.arch").compareTo("aarch64") == 0) {

            artifact = "com.google.protobuf:protoc:$version_protobuf_protoc:osx-x86_64"

        } else {

            artifact = "com.google.protobuf:protoc:$version_protobuf_protoc"

        }

    }

    plugins {

        grpc {

            if (System.getProperty("os.arch").compareTo("aarch64") == 0) {

                artifact = 'io.grpc:protoc-gen-grpc-java:1.36.1:osx-x86_64'

            } else {

                artifact = 'io.grpc:protoc-gen-grpc-java:1.36.1'

            }

        }

    }

    generateProtoTasks {

        all().each { task ->

            task.generateDescriptorSet = true

            task.builtins {

                // In most cases you don't need the full Java output

                // if you use the lite output.

                java {



                }



            }

            task.plugins {

                grpc { option 'lite' }

            }

        }

    }

}

afterEvaluate {

    project.tasks.findByName("compileJava").dependsOn(tasks.findByName("generateProto"))

    project.tasks.findByName("compileKotlin").dependsOn(tasks.findByName("generateProto"))

}

dependencies {

    implementation "org.glassfish:javax.annotation:10.0-b28"

    def grpcJava = '1.36.1'

    compileOnly "io.grpc:grpc-protobuf-lite:${grpcJava}"

    compileOnly "io.grpc:grpc-stub:${grpcJava}"

    compileOnly "io.grpc:grpc-core:${grpcJava}"

    File file = new File(projectDir, "depend.txt")

    if (!file.exists()) {

        return

    }

    def lines = file.readLines()

    if (lines.isEmpty()) {

        return

    }

    lines.forEach {

        logger.lifecycle("project:" + name + "   implementation: " + it)

        implementation(it)

    }

}

如果需要将proto编译成java代码,就需要依赖于com.google.protobuf插件，依赖于上面的build.gradle基本就可以将一个proto输入编译成一个jar工程。

另外我们需要把所有的proto文件拷贝到这个壳工程的src/main/proto文件夹下，最后我们会将buf.yaml中的name: buf.xxx.co/xxx/xxxxxx的/xxx/xxxxxx转化成工程名，去除掉一些无法识别的字符。

我们生成的模板工程如下:

其中proto.version会记录proto内的gitsha值还有文件的lastModified时间，如果输入发生变更则会重新进行一次文件拷贝操作，避免重复覆盖的风险。

input.txt则包含了所有proto文件路径，方便我们进行开发调试。

deps 转化

由于proto之间存在依赖，没有依赖则会导致无法将proto转化成java。所以这里我讲buf.yaml中读取出的deps转化成了一个depend.txt.

com.xxxx.api:google-protobuf:7.7.7

depend.txt内会逐行写入当前模块的依赖，我们会对name进行一次转化，变成一个可读的gradle工程名。其中7.7.7的版本只是一个缺省而已，并没有实际的价值。

多线程操作

这里我们出现了一点点的性能问题, 如果可以gradle插件中尽量多使用点多线程，尤其是这种需要io的操作中。

这里我通过ForkJoinPool，这个是ExecutorService的实现类。其中submit方法中会返回一个ForkJoinTask，我们可以将获取gitsha值和lastModified放在这个中。之后把所有的ForkJoinTask放到一个数组中。

fun await() {

     forkJoins.forEach {

         it.join()

     }

 }

然后最后暴露一个await方法，来做到所有的获取方法完成之后再继续向下执行。

另外则就是壳module的生成，我们也放在了子线程内执行。我们这次使用了线程池的invokeAll方法。

protoFileWalk.hashMap.forEach { (_, pbBufYaml) ->

           callables.add(Callable<Void> {

               val root = FileUtils.getRootProjectDir(settings.gradle)

               try {

                   val file = pbBufYaml.copyLib(File(root, "bapi"))

                   projects[pbBufYaml.projectName()] = file.absolutePath ?: ""

               } catch (e: Exception) {

                   e.printStackTrace()

                   e.message.log()

               }

               null

           })

       }

       executor.invokeAll(callables)

这里有个面试经常出现的考点，多线程操作Hashmap，之后我在测试环节随机出现了生成工程和include不匹配的问题。所以最后我更换了ConcurrentHashMap就没有出现这个问题了。

加载壳Module

这部分就和源码编译插件基本是一样的写法。

projects.forEach { (s, file) ->

              settings.include(":${s}")

              settings.project(":${s}").projectDir = File(file)

          }

把工程插入settings 即可。

结尾

最终结果大概就是原先一个Module，现在被拆分成100+的Module，而且基于buf.yaml 文件动态生成，基本符合第一期需求。

这部分方案这样也就大概完成了一半，剩下的一半我们需要逐一把生层业务的依赖进行一次变更，这样就可以做到依赖最小化，然后也可以去除掉一部分无用的代码块。

前言

位运算其实是一个比较常用的操作，有的人可能说，并没有啊，我好像基本就没怎么用过位运算，但如果你经常看源码，你就会发现源码里面有很多位运算的操作，而且这些操作我个人觉得确实是有很意思，所以位运算很重要，平时用不多，也需要经常去回顾复习。

因为临时写的，有些源码的操作我不太记得是出自哪里了，如果以后碰到了，会在评论区进行补充。比如会有一些取反计算再取反回来的操作，比如左移和右移，我现在不太记得是出自哪里了，反正比较经典的。我的个人可能就记得用位运算来表示状态，因为我会经常用这个。

位运算基础

简单来回顾一下基础的计算，位运算会分为一元运算和二元运算。

一元有左移<<，右移>>，无符号右移动>>>和取反～

左移是是什么？比如 0010 左移动一位就变成 0100 （注意这里是二进制的表示），右移动就是 0100 变成 0010。 当然没这么简单啦，二进制也有表示正负值的标志位，右移之后，左边会补标志位的数。而无符号右移动是左边补0。也就是说正数的右移和无符号右移动的结果相同，而负数就不同了。这样说应该好理解吧？那思考一下为什么没有无符号左移

还是不好懂，没关系，我们讲慢些，假如8转成2进制是00001000

而-8就是先取反码，反码就是取反，所以8的反码是11110111，然后再用反码取补码，补码就是+1,所以这里得到补码1111000。即-8转成二进制是11111000

先看看我们对11111000取反码，得00000111，再取补码得00001000，看到从-8到8也是同样的操作。

然后我们看右移一位和无符号右移一位的效果。

-8的二进制11111000，右移一位是11111100，这是多少啊？我们可以用上面的计算看它的正数是多少，反码00000011，补码00000100，这是4吧，所以11111100是-4。

同理看无符号右移，得01111100，反码10000011，补码10000100，这是多少？2的7次方+4，所以是不同的。

取反就好理解了，取反就是逻辑非，比如0010取反就是1101

二元有与&&、或||、异或^

这些都好理解吧，与运算 1010 && 1001 = 1000 ， 或运算 1010 || 1001 = 1010 ， 异或 1010 ^ 1001 = 0011 ，这没什么好讲的，很基础。

位运算很简单？

一看，哎哟，真的简单，就这？1分钟学会了。学会？那会用吗？

没关系，我们来看一题算法：

一个整型数组里除了两个数字只出现一次，其他的数字都出现了两次。请写程序找出这两个只出现一次的数字。例如：

输入：

[1,4,1,6]

返回值：

[4,6]

明确说了，这题是用位运算，但是怎么做？

开发中位运算的使用

这个我因为临时写的，android源码里确实是有些比较经典的位运算使用场景，我现在不完全记得，只能先列举几个，其它的如果以后想起来，会在评论区中做补充。

用来表示状态

位运算可以用来表示状态，我之前也写过一篇文章 juejin.cn/post/715547… 差不多也是这个意思。

比如window的flags，看看它的定义

public static final int FLAG_LAYOUT_IN_SCREEN   = 0x00000100;

public static final int FLAG_LAYOUT_NO_LIMITS   = 0x00000200;

public static final int FLAG_FULLSCREEN      = 0x00000400;

public static final int FLAG_FORCE_NOT_FULLSCREEN   = 0x00000800;

......

那他这样做有什么好处，他能一个变量表示多个维度的状态。比如FLAG_LAYOUT_IN_SCREEN|FLAG_LAYOUT_NO_LIMITS|FLAG_FULLSCREEN|FLAG_FORCE_NOT_FULLSCREEN就是 1111 （二进制表示）

如果你要判断这个window是不是同时设置了这4个flag，要怎么判断，就直接if(flags == 15)啊，多简单

但是如果你用多个变量存flag要怎么判断, if(isScreen && isNoLimits && usFullscreen && isForceNot)，这样写就很难看，很不方便，我window的flag多着呢，难道你要排火车？

数组扩容

来看看ArrayList的扩容源码

private void grow(int minCapacity) {

    // overflow-conscious code

    int oldCapacity = elementData.length;

    int newCapacity = oldCapacity + (oldCapacity >> 1);

    if (newCapacity - minCapacity < 0)

        newCapacity = minCapacity;

    if (newCapacity - MAX_ARRAY_SIZE > 0)

        newCapacity = hugeCapacity(minCapacity);

    // minCapacity is usually close to size, so this is a win:

    elementData = Arrays.copyOf(elementData, newCapacity);

}

这里的int newCapacity = oldCapacity + (oldCapacity >> 1);就是阔人操作，这个右移是什么？看不懂也没关系，自己套一个数字进去算就知道了，是除2吧，那ArrayList的扩容就是旧容量的一半。

看着简单是吧？那有没有想过一个问题，他写这个代码，为什么不写oldCapacity/2，而写oldCapacity >> 1

那既然右移一位 >> 1 是除2，那左移一位 << 1 是什么操作呢？是什么计算呢？

总结

我这里确实是很久没有用位运算，所以需要复习一下。这个东西对开发来说很重要，比如你是开发应用层的，你觉得这个是底层用到的，你用不到，并不是这样。就拿那个表示状态的来说，自从我看到源码用这一招之后，只要有合适的场景，我也会这样用。

不管是做数学运算，还是逻辑运算，位运算都能适用，它是很简单就能学会，但是学会用，那就是另外一回事，当然不是说看完我这篇文章就开始瞎用，能在合适的场合去使用，那效果十分的好，用不上也没关系，至少要有个意识，这样不管在看源码还是其它时候，都是能帮到你的。

现象

线上某个服务有接口非常慢，通过监控链路查看发现，中间的 GAP 时间非常大，实际接口并没有消耗很多时间，并且在那段时间里有很多这样的请求。

原因分析

先从监控链路分析了一波，发现请求是已经打到服务上了，处理之前不知道为什么等了 3s，猜测是不是机器当时负载太大了，通过 QPS 监控查看发现，在接口慢的时候 CPU 突然增高，同时也频繁的 GC ，并且时间很长，但是请求量并不大，并且这台机器很快就因为 Heap满了而被下掉了。

去看了下日志，果然有 OOM 的报错，但是从报错信息上并没办法找到 Root Cause。

system error: org.springframework.web.util.NestedServletException: Handler dispatch failed; nested exception is java.lang.OutOfMemoryError: Java heap space   at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1055)   at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:943)   at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)   at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:909)   at javax.servlet.http.HttpServlet.service(HttpServlet.java:681) 

另外开发同学提供了线索，在发生问题的时候在跑一个大批量的一次性 JOB，怀疑是不是这个 JOB 导致的，马上把 JOB 代码拉下来分析了下，JOB 做了分批处理，代码也没有发现什么问题。

虽然我们系统加了下面的 JVM 参数，但是由于容器部署的原因，这些文件在 pod 被 kill 掉之后没办法保留下来。

-XX:+HeapDumpOnOutOfMemoryError -XX:ErrorFile=/logs/oom_dump/xxx.log -XX:HeapDumpPath=/logs/oom_dump/xxx.hprof

这个现象是最近出现的，猜测是最近提交的代码导致的，于是去分析了最近提交的所有代码，很不幸的都没有发现问题。。。

在分析代码的过程中，该服务又无规律的出现了两次 OOM，只好联系运维同学优先给这个服务加了 EFS （Amazon 文件系统）等待下次出现能抓住这个问题。

刚挂载完 EFS，很幸运的就碰到了系统出现 OOM 的问题。

dump 出来的文件足有 4.8G，话不多说祭出 jvisualvm 进行分析，分析工具都被这个dump文件给搞挂了也报了个java.lang.OutOfMemoryError: Java heap space，加载成功之后就给出了导致OOM的线程。

找到了具体报错的代码行号，翻一下业务代码，竟然是一个查询数据库的count操作，这能有啥问题?

仔细看了下里面有个foreach遍历userId的操作，难道这个userId的数组非常大?

找到class按照大小排序，占用最多的是一个 byte 数组，有 1.07G，char 数组也有1.03G，byte 数组都是数字，直接查看 char 数组吧，点进去查看具体内容，果然是那条count语句，一条 SQL 1.03G 难以想象。。。

这个userId的数据完全是外部传过来的，并没有做什么操作，从监控上看，这个入参有 64M，马上联系对应系统排查为啥会传这么多用户过来查询，经过一番排查确认他们有个bug，会把所有用户都发过来查询。。。到此问题排查清楚。

解决方案

对方系统控制传入userId的数量，我们自己的系统也对userId做一个限制，问题排查过程比较困难，修改方案总是那么的简单。

别急，还有一个

看到这个问题，就想起之前我们还有一个同样类似的问题导致的故障。

也是突然收到很多告警,还有机器 down 机的告警，打开 CAT 监控看的时候，发现内存已经被打满了。

操作和上面的是一样的，拿到 dump 文件之后进行分析，不过这是一个漫长的过程，因为 down了好几台机器，最大的文件有12GB。

通过 MAT 分析 dump 文件发现有几个巨大的 String（熟悉的味道，熟悉的配方）。

接下来就是早具体的代码位置了，去查看了下日志，这台机器已经触发自我保护机制了，把代码的具体位置带了出来。

经过分析代码发现，代码中的逻辑是查询 TIDB（是有同步延迟的），发现在极端情况下会出现将用户表全部数据加载到内存中的现象。

于是找 DBA 拉取了对应时间段 TIDB 的慢查询，果然命中了。

总结

面对 OOM 问题如果代码不是有明显的问题，下面几个JVM参数相当有用，尤其是在容器化之后。

-XX:+HeapDumpOnOutOfMemoryError -XX:ErrorFile=/logs/oom_dump/xxx.log -XX:HeapDumpPath=/logs/oom_dump/xxx.hprof

另外提一个参数也很有用，正常来说如果程序出现 OOM 之后，就是有代码存在内存泄漏的风险，这个时候即使能对外提供服务，其实也是有风险的，可能造成更多的请求有问题，所以该参数非常有必要，可以让 K8S 快速的再拉起来一个实例。

-XX:+ExitOnOutOfMemoryError

另外，针对这两个非常类似的问题，对于 SQL 语句，如果监测到没有where条件的全表查询应该默认增加一个合适的limit作为限制，防止这种问题拖垮整个系统。

本想新周摸新鱼，却是早早入坑。看到群友千元求解一个叫当当网的索引瞬间来了兴趣

1. 网站地址，大体一看没什么特别的地方就是一个关键字编码问题，打眼一看url编码没跑直接拿去解码无果

-有点惊讶看似url编码实则url编码只是这，滋滋滋...

有点东西，开始抓包，断点，追踪的逆向之路

2. 发现是ajax加载（不简单呀纯纯的吊胃口）先来一波关键字索引（keyword）等一系列基操轻而易举的找到了他

从此开始走向了一条不归路，经过一上午的时间啥也没追到，午休之后继续战斗，经过了一两个半小时+三支长白山牌香烟的努力终于

cihui = '哈哈哈'

js = open("./RSAAA.js", "r", encoding="gbk", errors='ignore')

line = js.readline()

htmlstr = ''

while line:

    htmlstr = htmlstr + line

    line = js.readline()

ctx = execjs.compile(htmlstr)

result = ctx.call('invokeServer', cihui)

print(result)

const jsdom = require("jsdom");

const {JSDOM} = jsdom;

const dom = new JSDOM('<head>\n' +

    '                <base href="//search.dangdang.com/Standard/Search/Extend/hosts/">\n' +

    '<link rel="dns-prefetch" href="//search.dangdang.com">\n' +

    '<link rel="dns-prefetch" href="//img4.ddimg.cn">\n' +

    '<title>王子-当当网</title>\n' +

    '<meta http-equiv="Content-Type" content="text/html; charset=GB2312">\n' +

    '<meta name="description" content="当当网在线销售王子等商品，并为您购买王子等商品提供品牌、价格、图片、评论、促销等选购信息">\n' +

    '<meta name="keywords" content="王子">\n' +

    '<meta name="ddclick_ab" content="ver:429">\n' +

    '<meta name="ddclick_search" content="key:王子|cat:|session_id:0b69f35cb6b9ca3e7dee9e1e9855ff7d|ab_ver:G|qinfo:119800_1_60|pinfo:_1_60">\n' +

    '<link rel="canonical" href="//search.dangdang.com/?key=%CD%F5%D7%D3\&amp;act=input">\n' +

    '        <link rel="stylesheet" type="text/css" href="css/theme_1.css">\n' +

    '    <!--<link rel="Stylesheet" type="text/css" href="css/model/home.css" />-->\n' +

    '   <link rel="stylesheet" type="text/css" href="css/model/search_pub.css?20211117">    \n' +

    '<style>.shop_button {height: 0px;}.children_bg01 a {\n' +

    'margin-left: 0px;\n' +

    'padding-left: 304px;\n' +

    'width: 630px;\n' +

    '}\n' +

    '.children_bg02 a {\n' +

    'margin-left: 0px;\n' +

    'padding-left: 304px;\n' +

    'width: 660px;\n' +

    '}\n' +

    '.children_bg03 a {\n' +

    'margin-left: 0px;\n' +

    'padding-left: 304px;\n' +

    'width: 660px;\n' +

    '}\n' +

    '.narrow_page .children_bg01 a{\n' +

    'width: 450px;\n' +

    '}\n' +

    '.narrow_page .children_bg02 a{\n' +

    'width: 450px;\n' +

    '}\n' +

    '.narrow_page .children_bg03 a{\n' +

    'width: 450px;\n' +

    '}.price .search_e_price span {font-size: 12px;font-family: 微软雅黑;display: inline-block;background-color: #739cde;color: white;padding: 2px 3px;line-height: 12px;border-radius: 2px;margin: 0 4px 0 5px;}\n' +

    '.price .search_e_price:hover {text-decoration: none;}</style>                        <link rel="stylesheet" href="http://product.dangdang.com/js/lib/layer/3.0.3/skin/default/layer.css?v=3.0.3.3303" id="layuicss-skinlayercss"><script id="temp_script" type="text/javascript" src="//schprompt.dangdang.com/suggest_new.php?keyword=好好&amp;pid=20230227105316030114015279129895799&amp;hw=1&amp;hwps=12&amp;catalog=&amp;guanid=&amp;0.918631418357919"></script><script id="json_script" type="text/javascript" src="//static.dangdang.com/js/header2012/categorydata_new.js?20211105"></script></head>');



window = dom.window;

document = window.document;

function invokeServer(url) {



     var scriptOld = document.getElementById('temp_script');

     if(scriptOld!=null && document.all)

     {

        scriptOld.src = url;

        return script;

     }

    var head=document.documentElement.firstChild,script=document.createElement('script');

    script.id='temp_script';

    script.type = 'text/javascript';

    script.src = url;

    if(scriptOld!=null)

       head.replaceChild(script,scriptOld);

    else

       head.appendChild(script);

    return script

}

3. 
   

   完事!当我以为都要结束了的时候恍惚直接看到了源码中的gb2312突然想起了之前做的一个萍乡房产网的网站有过类似经历赶快去尝试结果我**
   
   
   

   
   


4. 
   

   总结：提醒各位大佬在逆向之路中还是要先从基操开始，没必要一味的去搞攻克扒源码，当然还是要掌握相对全面的内容，其实除了个别大厂有些用些贵的东西据说某数5要20个W随着普遍某数不知道那些用了20w某数的大厂心里是什么感觉或许并不在乎这点零头哈哈毕竟是大厂，小网站的反扒手段并不是很难，俗话说条条大道通北京。

问题描述：

项目的通知栏的RemoteViews背景图有些厂商颜色不对，需要一个适配方案，来适配所有机型。

项目现状：

目前的方案是，创建一个新的通知，通过这个通知来获取底色。

其中有一个字段是获取是否是暗黑模式，这段代码是先用按位或忽略掉透明度，系统的字体颜色不会有特别高的同名度，所以这里理论上没什么问题，然后计算两个三维向量的距离，距离越近，颜色越接近。

这里是有误差的，目标向量距离灰色向量rgb(127.5,127.5,127.5)的最大值约为220，而不是180，就会造成纯白色rgb(255,2555,255)的标题字体颜色，理应是黑色背景才能看到，但却被识别成非暗黑模式。

误判了暗黑模式，这里的背景就颜色就会出问题了。

目前项目的解决方案是通过设置RemoteViews的background颜色去做，这里需要适配的问题由RemoteViews实现机制产生：RemoteViews被设计具有跨进城通信的属性，通过Binder传递到SystemService进程，根据它的包名来拿相应的应用的资源，为了提高效率，系统没有直接通过Binder去支持所有的View和View操作，那这里对普通view生效的xml属性，很有可能厂商对系统修改源码后没有完全的适配，可能就不能对其全部生效。

比如对android:background属性进行设置在部分机型上就不会生效，但下面这段代码可以。

RemoteView?.setInt(R.id.ll_root, "setBackgroundColor", ContextCompat.getColor(context, R.color.color_367AF6))

接下来来看项目如何设置颜色。

然后来看拿到暗黑模式的布尔字段后，会设置为#FFFFFFFF/#00000000这两个颜色，这两个颜色都是有问题的，首先暗黑模式情况下，#00000000（百分百透明的黑色）不一定会正确解析为透明色，类似问题为启动icon解析时，透明色解析为黑色背景，具体还要观察各厂商系统对源码的修改。

#FFFFFFFF这个颜色也是不对的，不是每个通知栏的背景都是白色，而且这个颜色也不一定会作为背景色，下面鸿蒙系统上就没有生效为白色。

来观察下不同时期的通知样式，可以发现不是每个时期都是固定颜色底色，有白有黑有灰，那就要动态的获取背景色来设置RemoteVies的背景色，下图以安卓1-7为示例。

接着还要考虑不同的系统版本对Notification的改动，如安卓8.0以上加入了Channel这一特性，项目的通知最后是要有一步渠道检查的。这里或许要额外对安卓13的有权限上的适配。

同时如果要考虑通知栏高度的问题的话，以安卓12为例，自定义通知的显示区域比安卓11有调整，折叠态高度上限为64dp，展开时高度上限为256dp，且系统强制显示通知的小图标。所以要考虑到ui层面对高度是否有要求，再来适配各个版本的RemoteViews的高度。下图为展开时示例。

以上，这个方案做不到适合所有机型，要适配所有机型确实是不是个简单的事情。

尝试过程：

核心问题为RemoteViews的背景色不能完美适配所有厂商。首先原安卓系统（非厂商自定义）不需要对其有特定的设置，自动跟随主题颜色；厂商自定义安卓系统，则各不相同，如小米则不会自动更改RemoteViews的颜色。

首先尝试获取背景色，我开始的尝试方式是沿用之前的方式，即build一个Notification，通过遍历其中的text，发现不是所有的都能拿到，参考其他文章列出的类似的表格如下：

虎牙项目目前的方案是，如果没拿到字体，默认就是字体为黑色，这个方法安卓7.0之后就失效了。安卓7.0+修改了Notification，采用 @android:color/primary_text_dark已经获取不到颜色值了。

那既然不能完美解决，这里我使用反编译工具，观察各厂商的逆向工程（以小米为例），这里需要花费大量的时间来阅读源码（前公司的代码真的看不懂= =），最后看到其他文章给出一个方案是在manifest加上这一句才会生效。

<item name="android:forceDarkAllowed" tools:targetApi="q">false</item>

复制代码

以上，RemoteViews的确拥有高自定义ui的特性，但很难找到一个方案来适配所有国内厂商的机型，因为Google设计通知栏，或者说其他任何的系统组件的伊始就没考虑过自定以rom的因素。

解决方案：

1.  不使用RemoteViews，改用其他方案解决

2.  使用RemoteViews

先说第一个，如果仅仅是虎牙目前的通知栏用途的话，确实没有使用复杂ui，使用RemoteViews的收益好像不足以掩盖bug多这个缺点。直播间的通知栏提醒完全可以用addAction方法来代替：

其他简单场景的情况下：

第二个，如果坚持使用RemoteViews，基本上网络上大部分的相关的文章我都翻过了，我也没看到业界更好的办法，大概只能反编译去看看抖音和微信是怎么做的吧。

答案是采用了原型模式。

原型模式的好处在于方便地拷贝某个实例的属性进行使用、又不会对原实例造成影响，其逻辑在于对 Cloneable 接口的实现。

话不多说看下 Intent 的关键源码：

 // frameworks/base/core/java/android/content/Intent.java

 public class Intent implements Parcelable, Cloneable {

     ...

     private static final int COPY_MODE_ALL = 0;

     private static final int COPY_MODE_FILTER = 1;

     private static final int COPY_MODE_HISTORY = 2;

 

     @Override

     public Object clone() {

         return new Intent(this);

     }

 

     public Intent(Intent o) {

         this(o, COPY_MODE_ALL);

     }

 

     private Intent(Intent o, @CopyMode int copyMode) {

         this.mAction = o.mAction;

         this.mData = o.mData;

         this.mType = o.mType;

         this.mIdentifier = o.mIdentifier;

         this.mPackage = o.mPackage;

         this.mComponent = o.mComponent;

         this.mOriginalIntent = o.mOriginalIntent;

         ...

 

         if (copyMode != COPY_MODE_FILTER) {

             ...

             if (copyMode != COPY_MODE_HISTORY) {

                 ...

             }

         }

     }

     ...

 }

可以看到 Intent 实现的 clone() 逻辑是直接调用了 new 并传入了自身实例，而非调用 super.clone() 进行拷贝。

默认的拷贝策略是 COPY_MODE_ALL，顾名思义，将完整拷贝源实例的所有属性进行构造。其他的拷贝策略是 COPY_MODE_FILTER 指的是只拷贝跟 Intent-filter 相关的属性，即用来判断启动目标组件的 action、data、type、component、category 等必备信息。无视启动 flag、bundle 等数据。

 // frameworks/base/core/java/android/content/Intent.java

 public class Intent implements Parcelable, Cloneable {

     ...

     public @NonNull Intent cloneFilter() {

         return new Intent(this, COPY_MODE_FILTER);

     }

 

     private Intent(Intent o, @CopyMode int copyMode) {

         this.mAction = o.mAction;

         ...

 

         if (copyMode != COPY_MODE_FILTER) {

             this.mFlags = o.mFlags;

             this.mContentUserHint = o.mContentUserHint;

             this.mLaunchToken = o.mLaunchToken;

             ...

         }

     }

 }

还有中拷贝策略是 COPY_MODE_HISTORY，不需要 bundle 等历史数据，保留 action 等基本信息和启动 flag 等数据。

 // frameworks/base/core/java/android/content/Intent.java

 public class Intent implements Parcelable, Cloneable {

     ...

     public Intent maybeStripForHistory() {

         if (!canStripForHistory()) {

             return this;

         }

         return new Intent(this, COPY_MODE_HISTORY);

     }

 

     private Intent(Intent o, @CopyMode int copyMode) {

         this.mAction = o.mAction;

         ...

 

         if (copyMode != COPY_MODE_FILTER) {

             ...

             if (copyMode != COPY_MODE_HISTORY) {

                 if (o.mExtras != null) {

                     this.mExtras = new Bundle(o.mExtras);

                 }

                 if (o.mClipData != null) {

                     this.mClipData = new ClipData(o.mClipData);

                 }

             } else {

                 if (o.mExtras != null && !o.mExtras.isDefinitelyEmpty()) {

                     this.mExtras = Bundle.STRIPPED;

                 }

             }

         }

     }

 }

总结起来：

除了 Intent，Android 源码中还有很多地方采用了原型模式。

• 
  

  Bundle 也实现了 clone()，提供了 new Bundle(this) 的处理：

  
  

   public final class Bundle extends BaseBundle implements Cloneable, Parcelable {
  
       ...
  
       @Override
  
       public Object clone() {
  
           return new Bundle(this);
  
       }
  
   }

  
  


• 
  

  组件信息类 ComponentName 也在 clone() 中提供了类似的实现：

  
  

   public final class ComponentName implements Parcelable, Cloneable, Comparable<ComponentName> {
  
       ...
  
       public ComponentName clone() {
  
           return new ComponentName(mPackage, mClass);
  
       }
  
   }

  
  


• 
  

  工具类 IntArray 亦是如此：

  
  

   public class IntArray implements Cloneable {
  
       ...
  
       @Override
  
       public IntArray clone() {
  
           return new IntArray(mValues.clone(), mSize);
  
       }
  
   }

  
  

原型模式也不一定非得实现 Cloneable，提供了类似的实现即可。比如：

• 
  

  Bitmap 没有实现该接口但提供了 copy()，内部将传递原始 Bitmap 在 native 中的对象指针并伴随目标配置进行新实例的创建：

  
  

   public final class ComponentName implements Parcelable, Cloneable, Comparable<ComponentName> {
  
       ...
  
       public Bitmap copy(Config config, boolean isMutable) {
  
           ...
  
           noteHardwareBitmapSlowCall();
  
           Bitmap b = nativeCopy(mNativePtr, config.nativeInt, isMutable);
  
           if (b != null) {
  
               b.setPremultiplied(mRequestPremultiplied);
  
               b.mDensity = mDensity;
  
           }
  
           return b;
  
       }
  
   }

  
  

前言

开发同学应该都很熟悉我们页面的渲染过程一般是从Activity#onCreate开始，再发起网络请求，等请求回调回来后，再基于网络数据渲染页面。可以用下面这幅图来粗略描述这个过程：

可以看到，目标页面渲染完成前必须得等待网络请求，导致渲染速度并没有那么快。尤其是当网络并不好的时候感受会更加明显。并且，当目标页面是H5页面或者是Flutter页面的时候，因为涉及到H5容器与Flutter容器的创建，白屏时间会更长。

那么有没有可能提前发起请求，来缩短网络请求这一部分的等待时间呢？这就是我们今天要讲的部分，接口预请求。

目标

我们要达到的目标很简单，就是提前异步发起目标页面的网络请求，从而加快目标页面的渲染速度。改善后的过程可以用下图表示：

并且，我们的预请求能力需要尽量少地侵入业务，与业务解耦，并保证能力的通用性，适用于工程内的任意页面（Android页面、H5页面、Flutter页面）。

方案

整体链路

首先给大家看一下整体链路，具体的细节可以先不用去抠，下面会一一讲到。

预请求时机

预请求时机一般有三种选择：

1. 由业务层自行选择时机进行异步预请求


2. 点击控件时进行异步预请求


3. 路由最终跳转前进行异步预请求

第1种选择，由业务层自行选择时机进行预请求，需要涉及到业务层的改造，以及对时机合理性的把握。一方面是存在改造成本，另一方面是无法保证业务侧调用时机的合理性。

第2种选择，点击控件时进行预请求。若点击时进行预请求，点击事件监听并不是业务域统一的，无法形成有效封装。并且，若后续路由拦截器修改了参数，或是终止了跳转，这次预请求就失去了意义。

因此这里我们选择第3种，基于统一路由框架，在路由最终跳转前进行预请求。既保证了良好的封装性，也实现了对业务的零侵入，同时也做到了懒请求，即用户必然要发起该请求时才会去预请求。这里需要注意的是必须是在最终跳转前进行预请求，可以理解为是路由的最后一个前置异步拦截器。

预请求规则配置

我们通过本地的json文件（当然，有需要也可以上云通过配置后台下发），对预请求的规则进行配置，并将这份配置在App启动阶段异步读入到内存。后续在路由过程中，只有命中了预请求规则，才能发起预请求。配置demo如下：

{

  "routeConfig":{

    "scheme://domain/path?param1=true&itemId=123":["prefetchKey"],

    "route2":["prefetchKey2"],

    "route3":["prefetchKey3","prefetchKey4"]

  },

  "prefetcher":{

    "prefetchKey":{

      "prefetchType":"network",

      "prefetchInfo":{

        "api":"network.api.name",

        "apiVersion":"1.0",

        "method":"post",

        "needLogin":"false",

        "showLoginUI":"false",

        "params": {

          "itemId":"$route.itemId",

          "firstTime":"true"

        },

        "headers": {

          

        },

        "prefetchImgInResponse": [

          {

            "imgUrl":"$data.imgData.img",

            "imgWidth":"$data.imgData.imgWidth",

            "imgHeight":150

          }

        ]

      }

    },

    "prefetchKey2":{

      "prefetchType":"network",

      "prefetchInfo":{

        "api":"network.api.name2",

        "apiVersion":"1.0",

        "method":"post",

        "needLogin":"false",

        "showLoginUI":"false",

        "params": {

          "itemId":"$route.productId",

          "firstTime":"false"

        },

        "headers": {

          

        }

    },

    "prefetchKey3":{

      "prefetchType":"image",

      "prefetchInfo":{

        "imgUrl":"$route.imgUrl",

        "imgWidth":"$route.imgWidth",

        "imgHeight": 150

      }

    },

    "prefetchKey4":{

      "prefetchInfo":{}

    }

  }

}

规则解读

举例说明

网络预请求

例如跳转目标页面，它的路由是scheme://domain/path?param1=true&itemId=123。

首先我们在跳转路由时，若跳转的路由是这个目标页面，我们就会尝试去发起预请求。根据上面的demo配置文件，它将匹配到prefetchKey这个预请求。

那么我们详细看prefetchKey这个预请求，预请求类型prefetchType为network，是一个网络预请求，prefetchInfo中具备了请求的基本参数（如apiName、apiVersion、method、请求params与请求headers，不同工程不一样，大家可以根据自己的工程项目进行修改）。具体看params中，有一个参数为itemId:$route.itemId。以$route.开头的意思，就是这个value值要从路由中获取，即itemId=123，那么这个值就是123。

图片预请求

在做网络预请求的过程中，我忽然想到图片做预请求也是可以大大提升用户体验的，尤其是当大图片首次下载到内存中渲染需要的时间会比较长。图片预请求分为url已知与url未知两种场景，下面各举两个例子。

图片url已知

什么是图片url已知呢？比如我们在首页跳转首页的二级页面时，如果二级页面需要预加载的图片跟首页的某张图是一样的（尺寸可能不同），那么首页跳转路由时我们是能够提前知道这个图片的url的，所以我们看到prefetchKey3中配置了prefetchType为image的预请求。image的信息来自于路由参数，需要在跳转时将图片url和宽高作为路由参数之一。

比如scheme://domain/path?imgUrl=${encodeUrl}&imgWidth=200，那么根据配置项，我们将提前将encodeUrl这个图片以宽200，高150的尺寸，加载到内存中去。当目标页面用到这个图片时，将能很快渲染出来。

图片url未知

相反，当跳转目标页面时，目标页面所要加载的图片url没法取到，就对应了图片url未知的场景。

例如闪屏页跳转首页时，如果需要预加载首页顶部的图片，此时闪屏页是无法获取到图片的url的，因为这个图片url是首页接口返回的。这种情况下，我们只能依赖首页的预请求进行。

在demo配置文件中，我们可以看到prefetchImgFromResponse字段。这个字段代表着，当这个预请求响应回来之后，我需要去预请求某张图片。其中，imgUrl是$data.param格式，以$data.开头，代表着这份数据是来自于响应数据的。响应数据就是一串json串，可以凭此，索引到预请求响应中图片url的位置，就能实现图片的提前加载了。

至于图片怎么提前加载到内存中，以及真实图片的加载怎么匹配到内存中的图片，这一部分是通过glide已有的preload机制实现的，感兴趣的同学可以去看一下源码了解一下，这里就不展开了。后面讲的预请求的方案细节，都只限于网络请求。

预请求匹配

预请求匹配指的是实际的业务请求怎样与已经执行的预请求匹配上，从而节省请求的空中时间，直接返回预请求的结果。

首先网络预请求执行前先在内存中生成一份PrefetchRecord，代表着已经执行的预请求，其中的字段跟配置文件中差不多，主要就是记录预请求相关的信息：

class PrefetchRecord {

    // 请求信息

    String api;

    String apiVersion;

    String method;

    String needLogin;

    String showLoginUI;

    JSONObject params;

    JSONObject headers;



    // 预请求状态

    int status;

    // 预请求结果

    ResponseModel response;

    // 生成的请求id

    String requestId;



    boolean isMatch(RealRequest realRequest) {

        requestId.equals(realRequest.requestId)

    }

}

每一个PrefetchRecord生成时，都会生成一个requestId，用于跟实际业务请求进行匹配。requestId的生成规则可以自行制定，比如将所有请求信息包一起做一下md5处理之类。

在实际业务请求发起之前，也会根据同样的规则生成requestId。若内存中存在相同requestId对应的PrefetchRecord，那么就相当于匹配成功了。匹配成功后，再根据预请求的状态进行进一步的处理。

预请求状态

预请求状态分为START、FINISH、ABORT，对应“正在发起预请求”、“已经获得预请求结果”、“预请求被抛弃”。ABORT状态下一节再讲。

为什么要记录这个状态呢？因为我们无法保证，预请求的响应一定在实际请求之前。用图来表示：

因为预请求是一个并发行为。当预请求的空中时间特别长，长到目标页面已经发出实际请求了，预请求的响应还没回来，即预请求状态为START，而非FINISH。那么此时该怎么办？我们就需要让实际请求在一旁等着（记录到内存中，RealRequestRecord），等预请求接收到响应了，再根据requestId去进行匹配，匹配到RealRequestRecord了，就触发RealRequestRecord中的回调，返回数据。

另外，在匹配过程中需要注意一点，因为每次路由跳转，如果发起预请求了，总会生成一个Record在内存中等待匹配。因此在匹配结束后，不管是匹配成功还是匹配失败，都要及时释放将Record从内存中释放掉。

超时重试机制

基于实际请求等待预请求响应的场景，我们再延伸一下。若预请求请求超时，迟迟拿不到响应，该怎么办？用图表示：

假设目前的网络请求，端上默认的超时时间是30s。那么在超时场景下，实际的业务请求在30s内若拿不到预请求的结果，就需要重新发起业务请求，抛弃预请求，并将预请求的状态置为ABORT，这样即使后面预请求响应回来了也不做任何处理。

忽然想到一个很贴切的场景来比喻这个预请求方案。

我们把跳转页面理解为去柜台取餐。

预请求代表着我们人还没到柜台，就先远程下单让柜员去准备食物。

如果柜员准备得比较快，那么我们到柜台后就能直接把食物拿走了，就能快点吃上了（代表着页面渲染速度变快）。

如果柜员准备得比较慢，那么我们到柜台后还是得等一会儿才能取餐，但总体上吃上食物的速度还是要比到柜台后再点餐来得快。

但如果这个柜员消极怠工准备得太慢了，我们到柜台等了很久都没拿到食物，那么我们就只能换个柜员重新点了（超时后发起实际的业务请求），同时还不忘投诉一把（预请求空中时间太慢了）。

总结

通过这篇文章，我们知道了什么是接口预请求，怎么实现接口预请求。我们通过配置文件+统一路由处理+预请求发起、匹配、回调，实现了与业务解耦的，可适用于任意页面的轻量级预请求方案，从而提升页面的渲染速度。

从Android Studio Dophin开始，Android Studio中的默认展示了新版的logcat。新版的logcat色彩上是更加的好看了，不同的tag会有不同的颜色，不同level等级的log默认也有不同的颜色。log过滤修改的更简洁了，当然使用起来也更加复杂了。原先的log视图只需要勾选就可以选择不同level的log了，只需要选择只展示当前应用的log就可以过滤掉其他应用的log了，但是新版只提供了一个输入框去过滤。在经过几个月的适应和对于官方文档的学习后，终于熟练使用，这里简单分享一下，让更多人更快入门。

定义自己专属的log view

log view 默认提供了两种视图，Standard View 和Compat View。Stand View会展示每一条log的日期，时间，进程线程id，tag，包名，log level以及message。Compat View只展示时间，log level和详细的message。可以通过log view左边的Configure Logcat Formatting Options按钮来修改，同时这个按钮中还有一个Modify Views选项可以来修改standard和 Compat视图的具体展示内容，可以定制自己的logview样式，如下图所示。

个性化的logcat 视图不仅仅是可以自定义展示的内容，还可以修改log和filter的配色方案。前往Settings(Windows)/Preferences(Mac) ->Editor -> Color Scheme，选择Android Logcat即可修改log 的颜色，选择Logcat Filter即可修改filter的颜色。

以上修改的是logcat view的外表，我们还可以修改它的内核，一个是logcat循环滚动区的大小，以及新logcat window的默认filter，可以通过前往Settings(Windows)/Preferences(Mac) -> Tools -> Logcat 设置。

一些操作技巧

在标准布局下，或者我们的log太长的时候，一屏通常展示不下，我们需要不停的向右滑动，滚动才能看到log的信息，我们可以用log view左侧的Soft-Wrap 按钮来让log换行。

左侧的Clear Logcat按钮可以清空logcat。左侧的Pause按钮可以暂停logcat的输出，方便看错误日志，可以避免关心的日志被新的日志冲掉。

新版本中，可以通过点击logcat tab右侧的New tab 按钮来同时创建多个logcat view窗口。这种方式创建的不能同时展示，而利用logcat view左侧的split Panels 按钮则可以创建多个窗口，并且同时展示。每一个窗口都可以设置自己要展示的连接设备，展示样式，以及过滤选项。这样就可以很方便的同时观察多种log。

通过键值对来过滤Log

新的过滤器，看起来简单，实际上更加复杂且强大了。通过Ctrl+Space按键可以查看系统建议的一些查询列表。这里介绍一下查询中会用到的键：

• tag: 匹配日志的tag字段


• package：匹配记录日志的软件包名，其中特殊值mine匹配当前打开项目对应的应用log。


• process：匹配记录日志的进程名


• message：匹配日志中我们自己填写的message的部分。


• level：与指定或者更高级别的日志匹配，比如debug或者error，输入level后as会自动提示可以选择。


• age：让窗口中只保留最近一段时间的log，值为数字加单位，s表示秒，m表示分钟，h表示小时，d表示天。如age:10s就只保留最近10s的日志。


• is: 这个键有两个固定的value取值，crash匹配应用崩溃日志，stacktrace匹配任意类似java堆栈轨迹的日志，这两个对于看crash查问题是非常好用的。

这么多的键匹配，是可以逻辑组合的。我们可以使用&和|以及圆括号，系统会强制执行常规的运算符优先级。level:ERROR | tag:foo & package:mine 会被强转为level:ERROR | （tag:foo & package:mine ) 。如果我们没有填写逻辑运算符，查询语言会将多个具有相同键的非否定过滤视为OR，其他过滤视为AND。
如：
tag:fa tag:ba package:mine 计算逻辑是 (tag:fa | tag:ba) & package:mine
但tag:fa -tag:ba package:mine 计算逻辑是 tag:fa & -tag:ba & package:mine。这里的-用来表示否定，既tag不包含ba的情况。

新版的logcat view当然也是支持正则的，tag、message、package、process这几项是支持正则的。使用正则需要在键后面加一个~，例如： tag~:My.*Report。
除了正则这个选项之外，这几个键还有完全匹配和包含字符串即可的选项。不加修饰符号就是包含指定的字符串即可匹配。如果后面加=则要完全匹配才可以，例如process=:system_server和process:system_ser可以匹配到system_server的log，但是process=:system_ser则无法匹配到。

同时如上几个匹配选项都支持和前面说的否定符号连用如：-process=:system_server。

既然新版支持了这么复杂和强大过滤功能，如果每次都现想现写，那肯定是头皮发麻。as也为我们提供了收藏和历史记录功能。点击右侧的的星星按钮即可收藏当前的过滤条件，点击左侧的漏斗即可查看历史和收藏，并且可以删除不想要的记录。

切换回旧版log view

最后的最后，如果你觉得新版本适应不了，还是想要切换回旧版本的log view，还想要保留新版的android studio，也还是可以通过修改设置进行切换的。
前往Settings(Windows)/Preferences(Mac) -> Experimental, 反选Enable new logcat tool window 即可，如下图所示。

学习工具的目的，是为了让工具更好的为我们服务。希望大家都能够通过使用as提供的新功能来提高效率，从而有更多的时间去风花雪月。

参考：developer.android.com/studio/debu…

免责声明

本次技术分享仅用于逆向技术的交流与学习，请勿用于其他非法用途；技术是把双刃剑，请善用它。

逆向是什么、可以做什么、怎么做

• 
  

  简单讲，就是将别人打包好的 apk 进行反编译，得到源码并分析代码逻辑，最终达成自己的目的。

  
  


• 
  

  可以做的事：

  
  
  
  
  • 修改 smali 文件，使程序达到自己想要的效果，重新编译签名安装，如去广告、自动化操作、电商薅羊毛、单机游戏修改数值、破解付费内容、汉化、抓包等
  
  
  • 阅读源码，借鉴别人写好的技术实践
  
  
  • 破解：小组件盒子：http://www.coolapk.com/apk/io.ifte…
  
  
  
  


• 
  

  怎么做：

  
  
  
  
  • 这是门庞杂的技术活，需要知识的广度、经验、深度
  
  
  • 需要具体问题，具体分析，有针对性的学习与探索
  
  
  • 了解打包原理、ARM、Smali汇编语言
  
  
  • 加固、脱壳
  
  
  • Xposed、Substrate、Fridad等框架
  
  
  • 加解密
  
  
  • 使用好工具## 今日分享涉及工具
  
  
  
  


• 
  

  apktool：反编译工具

  
  
  
  
  • 反编译：apktool d <apkPath> o <outputPath>
  
  
  • 重新打包：apktool b <fileDirPath> -o <apkPath>
  
  
  • 安装：brew install apktool
  
  
  
  


• 
  

  jadx：支持命令行和图形界面，支持apk、dex、jar、aar等格式的文件查看

  
  
  
  
  • github.com/skylot/jadx
  
  
  
  


• 
  

  apksigner：签名工具

  
  
  
  
  • developer.android.com/studio/comm…
  
  
  
  


• 
  

  Charles：抓包工具

  
  
  
  
  • http://www.charlesproxy.com/
  
  
  • Android 7 以上抓包 HTTPS ，需要手机 Root 后将证书安装到系统中
  
  
  • Android 7 以下 HTTPS 直接抓
  
  
  
  

正题

• 
  

  正向编译

  
  
  
  
  • java -> class -> dex -> apk
  
  
  
  


• 
  

  反向编译

  
  
  
  
  • apk -> dex -> smali -> java
  
  
  
  


• 
  

  Smali 是 Android 的 Dalvik 虚拟机所使用的一种 dex 格式的中间语言

  
  


• 
  

  官方文档source.android.com/devices/tec…

  
  


• 
  

  code.flyleft.cn/posts/ac692…

  
  


• 
  

  正题开始，以反编译某瓣App为例：

  
  
  
  
  • 
    

    jadx 查看 Java 源码，找到想修改的代码

    
    
  
  
  • 
    

    反编译得到 smali 源码：apktool d douban.apk -o doubancode --only-main-classes

    
    
  
  
  • 
    

    修改：找到 debug 界面入口并打开

    
    
  
  
  • 
    

    将修改后的 smali 源码正向编译成 apk：apktool b doubancode -o douban_mock1.apk

    
    
  
  
  • 
    

    重签名：jarsigner -verbose -keystore keys.jks test.apk key0

    
    
  
  
  • 
    

    此时的包不能正常访问接口，因为豆瓣 API 做了签名校验，而我们的新 apk 是用了新的签名，看接口抓包

    
    
  
  
  • 
    

    怎么办呢？

    
    
  
  
  • 
    

    继续分析代码，修改网络请求中的 apikey

    
    
  
  
  • 
    

    来看看新的 apk

    
    
  
  
  
  


• 
  

  也可以做爬虫等

  
  

启发与防范

• 混淆


• 加固


• 加密


• 运行环境监测


• 不写敏感信息或操作到客户端


• App 运行签名验证


• Api 接口签名验证

One More Thing

• 
  

  工具分享：code.flyleft.cn/posts/3e3d8…

  
  


• 
  

  书籍分享：book.douban.com/subject/205…

  
  


• 
  

  进阶(下次分享)：

  
  
  
  
  • 静态调试
  
  
  • 动态调试
  
  
  • 脱壳
  
  
  • NDK你想
  
  
  • so文件修改

转眼时间已经到2月下旬了，按照往年各个公司的招聘进度，估计近期各个公司的春招就会开启了。

春招作为校招生们求职的黄金时间，把握好金三银四的招聘季，不仅可以为金九银十的秋招做好铺垫，运气好的话可以直接通过实习转正一步到位免去秋招。

因此，准备在春招中大显身手的朋友，也该把写简历提上日程了！

为什么要写简历

简历作为求职者的名片，是HR衡量求职者岗位匹配度的重要因素，也是面试前留给面试官的第一印象。

一份内容丰富、排版精美的简历不仅可以增大简历筛选的通过率，也能让面试官在面试中更愿意去挖掘出你的闪光点。

毕竟求职者有没有用心、求职意愿是否强烈都是可以从简历中窥探一二的！

与此同时，一份排版混乱、内容随意的简历，如果被石沉大海也就情有可原了。

毕竟简历代表的是一种态度！

如何写简历

简历的目的是向HR和面试官清晰展示自己是否与岗位匹配。

一份简历的制作，通常需要从格式和内容两个方面来考虑。

格式

一份还算不错的简历格式应该考虑到如下几个因素：

最近帮一些同学修改简历，我发现很多同学的简历在排版方面存在如下几个方面的问题：

x 简历色彩太多

理解大家想要突出亮点的心情。但是过于花里胡哨可能会分散阅读者的注意力，从而导致适得其反的结果。

x 内容没有边距

很多同学的经历很丰富，想在简历中充分展现自我，因此密密麻麻写了很多内容。但没有突出亮点，也没有合理的设置边距，这可能会给阅读者带来不好的阅读体验。

x 个人照过于随意

为了在视觉上给招聘官良好的印象，很多同学会放自己的一寸照片在简历上。诚然，良好的求职形象是一个加分项，但是在照片的选择上，大家应该以合适出发，生活照和艺术照确实不太适合在简历上出现。

负责招聘的HR一天可能要阅读上百上千份简历，视觉上的体验也是写简历时需要考虑的因素。

对于理工科的同学们来说，简历排版可能是大家不擅长或者不太care的点，其实目前市面上有很多制作简历的网站，大家可以去这些平台选择合适的模板！

内容

如果说简历的格式只是起到印象分的作用，那么简历的内容就是简历能否选中的决定性因素了！

记得之前去线下招聘会应聘时，HR在拿到我的简历后，手上的笔一直在简历上圈重点，包括我的教育背景、求职意向、实习经历、项目经历、获奖情况等等...

现在回想起来，这应该就是大家常说的star法则吧！

因此，强烈建议大家按照star法则来填充自己简历的内容：

具体到简历中的每个模块，需要包含的内容有以下几个方面：

01 基本信息&求职意向（非常重要）

基本信息是HR联系求职者的主要途径，而求职意向则是岗位匹配度的重要衡量标准。

02 教育背景

成绩好的同学可以放上自己的绩点&排名，学校好的同学可以标注985、211。

03 自我评价&技术栈

自我评价是从性格方面展示求职者的岗位匹配度，技术栈是从能力上体现求职者实力。

对于致力于从事技术岗位的同学，可以在技术栈部分展示出自己的能力。

比如：熟练掌握原生 HTML、CSS、JavaScript 的使用，熟悉 React 框架、了解 Webpack、 TypeScript，熟练使用代码托管工具 Git等等。

如果有持续更新的技术博客或者开源项目，也可以在这里用数字量化加粗体现访问量和star数...

04 实习经历&项目经历（篇幅至少占3/5）

某种程度上说，有和求职岗位相匹配的大厂实习背景的同学在简历筛选中会更容易通过。

如果没有实习经历，有和求职岗位相匹配的项目经历也是star之一。

因为实习经历本质上也是项目经历。

在表述项目经历时，应重点突出自己的工作内容及成果，按照star原则写出技术难点和技术亮点，并量化展示成果，减少口水话的表述。

05 获奖经历和校园经历

获奖经历是软实力的体现， 如果在求职岗位所在的领域获得过有含金量的证书，会给阅读者留下更好的印象。或者在校期间拿到过学业奖学金，也是软实力的体现哦~

总结

一份好的简历，通常会经历多次打磨。

在这期间，我们也可以根据简历来进行阶段性的有效复盘，找出自己的亮点和待提升点，并在下一个版本中进一步提高。

与此同时，建议大家将每个版本的简历保存为word和pdf两个版本。word版本便于进一步修改简历，pdf版本用于求职投递, 防止因设备问题导致格式错乱!

闲言碎语

今天回了趟家里，陪父母一起吃了个饭。父母照例是在唠叨，这个年纪了还不结婚，也没个稳定的工作，巴拉巴拉的一大堆。吃完饭我匆匆的就回到了我租住的地方。在现阶段，其实我对于父母所诉说的很多东西，我都是认同的。

但在我这个年纪，这个阶段，看似有很多选择，但其实我没有选择。能做的也只是多挣点钱。

在这个信息爆炸的时代，我们知道更高的地方在哪里。但当你想要再往上走一步的时候，你发现你的上限，其实从出生或从你毕业的那一刻就已经注定了。可能少部分人通过自身的努力，的确能突破壁垒达到理想的高度。但这只是小概率事件罢了。在我看来整个社会的发展，其实早就已经陷入了一种怪圈。

在我，早些年刚刚进入社会的时候。那时的想法特别简单。就想着努力工作，努力提升自身的专业素养。被老板赏识，升职加薪成为一名管理者。如果，被淘汰了那应该是自己不够优秀，不够努力，专业技能不过硬，自己为人处事不够圆滑啥的。

当内卷这个词语引爆网络的时候；当35岁被裁员成为常态的时候。再回头看我以前的那些想法那真的是一个笑话。（我觉得我可能是在为自己被淘汰找借口）

当前的状态

游戏工作室的项目，目前基本处于停滞的状态。我不敢加机器也不敢关机。有时候我都在想，是不是全中国那3-4亿的人都在搞这个？一个国外的游戏，金价直接拉成这个逼样。

汽配这边的话，只能说喝口稀饭。（我花了太多精力在游戏工作室上了）

梦想破灭咯

其实按照正常情况来说，游戏工作室最开始的阶段，我应该是能够稍微挣点钱的。我感觉我天时、地利、人和。我都占的。现在来看的话，其实我只占了人和。我自己可以编码，脚本还是从驱动层模拟键鼠，写的一套脚本。这样我都没赚钱，我擦勒。

接下来干嘛

接下来准备进厂打螺丝。（开玩笑的）
还是老老实实跟着我弟学着做生意吧。老老实实做汽配吧！在这个时代，好像有一技之长（尤其是IT）的人，好像并不能活得很好。除非，你这一技之长，特别特别长。（当下的中国不需要太多的这类专业技术人员吧。）

我感受到的大环境

我身边有蛮多的大牛。从他们的口中和我自己看到的。我感觉在IT这个领域，国内的环境太恶劣了。在前端，除开UI库，我用到的很多多的库全是老外的。为什么没有国人开源呢？因为，国人都忙着996了。我们可以在什么都不知道的情况下，通过复制粘贴，全局搜索解决大部分问题。 机械视觉、大数据分析、人工智能 等很多东西。这一切的基石很多年前就有了，为什么没人去研究他？为什么我们这波人，不断的在学习：这样、那样的框架。搭积木虽然很好玩。但创造一个积木，不应该也是一件更有挑战性的事情么？

在招聘网站还有一个特别奇怪的现象。看起来这家公司是在招人，但其实是培训机构。 看起来这家公司正儿八经是在招聘兼职，但其实只想骗你去办什么兼职卡。看起来是在招送快递，送外卖的，招聘司机的，但其实只是想套路你买车。我擦勒。这是怎样的一个恶劣的生存环境。这些个B人就不能干点，正经事？

卖菜的、拉车的、搞电商的、搞短视频、搞贷款的、卖保险的、这些个公司市值几百亿。很难看到一些靠创新，靠创造，靠产品质量，发展起来的公司。

前言

有一个经典的问题，我们在Activity的onCreate中可以获取View的宽高吗？onResume中呢？

对于这类八股问题，只要看过都能很容易得出答案：不能。

紧跟着追问一个，那为什么View.post为什么可以获取View宽高？

今天来看看这些问题，到底为何？

今日份问题：

0. 为什么onCreate和onResume中获取不到view的宽高？


1. 为什么View.post为什么可以获取View宽高？

基于Android API 29版本。

问题1、为什么onCreate和onResume中获取不到view的宽高?

首先我们清楚，要拿到View的宽高，那么View的绘制流程（measure—layout—draw）至少要完成measure，【记住这一点】。

还要弄清楚Activity的生命周期，关于Activity的启动流程，后面单独写一篇，本文会带一部分。

另外布局都是通过setContentView(int)方法设置的，所以弄清楚setContentView的流程也很重要，后面也补一篇。

首先要知道Activity的生命周期都在ActivityThread中, 当我们调用startActivity时，最终会走到ActivityThread中的performLaunchActivity

    private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {

        ……

        Activity activity = null;

        try {

            java.lang.ClassLoader cl = appContext.getClassLoader();

          // 【关键点1】通过反射加载一个Activity

            activity = mInstrumentation.newActivity(

                    cl, component.getClassName(), r.intent);

           ……

        } catch (Exception e) {

            ……

        }



        try {

            ……



            if (activity != null) {

                ……

                // 【关键点2】调用attach方法，内部会初始化Window相关信息

                activity.attach(appContext, this, getInstrumentation(), r.token,

                        r.ident, app, r.intent, r.activityInfo, title, r.parent,

                        r.embeddedID, r.lastNonConfigurationInstances, config,

                        r.referrer, r.voiceInteractor, window, r.configCallback,

                        r.assistToken);



                ……

                  

                if (r.isPersistable()) {

                  // 【关键点3】调用Activity的onCreate方法

                    mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);

                } else {

                    mInstrumentation.callActivityOnCreate(activity, r.state);

                }

                ……

            }

            ……

        return activity;

    }

performLaunchActivity中主要是创建了Activity对象，并且调用了onCreate方法。

onCreate流程中的setContentView只是解析了xml，初始化了DecorView，创建了各个控件的对象；即将xml中的 转化为一个TextView对象。并没有启动View的绘制流程。

上面走完了onCreate，接下来看onResume生命周期，同样是在ActivityThread中的performResumeActivity

    @Override

    public void handleResumeActivity(IBinder token, boolean finalStateRequest, boolean isForward,

            String reason) {

        ……

        // 【关键点1】performResumeActivity 中会调用activity的onResume方法

        final ActivityClientRecord r = performResumeActivity(token, finalStateRequest, reason);

        ……

          

        final Activity a = r.activity;



        ……

          

        if (r.window == null && !a.mFinished && willBeVisible) {

            r.window = r.activity.getWindow();

            View decor = r.window.getDecorView();

            decor.setVisibility(View.INVISIBLE); // 设置不可见

            ViewManager wm = a.getWindowManager();

            WindowManager.LayoutParams l = r.window.getAttributes();

            a.mDecor = decor;

            ……

              

            if (a.mVisibleFromClient) {

                if (!a.mWindowAdded) {

                    a.mWindowAdded = true;

                  // 【关键点2】在这里，开始做View的add操作

                    wm.addView(decor, l); 

                } else {

                    ……

                    a.onWindowAttributesChanged(l);

                }

            }



            

        } else if (!willBeVisible) {

           ……

        }

       ……

    }

handleResumeActivity中两个关键点

0. 调用performResumeActivity, 该方法中r.activity.performResume(r.startsNotResumed, reason);会调用Activity的onResume方法。


1. 执行完Activity的onResume后调用了wm.addView(decor, l);，到这里，开始将此前创建的DecorView添加到视图中，也就是在这之后才开始布局的绘制流程

到这里，我们应该就能理解，为何onCreate和onResume中无法获取View的宽高了，一句话就是：View的绘制要晚于onResume。

问题2、为什么View.post为什么可以获取View宽高？

那接下来我们开始看第二个问题，先看看View.post的实现。

    public boolean post(Runnable action) {

        final AttachInfo attachInfo = mAttachInfo;

        // 添加到AttachInfo的Handler消息队列中

        if (attachInfo != null) {

            return attachInfo.mHandler.post(action);

        }



        // 加入到这个View的消息队列中

        getRunQueue().post(action);

        return true;

    }

post方法中，首先判断attachInfo成员变量是否为空，如果不为空，则直接加入到对应的Handler消息队列中。否则走getRunQueue().post(action);

从Attach字面意思来理解，其实就可以知道，当View执行attach时，才会拿到mAttachInfo, 因此我们在onResume或者onCreate中调用view.post()，其实走的是getRunQueue().post(action)。

接下来我们看一下mAttachInfo在什么时机才会赋值。

在View.java中

void dispatchAttachedToWindow(AttachInfo info, int visibility) {

    mAttachInfo = info;

}

dispatch相信大家都不会陌生，分发；那么一定是从根布局上开始分发的，我们可以全局搜索，可以看到

不要问为什么一定是这个，因为我看过，哈哈哈

其实ViewRootImpl就是一个布局管理器，这里面有很多内容，可以多看看。

在ViewRootImpl中直接定位到performTraversals方法中；这个方法一定要了解，而且特别长，下面我抽取几个关键点。

    private void performTraversals() {

      ……

      // 【关键点1】分发mAttachInfo

      host.dispatchAttachedToWindow(mAttachInfo, 0);

      ……

        

      //【关键点2】开始测量

      performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);

      ……

      //【关键点3】开始布局

      performLayout(lp, mWidth, mHeight);

      ……

      // 【关键点4】开始绘制

      performDraw();

      ……

    }

再强调一遍，这个方法很长，内部很多信息，但其实总结来看，就是View的绘制流程，上面的【关键点2、3、4】。也就是这个方法执行完成之后，我们就能拿到View的宽高了；到这里，我们终于看到和View的宽高相关的东西了。

但还没结束，我们post出去的任务，什么时候执行呢，上面host可以看成是根布局，一个ViewGroup，通过一层一层的分发，最后我们看看View的dispatchAttachedToWindow方法。

 void dispatchAttachedToWindow(AttachInfo info, int visibility) {

     mAttachInfo = info;

     ……

     // Transfer all pending runnables.

     if (mRunQueue != null) {

         mRunQueue.executeActions(info.mHandler);

         mRunQueue = null;

     }

}

这里可以看到调用了mRunQueue.executeActions(info.mHandler);

public void executeActions(Handler handler) {

    synchronized (this) {

        final HandlerAction[] actions = mActions;

        for (int i = 0, count = mCount; i < count; i++) {

            final HandlerAction handlerAction = actions[i];

            handler.postDelayed(handlerAction.action, handlerAction.delay);

        }



        mActions = null;

        mCount = 0;

    }

}

这就很简单了，就是将post中的Runnable，转移到mAttachInfo中的Handler, 等待接下来的调用执行。

这里要结合Handler的消息机制，我们post到Handler中的消息，并不是立刻执行，不要认为我们是先dispatchAttachedToWindow的，后执行的测量和绘制，就没办法拿到宽高。实则不是，我们只是将Runnable放到了handler的消息队列，然后继续执行后面的内容，也就是绘制流程，结束后，下一个主线程任务才会去取Handler中的消息，并执行。

结论

0. onCreate和onResume中无法获取View的宽高，是因为还没执行View的绘制流程。


1. view.post之所以能够拿到宽高，是因为在绘制之前，会将获取宽高的任务放到Handler的消息队列，等到View的绘制结束之后，便会执行。

水平有限，若有不当，请指出！！！

背景

一、接手

7 月份组织架构调整后，我们组接手了搜索链路中的 Query 理解基础模块，包括本次重构对象 Query Optimizer，负责 query 的分词、词权、紧密度、意图识别。

二、为什么重构

面对一份 10年+ 历史包袱较重的代码，大多数开发者认为“老项目和人有一个能跑就行”，不愿意对其做较大的改动，而我们选择重构，主要有这些原因：

1.生产工具落后，无法使用现代 C++，多项监控和 TRACE 能力缺失

2.单进程内存消耗巨大——114G

3.服务不定期出现耗时毛刺

4.进程启动需要 18 分钟

5.研效低下，一个简单的功能需要开发 3 人天

基于上述原因，也缘于我们热爱挑战、勇于折腾，我们决定进行拆迁式的重构。

编码实现

一、重写与复用

我们对老 QO 的代码做分析，综合考虑三个因素：是否在使用、是否Query理解功能、是否高频迭代，将代码拆分为四种处理类型：1、删除；2、lib库引入；3、子仓库引入；4、重写引入。

二、整体架构

老服务代码架构堪称灾难，整体遵守“想到哪就写到哪，需要啥就拷贝啥”的设计原则，完全不考虑单一职责、接口隔离、最少知识、模块化、封装复用等。下图介绍老服务的抽象架构：

请求进来先后执行 3 次分词：

1.不带标点符号的分词结果，用于后续紧密度词权算子的计算输入；

2.带标点符号的分词结果，用于后续基于规则的意图算子的计算输入；

3.不带标点符号的分词结果，用于最终结果 XML queryTokens 字段的输出。

1 和 3 的唯一区别，就是调用内核分词的代码位置不同。

下一个环节，请求 Query 分词时，分词接口中竟然包含了 RPC 请求下游 GPU 模型服务获取意图。这是此服务迭代最频繁的功能块，当想要实验模型调整、增减意图时，需要在 QO 仓库进行实验参数解析，将参数万里长征传递到 word_segmentor 仓库的分词接口里，再根据参数修改 RPC 意图调用逻辑。一个简单参数实验，要修改 2个仓库中的多个模块。设计上不符合模块内聚的设计原理，会造成霰弹式代码修改，影响迭代效率，又因为 Query 分词是处理链路中的耗时最长步骤，不必要的串行增加了服务耗时，可谓一举三失。

除此之外，老服务还有其他各类问题：多个函数超过一千行，圈复杂度破百，接口定义 50 多个参数并且毫无注释，代码满地随意拷贝，从以下 CodeCC 扫描结果可见一斑：

新的服务求追架构合理性，确保：

1.类和函数实现遵守单一职责原则，功能内聚；

2.接口设计符合最少知识原则，只传入所需数据；

3. 每个类、接口都附上功能注释，可读性高。

项目架构如下：

CodeCC 扫描结果：

三、核心实现

老服务的请求处理流程：

老服务采用的是原始的线程池模型。服务启动时初始化 20 条线程，每条线程分别持有自身的分词和意图对象，监听任务池中的任务。服务接口收到请求则投入任务池，等待任意一条线程处理。单个请求的处理基本是串行执行，只少量并行处理了几类意图计算。

新服务中，我们实现了一套基于 tRPC Fiber 的简单 DAG 控制器：

1.用算子数初始化 FiberLatch，初始化算子任务间的依赖关系

2.StartFiberDetached 启动无依赖的算子任务，FiberLatch Wait 等待全部算子完成

3.算子任务完成时，FiberLatch -1 并更新此算子的后置算子的前置依赖数

4.计算前置依赖数规 0 的任务，StartFiberDetached 启动任务

通过 DAG 调度，新服务的请求处理流程如下，最大化的提升了算子并行度，优化服务耗时：