使用 Kotlin 进行开发，对于 latelinit 和 lazy 肯定不陌生。但其原理上的区别，可能鲜少了解过，借着本篇文章普及下这方面的知识。

lateinit

用法

非空类型可以使用 lateinit 关键字达到延迟初始化。

 class InitTest() {

     lateinit var name: String

 

     public fun checkName(): Boolean = name.isNotEmpty()

 }

如果在使用前没有初始化的话会发生如下 Exception。

 AndroidRuntime: FATAL EXCEPTION: main

      Caused by: kotlin.UninitializedPropertyAccessException: lateinit property name has not been initialized

         at com.example.tiramisu_demo.kotlin.InitTest.getName(InitTest.kt:4)

         at com.example.tiramisu_demo.kotlin.InitTest.checkName(InitTest.kt:10)

         at com.example.tiramisu_demo.MainActivity.testInit(MainActivity.kt:365)

         at com.example.tiramisu_demo.MainActivity.onButtonClick(MainActivity.kt:371)

         ...

为防止上述的 Exception，可以在使用前通过 ::xxx.isInitialized 进行判断。

 class InitTest() {

     lateinit var name: String

 

     fun checkName(): Boolean {

         return if (::name.isInitialized) {

             name.isNotEmpty()

         } else {

             false

         }

     }

 }

 Init: testInit():false

当 name 初始化过之后使用亦可正常。

 class InitTest() {

     lateinit var name: String

 

     fun injectName(name: String) {

         this.name = name

     }

 

     fun checkName(): Boolean {

         return if (::name.isInitialized) {

             name.isNotEmpty()

         } else {

             false

         }

     }

 }

 Init: testInit():true

原理

反编译之后可以看到该变量没有 @NotNull 注解，使用的时候要 check 是否为 null。

 public final class InitTest {

    public String name;

        

    @NotNull

    public final String getName() {

       String var10000 = this.name;

       if (var10000 == null) {

          Intrinsics.throwUninitializedPropertyAccessException("name");

       }

 

       return var10000;

    }

 

     public final boolean checkName() {

       String var10000 = this.name;

       if (var10000 == null) {

          Intrinsics.throwUninitializedPropertyAccessException("name");

       }

 

       CharSequence var1 = (CharSequence)var10000;

       return var1.length() > 0;

    }

 }

null 则抛出对应的 UninitializedPropertyAccessException。

 public class Intrinsics {

     public static void throwUninitializedPropertyAccessException(String propertyName) {

         throwUninitializedProperty("lateinit property " + propertyName + " has not been initialized");

     }

 

     public static void throwUninitializedProperty(String message) {

         throw sanitizeStackTrace(new UninitializedPropertyAccessException(message));

     }

 

     private static <T extends Throwable> T sanitizeStackTrace(T throwable) {

         return sanitizeStackTrace(throwable, Intrinsics.class.getName());

     }

 

     static <T extends Throwable> T sanitizeStackTrace(T throwable, String classNameToDrop) {

         StackTraceElement[] stackTrace = throwable.getStackTrace();

         int size = stackTrace.length;

 

         int lastIntrinsic = -1;

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

             if (classNameToDrop.equals(stackTrace[i].getClassName())) {

                 lastIntrinsic = i;

             }

         }

 

         StackTraceElement[] newStackTrace = Arrays.copyOfRange(stackTrace, lastIntrinsic + 1, size);

         throwable.setStackTrace(newStackTrace);

         return throwable;

     }

 }

 

 public actual class UninitializedPropertyAccessException : RuntimeException {

     ...

 }

如果是变量是不加 lateinit 的非空类型，定义的时候即需要初始化。

 class InitTest() {

     val name: String = "test"

 

     public fun checkName(): Boolean = name.isNotEmpty()

 }

在反编译之后发现变量多了 @NotNull 注解，可直接使用。

 public final class InitTest {

    @NotNull

    private String name = "test";

 

    @NotNull

    public final String getName() {

       return this.name;

    }

 

    public final boolean checkName() {

       CharSequence var1 = (CharSequence)this.name;

       return var1.length() > 0;

    }

 }

::xxx.isInitialized 的话进行反编译之后可以发现就是在使用前进行了 null 检查，为空直接执行预设逻辑，反之才进行变量的使用。

 public final class InitTest {

    public String name;

    ...

    public final boolean checkName() {

       boolean var2;

       if (((InitTest)this).name != null) {

          String var10000 = this.name;

          if (var10000 == null) {

             Intrinsics.throwUninitializedPropertyAccessException("name");

          }

 

          CharSequence var1 = (CharSequence)var10000;

          var2 = var1.length() > 0;

       } else {

          var2 = false;

       }

 

       return var2;

    }

 }

lazy

用法

lazy 的命名和 lateinit 类似，但使用场景不同。其是用于懒加载，即初始化方式已确定，只是在使用的时候执行。而且修饰的只是能是 val 常量。

 class InitTest {

     val name by lazy {

         "test"

     }

     

     public fun checkName(): Boolean = name.isNotEmpty()

 }

lazy 修饰的变量可以直接使用，不用担心 NPE。

 Init: testInit():true

原理

上述是 lazy 最常见的用法，反编译之后的代码如下：

 public final class InitTest {

    @NotNull

    private final Lazy name$delegate;

 

    @NotNull

    public final String getName() {

       Lazy var1 = this.name$delegate;

       return (String)var1.getValue();

    }

 

    public final boolean checkName() {

       CharSequence var1 = (CharSequence)this.getName();

       return var1.length() > 0;

    }

 

    public InitTest() {

       this.name$delegate = LazyKt.lazy((Function0)null.INSTANCE);

    }

 }

所属 class 创建实例的时候，实际分配给 lazy 变量的是 Lazy 接口类型，并非 T 类型，变量会在 Lazy 中以 value 暂存，当使用该变量的时候会获取 Lazy 的 value 属性。

Lazy 接口的默认 mode 是 LazyThreadSafetyMode.SYNCHRONIZED，其默认实现是 SynchronizedLazyImpl，该实现中 _value 属性为实际的值，用 volatile 修饰。

value 则通过 get() 从 _value 中读写，get() 将先检查 _value 是否尚未初始化

• 
  

  已经初始化过的话，转换为 T 类型后返回

  
  


• 
  

  反之，执行同步方法（默认情况下 lock 对象为 impl 实例），并再次检查是否已经初始化：

  
  
  
  
  • 已经初始化过的话，转换为 T 类型后返回
  
  
  • 反之，执行用于初始化的函数 initializer，其返回值存放在 _value 中，并返回
  
  
  
  

 public actual fun <T> lazy(initializer: () -> T): Lazy<T> = SynchronizedLazyImpl(initializer)

 

 private class SynchronizedLazyImpl<out T>(initializer: () -> T, lock: Any? = null) : Lazy<T>, Serializable {

     private var initializer: (() -> T)? = initializer

     @Volatile private var _value: Any? = UNINITIALIZED_VALUE

     // final field is required to enable safe publication of constructed instance

     private val lock = lock ?: this

 

     override val value: T

         get() {

             val _v1 = _value

             if (_v1 !== UNINITIALIZED_VALUE) {

                 @Suppress("UNCHECKED_CAST")

                 return _v1 as T

             }

 

             return synchronized(lock) {

                 val _v2 = _value

                 if (_v2 !== UNINITIALIZED_VALUE) {

                     @Suppress("UNCHECKED_CAST") (_v2 as T)

                 } else {

                     val typedValue = initializer!!()

                     _value = typedValue

                     initializer = null

                     typedValue

                 }

             }

         }

 

     override fun isInitialized(): Boolean = _value !== UNINITIALIZED_VALUE

 

     override fun toString(): String = if (isInitialized()) value.toString() else "Lazy value not initialized yet."

 

     private fun writeReplace(): Any = InitializedLazyImpl(value)

 }

总之跟 Java 里双重检查懒汉模式获取单例的写法非常类似。

 public class Singleton {

     private static volatile Singleton singleton;

 

     private Singleton() {

     }

 

     public static Singleton getInstance() {

         if (singleton == null) {

             synchronized (Singleton.class) {

                 if (singleton == null) {

                     singleton = new Singleton();

                 }

             }

         }

         return singleton;

     }

 }

lazy 在上述默认的 SYNCHRONIZED mode 下还可以指定内部同步的 lock 对象。

     val name by lazy(lock) {

         "test"

     }

lazy 还可以指定其他 mode，比如 PUBLICATION，内部采用不同于 synchronized 的 CAS 机制。

     val name by lazy(LazyThreadSafetyMode.PUBLICATION) {

         "test"

     }

lazy 还可以指定 NONE mode，线程不安全。

     val name by lazy(LazyThreadSafetyMode.NONE) {

         "test"

     }

the end

lateinit 和 lazy 都是用于初始化场景，用法和原理有些区别，做个简单总结：

lateinit 用作非空类型的初始化：

• 在使用前需要初始化


• 如果使用时没有初始化内部会抛出 UninitializedPropertyAccess Exception


• 可配合 isInitialized 在使用前进行检查

lazy 用作变量的延迟初始化：

• 定义的时候已经明确了 initializer 函数体


• 使用的时候才进行初始化，内部默认通过同步锁和双重校验的方式返回持有的实例


• 还支持设置 lock 对象和其他实现 mode

1. 前言

上一篇 《桌面导航 NavigationRail》 中介绍了官方的桌面导航，但整体灵活性并不是太好，风格我也不是很喜欢。看到飞书桌面端的导航栏可以支持拖拽排序，感觉挺有意思。而且排序之后，下次进入时会使用该顺序，而且在其他设备上也会同步该配置顺序。这说明用户登录时会从服务器获取配置信息，作为导航栏的状态数据决定显示。

本文我们将来探讨两个问题：

• 第一：如何将导航栏的数据变得 可配置。


• 第二：如何实现 拖拽 更改导航栏位置。

2.整体静态界面布局：

首先，我们先来对整体结构进行一下静态布局，也就是先抛开交互逻辑，对整体结构进行一下划分。整体是一个 上下 结构，下方是 导航栏 + 内容 的左右结构：

下面是对静态界面结构的简单仿写，本文主要介绍导航栏的交互实现，其他内容暂时忽略。以后有机会可以慢慢展开来说。

代码如下，整体界面的呈现由 AppNavigation 负责。通过 Column 实现上下结构，上面是 TopBar ，下面是通过 Expanded 包裹，可以让内容填充剩余部分。下方通过 Row 实现左右结构，左侧是今天的主角 LeftNavigationBar 组件，右侧是一个暂时空白的内容。

class AppNavigation extends StatelessWidget {

  const AppNavigation({Key? key}) : super(key: key);



  @override

  Widget build(BuildContext context) {

    return Scaffold(

      body: Column(

        children: [

          const TopBar(),

          Expanded(

              child: Row(

            children: const [

              LeftNavigationBar(),

              // TODO 主题内容构建

              Expanded(child: SizedBox.shrink()),

            ],

          ))

        ],

      ),

    );

  }

}

所以整体结构还是很简单的，通过 Expanded 组件，可以让指定的区域具有 “延展性” 。比如下面，当窗口尺寸变化时，中间的区域会自动收缩，而头部栏和导航栏不会受到影响。

3. 导航栏布局实现

导航栏是自定义的 LeftNavigationBar 组件，是一个上下结构：Logo 在最底端，LeftNavigationMenu 菜单在上方。这里的 Spacer 相当于一个占位组件，其高度为 Column 的剩余部分，也就是会 “撑开” 区域，在窗口高度发生变化时，这块区域会自动延展，来保证 Logo 始终在下方。

界面上呈现的内容，都有其对应的数据载体。这里先简单定义一个 LeftNavigationBarItem 的实体类，用于记录图标和标题信息。另外 id 用于菜单的唯一标识，因为后面要涉及到菜单位置的交换，不能靠索引进行标识：

class LeftNavigationBarItem {

  final int id;

  final IconData icon;

  final String label;



  const LeftNavigationBarItem({

    required this.icon,

    required this.label,

    required this.id,

  });

}

LeftNavigationMenu 组件中接收 LeftNavigationBarItem 列表数据。通过 Column 组件进行竖直排布，另外把每个菜单的单体抽离为 LeftNavigationBarItemWidget 组件方便维护：

class LeftNavigationMenu extends StatelessWidget {

  final List<LeftNavigationBarItem> items;



  const LeftNavigationMenu({Key? key, required this.items}) : super(key: key);



  @override

  Widget build(BuildContext context) {

    return Column(

      children: items

          .map((e) => LeftNavigationBarItemWidget( item: e ))

          .toList(),

    );

  }

}

对于导航栏而言，鼠标悬浮一般会有一个临时的激活状态。外界并不需要用到这个状态，所以可以将 LeftNavigationBarItemWidget 组件定义为 StatefulWidget ，来维护悬浮时的内部状态变化。

如下，在单体的组件状态类中定义 _hovering 私有状态量，通过 InkWell 监听悬浮的变化。由于这里是单独抽离的 LeftNavigationBarItemWidget 组件，所以这里在 _onHover 中触发的 setState 只会对局部组件进行构建。在构建时，根据 active 状态创建不同样式的条目即可。

4. 菜单的点击激活状态管理

界面上呈现的内容，都有其对应的数据载体，菜单的点击激活也不例外。比如你在飞书中点击了一个菜单，变成激活态，就表示在内存中一定对某个菜单的激活数据信息进行了变动，并重新渲染。我们想实现点击更换激活菜单，也是一样。需要考虑的只有两件事：

• 如何 记录 和 维护 数据的变化。


• 如何在数据变化后触发更新。

状态管理的工具多种多样，但都不会脱离这两件本质的工作，不同的只是用法的形式而已。不必为了一些表面的功夫争论不休，而忽略问题的本质，适合自己就是好的。其实 State 类本身也是一种状态管理的工具，也有维护数据变化和触发更新的特定性，只不过处理较深层级间的共享数据时比较麻烦。

关于这一点，在上次掘金直播中进行过介绍，感兴趣的可以去看一下 回放 。由于没有什么直播经验，所以那次显得很紧张，不过想分享的核心知识还是都介绍到的。

这里用我比较熟悉的 flutter_bloc 来对激活菜单数据进行管理。现在引入 Cubit 后，对于小的数据进行管理变得非常方便。比如下面的 NavSelectionCubic ，只用 4 行代码就能实现对 激活菜单 id 的管理：

class NavSelectionCubic extends Cubit<int> {

  NavSelectionCubic({int id = 1}) : super(id);



  void selectMenu(int id) {

    emit(id);

  }

}

上面完成了 记录 和 维护 数据的变化，那接下来的重点就是：如何在数据变化后触发更新。通过 BlocBuilder 可以在变化到新状态时，触发 builder 回调，重新构建局部组件，实现局部刷新。

在点击菜单是，触发 NavSelectionCubic 的 selectMenu 方法，更新状态数据即可。这样就可以实现如下效果：点击某个菜单，变为激活状态：

---->[_LeftNavigationBarItemWidgetState#_onTap]----

void _onTap() {

  BlocProvider.of<NavSelectionCubic>(context).selectMenu(widget.item.id);

}

5. 菜单数据的状态管理

我们现在的菜单数据是写死的，对于可拖拽的功能，需要对这些数据进行修改和触发更新。所以菜单数据本身也就上升为了需要管理的状态。对菜单数据状态进行管理，还有个好处：可以动态的修改菜单，比如不同角色的显示不同的菜单，只要根据角色维护数据即可。

这里再定义一个 NavMenuCubic 用于管理菜单数据，状态量是 NavMenus ，其中维护着 LeftNavigationBarItem 的列表。这样在拖拽时，执行 switchMenu 方法，进行拖拽菜单数据交换，再产出新的状态，即可完成需求。

class NavMenuCubic extends Cubit<NavMenus> {

  NavMenuCubic({required List<LeftNavigationBarItem> item}) : super(NavMenus(menus:item ));



  void switchMenu(int dragId, int targetId) {

    // TODO 处理拖拽菜单数据交换

  }

}



class NavMenus{

  final List<LeftNavigationBarItem> menus;



  const NavMenus({required this.menus});



}

另外说一点，导航模块使用了两个 Bloc ，可以单独抽离一个组件进行包裹 BlocProvider，这样其子树的上下文中才可以访问到相关的 Bloc。比如下面的 _NavigationScope ，这里的菜单数据直接给出，其实也可以通过服务端记录这些配置数据，在登录时读取进行初始化：

class _NavigationScope extends StatelessWidget {

  const _NavigationScope({Key? key}) : super(key: key);



  final List<LeftNavigationBarItem> items = const [

    LeftNavigationBarItem(id: 1, icon: Icons.message_outlined, label: "消息"),

    LeftNavigationBarItem(id: 2, icon: Icons.video_camera_back_outlined, label: "视频会议"),

    LeftNavigationBarItem(id: 3, icon: Icons.book_outlined, label: "通讯录"),

    LeftNavigationBarItem(id: 4, icon: Icons.cloud_upload_outlined, label: "云文档"),

    LeftNavigationBarItem(id: 5, icon: Icons.games_sharp, label: "工作台"),

    LeftNavigationBarItem(id: 6, icon: Icons.calendar_month, label: "日历"),

  ];



  @override

  Widget build(BuildContext context) {

    return MultiBlocProvider(

      providers: [

        BlocProvider<NavSelectionCubic>(

          create: (BuildContext context) => NavSelectionCubic(id:items.first.id),

        ),

        BlocProvider<NavMenuCubic>(

          create: (BuildContext context) => NavMenuCubic(items:items),

        ),

      ],

      child: const LeftNavigationBar(),

    );

  }

}

6. 如何拖动菜单

我们先来分析一下拖拽菜单的界面表现。如下所示，可将一个菜单拖拽出来，拖出的组件具有一定的透明度；另外当拖拽物达到目标时，目标底部会显示蓝线示意移至其下。这里使用的是 Draggable 和 DragTarget 的组合，其中 Draggable 指的是可拖拽物体，DragTarget 指的是受体目标。

可以看出，其实这里导航菜单同时承担着这两种角色，既需要拖拽，又需要作为目标接收拖拽物，这就是可拖拽导航的一个小难点。另外还有一个小细节，在拖拽过程中要禁止 _hovering 的悬浮激活，结束后要开启悬浮激活。

下面是代码实现的核心，其中对应 _disableHover 标识来控制是否可以悬浮激活，在 DragTarget 的相关回调中维护 _disableHover 的值。 Draggable 和 DragTarget 需要一个泛型，也就是拖拽交互中需要传递的数据，这里是 int 类型的菜单 id 。数据由 Draggable 提供，如下 tag1 处所示，交互过程中有两个组件，其一是随拖拽浮动的部分，由 buildDraggableChild 方法构建，其二是主体菜单组件，由 buildTargetChild 方法构建。

class _LeftNavigationBarItemWidgetState  extends State<LeftNavigationBarItemWidget> {

  bool _hovering = false;

  bool _disableHover = false;



  void _onTap() {

    BlocProvider.of<NavSelectionCubic>(context).selectMenu(widget.item.id);

  }



  void _onHover(bool value) {

    if (_disableHover) return;

    setState(() {

      _hovering = value;

    });

  }



  final Color color = const Color(0xffcfd1d7);

  final Color activeColor = Colors.blue;



  @override

  Widget build(BuildContext context) {

    return DragTarget<int>(

      onAccept: _onAccept,

      builder: _buildTarget,

      onMove: _onMove,

      onLeave: _onLeave,

      onWillAccept: _onWillAccept,

    );

  }



  Widget buildTargetChild(bool active, bool dragging, int? dragItemId) {

     // 暂略...

  }



  Widget buildDraggableChild(bool active) {

      // 暂略...

  }



  Widget _buildTarget(BuildContext context, List<int?> candidateData,

      List<dynamic> rejectedData) {

    bool active = widget.active || _hovering;

    int? id;

    if (candidateData.isNotEmpty) {

      id = candidateData.first;

    }

    Widget child = buildTargetChild(active, _disableHover, id);



    return Draggable<int>(

      data: widget.item.id, // tag1

      feedback: buildDraggableChild(widget.active), // tag2

      child: child,

    );

  }

下面来单独看一下 DragTarget 的几个回调方法。_onWillAccept 可以通过返回值来控制，是否拖拽物是否符合目标的接收条件，只有符合条件才会在后续触发 _onAccept。比如这里当携带的 id 不是自身的 id 时，符合接收条件，这样就可以避免自己拖到自己身上的问题。

_onAccept 顾名思义，表示拖拽符合条件被接收，我们之后在此回调中对菜单栏进行重排序，再触发更新即可。_onMove 在拖拽物移入目标时触发，_onLeave在拖拽物离开目标时触发。另外 Draggable 中有一些拖拽事件相关的回调，在这里作用不大，大家可以只了解一下。

  bool _onWillAccept(int? data) {

    print('=====_onWillAccept=======$data===${data != widget.item.id}===');

    return data != widget.item.id;

  }

  

  void _onAccept(int data) {

    print('=====_onAccept=======$data======');

    _disableHover = false;

  }



  void _onMove(DragTargetDetails<int> details) {

    _hovering = false;

    _disableHover = true;

  }



  void _onLeave(int? data) {

    print('=====_onLeave=============');

    _disableHover = false;

  }

}

最后看一下 buildTargetChild 中的一个小细节，也就是达到目标时，目标组件底部出现蓝色线条示意。 DragTarget 组件的构建组件的回调中，可以感知到携带的数据。如下，只要根据 id 数据进行校验，当 enable 时添加底部边线即可：

7. 拖拽更新菜单数据

上面把所有的准备工作都完成了，接下来想要拖拽更新菜单数据，也就能水到渠成。前面说过。菜单数据由 NavMenuCubic 维护，现在只要在 switchMenu 中完成业务逻辑，在 _onAccept 中触发即可。这样界面交互、数据变化、界面更新三个层次就会非常清晰。

class NavMenuCubic extends Cubit<NavMenus> {

  NavMenuCubic({required List<LeftNavigationBarItem> items}) : super(NavMenus(menus:items ));



  void switchMenu(int dragId, int targetId) {

    // TODO 处理拖拽菜单数据交换

  }

}

如下，是交换的处理逻辑，根据 dragId 和 targetId 获取在列表中的索引，然后移除和添加而已。就是最基本的数据处理,在刚才的 _onAccept 方法中触发交换即可，效果如下：

---->[NavMenuCubic#switchMenu]---- 

 void switchMenu(int dragId, int targetId) {

    List<LeftNavigationBarItem> items = state.menus;

   int dragIndex = 0;

   int targetIndex = 0;

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

     LeftNavigationBarItem item = items[i];

     if(item.id == dragId){

       dragIndex = i;

     }

   }

    LeftNavigationBarItem dragItem =  items.removeAt(dragIndex);

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

      LeftNavigationBarItem item = items[i];

      if (item.id == targetId) {

        targetIndex = i;

      }

    }

    items.insert(targetIndex+1, dragItem);

    print(items);

    emit(NavMenus(menus: items));

  }

}



---->[_LeftNavigationBarItemWidgetState]----

void _onAccept(int data) {

  print('=====_onAccept=======$data======');

  BlocProvider.of<NavMenuCubic>(context).switchMenu(data,widget.item.id);

  _disableHover = false;

}

这里只是进行最基础的拖拽导航栏需求，还有一些可以拓展的地方。比如将菜单的数据存储在本地，这样就可以保证程序关闭之后，再打开不会重置。另外也可以提供相关的后端接口，让数据同步到服务端，这样多设备就可以实现同步。

本文简单介绍了一下状态管理的使用价值，完成了一个简单的自定义可拖拽导航栏，相信从中你可以学到一些东西。后续会基于这个导航继续拓展，比如界面切换，支持添加移除等。那本文就到这里，谢谢观看~

AIDL 全称 Android Interface Definition Language ，安卓接口定义语言。

AIDL 用来解决 Android 的跨进程通信问题，底层原理是 Binder ，实现思路是 C / S 架构思想。

• Server：接收请求，提供处理逻辑，并发送响应数据。
• Client：发起请求，接收响应数据。

C / S 之间通过 Binder 对象进行通信。

• Server 需要实现一个 Service 作为服务器，Client 侧则需要调用发起请求的能力。
• Client 需要调用 bindService 绑定到远程服务，然后通过 ServiceConnection 来接收远程服务的 Binder 对象。拿到 Binder 对象后就可以调用远程服务中定义的方法了。

因为是跨进程通信，所以需要实现序列化，AIDL 专门为 Android 设计，所以它的序列化不能使用 Java 提供的 Serializable ，而是 Android 提供的 Parcelable 接口。

AIDL 的用法

以一个跨进程相互发送消息的 Demo 为例，演示 AIDL 的用法。

场景：两个 App ，一个作为 Server ，用来启动一个服务，接收另一个作为 Client 的 App 发来的请求（Request），然后并进行响应（Response），另外，Server 也可以主动发消息给绑定到 Server 的 Client 。

Step 1 定义通信协议

AIDL 解决的是远程通信问题，是一种 C / S 架构思想，参考网络通信模型，客户端和服务端之间，需要约定好彼此支持哪些东西，提供了什么能力给对方（这里主要是服务端提供给客户端的），而定义能力在面向对象的编程中，自然就是通过接口来定义。所以 AIDL 是 Interface Definition Language。

定义服务端暴露给客户端的能力，首先要创建 AIDL 文件。AIDL 文件在同包名下，与 java / res 等目录同级，创建 aidl 文件夹，其内部结构和 java 保持一致：

src

｜- java

｜-- com

｜--- chunyu

｜---- aidl

｜----- service

｜------ ...// java file

｜

｜- aidl

｜-- com

｜--- chunyu

｜---- aidl

｜----- service

｜------ ... // aidl file

｜

｜- ...

复制代码

在定义 AIDL 接口前，我们现实现一个数据类，这个数据类作为服务端和客户端之间通信的数据结构。如果你的通信不需要复杂的数据对象，而是 int 、 long 等基本数据类型和 String ，则不需要这一个步骤。

通过 Android Studio 右键创建 AIDL 文件时，默认会生成一个方法：

interface IServerManager {

    /**

     * 演示了一些可以在AIDL中用作参数和返回值的基本类型。

     */

    void basicTypes(int anInt, long aLong, boolean aBoolean, float aFloat,

            double aDouble, String aString);

}

复制代码

这里说明了除了要实现 Parcelable 序列化接口的对象，这些类型可以直接传递。

这里我们定义一个 Msg 类，作为通信传递的数据类型，在 java 目录下实现这个类：

class Msg(var msg: String, var time: Long? = null): Parcelable {

    constructor(parcel: Parcel) : this(

        parcel.readString() ?: "",

        parcel.readValue(Long::class.java.classLoader) as? Long

    ) {

    }



    override fun writeToParcel(parcel: Parcel, flags: Int) {

        parcel.writeString(msg)

        parcel.writeValue(time)

    }



    override fun describeContents(): Int {

        return 0

    }



    companion object CREATOR : Creator<Msg> {

        override fun createFromParcel(parcel: Parcel): Msg {

            return Msg(parcel)

        }



        override fun newArray(size: Int): Array<Msg?> {

            return arrayOfNulls(size)

        }

    }

}

复制代码

其实只需要定义参数即可，方法和成员通过快捷键会自动实现。实现完这个类后，需要在 aidl 同包名下创建一个 Msg.aidl 文件，将这个类型进行声明：

package com.chunyu.aidl.service;



parcelable Msg;

复制代码

数据对象定义好了，下一步就可以定义服务端暴露给客户端的接口了。

首先定义一个服务端主动回调给客户端的接口，所有注册了的 Client ，都可以接收到服务端的主动消息：

package com.chunyu.aidl.service;



import com.chunyu.aidl.service.Msg;



interface IReceiveMsgListener {

    void onReceive(in Msg msg);

}

复制代码

需要注意的一点是，AIDL 文件中的 import 并不会自动导入，需要开发者自行添加。

然后定义 Server 暴露给 Client 的能力：

package com.chunyu.aidl.service;



import com.chunyu.aidl.service.Msg;

import com.chunyu.aidl.service.IReceiveMsgListener;



interface IMsgManager {

  	// 发消息

    void sendMsg(in Msg msg);

  	// 客户端注册监听回调

    void registerReceiveListener(IReceiveMsgListener listener);

  	// 客户端取消监听回调

    void unregisterReceiveListener(IReceiveMsgListener listener);

}

复制代码

IMsgManager 提供了三个方法，用来解决两个场景：

• Client 主动发送 Msg 给 Server （sendMsg 方法，也可以理解为网络通信中的客户端发起请求）。
• Server 主动发消息给所有订阅者，通过回调 IReceiveMsgListener 中的 onReceive 方法，每个注册的 Client 都会收到回调（典型的观察者模式）。

所有关于 AIDL 的部分就到这里了，此时，开发者需要手动运行 build 重新构建项目，这样 AIDL 会在 build 后生成一些 class 文件，供项目代码中调用。

注意：每次 AIDL 的改动都需要手动 build 一下。

Step 2 定义服务端

服务端的定义需要创建一个 Service 来作为服务器。这里创建一个 MyService 类，然后在 AndroidManifest.xml 中配置一个 action ，这个 action 后续会用来进行跨进程启动：

        <service

            android:name=".MyService"

            android:enabled="true"

            android:exported="true">

            <intent-filter>

                <action android:name="com.chunyu.aidl.service.MyService"></action>

            </intent-filter>

        </service>

复制代码

配置完这个后，就可以在 MyService 中实现服务器的逻辑了。

Service 的启动方式有两种，startService 和 bindService ，后者是我们在实现 Client 连接 Server 的核心方法。通过 bindService 创建 C / S 之间的连接。而 Service 在通过 bindService 启动时，会回调 onBind 方法:

fun onBind(intent: Intent): IBinder 

复制代码

onBind 的返回类型时 IBinder ，这个就是跨进程通信间传递的 Binder 。在同一个进程中不需要进行跨进程通信，这里可以返回为 null 。而此时需要实现 IPC ，自然这个方法需要返回一个存在的 Binder 对象，所以，配置服务器的第二步，就是实现一个 Binder 并在 onBind 中返回。

我们在定义通信协议时，定义了一个用来表示 Server 提供给 Client 能力的接口 IMsgManager，经过 build 后，编译器会自动生成 IMsgManager.Stub ，这是一个自动生成的实现了 IMsgManager 接口的 Binder 抽象实现：

public static abstract class Stub extends android.os.Binder implements com.chunyu.aidl.service.IMsgManager

复制代码

在 MyService 中实现这个抽象类：

class MyService : Service() {



  	// ...

  

    inner class MyBinder: IMsgManager.Stub() {

        override fun sendMsg(msg: Msg?) {

            // todo 收到 Client 发来的消息，此处实现 Server 的处理逻辑

        }

        override fun sendMsg(msg: Msg?) {

            // todo 收到 Client 发来的消息，此处实现 Server 的处理逻辑

            val n = receiveListeners.beginBroadcast()

            for (i in 0 until n) {

                val listener = receiveListeners.getBroadcastItem(i)

                listener?.let {

                    try {

                        val serverMsg = Msg("服务器响应 ${Date(System.currentTimeMillis())}\n ${packageName}", System.currentTimeMillis())

                        listener.onReceive(serverMsg)

                    } catch (e: RemoteException) {

                        e.printStackTrace()

                    }

                }

            }

            receiveListeners.finishBroadcast()

        }



        override fun registerReceiveListener(listener: IReceiveMsgListener?) {

          	// receiveListeners 记录观察者

            receiveListeners.register(listener)

        }



        override fun unregisterReceiveListener(listener: IReceiveMsgListener?) {

            val success = receiveListeners.unregister(listener)

            if (success) {

                Log.d(TAG, "解除注册成功")

            } else {

                Log.d(TAG, "解除注册失败")

            }

        }

    }

}

复制代码

然后，在 onBind 方法中返回这个类的对象：

    override fun onBind(intent: Intent): IBinder {

        return MyBinder()

    }

复制代码

整体的一个服务端代码：

class MyService : Service() {



    private val receiveListeners =  RemoteCallbackList<IReceiveMsgListener>()



    override fun onBind(intent: Intent): IBinder {

        return MyBinder()

    }



    inner class MyBinder: IMsgManager.Stub() {

        override fun sendMsg(msg: Msg?) {

            // server process request at here

        }



        override fun registerReceiveListener(listener: IReceiveMsgListener?) {

            receiveListeners.register(listener)

        }



        override fun unregisterReceiveListener(listener: IReceiveMsgListener?) {

            val success = receiveListeners.unregister(listener)

            if (success) {

                Log.d(TAG, "解除注册成功")

            } else {

                Log.d(TAG, "解除注册失败")

            }

        }

    }

}

复制代码

这样，服务端的逻辑就完成了。

Step 3 客户端实现

客户端的实现在另一个 App 中实现，创建一个新项目，包名 com.chunyu.aidl.client ，将这个项目中的 MainActivity 作为 Client 。

Client 中需要实现的核心逻辑包括：

• 创建 Client 到 Server 的连接。
• 实现发送请求的功能。
• 实现接收 Server 消息的功能。
• 在销毁的生命周期中主动关闭连接。

创建连接

创建连接主要通过 bindService 来实现，分为两种情况，在同一个进程中，不需要跨进程，直接通过显式的 Intent 启动 Service ：

val intent = Intent(this, MyService::class.java)

bindService(intent, connection!!, BIND_AUTO_CREATE)

复制代码

这是因为在同一个进程中，能直接访问到服务端 Service 的类。而跨进程没有这个 class ，需要通过隐式 Intent 启动 ：

val intent = Intent()

intent.action = "com.chunyu.aidl.service.MyService"

intent.setPackage("com.chunyu.aidl.service")

bindService(intent, connection!!, BIND_AUTO_CREATE)

复制代码

Action 在实现服务端时，在 AndroidManifest.xml 中进行配置，此刻就用到了。

而不管是哪个进程调用 bindService ，都会需要一个 connection 参数，这是一个 ServiceConnection 的对象。

ServiceConnection 是一个监控应用 Service 状态的接口。和很多系统的其他回调一样，这个接口的实现的方法在进程的主线程中调用。

public interface ServiceConnection {



    void onServiceConnected(ComponentName name, IBinder service);



    void onServiceDisconnected(ComponentName name);



    default void onBindingDied(ComponentName name) {

    }

    

    default void onNullBinding(ComponentName name) {

    }

}

复制代码

了解了 ServiceConnection ，所以需要在 Client 中实现一个 ServiceConnection 对象，这里用匿名对象的形式：

private var deathRecipient = object : IBinder.DeathRecipient {

    override fun binderDied() {

        iMsgManager?.let {

          	// 当 binder 连接断开时，解除注册

            it.asBinder().unlinkToDeath(this, 0)

            iMsgManager = null

        }

    }

}



val connection = object : ServiceConnection {

  	// 服务连接创建成功时

    override fun onServiceConnected(name: ComponentName?, service: IBinder?) {

        iMsgManager = IMsgManager.Stub.asInterface(binder)

        try {

            iMsgManager?.asBinder()?.linkToDeath(deathRecipient, 0)

            iMsgManager?.registerReceiveListener(receiveMsgListener)

        } catch (e: RemoteException) {

            e.printStackTrace()

        }

    }

    override fun onServiceDisconnected(name: ComponentName?) { }

}

复制代码

接收 Server 消息

这里注册的 listener是一个 IReceiveMsgListener.Stub 对象：

    private var receiveMsgListener = object : IReceiveMsgListener.Stub() {

        override fun onReceive(msg: Msg?) {

            displayTv.post {

                displayTv.text = "客户端：${msg?.msg}, time: ${msg?.time}"

            }

        }

    }

复制代码

写到这里的时候，我是有一个疑问的，为什么是 IReceiveMsgListener.Stub 类型，而不是一个 IReceiveMsgListener 的匿名对象。

首先 IReceiveMsgListener.Stub 的继承关系是：

public static abstract class Stub extends android.os.Binder implements com.chunyu.aidl.service.IReceiveMsgListener

复制代码

IReceiveMsgListener.Stub 本身也是 IReceiveMsgListener 的实现，而且它还继承自 Binder ，也就是具备了 Binder 的能力，能够在跨进程通信中作为 Binder 传输，所以这里是 IReceiveMsgListener.Stub 类型的对象。

而如果直接使用 IReceiveMsgListener ， 匿名对象要求多实现一个 asBinder 方法：

    private var receiveMsgListener = object : IReceiveMsgListener {

        override fun asBinder(): IBinder {

            TODO("Not yet implemented")

        }



        override fun onReceive(msg: Msg?) {

            displayTv.post {

                displayTv.text = "客户端：${msg?.msg}, time: ${msg?.time}"

            }

            Log.d(TAG, "客户端：$msg")

        }

    }

复制代码

其实 IReceiveMsgListener.Stub 就是帮我们实现好了一些逻辑，减少了开发的复杂度。

而从另一个方面也验证了 AIDL 跨进程通信调用的对象能需要具备作为 Binder 的能力。

Client 发送消息

val connection = object : ServiceConnection {

  	// 服务连接创建成功时

    override fun onServiceConnected(name: ComponentName?, binder: IBinder?) {

        iMsgManager = IMsgManager.Stub.asInterface(binder)

        try {

            iMsgManager?.asBinder()?.linkToDeath(deathRecipient, 0)

            iMsgManager?.registerReceiveListener(receiveMsgListener)

        } catch (e: RemoteException) {

            e.printStackTrace()

        }

    }

    override fun onServiceDisconnected(name: ComponentName?) { }

}

复制代码

onServiceConnected 代表着连接创建成功了，此时首先赋值了 iMsgManager ，iMsgManager 是 AIDL 中定义的 Server 暴露给 Client 的能力的接口对象：

private var iMsgManager: IMsgManager?  = null

复制代码

它的初始化：

iMsgManager = IMsgManager.Stub.asInterface(binder)

复制代码

这里的 asInerface 和 asBinder 方法，说明 AIDL 中定义的接口可以转换为 Binder ，Binder 也可以转换为 Interface ，因为这里的 Binder 来自于 Service 的 onBind 方法，在 onBind 中返回的就是 IMsgManager.Stub 的实现，自然可以转换为 IMsgManager 。

通过 IMsgManager 就可以调用 Server 中的方法了：

        sendMsgBtn.setOnClickListener {

            iMsgManager?.sendMsg(Msg("from 客户端，当前第 ${count++} 次", System.currentTimeMillis()))

        }

复制代码

随便给一个 button 的点击事件中调用 sendMsg 方法，发送消息给 MyService 。

生命周期管理

最后是在 Client 的生命周期中及时关闭连接，清除不需要的对象。

    // in MainActivity

    override fun onDestroy() {

        if (iMsgManager?.asBinder()?.isBinderAlive == true) {

            try {

                iMsgManager?.unregisterReceiveListener(receiveMsgListener)

            } catch (e: RemoteException) {

                e.printStackTrace()

            }

        }

        connection?.let {

            unbindService(it)

        }

        super.onDestroy()

    }

复制代码

基本上这就是一个完整的 AIDL 流程了。

总结

• AIDL 是一套快速实现 Android Binder 机制的框架。
• Android 中的 Binder 机制，架构思想是 C / S 架构。
• 所有跨进程传递的数据需要实现 Parcelable （除了一些基本的类型）。
• 所有跨进程调用的对象，都必须是 Binder 的实现。
• Binder 对象可以和 Interface 实例进行转换，这是因为 Service 中返回的 Binder 对象实现了 Interface。
• 通过 aidl 文件中定义的接口，可以跨进程调用远程对象的方法。

程序猿是口青春饭，30有点“老”，35非常“老”。当年龄越来越大，体力精力学习能力越来越竞争不过年轻人时，除了技术和管理，码农还有没有别的选择吗？以下这些切实又不切实的选择仅供参考。

1.转往临近岗位，比如你讨厌的产品经理

程序猿和产品经理可谓是最像夫妻的两个职位，相爱相杀，知根知底。

程序员转产品经理有很大优势，因为了解产品的实现过程，所以对项目的时间把握有相当的话语权，能保证了项目的进度，对产品将来的扩展和升级都有帮助，所以程序员转过来的产品经理是很抢手的。

只要多学习一些产品营销和运营方面的知识，多一点沟通能力，程序员出生的产品经理就自然而然在市场上占据很大优势。

国内目前最牛逼的产品经理非微信之父张小龙莫属，他就是程序员转产品经理的最佳案例。如果你拥有绝佳的洞察力，能够了解人性需求，相信自己可以创造出人人都愿意的产品，你也可以像张小龙一样，升职加薪、当上总经理、出任CEO、迎娶白富美、走上人生巅峰。

2.任何行业的教育行业都可以作为备胎

随着猿在劳动力市场的走红，IT讲师也成为了一个热门职位。大龄码农在工作中年限越长上升越慢，到大龄阶段，就不得不面对自己的停滞，IT讲师对于他们会是一个很好的选择。

3.个体户，谁自由谁知道

除了做IT讲师和产品经理，有的程序猿纯粹是写腻了代码，想完全摆脱代码，摆脱程序猿的工作。他们有的就利用自己多年攒下的钱，做起了个体户。

不知是因为新闻性还是真有那么大基数，据说程序猿转行做餐饮的不少，并且都还做得不错。

无论是卖肠粉的，卖凉皮的，卖热干面，卖火锅的都有！

程序猿卖烧饼，卖凉皮，听上去有些屈才。但如今的个体户收入并不低，即使只是卖个热干面，卖个烧饼，好好经营，收入不比一个高级码农差。

4.一些高薪产业，比如做明星

此条建议，是认真的，毕竟明星中有不少的程序猿转行成功的案例。

潘玮柏

潘玮柏，曾设计一款游戏——熊猫屁王，他是第一个设计 iPhone app 的艺人， 还创造过 App Store 上下载量第一。

李健

马东

奇葩说的主持人马东也曾经是一名计算机专业的人才。在他还未满18岁的时候，马东就只身前往澳洲学习计算机专业，在澳洲有着10年的IT工程师经历。而这使得他对数据有着灵敏的认知和有序的编程思维，能够在传媒行业风格别具一致，脱颖而出。

除了这些明星是程序猿转行过来的，还有猿混成了总理。

李显龙

新加坡总理李显龙也曾是位真正入行的程序员。他在剑桥大学三一学院修习数学和计算机科学，曾把自己写过的解熟读程序放了出来，让网民们一起帮忙找BUG。李显龙在一次科技创业论坛上透露，自己曾“非常享受编程”。

5.追求自己的爱好，找寻真正的自我

有人说，最好的转行是为了兴趣爱好而转。毕竟换一个行业需要投入大量时间精力，还要面对失败。做一个程序猿，奋斗几年，攒够一定资金后，就该找寻自我，追求自己的爱好了。以下两个案例中的程序猿，都曾有稳定的程序猿工作，但都放弃了选择了追求自己的爱好，最终闯出了一片天。

闫鹤祥

王小波

王小波曾在自己的小说里骄傲地写到，我写书的软件都是自己编写的。当时的他还通过卖软件还赚了不少钱呢，很多中关村的老板想要拉他入伙，这对于当时的屌丝王小波还是有致命吸引力的，王小波也认真地考虑过，只不过后来觉得写东西更有意思，便一一回绝了。

以上为不完全程序猿转行方向手册，无论如何，转行需谨慎。

本篇将带你在 Flutter 上快速实现两个炫酷的动画特效，希望最后的效果可以惊艳到你。

这次灵感的来源于更新 MIUI 13 时刚好看到的卡片效果，其中除了卡片会跟随手势出现倾斜之外，内容里的部分文本和绿色图标也有类似悬浮的视差效果，恰逢此时灵机一动，我们也来用 Flutter 快速实现炫酷的 3D 视差卡片，最后再拓展实现一个支持帅气的 360° 展示的卡片效果。

❤️ 本文正在参加征文投稿活动，还请看官们走过路过来个点赞一键三连，感激不尽～

既然需要卡片跟随手势产生不规则形变，我们第一个想到的肯定是矩阵变换，在 Flutter 里我们可以使用 Matrix4 配合 Transform 来实现矩阵变换效果。

开始之前，首先我们创建用 Transform 嵌套一个 GestureDetector ，并绘制出一个 300x400 的圆角卡片，用于后续进行矩阵变换处理。

Transform(

  transform: Matrix4.identity(),

  child: GestureDetector(

    child: Container(

      width: 300,

      height: 400,

      padding: EdgeInsets.all(20),

      decoration: BoxDecoration(

        color: Colors.blueGrey,

        borderRadius: BorderRadius.circular(20),

      ),

    ),

  ),

);

接着，如下代码所示，因为我们需要卡片跟随手势进行矩阵变换，所以我们可以直接在 GestureDetector 的 onPanUpdate 里获取到手势信息，例如 localPosition 位置信息，然后把对应的 dx 和 dy赋值到 Matrix4 的 rotateX 和 rotateY 上实现旋转。

child: Transform(

  transform: Matrix4.identity()

    ..rotateX(touchY)

    ..rotateY(touchX),

  alignment: FractionalOffset.center,

  child: GestureDetector(

    onPanUpdate: (details) {

      setState(() {

        touchX = details.localPosition.dx;

        touchY = details.localPosition.dy;

      });

    },

    child: Container(

这里有个需要注意的是：上面代码里 rotateX 使用的是 touchY ，而 rotateY 使用的是 touchX ，为什么要这样做呢？

⚠️举个例子，当我们手指左右移动时，是希望卡片可以围绕 Y 轴进行旋转，所以我们会把 touchX 传递给了 rotateY ，同样 touchY 传递给 rotateX 也是一个道理。

但是当我们实际运行上述代码之后，如下图所示，可以看到基本上我们只是稍微移动手指，卡片就会陷入疯狂旋转的情况，并且实际的旋转速度会比 GIF 里快很多。

问题的原因其实是因为 rotateX 和 rotateY 需要的是一个 angle 参数，假设这里对 rotateX 和 rotateY 设置 pi / 4 ，就可以看到卡片在 X 轴和 Y 轴上都产生了 45 度的旋转效果。

 Transform(

    transform: Matrix4.identity()

      ..rotateX(pi / 4)

      ..rotateY(pi / 4),

    alignment: FractionalOffset.center,

所以如果直接使用手势的 localPosition 作用于 Matrix4 肯定是不行的，我们首先需要对手势数据进行一个采样，因为代码里我们设置了 FractionalOffset.center ，所以我们可以用卡片的中心点来计算手指位置，再进行压缩处理。

如下代码所示，我们通过以卡片中心点为原点进行计算，其中 / 2 就是得到卡片的中心点，/ 100 是对数据进行压缩采样，但是为什么 touchX 和 touchY 的计算方式是相反的呢？

touchX = (cardWidth / 2 - details.localPosition.dx) / 100;

touchY = (details.localPosition.dy - cardHeight / 2 ) / 100;

如下图所示，因为在设置 rotateX 和 rotateY 时，赋予 > 0 的数据时卡片就会以图片中的方向进行旋转，由于我们是需要手指往哪边滑动，卡片就往哪边倾斜，所以：

• 当我们往左水平滑动时，需要卡片往左边倾斜，也就是图中绕 Y 轴转动的 >0 的方向，并且越靠近左边需要正向的 Angle 数值越大，由于此时 localPosition.dx 是越往左越小，所以需要利用 CardWidth / 2 - details.localPosition.dx 进行计算，得到越往左有越大的正向 Angle 数值


• 同理，当我们往下滑动时，需要卡片往下边倾斜，也就是图中绕 X 轴转动的 >0 的方向，并且越靠近下边需要正向 Angle 数值越大，由于此时 localPosition.dy 越往下越大，所以使用 details.localPosition.dy - cardHeight / 2 去计算得到正确数据

如果觉得太抽象，可以结合上边右侧的动图，和大家买股票一样，图中显示红色时是正数，显示绿色时是负数，可以看到：

• 手指往左移动时，第一行 TouchX 是红色正数，被设置给 rotateY ， 然后卡片绕 Y 轴正方向旋转


• 手指往下移动时，第二行 TouchY 是红色正数，被设置给 rotateX ， 然后卡片绕 X 轴正方向旋转

到这里我们就初步实现了卡片跟随手机旋转的效果，但是这时候的立体旋转效果看起来其实“很别扭”，总感觉差了点什么，其实这是因为卡片在旋转时没有产生视觉上的深度感知。

所以我们可以通过矩阵的透视变换调整视觉效果，而为了在 Z 方向实现深度感知，我们需要在矩阵中配置 .setEntry(3, 2, 0.001) ，这里的 3 表示第 3 列，2 表示第 2 行，因为是从 0 开始排列，所以也就是图片中 Z 的位置。

其实 .setEntry(3, 2, 0.001) 就是调整 Z 轴的视角，而在 Z 上的 0.001 就是需要的透视效果测量值，类似于相机上的对焦点进行放大和缩小的作用，这个数字越大就会让交点处看起来好像离你视觉更近，所以最终代码如下

Transform(

  transform: Matrix4.identity()

    ..setEntry(3, 2, 0.001)

    ..rotateX(touchY)

    ..rotateY(touchX),

  alignment: FractionalOffset.center,

运行之后，可以看到在增加了 Z 角度的视角调整之后，这时候看起来的立体效果就好了很多，并且也有了类似 3D 空间的感觉。

接着我们在卡片上放上一个添加一个 13 的 Text 文本，运行之后可以看到此时文本是跟随卡片发生变化，而接下来我们需要做的，就是通过另外一个 Transform 来让 Text 文本和卡片之间产生视差，从而出现悬浮的效果。

所以接下来需要给文本内容设置一个 translate 的 Matrix4 ，让它向着倾斜角度的相反方向移动，然后对前面的 touchX 和 touchY 进行放大，然后再通过 - 10 操作来产生一个位差。

    Transform(

      transform: Matrix4.identity()

        ..translate(touchX * 100 - 10,

            touchY * 100 - 10, 0.0),

-10 这个是我随意写的，你也可以根据自己的需求调节。

例如，这时候当卡片往左倾斜时，文字就会向右移动，从而产生视觉差的效果，得到类似悬浮的感觉。

完成这一步之后，接下来可以我们对文本内容进行一下美化处理，例如增加渐变颜色，添加阴影，更换字体，目的是让字体看起来更加具备立体的效果，这里使用的 shader ，也可以让文字在移动过程中出现不同角度的渐变效果。

最后，我们还需要对卡片旋转进行一个范围约束，这里主要是通过卡片大小比例：

• 在 onPanUpdate 时对 touchX 和 touchY 进行范围约束，从而约束的卡片的倾斜角度


• 增加了 startTransform 标志位，用于在 onTapUp 或者 onPanEnd 之后，恢复卡片回到默认状态的作用。

Transform(

  transform: Matrix4.identity()

    ..setEntry(3, 2, 0.001)

    ..rotateX(startTransform ? touchY : 0.0)

    ..rotateY(startTransform ? touchX : 0.0),

  alignment: FractionalOffset.center,

  child: GestureDetector(

    onTapUp: (_) => setState(() {

      startTransform = false;

    }),

    onPanCancel: () => setState(() => startTransform = false),

    onPanEnd: (_) => setState(() {

      startTransform = false;

    }),

    onPanUpdate: (details) {

      setState(() => startTransform = true);

      ///y轴限制范围

      if (details.localPosition.dx < cardWidth * 0.55 &&

          details.localPosition.dx > cardWidth * 0.3) {

        touchX = (cardWidth / 2 - details.localPosition.dx) / 100;

      }



      ///x轴限制范围

      if (details.localPosition.dy > cardHeight * 0.4 &&

          details.localPosition.dy < cardHeight * 0.6) {

        touchY = (details.localPosition.dy - cardHeight / 2) / 100;

      }

    },

    child:

到这里，我们只需要在全局再进行一些美化处理，运行之后就会如下图所示，再配合阴影和渐变效果，整体的视觉立体感会更强烈，此时我们基本就实现了一开始想要的功能，

完整代码可见： card_perspective_demo_page.dart

Web 体验地址，PC 端记得开 Chrome 手机模式： 3D 视差卡片 。

那有人可能就想问了： 学会了这个我们还可以实现什么？

举个例子，比如我们可以实现一个 “伪3D” 的 360° 卡片效果，利用堆叠实现立体的电子银行卡效果。

依旧是前面的手势旋转逻辑，只是这里我们可以把具有前后画面的银行卡图片，通过 IndexedStack 嵌套起来，嵌套之后主要是根据旋转角度来调整 IndexedStack 里需要展示的图片，然后利用透视旋转来实现类似 3D 物体的 360° 旋转展示。

这里的关键是通过手势旋转角度，判断当前需要展示 IndexedStack 里的哪个卡片，因为 Flutter 使用的 Skia 是 2D 渲染引擎，如果没有这部分逻辑，你就只会看到单张图片画面的旋转效果。

if (touchX.abs() % (pi * 3 / 2) >= pi / 2 ||

    touchY.abs() % (pi * 3 / 2) >= pi / 2) {

  showIndex = 0;

} else {

  showIndex = 1;

}

运行效果如下图所示，可以看到在视差和图片切换的作用下，我们用很低的成本在 Flutter 上实现了 “伪3D” 的卡片的 360° 展示，类似的实现其实还可以用于一些商品展示或者页面切换的场景，本质上就是利用视差的效果，在 2D 屏幕上模拟现实中的画面效果，从而达到类似 3D 的视觉作用 。

最后我们只需要用 Text 在卡片上添加“模拟”凹凸的文字，就实现了我们现实中类似银行卡的卡面效果。

完整代码可见： card_3d_demo_page.dart

Web 体验地址，PC 端记得开 chrome 手机模式： 360° 可视化 3D 电子银行卡

好了，本篇动画特效就到此为止，如果你有什么想法，欢迎留言评论，感谢大家耐心看完，也还请看官们走过路过的来个点赞一键三连，感激不尽～

Android Native 异常捕获库

基于google/breakpad的Android Native 异常捕获库，在native层发生异常时java层能得到相关异常信息。

项目主页

现状

• 发生native异常时，安卓系统会将native异常信息输出到logcat中，但是java层无法感知到native异常的发生，进而无法获取这些异常信息并上报到业务的异常监控系统。


• 业务部门可以快速实现java层的异常监控系统（java层全局异常捕获的实现很简单），又或者业务部门已经实现了java层的异常监控系统，但没有覆盖到native层的异常捕获。


• 安卓还可以接入Breakpad，其导出的minidump文件不仅体积小信息还全，但有两个问题：
  
  
  
  • 1.和现状第1点的问题相同。
  
  
  • 2.：需要拉取minidump文件并经过比较繁琐的步骤才可以得出有用的信息：
    
    
    
    • 启动时检测Breakpad是否有导出过minidump文件，有则说明发生过native异常。
    
    
    • 到客户现场，或者远程拉取minidump文件。
    
    
    • 编译出自己电脑的操作系统的minidump_stackwalk工具。
    
    
    • 使用minidump_stackwalk工具翻译minidump文件内容，例如拿到崩溃时的程序计数器寄存器内的值（下文称为pc值）。
    
    
    • 找到对应崩溃so库ABI的add2line工具，并根据上一步拿到的pc值定位出发生异常的代码行数。
    
    
    
    
  
  
  
  

整个步骤十分复杂和繁琐，且没有java层的crash线程栈信息，不利于java开发者快速定位调用native的代码。

设计意图

1. 让java层有知悉native异常的通道：
   
   
   
   • java开发者可以在java代码中得到native异常的情况，进而对native异常做出反应，而不是再次启动后去检测Breakpad是否有导出过minidump文件。
   
   
   
   


2. 增加信息的可用性，进而提升问题分析的效率：
   
   
   
   • 
     

     回调中提供naive异常信息、naive和java调用栈信息和minidump文件文件路径，这些信息可以直接通过业务部门的异常监控系统上报。

     
     
   
   
   • 
     

     划分为两个阶段解决问题，我预想是大部分都在阶段一解决了问题，而不需要再对minidump文件进行分析，总体来讲是提升了分析效率的：

     
     
     
     
     • 阶段一：有了java的调用栈和native的调用栈信息，大部分异常原因都可以快速定位并分析出来。
     
     
     • 阶段二：回调中也会提供minidump文件的存储路径，业务部门可以按需拉取。（这一步需要业务部门本身有拉取日志的功能，且需要按上文”现状部分进行操作”，较费时费力）
     
     
     
     
   
   
   
   


3. 最少改动：
   
   
   
   • 让接入方不因为引入新功能而大量改动现有代码。例如：在native崩溃回调处,使用现有的java层异常监控系统上报native异常信息。
   
   
   
   


4. 单一职责：
   
   
   
   • 只做native的crash捕获，不做系统内存情况、cpu使用率、系统日志等信息的采集功能。
   
   
   
   

整体流程

功能介绍

• 保留breakpad导出minidump文件功能 （可选择是否启用）


• 发生native异常时将异常信息、native层调用栈、java层的调用栈通过回调提供给开发者，将这些信息输出到控制台的效果如下：

2022-02-14 11:33:08.598 30228-30253/com.babyte.banativecrash E/crash:  

    /data/user/0/com.babyte.banativecrash/cache/f1474006-60ca-40f4-c9d8e89a-47e90c2e.dmp

2022-02-14 11:33:08.599 30228-30253/com.babyte.banativecrash E/crash:  

    Operating system: Android 28 Linux 4.4.146 #37 SMP PREEMPT Wed Jan 20 18:26:59 CST 2021

    CPU: aarch64 (8 core)

    

    Crash reason: signal 11(SIGSEGV) Invalid address

    Crash address: 0000000000000000

    Crash pc: 0000000000000650

    Crash so: /data/app/com.babyte.banativecrash-ptLzOQ_6UYz-W3Vgyact8A==/lib/arm64/libnative-lib.so(arm64)

    Crash method: _Z5Crashv

2022-02-14 11:33:08.602 30228-30253/com.babyte.banativecrash E/crash:  

    Thread[name:DefaultDispatch] (NOTE: linux thread name length limit is 15 characters)

    #00 pc 0000000000000650  /data/app/com.babyte.banativecrash-ptLzOQ_6UYz-W3Vgyact8A==/lib/arm64/libnative-lib.so (Crash()+20)

    #01 pc 0000000000000670  /data/app/com.babyte.banativecrash-ptLzOQ_6UYz-W3Vgyact8A==/lib/arm64/libnative-lib.so (Java_com_babyte_banativecrash_MainActivity_nativeCrash+20)

    #02 pc 0000000000565de0  /system/lib64/libart.so (offset 0xc1000) (art_quick_generic_jni_trampoline+144)

    #03 pc 000000000055cd88  /system/lib64/libart.so (offset 0xc1000) (art_quick_invoke_stub+584)

    #04 pc 00000000000cf740  /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200)

    #05 pc 00000000002823b8  /system/lib64/libart.so (offset 0xc1000) 

...

2022-02-14 11:33:08.603 30228-30253/com.babyte.banativecrash E/crash:  

    Thread[DefaultDispatcher-worker-1,5,main]

        at com.babyte.banativecrash.MainActivity.nativeCrash(Native Method)

        at com.babyte.banativecrash.MainActivity$onCreate$2$1.invokeSuspend(MainActivity.kt:39)

        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)

        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)

        at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)

        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)

        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)

        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)

    Thread[DefaultDispatcher-worker-2,5,main]

        at java.lang.Object.wait(Native Method)

        at java.lang.Thread.parkFor$(Thread.java:2137)

        at sun.misc.Unsafe.park(Unsafe.java:358)

        at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:353)

        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.park(CoroutineScheduler.kt:795)

        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.tryPark(CoroutineScheduler.kt:740)

        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:711)

        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)

...

定位到so中具体代码行示例

可以使用ndk中的add2line工具根据pc值和带符号信息的so库，定位出具体代码行数。

例：从上文的异常信息中可以看到abi是aarch64，对应的so库abi是arm64，所以add2line的使用如下：

$ ./ndk/android-ndk-r16b/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-addr2line -Cfe ~/arm64-v8a/libnative-lib.so 0000000000000650

输出结果如下：

Crash()

/Users/ba/AndroidStudioProjects/NativeCrash2Java/app/.cxx/cmake/debug/arm64-v8a/../../../../src/main/cpp/native-lib.cpp:6

接入方式

根项目的build.gradle中:

allprojects {

    repositories {

        mavenCentral()//添加这一行

    }

}

模块的build.gradle中：

dependencies {   

    //添加这一行,releaseVersionCode填最新的版本

	implementation 'io.github.BAByte:native-crash:releaseVersionCode' 

}

初始化

两种模式可选：

//发生native异常时:回调异常信息并导出minidump到指定目录，

BaByteBreakpad.initBreakpad(this.cacheDir.absolutePath) { info:CrashInfo ->

    //格式化输出到控制台

    BaByteBreakpad.formatPrint(TAG, info)

}



//发生native异常时:回调异常信息

BaByteBreakpad.initBreakpad { info:CrashInfo ->

    //格式化输出到控制台

    BaByteBreakpad.formatPrint(TAG, info)

}

示例项目

点击查看：示例项目

致谢

• 感谢google breakpad库提供的源码


• 感谢腾讯bugly团队提供在发生异常时，native回调java层的思路


• 感谢爱奇艺xCrash库源码中的dlopen思路

背景

一直从事金融相关项目，所以对BigDecimal再熟悉不过了，也曾看到很多同学因为不知道、不了解或使用不当导致资损事件发生。

所以，如果你从事金融相关项目，或者你的项目中涉及到金额的计算，那么你一定要花时间看看这篇文章，全面学习一下BigDecimal。

BigDecimal概述

Java在java.math包中提供的API类BigDecimal，用来对超过16位有效位的数进行精确的运算。双精度浮点型变量double可以处理16位有效数，但在实际应用中，可能需要对更大或者更小的数进行运算和处理。

一般情况下，对于不需要准确计算精度的数字，可以直接使用Float和Double处理，但是Double.valueOf(String) 和Float.valueOf(String)会丢失精度。所以如果需要精确计算的结果，则必须使用BigDecimal类来操作。

BigDecimal对象提供了传统的+、-、*、/等算术运算符对应的方法，通过这些方法进行相应的操作。BigDecimal都是不可变的（immutable）的， 在进行每一次四则运算时，都会产生一个新的对象 ，所以在做加减乘除运算时要记得要保存操作后的值。

BigDecimal的4个坑

在使用BigDecimal时，有4种使用场景下的坑，你一定要了解一下，如果使用不当，必定很惨。掌握这些案例，当别人写出有坑的代码，你也能够一眼识别出来，大牛就是这么练成的。

第一：浮点类型的坑

在学习了解BigDecimal的坑之前，先来说一个老生常谈的问题：如果使用Float、Double等浮点类型进行计算时，有可能得到的是一个近似值，而不是精确的值。

比如下面的代码：

  @Test

  public void test0(){

    float a = 1;

    float b = 0.9f;

    System.out.println(a - b);

  }

结果是多少？0.1吗？不是，执行上面代码执行的结果是0.100000024。之所以产生这样的结果，是因为0.1的二进制表示是无限循环的。由于计算机的资源是有限的，所以是没办法用二进制精确的表示 0.1，只能用「近似值」来表示，就是在有限的精度情况下，最大化接近 0.1 的二进制数，于是就会造成精度缺失的情况。

关于上述的现象大家都知道，不再详细展开。同时，还会得出结论在科学计数法时可考虑使用浮点类型，但如果是涉及到金额计算要使用BigDecimal来计算。

那么，BigDecimal就一定能避免上述的浮点问题吗？来看下面的示例：

  @Test

  public void test1(){

    BigDecimal a = new BigDecimal(0.01);

    BigDecimal b = BigDecimal.valueOf(0.01);

    System.out.println("a = " + a);

    System.out.println("b = " + b);

  }

上述单元测试中的代码，a和b结果分别是什么？

a = 0.01000000000000000020816681711721685132943093776702880859375

b = 0.01

上面的实例说明，即便是使用BigDecimal，结果依旧会出现精度问题。这就涉及到创建BigDecimal对象时，如果有初始值，是采用new BigDecimal的形式，还是通过BigDecimal#valueOf方法了。

之所以会出现上述现象，是因为new BigDecimal时，传入的0.1已经是浮点类型了，鉴于上面说的这个值只是近似值，在使用new BigDecimal时就把这个近似值完整的保留下来了。

而BigDecimal#valueOf则不同，它的源码实现如下：

    public static BigDecimal valueOf(double val) {

        // Reminder: a zero double returns '0.0', so we cannot fastpath

        // to use the constant ZERO.  This might be important enough to

        // justify a factory approach, a cache, or a few private

        // constants, later.

        return new BigDecimal(Double.toString(val));

    }

在valueOf内部，使用Double#toString方法，将浮点类型的值转换成了字符串，因此就不存在精度丢失问题了。

此时就得出一个基本的结论：第一，在使用BigDecimal构造函数时，尽量传递字符串而非浮点类型；第二，如果无法满足第一条，则可采用BigDecimal#valueOf方法来构造初始化值。

这里延伸一下，BigDecimal常见的构造方法有如下几种：

BigDecimal(int)       创建一个具有参数所指定整数值的对象。

BigDecimal(double)    创建一个具有参数所指定双精度值的对象。

BigDecimal(long)      创建一个具有参数所指定长整数值的对象。

BigDecimal(String)    创建一个具有参数所指定以字符串表示的数值的对象。

其中涉及到参数类型为double的构造方法，会出现上述的问题，使用时需特别留意。

第二：浮点精度的坑

如果比较两个BigDecimal的值是否相等，你会如何比较？使用equals方法还是compareTo方法呢？

先来看一个示例：

  @Test

  public void test2(){

    BigDecimal a = new BigDecimal("0.01");

    BigDecimal b = new BigDecimal("0.010");

    System.out.println(a.equals(b));

    System.out.println(a.compareTo(b));

  }

乍一看感觉可能相等，但实际上它们的本质并不相同。

equals方法是基于BigDecimal实现的equals方法来进行比较的，直观印象就是比较两个对象是否相同，那么代码是如何实现的呢？

    @Override

    public boolean equals(Object x) {

        if (!(x instanceof BigDecimal))

            return false;

        BigDecimal xDec = (BigDecimal) x;

        if (x == this)

            return true;

        if (scale != xDec.scale)

            return false;

        long s = this.intCompact;

        long xs = xDec.intCompact;

        if (s != INFLATED) {

            if (xs == INFLATED)

                xs = compactValFor(xDec.intVal);

            return xs == s;

        } else if (xs != INFLATED)

            return xs == compactValFor(this.intVal);



        return this.inflated().equals(xDec.inflated());

    }

仔细阅读代码可以看出，equals方法不仅比较了值是否相等，还比较了精度是否相同。上述示例中，由于两者的精度不同，所以equals方法的结果当然是false了。而compareTo方法实现了Comparable接口，真正比较的是值的大小，返回的值为-1（小于），0（等于），1（大于）。

基本结论：通常情况，如果比较两个BigDecimal值的大小，采用其实现的compareTo方法；如果严格限制精度的比较，那么则可考虑使用equals方法。

另外，这种场景在比较0值的时候比较常见，比如比较BigDecimal("0")、BigDecimal("0.0")、BigDecimal("0.00")，此时一定要使用compareTo方法进行比较。

第三：设置精度的坑

在项目中看到好多同学通过BigDecimal进行计算时不设置计算结果的精度和舍入模式，真是着急人，虽然大多数情况下不会出现什么问题。但下面的场景就不一定了：

  @Test

  public void test3(){

    BigDecimal a = new BigDecimal("1.0");

    BigDecimal b = new BigDecimal("3.0");

    a.divide(b);

  }

执行上述代码的结果是什么？ArithmeticException异常！

java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.



  at java.math.BigDecimal.divide(BigDecimal.java:1690)

  ...

这个异常的发生在官方文档中也有说明：

If the quotient has a nonterminating decimal expansion and the operation is specified to return an exact result, an ArithmeticException is thrown. Otherwise, the exact result of the division is returned, as done for other operations.

总结一下就是，如果在除法（divide）运算过程中，如果商是一个无限小数（0.333…），而操作的结果预期是一个精确的数字，那么将会抛出ArithmeticException异常。

此时，只需在使用divide方法时指定结果的精度即可：

  @Test

  public void test3(){

    BigDecimal a = new BigDecimal("1.0");

    BigDecimal b = new BigDecimal("3.0");

    BigDecimal c = a.divide(b, 2,RoundingMode.HALF_UP);

    System.out.println(c);

  }

执行上述代码，输入结果为0.33。

基本结论：在使用BigDecimal进行（所有）运算时，一定要明确指定精度和舍入模式。

拓展一下，舍入模式定义在RoundingMode枚举类中，共有8种：

• RoundingMode.UP：舍入远离零的舍入模式。在丢弃非零部分之前始终增加数字(始终对非零舍弃部分前面的数字加1)。注意，此舍入模式始终不会减少计算值的大小。


• RoundingMode.DOWN：接近零的舍入模式。在丢弃某部分之前始终不增加数字(从不对舍弃部分前面的数字加1，即截短)。注意，此舍入模式始终不会增加计算值的大小。


• RoundingMode.CEILING：接近正无穷大的舍入模式。如果 BigDecimal 为正，则舍入行为与 ROUNDUP 相同;如果为负，则舍入行为与 ROUNDDOWN 相同。注意，此舍入模式始终不会减少计算值。


• RoundingMode.FLOOR：接近负无穷大的舍入模式。如果 BigDecimal 为正，则舍入行为与 ROUNDDOWN 相同;如果为负，则舍入行为与 ROUNDUP 相同。注意，此舍入模式始终不会增加计算值。


• RoundingMode.HALF_UP：向“最接近的”数字舍入，如果与两个相邻数字的距离相等，则为向上舍入的舍入模式。如果舍弃部分 >= 0.5，则舍入行为与 ROUND_UP 相同;否则舍入行为与 ROUND_DOWN 相同。注意，这是我们在小学时学过的舍入模式(四舍五入)。


• RoundingMode.HALF_DOWN：向“最接近的”数字舍入，如果与两个相邻数字的距离相等，则为上舍入的舍入模式。如果舍弃部分 > 0.5，则舍入行为与 ROUND_UP 相同;否则舍入行为与 ROUND_DOWN 相同(五舍六入)。


• RoundingMode.HALF_EVEN：向“最接近的”数字舍入，如果与两个相邻数字的距离相等，则向相邻的偶数舍入。如果舍弃部分左边的数字为奇数，则舍入行为与 ROUNDHALFUP 相同;如果为偶数，则舍入行为与 ROUNDHALF_DOWN 相同。注意，在重复进行一系列计算时，此舍入模式可以将累加错误减到最小。此舍入模式也称为“银行家舍入法”，主要在美国使用。四舍六入，五分两种情况。如果前一位为奇数，则入位，否则舍去。以下例子为保留小数点1位，那么这种舍入方式下的结果。1.15 ==> 1.2 ,1.25 ==> 1.2


• RoundingMode.UNNECESSARY：断言请求的操作具有精确的结果，因此不需要舍入。如果对获得精确结果的操作指定此舍入模式，则抛出ArithmeticException。

通常我们使用的四舍五入即RoundingMode.HALF_UP。

第四：三种字符串输出的坑

当使用BigDecimal之后，需要转换成String类型，你是如何操作的？直接toString？

先来看看下面的代码：

@Test

public void test4(){

  BigDecimal a = BigDecimal.valueOf(35634535255456719.22345634534124578902);

  System.out.println(a.toString());

}

执行的结果是上述对应的值吗？并不是：

3.563453525545672E+16

也就是说，本来想打印字符串的，结果打印出来的是科学计数法的值。

这里我们需要了解BigDecimal转换字符串的三个方法

• toPlainString()：不使用任何科学计数法；


• toString()：在必要的时候使用科学计数法；


• toEngineeringString() ：在必要的时候使用工程计数法。类似于科学计数法，只不过指数的幂都是3的倍数，这样方便工程上的应用，因为在很多单位转换的时候都是10^3；

三种方法展示结果示例如下：

基本结论：根据数据结果展示格式不同，采用不同的字符串输出方法，通常使用比较多的方法为toPlainString() 。

另外，NumberFormat类的format()方法可以使用BigDecimal对象作为其参数，可以利用BigDecimal对超出16位有效数字的货币值，百分值，以及一般数值进行格式化控制。

使用示例如下：

NumberFormat currency = NumberFormat.getCurrencyInstance(); //建立货币格式化引用

NumberFormat percent = NumberFormat.getPercentInstance();  //建立百分比格式化引用

percent.setMaximumFractionDigits(3); //百分比小数点最多3位



BigDecimal loanAmount = new BigDecimal("15000.48"); //金额

BigDecimal interestRate = new BigDecimal("0.008"); //利率

BigDecimal interest = loanAmount.multiply(interestRate); //相乘



System.out.println("金额:\t" + currency.format(loanAmount));

System.out.println("利率:\t" + percent.format(interestRate));

System.out.println("利息:\t" + currency.format(interest));

输出结果如下：

金额: ￥15,000.48 

利率: 0.8% 

利息: ￥120.00

小结

本篇文章介绍了BigDecimal使用中场景的坑，以及基于这些坑我们得出的“最佳实践”。虽然某些场景下推荐使用BigDecimal，它能够达到更好的精度，但性能相较于double和float，还是有一定的损失的，特别在处理庞大，复杂的运算时尤为明显。故一般精度的计算没必要使用BigDecimal。而必须使用时，一定要规避上述的坑。

我们都知道 BottomNavigationBar 是一个移动端非常常用的底部导航栏组件，可以用于点击处理激活菜单，并通过回调来处理界面的切换。

-	-

但是在桌面端，由于一般是宽大于高，所以 BottomNavigationBar 并不适用。而是侧边的导航栏较为常见，比如下面飞书的客户端界面布局。

为了满足桌面端的导航栏适用需求，官方新增了 NavigationRail 组件，而非对 BottomNavigationBar 组件进行适配。之前我也说过，对于差异较大的结构,并没有必要让一个组件通过适配来完成两端需求。分离开来也不是坏事，让一件衣服同时适配 蚂蚁 和 燕子 是很困难的，这时做两件衣服，各司其职显然是更好地方式。

BottomNavigationBar 和 NavigationRail 两个导航就是如此，从语义上来看 Bottom 就是用于底部的导航， Rail 是 扶手 、铁轨 的意思，作为侧栏导航的语义，还是很生动有趣的。两者分别处理特定的结构，这也很符合 单一职责 的原则。

该组件已录入 【FlutterUnit】 ，可以在 App 中体验。另外，本文中的代码可在对应文件夹中查看：

1. NavigationRail 组件的基本使用

下面是 NavigationRail 组件的构造方法，其中必须传入的有两个参数:

• destinations : 表示导航栏的信息，是 NavigationRailDestination 列表。


• selectedIndex: 表示激活索引，int 类型。

我们先来实现如下最简单的使用场景，左侧导航栏，在点击时切换右侧内容页：

如果导航栏的数据是固定的，可以提前定义如下的 destinations 常量。如下的 _buildLeftNavigation 方法负责构建左侧导航栏，NavigationRail 在构造中可以通过 onDestinationSelected 回调方法，来监听用户和导航栏的交互事件，传递用点击的索引位置。

final List<NavigationRailDestination> destinations = const [

  NavigationRailDestination(icon: Icon(Icons.message_outlined),label: Text("消息")),

  NavigationRailDestination(icon: Icon(Icons.video_camera_back_outlined),label: Text("视频会议")),

  NavigationRailDestination(icon: Icon(Icons.book_outlined),label: Text("通讯录")),

  NavigationRailDestination(icon: Icon(Icons.cloud_upload_outlined),label: Text("云文档")),

  NavigationRailDestination(icon: Icon(Icons.games_sharp),label: Text("工作台")),

  NavigationRailDestination(icon: Icon(Icons.calendar_month),label: Text("日历"))

];



Widget _buildLeftNavigation(int index){

  return NavigationRail(

    onDestinationSelected: _onDestinationSelected,

    destinations: destinations,

    selectedIndex: index,

  );

}



void _onDestinationSelected(int value) {

  //TODO 更新索引 + 切换界面

}

在 NavigationRail 的文档注释中说道：该组件一般在 Row 中，使用于 Scaffold.body 属性下。这也很容易理解，这是一个左右结构，在 Row 中可以通过 Expanded 可以自动延伸主体内容。如下，主体内容界面通过 PageView 进行构建，其中的 TestContent 组件在实际使用中换成你的需求界面。

@override

Widget build(BuildContext context) {

  return Scaffold(

    body: Row(

      children: [

        _buildLeftNavigation(index),

        Expanded(child: PageView(

          children:const [

            TestContent(content: '消息',),

            TestContent(content: '视频会议',),

            TestContent(content: '通讯录',),

            TestContent(content: '云文档',),

            TestContent(content: '工作台',),

            TestContent(content: '日历',),

          ],

        ))

      ],

    ),

  );

}

最后是关键的一点：点击时，如何实现导航索引的切换和主体内容的切页。思路其实很简单，我们已经知道用户点击导航菜单的回调事件。对于 PageView 来说，可以通过 PageController 切换界面，NavigationRail 可以通过 selectedIndex 确定激活索引，所以只要用新索引重新构建 NavigationRail即可。
如下代码所示，在 _onDestinationSelected 在处理这两件重要的事。如下 tag1 处，通过 PageController 的 jumpToPage 方法进行界面跳转。

这里通过 ValueListenableBuilder 来监听 _selectIndex 实现局部更新构建，如下 tag2 处，只要更新 _selectIndex 的值，就可以通知 ValueListenableBuilder 触发 builder 方法，使用新索引，构建 NavigationRail 。这样可以避免直接触发 _MyHomePageState 的更新方法，对 Scaffold 整体进行更新。

class _MyHomePageState extends State<MyHomePage> {



 final PageController _controller = PageController();

 final  ValueNotifier<int> _selectIndex = ValueNotifier(0);

 

  // 略同...

  @override

  Widget build(BuildContext context) {

    return Scaffold(

      body: Row(

        children: [

          ValueListenableBuilder<int>(

            valueListenable: _selectIndex,

            builder: (_,index,__)=>_buildLeftNavigation(index),

          ),

          Expanded(child: PageView(

            controller: _controller,

           // 略同...

  }



  void _onDestinationSelected(int value) {

    _controller.jumpToPage(value); // tag1

    _selectIndex.value = value; //tag2

  }



  @override

  void dispose(){

    _controller.dispose();

    _selectIndex.dispose();

    super.dispose();

  }

}

这样就完成了 NavigationRail 最基本的使用，实现了左侧导航结构以及点击时的切换逻辑。NavigationRail 在构造方法中还有很多其他的配置参数用于样式调整，这些不是核心，但可以锦上添花，下面一起来看一下。

2.首尾组件与折叠

leading 和 trailing 属性相当于两个插槽，如下所示，表示导航菜单外的首尾组件。

Widget _buildLeftNavigation(int index){

  return NavigationRail(

    leading: const Icon(Icons.menu_open,color: Colors.grey,),

    trailing: FlutterLogo(),

    onDestinationSelected: _onDestinationSelected,

    destinations: destinations,

    selectedIndex: index,

  );

}

这里有个小细节，trailing 紧随最后一个菜单，如何让它像飞书的导航那样，在最尾部呢？偷瞄一些源码可以看出 trailing 是和导航菜单一起被放入 Column 中的。

所以我们可以通过 Expanded 来延伸剩余空间形成紧约束，通过 Align 使 FlutterLogo 排在下方：

Widget _buildLeftNavigation(int index){

  return NavigationRail(

    leading: const Icon(Icons.menu_open,color: Colors.grey,),

    extended: false,

    trailing: const Expanded(

      child: Align(

        alignment: Alignment.bottomCenter,

        child: Padding(

          padding: EdgeInsets.only(bottom: 20.0),

          child: FlutterLogo(),

        ),

      ),

    ),

    onDestinationSelected: _onDestinationSelected,

    destinations: destinations,

    selectedIndex: index,

  );

}

另外，NavigationRail 中有个 extended 的 bool 参数，用于控制是否展开侧边栏，当该属性变化时，会进行动画展开和收起。如下所示，点击头部时，更新 NavigationRail 的 extended 入参即可：

3.影深 与 标签类型

elevation 表示阴影的深度，这是非常常见的一个属性，如下红框所示，设置 elevation 之后右侧会有阴影，该值越大，阴影越明显。

labelType 参数表示标签类型，对应的属性是 NavigationRailLabelType 枚举。用于表示什么时候显示文字标签，默认是 none ，也就是只显示图标，没有文字。

enum NavigationRailLabelType {

  none,

  selected,

  all,

}

设置为 all 时，效果如下：导航菜单会同时显示 图标 和 文字标签。

设置为 selected 时，效果如下：只有激活的导航菜单会同时显示 图标 和 文字标签 。

另外，有一点需要注意: 当 extended 属性为 true 时， labelType 必须为 NavigationRailLabelType.none 不然会报错。

---->[NavigationRail构造断言]----

assert(!extended || (labelType == null || labelType == NavigationRailLabelType.none)),

4.背景、文字、图标样式

• unselectedLabelTextStyle : 未选中签文字样式


• selectedLabelTextStyle : 选中标签文字样式


• unselectedIconTheme : 未选中图标样式


• selectedIconTheme : 选中图标样式

这四个样式基本上是顾名思义，下面通过一个深色背景版本来使用一下：

@override

Widget build(BuildContext context) {

  const Color textColor =  Color(0xffcfd1d7);

  const  Color activeColor =  Colors.blue;

  const TextStyle labelStyle =  TextStyle(color: textColor,fontSize: 11);

  

  return NavigationRail(

    backgroundColor: const Color(0xff324465),

    unselectedIconTheme: const IconThemeData(color: textColor) ,

    selectedIconTheme: const IconThemeData(color: activeColor) ,

    unselectedLabelTextStyle: labelStyle,

    selectedLabelTextStyle: labelStyle,

    // 略同...

}

5.指示器与最小宽度

• useIndicator : 是否添加指示器


• indicatorColor : 指示器颜色

这两个属性用于控制图标后面的背景指示器，如下是在 NavigationRailLabelType.all 类型下指示器的样式，通过圆角矩形包裹图标：

在 NavigationRailLabelType.none 类型下,指示器通过圆形包裹图标：

• minWidth : 默认 72 ，未展开时导航栏宽度

• indicatorColor :默认 256 ，展开时导航栏宽度

NavigationRail 组件的属性介绍就到这里，总的来看，悬浮和点击时，导航栏还是一股 Material 的味。个人觉得这并不适合桌面端，导航栏的菜单可定制性也一般般，只能满足基本的需求。对于稍微特别点的样式，无法支持，比如飞书客户端的导航样式。另外像 拖动更换菜单位置 这样的交互，我们也只通过自定义组件来实现。

6.剖析 NavigationRail 组件，借鉴思路

就像世界上并没有什么包治百病的 药 ，我们也并不能苛求一个组件能满足所有的布局需求。对于一个原生组件满足不了的需求，发挥创造能力去解决问题，这应是我们的本职工作。借鉴官方对于组件实现的思路是非常重要的，它可以为你提供一个主方向。

我们可以发现 NavigationRail 和 Switch 、BottomNavigationBar 等组件一样，虽然自身是 StatefulWidget, 但对于激活状态的数据并不是在内部状态中维护，而是让 使用者主动提供，比如这里在构造 NavigationRail 时必须传入 selectedIndex 。 该组件只提供回调事件来通知使用者，这样的用意是让使用者更容易 控制 该状态，而不是完全封装在状态类内部。

另外，从 selectedIndex 属性在状态类中的使用中可以看出，每个菜单的条目组件通过 _RailDestination 进行构建。从这里可以看出，_RailDestination 会通过 selected 属性来区分是否激活，而且会通过 onTap 回调点击事件。在此触发 widget.onDestinationSelected ,将当前索引 i 传递给用户。

这里 _RailDestination 是 StatelessWidget, 只说明并不需要维护内部状态的变化，组需要根据构造中的配置信息构建需要的组件即可。这就尽可能地简化了 _RailDestination 的构建逻辑，让其相对独立，专注地去做一件事。这就是组件分离的好处之一：既可以简化构建结构，增加可读性，又可以将相对独立的构建逻辑内聚在一起。我们完全可以在日常开发中对这样的分离进行借鉴和发挥。

另外这里比较值得借鉴的还有动画的处理，我看了一下目前桌面的一些应用，比如 微信 、飞书 、有道词典、百度网盘、AndroidStudio 、有道云笔记 ，这些导航栏在切换时都是没有动画的。如下所示，NavigationRail 对应的状态类中维护了两种动画控制器，这也是 NavigationRail 为什么需要是 StatefulWidget 的原因。

其中 _destinationControllers 用于处理，菜单背景指示器在点击时激活/非激活的透明度渐变动画。可以追踪一下动画器的去向: 在 NavigationIndicator 中通过 FadeTransition使用动画器完成透明度渐变动画。

_RailDestination -->  _AddIndicator --> NavigationIndicator

复制代码

最后看一下 _extendedController 动画控制器，它对应的动画器也被传入 _RailDestination 中来完成动画功能。这个动画控制器在 extended 属性变化时，展开折叠导航栏的动画。如下源码所示，可以看出关于这个动画更多的细节。 动画过程中文字标签有个透明度渐变的动画，宽度约束通过对 ConstrainedBox 进行限制，并通过 Align 的 widthFactor 控制文字标签区域的尺寸。

这里的 ClipRect 组件套的很迷，我试了一下去除后并不影响动画效果，一开始不知道为什么要加。之后将动画时长拉长，进行了一些测试发现端倪，如果不进行裁剪，就会出现如下的不和谐情况。默认动画 200 ms 看不出太大差异。从这里我又学到了一个小技巧：如何动画展开一个区域。

所以说源码是最好的老师，通过分析源码的实现去思考和学习，是成长的一条很好的途径。而不是什么东西都靠别人给你灌输，遇到不会的或犹豫不决时就到处问。Flutter 组件的源码相对独立，套路也比较简单，很适合去研究学习。《Flutter 组件集录》 专栏专门用于收录我对 Flutter 常用组件的使用介绍，其中一般也会有相关源码实现的一些分析。对一些能力稍弱的朋友，也可以根据这些介绍去尝试研究。那本文就到这里，谢谢观看 ~

大家好，我是老王，最近开发新产品，然后老板说我们现在系统太多了，每次切换系统登录太麻烦了，能不能做个优化，同一账号互通掉。作为一个资深架构狮，老板的要求肯定要满足，安排！

一个公司产品矩阵比较丰富的时候，用户在不同系统之间来回切换，固然对产品用户体验上较差，并且增加用户密码管理成本。也没有很好地利用内部流量进行用户打通，并且每个产品的独立体系会导致产品安全度下降。因此实现集团产品的单点登录对用户使用体验以及效率提升有很大的帮助。那么如何实现统一认证呢？我们先了解一下传统的身份验证方式。

1 传统Session机制及身份认证方案

1.1 Cookie与服务器的交互

众所周知，http是无状态的协议，因此客户每次通过浏览器访问web

页面，请求到服务端时，服务器都会新建线程，打开新的会话，而且服务器也不会自动维护客户的上下文信息。比如我们现在要实现一个电商内的购物车功能，要怎么才能知道哪些购物车请求对应的是来自同一个客户的请求呢？

因此出现了session这个概念，session 就是一种保存上下文信息的机制，他是面向用户的，每一个SessionID 对应着一个用户，并且保存在服务端中。session主要 以 cookie 或 URL 重写为基础的来实现的，默认使用 cookie 来实现，系统会创造一个名为JSESSIONID的变量输出到cookie中。

JSESSIONID 是存储于浏览器内存中的，并不是写到硬盘上的，如果我们把浏览器的cookie 禁止，则 web 服务器会采用 URL 重写的方式传递 Sessionid，我们就可以在地址栏看到 sessionid=KWJHUG6JJM65HS2K6 之类的字符串。

通常 JSESSIONID 是不能跨窗口使用的，当你新开了一个浏览器窗口进入相同页面时，系统会赋予你一个新的sessionid，这样我们信息共享的目的就达不到了。

1.2 服务器端的session的机制

当服务端收到客户端的请求时候，首先判断请求里是否包含了JSESSIONID的sessionId，如果存在说明已经创建过了，直接从内存中拿出来使用，如果查询不到，说明是无效的。

如果客户请求不包含sessionid，则为此客户创建一个session并且生成一个与此session相关联的sessionid，这个sessionid将在本次响应中返回给客户端保存。

对每次http请求，都经历以下步骤处理：

-服务端首先查找对应的cookie的值（sessionid）。

-根据sessionid，从服务器端session存储中获取对应id的session数据，进行返回。

-如果找不到sessionid，服务器端就创建session，生成sessionid对应的cookie，写入到响应头中。

session是由服务端生成的，并且以散列表的形式保存在内存中

1.3 基于 session 的身份认证流程

基于seesion的身份认证主要流程如下：

因为 http 请求是无状态请求，所以在 Web 领域，大部分都是通过这种方式解决。但是这么做有什么问题呢？我们接着看

2 集群环境下的 Session 困境及解决方案

随着技术的发展，用户流量增大，单个服务器已经不能满足系统的需要了，分布式架构开始流行。通常都会把系统部署在多台服务器上，通过负载均衡把请求分发到其中的一台服务器上，这样很可能同一个用户的请求被分发到不同的服务器上，因为 session 是保存在服务器上的，那么很有可能第一次请求访问的 A 服务器，创建了 session，但是第二次访问到了 B 服务器，这时就会出现取不到 session 的情况。

我们知道，Session 一般是用来存会话全局的用户信息（不仅仅是登陆方面的问题），用来简化/加速后续的业务请求。

传统的 session 由服务器端生成并存储，当应用进行分布式集群部署的时候，如何保证不同服务器上 session 信息能够共享呢？

2.1 Session共享方案

Session共享一般有两种思路

• session复制


• session集中存储

2.1.1 session复制

session复制即将不同服务器上 session 数据进行复制，用户登录，修改，注销时，将session信息同时也复制到其他机器上面去

这种实现的问题就是实现成本高，维护难度大，并且会存在延迟登问题。

2.1.2 session集中存储

集中存储就是将获取session单独放在一个服务中进行存储，所有获取session的统一来这个服务中去取。这样就避免了同步和维护多套session的问题。一般我们都是使用redis进行集中式存储session。

3 多服务下的登陆困境及SSO方案

3.1 SSO的产生背景

如果企业做大了之后，一般都有很多的业务支持系统为其提供相应的管理和 IT 服务，按照传统的验证方式访问多系统，每个单独的系统都会有自己的安全体系和身份认证系统。进入每个系统都需要进行登录，获取session，再通过session访问对应系统资源。这样的局面不仅给管理上带来了很大的困难，对客户来说也极不友好，那么如何让客户只需登陆一次，就可以进入多个系统，而不需要重新登录呢？

“单点登录”就是专为解决此类问题的。 其大致思想流程如下：通过一个 ticket 进行串接各系统间的用户信息

3.2 SSO的底层原理 CAS

3.2.1 CAS实现单点登录流程

我们知道对于完全不同域名的系统，cookie 是无法跨域名共享的，因此 sessionId 在页面端也无法共享，因此需要实现单店登录，就需要启用一个专门用来登录的域名如（ouath.com）来提供所有系统的sessionId。当业务系统被打开时，借助中心授权系统进行登录，整体流程如下：

1.当b.com打开时，发现自己未登陆，于是跳转到ouath.com去登陆

2. ouath.com登陆页面被打开，用户输入帐户/密码登陆成功

3. ouath.com登陆成功，种 cookie 到ouath.com域名下

4. 把 sessionid 放入后台redis，存放<ticket，sesssionid>数据结构，然后页面重定向到A系统

5.当b.com重新被打开，发现仍然是未登陆，但是有了一个 ticket值

6. 当b.com用ticket 值，到 redis 里查到 sessionid，并做 session 同步，然后种cookie给自己，页面原地重定向

7. 当b.com打开自己页面，此时有了 cookie，后台校验登陆状态，成功

整个交互流程图如下：

3.2.2 单点登录流程演示

3.2.2.1 CAS登录服务demo核心代码

1.用户实体类

public class UserForm implements Serializable{

private static final long serialVersionUID = 1L;



private String username;

private String password;

private String backurl;



public String getUsername() {

    return username;

}



public void setUsername(String username) {

    this.username = username;

}



public String getPassword() {

    return password;

}



public void setPassword(String password) {

    this.password = password;

}



public String getBackurl() {

    return backurl;

}



public void setBackurl(String backurl) {

    this.backurl = backurl;

}



}

2.登录控制器

@Controller

public class IndexController {

    @Autowired

    private RedisTemplate redisTemplate;



@GetMapping("/toLogin")

public String toLogin(Model model,HttpServletRequest request) {

    Object userInfo = request.getSession().getAttribute(LoginFilter.USER_INFO);

    //不为空，则是已登陆状态

    if (null != userInfo){

        String ticket = UUID.randomUUID().toString();

        redisTemplate.opsForValue().set(ticket,userInfo,2, TimeUnit.SECONDS);

        return "redirect:"+request.getParameter("url")+"?ticket="+ticket;

    }

    UserForm user = new UserForm();

    user.setUsername("laowang");

    user.setPassword("laowang");

    user.setBackurl(request.getParameter("url"));

    model.addAttribute("user", user);



    return "login";

}



@PostMapping("/login")

public void login(@ModelAttribute UserForm user,HttpServletRequest request,HttpServletResponse response) throws IOException, ServletException {

    System.out.println("backurl:"+user.getBackurl());

    request.getSession().setAttribute(LoginFilter.USER_INFO,user);



    //登陆成功，创建用户信息票据

    String ticket = UUID.randomUUID().toString();

    redisTemplate.opsForValue().set(ticket,user,20, TimeUnit.SECONDS);

    //重定向，回原url  ---a.com

    if (null == user.getBackurl() || user.getBackurl().length()==0){

        response.sendRedirect("/index");

    } else {

        response.sendRedirect(user.getBackurl()+"?ticket="+ticket);

    }

}



@GetMapping("/index")

public ModelAndView index(HttpServletRequest request) {

    ModelAndView modelAndView = new ModelAndView();

    Object user = request.getSession().getAttribute(LoginFilter.USER_INFO);

    UserForm userInfo = (UserForm) user;

    modelAndView.setViewName("index");

    modelAndView.addObject("user", userInfo);

    request.getSession().setAttribute("test","123");

    return modelAndView;

}

}

3.登录过滤器

public class LoginFilter implements Filter {

    public static final String USER_INFO = "user";

    @Override

    public void init(FilterConfig filterConfig) throws ServletException {



}



@Override

public void doFilter(ServletRequest servletRequest,

                     ServletResponse servletResponse, FilterChain filterChain)

        throws IOException, ServletException {



    HttpServletRequest request = (HttpServletRequest) servletRequest;

     HttpServletResponse response = (HttpServletResponse)servletResponse;



    Object userInfo = request.getSession().getAttribute(USER_INFO);;



    //如果未登陆，则拒绝请求，转向登陆页面

    String requestUrl = request.getServletPath();

    if (!"/toLogin".equals(requestUrl)//不是登陆页面

            && !requestUrl.startsWith("/login")//不是去登陆

            && null == userInfo) {//不是登陆状态



        request.getRequestDispatcher("/toLogin").forward(request,response);

        return ;

    }



    filterChain.doFilter(request,servletResponse);

}



@Override

public void destroy() {



}

}

4.配置过滤器

@Configuration

public class LoginConfig {



//配置filter生效

@Bean

public FilterRegistrationBean sessionFilterRegistration() {



    FilterRegistrationBean registration = new FilterRegistrationBean();

    registration.setFilter(new LoginFilter());

    registration.addUrlPatterns("/*");

    registration.addInitParameter("paramName", "paramValue");

    registration.setName("sessionFilter");

    registration.setOrder(1);

    return registration;

}

}

5.登录页面

<!DOCTYPE HTML>

<html xmlns:th="http://www.thymeleaf.org">

<head>

    <title>enjoy login</title>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

</head>

<body>

<div text-align="center">

    <h1>请登陆</h1>

    <form action="#" th:action="@{/login}" th:object="${user}" method="post">

        <p>用户名: <input type="text" th:field="*{username}" /></p>

        <p>密  码: <input type="text" th:field="*{password}" /></p>

        <p><input type="submit" value="Submit" /> <input type="reset" value="Reset" /></p>

        <input type="text" th:field="*{backurl}" hidden="hidden" />

    </form>

</div>





</body>

</html>

3.2.2.2 web系统demo核心代码

1.过滤器

public class SSOFilter implements Filter {

    private RedisTemplate redisTemplate;



public static final String USER_INFO = "user";



public SSOFilter(RedisTemplate redisTemplate){

    this.redisTemplate = redisTemplate;

}

@Override

public void init(FilterConfig filterConfig) throws ServletException {



}



@Override

public void doFilter(ServletRequest servletRequest,

                     ServletResponse servletResponse, FilterChain filterChain)

        throws IOException, ServletException {



    HttpServletRequest request = (HttpServletRequest) servletRequest;

    HttpServletResponse response = (HttpServletResponse)servletResponse;



    Object userInfo = request.getSession().getAttribute(USER_INFO);;



    //如果未登陆，则拒绝请求，转向登陆页面

    String requestUrl = request.getServletPath();

    if (!"/toLogin".equals(requestUrl)//不是登陆页面

            && !requestUrl.startsWith("/login")//不是去登陆

            && null == userInfo) {//不是登陆状态



        String ticket = request.getParameter("ticket");

        //有票据,则使用票据去尝试拿取用户信息

        if (null != ticket){

            userInfo = redisTemplate.opsForValue().get(ticket);

        }

        //无法得到用户信息，则去登陆页面

        if (null == userInfo){

            response.sendRedirect("http://127.0.0.1:8080/toLogin?url="+request.getRequestURL().toString());

            return ;

        }



        /**

         * 将用户信息，加载进session中

         */

        UserForm user = (UserForm) userInfo;

        request.getSession().setAttribute(SSOFilter.USER_INFO,user);

        redisTemplate.delete(ticket);

    }



    filterChain.doFilter(request,servletResponse);

}



@Override

public void destroy() {



}

}

2.控制器

@Controller

public class IndexController {

    @Autowired

    private RedisTemplate redisTemplate;



@GetMapping("/index")

public ModelAndView index(HttpServletRequest request) {

    ModelAndView modelAndView = new ModelAndView();

    Object userInfo = request.getSession().getAttribute(SSOFilter.USER_INFO);

    UserForm user = (UserForm) userInfo;

    modelAndView.setViewName("index");

    modelAndView.addObject("user", user);



    request.getSession().setAttribute("test","123");

    return modelAndView;

}

}

3.首页

<!DOCTYPE HTML>

<html xmlns:th="http://www.thymeleaf.org">

<head>

    <title>enjoy index</title>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

</head>

<body>

<div th:object="${user}">

    <h1>cas-website：欢迎你"></h1>

</div>

</body>

</html>

3.2.3 CAS的单点登录和OAuth2的区别

OAuth2:三方授权协议，允许用户在不提供账号密码的情况下，通过信任的应用进行授权，使其客户端可以访问权限范围内的资源。

CAS ：中央认证服务（Central Authentication Service），一个基于Kerberos票据方式实现SSO单点登录的框架，为Web 应用系统提供一种可靠的单点登录解决方法（属于 Web SSO ）。

1. CAS的单点登录时保障客户端的用户资源的安全 ；OAuth2则是保障服务端的用户资源的安全 。


2. CAS客户端要获取的最终信息是，这个用户到底有没有权限访问我（CAS客户端）的资源；OAuth2获取的最终信息是，我（oauth2服务提供方）的用户的资源到底能不能让你（oauth2的客户端）访问。

因此，需要统一的账号密码进行身份认证，用CAS；需要授权第三方服务使用我方资源，使用OAuth2；

好了，不知道大家对SSO是否有了更深刻的理解，大家有问题可以私信我。我是王老狮，一个有想法有内涵的工程狮，关注我，学习更多技术知识。

引子

App 开发中，等待多个异步结果的场景很多见，

比如并发地在后台执行若干个运算，待所有运算执行完毕后归总结果。

比如并发地请求若干个接口，待所有结果返回后刷新界面。

比如统计相册页并发加载 20 张图片的耗时。

其实把若干异步任务串行化是最简单的解决办法，即前一个异步任务执行完毕后再执行下一个。但这样就无法利用多核性能，执行时间被拉长，此时的执行总时长 = 所有任务执行时长的和。

若允许任务并发，则执行总时长 = 执行时间最长任务的耗时。时间性能得以优化，但随之而来的一个复杂度是：“如何等待多个异步结果”。

本文会介绍几种解决方案，并将它们运用到不同的业务场景，比对一下哪个方案适用于哪个场景。

等待并发网络请求

布尔值

假设有如下两个网络请求：

// 拉取新闻

fun fetchNews() {

    newsApi.fetchNews().enqueue(object : Callback<List<News>> {

        override fun onFailure(call: Call<List<News>>, t: Throwable) { ... }

        override fun onResponse(call: Call<List<News>>, response: Response<List<News>>) { ... }

    })

}

// 拉取广告

fun fetchAd() {

    newsApi.fetchAd().enqueue(object : Callback<List<Ad>> {

        override fun onFailure(call: Call<List<Ad>>, t: Throwable) { ... }

        override fun onResponse(call: Call<List<Ad>>, response: Response<List<Ad>>) { ... }

    })

}

广告需要按一定规则插入到新闻列表中。

最简单的做法是，先请求新闻，待其返回后再请求广告。显然这会增加用户等待时间。而且会写出这样的代码：

// 拉取新闻

fun fetchNews() {

    newsApi.fetchNews().enqueue(object : Callback<News> {

        override fun onFailure(call: Call<News>, t: Throwable) { ... }

        override fun onResponse(call: Call<News>, response: Response<News>) {

                // 拉取广告

                newsApi.fetchAd().enqueue(object : Callback<Ad> {

                    override fun onFailure(call: Call<Ad>, t: Throwable) { ... }

                    override fun onResponse(call: Call<Ad>, response: Response<Ad>) { ... }

                })

        }

    })

}

嵌套回调，若再加一个接口，回调层次就会再加一层，不能忍。
用户和程序员的体验都不好，得想办法解决。

第一个想到的方案是布尔值：

var isNewsDone = false

var isAdDone = false

var news = emptyList()

var ads = emptyList()

// 拉取新闻

fun fetchNews() {

    newsApi.fetchNews().enqueue(object : Callback<List<News>> {

        override fun onFailure(call: Call<List<News>>, t: Throwable) { 

            isNewsDone = true

            tryRefresh(news, ad)

        }

        override fun onResponse(call: Call<List<News>>, response: Response<List<News>>) { 

            isNewsDone = true

            news = response.body().result

            tryRefresh(news, ad)

        }

    })

}

// 拉取广告

fun fetchAd() {

    newsApi.fetchAd().enqueue(object : Callback<List<Ad>> {

        override fun onFailure(call: Call<List<Ad>>, t: Throwable) { 

            isAdDone = true

            tryRefresh(news, ad)

        }

        override fun onResponse(call: Call<List<Ad>>, response: Response<List<Ad>>) { 

            isAdDone = true

            ads = response.body().result

            tryRefresh(news, ad)

        }

    })

}

// 尝试刷新界面（只有当两个请求都返回时才刷新）

fun tryRefresh(news: List<News>, ads: List<Ad>) {

    if(isNewsDone && isAdDone){ //刷新界面 }

}

设置两个布尔值分别对应两个请求是否返回，并且在每个请求返回时检测两个布尔值，若都为 true 则进行刷新界面。

网络库通常会将请求成功的回调抛到主线程执行，所以这里没有线程安全问题。但如果不是网络请求，而是后台任务，此时需要将布尔值声明为volatile保证其可见性，关于 volatile 更详细的解释可以点击面试题 | 徒手写一个非阻塞线程安全队列 ConcurrentLinkedQueue？。

这个方案能解决问题，但只适用于并发请求数量很少的请求，因为每个请求都要声明一个布尔值。而且每增加一个请求都要修改其余请求的代码，可维护性差。

CountdownLatch

更好的方案是CountDownLatch，它是java.util.concurrent包下的一个类，用来等待多个异步结果，用法如下：

val countdownLatch = CountDownLatch(2)//初始化，等待2个异步结果

var news = emptyList()

var ads = emptyList()

// 拉取新闻

fun fetchNews() {

    newsApi.fetchNews().enqueue(object : Callback<List<News>> {

        override fun onFailure(call: Call<List<News>>, t: Throwable) { 

            countdownLatch.countDown()

        }

        override fun onResponse(call: Call<List<News>>, response: Response<List<News>>) { 

            news = response.body().result

            countdownLatch.countDown()

        }

    })

}

// 拉取广告

fun fetchAd() {

    newsApi.fetchAd().enqueue(object : Callback<List<Ad>> {

        override fun onFailure(call: Call<List<Ad>>, t: Throwable) { 

            countdownLatch.countDown()

        }

        override fun onResponse(call: Call<List<Ad>>, response: Response<List<Ad>>) { 

            ads = response.body().result

            countdownLatch.countDown()

        }

    })

}

// countdownLatch 在新线程中等待

thread { 

    countdownLatch.await() // 阻塞线程等待两个请求返回

    liveData.postValue() // 抛数据到主线程刷刷新界面

}.start()

CountDownLatch 在构造时需传入一个数量，它的语义可以理解为一个计数器。countDown() 将计数器减一，而 await() 会阻塞当前线程直到计数器为 0 才被唤醒。

该计数器是一个 int 值，可能被多线程访问，为了保证线程安全，它被声明为 volatile，并且 countDown() 通过 CAS + 自旋的方式将其减一。

关于 CAS 的介绍可以点击面试题 | 徒手写一个非阻塞线程安全队列 ConcurrentLinkedQueue？。

若新增一个接口，只需要将计数器的值加一，并在新接口返回时调用 countDown() 即可，可维护性陡增。

协程

Kotlin 是降低复杂度的大师，它对于这个问题的解决方案可以让代码看上去更简单。

在 Kotlin 的世界里异步操作应该被定义为suspend方法，retrofit 就支持这样的操作，比如：

interface NewsApi {

    @GET("/xxx")

    suspend fun fetchNews(): List<News>

    @GET("/xxx")

    suspend fun fetchAd(): List<Ad>

}

然后在协程中使用async启动异步任务：

scope.launch {

    // 并发地请求网络

    val newsDefered = async { fetchNews() }

    val adDefered = async { fetchAd() }

    // 等待两个网络请求返回

    val news = newsDefered.await()

    val ads = adDefered.await()

    // 刷新界面

    refreshUi(news, ads)

}

不管是写起来还是读起来，体验都非常好。因为协程把回调干掉了，逻辑不会跳来跳去。

其中的async()是 CoroutineScope 的扩展方法：

// 启动协程，并返回协程执行结果

public fun <T> CoroutineScope.async(

    context: CoroutineContext = EmptyCoroutineContext,

    start: CoroutineStart = CoroutineStart.DEFAULT,

    block: suspend CoroutineScope.() -> T

): Deferred<T> {

    ...

}

async() 和 launch() 唯一的不同是它的返回值是Defered，用于描述协程体执行的结果：

public interface Deferred<out T> : Job {

    // 挂起方法: 等待值的计算，但不会阻塞当前线程，计算完成后恢复当前协程执行

    public suspend fun await(): T

}

调用async()启动子协程不会挂起外层协程，而是立即返回一个Deferred对象，直到调用Deferred.await()协程的执行才会被挂起。当协程在多个Deferred对象上被挂起时，只有当它们都恢复后，协程才继续执行。这样就实现了“等待多个并行的异步结果”。

但这样写会问题：当广告拉取抛出异常时，新闻拉取也会被取消。

这是协程的一个默认设定，叫结构化并发，即并发是有结构性的。

Java 中线程的并发是没有结构的，所以做如下事情很困难：

1. 结束一个线程时，如何一并结束它所有的子线程？


2. 当某个子线程抛出异常时，如何结束和它同一层级的兄弟线程？


3. 父线程如何等待所有子线程结束之后才结束？

之所以会很困难，是因为 Java 中的线程是没有级联关系的。而 Kotlin 通过协程域 CoroutineScope 以及协程上下文 CoroutineContext 实现级联关系。

在协程中启动的子协程会继承父协程的协程上下文，除了其中的 Job，一个新的 Job 会被创建并归属于父协程的子 Job。通过这套机制，协程和子协程之间有了级联关系，就能实现结构化并发。（以后会就结构化并发写一个系列，敬请期待~）

关于 CoroutineContext 内部结构的详细剖析可以点击Kotlin 协程 | CoroutineContext 为什么要设计成 indexed set？

但有些业务场景不需要子任务之间相互关联，比如当前场景，广告加载失败不应该影响新闻的拉取，大不了不展示广告。为此 kotlin 提供了supervisorScope：

scope.launch {

    supervisorScope {

        // 并发地请求网络

        val newsDefered = async { fetchNews() }

        val adDefered = async { fetchAd() }

        // 等待两个网络请求返回

        val news = newsDefered.await()

        val ads = adDefered.await()

        // 刷新界面

        refreshUi(news, ads)

    }

}

supervisorScope 新建一个协程域继承父亲的协程上下文，但会将其中的 Job 重写为SupervisorJob，它的特点就是孩子的失败不会影响父亲，也不会影响兄弟。

现在广告和新闻加载互不影响，各自抛异常都不会影响对方。但就目前的业务场景来说，理想情况是这样的：“广告加载失败不应该影响新闻的加载。但新闻加载失败应该取消广告的加载（因为此时广告也没有展示的机会）”

稍改动下代码：

scope.launch {

    supervisorScope {

        // 并发地请求网络

        val adDefered = async { fetchAd() }

        val newsDefered = async { fetchNews() }

        // 当新闻请求抛异常时，取消广告请求

        newsDefered.invokeOnCompletion { throwable ->

            throwable?.let { adDefered.cancel() }

        }

        // 等待新闻

        val news = try {

            newsDefered.await()

        } catch (e: Exception) {

            emptyList()

        }

        // 等待广告

        val ads = try {

            adDefered.await()

        } catch (e: Exception) {

            emptyList()

        }

        // 刷新界面

        refreshUi(news, ads)

    }

}

invokeOnCompletion()相当于注册了一个回调，在异步任务结束时调用，不管是正常结束还是因异常而结束。在该回调中判断，若新闻因异常而结束则取消广告任务。

因为新闻和广告任务都可能抛出异常，且 async 启动的异步任务是在调用 await() 时才会抛出异常，所以它应该包裹在 try-catch 中。Kotlin 中的 try-catch 是一个表达式，即是有返回值的。这个特性让正常和异常情况的值聚合在一个表达式中。

若不使用 try-catch，程序也不会奔溃，因为 supervisorScope 中异常是不会向上传播的，即子协程的异常不会影响兄弟和父亲。但这样就少了异常情况的处理。

若现有代码都是 Callback 形式的，还能不能享受协程的简洁？

能！Kotlin 提供了suspendCoroutine()，专门用于将回调风格的代码转换成 suspend 方法，以拉取新闻为例：

// Callback 形式

fun fetchNews() {

    newsApi.fetchNews().enqueue(object : Callback<List<News>> {

        override fun onFailure(call: Call<List<News>>, t: Throwable) { ... }

        override fun onResponse(call: Call<List<News>>, response: Response<List<News>>) { ... }

    })

}



// suspend 形式

suspend fun fetchNews() = suspendCoroutine<List<News>> { continuation ->

    newsApi.fetchNews().enqueue(object : Callback<List<News>> {

        override fun onFailure(call: Call<List<News>>, t: Throwable) { 

            continuation.resumeWithException(t)

        }

        override fun onResponse(call: Call<List<News>>, response: Response<List<News>>) { 

            continuation.resume(response.body().result)

        }

    }) 

}

其中的Continuation是剩余的计算，从形式上看，它就是一个回调：

public interface Continuation<in T> {

    public val context: CoroutineContext

    public fun resumeWith(result: Result<T>) // 开始剩余的计算

}

每个 suspend 方法被编译成 java 之后，都会在原有方法参数表最后添加一个 Continuation 参数，用于表达这个挂起点之后“剩余的计算”，举个例子：

scope.launch {

    fun1() // 普通方法

    suspendFun1() // 挂起方法 

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

    fun2() // 普通方法

    suspendFun2() // 挂起方法

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

}

整个协程体中有四个方法，其中两个是挂起方法，每个挂起方法都是一道水平的分割线，分割线下方的代码就是当前执行点相对于整个协程体剩余的计算，这“剩余的计算”会被包装成 Continuation 并作为参数传入挂起方法。所以上述代码翻译成 java 就类似于：

scope.launch {

    fun1()

    suspendFun1(new Continuation() {

        @override

        public void resumeWith(Result<T> result) {

            fun2()

            suspendFun2(new Continuation() {

                @override

                public void resumeWith(Result<T> result) {

                    

                }

            })

        }

    })

}

所以挂起方法无异于 java 中带回调的方法，它自然不会阻塞当前线程，它只是把协程体中剩下的代码当成回调，该回调会在将来某个时间点被执行。通过这种方式，挂起方法主动让出了 cpu 执行权。

题外话

从业务上讲，将 Callback 方法改造成挂起式可以降低业务复杂度。举个例子：用户可以通过若干动作触发拉取新闻，比如首次进入新闻页、下拉刷新新闻页、上拉加载更多新闻、切换分区。新闻页有一个埋点，当首次展示某分区时，上报此时的新闻。

若没有 suspend 方法，代码应该这样写：

// NewsViewModel.kt

fun fetchNews(isFirstLoad: Boolean, isChangeType: Boolean) {

    newsApi.fetchNews().enqueue(object : Callback<List<News>> {

        override fun onFailure(call: Call<List<News>>, t: Throwable) { ... }

        override fun onResponse(call: Call<List<News>>, response: Response<List<News>>) { 

            // 将新闻抛给界面刷新

            newsLiveData.value = response.body.result

            // 只有当首次加载或切换分区时时才埋点

            if(isFirstLoad || isChangeType) {

                reportNews(response.body.result)

            }

        }

    })

}

// NewsActivity.kt

// 分区切换监听

tab.setOnTabChangeListener { index ->

    newsViewModel.fetchNews(false, true)

}

// 首次加载新闻

fun init() {

    newsViewModel.fetchNews(true, false)

}

// 下拉刷新

refreshLayout.setOnRefreshListener {

    newsViewModel.fetchNews(false, false)

}

// 上拉加载更多

refreshLayout.setOnLoadMoreListener {

    newsViewModel.fetchNews(false, false)

}

因为埋点需要带上新闻列表，所以必须在请求返回之后上报。不同业务场景的拉取接口是同一个，所以只能在统一的 onResponse() 中分类讨论，分类讨论依赖于标记位，不得不为 fetchNews() 添加两个参数。

如果将拉取新闻的接口改成 suspend 方式就能化解这类复杂度：

// NewsViewModel.kt

suspend fun fetchNews() = suspendCoroutine<List<News>> { continuation ->

    newsApi.fetchNews().enqueue(object : Callback<List<News>> {

        override fun onFailure(call: Call<List<News>>, t: Throwable) { 

            continuation.resumeWithException(t)

        }

        override fun onResponse(call: Call<List<News>>, response: Response<List<News>>) { 

            val news = response.body.result

            newsLiveData.value = news

            continuation.resume(news)

        }

    }) 

}



// NewsActivity.kt

fun initNews() {

    scope.launch {

        val news = viewModel.fetchNews()

        reportNews(news)

    }

}



fun changeNewsType() {

    scope.launch {

        val news = viewModel.fetchNews()

        reportNews(news)

    }

}



fun loadMoreNews() {

    scope.launch { viewModel.fetchNews() }

}



fun refreshNews() {

    scope.launch { viewModel.fetchNews() }

}



newsViewModel.newsLiveData.observe {news ->

    showNews(news)

}

所有界面的刷新还是走 LiveData，但拉取新闻的方法被改造成挂起之后，也会将新闻列表用类似同步的方式返回，所以可以在相关业务点进行单独埋点。

统计相册加载图片耗时

再通过一个更高并发数的场景比对下各个方案代码上的差异，场景如下：

测试并发加载 20 张网络图片的总耗时。该场景下已经无法使用布尔值，因为并发数太多。

CountdownLatch

var start = SystemClock.elapsedRealtime()

var imageUrls = listOf(...)

val countdownLatch = CountDownLatch(imageUrls.size)

// 另起线程等待 CountDownLatch 并输出耗时

scope.launch(Dispatchers.IO) {

    countdownLatch.await()

    Log.d( "test", "time-consume=${SystemClock.elapsedRealtime() - start}" )

}



// 遍历 20 张图片 url

imageUrls.forEach { img ->

        ImageView {// 动态构建 ImageView

            layout_width = 100

            layout_height = 100

            Glide.with(this@GlideActivity)

                .load(img)

                .listener(object : RequestListener<Drawable> {

                    override fun onLoadFailed(

                        e: GlideException?,

                        model: Any?,

                        target: Target<Drawable>?,

                        isFirstResource: Boolean

                    ): Boolean {

                        countdownLatch.countDown() // 加载完一张

                        return false

                    }



                    override fun onResourceReady(

                        resource: Drawable?,

                        model: Any?,

                        target: Target<Drawable>?,

                        dataSource: DataSource?,

                        isFirstResource: Boolean

                    ): Boolean {

                        countdownLatch.countDown() // 加载完一张

                        return false

                    }

                })

               .into(this)

        }

}

协程

var imageUrls = listOf(...)

scope.launch {

    val start = SystemClock.elapsedRealtime()

    // 将每个 url 都变换为一个 Defered

    val defers = imageUrls.map { img ->

            val imageView = ImageView {

                layout_width = 100

                layout_height = 100

            }

            async { imageView.loadImage(img) }

    }

    defers.awaitAll()//等待所有的异步任务结束

    Log.d( "test", "time-consume=${SystemClock.elapsedRealtime() - start}" )

}

// 将 Callback 方式的加载转换为挂起方式

private suspend fun ImageView.loadImage(img: String) = suspendCoroutine<String> { continuation ->

    Glide.with(this@GlideActivity)

        .load(img)

        .listener(object : RequestListener<Drawable> {

            override fun onLoadFailed(

                e: GlideException?,

                model: Any?,

                target: Target<Drawable>?,

                isFirstResource: Boolean

            ): Boolean {

                continuation.resume("")

                return false

            }



            override fun onResourceReady(

                resource: Drawable?,

                model: Any?,

                target: Target<Drawable>?,

                dataSource: DataSource?,

                isFirstResource: Boolean

            ): Boolean {

                continuation.resume("")

                return false

            }

        })

        .into(this)

}

你更喜欢哪种方式？