概述

本次关于 uni-app 代码整体重构工作，基于上一期针对 uni-app 官网 demo 从 vue2 迁移 vue3 框架衍生而来，在迁移过程中有明显感知，目前的项目存在的问题为，项目部分代码风格较为不统一，命名不够规范，注释不够清晰、可读性差、以造成如果复用困难重重，本地重构期望能够充分展示 api 在实际项目中的调用方式，尽可能达到示例代码可移植，或能辅助进行即时通讯功能二次开发的能力。

目的

• 使代码更加可读。

• 简化或去除冗余代码。

• 部分组件以及逻辑重命名、重拆分、重合并。

• 增加全局状态管理。

• 修改 SDK 引入方式为通过 npm 形式引入

• 收束 SDK 大部分 API 到统一文件、方便管理调用。

• 升级 SDK api 至最新的调用方式（监听、发送消息）

• 增加会话列表接口、消息漫游接口。

• SDK 指环信 IM uni-app SDK

重构计划

一、修改原 WebIM 的导出导入使用方式。

目的

1. 现有 uniSDK 已支持 npm 形式导入。
2. 原有实例化代码与 config 配置较为混乱不够清晰。
3. 分离初始化以及配置形成独立文件方便管理。

实现

1. 项目目录中创建 EaseIM 文件夹并创建 index.js,在 index.js 中完成导入 SDK 并实现实例化并导出。
2. EaseIM -> config 文件夹并将 SDK 中相关配置在此文件中书写并导出供实例化使用。
   

影响（无影响）

二、引入 pinia 进行状态管理

Pinia 文档

Uni-app Pinia 文档

pinia 还能通过$reset()方法即可完成对某个 store 的初始化，利用该方法可以非常方便的在切换账号时针对缓存在 stores 中的数据初始化，防止切换后的账号与上一个账号的数据造成冲突。

目的

1. 存放 SDK 部分数据以及状态（登录状态、会话列表数据、消息数据）
2. 方便各组件状态或数据取用避免数据层层传递。
3. 用以平替原有本地持久化数据存储。
4. 可以替代原有 disp 发布订阅管理工具，因为 store 中状态改变，各组件可以进行重新计算或监听，无需通过发布订阅通知改变状态。

实现

1. 在 mian.js 中引入 pinia,并挂载

//Pinia

import * as Pinia from 'pinia';

export function createApp() {

  const app = createSSRApp(App);

  app.use(Pinia.createPinia());

  return {

    app,

    Pinia,

  };

}

2. 项目目录中新建 stores 并创建各个所需 store，类似目录如下：
   

影响（无影响）

三、重新梳理 App.vue 根组件中代码

目的

1. 简化项目中 App.vue 根组件中的冗长代码。
2. 迁移根组件中的监听代码。
3. globalData，method 中代码转为 stores 中或剔除。
4. disp 代码剔除。

实现

1. App.vue 中的监听嵌入至 EaseIM 文件夹下的 listener 集中管理，并在 App.vue 中重新进行挂载
2. import ‘@/EaseIM’;从而实现实例化 SDK。
3. 将需要 IM 连接成功后调用的数据，合为一个方法中，并在 onConnected 触发后调用。
4. 部分关于 SDK 调用的代码迁入至 EaseIM 文件夹下的 imApis 文件夹中
5. 部分有关 SDK 的工具方法代码迁入至 EaseIM 文件夹下的 utils 文件夹中

影响

App.vue 改动相对较大，主要为监听的迁移，一部分方法迁移至 stores 中，并且需要重新进行监听的挂载。具体代码可在后续迁移前后比对中看到，或者文尾的看到 github 中看到代码地址。

四、优化 login 页面代码

目的

原有 login 组件登录部分代码比较冗长并且可读性较差因此进行优化。

实现

1. 删除原有操作 input 的代码，改为通过 v-model 双向绑定。
2. 拆分登录代码为通过 username+password,以及手机号+验证码两个登录方法。
3. 增加登录存储 token 方法，方便后续重连时通过用户名+token 形式进行重新登录。
4. 登录成功之后将登录的 id 以及手机号信息 set 进入到 stores 中。

影响（无影响）

五、增加 home 页面

目的

1. 作为 Conversation、Contacts、Me 三个核心页面容器组件，方便页面切换管理。
2. 作为 Tabbar 的容器组件

实现

1. 去除原有会话、联系人、我的（原 setting 页面）pages.json 的路由配置，增加 home 页面路由相关配置。
2. pages 中增加 home 组件，并以组件化的形式引入三个核心页面组件。
3. 项目根目录中新建 layout 文件夹并增加 tabbar 组件，将三个页面中的 tabbar 功能抽离至 tabbar 组件中，并增加相应切换逻辑。

影响

此改动主要影响为要涉及到将原 setting 组件改为 Me 组件，并将三个原有页面 pages.json 删除并在 home 中引入，并无其他副作用。

六、重构 Conversation、Contacts、Me 等基础组件

目的

1. 将原有数据(会话列表数据，联系人数据，昵称头像数据)来源切换为从 SDK 接口+stores 中获取。
2. 去除组件内的 disp 发布订阅相关代码，以及 WebIM 的使用。
3. 调整原组件代码中的不合理的命名，去除不再使用的方法简化该组件代码。

实现

以 Conversation 组件举例

1. 以 SDK 接口 getConversationlist 获取会话列表数据，缓存至 stores 中并做排序处理，在组件中使用计算属性获取作为新的会话列表数据来源。
2. 由于会话列表的更新是动态的，因此不再需要 disp 订阅一系列的事件进行处理，因此相关代码可以开始进行删除。
3. 原有的通过会话列表跳转至联系人页面或者其他群组页面命名改为单词从 into 改为 entry 并改为驼峰命名，经过改造该组件用不到的方法则完全删除。

影响

主要影响则是这些组件内的逻辑代码会有从结构以及数据源会有较大变化，需要边改造边验证，并且会与 stores、EaseIM 等组件有较大的关系，需要耐心进行调整。

七、增加 emChatContainer 组件

目的

1. 新增此组件命名更为语义化，能够通过组件名看出其实际功能为 emChat 聊天页组件容器。
2. 合并原有 singleChatEntry 组件以及 groupChatEntry 组件，两个相似功能组件至统一的一个 emChatContainer 内。

实现

1. 在 pages 下新建一个名为 emChatContainer 的组件，并先将 components 下的 chat 组件参考 singleChatEntry 组件引入，并在 pages 中配置对应路由路径映射。
2. 观察发现该组件作为 chat 组件容器，主要向下传递两个核心参数，1）目标 ID（也就是聊天的目标环信 ID）。2）chatType（也就是目标聊天的类型，常规为单聊、群聊。），且这两个核心参数经常被 chat 组件中的各个子组件用到，一层层向下传递较为繁琐，因此使用到 Vue 组件传参方法之一的，provide、inject 方式将参数注册并向下传递下去。
3. 完成合并之后将 singleChatEntry、groupChatEntry 删去，并且将原有用到向该组件跳转的方法路径全部指向 emChatContainer，且在 pages.json 中删除对应的页面路径。

影响

从会话进入到聊天页、从联系人、群组页面进入到聊天页的路由跳转路径全部改为 emChatContainer，并且将会改变 chat 组件使用 targetId（聊天目标 ID）以及 chatType 的方式，因为需要改为通过 inject 接收。

八、emChat 组件重构

目的

1. 改写该组件下不合理的文件命名。
2. 删除非必要的 js 文件或组件。
3. 该组件内各个功能子组件进行局部代码重构。

实现

1. 配合 emChatContainer 将 chat 组件改名为 emChat。
2. 删除其组件内的 msgpackager.js、msgstorage.js、msgtype.js、pushStorage.js，这几个 js 文件。
3. messagelist inputbar 改为驼峰命名。
4. messageList 组件内的消息列表来源改为从 stores 中获取，增加下拉通过 getHistroyMessage 获取历史消息。
5. 子组件内接收目标 id 以及消息类型改为通过 inject 接收。
6. msgType 从 EaseIM/constant 中获取。
7. 发送消息 API 全部改为 SDK4.xPromise 写法，在 EaseIM/imApis/emMessages 统一并导出，在需要的发送的组件中导入调用，剔除原有发送消息的方式。

影响

该组件调整难度最大，因为牵扯的组件，以及需要新增的调整的代码较多，需要逐个组件修改并验证，具体代码将在下方局部展示。详情请参看源码地址。

九、新增重连中提示监听回调

目的

能够在 IM websocket 断开的时候有相应的回调出来，并给到用户相应的提示。

实现

在 addEventHandler 监听中增加 onReconnecting 监听回调，并且在实际触发的时候增加 Toast 提示监听 IM 正在重连中。

PS：onReconnecting 属于实验性回调。

影响（无影响）

概述

我们都知道ConstraintLayout在构建嵌套层级复杂的视图界面时可以有效降低视图树的高度，使视图树扁平化，约束布局在测量布局耗时上比传统的相对布局具有更好的性能，并且约束布局可以根据百分比自适应各种尺寸的终端设备。因为约束布局确实很好用，所以，官方也为我们将约束布局迁移到了Compose平台。本文就是介绍约束布局在Compose中的使用。

实例解析

在使用约束布局之前，我们需要先在项目中的app.gradle脚本中添加compose版本的ConstraintLayout依赖

implementation('androidx.constraintlayout:constraintlayout-compose:1.0.1')

引入依赖以后，我们就可以看下如何在Compose中使用约束布局了

1.创建引用

在传统View系统中，我们在布局XML文件中可以给View设置资源的ID，并将资源ID作为索引来声明对应组件的摆放位置。而在Compose的约束布局中，可以主动创建引用并绑定到某个具体组件上，从而实现与资源ID相似的功能，每个组件都可以利用其他组件的引用获取到其他组件的摆放位置信息，从而确定自己摆放位置。

Compose 创建约束布局的方式有两种，分别时createRef()和createRefs(),根据字面意思我们就可以很清楚的知道，createRef()，每次只会创建一个引用，而createRefs()每次可以创建多个引用（最多可以创建16个），创建引用的方式如下：

// 创建单个引用

 val text = createRef()

// 创建多个引用

 val (button1,button2,text) = createRefs()

2.绑定引用

当我们创建完引用后就可以使用Modifier.constrainAs()修饰符将我们创建的引用绑定到某个具体组件上，可以在contrainAs尾部Lambda内指定组件的约束信息。我们需要注意的是，我们只能在ConstraintLayout尾部的Lambda中使用createRefer，createRefs函数创建引用，并使用Modifier.constrainAs函数来绑定引用，因为ConstrainScope尾部的Lambda的Reciever是一个ConstraintLayoutScope作用域对象。我们可以先看下面一段代码了解下约束布局的引用绑定：

@Composable

fun ConstrainLayoutDemo()

{

    ConstraintLayout(modifier = Modifier

        .width(300.dp)

        .height(100.dp)

        .padding(5.dp)

        .border(5.dp, color = Color.Red)) {

        val portraitImageRef = remember {

            createRef()

        }



        Image(painter = painterResource(id = R.drawable.portrait)

            , contentDescription = null,

        modifier = Modifier.constrainAs(portraitImageRef){

            top.linkTo(parent.top)

            bottom.linkTo(parent.bottom)

            start.linkTo(parent.start)

        })



    }

}

运行结果：

上面的代码是实现一个用户卡片的部分代码，从代码中看到我们使用约束的时候需要用到Modifier.constrainsAs(){……}的方式。Modifier.constrainsAs的尾部Lambda是一个ConstrainScope作用域对象，可以在其中获取当前组件的parent,top,bottom,start,end等信息。并使用linkTo指定组件约束。在上面的界面中，我们希望用户的头像可以居左对齐，所以将top拉伸至父组件的顶部，bottom拉伸至父组件的底部，start拉伸至父组件的左边。我们再为卡片添加上用户的昵称和描述，全部代码如下所示:

@Composable

fun ConstrainLayoutDemo()

{

    ConstraintLayout(modifier = Modifier

        .width(300.dp)

        .height(100.dp)

        .padding(5.dp)

        .border(5.dp, color = Color.Red)) {

        val (portraitImageRef,usernameTextRef,descriptionTextRef) = remember {

            createRefs()

        }



        Image(painter = painterResource(id = R.drawable.portrait)

            , contentDescription = null,

        modifier = Modifier.constrainAs(portraitImageRef){

            top.linkTo(parent.top)

            bottom.linkTo(parent.bottom)

            start.linkTo(parent.start)

        })



        Text(text = "旅游小美女", fontSize = 16.sp, maxLines = 1,

        textAlign = TextAlign.Left,

        modifier = Modifier.constrainAs(usernameTextRef){

            top.linkTo(portraitImageRef.top)

            start.linkTo(portraitImageRef.end,10.dp)

        })



        Text(text = "个人描述。。。。。。。。", fontSize = 14.sp,

            color = Color.Gray,

            fontWeight = FontWeight.Light,

            modifier = Modifier.constrainAs(descriptionTextRef){

                top.linkTo(usernameTextRef.bottom,5.dp)

                start.linkTo(portraitImageRef.end,10.dp)

            }

        )

    }

}

运行结果：

在上面的代码中我们也可以在ConstrainScope中指定组件的宽高信息，在ConstrainScope中直接设置width与height的可选值如下所示：

在ConstrainScope中指定组件的宽高信息时，通过在Modifier.constrainAs(xxxRef){width = Dimension.可选值}来设置，可选值如下：
Dimension.wrapContent: 实际尺寸为根据内容自适应
Dimension.matchParent: 实际尺寸为铺满父组件的尺寸
Dimension,wrapContent: 实际尺寸为根据约束信息拉伸后的尺寸
Dimension.preferredWrapContent： 如果剩余空间大于更具内容自适应的尺寸时，实际尺寸为自适应的尺寸，如果剩余空间小于内容自适应尺寸时，实际尺寸为剩余空间尺寸
Dimension.ratio(String): 根据字符串计算实际尺寸所占比率：如1 ：2
Dimension.percent(Float): 根据浮点数计算实际尺寸所占比率
Dimension.value(Dp): 将尺寸设置为固定值
Dimension.perferredValue(Dp): 如果剩余空间大于固定值时，实际尺寸为固定值，如果剩余空间小于固定值时，实际尺寸则为剩余空间尺寸

我们想象下，假如用户的昵称特别长，那么按照我们上面的代码展示则会出现展示不全的问题，所以我们可以通过设置end来指定组件所允许的最大宽度，并将width设置为preferredWrapContent,意思是当用户名很长时，实际的宽度会做自适应调整。我们将上面展示用户名的地方改一下，代码如下：

// 上面的代码只用改这个部分

   Text(

            text = "旅游小美女美美美美美名字很长长长长长长长长长",

            fontSize = 16.sp,

        textAlign = TextAlign.Left,

        modifier = Modifier.constrainAs(usernameTextRef){

            top.linkTo(portraitImageRef.top)

            start.linkTo(portraitImageRef.end,10.dp)

            end.linkTo(parent.end,10.dp)

            width = Dimension.preferredWrapContent

        })

运行结果：

辅助布局工具

在传统View的约束布局中有Barrier,GuideLine等辅助布局的工具，在Compose中也继承了这些特性，方便我们完成各种复杂场景的布局需求。

1.Barrier分界线

Barrier顾名思义就是一个屏障，使用它可以隔离UI布局上面的一些相互挤压的影响，举一个例子，比如我们希望两个输入框左对齐摆放，并且距离文本组件中的最长者仍保持着10dp的间隔，当用户名和密码等发生变化时，输入框的位置能够自适应调整。这里使用Barrier特性可以简单的实现这一需求：

@Composable

fun InputFieldLayout(){

    ConstraintLayout(

        modifier = Modifier

            .width(400.dp)

            .padding(10.dp)

    ) {

        val (usernameTextRef, passwordTextRef, usernameInputRef, passWordInputRef) = remember { createRefs() }

        val barrier = createEndBarrier(usernameTextRef, passwordTextRef)

        Text(

            text = "用户名",

            fontSize = 14.sp,

            textAlign = TextAlign.Left,

            modifier = Modifier

                .constrainAs(usernameTextRef) {

                    top.linkTo(parent.top)

                    start.linkTo(parent.start)

                }

        )



        Text(

            text = "密码",

            fontSize = 14.sp,

            modifier = Modifier

                .constrainAs(passwordTextRef) {

                    top.linkTo(usernameTextRef.bottom, 20.dp)

                    start.linkTo(parent.start)

                }

        )

        OutlinedTextField(

            value = "",

            onValueChange = {},

            modifier = Modifier.constrainAs(usernameInputRef) {

                start.linkTo(barrier, 10.dp)

                top.linkTo(usernameTextRef.top)

                bottom.linkTo(usernameTextRef.bottom)

                height = Dimension.fillToConstraints

            }

        )

        OutlinedTextField(

            value = "",

            onValueChange = {},

            modifier = Modifier.constrainAs(passWordInputRef) {

                start.linkTo(barrier, 10.dp)

                top.linkTo(passwordTextRef.top)

                bottom.linkTo(passwordTextRef.bottom)

                height = Dimension.fillToConstraints

            }

        )

    }

}

运行结果：

2.Guideline引导线

Barrier分界线需要依赖其他引用，从而确定自身的位置，而使用Guideline不依赖任何引用，例如，我们希望将用户头像摆放在距离屏幕顶部2：8的高度位置，头像以上是用户背景，以下是用户信息，这样的需求就可以使用Guideline实现，代码如下：

@Composable

fun GuidelineDemo(){

   ConstraintLayout(modifier = Modifier

       .height(300.dp)

       .background(color = Color.Gray)) {

       val guideline = createGuidelineFromTop(0.2f)

       val (userPortraitBackgroundRef,userPortraitImgRef,welcomeRef) = remember {

           createRefs()

       }



       Box(modifier = Modifier

           .constrainAs(userPortraitBackgroundRef) {

               top.linkTo(parent.top)

               bottom.linkTo(guideline)

               height = Dimension.fillToConstraints

               width = Dimension.matchParent

           }

           .background(Color(0xFF673AB7)))



       Image(painter = painterResource(id = R.drawable.portrait),

           contentDescription = null,

           modifier = Modifier

               .constrainAs(userPortraitImgRef) {

                   top.linkTo(guideline)

                   bottom.linkTo(guideline)

                   start.linkTo(parent.start)

                   end.linkTo(parent.end)

               }

               .size(100.dp)

               .clip(CircleShape)

               .border(width = 2.dp, color = Color(0xFF96659E), shape = CircleShape))



       Text(text = "不喝奶茶的小白兔",

       color = Color.White,

       fontSize = 26.sp,

       modifier = Modifier.constrainAs(welcomeRef){

           top.linkTo(userPortraitImgRef.bottom,10.dp)

           start.linkTo(parent.start)

           end.linkTo(parent.end)

       })



   }

}

运行结果：

在上面的代码中，我们使用createGuidelineFromTop()方法创建了一条从顶部出发的引导线，然后用户背景就可以依赖这条引导线确定宽高了，然后对于头像，我们只需要将top和bottom连接至引导线即可

3.Chain链接约束

ContraintLayout的另一个好用的特性就是Chain链接约束，通过链接约束可以允许多个组件平均分配布局空间，类似于weight修饰符。例如我们要展示一首古诗，用Chain链接约束实现如下：

@Composable

fun showQuotesDemo() {

    ConstraintLayout(

        modifier = Modifier

            .size(400.dp)

            .background(Color.Black)

    ) {

        val (quotesFirstLineRef, quotesSecondLineRef, quotesThirdLineRef, quotesForthLineRef) = remember {

            createRefs()

        }



        createVerticalChain(

            quotesFirstLineRef, quotesSecondLineRef, quotesThirdLineRef, quotesForthLineRef,

            chainStyle = ChainStyle.Spread

        )



        Text(text = "窗前明月光，",

            color = Color.White,

            fontSize = 20.sp,

            fontWeight = FontWeight.Bold,

            modifier = Modifier.constrainAs(quotesFirstLineRef) {

                start.linkTo(parent.start)

                end.linkTo(parent.end)

            })



        Text(text = "疑是地上霜。",

            color = Color.White,

            fontSize = 20.sp,

            fontWeight = FontWeight.Bold,

            modifier = Modifier.constrainAs(quotesSecondLineRef) {

                start.linkTo(parent.start)

                end.linkTo(parent.end)

            })



        Text(text = "举头望明月，",

            color = Color.White,

            fontSize = 20.sp,

            fontWeight = FontWeight.Bold,

            modifier = Modifier.constrainAs(quotesThirdLineRef) {

                start.linkTo(parent.start)

                end.linkTo(parent.end)

            })



        Text(text = "低头思故乡。",

            color = Color.White,

            fontSize = 20.sp,

            fontWeight = FontWeight.Bold,

            modifier = Modifier.constrainAs(quotesForthLineRef) {

                start.linkTo(parent.start)

                end.linkTo(parent.end)

            })

    }

}

运行结果：

如上面代码所示，我们要展示四句诗就需要创建四个引用对应四句诗，然后我们就可以创建一条垂直的链接约束将四句诗词连接起来，创建链接约束时末尾参数可以传一个ChainStyle，用来表示我们期望的布局样式，它的取值有三个，效果和意义如下所示：

（1）Spread：链条中的每个元素平分整个父空间

 createVerticalChain(

            quotesFirstLineRef, quotesSecondLineRef, quotesThirdLineRef, quotesForthLineRef,

            chainStyle = ChainStyle.Spread)

运行效果：

（2）SpreadInside:链条中的首尾元素紧贴边界，剩下的每个元素平分整个父空间

 createVerticalChain(

            quotesFirstLineRef, quotesSecondLineRef, quotesThirdLineRef, quotesForthLineRef,

            chainStyle = ChainStyle.SpreadInside)

运行效果：

（3）Packed:链条中的所有元素都聚集到中间，效果如下

 createVerticalChain(

            quotesFirstLineRef, quotesSecondLineRef, quotesThirdLineRef, quotesForthLineRef,

            chainStyle = ChainStyle.Packed)

运行效果：

总结

关于Compose约束布局的内容就是这些了，本文主要是简单的介绍了Compose中约束布局的基本使用，要熟练掌握Compose约束布局，还需要读者多去联系，多使用约束布局写界面，这样就会熟能生巧，在此我只做一个抛砖引玉的活。有任何疑问，欢迎在评论区交流。

前言

日新计划可真头疼，每天更文养成习惯是好，但有时候没思路就很烦，回到正题，本篇回到很久之前的组件学习（安卓UI设计开发——Material Design(BottomSheetDialogFragment篇) - 掘金 (juejin.cn)），这次我们来看看许多APP首页常用的NavigationView——滑动菜单如何使用。

2/22 更正：NavigationView为导航视图，DrawerLayout为抽屉布局，一起组合成滑动菜单（实现侧滑交互体验）

正篇

首先，使用NavigationView前我们先创建一个新项目，我这里为了学习这些组件，命名为MaterialDemo，作为我们学习Materia组件的项目，然后因为要使用Material库的NavigationView，所以我们项目的app目录下的build.gradle文件中的dependencies闭包中添加下面依赖：

implementation 'com.google.android.material:material:1.8.0'

implementation 'de.hdodenhof:circleimageview:3.1.0'

其中第二个依赖是我们导入的开源项目CircleImageView，这可以让我们更容易实现图片圆形化，也就是这个滑动菜单栏上圆形头像的形成。

当然，新建的是Kotlin安卓空Activity项目，我们采用了ViewBinding，所以同时也要在该文件下启用ViewBinding,位置在android闭包中：

buildFeatures {

    viewBinding = true

}

sync Gradle（同步 Gradle)完成后，我们再把res/values/theme.xml文件中AppTheme的parent主题换为Theme.MaterialComponents.Light.NoActionBar，用来适配我们的Material库组件：

我们还得事先准备几张图片备用（按钮，头像等），这里我放在了drawable-xxhdpi目录下，当然如果有需要可以到文末我的Github项目中找：

接着，我们在res目录下创建新的名为menu文件夹(和之前文章安卓开发基础——Menu菜单的使用 - 掘金 (juejin.cn)一样)：

再在这个文件夹上右击->New->Menu resource file ，创建一个nav_menu.xml文件，添加下面的代码：

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

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

    <group android:checkableBehavior="single">

        <item

            android:id="@+id/navCall"

            android:icon="@drawable/nav_call"

            android:title="Call" />

        <item

            android:id="@+id/navFriends"

            android:icon="@drawable/nav_friends"

            android:title="Friends" />

        <item

            android:id="@+id/navLocation"

            android:icon="@drawable/nav_location"

            android:title="Location" />

        <item

            android:id="@+id/navMail"

            android:icon="@drawable/nav_mail"

            android:title="Mail" />

        <item

            android:id="@+id/navTask"

            android:icon="@drawable/nav_task"

            android:title="Tasks" />

    </group>

</menu>

上面代码中我们加了一个group标签，并把其中的checkableBehavior属性设置为single，这样就能让菜单项变为只可以单选。
然后我们就能预览到这个菜单样式，这就是我们即将用的具体的菜单项：

但NavigationView样式不是这个预览到的，因为有菜单项这样还是不够的，我们还需要准备一个herderLayout用于显示NavigationView的头部布局，这个布局可以按照需求来定制，这里我们就构建了头像、用户名和邮箱地址这三项，这个布局我们直接在layout目录正常创建布局文件就行，我们这里创建一个名为nav_header的XML布局文件：

该文件代码如下：

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

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

    android:layout_width="match_parent"

    android:layout_height="180dp"

    android:padding="10dp"

    android:background="?attr/colorPrimary">



    <de.hdodenhof.circleimageview.CircleImageView

        android:id="@+id/iconImage"

        android:layout_width="70dp"

        android:layout_height="70dp"

        android:src="@drawable/nav_icon"

        android:layout_centerInParent="true" />



    <TextView

        android:id="@+id/mailText"

        android:layout_width="wrap_content"

        android:layout_height="wrap_content"

        android:layout_alignParentBottom="true"

        android:text="tonygreendev@gmail.com"

        android:textColor="#FFF"

        android:textSize="14sp" />



    <TextView

        android:id="@+id/userText"

        android:layout_width="wrap_content"

        android:layout_height="wrap_content"

        android:layout_above="@id/mailText"

        android:text="Tony Green"

        android:textColor="#FFF"

        android:textSize="14sp" />



</RelativeLayout>

我们使用了相对布局（RelativeLayout）作为最外层布局，其中CircleImageView就是之前加依赖提到的开源控件，将我们的图片圆形化，和ImageView用法一样，这里我们用于构建圆形的头像图片，且设为居中，还有两个TextView分别就是我们的用户名和邮箱地址，用相对布局属性定位即可。

这些做完后，我们的准备阶段就完成了，接下来我们开始使用NavigationView控件：

我们先把布局添加NavigationView：

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

<androidx.drawerlayout.widget.DrawerLayout

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

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

    android:id="@+id/drawerLayout"

    android:layout_width="match_parent"

    android:layout_height="match_parent">



    <FrameLayout

        android:layout_width="match_parent"

        android:layout_height="match_parent">

        

        <androidx.appcompat.widget.Toolbar

            android:id="@+id/toolbar"

            android:layout_width="match_parent"

            android:layout_height="?attr/actionBarSize"

            android:background="?attr/colorPrimary"

            android:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar"

            app:popupTheme="@style/ThemeOverlay.AppCompat.Light" />

    </FrameLayout>

            



    <com.google.android.material.navigation.NavigationView

        android:id="@+id/navView"

        android:layout_width="match_parent"

        android:layout_height="match_parent"

        android:layout_gravity="start"

        app:menu="@menu/nav_menu"

        app:headerLayout="@layout/nav_header"/>



</androidx.drawerlayout.widget.DrawerLayout>

Activity中：

package com.example.materialdemo



import androidx.appcompat.app.AppCompatActivity

import android.os.Bundle

import com.example.materialdemo.databinding.ActivityMainBinding



class MainActivity : AppCompatActivity() {



    lateinit var binding: ActivityMainBinding

    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        binding = ActivityMainBinding.inflate(layoutInflater)

        setContentView(binding.root)



        setSupportActionBar(binding.toolbar)



        supportActionBar?.let {

            it.setDisplayHomeAsUpEnabled(true)

            it.setHomeAsUpIndicator(R.drawable.ic_menu)

        }

        binding.navView.setCheckedItem(R.id.navCall)

        binding.navView.setNavigationItemSelectedListener {

            binding.drawerLayout.closeDrawers()

            true

        }

    }

}

最终效果：

这里一开始忘记加我的项目地址了，现在补上：GitHub - ObliviateOnline/MaterialDemo: Material库组件学习

总结

今天学了NavigationView，结果忘记写前面的滑动菜单DrawerLayout和标题栏Toolbar控件了，下一篇就把前面的构建过程给理一遍。

随着 Google I/O 2023 发布的 Android beta2 ，预计 Android 14 将在2023年第三季度发布，目前看整体需要适配的内容已经趋向稳定，那就根据官方文档简单做个适配要点总结吧。

如何做到最优雅的版本适配？那就是尽可能提高 minitSdkVersion ，说服老板相信低版本用户无价值论，低版本用户更多是羊毛党～

针对 Android 14 或更高版本的应用

这部分主要是影响 targetSdkVersion 34 的情况 ，目前 Google Play 已经开始要求 33 了，相信未来 34 也不远了。

前台服务类型

targetSdkVersion 34 的情况下，必须为应用内的每个前台服务(foreground-services) 指定至少一种前台服务类型。

前台服务类型是在 Android 10 引入的，通过 android:foregroundServiceType 可以指定 <service> 的服务类型，可供选择的前台服务类型有：

• camera


• connectedDevice


• dataSync


• health


• location


• mediaPlayback


• mediaProjection


• microphone


• phoneCall


• remoteMessaging


• shortService


• specialUse


• systemExempted

例如：

<manifest ...>

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

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

   <application ...>

     <service

         android:name=".MyMediaPlaybackService"

         android:foregroundServiceType="mediaPlayback"

         android:exported="false">

     </service>

   </application>

</manifest>

如果你 App 中的用例与这些类型中的任何一种都不相关，那么建议还是将服务迁移成 WorkManager 或 jobs 。

更多详细可见：developer.android.com/about/versi…

安全

对 pending/implicit intent 的限制

对于面向 Android 14 的应用，Android 通过以下方式限制应用向内部应用组件发送隐式 intent：

• 隐式 intent 仅传递给导出的组件，应用必须使用明确的 intent 来交付给未导出的组件，或者将组件标记为已导出（exported） 。


• 如果应用创建一个 mutable pending intent ，但 intent 未指定组件或包，系统现在会抛出异常。

这些更改可防止恶意应用拦截只供给用内部组件使用的隐式 intent，例如：

<activity

   android:name=".AppActivity"

   android:exported="false">

   <intent-filter>

       <action android:name="com.example.action.APP_ACTION" />

       <category android:name="android.intent.category.DEFAULT" />

   </intent-filter>

</activity>

如果应用尝试使用隐式 intent 启动该 activity，则会抛出异常：

// Throws an exception when targeting Android 14.

context.startActivity(Intent("com.example.action.APP_ACTION"))

要启动未导出的 Activity，应用应改用显式 Intent：

// This makes the intent explicit.

val explicitIntent =

       Intent("com.example.action.APP_ACTION")

explicitIntent.apply {

   package = context.packageName

}

context.startActivity(explicitIntent)

运行时注册的广播接收器必须指定导出行为

以 Android 14 为目标，并使用 context-registered receivers （ContextCompat.registerReceiver）应用和服务的需要指定一个标志，以指示接收器是否应导出到设备上的所有其他应用：分别为 RECEIVER_EXPORTED 或 RECEIVER_NOT_EXPORTED。

val filter = IntentFilter(APP_SPECIFIC_BROADCAST)

val listenToBroadcastsFromOtherApps = false

val receiverFlags = if (listenToBroadcastsFromOtherApps) {

   ContextCompat.RECEIVER_EXPORTED

} else {

   ContextCompat.RECEIVER_NOT_EXPORTED

}

ContextCompat.registerReceiver(context, br, filter, receiverFlags)

仅接收系统广播的接收器例外

如果应用仅通过 Context#registerReceiver 方法为系统广播注册接收器时，那么它可以不在注册接收器时指定标志， 例如 android.intent.action.AIRPLANE_MODE 。

更安全的动态代码加载

如果应用以 Android 14 为目标平台并使用动态代码加载 (DCL)，则所有动态加载的文件都必须标记为只读，否则，系统会抛出异常。

我们建议应用尽可能避免动态加载代码，因为这样做会大大增加应用因代码注入或代码篡改而受到危害的风险。

如果必须动态加载代码，请使用以下方法将动态加载的文件（例如 DEX、JAR 或 APK 文件）在文件打开后和写入任何内容之前立即设置为只读：

val jar = File("DYNAMICALLY_LOADED_FILE.jar")

val os = FileOutputStream(jar)

os.use {

   // Set the file to read-only first to prevent race conditions

   jar.setReadOnly()

   // Then write the actual file content

}

val cl = PathClassLoader(jar, parentClassLoader)

处理已存在的动态加载文件

为防止现有动态加载文件抛出异常，我们建议可以尝试在应用中再次动态加载文件之前，删除并重新创建这些文件。

重新创建文件时，请按照前面的指导在写入时将文件标记为只读，或者将现有文件重新标记为只读，但在这种情况下，强烈建议首先验证文件的完整性（例如，通过根据可信值检查文件的签名），以帮助保护应用免受恶意操作。

Zip path traversal

对于针对 Android 14 的应用，Android 通过以下方式防止 Zip 路径遍历漏洞：如果 zip 文件条目名称包含 “..” 或以 “/” 开头，则 ZipFile(String) 和 ZipInputStream.getNextEntry() 会抛出一个 ZipException 。

应用可以通过调用 dalvik.system.ZipPathValidator.clearCallback() 选择退出验证。

从后台启动活动的附加限制

针对 Android 14 的应用，系统进一步限制了应用在后台启动 Activity 的时间：

• 当应用使用 PendingIntent#send() 发送 PendingIntent 以及类似行为时，如果应用想要授予其自己的后台 service 启动权限以启动 pending intent，则该应用现在必须选择加入一个 ActivityOptions，具体为带有 setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)


• 当一个可见应用使用 bindService() 绑定另一个在后台运行的应用的服务时，如果该可见应用想要将其自己的后台 activity 启动权限授予绑定服务，则它现在必须选择加入 BIND_ALLOW_ACTIVITY_STARTS 标志。

这些更改扩展了现有的一组限制 ，通过防止恶意应用滥用 API 从后台启动破坏性活动来保护用户。

具体可见：developer.android.com/guide/compo…

OpenJDK 17

Android 14 会要求的 OpenJDK 17 的支持，这对一些语法上可以会有一定影响，例如：

• 对正则表达式的更改：现在不允许无效的组引用


• UUID 处理：java.util.UUID.fromString() 方法现在在验证输入参数时会进行更严格的检查


• ProGuard 问题：在某些情况下，如果使用 ProGuard 缩小、混淆和优化应用，添加 java.lang.ClassValue 会导致出现问题，问题源于 Kotlin 库，库会根据是否 Class.forName("java.lang.ClassValue") 返回类来更改运行时行为。

反正适配 OpenJDK 17 就对了，新版 Android Studio Flamingo 也默认内置 OpenJDK 17 了。

针对所有版本的 Android 14 变更

以下行为主要针对在 Android 14 上运行的所有应用，可以看到从 Android 10 开始， Androd Team 针对这些变动越来越强势。

核心功能

默认情况下拒绝计划精确提醒

精确提醒（Exact alarms）用于用户有目的的通知，或用于需要在精确时间发生的操作情况，从 Android 14 开始，该 SCHEDULE_EXACT_ALARM 权限不再预先授予大多数新安装的针对 Android 13 及更高版本的应用，默认情况下该权限会被拒绝。

如果用户通过备份还原操作将应用数据传输到运行Android 14 的设备上，权限仍然会被拒绝。如果现有的应用已经拥有该权限，它将在设备升级到 Android 14 时预先授予。

而现在需要权限 SCHEDULE_EXACT_ALARM 才能通过以下 API 启动确切的提醒，否则将抛出 SecurityException：

• setExact()


• setExactAndAllowWhileIdle()


• setAlarmClock()

注意： 如果确切的 alarms 是使用 OnAlarmListener 对象设置的，例如在 setExact API 中，SCHEDULE_EXACT_ALARM 则不需要权限。

现有的权限最佳实践 SCHEDULE_EXACT_ALARM 仍然适用，包括以下内容：

• 在安排确切的提醒之前检查权限 canScheduleExactAlarms()。


• 设置应用以 AlarmManager.ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED 监听前台广播并对其做出正确反应 ，系统会在用户授予权限时发送该广播。

详细可见：developer.android.com/about/versi…

Context-registered 广播在缓存应用时排队

在 Android 14 上，当应用处于缓存状态时，系统可能会将上下文注册的广播放入队列中。

这类似于 Android 12（API 级别 31）为异步活页夹事务引入的排队行为，清单声明的广播不会排队，并且应用会从缓存状态中删除以进行广播传输。

当应用离开缓存状态时，例如返回前台，系统会传送任何排队中的广播，某些广播的多个实例可以合并为一个广播。

根据其他因素（例如系统运行状况），应用可能会从缓存状态中删除，并且先前排队的所有广播都会被传送。

应用只能杀死自己的后台进程

从 Android 14 开始，应用调用 killBackgroundProcesses() 时，该 API 只能杀死自己应用的后台进程。

如果传入其他应用的包名，该方法对该应用的后台进程没有影响，Logcat中会出现如下信息：

Invalid packageName: com.example.anotherapp

应用不应该使用 killBackgroundProcesses() API ，或以其他方式尝试影响其他应用的进程生命周期，即使是在较旧的操作系统版本上。

Android 旨在将缓存的应用保留在后台，并在系统需要内存时自动终止它们，如果应用出现不必要地杀死其他应用，它会降低系统性能并增加电池消耗，因为稍后需要完全重启这些应用，比恢复现有的缓存应用占用的资源要多得多。

安全

最低可安装目标 API 级别

从 Android 14 开始，无法安装 targetSdkVersion 低于 23 的应用 ，要求应用必须满足这些最低目标 API 级别，这样可以提高用户的安全性和隐私性。

恶意软件通常以较旧的 API 级别为 target，以绕过较新 Android 版本中引入的安全和隐私保护，例如一些恶意软件应用使用 targetSdkVersion 22 的来避免受到 Android 6.0 的运行时权限模型的约束。

Android 14 的这一变化使恶意软件更难避开安全和隐私管理，尝试安装针对较低 API 级别的应用将导致安装失败，并在 Logcat 中显示以下消息：

INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 23, but found 7

在升级到 Android 14 的设备上，任何低于targetSdkVersion23 的应用都将保持安装状态，如果你需要针对较旧 API 级别的应用进行测试，请使用以下 ADB 命令：

adb install --bypass-low-target-sdk-block FILENAME.apk

用户体验

授予对照片和视频的部分访问权限

注意： 如果你的应用已经使用了系统照片选择器（photopicker），那么无需进行任何改动。

在 Android 14 上，当应用请求 Android 13（API 级别 33）中引入的任何 READ_MEDIA_IMAGES或 READ_MEDIA_VIDEO 媒体权限时，用户可以授予对其照片和视频的部分访问权限。

新对话框显示以下权限选项：

• 选择照片和视频： Android 14 中的新功能，用户选择他们想要提供给应用的特定照片和视频。


• 全部允许：用户授予对设备上所有照片和视频的完整库访问权限。


• 不允许：用户拒绝所有访问。

要在应用中出现改逻辑，可以声明新的 READ_MEDIA_VISUAL_USER_SELECTED 权限。

详细可见：developer.android.com/about/versi…

安全的全屏 Intent 通知

在 Android 11（API 级别 30）中，任何应用都可以通过 Notification.Builder.setFullScreenIntent 在手机锁定时发送全屏 intent。

一般可以通过在 AndroidManifest 中声明 USE_FULL_SCREEN_INTENT 权限来在应用安装时自动授予该权限 ，全屏 intent 通知专为需要用户立即关注的极高优先级通知而设计，例如来电或用户配置的闹钟设置。

从 Android 14 开始，允许使用该权限的应用仅限于提供通话和闹钟的应用，Google Play 商店会撤销任何不符合该配置文件的应用的默认权限。

在用户更新到 Android 14 之前，该权限对安装在手机上的应用保持启用状态，用户可以打开和关闭该权限。

开发者可以使用新的API NotificationManager.canUseFullScreenIntent 来检查应用是否具有权限；如果没有，应用可以使用新的 ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT 来启动跳转到可以授予权限的设置页面。

改变用户体验不可关闭通知的方式

如果你的应用向用户显示不可关闭的前台通知，Android 14 已更改行为以允许用户关闭此类通知。

此次更改适用于通过 Notification.Builder#setOngoing(true) 或者 NotificationCompat.Builder#setOngoing(true) 来设置 Notification.FLAG_ONGOING_EVENT 从而阻止用户关闭前台通知的应用 的行为。

现在 FLAG_ONGOING_EVENT 的行为已经改变，用户实际上可以关闭此类通知。

在以下情况下，该类通知仍然不可关闭：

• 当手机被锁定时


• 如果用户选择清除所有通知操作（这有助于防止意外）

此外，新行为不适用于以下用例中的不可关闭通知：

• 使用 CallStyle与真实通话相关的通知


• 使用 MediaStyle 创建的通知


• 设备策略控制器 (DPC) 和企业支持包

辅助功能

非线性字体缩放至 200%

从 Android 14 开始，系统支持高达 200% 的字体缩放，为弱视用户提供符合 Web 内容无障碍指南 (WCAG) 的额外无障碍选项。

如果已经使用缩放像素 (sp) 单位来定义文本大小，那么此次更改可能不会对应用产生重大影响。

DialogFragment

Android 中 Dialog 并没办法感知生命周期，但 Frg 可以感知，所以将 Diglog 与 Frg 结合后生成 DialogFragment，它提供了可以感知生命周期的 Dialog。另外 DialogFragment 也继承 Fragment，所以也可以当作普通的 Fragment 使用。

由于 DialogFragment 可以感知生命周期，而且还处理了 Dialog 状态的保存与恢复，所以 DialogFragment 应多用。

原理

DialogFragment 中的 Dialog 是在 onGetLayoutInflater 中创建的，该方法会先于 onCreateView() 调用，但后于 onCreate()。

第一个问题：DialogFragment 当作 Dialog 使用时为什么不会显示到 Activity 布局中，而是以 Dialog 形式出现。将 DialogFragment 当作 Dialog 用时需要调用其 show 方法，其内部也是使用了 FragmentTransaction，只不过依赖的 containerViewId 是 0，因此无法添加到某个 View 上，也就不会在 Activity 布局中显示。

// show() 方法节选

FragmentManager manager = ....

FragmentTransaction ft = manager.beginTransaction();

ft.setReorderingAllowed(true);

ft.add(this, tag);

ft.commit();



// FragmentTransaction::add() 方法

public FragmentTransaction add(@NonNull Fragment fragment, @Nullable String tag)  {

    // 主要第一个参数是 0，这就导致调用 show 方法时不会显示到具体界面

    doAddOp(0, fragment, tag, OP_ADD);

    return this;

}



// 将 Frg 当作普通 Frg 使用时会调用该方法

public FragmentTransaction add(@IdRes int containerViewId, @NonNull Fragment fragment) {

    // 此时 containerViewId 就不是 0，所以 Fragment 中的 view 会显示到界面上

    doAddOp(containerViewId, fragment, null, OP_ADD);

    return this;

}

通过 show() 方法将当前 Fragment 绑定到了某一个 Activity，当 Frg 感知到生命周期发生变化时就会将 Dialog 显示或隐藏，而且在 onSaveInstanceState 等方法也处理了状态的保存与显示。

// onResume() 回调中会显示 dialog

// onStop() 回调中隐藏 dialog

// onDestroyView() 中会销毁 Dialog

public void onStop() {

    super.onStop();

    if (mDialog != null) {

        mDialog.hide();

    }

}

第二个问题：onCreateView() 返回的 View 有什么用。onCreateView() 返回的 View 就是 Dialog 要显示的内容。在 DialogFragment::onAttach() 中会添加一个监听

// mObserver 中通过 requireView() 拿到 onCreateView() 的返回值

// 同时调用 Dialog::setContentView() 将返回值设置成 dialog 显示的内容

// mObserver 节选

if (lifecycleOwner != null && mShowsDialog) {

    // 拿到 onCreateView 返回值

    View view = requireView();

    if (view.getParent() != null) {

        throw new IllegalStateException(

                "DialogFragment can not be attached to a container view");

    }

    if (mDialog != null) {

        mDialog.setContentView(view);

    }

}

// onAttach() 节选

getViewLifecycleOwnerLiveData().observeForever(mObserver);

第三个问题：上面 mObserver 看出如果不重写 onCreateView()，requireView() 应该会报错的，为啥使用时不会出问题。这个主要在 Fragment::performCreateView() 中

mViewLifecycleOwner = new FragmentViewLifecycleOwner(this, getViewModelStore());

// 调用 onCreateView() 默认返回 null

mView = onCreateView(inflater, container, savedInstanceState);

if (mView != null) {

   // 只有 mView 不为 null 时才触发 liveData 更新，上面的 mObserver 才会收到通知

    // Then inform any Observers of the new LifecycleOwner

    mViewLifecycleOwnerLiveData.setValue(mViewLifecycleOwner);

} else {

    mViewLifecycleOwner = null;

}

BottomSheetDialogFragment

继承于 DialogFragment，只不过它返回的 Dialog 是 BottomSheetDialog。从上面可以看出 onCreateView() 的返回值最终会传递给 Dialog::setContentView() 中。BottomSheetDialog::setContentView() 会调用 wrapInBottomSheet()，最核心的两句就是：

// 它会初始化一个 View，该 View 就是 Dialog 要显示的 View

ensureContainerAndBehavior();

// view 就是我们传入 setContentView 中的 view

// bottomSheet 就是上面 View 的一个子 View

bottomSheet.addView(view);



// 生成 Dialog 要显示的 View 

private FrameLayout ensureContainerAndBehavior() {

  if (container == null) {

    container =

        (FrameLayout) View.inflate(getContext(), R.layout.design_bottom_sheet_dialog, null);

    coordinator = (CoordinatorLayout) container.findViewById(R.id.coordinator);

    

    // 查看上面的布局，可以发现 bottomSheet 是 CoordinatorLayout 的子类

    // 其 behavior 是 com.google.android.material.bottomsheet.BottomSheetBehavior

    bottomSheet = (FrameLayout) container.findViewById(R.id.design_bottom_sheet);

    behavior = BottomSheetBehavior.from(bottomSheet);

    behavior.addBottomSheetCallback(bottomSheetCallback);

    behavior.setHideable(cancelable);

  }

  return container;

}

总之，BottomSheetDialogFragment 会将 onCreateView() 的返回结果包裹在 CoordinatorLayout 中，从而实现 bottom_sheet 效果。

前言

突发奇想想搞一个同步切换线程的Kotlin协程,而不用各种withContext(){},可以减少嵌套且逻辑更清晰,想实现的结果如下图:

分析

实现我们想要的结果,首先需要知道协程为什么可以控制线程的切换以及在挂起函数恢复的时候回到原来设定的线程中

ps:挂起函数比普通函数多出了两个操作:挂起和恢复,具体参考:Kotlin协程在项目中的实际应用_lt的博客-CSDN博客_kotlin协程使用

其实控制线程切换是协程库内内置的一个拦截器类:ContinuationInterceptor

拦截器是一个协程上下文元素(ContinuationInterceptor实现了Element接口 ,Element实现了CoroutineContext接口)

拦截器的作用是将协程体包装一层后,拦截其恢复功能(resumeWith),这样就可以在协程恢复的时候将包装在其内部的协程体在相应的线程中恢复执行(执行resumeWith方法)

比如协程自带的Dispatchers.Main,Dispatchers.IO等都是协程拦截器,下面简单分析下Dispatchers.IO拦截器

我们点进去IO的定义,兜兜转转的找到其实现类LimitingDispatcher,其继承了ExecutorCoroutineDispatcher ,ExecutorCoroutineDispatcher继承了CoroutineDispatcher ,CoroutineDispatcher实现了ContinuationInterceptor接口,也就是其最终实现了协程拦截器的接口

CoroutineDispatcher重写了拦截器的interceptContinuation方法,该方法就是用来包装并拦截的

然后我们在看看DispatchedContinuation的resumeWith方法(也就是如何拦截并将包装的协程体运行在子线程的)

ps:其实走的是resumeCancellableWith方法,因为协程内部做了一个判断,IO的拦截器是继承了DispatchedContinuation的

第一个红框IO那是写死的true,所以只会走第一个流程,而第二个红框你可以简单的理解为将后续任务(下面的代码逻辑)放在这个dispatcher的线程池中运行(就相当于将协程中的代码的线程放到了IO子线程中运行了)

通过上面的分析,其实IO的拦截器可以简单理解为如下代码:

实现

那我们是不是可以将拦截器从协程上下文中移除呢?我试了下并不行,发现是在launch的时候会自动判断,如果没有拦截器则默认附加Dispatchers.Default拦截器用于将操作置于子线程中

ps:可以通过遍历来查看当前协程上下文中都有哪些协程元素(下面是反射的实现,可以使用系统提供的fold来遍历):

/**

 * 通过反射遍历协程上下文中的元素

 */

fun CoroutineContext.forEach(action: (CoroutineContext.Element) -> Unit) {

    val modeClass = Class.forName("kotlin.coroutines.CombinedContext")

    val elementField = modeClass.getDeclaredField("element")

    elementField.isAccessible = true

    val leftField = modeClass.getDeclaredField("left")

    leftField.isAccessible = true

    var context: CoroutineContext? = this

    while (context?.javaClass == modeClass) {

        (elementField.get(context) as? CoroutineContext.Element)?.let(action)

        context = leftField.get(context) as? CoroutineContext

    }

    (context as? CoroutineContext.Element)?.let(action)

}



coroutineContext.forEach {

    it.toString().e()

}

pps:协程上下文其实是以链表形式来存储的,CombinedContext就相当于链表的Node节点,其element相当于数据,其left相当于下一个节点,而存储的最后一个节点是未经过CombinedContext包装的协程上下文元素(可能是节省空间);而不管协程上下文,或者CombinedContext的element和left,都是val的,这样上下文都是只读的,避免了并发修改的危险.

那现在看来其实我们只要自己写一个拦截器,然后在运行协程的时候附加上去,线程切换就可以由我们来控制了,那实现起来其实也很简单,代码如下:

/**

 * 同步切换线程的协程元素,需要注意所有挂起函数都有可能影响到后面的线程,所以需要注意:最好内部使用不会切换线程的挂起函数(或者你清楚使用的后果)

 */

fun CoroutineScope.launchSyncSwitchThread(block: suspend SyncSwitchThreadCoroutineScope.() -> Unit): Job =

        launch(SyncSwitchThreadContinuationInterceptor) { SyncSwitchThreadCoroutineScope(this@launch).block() }



//拦截器

object SyncSwitchThreadContinuationInterceptor : ContinuationInterceptor {

    override val key: CoroutineContext.Key<*> = ContinuationInterceptor



    override fun <T> interceptContinuation(continuation: Continuation<T>): Continuation<T> = SyncSwitchThreadContinuation(continuation)



    //协程体包装类

    class SyncSwitchThreadContinuation<T>(private val continuation: Continuation<T>) : Continuation<T> {

        override val context: CoroutineContext = continuation.context



        //这里我们不进行拦截恢复方法,直接使用恢复者(谁调用了resume)的线程

        override fun resumeWith(result: Result<T>): Unit = continuation.resumeWith(result)

    }

    

    //协程作用域包装类,用于控制toMain等方法不会被别的地方使用

    class SyncSwitchThreadCoroutineScope(coroutineScope: CoroutineScope) : CoroutineScope by coroutineScope {

        private suspend inline fun suspendToThread(crossinline threadFunction: (()->Unit) -> Unit) =

                suspendCoroutine<Unit> {

                    threadFunction {

                        if (it.context.isActive)

                            it.resume(Unit)

                    }

                }



        //切换到主线程,[force]是否强制post到主线程(false:如果当前是主线程则不会post)

        suspend fun toMain(force: Boolean = false) {

            if (!force && isMainThread) return

            suspendToThread(HandlerPool::postEmptyListener)//Handler#post方法

        }



        //切换到单例子线程

        suspend fun toSingle(): Unit = suspendToThread(ThreadPool::submitToSingleThreadPool)//提交到单线程线程池



        suspend fun toIO(): Unit = suspendToThread(ThreadPool::submitToCacheThreadPool)//提交到子线程池



        suspend fun toCPU(): Unit = suspendToThread(ThreadPool::submitToCPUThreadPool)//提交到CPU密集型子线程池



        //或者为了理解起来简单减少封装写成如下方式

        suspend fun toCPU(): Unit = suspendCoroutine { 

            ThreadPool.submitToCacheThreadPool { 

                if(it.context.isActive)

                    it.resume(Unit)

            }

        }

    }

}

ps:第一次运行的线程是启动它的线程

pps:这里我们包装了一下协程作用域CoroutineScope,可以防止toMain这些方法用在别的地方造成歧义且无用

然后我们就可以像开头那样使用了

或者通过协程上下文的plus(+)方法来替换掉默认的拦截器:

最后在封装一下:

fun CoroutineScope.launchSyncSwitchThread(block: suspend SyncSwitchThreadCoroutineScope.() -> Unit): Job =

        launch(SyncSwitchThreadContinuationInterceptor) { SyncSwitchThreadCoroutineScope(this@launch).block() }

使用方式就和最开始的图一样了

结语

这样就ok了,其实任何事情只要了解原理,就可以很快的想到方案,如果不清楚原理,就会对一些事情一头雾水

ps:其实使用Dispatchers.Unconfined也可以实现相同的效果2333,但是了解原理还是更重要

pps:如果想限制launchSyncSwitchThread的lambda范围内只能使用自己定义的几个挂起函数,只需要给SyncSwitchThreadCoroutineScope类加上@RestrictsSuspension注解即可,这样在SyncSwitchThreadCoroutineScope的作用域内,只能使用他内部定义的挂起函数,可以有效减少别的挂起函数意外切换掉线程的情况

end

周岭在《认知觉醒》一书中提出了快速改变人生的五件事，即:「早起」、「冥想」、「阅读」、「写作」、「运动」。低调务实优秀中国好青年交流群也正是从这 5 件事入手，帮你养成好习惯。我也试着实践了有将近一年的时间，今谈谈收获与心得。

早起

一日之计在于晨，一年之计在于春；早起是个老生常谈的话题了，鲁迅先生小时候为了上课不迟到，还把「早」刻在桌上告诫自己。我小时候每天晚上吃完饭，没什么事早早地就睡了，甚至觉得十点睡觉都是一件很可怕的事。如今呢，自从步入互联网时代，十点？不好意思，十点夜生活才刚刚开始。

秉承着先僵化、后优化、再固化的原则，我决定尝试一段时间。起初几天是真的很难受，白天浑浑噩噩的完全提不起精神。不过慢慢的，晚上倒是越来越早的睡了。差不多半个月时间几乎都习惯了 10 点左右睡觉，6 点前起床。正常早上六点起床后，稍微锻炼一会回来坐那下下汗，冲个凉水澡，然后吃个早饭就去工作了。

持续了有半年时间，直观感受就是身体越来越好，精神头越来越棒；但我并不认为这是早起带来的，潜移默化改变了我的是生活规律。毕竟美国人时差和咱们完全反着来，也没见几个英年嗝屁的。现在为止，我想早起也许就真的只是早点起来罢了。

但有一天，我翻看着旧日的朋友圈：星光不问赶路人，豁然开朗。也深刻地认识到了自己的肤浅，早起其实并不只意味着早点起来罢了。想象一下，如果明天要和女神约会？或者新工作的第一天？不用考虑肯定早早的就起来收拾了，因为你开心，快乐，幸福；甚至要迎来人生新阶段了。所以早起真谛可能不仅仅是早点起来，更重要的是进一步寻找人生的意义，创造生命的价值，为我所热爱奋斗终生！

冥想

关于冥想，老实说太高端了，高端到有点不接地气，反正 100 个人有 100 个见解。刚开始还看了各种视频、翻了有关的书、试了各种动作体验冥想、有没有效果我不清楚，不过睡得倒很快。

感受呼吸、扫描身体、提升专注力，但越努力就越凌乱……由于不能形成持续的正反馈，所以我有点消极。去你的冥想，浪费生命。后续冥想也是断断续续的持续了好久，那天想起来就尝试一下，想不起来就算了。

直到有阵子，忘记具体在做什么，总之就是在写代码。从上班来坐那，要不是同事喊我，还真没感觉一个上午都过去了……也是瞬间明白了《十分钟冥想》中：心流。

我把冥想定义为心无杂念、极致专注。但是早期的努力只是停留在表面上而没有透彻地理解。我认为冥想最重要的一点：感知力、尝试学会深入感受身体各个部位，体会情绪在大脑波动，品尝茶水在身体流淌，体会世间万物。

一个小和尚问得道的师父：“您得道之前做什么？”



老和尚说：“砍柴、挑水、做饭。”



“那得道之后呢？”小和尚继续问道。



老和尚回答：“还是砍柴、挑水、做饭。”



小和尚一脸疑惑：“师父，这不是一样吗？”



老和尚说：“当然不一样。得道前，我砍柴时惦记着挑水，挑水时惦记着做饭；得道后，砍柴即砍柴，挑水即挑水，做饭即做饭。”

阅读

生命是有限的，但书籍却是无限的，怎么用有限的生命阅读无限的书籍呢？根据不科学统计，人的一生最多只能阅读 15000 本书籍，那估计是没有一个人可以活着读完。所以我们应该要追求精读细阅和高质量的阅读。

首先要会读书，读好书。《如何阅读一本书》就非常详细的讨论了怎么样阅读一本书，尽管有关读书的方法论确实很好，但我觉得阐述得太过重复啰嗦。其实读书喜欢什么就读什么，不要拘泥于阅读世界名著，人文哲理。但我建议少读都市言情，穿越爽文，其可吸收的营养价值较少。具体想怎么读就怎么读，咬文嚼字、一目十行都无所谓，但是这一种读法仅限于是一本好书的情况下。可是究竟什么是好书呢？追随那些走的快的人，阅读其推荐的书单。

假如面临的是一本新书，那么你可以尝试：

1. 深入了解书的作者、写作的背景。


2. 详细阅读书的自序、引言、大纲、目录等重要信息。


3. 快速翻阅书中的部分章节。如果感觉这本书很有价值，那就接着继续。


4. 带着疑问追随作者的步伐，选择最适合的方式阅读。
   
   
   
   1. 这本书讲了什么？
   
   
   2. 作者细说了什么？
   
   
   3. 作者的观点是否正确？
   
   
   4. 作者讲的和我有什么关系？
   
   
   
   


5. 收获体会，记录笔记。

再分享一种进一步的阅读方法：主题阅读。在某个类目中挑选同方向的若干本书，然后确认自己研究的主题和方向。

1. 依次阅读每本书。


2. 理清问题、界定主题。


3. 与不同作者达成共识。


4. 分析讨论。

写作

我学生时期其实最厌恶写作了……为什么会是你给我段话，让我来研究一下它怎么想的，然后再为你阐述一下自己的观点。我 TM 怎么知道他想什么，爱想什么想什么。

写作实际上可以和阅读相结合，从而构成完美的闭环。

不知道是不是只有自己写作效率低，感觉自己就像间歇泉，总是时不时的迸发灵感。但有时候喷多了，我还写不下来。所以我一般阅读书籍的时候总是会主动掺杂一些技术类目书籍，这样既有助于提高专业技能，又能留足思考时间。

写作我倒没啥可分享心得的，随心所欲，不必整的很累。但必须重视以下三点：

1. 务必不要出现错字。


2. 一定要正确地运用标点符号和合理地分段。


3. 确保文章整体阅读流畅性。

运动

生命在于运动，如只老乌龟一样冲击活 100 年！

运动锻炼不局限于任何形式，爬楼梯也可以，最重要的是生活态度。千万不要眼高手低，今天运动明天就想超越博尔特，持续保持正反馈，日拱一卒，冲吧骚年！

如果不知道如何下手，可以参考我的 wiki 手册：健身手册

其实吧，哪怕你尝试了「早起」、「冥想」、「阅读」、「写作」、「运动」，也不可能立刻获得收获。过去既然无法改变，未来更不知道何去。

那么请尝试着慢一点，慢一点，再慢一点，也许当你回头那刻，轻舟已过万重山。

Hello啊老铁们，这篇文章还是阐述自定义View相关的内容，用Canvas轻轻松松搞一个数字键盘，本身没什么难度，这种效果实现的方式也是多种多样，这篇只是其中的一种，要说本篇有什么特别之处，可能就是纯绘制，没有用到其它的任何资源，一个类就搞定了，文中不足之处，各位老铁多包含，多指正。

今天的内容大概如下：

1、效果展示

2、快速使用及属性介绍

3、具体代码实现

4、源文件地址及总结

一、效果展示

很常见的数字键盘，背景，颜色，文字大小，点击的事件等等，均已配置好，大家可以看第2项中相关介绍。

静态效果展示：

动态效果展示，录了一个gif，大家可以看下具体的触摸效果。

二、快速使用及属性介绍

鉴于本身就一个类，不值当去打一个远程的Maven，大家用的话可以直接下载，把文件复制到项目里即可，复制到项目中，就可以按照下面的步骤去使用。

引用

1、xml中引用，可以根据需要，设置宽高及相关属性

<KeyboardView

  android:id="@+id/key_board_view"

  android:layout_width="match_parent"

  android:layout_height="wrap_content" />

2、代码直接创建，然后追加到相关视图里即可

val keyboardView=KeyboardView(this)

方法及属性介绍

单个点击的触发监听：

keyboardView.setOnSingleClickListener {

            //键盘点击的数字



}

获取最终的字符串点击监听，其实就是把你点击的数字拼接起来，一起输出，特别在密码使用的时候，省的你再自己拼接了，配合number_size属性和setNumberSize方法一起使用，默认是6个长度，可以根据需求，动态设置。

keyboardView.setOnNumClickListener {

        //获取最终的点击数字字符串，如：123456，通过number_size属性或setNumberSize方法，设置最长字符

    }

其它方法

属性介绍

三、具体代码实现

代码实现上其实也没有什么难的，主要就是用到了自定义View中的onDraw方法，简单的初始化，设置画笔，默认属性就不一一介绍了，直接讲述主要的绘制部分，我的实现思路如下，第一步，绘制方格，按照UI效果图，应该是12个方格，简图如下，需要注意的是，第10个是空的，也就是再绘制的时候，需要进行跳过，最后一个是一个删除的按钮，绘制的时候也需要跳过，直接绘制删除按钮即可。

1、关于方格的绘制

方格的宽度计算很简单，（手机的宽度-方格间距*4）/3即可，绘制方格，直接调用canvas的drawRoundRect方法，单纯的和数字一起绘制，直接遍历12个数即可，记住9的位置跳过，11的位置，绘制删除按钮。

mRectWidth = (width - mSpacing * 4) / 3

mPaint!!.strokeWidth = 10f

for (i in 0..11) {

            //设置方格

            val rect = RectF()

            val iTemp = i / 3

            val rectTop = mHeight * iTemp + mSpacing * (iTemp + 1f)

            rect.top = rectTop

            rect.bottom = rect.top + mHeight

            var leftSpacing = (mSpacing * (i % 3f))

            leftSpacing += mSpacing

            rect.left = mRectWidth!! * (i % 3f) + leftSpacing

            rect.right = rect.left + mRectWidth!!

            //9的位置是空的，跳过不绘制

            if (i == 9) {

                continue

            }

            //11的位置，是删除按钮，直接绘制删除按钮

            if (i == 11) {

                drawDelete(canvas, rect.right, rect.top)

                continue

            }

            mPaint!!.textSize = mTextSize

            mPaint!!.style = Paint.Style.FILL

            //按下的索引 和 方格的 索引一致,改变背景颜色

            if (mDownPosition == (i + 1)) {

                mPaint!!.color = mDownBackGroundColor

            } else {

                mPaint!!.color = mRectBackGroundColor

            }

            //绘制方格

            canvas!!.drawRoundRect(rect, 10f, 10f, mPaint!!)

}

2、关于数字的绘制

没有字母显示的情况下，数字要绘制到中间的位置，有字母的情况下，数字应该往上偏移，让整体进行居中，通过方格的宽高和自身文字内容的宽高来计算显示的位置。

//绘制数字

            mPaint!!.color = mTextColor

            var keyWord = "${i + 1}"

            //索引等于 10 从新赋值为 0

            if (i == 10) {

                keyWord = "0"

            }

            val rectWord = Rect()

            mPaint!!.getTextBounds(keyWord, 0, keyWord.length, rectWord)

            val wWord = rectWord.width()

            val htWord = rectWord.height()

            var yWord = rect.bottom - mHeight / 2 + (htWord / 2)

            //上移

            if (i != 0 && i != 10 && mIsShowLetter) {

                yWord -= htWord / 3

            }

            canvas.drawText(

                keyWord,

                rect.right - mRectWidth!! / 2 - (wWord / 2),

                yWord,

                mPaint!!

            )

3、关于字母的绘制

因为字母是和数字一起绘制的，所以需要对应的字母则向下偏移，否则不会达到整体居中的效果，具体的绘制如下，和数字的绘制类似，拿到方格的宽高，以及字母的宽高，进行计算横向和纵向位置。

    	//绘制字母

            if ((i in 1..8) && mIsShowLetter) {

                mPaint!!.textSize = mLetterTextSize

                val s = mWordArray[i - 1]

                val rectW = Rect()

                mPaint!!.getTextBounds(s, 0, s.length, rectW)

                val w = rectW.width()

                val h = rectW.height()

                canvas.drawText(

                    s,

                    rect.right - mRectWidth!! / 2 - (w / 2),

                    rect.bottom - mHeight / 2 + h * 2,

                    mPaint!!

                )

            }

4、关于删除按钮的绘制

删除按钮是纯线条的绘制，没有使用图片资源，不过大家可以使用图片资源，因为图片资源还是比较的靠谱。

 /**

     * AUTHOR:AbnerMing

     * INTRODUCE:绘制删除按键，直接canvas自绘，不使用图片

     */

    private fun drawDelete(canvas: Canvas?, right: Float, top: Float) {

        val rWidth = 15

        val lineWidth = 35

        val x = right - mRectWidth!! / 2 - (rWidth + lineWidth) / 4

        val y = top + mHeight / 2

        val path = Path()

        path.moveTo(x - rWidth, y)

        path.lineTo(x, y - rWidth)

        path.lineTo(x + lineWidth, y - rWidth)

        path.lineTo(x + lineWidth, y + rWidth)

        path.lineTo(x, y + rWidth)

        path.lineTo(x - rWidth, y)

        path.close()

        mPaint!!.strokeWidth = 2f

        mPaint!!.style = Paint.Style.STROKE

        mPaint!!.color = mTextColor

        canvas!!.drawPath(path, mPaint!!)



        //绘制小×号

        mPaint!!.style = Paint.Style.FILL

        mPaint!!.textSize = 30f

        val content = "×"

        val rectWord = Rect()

        mPaint!!.getTextBounds(content, 0, content.length, rectWord)

        val wWord = rectWord.width()

        val htWord = rectWord.height()

        canvas.drawText(

            content,

            right - mRectWidth!! / 2 - wWord / 2 + 3,

            y + htWord / 3 * 2 + 2,

            mPaint!!

        )



    }