前言

之前整理过 整理下最近做的产品里 比较典型的代码规范问题，里面有一个关于可选链运算符(?.)的规范，当时只是提了一下，今天详细说下想法，欢迎大佬参与讨论。

可选链运算符(?.)，大家都很熟悉了，直接看个例子：

const result = obj?.a?.b?.c?.d

很简单例子，上面代码?前面的属性如果是空值（null或undefined），则result值是undefined，反之如果都不是空值，则会返回最后一个d属性值。

本文不是讲解这种语法的用法，主要是想分析下日常开发中，这种语法 滥用、乱用 的问题。

滥用、乱用

最近在code review一个公司项目代码，发现代码里用到的可选链运算符，很多滥用，用的很无脑，经常遇到这种代码：

const userName = data?.items?.[0]?.user?.name

↑ 不管对象以及属性有没有可能是空值，无脑加上?.就完了。

// react class component

const name = this.state?.name



// react hooks

const [items, setItems] = useState([])

items?.map(...)

setItems?.([]) // 真有这么写的

↑ React框架下，this.state 值不可能是空值，初始化以及set的值都是数组，都无脑加上?.

const item1 = obj?.item1

console.log(item1.name)

↑ 第一行代码说明obj或item1可能是空值，但第二行也明显说明不可能是空值，否则依然会抛错，第一行的?.也就没意义了。

if (obj?.item1?.item2) {

    const item2 = obj?.item1?.item2

    const name = obj?.item1?.item2?.name

}

↑ if 里已经判断了非空了，内部就没必要判断非空了。

问题、缺点

如果不考虑 ?. 使用的必要性，无脑滥用其实也没问题，不会影响功能，优点也很多：

但是问题和缺点也很明显，而且也会很严重。分两点分析下：

1. 可读性、维护性

可读性和维护性其实是一回事，都是指不是源代码作者的开发维护人员，在捋这块代码逻辑、修改bug等情况时，处理问题的效率，代码写的好处理就快，写的烂就处理慢，很简单道理。

const onClick = () => {

    const user = props.data?.items?.[0]?.user

    if (user) {

        // use user to do something

    }

}

已这行代码为例，有个bug现象是点击按钮没反应，维护开发看到这块代码，就会想这一串链式属性里，是不是有可能有空值，所以导致了user是空值，没走进if里导致没反应。然后就继续分析上层组件props传输代码，看data值从哪儿传来的，看是不是哪块代码导致data或items空值了。。。

其实呢？从外部传过来的这一串属性里不会有空值的情况，导致bug问题根本不在这儿。

const user = props.data.items[0].user

那把?.都去掉呢？维护开发追踪问题看到这行代码，data items 这些属性肯定不能是空值，不然console就抛错了，但是bug现象里并没有抛错，所以只需要检查user能不能是空值就行了，很容易就排除了很多情况。

总结就是：给代码维护人员带来了很多分析代码的干扰，代码可读性和维护性都很差。

2. 隐式过滤了异常

api.get(...).then(result => {

    const id = result?.id

    // use id to do something

})

比如有个需求，从后台api获取数据时，需要把结果里id属性获取到，然后进行数据处理，从业务流程上看，这个api返回的result以及id必须有值，如果没值的话后续的流程就会走不通。

然后后台逻辑由于写的有问题，导致个别情况返回的 result=null，但是由于前端这里加了?.，导致页面没有任何反应，js不抛错，console也没有log，后续流程出错了，这时候如果想找原因就会很困难，对代码熟悉还行，如果不是自己写的就只能看代码捋逻辑，如果是生产环境压缩混淆了就更难排查了。

api.get(...).then(result => {

    const id = result.id

    // use id to do something

})

把?.去掉呢？如果api返回值有问题，这里会立即抛错，后面的流程也就不能进行下去了，无论开发还是生产环境都能在console里快速定位问题，即使是压缩混淆的也能从error看出一二，或者在一些前端监控程序里也能监听到。

其实这种现象跟 try catch 里不加 throw 类似，把隐式异常错误完全给过滤掉了，比如下面例子：

// 这个try本意是处理api请求异常

try {

    const data = getSaveData() // 这段js逻辑也在try里，所以如果这个方法内部抛错了，页面上就没任何反应，很难追踪问题

    const result = await api.post(url, data)

    // result 逻辑处理

} catch (e) {

    // 好点的给弹个框，打个log，甚至有的啥都不处理

}

总结就是：把异常给隐式过滤掉了，导致不能快速定位问题。

3. 编译后代码冗余

如果代码是ts，并且编译目标是ES2016，编译后代码会很长。可以看下 http://www.typescriptlang.org/play 效果。

Babel在个别stage下，编译效果一样。

但并不是说一点都不用，意思是尽量减少滥用，这样使用的频率会少很多，这种编译代码沉余也会少不少。

应该怎么用？

说了这么多，.? 应该怎么用呢？意思是不用吗？当然不是不能用，这个特性对于开发肯定好处很多的，但是得合理用，不能滥用。

其实说白了就是：什么时候需要判断一个变量或属性非空，什么时候不需要。首先在使用的时候得想下，问号前面的变量或属性值，有没有可能是空值：

const userName = data?.items?.[0]?.user?.name // 不要滥用，如果某个属性有可能是空值，则需要?.

const userName = data.items[0].user?.name // 比如data.items数组肯定不是空数组

const items2 = items1.filter(item => item.checked)

if (items2?.length) { } // 不需要?.

// react class component

const name = this.state?.name // 不需要?.



// react hooks

const [items, setItems] = useState([])

items?.map(...) // 如果setItems没有赋值空值情况，则不需要?.

setItems?.([]) // 不需要?.

const item1 = obj?.item1 // 不需要?.

console.log(item1.name)

const id = obj?.id // 下面代码已经说明不能是空值了，不需要?.

const name = obj.name

if (obj?.item1?.item2) {

    const item2 = obj?.item1?.item2 // 不需要?.

    const name = obj?.item1?.item2?.name // 不需要?.

}

const id = obj?.item?.id // 不需要?.

api.get(id).then(...) // 这个api如果id是空值，则api会抛错

当然，写代码时还得多想一下属性是否可能是空值，会一定程度的影响开发效率，也一定有开发会觉得很烦，不理解，无脑写?.多容易啊，但是我从另外两个角度分析下：

总结

本文以一个 code reviewer 角度，分析了 可选链运算符(?.) 特性的滥用情况，以及“正确使用方式”，只是代表我本人的看法，欢迎大佬参与讨论，无条件接受任何反驳。

滥用的缺点：

“正确用法”：

后记（09月25日更新）

从评论上看，对于可选链的看法，大多声音是能加就加，多加总比少加好，原因就是不想背锅，不想上线后JS动不动就崩了，无论根本原因是不是前端开发没加判断导致的，第一责任人就会找到你，有的甚至会被上级追责，问题就更严重了，而且很难解释清楚；另一方面就是为了赶工期，可选链的其中一个优点就是简单，提高开发效率。

我再从几个方面浅浅的扩展下我的看法，欢迎参与讨论

总之。。。对对对，你们说的都对！

Jetpack Compose 是个啥？为啥要学它？

谷歌对 Jetpack Compose 的定义：

Jetpack Compose 是推荐用于构建原生 Android 界面的新工具包。它可简化并加快 Android 上的界面开发，使用更少的代码、强大的工具和直观的 Kotlin API，快速打造生动而精彩的应用。

提取关键词：界面开发新工具包、简化并加快界面开发、Kotlin API。

对于大部分Android项目来说，如果基础库(如网络库、hybird、图片加载、热修复库等)已经搭好，那么平时大部分时间就是跟 UI界面、需求逻辑 打交道了，而谷歌提供的 Jetpack Compose 正好是加快界面开发的工具包。

就跟魂斗罗里的子弹类型似的，使用普通子弹(XML方式)也可以通关，但是相比之下耗时更长；而换成超级子弹(Jetpack Compose)体验就不一样了，耗时更少，而且游戏体验更爽！

命令式UI vs 声明式UI

长期以来，Android 视图层次结构一直可以表示为界面 widget 树。最常见的界面更新方式是使用 findViewById() 等函数遍历树，并通过调用 button.setText(String)、container.addChild(View) 或 img.setImageBitmap(Bitmap) 等方法更改节点。这些方法会改变 widget 的内部状态，这种手动更新UI的方式即是命令式UI。

在过去的几年中，整个行业已开始转向声明性界面模型，该模型大大简化了与构建和更新界面关联的工程任务。该技术的工作原理是在概念上从头开始重新生成整个屏幕，然后仅执行必要的更改。此方法可避免手动更新有状态视图层次结构的复杂性。Compose 即是一个声明式UI框架。

Jetpack Compose要学起来了？

很遗憾，Jetpack Compose 确实要学起来了（快起来，你还能学！哈哈...），随着Jetpack Compose 版本的不断迭代，API 逐渐稳定了，性能也越来越好了。

• 更少的代码：编写代码只需要采用Kotlin，而不用拆分成 Kotlin + XML方式了。


• 直观：只需描述界面，Compose会负责处理剩余工作。应用状态变化时，界面自动更新。


• 加速开发：View 与 Compose 之间可以相互调用，兼容现有的所有代码。借助AS可以实时预览界面，轻松执行界面检查。


• 功能强大：直接访问Android API，内置对Material Design、主题、动画等的支持。

Jetpack Compose vs Flutter

• Jetpack Compose的目的是为了提高 Android 原生的 UI 开发效率！声明式UI已经成为主流的开发方式了，就像当初谷歌将Kotlin定为Android主流语言时我们学习Kotlin一样，未来Jetpack Compose 一定会是Android UI开发的主流方式。


• Flutter 的定位是多平台 UI 框架，优势在于跨平台。

大家很喜欢把Jetpack Compose 和 Flutter作对比，不知道该学哪一个？的确，某些场景下它们确实挺像的，而且还都是谷歌在推的。

个人理解是：如果你未来的主攻方向还是Android，那么无脑选择Jetpack Compose，虽然Compose目前也能实现跨端，但跨端目前看并不是它的主要工作；而如果你的方向是多平台开发，那么学习Flutter是首选吧。

另外，与其一直纠结学哪一个，不如直接上手亲身感受下它们的不同，正所谓 “纸上得来终觉浅，绝知此事要躬行”。

Jetpack Compose入门

class MainActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContent {

            Text("Hello World!")

        }

    }

}

其中，setContent()传入一个@Composable作用域，其作用跟之前的setContentView()一样用来设置界面。Text()用来描述一个UI元素，里面有各种参数，这里我们只把文案填上去，执行结果：

一个最简单的功能就完成了。

1、@Composable 可组合函数

还是上述展示一个文本的功能，我们换一种写法：

class MainActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContent {

            MessageCard("Android")

        }

    }

}



@Composable

fun MessageCard(name: String) {

    Text(text = "Hello $name!")

}

执行效果跟上面一样。唯一的区别就是把文本展示单独抽离到一个方法中了，并且该方法上面加了@Composable 注解：

@Composable注解用于标记一个函数为可组合函数。可组合函数是一种特殊的函数，不需要返回任何UI元素，因为可组合函数描述的是所需的屏幕状态，而不是构造界面widget；而如果按我们以前的XML编程方式，必须在方法中返回UI元素才能使用它（如返回View类型）。

@Composable注解的函数之间可以相互调用，因为这样Compose框架才能正确处理依赖关系。另外，@Composable函数中也可以调用普通函数，而普通函数中却不能直接调用@Composable函数。 这里可以类比下kotlin中suspend挂起函数的用法，其用法是相似的。

几个定义：

• 组合：对 Jetpack Compose 在执行可组合项时所构建界面的描述。


• 初始组合：通过首次运行可组合项创建组合。


• 重组：在数据发生变化时重新运行可组合项以更新组合。

可组合函数的特点：

• 使用同一参数多次调用此函数时，它的行为方式相同，并且它不使用其他值，如全局变量或对 random() 的调用。


• 此函数描述界面而没有任何副作用，如修改属性或全局变量、点击事件的处理等。当需要执行附带效应时，应通过回调触发。如：

@Composable

private fun NamePickerItem(name: String, onClicked: (String) -> Unit) {

    Text(name, Modifier.clickable(onClick = { onClicked(name) }))

}

可见通过回调，点击事件这个附带效应是在调用方触发的。

在编译时，Jetpack Compose会将标记为@Composable的函数编译成字节码，并生成一个专门的ComposeNode类来管理其状态和属性。这个类会自动处理依赖关系，并在需要时计算UI元素。这样，开发者就可以专注于编写UI逻辑，而不用担心状态管理和UI更新的细节。

这里引出一个问题，Compose 是如何做 UI 更新的呢？总不能每次有一小部分数据的变化，整个UI都要跟着刷新一次吧，那性能肯定差的要死。其实，当有数据变化时，Compose实现的是增量更新，只会重新绘制数据有改动的UI（该过程称为重组），数据没有改动的则不会重新绘制了。

2、布局基础知识

Compose 通过元素组合、布局、绘制之后可以将状态转换为UI元素。

组合

在 Compose 中，可以通过从可组合函数中调用其他可组合函数来构建界面层次结构。

如图所示：

• Column ：可以将多个项垂直地放置在屏幕上；


• Row ：可以将多个项水平地放置在屏幕上；


• Box ：可将元素放在其他元素上，还支持为其包含的元素配置特定的对齐方式。

排列及对齐方式：

/**

 * @param verticalArrangement 竖直排列方式

 * @param horizontalAlignment 水平对齐方式

 */

inline fun Column(

    modifier: Modifier = Modifier,

    verticalArrangement: Arrangement.Vertical = Arrangement.Top,

    horizontalAlignment: Alignment.Horizontal = Alignment.Start,

    content: @Composable ColumnScope.() -> Unit

) {...}



/**

 * @param horizontalArrangement 水平排列方式

 * @param verticalAlignment 竖直对齐方式

 */

@Composable

inline fun Row(

    modifier: Modifier = Modifier,

    horizontalArrangement: Arrangement.Horizontal = Arrangement.Start,

    verticalAlignment: Alignment.Vertical = Alignment.Top,

    content: @Composable RowScope.() -> Unit

) {...}



/**

 * @param contentAlignment 内容对齐方式

 */

@Composable

inline fun Box(

    modifier: Modifier = Modifier,

    contentAlignment: Alignment = Alignment.TopStart,

    propagateMinConstraints: Boolean = false,

    content: @Composable BoxScope.() -> Unit

) {...}

verticalArrangement、horizontalArrangement 排列方式及效果：

布局

界面树布局通过单次传递即可完成。父节点会在其子节点之前进行测量，但会在其子节点的尺寸和放置位置确定之后再对自身进行调整。

当界面树较深时，Compose 可以通过只测量一次子项来实现高性能。

3、Modifier修饰符

可以通过Modifier修饰符更改可组合项的大小、布局、外观，还可以添加高级互动，例如使元素可点击等。如：

  Image(

    painter = painterResource(id = R.mipmap.icon_water_melon),

    contentDescription = "",

    modifier = Modifier

         .size(50.dp)

         .clip(CircleShape)

         .border(width = 2.dp, Color.Red, CircleShape)

   )

执行结果：，原图本身是长方形的，通过Modifier修饰符修饰后，很容易变成圆角图片。想一下如果用XML方式来写，是不是要写好多代码呢。

4、存储状态

可组合函数中可以使用 remember 将本地状态存储在内存中，并跟踪传递给 mutableStateOf 的值的变化。该值更新时，系统会自动重新绘制使用此状态的可组合项（及其子项），这也是上面所说的重组。如：

@Composable

fun MessageCard(msg: Message) {

  // We keep track if the message is expanded or not in this variable

  var isExpanded by remember { mutableStateOf(false) }

  // We toggle the isExpanded variable when we click on this Column

  Column(modifier = Modifier.clickable { isExpanded = !isExpanded }) {...}

}

当点击Column 元素时，每次都会重新执行MessageCard()可组合函数进行刷新，而通过remember和mutableStateOf可以保存了上次的isExpanded状态；如果不使用它们，重新执行 MessageCard() 时 isExpanded 也会重新初始化。

除了remember之外，还有rememberSaveable、savedStateHandle.saveable等。。。

总结

这篇文章主要讲了Compose是什么以及我们要开始学习它的必要性。作为Compose 第一篇介绍文章，本文旨在初步感受一下 Compose的能力，后续再详细研究 Compose 的精彩用法！

资料

【1】谷歌Jetpack Compose 教程：
https://developer.android.com/jetpack/compose/tutorial?hl=zh-cn

扯皮

这段时间闲着没事就去翻翻红宝书，已经看到 Promise 篇了，今天又让我翻到两个陌生的知识点。

因为 Promise 业务场景太多了自我感觉掌握的也比较透彻，之前也跟着 Promise A+ 的规范手写过完整的 Promise，所以这部分内容基本上就大致过一遍，直到看见关于 Promise 的取消以及监听进度...🤔

只能说以后要是我当上面试官一定让候选人来谈谈这两个点，然后顺势安利我这篇文章🤣

不过好像目前为止也没见哪个面试官出过...

正文

取消功能

我们都知道 Promise 的状态是不可逆的，也就是说只能从 pending -> fulfilled 或 pending -> rejected，这一点是毋庸置疑的。

但现在可能会有这样的需求，在状态转换过程当中我们可能不再想让它进行下去了，也就是说让它永远停留至 pending 状态。

奇怪了，想要一直停留在 pending，那我不调用 resolve 和 reject 不就行了🤔

 const p = new Promise((resolve, reject) => {

    setTimeout(() => {

      // handler data, no resolve and reject

    }, 1000);

 });

 console.log(p); // Promise {<pending>} 💡

但注意我们的需求条件，是在状态转换过程中，也就是说必须有调用 resolve 和 reject，只不过中间可能由于某种条件，阻止了这两个调用。

其实这个场景和超时中断有点类似但还是不太一样，我们先利用 Promise.race 来看看：模拟一个发送请求，如果超时则提示超时错误：

const getData = () =>

  new Promise((resolve) => {

    setTimeout(() => {

      console.log("发送网络请求获取数据"); // ❗

      resolve("success get Data");

    }, 2500);

  });



const timer = () =>

  new Promise((_, reject) => {

    setTimeout(() => {

      reject("timeout");

    }, 2000);

  });



const p = Promise.race([getData(), timer()])

  .then((res) => {

    console.log("获取数据:", res);

  })

  .catch((err) => {

    console.log("超时: ", err);

  });

问题是现在确实能够确认超时了，但 race 的本质是内部会遍历传入的 promise 数组对它们的结果进行判断，那好像并没有实现网络请求的中断哎🤔，即使超时网络请求还会发出：

而我们想要实现的取消功能是希望不借助 race 等其他方法并且不发送请求。

比如让用户进行控制，一个按钮用来表示发送请求，一个按钮表示取消，来中断 promise 的流程：

当然这里我们不讨论关于请求的取消操作，重点在 Promise 上

其实按照我们的理解只用 Promise 是不可能实现这样的效果的，因为从一开始接触 Promise 就知道一旦调用了 resolve/reject 就代表着要进行状态转换。不过 取消 这两个字相信一定不会陌生，clearTimeout、clearInterval 嘛。

OK，如果你想到了这一点这个功能就出来了，我们直接先来看红宝书上给出的答案：

<!DOCTYPE html>

<html lang="en">

  <head>

    <meta charset="UTF-8" />

    <meta name="viewport" content="width=device-width, initial-scale=1.0" />

    <title>Document</title>

  </head>

  <body>

    <button id="send">Send</button>

    <button id="cancel">Cancel</button>

    

    <script>

      class CancelToken {

        constructor(cancelFn) {

          this.promise = new Promise((resolve, reject) => {

            cancelFn(() => {

              console.log("delay cancelled");

              resolve();

            });

          });

        }

      }

      const sendButton = document.querySelector("#send");

      const cancelButton = document.querySelector("#cancel");



      function cancellableDelayedResolve(delay) {

        console.log("prepare send request");

        return new Promise((resolve, reject) => {

          const id = setTimeout(() => {

            console.log("ajax get data");

            resolve();

          }, delay);



          const cancelToken = new CancelToken((cancelCallback) =>

            cancelButton.addEventListener("click", cancelCallback)

          );

          cancelToken.promise.then(() => clearTimeout(id));

        });

      }

      sendButton.addEventListener("click", () => cancellableDelayedResolve(1000));

    </script>

  </body>

</html>

这段代码说实话是有一点绕的，而且个人觉得是有多余的地方，我们一点一点来看：

首先针对于 sendButton 的事件处理函数，这里传入了一个 delay，可以把它理解为取消功能期限，超过期限就要真的发送请求了。我们看该处理函数内部返回了一个 Promise，而 Promise 的 executor 中首先开启了定时器，并且实例化了一个 CancelToken，而在 CancelToken 中才给 cancelButton 添加点击事件。

这里的 CancelToken 就是我觉得最奇怪的地方，可能没有体会到这个封装的技巧，路过的大佬如果有理解的希望能帮忙解释一下。它的内部创建了一个 Promise，绕了一圈后相当于 cancelButton 的点击处理函数是调用这个 Promise 的 resolve，最终是在其 pending -> fuilfilled，即 then 方法里才去取消定时器，那为什么不直接在事件处理函数中取消呢？难道是为了不影响主执行栈的执行所以才将其推到微任务处理🤔？

介于自己没理解，我就按照自己的思路封装个不一样的🤣：

const sendButton = document.querySelector("#send");

const cancelButton = document.querySelector("#cancel");



class CancelPromise {



 // delay: 取消功能期限  request：获取数据请求(必须返回 promise)

  constructor(delay, request) {

    this.req = request;

    this.delay = delay;

    this.timer = null;

  }



  delayResolve() {

    return new Promise((resolve, reject) => {

      console.log("prepare request");

      this.timer = setTimeout(() => {

        console.log("send request");

        this.timer = null;

        this.req().then(

          (res) => resolve(res),

          (err) => reject(err)

        );

      }, this.delay);

    });

  }



  cancelResolve() {

    console.log("cancel promise");

    this.timer && clearTimeout(this.timer);

  }

}



// 模拟网络请求

function getData() {

  return new Promise((resolve) => {

    setTimeout(() => {

      resolve("this is data");

    }, 2000);

  });

}



const cp = new CancelPromise(1000, getData);



sendButton.addEventListener("click", () =>

  cp.delayResolve().then((res) => {

    console.log("拿到数据：", res);

  })

);

cancelButton.addEventListener("click", () => cp.cancelResolve());

正常发送请求获取数据：

中断 promise：

没啥大毛病捏~

进度通知功能

进度通知？那不就是类似发布订阅嘛？还真是，我们来看红宝书针对这块的描述：

执行中的 Promise 可能会有不少离散的“阶段”，在最终解决之前必须依次经过。某些情况下，监控 Promise 的执行进度会很有用

这个需求就比较明确了，我们直接来看红宝书的实现吧，核心思想就是扩展之前的 Promise，为其添加 notify 方法作为监听，并且在 executor 中增加额外的参数来让用户进行通知操作：

class TrackablePromise extends Promise {

  constructor(executor) {

    const notifyHandlers = [];

    super((resolve, reject) => {

      return executor(resolve, reject, (status) => {

        notifyHandlers.map((handler) => handler(status));

      });

    });

    this.notifyHandlers = notifyHandlers;

  }

  notify(notifyHandler) {

    this.notifyHandlers.push(notifyHandler);

    return this;

  }

}

let p = new TrackablePromise((resolve, reject, notify) => {

  function countdown(x) {

    if (x > 0) {

      notify(`${20 * x}% remaining`);

      setTimeout(() => countdown(x - 1), 1000);

    } else {

      resolve();

    }

  }

  countdown(5);

});



p.notify((x) => setTimeout(console.log, 0, "progress:", x));

p.then(() => setTimeout(console.log, 0, "completed"));

emm 就是这个例子总感觉不太好，为了演示这种效果还用了递归，大伙们觉得呢？

不好就自己再写一个🤣！不过这次的实现就没有多大问题了，基本功能都具备也没有什么阅读障碍，我们再添加一个稍微带点实际场景的例子吧：

// 模拟数据请求

function getData(timer, value) {

    return new Promise((resolve) => {

      setTimeout(() => {

        resolve(value);

      }, timer);

    });

}



let p = new TrackablePromise(async (resolve, reject, notify) => {

  try {

    const res1 = await getData1();

    notify("已获取到一阶段数据");

    const res2 = await getData2();

    notify("已获取到二阶段数据");

    const res3 = await getData3();

    notify("已获取到三阶段数据");

    resolve([res1, res2, res3]);

  } catch (error) {

    notify("出错！");

    reject(error);

  }

});



p.notify((x) => console.log(x));

p.then((res) => console.log("Get All Data:", res));

对味儿了~😀

End

关于取消功能在红宝书上 TC39 委员会也曾准备增加这个特性，但相关提案最终被撤回了。结果 ES6 Promise 被认为是“激进的”：只要 Promise 的逻辑开始执行，就没有办法阻止它执行到完成。

实际上我们学了这么久的 Promise 也默认了这一点，因此这个取消功能反而就不太符合常理，而且十分鸡肋。比如说我们有使用 then 回调接收数据，但因为你点击了取消按钮造成 then 回调不执行，我们知道 Promise 支持链式调用，那如果还有后续操作都将会被中断，这种中断行为 debug 时也十分痛苦，更何况最麻烦的一点是你还需要传入一个 delay 来表示取消的期限，而这个期限到底要设置多少才合适呢...

至于说进度通知功能，仁者见仁智者见智吧...

但不管怎么样两个功能实现的思路都是比较有趣的，而且不太常见，不考虑实用性确实能够成为一道考题，只能说很符合面试官的口味😏

前言

在业务开发中，弹窗是我们常常能够遇到的开发需求，通常我们使用组件都是通过show变量来控制弹窗的开启或者隐藏。这样面对简单的业务需求的确可以满足了，但是面对深层嵌套，不同地方打开同一个弹窗便会让我们头疼。于是我想通过函数的方式来打开弹窗，通过函数参数的方式来向弹窗内更新props和处理弹窗的emit事件。

<template>

  <n-button @click="open">open</n-button>

</template>



<script setup lang="ts">

import { injectTestModal } from "./test-modal/use-test-modal"

const model = injectTestModal()

function open() {

  model?.open({

    testValue: "传给弹窗组件的值",

    onConfirm({ formData }, close, endLoading) {

      console.log({ ...formData })

      endLoading()

      close()

    },

  })

}

</script>

传统vue编写弹窗

通过变量来直接控制弹窗的开启和关闭。

<template>

  <n-button @click="showModal = true">

    来吧

  </n-button>

  <n-modal v-model:show="showModal" preset="dialog" title="Dialog">

    <template #header>

      <div>标题</div>

    </template>

    <div>内容</div>

    <template #action>

      <div>操作</div>

    </template>

  </n-modal>

</template>



<script lang="ts">

import { defineComponent, ref } from 'vue'



export default defineComponent({

  setup () {

    return {

      showModal: ref(false)

    }

  }

})

</script>

痛点

• 深层次的传props让人有很大的心理负担，污染组件props


• 要关注弹窗show变量的true，false

函数式弹窗

在主页面用Provider包裹一下

// RootPage.vue

<ModalProvider>

  <ChildPage></ChildPage>

</ModalProvider>



<script setup lang="ts">

import ModalProvider from "./ModalProvider.vue"

import ChildPage from "./ChildPage.vue"

</script>

在页面内的某个子组件中，直接通过oepn方法打开弹窗

// ChidPage.vue

<template>

	<n-button @click="open">open</n-button>

</template>



<script setup lang="ts">

import { injectTestModal } from "./test-modal/use-test-modal"

const model = injectTestModal()

function open() {

	model?.open({

		testValue: "传给弹窗组件的值",

		onConfirm({ formData }, close, endLoading) {

			console.log({ ...formData })

			endLoading()

			close()

		},

	})

}

</script>

优势

• 对于使用者来说简单，没有控制show的心理负担


• 弹窗内容和其他业务代码分离，不会污染其他组件props和结构


• 能够充分复用同一个弹窗，通过函数参数的方式来更新弹窗内容，在不同地方打开同一个弹窗

劣势

• 对于一些简单需求的弹窗，用这种函数式的弹窗会有些臃肿


• 在使用函数式弹窗前需要做一些操作（Provider和Inject），会在后面提到以及解决方案。

如何使用这种函数式的弹窗

原理

通过在根页面将我们的Modal组件挂载上去，然后通过使用hook去管理这个modal组件的状态值（props,ref）,然后通过provide将props和event和我们的modal组件联系起来，再在我们需要使用弹窗的地方使用inject更新props来启动弹窗。

步骤1(❌):编写Modal

这里我使用的是Naive Ui的Modal组件，按喜好选择就行。按照你的需求编写弹窗的内容。定义好props和emits，写好他们的类型申明。

// TestModal.vue

<template>

  <n-modal

    v-model:show="isShowModal"

    preset="dialog"

    @after-leave="handleClose"

  >

    ...你的弹窗内容

  </n-modal>

</template>



<script setup lang="ts">

import { ref, reactive, computed, watch } from "vue"

import { useVModel } from "@vueuse/core"

import { FormRules } from "naive-ui"

interface ModalProps {

  show: boolean

  testValue: string

}



// 中间区域不要修改

const props = defineProps<ModalProps>()

const formRef = ref()

const loading = ref(false)

const isShowModal = useVModel(props, "show")

// 中间区域不要修改



const rules: FormRules = []



const formData = reactive({

  testValue: props.testValue,

})



const callBackData = computed(() => {

  return {

    formData,

  }

})



watch(

  () => props.show,

  () => {

    if (props.show) {

      formData.testValue = props.testValue

    } else {

      formData.testValue = ""

    }

  }

)



const emits = defineEmits<{

  (e: "update:show", value: boolean): void

  (e: "close", param: typeof callBackData.value): void

  (

    e: "confirm",

    param: typeof callBackData.value,

    close: () => void,

    endLoading: () => void

  ): void

  (e: "cancel", param: typeof callBackData.value): void

}>()

function handleCancel() {

  // 中间区域不要修改

  emits("cancel", callBackData.value)

  isShowModal.value = false

  // 中间区域不要修改

}



function handleClose() {

  // 中间区域不要修改

  emits("close", callBackData.value)

  isShowModal.value = false

  // 中间区域不要修改

}



function handleConfirm() {

  // 中间区域不要修改

  loading.value = true

  emits(

    "confirm",

    callBackData.value,

    () => {

      loading.value = false

      isShowModal.value = false

    },

    () => {

      loading.value = false

    }

  )

  // 中间区域不要修改

}

</script>

步骤2(❌):编写hook来管理弹窗的状态

在这个文件里面，使用hook管理 TestModal 弹窗需要的props和event事件，然后我们通过ts类型体操来获取TestModal的props类型和event类型，我们向外inject一个 open 函数，这个函数可以更新 TestModal 的props和event，同时打开弹窗，他的参数有完整的类型提示，可以让使用者更加明确的使用我们的弹窗。

// use-test-modal.ts

import {

  ref,

  provide,

  InjectionKey,

  inject,

  VNodeProps,

  AllowedComponentProps,

  reactive,

} from "vue";

import Modal from "./TestModal.vue";



/**

 * 通过引入弹窗组件来获取组件的除show，update：show以外的props和emits来作为open函数的

 */

type ModalInstance = InstanceType<

  typeof Modal extends abstract new (...args: any) => any ? typeof Modal : any

>["$props"];

type OpenParam = Omit<

  {

    readonly [K in keyof Omit<

      ModalInstance,

      keyof VNodeProps | keyof AllowedComponentProps

    >]: ModalInstance[K];

  },

  "show" | "onUpdate:show"

>;



interface AnyFileChangeModal {

  open: (param?: OpenParam) => Promise<void>;

}



/**

 * 通过弹窗实例来获取弹窗组件内需要哪些props

 */

type AllProps = Omit<

  OpenParam,

  "onClose" | "onCancel" | "onConfirm" | "onUpdate:show"

> & { show: boolean };

const anyModalKey: InjectionKey<AnyFileChangeModal> = Symbol("ModalKey");

export function provideTestModal() {

  const allProps: AllProps = reactive({

    show: false,

  } as AllProps);

  const closeCallback = ref();

  const cancelCallback = ref();

  const confirmCallback = ref();

  const handleUpdateShow = (value: boolean) => {

    allProps.show = value;

  };



  /**

   * @param param 通过函数来更新props

   */

  function updateAllProps(param: OpenParam) {

    const excludeKey = ["show", "onClose", "onConfirm", "onCancel"];

    for (const [key, value] of Object.entries(param)) {

      if (!excludeKey.includes(key)) {

        allProps[key] = value;

      }

    }

  }

  function clearAllProps() {

    for (const [key] of Object.entries(allProps)) {

      allProps[key] = undefined;

    }

  }



  async function open(param: OpenParam) {

    clearAllProps();

    updateAllProps(param);

    allProps.show = true;

    param.onClose && (closeCallback.value = param.onClose);

    param.onConfirm && (confirmCallback.value = param.onConfirm);

    param.onCancel && (cancelCallback.value = param.onCancel);

  }

  provide(anyModalKey, { open });

  return {

    allProps,

    closeCallback,

    confirmCallback,

    cancelCallback,

    handleUpdateShow,

  };

}



export function injectTestModal() {

  return inject(anyModalKey)

}

Ï

步骤3(❌):提供Provider

在这个文件里，我将TestModal放在了根页面，然后将hook返回的props和event绑定给TestModal

// ModalProvider.vue

<template>

  <slot />



  <TestModal

    v-bind="allTestModalProps"

    @update:show="handleTestModalUpdateShow"

    @close="closeTestModalCallback"

    @confirm="confirmTestModalCallback"

    @cancel="cancelTestModalCallback"

  />

  <!-- 新增Modal -->

</template>



<script setup lang="ts">

import TestModal from "./test-modal/TestModal.vue";

import { provideTestModal } from "./test-modal/use-test-modal";

/** 新增import */



const {

  allProps: allTestModalProps,

  handleUpdateShow: handleTestModalUpdateShow,

  closeCallback: closeTestModalCallback,

  confirmCallback: confirmTestModalCallback,

  cancelCallback: cancelTestModalCallback,

} = provideTestModal();

/** 新增provide */

</script>

步骤4(❌):通过函数打开弹窗

<template>

  <n-button @click="open">open</n-button>

</template>



<script setup lang="ts">

import { injectTestModal } from "./test-modal/use-test-modal"

const model = injectTestModal()

function open() {

  model?.open({

    testValue: "传给弹窗组件的值",

    onConfirm({ formData }, close, endLoading) {

      console.log({ ...formData })

      endLoading()

      close()

    },

  })

}

</script>

到这里也就结束了。如果这样写一个弹窗，确实可以达到函数式的打开弹窗，但是他实在是太繁琐了，要写这么一堆东西，不如直接修改弹窗的show来的快。如果看过上面的use-test-modal.ts的话，会发现里面有AllProps，这是为了减少方便使用脚本工具来写通用化的代码，可以大大减少人工的重复代码编写，接下来我们使用一个工具来减少这些繁琐的操作。

步骤1(✅):初始化Provider

通过使用工具生成根页面ModalProvder组件。
具体步骤：在你想放置当前业务版本的弹窗文件夹路径下使用终端执行脚本，选择initProvider

步骤2(✅):生成弹窗模板

通过继续使用脚本工具，生成弹窗组件以及hook文件。
具体步骤：在你想放该弹窗的文件夹路径下使用终端，使用脚本工具，选择genModal,然后跟着指令操作就行。比如例子中，我们生产名为test的弹窗，然后告诉脚本我们的ModalProvider组件的绝对路径，脚本帮我生产test-modal的文件夹，里面放着testModal.vue和use-test-modal.ts，这里的use-test-modal.ts文件已经是成品了，不需要你去修改，ModalProvider.vue也不需要你去修改，里面的路径关系也帮你处理好了。

步骤3(✅):修改弹窗内容

上一步操作中，脚本帮我写好了TestModal.vue组件，我们可以在他的基础上完善我们的业务需求。

步骤4(✅):调用弹窗

我们找到生成的use-test-modal.ts，里面有一个injectXXXModal的方法，我们在哪个地方用到弹窗就引用执行他，返回的对象中有open方法，通过open方法去开启弹窗并且更新弹窗props。

Demo

预览
Demo地址
里面有完整的demo代码

脚本工具

仓库地址
这个是我写的脚本工具，用来减少一些重复代码的工作。用法可看readme

总结

本文先通过比较函数式的弹窗和直接传统编写弹窗的优劣，然后引出本文的主旨（如何编写函数式弹窗），再考虑我这一版函数式弹窗的问题，最后通过脚本工具来解决这一版函数式弹窗的劣势，完整的配合脚本工具，可以极大的加快我们的工作效率。
大家不要看这么写要好几个文件夹，实际使用的时候其实就是脚本生成代码后，我们只需要去修改弹窗主题的内容。有什么疑惑或者建议评论区聊。

前言

最近对一个Java写的老项目进行了部分重构，测试过程中波澜不惊，顺利上线后几天通过APM平台查看发现Crash率上升了，查看堆栈定位到NPE类型的Crash，大部分发生在Java调用Kotlin的函数里，本篇将会分析具体的场景以及规避方式。

通过本篇文章，你将了解到：

1. NPE(空指针 NullPointerException)的本质


2. Java 如何预防NPE？


3. Kotlin NPE检测


4. Java/Kotlin 混合调用


5. 常见的Java/Kotlin互调场景

1. NPE(空指针 NullPointerException)的本质

变量的本质

    val name: String = "fish"

name是什么？

对此问题你可能嗤之以鼻：

不就是变量吗？更进一步说如果是在对象里声明，那就是成员变量(属性)，如果在方法(函数)里声明，那就是局部变量，如果是静态声明的，那就是全局变量。

回答没问题很稳当。

那再问为什么通过变量就能找到对应的值呢？

答案：变量就是地址，通过该地址即可寻址到内存里真正的值

无法访问的地址

如上图，若是name="fish"，表示的是name所指向的内存地址里存放着"fish"的字符串。

若是name=null，则说明name没有指向任何地址，当然无法通过它访问任何有用的信息了。

无论C/C++亦或是Java/Kotlin，如果一个引用=null，那么这个引用将毫无意义，无法通过它访问任何内存信息，因此这些语言在设计的过程中会将通过null访问变量/方法的行为都会显式(抛出异常)提醒开发者。

2. Java 如何预防NPE？

运行时规避

先看Demo：

public class TestJava {

   public static void main(String args[]) {

      (new TestJava()).test();

   }



   void test() {

      String str = getString();

      System.out.println(str.length());

   }



   String getString() {

      return null;

   }

}

执行上述代码将会抛出异常，导致程序Crash：

1. try...catch


2. 对象判空

try...catch 方式

public class TestJava {

    public static void main(String args[]) {

        (new TestJava()).testTryCatch();

    }



    void testTryCatch() {

        try {

            String str = getString();

            System.out.println(str.length());

        } catch (Exception e) {

        }

    }



    String getString() {

        return null;

    }

}

NPE被捕获，程序没有Crash。

对象判空

public class TestJava {

    public static void main(String args[]) {

        (new TestJava()).testJudgeNull();

    }



    void testJudgeNull() {

        String str = getString();

        if (str != null) {

            System.out.println(str.length());

        }

    }



    String getString() {

        return null;

    }

}

因为提前判空，所以程序没有Crash。

编译时检测

在运行时再去做判断的缺点：

无法提前发现NPE问题，想要覆盖大部分的场景需要随时try...catch或是判空
总有忘记遗漏的时候，发布到线上就是个生产事故

那能否在编译时进行检测呢？

答案是使用注解。

public class TestJava {

    public static void main(String args[]) {

        (new TestJava()).test();

    }



    void test() {

        String str = getString();

        System.out.println(str.length());

    }



    @Nullable String getString() {

        return null;

    }

}

在编写getString()方法时发现其可能为空，于是给方法加上一个"可能为空"的注解：@Nullable

当调用getString()方法时，编译器给出如下提示：

意思是访问的getString()可能为空，最后访问String.length()时可能会抛出NPE。

看到编译器的提示我们就知道此处有NPE的隐患，因此可以针对性的进行处理(try...catch或是判空)。

当然此处的注解仅仅只是个"弱提示"，你即使没有进行针对性的处理也能编译通过，只是问题最后都流转到运行时更难挽回了。

有"可空"的注解，当然也有"非空"的注解：

@Nonnull 注解修饰了方法后，若是检测到方法返回null，则会提示修改，当然也是"弱提示"。

3. Kotlin NPE检测

编译时检测

Kotlin 核心优势之一：

空安全检测，变量分为可空型/非空型，能够在编译期检测潜在的NPE，并强制开发者确保类型一致，将问题在编译期暴露并解决

先看非空类型的变量声明：

class TestKotlin {



    fun test() {

        val str = getString()

        println("${str.length}")

    }



    private fun getString():String {

        return "fish"

    }

}



fun main() {

    TestKotlin().test()

}

此种场景下，我们能确保getString()函数的返回一定非空，因此在调用该函数时无需进行判空也无需try...catch。

你可能会说，你这里写死了"fish"，那我写成null如何？

编译期直接提示不能这么写，因为我们声明getString()的返回值为String，是非空的String类型，既然声明了非空，那么就需要言行一致，返回的也是非空的。

有非空场景，那也得有空的场景啊：

class TestKotlin {



    fun test() {

        val str = getString()

        println("${str.length}")

    }



    private fun getString():String? {

        return null

    }

}



fun main() {

    TestKotlin().test()

}

此时将getString()声明为非空，因此可以在函数里返回null。

然而调用之处就无法编译通过了：

意思是既然getString()可能返回null，那么就不能直接通过String.length访问，需要改为可空方式的访问：

class TestKotlin {



    fun test() {

        val str = getString()

        println("${str?.length}")

    }



    private fun getString():String? {

        return null

    }

}

str?.length 意思是：如果str==null，就不去访问其成员变量/函数，若不为空则可以访问，于是就避免了NPE问题。

由此可以看出：

Kotlin 通过检测声明与实现，确保了函数一定要言行一致（声明与实现），也确保了调用者与被调用者的言行一致

因此，若是用Kotlin编写代码，我们无需花太多时间去预防和排查NPE问题，在编译期都会有强提示。

4. Java/Kotlin 混合调用

回到最初的问题：既然Kotlin都能在编译期避免了NPE，那为啥使用Kotlin重构后的代码反而导致Crash率上升呢？

原因是：项目里同时存在了Java和Kotlin代码，由上可知两者在NPE的检测上有所差异导致了一些兼容问题。

Kotlin 调用 Java

调用无返回值的函数

Kotlin虽然有空安全检测，但是Java并没有，因此对于Java方法来说，不论你传入空还是非空，在编译期我都没法检测出来。

public class TestJava {

    void invokeFromKotlin(String str) {

        System.out.println(str.length());

    }

}

class TestKotlin {



    fun test() {

        TestJava().invokeFromKotlin(null)

    }

}



fun main() {

    TestKotlin().test()

}

如上无论是Kotlin调用Java还是Java之间互调，都没法确保空安全，只能由被调用者(Java)自己处理可能的异常情况。

调用有返回值的函数

public class TestJava {

    public String getStr() {

        return null;

    }

}

class TestKotlin {

    fun testReturn() {

        println(TestJava().str.length)

    }

}



fun main() {

    TestKotlin().testReturn()

}

如上，Kotlin调用Java的方法获取返回值，由于在编译期Kotlin无法确定返回值，因此默认把它当做非空处理，若是Java返回了null，那么将会Crash。

Java 调用 Kotlin

调用无返回值的函数

先定义Kotlin类：

class TestKotlin {



    fun testWithoutNull(str: String) {

        println("len:${str.length}")

    }



    fun testWithNull(str: String?) {

        println("len:${str?.length}")

    }

}

有两个函数，分别接收可空/非空参数。

在Java里调用，先调用可空函数：

public class TestJava {

    public static void main(String args[]) {

        (new TestKotlin()).testWithNull(null);

    }

}

因为被调用方是Kotlin的可空函数，因此即使Java传入了null，也不会有Crash。

再换个方式，在Java里调用非空函数：

public class TestJava {

    public static void main(String args[]) {

        (new TestKotlin()).testWithoutNull(null);

    }

}

却发现Crash了！

为什么会Crash呢？反编译查看Kotlin代码：

public final class TestKotlin {

   public final void testWithoutNull(@NotNull String str) {

      Intrinsics.checkNotNullParameter(str, "str");

      String var2 = "len:" + str.length();

      System.out.println(var2);

   }



   public final void testWithNull(@Nullable String str) {

      String var2 = "len:" + (str != null ? str.length() : null);

      System.out.println(var2);

   }

}

对于非空的函数来说，会有检测代码：

Intrinsics.checkNotNullParameter(str, "str")：

    public static void checkNotNullParameter(Object value, String paramName) {

        if (value == null) {

            throwParameterIsNullNPE(paramName);

        }

    }

    private static void throwParameterIsNullNPE(String paramName) {

        throw sanitizeStackTrace(new NullPointerException(createParameterIsNullExceptionMessage(paramName)));

    }

可以看出：

1. Kotlin对于非空的函数参数，先判断其是否为空，若是为空则直接抛出NPE


2. Kotlin对于可空的函数参数，没有强制检测是否为空

调用有返回值的函数

Java 本身就没有空安全，只能在运行时进行处理。

小结

很容看出来：

1. Java 调用Kotlin的非空函数有Crash的风险，编译器无法检查到传入的参数是否为空


2. Java 调用Kotlin的可空函数没有Crash风险，Kotlin编译期检查空安全


3. Kotlin 调用Java的函数有Crash风险，由Java代码规避风险


4. Kotlin 调用Java有返回值的函数有Crash风险，编译器无法检查到返回值是否为空

回到文章的标题，我们已经大致知道了Java切换到Kotlin，为啥Crash就升上了的原因了，接下来再详细分析。

5. 常见的Java/Kotlin互调场景

Android里的Java代码分布

在Kotlin出现之前，Java就是Android开发的唯一语言，Android Framework、Androidx很多是Java代码编写的，因此现在依然有很多API是Java编写的。

而不少的第三方SDK因为稳定性、迁移代价的考虑依然使用的是Java代码。

我们自身项目里也因为一些历史原因存在Java代码。

以下讨论的前提是假设现有Java代码我们都无法更改。

Kotlin 调用Java获取返回值

由于编译期无法判定Java返回的值是空还是非空，因此若是确认Java函数可能返回空，则可以通过在Kotlin里使用可空的变量接收Java的返回值。

class TestKotlin {

    fun testReturn() {

        val str: String? = TestJava().str

        println(str?.length)

    }

}



fun main() {

    TestKotlin().testReturn()

}

Java 调用Kotlin函数

LiveData Crash的原因与预防

之前已经假设过我们无法改动Java代码，那么Java调用Kotlin函数的场景只有一个了：回调。

上面的有返回值场景还是比较容易防备，回调的场景就比较难发现，尤其是层层封装之后的代码。

这也是特别常见的场景，典型的例子如LiveData。

Crash原因

class TestKotlin(val lifecycleOwner: LifecycleOwner) {

    val liveData: MutableLiveData = MutableLiveData()

    fun testLiveData() {

        liveData.observe(lifecycleOwner) {

            println(it.length)

        }

    }



    init {

        testLiveData()

    }

}

如上，使用Kotlin声明LiveData，其类型是非空的，并监听LiveData的变化。

在另一个地方给LiveData赋值：

TestKotlin(this@MainActivity).liveData.value = null

虽然LiveData的监听和赋值的都是使用Kotlin编写的，但不幸的是还是Crash了。

发送和接收都是用Kotlin编写的，为啥还会Crash呢？

看看打印：

意思是接收到的字符串是空值(null)，看看编译器提示：

原来此处的回调传入的值被认为是非空的，因此当使用it.length访问的时候编译器不会有空安全提示。

再看看调用的地方：

可以看出，这回调是Java触发的。

Crash 预防

第一种方式：

我们看到LiveData的数据类型是泛型，因此可以考虑在声明数据的时候定为非空：

class TestKotlin(val lifecycleOwner: LifecycleOwner) {

    val liveData = MutableLiveData()

    fun testLiveData() {

        liveData.observe(lifecycleOwner) {

            println(it?.length)

        }

    }



    init {

        testLiveData()

    }

}

如此一来，当访问it.length时编译器就会提示可空调用。

第二种方式：

不修改数据类型，但在接收的地方使用可空类型接收：

class TestKotlin(val lifecycleOwner: LifecycleOwner) {

    val liveData = MutableLiveData()

    fun testLiveData() {

        liveData.observe(lifecycleOwner) {

            val dataStr:String? = it

            println(dataStr?.length)

        }

    }



    init {

        testLiveData()

    }

}

第三种方式：

使用Flow替换LiveData。

LiveData 修改建议：

1. 若是新写的API，建议使用第三种方式


2. 若是修改老的代码，建议使用第一种方式，因为可能有多个地方监听LiveData值的变化，如果第一种方式的话需要写好几个地方。

其它场景的Crash预防：

与后端交互的数据结构
比如与后端交互声明的类，后端有可能返回null，此时在客户端接收时若是使用了非空类型的字段去接收，那么会发生Crash。

通常来说，我们会使用网络框架（如retrofit）接收数据，数据的转换并不是由我们控制，因此无法使用针对LivedData的第二种方式。

有两种方式解决：

1. 与后端约定，不能返回null（等于白说）


2. 客户端声明的类的字段声明为可空（类似针对LivedData的第一种方式）

Json序列化/反序列化

Json字符串转换为对象时，有些字段可能为空，也需要声明为可空字段。

小结

在Activity间传递的数据一般比较简单，但是有时候实际开发中也会传一些比较复杂的数据，尤其是面试问道当遇到需要在Activity间传递大量的数据怎么办？

Intent 传递数据的大小是有限制的，它大概能传的数据是1M-8K，原因是Binder锁映射的内存大小就是1M-8K.一般activity间传递数据会要使用到binder，因此这个就成为了数据传递的大小的限制。那么当activity间要传递大数据采用什么方式呢？其实方式很多，我们就举几个例子给大家说明一下，但是无非就是使用数据持久化，或者内存共享方案。一般大数据的存储不适宜使用SP， MMKV，DataStore。

Activity之间传递大量数据主要有如下几种方式实现：

• LruCache


• 持久化（sqlite、file等）


• 匿名共享内存

使用LruCache

LruCache是一种缓存策略，可以帮助我们管理缓存，想具体了解的同学可以去Glide章节中具体先了解下。在当前的问题下，我们可以利用LruCache存储我们数据作为一个中转，好比我们需要Activity A向Activity B传递大量数据，我们可以Activity A先向LruCache先写入数据，之后Activity B从LruCache读取。

首先我们定义好写入读出规则：

public interface IOHandler {

    //保存数据

    void put(String key, String value);

    void put(String key, int value);

    void put(String key, double value);

    void put(String key, float value);

    void put(String key, boolean value);

    void put(String key, Object value);

​

    //读取数据

    String getString(String key);

    double getDouble(String key);

    boolean getBoolean(String key);

    float getFloat(String key);

    int getInt(String key);

    Object getObject(String key);

}

我们可以根据规则也就是接口，写出具体的实现类。实现类中我们保存数据使用到LruCache，这里面我们一定要设置一个大小，因为内存中数据的最大值是确定，我们保存数据的大小最好不要超过最大值的1/8.

LruCache<String, Object> mCache = new LruCache<>( 10 * 1024*1024);

写入数据我们使用比较简单：

@Override

public void put(String key, String value) {

    mCache.put(key, value);

}

好比上面写入String类型的数据，只需要接收到的数据全部put到mCache中去。

读取数据也是比较简单方便：

@Override

public String getString(String key) {

    return String.valueOf(mCache.get(key));

}

持久化数据

那就是sqlite、file等方式。将需要传递的数据写在临时文件或者数据库中，再跳转到另外一个组件的时候再去读取这些数据信息，这种处理方式会由于读写文件较为耗时导致程序运行效率较低。这种方式特点如下：

优势：

（1）应用中全部地方均可以访问

（2）即便应用被强杀也不是问题了

缺点：

（1）操做麻烦

（2）效率低下

匿名共享内存

在跨进程传递大数据的时候，我们一般会采用binder传递数据，但是Binder只能传递1M一下的数据，所以我们需要采用其他方式完成数据的传递，这个方式就是匿名共享内存。

「Anonymous Shared Memory 匿名共享内存」是 Android 特有的内存共享机制，它可以将指定的物理内存分别映射到各个进程自己的虚拟地址空间中，从而便捷的实现进程间内存共享。

Android 上层提供了一些内存共享工具类，就是基于 Ashmem 来实现的，比如 MemoryFile、 SharedMemory。

今日分享到此结束，对你有帮助的话，点个赞再走呗，每日一个面试小技巧

关注公众号：Android老皮

解锁  《Android十大板块文档》 ，让学习更贴近未来实战。已形成PDF版

内容如下：

1.Android车载应用开发系统学习指南（附项目实战）

2.Android Framework学习指南，助力成为系统级开发高手

3.2023最新Android中高级面试题汇总+解析，告别零offer

4.企业级Android音视频开发学习路线+项目实战（附源码）

5.Android Jetpack从入门到精通，构建高质量UI界面

6.Flutter技术解析与实战，跨平台首要之选

7.Kotlin从入门到实战，全方面提升架构基础

8.高级Android插件化与组件化（含实战教程和源码）

9.Android 性能优化实战+360°全方面性能调优

10.Android零基础入门到精通，高手进阶之路

在 Android 应用开发中，网络请求必不可少，如何去封装才能使自己的请求代码显得更加简洁优雅，更加方便于以后的开发呢？这里利用 Kotlin 的函数式编程和 Retrofit 来从零开始封装一个网络请求框架，下面就一起来瞧瞧吧！

首先，引入网络请求框架的依赖。

implementation 'com.squareup.okhttp3:okhttp:4.9.1'

implementation 'com.squareup.okhttp3:logging-interceptor:4.9.1'

implementation 'com.squareup.retrofit2:retrofit:2.9.0'

implementation 'com.squareup.retrofit2:converter-gson:2.9.0'

定义拦截器

我们可以先自定义一些拦截器，对一些公共提交的字段做封装，比如 token。在服务器注册成功或者登录成功之后获取 token，过期之后便无法正常请求接口，所以需要在请求接口时判断 token 是否过期，由于接口众多，不可能每个接口都进行判断，所以需要全局设置一个拦截器判断 token。

class TokenInterceptor : Interceptor {



    override fun intercept(chain: Interceptor.Chain): Response {

        // 当前拦截器中收到的请求对象

        val request = chain.request()

        // 执行请求

        var response = chain.proceed(request)

        if (response.body == null) {

            return response

        }

        val mediaType = response.body!!.contentType() ?: return response

        val type = mediaType.toString()

        if (!type.contains("application/json")) {

            return response

        }

        val result = response.body!!.string()

        var code = ""

        try {

            val jsonObject = JSONObject(result)

            code = jsonObject.getString("code")

        } catch (e: Exception) {

            e.printStackTrace()

        }

        // 重新构建 response

        response = response.newBuilder().body(result.toResponseBody(null)).code(200).build()

        if (isTokenExpired(code)) {

            // token 过期，需要获取新的 token

            val newToken = getNewToken() ?: return response

            // 重新构建新的 token 请求

            val builder = request.url.newBuilder().setEncodedQueryParameter("token", newToken)

            val newRequest = request.newBuilder().method(request.method, request.body)

                .url(builder.build()).build()

            return chain.proceed(newRequest)

        }

        return response

    }



    // 判断 token 是否过期

    private fun isTokenExpired(code: String) =

        TextUtils.equals(code, "401") || TextUtils.equals(code, "402")



    // 刷新 token

    private fun getNewToken() = ServiceManager.instance.refreshToken()



}

这里是 token 过期之后直接重新请求接口获取新的 token，这需要根据具体业务需求来，有些可能是过期之后跳转到登录页面，让用户重新登录等等。

我们还可以再定义一个拦截器，全局添加 token。

class TokenHeaderInterceptor : Interceptor {



    override fun intercept(chain: Interceptor.Chain): Response {

        var request = chain.request()

        val headers = request.headers

        var token = headers["token"]

        if (TextUtils.isEmpty(token)) {

            token = ServiceManager.instance.getToken()

            request = request.newBuilder().addHeader("token", token).build()

        }

        return chain.proceed(request)

    }

    

}

创建 retrofit

class RetrofitUtil {



    companion object {



        private const val TIME_OUT = 20L



        private fun createRetrofit(): Retrofit {



            // OkHttp 提供的一个拦截器，用于记录和查看网络请求和响应的日志信息。

            val interceptor = HttpLoggingInterceptor()

            // 打印请求和响应的所有内容，响应状态码和执行时间等等。

            interceptor.level = HttpLoggingInterceptor.Level.BODY



            val okHttpClient = OkHttpClient().newBuilder().apply {

                addInterceptor(interceptor)

                addInterceptor(TokenInterceptor())

                addInterceptor(TokenHeaderInterceptor())

                retryOnConnectionFailure(true)

                connectTimeout(TIME_OUT, TimeUnit.SECONDS)

                writeTimeout(TIME_OUT, TimeUnit.SECONDS)

                readTimeout(TIME_OUT, TimeUnit.SECONDS)

            }.build()



            return Retrofit.Builder().apply {

                addConverterFactory(GsonConverterFactory.create())

                baseUrl(ServiceManager.instance.baseHttpUrl)

                client(okHttpClient)

            }.build()



        }



        fun <T> getAPI(clazz: Class<T>): T {

            return createRetrofit().create(clazz)

        }



    }

}

网络请求封装

定义通用基础请求返回的数据结构

private const val SERVER_SUCCESS = "200"



data class BaseResp<T>(val code: String, val message: String, val data: T)



fun <T> BaseResp<T>?.isSuccess() = this?.code == SERVER_SUCCESS

请求状态流程封装，可以根据具体业务流程实现方法。

class RequestAction<T> {



    // 开始请求

    var start: (() -> Unit)? = null

        private set



    // 发起请求

    var request: (suspend () -> BaseResp<T>)? = null

        private set



    // 请求成功

    var success: ((T?) -> Unit)? = null

        private set



    // 请求失败

    var error: ((String) -> Unit)? = null

        private set



    // 请求结束

    var finish: (() -> Unit)? = null

        private set



    fun request(block: suspend () -> BaseResp<T>) {

        request = block

    }



    fun start(block: () -> Unit) {

        start = block

    }



    fun success(block: (T?) -> Unit) {

        success = block

    }



    fun error(block: (String) -> Unit) {

        error = block

    }



    fun finish(block: () -> Unit) {

        finish = block

    }



}

因为网络请求都是在 ViewModel 中进行的，我们可以定义一个 ViewModel 的扩展函数，用来处理网络请求。

fun <T> ViewModel.netRequest(block: RequestAction<T>.() -> Unit) {



    val action = RequestAction<T>().apply(block)



    viewModelScope.launch {

        try {

            action.start?.invoke()

            val result = action.request?.invoke()

            if (result.isSuccess()) {

                action.success?.invoke(result!!.data)

            } else {

                action.error?.invoke(result!!.message)

            }

        } catch (ex: Exception) {

            // 可以做一些定制化的返回错误提示

            action.error?.invoke(getErrorTipContent(ex))

        } finally {

            action.finish?.invoke()

        }

    }



}

private const val SERVER_ERROR = "HTTP 500 Internal Server Error"

private const val HTTP_ERROR_TIP = "服务器或者网络连接错误"



fun getErrorTipContent(ex: Throwable) = if (ex is ConnectException || ex is UnknownHostException

    || ex is SocketTimeoutException || SERVER_ERROR == ex.message.toString()

) HTTP_ERROR_TIP else ex.message.toString()

使用案例

定义网络请求接口

interface HttpApi {

    

    @GET("/exampleA/exampleP/exampleI/exampleApi/getNetData")

    suspend fun getNetData(@QueryMap params: HashMap<String, String>): BaseResp<NetDataBean>



    @GET("/exampleA/exampleP/exampleI/exampleApi/getTestData")

    suspend fun getTestData(

        @Query("param1") param1: String,

        @Query("param2") param2: String

    ): BaseResp<NetDataBean>



    @GET("/exampleA/exampleP/exampleI/exampleApi/{id}")

    fun getNetTask(

        @Path("id") id: String,

        @QueryMap params: HashMap<String, String>,

    ): Call<BaseResp<TaskBean>>



    @FormUrlEncoded

    @POST("/exampleA/exampleP/exampleI/exampleApi/confirm")

    suspend fun confirm(@Field("id") id: String, @Field("token") token: String): BaseResp<String>



    @FormUrlEncoded

    @POST("/exampleA/exampleP/exampleI/exampleApi/upload")

    suspend fun upload(@FieldMap params: Map<String, String>): BaseResp<String>



}

我们可以写一个网络请求帮助类，用于请求的创建。

class RequestHelper {



    private val httpApi = RetrofitUtil.getAPI(HttpApi::class.java)



    companion object {

        val instance: RequestHelper by lazy(mode = LazyThreadSafetyMode.SYNCHRONIZED) {

            RequestHelper()

        }

    }



    suspend fun getNetData(params: HashMap<String, String>) = httpApi.getNetData(params)



    suspend fun getTestData(branchCode: String, token: String) =

        httpApi.getTestData(branchCode, token)



    suspend fun getNetTask(id: String, params: HashMap<String, String>) =

        httpApi.getNetTask(id, params)



    suspend fun confirm(id: String, token: String) = httpApi.confirm(id, token)



    suspend fun upload(params: HashMap<String, String>) = httpApi.upload(params)



}

定义用户的意图和 UI 状态

// 定义用户意图

sealed class MainIntent {

    object FetchData : MainIntent()

}



// 定义 UI 状态

sealed class MainUIState {

    object Loading : MainUIState()

    data class NetData(val data: NetDataBean?) : MainUIState()

    data class Error(val error: String?) : MainUIState()

}

ViewModel 中做意图的处理和 UI 状态的变更，根据网络请求结果传递不同的状态，使用定义的扩展方法去执行网络请求，封装过后的网络请求就很简洁方便了，下面演示下具体使用。

class MainViewModel : ViewModel() {



    val mainIntent = Channel<MainIntent>(Channel.UNLIMITED)



    private val _mainUIState = MutableStateFlow<MainUIState>(MainUIState.Loading)

    val mainUIState: StateFlow<MainUIState>

        get() = _mainUIState



    init {

        viewModelScope.launch {

            mainIntent.consumeAsFlow().collect {

                if (it is MainIntent.FetchData) {

                    getNetDataResult()

                }

            }

        }

    }

    // 使用

    private fun getNetDataResult() = netRequest {

        start { _mainUIState.value = MainUIState.Loading }

        request {

            val paramMap = hashMapOf<String, String>()

            paramMap["param1"] = "param1"

            paramMap["param2"] = "param2"

            RequestHelper.instance.getNetData(paramMap)

        }

        success { _mainUIState.value = MainUIState.NetData(it) }

        error { _mainUIState.value = MainUIState.Error(it) }

    }

    

}

这样是不是看起来很简洁呢？接下来，Activity 负责发送意图和接收 UI 状态进行相关的处理就行啦！

class MainActivity : AppCompatActivity() {



    private val viewModel by viewModels<MainViewModel>()

    private lateinit var binding: ActivityMainBinding



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        binding = DataBindingUtil.setContentView(this, R.layout.activity_main)

        initData()

        observeViewModel()

    }



    private fun initData() {

        lifecycleScope.launch {

            // 发送意图

            viewModel.mainIntent.send(MainIntent.FetchData)

        }

    }

    

    private fun observeViewModel() {

        lifecycleScope.launch {

            viewModel.mainUIState.collect {

                when (it) {

                    is MainUIState.Loading -> showLoading()

                    // 这里拿到网络请求返回的数据，根据业务自行操作，这里只做简单的显示。

                    is MainUIState.NetData -> showText(it.data.toString())

                    is MainUIState.Error -> showText(it.error)

                }

            }

        }

    }



    private fun showLoading() {

        binding.progressBar.visibility = View.VISIBLE

        binding.netText.visibility = View.GONE

    }



    private fun showText(result: String?) {

        binding.progressBar.visibility = View.GONE

        binding.netText.visibility = View.VISIBLE

        binding.netText.text = result

    }

    

}

文件的上传与下载

如果是文件的上传和下载呢？其实文件还不太一样，这涉及到上传进度，文件的处理等方面，所以，为了方便开发使用，我们可以针对文件单独再做一下封装。

定义文件上传对象

data class UpLoadFileBean(val file: File, val fileKey: String)

自定义 RequestBody，从中获取上传进度。

class ProgressRequestBody(

    private var requestBody: RequestBody,

    var onProgress: ((Int) -> Unit)?,

) : RequestBody() {



    private var bufferedSink: BufferedSink? = null



    override fun contentType(): MediaType? = requestBody.contentType()



    override fun contentLength(): Long {

        return requestBody.contentLength()

    }



    override fun writeTo(sink: BufferedSink) {

        if (bufferedSink == null) bufferedSink = createSink(sink).buffer()

        bufferedSink?.let {

            requestBody.writeTo(it)

            it.flush()

        }

    }



    private fun createSink(sink: Sink): Sink = object : ForwardingSink(sink) {

        // 当前写入字节数

        var bytesWritten = 0L



        // 总字节长度

        var contentLength = 0L



        override fun write(source: Buffer, byteCount: Long) {

            super.write(source, byteCount)



            if (contentLength == 0L) {

                contentLength = contentLength()

            }



            // 增加当前写入的字节数

            bytesWritten += byteCount



            CoroutineScope(Dispatchers.Main).launch {

                // 进度回调

                onProgress?.invoke((bytesWritten * 100 / contentLength).toInt())

            }

        }

    }



}

创建 MultipartBody.Part

fun <T> createPartList(action: UpLoadFileAction<T>): List<MultipartBody.Part> =

    MultipartBody.Builder().apply {

        // 公共参数 token

        addFormDataPart("token", ServiceManager.instance.getToken())



        // 其他基本参数

        action.params?.forEach {

            if (it.key.isNotBlank() && it.value.isNotBlank()) {

                addFormDataPart(it.key, it.value)

            }

        }



        // 文件校验

        action.fileData?.let {

            addFormDataPart(

                it.fileKey, it.file.name, ProgressRequestBody(

                    requestBody = it.file

                    .asRequestBody("application/octet-stream".toMediaTypeOrNull()),

                    onProgress = action.progress

                )

            )

        }

    }.build().parts

定义文件上传行为

class UpLoadFileAction<T> {



    // 请求体

    lateinit var request: (suspend () -> BaseResp<T>)

        private set



    lateinit var parts: List<MultipartBody.Part>



    // 其他普通参数

    var params: HashMap<String, String>? = null

        private set



    // 文件参数

    var fileData: UpLoadFileBean? = null

        private set



    // 初始化参数

    fun init(params: HashMap<String, String>?, fileData: UpLoadFileBean?) {

        this.params = params

        this.fileData = fileData

        parts = createPartList(this)

    }



    var start: (() -> Unit)? = null

        private set



    var success: (() -> Unit)? = null

        private set



    var error: ((String) -> Unit)? = null

        private set



    var progress: ((Int) -> Unit)? = null

        private set



    var finish: (() -> Unit)? = null

        private set



    fun start(block: () -> Unit) {

        start = block

    }



    fun success(block: () -> Unit) {

        success = block

    }



    fun error(block: (String) -> Unit) {

        error = block

    }



    fun progress(block: (Int) -> Unit) {

        progress = block

    }



    fun finish(block: () -> Unit) {

        finish = block

    }



    fun request(block: suspend () -> BaseResp<T>) {

        request = block

    }



}

同样，定义 ViewModel 的扩展函数，用来执行文件上传。

fun <T> ViewModel.upLoadFile(

    block: UpLoadFileAction<T>.() -> Unit,

    params: HashMap<String, String>?,

    fileData: UpLoadFileBean?,

) = viewModelScope.launch {

    val action = UpLoadFileAction<T>().apply(block)

    try {

        action.init(params, fileData)

        action.start?.invoke()

        val result = action.request.invoke()

        if (result.isSuccess()) {

            action.success?.invoke()

        } else {

            action.error?.invoke(result.message)

        }

    } catch (ex: Exception) {

        action.error?.invoke(getErrorTipContent(ex))

    } finally {

        action.finish?.invoke()

    }

}