一、前言

大家好！我是sum墨，一个一线的底层码农，平时喜欢研究和思考一些技术相关的问题并整理成文，限于本人水平，如果文章和代码有表述不当之处，还请不吝赐教。

只要是干过后台系统的同学应该都做过分页查询吧，前端发送带有页码（pageNum）和每页显示数量（pageSize）的请求，后端根据这些参数来提取并返回相应的数据集。在SpringBoot框架中，经常会使用Mybatis+PageHelper的方式实现这个功能。

但大家可能对分页合理化这个词有点儿陌生，不过应该都遇到过因为它产生的问题。这些问题不会触发明显的错误，所以大家一般都忽视了这个问题。那么啥是分页合理化，我来举几个例子：

它的定义：分页合理化通常是指后端在处理分页请求时会自动校正不合理的分页参数，以确保用户始终收到有效的数据响应。

1. 请求页码超出范围：

假设数据库中有100条记录，每页展示10条，那么就应该只有10页数据。如果用户请求第11页，不合理化处理可能会返回一个空的数据集，告诉用户没有更多数据。开启分页合理化后，系统可能会返回第10页的数据（即最后一页的数据），而不是一个空集。

2. 请求页码小于1：

用户请求的页码如果是0或负数，这在分页上下文中是没有意义的。开启分页合理化后，系统会将这种请求的页码调整为1，返回第一页的数据。

3. 请求的数据大小小于1：

如果用户请求的数据大小为0或负数，这也是无效的，因为它意味着用户不希望获取任何数据。开启分页合理化后，系统可能会设置一个默认的页面大小，比如每页显示10条数据。

4. 请求的数据大小不合理：

如果用户请求的数据大小非常大，比如一次请求1000条数据，这可能会给服务器带来不必要的压力。开启分页合理化后，系统可能会限制页面大小的上限，比如最多只允许每页显示100条数据。

二、为啥要设置分页合理化？

其实上面那些问题对于后端来讲很合理，页码和页大小设置不正确查询不出来值难道不合理吗？唯一的问题就是如果一次性查询太多条数据服务器压力确实大，但如果是产品要求的那也没办法呀！
真正让我不得不解决这个问题的原因是前端的一个BUG，这个BUG是啥样的呢？我来给大家描述一下。

1. BUG复现

我们先看看前端的分页组件

前端的这个分页组件大家应该很常见，它需要两个参数：总行数、每页行数。比如说现在总条数是6条，每页展示5条，那么会有2页，没啥问题对吧。

那么，现在我问一个问题：我们切换到第二页，把第二页仅剩的一条数据给删除掉，会出现什么情况？

理想情况：页码自动切换到第1页，并查询第一页的数据；
真实情况：页码切换到了第1页，但是查询不到数据，这明显就是一个BUG！

2. BUG分析

1. 用户切换到第二页，前端发起了请求，如：http://localhost:8080/user/pageQuery?pageNum=2&pageSize=5 ，此时第2页有一条数据；

2. 用户删除第2页的唯一数据后，前端发起查询请求，但还是第2页的查询，因为总数据的变化前端只能通过下一次的查询才能知道，但此时数据查询为空；

3. 虽然第二次查询的数据集为空，但是总条数已经变化了，只剩下5条，前端分页组件根据计算得出只剩下一页，所以自动切换到第1页；

可以看出这个BUG是分页查询的一个临界状态产生的，必现、中低频，属于必须修复的那一类。不过这个BUG想甩给前端，估计不行，因为总条数的变化只有后端知道，必须得后端修了。

三、设置分页合理化

咋一听这个BUG有点儿复杂，但如果你使用的是PageHelper框架，那么修复它非常简单，只需要两行配置。
在application.yml或application.properties中添加

pagehelper.helper-dialect=mysql

pagehelper.reasonable=true

只要加了这两行配置，这个BUG就能解决。因为配置是全局的，如果你只想对单个查询场景生效，那就在设置分页参数的时候，加一个参数，如下：

PageHelper.startPage(pageNumber, pageSize, true);

四、分页合理化配置的原理说明

这个BUG如果要自己解决的话，是不是感觉有点头痛了，但是人家PageHelper早就想到这个问题了，就像游戏开挂一样，一个配置就解决了这个麻烦的问题。
用的时候确实很爽，但是我却有点担心，这个配置现在解决了这个BUG，会不会导致新的BUG呢？如果真的出现了新BUG，我应该怎么做呢？所以我决定研究一下它的基础原理。

在com.github.pagehelper.Page类下，找到了这段核心源码，这段应该就是分页合理化的实现逻辑

// 省略其他代码

public Page<E> setReasonable(Boolean reasonable) {

  if (reasonable == null) {

    return this;

  }

  this.reasonable = reasonable;

  //分页合理化，针对不合理的页码自动处理

  if (this.reasonable && this.pageNum <= 0) {

     this.pageNum = 1;

     calculateStartAndEndRow();

   }

   return this;

}

// 省略其他代码



// 省略其他代码

/**

 * 计算起止行号

*/

private void calculateStartAndEndRow() {

    this.startRow = this.pageNum > 0 ? (this.pageNum - 1) * this.pageSize : 0;

    this.endRow = this.startRow + this.pageSize * (this.pageNum > 0 ? 1 : 0);

}

// 省略其他代码

还有一些代码我没贴，比如PageInterceptor#intercept方法，这里我整理了一下它的执行流程图，如下：

看了图解，这套配置还挺清晰的，懂了怎么回事儿，用起来也就放心了。记得刚开始写代码时，啥都希望有人给弄好了，最好是拿来即用。但时间一长，自己修过一堆BUG，才发现只有自己弄明白的代码才靠谱，什么都想亲手来。等真正搞懂了一些底层的东西，才意识到要想造出好东西，得先学会站在巨人的肩膀上。学习嘛，没个头儿！

前几天，一位师弟约我吃饭，师弟跟我同校同一个专业，2022年本科毕业，比我低很多届，目前在华为工作。我们聊了很多母校的共同回忆，最近几年应届生求职的情况，也聊到了他在华为的工作经历。

师弟性格开朗，为人谦和，属于在学校各大社团特别混得开的那种，成绩也不错，保研到本校，但拿到华为offer后，放弃了继续深造，选择直接就业。

聊到当今应届生求职现状时，感慨万千。

我的母校是一所普通211，部分专业比较有特色，在行业属于领先地位，但学校整体名气一般。

记得我们大四毕业时，就业行情还比较好，每个班都有好几个同学进入了华为。读研后，实验室的师兄师姐基本都拿到了华为offer，等我们开始找工作时，大部分同学也都拿了华为offer，华为基本属于大家的保底选择。

师弟去年毕业时，他是专业唯一拿到华为offer的学生。这几年的就业形势，本科生基本找不到什么好工作，除了继续读书深造，没有更好的选择。

短短的几年，社会瞬息万变，就像坐上了一辆过山车，身处其中的人，也只能仅仅抓住车身的杠子，在急速下坡时，不让自己摔下来。

师弟进入华为，原本是一件很开心的事，短短一年，经历职场拷打，再也没有大学时代那份锐气。

华为属于员工人数最多的科技公司之一，每年吸收了大批校招生，但员工离职率也非常高。

师弟反馈，跟他同一批进去的人，很多干了几个月就离开了，他是那一批少数还留下来的人。

刚入职时，每个人都要参加新员工入职培训，那时候大家都很骄傲和自豪，也非常认同企业的价值观和文化。

但当真正的分到项目组开始工作时，发现大家实际工作情况，和价值观上说的，并不不太一样。在基层落地时，价值观更多是挂在墙上的标语。

领导也基本不太关心员工的成长和未来发展，更多是把每一个员工当作生产工具，哪一件工具用的顺手、更能出活儿，就会用谁；还没证明过自己的工具，或者经验匮乏的工具，很有可能会被无情抛弃。

华为的假期还可以，但大家有什么事，都不太敢请假。即便是生病，如果不是非住院不可，也不太会请假；公司支持请假，但大家还是轻伤不下火线，请假会影响出勤系数，各种与之相关的奖金，也会大打折扣。

……

师弟还分享了工作以来其他的一些心得体会，一句话总结：职场很残酷，相比起来，大学轻松太多了。

在我看来，华为还是中国一流的科技公司。大部分人，还是要挤破脑袋才能进得去。

华为有很好的制度，比如员工转岗，门槛还不太高。华为支持不同工种互相转岗，比如，干技术的，有一天不想写代码了，可以转人力，或者转销售。开发太累，也可以转做测试。公司会提供基本的业务培训，还有三个月的考核期，只要达到一定的用人标准，就能转岗成功。

华为还有很好的奖励制度，只要能吃苦，且绩效不太差，能坚持下来，很多人最后都获得了丰厚的回报。比我高一两届的师兄师姐，还有跟我同一届的很多朋友，现在都还在华为，过得还不错。

华为还有比较完善的福利体系。在各地的办公区，远离市区，地价也很便宜，平时在公司会有夜宵、员工餐厅、下午茶和健身房各种福利，也有些地方，会有单身公寓。进入华为后，除了工作，也没什么社交，公司能满足日常的衣食住行。平时挣的钱，基本都能存下来，成家后，在华为附近买房，也基本衣食无忧了。

华为是一家跨国公司，如果是干技术支持或销售，还能享受去各国打卡的福利。在年轻的时候，能去更远的地方走一走，也是一件很宝贵的人生经历。

华为是中国众多私企大厂的一个缩影，也是最早践行狼性文化的一家公司。

如今的字节、阿里等互联网企业，也在走华为的老路。

这些大厂，给了年轻人一个令人向往的机会，但并不适合每个人。如果我们能早些看清现实，自己只是大厂的一颗螺丝钉，需要做的是，尽快掌握螺丝钉需要具备的技能，与此同时，如果借助大厂的势能，多开眼界，多认识一些各个领域的前辈和牛人，把企业能提供的资源用到极致，就更了不起了。

至于在公司里寻找朋友、寻找归属感或者安全感，那并不是一个好选择。同事间的八卦，公司股价的涨跌，CEO的致辞，也并不是我们需要关心的事。

最重要的是，无论在大厂还是小厂，在国企还是私企，都要拥有良好的心态。最怕的是，在国企羡慕华为的工资；在大厂，又羡慕国企的朝九晚五。

人生在世，各有各的不易。每一种选择，都没有对错， 选择了其中一个，在另外一部分，就得有所取舍。

在任何时候，学会“自洽”，与生活和解，与自己和解很重要。

大家好，我是程序员凌览。又看到一个独立开发变现的故事，来分享下。

以下是变现分享内容：

大家好，我是Dmytro Krasun, screenshotone的创始人，这是一个简单的API，可以将任何网站的URL转换为网页截图。

人们经常惊讶于你可以通过自动截图网站来建立一个业务。如果你想在你的应用程序中显示任何网站的截图，那么就需要我的产品。

我才刚刚开始，但已经成功地将我的“小”产品发展到月收入2200美元。

你是如何想到这个主意的?

在开始我现在的产品之前，我是一个服务器端开发人员，工作了大约10年，薪水还不错。那时我写了15年的代码。

我有一些业余项目，我想尝试成为一名企业家。但在我工作的时候很难发布任何东西。我总是完全专注于我的日常工作，这是优先考虑的事情。这可能就是为什么我成长得很快，赚了不少钱。

一个机会几乎是“偶然”出现的。我家有了一个新宝宝，我休陪产假，我想这可能是一个好时机，我可以把时间花在抚养孩子、建立和启动一个项目上。这是一个艰难的决定。

最终，我决定毫无计划地跳进未知的世界。可能，因为我只是疯了，这“感觉”像一个有趣的冒险。

我是一名服务器端开发人员，在构建api方面有着丰富的经验。我坐下来写下我遇到的所有问题。我选择了一个随机截图API。我决定在运行中验证它，看看是否有需求。

然后我开始建造它。我谷歌了一下，发现有很多竞争对手，而且都是不错的。一开始我很失望。但后来我意识到，这意味着市场已经得到了验证，我只需要在细分市场打造出最好的产品。

请向我们介绍构建第一个版本的过程

在2022年1月5日买了一个域名，建立了一个简单的网站，开始写与我未来产品相关的内容。看看我的第一个丑陋版本的登陆页:

我写下了我在构建产品时遇到的任何问题，以及如何通过使用我的产品来更快更便宜地解决这些问题。

例如，我的截图API允许你在渲染截图时隐藏广告和cookie横幅，所以我写了如何自己免费做到这一点，并推荐我的产品作为替代方案。事实证明，这是一种推动转化率的有效方法。

seo优先的方法帮助了我，5个月后，当我发布产品时，我已经有了流量，我可以利用它来盈利。

我开始构建一个仪表盘应用程序，让潜在客户可以试用产品、查看使用历史、升级计划和配置通知。它是由Go渲染的纯HTML、CSS和JavaScript。我是一名服务器端开发人员，不知道如何使用现代JavaScript框架。

我将产品的第一个版本托管在Digital Ocean droplet上，然后当我开始增长时，我开始使用Render，然后需要更多的弹性服务器，并转移到谷歌云平台上。一周前，我启动了一个新的Kubernetes集群，以减少我在Google cloud Platform上的成本使用，它已经运行良好。

描述创业的过程

当我的产品的第一个版本准备好时，那是在2022年5月底，我已经从谷歌获得了一些相关流量，因为在发布之前创建了内容。但这还不足以促成销售。在Reddit, Indie Hackers，论坛，目录和Twitter上写文章。

最后，我总结了我在Indie Hackers的第一个营销月所做的一切。这是当月最热门的帖子，并迅速传播开来。

我几乎要放弃了，我累了。最终，在2022年7月4日，我迎来了第一位付费客户。我永远不会忘记这一点。我在Twitter上的朋友Jannis正在为创作者创建一个工具目录，并希望自动截图工具。

如果我今天重新开始，我不会从SEO开始。我会快速构建一个带有付费链接的原型，并尝试着将其展示给潜在的感兴趣的人。SEO是一个长期的游戏，它需要一个长期投入的工作。

是什么吸引并留住了客户?

根据我目前对市场营销的理解，没有什么灵丹妙药。你需要找到2-3个可以持续获得客户的渠道。除了实验，没有其他方法可以做到这一点，看看什么有效。

对我来说，搜索引擎优化、谷歌广告和推特都很管用。但我测试了Reddit、Indie Hackers、Twitter Ads、LinkedIn和其他平台。它们都是有效的，但问题是你可以反复从哪一个中获取客户?

我在Indie hacker上分享了我简单的SEO策略——我基本上是快速创建内容，获得流量，分析并更新内容。

对于X (Twitter)，在早期，我积极推广我的产品，到处提到它。但感觉很尴尬，所以我就不再那样做了。开始专注于帮助人们，解决他们的问题，回答他们的问题。人们开始知道我在做什么，如何找到我。现在看到别人会主动去推荐我得产品。

我的主要流量来源是Twitter (X)和Google。我在Twitter上有1万名粉丝，这有助于推广我的产品。在搜索引擎优化上付出了很大的努力，现在我得到了回报。我的产品在细分市场中最具竞争力的关键词排名前5位，比如“screenshot API”之类的。

我认为没有捷径可走。无论如何，尝试每一种方法，找到最适合你的方法。

对其他创业者有什么建议吗?

先把你的野心放一边，试着一个SaaS软件或一个简单的应用程序来赚第1美元。一旦赚到钱，试着赚10美元，然后是100美元。不断重复，直到你确定创业真的是你想要的，并且你喜欢所发生的一切，不管结果有多难。

一旦你意识到这是你喜欢做的事情，不要放弃。如果你赚了1美元，10美元，然后100美元，你不放弃，那么一切皆有可能，只有天空才是你的极限。

别听任何人的建议，包括我的。只有你自己决定，如果你最终决定回到一份正常的工作，这是你的生活，你只能活一次，请保持自己的快乐。

"先把你的野心放一边，从赚第1美元开始"

有幸拜读了诸多掘友的年终总结，那些压力、纠结、卷、焦虑，我仅透过文字就感受到了，所以我又写回了上一年的主题了~

我没再去写什么总结，反省啊，我只想轻松再带着些许俏皮的回顾一下2023年我在世界上存活过的痕迹，欢快些吧，生活总是要活下去的。

有时候，我们健康的活着，我们已经很棒啦。

这篇文章我更多的抱着分享生活的想法去写的，不谈及那些重的话题，更像是活在当下的人吧

所以如果你是想要获取一些总结上的经验或者一些思考，可能我这篇年终文并不那么适合你。

博客较长，文字较多，希望朋友你能慢慢的读，犹如生活要慢慢的过。

今年有幸在湘江边、珠江边和黄浦江边三地留下足迹，三处不同的场景，三种不同的生活状态，不一样人生阶段的结束和开始。

起伏跌宕的开始😀😟

和朋友一起在长沙度过了2022年最后一天，不知疲倦的在那个五一广场，一群人看着手机，数着秒表，大声呼喊着度过了2022年的最后一刻。

可时至今日，去年一起跨年的朋友，现在已经相隔千里了，而今年多半是在房间里面一个人度过这2023年的最后一刻啦。

想到了去年写的那句“去年陪在你身边的人，如今还在你身旁吗？一年过完了，你的生活有变化吗？今年你过得开心吗？ ”
人山人海，矮一丢丢，走进去就出不来啦。

人从众	2023的	新年时刻

回忆起那时的场景，调皮的人们在附近的高楼放起了鞭炮，气球在人们手上释放，一同奔向星空。

（可惜这一幕我已经没有原视频啦，现在突然回忆起那个时刻，才发觉时间真的好快好快，一晃而过啊）

说起来，那还是我第一次在长沙看到那么那么多的人，也从没想过一个地方的退场，需要走半小时，打车更别说啦，都直接交通管制啦。

看起来这一切都像是美好的开始啊。

但在那一晚的九点，我接到了来自家里的电话，让我抽空回家一趟，看一看最疼爱我的爷爷。

可殊不知，那是我和他的最后一次交谈了。

“只愿世间永无病痛”。

长大后，那深夜里的电话🥺

长大后，才知道深夜里的电话，无一例外都是大事。

那是在某晚凌晨4点时接到我父亲打来的电话。

其实看清是我父亲打来时，我就清楚知道，小时候最疼爱我的爷爷可能去向了另外一个世界了。

当时的我真的算是非常平静，开始思考工作相关的事情，准备和领导请假，订高铁票，我以为我真的会非常平静的。

图一：等地铁

但当离家越来越近时，我才明白有些情绪是没有办法隐藏住的，有些崩溃就在某一瞬间。

图二：回家的路

我看着我的奶奶流泪，我觉得她好无助啊，那一瞬间，我崩溃了。奶奶陪伴我爷爷一生，却剩她独自去过这余下的时光，（我小时候是和爷爷奶奶一起长大的，一直到我上小学之后，但那之后我每年的寒暑假也都会回到乡下去陪爷爷奶奶，只是不知道从什么时候开始，变得不再那么想要回去了）

奶奶很小就嫁过来了，可以说我爷爷就是她拥有的一切啦，儿女子孙大多在外拼搏，她自己也不愿意去麻烦儿女子孙了，所以说，这余下的日子大都是她一人度过了。

有很多时刻，我都不愿去深想，那将是怎样的一个生活。在写这一段的时候，我非常想给她打一个电话，但是我的奶奶她已经非常听不清啦，只有偶尔父亲回去时，通过我父亲的传递才能更好的交流。

所幸在去年爷爷奶奶还算健康时，我回到家里陪他们。那一次我非常认真去和他们促膝交谈，安安静静的听他们说他们当年的故事给我听，而我也有幸做了一份录音，只是日后不知道有没有去倾听的勇气。

今年回去我有一些想法了， 比如去给奶奶买一个助听器，再去装一个可以对话的摄像头，这些我终于都可以去付出实践啦，我现在有些期待过年啦。

那时的我其实也写下了许多文字，关于病痛、选择、亲情、离世、我的父亲、我的奶奶、亲人、还有村里各位长辈，也有很多很多思考，但可能不那么适合写出来吧。

只能说在有那么一刻，我深刻且贴切的感受到了亲情的冷暖和选择的无奈吧。

也有那么一瞬间的快乐吧，看着五岁的侄女，开开心心的，不免也有些被感染，彷佛从她的身上，才能看到那些无忧无虑的快乐啊

小时候日日期盼的长大，长大后才知道长大是这一生最大的苦痛啊。

短暂的相聚时间啊 😒

自从进入社会，开始成为一名社畜后，寒暑假的消失，让能待在家里的时间开始变得愈来愈短了。

好像每一年的开始，我们的时间就已经被定好啦。

以前的过年，其实最好玩的是过年前的那段时间，家里开始筹备年货，准备各种各样的吃的，熬夜打游戏、看电视，一起嗑瓜子啊，和朋友们一起聚会啊，但现在已经变得越来越少啦。

回归中心，继续聊这个短暂的相聚时间吧，文字可不是拿来抱怨的呀~

今年回去，我也开始从我父亲那接过啦一些活，比如准备年货，包蛋饺等等，还有一些杂食，都交给我来做，在那么一刻感觉自己长大啦

另外每年大家来我家干饭的时候，总是要喝酒，我老爸又喝不了酒，就是我来陪酒，今年我几个弟弟，直接把我喝趴啦，麻啦麻啦

不过也只有在家里可以那么那么放松啦，出门在外，又能有几回这样的时刻呢？

返回社畜岗位前，把自己的房间收拾了一番，晒给大伙看看吧

部分小玩偶	房间里的书桌

当时租房里面的小书桌，这个小桌子，也陪伴了我将近小一年，2022年的博客大部分是在这个小书桌上敲出来的，也是我看电影、刷剧的小书桌啦~

轻松愉快的时光 😊

生日、吃饭、按摩、记录生活、离开前的放松时光

清楚的记得，这是我今年第一篇日记朋友圈的开始，写的很长很长，还放了自己的自拍照

顺颂时宜，百事从欢

打游戏&按摩篇

身边有个社牛朋友，快乐有时候会变得很简单啊，笑点也会随之一降再降啊，哈哈。

我俩在游戏城的时候，他拿全部彩-票换了把M24，他说：“这是他绝地求生，丢了所有装备都要捡的枪”，他拿到枪后的第一时间就是看看哪里有小孩子，说这必须得让他们看看，男人至死是少年，哈哈哈。

观影篇

夜晚一起去按摩的时候，看了电影《人生大事》，借用一句豆瓣的影评：“人生除死无大事，天上的每一颗星星，都是爱过我们的人”。 在今年的年初，我也亲眼看到了一颗星星缓缓上升啊，请各位要早点爱自己所爱的人，人生总是在不经意间就会留下遗憾，但是我们就是不要……不要留下太多遗憾啊。 在一切都还来的及的时候，去爱你身边的一切，去尝试生活，去绽放自己的光芒，那就是属于你的人生大事啦。

后面还去看啦流浪地球，我能说的是“十分震撼人心，这是一部值得我推荐的电影，如果有可能的话，一定要选择 IMAX 影院，观影体验会更佳，也更能展现这部影片的大制作”。这部真是为数不多让我在朋友圈中写上这么主观的电影观后感的片子啦。

脱口秀篇

第一次去观看了线下的脱口秀表演，那时候我才知道，原来脱口秀演员，大都数是兼职的。

观看体验的话，具体得看演员玩的是什么样的梗，有优雅的，也有不太优雅的，还有一些内容是16岁以上的朋友们才适合明白的，遇上一个能活跃气氛并且能和观众们互动的表演者的话，体验就会非常好，如果平平淡淡的话，就会显得有点枯燥啦。如果要想深度体验，就要坐第一排，那样乐趣会多很多，不过前提是需要能够接受调侃。

（补充：一定要遇到开合适段子的脱口秀表演的演员，有些重口味的，是有点难受的）

哦对啦，还遇到了一位杭州的朋友赠送了一份属于ta的运气王的票和夜宵套餐

干饭篇 🍻

干饭篇（一），长沙的《一盏灯》，主打一个辣，不过味道还是蛮不错的，哈哈哈

干饭篇（二）名称忘记啦

这是第二天我生日时，拉着朋友一起去了另外的苍蝇馆子

那天聚会的餐桌旁，有一位同年同月同日生日的伙伴，我的社牛朋友就拉着隔壁桌的朋友一起给我唱生日快乐歌，让我也给人家唱生日歌，我只能说当时我的脚趾在扣地啦

不过也算是有缘认识到新的朋友

即使许久之后再看到那天的视频和图片，也仍然觉得是有趣和有缘

干饭篇（三）北二楼大排档

接脱口秀篇的夜宵套餐，这家店味道是真不错，值得我推荐。

哈哈哈，来长沙可以去试一下，味道和价格都可以，唯一的缺点就是排队排的太久啦，当时我们两个好像从夜晚八点排到了夜晚十一点，中间去了那个HIB HUB公社酒吧溜达，我们两个去看男孩子跳舞，哈哈哈哈

我是真佩服那会的我们，吃的是真多啊，这我们两个人的吃的量...

干饭篇（四）烤肉店，店名忘记啦

我们一伙人在一起，主打一个笑点低，啥事都能笑半天，我这种高冷boy直接被同化成搞笑boy

干饭篇（五）喝酒&夜宵

这个忘记是哪一天啦，只隐约记得，凌晨三点多，一起喝完酒，和朋友一起在街边买烤串和麻辣烫，那时候是真放纵自己啊，现在是吃了晚饭，就坚决不吃东西啦，我要减肥啊啊啊啊

清吧喝酒	街边小摊的夜宵

美术馆&看展 🖼

在长沙的时候，一个人去了长沙美术馆—齐白石先生的画展，在馆内看到了曾经语文教科书上那画得惟妙惟肖的“虾”

我本没有艺术天赋，去看展大都是静心养气，瞎逛闲逛，但有些美，它就是美得非常直接，直击你的心灵。

有些画本身就真的非常美，你一眼看上去，就会立马喜欢上，换我也想收藏这些画😃

云海夕阳	蚂蚱	独身一人	虾

总的说来，这可能是我这一年来最放松的一个月啦吧，这么吃喝玩乐的原因也是朋友准备离开长沙啦，就聚一聚，在长沙逛一逛，吃一吃。我也非常开心，看到自己有留下这么多的瞬间和记录。

在此时此刻写下这些文字时，我才感觉自己有真实的在这个世界上活过一样。

裸辞 | 年少轻狂或是年少无知吧 🤡

在去年我就有考虑离职，但一直没有行动，主要一方面是能力不足，第二个是没有足够的存款，无法承担裸辞后的风险。

但直到我正式提出离职，其实我也还没有准备好，只是觉得拖得太久啦，不能再内耗下去啦。

离开

我最终还是决定离开了我职业生涯中的第一家公司。

总的来说，其实这家公司各方面还蛮不错的吧，位于长沙、双休、不加班、偶尔也有个下午茶。当然这都是不谈薪资的情况下，哈哈哈。

只言片语聊一聊离开的原因吧。

关于离开，这个想法其实在进入这家公司数周后就有啦。熟悉一家公司所要花费的时间，真的没有想象中那么长，几周到一月，大致就可以把所属团队的技术栈，技术水平、团队氛围、领导性格、团队主要工作方向都了解的差不多。而通过这几点，大致就可以决定或影响你在这个团队中所待的时间啦。

对于我这种年少无知的年轻人，那个时候我最看重的是技术水平，如果让我觉得没有技术可以继续学下去啦，就会下意识认为继续待着是没有意义的啦。

但是换到现在来说的话，有几人又能够一直做技术基建工作呢？在小公司又能做什么样的基建呢？另外IT人这么多，大家都卷技术，又能卷赢谁呢？无疑都是为了生存下来罢啦。

另外很大程度上是业务推动技术发展，你如果没有十万级的数据，坦白说你日常开发中，真的不会老是去想怎么优化SQL，改数据库配置之类的，没有百万千万级，很少有机会去思考去实践分库分表这些操作，不得不说，平台真的非常重要的。

我现在还记得去年我写到一篇文章，聊到过“团队>领导>个人努力”，优秀的团队，放手让你干的领导和努力的自己。

说回这小节的中心吧，我跳出属于自己的那个舒适圈，有以下几点原因吧：

1、年轻气盛。想的是年轻再不出来看看，以后混不下去了，退路都没有啦

2、学习技术。想要学习更多技术相关的知识，薪资可以少，但吃饭的技术不能停滞不前。（不过现在看来，还是蛮天真的，现在是有个班上就行，哈哈哈哈）

3、完整的软件开发流程。想要经历从零到一的项目，项目需求、文档、画图等等，都想要去了解一遍，而不仅仅是开发代码（事实证明，浪浪山外还是浪浪山，只是山大了一点，爬山的人多了一些。）

4、薪资问题。（这个对于当时的我算是问题也不算是关键问题吧，当时真觉得是只要能获得成长，我就觉得非常OK，现在让我选的话，哪家给的多就去哪家啦😂）

心路历程

团队内交流。最开始对职场是陌生的，这个要离职的想法并没有太藏着，团队的老哥都知道我这个想法，当时都挺照顾我，也没谁介意这个问题，后面在真的到离开的时候，老哥们提醒我，下次如果再离职，千万不要声张，悄无声息的就好。后面仔细想想确实是这样，你大大咧咧的说，比较影响公司团队氛围。

与人事交谈。最开始正式知道的我想要离职的第一个人是人事，因为人事和我谈岗位调整的问题，需要增加一个运维的工作给我，附带调整薪资。但那个时候我，我已经想要提离职了，就不想在交接工作时，再附加其他问题。我就提出了近期可能会离职的说法，提了之后，我的身份就变得十分敏感啦。那会人事有事没事就问我，打算什么时候离职啊之类的。现在回想起来是真不应该啊，说了之后导致该调的薪资也没了，也被大领导关注到我要离职的事情啦。

与大领导谈话。人事知道我的想法后，就向上汇报啦（与大领导认识，他是想让我之后接实施的活，后续与他和项目经理一起去到项目上）。他了解完我离职的想法，先是肯定，后谈薪资，谈未来工作，定军心，提出挽留；不过最后我还是婉拒啦，抱着那一丝对大城市的向往跑出来啦吧。

与直属领导交谈。最后和直属领导了提出了正式离职的想法，与大领导类似的，也是支持和提出挽留，我都一一拒绝啦，最后只有支持和祝福啦。

正式离职。交接工作、清理账号权限、格式化文件、领导签字、人事签字，拿到离职证明，和团队中的各位伙伴说再见，也是下次再见。

坦白说，当走出公司门，还是有那么一些不舍吧，就感觉以后不会再踏及这个地方，只能是一段回忆的感觉啦。

短暂的轻松快乐。刚离职的时候还能的听《蓝莲花》，还能打一打王者。后面真的是...

出远门前，还回了一趟家，和老爸老妈待了几天。

无意中聊起年龄、结婚和生孩子的问题，才发现我家老爸老妈转眼间也老了，白发也开始显眼起来了。上次聊到这个话题还是在朋友家听她谈到相亲的话题，说她的父母五十来岁，年龄再大些，站到台上就不那么美丽啦。

心情也莫名沉重了几分~

那时候想到今年的Flag之一是带着父母出去外面按按摩，洗个脚，在那一刻想的却是今年要多挣点钱，过年回去的时候，陪他们一起去医院好好做个完整的体检，好让他们在之后的岁月中可以平安健康的享享清福。

不过现在看来是都容易啊。

最后的最后也只是回家简单吃了两顿饭，然后就踏上了去远方的旅程啊。

也许我们回家和离家的路总是开心的，可父母都是站着门前望着，一个是望着回来，一个是目送着你的离开。

羊城飘荡 🛫

到啦这边之后，投了差不多两三周之后，情绪心态已经完全不一样啦。

那份来时的轻松自在已不再了，虽不至于坐立难安，但也是焦虑丛生啦。

不过认真说起来，在羊城的那段找工作的时间，虽然没找到工作，但说真的其实开心还占了多数，可能还是和那群一起爱搞事的兄弟们。

坦白说，写出来，我感觉有些小伙伴都不太会相信，在一室一厅的房间里面，最多的时候一起住了五个大兄弟，哈哈哈哈哈哈。

当时都是碰巧辞职或者是想在羊城或者鹏城找个工作，就从最开始的两个人，一步一步的凑到了五个人。

那会可以说整个房间可以说是能利用的都利用上啦，房间里的地板、木板床、沙发都睡着人。

突然想到啦那句“三块是面子，四块是生活。不是小瓶买不起，而是大瓶更有性价比。”

我们则是”不是房租出不起，而是一起住更有性价比“，也感受了一番城中村的生活

在那间房里我还有另外一个身份，”大厨“，那时候也靠这件事情转移我的注意力，同时也算是造福几个哥们，给他们做了一段时间的饭菜。也只有在做饭的时候，我不用去想找不到工作的焦虑

落地羊城后的第一顿饭	我第一次做九转大肠

生活也蛮有意思的，凌晨夜话；失眠拉着大家一起发疯；翻来覆去睡不着时，就要问一嘴谁还没睡，起来聊会天；一起出去玩，逛动物园、博物馆、广州塔、大佛寺、相亲角等；还有夜晚出去散步一起喝蜜雪冰城，哈哈哈哈

逛相亲角还蛮有意思的，以前都是在网上看，真来到线下，看到那一张张如同商品挂在上面的个人介绍，压力顿感庞大，优秀的人真滴是太多啦。

夜晚的小蛮腰	大厂

广东省博物馆	动物园

明年有机会应该去看一看上海市博物馆。

另外还凑了一波雪王的不倒翁，来到魔都也想继续凑的，但是这边没有卖，遗憾。

非常感谢有他们，我才能够较为开心的度过了那段十分焦虑的求职时期吧

后来的后来，我因为身边其他兄弟引荐，机缘巧合下来到了魔都；一个则找工作去了新疆；还有一个也留在羊城了，不过已经不再从事编程这一行业啦。

真正意义的相隔千里了，只有在年前年尾才能短暂的再相聚了呀

在羊城的时候，机缘巧合下，博客有帮助到一名网友，碰巧也在广州，就线下一起面基啦。

当时他还在中国建设银行实习，一起吃了个便饭，聊了很多，溜达了一圈，看了广州塔，我也有不少收获。

关于这一点我多补充一下，多和行业内的小伙伴们交流，我个人觉得真的是有意义的，大家可能都是做开发，但业务可能不同，技术栈可能不同，背景不同，很多想法也是不一样的，每次交流可以收获一些以往不知道的知识吧。

离开后，已许久未曾联系啦，希望一切安好和顺利！祝福

人这一生就是在不断的遇见和离开，珍惜每一次的相遇，或许就是我们能做到的最棒的事情啦

辗转流离 🚄

为啥说是辗转流离勒，还要听我细细道来啊。

长沙裸辞

从长沙裸辞，我就回了趟家，看啦看我的老爸老妈，在家真的只能待三天。再久，那个经就会念起来啦，哈哈哈。所以三天一到，我就踏上了去往羊城的道路啦。

当时是还没被社会毒打，心情还不错，后面真的是心态一崩再崩😐

现在想一想，我都觉得当时的自己是真勇敢，换现在的我，真的不敢裸辞啦，手上没余钱和找不到工作的焦虑真的太折磨人啦。

羊城飘荡

还是多亏有兄弟照顾，来到这边，有个住的地方，没有太多的经济压力，只要认真投简历，找工作就好。

即使后面投简历投到心态爆炸，也因为有兄弟们一起陪着，让那些焦虑生了又灭了。

如果心里有事情，是可以找一找身边愿意倾听的朋友说一说的，当然不是长期输出负面情绪，而是适当的说一说，憋在心里容易出问题。

鹏城溜达

要离开前，去鹏城溜达了一遍，和我的表哥表姐吃了一顿饭。因为离开广深地区，下次再相聚也就只能是过年啦啊。

我姐的小女儿，超级可爱的小侄女~

写到这里的时候，我还想起了当时答应她，下次去要给她带玩具，我还写了备忘录，过年要准备准备啦

和我老哥晚上吃夜宵，但没想到的是，这顿生蚝将是我今年吃的最爽的一次🤡

（xxxx，上海夜宵店上的生蚝，真不知道是个什么超级刺客价格，真的该死，我这还是在深圳商场里的夜宵店里面吃的，又大，而且比起上海便宜好多，我真的气死啦）

烧烤	鲜甜的生蚝

转战魔都

转战魔都前，我又跑回家躺了两天，你没看错，我又回家躺了两天，其实也是感觉如果来了魔都，可能要等到过年才有机会回去啦【事后确实如此】

然后从湖南出发去魔都~

昂贵的高铁费	上海虹桥站	来接我的科科	ikun之家

我这个小黑子成功加入ikun之家，开启啦在ikun之家的生活~

来到上海后，重新整备后的书桌：

工作 | 新的启程 🐱‍💻

转变

来到魔都后，工作方向略有改变，不再是单纯的Java开发吧，没法单纯的说是什么样的工作吧，定位也不够准确。

另外也是目前没什么大的成就，就不太想谈论工作这个话题，明年慢慢去更新更多的文章，会一步一步谈论到现在的工作吧。

不过我还是活跃在一线开发岗位上的，最让我苦恼的是垂直领域深度不够，非常烦啊。

但这边的整体团队氛围、管理风格都让人比较放松，工作也相比以前开心许多，有一段时间让我一度找回了开发的乐趣。

来到这边后，有几个方向的提升吧。

1、公司提供了更大的平台，接触到了更多的新事物；

2、负责的事情要比之前多；

3、技术的横向扩展拉得比较广。就是有点大网捞鱼，鱼全部漏掉了的感觉，头大。

4、扁平化的管理，让我更大胆的去做事

总的来说，是非常棒的，我也在努力的将手上的事情去做好，也在寻找工作上的乐趣，而不是麻木的工作

下班等电梯时的随手拍，剪刀手boy~

因为目前正在岗位上，有些内容是没有办法写出来的~

补充

浅浅的谈论一下求职这个问题

我在去年和今年年初都有求职的经历，只差一年，但感受相差甚远。

求职

去年的情况还只是有些糟糕，但还能约到面试，到处也还在招人。

今年离职出来的时候，可以说是寒气逼人，先说我自己，我是陆陆续续投了一个月，投了1.5k左右，能约到的面试少之又少，贴几个朋友的求职经历：

朋友1，求职前端开发，base：深圳、广州、厦门，boss投递3k+，4个月还没找到份前端开发的工作，最后转行啦；

朋友2，求职Java开发岗位，base：深圳、广州，boss投递1k+，最后找了个外包去了新疆；

朋友3，求职前端开发，base：深圳，找了近3个月，最后转回安卓，上个月才收到一个安卓岗位的offer；

朋友4，求职Java开发，base：成都，有美团短期实习经历、银行6个月的实习经历，在成都找了3个月，上个月才入职新的公司，转向 kotlin 开发啦

上述都是求职初中级开发，年限1-3年

收简历

这边公司有开放过岗位，因此有过收简历的经历，浅谈一下，当时两周左右，看了将近300份的简历，本科生研究生的简历都不少，就我个人看简历的心态变化大致是以下几个阶段：

最开始：每一份简历都看的非常认真。看技术栈、项目经历，比较需求匹配度，后面再看学校如何，判断是否进一步交流；

中间阶段：每天都收，真的太多啦，有时候看都看不完（有工作，可能是每天晚上回到家才看），开始转变成，没有get到需求可能就忽略了；

后期：只要基本满足条件，学历优秀的优先谈。不行就下一个。主要会去关注下面几个问题，基础条件是不是满足；相关的技术栈的熟练程度；进行前期沟通，了解性格，初步判断能否融入当前团队；入职后，能不能发挥他应有能力；稳定性等方面的问题；

小小的思考
今年我求过职，同时又收过不少简历，后面就补了这么一个小节。

找工作难，招人也难。

说实话，如果没有实际工作经历，看十份简历，有六份简历中的内容基本上大差不差的。

你说怎么选。

以前是想着跳槽涨工资，或者是想找个好工作，今年的想法是能有个b班上就不错啦。

魔都生活 | 出游 | 干饭

在魔都的日子，出门时间其实不算多，工作日的三点一线，休息日的步数100，总的来说，不是在干饭的路上，就是在干饭的桌上。

外出篇

大魔都的标志性建筑物--东方明珠塔。

美是真的美啊，也是来到了外滩才深刻感受到金融到底多么挣钱，外滩这边一条街，全部都是xxx银行，感觉没有一栋楼，都不好意思说自己是个大银行啦。

白昼时的东方明珠	傍晚时的东方明珠

夜景更美一些，要不是上塔顶的票太贵，我感觉我已经冲啦

豫园

国庆假期时过去溜达的，当时好好的感受了一下上海的City Walk

挹秀楼	阁楼

有没有觉得第一张照片中阁楼里的两个闪光灯非常有趣呀~

广富林遗址和醉白池公园

天高云淡时，和室友一起外出骑行，去看看外面的风景~

广富林遗址	醉白池	含苞待放

游泳

和两个小伙伴一起去游泳。不对，他们两才是游泳的，我是去喝盐水，是的，我这个小菜鸡还是不会游泳，哭死。

不过我对于魔都这座城市知道的还是太少，那么多馆，那么多展，那么多景点，但我是动都不想动啊。

希望明年可以去做更多探索吧，如果有小伙伴一起的话，那就更好啦。

干饭篇 😲

在写这一小节的时候，我想我终于找到我自己反向减肥十斤的原因啦🤡

十天的照片里，八天的照片都是关于吃的… 我自己都不敢相信

同事聚餐、在家做饭、周末小聚、生日聚会、夜宵、外出游玩干饭、疯狂星期四，各种各样的干饭，上演各种碳水炸弹

可是今年原来的的目标要减肥的啊啊啊啊啊啊啊🥺

偶尔周末给自己和室友加餐的日子

干饭	加餐篇

与团队中的小伙伴一起在住房里面小聚一下，再加上一点小酒，不免也是一个快乐时光

热时多数是炒菜，转凉后多数是吃火锅，夏天小龙虾和啤酒更配哦，冬天则是牛羊肉更暖身啦

聚会篇	繁忙工作里的畅谈和轻松

大声呼喊着减肥，每天和室友一起吃荞麦面，还一起跳绳，但。。。

实际情况是工作日每天吃荞麦面，一到周末就是夜宵、KFC、聚餐，妥妥的反向减肥

夏天时，自制青柠和百香果的饮料果汁喝，非常爽哦

青柠	百香果

（别看我说的这么好，实际上我把所有装备买齐，就做了三次，哈哈哈哈）

外出干饭，聚会~

补充：黄酒初喝不上头，喝多啦该醉还是醉，下次我要坐小孩子那桌去

温暖你的猪	小餐馆	淞沪名灶	和记小菜

安徽

今年有幸到过两次安徽，一次是去了黄山，一次是去了合肥，尝试了安徽的菜，我觉得也蛮好吃的，可能也是偏向于辣和咸，挺合适我这个湖南人滴

总的来说，感觉内陆省份的菜品都偏向于重油、重盐和重辣，而沿海省份，感觉就是鲜、淡、甜，吃食材的本味~

忘记名称的店	脑海中只记得吃啦	地锅鸡

我们这群人属于是，遇上开心的事情，烧烤配啤酒；碰上不开心的事情，也是烧烤配啤酒！！

开心烧烤配啤酒	不开心也是烧烤配啤酒

疯狂星期四

以往都是说段子，后面真是每周都过疯狂星期四，碳水炸弹

细细想来，我的长胖好像也是有迹可循的，没写出来前，我日常还觉得我自己吃的不多😂

总的来说，在上海的周末做的最多的事情就是干饭啦。

室友篇

从个人生活状态转变到合租生活状态，其实有不少改变的。

不过非常幸运的是，在这里遇到的每一位室友都非常棒，也分别给我带来的不一样的影响。

首先第一点，室友们都是大厨，这才有了上述那种每天吃吃喝喝的生活。

如果要是我一个人独居的话，吃饭在我看来更可能一种任务，随便应付一下就算是完事啦，根本不会去想着一荤一素，更不会想着好好做个菜啦，哈哈哈

keke哥哥。最开始来到魔都时，我没有另外再出去租房啦，就是和keke哥哥一起睡。因为他有考虑后面要搬出去和女朋友一起住，所以最开始我们就是睡一起的；坦白说，如果他女朋友没来，他最后没搬出去住，我感觉我们两个男生才像谈恋爱的感觉【捂脸】

生活非常同频。今天我买菜做饭，他就洗碗；隔天他买菜做饭，我就洗碗；作息时间同频；有问题会直接说；一起电动车上下班；周末一起去游泳；一起吃KFC；半夜睡不着一起骑电动去吃夜宵；一起养猫；一起打游戏，cf、王者五排；安静互相不打扰，多数时候是一起同行的。有那么片刻，恍惚间有感觉像是在谈恋爱的。

这种生活一直持续到他女朋友到来，他搬出去之后才结束，说起来还是有点怀念啊。

要是谈恋爱的时候也能是这种感觉，可能我现在也不会一直单身着啦吧。

wancheng哥哥。这个叫法是因为我某一天打王者，听到一个男生在用那种夹子音叫哥哥，我一下就学会啦，然后就整天在他们的名后面加个哥哥，哈哈哈，最终的结果就是整个房间里，所有人都被我带偏啦~

wancheng哥哥是这里的大厨，要是每次有个什么聚会，肯定就是我们两个搭配掌勺，不过我们两单独某一个人都懒，但要是一起合作去做某件事情，就会非常认真的去做，想要去做好，而不是偷懒。

还有他今年经常带我一起消费，笑麻了。他买机械臂，就会非常真诚的向我安利它，陈述它的一些优点，把我说的心动，然后就是买买买；冬天来啦，他买暖风机，也会非常真诚的说这款产品的优缺点等等，最后我又忍不住去剁手；还有其他的，我自己都被自己笑麻啦。另外大家都偏向于及时享乐，我也有被影响吧，多了很多消费，也比以前果断许多啦。

对啦，最最最重要的一点，他现在不减肥啦。然后他现在是直接往住房里疯狂买零食，放在客厅的桌子上，他知道我一定会去吃，我真的哭死，他真是生怕我瘦下来啦。周末吃完饭还要再点个烤串，减肥减肥，越减越肥~

不过也有带动我共同提高。因为他老是来查我房，来查我在干嘛，是不是在打游戏；如果我是在卷的话，他也会立马回到房间去卷。当然我也会去反向查他的房，他如果不在下棋，我也会立马回到房间卷，坦白说，是有点小孩子行为的。

补充：要非常感谢wancheng哥哥，还有未曾蒙面的阿姨，才让我们在魔都有吃不完的湖南特产，剁辣椒、腊肉、腊牛肉、腊肠、萝卜条、豆鼓，对啦还有扣肉等等，真的太棒啦

另外还有一个我此前并非那么了解的室友-sian哥哥，在今年给过我很多帮助。在和他的诸多交谈中，我是真的受益匪浅，也有重塑他在我心里的印象。

在这里暂且称呼他是个游戏佬好啦。在我以前十分局限且带有偏见的认知中，对游戏佬的印象都比较一般。人的专注是有限的，沉迷于某一个事物当中，那么自然对其他事物的关注肯定不会那么高啦。

很长一段时间里，我认为阅读是最容易带给人深度思考的，但是在和他交流的过程中，我发现，其实我们专注做的每件事情，都是值得思考的。

比如他热爱建城类的游戏（请原谅我已经忘记游戏名称了），可能部分玩家是去追求那张掌控城市的爽感的，他在我看来，则是那种享受自己从零建造一切的成就感的。在那么一刻我突然意识到，在游戏中完成一个从零到一的任务，换成我们编程的说法，也就是从零到一完成了一个项目啊。仔细停下来想一想，是不是这样。

他做的更好，他将这种从零到一的思维方式，从游戏带到了现实生活中，在和他共事的过程中，我发现他的思考和规划大多是从全局到局部的。

这点我是非常想要学习的，因为我个人的观念，老是非常局限，不管做什么，我第一个想到的，总是站在自己的位置上去思考问题，跳不出去，无法抛开自己的固有思维去思考问题，犹如井底之蛙。

另外他是我身边朋友圈里，和我一样，不刷抖音的人，都是b站的深度用户，喜爱那种能够引导人进行深度思考的长视频。

不过话说回来，我感觉我今年比起往年心浮气躁了许多，以前还能心平气和的看完长视频，今年已经要加速啦。

朋友篇

今年有幸在魔都认识到一位非常真诚的朋友，见证过ta的勇敢，也见识到的ta的真诚，也有被ta写的一段话所惊艳到。

“我一生都在探索人性，我知道现实残酷人性凉薄，所以我任愿抱以真诚去对待所有人、事。

我所付出的那些金钱和精力，又比如你说我以后会吃的亏，在我看来远不及一次灵魂碰撞来的重要。

同样真诚的人难能可贵。

这条路艰难，我必定会历经诸多碰壁。

我可以被拒绝可以被推开，我都不在意，但唯独不能不真诚。”

生活状态的转变 🏄‍♂️🤼‍♀️

写完上面那部分内容，我在思考一个问题，今年的生活状态和去年还是有很多不一样的。

我在湖南的时候，多数周末还是会出去走一走；但是在上海，外出的欲望是真的低啊，直接进化成宅男啦

思考了几个原因：

1、交通不便。目前在魔都比较偏的地方吧，附近没有地铁口，只能坐金山铁路

2、外出通勤时间太长。因为没有地铁，出去一次，动辄一个小时、一个半小时，出行欲望极低。来上海近半年，准确来说我只坐过一天地铁，那时候好像还是是火山引擎的一个活动，在市中心那边的一个酒店，那天我一个人过去的。其他时候好像完全没坐过地铁。捂脸，甚至于有时候同事聊到上海几号线几号线，我完全不知道在哪。

其他时候，和室友们一起出去玩的话，要么打车，要么踩单车，要么找公司财务借车。公共交通除了当时坐轨道交通去游泳，好像其他真没坐过啥啦。回想起来，我自己也觉得有点离谱啦。

3、从个人居住状态转变到合租状态。开始习惯和与人同行，而非个人独行，以往自己要干嘛，我可能自己想啦就去坐了，当习惯有人同行后，我会下意识问ta愿意一起吗，如果他不愿意，我的意愿会降低。

4、脑子暂停转动😵。一个人住的时候，要做什么，想去干嘛，都是自己在思考，与室友一起住后，思想开始懒惰啦，比如吃饭，总想问一句他想要吃什么，不想自己去动脑子思考啦。

类比到我自己打王者也是一样，一个人单排，我会去想整体局势如何，该怎么打，人在哪，和朋友一起打，我就直接开摆，成为机器人，哈哈哈哈。

我仔细想了想，我并没有因为没有减少外出溜达，而变得不快乐，也没有讨厌宅在家里的自己，我觉得这种生活状态是适应当下的我。

但是我觉得我还是要做出一些适当的改变，如果长期不动自己的脑子去做决定的话，我感觉我会丧失掉自己的主动意愿，之后就更不愿意去思考啦，有些事情，想做就做啦~

《杂乱无章》 🖋

在今年有能力的情况下，这次终于可以好好的支持喜欢了很久的《杂乱无章》啦

购买了一些周边，其实不太贵，就正常的衣物、香水、护手霜、鞋等等。

不过我老是给身边朋友安利，感觉自己已经很久很久没有做过这样的事情啦，其实就是非常单纯的想要分享自己所喜欢的宝藏吧。

一直在等正常装的香水，可惜一直没有货	一个人也要穿情侣装

新品护手霜，味道非常好闻的

我关注《杂乱》，没记错应该是在两年前啦，现在回想起来我已经不记得我为什么会关注到它，但是我记得当时看完第一篇文章就点了关注，然后一口气把当时的历史文章全部看了，就是非常喜欢他们输出来的文字。

喜欢文字的朋友，可能也会喜欢上他们吧。

另外今年，他们在广州开展啦，可惜的是，不在江浙沪地区，不可惜的是，我让一个朋友去逛了这个展。

下面是展馆里的个别片段，希望来年能够来到魔都，不行的话，江浙沪地区就好，哈哈哈

文字	图
我们都需要适度抽离，谈恋爱要一直要有这个状态才行，偶尔的距离感，会让人舒适许多。
希望你开心，无论和谁，不管在哪
成年人除了容易胖，还容易加班，容易熬夜，还容易在杂乱无章里找到同感，真的太对啦
给自己的生活留一些属于自己的片段吧
《心情》“过年了！” “又过年了。“

不知道，你有没有在在上述的几幅图中呢？你又是哪种情绪呢？

猫猫相伴的时光 🐱🐱‍👓

养猫，真的是一个极费照片的事情，哈哈哈

我在这之前，很长一段时间都没拍过啥照片啦，后面和室友一起养之后，可以说是，照片以一个非正常量级的速度往上递增，哈哈哈哈

它的存在，我相信是真的能治愈人的，上班一整天，回到家，看到它，那些愁绪会消散一大半。

七月刚回来时,那时候还是娇小可爱勒

现在在室友饲养下，已经是胖嘟嘟啦，变得更可爱。
虽然最后，是让它和室友一起和室友女朋友出去住啦

但最后的效果是好的，它已经成功的胖嘟嘟啦，很开心遇见和陪伴，现在偶尔也能去看一看，也算是非常快乐啦

掘金瞬间

八月Docker技术征文一等奖

不知不觉中在掘金也待了两年多啦，时间真的很快啊，同时也代表着我写网络博客也近两三年啦

用心对待的博客，被掘友们用心认可，真的非常快乐，非常感谢每位阅读过的朋友

让我记录一下这个高光时刻吧~

有在多个平台写过博客，但最让我喜欢的，还是掘金

很多原因吧，有掘金的大方，也有因为掘金而相识的朋友，大家不仅是在掘金上有交流，也是彼此的微信好友，接触的越多，就越习惯这里吧，如果有一天不再玩掘金，那么可能就是这些朋友也在逐步退圈啦吧

图一：Docker技术专题的实体奖牌

也非常感谢斗金小姐姐第一个来告诉我这个好消息，不知道斗金小姐姐能注意到这句话吗，哈哈

要是其他运营小伙伴看到啦，劳请转达一下下啦，还有记得给来个推荐，哈哈哈

图二：在奖金的基础上加了些给自己淘来的4k屏幕

后续也有多个活动想参加的，有可能是懒吧，也有可能是心浮气躁，总之今年的博客数量对比起2022、2021年，差之甚远

2023年统计	2022年统计	2021年统计

真的是每年比折半还折半，明年我一定要努力克服🤡🥺

与友人见面 | 人间有味是清欢

因博文相识的朋友，时隔许久，终于有幸在线下见面啦

开始，可能还是要提起掘金，哈哈哈，那会加上好友，还是因为同时在掘金的“神转折滴评审团”中~

在这之后，其实成为了互相的读者和粉丝，ta的文章内容简短，偏向于日常思考、感悟和读书笔记。

话说ta的日更是我当时早上的摸鱼读物，哈哈哈哈

我个人也偏好去阅读其他人的想法，想了解其他人对于某件事情是如何看待的。

ta的文章也让我在寻找自信以及与自己和解等方面，荣获不少的成长。

去年写到”我们是彼此的正向反馈”，那么今年就是”幸会“。

“杭城，幸会”

人间之幸事，遇良师益友，品人间有味，游山河大地。

在这月准备写年终博文时，在回忆在思考，今年有哪件事是想做而未做的，最后才有啦这次的见面和交流～ 很感谢那晚的思考和感性的自己，才有今天关于杭城的人和事的记忆。 或许这趟出行，是略有唐突的，（因为我的到来，让朋友有不小的心理负担，特意规划了去哪里，从那里走到那里，非常细心），辛苦啦，庆幸的是，最后都收获满满～

“幸会”，有预想过双方的见面，虽然都感受对方都是极易相处的人，但是也不免有一丝不安吧

但真实情况远比起预想中要好，可能是我因为成功的把我那份社牛属性释放出来啦吧。

当文中那个积极向上、热爱生活的形象真实立体出现在眼前时，有那么片刻的不真实吧，同时也非常激动；另外所期待的聊天，也贯穿于整个同行的过程，十分放松和愉快的一天，不用去这想那的。

期待下一次吧~

回忆起整个交流过程中有些问题我还存惑，不过我已经想好要再次拾起阅读啦

人间有味。一方面是尝了那份老杭州的美食味道，另一方面是品鉴了那份属于杭城的老味道。日常总是忙于工作，已经很少有过沉下心来去感受那些明明离我们很近，但又久久未曾感受的地方啦。

山河大地自然是杭州西湖啦。不过那时未曾记起苏轼先生的诗句，一开口便只能是，wc，好美，哈哈哈（已然决定要去b站学习一下关于东坡居士的历史啦），下一次再踏足时，希望自己能欣赏到另一种更深刻的美。

补充：中间也有过许多搞笑瞬间和尴尬的瞬间 比如下面👇的照片，已然是我摆的比较好的姿势了；不熟悉杭州路况，我老是走神开错道；还有最后找停车的地方，下到车库，都没想起自己车停在哪里，还信誓旦旦走错啦，回忆起来，我真的要被自己的信誓旦旦给整麻啦，现在想想都蠢死啦，还不相信你，麻啦；表情管理更不用说了，直接全放开，现在回头看照片，我真的😁😂🙄😵🤡

标题

西湖边上拿着旁边的小朋友的饼干喂鸳鸯，哈哈

在我很喜欢的一个公众号《杂乱无章》的一篇推文中，看到了下面的这段话，我觉得是非常契合这次的见面

如果说见完面之后的想法是什么的话，一方面可能是想要继续去拾起阅读吧，觉得自己言语谈吐仍然有需要进步的地方；另外一方面就是想要改变下自己的仪态吧（在相机中的自己，实在是称的上难看啦，哈哈哈哈）

不管是和哪位好友的见面，我想我们都会永远期待下一次的见面吧

记录生活 | 观影 | 阅读 | 消费

今年总的来说，比起以往，是多了很多记录的，也是想用数字去量化，看看自己的变化。

比如关于看电影、剧，我今年线上线下观影和追剧总的来说是45部吧。有2/3我是写下了观后感的，还有三分之一要么是看完太晚，懒得写，要么纯粹就是懒得写啦。我看的大部分都集中于评分高的经典电影和突然刷到感兴趣的。

关于阅读的话，我今年阅读量降低了很多很多，只有寥寥几本😂

补充：不过这几本书，我个人觉得还是非常值得阅读的。《认知觉醒》有谈及到很多日常行为，阅读这本书的同时，会下意识的反省自己的行为；《娱乐至死》是新闻专业的考研读物，里面谈到的诸多观点，都非常有意思，而且十分深刻，但是有些话不适合写出来，只能自己知道；我还记得我当时读完这本书，就感觉是读书越多的人，并不是多么厉害，而是对这个世界背后的真实规则了解的越多，这本书，让我对宣传、新闻、娱乐了解的更深刻些了，也明白某些新闻背后的意图吧。新闻真真假假，但如今信三分都算多

关于消费。今年的消费直接上了一个量级，把自己也给吓到了。工作真就是给老板和房东挣钱，钱包该是多空还是多空。不过今年还是有几个大额消费的，主要是下面几个：

1、房租费用。一年下来真的心痛的要死；

2、双十一购物。有不少花销，反正花钱如流水的感觉...

3、一台二手台式电脑+一块4K屏幕

4、给家里打钱，给了妹妹一些生活费

5、个人消费也是真的高；

6、软件费用也贵。总的一算，都1k+啦，麻啦

白吃白喝魔都过一年。

补充：详细的消费记录没有写到这里，不然大伙都该知道春春我还差一周，就真是一年穷到头啦。

立下来又总挂掉的Flag

照例回忆下去年年终写下的Flag，可以说是完成的非常糟糕啦

很坦白的说，完成度非常低，低到我自己都不愿意去翻看这个事情。

最主要很多不是无法完成，而是我没有去努力完成，这是我最无法接受的事情。

回头一看2023年，真的十分模糊，不知道自己到底做了些什么，恍惚间就又要到2024年啦。

今年是这种感觉最强烈的一年，因为真的有过迷茫，找不到努力的方向，也浪费了许许多多时间。

我现在还记得我大学室友在今年12月问我的一句话，“二哥，今年我看你文章也没写多少，朋友圈也没咋更新，你今年到底在忙啥啊？”

我也不知道我忙了啥啊

关于明年

下面是我2024年的一些目标和想法，能不能完成，能完成多少，我心里也没底，反正都想冲一冲，试一试吗，先想啦，才能更好的去做，难道不是吗？

总的来说，主要是围绕生活和工作方面，其他的我没有再给自己立明确的需求啦，还有一些则是去年就立过啦，我到目前还没有完成，那些想法今年也会接着去做。

对于明年，我对自己只有一个要求，如果一件事情如果我能做好，那就希望自己能尽力去完成它，而不是因为懒惰而一拖再拖。一定一定一定要有执行力。

那么正在读这篇文章的你呢？今年的你想要做什么呢？你有什么样的想法呢？你会去尽力实现它吗？

在写完之后，我就已经开始着手去开始，有些事情想做就去做吧，没有必要一定要等到某个特殊的时间点之后，时间是在自己手上，而不是在日历上。

长路修远，吾与子之所共适也

每每想到自己已将要岁至二十余四，不免有些恍惚，有些时候，在我自己看来，感觉自己还非常小，完全没长大，很多事情甚至都还没有去考虑过。

但看到身边的朋友，谈恋爱的谈恋爱，买车的买车，结婚的结婚，另外偶尔再加上家里边的催促，焦虑一下就放大了，莫名坐立难安。

但其实大家都一样的，别慌，我先来自黑一下。

我呢，一年工资那么点，给房东一大把，自己吃喝玩乐一大把，购物一大把；约等于白吃白喝在魔都过一年呢~

技术呢，说啥都会点也是，但要说会多少，也就是啥都会一点，问多一句，就直接是啥都不会啦。

该努力就努力，该生活就生活，做好自己该做的事情；那么多的信息流，分辨不了，就少看点；你就是你，想那么多干嘛，想那么多也得烦恼今天晚上吃什么。

无论如何，人生这条道路，仍然漫长而修远，我希望我们能一同享受这短短数十载。

那么这篇文章就写到这里啦。

如果你读到这里，如果你也喜欢的话，请说说你的感受吧，我真的非常想要收到来自于你的反馈，无论如何我都会认真的一一回复的，有问题也可以提出来，我也会一一回答~

2023年，我是宁在春，我在上海。

那2024年，平安喜乐，万事胜意，祝你，祝我，祝我们

现在大部分的中小型公司部署前端代码都是比较简单的，主要步骤如下:

首先，通过脚手架提供的命令npm run build打包前端代码，生成dist文件夹；

最后，将dist文件夹丢给后台开发人员放在他们的工程里面，随后台一起部署；现在普遍是前后端分开部署，因此，利用nginx起一个web服务器，将dist文件夹放到指定的路径下，配置下nginx访问路径，对于请求接口使用proxy_pass进行转发，解决跨域的问题。

更加高端一点的操作，是利用CI/CD + Docker进行自动化部署。

但是，你是否真的想过前端部署真的就这么简单吗？

这其实是一个非常严肃且复杂的问题，因为这关系到线上生产环境的稳定。

有一天，从自知乎上看到一篇张云龙大佬在2014年写的文章，非常有启发，即使这篇文章距离现在有快10年了，但是其中的思想仍然熠熠生辉。

因为写的真的是太好了，为了让更多的人看到，所以大部分内容直接就照搬过来，为了让自己加深印象。如果想看原文，原文网址在这里。

那让我们从原始的前端开发讲起。

下图是一个 index.html 页面和它的样式文件 a.css，无需编译，本地预览，丢到服务器，等待用户访问。

哇，前端这么简单，门槛好低啊。这也是前端有太多人涌入进来的原因。

接着，我们访问页面，看到效果，再查看一下网络请求，200！不错，太完美了！

那么，研发完成。。。。了么？

等等，这还没完呢！

对于像 BAT 这种公司来说，那些变态的访问量和性能指标，将会让前端一点也不好玩。

看看那个 a.css 的请求，如果每次用户访问页面都要加载，是不是很影响性能，很浪费带宽啊，我们希望最好这样：

利用304，让浏览器使用本地缓存。

但，这样也就够了吗？

不够！

304叫协商缓存，这玩意还是要和服务器通信一次，我们的优化级别是变态级，所以必须彻底灭掉这个请求，要变成这样：

强制浏览器使用本地缓存(cache-control/expires)，不要和服务器通信。

好了，请求方面的优化已经达到变态级别，那问题来了：你都不让浏览器发资源请求了，这缓存咋更新？

很好，相信有人想到了办法：通过更新页面中引用的资源路径，让浏览器主动放弃缓存，加载新资源。

像这样：

下次上线，把链接地址改成新的版本，这就更新资源了。

问题解决了么？当然没有，思考这种情况：

页面引用了3个 css 文件，而某次上线只改了其中的a.css，如果所有链接都更新版本，就会导致b.css，c.css的缓存也失效，那岂不是又有浪费了？

不难发现，要解决这种问题，必须让url的修改与文件内容关联，也就是说，只有文件内容变化，才会导致相应url的变更，从而实现文件级别的精确缓存控制。

什么东西与文件内容相关呢？

我们会很自然的联想到利用数据摘要要算法对文件求摘要信息，摘要信息与文件内容一一对应，就有了一种可以精确到单个文件粒度的缓存控制依据了。

OK，那我们把 url 改成带摘要信息的：

这回再有文件修改，就只更新那个文件对应的 url 了，想到这里貌似很完美了。你觉得这就够了么？

图样图森破！

现代互联网企业，为了进一步提升网站性能，会把静态资源和动态网页分集群部署，静态资源会被部署到CDN节点上，网页中引用的资源也会变成对应的部署路径：

好了，当我要更新静态资源的时候，同时也会更新 html 中的引用吧，就好像这样：

这次发布，同时改了页面结构和样式，也更新了静态资源对应的url地址。现在重点来了，现在要发布代码上线，亲爱的前端研发同学，你来告诉我，咱们是先上线页面，还是先上线静态资源？

这里的静态资源不仅仅包括css文件，也包括图片，以及不怎么经常变的资源。

好的，上面一坨分析想说的就是：先部署谁都不成！都会导致部署过程中发生页面错乱的问题。

所以，访问量不大的项目，可以让研发同学苦逼一把，等到半夜偷偷上线，先上静态资源，再部署页面，看起来问题少一些。这也是很多公司的部署方案。

但是，大公司超变态，没有这样的绝对低峰期，只有相对低峰期。

所以，为了稳定的服务，还得继续追求极致啊！

这个奇葩问题，起源于资源的 覆盖式发布，用待发布资源覆盖已发布资源，就有这种问题。

解决它也好办，就是实现 非覆盖式发布。

看上图，用文件的摘要信息来对资源文件进行重命名，把摘要信息放到资源文件发布路径中，这样，内容有修改的资源就变成了一个新的文件发布到线上，不会覆盖已有的资源文件。上线过程中，先全量部署静态资源，再灰度部署页面，整个问题就比较完美的解决了。

因为很多前端开发同学不怎么接触部署，对灰度部署不太熟悉，下面将介绍下什么是灰度部署。

软件开发一般都是一个版本一个版本的迭代。新版本上线前都会经过测试，但就算这样，也不能保证上线了不出问题。

所以，在公司里上线新版本代码一般都是通过灰度系统。灰度系统可以把流量划分成多份，一份走新版本代码，一份走老版本代码。

而且灰度系统支持设置流量的比例，比如可以把走新版本代码的流程设置为 5%，没啥问题了再放到 10%，50%，最后放到 100% 全量。这样可以把出现问题的影响降到最低。

不然一上来就全量，万一出了线上问题，那就是大事故。

另外，灰度系统不止这一个用途，比如，产品不确定某些改动是不是有效的，就要做 AB 实验，也就是要把流量分成两份，一份走 A 版本代码，一份走 B 版本代码。

那这样的灰度系统是怎么实现的呢？其实很多都是用 nginx 实现的。

nginx 是一个反向代理的服务，用户请求发给它，由它转发给具体的应用服务器。

它的过程如下图所示：

首先，需要对流量进行染色，即对这个用户进行标注，让这个用户访问服务1，另外的用户访问服务2。染色的方式有很多，可以通过cookie来完成。不同的用户携带的cookie是不同的。第一染色的时候，所有的用户都访问服务1。

然后，第二次访问的时候，nginx根据用户携带的cookie进行转发到不同的服务，这样就完成了灰度访问。

好了，灰度部署就介绍到这里，回到原文讲的先全量部署静态资源，再灰度部署页面，这是什么意思呢？

首先，部署静态资源的时候，不要删除原来的静态资源，而是把新的静态资源发复制过去，因为文件名用摘要算法重命名的，所以不会发生重名的问题。

其次，灰度部署动态页面，也就是一部分用户访问老的页面，一部分用户访问新的页面。访问老页面的用户请求的还是老资源，直接使用缓存。访问新页面的用户访问新资源，此时新资源已经部署完成，所以不会访问老的资源，导致页面出现错误。

最后，根据访问情况，利用灰度系统，逐渐把访问老页面的用户过渡到访问新页面上。

所以，大公司的静态资源优化方案，基本上要实现这么几个东西：

全套做下来，就是相对比较完整的静态资源缓存控制方案了，而且，还要注意的是，静态资源的缓存控制要求在前端所有静态资源加载的位置都要做这样的处理。

是的，所有！

什么js、css自不必说，还要包括js、css文件中引用的资源路径，由于涉及到摘要信息，引用资源的摘要信息也会引起引用文件本身的内容改变，从而形成级联的摘要变化，大概就是：

到这里本文结束了，我们已经了解了前端部署中关于静态资源缓存要面临的优化和部署问题，新的问题又来了：这™让工程师怎么写码啊！！！

这又会扯出一堆有关模块化开发、资源加载、请求合并、前端框架等等的工程问题。

妈妈，我再也不玩前端了。。。。

App跨平台框架历史悠久，从cordova、react native、flutter，直到最近的uni-app x。江山代有才人出，每个都试图颠覆原生，但过去却一直未成功。

过去的问题到底在哪里？

我们先捋一捋各种技术路线，分析这些跨平台开发框架和原生应用的差别具体在哪里。

上面的表格，除了行尾的原生应用外，各个跨平台框架按出现时间排序，可以看到跨平台框架是如何演进的。

上表中，uni-app x和原生应用是一样的，逻辑层和渲染层都是原生，都是强类型；而其他跨平台框架或者在逻辑层、或者在渲染层与原生不一致。

webview不行已经是业内常识了，启动慢、渲染慢、内存占用高。这块本文不再详述。

但那些非web-view的框架到底哪里不如原生？

1. js逻辑+ 原生渲染

react native、weex等抛弃webview，改由原生渲染的跨平台方案，2014年就推出了。
如今手机硬件也越来越好了，为什么性能还达不到原生？

js+原生渲染的方案主要有2点缺陷：

• JS引擎自身的性能问题


• JS和原生之间的通信延迟

1.1 js引擎慢，启动速度和运行速度都弱于原生

所以很多开发者即便使用这类方案，首页也还是原生来写。

React Native的Hermes引擎和华为的arkUI，提供了js编译为字节码的方案，这是一种空间换时间的方案，启动速度有了一定优化，但仍然比不过原生。

弱类型在编译期可优化的幅度有限，还是需要一个运行时来跑，无法像强类型那样直接深入底层。

以数字运算为例，js的number运算确实比强类型的int慢，内存开销也更大。

1.2 js语言与原生之间通信卡顿

每个语言有自己的内存空间，跨语言通信都有折损，每次通信几十到几百毫秒不等，视手机当时的状态。一旦频繁通信，就会明显卡顿。

逻辑层的js，即要和原生渲染层通信，还要和原生API通信：

1.2.1 js与原生ui通信

举个简单的场景例子，在js里监听滚动，根据滚动变化实时调整界面上某些元素的高度变化。这个问题能难倒一大批跨平台开发框架。

如果全部在webview里，js操作ui还好一些，所以uni-app的app-vue里的renderjs操作UI性能高，就是这个道理。同理还有微信小程序的wsx。

虽然小程序和uni-app都是js，但实际上逻辑层在独立js引擎里，通过原生桥来控制web-view，通信成本很高。

weex提供了bindingx技术，这是一种弱编程，渲染层预先定义了一些操作UI的方式，调用时全部在渲染层运行，不会来回与逻辑层通信。但这种预定义方式的适应面有限，无法做到在js里高性能、自由的操作所有UI。

1.2.2 js操作原生api

操作系统和三方SDK的API都是原生的，js调用这些能力也需要跨语言通信。比如js调用原生的Storage或IO，数据较多时遍历的性能非常差。

当然在js API的封装上可以做些优化，比如微信的storage提供了wx.batchGetStorageSync这种批量读取的API，既然遍历性能差，那干脆一次性从原生读出来再传给js。

这也只能是无奈的方案，如果在遍历时想用js做什么判断就实现不了了，而且一次性读出很大的数据后传给js这一下，也需要通信时间。

2. flutter方案

flutter在2018年发布，第一次统一了逻辑层和渲染层，而且使用了强类型。

它没有使用原生渲染，而是使用由dart驱动的渲染引擎，这样逻辑层的dart代码操作UI时，再也没有延时了！bindingx、wxs这种补丁方案再也不需要了。

并且dart作为强类型，编译优化很好做，启动速度和运行速度都胜过js。

在这个开源项目下gitcode.net/dcloud/test…，提供了一个flutter编写的100个slider同时滑动的示例， 项目下有源码也有打包好apk，可以直接安装体验。

100个slider同时滑动，非常考验逻辑和UI的通信。如果在webview内部，html和js写100个这样的slider，在新的手机上表现也还ok。但在小程序和react native这种逻辑和UI分离的模式下，100个slider是灾难。

下载安装apk后可以看到dart操作flutter的UI真的没有通信折损，100个slider的拖动非常流畅。

flutter看起来很完美。但为什么也没有成为主流呢？很多大厂兴奋的引入后为何又不再扩大使用范围呢？

2.1 dart与原生API的通信

别忘了上面1.2.2提到的原生API通信。flutter虽然在逻辑层和渲染层都是dart，但要调用原生API时，还是要通信。

操作系统和三方SDK的API是原生的，让dart调用需要做一层封装，又落到了跨语言通信的坑里。

gitcode.net/dcloud/test…这是一个开源测试项目，来测试原生的claas数据与dart的通信耗时。

项目里面有源码，大家可自行编译；根目录有打包好的apk，也可以直接安装体验。

这个项目首先在kotlin中构建了包含不同数据量的class，传递到dart然后渲染在界面上，并且再写回到原生层。

有0.1k和1k两种数据量（点击界面上的1k数字可切换），有读和读并写2个按钮，各自循环1000次。

以下截图的测试环境是华为mate 30 5G，麒麟990。手机上所有进程杀掉。如下图：

• 1k数据从原生读到dart并渲染

• 1k数据从原生读到dart并渲染再写回

• 0.1k数据从原生读到dart并渲染

• 0.1k数据从原生读到dart并渲染再写回

通信损耗非常明显。并且数据量从1k降低到0.1k时，通信时间并没有减少10倍，这是因为通信耗时有一个基础线，数据再小也降不下去。

为什么会这样？因为dart和kotlin不是一种编程语言，不能直接调用kotlin的class，只能先序列化成字符串，把字符串数据从原生传到dart，然后在dart层再重新构造。

当然也可以在原生层为dart封装API时提供wx.batchGetStorageSync这类批处理API，把数据一次读好再给dart，但这种又会遇到灵活性问题。

而在uni-app x中，这种跨语言通信是不存在的，不需要序列化，因为uni-app x使用的编程语言uts，在android上就编译为了kotlin，它可以直接调用kotlin的class而无需通信和封装。示例如下，具体uni-app x的原理后续章节会专题介绍。

<template>

template>

<script lang="uts">

import Build from 'android.os.Build';

export default {

	onLoad() {

		console.log(Build.MODEL); //uts可以直接导入并使用原生对象，不需要封装，没有跨语言通信折损

	}

}

script>

再分享一个知识：

很多人都知道iPhone上跨平台框架的应用，表现比android好。但大多数人只知道是因为iPhone的硬件好。

其实还有一个重要原因，iOS的jscore是c写的，OS的API及渲染层也都是ObjectC，js调用原生时，某些类型可以做共享内存的优化。但复杂对象也还是无法直接丢一个指针过去共享使用内存。

而android，不管java还是kotlin，他们和v8、dart通信仍然需要跨语言通信。

2.2 flutter渲染和原生渲染的并存问题

flutter的自渲染引擎，在技术上是不错的。但在生态兼容上有问题。

很多三方软件和SDK是原生的，原生渲染和flutter自渲染并存时，问题很多。

flutter开发者都知道的一个常见坑是输入法，因为输入法是典型的原生UI，它和flutter自绘UI并存时各种兼容问题，输入框被遮挡、窗体resize适应，输入法有很多种，很难适配。

混合渲染，还有信息流广告、map、图表、动画等很多三方sdk涉及。这个时候内存占用高、渲染帧率下降、不同渲染方式字体不一致、暗黑主题不一致、国际化、无障碍、UI自动化测试，各种不一致。。。

这里没有提供开源示例，因为flutter官方是承认这个问题的，它提供了2种方式：混合集成模式和虚拟显示模式模式。

但在渲染速度、内存占用、版本兼容、键盘交互上都各自有各自的问题。详见flutter官网：docs.flutter.dev/platform-in…。这个是中文翻译：flutter.cn/docs/platfo…

在各大App中，微信的小程序首页是为数不多的使用flutter UI的界面，已经上线1年以上。

下面是微信8.0.44（此刻最新版），从微信的发现页面进入小程序首页。

视频中手机切换暗黑主题后，这个UI却还是白的，而且flutter的父容器原生view已经变黑了，它又在黑底上绘制了一个白色界面，体验非常差。

这个小程序首页界面很简单，没有输入框，规避了混合渲染，点击搜索图标后又跳转到了黑色的原生渲染的界面里。

假使这个界面再内嵌一个原生的信息流SDK，那会看到白色UI中的信息流广告是黑底的，更无法接受。

当然这不是说flutter没法做暗黑主题，重启微信后这个界面会变黑。这里只是说明渲染引擎不一致带来的各种问题。

注：如何识别一个界面是不是用flutter开发的？在手机设置的开发者选项里，有一个GPU呈现模式分析，flutter的UI不触发这个分析。且无法审查布局边界。

flutter的混合渲染的问题，在所有使用原生渲染的跨平台开发框架中都不存在，比如react native、weex、uni-app x。

总结下flutter：逻辑层和UI层交互没有通信折损，但逻辑层dart和原生api有通信成本，自绘UI和原生ui的混合渲染问题很多。

3. js+flutter渲染

flutter除了上述提到的原生通信和混合渲染，还有3个问题：dart生态、热更新、以及比较难用的嵌套写法。

一些厂商把flutter的dart引擎换成了js引擎，来解决上述3个问题。比如微信skyline、webF、ArkUI-x。

其实这是让人困惑的行为。因为这又回到了react native和weex的老路了，只是把原生渲染换成了flutter渲染。

flutter最大的优势是dart操作UI不需要通信，以及强类型，而改成js，操作UI再次需要通信，又需要js运行时引擎。

为了解决js和flutter渲染层的通信问题，微信的skyline又推出了补丁技术worklet动画，让这部分代码运行在UI层。（当然微信的通信，除了跨语言，还有跨进程通信，会更明显）

这个项目gitcode.net/dcloud/test…， 使用ArkUI-x做了100个slider，大家可以看源码，下载apk体验，明显能看到由于逻辑层和UI层通信导致的卡顿。

上述视频中，注意看手指按下的那1个slider，和其他99个通过数据通讯指挥跟随一起行动的slider，无法同步，并且界面掉帧。

不过自渲染由于无法通过Android的开发者工具查看GPU呈现模式，所以无法从条状图直观反映出掉帧。

注意ArkUI-x不支持Android8.0以下的手机，不要找太老的手机测试。

很多人以为自渲染是王道，但其实自渲染是坑。因为flutter的UI还会带来混合渲染问题。

也就是说，js+flutter渲染，和js+原生渲染，这2个方案相比，都是js弱类型、都有逻辑层和渲染层的通信问题、都有原生API通信问题，而js+flutter还多了一个混合渲染问题。

可能有的同学会说，原生渲染很难在iOS、Android双端一致，自渲染没有这个问题。

但其实完全可以双端一致，如果你使用某个原生渲染框架遇到不一致问题，那只是这个框架厂商做的不好而已。

是的，很遗憾react native在跨端组件方面投入不足，官方连slider组件都没有，导致本次评测中未提供react native下slider-100的示例和视频。

4. uni-app x

2022年，uts语言发布。2023年，uni-app x发布。

uts语言是基于typescript修改而来的强类型语言，编译到不同平台时有不同的输出：

• 编译到web，输出js


• 编译到Android，输出kotlin


• 编译到iOS，输出swift

而uni-app x，是基于uts语言重新开发了一遍uni-app的组件、API以及vue框架。

如下这段示例，前端的同学都很熟悉，但它在编译为Android App时，变成了一个纯的kotlin app，里面没有js引擎、没有flutter、没有webview，从逻辑层到UI层都是原生的。

<template>

	<view class="content">

		<button @click="buttonClick">{{title}}button>

	view>

template>



<script> //这里只能写uts

	export default {

		data() {

			return {

				title: "Hello world"

			}

		},

		onLoad() {

			console.log('onLoad')

		},

		methods: {

			buttonClick: function () {

				uni.showModal({

					"showCancel": false,

					"content": "点了按钮"

				})

			}

		}

	}

script>



<style>

	.content {

		width: 750rpx;

		background-color: white;

	}

style>

这听起来有点天方夜谭，很多人不信。DCloud不得不反复告诉大家，可以使用如下方式验证：

• 在编译uni-app x项目时，在项目的unpackage目录下看看编译后生成的kt文件


• 解压打包后的apk，看看里面有没有js引擎或flutter引擎


• 手机端审查布局边界，看看渲染是不是原生的（flutter和webview都无法审查布局边界）

但是开发者也不要误解之前的uni-app代码可以无缝迁移。

• 之前的js要改成uts。uts是强类型语言，上面的示例恰好类型都可以自动推导，不能推导的时候，需要用:和as声明和转换类型。


• uni-app x支持css，但是css的子集，不影响开发者排版出所需的界面，但并非web的css全都兼容。

了解了uni-app x的基本原理，我们来看下uni-app x下的100个slider效果怎么样。

项目gitcode.net/dcloud/test…下有源码工程和编译好的apk。

如下视频，打开了GPU呈现模式，可以看到没有一条竖线突破那条红色的掉帧安全横线，也就是没有一帧掉帧。

uni-app x在app端，不管逻辑层、渲染层，都是kotlin，没有通信问题、没有混合渲染问题。不是达到了原生的性能，而是它本身就是原生应用，它和原生应用的性能没差别。

这也是其他跨平台开发框架做不到的。

uni-app x是一次大胆的技术突破，分享下DCloud选择这条技术路线的思路：

DCloud做了很多年跨平台开发，uni-app在web和小程序平台取得了很大的成功，不管规模大小的开发者都在使用；但在app平台，大开发者只使用uni小程序sdk，中小开发者的app会整体使用。

究其原因，uni-app在web和小程序上，没有性能问题，直接编译为了js或wxml，uni-app只是换了一种跨平台的写法，不存在用uni-app开发比原生js或原生wxml性能差的说法。

但过去基于小程序架构的app端，性能确实不及原生开发。

那么App平台，为什么不能像web和小程序那样，直接编译为App平台的原生语言呢？

uni-app x，目标不是改进跨平台框架的性能，而是给原生应用提供一个跨平台的写法。

这个思路的转换使得uni-app x超越了其他跨平台开发框架。

在web端编译为js，在小程序端编译为wxml等，在app端编译为kotlin。每个平台都只是帮开发者换种一致的写法而已，运行的代码都是该平台原生的代码。

然而在2年前，这条路线有2个巨大的风险：

没有人确定这个产品可以做出来，DCloud内部争议也很多。

还好，经历了无数的困难和挑战，这个产品终于面世了。

换个写法写原生应用，还带来另一个好处。

同样业务功能的app，使用vue的写法，比手写纯原生快多了。也就是uni-app x对开发效率的提升不只是因为跨平台，单平台它的开发效率也更高。

其实google自己也知道原生开发写法太复杂，关于换种更高效的写法来写原生应用，他们的做法是推出了compose UI。

不过遗憾的是这个方案引入了性能问题。我们专门测试使用compose UI做100个slider滑动的例子，流畅度也掉帧。

源码见：gitcode.net/dcloud/test…， 项目下有打包后的apk可以直接安装体验。

打开GPU呈现模式，可以看到compose ui的100个slider拖动时，大多数竖线都突破那条红色的掉帧安全横线，也就是掉帧严重。

既然已经把不同开发框架的slider-100应用打包出来了，我们顺便也比较了不同框架下的包体积大小、内存占用：

包体积数据说明：

• 包含3个CPU架构：arm64、arm32、x86_64。


• flutter的代码都是编译为so文件，支持的cpu类型和包体积是等比关系，1个cpu最小需要6M体积，业务代码越多，cpu翻倍起来越多。


• ArtUI-x的业务代码虽然写在js里，但除了引用了flutter外还引用了js引擎，这些so库体积都不小且按cpu分类型翻倍。


• uni-app x里主业务都在kotlin里，kotlin和Android x的兼容库占据了不少体积。局部如图片引用了so库，1个cpu最小需要7M体积。但由于so库小，增加了2个cpu类型只增加了不到1M。


• compose ui没有使用so库，体积裁剪也更彻底。


• uni-app x的常用模块并没有裁剪出去，比如slider100的例子其实没有用到图片，但图片使用的fesco的so库还是被打进去了。实际业务中不可能不用图片，所以实际业务中uni-app x并不会比compose ui体积大多少。

内存占用数据说明：

• 在页面中操作slider数次后停止，获取应用内存使用信息VmRSS: 进程当前占用物理内存的大小


• 表格中的内存数据是运行5次获取的值取平均值


• 自渲染会占据更多内存，如果还涉及混合渲染那内存占用更高

5. 后记

跨语言通信、弱类型、混合渲染、包体积、内存占用，这些都是过去跨平台框架不如原生的地方。

这些问题在uni-app x都不存在，它只是换了一种写法的原生应用。

当然，作为一个客观的分析，这里需要强调uni-app x刚刚面世，还有很多不成熟的地方。比如前文diss微信的暗黑模式，其实截止到目前uni-app x还不支持暗黑模式。甚至iOS版现在只能开发uts插件，还不能做完整iOS应用。

需求墙里都是uni-app x该做还未做的。也欢迎大家投票。

另外，原生Android中一个界面不能有太多元素，否则性能会拉胯。flutter的自渲染和compose ui解决了这个问题。而原生中解决这个问题需要引入自绘机制来降低元素数量，这个在uni-app x里对应的是draw自绘API。

uni-app x这个技术路线是产业真正需要的东西，随着产品的迭代完善，它能真正帮助开发者即提升开发效率又不牺牲性能。

让跨平台开发不如原生，成为历史。

欢迎体验uni-app x的示例应用，感受它的启动速度，渲染流畅度。

源码在：gitcode.net/dcloud/hell…； 

这个示例里有几个例子非常考验通信性能，除了也内置了slider-100外，另一个是“模版-scroll-view自定义滚动吸顶”，在滚动时实时修改元素top值始终为一个固定值，一点都不抖动。

我们不游说您使用任何开发技术，但您应该知道它们的原理和差别。

欢迎指正和讨论。

效果

实现

找到喜欢的图标

http://www.iconfont.cn/

打开 iconfont，随便搜个点赞，仅需一个点赞即可，节省内存，另一个用CSS完成

下载解压

取出如下文件，在项目入口导入 iconfont.css，或者统一放入一个文件导入也行

编写组件

一个点赞，就叫Like

一个点踩，就叫Hate吧

Hate点踩组件

先写属性，就几个，不用注释也明白

分别是

• 绑定值 modelValue


• 默认颜色 defaultColor


• 激活颜色 activeColor


• 大小 size

HTML给个容器，再加个固定格式(xxx-container)的容器类名，防止样式穿透

再把iconfont样式加上，图标就出来了

这些用VSCode自定义代码片段都能自动生成

现在是这样的图标，也就是点赞

那么怎样让它变成点踩手势呢？答案是rotate旋转

加上下图类名有用吗？ 答案是没用，他并不会旋转

为什么呢？因为i标签是行盒模型，必须变成块盒才行

方式有很多，不过我就爱flex，优点很多，这里就不赘述了

这不就转起来了吗

动效

加个鼠标移入变色效果，考虑到一会还有另一个点赞组件，那就写个通用的sass吧

接收一个激活颜色和默认颜色参数

导入并使用，下面用了个v-bind绑定当前被点击的颜色，下面来实现逻辑

上面接收了一个modelValue，类型是布尔值，当他为真时就把颜色改为激活颜色

于是就理所当然的使用计算属性

事件

当被点击或hover时，就激活图标颜色，现在还差点击

点击事件要做 3 件事

这里用一个showAnimation变量控制动画展示

再改变父组件的值，父组件的值一变，自己的颜色也会跟着变

还差个动画，只要让动画在其中一段不停反复横跳，即可实现国际友好手势

但这样有问题，只有第一次触发动画才有动效，后续需要改变showAnimation的值

那么怎么知道动画什么时候结束呢？

答案是事件onanimationend，只要在这个事件把动画关掉，点击时开启即可

ok，实现最主要的组件了，另一个点赞就是复制改东改西，大家都会

组合组件

接下来需要把点赞和点踩组合一起，那就叫Gr0up吧

需要实现逻辑

类型

传递一个固定类型的值，才能分辨是什么操作

null就是初始状态，无操作，另外俩见名知义

那么现在需要编写自身的状态

• wasChoose是否有按钮被选中


• disabled当被选中，同时父组件完成(done)，就禁用

样式

初始化

建议写代码都提供一个入口，后面有空出一期如何像写诗一般写代码

事件

当被点击时，改变两个状态，没什么好说的，完成

测试

源码: gitee.com/cjl2385/dig…

我媳妇是一个不爱读书的人。她有时候会反问我为什么读书？

最初我回答读书可以增长见识，陶冶情操。再后来我回答读书可以提升认知，获得更好的解决方案，而且腹有诗书气自华。

然而随着时间推移，我总觉得上面的回答差点意思。具体差什么呢？差的是和自己的真实链接，简单来说就是对自己的具体的实践层的意义。

回顾一下我的读书历程。

我是7岁上的小学一年级，后来按部就班的读初中高中，高中复读了，之后读大学读研。现在的感受高中以前的书都已经回忆不起来了。高中的书也只剩下零星点点，而且中学阶段主要都是教科书。

我读书的主要阶段还是大学之后。从这点来说，和现在的孩子相比，我读书读课外书的年纪真是太晚了。大学主要读的是文学性的书籍和所谓当时的显学经济学方面的。

我能想起来的文学性的书有法国司汤达的《红与黑》，罗曼罗兰的《约翰克利斯朵夫》、《简爱》。经济学方面的有曼昆《微观经济学》和《经济学原理》宏观经济分册，犹记得宏观经济分册一页一页的读完的。后来陆续也读了张五常的《经济解释》……其它肯定还有但是一时半会想不起来了。

网络小说也读了不少，反倒是网络小说记得很清晰。萧鼎的《诛仙》，土豆的《斗破苍穹》，纷舞妖姬的《弹痕》和《诡刺》，缘分0的《无尽武装》、《全能炼金师》、《天风》、《天纵商才》，还有三戒大师的历史类权谋小说《官居一品》《大官人》等；还有其他一些的历史类和玄幻类小说，想起来的《凡人修仙传》、《鬼吹灯》和《盗墓笔记》。

如果要推荐的话，喜欢军文的话，强烈推荐《弹痕》，还有《天风》；前者是现代军文，后者是古代军文。喜欢历史权谋的推荐《官居一品》。喜欢玄幻的推《凡人修仙传》、《鬼吹灯》和《盗墓笔记》。

为啥网络小说记得比正统文学清楚？一方面网络小说是兴趣；另一方面，最近这些年上面的一些小说拍成了动画片，让自己有机会回顾颓废的那些年，那些年熬夜看的小说。

言归正传。正统的文学名著，当时我特意将文中给我启迪的句子摘抄下来，但如今那些句子绝大部分已经是不知踪迹。能想起来的：这是最好的时代，这是最坏的时代……这出自名著《双城记》，但这本书我并没有读，还有那句：世界上有一种英雄主义，就是看清生活的真相以后依然热爱生活，出自罗曼罗兰的《名人传》，但这本书我也没读。

对于经济学，记住的：产权的界定的是市场经济的基本前提，这就是大名鼎鼎的科斯定理。

网络小说类脑袋里面只有小说情节，没有名句。

从上面来看，为什么读书？那些年读的书没有获得解决方案，也没有能大面积地提高认知。

我现在反思读书要有更加具体的目的性，要与个人的认知体系链接，与实践链接。提升特定认知，改善特定实践。

读书是一种主动的迭代认知体系的方式，但相比写文章，相比阐述，读书是一种相对被动的方式，因为读书往往不知道会读到什么具体而微的内容，也不知道这些具体而微的内容会与认知体系发生怎样的具体链接。

也因为这种被动性，相比较写文章，相比阐述，读书拥有更多可能性，这也正是一直说的开卷有益。

综上，读书是为了主动迭代认知体系，以一种相对开放的方式。

(本文完)

1. 背景

在我们的业务场景中，用户在完成下单后大部分的概率不再需要进入App做其他的操作，只需要知道当前的订单状态，为了方便用户在不解锁的情况下也能实时查看当前订单的状态，货拉拉用户 iOS端上线了灵动岛功能，用户的接受度较高，由于Android暂不支持灵动岛，所以我们自定义了一个锁屏页面。

2. 实践

  2.1 方案选择

  实现锁屏的方式有多种（锁屏应用、悬浮窗、普通Activity伪造锁屏等等），由于我们的业务场景简单只展示我们的订单状态，且不需要很强的保活干扰用户的操作，采用了普通的Activity伪造锁屏。

  2.2 方案原理

  锁屏的大概实现原理都很简单，监听系统的亮屏广播，在亮屏的时候展示自己的锁屏界面，自定义的锁屏界面会覆盖在系统的锁屏界面上，用户在自定义锁屏界面上进行一系列的动作后进入系统的解锁界面。

  2.3 代码实现

    2.3.1 锁屏页面

    锁屏页Activity在普通的Activity需要加上一些配置

      1. 在onCreate中设置添加Flags,让当前Activity可以在锁屏时显示

• FLAG_SHOW_WHEN_LOCKED：使Activity在锁屏时仍然能够显示


• FLAG_DISMISS_KEYGUARD：去掉系统锁屏页，设置了系统锁屏密码是没有办法去掉的，现在手机一般都会设置锁屏密码，该配置可基本忽略。

    this.window.addFlags(

        WindowManager.LayoutParams.FLAG_DISMISS_KEYGUARD or

                WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED

    )

      2. 在AndroidManifest.xml中进行对锁屏页Activity进行配置

• 主题配置，

      主要是配置锁屏Activity的背景为透明和去除过度动画,让锁屏Activity过渡到系统锁屏更自然

• 启动模式配置
  
  
  
  
  • 在BroadcastReceiver中启动锁屏页Activity，需要添加Intent.FLAG_ACTIVITY_NEW_TASK的flag，造成锁屏Activity单独创建一个history stack，会在最近任务中显示出来，通过配置excludeFromRecents，noHistory，taskAffinity来规避这个问题。
  
  
  
  

    name=".lockscreen.LockScreenActivity"
  
        android:configChanges="uiMode"
  
        android:excludeFromRecents="true"
  
        android:exported="false"
  
        android:launchMode="singleInstance"
  
        android:noHistory="true"
  
        android:screenOrientation="portrait"
  
        android:taskAffinity="com.xxx.lockscreen"
  
        android:theme="@style/LockScreenTheme">
  
  
  
    
  
    ```
  
  

  
  

      3. Home键，Back键和Menu键事件的处理

• Home键，由于不是用来替代系统锁屏的锁屏软件，不需要处理Home键事件.


• Back/Menu键，重写onKeyDown让锁屏页不处理这两个事件
  
  

    override fun onKeyDown(keyCode: Int, event: KeyEvent?): Boolean {
  
        return when (event?.keyCode) {
  
            KeyEvent.KEYCODE_BACK -> true
  
  
  
            KeyEvent.KEYCODE_MENU -> true
  
  
  
            else -> super.onKeyDown(keyCode, event)
  
        }
  
    }
  
    ```
  
  

  
  

    2.3.2 广播

    LockScreenBroadcastReceiver是普通的BroadcastReceiver，不做其他的配置，需要注意两点：

class LockScreenBroadcastReceiver : BroadcastReceiver() {



    override fun onReceive(context: Context?, intent: Intent?) {

        intent?.let { handleCommandIntent(context, it) }

    }



    private fun handleCommandIntent(context: Context?, intent: Intent) {

        when (intent.action) {

            Intent.ACTION_SCREEN_OFF -> {

                 val lockScreen = Intent(this, LockScreenActivity::class.java)

                 lockScreen.setPackage("com.xxx.xxx")

                 lockScreen.addFlags( Intent.FLAG_ACTIVITY_NEW_TASK )

                 context?.startActivity(lockScreen)

            }

            Intent.ACTION_USER_PRESENT -> {

                 // 处理解锁后才显示自定义锁屏Activity

            }

        }

    }

}

    2.3.3 实现效果

3. 注意点

以下是在实践过程中的一些问题小结，供大家参考。

  3.1 权限相关

  不同手机系统上权限的名称，大体分为5种：

• 后台弹窗


• 悬浮窗


• 显示在其他应用的上层


• 锁屏展示


• 后台弹出界面

    以及不同的组合效果也不同，以下是已测试过的手机，

品牌	型号	系统	系统版本	相关权限	权限截图	权限截图
华为	P50	HarmonyOS	HarmonyOS 4.0.0	1. 悬浮窗 2.后台弹窗
oppo	OPPO K9 5G	ColorOS 13	Android 13	1. 悬浮窗 2. 锁屏显示
vivo	Y52s	Funtouch OS 10.5	Android 10	1. 悬浮窗 2. 锁屏显示 3. 后台弹出界面
一加	OnePlus Ace Pro	ColorOS 13	Android 13	1. 悬浮窗 2. 锁屏显示
荣耀	honor 60	magic ui 6.1	Android 12	1. 显示在其他应用的上层
iQOO	Neo3	Origin OS	Android 12	1. 悬浮窗 2. 锁屏显示 3. 后台弹出界面
Hi nova	Hi nova 9	Emui 12	Android 12	1. 后台弹窗 2. 悬浮窗 3. 显示在其他应用的上层

  OPPO/一加 手机特殊说明：在默认状态下在系统设置下找不到“锁屏显示”的入口，需要先授权“悬浮窗”权限再次启动应用会在应用启动时弹窗提示授权在锁屏上显示，然后在系统设置中会出现“锁屏显示”的入口。

  3.2 有些手机在未授权时，应用在前台时锁屏可以展示，但是应用退到后台不展示。

  Android 10 (API 级别 29) 及更高版本对后台应用可启动Activity的时间施加限制。这些限制有助于最大限度地减少对用户造成的中断，并且可以让用户更好地控制其屏幕上显示的内容。具体见官方文档

  3.3 在部分手机上，点亮屏幕后不会立即展示自定义的锁屏界面，在解锁系统锁屏后才会展示自定义的锁屏。1. 监听解锁事件主动finish自定义的锁屏页面

    Intent.ACTION_USER_PRESENT->{

        ActivityUtils.getActivityList()?.forEach {

            if ("com.xxx.lockscreen.LockScreenActivity" == it.componentName.className) {

                it.finish()

            }

        }

    }

2. 在自定义锁屏Activity的onResume中监听设备是否已解锁并finish锁屏页

override fun onResume() {

    super.onResume()

    val isInteractive = (getSystemService(Context.POWER_SERVICE) as PowerManager).isInteractive

    val isKeyguardLocked = (getSystemService(KEYGUARD_SERVICE) as KeyguardManager).isKeyguardLocked

    if (isInteractive && !isKeyguardLocked) {

        finish()

    }

}

3.4 当在自定义锁屏页触发Home键事件后，锁屏页Activity不再显示

提示用户根据自己的系统去授予对应的权限，不同系统所需的权限参考上面第1点

3.5 Android 8.0 透明主题造成闪退

  在Android 8.0系统上Activity满足了以下条件：

会出现java.lang.IllegalStateException: Only fullscreen activities can request orientation

    // ActivityRecord.java

    void setRequestedOrientation(int requestedOrientation) {

        if (ActivityInfo.isFixedOrientation(requestedOrientation) && !fullscreen

                && appInfo.targetSdkVersion > O) {

            throw new IllegalStateException("Only fullscreen activities can request orientation");

        }

        ....

    }

  建议针对Android 8.0以外的系统才固定屏幕方向,可参考Android 8.0系统透明主题适配解决办法

4. 总结

从线上最新的数据来看，接近60%的订单在锁屏后可以通过自定义锁屏查看到订单状态。

功能上线后发现比较少用户会主动选择关闭，从最开始的出发点就是为用户提供一个便捷的状态查看的入口，用户下完单等待司机接单以及接单后司机的状态都是用户会重点关注的，同时我们会过滤掉一些不太重要的状态的显示避免对用户带来不必要的干扰。

从实现的角度上来说整体较简单，较麻烦的是国内的ROM对权限的管控越来越严，且不同的系统同一权限的命名和授予方式差异较大，需要用更吸引用户的体验去引导用户授权。

文章起因

这篇文章的起因来源于一个需求，产品：“我需要在浏览器点击后退的时候，加一个弹框引导用户做其他的操作”，老实讲这一块之前研究了很多次通过popstate去监听，但是始终有问题没有达到理想的状态或者说并没有完全研究透彻，本来想直接回复做不了砍掉这里吧，后来出于职业道德的遵守还是说试试看吧！

后来

之后在网上遨游了一段时间找了很多实现方案最后发现有一个Api叫做prompt，他来自于react-router，正好 项目中目前使用的路由就是react-router

import { Prompt } from 'react-router' //v5.2.0版本

我不太清楚看到这篇文章的同学有没有用到过这个Api，我大致介绍一下用法

const App = () =>{

    const [isBlocking, setIsBlocking] = useState(true)

    

    return <>

       <Prompt

           //这里是个Boolean 控制是否监听浏览器的后退 默认监听

           when={isBlocking} 

           message={(_, action) => {

               if (action === 'POP') {

                   Dialog.show({ //普普通通的弹框而已，，，，

                       title: '提示',

                       actions: [

                           {

                               key: 'back',

                               text: '回到浪浪山',

                               onClick() {

                                   history.go(-1)

                                   //用户选择按钮之后关闭掉监听

                                   setIsBlocking(false)

                               },

                           },

                           {

                               key: 'saveAndBack',

                               text: '去往光明顶',

                               onClick: async () => null

                           },

                           {

                               key: 'cancle',

                               text: intl.t('取消'),

                           },

                       ],

                   })

                   return false // 返回false通知该组件需要拦截到后退的操作 将执行权交给用户

               }

               return true //返回true 正常后退不做拦截

           }}

        >Prompt>

      {/* ...内容部分 */}

    

}

export default App

上面这样可以实现我的需求，但是因为之前研究过这好一阵子那会并没找到这个Api，现在找到了本着一种知其然知其所以然的态度，深究一下内部到底是怎么实现可以禁止浏览器后退的，如果你不知道就跟着一起寻找一下吧，可能需要占用一杯咖啡的时间☕️

| Prompt

最初的想法就是直接去看Prompt实现的源码就好了，看看是怎么实现的这里的逻辑 其实在看之前内心是有一些猜测的觉得可能是下面这样做的

• 可能是有一些浏览器提供的api但是我不清楚可以直接做到禁止后退，然后Prompt内部有调用
• 或者是先添加了浏览器记录然后在后退的时候监听又删除

git上找react-router源码，注意要切换到对应的版本V5.2.0，免得对不上号

react-router5.2.0版本对应的链接🔽

github.com/remix-run/r…

从这个链接点击去之后我们可以看到Prompt方法，主要是下面这一段我们捡重点解析一下

1. 获取history上面的block
2. 在初始化阶段将我们的message传递到block中执行，并且获取到当前的unblock
3. 离开的时候执行self.release()执行卸载操作

/**

 * The public API for prompting the user before navigating away from a screen.

 */

function Prompt({ message, when = true }) {

  return (

    

      {context => {

        invariant(context, "You should not use  outside a ");



        if (!when || context.staticContext) return null;

            

        // 这个context是当前使用的环境上下文我们内部路由跳转用的history的包

        const method = context.history.block; 



        return (

           {

              //初始化的阶段执行该方法

              self.release = method(message);

            }}

            onUpdate={(self, prevProps) => {

              if (prevProps.message !== message) {

                self.release();

                self.release = method(message);

              }

            }}

            onUnmount={self => {

              self.release();

            }}

            message={message}

          />

        );

      }}

    

  );

}

既然看到了这里再继续看下 Lifecycle 方法其实这个里面就是执行了一些生命周期，这里就不解析了贴个图大家自己看下吧，都能看懂

github.com/remix-run/r…

到了这里可能有些疑惑，这里好像并没有什么其他操作就是调用了一个block，起初我以为block是原生history上面提供的方法后来去查了一下api发现上面并没有这个方法，此刻就更加好奇block内部的实现方式了

因为我们项目的上下文里面使用的history是来自于一个npm包，后面就继续看看这个history内部怎么实现的

import { createBrowserHistory } from 'history'

const history = createBrowserHistory()

createBrowserHistory

传送门在这里👇🏻感兴趣的同学直接去看源码

github.com/remix-run/h…

直接看里面的block方法

let isBlocked = false



const block = (prompt = false) => {

    const unblock = transitionManager.setPrompt(prompt)



    if (!isBlocked) {

      checkDOMListeners(1)

      isBlocked = true

    }



    return () => {

      if (isBlocked) {

        isBlocked = false

        checkDOMListeners(-1)

      }



      return unblock()

    }

}

现在来分析一下上面的代码

1. prompt是我们传进来的弹框组件或者普通字符串信息
2. transitionManager是一个工厂函数将prompt存到了函数内部以便后面触发的时候使用
3. checkDOMListeners去做挂载操作就是监听popstate那一步
4. 返回出去的函数是在外面在离开的时候做销毁popstate监听的

现在按照上面的步骤在逐步做代码分析，下面会看具体的部分有些不重要的地方会做删减

| transitionManager.setPrompt

• 可以看到工厂函数里面存储了prompt
• 销毁的时机是在上面unblock的时候执行重置prompt

  const createTransitionManager = () => {

      let prompt = null

      const setPrompt = (nextPrompt) => {

        prompt = nextPrompt

        return () => {

          if (prompt === nextPrompt)

            prompt = null

        }

      }

      return {

        setPrompt,

      }

}

| checkDOMListeners

• 上面默认传了1初始化的时候会进行popstate监听
• 离开的时候传了-1移除监听

let listenerCount = 0

const checkDOMListeners = (delta) => {

    listenerCount += delta

    if (listenerCount === 1) {

      addEventListener(window, PopStateEvent, handlePopState)

    } else if (listenerCount === 0) {

      removeEventListener(window, PopStateEvent, handlePopState)

    }

}

| handlePopState

• 调用getDOMLocation获取到一个location

const handlePopState = (event) => {

    handlePop(getDOMLocation(event.state))

}

• getDOMLocation 内部调用createLocation创建了一个
• createLocation内部大家感兴趣可以自己去看一下，没有什么可讲的就是创建一些常规的属性
• 比如state、pathname之类的

const getDOMLocation = (historyState) => {

    const { key, state } = (historyState || {})

    const { pathname, search, hash } = window.location



    let path = pathname + search + hash



    if (basename)

      path = stripBasename(path, basename)



    return createLocation(path, state, key)

  }

那我们现在知道getDOMLocation是创建一个location并且传递到了handlePop方法内部现在去看看这个内部都干了啥

| handlePop

• 我们要看的主要在else里面
• confirmTransitionTo是我们上面提到的工厂函数里面的一个方法
• 该方法内部执行了Prompt并返回了Prompt执行后的结果

let forceNextPop = false



const handlePop = (location) => {

    if (forceNextPop) {

      forceNextPop = false

      setState()

    } else {

      const action = 'POP'



      transitionManager.confirmTransitionTo(location, action, getUserConfirmation, (ok) => {

        if (ok) {

          setState({ action, location })

        } else {

          revertPop(location)

        }

      })

    }

  }

敲黑板 重点来了！！！

现在来看下confirmTransitionTo内部的代码

const confirmTransitionTo = (location, action, getUserConfirmation, callback) => {

    if (prompt != null) {

      const result = typeof prompt === 'function' ? prompt(location, action) : prompt



      if (typeof result === 'string') {

        if (typeof getUserConfirmation === 'function') {

          getUserConfirmation(result, callback)

        } else {

          callback(true)

        }

      } else {

        // 重点在这里，result是我们调用block时候的返回参数 true or false

        // 如果返回false 那浏览器回退将被禁止 反之则正常

        callback(result !== false)

      }

    } else {

      callback(true)

    }

  }

所以现在回到上面的handlePop函数我们就能推测出如果我们回调中返回的false，说明我们想阻止浏览器的回退操作，那么执行的就是revertPop方法（其实名字大家可能也能猜出来 恢复 pop操作😂）

| revertPop

• delta的逻辑是计算从开始到目前为止走过的路径做个差值计算
• 这个时候正常来讲delta应该是1
• 我们看最后一个逻辑就好这里是禁止撤回的重点
• 当delta为1的时候就执行了go(1)
• go方法内部实际调用了window.history.go(n)

const revertPop = (fromLocation) => {

    const toLocation = history.location



    let toIndex = allKeys.indexOf(toLocation.key)



    if (toIndex === -1)

      toIndex = 0



    let fromIndex = allKeys.indexOf(fromLocation.key)



    if (fromIndex === -1)

      fromIndex = 0



    const delta = toIndex - fromIndex



    if (delta) {

      forceNextPop = true

      //window.history.go

      go(delta)

    }

}

之前我看到这里有个疑问就是如果最后的结果只是调用了go的话，那这个好像我们自己监听也可以实现一下于是就有了以下代码

function History() {

    this.handelState = function (event) {

        history.go(1)

    }



    this.block = function (Prompt) {

        window.addEventListener('popstate', this.handelState)

        return () => {

            window.removeEventListener('popstate', this.handelState)

        }

    }

}



const newHistory = new History()

等到我实验的时候发现页面回退确实阻止住了，但是会闪一下上一个页面，给大家举个例子

Step1
我从PageA页面一路push到PageC
PageA -> PageB -> PageC

Step2
从PageC页面点击返回，之后页面的过程是这样的
PageC -> PageB -> PageC

就是说我本应该在PageC点击撤回，理想的效果是就停留在了PageC页面，但是目前效果是先回到了PageB因为我使用了go(1)就又回到了PageC，相当于在点击回退的时候多加载了PageB页面

这使我又陷入了沉思，其实研究到这里如果不把这个弄懂之前的努力就白费了，抱着这种想法又扎到了history代码中遨游一番

之后光看代码捋逻辑对这确实有些迷茫，没有办法只能开始调试history的源码了，这里比较简单，history源码下载下来之后做几个步骤

1. 安装history相关依赖package
2. 启动服务会有一个本地域名

3. 之后在你真实项目中引入这个资源开始做调试

后面其实就一直打log和断点不断调试history源码查看执行路径，发现了问题所在

刚才上面提到的handlePop方法内部有一段代码那会忽略掉了，就是ok为true的时候，因为之前一直关注false的情况忽略了这里，后面把这个里面就研究了一下才明白其中的原委

if (ok) {

  setState({ action, location })

} else {

  revertPop(location)

}

| setState

这个方法做了几件事

• 更新本地history状态，nextState可以理解为下一个目标地址其中包含location和action
• 更新本地history的长度这里没有完全搞懂为什么要更新一下长度，但是猜测可能是为了和原生history状态一直保持同步吧防止出现意外情况
• 这里又看到了transitionManager工厂函数，此时调用的notifyListeners这个就是解决我们上面的谜团所在

const setState = (nextState) => {



    // 1.更新本地history状态

    Object.assign(history, nextState)



    history.length = globalHistory.length

    

    //2.更新依赖history相关的订阅方法

    transitionManager.notifyListeners(

      history.location,

      history.action

    )

}

| notifyListeners

notifyListeners更新订阅的方法，我直接把这块代码贴出来了，一个发布订阅模式没什么好讲的

  let listeners = []



  const appendListener = (fn) => {

    let isActive = true



    const listener = (...args) => {

      if (isActive)

        fn(...args)

    }



    listeners.push(listener)



    return () => {

      isActive = false

      listeners = listeners.filter(item => item !== listener)

    }

  }



  const notifyListeners = (...args) => {

    listeners.forEach(listener => listener(...args))

  }

重点的地方是react-router内部会调用history中的listen，这个listen方法会调用上面的appendListener进行存储，之后在合适的时间点执行react-router中传递的方法

这些方法的入参是目标页面的history属性（location，action），在接收到参数的时候根据参数中的location更新当前的页面

现在可以得出结论我们上面的例子不能成功的原因，是因为我们在执行的过程中没有绕过setState（因为此刻没有能让ok返回false的操作）所以当我们页面路径变更的时候自然页面也会更新

最后整体捋一下这个流程吧

到这里其实细心的同学会发现浏览器的回退我们确实是控制不了的只要点击了就一定会执行后退的操作。在history中针对block方法来说做的事情其实就下面这几步

1. 封装了一个自己本地的history，当然跳转能力等还是依赖原生的history
2. 在URL路径变更的时候history可以决定是否通知单页面应用的路由
3. 如果通知了就相当于我们的ok是true，需要页面也更新一下
4. 如果未通知相当于ok是false，就不需要页面更新

这就是为什么history里面的block为什么可以用go就能实现当前页面回退，本质上浏览器历史记录确实回退了，但是history并没有通知应用页面更新，并且继续执行go(1)这样给用户看到的视角就是页面没有回退并且url也没有变化

结论

其实在使用的时候history还是有一些问题如果当前页面reload了，那么revertPop里面的go就不会执行，因为此时的delta是0，这样就会导致即使页面没有变化但是url更新成了上一个记录

说一下我的看法这可能是这个history遗留的bug也可能是有意而为之但是也不重要了我们搞懂了原理就好。

其实浏览器后退加监听的行为感觉还是一个比较高频的需求操作，后面我打算自己写一个插件专门就做后退拦截的操作~

到底了------

今天圣诞节了 祝你们圣诞节快乐 Merry Christmas🎄🎄🎄 ！！！希望都能收到喜欢的礼物🎁

作者：零狐冲
来源：juejin.cn/post/7316202778790477834

前言

从三个月前就在想年终总结写什么，真的把手放在键盘上就不知道从何开口了，足足在电脑面前发呆了一个小时才开始写.....

前几年可能真的在无限重复一天或者两天，上班 下班 吃饭 打游戏 睡觉 然后无限循环这一天。但今年一年其实真没白活，酸甜苦辣咸全都经历了；

分手

2023年1月末 过完年从大连坐飞机回到南京，这个冰冷的出租屋只剩下我一个人还有三只猫，少了另一个人的存在，我们从2018年6月14号在一起，到1月26号分手。

南京租的是个商水商电的公寓因为她两年前就说想住loft，1块7一度的电费让我只能下班回家的三五个小时舍得开一会空调甚至她不在的时候我就忍着了否则只要人在家就开空调的话一个月估计要三五百的电费。

从确定分手到我找好房子搬走有一个半礼拜，那个屋子还是阴面， 那几天下班回到那个出租屋让我感觉像住在监狱里，阴暗 冰冷 孤独，一切负面心情几乎全部聚在那里那刻。

我们分手的主要原因是双方家庭谈彩礼和买房的时候没有谈妥，聊崩了，她家是安徽的我家是辽宁的，详细的我就不在这说了，简单明了一句话就是 彩礼和房她们要的我们给不起，就这样。

在一起时开玩笑说分手了就学电影里男女主角我剃光头她剪短发，想到这我就拿推子把头剃了 但我没有让她知道 我怕她也真的剪了短发。

恢复理智后就是开始给她收拾东西，因为她家里人不让她回来见我怕我们旧情复燃，所以给了我地址我把她的行李都收拾好她的衣服一件件叠好装进箱子，也不知道崩溃了多少次，明明上个月这个时候我还看着她洗澡前把项链拿下来挂在浴室墙壁，现在项链就一动不动的挂在浴室墙壁上 而我站在墙壁面前看着这个项链愣愣的发呆，不知道多久后还是拿了下来小心翼翼的装进盒子里再放进箱子继续收拾。

她的行李寄走后随之也就是收拾我的行李、找房子、搬家。彻底结束维持了四年半的恋爱。

新的房间是独门独户的，我自己一个人住，是阳面的房间 而且楼层比较低，在三楼 经常能听见孩子们在小区里喧闹的声音，这给了我极大的治愈。而且我很喜欢收拾屋子，我觉得很解压，收拾干净后换上自己喜欢的四件套、墙壁挂布、地毯、玩偶 我住这也舒服;

也正巧那几天工作也忙，我们办公室算我老大在内就三个前端，老大也基本是干指挥官的活，另一个前端又有些菜，所以又难又累的活基本都是我来干，工作繁忙起来让人也就不会想那么多消耗情绪的事情。

（也是这个时候发现了掘金的新大陆——沸点）

这个时候活干的其实正起劲呢，因为项目业务流程都已经轻车熟路了，而且我老大也很器重我。

还在想什么时候有时间系统学习一下react18，现在是会用，但也只是工作推进我才会用的 并没有vue掌握的那么熟练，甚至如果面试让我说react可能都说不上来什么东西。想要技术更精进一些还是要花点时间好好学一下。

22年秋天开始也迷上了撸铁，不敢去健身房怕被健身教练pua买课，怕被大佬笑话，怕器械不会用，就买了一对哑铃在家里自己学自己练，看视频博主很多教的怎么吃 怎么练 胸怎么练胳膊怎么练 肩膀怎么练 分手一个月后缓过来了健身更有动力了。

然后自己放假的时候也开始往周边的城市走走，以前放假都是屯在家里，懒得出门，现在发现没事经常出去转转真的挺好的。独自去了杭州、苏州、镇江，拍照片 看看这看看那....

似乎生活在往好的方向走....

音乐

鄙人不才，从小喜欢听歌唱歌研究歌，目前在网易云有三首个人单曲，全部是自己作词作曲演唱。

分手这件事也给我很大的情绪冲击，缓和以后就着一点点余动把年前的歌给写完了，名叫《背靠月亮的夜晚》JYM感兴趣可以直接去网易云搜，好听的话也麻烦给个小红心支持下。

为什么这段落的title叫音乐呢因为不只是发歌，还去听歌；

4月份一个人去看了伏仪的现场
现场听了《昨日记书》《神离少年》《我会在每个有意义的时辰》等

5月份很小哥们去看了黄绮珊 黄妈的演唱会
《年轮》《离不开你》《无聊的》等

6月份一个人去看了暗杠的现场
《说书人》《走歌人》《童话镇》等

前几年和前女友在一起生活好像从没有出去旅游，去看演唱会，不是说不去而是当时好像就没有这个意识，放假了就只想两个人买一堆好吃的在家里看电影打游戏，一天一天就这么过去了

离职

我一直觉得工作和谈恋爱有异曲同工之处，比如，找工作要看条件，是否符合预期，看通勤，看薪资，也要看自己能不能干的了这份活，谈恋爱也是要看对方性格，长得好不好看，三观合不合，在一起时候能长久，还有 一点点说不清道不明的缘分。

六月份我已经彻底从分手的阴影种走了出来，并且攒了一小笔钱，打算攒够三万买摩托车，当时想买的款式是GSX250。但天有不测风云，甲方集体转移去广州，听说北京那一拨 还给了外包赔偿 我天真的以为我们也有赔偿 所以当听到甲方要转移的时候我还挺乐呵，因为我干了四年了，从没拿过赔偿，一直是外包 说辞就辞了。

但其实还是很不舍的，人对于一个地方呆久了就会有依赖，如果离开这里去新的地方就会有一种陌生的感觉，这感觉会让人不舒服。这家公司从通勤、薪资、办公环境、同事氛围、加班不管各方面看都很满意了，很知足的。如果不开除我我觉得干个三年都不成问题。而且之前老大还跟我说过有个新项目要下来从零到一打算全权让我独立负责，我当时有些高兴又有些担心，高兴是会得到前所未有的挑战，以后简历上也是亮眼的一笔。担心是我其实也怕我技术不顶，倒时候再给惹祸，而且也担心到时候会不会天天加班.....现在好了，不用担心了。

南京的外包没有给赔偿而是给安排其他的甲方公司，没过多久我收到了人事给我安排的面试，当天下午就接到了电话，问的也都不难，但是实在是不想去，因为第一：目前这家公司待了一年多了 同事也混得很熟了去了谁都不认识。第二：这家公司距离我住得地方很远 每天上下班通勤要花费现在的通勤1.5倍的时间

就也没有去，窝囊的选择了自离。

正好也想去西藏很久了，什么青春没有售价这种话都要听烂了，也攒了一点钱，索性就买票去了

谁帮我看看图片的上面写的啥（doge）

旅行

网上说去西藏做有意义的事就是捡队友和被捡，正好我也是一个人去的，我就往这一坐（内心： 我看谁来捡我）
甚至做好了没人捡的准备，就打算自己玩了。
不过好在也确实被捡到了，一路上认识了好几个处的不错的朋友 半年多了过去了现在也还经常聊天。

这块要详细写的话太多了写不过来，直接给你们看我当时记录的朋友圈吧 你们有什么问题的话可以评论区或者私信问比如高 去了哪些地方 报团多少钱之类的

最后一个朋友圈写错了，应该是第七天了。

到这基本前半年就过完了，欲知下半年如何，请看另章分写

前几天，一位师弟约我吃饭，师弟跟我同校同一个专业，2022年本科毕业，比我低很多届，目前在华为工作。我们聊了很多母校的共同回忆，最近几年应届生求职的情况，也聊到了他在华为的工作经历。

师弟性格开朗，为人谦和，属于在学校各大社团特别混得开的那种，成绩也不错，保研到本校，但拿到华为offer后，放弃了继续深造，选择直接就业。

聊到当今应届生求职现状时，感慨万千。

我的母校是一所普通211，部分专业比较有特色，在行业属于领先地位，但学校整体名气一般。

记得我们大四毕业时，就业行情还比较好，每个班都有好几个同学进入了华为。读研后，实验室的师兄师姐基本都拿到了华为offer，等我们开始找工作时，大部分同学也都拿了华为offer，华为基本属于大家的保底选择。

师弟去年毕业时，他是专业唯一拿到华为offer的学生。这几年的就业形势，本科生基本找不到什么好工作，除了继续读书深造，没有更好的选择。

短短的几年，社会瞬息万变，就像坐上了一辆过山车，身处其中的人，也只能仅仅抓住车身的杠子，在急速下坡时，不让自己摔下来。

师弟进入华为，原本是一件很开心的事，短短一年，经历职场拷打，再也没有大学时代那份锐气。

华为属于员工人数最多的科技公司之一，每年吸收了大批校招生，但员工离职率也非常高。

师弟反馈，跟他同一批进去的人，很多干了几个月就离开了，他是那一批少数还留下来的人。

刚入职时，每个人都要参加新员工入职培训，那时候大家都很骄傲和自豪，也非常认同企业的价值观和文化。

但当真正的分到项目组开始工作时，发现大家实际工作情况，和价值观上说的，并不不太一样。在基层落地时，价值观更多是挂在墙上的标语。

领导也基本不太关心员工的成长和未来发展，更多是把每一个员工当作生产工具，哪一件工具用的顺手、更能出活儿，就会用谁；还没证明过自己的工具，或者经验匮乏的工具，很有可能会被无情抛弃。

华为的假期还可以，但大家有什么事，都不太敢请假。即便是生病，如果不是非住院不可，也不太会请假；公司支持请假，但大家还是轻伤不下火线，请假会影响出勤系数，各种与之相关的奖金，也会大打折扣。

……

师弟还分享了工作以来其他的一些心得体会，一句话总结：职场很残酷，相比起来，大学轻松太多了。

在我看来，华为还是中国一流的科技公司。大部分人，还是要挤破脑袋才能进得去。

华为有很好的制度，比如员工转岗，门槛还不太高。华为支持不同工种互相转岗，比如，干技术的，有一天不想写代码了，可以转人力，或者转销售。开发太累，也可以转做测试。公司会提供基本的业务培训，还有三个月的考核期，只要达到一定的用人标准，就能转岗成功。

华为还有很好的奖励制度，只要能吃苦，且绩效不太差，能坚持下来，很多人最后都获得了丰厚的回报。比我高一两届的师兄师姐，还有跟我同一届的很多朋友，现在都还在华为，过得还不错。

华为还有比较完善的福利体系。在各地的办公区，远离市区，地价也很便宜，平时在公司会有夜宵、员工餐厅、下午茶和健身房各种福利，也有些地方，会有单身公寓。进入华为后，除了工作，也没什么社交，公司能满足日常的衣食住行。平时挣的钱，基本都能存下来，成家后，在华为附近买房，也基本衣食无忧了。

华为是一家跨国公司，如果是干技术支持或销售，还能享受去各国打卡的福利。在年轻的时候，能去更远的地方走一走，也是一件很宝贵的人生经历。

华为是中国众多私企大厂的一个缩影，也是最早践行狼性文化的一家公司。

如今的字节、阿里等互联网企业，也在走华为的老路。

这些大厂，给了年轻人一个令人向往的机会，但并不适合每个人。如果我们能早些看清现实，自己只是大厂的一颗螺丝钉，需要做的是，尽快掌握螺丝钉需要具备的技能，与此同时，如果借助大厂的势能，多开眼界，多认识一些各个领域的前辈和牛人，把企业能提供的资源用到极致，就更了不起了。

至于在公司里寻找朋友、寻找归属感或者安全感，那并不是一个好选择。同事间的八卦，公司股价的涨跌，CEO的致辞，也并不是我们需要关心的事。

最重要的是，无论在大厂还是小厂，在国企还是私企，都要拥有良好的心态。最怕的是，在国企羡慕华为的工资；在大厂，又羡慕国企的朝九晚五。

人生在世，各有各的不易。每一种选择，都没有对错， 选择了其中一个，在另外一部分，就得有所取舍。

在任何时候，学会“自洽”，与生活和解，与自己和解很重要。

Vue3的逻辑复用

使用了 Vue3 Composables 之后，逻辑复用比之前要顺手很多，这里说说前端开发最常用的场景，管理页面的列表查询和增删改查的逻辑复用，欢迎大家共同探讨。

用免费的 render 服务搭建了个在线的预览地址，源码在这里，用了免费的 node 环境和免费的 pg 数据库，对这部分有兴趣的可以看看我以前的分享，我写了个部署 spring-boot 的分享，使用 node 就更简单了。

可能每个人的具体工作内容不一致，但是应该都完成过这样的工作内容：

这些最基础的工作可能占用了我们很大的时间和精力，下面来讨论下如何逻辑复用，提高工作效率

需求分析

一个后台管理中心，绝大部分都是这种管理页面，那么需要：

• 首先是封装一些通用的组件，这样代码量最低也容易保持操作逻辑和 UI 的一致性


• 其次要封装一些逻辑复用，比如进入页面就要进行一次列表查询，翻页的时候需要重新查询


• 最后需要有一些定制化的能力，最基本的列需要自定义，页面的过滤条件和操作也不一样

统一复用

列表的查询过程

新增 Item、查询 Item、修改 Item

删除 Item

定制化的内容

成果展示

代码直接贴在下面了，使用逻辑复用完成以上的内容一共 200 多行，大部分是各种缩进，可以轻松阅读，还写了一个 Work 的管理，也很简单，证明这套东西复用起来没有任何难度。

<template>

  <div class="user-mgmt">

    <biz-table

      :operations="operations"

      :filters="filters"

      :loading="loading"

      :columns="columns"

      :data="tableData"

      :pagination="pagination"

      :row-key="rowKey"

      :checked-row-keys="checkedRowKeys"

      @operate="onOperate"

      @filter-change="onFilterChange"

      @update:checked-row-keys="onCheckedRow"

      @update:page="onUpdatePage"

      @update:page-size="onUpdatePageSize"

    />

    <user-item :show="showModel" :item-id="itemId" @model-show-change="onModelShowChange" @refresh-list="queryList" />

  </div>

</template>



<script setup name="user-mgmt">

import { h, ref, computed } from 'vue';

import urls from '@/common/urls';

import dayjs from 'dayjs';

import { NButton } from 'naive-ui';

import BizTable from '@/components/table/BizTable.vue';

import UserItem from './UserItem.vue';

import useQueryList from '@/composables/useQueryList';

import useDeleteList from '@/composables/useDeleteList';

import useChangeUserActiveState from './useChangeUserActiveState';



// 自定义列数据

const columns = [

  {

    type: 'selection'

  },

  {

    title: '姓',

    key: 'firstName'

  },

  {

    title: '名',

    key: 'lastName'

  },

  {

    title: '是否激活',

    key: 'isActive',

    render(row) {

      return row.isActive ? '已激活' : '未激活';

    }

  },

  {

    title: '创建时间',

    key: 'createdAt'

  },

  {

    title: '更新时间',

    key: 'updatedAt'

  },

  {

    title: '操作',

    key: 'actions',

    render(row) {

      return [

        h(

          NButton,

          {

            size: 'small',

            onClick: () => onEdit(row),

            style: { marginRight: '5px' }

          },

          { default: () => '编辑' }

        ),

        h(

          NButton,

          {

            size: 'small',

            onClick: () => onChangeUserActiveState(row),

            style: { marginRight: '5px' }

          },

          { default: () => '改变状态' }

        )

      ];

    }

  }

];



// 自定义右上角筛选

const filters = ref([

  {

    label: '是否激活',

    type: 'select',

    value: '0',

    class: 'filter-select',

    options: [

      {

        label: '全部',

        value: '0'

      },

      {

        label: '已激活',

        value: '1'

      },

      {

        label: '未激活',

        value: '2'

      }

    ]

  },

  {

    label: '',

    type: 'input',

    placeholder: '请输入姓氏',

    value: ''

  }

]);



// 筛选变化，需要重新查询列表

const onFilterChange = ({ index, type, value }) => {

  filters.value[index].value = value;

  queryList();

};



// 自定义查询列表参数

const parmas = computed(() => {

  return {

    isActive: filters.value[0].value,

    like: filters.value[1].value

  };

});



// 封装好的查询列表方法和返回的数据

const { data, loading, pagination, onUpdatePage, onUpdatePageSize, queryList } = useQueryList(urls.user.user, parmas);



// 经过处理的列表数据，用于在 table 中展示

const tableData = computed(() =>

  data.value.list.map(item => {

    return {

      ...item,

      createdAt: dayjs(item.createdAt).format('YYYY-MM-DD HH:mm:ss'),

      updatedAt: dayjs(item.updatedAt).format('YYYY-MM-DD HH:mm:ss')

    };

  })

);



// 删除列表相关逻辑封装

const { checkedRowKeys, onCheckedRow, deleteList } = useDeleteList({

  content: '确定删除选中的用户？',

  url: urls.user.userDelete,

  callback: () => {

    queryList();

  }

});



// 列表中的快捷操作

const operations = computed(() => {

  return [

    {

      name: 'create',

      label: '新增',

      type: 'primary'

    },

    {

      name: 'delete',

      label: '删除',

      disabled: checkedRowKeys.value.length === 0

    }

  ];

});



// 触发操作函数

const onOperate = function (name) {

  operationFucs.get(name)();

};



// 新创建 item

const create = () => {

  showModel.value = true;

  itemId.value = 0;

};



const onModelShowChange = () => {

  showModel.value = !showModel.value;

};



const itemId = ref(0);



// 控制模态对话框

const showModel = ref(false);



// 编辑 item

const onEdit = row => {

  itemId.value = row.id;

  showModel.value = true;

};



const { changeUserActiveState } = useChangeUserActiveState();



// 改变激活状态

const onChangeUserActiveState = row => {

  changeUserActiveState({

    id: row.id,

    isActive: !row.isActive,

    loading,

    callback: () => {

      queryList();

    }

  });

};



// 指定 table 的 rowKey

const rowKey = row => row['id'];



// operation 函数集合

const operationFucs = new Map();

operationFucs.set('create', create);

operationFucs.set('delete', deleteList);

</script>



<style lang="scss">

.user-mgmt {

  height: 100%;

  .filter-select {

    .biz-select {

      width: 100px;

    }

  }

}

</style>

一、前言

最近有遇到一个需求，在h5浏览器中实现扫码功能，其本质便是打开手机摄像头定时拍照，特此做一个记录。主要技术栈采用的是vue2，使用的开发工具是hbuilderX。

经过测试发现部分浏览器并不支持打开摄像头，测试了果子，华子和米，发现夸克浏览器无法打开摄像头实现功能。

h5调用摄像头实现扫一扫只能在https环境下，亦或者是本地调试环境！！

二、技术方案

经过一番了解之后，找到了两个方案

1.使用html5-qrcode(对二维码的精度要求较高，胜在使用比较方便，公司用的是vue2，因此最终采用此方案)

2.使用vue-qrcode-reader(对vue版本和node有一定要求，推荐vue3使用，这里就不展开说了)

三、使用方式

当点击中间的扫码时，设置isScanning属性为true,即可打开扫码功能，代码复制粘贴即可放心‘食用’。

使用之前做的准备

通过npm install html5-qrcode 下载包

引入 import { Html5Qrcode } from 'html5-qrcode';

html结构

<view class="reader-box" v-if="isScaning">

	<view class="reader" id="reader"></view>

</view>

所用数据

data(){

    return{

        html5Qrcode: null,

        isScaning: false,

    }

}

methods方法

openQrcode() {

    this.isScaning = true;

    Html5Qrcode.getCameras().then((devices) => {

    if (devices && devices.length) {

    this.html5Qrcode = new Html5Qrcode('reader');

    this.html5Qrcode.start(

        {

        facingMode: 'environment'

        },

        {

        focusMode: 'continuous', //设置连续聚焦模式

        fps: 5,       //设置扫码识别速度

        qrbox: 280   //设置二维码扫描框大小

        },

        (decodeText, decodeResult) => {

         if (decodeText) {	//这里decodeText就是通过扫描二维码得到的内容

            this.action(decodeText)  //对二维码逻辑处理

            this.stopScan(); //关闭扫码功能

        }

    },

        (err) => {

            // console.log(err);  //错误信息

         }

     );

    }

    });

},



stopScan() {

	console.log('停止扫码')

	this.isScaning = false;

	if(this.html5Qrcode){

    this.html5Qrcode.stop();

	}

}

css样式

.reader-box {

		position: fixed;

		top: 0;

		bottom: 0;

		left: 0;

		right: 0;

		background-color: rgba(0, 0, 0, 0.5);

	}



	.reader {

		width:100%;

		// width: 540rpx;

		// height: 540rpx;

		position: absolute;

		top: 50%;

		left: 50%;

		transform: translate(-50%, -50%);

	}

四、最终效果

如有问题，欢迎指正，若此文对您有帮助，不要忘记收藏+关注！

在Java 8引入的Lambda表达式和函数式接口之后，双冒号运算符(::)成为了一项重要的功能。它可以将方法或构造函数作为参数传递，简化了编码和提升了代码的可读性。本文将介绍Java中的双冒号运算符及其常见应用场景。

双冒号运算符(::)的语法

双冒号运算符的语法是类名/对象名::方法名。具体来说，它有三种不同的使用方式：

静态方法引用

首先，我们来看一下如何使用双冒号运算符引用静态方法。假设有一个Utils类，其中有一个静态方法processData：

public class Utils {

    public static void processData(String data) {

        System.out.println("Processing data: " + data);

    }

}

我们可以使用双冒号运算符将该方法作为参数传递给其他方法：

List<String> dataList = Arrays.asList("data1", "data2", "data3");

dataList.forEach(Utils::processData);

上述代码等效于使用Lambda表达式的方式：

dataList.forEach(data -> Utils.processData(data));

通过使用双冒号运算符，我们避免了重复写Lambda表达式，使代码更加简洁和易读。

实例方法引用

双冒号运算符还可以用于引用实例方法。假设我们有一个User类，包含了一个实例方法getUserInfo：

public class User {

    public void getUserInfo() {

        System.out.println("Getting user info...");

    }

}

我们可以通过双冒号运算符引用该实例方法：

User user = new User();

Runnable getInfo = user::getUserInfo;

getInfo.run();

上述代码中，我们创建了一个Runnable对象，并将user::getUserInfo作为方法引用赋值给它。然后，通过调用run方法来执行该方法引用。

构造函数引用

在Java 8之前，要使用构造函数创建对象，需要通过写出完整的类名以及参数列表来调用构造函数。而使用双冒号运算符，我们可以将构造函数作为方法引用，实现更加简洁的对象创建方式。

假设有一个Person类，拥有一个带有name参数的构造函数：

public class Person {

    private String name;



    public Person(String name) {

        this.name = name;

    }



    public String getName() {

        return name;

    }

}

我们可以使用双冒号运算符引用该构造函数并创建对象：

Supplier<Person> personSupplier = Person::new;

Person person = personSupplier.get();

person.getName(); // 调用实例方法

上述代码中，我们使用Person::new将构造函数引用赋值给Supplier接口，然后通过get方法创建了Person对象。

总结

本文介绍了Java中双冒号运算符(::)的语法及其常见的应用场景。通过双冒号运算符，我们可以更方便地引用静态方法、实例方法和构造函数，使得代码更加简洁和可读。双冒号运算符是Java 8引入的重要特性，对于函数式编程和Lambda表达式的使用起到了积极的推动作用。

希望本文能够帮助您理解和应用双冒号运算符，提高Java开发的效率和代码质量。如有任何问题或疑惑，欢迎提问！

简介

朋友昨晚让我帮忙看怎么调试vue源码，我当时就不困了啊。兴致勃勃搞了半小时以失败告终。小白我可是永不言败的，早上鼓捣了俩小时总算写了点东西出来。想调试vue源码的小伙伴可以试试我这个思路

fork源码

首先肯定是要把vue/core代码fork一份到自己的仓库 这样后续有改动可以提交一下 也可以从源码一键同步

ps：github.com/baicie/vuej… 我的代码在这里可以参考一下

装包

pnpm i @pnpm/find-workspace-packages @pnpm/types -wD

ps:可以先看看pnpm与monorepo

在根目录执行上述命令装一下依赖-wD含义是在workspace的根安装开发依赖

脚本编写

首先在packages下执行pnpm creata vite创建一个vue项目

然后在scripts文件夹下创建dev.ts

import type { Project as PnpmProject } from '@pnpm/find-workspace-packages'

import { findWorkspacePackages } from '@pnpm/find-workspace-packages'

import type { ProjectManifest } from '@pnpm/types'

import { execa } from 'execa'

import os from 'node:os'

import path from 'node:path'

import process from 'node:process'

import color from 'picocolors'

import { scanEnums } from './const-enum'



export type Manifest = ProjectManifest & {

  buildOptions: {

    name?: string

    compat?: boolean

    env?: string

    formats: ('global' | 'cjs' | 'esm-bundler' | 'esm-browser')[]

  }

}



interface Project extends PnpmProject {

  manifest: Manifest

}



const pkgsPath = path.resolve(process.cwd(), 'packages')

const getWorkspacePackages = () => findWorkspacePackages(pkgsPath)



async function main() {

  scanEnums()

  // 获取所有的包 除了private与没有buildOptions的包

  const pkgs = (

    (await getWorkspacePackages()).filter(

      item => !item.manifest.private

    ) as Project[]

  ).filter(item => item.manifest.buildOptions)



  await buildAll(pkgs)

}



async function buildAll(target: Project[]) {

  // 并行打包

  return runParallel(Number.MAX_SAFE_INTEGER, target, build)

}



async function runParallel(

  maxConcurrent: number,

  source: Project[],

  buildFn: (project: Project) => void

) {

  const ret: Promise<void>[] = []

  const executing: Promise<void>[] = []

  for (const item of source) {

    const p = Promise.resolve().then(() => buildFn(item))

    // 封装所有打包任务

    ret.push(p)



    //

    if (maxConcurrent <= source.length) {

      const e: any = p.then(() => executing.splice(executing.indexOf(e), 1))

      executing.push(e)

      if (executing.length >= maxConcurrent) await Promise.race(executing)

    }

  }



  return Promise.all(ret)

}



async function build(project: Project) {

  const pkg = project.manifest

  // 获取相对路径 包名

  const target = path.relative(pkgsPath, project.dir)

  if (pkg.private) {

    return

  }



  const env = (pkg.buildOptions && pkg.buildOptions.env) || 'development'

  await execa(

    'rollup',

    [

      `-c`,

      // 给rollup配置文件传递参数 watch 监听文件变化

      '--watch',

      '--environment',

      [`NODE_ENV:${env}`, `TARGET:${target}`, `SOURCE_MAP:true`]

        .filter(Boolean)

        .join(',')

    ],

    { stdio: 'inherit' }

  )

}



main().catch(err => {

  console.error(color.red(err))

})

然后在根目录的package.json scripts 添加如下

"my-dev": "tsx scripts/dev.ts"

上述脚本主要是为了扫描工作目录下所有有意义的包并执行rollup打包命令（主要也就为了加一下watch没毛病）