背景原因

今天写需求，需要使用background简写属性，心想这还不简单吗，真男人写样式只需要两秒:

background:  url('./bg.png') no-repeat center contain ;

搞定！

上面设置的依次是 背景图片 背景平铺模式 背景位置 背景图片是保有其原有的尺寸还是拉伸到新的尺寸。

so easy~

看我ctrl + s 保存代码，编译。

嗯？ 怎么不生效？ 俺的背景呢？
打开控制台一看，好家伙，压根没生效:

问题排查

第一反应是这些属性有固定顺序，但是凭我练习两年半的经验，不应该啊，之前也是这样用的啊，遂打开MDN，仔细翻阅....

发现了下面这段话:

这让我更加确信 写的没毛病啊！！

background-attachment、background-color、background-image、background-position、background-repeat、background-size
这些属性可以以任意顺序书写。

见了鬼了,待我排查两小时(摸鱼...)

原因浮现

在仔细阅读文档后发现，其实在文档的上面，还有另外一段话：

我恍然大悟，索嘎，以后看文档不能马虎了，得仔细查阅，过于经验主义了，这都是细节啊！

background使用注意事项和总结

其实，使用background时，大部分时候 属性的顺序是可以任意位置书写的，
但是有两个属性有点特殊，那就是background-size和background-position，

当background简写同时有这两个属性时，那么必须background-position在前，background-size在后，且两者只能紧挨着书写并且以 "/"分隔。
例如:

错误: background: url('./bg.png') no-repeat center  contain ; // 没有以 "/"分隔

错误: background: url('./bg.png') center  no-repeat contain ; // 没有紧挨着书写

错误: background: url('./bg.png') no-repeat contain / center; //background-size写在了 background-position的前面



正确: background: url('./bg.png') no-repeat center / contain ; 

写在最后

其实MDN在关于background的文档最开头的例子中就有写：

只不过没有用语言描述出来，一般没有认真看很难发现，所以有时候能够静下心来认真查阅文档，真的会发现很多细节(甩锅:这tm是谁写的文档，出来挨打).

背景

前两天分享了一篇自己的个人经历，没想到引来了那么多人共鸣，很多人留下了评论，大部分评论我都认真看了，并且也回复了，有的评论建议真的很棒，对我的帮助很大，很感谢。

今天给评论给整理了一下，再加上自己有一些新的感悟，给大家分享分享，给迷茫的朋友一点建议。有很多东西想说，但是表达能力有限，只能写出一点。

一个30岁老前端的人生经历（学习+工作+婚姻+孩子），给迷茫的朋友一点激励。前端是不是真的不行了

有些没有毕业或者刚毕业的兄弟们，很关心这个问题，因为关乎他们是否要学前端开发。还有一些想转前端开发的兄弟，也很关心这个问题。

关于这个问题，上篇文章有评论开玩笑的说现在入前端，相当于49年入guojun，下面就这个问题我发表一下我的个人看法。

先说一下我的观点，前端确实比以前难很多，工作岗位变少，薪资变低，技术要求也变高了，还没入或准备入前端的，建议真的不要入了，有经验的都不好找工作，更别说没工作经验的了，当然天才除外。

我同学和我朋友两个前端（都是好几年工作经验的）找了几个月都没有合适的工作，面试机会还是有的，但是外包偏多，并且还要降薪，最后都拒了。

他们还发现了一个现象，有时候面试的过程中整体都非常好，hr有要发offer的意思，但是就一直拖着，然后后面突然有一天说不合适了。这种应该是有更好的选择了，以前都是求职者手握多个offer，去挑选公司，现在公司占据主动了，从多个候选人中挑员工了。

后端情况我不清楚，但是前端真的没有以前好就业了，这个时候想入前端的，我真的不太建议，除非你真的特别牛，就算你很牛，但是没有面试机会，也没办法证明啊。

有些已经入前端的新人私信我，让我给他一些提升建议。

小结

没入前端的同学，建议别入了。刚入前端的同学想快速提升自己，多学多练，多总结和复盘，不要怕被别人说卷，给自己定目标。

30岁前端的路

我在flag里写了打算2024年认真看一下react源码，很多大佬建议说现在别搞这些没意义的东西了，搞前端死路一条。

关于大龄前端发展，从评论建议中，我总结了以下几条常用出路，欢迎大家补充。

深入技术

都说前端的天花板就是组长，结合我自身的经历和评论区的留言来看好像确实是这样，我几年前就开始做前端负责人了，其实就是组长，只是管的人多少的问题，cto永远是后端。主要工作就是需求来了，把任务给下面人分一分，就没了，最有挑战的也就是框架基建了吧。

评论里有人说，如果想要继续搞技术的话，可以往全栈方向发展，因为前端很难涉及到公司业务，所以可替代性很高，后端和公司业务结合的比较深一点，而业务才是公司的根本，换一个人很难立马上手，可替代性比前端低很多。

关于全栈我的观点是，大龄前端还是往全栈发展比较好，除了上面的原因外，全栈可以自己做个产品，还可以接私活、做自由职业者，甚至转管理都需要懂点后端技术。

想转全栈，但是又不想学别人语言，node也是可以做后端开发的，现在比较成熟的框架有midway和nest，甚至koa都可以做后端开发。关注我的人应该知道我正在做的fluxy-admin就是一个全栈项目，前端使用的是react，后端使用的是midway，前端上手midway还是很简单的，我一个星期就上手写项目了。

转管理

有一些评论提到了转管理，说实话这个是需要机会的，不是所有人想转就转的，因为公司很少愿意给员工尝试的机会，除非你开发的时候已经表现出了管理方面的天赋，让老板认可你，不然都很难转成功，一是一个萝卜一个坑，老的领导没走你就上不去，而上面领导走了，很多公司可能会从外面招一个新的人空降过来，而不是从下面提拨一个上去。

还有管理也不是什么人都可以做的，有的人搞技术可以，管理真的不太行，比如我，在某家公司，当时管着10几个前端，团队被我带的一团糟，后来我找个副组长帮我管理，我专心搞技术搞框架，团队才慢慢走上正规。

个人觉得想转管理，需要机会和自身有管理才能，这两个条件都很重要。

转产品

有些评论还提到了转产品，我感觉这个还是比较靠谱的，玉伯大佬就是一个成功转型的案例。

个人感觉前端转产品还是有一些优势的，下面是我从网上搜的：

前端转产品，可以将技术理解和用户体验融入产品管理中，提高产品的竞争力。感觉门槛也不高，只需要有想法，并且现在软件行业那么发达，实在想不到好的点子，还可以借鉴别人产品设计。

甚至以后AI发展的很成熟了，可能就不需要开发了，只需要产品经理把需求描述好，产品就自动生成出来了。

我现在也在往这方面发展，最近一年在公司主导研发低代码平台，从最开始的设计到基本构架实现都是我一个人，框架成熟后，经常和交付直接交流，渐渐往产品的角色发展了。现在工作中不只是只有代码了，经常也会站在产品的角度去思考，做的东西怎么才能更有价值，怎么提高用户体验等。

平时有一些想法在公司产品里用不上，所以打算自己做一个产品，现在有了一些idea，明年应该会去做。这里说明一下，如果有想法想做个产品但找不到合适的后端合伙人，全栈做小应用或独立产品还是很有优势的，呼应了前面说的全栈优势。

搞副业

评论里也有很多人建议搞副业，这个确实也是一条出路，但是我感觉搞副业得有可靠的路子，不能盲目的去搞，不然最后可能血本无归。

我知道前几年有个程序员可以干的并且很好的副业，录视频卖课程，现在随着互联网新人越来越少，这个副业已经不行了。

现在我知道的有个副业还不错，在线帮别人修改简历，因为现在很多人找不到工作，甚至没有面试机会，他们会很焦虑，认为可能是自己简历的问题，会找一些大佬帮忙优化简历，搞这个的提前你得是个大佬，并且有一定的知名度，对于普通人不适用。

现在也有一些人趁着AI的热度，独立开发AI应用，靠这个赚了一些钱，我对这个不太了解，不做评价。

下面是一位大佬的评论，可能比较适合普通人，不过他说的那些我都没有认证，大家请谨慎对待：

转行

有很多评论认为搞技术没有前途，还是要考公，确实对于刚入行或准备入行的兄弟考公是一个比较好的选择，因为年轻还有很多机会，像我们这种年龄大的，还拖家带口的已经不适合改行了，成本太高了，真经不起折腾。

也有评论说想回老家，说实话我也想老家，但是以我的能力，回老家估计都养不活一家人，只会写代码，回老家能干啥呢。

最后

上面的内容是根据评论内容简单的整理了一下，还加了一些个人看法，大家可以结合自己的情况食用。可能还有更多好的建议因为我文笔有限，没写出来，欢迎大家评论，一起交流。

最后说一下自己吧，没写文章之前，我一直认为作为一个程序员技术最重要的，就像我的简介里说的那样，我唯一会的就是写代码，我不一定会成功，但是我会努力做的更好。看完大家的评论后，内心有过动摇，是不是不应该继续卷技术了，在写这篇文章的时候，我又坚定了，因为搞技术不只是我的工作，这也是我热爱的东西，即使有一天被迫失业不做程序员了，我可能偶尔还会写写代码。不过鸡蛋不能放在一个篮子里的道理我还是知道的，我现在已经在慢慢往产品转，用以保证未来不失业，因为还有一大家子需要我来养啊。共勉。

是的, 你没听错! 网络开发中无处不在的数据交换格式JSON, 可能会拖慢你的应用程序. 在这个速度和响应速度至上的世界里, 检查 JSON 的性能影响至关重要, 而我们对此却常常忽略. 在本博客中, 我们将深入探讨 JSON 成为应用程序瓶颈的原因, 并探索更快的替代方案和优化技术, 以确保你的应用程序以最佳状态运行.

JSON 是什么? 为何我要关注这个问题?

JSON 教程 | w3resource

JSON是JavaScript Object Notation的缩写, 是一种轻量级数据交换格式, 已成为Web应用中传输和存储数据的首选. 它的简洁性和人类可读格式使人类和机器都能轻松使用. 但是, 为什么要在Web开发项目中关注 JSON 呢?

JSON 是应用中数据的粘合剂. 它是服务器和客户端之间进行数据通信的语言, 也是数据库和配置文件中存储数据的格式.

JSON 的流行以及人们使用它的原因…

JSON 在Web开发领域的受欢迎程度怎么强调都不为过. 它已成为数据交换的事实标准, 这其中有几个令人信服的原因:

它易于使用!

鉴于这些优势, 难怪全球的开发人员都依赖 JSON 来满足他们的数据交换需求. 然而, 随着我们在本博客的深入探讨, 我们将发现与 JSON 相关的潜在性能挑战, 以及如何有效解决这些挑战.

速度需求

🚀🚀🚀

应用的速度和响应的重要性

在当今快节奏的数字环境中, 应用的速度和响应能力是不可或缺的. 用户希望在Web和移动应用中即时获取信息, 快速交互和无缝体验. 对速度的这种要求是由以下几个因素驱动的:

JSON 会拖慢我们的应用吗?

现在, 让我们来讨论核心问题: JSON 是否会拖慢我们的应用?

如前所述, JSON 是一种非常流行的数据交换格式. 它灵活, 易用, 并得到广泛支持. 然而, 这种广泛的应用并不意味着它不会面临性能挑战.

在某些情况下, JSON 可能是导致应用慢的罪魁祸首. 解析 JSON 数据的过程, 尤其是在处理大型或复杂结构时, 可能会耗费宝贵的毫秒时间. 此外, 低效的序列化和反序列化也会影响应用的整体性能.

在接下来的内容中, 我们将探讨 JSON 成为应用瓶颈的具体原因, 更重要的是, 探讨如何缓解这些问题. 在深入探讨的过程中, 请记住我们的目标不是诋毁 JSON, 而是了解其局限性并发现优化其性能的策略, 以追求更快, 反应更灵敏的应用.

LinkedIn将Protocal Buffers与Rest.li集成以提高微服务性能| LinkedIn工程

JSON 为什么会变慢

尽管 JSON 被广泛使用, 但它也难逃性能挑战. 让我们来探究 JSON 可能会变慢的原因, 并理解为什么 JSON 并不总是数据交换的最佳选择.

1. 解析带来的开销

当 JSON 数据到达应用时, 它必须经过解析过程才能转换成可用的数据结构. 解析过程可能相对较慢, 尤其是在处理大量或深度嵌套的 JSON 数据时.

2. 序列化和反序列化

JSON 要求在从客户端向服务器发送数据时进行序列化(将对象编码为字符串), 并在接收数据时进行反序列化(将字符串转换回可用对象). 这些步骤会带来开销, 影响应用的整体速度.

在微服务架构的世界里, JSON 通常用于在服务之间传递消息. 但是, 很关键的是, 我们必须认识到, JSON 消息需要序列化和反序列化, 这两个过程会带来巨大的开销.

在有大量微服务不断通信的场景中, 这种开销可能会增加, 并有可能使应用变慢, 以至于影响用户体验.

我们面临的第二个挑战是, 由于 JSON 的文本性质, 序列化和反序列化的延迟和吞吐量都不理想.
— LinkedIn

序列化和反序列化

3. 字符串操作

JSON 基于文本, 在连接和解析等操作中严重依赖字符串操作. 与处理二进制数据相比, 处理字符串的速度会慢一些.

4. 缺乏数据类型

JSON 的数据类型(如字符串, 数字, 布尔值)非常有限. 复杂的数据结构可能需要效率较低的表示法, 从而导致内存使用量增加和处理速度减慢.

5. 冗余

JSON 的人类可读性设计可能会导致冗余. 不需要的键和重复的结构增加了有效载荷的大小, 导致数据传输时间延长.

第一个挑战是 JSON 是一种文本格式, 往往比较冗余. 这导致网络带宽使用量增加, 更高的延迟, 效果并不理想.
— LinkedIn

6. 不支持二进制

JSON 缺乏对二进制数据的本地支持. 在处理二进制数据时, 开发人员通常需要将其编解码为文本, 而这可能会降低效率.

7. 深度嵌套

在某些情况下, JSON 数据可能是深嵌套的, 需要递归解析和遍历. 这种计算复杂性会降低应用的运行速度, 尤其是在没有优化的情况下.

JSON的替代方案

虽然 JSON 是一种通用的数据交换格式, 但由于其在某些情况下的性能限制, 人们开始探索更快的替代格式. 让我们深入探讨其中的一些替代方案, 了解何时以及为何选择它们:

1. Protocol Buffers(protobuf)

Protocal Buffers通常被称为protobuf, 是由谷歌开发的一种二进制序列化格式. 它的设计宗旨是高效, 紧凑和快速. Protobuf 的二进制性质使其在序列化和反序列化方面的速度明显快于 JSON.

• 何时选择: 当你需要高性能的数据交换时, 尤其是在微服务架构, 物联网应用或网络带宽有限的情况下, 请考虑使用Protobuf.

GitHub - vaishnav-mk/protobuf-example

2. MessagePack

MessagePack 是另一种二进制序列化格式, 以速度快, 结构紧凑而著称. 它比 JSON 更有效率, 同时与各种编程语言保持兼容.

• 何时选择: 当你需要在速度和跨语言兼容性之间取得平衡时, MessagePack 是一个不错的选择. 它适用于实时应用和对减少数据大小至关重要的情况.

3. BSON (二进制 JSON)

BSON 或二进制 JSON 是一种从 JSON 衍生出来的二进制编码格式. 它保留了 JSON 的灵活性, 同时通过二进制编码提高了性能. BSON 常用于 MongoDB 等数据库.

• 何时选择: 如果你正在使用 MongoDB, 或者需要一种格式来弥补 JSON 和二进制效率之间的差距, 那么 BSON 是一个很有价值的选择.

4. Apache Avro

Apache Avro 是一个数据序列化框架, 专注于提供一种紧凑的二进制格式. 它基于schema, 可实现高效的数据编解码.

• 何时选择: Avro 适用于schema演进非常重要的情况, 如数据存储, 以及需要在速度和数据结构灵活性之间取得平衡的情况.

与 JSON 相比, 这些替代方案提供了不同程度的性能改进, 具体选择取决于你的具体使用情况. 通过考虑这些替代方案, 你可以优化应用的数据交换流程, 确保将速度和效率放在开发工作的首位.

JSON, Protobufs, MessagePack, BSON 和 Avro 之间的差异

每个字节都很重要: 优化数据格式

在效率和速度至上的数据交换世界中, 数据格式的选择会产生天壤之别. 本节将探讨从简单的 JSON 数据表示到更高效的二进制格式(如 Protocol Buffers, MessagePack, BSON 和 Avro)的过程. 我们将深入探讨每种格式的细微差别, 并展示为什么每个字节都很重要.

开始: JSON 数据

我们从简单明了的 JSON 数据结构开始. 下面是我们的 JSON 数据示例片段:

{

  "id": 1,                                 // 14 bytes

  "name": "John Doe",                      // 20 bytes

  "email": "johndoe@example.com",          // 31 bytes

  "age": 30,                               // 9 bytes

  "isSubscribed": true,                    // 13 bytes

  "orders": [                              // 11 bytes

    {                                      // 2 bytes

      "orderId": "A123",                   // 18 bytes

      "totalAmount": 100.50                // 20 bytes

    },                                     // 1 byte

    {                                      // 2 bytes

      "orderId": "B456",                   // 18 bytes

      "totalAmount": 75.25                 // 19 bytes

    }                                      // 1 byte

  ]                                        // 1 byte

}                                          // 1 byte

JSON 总大小: ~ 139 字节

虽然 JSON 用途广泛且易于使用, 但它也有一个缺点, 那就是它的文本性质. 每个字符, 每个空格和每个引号都很重要. 在数据大小和传输速度至关重要的情况下, 这些看似微不足道的字符可能会产生重大影响.

效率挑战: 使用二进制格式减小尺寸

现在, 让我们提供其他格式的数据表示并比较它们的大小:

Protocol Buffers (protobuf):

syntax = "proto3";



message User {

  int32 id = 1;

  string name = 2;

  string email = 3;

  int32 age = 4;

  bool is_subscribed = 5;

  repeated Order orders = 6;



  message Order {

    string order_id = 1;

    float total_amount = 2;

  }

}

0A 0E 4A 6F 68 6E 20 44 6F 65 0C 4A 6F 68 6E 20 44 6F 65 65 78 61 6D 70 6C 65 2E 63 6F 6D 04 21 00 00 00 05 01 12 41 31 32 33 03 42 DC CC CC 3F 05 30 31 31 32 34 34 35 36 25 02 9A 99 99 3F 0D 31 02 42 34 35 36 25 02 9A 99 99 3F

Protocol Buffers 总大小: ~ 38 bytes

MessagePack:

(注意:MessagePack 是一种二进制格式, 此处的表示法非人工可读.)

二进制表示(十六进制):

a36a6964000000000a4a6f686e20446f650c6a6f686e646f65406578616d706c652e636f6d042100000005011241313302bdcccc3f0530112434353625029a99993f

MessagePack 总大小: ~34 字节

BSON (二进制 JSON):

(注意:BSON 是一种二进制格式, 此处的表示法非人工可读.)

二进制表示法 (十六进制):

3e0000001069640031000a4a6f686e20446f6502656d61696c006a6f686e646f65406578616d706c652e636f6d1000000022616765001f04370e4940

BSON 总大小: ~ 43 字节

Avro:

(注: Avro使用schema, 因此数据与schema信息一起编码.)

二进制表示法 (十六进制):

0e120a4a6f686e20446f650c6a6f686e646f65406578616d706c652e636f6d049a999940040a020b4108312e3525312e323538323539

Avro 总大小: ~ 32 字节

(这些替代方案的实际字节数可能会有所不同, 提供这些数字只是为了让大家有个大致的了解.)

现在你可能会感到奇怪, 为什么我们的程序会有这么多的字节数?

现在你可能想知道为什么有些格式输出的是二进制, 但它们的大小却各不相同. Avro, MessagePack 和 BSON 等二进制格式具有不同的内部结构和编码机制, 这可能导致二进制表示法的差异, 即使它们最终表示的是相同的数据. 下面简要介绍一下这些差异是如何产生的:

1. Avro:

• Avro 使用schema对数据进行编码, 二进制表示法中通常包含该schema.


• Avro 基于schema的编码可提前指定数据结构, 从而实现高效的数据序列化和反序列化.


• Avro 的二进制格式设计为自描述格式, 这意味着schema信息包含在编码数据中. 这种自描述性使 Avro 能够保持不同版本数据模式之间的兼容性.

2. MessagePack:

• MessagePack 是一种二进制序列化格式, 直接对数据进行编码, 不包含schema信息.


• 它使用长度可变的整数和长度可变的字符串的紧凑二进制表示法, 以尽量减少空间使用.


• MessagePack 不包含schema信息, 因此更适用于schema已预先知道并在发送方和接收方之间共享的情况.

3. BSON:

• BSON 是 JSON 数据的二进制编码, 包括每个值的类型信息.


• BSON 的设计与 JSON 紧密相连, 但它增加了二进制数据类型, 如 JSON 缺乏的日期和二进制数据.


• 与 MessagePack 一样, BSON 不包含schema信息.

这些设计和编码上的差异导致了二进制表示法的不同:

• Avro 包含模式信息并具有自描述性, 这导致二进制大小稍大, 但提供了schema兼容性.


• MessagePack 因其可变长度编码而高度紧凑, 但缺乏模式信息, 因此适用于已知模式的情况.


• BSON 与 JSON 关系密切, 包含类型信息, 与 MessagePack 等纯二进制格式相比, 会增加大小.

总之, 这些差异源于每种格式的设计目标和功能. Avro 优先考虑schema兼容性, MessagePack 注重紧凑性, 而 BSON 则在保持类似 JSON 结构的同时增加了二进制类型. 格式的选择取决于具体的使用情况和要求, 如schema兼容性, 数据大小和易用性.

优化 JSON 性能

JSON 虽然用途广泛, 在Web开发中被广泛采用, 但在速度方面也存在挑战. 这种格式的人类可读性会导致数据负载较大, 处理时间较慢. 因此, 问题出现了: 我们能够怎样优化JSON以使得它更快更高效? 在本文中, 我们将探讨可用于提高 JSON 性能的实用策略和优化方法, 以确保 JSON 在提供应用所需的速度和效率的同时, 仍然是现代 Web 开发中的重要工具.

以下是一些优化 JSON 性能的实用技巧以及代码示例和最佳实践:

1. 最小化数据大小:

• 使用简短, 描述性的键名: 选择简洁但有意义的键名, 以减小 JSON 对象的大小.

// Inefficient

{

  "customer_name_with_spaces": "John Doe"

}



// Efficient

{

  "customerName": "John Doe"

}

• 尽可能缩写:  在不影响清晰度的情况下, 考虑对键或值使用缩写.

// Inefficient

{

  "transaction_type": "purchase"

}

 

// Efficient

{

  "txnType": "purchase"

}

2. 明智地使用数组:

• 最小化嵌套: 避免深度嵌套数组, 因为它们会增加解析和遍历 JSON 的复杂性.

// Inefficient

{

  "order": {

    "items": {

      "item1": "Product A",

      "item2": "Product B"

    }

  }

}



// Efficient

{

  "orderItems": ["Product A", "Product B"]

}

3. 优化数字表示:

• 尽可能使用整数:  如果数值可以用整数表示, 请使用整数而不是浮点数.

// Inefficient

{

  "quantity": 1.0

}



// Efficient

{

  "quantity": 1

}

4. 消除冗余:

• 避免重复数据: 通过引用共享值来消除冗余数据.

// Inefficient

{

  "product1": {

    "name": "Product A",

    "price": 10

  },

  "product2": {

    "name": "Product A",

    "price": 10

  }

}



// Efficient

{

  "products": [

    {

      "name": "Product A",

      "price": 10

    },

    {

      "name": "Product B",

      "price": 15

    }

  ]

}

5. 使用压缩:

• 使用压缩算法:  如何可行的话, 使用压缩算法, 比如Gzip 或者Brotli, 以在传输过程中减少JSON负载大小.

// Node.js example using zlib for Gzip compression

const zlib = require('zlib');



const jsonData = {

  // Your JSON data here

};



zlib.gzip(JSON.stringify(jsonData), (err, compressedData) => {

  if (!err) {

    // Send compressedData over the network

  }

});

6. 采用服务器端缓存:

• 缓存 JSON 响应:  实施服务器端缓存, 以便高效地存储和提供 JSON 响应, 减少重复数据处理的需要.

7. 剖析与优化:

• 剖析性能:  使用剖析工具找出 JSON 处理代码中的瓶颈, 然后优化这些部分.

请记住, 你实施的具体优化措施应符合应用的要求和限制.

真实世界的优化: 在实践中加速

在这一部分, 我们将深入探讨现实世界中遇到 JSON 性能瓶颈并成功解决的应用和项目. 我们将探讨企业如何解决 JSON 的局限性, 以及这些优化为其应用带来的切实好处. 从 LinkedIn 和 Auth0 这样的知名平台到 Uber 这样的颠覆性科技巨头*, 这些示例为我们提供了宝贵的见解, 让我们了解在尽可能利用 JSON 的多功能性的同时提高速度和响应能力的策略.

1. LinkedIn集成Protocol Buffers:

挑战: LinkedIn 面临的挑战是 JSON 的冗长以及由此导致的网络带宽使用量增加, 从而导致延迟增加.
解决方案: 他们在微服务通信中采用了二进制序列化格式 Protocol Buffers 来取代 JSON.
影响: 这一优化将延迟降低了60%, 提高了 LinkedIn 服务的速度和响应能力.

2. Uber的H3地理索引:

• 挑战: Uber 使用 JSON 表示各种地理空间数据, 但解析大型数据集的 JSON 会降低其算法的速度.


• 解决方法 他们引入了H3地理索引, 这是一种用于地理空间数据的高效六边形网格系统, 可减少 JSON 解析开销.


• 影响: 这一优化大大加快了地理空间操作, 增强了 Uber 的叫车和地图服务.

3. Slack的消息格式优化:

• 挑战: Slack 需要在实时聊天中传输和呈现大量 JSON 格式的消息, 这导致了性能瓶颈.


• 解决方法 他们优化了 JSON 结构, 减少了不必要的数据, 只在每条信息中包含必要的信息.


• 影响: 这一优化提高了消息渲染速度, 改善了 Slack 用户的整体聊天性能.

4. Auth0的Protocal Buffers实现:

• 挑战: Auth0 是一个流行的身份和访问管理平台, 在处理身份验证和授权数据时面临着 JSON 的性能挑战.


• 解决方案: 他们采用Protocal Buffers来替代 JSON, 以编解码与身份验证相关的数据.


• 影响: 这一优化大大提高了数据序列化和反序列化的速度, 从而加快了身份验证流程, 并增强了 Auth0 服务的整体性能.

这些真实案例表明, 通过优化策略解决 JSON 的性能难题, 可对应用的速度, 响应和用户体验产生重大积极影响. 它们强调了在各种应用场景中考虑使用替代数据格式和高效数据结构来克服 JSON 相关缓慢的问题的重要性.

总结一下

在开发领域, JSON 是数据交换不可或缺的通用工具. 其人类可读格式和跨语言兼容性使其成为现代应用的基石. 然而, 正如我们在本文中所探讨的, JSON 的广泛应用并不能使其免于性能挑战.

我们在优化 JSON 性能的过程中获得的主要启示是显而易见的:

• 性能至关重要: 在当今的数字环境中, 速度和响应速度至关重要. 用户希望应用能够快如闪电, 即使是微小的延迟也会导致不满和机会的丧失.


• 尺寸至关重要: 数据有效载荷的大小会直接影响网络带宽的使用和响应时间. 减少数据大小通常是优化 JSON 性能的第一步.


• 替代格式: 当效率和速度至关重要时, 探索其他数据序列化格式, 如Protocal Buffers, MessagePack, BSON 或 Avro.


• 真实世界案例: 从企业成功解决 JSON 速度变慢问题的实际案例中学习. 这些案例表明, 优化工作可以大幅提高应用的性能.

在继续构建和增强Web应用时, 请记住要考虑 JSON 对性能的影响. 仔细设计数据结构, 选择有意义的键名, 并在必要时探索其他序列化格式. 这样, 你就能确保你的应用在速度和效率方面不仅能满足用户的期望, 而且还能超越用户的期望.

在不断变化的Web开发环境中, 优化 JSON 性能是一项宝贵的技能, 它能让你的项目与众不同, 并确保你的应用在即时数字体验时代茁壮成长.

我和你一样都经历过 家里蹲 狗都嫌 的尴尬时期，每天早上起来拿着手机不断刷着招聘软件，

海投几百份还是杳无音讯，在BOSS直拒、前程堪忧、失联招聘、猎空之间反复横跳...

还经历了十分灰暗的阶段，焦虑导致出现躯体化反应（头痛、严重失眠、吃不下东西等）

整夜整夜睡不着，躺下脑子都是工作、面试、人生选择带来的压力

不想出门社交，害怕面试。

其实，我想跟你说：裸辞并不是终点。

1.裸辞/辞职并不是终点

当我扛着我的键盘收拾东西离开工位，第一次对辞职的 “人走茶凉” 有了实感，

下午六点跟对我很好的前辈们告了别，公司离地铁有点远，和往常不一样，天还没黑，有黄昏相伴

三号线还是这么挤 还有点闷。

算起来这是第二次辞职，但第一次辞职找了一个礼拜就顺利入职了
，这次好像有点久，今年大家都在说被裁员、大环境差，同学领证成家的也不少。

我意识到人与人的节奏不同，而我好像又一次走到了岔路口，上一次这么慌张还是在高考前

即便我从来没后悔过离职这个决定，但还是会因为面试带来的压力感到局促不安

每次离职就像是一场查漏补缺的大考，对勇气，对储蓄，对知识点的大考

唯有拆迁和认亲能打破这场突如其来的考验。。。啊不是。。。我想说：

唯有行动能打破僵局！！

行动！！！去吃个冰淇淋！！。。。果然有灵感了

短暂的欢愉后，是与台灯的昼夜相守，与简历的交织缠绵

（简历编。。不是。。写不出来呀！！！）

反复改了几版之后确实多了一些“打招呼”的机会，但是实际面试机会还是屈指可数呀，

切！又不是第一次没人要🤡，拒绝我的多的去了，得从巴黎排到广州...

继续努力，等待运气，厚积薄发

2.当知识脱离了考试，真理和美丽才慢慢浮现

2.1 心态调整（分享一下最近对我有帮助的书）

• 《见识》 - 吴军

这是第一年出来工作，遇上了很好的领导送我的书，每当迷茫的时候再拿出来翻翻有了不一样的感悟，很多我们看上去非做不可的事情，其实想通了并没有那么重要，无论在职场上还是在生活中，提高效率都需要从拒绝伪工作开始，有些苦是可以不用吃的，苦难并非造就人类。

幸福是目的，成功是手段

• 《意志力》 - 罗伊·鲍迈斯特

技术行业的人都知道学习是个漫长/终身的事情，跟考公考研短期爆发式集中不同，我们更需要坚持、长期一点点做下去，我认识到所有人的意志力都是有限的，使用就会消耗，压力也并非与动力画等号，人也跟机器一样需要“充电”和合理分配，每个人的节奏和身体承受能力也不同。

• 《被讨厌的勇气》 - 岸见一郎、古贺史健编著

在心情动荡的时期，这本书就像开了一盏加热灯一样在一旁无声陪伴，那会我就像婴儿一样无意识地紧紧抓着自己的头发，直到我睁开眼看见了、意识到了，放下禁锢着工作、生活、交友的课题的手，更能轻松地赶路了。

生活的方式千千万，人生的意义，由我自己决定

• 《法律常识全知道》 - 李桥

读书的时候没有一门跟社会接轨的课程，毕业了也一直专研技术，导致一毕业不知道劳动合同/租房有什么坑，把仲裁和维权看得过于艰难，法律条例密密麻麻 一时间不知从何下手，这本书就很适合我这种来一线城市打工没什么社会经验的小白，用简单的案例植入“NPC游戏”攻略，和《影响力》这本书加一起简直就是进城防骗指南哈哈哈

免费法律援助电话：12348

2.2 前端学习路线图：

各位摸鱼的小伙伴下次见，这篇便是我的2023年终总结：

裸辞不是终点，唯有行动才能打破僵局，当知识脱离了考试，真理和美丽才慢慢浮现。

参考资料：

前端学习路线

我是一个普普通通的前端开发工程师，

除了我的同事，在这个圈子内没人认识我。

“前端开发工程师”，老实讲，我很喜欢这个称呼，我对一些圈外朋友总是这么称呼我自己，当然我的内心和认识我的人都知道，我就是一个“写代码的”。

初见

在2019年，我大专毕业，那时候的学长学姐总和我开玩笑说，以后毕业的我们都会去卖保险，跑销售，那时候的我不以为意，以为只是自我调侃，后来发现人家说的是真的，根本不是开玩笑。我在某大厂做了近3个月的电销，那时候我还是我们班工资最高的人，但不得不说这份职业我根本不喜欢。后来，我大学的班花邓某（真的很漂亮）有一次和我聊天，那阵子她在某大厂做审核。她说她打算去培训前端，问我有没有兴趣。那时候的我觉得计算机啊，编程啊都是精英人群，我这等人也能从事吗？我还打趣的问她，参与前端和高考上清华哪个难？（可见那时候的我对这个想都不敢想）

学习

在19年6月毕业后，我就失业了。我根本想不到大专毕业生能从事什么好的工作，也不清楚我能做些什么。后来我一想，那不妨去培训吧，这样就能和班花做同学，有一起接触的空间和机会了！然后我就开始联系她，但是不得不说，她有强烈的拖延症，她根本对这件事没放在心上。那就自学吧！如果我先学会了，然后等她入门的时候，我就可以教她了！她一定对我刮目相看！嘿嘿！我当时是这样想的没错。我首先找到了培训机构，找他们要到了课程大纲，然后自己逐一的根据大纲上的内容，在网上找视频。不得不说，bilibili大学真的很好用。我的html,css,js都是师承的pink老师，他讲的真的很棒，后来vue就跟着180的科比老师学习，不得不说，这两位的视频对我来说有着举足轻重的作用。那时候第一次学习编程，很多东西都是死记硬背的（切记不要这么做），你很难想象到一个人会去背各种元素的作用以及api。那时候学习的过程还是很快乐的，每天都能接触到新知识，在这就是看着那些视频的进度，想象着看完后自己就能毕业的样子，还是很期待的。甚至说，根据视频模仿了一个很小的功能，然后和自己父母分享的时候，他们都在夸我，现在回想起来，那是我从事前端这么多年来最快乐的时光。

毕业

20年9月的时候，大概经历了近10个月的自学，我决定出山找工作了，我来到了广东。当时我具备的技能有html,css,js,vue2,ts。后来就进入了刷面试题的阶段，有很多面试题完全都是死记硬背的，印象最深刻的就是vue2的响应式原理和nextTick原理，完全是根据百度来的台词去阐述。虽然说现在的我让我自己手写这些都不成问题。不得不说，准备的面试题可以准备，但是项目经验，一些细节可真是苦恼了我。一些对项目，业务比较感兴趣的面试官，我通常都会挂在这里，因为没有任何的工作经验。

我还记得，我面试的第一家公司，是在一个星期天，他们需要找开发小程序的人，最后聊完了技术之后;

面试官：“我看你的简历上写着你上一份工作在武汉有着6k/月，是吗？”

我：“是的”（在这里，我和大多数人一样，包装了，美化了自己的简历）

面试官：“据我所知，不到1年工作经验的专科生，是不可能在武汉有6k/月的，当然这只是我个人的片面的看法，江东自古多才俊嘛”（这就是他的原话，我此生都忘不了）

我内心：“尴尬，脸红，我要逃！快让我走！”

我也还记得，我第一次收获的offer的时候，是一家在CBD，25层高楼的公司，在我毕业以前，我一直都以为能在那里工作的人都是精英，商业大佬。这家公司他让我试岗三天，试岗第一天有个题目是让人手写轮播图和使用element做一个分页功能。我还是通过网友，帮我远程控制我的电脑才完成的这个任务，不过很遗憾，我自己选择了离开这家公司，原因嘛，因为我每天挤不上地铁，再者就是，那家公司气氛感觉很压抑。21年的我还很年轻，有这样的果敢和勇气，如果说24年的我，肯定会忍耐这两点。

第一份工作

2021年3月，在经历过长达3个月的求职经历后，我已经被磨练成了面试机器人。终于找到了一家公司，给我的薪水也很不错，至今我都觉得那家公司是宝藏公司，人数500+，我在那里上班1年没有任何加班经历，需求也非常简单，用vue改改东西，写下静态，一周5天能摸鱼3天。就姑且叫那家公司为X公司吧，还有一个特别搞笑的经历，在X面试的时候，老大问我，“你的项目上有分页查询，这个功能是怎么做的？”，我的回答是：“这个功能是前端做的”。真的很难崩有木有！！！他居然要我了！后来在X的日子，开始过起了神仙般的日子，温饱问题总算是解决了，开始每天接触前端这个圈子，和群友聊天，早上刷各种社交软件。 那时候下班了自己也会回家学习，心里也有一个大牛梦，想着自己能不能做出一些很棒的产品开源出去，就像那些社区圈子的名人一样。还记得那时候跟着视频学习写mini-vue框架，也买了很多课程，觉得投资自己是一笔超值的买卖，然而时至今日那些视频都没有看完。在X公司混到了要转正的那一天，还是蛮忐忑的，结果老大把我单独喊出去谈话，到这里已经开始觉得事情不对了。老大说我的表现还不能满足转正，要继续观察一个月，如果说看到这里，可能很多人会说垃圾公司快跑，但我始终为我当时没有赌气离职感到自豪和开心。

ps：有趣的事，在22年的时候我和带我的女同事都离职了，我们聊天的时候说谈起来这件事，她告诉我，关于我是否能转正的问题，是老大先去问她的意见，问我技术怎么样，她把我夸了一顿。当我知道这个事情的时候，泪目了。

第二份工作

在X公司混了1年左右后，说实在的，我的任务实在是太简单了，上班大多数时间都在摸鱼和自学，没有接触到真正的业务。后来就跑路来到了第二家公司，且叫Y公司吧。在这里我接手的一个项目是从0到1实现的，这正是我想要的，能够完整的学习到项目经验，太妙了。那阵子加班的时间就开始多起来，不过也还挺满意的，能学习到真正的业务。不过这种情况持续了大概半年，新鲜感就退去了，我发现我所做的事情，就是“搬砖”。业务上需要用到什么东西，直接搜一个开源的，然后自己管理一下状态，和后端交互一下，结束了，基本上所有的我参与的业务都是这样的模式，我开始懈怠了，早上每天来了先吃半个小时早饭，然后刷新闻，甚至直到下午才开始做活，因为这些事情实在是太无聊了。在下班后，我开始探索代码的世界，开始着手实现自己刚出道的时候的梦想----实现一个开源产品。那时候的我仿佛就是为了写而去写，我根本不知道要写什么，解决什么样的问题，完全就是照着vue，react这种前端框架去抄，而且实现的非常玩具，没坚持多久就放弃了这个天真的想法。

再见

突然有一天，班花邓某突然联系我了，她告诉我她已经辞职去培训了，问我要不要一起。我得承认，收到她消息的时候小鹿乱撞了，我告诉了她我已经从事前端的工作了，她大为开心，说要我帮帮她，有什么不会的就来问我，我很开心，第一次明白被人需要是什么感受。后来她在培训班毕业了，她让我来面试她，不得不说教她的都是什么妖魔鬼怪，我问她对Vue的理解，她居然背文档说，“vue是一款渐进式框架...”。我问她什么是“渐进式”，她就不知道了。那阵子和她交流了很多，虽然不在一个城市，但还是很开心。另外确实漂亮的女生真的在我们这个行业很有优势，她不到1个月就找到工作，而且她提出期望9k，人家面试官给她10k。

JS为我做的三件事

1. 工作，

这第一件事就是让我有了生存的技能，找到了一份工作，首先是能生存下来了。说真的，在我参加工作之后，程序员人数膨胀之前，我一直都认为程序员是普通家庭的专科生一项比较好的出路，但现在的话的来说，我可能也会偏向于劝退专科生的萌新吧，这张图是我专科，4年工作经验，计算机专业的求职经历，如果你能承担像这样的挫折感的话，并且你比较自律，热爱编程，我也鼓励你坚持梦想！

其实我目前的状态也很难讲，因为这是一个离奇的经历。我们公司最近的效益不太好，可能是我们部门的产品没能带来什么收益，已经开始裁员了，而且很过分的一件事情是，我和我的部门同事，已经3个月没有发薪水了！这件事超级严重，根据过往的经验和数据的话，大概是要凉凉的节奏。

我们部门一个资历比较老的同事，就带头跑路，然后搞的其他人也就跟风，然后吧，好巧不巧，他们问我跑不跑，我深知专科生找工作无比艰难（请参考上面我的BOOS图），我只能相信公司，会好起来的。

这件事无论说到哪里，大家给我的建议都会是立马跑路，然后去仲裁，可能现在看文章的你也是这么想的，但是我很怕，我怕失去工作，我已经适应了现在的环境，我没办法面对接下来的未知挑战，这和我的个人性格有关系，我决定留下来，在赌一下自己的前程，或者等公司裁掉我，没准还有补偿不是吗？

好巧不巧，我们部门资历老的全跑了，老大让我来当老二了，我听到这个消息的时候是懵逼的，老大给我布置了一系列的任务，包括架构一下前端，招人等事宜，我提道工资呢？老大说会给你发的，公司在等机会。也就是典型的加量不加价，其实今天为什么能来更新这篇文章，也是因为我来架构前端，打算在掘金调研一套eslint规则，因为这里的大佬比较多，技术文章质量也还是很高的。

我想到这里，其实觉得我的平台，舞台也是蛮大的，发挥的机会很多，（虽然没发工资）。于是乎我提出了一系列计划上报了老大，包括技术从Vue2转到react18,前端组件库改用storybook等。除了使用react18这套方案被否决了，其余的也都通过了。

说真的，对这份工作的未来也是有极高的不确定性，如果你不敢承受10%的暴跌，那就会错过1%的大涨，不是吗？

2. 爱情，

我在2023年的时候，在某书上认识了一个江西的女生，我们聊的很投缘，我们甚至是一个大学毕业的，她在武汉上的大学。我们有着共同的爱好，经常聊天就是半天的时间就过去了。而且，我们经常分享自己的一些身边事给对方，一些实事的热点新闻的看法，我们也出奇的一致，她在朋友圈发的照片也很好看，有一次，我给她发消息，她过了一段时间没有回复我，我就开始想着，她在干嘛，为什么还没有回，开始焦急，情绪被左右了，我明白了，我确实喜欢他了。

当从朋友，也可能是网友的关系，变成了爱慕的时候，我对她的态度就变了，我开始变得很有占有欲，开始看她某书下的评论有没有其他男孩子，那阵子的我，真的很丑陋。

我开始着急了，我决定更近一步试探一下，我邀请她一起玩某某荣耀，她也答应的很爽快，那时候我还以为我成功了，有戏！没想到，当天，我上号后，她邀请我，我发现！她居然带了她闺蜜和一个男生，我纯纯无语。。。而且游戏过程中，他们三个互动比较多，基本上我就是路人甲，那晚挺失望的反正。

到了她的生日，我说我送你一个生日礼物吧！她也婉拒了，从那时候开始，我们的距离就变得远了。到今天，2024，3，27号，我们大概40多天没说过话了。

到这里，和js有什么关系呢？

我即将告诉你我人生中，做的最小丑的决定

我想的是，女生都比较幕强，我要给她展现一个技术大佬的人设！没错，在某个夜晚我是这么想的，晚上下班后，我上某里云租了一个最便宜的服务器，然后用express + react.js（没错，我个人更喜欢react，这也是我为什么尝试说服领导转react的原因，hhh）花了一晚上时间，写了一个聊天室功能，还内置了许多她喜欢的东西作为背景，icon，logo，然后我部署在了服务器上。

第二天，我立马把域名分享给她，期待她的回复！还俏皮的说，能打败微信吗？我以为这样，她会对我五体投地的佩服，结果她只回了一个 “6”，然后补充“哈哈哈哈哈哈”

那时候我觉得，她是对这种技术不感冒，她只对迪士尼和追星有兴趣，她每周都会去迪士尼和一只小狐狸合影，请注意是每周。而且她会追每一个在她城市开演唱会的人，某杰，某谦，某棋。我以为她是喜欢这些，后来我才发现，她其实是对我没兴趣而已，意识到我越界了，有意疏远我。

3. 开源，

我用js尝试写过很多开源，也想成为一个为社区有过贡献的人，但后来发现根本没什么用，自己无论写什么，都已经有了前人的库，比我好，比我成熟，比我火。我最近一直在思考，如果我把学习这些，折腾这些的时间用来学习一门其他的事情，比如吉他，或者打游戏，我会不会更快乐？都说1-3年的前端交流群里都在聊技术，4-5年都在聊业务，5年以上的都在聊家庭和钓鱼，看得出，这就是现实，极少有人能从技术中脱颖而出，我也认清了自己。

一、背景

转转集团旗下有多款APP产品，随着业务发展，各APP发版频率变高。在持续交付的背景下，渠道包更新存在以下几个效率问题：

（1）Android渠道包提交应用市场审核，工作重复&人工成本高  

（2）公司目前存在多个APP、需更多人支持，有培训成本

（3）每次发版需要人工通知项目成员渠道包审核进度 

  针对以上问题，我们设计开发了渠道包自动更新后台，用来解决渠道更新的效率问题。

二、方案调研

1、基于业务现状，做了技术调研和逻辑抽象

  不同APP支持的渠道不同，不同渠道更包api不同，如下图：

针对以上调研结果，我们将通用的逻辑统一封装开发，将差异点进行配置，做到灵活配置可扩展。

2、整体的实现方案演变

初期方案，每个应用市场单独提审（需要先选择物料，选好物料后上传包文件，文件上传成功后再点击提交审核），多个应用市场需要重复该操作。

上线运行了一段时间后，发现存在一些问题：单个市场提交步骤繁琐、多个应用市场需要分开多次提交。这些步骤是重复且可简化的，因此我们又对提审的过程做了封装，提供批量上传的入口，简化交互过程，做到一键提审。以下是当前运行的第二版方案：

第二版方案上线后，提审同学只需要在入口处选择要更新的应用市场，然后一键上传全部物料，再点击提审按钮即可提审成功。代码内部会处理具体的逻辑，比如：根据配置规则将物料匹配到对应市场、自动匹配包文件进行提审。

三、方案设计

自动上传包含以下核心模块：

• APP管理：支持配置多个APP信息，包括转转、找靓机、采货侠等


• 包管理：支持下载不同渠道，不同版本的包


• 物料管理：包括历史物料的选择，和新增物料的存储（icon、市场截图）


• 提交审核：包括包下载、物料下载，支持按照APP配置账号密码提交审核


• 消息提醒：对提交的结果和审核的结果进行消息通知

实现效果：

提审前信息确认，选择APP，可选择单个或者多个渠道，系统自动选择包地址，用户选择物料后可一键提审多应用市场。操作简单便捷，使用成本低

提审后发送消息通知，便于各方了解渠道的审核结果，对审核异常信息进行及时干预。同时自动存储不同版本的审核记录，方便后续分析。

四、总结

渠道包自动更新功能，节省了大量的提交审核人力成本，打通了Android整体的持续交付过程，降低了人工学习成本。之后我们也会针对各种体验问题进行不断的改进和更新～

大家好，本篇文章仍然聊聊kotlin官方做的一些优化工作，主要包括以下三个方面：

接下来就带大家介绍下上面三个特性。

一. 数据对象data object的支持

该特性由kotlin1.7.20插件版本提供，并处于实验阶段。

这个特性主要是和原来的object声明的单例类的toString()方法输出有关，在了解这个特性之前，我们先看下下面一个例子：

object Single1



fun main() {

    println(Single1)

}

输出：

这个输出本质上就是一个类名、@、地址的拼接，有时候你想要打印输出的仅仅是类名，就得需要重写下toString()方法：

object Single1 {



    override fun toString(): String {

        return "Single1"

    }

}

然后再看一个密封类的例子：

sealed interface Response {

    

    data class Success(val response: String): Response

    

    data class Fail(val error: String): Response

    

    object Loading : Response

    

}



fun main() {

    println(Response.Success("{code: 200}"))

    println(Response.Fail("no net"))

    println(Response.Loading)

}

输出：

可以看到，大家都是密封子类，但就这个Loading类的输出比较"丑陋"，没有上面两个兄弟类的输出简洁清爽。

接下来我们就要介绍下主人公数据对象data object了，这个东西其实使用起来和object一模一样，核心的区别就是前者的toString() 更加简洁。

接下来从一个例子一探究竟：

data object Single2



fun main() {

    println(Single2)

}

看下输出：

输出是不是比上面的object Single1更加简单明了。最重要的是在密封类中使用效果更加，我们把上面密封类Loading声明为data object：

    data object Loading : Response

看下最终的输出结果：

这下子输出结果是不是清爽更多！！

讲完了应用，我们再java的角度看下其背后的实现机制，相比较于object，data object会多了下面这三个重写方法：

public final class Single2 {

    

   @NotNull

   public String toString() {

      return "Single2";

   }



   public int hashCode() {

      return -535782198;

   }



   public boolean equals(@Nullable Object var1) {

      if (this != var1) {

         if (!(var1 instanceof Single2)) {

            return false;

         }



         Single2 var2 = (Single2)var1;

      }



      return true;

   }

}

我们需要关心的toString()方法就是直接重写返回了当前的类名。

如果想要使用这个特性，我们只需要增加如下配置即可：

compileKotlin.kotlinOptions {

    languageVersion = "1.9"

}

二. @Repeatable注解优化

该特性由kotlin1.6.0插件版本提供优化。

在了解这个特性之前，我们先回忆下@Repeatable这个注解在java中的使用：

如果一个注解在某个方法、类等等上面需要重复使用，那就需要@Repeatable帮助。

• 首先定义需要重复使用的注解

@Retention(RetentionPolicy.RUNTIME)

@Target(ElementType.TYPE)

@Repeatable(Fruits.class)

public @interface Fruit {

    String name();

    String color();

}

• 然后定义注解容器，用来指定可重复使用的注解类型

@Retention(RetentionPolicy.RUNTIME)

@Target(ElementType.TYPE)

public @interface Fruits {

    Fruit[] value();

}

然后就可以在代码中这样使用：

@Fruits({

        @Fruit(name = "apple", color = "red"),

        @Fruit(name = "origin", color = "yellow"),

})

public class Detail {

}

大家有没有发现，可重复注解定义起来还是由一丢丢的麻烦，接下来轮到我们kotlin重磅出击了。先看下面一个例子：

@Repeatable 

annotation class Animal(val name: String)

在kotlin中我们只要声明一个需要重复使用的注解即可，kotlin编译器会自动帮助我们生成注解容器@Animal.Container，然后我们就能在代码中这样使用：

@Animal(name = "dog")

@Animal(name = "horse")

public class Detail {

}

是不是非常简单便捷了。

如果你偏要显示指明一个包含注解，也可以，通过以下方式即可实现：

@JvmRepeatable(Animals::class)

annotation class Animal(val name: String)



annotation class Animals(val value: Array)

然后除了上面的使用方式，你在kotlin中还可以这样使用：

@Animals([Animal(name = "dog"), Animal(name = "dog")])

class Detail {

}

请注意：

另外，其实这个特性kotlin早就支持了，只不过kotlin1.6.0插件版本之前，kotlin这个特性只只支持RetentionPolicy.SOURCE生命周期的注解，并且还和java的可重复注解不兼容。

总结

这两个小技巧相信在大家日常开发中还是比较实用的，希望本篇能对你有所帮助。

参考文章：

Improved string representations for singletons and sealed class hierarchies with data objects

Repeatable annotations with runtime retention for 1.8 JVM target

1.Android Room 数据库的坑

在用Room数据库的时候 发现有需要一个字段的条件合到一起去写这个SQL

 @Query("SELECT * FROM 表名 WHERE 字段A = '1' and 字段B <= :Time " +

            "and 字段B >= :Time and 字段C <= :BTime and 字段C >= :BTime " +

            "and '(' || 字段D is null or 字段D = '' || ')'")

    List selectList(String Time, String BTime);

这里面的 “ ||” 是Room里面独特的表达方式 是替代了java里面的“+”号

正常在android中 使用 是这样的

String sql = "SELECT * FROM 表名 WHERE 字段A = '1' and 字段B <= "+传入的参数+" " +

            "and 字段B >= "+传入的参数+" and 字段C <= "+传入的参数+" and 字段c >= "+传入的参数+" " +

            "and '(' "+" 字段D is null or 字段D = '' "+" ')'"





cursor = db.rawQuery(sql, null);

而在Room 中 用 “||” 代替了 “+”

2.Android Room 查询语句的坑

@Query("SELECT * FROM 表名 WHERE 字段A = '0' order by id desc")

List selectList();

假如你正在查询一张表的面的内容,然后忽然跑出来一个异常

# [Android RoomDatabase Cruash "Cursor window allocation of 4194304 bytes failed"](https://stackoverflow.com/questions/75456123/android-roomdatabase-cruash-cursor-window-allocation-of-4194304-bytes-failed)

奔溃日志:

android.database.CursorWindowAllocationException: Could not allocate CursorWindow '/data/user/0/cn.xxx.xxx/databases/xxx.db' of size 2097152 due to error -13.

	at android.database.CursorWindow.nativeCreate(Native Method)

	at android.database.CursorWindow.(CursorWindow.java:139)

	at android.database.CursorWindow.(CursorWindow.java:120)

	at android.database.AbstractWindowedCursor.clearOrCreateWindow(AbstractWindowedCursor.java:202)

	at android.database.sqlite.SQLiteCursor.fillWindow(SQLiteCursor.java:147)

	at android.database.sqlite.SQLiteCursor.getCount(SQLiteCursor.java:140)

	at yd.d.m(SourceFile:21)

	at cn.xxx.control.y.y0(SourceFile:1)

	at e5.y.p(SourceFile:230)

	at e5.y.l(SourceFile:1)

	at e5.y.E(SourceFile:1)

	at cn.xxx.cluster.classin.viewmodel.SessionViewModel$d.invokeSuspend(SourceFile:42)

触发原因

• Room 对应的 Sqlite 数据库，其对 CursorWindows 分配的大小是有限制的，最大为 2M，超过之后会发生上述崩溃闪退现象（偶现且难以复现的 bug）

解决方法

需要业务方梳理这块的业务，优化数据库的调用，如果明确知道在一个方法里面会调用多个数据库的方法，需要让 controller 提供新的方法，且这个 controller 层的方法需要添加 @Transaction 进行注解，从而保证在同一个事物内进行数据库操作，以此避免 CursorWindows 大小超过 2M

那么问题来了 @Transaction 这个注解是干嘛的呢

翻译 事务的意思

@Transaction

@Query("SELECT * FROM 表名 WHERE 字段A = '0' order by id desc")

List selectList();

接着 问题完美解决

今天想和大家分享的一个技术是 SSE 流式传输 。如标题所言，通过 SSE 流式传输的方式可以让我们不再通过轮询的方式获取服务端返回的结果，进而提升前端页面的性能。

对于需要轮询的业务场景来说，采用 SSE 确实是一个更好的技术方案。

接下来，我将从 SSE 的概念、与 Websocket 对比、SSE 应用场景多个方面介绍 SSE 流式传输，感兴趣的同学一起来了解下吧！

什么是 SSE 流式传输

SSE 全称为 Server-sent events , 是一种基于 HTTP 协议的通信技术，允许服务器主动向客户端（通常是Web浏览器）发送更新。

它是 HTML5 标准的一部分，设计初衷是用来建立一个单向的服务器到客户端连接，使得服务器可以实时地向客户端发送数据。

这种服务端实时向客户端发送数据的传输方式，其实就是流式传输。

我们在与 ChatGPT 交互时，可以发现 ChatGPT 的响应总是间断完成。细扒 ChatGPT 的网络传输模式，可以发现，用的也是流式传输。

SSE 流式传输的好处

在 SSE 技术出现之前，我们习惯把需要等待服务端返回的过程称为长轮询。

长轮询的实现其实也是借助 http 请求来完成，一个完整的长轮询过程如下图所示：

从图中可以发现，长轮询最大的弊端是当服务端响应请求之前，客户端发送的所有请求都不会被受理。并且服务端发送响应的前提是客户端发起请求。

前后端通信过程中，我们常采用 ajax 、axios 来异步获取结果，这个过程，其实也是长轮询的过程。

而同为采用 http 协议通信方式的 SSE 流式传输，相比于长轮询模式来说，优势在于可以在不需要客户端介入的情况下，多次向客户端发送响应，直至客户端关闭连接。

这对于需要服务端实时推送内容至客户端的场景可方便太多了！

SSE 技术原理

1. 参数设置

前文说到，SSE 本质是一个基于 http 协议的通信技术。

因此想要使用 SSE 技术构建需要服务器实时推送信息到客户端的连接，只需要将传统的 http 响应头的 contentType 设置为 text/event-stream 。

并且为了保证客户端展示的是最新数据，需要将 Cache-Control 设置为 no-cache 。

在此基础上，SSE 本质是一个 TCP 连接，因此为了保证 SSE 的持续开启，需要将 Connection 设置为 keep-alive 。

Content-Type: text/event-stream

Cache-Control: no-cache

Connection: keep-alive

完成了上述响应头的设置后，我们可以编写一个基于 SSE 流式传输的简单 Demo 。

2. SSE Demo

服务端代码：

const express = require('express');

const app = express();

const PORT = 3000;



app.use(express.static('public'));



app.get('/events', function(req, res) {

    res.setHeader('Content-Type', 'text/event-stream');

    res.setHeader('Cache-Control', 'no-cache');

    res.setHeader('Connection', 'keep-alive');



    let startTime = Date.now();



    const sendEvent = () => {

        // 检查是否已经发送了10秒

        if (Date.now() - startTime >= 10000) {

            res.write('event: close\ndata: {}\n\n'); // 发送一个特殊事件通知客户端关闭

            res.end(); // 关闭连接

            return;

        }



        const data = { message: 'Hello World', timestamp: new Date() };

        res.write(`data: ${JSON.stringify(data)}\n\n`);



        // 每隔2秒发送一次消息

        setTimeout(sendEvent, 2000);

    };



    sendEvent();

});



app.listen(PORT, () => {

    console.log(`Server running on http://localhost:${PORT}`);

});

客户端代码：

<!DOCTYPE html>

<html lang="en">



<head>

    <meta charset="UTF-8">

    <title>SSE Example</title>

</head>



<body>

    <h1>Server-Sent Events Example</h1>

    <div id="messages"></div>



    <script>

        const evtSource = new EventSource('/events');

        const messages = document.getElementById('messages');



        evtSource.onmessage = function(event) {

            const newElement = document.createElement("p");

            const eventObject = JSON.parse(event.data);

            newElement.textContent = "Message: " + eventObject.message + " at " + eventObject.timestamp;

            messages.appendChild(newElement);

        };

    </script>

</body>

</html>

当我们在浏览器中访问运行在 localhost: 3000 端口的客户端页面时，页面将会以 流式模式 逐步渲染服务端返回的结果：

需要注意的是，为了保证使用 SSE 通信协议传输的数据能被客户端正确的接收，服务端和客户端在发送数据和接收数据应该遵循以下规范：

服务端基本响应格式

SSE 响应主要由一系列以两个换行符分隔的事件组成。每个事件可以包含以下字段：

data：事件的数据。如果数据跨越多行，每行都应该以data:开始。

id：事件的唯一标识符。客户端可以使用这个ID来恢复事件流。

event：自定义事件类型。客户端可以根据不同的事件类型来执行不同的操作。

retry：建议的重新连接时间（毫秒）。如果连接中断，客户端将等待这段时间后尝试重新连接。

字段之间用单个换行符分隔，而事件之间用两个换行符分隔。

客户端处理格式

客户端使用 EventSource 接口监听 SSE 消息：

const evtSource = new EventSource('path/to/sse');

evtSource.onmessage = function(event) {

    console.log(event.data); // 处理收到的数据

};

SSE 应用场景

SSE 作为基于 http 协议由服务端向客户端单向推送消息的通信技术，对于需要服务端主动推送消息的场景来说，是非常适合的：

SSE 兼容性

可以发现，除了 IE 和低版本的主流浏览器，目前市面上绝大多数浏览器都支持 SSE 通信。

SSE 与 WebSocket 对比

看完 SSE 的使用方式后，细心的同学应该发现了：

SSE 的通信方式和 WebSocket 很像啊，而且 WebSocket 还支持双向通信，为什么不直接使用 WebSocket ？

下表展示了两者之间的对比：

可以发现，SSE 与 WebSocket 各有优缺点，对于需要客户端与服务端高频交互的场景，WebSocket 确实更适合；但对于只需要服务端单向数据传输的场景，SSE 确实能耗更低，且不需要客户端感知。

参考文档

developer.mozilla.org/zh-CN/docs/…

需求场景

我们在开发应用的时候经常会遇到先登录，登录成功后再跳转到目标页面。比如商品详情页面我们点击购买必须要先登录，登录完成才能去下单支付。针对这种场景，我们一般有两种做法：

第一种我们就不谈了产品经理不同意🐶。第二种我们一般是在 onActivityResult 里面获取到登录成功，然后根据 code 跳转到目标页面。这种方式缺点就是我们要在每个页面都处理相同的逻辑还有定义各种 code，如果应用里面很多这种场景也太繁琐了。那有没有统一的方式去处理这种场景就是我们今天的主题了。

封装方式

我们的应用是组件化的，APP 的页面跳转使用了 Arouter。所以我们统一处理使用 Arouter 封装。直接上代码

fun checkLoginToTarget(postcard: Postcard) {//Postcard 是 Arouter 的类

    if (User.isLogin()) {

        postcard.navigation()

    } else {

        //不能使用 postcard 切换 path 直接跳转，因为 group 可能不同，所以重新 build

        ARouter.getInstance().build(Constant.LOGIN)

            .with(postcard.extras)//获取携带的参数重新转入

            .withString(Constant.TAGACTIVIFY, postcard.path)//添加目标路由

            .navigation()

    }

}

//登录成功后在登录页面执行这个方法

fun loginSuccess() {

    val intent= intent

    val target = intent.getStringExtra(Constant.TAGACTIVIFY)//获取目标路由

    target?.apply { 

        if (isNotEmpty()){

            val build = ARouter.getInstance().build(this)

            val extras = intent.extras//获取携带的参数

            if (extras != null) {

                build.with(extras)

            }

            build.navigation()

        }

    }

    finish()

}

代码加了注释，使用 Kotlin 封装了顶层函数，登录页面在登录成功后跳转到目标页面，针对上面的场景直接调用 checkLoginToTarget 方法。

checkLoginToTarget(ARouter.getInstance().build(Constant.PAY_PAGE).withInt(Constant.GOOD_ID,id))

通过 Arouter 传入下单支付的路由地址，并且携带了商品的 ID，生成了 Postcard 参数。登录成功后能带着商品 ID
直接下单支付了。

最后

如果项目里没有使用路由库可以使用 Intent 封装实现，或者别的路由库也可以用上面的方式去做统一处理。

哈喽,大家好 我是 xy👨🏻‍💻。今天我们来聊聊一个面试时超级敏感但又不得不面对的问题——离职原因💢

找工作面试被问离职原因，千万不要直接说出你为什么从上家公司离职的真实原因！！！

当老实人要吃亏的！！！

其实，大部分真实的离职原因都是每家公司或多或少会遇到的，但如果直接说出来，很可能会让面试官担心你入职后也会因为同样的原因离职哦！💢

😉 所以，作为一个聪明的求职者，我们应该如何回答这个问题呢？

6 个常见的离职原因

首先，让我们来看看这 6 个常见的离职原因❌，以及它们的“禁忌”回答方式吧！🚫

🎯 工资太低

🚫 禁忌回答：因为前公司给的工资太低了，我实在是受不了了。

🎯 加班严重

🚫 禁忌回答：前公司加班太严重了，我身体都垮了。

🎯 领导傻 X

🚫 禁忌回答：前领导简直就是个傻 X，根本不懂管理。

🎯 被裁员

🚫 禁忌回答：我之前的公司裁员，我被无辜波及了。

🎯 无法升职

🚫 禁忌回答：我在前公司干了几年，但一直升不上去。

🎯 同事相处不和谐

🚫 禁忌回答：前公司的同事们都太奇葩了，我实在受不了。

👀 看到了吗？这些回答都是大忌，因为它们会让 HR 觉得你不稳定、有负面情绪、甚至可能是个问题员工。那么，正确的回答方式是什么呢？别急，我们接着往下看！✅

🎯 工资太低

✅ 回答模板：HR 您好!我过去 2 年，在公司和领导的帮助下，我在技术和能力方面有了很大提升，为公司开发的各种工具和库，极大地提高了项目开发效率，领导对我很认可，但公司的薪资结构有一些硬指标，无法满足我的涨薪需求，所以想看看市场上的新机会，寻找一个可以长期稳走发展的平台。

🎯 加班严重

✅ 回答模板：HR 您好!在上家公司，我的工作效率较高，能按时保质保量地完成工作，但前司会定期统计加班时长，并以此进行考核，导致大部分人为了加班而加班，效率非常低，我个人并不反对加班，但这种低效的常态化 996，我并不认可，我希望能在更人性化管理的公司里发挥优势。

🎯 领导傻 X（这个有点难，但我们可以尽量委婉）

✅ 回答模板：HR 您好!因为前公司的工作职贵划分比较固定，每个人负责的业务比较少，对于所负责的开发工作，我已经没有什么新知识可以学的了，我希望职业生涯是一个持续的学习和提升的过程，并且在自己具备了相关业务技能经验后，也想迎接一些新的挑战。

🎯 被裁员

✅ 回答模板：HR 您好!前公司当时在进行业务调整，公司想让我调到其他业务线上，岗位职责也发生了变化，我觉得自己还是很擅长做前端工具链方向的开发，并且也在这块积累了几年经验，还是想继续在这个方向上深耕，因此出来看看机会。

🎯 无法升职

✅ 回答模板：HR 您好!前公司管理比较扁平，虽然一直被领导重用，也负责过多个核心业务，但是职级几年来来一直没有变化。领导也争取过，但由于工作年限等原因，没能通过。我不想安于现状，想找一个更能发挥自己才能的平台。

🎯 同事相处不和谐

✅ 回答模板：HR 您好!我之前在前司能力不错，取得了不错的成绩，但由于分工不太合理，出现了很多扯皮现象和低效沟通，影响到了工作效率，有时甚至会影响整个项目的进度，内耗较大，所以决定离开，希望找一个氛国好团队长期发展。

💡 记住了吗？面试时回答离职原因的关键在于：不要贬低前司和前同事、不要让 HR 觉得是你的问题、也不要吐槽前司的任何不足。掌握这些要领，相信你在面试中一定能够游刃有余地应对这个问题啦！

需求背景

前几天，甲方提了个需求，想让下面的数据循环展示，准备放在他们集团首页给他们领导演示用。

我们领导很重视这个事儿，拍了拍我，语重心长的说，小伙子，好好做。

我啪的一下就兴奋了，老板居然如此器重我，我必当鞠躬尽瘁，减少摸鱼，我要让老板拜倒在精湛的技术下！

于是，我搬出自己的库存代码，仅2min就实现了数据的滚动：

没错，我直接照搬了自己以前写过的文章：JS实现可滚动区域自动滚动展示 - 掘金

就在我准备告诉老板我做完了的时候，我突然想了想，这么快做完，老板一定觉得我没好好做，我以后还怎么升职加薪，赢取白富美？

于是，我连夜研究，终于改进了数据滚动方式，赢得了老板的大饼（以后涨500）。最终效果：

技术方案

技术选型

观察最终效果图，可以发现这其实就是一个数据循环滚动的效果，每条内容之间间隔1000ms，每条出现动的时间为500ms。用术语来说，这就是一个单步停顿滚动效果。

我百度了一下，社区还是有这个实现的现成方案的：vue-seamless-scroll，周下载也还行。

于是，我果断试了试，结果不知道什么原因，并不生效...

既然如此，直接手写一个吧！

实现思路

要实现上述效果其实很简单，如图

我们创造一个含有六个值的数组，每隔一段时间循环更改黄色区域的数据，当黄色区域数据变成最新的时候，红色区域整体向下移动，当有数值超出滚动区域后，在删除这个数据即可。

数据更新

如果不考虑动画，我们的代码应该这么写

<template>

    <div class="item-wrap" v-for="(item, index) in animationData">

          <!-- 模块内容 -->     

     </div>

</template>

<script setup lang="ts">

// #假设这是接口请求的10条最新数据

const allCarouseData = ref([1, 2, 3, 4, 5, 6, 7, 8, 9, 10])

// #需要轮播的数据

const animationData = ref<any>([])

// *定时器

const animationTimerMeta: any = {

    timer: null,

    // 这个函数负责设置轮播数据的更新逻辑。

    timeFuc() {

        let setTimeoutId: any = null

        if (this.timer) return

        this.timer = setInterval(() => {

            // 取轮播数据的第一条id

            let firstId = animationData.value[0].id

            // 为轮播数据添加最新的第一项数据 

            let index = allCarouseData.value.findIndex((res: any) => res.id === firstId)

            let addIndex = index - 1 < 0 ? allCarouseData.value.length - 1 : index - 1

            animationData.value.unshift(allCarouseData.value[addIndex])

            setTimeout(() => {

                // 删除数组的最后一项

                animationData.value.pop()

            }, 1000)

            

        }, 1500)

    }

}

animationData.value = allCarouseData.value.slice(-5)

animationTimerMeta.timeFuc()

</script>

上述代码的主要功能是：

上述代码没有实现动画，他的效果是这样的：

动画添加

<template>

    <div class="item-wrap" v-for="(item, index) in animationData" 

    :class="[{ moveToBottom: animationActive }, { show: animationActive && index === 0 }]"

    >

          <!-- 模块内容 -->     

     </div>

</template>

<script setup lang="ts">

// #假设这是接口请求的10条最新数据

const allCarouseData = ref([1, 2, 3, 4, 5, 6, 7, 8, 9, 10])

// #需要轮播的数据

const animationData = ref<any>([])

// #是否开启动画

const animationActive = ref(false)

// *定时器

const animationTimerMeta: any = {

    timer: null,

    // 这个函数负责设置轮播数据的更新逻辑。

    timeFuc() {

        let setTimeoutId: any = null

        if (this.timer) return

        this.timer = setInterval(() => {

            // 取轮播数据的第一条id

            let firstId = animationData.value[0].id

            // 为轮播数据添加最新的第一项数据 

            let index = allCarouseData.value.findIndex((res: any) => res.id === firstId)

            let addIndex = index - 1 < 0 ? allCarouseData.value.length - 1 : index - 1

            animationData.value.unshift(allCarouseData.value[addIndex])

            setTimeout(() => {

                // 删除数组的最后一项

                animationData.value.pop()

            }, 1000)

            

        }, 1500)

    }

}

animationData.value = allCarouseData.value.slice(-5)

animationTimerMeta.timeFuc()

</script>





@keyframes moveToBottom {

    0% {

        transform: translateY(-47px);

    }



    100% {

        transform: translateY(0);

    }

}



.moveToBottom {

    animation: moveToBottom 500ms ease-in-out forwards;

}



@keyframes fadeInFromTop {

    0% {

        opacity: 0;

        transform: translateY(-47px);

    }



    100% {

        opacity: 1;

        transform: translateY(0);

        color: #683BD6;

    }

}



.show {

    animation: fadeInFromTop 500ms ease-in-out forwards;

}

上述代码中，为了实现动画效果，采用了动态添加类名的技术方案。

animationData 数组中的元素会按照一定顺序进行显示和隐藏，同时伴随有动画效果。当第一个元素进入视图时，它会应用 fadeInFromTop 动画；其他元素会应用 moveToBottom 动画。通过定时器，元素会定期从 allCarouseData 中获取新的数据并更新 animationData。

代码释义：

• moveToBottom: 当 animationActive 为真值时，此类名会被添加到 div 上。


• show: 当 animationActive 为真值且当前元素是数组的第一个元素时，此类名会被添加到 div 上。

CSS 释义：

• moveToBottom 动画:

定义一个名为 moveToBottom 的关键帧动画，使元素从上方移动到其原始位置。

moveToBottom 类将此动画应用到元素上。

• fadeInFromTop 动画:

定义一个名为 fadeInFromTop 的关键帧动画，使元素从上方淡入并改变颜色。

show 类将此动画应用到元素上。

通过上述简单的实现方式，就能最终实现我们想要的效果

相比于普通滚动，这种方式看起来要好很多！

结语

要想实现这种单步停帧的效果，其实有很多实现方式，这只是笔者实现的一种，核心逻辑就是动态改变数据、增添类名。如果大家还有更好的方式，也欢迎大家指点。

本人写了五年的后台管理。每次面试前就会头疼，因为写的页面除了表单就是表格。抱怨过苦恼过也后悔过（虽然我现在已经心安理得的摆烂），但是站在现在的时间点回想以前，发现有很多事情可以做的更好，于是有了这篇文章。

写优雅的代码

一道面试题

大概两年以前，面试美团的时候，面试官让我写一道代码题，时间单位转换。具体的题目我忘记了。

原题目我没做过，但是我写的业务代码代码里有类似的单位转换，后端返回一个数字，单位是kb，而我要展示成 KB，MB 等形式。大概写一个工具函数（具体怎么写的忘记了，不过功能比这个复杂点）：

function formatSizeUnits(kb) {

    let units = ['KB', 'MB', 'GB', 'TB', 'PB'];

    let unitIndex = 0;



    while (kb >= 1024 && unitIndex < units.length - 1) {

        kb /= 1024;

        unitIndex++;

    }



    return `${kb.toFixed(2)} ${units[unitIndex]}`;

}

而在此之前，是一个后端同学写的代码（说起来，后台管理系统前端人力不够后端帮忙写好像是常规操作，后端总觉得写前端简单，而我只能说你们那代码写的，一言难尽……），如下：

function formatSizeUnits(kb) {

    var result = '';



    if (kb < 1024) {

        result = kb + ' KB';

    } else if (kb < 1024 * 1024) {

        result = (kb / 1024).toFixed(2) + ' MB';

    } else if (kb < 1024 * 1024 * 1024) {

        result = (kb / 1024 / 1024).toFixed(2) + ' GB';

    } else {

        result = (kb / 1024 / 1024 / 1024).toFixed(2) + ' TB';

    }



    return result;

}

虽然功能都一样，但是我写在面试的时候写了上面的代码得到了面试官的赞扬，也因此非常顺利的通过了面试。而如果我写成了下面的样子，估计不会有这种效果。

如何提升代码质量

想提升代码质量，最理想的是靠 code review ，但实际上这玩意在大多数公司根本就不存在。其次就只能多看看大佬们写的代码，但是一来后台管理本来就没太大难度很少有大佬，二来很多时候一个后台管理系统就一两个人负责。

还好现在有了各种 AI 工具，可以非常方便的优化自己的代码了。

还是上面的问题，看看 GPT 给的答案

// 提问：写一个工具函数，对文件大小的单位进行转换，加注释

// 回答：下面是一个JavaScript工具函数，它接受文件大小、初始单位、目标单位和小数位数，然后返回目标单位下的文件大小。



/**

 * 将文件大小从一个单位转换为另一个单位。

 *

 * @param {number} size 文件大小。

 * @param {string} fromUnit 初始单位（'B', 'KB', 'MB', 'GB', 'TB', 'PB', 'EB', 'ZB', 'YB'）。

 * @param {string} toUnit 目标单位（'B', 'KB', 'MB', 'GB', 'TB', 'PB', 'EB', 'ZB', 'YB'）。

 * @param {number} [decimalPoint=2] 结果保留的小数位数，默认为2。

 * @return {string} 转换后的文件大小，带单位。

 */

function convertFileSize(size, fromUnit, toUnit, decimalPoint = 2) {

  // 定义单位与字节之间的转换关系

  const units = ['B', 'KB', 'MB', 'GB', 'TB', 'PB', 'EB', 'ZB', 'YB'];

  // 获取初始单位和目标单位的索引

  const fromIndex = units.indexOf(fromUnit);

  const toIndex = units.indexOf(toUnit);



  // 如果单位不在列表中，抛出错误

  if (fromIndex === -1 || toIndex === -1) {

    throw new Error('Invalid units');

  }



  // 计算初始单位与目标单位之间的转换系数

  const exponent = toIndex - fromIndex;

  // 计算结果大小

  const resultSize = size / Math.pow(1024, exponent);



  // 返回格式化后的结果

  return parseFloat(resultSize.toFixed(decimalPoint)) + ' ' + toUnit;

}



// 示例使用

console.log(convertFileSize(1, 'GB', 'MB')); // 输出: 1024.00 MB

console.log(convertFileSize(1, 'MB', 'KB')); // 输出: 1024.00 KB

console.log(convertFileSize(1, 'KB', 'B'));  // 输出: 1024.00 B

console.log(convertFileSize(1, 'MB', 'GB', 5)); // 输出: 0.00098 GB

还能说什么，我只能说 NB！（经评论区提示，此段代码可能有问题，建议大家在使用AI工具时，重点是借鉴思路，直接使用代码需要谨慎~）

我现在每次写大段逻辑之后都习惯拿给 AI 看看，有什么更好的实现方式，或者用什么设计模式。AI 是非常低成本且高效提升代码质量的工具。

学会封装

一个功能用到了好多次，为什么不封装成组件？一个组件用到了好几个项目，为什么不单独写个npm包？差不多的项目创建了好几个，为什么不封装成脚手架？

你说，没时间，没必要，复制粘贴反而更快。

那你就完全没理解，这么做不一定是为了让工作更快完成，而是可以让你在年年终述职时更有话说（你就算写了一百个表单表格没有写一个脚手架更值得炫耀），如果不会写可以问问 AI。

而当你真正开始封装组件，开始写工具库了，你会发现你需要思考的确实比之前多了。

关注业务

对于前端业务重要吗？

相比于后端来说，前端一般不会太关注业务。就算出了问题大部分也是后端的问题。

但是就我找工作的经验，业务非常重要！

如果你做的工作很有技术含量，比如你在做低代码，你可以面试时讲一个小时的技术难点。但是你只是一个破写后台管理，你什么都没有的说。这个时候，了解业务就成为了你的亮点。

一场面试

还是拿真实的面试场景举例，当时前同事推我字节，也是我面试过N次的梦中情厂了，刚好那个组做的业务和我之前呆的组做的一模一样。

• 同事：“做的东西和咱们之前都是一样的，你随便走个过场就能过，我在前端组长面前都夸过你了！”


• 我：“好嘞！”

等到面试的时候：

• 前端ld：“你知道xxx吗？（业务名词）”


• 我：“我……”


• 前端ld：“那xxxx呢？（业务名词）”


• 我：“不……”


• 前端ld：“那xxxxx呢？？（业务名词）”


• 我：“造……”

然后我就挂了………………

如何了解业务

关注源码

说到源码， Vue，React 这些基本是每次必问，也有太多大佬们的总结我就不多说了。

除此之外，我想大家每次面试应该都会被问，你写了什么亮点的项目，困难的项目，你会说什么？哦，都是表单表格，都用 Element UI 实现的，没什么难度。那估计你面试也就到这里了。

那说什么，后台管理就这些啊？！

如果你用了 Element UI 你可以说写了什么自定义 Element UI 表单组件，Element UI 表单源码是什么原理，怎么通信的？用了 Axios 可以说 Axios 的原理，它的拦截器怎么实现的？用了编辑器 diff 那你知道 diff 算法是什么吗？用了 ECharts 那你知道他底层是用什么绘制的吗？用了 husky ？husky的原理是什么？用了Vite，它为什么快？是怎么打包的？写过插件吗？

可能有人觉得我离谱，事实上上面每一个问题都是我在面试中真实被问到的。当然，如果全部去了解，肯定不现实，每个人的精力有限，不可能每个用到的每个工具每个库都去了解原理，不过只要有一两个你去了解过，就可以在面试中引导面试官来问，要学会表现出你擅长的点。

至于怎么读源码？以前我不知道，现在嘛…… 为什么不问问神奇的 ChatGPT 呢？

讲一下 Axios 源码中，拦截器是怎么实现的？

Axios 的拦截器实现基于 Axios 的核心原理，即 Axios 实例是一个包含请求和响应拦截器堆栈的对象。当发出请求或接收响应时，Axios 会遍历这些拦截器，并按照添加的顺序执行请求拦截器，以及按照相反的顺序执行响应拦截器。

在 Axios 的源码中，拦截器是通过一个 AxiosInterceptorManager 实例来管理的，它维护了一个拦截器数组。每个拦截器都是一个包含 fulfilled 和 rejected 函数的对象。这两个函数分别对应于拦截器成功处理和拦截器处理出错的情况。

以下是 Axios 拦截器管理器的一个简化版本，展示了其核心实现思路：

class InterceptorManager {

  constructor() {

    this.handlers = []; // 存储拦截器的数组

  }



  use(fulfilled, rejected) {

    this.handlers.push({

      fulfilled: fulfilled,

      rejected: rejected

    });

    return this.handlers.length - 1; // 返回拦截器的ID

  }



  eject(id) {

    if (this.handlers[id]) {

      this.handlers[id] = null; // 移除拦截器

    }

  }



  forEach(fn) {

    this.handlers.forEach((h) => {

      if (h !== null) {

        fn(h);

      }

    });

  }

}

在发送请求或接收响应时，Axios 会创建一个 promise 链，并通过 forEach 方法将拦截器中的 fulfilled 和 rejected 函数添加到这个链中。这样，每个拦截器都可以对请求或响应进行处理，然后将结果传递到链的下一个拦截器，或者在出错时结束链的执行。

axios.interceptors.request.forEach(function unshiftRequestInterceptors(interceptor) {

  chain.unshift(interceptor.fulfilled, interceptor.rejected);

});



axios.interceptors.response.forEach(function pushResponseInterceptors(interceptor) {

  chain.push(interceptor.fulfilled, interceptor.rejected);

});

在 Axios 的完整实现中，这个拦截器机制被集成到了 Axios 的请求发送和响应处理流程中。通过这种方式，Axios 可以在发送请求之前和接收响应之后，但在用户定义的 .then 或 .catch 执行之前，插入自定义的逻辑。

请注意，这里提供的代码只是为了说明 Axios 拦截器的实现原理，并不是 Axios 源码的完整复制。如果你对 Axios 的拦截器实现细节感兴趣，建议查看 Axios 的官方 GitHub 仓库中的源码。

前端基建

当我们工作时间久了面试难免会遇到这些问题，前端工程化，前端监控，工作流，部署，性能等等。其实我们在工作中绝大部分时间都在写代码，对于这些不是所有人都有机会接触到，不过这些和所做的业务无关，是我们提升自己很好的一个思路。

技术选型

技术栈选 Vue 还是 React？Vue 选 Vue2 还是 Vue3？组件库选 ElementUI 还是 Ant Design？微前端有没有使用过？打包工具用 Vite 还是 Webpack？有那么多表单怎么实现的，有没有什么表达配置化方案，比如Formily？

对于我这种菜鸡，我这种只写简单的表单表格的人，这些都……无所谓……

不过为了应对面试我们还是需要了解下未选择技术栈的缺点，和已选择技术栈的优点（有点本末倒置…但是常规操作啦）

Vue 你可以说简单高效轻量级，面试必会问你为什么，你就开始说 Vue 的响应式系统，依赖收集等。

React 你可以说 JSX、Hooks 很灵活，那你必然要考虑 JSX 怎么编译， Hooks 实现方式等。

总体而言，对于技术选型，依赖于我们对所有可选项的理解，做选择可能很容易，给出合理的理由还是需要花费一些精力的。

开发规范

这个方面，在面试的时候我被问到的不多，我们可以在创建项目的时候，配置下 ESlint，stylelint， prettier， commitlint 等。

前端监控

干了这么多年前端，前端监控我是……一点没做过。

前端监控，简单来说就是我们在前端程序中记录一些信息并上报，一般是错误信息，来方便我们及时发现问题并解决问题。除此之外也会有性能监控，用户行为的监控（埋点）等。之前也听过有些团队分享前端监控，为了出现问题明确责任（方便甩锅）。

对于实现方案，无论使用第三方库还是自己实现，重要的都是理解实现原理。

对于错误监控，可以了解一下 Sentry，原理简单来说就是通过 window.onerror 和 window.addEventListener('unhandledrejection', ...) 去分别捕获同步和异步错误，然后通过错误信息和 sourceMap 来定位到源码。

对于性能监控，我们可以通过 window.performance、PerformanceObserver 等 API 收集页面性能相关的指标，除此之外，还需要关注接口的响应时间。

最后，收集到信息之后，还要考虑数据上报的方案，比如使用 navigator.sendBeacon 还是 Fetch、AJAX？是批量上报，实时上报，还是延迟上报？上报的数据格式等等。

CI/CD

持续集成（Continuous Integration, CI）和 持续部署（Continuous Deployment, CD），主要包括版本控制，代码合并，构建，单测，部署等一系列前端工作流。

场景的工作流有 Jenkins、 Gitlab CI 等。我们可以配置在合并代码时自动打包部署，在提交代码时自动构建并发布包等。

这块我了解不多，但感觉这些工具层面的东西，不太会涉及到原理，基本上就是使用的问题。还是需要自己亲自动手试一下，才能知道细节。比如在 Gitlab CI 中， Pipeline 、 Stage 和 Job 分别是什么，怎么配置，如何在不同环境配置不同工作流等。

了解技术动态

这个可能还是比较依赖信息收集能力，虽然我个人觉得很烦，但好像很多领导级别的面试很愿意问。

比如近几年很火的低代码，很多面试官都会问，你用过就问你细节，你没用过也会问你有什么设计思路。

还有最近的两年爆火的 AI，又或者 Vue React的最新功能，WebAssembly，还有一些新的打包工具 Vite Bun 什么的，还有鸿蒙开发……

虽然不可能学完每一项新技术，但是可以多去了解下。

总结

写了这么多，可能有人会问，如果能回到过去，你会怎么做。

啊，我只能说，说是一回事，做又是另一回事，事实上我并不希望回到过去去卷一遍，菜点没关系，快乐就好，一切都是最好的安排。

早上刚来，就看到仓库那边不停发消息说，我们的某个功能用不了了。赶紧放下早餐加紧看。

原来是调的一个三方接口报错了：

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

	at sun.security.ssl.Alert.createSSLException(Alert.java:131)

	at sun.security.ssl.TransportContext.fatal(TransportContext.java:353)

	at sun.security.ssl.TransportContext.fatal(TransportContext.java:296)

	at sun.security.ssl.TransportContext.fatal(TransportContext.java:291)

	at sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:652)

	at sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:471)

	at sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:367)

	at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:376)

	at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)

	at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:422)

	at sun.security.ssl.TransportContext.dispatch(TransportContext.java:183)

	at sun.security.ssl.SSLTransport.decode(SSLTransport.java:154)

	at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1279)

	at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1188)

	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:401)

	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:373)

查看原因：

由于JVM默认信任证书不包含该目标网站的SSL证书，导致无法建立有效的信任链接。

奥...原来是他们把接口从http改为了https,导致我们获取数据报错了。再看看他们的证书，奥...新的。

好了，看看我们的逻辑，这其实是一个获取对方生成的PDF文件的接口

PdfReader pdfReader = new PdfReader(url);

url就是他们给的链接，是这行代码报的错。这时候，开始研究，在网上扒拉，找到了初版方案

尝试1

写一个程序专门获取安全证书，这代码有点长，全贴出来影响阅读。我给扔我hithub上了github.com/lukezhao6/I… 将这个文件贴到本地，执行javac InstallCert.java将其进行编译

编译完长这样：

然后再执行java InstallCert http://www.baidu.com （这里我们用百度举例子，实际填写的就是你想要获取证书的目标网站）

报错不用怕，因为它会去检查目标服务器的证书，如果出现了SSLException,表示证书可能存在问题，这时候会把异常信息打印出来。

在生成的时候需要输入一个1

这样，我们需要的证书文件就生成好了

这时候，将它放入我们本地的 jdk的lib\security文件夹内就行了

重启，这时候访问是没有问题了。阶段性胜利。

但是，但是。一顿操作下来，对于测试环境的docker，还有生产环境貌似不能这么操作。 放这个证书文件比较费事。

那就只能另辟蹊径了。

尝试2

搜到了，还有两种方案。

1.通过System.setProperty("javax.net.ssl.trustStore", "你的jssecacerts证书路径");

2.程序启动命令-Djavax.net.ssl.trustStore=你的jssecacerts证书路径 -Djavax.net.ssl.trustStorePassword=changeit

我尝试了第一种，System.setProperty可以成功，但是读不到文件，权限什么的都是ok的。
检查了蛮多地方

• 路径格式问题


• 文件是否存在


• 文件权限


• 信任库密码


• 系统属性优先级

貌似都是没问题的，但肯定又是有问题的，因为没起作用。但是想着这样的接口有4个，万一哪天其他三个也改了，我又得来一遍。所以就算研究出来了，还是不能稳坐钓鱼台。有没有一了百了的方法嘞。

尝试3

还真找到了：这个错是因为对方网站的证书不被java信任么，那咱不校验了，直接全部信任。这样就算其他接口改了，咱也不愁。而且这个就是获取pdf，貌似安全性没那么重。那就开搞。

代码贴在了下方，上边的大概都能看懂吧，下方的我加了注释。

URL console = new URL(url);

HttpURLConnection conn = (HttpURLConnection) console.openConnection();

if (conn instanceof HttpsURLConnection)  {

    SSLContext sc = SSLContext.getInstance("SSL");

    sc.init(null, new TrustManager[]{new TrustAnyTrustManager()}, new java.security.SecureRandom());

    ((HttpsURLConnection) conn).setSSLSocketFactory(sc.getSocketFactory());

    ((HttpsURLConnection) conn).setHostnameVerifier(new TrustAnyHostnameVerifier());

}

conn.connect();

InputStream inputStream = conn.getInputStream();

PdfReader pdfReader = new PdfReader(inputStream);

inputStream.close();

conn.disconnect();

private static class TrustAnyTrustManager implements X509TrustManager {

    //这个方法用于验证客户端的证书。在这里，方法体为空，表示不对客户端提供的证书进行任何验证。

    public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {

    }

    //这个方法用于验证服务器的证书。同样，方法体为空，表示不对服务器提供的证书进行任何验证。

    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {

    }

    //这个方法返回一个信任的证书数组。在这里，返回空数组，表示不信任任何证书，也就是对所有证书都不做任何信任验证。

    public X509Certificate[] getAcceptedIssuers() {

        return new X509Certificate[]{};

    }

}

//这个方法用于验证主机名是否可信。在这里，无论传入的主机名是什么，方法始终返回 true，表示信任任何主机名。这就意味着对于 SSL 连接，不会对主机名进行真实的验证，而是始终接受所有主机名。

private static class TrustAnyHostnameVerifier implements HostnameVerifier {

    public boolean verify(String hostname, SSLSession session) {

        return true;

    }

}

解决了解决了，这样改算是个比较不错的方案了吧。

前言

在产品经理提需求时候提到，app在接收到报警信息时候能不能弹出一个弹框，告诉用户报警信息，这个弹框要在app的任意界面能够弹出，并且用户点击详情时候，会跳转到报警详情界面，查看具体信息，当用户将app至于后台的时候，接收到报警信息，app发送通知，当用户点击通知时候，跳转到报警详情界面。
功能大体总结如上，在实现弹框与通知在跳转界面时遇到一些问题，在此记录一下。效果图如下：

功能分析

弹框实现，使用DialogFragment。

前后台判断则是，创建一个继承自ActivityLifecycleCallbacks接口和Application的类，继承ActivityLifecycleCallbacks接口是为了前后台判断，继承Application则是方便在基类BaseActivity获取前后台相关数据。

项目原本采用单Activity多Fragment实现，后面因为添加了视频相关功能，改为了多Activity多Fragment。

原单Activity时候，实现比较容易。后面修改为多Activity，就有些头疼，最终用思路是创建基类BaseActivity，后面添加Activity时都要继承基类BaseActivity。使用基类原因是把相同的功能抽取出来，且若每个Activity都自己实现弹框和通知的话太容易出错，也太容易漏下代码了。

代码实现

弹框

在实现继承自DialogFragment的弹框时，需要在onCreateDialog方法内设置dialog的宽高模式以及背景，不然弹框会有默认的边距，导致显示效果与预期不符，未去边距与去掉边距的弹框效果如下：

关于onCreateDialog的代码如下：

override fun onCreateDialog(savedInstanceState: Bundle?): Dialog {

    val dialog = Dialog(requireContext())

    dialog.setContentView(R.layout.custom_dialog_layout)

    dialog.window?.apply {

        setLayout(ViewGr0up.LayoutParams.MATCH_PARENT,ViewGr0up.LayoutParams.MATCH_PARENT)

        setBackgroundDrawable(ColorDrawable(Color.parseColor("#88000000")))//去掉DialogFragment的边距

    }

    dialog.setCancelable(false)

    return dialog

}

此外当弹框出现的时候，弹框背景色还会闪烁。这里采用属性值动画设置弹框背景色控件的透明度变换。完整的Dialog代码如下：

class AlarmDialogFragment: DialogFragment() {

    private lateinit var binding:CustomDialogLayoutBinding

    private var animator:ObjectAnimator? = null



    override fun show(manager: FragmentManager, tag: String?) {

        try {

            super.show(manager, tag)

        }catch (e:Exception){

            e.printStackTrace()

        }

    }



    override fun onCreateView(

        inflater: LayoutInflater,

        container: ViewGr0up?,

        savedInstanceState: Bundle?

    ): View? {

        binding = CustomDialogLayoutBinding.inflate(inflater)

        return binding.root

    }



    override fun onStart() {

        super.onStart()

        binding.viewAlarmDialogBg

        startAnimation()

    }



    override fun onCreateDialog(savedInstanceState: Bundle?): Dialog {

        val dialog = Dialog(requireContext())

        dialog.setContentView(R.layout.custom_dialog_layout)

        dialog.window?.apply {

            setLayout(ViewGr0up.LayoutParams.MATCH_PARENT,ViewGr0up.LayoutParams.MATCH_PARENT)

            setBackgroundDrawable(ColorDrawable(Color.parseColor("#88000000")))//去掉DialogFragment的边距

        }

        dialog.setCancelable(false)

        return dialog

    }



    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {

        super.onViewCreated(view, savedInstanceState)

        initView()

    }



    override fun onDestroy() {

        super.onDestroy()

        if(animator?.isStarted == true){

            animator?.end()

        }

    }



    private fun initView() {

        binding.btnCloseDialog.setOnClickListener {

            dismiss()

        }



        binding.btnDialogNav.setOnClickListener {

            if(context is MainActivity){

                val bundle = Bundle()

                bundle.putString("alarmId","1")

                findNavController().navigate(R.id.alarmDetailFragment,bundle)

            }else{

                val intent = Intent(context,MainActivity::class.java)

                intent.putExtra("task","toAlarmDetail")

                startActivity(intent)

            }

            dismiss()

        }

    }



    private fun startAnimation() {

        animator = ObjectAnimator.ofFloat(binding.viewAlarmDialogBg, "alpha", 0f, 0.6f, 0f, 0.6f, 0f)

        animator?.duration = 1200

        animator?.interpolator = AccelerateInterpolator()

        animator?.start()

    }

}

需要注意地方是，由于弹框还负责跳转，而跳转有两种情况，一种是在ActivityA内，fragmentA与fragmentB间的跳转，这种情况使用findNavController().navigate()方法进行跳转，另一种是ActivityB到另一个ActivityA内的指定FragmentB界面。这种采用startActivity(intent)方式跳转，并且在ActivityA的onStart()的方法使用下面方法。

/** 跳转报警详情界面 */

private fun initToAlarmDetail() {

    val task = intent.getStringExtra("task")

    if (task == "toAlarmDetail"){

        val bundle = Bundle()

        bundle.putString("alarmId","1")

        findNavController(R.id.fragment_main_table).navigate(R.id.alarmDetailFragment,bundle)

    }

}

这样从ActivityB到另一个ActivityA时候，在onStart()方法内会触发上面的initToAlarmDetail()方法，获取跳转里面的信息，在决定具体跳转到哪个Fragment。这里解释的可能不太清楚，可以在Github下载源码看看可能更好理解些。

弹框对应的xml文件代码，可以在Github内查看，可以自己写一个，这个xml比较简单，只是xml代码比较占地方这里就不粘贴了。

前后台判断

关于前后台判断，需要创建一个继承ActivityLifecycleCallbacks和Application的类，这里命名为CustomApplication，在类里面实现ActivityLifecycleCallbacks接口相关方法，此外需要创建下面三个变量，分别表示activity数量，当前activity的名称，是否处于后台，代码如下：

private var activityCount = 0

private var nowActivityName:String? = null

private var isInBackground = true

之后需要在onActivityStarted，onActivityResumed，onActivityStopped方法内进行前后台相关处理，代码如下：

override fun onActivityStarted(activity: Activity) {

    activityCount++

    if (isInBackground){

        isInBackground = false

    }

    nowActivityName = activity.javaClass.name

}



override fun onActivityStopped(activity: Activity) {

    activityCount--

    if (activityCount == 0 && !isInBackground){

        isInBackground = true

    }

}

上面代码可以看出，当触发onActivityStarted方法时候，activityCount数量加一，且app处于前台。之后记录当前activity名称，这里记录activity名称是后面有个功能是app置于后台时候弹出通知，而通知相关操作，为了每个activity都能实现就放在基类执行，而弹出通知并不需要每个继承基类的activity都执行，到时候需要根据根据nowActivityName判断哪个继承了基类的activity执行通知操作。

当触发onActivityStopped方法时候，activityCount数量减一，且当activityCount数量为零时，app置于后台。
CustomApplication完整代码如下：

class CustomApplication: Application(),Application.ActivityLifecycleCallbacks {

    companion object{

        const val TAG = "CustomApplication"

        @SuppressLint("CustomContext")

        lateinit var context: Context 

    }



    private var activityCount = 0

    private var nowActivityName:String? = null

    private var isInBackground = true



    fun getNowActivityName(): String? {

        return nowActivityName

    }



    fun getIsInBackground():Boolean{

        return isInBackground

    }



    override fun onCreate() {

        super.onCreate()

        context = applicationContext

        registerActivityLifecycleCallbacks(this)

    }



    override fun onActivityCreated(activity: Activity, p1: Bundle?) {



    }



    override fun onActivityStarted(activity: Activity) {

        activityCount++

        if (isInBackground){

            isInBackground = false

        }

        nowActivityName = activity.javaClass.name

    }



    override fun onActivityResumed(activity: Activity) {



    }



    override fun onActivityPaused(activity: Activity) {



    }



    override fun onActivityStopped(activity: Activity) {

        activityCount--

        if (activityCount == 0 && !isInBackground){

            isInBackground = true

        }

    }



    override fun onActivitySaveInstanceState(activity: Activity, p1: Bundle) {



    }



    override fun onActivityDestroyed(activity: Activity) {



    }

}

弹框与通知弹出

开发中弹框与通知弹出的触发条件是，监听Websocket若有信息过来，app处于前台弹框，处于后台弹通知。这里使用Handler来模拟，弹框弹出比较简单，若有继承了DialogFragment的AlarmDialogFragment类。代码如下：

val dialog = AlarmDialogFragment()

dialog.show(supportFragmentManager,"tag")

通知弹出也不难，若只是弹出通知示例代码如下：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {

    val channel =

        NotificationChannel("normal", "Normal", NotificationManager.IMPORTANCE_DEFAULT)

    notificationManager?.createNotificationChannel(channel)

}

val notification = NotificationCompat.Builder(this.applicationContext, "normal")

    .setContentTitle("标题")

    .setContentText("通知次数:${++alarmCount}")

    .setSmallIcon(R.drawable.ic_launcher_background)

    .setTimeoutAfter(5000)

    .setAutoCancel(true)

    .build()

notificationManager?.notify(notificationId,notification)

弹框与通知的特殊要求是，能在界面任意地方弹出且跳转到指定界面。弹框跳转相关代码在上面'弹框'部分，下面来说下通知的跳转，点击通知跳转是通过创建PendingIntent后在设置进NotificationCompat的setContentIntent方法内，不过通知跳转与弹框跳转一样需要分两种情况考虑，第一种同一Activity内Fragment与Fragment跳转，这种情况下PendingIntent如下代码所示：

var pendingIntent:PendingIntent? = null

val bundle = Bundle()

bundle.putString("alarmId","1")

pendingIntent = NavDeepLinkBuilder(this)

    .setGraph(R.navigation.main_navigation)

    .setDestination(R.id.alarmDetailFragment)

    .setArguments(bundle)

    .createPendingIntent()

上面代码中使用NavDeepLinkBuilder创建了一个PendingIntent，并且使用setGraph()指向使用的导航图，setDestination()则指向目标Fragment。
另一种情况则是ActivityB到另一个ActivityA内的指定FragmentB界面，这种情况下PendingIntent设置代码如下：

val intent = Intent(this@BaseActivity,MainActivity::class.java)

intent.putExtra("task","toAlarmDetail")

intent.flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK

pendingIntent = TaskStackBuilder.create(this@BaseActivity)

    .addNextIntentWithParentStack(intent)

    .getPendingIntent(0,PendingIntent.FLAG_UPDATE_CURRENT)

这种是创建一个跳转到MainActivity的Intent，并添加传递的参数task，接着设置Intent的启动方式，其中Intent.FLAG_ACTIVITY_NEW_TASK，表示启动Activity作为新任务启动，Intent.FLAG_ACTIVITY_CLEAR_TASK，表示清除任务栈中所有现有的Activity。之后调用TaskStackBuilder创建PendingIntent。
上面两种方式创建的PendingIntent可以通过NotificationCompat.setContentIntent(pendingIntent)添加进去，关于通知创建的代码如下：

/** 使用通知 - 通过pendingIntent实现跳转，缺点是任意界面进入报警详情界面，点击返回键只能返回MainFragment */

    private fun useNotificationPI() {

        var pendingIntent:PendingIntent? = null

        if(javaClass.simpleName == "MainActivity"){//主界面

            val bundle = Bundle()

            bundle.putString("alarmId","1")

            pendingIntent = NavDeepLinkBuilder(this)

                .setGraph(R.navigation.main_navigation)

                .setDestination(R.id.alarmDetailFragment)

                .setArguments(bundle)

                .createPendingIntent()

        }else {//其他界面时候切换后台通知

            val intent = Intent(this@BaseActivity,MainActivity::class.java)

            intent.putExtra("task","toAlarmDetail")

            intent.flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK

            pendingIntent = TaskStackBuilder.create(this@BaseActivity)

                .addNextIntentWithParentStack(intent)

                .getPendingIntent(0,PendingIntent.FLAG_UPDATE_CURRENT)

        }



        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {

            val channel =

                NotificationChannel("normal", "Normal", NotificationManager.IMPORTANCE_DEFAULT)

            notificationManager?.createNotificationChannel(channel)

        }

        val notification = NotificationCompat.Builder(this.applicationContext, "normal")

            .setContentTitle("标题")

            .setContentText("通知次数:${++alarmCount}")

            .setSmallIcon(R.drawable.ic_launcher_background)

            .setTimeoutAfter(5000)

            .setAutoCancel(true)

            .setContentIntent(pendingIntent)

            .build()

        notificationManager?.notify(notificationId,notification)

    }

上面代码中if(javaClass.simpleName == "MainActivity"),及第四行代码，该代码用处是当app置于后台时候，pp界面是MainActivity时，pendingIntent使用NavDeepLinkBuilder生成，当是其他Activity时使用TaskStackBuilder生成。之所以这样是因为，在MainActivity的xml，使用了FragmentContainerView用于fragment间跳转，其他的Activity没有FragmentContainerView，因此在生成pendingIntent需要采用不同的方式生成。

这示例代码中，主要涉及到的Avtivity有MainActivity与VideoActivity，MainActivity使用FragmentContainerView，而VideoActivity没有。弹框与通知跳转的界面是AlarmDetailFragment，这个fragment在MainActivity通过Navigation实现导航。

因此在MainActivity界面进入后台时，pendingIntent使用NavDeepLinkBuilder生成，NavDeepLinkBuilder则可以使用导航图中fragment生成深度链接URI，这个URI则可以导航到指定的fragment（关于NavDeepLinkBuilder了解不深入，这里说的可能有错误地方，欢迎大佬指正）。

而VideoActivity界面进入后台时，就需要使用TaskStackBuilder生成一个启动MainActivity的Intent。而在MainActivity的onStart方法内有下面initToAlarmDetail方法，判断跳转时携带参数决定是否跳转到AlarmDetailFragment界面。

/** 跳转报警详情界面 */

private fun initToAlarmDetail() {

    val task = intent.getStringExtra("task")

    if (task == "toAlarmDetail"){

        val bundle = Bundle()

        bundle.putString("alarmId","1")

        findNavController(R.id.fragment_main_table).navigate(R.id.alarmDetailFragment,bundle)

    }

}

至此弹框与通知的功能基本实现，完整的BaseActivity代码如下：

open class BaseActivity: AppCompatActivity() {

    companion object{

        const val TAG = "BaseActivity"

    }

    private var alarmCount = 0

    private val handler = Handler(Looper.myLooper()!!)

    //为了关闭通知，manager放在外面

    private val notificationId = 1

    private var alarmDialogFragment: AlarmDialogFragment? = null

    private var notificationManager:NotificationManager? = null

    private var bgServiceIntent:Intent? = null//前台服务



    private var nowClassName = ""



    /** 弹框定时任务 */

    private val dialogRunnable = object : Runnable {

        override fun run() {

            //在定时方法里面 javaClass.simpleName 不能获取当前所处Activity的名称

            if (nowClassName == "VideoActivity"){ //视频界面不弹弹框

                CustomLog.d(TAG,"不使用弹框 ${nowClassName}")

            }else{

                CustomLog.d(TAG,"使用弹框 ${nowClassName}")

                useDialog()

                handler.postDelayed(this, 10000)

            }

        }

    }



    /** 通知定时任务 */

    private val notificationRunnable = object :Runnable{

        override fun run() {

            useNotificationPI()

            handler.postDelayed(this,10000)

        }

    }



    override fun onCreateView(name: String, context: Context, attrs: AttributeSet): View? {

        initWindow()

        return super.onCreateView(name, context, attrs)

    }



    override fun onCreate(savedInstanceState: Bundle?, persistentState: PersistableBundle?) {

        super.onCreate(savedInstanceState, persistentState)

        CustomLog.d(TAG,"onCreate(savedInstanceState: Bundle?, persistentState: PersistableBundle?) 当前类:${javaClass.simpleName}")

    }



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        CustomLog.d(TAG,"onCreate(savedInstanceState: Bundle?) 当前类:${javaClass.simpleName}")

        initData()

    }



    override fun onStart() {

        super.onStart()

        CustomLog.d(TAG,"onStart 当前类:${javaClass.simpleName}")

        nowClassName = javaClass.simpleName

        handler.postDelayed(dialogRunnable, 3000)

        initService()

    }



    override fun onResume() {

        super.onResume()

        CustomLog.d(TAG,"onResume 当前类:${javaClass.simpleName}")

    }



    override fun onRestart() {

        super.onRestart()

        CustomLog.d(TAG,"onRestart 当前类:${javaClass.simpleName}")

    }



    override fun onPause() {

        super.onPause()

        CustomLog.d(TAG,"onPause 当前类:${javaClass.simpleName}")

    }



    override fun onStop() {

        super.onStop()

        CustomLog.d(TAG,"onStop 当前类:${javaClass.simpleName}")

        val customApplication = applicationContext as CustomApplication

        val nowActivityName = customApplication.getNowActivityName()

        val activitySimpleName = nowActivityName?.substringAfterLast(".")

        CustomLog.d(TAG,"activitySimpleName:$activitySimpleName")

        val isInBackground = (this@BaseActivity.applicationContext as CustomApplication).getIsInBackground()

        if (isInBackground && activitySimpleName.equals(javaClass.simpleName)){// 处于后台 且 切换至后台app的activity页面名称等于当前基类里面获取activity类名

            handler.postDelayed(notificationRunnable,3000)

            CustomLog.d(TAG,"使用通知 $nowClassName")

        }else{

            CustomLog.d(TAG,"关闭所有定时任务 $nowClassName")

            closeAllTask()

        }

    }



    override fun onDestroy() {

        super.onDestroy()

        CustomLog.d(TAG,"onDestroy 当前类:${javaClass.simpleName}")

        closeAllTask()

        this.stopService(bgServiceIntent)

    }



    /** 关闭所有定时任务 */

    private fun closeAllTask() {

        handler.removeCallbacks(dialogRunnable)

        handler.removeCallbacks(notificationRunnable)

    }



    /** 初始化数据 - 关于弹框*/

    private fun initData() {

        notificationManager = notificationManager ?: this.getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager

        alarmDialogFragment = alarmDialogFragment ?: AlarmDialogFragment()

    }



    /** 使用通知 - 通过pendingIntent实现跳转，缺点是任意界面进入报警详情界面，点击返回键只能返回MainFragment */

    private fun useNotificationPI() {

        var pendingIntent:PendingIntent? = null

        if(javaClass.simpleName == "MainActivity"){//主界面

            CustomLog.d(TAG,">>>通知：MainActivity")

            val bundle = Bundle()

            bundle.putString("alarmId","1")

            pendingIntent = NavDeepLinkBuilder(this)

                .setGraph(R.navigation.main_navigation)

                .setDestination(R.id.alarmDetailFragment)

                .setArguments(bundle)

                .createPendingIntent()

        }else {//其他界面时候切换后台通知

            CustomLog.d(TAG,">>>通知：else")

            val intent = Intent(this@BaseActivity,MainActivity::class.java)

            intent.putExtra("task","toAlarmDetail")

            intent.flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK

            pendingIntent = TaskStackBuilder.create(this@BaseActivity)

                .addNextIntentWithParentStack(intent)

                .getPendingIntent(0,PendingIntent.FLAG_UPDATE_CURRENT)

        }



        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {

            val channel =

                NotificationChannel("normal", "Normal", NotificationManager.IMPORTANCE_DEFAULT)

            notificationManager?.createNotificationChannel(channel)

        }

        val notification = NotificationCompat.Builder(this.applicationContext, "normal")

            .setContentTitle("标题")

            .setContentText("通知次数:${++alarmCount}")

            .setSmallIcon(R.drawable.ic_launcher_background)

            .setTimeoutAfter(5000)

            .setAutoCancel(true)

            .setContentIntent(pendingIntent)

            .build()

        notificationManager?.notify(notificationId,notification)

    }



    /** 弹框使用 - 因为此处涉及到fragment等生命周期，进入其他activity内时候，在前的activity使用useDialog会因为生命周期问题闪退*/

    private fun useDialog() {

        //弹出多个同种弹框

//        alarmDialogFragment = AlarmDialogFragment()

//        alarmDialogFragment?.show(supportFragmentManager,"testDialog")



        //不弹出多个同种弹框，一次只弹一个，若弹框存在不弹新框

        if (alarmDialogFragment?.isVisible == false){//如果不加这一句，当弹框存在时候在调用alarmDialogFragment.show的时候会报错，因为alarmDialogFragment已经存在

            alarmDialogFragment?.show(supportFragmentManager,"testDialog")

        }else{

            //更新弹框内信息

        }

    }



    /** 关闭报警弹框 */

    private fun closeAlarmDialog() {

        if (alarmDialogFragment?.isVisible == true) {

            alarmDialogFragment?.dismiss()//要关闭的弹框

        }

    }



    //状态栏透明,且组件占据了状态栏

    private fun initWindow() {

        window.statusBarColor = Color.TRANSPARENT

        window.decorView.systemUiVisibility = View.SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION

    }



    /** 初始化服务 */

    private fun initService() {

        CustomLog.d(TAG,"开启前台服务")

        bgServiceIntent = bgServiceIntent ?: Intent(this, BackgroundService::class.java)

        this.startService(bgServiceIntent)

    }

}

总结

只是弹出弹框和通知的话，实现很好实现，中间麻烦地方在于当app使用多个Activity，该怎么实现跳转到指定的界面。当然这里麻烦是，从ActivityB跳转到ActivityA的Fragment，如果是只有一个Activity应该会好办些。个人感觉fragment跳转应该有更好的方式实现希望能和大佬们交流下这种情况下，用什么技术实现。

PS：感觉原生Android在写界面和跳转方面写起来不太方便。不知道大家有便捷的方式吗。

代码地址

GitHub：github.com/SmallCrispy…

有些场景下需要显示一些提示弹窗，但把握不好弹出时机容易先弹出弹窗然后界面马上被杀掉进而看不到提示内容，例如强制下线：客户端退回登录界面并弹出提示弹窗。

如果是直接拿的栈顶activity去弹出，没有将弹窗逻辑写到具体activity中，或不好确定activty的变化就容易出现这种现象。

由于applicationContext没有AppWindowToken，所以dialog无法使用applicationContext创建，要么就使用windowManager配合WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY使用创建全局悬浮窗。但是这种做法需要申请权限。那么，在没有悬浮权限情况下如何做到让dialog不受栈顶activity变化的影响？

我的想法是通过application.registerActivityLifecycleCallbacks在activity变化时，关闭原来的弹窗，并重新创建一个一样的dialog并显示。

效果演示：

1. 栈顶界面被杀

2. 有新界面弹出

以下是代码实现：

/**

 * @Description 无需悬浮权限的全局弹窗，栈顶activity变化后通过反射重建，所以子类构造方法需无参

 */

open class BaseAppDialog<T : ViewModel>() : Dialog(topActivity!!.get()!!), ViewModelStoreOwner {



    companion object {

        private val TAG = BaseAppDialog::class.java.simpleName

        private var topActivity: WeakReference<Activity>? = null

        private val staticRestoreList = linkedMapOf<Class<*>, Boolean>()    //第二个参数：是否临时关闭

        private val staticViewModelStore: ViewModelStore = ViewModelStore()



        @JvmStatic

        fun init(application: Application) {

            application.registerActivityLifecycleCallbacks(object : Application.ActivityLifecycleCallbacks {

                override fun onActivityCreated(activity: Activity, savedInstanceState: Bundle?) {

                    topActivity = WeakReference(activity)

                }



                override fun onActivityStarted(activity: Activity) {



                }



                override fun onActivityResumed(activity: Activity) {

                    topActivity = WeakReference(activity)

                    val tempList = arrayListOf<BaseAppDialog<*>>()

                    val iterator = staticRestoreList.iterator()

                    while (iterator.hasNext()) {

                        val next = iterator.next()

                        val topName = (topActivity?.get() ?: "")::class.java.name

                        if (next.value == true) {  //避免onCreate创建的弹窗重复弹出

                            val newInstance = Class.forName(next.key.name).getConstructor().newInstance() as BaseAppDialog<*>

                            tempList.add(newInstance)

                            Log.e(TAG, "重新创建${next.key.name}，于$topName")

                            iterator.remove()

                        }



                    }



                    tempList.forEach {

                        it.show()

                    }



                    if (staticRestoreList.size == 0) {

                        staticViewModelStore.clear()

                    }

                }



                override fun onActivityPaused(activity: Activity) {

                }



                override fun onActivityStopped(activity: Activity) {



                }



                override fun onActivitySaveInstanceState(activity: Activity, outState: Bundle) {

                }



                override fun onActivityDestroyed(activity: Activity) {

                }

            })

        }

    }





    var vm: T? = null



    init {

        val genericClass = getGenericClass()

        if (vm == null) {

            (genericClass as? Class<T>)?.let {

                vm = ViewModelProvider(this)[it]

            }

        }



        topActivity?.get()?.let {

            (it as LifecycleOwner).lifecycle.addObserver(object : DefaultLifecycleObserver {

                override fun onPause(owner: LifecycleOwner) {

                    super.onPause(owner)

                    dismissSilent()

                }

            })

        }

    }





    //用于栈顶变化时的关闭

    private fun dismissSilent() {

        super.dismiss()

        staticRestoreList.replace(this::class.java, true)

    }



    override fun show() {

        super.show()

        staticRestoreList.put(this::class.java, false)

    }



    override fun dismiss() {

        super.dismiss()

        staticRestoreList.remove(this::class.java)

    }





    //获取泛型实际类型

    private fun getGenericClass(): Class<*>? {

        val superclass = javaClass.genericSuperclass

        if (superclass is ParameterizedType) {

            val actualTypeArguments: Array<Type>? = superclass.actualTypeArguments

            if (!actualTypeArguments.isNullOrEmpty()) {

                val type: Type = actualTypeArguments[0]

                if (type is Class<*>) {

                    return type

                }

            }

        }

        return ViewModel::class.java

    }





    //自己管理viewModel以便恢复数据

    override fun getViewModelStore(): ViewModelStore {

        return staticViewModelStore

    }

}

参数传递的话，直接通过修改dialog的viewmodel变量或调用其方法来实现。

class TipDialogVm : ViewModel() {

    val content = MutableLiveData<String>("")

}





class TipDialog2 : BaseAppDialog<TipDialogVm>() {



    var binding : DialogTip2Binding? = null



    init {

        binding = DataBindingUtil.inflate(LayoutInflater.from(context), R.layout.dialog_tip2, null, false)

        binding?.lifecycleOwner = context as? LifecycleOwner

        binding?.vm = vm

        setContentView(binding!!.root)



    }

}

弹出弹窗

TipDialog2().apply {

    vm?.content?.value = "嗨嗨嗨"

}.show()