大家在开发时，遇到的一个典型的 Bug 就是：为什么数据查询为空？

对应的现象就是：前端展示不出数据、或者后端查询到的数据列表为空。

遇到此类问题，其实是有经典的解决套路的，下面鱼皮给大家分享如何高效解决这个问题。

只需 4 个步骤：

解决步骤

1、定位问题边界

首先要定位数据查询为空的错误边界。说简单一点，就是要确认是前端还是后端的锅。

要先从请求的源头排查，也就是前端浏览器，毕竟前端和后端是通过接口（请求）交互的。

在浏览器中按 F12 打开浏览器控制台，进入网络标签，然后刷新页面或重新触发请求，就能看到请求的信息了。

选中请求并点击预览，就能看到后端返回结果，有没有返回数据一看便知。

如果发现后端正常返回了数据，那就是前端的问题，查看自己的页面代码来排查为什么数据没在前端显示，比如是不是取错了数据的结构？可以多用 debugger 或 console.log 等方式输出信息，便于调试。

星球同学可以免费阅读前端嘉宾神光的《前端调试通关秘籍》：t.zsxq.com/13Rh4xxNK

如果发现后端未返回数据，那么前端需要先确认下自己传递的参数是否正确。

比如下面的例子，分页参数传的太大了，导致查不到数据：

如果发现请求参数传递的没有问题，那么就需要后端同学帮忙解决了。

通过这种方式，直接就定位清楚了问题的边界，高效~

2、后端验证请求

接下来的排查就是在后端处理了，首先开启 Debug 模式，从接受请求参数开始逐行分析。

比如先查看请求参数对象，确认前端有没有按照要求传递请求参数：

毕竟谁能保证我们的同事（或者我们自己）不是小迷糊呢？即使前端说自己请求是正确的，但也必须要优先验证，而不是一上来就去分析数据库和后端程序逻辑的问题。

验证请求参数对象没问题后，接着逐行 Debug，直到要执行数据库查询。

3、后端验证数据库查询

无论是从 MySQL、MongoDB、Redis，还是文件中查询数据，为了理解方便，我们暂且统称为数据库。

上一步中，我们已经 Debug 到了数据库查询，需要重点关注 2 个点：

1）查看封装的请求参数是否正确

对于 MyBatis Plus 框架来说，就是查看 QueryWrapper 内的属性是否正确填充了查询条件

2）查看数据库的返回结果是否有值

比如 MyBatis Plus 的分页查询中，如果 records 属性的 size 大于 0，表示数据库返回了数据，那么就不用再排查数据库查询的问题了；而如果 size = 0，就要分析为什么从数据库中查询的数据为空。

这一步尤为关键，我们需要获取到实际发送给数据库查询的 SQL 语句。如果你使用的是 MyBatis Plus 框架，可以直接在 application.yml 配置文件中开启 SQL 语句日志打印，参考配置如下：

mybatis-plus:

  configuration:

    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

然后执行查询，就能看到完整的 SQL 语句了：

把这个 SQL 语句复制到数据库控制台执行，验证下数据结果是否正确。如果数据库直接执行语句都查不出数据，那就确认是查询条件错误了还是数据库本身就缺失数据。

4、后端验证数据处理逻辑

如果数据库查询出了结果，但最终响应给前端的数据为空，那么就需要在数据库查询语句后继续逐行 Debug，验证是否有过滤数据的逻辑。

比较典型的错误场景是查询出的结果设置到了错误的字段中、或者由于权限问题被过滤和脱敏掉了。

最后

以后再遇到数据查询为空的情况，按照以上步骤排查问题即可。排查所有 Bug 的核心流程都是一样的，先搜集信息、再定位问题、最后再分析解决。

背景

记得有次公司搞促销活动，流量增加，但是系统一直很平稳（我们开发的系统真牛），大家很开心的去聚餐，谈笑风声，气氛融洽，突然电话响起....

运维：小李，你们系统使用的rabbitmq的消息大量堆积，导致服务器cpu飙升，赶紧回来看看，服务器要顶不住了

小李：好的

系统架构描述

我们使用rabbitmq主要是为了系统解耦、异步提高系统的性能

前端售卖系统，生成订单后，推送订单消息到rabbitmq，订单履约系统作为消费者，消费订单消息落库，做后续操作

排查以及解决

方案一 增加消费者

第一我们想到的原因，流量激增，生成的订单速度远远大于消费者消费消息的速度，目前我们只部署了三个节点，那我们是否增加消费者，就可以解决这个问题，让消费者消费消息的速度远远大于生成者生成消息的速度，那消息就不存在堆积的问题，自然服务器压力也就下来了

通知运维，再部署三个点，也是就增加三个消费者，由原来的三个消费者变为6个消费者，信心满满的部署完成后，等待一段时间，不出意外还是出了意外，消息还是在持续堆积，没有任何改善，我心里那个急啊，为什么增加了消费者？一点改善没有呢

方案二 优化消费者的处理逻辑

持续分析，是不是消费者的逻辑有问题，处理速度还是慢？在消费逻辑分析中，发现在处理订单消息的逻辑里，调用了库存系统的一个接口，有可能是这个接口响应慢，导致消费的速度慢，跟不上生产消息的速度。

查看库存系统的运行情况，发现系统压力非常大，接口请求存在大量超时的情况，系统也在崩溃的边缘，因为我们上面的解决方案，增加了三个节点，间接的增大了并发。告知负责库存系统的同学，进行处理排查解决，但一时解决不了，如果持续这样，整体链路有可能全部崩掉，这怎么办呢？

消费者逻辑优化，屏蔽掉调用库存的接口，直接处理消息，但这种我们的逻辑是不完成，虽然能减少服务器的压力，后续处理起来也非常的麻烦，这种方式不可取

方案三 清空堆积的消息

为了减少消息的堆积，减轻服务器的压力，我们是否可以把mq里面的消息拿出来，先存储，等服务恢复后，再把存储的消息推送到mq，再处理呢？

• 新建消费者，消费rabbitmq的消息，不做任何业务逻辑处理，直接快速消费消息，把消息存在一张表里，这样就没消息的堆积，服务器压力自然就下来了。

这方案上线后，过了一段时间观察，消息不再堆积，服务器的负载也下来了，我内心也不再慌了，那存储的那些消息，还处理吗？当然处理，怎么处理呢？

• 后续等库存服务问题解决后，停掉新的消费者，新建一个生产者，再把表里的订单数据推送到rabbitmq，进行业务逻辑的处理

至此，问题就完美的解决了，悬着的心也放下了

问题产生的原因分析

整个链路服务一直都是很稳定的，因为流量的激增，库存服务的服务能力跟不上，导致整个链路出了问题，如果平台要搞促销这种活动，我们还是要提前评估下系统的性能，对整个链路做一次压测，找出瓶颈，该优化的要优化，资源不足的加资源

消息堆积为什么会导致cpu飙升呢？

问题虽然解决了，但我很好奇，消息堆积为什么会导致cpu飙升呢？

RabbitMQ 是一种消息中间件，用于在应用程序之间传递消息。当消息堆积过多时，可能会导致 CPU 飙升的原因有以下几点：

1. 消息过多导致消息队列堆积：当消息的产生速度大于消费者的处理速度时，消息会积累在消息队列中。如果消息堆积过多，RabbitMQ 需要不断地进行消息的存储、检索和传递操作，这会导致 CPU 使用率升高。


2. 消费者无法及时处理消息：消费者处理消息的速度不足以追赶消息的产生速度，导致消息不断积累在队列中。这可能是由于消费者出现瓶颈，无法处理足够多的消息，或者消费者的处理逻辑复杂，导致消费过程耗费过多的 CPU 资源。


3. 消息重试导致额外的 CPU 开销：当消息处理失败时，消费者可能会进行消息的重试操作，尝试再次处理消息。如果重试频率较高，会导致消息在队列中频繁流转、被重复消费，这会增加额外的 CPU 开销。


4. 过多的连接以及网络IO：当消息堆积过多时，可能会引发大量的连接请求和网络数据传输。这会增加网络 IO 的负载，并占用 CPU 资源。

通用的解决方案

• 增加消费者：通过增加消费者的数量来提升消息的处理能力。增加消费者可以分担消息消费的负载，缓解消息队列的堆积问题。


• 优化消费者的处理逻辑：检查消费者的代码是否存在性能瓶颈或是复杂的处理逻辑。可以通过优化算法、减少消费过程的计算量或是提高代码的效率来减少消费者的 CPU 开销。


• 避免频繁的消息重试：当消息无法处理时，可以根据错误类型进行不同的处理方式，如将无法处理的消息转移到死信队列中或进行日志记录。避免频繁地对同一消息进行重试，以减少额外的 CPU 开销。


• 调整 RabbitMQ 配置：可以调整 RabbitMQ 的参数来适应系统的需求，如增加内存、调整消息堆积的阈值和策略，调整网络连接等配置。


• 扩展硬件资源：如果以上措施无法解决问题，可能需要考虑增加 RabbitMQ 的集群节点或者扩容服务器的硬件资源，以提升整个系统的处理能力。

需要根据具体情况综合考虑以上因素，并结合实际情况进行调试和优化，以解决消息堆积导致 CPU 飙升的问题，不能照葫芦画瓢，像我第一次直接增加消费者，差点把这个链路都干挂了

写作不易，刚好你看到，刚好对你有帮助，麻烦点点赞，有问题的留言讨论。

快过年，我的线上发布出现故障

“五哥，你在上线吗？”，旁边有一个声音传来。

“啊，怎么了？”。真是要命，在上线发布时候，我最讨厌别人叫我的名字 。我慌忙站起来，看向身后，原来是 建哥在问我。我慌忙的问，怎么回事。

“DBA 刚才在群里说，Task数据库 cpu 负载增加！有大量慢查询”，建哥来我身边，跟我说。

慢慢的，我身边聚集着越来越多的人

“你在上线Task服务吗？改动什么内容了，看看要不要立即回滚？”旁边传来声音。此时，我的心开始怦怦乱跳，手心发痒，紧张不已。

我检查着线上机器的日志，试图证明报警的原因不是出在我这里。

我对着电脑，微微颤抖地回答大家：“我只是升级了基础架构的Jar包，其他内容没有改动啊。”此时我已分不清是谁在跟我说话，只能对着电脑作答……

这时DBA在群里发送了一条SQL，他说这条SQL导致了大量的慢查询。

我突然记起来了，我转过头问林哥：“林哥，你上线了什么内容？”这次林哥有代码的变更，跟我一起上线。我觉得可能是他那边有问题。

果然，林哥看着代码发呆。他嘟囔道：“我添加了索引啊，怎么会有慢查询呢？”原来慢查询的SQL是林哥刚刚添加的，这一刻我心里的石头放下了，问题并不在我，我轻松了许多。

“那我先回滚吧”，幸好我们刚发布了一半，现在回滚还来得及，我尝试回滚机器。此刻我的紧张情绪稍稍平静下来，手也不再发抖。

既然不是我的问题，我可以以吃瓜的心态，暗中观察事态的发展。我心想：真是吓死我了，幸好不是我的错。

然而我也有一些小抱怨：为什么非要和我一起搭车上线，出了事故，还得把我拖进来。

故障发生前的半小时

2年前除夕前的一周，我正准备着过年前的最后一次线上发布，这时候我刚入职两个月，自然而然会被分配一些简单的小活。这次上线的内容是将基础架构的Jar包升级到新版本。一般情况下，这种配套升级工作不会出问题，只需要按部就班上线就行。

“五哥，你是要上线 Task服务吗？”，工位旁的林哥问我，当时我正做着上线前的准备工作。

“对啊，马上要发布，怎么了？”，我转身回复他。

“我这有一个代码变更，跟你搭车一起上线吧，改动内容不太多。已经测试验证过了”，林哥说着，把代码变更内容发给我，简单和我说了下代码变更的内容。我看着改动内容确实不太多，新增了一个SQL查询，于是便答应下来。我重新打包，准备发布上线。

半小时以后，便出现了文章开头的情景。新增加的SQL 导致大量慢查询，数据库险些被打挂。

为什么加了索引，还会出现慢查询呢？

”加了索引，为什么还有慢查询？“，这是大家共同的疑问。

事后分析故障的原因，通过 mysql explain 命令，查看该SQL 确实没有命中索引，从而导致慢查询。

这个SQL 大概长这个样子！我去掉了业务相关的部分。

select * from order_discount_detail where orderId = 1123;

order_discount_detail 在 orderId 这一列上确实加了索引，不应该出现慢查询，乍一看，没有什么问题。我本能的想到了索引失效的几种场景。难道是类型不匹配，导致索引失效？

果不其然， orderId 在数据库中的类型 是 varchar 类型，而传参是按照 long 类型传的。

复习一下： 类型转换导致索引失效

类型转换导致索引失效，是很容易犯的错误

因为在某些特殊场景下要对接外部订单，存在订单Id为字符串的情况，所以 orderId被设计成 varchar 字符串类型。然而出问题的场景比较明确，订单id 就是long类型，不可能是字符串类型。

所以林哥，他在使用Mybatis 时，直接使用 long 类型的 orderId字段传参，并且没有意识到两者数据类型不对。

因为测试环境数据量比较小，即使没有命中索引，也不会有很严重的慢查询，并且测试环境请求量比较低，该慢查询SQL 执行次数较少，所以对数据库压力不大，测试阶段一直没有发现性能问题。

直到代码发布到线上环境————数据量和访问量都非常高的环境，差点把数据库打挂。

mybatis 能避免 “类型转换导致索引失效” 的问题吗？

mybatis能自动识别数据库和Java类型不一致的情况吗？如果发现java类型和数据库类型不一致，自动把java 类型转换为数据库类型，就能避免索引失效的情况！

答案是不能。我没找到 mybatis 有这个能力。

mybatis 使用 #{} 占位符，会自动根据 参数的 Java 类型填充到 SQL中，同时可以避免SQL注入问题。

例如刚才的SQL 在 mybatis中这样写。

select * from order_discount_detail where orderId = #{orderId};

orderId 是 String 类型，SQL就变为

select * from order_discount_detail where orderId = ‘1123’;

mybatis 完全根据 传参的java类型，构建SQL，所以不要认为 mybatis帮你处理好java和数据库的类型差异问题，你需要自己关注这个问题！

再次提醒，"类型转换导致索引失效"的问题，非常容易踩坑。并且很难在测试环境发现性能问题，等到线上再发现问题就晚了，大家一定要小心！小心！

险些背锅

可能有朋友疑问，为什么发布一半时出现慢查询，单机发布阶段不能发现这个问题吗？

之所以没发现这个问题，是因为 新增SQL在 Kafka消费逻辑中，由于单机发布机器启动时没有争抢到 kafka 分片，所以没有走到新代码逻辑。

此外也没有遵循降级上线的代码规范，如果上线默认是降级状态，上线过程中就不会有问题。放量阶段可以通过降级开关快速止损，避免回滚机器过程缓慢而导致的长时间故障。

不是我的问题，为什么我也背了锅

因为我在发布阶段没有遵循规范，按照规定的流程应该在单机发布完成后进行引流压测。引流压测是指修改机器的Rpc权重，将Rpc请求集中到新发布的单机上，这样就能提前发现线上问题。

然而由于我偷懒，跳过了单机引流压测。由于发布的第一台机器没有抢占到Kafka分片，因此无法执行新代码逻辑。即使进行了单机引流压测，也无法提前发现故障。虽然如此，但我确实没有遵循发布规范，错在我。

如果上线时没有出现故障，这种不规范的上线流程可能不会受到责备。但如果出现问题，那只能怪我倒霉。在复盘过程中，我的领导抓住了这件事，给予了重点批评。作为刚入职的新人，被指责确实让我感到不舒服。

快要过年了，就因为搭车上线，自己也要承担别人犯错的后果，让我很难受。但是自己确实也有错，当时我的心情复杂而沉重。

两年前的事了，说出来让大家吃个瓜，乐呵一下。如果这瓜还行，东东发财的小手点个赞

前言

目前大多数库api设计都是Log.d("tag", "msg")这种风格，而且支持自定义日志存储的比较少，
所以作者想自己造一个轮子。

这种api风格有什么不好呢？

首先，它的tag是一个字符串，需要开发人员严格管理tag，要不然可能各种硬编码的tag满天飞。

另外，它也可能导致性能陷阱，假设有这么一段代码：

// 打印一个List

Log.d("tag", list.joinToString())

此处使用Debug打印日志，生产模式下调高日志等级，不打印这一行日志，但是list.joinToString()这一行代码仍然会被执行，有可能导致性能问题。

下文会分析作者期望的api是什么样的，本文演示代码都是用kotlin，库中好用的api也是基于kotlin特性来实现的。

作者写库有个习惯，对外开放的类或者全局方法都会加一个前缀f，一个是为了避免命名冲突，另一个是为了方便代码检索，以下文章中会出现，这里做一下解释。

期望

什么样的api才能解决上面的问题呢？我们看一下方法的签名和打印方式

inline fun <reified T : FLogger> flogD(block: () -> Any)

interface AppLogger : FLogger

flogD {

    list.joinToString { it }

}

flogD方法打印Debug日志，传一个Flogger的子类AppLogger作为日志标识，同时传一个block来返回要打印的日志内容。

日志标识是一个类或者接口，所以管理方式比较简单不会造成tag混乱的问题，默认tag是日志标识类的短类名。生产模式下调高日志等级后，block就不会被执行了，避免了可能的性能问题。

实现分析

日志库的完整实现已经写好了，放在这里xlog

• 支持限制日志大小，例如限制每天只能写入10MB的日志


• 支持自定义日志格式


• 支持自定义日志存储，即如何持久化日志

这一节主要分析一下实现过程中遇到的问题。

问题：如果App运行期间日志文件被意外删除了，怎么处理？

在Android中，用java.io的api对一个文件进行写入，如果文件被删除，继续写入的话不会抛异常，导致日志丢失，该如何解决？

有同学说，在写入之前先检查文件是否存在，如果存在就继续写入，不存在就创建后写入。

检查一个文件是否存在通常是调用java.io.File.exist()方法，但是它比较耗性能，我们来做一个测试：

measureTime {

    repeat(1_0000) {

        file.exists()

    }

}.let {

    Log.i("MainActivity", "time:${it.inWholeMilliseconds}")

}

14:50:33.536 MainActivity            com.sd.demo.xlog                I  time:39

14:50:35.872 MainActivity            com.sd.demo.xlog                I  time:54

14:50:38.200 MainActivity            com.sd.demo.xlog                I  time:43

14:50:40.028 MainActivity            com.sd.demo.xlog                I  time:53

14:50:41.693 MainActivity            com.sd.demo.xlog                I  time:58

可以看到1万次调用的耗时在50毫秒左右。

我们再测试一下对文件写入的耗时：

val output = filesDir.resolve("log.txt").outputStream().buffered()

val log = "1".repeat(50).toByteArray()

measureTime {

    repeat(1_0000) {

        output.write(log)

        output.flush()

    }

}.let {

    Log.i("MainActivity", "time:${it.inWholeMilliseconds}")

}

14:57:56.092 MainActivity            com.sd.demo.xlog                I  time:38

14:57:56.558 MainActivity            com.sd.demo.xlog                I  time:57

14:57:57.129 MainActivity            com.sd.demo.xlog                I  time:57

14:57:57.559 MainActivity            com.sd.demo.xlog                I  time:46

14:57:58.054 MainActivity            com.sd.demo.xlog                I  time:54

可以看到1万次调用，每次写入50个字符的耗时也在50毫秒左右。如果每次写入日志前都判断一下文件是否存在，那么实际上相当于2次写入的性能成本，这显然很不划算。

还有同学说，开一个线程，定时判断文件是否存在，这样子虽然不会损耗单次写入的性能，但是又多占用了一个线程资源，显然也不符合作者的需求。

其实Android已经给我们提供了这种场景的解决方案，那就是android.os.MessageQueue.IdleHandler，关于IdleHandler这里就不展开讨论了，简单来说就是当你注册一个IdleHandler后，它会在主线程空闲的时候被执行。

我们可以在每次写入日志之后注册IdleHandler，等IdleHandler被执行的时候检查一下日志文件是否存在，如果不存在就关闭输出流，这样子在下一次写入的时候就会重新创建文件写入了。

这里要注意每次写入日志之后注册IdleHandler，并不是每次都创建新对象，要判断一下如果原先的对象还未执行的话就不用注册一个新的IdleHandler，库中大概的代码如下：

private class LogFileChecker(private val block: () -> Unit) {

    private var _idleHandler: IdleHandler? = null



    fun register(): Boolean {

        // 如果当前线程没有Looper则不注册，上层逻辑可以直接检查文件是否存在，因为是非主线程

        Looper.myLooper() ?: return false

        

        // 如果已经注册过了，直接返回

        _idleHandler?.let { return true }

        

        val idleHandler = IdleHandler {

            // 执行block检查任务

            libTryRun { block() }

            

            // 重置变量，等待下次注册

            _idleHandler = null

            false

        }

        

        // 保存并注册idleHandler

        _idleHandler = idleHandler

        Looper.myQueue().addIdleHandler(idleHandler)

        return true

    }

}

这样子文件被意外删除之后，就可以重新创建写入了，避免丢失大量的日志。

问题：如何检测文件大小是否溢出

库支持对每天的日志大小做限制，例如限制每天最多只能写入10MB，每次写入日志之后都会检查日志大小是否超过限制，通常我们会调用java.io.File.length()方法获取文件的大小，但是它也比较耗性能，我们来做一个测试：

val file = filesDir.resolve("log.txt").apply {

    this.writeText("hello")

}

measureTime {

    repeat(1_0000) {

        file.length()

    }

}.let {

    Log.i("MainActivity", "time:${it.inWholeMilliseconds}")

}

16:56:04.090 MainActivity            com.sd.demo.xlog                I  time:61

16:56:05.329 MainActivity            com.sd.demo.xlog                I  time:80

16:56:06.382 MainActivity            com.sd.demo.xlog                I  time:72

16:56:07.496 MainActivity            com.sd.demo.xlog                I  time:79

16:56:08.591 MainActivity            com.sd.demo.xlog                I  time:78

可以看到耗时在60毫秒左右，相当于上面测试中1次文件写入的耗时。

库中支持自定义日志存储，在日志存储接口中定义了size()方法，上层通过此方法来判断当前日志的大小。

如果开发者自定义了日志存储，避免在此方法中每次调用java.io.File.length()来返回日志大小，应该维护一个表示日志大小的变量，变量初始化的时候获取一下java.io.File.length()，后续通过写入的数量来增加这个变量的值，并在size()方法中返回。库中默认的日志存储实现类就是这样实现的，有兴趣的可以看这里

问题：文件大小溢出后怎么处理？

假设限制每天最多只能写入10MB，那超过10MB后如何处理？有同学说直接删掉或者清空文件，重新写入，这也是一种策略，但是会丢失之前的所有日志。

例如白天写了9.9MB，到晚上的时候写满10MB，清空之后，白天的日志都没了，这时候用户反馈白天遇到的一个bug，需要上传日志，那就芭比Q了。

有没有办法少丢失一些呢？可以把日志分多个文件存储，为了便于理解假设分为2个文件存储，一天10MB，那1个文件最多只能写入5MB。具体步骤如下：

1. 写入文件20231128.log


2. 20231128.log写满5MB的时候关闭输出流，并把它重命名为20231128.log.1

这时候继续写日志的话，发现20231128.log文件不存在就会创建，又跳到了步骤1，就这样一直重复1和2两个步骤，到晚上写满10MB的时候，至少还有5MB的日志内容保存在20231128.log.1文件中避免丢失全部的日志。

分的文件数量越多，保留的日志就越多，实际上就是拿出一部分空间当作中转区，满了就向后递增数字重命名备份。目前库中只分为2个文件存储，暂时不开放自定义文件数量。

问题：打印日志的性能

性能，是这个库最关心的问题，通常来说文件写入操作是性能开销的大头，目前是用java.io相关的api来实现的，怎样提高写入性能作者也一直在探索，在demo中提供了一个基于内存映射的日志存储方案，但是稳定性未经测试，后续测试通过后可能会转正。有兴趣的读者可以看看这里。

还有一个比较影响性能的就是日志的格式化，通常要把一个时间戳转为某个日期格式，大部分人都会用java.text.SimpleDateFormat来格式化，用它来格式化年:月:日的时候问题不大，但是如果要格式化时:分:秒.毫秒那它就比较耗性能，我们来做一个测试：

val format = SimpleDateFormat("HH:mm:ss.SSS")

val millis = System.currentTimeMillis()

measureTime {

    repeat(1_0000) {

        format.format(millis)

    }

}.let {

    Log.i("MainActivity", "time:${it.inWholeMilliseconds}")

}

16:05:26.920 MainActivity            com.sd.demo.xlog                I  time:245

16:05:27.586 MainActivity            com.sd.demo.xlog                I  time:227

16:05:28.324 MainActivity            com.sd.demo.xlog                I  time:212

16:05:29.370 MainActivity            com.sd.demo.xlog                I  time:217

16:05:30.157 MainActivity            com.sd.demo.xlog                I  time:193

可以看到1万次格式化耗时大概在200毫秒左右。

我们再用java.util.Calendar测试一下：

val calendar = Calendar.getInstance()

// 时间戳1

val millis1 = System.currentTimeMillis()

// 时间戳2

val millis2 = millis1 + 1000

// 切换时间戳标志

var flag = true

measureTime {

    repeat(1_0000) {

        calendar.timeInMillis = if (flag) millis1 else millis2

        calendar.run {

            "${get(Calendar.HOUR_OF_DAY)}:${get(Calendar.MINUTE)}:${get(Calendar.SECOND)}.${get(Calendar.MILLISECOND)}"

        }

        flag = !flag

    }

}.let {

    Log.i("MainActivity", "time:${it.inWholeMilliseconds}")

}

16:11:25.342 MainActivity            com.sd.demo.xlog                I  time:35

16:11:26.209 MainActivity            com.sd.demo.xlog                I  time:35

16:11:27.316 MainActivity            com.sd.demo.xlog                I  time:37

16:11:28.057 MainActivity            com.sd.demo.xlog                I  time:25

16:11:28.825 MainActivity            com.sd.demo.xlog                I  time:18

这里解释一下为什么要用两个时间戳，因为Calendar内部有缓存，如果用同一个时间戳测试的话，没办法评估它真正的性能，所以这里每次格式化之后就切换到另一个时间戳，避免缓存影响测试。

可以看到1万次的格式化耗时在30毫秒左右，差距很大。如果要自定义日志格式的话，建议用Calendar来格式化时间，有更好的方案欢迎和作者交流。

问题：日志的格式如何显示

手机的存储资源是宝贵的，如何定义日志格式也是一个比较重要的细节。

• 优化时间显示

目前库内部是以天为单位来命名日志文件的，例如：20231128.log，所以在格式化时间戳的时候只保留了时:分:秒.毫秒，避免冗余显示当天的日期。

• 优化日志等级显示

打印的时候提供了4个日志等级：Verbose, Debug, Info, Warning, Error，一般最常用的记录等级是Info，所以在格式化的时候如果等级是Info则不显示等级标志，规则如下：

private fun FLogLevel.displayName(): String {

    return when (this) {

        FLogLevel.Verbose -> "V"

        FLogLevel.Debug -> "D"

        FLogLevel.Warning -> "W"

        FLogLevel.Error -> "E"

        else -> ""

    }

}

• 优化日志标识显示

如果连续2条或多条日志都是同一个日志标识，那么就只有第1条日志会显示日志tag

• 优化线程ID显示

如果是主线程的话，不显示线程ID，只有非主线程才显示线程ID

经过上面的优化之后，日志打印的格式是这样的：

flogI { "1" }

flogI { "2" }

flogW { "3" }

flogI { "user debug" }

thread {

    flogI { "thread" }

}

19:19:43.961[AppLogger] 1

19:19:43.974 2

19:19:43.975[W] 3

19:19:43.976[UserLogger] user debug

19:19:43.977[12578] thread

API

这一节介绍一下库的API

常用方法

/**

 * 打开日志，文件保存目录：[Context.getFilesDir()]/flog，

 * 默认只打开文件日志，可以调用[FLog.enableConsoleLog()]方法开关控制台日志，

 */

FLog.open(

    context = this,

    

    //（必传参数）日志等级 All, Verbose, Debug, Info, Warning, Error

    level = FLogLevel.All,



    //（可选参数）限制每天日志文件大小(单位MB)，小于等于0表示不限制大小，默认100MB

    limitMBPerDay = 100,

    

    //（可选参数）自定义日志格式

    formatter = AppLogFormatter(),

    

    //（可选参数）自定义日志存储

    storeFactory = AppLogStoreFactory(),

)





// 是否打打印控制台日志

FLog.enableConsoleLog(false)





/**

 * 删除日志，参数saveDays表示要保留的日志天数，小于等于0表示删除全部日志，

 * 此处saveDays=1表示保留1天的日志，即保留当天的日志

 */

FLog.deleteLog(1)





// 关闭日志

FLog.close()

打印日志

interface AppLogger : FLogger

flogV { "Verbose" }

flogD { "Debug" }

flogI { "Info" }

flogW { "Warning" }

flogE { "Error" }



// 打印控制台日志，不会写入到文件中，不需要指定日志标识，tag：DebugLogger

fDebug { "console debug log" }

配置日志标识

可以通过FLog.config方法修改某个日志标识的配置信息，例如下面的代码：

FLog.config {

    // 修改日志等级

    this.level = FLogLevel.Debug



    // 修改tag

    this.tag = "AppLoggerAppLogger"

}

自定义日志格式

class AppLogFormatter : FLogFormatter {

    override fun format(record: FLogRecord): String {

        // 自定义日志格式

        return record.msg

    }

}

interface FLogRecord {

    /** 日志标识 */

    val logger: Class<out FLogger>



    /** 日志tag */

    val tag: String



    /** 日志内容 */

    val msg: String



    /** 日志等级 */

    val level: FLogLevel



    /** 日志生成的时间戳 */

    val millis: Long



    /** 日志是否在主线程生成 */

    val isMainThread: Boolean



    /** 日志生成的线程ID */

    val threadID: String

}

自定义日志存储

日志存储是通过FLogStore接口实现的，每一个FLogStore对象负责管理一个日志文件。
所以需要提供一个FLogStore.Factory工厂为每个日志文件提供FLogStore对象。

class AppLogStoreFactory : FLogStore.Factory {

    override fun create(file: File): FLogStore {

        return AppLogStore(file)

    }

}

class AppLogStore(file: File) : FLogStore {

    // 添加日志

    override fun append(log: String) {}



    // 返回当前日志的大小

    override fun size(): Long = 0



    // 关闭

    override fun close() {}

}

结束

库目前还处于alpha阶段，如果有开发者遇到问题了可以及时反馈给作者，最后感谢大家的阅读。

记录Android原生项目集成Flutter模块经验，其中不乏一些踩坑，也是几番查找资料之后才成功运用于实际开发。

主要为了记录，将使用简洁的描述。

Flutter开发环境

1. Flutter安装和环境配置

官方文档：flutter.cn/docs/get-st…

参照官方文档一步步按步骤即可

下载SDK->解压->配置PATH环境变量

其中配置PATH环境变量务必使其永久生效方式

2. AS安装flutter和dart插件

将 Flutter module 集成到 Android 项目

官方文档：flutter.cn/docs/add-to…

仍然主要是参照官方文档。

有分为使用AS集成和不使用AS集成，其中使用AS集成有AAR集成和使用模块源码集成两种方式。

• AAR 集成： AAR 机制可以为每个 Flutter 模块创建 Android AAR 作为依赖媒介。当你的宿主应用程序开发者不想安装 Flutter SDK 时，这是一个很好方案。但是每次修改都需要重新编译。


• 模块源码集成：直接将 Flutter 模块的源码作为子项目的依赖机制是一种便捷的一键式构建方案，但此时需要另外安装 Flutter SDK，这是目前 Android Studio IDE 插件使用的机制。

本文讲述的是使用模块源码集成的方式。

1.创建Flutter Module

使用File > New > New Flutter Project创建，选择Module，官方建议Flutter Module和Android项目在同一个目录下。

2. 配置Module

在Android项目的 settings.gradle中添加以下配置：flutter_module为创建的flutter module名称

// Include the host app project.

include ':app'                                    // assumed existing content

setBinding(new Binding([gradle: this]))                                // new

evaluate(new File(                                                     // new

    settingsDir.parentFile,                                            // new

    'flutter_module/.android/include_flutter.groovy'                   // new

))                                                                     // new

在应用中引入对 Flutter 模块的依赖：

dependencies {

    implementation project(':flutter')

}

3. 编译失败报错：Failed to apply plugin class 'FlutterPlugin'

gradle6.8后 在settings.gradle的dependencyResolutionManagement 下新增了如下配置：

repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)

RepositoriesMode配置在构建中仓库如何设置，总共有三种方式：

FAIL_ON_PROJECT_REPOS

表示如果工程单独设置了仓库，或工程的插件设置了仓库，构建就直接报错抛出异常

PREFER_PROJECT

表示如果工程单独设置了仓库，就优先使用工程配置的，忽略settings里面的

PREFER_SETTINGS

表述任何通过工程单独设置或插件设置的仓库，都会被忽略

settings.gradle里配置的是FAIL_ON_PROJECT_REPOS，Flutter插件又单独设置了repository，所以会构建报错，因此需要把FAIL_ON_PROJECT_REPOS改成PREFER_PROJECT。

因为gradle调整，Android仓库配置都在settings.gradle中，但是因为设置了PREFER_PROJECT，settings.gradle被忽略了，那该怎么解决呢？发现虽然project的gradle文件虽然调整了，但是依然可以跟之前一样配置仓库这些，于是在项目build.gradle中加上settings.gradle中的所有仓库，成功解决问题并编译安装成功。

allprojects{

    repositories {

        maven {

            url "https://plugins.gradle.org/m2/"

        }

        maven { url "https://s01.oss.sonatype.org/content/groups/public" }

        maven { url 'https://jitpack.io' }

        google()

        // 极光 fcm， 若不集成 FCM 通道，可直接跳过

        maven { url "https://maven.google.com" }

        maven {

            url 'https://artifact.bytedance.com/repository/pangle'

        }

    }

}

总结：需要先将settings.gradle中repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)替换为repositoriesMode.set(RepositoriesMode.PREFER_PROJECT)，
然后在项目build.gradle中添加settings.gradle中的所有仓库。

添加Flutter页面

官方文档：flutter.cn/docs/add-to…

Flutter 提供了 FlutterActivity，用于在 Android 应用内部展示一个 Flutter 的交互界面。需要在清单文件中注册FlutterActivity。

<activity

    android:name="io.flutter.embedding.android.FlutterActivity"

    android:screenOrientation="portrait"

    />

然后加载FlutterActivity

startActivity(

    FlutterActivity.createDefaultIntent(requireContext())

)

此外还有withNewEngine、withCachedEngine等多种加载方式，具体可见官方文档。

添加Flutter视图

官方文档：flutter.cn/docs/add-to…

参考官方demo：github.com/flutter/sam…

创建FlutterViewEngine用以管理FlutterView、FlutterEngine、Activity三者。
FlutterEngine用以执行dart执行器，"showCell"为dart中方法名，FlutterEngine和FlutterView attach之后，会将"showCell"中生成的ui绘制到FlutterView上。

val engine = FlutterEngine(BaseApplication.instance)

engine.dartExecutor.executeDartEntrypoint(

    DartExecutor.DartEntrypoint(

        FlutterInjector.instance().flutterLoader().findAppBundlePath(),

        "showCell"))

在原生页面里面添加FlutterView还是比较麻烦的，需要开发者自己管理FlutterView、FlutterEngine、Activity三者之间生命周期联系。

刚毕业时候年轻气盛，和邻居组的老板吵了几句。后来我晋升时，发现他是评委…… 曾经的我多么嚣张，现在的我就多么低调。

一路走来，磕磕绊绊，几年来，我总结了工作上的思考……

工作思考

代码编写和技术问题

当你写下一行代码前

当你设计一个接口时

近期写了一篇文章《# 美团三年，总结的10条血泪教训》，后台很多网友留言对我过往工作经历感兴趣，小红书也收到很多薯友关于职业选择的咨询，于是就有了这篇文章。希望能给正在求职或者想转型的朋友，带来一些帮助。

01 放弃腾讯加入国企

我是2015年硕士毕业，14年秋招时，面了6家公司，拿到了几个offer，包括腾讯和我后来入职的央企。

腾讯当时发offer的是SNG社交网络事业群（Social Network Gr0up，简称SNG），旗下主要产品是QQ和QQ音乐，在当时算是最核心的事业群之一。腾讯当时算是最炙手火热的大厂，类比于今日的字节。

能拿到offer，想想主要两个原因，一是我曾经在大连腾讯（全称是：腾讯无线大连大连研发中心，属于MIG事业群的一家子公司）实习了4个多月，对腾讯的企业文化还有内部协作模式非常了解；另外一点，要感谢我的导师，读研时参与的几个项目都非常有含金量，面试时也能很好地和面试官吹一吹。

拿到央企的offer倒是挺意外，央企是非常看重学校名气还有在校期间学习成绩的，在这两点上，我都不占优势。当时只是有面试的机会，经过一轮笔试和两轮面试，顺利拿到offer。很多学习成绩好，各种大奖拿到手软、一心奔着北京户口去的，反而止步二轮三轮。

所以，企业招聘，一定不是挑选最优秀的，而是选择最合适的，明白这个道理，在应聘的时候，就不会妄自菲薄，多去尝试，就有机会。

腾讯和央企这两个算是最好的offer，当时纠结到底选择哪一个。腾讯岗base深圳，央企base北京，所以，选择的核心，无非是选择未来在哪座城市发展。

在东北上学6.5年，喜欢上了北方的气候和文化，喜欢北方人的直接，也爱上了北方的包子和面条，最重要的，最好的一些朋友，都在北京和大连，所以，即便央企的薪资只有腾讯的一半，知名度也远远比不上腾讯， 但还是义无反顾的拒掉了腾讯offer。当时的出发点是，选择一个和自己有情感连接和认同感的城市，比一个完全陌生的城市，对我更重要。

人生每一个十字路口，都有很多不同的选择，遵从自己的内心很重要。

我很庆幸当时的选择。来北京的同一年，我的太太从南方另外一座城市出发，一路北上，拖着大大的行李箱，也开启了北漂。

我们2015年相识，18年正式确立关系，19年结婚，现在有一个2岁可爱的小朋友。

太太是我最好的朋友，是我的老师，也是对我人生影响最大的一个人，我们相互支持、陪伴、成长，一起经营我们的小家。

所以，人生中很多的相逢，也是冥冥中注定好的。

02 我为什么离开了国企

我加入的单位，是XX央企下的一个研究所，因为涉密原因，直接用SDT代替吧。

最初面试时，不知道SDT有多厉害，只知道福利待遇在各种研究所里还算可以，上班地点在朋友合租的房子附近，不用每天挤地铁。

入职后才知道，SDT的业务，基本属于行业垄断地位，唯一的竞争对手是中电科旗下的另一家研究所。

入职时的岗位应用软件开发岗，工作第一年，因为单位业务涉及全国各地，需要很多人做系统集成和技术支持，作为新人，首先得有奉献精神，很自然的被派到前线。有半年时间，一个人全国各地出差，涉及东北、华北、华南七省，最北去过黑龙江佳木斯，最南抵达海口。那是一段兴奋又略显孤单的时光。

国企出差时去过最远的地方

工作第二年，轮岗到另外一个部门，做嵌入式开发，接触到的业务，算是单位最核心业务了。

这一年，在技术上提升也非常快，从一个完全没有嵌入式经验的小白，到知道怎么和硬件交互，用C语言写上层应用，也在几个大的项目里，配合项目经理，做了很多项目管理的工作。

因为所从事的业务，关系到国家信息安全，工作的价值感也非常高，觉得自己直接在为国效力。

国企主要是项目制，项目周期长，大多数时候都不需要加班，按部就班的往前推进就行~因为没有明确的流程规范，很多时候，一个人要身兼数职，开发、测试、项目管理、各种类型的评审、打印材料…这些都要做，好处是，可以很好的培养综合能力，与之对应的，杂而不精。

程序员是一个特别讲究刻意练习的职业，在早期，深度比广度更重要。只有密集输出，成长才会快。我的室友安仔在一家私企做开发，经常跟我提spring、微服务、全栈、Native、H5这些概念，当时我听的一脸懵，莫非是国企的技术栈过于陈旧，跟不上主流软件开发了？那时候开始有了些危机感。

好在大多数时候不加班，下班后可以直接去五道口三联韬奋书店看书，或者跑步、游泳。这个时候慢慢建立起的运动和阅读的好习惯，一直持续至今。

工作第三年，完全适应了国企的节奏，也有了一些小成绩，但内心总觉得隐隐不安。常常问自己一个问题，我能在这里待一辈子吗？工作七八年后，最多跟我们现在的项目经理差不多，这是我想要的工作吗？为国家效力的情怀，能否支持我走得更远、更久？如果我在里面待了10年，有一天想出来，是否还能找到工作？

带着很多的疑问，还有对未来的不确定感，开始了探索之旅。也在合同结束前的几个月，尝试找工作。那时候，互联网还处在蓬勃发展期，华为还没被美国制裁，总共面了四五家公司，非常幸运拿到了华为和阿里的offer，最后选择了阿里。

03 在阿里的那些事

在阿里的两年多，算是快乐和痛苦并存吧。快乐源自于认知快速迭代，痛苦也源于此。

在阿里和国企的工作内容完全不一样，技术栈也完全不一样，前几个月，一边快速的学习各种新技术，学习大厂人的沟通模式，学习各种黑话，也要应对来自上级的压力，工作本身的压力，好在天性比较皮实，咬牙坚持着，化压力为动力，大半年的时间，慢慢缓了过来。

大厂的高压和竞争环境，迫使多数人放弃了真我，时刻要迎接战斗或者提防别人。人和人之间，也很难建立起真正的共情，这和在国企时大家相互帮助，共同把事做好，差别巨大。

阿里让我见识了真正的职场，也迫使我不断提升自己的专业性还有抗压能力，后面在美团的工作，相对来说，要轻松很多了。

阿里20周年年会现场

不断打破舒适圈，重塑自我的过程，并不轻松。

扛过去了，再回首，会发现那是自己成长最快的一段时光，想到的反而都是感激。

离开阿里有好几年了，偶尔还会和前同事聚一聚，当大家放下曾经的身份，回归到真我时，每个人其实都很可爱，喜怒哀乐、家长里短，都能聊一聊，阿里人还是非常有情怀的一群人。

04 尊重过去，努力面前

离开国企后，常常会有人问我后不后悔，最近两年，互联网增长见顶，内卷加剧，小红书或者微信里面，咨询我的，多数都是了解如何进国企。

那么，放弃一份直接效力国家、在行业有垄断地位的国企工作，我后悔了吗？

答案是：不后悔。

人生是一个漫长的过程，搞清楚自己想要什么非常重要，在我们年轻的时候，所有的探索都是值得的。

大多数像我一样的普通人，很难直接回答自己想要什么，更多时候，是通过不断的做除法，排除不适合自己、或者自己不想要的。在不断的尝试，不断深挖自己过程中， 渐渐找到自己的定位，翻越愚昧之巅，跨过绝望之谷，走上开悟之坡。

职业生涯是这样，寻找人生另一半也是这样，和错的人挥手告别，才能和对的人相逢。

05 关于求职的一点点想法

作为过来人，如果要结合自己的经历，给几点建议，我想是这三点：

Ⅰ.小事从脑，大事从心

在人生每一个大的决定面前，我们不需要做太多的理性分析，追随自己的内心吧，世界可能会欺骗你，但你的内心不会。做一个有情感、有血有肉的人，胜过成为一位精致的利己主义者。

Ⅱ.人生没有白走的路，每一步都算数

每一个选择，都会引领我们走上一段奇妙的路，无论起步时选择的是hard模式还是easy模式，我们都有机会在这个过程中，不断地丰富和完善自己。所以，不要后悔曾经做过的任何选择，不要否定自己，不要和自己对抗，人生没有白走的路，每一步都算数。

Ⅲ.谦卑+open+学会感激，成为更好的自己

一直觉得自己是一个天资平庸的人，在人生的赛场上，没有太大的竞争力，但在很多个关键节点上，都能得到一些人的帮助，我想这也跟最近十多年被训练出的心性有关吧：谦卑+open+学会感激。

谦卑就是当自己不会的时候，承认自己的不足。把姿态放得足够低，才有机会被抬高；

open就是不封闭自己，能听得进各种声音，也能接纳各种人和事，对任何选择都持开放的心态；

学会感激，这个就很直接了，当我们珍视身边人的帮助，愿意多说一句感谢时，帮助过我们的人，下一次还会再帮我们一次，人生之路也会越走越宽。

最后，如果你在求职和职业选择、职业转型上，有任何的困惑，都可以加我微信和我聊聊。如果只是对辉哥好奇，也可以围观我的朋友圈，辉哥会不定期分享职场、育儿、亲密关系、阅读相关的心得体会。

从 2023 年 11 月 27 日晚上 10 点左右截止 2023 年 11 月 28 日中午 12 点期间，滴滴打车 APP、小程序得常用功能终于相继恢复正常。放眼整个事件来看，滴滴打车得故障时间已然超过 12 个小时，整个事件放在 2023 年得互联网来看真是相当炸裂。

回顾昨晚，原本我在写下 降本增笑，滴滴打车也崩了 这篇文章后就入睡了，想着今天晚上滴滴得程序员可有得忙了。

没想到的是 28 号 7 点起来 9 点到公司发现滴滴打车 APP 昨晚出现的绝大部分故障任然还在，骑行功能无法使用、底部标签栏车主、领打车费等还是无法打开，查看微博，滴滴官方也是在 7 点 33 分左右对昨晚事故做出了第二次回应，

也就是说 28 号早高峰上班期间，全国上下不知有多少用户任然受到此次事故影响导致无法正常打车、骑行等。进一步也可能会导致这些用户的全勤不保。

心痛一波这些用户 ❤️‍。

我当时就在想，滴滴得程序员昨天晚上去干什么了？一晚上都修不完这些 bug？对于大厂的高级研发，架构师来说，线上系统发布出现问题时的回滚流程应该是一套很成熟的体系，但是万万没想到这个事故竟然能持续一晚上还没结束。

没想到 2023 年的互联网还有这么到超出我对大厂认知的事情在不断发生 😔。

事故影响最后一直持续到 28 号 12 点左右才相继结束。

那么这里面到底出了哪些问题？作为一个互联网从业者，我给大家分析一下这里面可能存在的原因。

事故分析

降本增效

一个词概括 2023 年的互联网行情就是 “降本增效” 。疫情三年可以说是导致本就难做的实体行业是难上加难，但确给互联网行业带来了一大波用户增长。可谁曾想到来都 2023 年初，互联网行业可以说是寸草不生，直接进入存量内卷时代，各家都不在出新产品，开始巩固护城河。

记得三年前阿里的市值巅峰是 8000 亿跌倒现在不到 2000 亿，想想这里面市值缩水了 4 倍，想想 8000 亿市值招了多少人，现在不到 2000 亿，那又需要裁多少人嘞？年初阿里裁撤 15000 人的消息还历历在目。虽然这里面有全球大环境、国家政策以及市场竞争多众多因素导致。但是裁员时，资本又不会管你一个普通底层干活的技术员工干了多少年，技术上做出了多少贡献，他只会看优化后的财务报表有多么好看。

回看滴滴这几年经历了什么，2021 年 6 月 30 日 滴滴是美国纳斯达克上市的，估值最高达到 800 亿美元，随后 2021 年 7 月 4 日，国家网信办发布公告称，“滴滴出行”APP 存在严重违法违规收集使用个人信息问题，依据相关法律规定，通知应用商店下架“滴滴出行”APP，滴滴宣布暂停新用户注册。2022 年 7 月 21 日滴滴被处以罚款 80.26 亿人民币，2023 年 1 月 16 日 滴滴宣布整改完毕，恢复新用户注册，整个事件才告一段落。

可以说滴滴也为自己的违法行为付出了代价，这里面滴滴为了能活下去裁撤了公司多少人员我们也不得而知。但是影响了滴滴打车系统的稳定性是肯定的，不然也不会有今天这件事情。

降本增效、降本增效，今年提到互联网企业就离不开这四个字。具体怎么执行嘞？

何为降本：裁掉底层干活的人，留下一堆中层领导，相信这是大部分互联网公司的降本举措。

何为增效：一个人干两个人的事情，这就是增效，相信这也是大部分互联网公司的增效举措。

试想一下，假如我是一个互联网大厂开发，周六领导开会整个部门被裁，周一上午 HR 宣读通知，下午要求走人，只留下我一人维护老系统。你说我咋接？这系统是整个部门同事多年以来共同合作开发维护，我也只是负责其中一个模块。现在要我接收全部，能不出问题吗？

OK，进一步来说，假如某个模块出问题了我找谁，或者谁担责，我只能向上反馈。领导一顿 PUA 教育，最后还是底层干活的我默默承受了一切。

结合滴滴崩溃这件事来说，会不会是某个人留下来的隐秘 bug 终于在 27 号晚 10 点爆发，而留下来的程序员不知道如何解决，而且当时半夜 12 点想要联系前同事，打不通电话是不是也有可能。这一切的结果叠加也就导致了滴滴此次事故持续事件超过了 12 个小时。

这个事情很难说，因为官方也不可能承认是裁员导致。

底层依赖更新出错

还记得语雀上次事故，事故原因就是运维工具升级报错导致。滴滴这一波会不会也是这个原因嘞？

想一想如果是应用层服务出错，线上环境针对应用服务都有完整的回滚措施。回滚操作一般不会超过 10 分钟，那么像滴滴这样的互联网大厂，就算线上服务真的很多，回滚也不可能超过一晚上 6 个小时吧。所以造成此次事故的元凶就不太可能是应用层服务。

那么造成这次事故的核心原因就只可能是一个平台已经使用了多年的底层依赖，而不凑巧的是昨天晚上某个运维升级了这个依赖导致平台应用服务全面崩溃。

想一想，在我这么多年的互联网从业经验中，一般公司只会针对线上环境针的应用服务做回滚举措。而运维负责的一些平台底层依赖，很少又回滚这一说吧。

所以这个原因是有可能的。

最后聊两句

分析到这里，这篇文章要将的内容也就讲完了，互联网大厂一直把高可用、异地多活、两地三中心这些词语挂在嘴边，但是 2023 年以来，阿里崩了、语雀崩了、滴滴也崩了，可以说互联网大厂 APP 或者服务崩了在今年已经成了一种常态。还是希望大家保持常态，大厂的 APP 也是无数人堆出来，是人就会犯错，习惯就好。

博君一笑

不过在我看了网友评论后，我又觉得合理起来，历来网友的想象力都比较丰富。

ModuleExpose

项目地址：github.com/JailedBird/…

序言

Android模块化必须要解决的问题是 如何实现模块间通信 ？而模块之间通信往往需要获取相同的实体类和接口，造成部分涉及模块通信的接口和实体类被迫下沉到基础模块，导致 基础模块代码膨胀、模块代码分散和不便维护等问题；

ModuleExpose方案使用模块暴露&依赖注入框架Hilt的方式，实现模块间通信：

• 使用模块暴露（模块api化）解决基础模块下沉问题


• 使用依赖注入框架Hilt实现基于接口的模块解耦方案

简介

ModuleExpose，是将module内部需要暴露的代码通过脚本自动暴露出来；不同于手动形式的接口下沉，ModuleExpose是直接将module中需要暴露的代码完整拷贝到module_expose模块，而module_expose模块的生成、拷贝和配置是由ModuleExpose脚本自动完成，并保证编译时两者代码的完全同步；

最终，工程中包含如下几类核心模块：

• 
  

  基础模块：基础代码封装，可供任何业务模块使用；

  
  


• 
  

  业务模块：包含业务功能，业务模块可以依赖基础模块，但无法依赖其他业务模块（避免循环依赖）；

  
  


• 
  

  暴露模块：由脚本基于业务模块或基础模块自动拷贝生成，业务模块可依赖其他暴露模块（通过compileOnly方式，只参与编译不参与打包），避免模块通信所需的接口、数据实体类下沉到基础模块，造成基础模块膨胀、业务模块核心类分散到基础模块等问题；

  
  

注意这种方案并非原创，原创出处如下：

思路原创：微信Android模块化架构重构实践

先寻找代码膨胀的原因。

翻开基础工程的代码，我们看到除了符合设计初衷的存储、网络等支持组件外，还有相当多的业务相关代码。这些代码是膨胀的来源。但代码怎么来的，非要放这？一切不合理皆有背后的逻辑。在之前的架构中，我们大量使用Event事件总线作为模块间通信的方式，也基本是唯一的方式。使用Event作为通信的媒介，自然要有定义它的地方，好让模块之间都能知道Event结构是怎样的。这时候基础工程好像就成了存放Event的唯一选择——Event定义被放在基础工程中；接着，遇到某个模块A想使用模块B的数据结构类，怎么办？把类下沉到基础工程；遇到模块A想用模块B的某个接口返回个数据，Event好像不太适合？那就把代码下沉到基础工程吧……

就这样越来越多的代码很“自然的”被下沉到基础工程中。

implementation工程提供逻辑的实现。api工程提供对外的接口和数据结构。library工程，则提供该模块的一些工具类。

项目原创: github/tyhjh/module_api

如果每次有一个模块要使用另一个模块的接口都把接口和相关文件放到公共模块里面，那么公共模块会越来越大，而且每个模块都依赖了公共模块，都依赖了一大堆可能不需要的东西；

所以我们可以提取出每个模块提供api的文件放到各种单独的模块里面；比如user模块，我们把公共模块里面的User和UserInfoService放到新的user-api模块里面，这样其他模块使用的时候可以单独依赖于这个专门提供接口的模块，以此解决公共模块膨胀的问题

本人工作：

• 使用kts和nio重写脚本，基于性能的考量，对暴露规则和生成方式进行改进；


• 将nowinandroid项目编译脚本系统、Ksp版本的Hilt依赖注入框架、示例工程三者结合起来，完善基于 模块暴露&依赖注入框架 的模块解耦示例工程；


• 将api改名expose（PS：因内部项目使用过之前的api方案，为避免冲突所以改名，也避免和大佬项目名字冲突😘 脚本中亦可自定义关键词）

术语说明：

• 部分博客中称这种方式为模块api化，我觉得这是合理的；本文的语境中的expose和api是等价的意思；

模块暴露

1、项目启用kts配置

因为脚本使用kts编写，因此需要在项目中启用kts配置；如因为gradle版本过低等原因导致无法接入kts，那应该是无法使用的；后续默认都开启kts，并使用kts语法脚本；

2、导入脚本到gradle目录&修改模板

请拷贝示例工程gradle/expose目录到个人项目gradle目录，拷贝后目录如下：

Path

ModuleExpose\gradle



gradle

│  libs.versions.toml

├─expose

│      build_gradle_template_android

│      build_gradle_template_java

│      build_gradle_template_expose

│      expose.gradle.kts

└─wrapper

        gradle-wrapper.jar

        gradle-wrapper.properties

其中：expose.gradle.kts是模块暴露的核心脚本，包含若干函数和配置参数；

其中：build_gradle_template_android和build_gradle_template_java脚本模板因项目不同而有所不同，需要自行根据项目修改，否则无法编译；

• 
  

  build_gradle_template_android，生成Android模块的脚本模板，注意高版本gradle必须配置namespace，因此最好保留如下的配置（细则见脚本如何处理的）：

  
  

  android {
  
      namespace = "%s"
  
  }
  
  

  
  


• 
  

  build_gradle_template_java， 生成Java模块的脚本模板，配置较为简单；

  
  


• 
  

  includeWithApi函数使用build_gradle_template_android模板生成Android Library模块

  
  


• 
  

  includeWithJavaApi函数使用build_gradle_template_java模板生成Java Library模块

  
  


• 
  

  build_gradle_template_expose，不同于build_gradle_template_android、build_gradle_template_java的模板形式的配置，使用includeWithApi、includeWithJavaApi时，会优先检查模块根目录是否存在build_gradle_template_expose，如果存在则优先、直接将build_gradle_template_expose内容拷贝到module_expose, 作为build.gradle.kts ！ 保留这个配置的原因在于：如果需要暴露的类，引用三方类如gson、但不便将三方库implementation到build_gradle_template_android，这会导致module_expose编译报错，因此为解决这样的问题，最好使用自定义module_expose脚本（拷贝module的配置、稍加修改即可）

  
  

  PS：注意这几个模板都是无后缀的，kts后缀文件会被IDE提示一大堆东西；

  
  

注意： Java模块编译更快，但是缺少Activity、Context等Android环境，请灵活使用；当然最灵活的方式是为每个module_expose单独配置build_gradle_template_expose （稍微麻烦一点）；另外，如果不用includeWithJavaApi，其实build_gradle_template_java也是不需要的；

3、settings.gradle.kts导入脚本函数

根目录settings.gradle.kts配置如下：

apply(from = "$rootDir/gradle/expose/expose.gradle.kts")

val includeWithApi: (projectPaths: String) -> Unit by extra

val includeWithJavaApi: (projectPaths: String) -> Unit by extra

（PS：只要正确启用kts，settings.gradle应该也是可以导入includeWithApi的，但是我没尝试；其次老项目针对ModuleExpose改造kts时，可以渐进式改造，即只改settings.gradle.kts即可）

4、模块配置

将需要暴露的模块，在settings.gradle.kts 使用includeWithApi（或includeWithJavaApi）导入；

includeWithApi(":feature:settings")

includeWithApi(":feature:search")

即可自动生成新模块 ${module_expose}；然后在模块源码目录下创建名为expose的目录，将需要暴露的文件放在expose目录下， expose目录下的文件即可在新模块中自动拷贝生成；

生成细则：

1、 模块支持多个expose目录（递归、含子目录）同时暴露，这可以避免将实体类，接口等全部放在单个expose，看着很乱

2、 expose内部的文件，默认全部复制，但脚本提供了开关，可以自行更改并配置基于文件名的拷贝过滤；

5、使用module_expose模块

请使用 compileOnly 导入项目，如下：

compileOnly(project(mapOf("path" to ":feature:search_expose")))

错误：会导致资源冲突

implementation(project(mapOf("path" to ":feature:search_expose")))

原理解释：compileOnly只参与编译，不会被打包；implementation参与编译和打包；

因此search_expose只能使用compileOnly导入，确保解耦的模块之间可以访问到类引用，但不会造成打包时2个类相同的冲突问题；

依赖注入

基于模块暴露的相关接口，可以使用依赖注入框架Hilt实现基于接口的解耦； 当然如果大家不使用Hilt技术栈的话，这节可以跳过；

本节内容会以业务模块search和settings为例，通过代码展示：

• search模块跳转到settings模块，打开SettingsActivity


• settings模块跳转到search模块，打开SearchActivity

PS：关于Hilt的配置和导入，本项目直接沿用nowinandroid工程中build-logic的配置，具体配置和使用请参考本项目和nowinandroid项目；

1、 基本配置&工程结构：

导入脚本之后，使用includeWithApi导入三个业务模块，各自生成对应的module_expose；

注意，请将*_expose/添加到gitignore，避免expose模块提交到git

2、 业务模块接口暴露&实现

settings模块expose目录下暴露SettingExpose接口， 脚本会自动将其同步拷贝到settings_expose中对应expose目录

exposeimpl/SettingExposeImpl实现SettingExpose接口的具体功能，完善跳转功能

class SettingExposeImpl @Inject constructor() : SettingExpose {

    override fun startSettingActivity(context: Context) {

        SettingsActivity.start(context)

    }

}

3、 Hilt添加注入接口绑定

使用Hilt绑定全局单例SettingExpose接口实现，其对应实现为SettingExposeImpl

4、 search模块compileOnly导入settings_expose

compileOnly(projects.feature.settingsExpose)

注意，模块暴露依赖只能使用compileOnly，保证编译时候能找到对应文件即可；另外projects.feature.settingsExpose这种项目导入方式，需要在settings.gradle.kts启用project类型安全配置；

 enableFeaturePreview("TYPESAFE_PROJECT_ACCESSORS")

5、 search注入并使用SettingExpose

@AndroidEntryPoint

class SearchActivity : AppCompatActivity() {

    @Inject

    lateinit var settingExpose: SettingExpose

    

    private val listener = object : AppSettingsPopWindow.Listener {



        override fun settings() {

            settingExpose.startSettingActivity(this@SearchActivity)

        }

    }

}

6、 实现解耦

最终实现【search模块跳转到settings模块，打开SettingsActivity】， 至于【settings模块跳转到search模块，打开SearchActivity】的操作完全一致，不重复叙述了；

参考资料

1、思路原创：微信Android模块化架构重构实践

2、项目原创：github/tyhjh/module_api

3、脚本迁移：将 build 配置从 Groovy 迁移到 KTS

4、参考文章：Android模块化设计方案之接口API化

5、Nowinandroid：github.com/android/now…

6、Dagger项目：github.com/google/dagg…

7、Hilt官方教程：developer.android.com/training/de…

大家好，这里是大家的林语冰。

免责声明

本文属于是语冰的直男翻译了属于是，仅供粉丝参考，英文原味版请临幸 The 10 Most Common JavaScript Issues Developers Face。

今时今日，JS（JavaScript）几乎是所有现代 Web App 的核心。这就是为什么 JS 出问题，以及找到导致这些问题的错误，是 Web 开发者的最前线。

用于 SPA（单页应用程序）开发、图形和动画以及服务器端 JS 平台的给力的 JS 库和框架不足为奇。JS 在 Web App 开发领域早已无处不在，因此是一项越来越需要加点的技能树。

乍一看，JS 可能很简单。事实上，对于任何有经验的软件开发者而言，哪怕它们是 JS 初学者，将基本的 JS 功能构建到网页中也是举手之劳。

虽然但是，这种语言比大家起初认为的要更微妙、给力和复杂。事实上，一大坨 JS 的微妙之处可能导致一大坨常见问题，无法正常工作 —— 我们此处会讨论其中的 10 个问题。在成为 JS 大神的过程中，了解并避免这些问题十分重要。

问题 1：this 引用失真

JS 开发者对 JS 的 this 关键字不乏困惑。

多年来，随着 JS 编码技术和设计模式越来越复杂，回调和闭包中自引用作用域的延伸也同比增加，此乃导致 JS “this 混淆”问题的“万恶之源”。

请瞄一眼下述代码片段：

const Game = function () {

  this.clearLocalStorage = function () {

    console.log('Clearing local storage...')

  }

  this.clearBoard = function () {

    console.log('Clearing board...')

  }

}



Game.prototype.restart = function () {

  this.clearLocalStorage()

  this.timer = setTimeout(function () {

    this.clearBoard() // this 是什么鬼物？

  }, 0)

}



const myGame = new Game()

myGame.restart()

执行上述代码会导致以下错误：

未捕获的类型错误: this.clearBoard 不是函数

为什么呢？这与上下文有关。出现该错误的原因是，当您执行 setTimeout() 时，您实际是在执行 window.setTimeout()。因此，传递给 setTimeout() 的匿名函数定义在 window 对象的上下文中，该对象没有 clearBoard() 方法。

一个传统的、兼容旧浏览器的技术方案是简单地将您的 this 引用保存在一个变量中，然后可以由闭包继承，举个栗子：

Game.prototype.restart = function () {

  this.clearLocalStorage()

  const self = this // 当 this 还是 this 的时候，保存 this 引用！

  this.timer = setTimeout(function () {

    self.clearBoard() // OK，我们可以知道 self 是什么了！

  }, 0)

}

或者，在较新的浏览器中，您可以使用 bind() 方法传入正确的引用：

Game.prototype.restart = function () {

  this.clearLocalStorage()

  this.timer = setTimeout(this.reset.bind(this), 0) // 绑定 this

}



Game.prototype.reset = function () {

  this.clearBoard() // OK，回退到正确 this 的上下文！

}

问题 2：认为存在块级作用域

JS 开发者之间混淆的“万恶之源”之一（因此也是 bug 的常见来源）是，假设 JS 为每个代码块创建新的作用域。尽管这在许多其他语言中是正确的，但在 JS 中却并非如此。举个栗子，请瞄一眼下述代码：

for (var i = 0; i < 10; i++) {

  /* ... */

}

console.log(i) // 输出是什么鬼物？

如果您猜到调用 console.log() 会输出 undefined 或报错，那么恭喜您猜错了。信不信由你，它会输出 10。为什么呢？

在大多数其他语言中，上述代码会导致错误，因为变量 i 的“生命”（即作用域）将被限制在 for 区块中。虽然但是，在 JS 中，情况并非如此，即使在循环完成后，变量 i 仍保留在范围内，在退出 for 循环后保留其最终值。（此行为被称为变量提升。）

JS 对块级作用域的支持可通过 let 关键字获得。多年来，let 关键字一直受到浏览器和后端 JS 引擎（比如 Node.js）的广泛支持。如果这对您来说是新知识，那么值得花时间阅读作用域、原型等。

问题3：创建内存泄漏

如果您没有刻意编码来避免内存泄漏，那么内存泄漏几乎不可避免。它们有一大坨触发方式，因此我们只强调其中两种更常见的情况。

示例 1：失效对象的虚空引用

注意：此示例仅适用于旧版 JS 引擎，新型 JS 引擎具有足够机智的垃圾回收器（GC）来处理这种情况。

请瞄一眼下述代码：

var theThing = null

var replaceThing = function () {

  var priorThing = theThing // 保留之前的东东

  var unused = function () {

    // unused 是唯一引用 priorThing 的地方，

    // 但 unused 从未执行

    if (priorThing) {

      console.log('hi')

    }

  }

  theThing = {

    longStr: new Array(1000000).join('*'), // 创建一个 1MB 的对象

    someMethod: function () {

      console.log(someMessage)

    }

  }

}

setInterval(replaceThing, 1000) // 每秒执行一次 replaceThing

如果您运行上述代码并监视内存使用情况，就会发现严重的内存泄漏 —— 每秒有一整兆字节！即使是手动垃圾收集器也无济于事。所以看起来每次调用 replaceThing 时我们都在泄漏 longSte。但是为什么呢？

如果您没有刻意编码来避免内存泄漏，那么内存泄漏几乎不可避免。

让我们更详细地检查一下：

每个 theThing 对象都包含自己的 1MB longStr 对象。每一秒，当我们调用 replaceThing 时，它都会保留 priorThing 中之前的 theThing 对象的引用。但我们仍然不认为这是一个问题，因为每次先前引用的 priorThing 都会被取消引用（当 priorThing 通过 priorThing = theThing; 重置时）。此外，它仅在 replaceThing 的主体中和 unused 函数中被引用，这实际上从未使用过。

因此，我们再次想知道为什么这里存在内存泄漏。

要了解发生了什么事，我们需要更好地理解 JS 的内部工作原理。闭包通常由链接到表示其词法作用域的字典风格对象（dictionary-style）的每个函数对象实现。如果 replaceThing 内部定义的两个函数实际使用了 priorThing，那么它们都得到相同的对象是很重要的，即使 priorThing 逐次赋值，两个函数也共享相同的词法环境。但是，一旦任何闭包使用了变量，它就会进入该作用域中所有闭包共享的词法环境中。而这个小小的细微差别就是导致这种粗糙的内存泄漏的原因。

示例 2：循环引用

请瞄一眼下述代码片段：

function addClickHandler(element) {

  element.click = function onClick(e) {

    alert('Clicked the ' + element.nodeName)

  }

}

此处，onClick 有一个闭包，它保留了 element 的引用（通过 element.nodeName）。通过同时将 onClick 赋值给 element.click，就创建了循环引用，即 element -> onClick -> element -> onClick -> element ......

有趣的是，即使 element 从 DOM 中删除，上述循环自引用也会阻止 element 和 onClick 被回收，从而造成内存泄漏。

避免内存泄漏：要点

JS 的内存管理（尤其是它的垃圾回收）很大程度上基于对象可达性（reachability）的概念。

假定以下对象是可达的，称为“根”：

• 从当前调用堆栈中的任意位置引用的对象（即，当前正在执行的函数中的所有局部变量和参数，以及闭包作用域中的所有变量）


• 所有全局变量

只要对象可以通过引用或引用链从任何根访问，那么它们至少会保留在内存中。

浏览器中有一个垃圾回收器，用于清理不可达对象占用的内存；换而言之，当且仅当 GC 认为对象不可达时，才会从内存中删除对象。不幸的是，很容易得到已失效的“僵尸”对象，这些对象不再使用，但 GC 仍然认为它们可达。

问题 4：混淆相等性

JS 的便捷性之一是，它会自动将布尔上下文中引用的任何值强制转换为布尔值。但在某些情况下，这可能既香又臭。

举个栗子，对于一大坨 JS 开发者而言，下列表达式很头大：

// 求值结果均为 true！

console.log(false == '0');

console.log(null == undefined);

console.log(" \t\r\n" == 0);

console.log('' == 0);



// 这些也是 true！

if ({}) // ...

if ([]) // ...

关于最后两个，尽管是空的（这可能会让您相信它们求值为 false），但 {} 和 [] 实际上都是对象，并且 JS 中任何对象都将被强制转换为 true，这与 ECMA-262 规范一致。

正如这些例子所表明的，强制类型转换的规则有时可以像泥巴一样清晰。因此，除非明确需要强制类型转换，否则通常最好使用 === 和 !==（而不是 == 和 !=）以避免强制类型转换的任何意外副作用。（== 和 != 比较两个东东时会自动执行类型转换，而 === 和 !== 在不进行类型转换的情况下执行同款比较。）

由于我们谈论的是强制类型转换和比较，因此值得一提的是，NaN 与任何事物（甚至 NaN 自己！）进行比较始终会返回 false。因此您不能使用相等运算符（ ==，===，!=，!==）来确定值是否为 NaN。请改用内置的全局 isNaN() 函数：

console.log(NaN == NaN) // False

console.log(NaN === NaN) // False

console.log(isNaN(NaN)) // True

问题 5：低效的 DOM 操作

JS 使得操作 DOM 相对容易（即添加、修改和删除元素），但对提高操作效率没有任何作用。

一个常见的示例是一次添加一个 DOM 元素的代码。添加 DOM 元素是一项代价昂贵的操作，连续添加多个 DOM 元素的代码效率低下，并且可能无法正常工作。

当需要添加多个 DOM 元素时，一个有效的替代方案是改用文档片段（document fragments），这能提高效率和性能。

举个栗子：

const div = document.getElementById('my_div')

const fragment = document.createDocumentFragment()

const elems = document.querySelectorAll('a')



for (let e = 0; e < elems.length; e++) {

  fragment.appendChild(elems[e])

}

div.appendChild(fragment.cloneNode(true))

除了这种方法固有的提高效率之外，创建附加的 DOM 元素代价昂贵，而在分离时创建和修改它们，然后附加它们会产生更好的性能。

问题 6：在 for 循环中错误使用函数定义

请瞄一眼下述代码：

var elements = document.getElementsByTagName('input')

var n = elements.length // 我们假设本例有 10 个元素

for (var i = 0; i < n; i++) {

  elements[i].onclick = function () {

    console.log('This is element #' + i)

  }

}

根据上述代码，如果有 10 个输入元素，单击其中任何一个都会显示“This is element #10”！这是因为，在为任何元素调用 onclick 时，上述 for 循环将完成，并且 i 的值已经是 10（对于所有元素）。

以下是我们如何纠正此问题，实现所需的行为：

var elements = document.getElementsByTagName('input')

var n = elements.length // 我们假设本例有 10 个元素

var makeHandler = function (num) {

  // 外部函数

  return function () {

    // 内部函数

    console.log('This is element #' + num)

  }

}

for (var i = 0; i < n; i++) {

  elements[i].onclick = makeHandler(i + 1)

}

在这个修订版代码中，每次我们通过循环时，makeHandler 都会立即执行，每次都会接收当时 i + 1 的值并将其绑定到作用域的 num 变量。外部函数返回内部函数（也使用此作用域的 num 变量），元素的 onclick 会设置为该内部函数。这确保每个 onclick 接收和使用正确的 i 值（通过作用域的 num 变量）。

问题 7：误用原型式继承

令人惊讶的是，一大坨 JS 爱好者无法完全理解和充分利用原型式继承的特性。

下面是一个简单的示例：

BaseObject = function (name) {

  if (typeof name !== 'undefined') {

    this.name = name

  } else {

    this.name = 'default'

  }

}

这似乎一目了然。如果您提供一个名称，请使用该名称，否则将名称设置为“default”。举个栗子：

var firstObj = new BaseObject()

var secondObj = new BaseObject('unique')



console.log(firstObj.name) // -> 结果是 'default'

console.log(secondObj.name) // -> 结果是 'unique'

但是，如果我们这样做呢：

delete secondObj.name

然后我们会得到：

console.log(secondObj.name) // -> 结果是 'undefined'

骚然但是，将其恢复为“default”不是更好吗？如果我们修改原始代码以利用原型式继承，这很容易实现，如下所示：

BaseObject = function (name) {

  if (typeof name !== 'undefined') {

    this.name = name

  }

}



BaseObject.prototype.name = 'default'

在此版本中，BaseObject 从其 prototype 对象继承该 name 属性，其中该属性（默认）设置为 'default'。因此，如果调用构造函数时没有名称，那么名称将默认为 default。同样，如果从 BaseObject 的实例删除该 name 属性，那么会搜索原型链，并从 prototype 对象中检索值仍为 'default' 的 name 属性。所以现在我们得到：

var thirdObj = new BaseObject('unique')

console.log(thirdObj.name) // -> 结果是 'unique'



delete thirdObj.name

console.log(thirdObj.name) // -> 结果是 'default'

问题 8：创建对实例方法的错误引用

让我们定义一个简单对象，并创建它的实例，如下所示：

var MyObjectFactory = function () {}



MyObjectFactory.prototype.whoAmI = function () {

  console.log(this)

}



var obj = new MyObjectFactory()

现在，为了方便起见，让我们创建一个 whoAmI 方法的引用，大概这样我们就可以通过 whoAmI() 访问它，而不是更长的 obj.whoAmI()：

var whoAmI = obj.whoAmI

为了确保我们存储了函数的引用，让我们打印出新 whoAmI 变量的值：

console.log(whoAmI)

输出：

function () {

    console.log(this);

}

目前它看起来不错。

但是瞄一眼我们调用 obj.whoAmI() 与便利引用 whoAmI() 时的区别：

obj.whoAmI() // 输出 "MyObjectFactory {...}" （预期）

whoAmI() // 输出 "window" （啊这！）

哪里出了问题？我们的 whoAmI() 调用位于全局命名空间中，因此 this 设置为 window（或在严格模式下设置为 undefined），而不是 MyObjectFactory 的 obj 实例！换而言之，该 this 值通常取决于调用上下文。

箭头函数（(params) => {} 而不是 function(params) {}）提供了静态 this，与常规函数基于调用上下文的 this 不同。这为我们提供了一个技术方案：

var MyFactoryWithStaticThis = function () {

  this.whoAmI = () => {

    // 请注意此处的箭头符号

    console.log(this)

  }

}



var objWithStaticThis = new MyFactoryWithStaticThis()

var whoAmIWithStaticThis = objWithStaticThis.whoAmI



objWithStaticThis.whoAmI() // 输出 "MyFactoryWithStaticThis" （同往常一样）

whoAmIWithStaticThis() // 输出 "MyFactoryWithStaticThis" （箭头符号的福利）

您可能已经注意到，即使我们得到了匹配的输出，this 也是对工厂的引用，而不是对实例的引用。与其试图进一步解决此问题，不如考虑根本不依赖 this（甚至不依赖 new）的 JS 方法。

问题 9：提供一个字符串作为 setTimeout or setInterval 的首参

首先，让我们在这里明确一点：提供字符串作为首个参数给 setTimeout 或者 setInterval 本身并不是一个错误。这是完全合法的 JS 代码。这里的问题更多的是性能和效率。经常被忽视的是，如果将字符串作为首个参数传递给 setTimeout 或 setInterval，它将被传递给函数构造函数以转换为新函数。这个过程可能缓慢且效率低下，而且通常非必要。

将字符串作为首个参数传递给这些方法的替代方法是传入函数。让我们举个栗子。

因此，这里将是 setInterval 和 setTimeout 的经典用法，将字符串作为首个参数传递：

setInterval('logTime()', 1000)

setTimeout("logMessage('" + msgValue + "')", 1000)

更好的选择是传入一个函数作为初始参数，举个栗子：

setInterval(logTime, 1000) // 将 logTime 函数传给 setInterval



setTimeout(function () {

  // 将匿名函数传给 setTimeout

  logMessage(msgValue) // （msgValue 在此作用域中仍可访问）

}, 1000)

问题 10：禁用“严格模式”

“严格模式”（即在 JS 源文件的开头包含 'use strict';）是一种在运行时自愿对 JS 代码强制执行更严格的解析和错误处理的方法，也是一种使代码更安全的方法。

诚然，禁用严格模式并不是真正的“错误”，但它的使用越来越受到鼓励，省略它越来越被认为是不好的形式。

以下是严格模式的若干主要福利：

• 更易于调试。本来会被忽略或静默失败的代码错误现在将生成错误或抛出异常，更快地提醒您代码库中的 JS 问题，并更快地将您定位到其源代码。


• 防止意外全局变量。如果没有严格模式，将值赋值给给未声明的变量会自动创建同名全局变量。这是最常见的 JS 错误之一。在严格模式下，尝试这样做会引发错误。


• 消除 this 强制类型转换。如果没有严格模式，对 null 或 undefined 值的 this 引用会自动强制转换到 globalThis 变量。这可能会导致一大坨令人沮丧的 bug。在严格模式下，null 或 undefined 值的 this 引用会抛出错误。


• 禁止重复的属性名或参数值。严格模式在检测到对象中的重名属性（比如 var object = {foo: "bar", foo: "baz"};）或函数的重名参数（比如 function foo(val1, val2, val1){}）时会抛出错误，从而捕获代码中几乎必然出错的 bug，否则您可能会浪费大量时间进行跟踪。


• 更安全的 eval()。严格模式和非严格模式下 eval() 的行为存在某些差异。最重要的是，在严格模式下，eval() 语句中声明的变量和函数不会在其包裹的作用域中创建。（它们在非严格模式下是在其包裹的作用域中创建的，这也可能是 JS 问题的常见来源。）


• delete 无效使用时抛出错误。delete 运算符（用于删除对象属性）不能用于对象的不可配置属性。当尝试删除不可配置属性时，非严格代码将静默失败，而在这种情况下，严格模式将抛出错误。

使用更智能的方法缓解 JS 问题

与任何技术一样，您越能理解 JS 奏效和失效的原因和方式，您的代码就会越可靠，您就越能有效地利用语言的真正力量。

相反，缺乏 JS 范式和概念的正确理解是许多 JS 问题所在。彻底熟悉语言的细微差别和微妙之处是提高熟练度和生产力的最有效策略。

您现在收看的是前端翻译计划，学废了的小伙伴可以订阅此专栏合集，我们每天佛系投稿，欢迎持续关注前端生态。谢谢大家的点赞，掰掰~

作者简介：徐卓毅Joe，来自货拉拉/技术中心/质量保障部，专注于移动测试效能方向。

一、背景与目标

近些年货拉拉的业务持续高速发展，为了满足业务更短周期、更高质量交付的诉求，从今年开始我们的移动App的迭代交付模型也从双周演化为单周。因此，在一周一版的紧张节奏下，随之而来的对测试质量保障的挑战也日益增加，首当其冲要解决的就是如何降低移动App每周版本回归测试的人力投入。

早期我们尝试过基于Appium框架编写UI自动化测试脚本，并且为了降低编写难度，我们也基于Appium框架进行了二次开发，但实践起来依然困难重重，主要原因在于：

1. 
   

   上手和维护成本高

   
   
   
   
   • 需要掌握一定基础知识才能编写脚本和排查过程中遇到的问题；
   
   
   • 脚本编写+调试耗时长，涉及的元素定位+操作较多，调试要等待脚本执行回放才能看到结果；
   
   
   • 排查成本高，由于UI自动化测试的稳定性低，需投入排查的脚本较多，耗时长；
   
   
   • 维护成本高，每个迭代的需求改动都可能导致页面元素或链路调整，需不定期维护；
   
   
   
   


2. 
   

   测试脚本稳定性低

   
   
   
   
   • 容易受多种因素（服务端环境、手机环境等）影响，这也造成了问题排查和溯源困难；
   
   
   • 脚本本身的稳定性低，模拟手工操作的方式，但实际操作点击没有那么智能；
     
     
     
     • 脚本识别元素在不同分辨率、不同系统版本上，识别的速度及准确度不同；
     
     
     • 不同设备在某些操作上表现，例如缩放（缩放多少）、滑动（滑动多少）有区别；
     
     
     • 由于功能复杂性、不同玩法的打断（如广告、弹窗、ab实验等）；
     
     
     
     
   
   
   
   

所以，在App UI自动化测试上摸爬滚打一段时间后，我们积累了大量的踩坑经验。但这些经验也让我们更加明白，如果要大规模推行App UI自动化测试，必须要提高自动化ROI，否则很难达到预期效果，成本收益得不偿失。

我们的目标是打造一个低成本、高可用的App UI自动化测试平台。它需要满足如下条件：

1. 更低的技术门槛：上手简单，无需环境配置；


2. 更快的编写速度：无需查找控件，手机上操作后就能生成一条可执行的测试脚本；


3. 更小的维护成本： 支持图像识别，减少由于控件改动导致的问题；


4. 更高的稳定性： 回放识别通过率高，降低环境、弹窗的影响；


5. 更好的平台功能： 支持脚本管理、设备调度、测试报告等能力，提升执行效率，降低排查成本；

二、行业方案

考虑到自动化ROI，我们基本确定要使用基于录制回放方式的自动化方案，所以我们也调研了美团、爱奇艺、字节、网易这几个公司的测试工具平台的实现方案：

1. 网易Airtest是唯一对外发布的工具，但免费版本是IDE编写的，如果是小团队使用该IDE录制UI脚本来说还是比较方便的，但对于多团队协同，以及大规模UI自动化的实施的需求来说，其脚本管理、设备调度、实时报告等平台化功能的支持还不满足。


2. 美团AlphaTest上使用的是App集成SDK的方式，可以通过底层Hook能力采集到操作数据、网络数据等更为详尽的内容，也提供了API支持业务方自定义实现，如果采用这种方案，移动研发团队的配合是很重要的。


3. 爱奇艺的方案是在云真机的基础上，使用云IDE的方式进行录制，重点集成了脚本管理、设备调度、实时报告等平台化功能，这种方案的优势在于免去开发SDK的投入，可以做成通用能力服务于各业务App。


4. 字节SmartEye也是采用集成SDK的方式，其工具本身更聚焦精准测试的能力建设，而精准测试当前货拉拉也在深入实践中，后续有机会我们再详细介绍。

综上分析，如果要继续推行App UI自动化测试，我们也需要自研测试平台，最好是能结合货拉拉现有的业务形态和能力优势，用最低的自研方案成本，快速搭建起适合我们的App录制回放测试平台，这样就能更快推动实践，降低业务测试当前面临的稳定性保障的压力。

三、能力建设

货拉拉现有的能力优势主要有：

1. 货拉拉的云真机建设上已有成熟的经验（感兴趣的读者可参见文章《货拉拉云真机平台的演进与实践》）；


2. 货拉拉在移动App质效上已有深入实践，其移动云测平台已沉淀了多维度的自动化测试服务（如性能、兼容性、稳定性、健壮性、遍历、埋点等），具备比较成熟的平台能力。

因此，结合多方因素，最终我们选择了基于云真机开展App UI录制回放的方案，在借鉴其他公司优秀经验的基础上，结合我们对App UI自动化测试过程中积累的宝贵经验，打造了货拉拉App云录制回放测试平台。

下面我们会按录制能力、回放能力、平台能力三大部分进行介绍。

3.1 录制能力

录制流程从云真机的操作事件开始，根据里面的截图和操作坐标解析操作的控件，最终将操作转化为脚本里的单个步骤。并且支持Android和iOS双端，操作数据上报都是用旁路上报的方式，不会阻塞在手机上的操作。

下面是我们当前基于云真机录制的效果：

  在录制的过程中，其目标主要有：

1. 取到当前操作的类型 ： 点击、长按、输入、滑动等；


2. 取到操作的目标控件 ： 按钮、标签栏、文本框等；

3.1.1 云真机旁路上报&事件解析

  首先要能感知到用户在手机上做了什么操作，当我们在页面上使用云真机时，云真机后台可以监控到最原始的屏幕数据，不同操作的数据流如下：

// 点击

d 0 10 10 50

c

u 0

c

// 长按

d 0 10 10 50

c

<wait in your own code>

u 0

c

// 滑动

d 0 0 0 50

c

<wait in your own code>  //需要拖拽加上等待时间

m 0 20 0 50

c

m 0 40 0 50

c

m 0 60 0 50

c

m 0 80 0 50

c

m 0 100 0 50

c

u 0

c

  根据协议我们可以判断每次操作的类型以及坐标，但仅依赖坐标的录制并不灵活，也不能实现例如断言一类的操作，所以拿到控件信息也非常关键。

  一般UI自动化中会dump出控件树，通过控件ID或层级关系定位控件。而dump控件树是一个颇为耗时的动作，普通布局的页面也需要2S左右。

  如果在录制中同时dump控件树，那我们每点击都要等待进度条转完，显然这不是我们想要的体验。而可以和操作坐标一起拿到的还有手机画面的视频流，虽然单纯的截图没有控件信息，但假如截图可以像控件树一样拆分出独立的控件区域，我们就可以结合操作坐标匹配对应控件。

3.1.2 控件/文本检测

  控件区域检测正是深度学习中的目标检测能解决的问题。

  这里我们先简单看一下深度学习的原理以及在目标检测过程中做了什么。

  深度学习原理

深度学习使用了一种被称为神经网络的结构。像人脑中的神经元一样，神经网络中的节点会对输入数据进行处理，然后将结果传递到下一个层级。这种逐层传递和处理数据的方式使得深度学习能够自动学习数据的复杂结构和模式。

  总的来说，深度学习网络逐层提取输入的特征，总结成更抽象的特征，将学习到的知识作为权重保存到网络中。

举个例子，如果我们使用深度学习来学习识别猫的图片，那么神经网络可能会在第一层学习识别图片中的颜色或边缘，第二层可能会识别出特定的形状或模式，第三层可能会识别出猫的某些特征，如猫的眼睛或耳朵，最后，网络会综合所有的特征来确定这张图片是否是猫。

  目标检测任务

  目标检测是深度学习中的常见任务，任务的目标是在图像中识别并定位特定物体。

  在我们的应用场景中，任务的目标自然是UI控件：

1. 识别出按钮、文本框等控件，可以归类为图标、图片和文本；


2. 圈定控件的边界范围；

这里我们选用知名的YOLOX目标检测框架，社区里也开放许多了以UI为目标的预训练模型和数据集，因为除了自动化测试外，还有通过UI设计稿生成前端代码等应用场景。

  下图是使用公开数据集直接推理得到的控件区域，可以看出召回率不高。这是因为公开数据集中国外APP标注数据更多，且APP的UI风格不相似。

示例一	示例二

预训练和微调模型

  而最终推理效果依赖数据集质量，这需要我们微调模型。由于目标数据集相似，所以我们只需要在预训练模型基础时，冻结骨干网络，重置最后输出层权重，喂入货拉拉风格的UI数据继续训练，可以得到更适用的模型。

model = dict (backbone=dict (frozen_stages=1 # 表示第一层 stage 以及它之前的所有 stage 中的参数都会被冻结 )) 

通过目标检测任务，我们可以拿到图标类的控件，控件的截图可以作为标识存储。当然，文本类的控件还是转化成文本存储更理想。针对文本的目标检测任务不仅精准度更高，还能提供目标文本的识别结果。我们单独用PaddleOCR再做了一次文本检测识别。

3.1.3 脚本生成

  所有操作最终都会转化为脚本储存，我们自定义了一种脚本格式用来封装不同的UI操作。

  以一次点击为例，操作类型用Click()表示；如果是点击图标类控件，会将图标的截图保存（以及录制时的屏幕相对坐标，用于辅助回放定位），而点击文案则是记录文本。

  操作消抖： 点击、长按和滑动之间通过设置固定的时长消除实际操作时的抖动，我们取系统中的交互动效时长，一般是200～300ms。

  文本输入： 用户实际操作输入文本时分为两种情况，一是进入页面时自动聚焦编辑框，另一种是用户主动激活编辑，都会拉起虚拟键盘。我们在回放时也需要在拉起键盘的情况下输入，才能真实还原键盘事件对页面的影响。

am broadcast -a ADB_INPUT_B64 --es msg "xxx"

  目标分组： 一个页面上可能有多个相同的图标或文案，所以在录制时会聚合相同分组，在脚本中通过下标index(0)区分。

3.2 回放能力

  回放脚本时，则是根据脚本里记录的控件截图和文本，匹配到回放手机上的目标区域，进而执行点击、滑动等操作。这里用到的图像和文本匹配能力也会用在脚本断言里。

回放效果见下图：

3.2.1 图像匹配

  与文本相比，图标类控件在回放时要应对的变化更多：

• 颜色不同；


• 分辨率不同


• 附加角标等提示；

  在这种场景中，基于特征点匹配的SIFT算法很合适。

尺度不变特征变换(Scale-invariant feature transform, SIFT)是计算机视觉中一种检测、描述和匹配图像局部特征点的方法，通过在不同的尺度空间中检测极值点或特征点(Conrner Point, Interest Point)，提取出其位置、尺度和旋转不变量，并生成特征描述子，最后用于图像的特征点匹配。

  对图像做灰度预处理之后能减少颜色带来的噪音，而SIFT的尺度不变特性容忍了分辨率变化，附加的角标不会影响关键特征点的匹配。

  除此之外，为了减低误匹配，我们增加了两个操作：

  RegionMask：在匹配之前，我们也做了控件检测，并作为遮罩层Mask设置到SIFT中，排除错误答案之后的特征点更集中稳定。

  屏蔽旋转不变性：因为不需要在页面上匹配旋转后的目标，所以我们将提取的特征点向量角度统一重置为0。

  sift.detect(image, kpVector, mask);

  // 设置角度统一为0，禁用旋转不变性

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

      KeyPoint point = kpVector.get(i);

      point.angle(0);

      ...

  }

  sift.compute(image, kpVector, ret);

3.2.2 文本匹配

  文本匹配很容易实现，在OCR之后做字符串比较可以得到结果。

  但是因为算法本身精准度并不是百分百（OCR识别算法CRNN精准度在80%），遇到长文案时会出现识别错误，我们通过计算与期望文本间的编辑距离容忍这种误差。

  但最常见的还是全角和半角字符间的识别错误，需要把标点符号作为噪音去除。

  还有另一个同样和长文案有关的场景：机型宽度不同时，会出现文案换行展示的情况，这时就不能再去完整匹配，但可以切换到xpath使用部分匹配

//*[contains(@text,'xxx')]

3.2.3 兜底弹窗处理

  突然出现的弹窗是UI自动化中的一大痛点，无论是时机和形式都无法预测，造成的结果是自动化测试中断。

  弹窗又分为系统弹窗和业务弹窗，我们有两种处理弹窗的策略：

1. Android提供了一个DeviceOwner角色托管设备，并带有一个策略配置（PERMISSION_POLICY_AUTO_GRANT），测试过程中APP申请权限时天宫管家自动授予权限；

2. 在自动化被中断时，再次检查页面有没有白名单中的弹窗文案，有则触发兜底逻辑，关闭弹窗后，恢复自动化执行。

3.2.4 自动装包授权

  Android碎片化带来的还有不同的装包验证策略，比如OPPO&VIVO系机型就需要输入密码才能安装非商店应用。

  为了保持云真机的环境纯净，我们没有通过获取ROOT授权的方式绕过，而是采用部署在云真机内置的装包助手服务适配了不同机型的装包验证。

3.2.5 数据构造&请求MOCK

  目前为止我们录制到的还只有UI的操作，但场景用例中缺少不了测试数据的准备。
  首先是测试数据构造，脚本中提供一个封装好的动作，调用内部平台数据工厂，通过传入和保存变量能在脚本间传递调用的数据。

  同时脚本还可以关联到APP-MOCK平台，在一些固定接口或特定场景MOCK接口响应。譬如可以固定AB实验配置，又或是屏蔽推送类的通知。

3.1 平台能力

3.3.1 用例编辑&管理

  有实践过UI自动化的人应该有这种感受，在个人电脑搭建一套自动化环境是相当费劲的，更不用说要同时兼顾Android和iOS。

  当前我们已经达成了UI自动化纯线上化这一个小目标，只需要在浏览器中就可以完成UI脚本的编辑、调试和执行。现在正完善更多的线上操作，以Monaco Editor为基础编辑器提供更方便的脚本编辑功能。

3.3.2 脚本组&任务调度

  为了方便管理数量渐涨的用例，我们通过脚本组的方式分模块组织和执行脚本。每个脚本组可以设置前后置脚本和使用的帐号类别，一个脚本组会作为最小的执行单元发送到手机上执行。

  我们可以将回归场景拆分成若干个组在多台设备上并发执行，大大缩短了自动化用例的执行时间。

四、效果实践

4.1 回归测试提效

App录制回放能力建设完毕后，我们立即在多个业务线推动UI自动化测试实践。我们也专门成立了一支虚拟团队，邀请各团队骨干加入，明确回归测试提效的目标，拉齐认知，统一节奏，以保障UI自动化的大规模实践的顺利落地。

1. 
   

   建立问题同步及虚拟团队管理的相关制度，保障问题的快速反馈和快速解决。

   
   


2. 
   

   制定团队的UI测试实践管理规范，指导全体成员按统一的标准去执行，主要包括：

   
   
   
   
   • 回归用例筛选：按模块维度进行脚本转化，优先覆盖P0用例（占比30%左右）；
   
   
   • 测试场景设计：设计可以串联合并的场景，这样合并后可提升自动化执行速度；
   
   
   • 测试数据准备：自动化账号怎么管理，有哪些推荐的数据准备方案；
   
   
   • 脚本编写手册：前置脚本、公共脚本引入规范、断言规范等；
   
   
   • 脚本执行策略：脚本/脚本组管理及执行策略，怎样能执行的更快；
   
   
   
   

所以，我们在很短的时间内就完成了P0回归测试用例的转化，同时我们还要求：

1. 回放通过率必须高于90%，避免给业务测试人员造成额外的干扰，增加排查工作量；


2. 全量场景用例的执行总时长要小于90分钟，充分利用云真机的批量调度能力，快速输出测试报告。而且某种程度来说，还能避开因服务端部署带来的环境问题的影响；

截止目前，我们已经支持10多次单周版本的回归测试，已经可以替代部分手工回归测试工作量，降低测试压力的同时提升了版本发布质量的信心。

4.2 整体测试效能提升

在App UI自动化测试的实施取得突破性进展后，我们开始尝试优化原有性能、兼容、埋点等自动化测试遇到的一些问题，以提升移动App的整体测试效能。

• App性能自动化测试： 原有的性能测试脚本都是使用基于UI元素定位的方式，每周的功能迭代都或多或少会影响到脚本的稳定性，所以我们的性能脚本早期每周都需要维护。而现在的性能测试脚本通过率一般情况下都是100%，极个别版本才会出现微调脚本的情况。


• App深度兼容测试： 当涉及移动App测试时，兼容性测试的重要性不言而喻。移动云测平台在很早就已支持了标准兼容测试能力，即结合智能遍历去覆盖更多的App页面及场景，去发现一些基础的兼容测试问题。但随着App UI自动化测试的落地，现在我们已经可以基于大量的UI测试脚本在机房设备上开展深度兼容测试。

机房执行	深度兼容测试

• App 埋点 自动化测试： 高价值埋点的回归测试，以往我们都需要在回归期间去手工额外去触发操作路径，现在则基于UI自动化测试模拟用户操作行为，再结合移动云测平台已有的埋点自动校验+测试结果实时展示的能力，彻底解放人力，实现埋点全流程自动化测试。

• 接入 CICD 流水线： 我们将核心场景的UI回归用例配CICD流水线中，每当代码合入或者触发构建后，都会自动触发验证流程，如果测试不通过，构建人和相关维护人都能立即收到消息通知，进一步提升了研发协同效率。

五、未来展望

“道阻且长，行则将至，行而不辍，未来可期”。——《荀子·修身》

货拉拉App云录制回放测试平台的建设上，未来还有一些可提升的方向：

1. 迭代优化模型，提升精准度和性能；


2. 补全数据的录制回放，增加本地配置和缓存的控制；


3. 探索使用AI大模型的识图能力，辨别APP页面上的UI异常；


4. 和客户端精准测试结合，推荐未覆盖场景和变更相关用例；

大家好呀，我是楼仔。

最近发现很多号主发消息队列的文章，质量参差不齐，相关文章我之前也写过，建议直接看这篇。

这篇文章，主要讲述 Kafka、RabbitMQ、RocketMQ 和 ActiveMQ 这 4 种消息队列的异同，无论是面试，还是用于技术选型，都有非常强的参考价值。

不 BB，上文章目录：

01 消息队列基础

1.1 什么是消息队列？

消息队列是在消息的传输过程中保存消息的容器，用于接收消息并以文件的方式存储，一个消息队列可以被一个也可以被多个消费者消费，包含以下 3 元素：

• Producer：消息生产者，负责产生和发送消息到 Broker；


• Broker：消息处理中心，负责消息存储、确认、重试等，一般其中会包含多个 Queue；


• Consumer：消息消费者，负责从 Broker 中获取消息，并进行相应处理。

1.2 消息队列模式

• 点对点模式：多个生产者可以向同一个消息队列发送消息，一个具体的消息只能由一个消费者消费。

• 发布/订阅模式：单个消息可以被多个订阅者并发的获取和处理。

1.3 消息队列应用场景

• 应用解耦：消息队列减少了服务之间的耦合性，不同的服务可以通过消息队列进行通信，而不用关心彼此的实现细节。


• 异步处理：消息队列本身是异步的，它允许接收者在消息发送很长时间后再取回消息。


• 流量削锋：当上下游系统处理能力存在差距的时候，利用消息队列做一个通用的”载体”，在下游有能力处理的时候，再进行分发与处理。


• 日志处理：日志处理是指将消息队列用在日志处理中，比如 Kafka 的应用，解决大量日志传输的问题。


• 消息通讯：消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯，比如实现点对点消息队列，或者聊天室等。


• 消息广播：如果没有消息队列，每当一个新的业务方接入，我们都要接入一次新接口。有了消息队列，我们只需要关心消息是否送达了队列，至于谁希望订阅，是下游的事情，无疑极大地减少了开发和联调的工作量。

02 常用消息队列

由于官方社区现在对 ActiveMQ 5.x 维护越来越少，较少在大规模吞吐的场景中使用，所以我们主要讲解 Kafka、RabbitMQ 和 RocketMQ。

2.1 Kafka

Apache Kafka 最初由 LinkedIn 公司基于独特的设计实现为一个分布式的提交日志系统，之后成为 Apache 项目的一部分，号称大数据的杀手锏，在数据采集、传输、存储的过程中发挥着举足轻重的作用。

它是一个分布式的，支持多分区、多副本，基于 Zookeeper 的分布式消息流平台，它同时也是一款开源的基于发布订阅模式的消息引擎系统。

重要概念

• 主题（Topic）：消息的种类称为主题，可以说一个主题代表了一类消息，相当于是对消息进行分类，主题就像是数据库中的表。


• 分区（partition）：主题可以被分为若干个分区，同一个主题中的分区可以不在一个机器上，有可能会部署在多个机器上，由此来实现 kafka 的伸缩性。


• 批次：为了提高效率， 消息会分批次写入 Kafka，批次就代指的是一组消息。


• 消费者群组（Consumer Gr0up）：消费者群组指的就是由一个或多个消费者组成的群体。


• Broker: 一个独立的 Kafka 服务器就被称为 broker，broker 接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。


• Broker 集群：broker 集群由一个或多个 broker 组成。


• 重平衡（Rebalance）：消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。

Kafka 架构

一个典型的 Kafka 集群中包含 Producer、broker、Consumer Gr0up、Zookeeper 集群。

Kafka 通过 Zookeeper 管理集群配置，选举 leader，以及在 Consumer Gr0up 发生变化时进行 rebalance。Producer 使用 push 模式将消息发布到 broker，Consumer 使用 pull 模式从 broker 订阅并消费消息。

Kafka 工作原理

消息经过序列化后，通过不同的分区策略，找到对应的分区。

相同主题和分区的消息，会被存放在同一个批次里，然后由一个独立的线程负责把它们发到 Kafka Broker 上。

分区的策略包括顺序轮询、随机轮询和 key hash 这 3 种方式，那什么是分区呢？

分区是 Kafka 读写数据的最小粒度，比如主题 A 有 15 条消息，有 5 个分区，如果采用顺序轮询的方式，15 条消息会顺序分配给这 5 个分区，后续消费的时候，也是按照分区粒度消费。

由于分区可以部署在多个不同的机器上，所以可以通过分区实现 Kafka 的伸缩性，比如主题 A 的 5 个分区，分别部署在 5 台机器上，如果下线一台，分区就变为 4。

Kafka 消费是通过消费群组完成，同一个消费者群组，一个消费者可以消费多个分区，但是一个分区，只能被一个消费者消费。

如果消费者增加，会触发 Rebalance，也就是分区和消费者需要重新配对。

不同的消费群组互不干涉，比如下图的 2 个消费群组，可以分别消费这 4 个分区的消息，互不影响。

2.2 RocketMQ

RocketMQ 是阿里开源的消息中间件，它是纯 Java 开发，具有高性能、高可靠、高实时、适合大规模分布式系统应用的特点。

RocketMQ 思路起源于 Kafka，但并不是 Kafka 的一个 Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog 分发等场景。

重要概念

• Name 服务器（NameServer）：充当注册中心，类似 Kafka 中的 Zookeeper。


• Broker: 一个独立的 RocketMQ 服务器就被称为 broker，broker 接收来自生产者的消息，为消息设置偏移量。


• 主题（Topic）：消息的第一级类型，一条消息必须有一个 Topic。


• 子主题（Tag）：消息的第二级类型，同一业务模块不同目的的消息就可以用相同 Topic 和不同的 Tag 来标识。


• 分组（Gr0up）：一个组可以订阅多个 Topic，包括生产者组（Producer Gr0up）和消费者组（Consumer Gr0up）。


• 队列（Queue）：可以类比 Kafka 的分区 Partition。

RocketMQ 工作原理

RockerMQ 中的消息模型就是按照主题模型所实现的，包括 Producer Gr0up、Topic、Consumer Gr0up 三个角色。

为了提高并发能力，一个 Topic 包含多个 Queue，生产者组根据主题将消息放入对应的 Topic，下图是采用轮询的方式找到里面的 Queue。

RockerMQ 中的消费群组和 Queue，可以类比 Kafka 中的消费群组和 Partition：不同的消费者组互不干扰，一个 Queue 只能被一个消费者消费，一个消费者可以消费多个 Queue。

消费 Queue 的过程中，通过偏移量记录消费的位置。

RocketMQ 架构

RocketMQ 技术架构中有四大角色 NameServer、Broker、Producer 和 Consumer，下面主要介绍 Broker。

Broker 用于存放 Queue，一个 Broker 可以配置多个 Topic，一个 Topic 中存在多个 Queue。

如果某个 Topic 消息量很大，应该给它多配置几个 Queue，并且尽量多分布在不同 broker 上，以减轻某个 broker 的压力。Topic 消息量都比较均匀的情况下，如果某个 broker 上的队列越多，则该 broker 压力越大。

简单提一下，Broker 通过集群部署，并且提供了 master/slave 的结构，salve 定时从 master 同步数据（同步刷盘或者异步刷盘），如果 master 宕机，则 slave 提供消费服务，但是不能写入消息。

看到这里，大家应该可以发现，RocketMQ 的设计和 Kafka 真的很像！

2.3 RabbitMQ

RabbitMQ 2007 年发布，是使用 Erlang 语言开发的开源消息队列系统，基于 AMQP 协议来实现。

AMQP 的主要特征是面向消息、队列、路由、可靠性、安全。AMQP 协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。

重要概念

• 信道（Channel）：消息读写等操作在信道中进行，客户端可以建立多个信道，每个信道代表一个会话任务。


• 交换器（Exchange）：接收消息，按照路由规则将消息路由到一个或者多个队列；如果路由不到，或者返回给生产者，或者直接丢弃。


• 路由键（RoutingKey）：生产者将消息发送给交换器的时候，会发送一个 RoutingKey，用来指定路由规则，这样交换器就知道把消息发送到哪个队列。


• 绑定（Binding）：交换器和消息队列之间的虚拟连接，绑定中可以包含一个或者多个 RoutingKey。

RabbitMQ 工作原理

AMQP 协议模型由三部分组成：生产者、消费者和服务端，执行流程如下：

1. 生产者是连接到 Server，建立一个连接，开启一个信道。


2. 生产者声明交换器和队列，设置相关属性，并通过路由键将交换器和队列进行绑定。


3. 消费者也需要进行建立连接，开启信道等操作，便于接收消息。


4. 生产者发送消息，发送到服务端中的虚拟主机。


5. 虚拟主机中的交换器根据路由键选择路由规则，发送到不同的消息队列中。


6. 订阅了消息队列的消费者就可以获取到消息，进行消费。

常用交换器

RabbitMQ 常用的交换器类型有 direct、topic、fanout、headers 四种，具体的使用方法，可以参考官网：

官网入口：https://www.rabbitmq.com/getstarted.html

03 消息队列对比

3.1 Kafka

优点：

• 高吞吐、低延迟：Kafka 最大的特点就是收发消息非常快，Kafka 每秒可以处理几十万条消息，它的最低延迟只有几毫秒；


• 高伸缩性：每个主题（topic）包含多个分区（partition），主题中的分区可以分布在不同的主机（broker）中；


• 高稳定性：Kafka 是分布式的，一个数据多个副本，某个节点宕机，Kafka 集群能够正常工作；


• 持久性、可靠性、可回溯： Kafka 能够允许数据的持久化存储，消息被持久化到磁盘，并支持数据备份防止数据丢失，支持消息回溯；


• 消息有序：通过控制能够保证所有消息被消费且仅被消费一次；


• 有优秀的第三方 Kafka Web 管理界面 Kafka-Manager，在日志领域比较成熟，被多家公司和多个开源项目使用。

缺点：

• Kafka 单机超过 64 个队列/分区，Load 会发生明显的飙高现象，队列越多，load 越高，发送消息响应时间变长；


• 不支持消息路由，不支持延迟发送，不支持消息重试；


• 社区更新较慢。

3.2 RocketMQ

优点：

• 高吞吐：借鉴 Kafka 的设计，单一队列百万消息的堆积能力；


• 高伸缩性：灵活的分布式横向扩展部署架构，整体架构其实和 kafka 很像；


• 高容错性：通过ACK机制，保证消息一定能正常消费；


• 持久化、可回溯：消息可以持久化到磁盘中，支持消息回溯；


• 消息有序：在一个队列中可靠的先进先出（FIFO）和严格的顺序传递；


• 支持发布/订阅和点对点消息模型，支持拉、推两种消息模式；


• 提供 docker 镜像用于隔离测试和云集群部署，提供配置、指标和监控等功能丰富的 Dashboard。

缺点：

• 不支持消息路由，支持的客户端语言不多，目前是 java 及 c++，其中 c++ 不成熟；


• 部分支持消息有序：需要将同一类的消息 hash 到同一个队列 Queue 中，才能支持消息的顺序，如果同一类消息散落到不同的 Queue中，就不能支持消息的顺序。


• 社区活跃度一般。

3.3 RabbitMQ

优点：

• 支持几乎所有最受欢迎的编程语言：Java，C，C ++，C＃，Ruby，Perl，Python，PHP等等；


• 支持消息路由：RabbitMQ 可以通过不同的交换器支持不同种类的消息路由；


• 消息时序：通过延时队列，可以指定消息的延时时间，过期时间TTL等；


• 支持容错处理：通过交付重试和死信交换器（DLX）来处理消息处理故障；


• 提供了一个易用的用户界面，使得用户可以监控和管理消息 Broker；


• 社区活跃度高。

缺点：

• Erlang 开发，很难去看懂源码，不利于做二次开发和维护，基本职能依赖于开源社区的快速维护和修复 bug；


• RabbitMQ 吞吐量会低一些，这是因为他做的实现机制比较重；


• 不支持消息有序、持久化不好、不支持消息回溯、伸缩性一般。

04 消息队列选型

Kafka：追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务，大型公司建议可以选用，如果有日志采集功能，肯定是首选 kafka。

RocketMQ：天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。RoketMQ 在稳定性上可能更值得信赖，这些业务场景在阿里双 11 已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择 RocketMQ。

RabbitMQ：结合 erlang 语言本身的并发优势，性能较好，社区活跃度也比较高，但是不利于做二次开发和维护，不过 RabbitMQ 的社区十分活跃，可以解决开发过程中遇到的 bug。如果你的数据量没有那么大，小公司优先选择功能比较完备的 RabbitMQ。

ActiveMQ：官方社区现在对 ActiveMQ 5.x 维护越来越少，较少在大规模吞吐的场景中使用。

今天就聊到这里，我们下一篇见~~

最后，把楼仔的座右铭送给你：我从清晨走过，也拥抱夜晚的星辰，人生没有捷径，你我皆平凡，你好，陌生人，一起共勉。

原创好文：

• 聊聊自己，我的另一面


• select...for update，表锁？行锁？间隙锁？


• 如何解决 MySQL 主从延时问题？


• 晋升成功了


• 拿到优秀员工了


• 聊聊情绪管理


• 4 种 MySQL 同步 ES 方案，yyds！


• 技术派中的缓存一致性解决方案


• 高频面试：Spring 如何解决循环依赖？


• 技术派中 ES 集成的实现姿势


• MySQL 同步 ES 实战，肝到爆！

来聊聊Nuxt源码。

聊聊启动nuxt项目

废话不多说，看官网一段Nuxt项目启动

const { Nuxt, Builder } = require('nuxt')



const app = require('express')()

const isProd = process.env.NODE_ENV === 'production'

const port = process.env.PORT || 3000



// 用指定的配置对象实例化 Nuxt.js

const config = require('./nuxt.config.js')

config.dev = !isProd

const nuxt = new Nuxt(config)



// 用 Nuxt.js 渲染每个路由

app.use(nuxt.render)



// 在开发模式下启用编译构建和热加载

if (config.dev) {

  new Builder(nuxt).build().then(listen)

} else {

  listen()

}



function listen() {

  // 服务端监听

  app.listen(port, '0.0.0.0')

  console.log('Server listening on `localhost:' + port + '`.')

}

解读一下这段代码：

导入nuxt的Nuxt类和Builder类，然后用express创建一个node服务。

导入nuxt.config.js，使用导入的nuxt的config对象，创建nuxt实例： const nuxt = new Nuxt(config)

然后重点是 app.use(nuxt.render)。把nuxt.render作为node服务中间件使用即可。
到这里在生产上就可以运行了（生成前会先nuxt build）。

然后就是监听listen端口

所以到这里有2条线索，一个是：nuxt build的产物，自动生成路由。dist下的client和server资源文件是什么？
一个是，上面的服务，怎么会根据当前页面路径渲染出当期的html的。

你知道了，今天说的是第二条，来看看，nuxt是怎么渲染页面的，它做了什么nuxt到底是什么？

目录结构

下载好源码后来看下源码的核心目录结构：

// 工程核心目录结构

├─ distributions   

    ├─ nuxt                 // nuxt指令入口，同时对外暴露@nuxt/core、@nuxt/builder、@nuxt/generator、getWebpackConfig

    ├─ nuxt-start           // nuxt start指令，同时对外暴露@nuxt/core

├─ lerna.json               // lerna配置文件

├─ package.json         

├─ packages                 // 工作目录

    ├─ babel-preset-app     // babel初始预设

    ├─ builder              // 根据路由构建动态当前页ssr资源，产出.nuxt资源

    ├─ cli                  // 脚手架命令入口

    ├─ config               // 提供加载nuxt配置相关的方法

    ├─ core                 //  Nuxt实例，加载nuxt配置，初始化应用模版，渲染页面，启动SSR服务

    ├─ generator            // Generato实例，生成前端静态资源（非SSR）

    ├─ server               // Server实例，基于Connect封装开发/生产环境http服务，管理Middleware

    ├─ types                // ts类型

    ├─ utils                // 工具类

    ├─ vue-app              // 存放Nuxt应用构建模版，即.nuxt文件内容

    ├─ vue-renderer         // 根据构建的SSR资源渲染html

    └─ webpack              // webpack相关配置、构建实例

├─ scripts

├─ test

└─ yarn.lock

Nuxt类在core下nuxt.js文件。来看看new Nuxt的主要代码：

export default class Nuxt extends Hookable {

  constructor (options = {}) {

    super(consola)



    // Assign options and apply defaults

    this.options = getNuxtConfig(options)



    this.moduleContainer = new ModuleContainer(this)



    // Deprecated hooks

    this.deprecateHooks({

    })



    this.showReady = () => { this.callHook('webpack:done') }



    // Init server

    if (this.options.server !== false) {

      this._initServer()

    }



    // Call ready

    if (this.options._ready !== false) {

      this.ready().catch((err) => {

        consola.fatal(err)

      })

    }

  }





  ready () {

  }



  async _init () {

  }



  _initServer () {

  }

}

实例化nuxt的工作内容很简单：

1. this.options = getNuxtConfig(options) nuxt.config.js对象合并 Nuxt默认对象

// getDefaultNuxtConfig

export function getDefaultNuxtConfig (options = {}) {

  if (!options.env) {

    options.env = process.env

  }



  return {

    ..._app(),

    ..._common(),

    build: build(),

    messages: messages(),

    modes: modes(),

    render: render(),

    router: router(),

    server: server(options),

    cli: cli(),

    generate: generate()

  }

}



// config

...

const nuxtConfig = getDefaultNuxtConfig()

defaultsDeep(options, nuxtConfig)

...

2. this.moduleContainer = new ModuleContainer(this) 创建了一个moduleConiner实例

export default class ModuleContainer {

  constructor (nuxt) {

    this.nuxt = nuxt

    this.options = nuxt.options

    this.requiredModules = {}



  }

}

3. this._initServer() 来创建一个connect服务。

  _initServer () {

    if (this.server) {

      return

    }

    this.server = new Server(this)

    this.renderer = this.server

    this.render = this.server.app

    defineAlias(this, this.server, ['renderRoute', 'renderAndGetWindow', 'listen'])

  }

export default class Server {

  constructor (nuxt) {

    this.nuxt = nuxt

    this.options = nuxt.options



    this.globals = determineGlobals(nuxt.options.globalName, nuxt.options.globals)



    this.publicPath = isUrl(this.options.build.publicPath)

      ? this.options.build._publicPath

      : this.options.build.publicPath.replace(/^\.+\//, '/')



    // Runtime shared resources

    this.resources = {}



    // Will be set after listen

    this.listeners = []



    // Create new connect instance

    this.app = connect()



    // Close hook

    this.nuxt.hook('close', () => this.close())



    // devMiddleware placeholder

    if (this.options.dev) {

      this.nuxt.hook('server:devMiddleware', (devMiddleware) => {

        this.devMiddleware = devMiddleware

      })

    }

  }

}

server很简单，使用connect创建了一个instance. 然后实例化一些参数。其中，我们发现nuxt会触发一些hooks。在每一个节点可以去做一些事情。nuxt能设置hooks是因为nuxt继承Hookable。

随后调用this.ready()方法，就是调用了私有init方法

async _init () {

   await this.moduleContainer.ready()

   await this.server.ready()

}

主要是调用两个实例的ready方法。

moduleContainer实例ready方法

 async ready () {

    // Call before hook

    await this.nuxt.callHook('modules:before', this, this.options.modules)



    if (this.options.buildModules && !this.options._start) {

      // Load every devModule in sequence

      await sequence(this.options.buildModules, this.addModule)

    }



    // Load every module in sequence

    await sequence(this.options.modules, this.addModule)



    // Load ah-hoc modules last

    await sequence(this.options._modules, this.addModule)



    // Call done hook

    await this.nuxt.callHook('modules:done', this)

  }

总结就是加载 buildModules modules 模块并且执行。

buildModules: [

  '@nuxtjs/eslint-module'

],

 modules: [

    '@nuxtjs/axios'

 ],

server实例的ready方法

async ready () {

  	this.serverContext = new ServerContext(this)

    this.renderer = new VueRenderer(this.serverContext)

    await this.renderer.ready()

  	await this.setupMiddleware()

}

ServerContext类很简单，就是设置server 上下文resources/options/nuxt/globals这些信息

export default class ServerContext {

  constructor (server) {

    this.nuxt = server.nuxt

    this.globals = server.globals

    this.options = server.options

    this.resources = server.resources

  }

}

VueRenderer ready方法做了那些事情呢？

async _ready () {

  await this.loadResources(fs)

  this.createRenderer()

}

get resourceMap () {

    const publicPath = urlJoin(this.options.app.cdnURL, this.options.app.assetsPath)

    return {

      clientManifest: {

        fileName: 'client.manifest.json',

        transform: src => Object.assign(JSON.parse(src), { publicPath })

      },

      modernManifest: {

        fileName: 'modern.manifest.json',

        transform: src => Object.assign(JSON.parse(src), { publicPath })

      },

      serverManifest: {

        fileName: 'server.manifest.json',

        // BundleRenderer needs resolved contents

        transform: async (src, { readResource }) => {

          const serverManifest = JSON.parse(src)



          const readResources = async (obj) => {

            const _obj = {}

            await Promise.all(Object.keys(obj).map(async (key) => {

              _obj[key] = await readResource(obj[key])

            }))

            return _obj

          }



          const [files, maps] = await Promise.all([

            readResources(serverManifest.files),

            readResources(serverManifest.maps)

          ])



          // Try to parse sourcemaps

          for (const map in maps) {

            if (maps[map] && maps[map].version) {

              continue

            }

            try {

              maps[map] = JSON.parse(maps[map])

            } catch (e) {

              maps[map] = { version: 3, sources: [], mappings: '' }

            }

          }



          return {

            ...serverManifest,

            files,

            maps

          }

        }

      },

      ssrTemplate: {

        fileName: 'index.ssr.html',

        transform: src => this.parseTemplate(src)

      },

      spaTemplate: {

        fileName: 'index.spa.html',

        transform: src => this.parseTemplate(src)

      }

    }

  }