做了几年的技术管理，简单几点经验可以分享交流一下，管理比起程序还复杂很多，因为一个面向人，一个面向机器，不能以相同的方式来思考，重点是找到平衡，不能用一种方式解决所有问题；好的管理者日常要看的面相非常多，尤其是一、二线带团队，不仅要关注好每个人，同时还要能做好承上启下的作用，要做到面面俱到难度十分高，以下就根据几个维度来分享我自己的经验。

做一个自己都喜欢的团队

每个人带的团队都会有自己的风格，我对自己的要求就是创造自己都愿意待的团队，至于什么是我自己喜欢的团队，简单归类了几个要点，有目标、有空间、有坚持，有明确且有挑战的目标，有足够的空间和舞台来发挥所长，有耐心能坚持做正确的事，能有机会和一群伙伴来达成目标真的是再幸福不过的事，这过程肯定会遇到无数的问题，只要确认不断保持向前，坚持就是胜利✌️

找到共同的目标，坚持做对的事

很多时候团队会存在支持多个目标/业务，这时候就必须类似技术抽象一样的来找到团队内的最大公约数，不一定只有一个但必须要有，核心点还是找到共同的目标，有了共同目标、愿景后可以更好的凝聚方向。

如果一个管理者只是在做分配资源的事，那么还不如不要这个管理者，毕竟传声筒的工作完全可以交给系统解决，例如团队 OKR 只是把每个小方向聚合，那么团队大概率是没方向，等待着别人来推进。

换位思考，保持沟通，面对的是人不是机器

任何沟通最重要的就是换位思考，如果能做到这件事大概率沟通上可以减少很多问题；沟通的过程重点应该是通，关键点不是自己说了多少或做了多少，而是对方获得了多少，多理解对方背后考量的因素，去解决问题而不是解决出问题的人。

过去常听到对于技术人的评价是 “无法沟通”，这种情况大概率是双方没找到频率，每个人都有自己习惯的沟通方式，作为管理者应该要在团队内帮助大家达成一种沟通默契，不应该要求所有人都能使用同一种方式来交流，以及该有的底线划清楚；非常多优秀的人是很有个性的，懂得如何把这样的人摆好位置，会比起把这样的人驯服更有意义，只要在影响范围可控的情况下，应该多花点时间思考在整体排兵布阵。

团队成长 > 个人成长

带团队后最大的不同点就在于需要思考的是整个团队的产出，而不是自己的产出；尤其是原先自己是同团队最优秀的成员因此被提拨出来作管理，自己原先是其他人的 150% 以上的贡献度，但开始带团队后必须要能接受自己的产出会大幅下降，可能自己剩下 50%，团队其他人提升 20%，达到团队整体产出提升。

放权、给予试错空间很重要，想要让团队成员成长势必要让他逐步能承担起更重要的责任与任务；以战养兵是在工作中很好的方案，过程给予适度的辅助与容错，很多错没经历过是不会懂，读万卷书不如行万里路。

建团队，招聘 培养 汰换

建团队是每个管理者都会面对的问题，团队人才密度、人才水平都会决定采用不同的管理方式，其中招聘我认为是最重要的，这关卡的越严格后面就会越轻松，强烈建议这关必须把握好底线，水桶永远会从最低的那一边开始漏水。

招聘是一门大学问，坊间也有很多相关的书籍介绍，并且有专门的服务和职位，在这就以用人的部分来谈谈，一般我自己决定用人就两个原则，“我是否愿意汇报给他/她？”或 “我是否愿意把背后交给他/她？” 这两个问题概括大量的信息和判断，包含当前/未来是否需要这样的能力、团队匹配度、潜力和领导力等，团队整体布局上最好能保持更多元，并且别怕团队成员能力超越自己，就像曾子说的 “用師者王，用友者霸，用徒者亡。”

培养简单可以分为两块专业和软素质，专业部分培养一般相对容易，刚好是相同专业可以直接指导，如果是不同的领域可以找外部进来帮忙，软素质部分大多还是依靠团队日常培养，这块重点主要还是言传身教，身为主管日常的一举一动都会成为团队同学的标杆，因此必须对于自己的言行有一定的要求，尤其是公开场合。

汰换对管理者来说是个很重要的责任，尤其在面对这个环节一定要慎重的考量，要对于每个汰换最好都能有记录留底，帮助自己复盘；一般来说必须找到当前的瓶颈，究竟是卡在事还是人，如果是卡在人，也必须分析清楚原因，因为造成团队不稳定因素？潜力？阻碍团队发展？包含考虑这个瓶颈是不是自己。

1 to 10，10 to N，定义规则

团队 <10 的时候可与所有团队成员都非常的亲近，能明确的知道每个人在做些什么，甚至是团队成员家里的猫受伤了都能知道，在这个时期管理的负担并不是特别大，至少能有一半的时间能在执行日常工作，这时期可能会出现蜡烛两头烧的情况，必须要能尽快的找到平衡点，不需要扣每个细节，但要抓准方向。

团团在 >10 后在 <=15 可能整体变化不大，不过可以很明显的感受到管理成本提升，这个时期会慢慢的开始发现到靠着过去手把手了解细节方式精力会严重不足，需要靠着各种规则、规范来达到找寻最大公约数。

随着管理的范围越大会发现想要知道每个同学的情况不现实，靠着规则来减少管理精力，引导团队走向正确的方向，这其中会有很多的权衡，出现很多错误解读或过度解读信息的问题，通过不断的调整来达到平衡，然而这个平衡是来自于成熟度及规模。

Netflix 的团队有出了一本《零规则》，描述的是大多更像是以原则来取代规则减少理解成本，相信每个人都能按照规则走，再定期抽查的机制保障，从书中来看是可行的，为了适配不同地区文化不同也做了适度的调整，是一种感觉可行的模式，但还是要根据当前团队情况调整。

绩效管理

绩效只是管理的工具和手段，通过这个工具来帮助团队发展和个人提升，让每个同学知道自己阶段的优缺点以和校正方向，让好的更好，阶段性不好的同学能找到方向，达到个人和团队的成长。

绩效管理一定要记得 “功在平时”，绝对不能把绩效管理作为周期性的工作处理，日常付出的越多在绩效评分的时候问题就越少，同时也能帮助绩效沟通上更顺畅，把事情放到最后一刻很容易造成意外，一个不小心就成了事故。

不能忘本

大多技术管理者都是从 IC 开始，保持手感很重要，随着管理的幅度增加会大量降低自己的时间，最好还是能保持着写代码的手感，过往的经验能帮助增加判断力，但技术是不断在翻新，缺少了手感短期可能问题不大，要是习惯了会逐步脱节，严重点就会出现 “技术官僚” 问题，毕竟迭代这么快，哪怕知道原理也容易出现多个类似产品出现后该如何更好的判断问题。

多体验自己做出来的东西，感受技术带来的价值，相信自己每一行代码都在提升人的生活水平，而不是完成一个个任务；技术是个很不同的工种，除了使用工具还能够创造新的工具，为别人提升效率同时也能为自己提升效率。

小结

修身 齐家 治国 平天下，先能以身作则才能更好的要求其他人，让更多人能一起朝着相同方向前进，就像优秀的技术管理者大多也会是个优秀的 IC；保持同理心，多换位思考，帮助更多人激发潜力，各自发挥所长并找到其中的平衡点，这门学问就像是艺术一样的有趣。

到今天仍然觉得自己不是个合格的管理者，还有很多事要学，还有很多要改，没办法做到完美，只能尽可能在前往更好的路上加速前进着，欢迎各种交流讨论，互相学习🤝

原则一：乙方来做决策

• 最终拍板人是谁？是甲方，如果你非要抢板子，那你以后就没有甲方了


• 但是，如果甲方也觉得“我花钱了，当然要听我的（那些只对上级负责又不能拍板的底层打工人，总是这样认为）”，那这种甲方的项目你就不要接


• 因为在这种甲方眼里，你只是“施工方”，他们即不需要你的经验价值，更不会为你的经验买单。所以这种甲方你会做得很累，当他们觉得“你的工作强度不足以匹配付给你的费用时（他们总这样觉得）”，他们就会不停地向你提出新的开发需求


• 所以，你要尽量找那种尊重你经验价值，总是向你请教，请你帮他做决策的甲方

原则二：为甲方护航

• 甲方未来会遇到什么问题，你们双方其实都不知道，所以你需要一边开发一边解决甲方实际遇到的问题。


• 因此，不要为了完成合同上的工作内容而工作，要为甲方遇到的实际问题，为了甲方的利益而开发，要提前做好变通的准备。


• 永远不要觉得你把合同上的功能列表做完，你就能休息了。你要解决的真正问题是，为甲方护航，直至甲方可以自己航行。

原则三：不做没有用户的项目

• 如果甲方的项目没有太多用户使用，这种项目就不要接。


• 除了代码的累计经验，还有一种经验也很重要，那就是“了解用户的市场经验”


• 只有真正面对有实际用户的项目，你才能有“解决市场提出的问题”的经验，而不是停留在“解决甲方提出的问题”


• 拥有市场经验，你就会有更高的附加价值，再配上尊重你经验价值的甲方，你就会有更高的收入


• 永远记住：真正愿意在你身上花钱的甲方，他的目的一定是为了让你帮他赚钱！

以上只是我根据自己经验的一家之言，可能对我有用，不一定对别人也有用。肯定还有很多有价值的原则，希望大家根据自己的经验一起来分享。

下面是一些有意思的讨论

原则 2 、3 都是虚的，就不讨论了。

只说原则一：

一般而言，甲方跟你对接的，一定不是老板。

所以他的核心目的一定是项目实施成功。

但项目是不是真的能给企业带来效益，其实是优先级特别低的一个选项。

拿日常生活举个例子。夫妻、情侣之间，你媳妇儿托你办个事，比如让你买个西瓜。

你明知道冬天的西瓜又贵又不好吃，你会怎么办？

A ，买西瓜，回去一边吃西瓜一起骂水果摊老板没良心。

B ，给你媳妇儿上农业课。然后媳妇儿让你跪搓衣板。

C ，水果摊老板训你一顿，以冬天吃白菜豆腐好为由，非卖你一颗大白菜。你家都不敢回。

这里面，你就是那个甲方对接人。你怎么选？

所以乙方一定不能做决策。乙方做决策的结果，就是甲方对接人被利益集团踹开或者得罪甲方对接人，最终导致项目失败

---

我也来说三个原则

1.要签合同，合同越细越好；

2.要给订金，订金越多越好；

3.尾款不结不给全部源码。

---

原则一:外包大部分就是苦力活，核心有价值的部分有自己公司的人干轮不到外包，你不干有的是人干，不会有人尊重你经验价值，甲方说怎么干就怎么干，写到合同里，按合同来，没甲方懂自家业务，别替甲方做决策，万一瞎建议导致项目出现大问题，黄了，外包钱都拿不回来

原则二:给多少钱办多少事，如果甲方给钱痛快，事少，可以看自己良心对甲方多上点心，否则别给自己加戏，不然很可能把自己感动了，甲方却想着好不容易碰上这么个人，白嫖

原则三:不做没有用户的项目,太片面，不是所有外包项目都是面对海量用户，但是做所有外包项目都是为了赚钱，假如有个富二代两三万找你做个毕设，简单钱多不用后续维护，这种接不接？假如某工厂几十万定制内部系统，可能只有几个人用，这种接不接

总之外包就是赚个辛苦钱，别指望这个来提升自己技术和自我价值，外包行业水太深，你这几个原则都太理想化

---

某富豪要盖一栋私人别墅，招建筑工人，现在缺一名搅拌水泥的工人，

找到了张三，张三说我去过很多工地，啥活儿都干过，经验极其丰富，我可以指导一切事物，我再给你兼职当个总设计师吧，一切事物听我的决策没错。

我每天做完我的本职工作搅拌水泥砂浆，我还能熬夜给建筑设计布局，风水，房间规划，材料采购等等，我啥都会，直接干到建筑完工

富豪很感兴趣，说那你来吧，我盖的是自己住的别墅，张三一听连连摆手:你是盖私人别墅啊？不行不行，我不去了，我以前盖的都是高楼大厦，住户多对我技术水平有严峻的考验，做成了对我有很大提高，私人别墅才几个人用，对我职业生涯一点帮助都没

---

永远不要接外包

这才是正确的答案

做私活的时间

不如自己休息休息，陪陪家人

---

屁事真多，有钱就行了，管他项目有没有人，人家产品低能你还得兜底，接外包考虑的是能不能满足需求。啥条件啊还能挑三拣四，给多少钱干多少活。 招投标接的 30 万以上的项目才有可能考虑你说的这些东西。

---

呵呵 我的意见是：

1. 给钱就做（前提是合规，不是合理），先给定金，拿到定金开工。


2. 遇到扯皮，就停止开发。


3. 要有空闲的时间，偶尔做做（上面说的对：永远不要做外包）。

展开来说，做外包的长期收益很低。就当临时玩一下，所以给钱就做，不管你的需求合理不合理，比如甲方想给智障人士开发一款数独小游戏，好，给钱，签合同，支付定金，开工。

开工了3天，甲方突然说，那个我想加个魔方游戏。不好意思，不行，立即停止开发，开始和甲方掰扯，如果掰扯不明白，就终止合同，如果掰扯明白就继续。

不说了，我要和甲甲甲甲甲方掰扯去了。

再高级的打工人也只是打工人！

OpenAI CEO 奥特曼被罢免的事情人尽皆知「虽然，今天又复职了。。」，我们能从中学到什么呢？

CEO 也能被裁，这应该是最近几年被裁名单里面，职级最高的一个人了吧。你再也不用担心给别人说自己被裁有多丢人了，因为 CEO 都会被裁。

另外，我想说，再高级的打工人也只是打工人！

作为打工人，被裁，尤其是这几年，是在是再正常不过的事情。尽管 CEO 的罢免和总裁的辞职对于外界来说可能是一个令人震惊的消息，但在公司内部，这些变动可能只是公司内部的调整和重组的一部分。

因为，再高级的打工人对于整个公司来说，都不是不可替代的。甚至，连公司的老板也不是不可替代的。国内很多大公司都开始这么培养接班人，离开了老板，公司照常运转的公司，才是一个体制健全的公司，这样的公司才能实现基业长青！当然，老板的不同在于，自己能决定自己什么时候离开。

不管是谁，当公司想裁你的时候，你就不再重要，就跟我上次被裁一样，上午还在写需求、改 bug，下午 6 点多通知被裁，第二天就不用来了！虽然这个对比优点不恰当，毕竟我对于公司来说只是一个普通打工人。

一声被裁，马上就得搬着东西走人。

当然，对于奥特曼（Sam Altman）这样的人来说，被裁不像我们大多数人一样需要考虑下一份工作、生活有没有保障、房贷能不能还上等一系列生存问题。

但是这件事也提醒了我们，无论我们的职位有多高级，我们仍然处于职场中不可忽视的变化之中。因此，我们应该时刻保持敏感和警觉，不断更新自己的知识和技能，以应对潜在的职业变动和挑战。

尤其是对于很多大厂中低层管理者而言，放弃了技术，管理能力也不见得有竞争力，毕竟国内大部分管理者都是野路子，没有经过系统的学习与培训。

如果你放弃了技术，之后因为各种原因被裁，那你可能还不如底层员工，他们还能更好的获取下一份工作，毕竟金字塔的底层岗位最多。

那我们能做什么呢？

做一家「一人企业」。什么是「一人企业」，就是把自己当做一个企业、一个产品来运营，来推销，把自己的能力最大化。

什么人适合做「一人企业」呢？借用饭大的话来说：主业稳定、有时间&有乐趣、不躺平&能利他。

所以，我不是在劝你无脑去干，而是满足了这三个条件，你再去干，你也应该是去干。

当自己的老板！

🙈 序言
时光弹指一挥，三十而立的年纪，生活在自己眼里，可以说一地鸡毛…
我通过这篇文章来分享我的经历,在软件行业栉风沐雨的六年…

🚂 茫
16年专科毕业，确切的说是在英雄联盟游戏里毕业，夙兴夜寐的三年，在游戏、吃喝上忙碌，一周7天，五个通宵。就这样，从学校出来，开始做销售，第一份工作，卖鞋油，给别人擦鞋，三月后，去了企业管理咨询公司，卖课，做了半年，兜里比脸还干净，又去做保险，更惨淡，就这样，17年，踏上北漂之路！

🪂 17 入行

17年三月，清楚记得自己报道的日子。七天的基础班，倒数第一名的成绩，差点把我劝退，硬着头皮坚持，扛下来了，我是最笨的人，但也是最努力的人，培训的那半年，每天早八点，晚12的敲代码。只因为，这是自己唯一的退路！半年后，我是班里第二个找到工作的人，入职某外包公司，现在想想自己那时候的选择，还是有一些遗憾。

☠ 18 踩坑最多的一年
拿到第一个月工资的时候，简直不敢相信，激动的和家里人分享。如果不做这个行业，我觉得月薪1万1很可能就是做梦，现在我也能理解到认知那句话了。这算是第一次找到了自信，在工作上有了结果。工作没想象的难，但也非常难受，学习能力方面确实和本科是有差距，纯野路子，没有什么专业基础，为此，18年，加了很多班，通宵达旦的修复很多自己写的Bug，后来，能力得到认可，当然，这是一点一滴的积累，血和泪只有自己知道。

🔥 19 裸辞
18年上半年买了房子，开始背负房贷，又贷款买了车位，这个时候每月贷款就需要还6K，去掉房租，生活费，身无分文，很多个夜晚挣扎着无法入睡，在压力驱使下，不得不找一个薪水更高一些的工作，找工作的过程对我的打击很大，找了将近一个月，才得到一份工作，比原来高2K，14薪，不过是内部员工，这一点是值得欣慰的。在找工作的过程中能明显感觉到社会对专科的歧视很大，因为有很多聊的很好的场面，但都是因为学历失之交臂！
这一年，我成了开发组长，管理四五个人开发，说组长感觉又不太合适，因为自己的开发任务也比较大，就算这样，也还好，因为房贷压力小了，能腾出手忙一点发展的事儿了，这个时候，没有时间谈个人的私事，这一年，工作中忙碌，兼顾生活，贷款，家庭，遇到了很多研发方面的困难，不过都一一克服了，还获得了客户的好评，这儿就不细说了，后续博客会写一部分。

🤡 20 裸辞
这一年，房子交房了，要装修，除了贷款的压力，还得装修房子，在工作上，已顺风顺水，有啥困难都能解决，个人能力团队也都很认可，但薪水成了一个生活发展的阻碍，为此向公司提了一下涨薪，被驳回了。然后我又提出裸辞，公司开始打算涨薪挽留，我拒绝了！然后我又去了外包公司，只为多拿点钱，让压力小一些，把家里的事情处理完。

下图来纪念以下公司的前台！！！

🦧 21 沉淀
裸辞也算非常顺利，半月的时间就接上了，薪资的话18K。工作很轻松，很多任务都能快速高效完成，在这个空闲的时间里，也没有闲着，会读读书，思考一下人生的意义！以下是我读完的书！

读书给我带来了一些动力和精神的慰藉，我也没有想到，一个大学不务正业的人能够静下来看书看到一千多个小时！我读的书没有太多技术方面的，在那个时候最大的作用应该是抵抗那些来自生活得压力和孤独吧。这一年的收获和前几年相比来说，应该是人更平和了，不在那么功利和浮躁，开始看淡一些物质相关的东西！

🧸 22 被解雇
作为一个外包公司，服务的项目做完了，又赶上疫情，被解雇也算是顺理成章的事情，这个时候也没有埋怨，也赶上春节，在家里呆了半个月，就开始投递简历，心里想的是在奋斗一年，找个离家近一点的工作。这个时候的就业环境已经不太乐观了，就学历门槛就很卡了，复习了几天，然后面了三四家吧，就又踏上北漂征程，这次也是外包公司，薪资22K。
三月入职，9月晋升，薪水涨到24.3K，工作上没怎么加过班，工作时间内也都能很出色的完成任务，这一年的总结就是遇到了很多优秀的人，学到了很多方法论，自己更能独立解决问题，在研发层面能够结合业务提出更多的解决方案，的确，这一年做方案的能力很强了。

🎨 23 前篇裸辞
23年五月，通过了PMP项目管理考试，顺利获得证书。作为一个山东人，深受孔孟思想的影响，不孝有三，无后为大！如今也快30岁了，别说结婚，对象的影子也没见！这个压力也慢慢加到了生活了。当我感受到痛苦和不想漂泊的时候，今年五月底，我递交了辞职申请！
离职需要在呆一个月，处理一下自己手头的尾部工作和交接事宜，7月1号，踏上了回家的征程。我很感谢这个公司，让我经历压力没那么大了，房子装修完了，就剩贷款了！
用此图来纪念一下！！！

🎨 23 中篇挣扎
回到家，作为一个驾-照拿了八年没摸过车的人，这个时候买了车，找了个教练，练了练车，差不多了，就开始闭关一月，学习，看视频，属于恶补吧。
8月开始投递简历，本是泰安人，想在家乡谋一份差事，为家乡发展做点贡献，自己钱包也多一点，这个双赢的机会在我面了两三家公司后打消了念头。
开始投递济南的公司，面了一家，项目经理职位，16k,就去工作了，也是一家外包公司。局方公司背景还是不错的！
工作了三个月，我又裸辞了，原因是太累，在提升自己层面上，得到的比较少。因为有贷款的压力，我辞职是做了很大心理建设的！

🔅 23 后篇 展望
辞职后，无缝衔接了一家公司，就是专门做研发，薪资12K，大小周。没有嫌弃，没有抱怨。目前自己的想法很简单，就是打造自己的产品，能够拿得出手一些东西，比如博客，比如项目，比如情感的一些价值！以前的自己好高骛远，现在的自己更脚踏实地，一步一个脚印，把自己的价值分享出来，成就别人，也成就自己！

⚜ 未来我会怎么做

• 做好自己的本职工作-核心


• 少花一点时间放在娱乐上


• 多做一些有价值有产出的事儿 比如博客 比如读书分享 比如研究新项目


• 跟随趋势走 拥抱变化


• 更好的利用技术而不是沉迷技术


• 更平和的心态处事


• 简单的态度生活处世 己所不欲 勿施于人

密码是用户最重要的数据，也是系统最需要保护的数据，我们在登录的时候需要用账号密码请求登录接口，如果用户勾选记住密码，那么下一次登录时，我们需要将账号密码回填到输入框，用户可以直接登录系统。我们分别对这种流程进行说明：

记住密码

在请求登录接口成功后，我们需要判断用户是否勾选记住密码，如果是，则将记住密码状态、账号信息存入本地。
下次登录时，获取本地的记住密码状态，如果为true则获取本地存储的账号信息，将信息回填登录表单。

密码加密

我在这里例举两种加密方式MD5、Base64
MD5：
1、不可逆
2、任意长度的明文字符串，加密后得到的固定长度的加密字符串
3、实质是一种散列表的计算方式

Base64：
1、可逆性
2、可以将图片等二进制文件转换为文本文件
3、可以把非ASCII字符的数据转换成ASCII字符，避免不可见字符
4、实质是 一种编码格式，如同UTF-8

我们这里使用Base64来为密码做加密处理。

npm install --save js-base64

引入Base64

// js中任意位置都可引入

let Base64 = require('js-base64').Base64;

可以通过encode和decode对字符串进行加密和解密

let Base64 = require('js-base64').Base64;



let pwd = Base64.encode('a123456'); 

console.log(pwd);  // YTEyMzQ1Ng==



let pws2 = Base64.decode('YTEyMzQ1Ng==');

console.log(pwd2);  // a123456

到这里我们对密码的简单加密和解密就完成了。
需要注意的是，Base64是可以解密的，所以单纯使用Base64进行加密是不安全的，所以我们要对Base64进行二次加密操作，生成一个随机字符串 + Base64的加密字符。

/***

 * @param {number} num 需要生成多少位随机字符

 * @return {string} 生成的随机字符 

 */

const randomString = (num) => {

  let str = "",

    arr = ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z'];

  let index = null;

  for (let i = 0; i < num; i++) {

    index = Math.round(Math.random() * (arr.length - 1));

    str += arr[index];

  }

  return str;

}

调用randomString函数，根据你传入的数字来生成指定长度的随机字符串，然后将随机字符串与Base64生成的随机字符凭借，完成对密码的二次加密。

let pwd = randomWord(11) + Base64.encode(password); // J8ndUzNIPTtYTEyMzQ1Ng==

到这里就完成了密码加密操作。
在用户登录时，将账号密码存入本地，存入本地方式有很多，例如：Cookies、localStorage、sessionStorage等，关于使用方法网上有很多，这里我们使用微信小程序的存储方式wx.setStorageSyn。

// 我们这里使用微信小程序的存储方式wx.setStorageSync

let account = {

   username: 'test‘,

   password: pwd

 }

wx.setStorageSync('account', account)

二次登录

用户勾选记住密码后，第二次进入系统，直接从本地获取账号密码，对密码进行解密后回填到表单。
先判断用户是否勾选记住密码，然后对密码进行解密。

init() {

   let state = wx.getStorageSync('rememberMe')

   if (state) {

      let account = wx.getStorageSync('account')

      let Base64 = require('js-base64').Base64;

      let pwd = Base64.decode(account.password.slice(11))

      this.setData({

        username: account.username,

        password: pwd

      })

    }

   this.setData({ rememberMe: state })

 }

将解密后的数据回显到表单上，用户就可以直接登录了。

最后

关于记住密码业务，需要保证用户的密码是加密存储，这里用的是微信小程序示例，在web上的流程也是如此，你可以在vue项目中使用本文提到的方法。

如何在前端实现自动或无感化的登录态管理，包括用户注册、登录、接口校验登录态以及实现自动化请求时自动携带访问令牌。我们将探讨两种常见的实现方式：使用 HTTP Cookie 和前端存储和发送访问令牌。

1. 注册和登录

首先，用户需要通过注册和登录来获取访问令牌。

1.1 注册接口

在注册接口中，用户提供必要的注册信息（如用户名和密码），服务器对用户进行验证并创建用户账户。

示例代码（Node.js + Express）：

// 注册接口

app.post('/register', async (req, res) => {

  try {

    const { username, email, password } = req.body;



    // 检查用户名和邮箱是否已被注册

    if (users.some(user => user.username === username)) {

      return res.status(400).json({ error: '用户名已被注册' });

    }



    if (users.some(user => user.email === email)) {

      return res.status(400).json({ error: '邮箱已被注册' });

    }



    // 使用bcrypt对密码进行哈希处理

    const hashedPassword = await bcrypt.hash(password, 10);



    // 创建新用户对象

    const user = {

      id: Date.now().toString(),

      username,

      email,

      password: hashedPassword

    };



    // 将用户信息存储到数据库

    users.push(user);



    // 创建访问令牌

    const token = jwt.sign({ userId: user.id }, 'secretKey');



    res.status(201).json({ message: '注册成功', token });

  } catch (error) {

    res.status(500).json({ error: '注册失败' });

  }

});

1.2 登录接口

在登录接口中，用户提供登录凭据（如用户名和密码），服务器验证凭据的正确性并颁发访问令牌。

示例代码（Node.js + Express）：

app.post('/login', (req, res) => {

  // 获取登录凭据

  const { username, password } = req.body;



  // 在此处进行用户名和密码的验证，如检查用户名是否存在、密码是否匹配等



  // 验证成功，颁发访问令牌

  const token = createAccessToken(username);



  // 将访问令牌写入 Cookie

  res.cookie('token', token, {

    httpOnly: true,

    secure: true, // 仅在 HTTPS 连接时发送 Cookie

    sameSite: 'Strict' // 限制跨站点访问，提高安全性

  });



  // 返回登录成功的响应

  res.status(200).json({ message: '登录成功' });

});

2. 接口校验登录态

在需要校验登录态的受保护接口中，服务器将校验请求中的登录凭据（Cookie 或访问令牌）的有效性。

示例代码（Node.js + Express）：

app.get('/protected', (req, res) => {

  // 从请求的 Cookie 中提取访问令牌

  const token = req.cookies.token;



  // 或从请求头部中提取访问令牌，如果采用前端存储和发送访问令牌方式

  // const token = req.headers.authorization.split(' ')[1]; // 示例代码，需根据实际情况进行解析



  // 检查访问令牌的有效性

  if (!token) {

    return res.status(401).json({ error: '未提供访问令牌' });

  }



  try {

    // 验证访问令牌

    const decoded = verifyAccessToken(token);



    // 在此处进行更详细的用户权限校验等操作



    // 返回受保护资源

    res.status(200).json({ message: '访问受保护资源成功' });

  } catch (error) {

    res.status(401).json({ error: '无效的访问令牌' });

  }

});

3. 自动化登录态管理

要实现自动或无感化的登录态管理，前端需要在每个请求中自动携带访问令牌（Cookie 或请求头部）。

3.1 使用 HTTP Cookie

当使用 HTTP Cookie 时，浏览器会自动将 Cookie 包含在每个请求的头部中，无需手动设置。

示例代码（前端使用 JavaScript）：

// 发送请求时，浏览器自动携带 Cookie

fetch('/protected');

3.2 前端存储和发送访问令牌

当使用前端存储和发送访问令牌时，前端需要在每个请求的头部中手动设置访问令牌。

示例代码（前端使用 JavaScript）：

// 从存储中获取访问令牌

const token = localStorage.getItem('token');



// 设置请求头部

const headers = {

  'Authorization': `Bearer ${token}`

};



// 发送请求时，手动设置请求头部

fetch('/protected', { headers });

在上述示例代码中，我们使用了前端的 localStorage 来存储访问令牌，并在发送请求时手动设置了请求头部的 Authorization 字段。

请注意，无论使用哪种方式，都需要在服务器端进行访问令牌的验证和安全性检查，以确保请求的合法性和保护用户数据的安全。

补充说明：

• createUser：自定义函数，用于创建用户账户并将其保存到数据库或其他持久化存储中。


• createAccessToken：自定义函数，用于创建访问令牌。


• verifyAccessToken：自定义函数，用于验证访问令牌的有效性。

写在最后

文章旨在答疑扫盲，内容简明扼要方便学习了解，请确保在实际应用中采取适当的安全措施来保护用户的登录凭据和敏感数据，保持学习，共勉~

一、原因

某天早上，同事突然对我说我换了小米14pro手机但是安装不了公司的打卡软件，怎么办呀。一时间，我也不知道原因，看到给我发的安装不上的截图陷入了沉思。随即打开在git仓库里找到这个项目，到本地编译打开，开始思考解决办法。

二、解决思路

从网上查询了一番，小米14pro 只支持安装64位的应用，可能是老项目没有做64位的适配。等到项目编译好，打开模块下的build.gradle文件，果然如此，没有做64位的适配。

ndk {

    abiFilters 'armeabi', "x86", "x86_64"

}

针对64位做适配，一般都是适配so库，一般来说，如果你的项目中没有使用到so库或者C，C++代码，都是支持64位的。
这里再做下说明，ABI是Application Binary Interface（应用程序二进制接口）的缩写，在Android中，它指的是Android操作系统与设备硬件供应商提供的库之间的接口。ABI定义了程序各个组件在二进制级别上的交互方式，其中一个重要的方面是处理器使用的指令集架构。Android支持多种ABI以适应具有不同硬件架构的设备。

• ARM（Advanced RISC Machine）：
  
  
  
  • ARM是移动设备中常见的架构。
  
  
  • 变体：armv5、armv7-A、armv8-A（64位）等。
  
  
  
  


• x86：
  
  
  
  • x86是台式机和笔记本电脑中常见的架构。
  
  
  • 变体：x86、x86_64（64位）。
  
  
  
  


• MIPS（Microprocessor without Interlocked Pipeline Stages）：
  
  
  
  • MIPS架构在过去在一些Android设备中被广泛使用，但近年来变得不那么常见。
  
  
  
  

好了，回归到正题，就要针对项目中这种情况处理so库了，因为这个老项目是从其他项目演变过来的，用不到这些so库，所以我的解决办法就是全部删除掉(当然要对项目中的源代码进行处理)，再进行打包处理。
如果你们处理项目中的没有兼容的so库，推荐一个检测插件EasyPrivacy，接入这个就可以方便查看那些so库没有做适配了。
找到没有适配的so库之后，需要找到提供者获取最新兼容的so库或者找到相关官网看是否提供64位的so库。当然代码中还需要进行处理。

ndk {

    abiFilters 'armeabi-v7a', 'arm64-v8a', "x86", "x86_64"

}

这样子打包的时候，在apk中的libs文件夹下就会出现四个对应的文件夹，里面就是对应的so库了。但是这样会增大包的体积。在android{}中配置如下代码，这样子打包之后就会出现四种包对应不同架构的包，这样子包的体积也会减小。

splits {

    abi {

        enable true

        reset()

        include 'armeabi-v7a', 'arm64-v8a', 'x86', 'x86_64' //select ABIs to build APKs for

        universalApk true //generate an additional APK that contains all the ABIs

    }

}

回归正题，当我把打好的包发给同事的时候，同事告诉我还是不行。思来想去，排除64位的问题，那么剩下的只有Android版本的问题了。新出的手机肯定是搭载最新的Android版本，目前Android 14 有什么新变动还没有了解到。

从官网看到，映入眼前的第一条就是这个，检查项目中的代码，发现targetSdkVersion 还是16，怪不得安装不上，至此所有问题解决。

hi 大家好，我是 DHL。就职于美团、快手、小米。

Android 开发者应该深有感触，近几年 Android 每次的更新，对开发者的影响都非常的大，而这次 Android 14 的更新，直接让陪伴我们多年的老朋友 overridePendingTransition 下线。

这篇文章主要想介绍一下我们的老朋友 overridePendingTransition，它陪伴了我们度过了 14 年，如今也完成了它的使命，现已功成身退，这个方法在 Android 14 中被废弃了。

在 2009 年的时候，正式将 overridePendingTransition 添加到 Android Eclair(2.0) 源码中，Android 开发者对它应该有一种熟悉有陌生的感觉吧，我们刚开始学 Android 写 Activity 跳转动画的时候，都接触过这个。

Intent intent = new Intent(B.this, C.class);

startActivity(intent);

overridePendingTransition(R.anim.fade_in, R.anim.fade_out);

这段代码对每个 Android 同学都非常熟悉，而且至今在项目里面，到处都有它的身影。如果我们要为 Antivity 添加进入或者退出动画，那么只需要在 startActivity() 或者 finish() 方法之后立即调用 overridePendingTransition 即可。

14 年后的今天，Android 14 的横空出世 overridePendingTransition 也完成了它的使命，在 Android 14 的源码中正式被废弃了，感兴趣的小伙伴，可以打开 Android 14 的源码看一下。

当得知它都被废弃了，确实感到有些意外，源码中推荐我们使用新方法 overrideActivityTransition 代替 overridePendingTransition。

我还以为是什么更好的方法，结果推荐的方法更加的难用，为了一个虚有其表的功能，废弃了这个 API，还给开发者增加了很大的负担。

按照 Android 官方的解释和源码中的说明，废弃掉这个方法是因为在 Android 14 中引入了新的返回动画，而 overrideActivityTransition 方法不能和它很好的做兼容，所以需要用新的方法去替换。

什么是新的返回动画

比如使用返回手势可以在应用后面显示主屏幕的动画预览。

小伙伴们一起来评评这个功能实用性怎么样，为了这个功能废弃掉我们的老朋友，如果是你，你会这么做吗？另外我们在看看新的 API 的设计。

新的 API 相比于旧 API 多了一个参数 overrideType，一起来看看源码中是如何描述这个参数 overrideType。

For example, if we want to customize the opening transition when launching 

Activity B which gets started from Activity A, we should call this method inside 

onCreate with overrideType = OVERRIDE_TRANSITION_OPEN because the Activity B 

will on top of the task. And if we want to customize the closing transition when

finishing Activity B and back to Activity A, since B is still is above A, we 

should call this method in Activity B with overrideType = OVERRIDE_TRANSITION_CLOSE.

 

If an Activity has called this method, and it also set another activity animation

by Window#setWindowAnimations(int), the system will choose the animation set from 

this method.

翻译一下就是，每次想使用过渡动画，都必须告诉系统 overrideType 使用什么参数，比如当我们从 Activity A 打开 Activity B 时，需要使用参数 overrideType = OVERRIDE_TRANSITION ，当我们从 Activity B 返回到 Activity A 时，需要使用参数 overrideType = OVERRIDE_TRANSITION_CLOSE。

这个参数不是应该由系统自动来处理吗，开发者只需要关心参数 enterAnim 和 exitAnim 即可，这明显没有带来任何好处，还给开发者增加了很多负担。

这只是其中一个改变，Android 开发者应该都深有感触，每次 Android 的更新，都有一堆无用的改变，还给开发者增加了很多负担，每次的适配都是一堆体力活，这样就导致了 App 对 SDK 的版本产生了强烈的依赖。

不过好在有经验的开发者，经历过一次有一次的适配之后，积累了经验，在新的项目中，会对大部分 Android API 进行封装，如果 API 有大的变化，不需要对整个项目进行修改。

全文到这里就结束了，感谢你的阅读，坚持原创不易，欢迎在看、点赞、分享给身边的小伙伴，我会持续分享原创干货！！！

我开了一个云同步编译工具（SyncKit），主要用于本地写代码，同步到远程设备，在远程设备上进行编译，最后将编译的结果同步到本地，代码已经上传到 Github，欢迎前往仓库 hi-dhl/SyncKit 查看。

• 仓库 SyncKit：https://github.com/hi-dhl/SyncKit


• 下载地址：https://github.com/hi-dhl/SyncKit/releases

Vue3 中定义的ref类型的变量，在setup中使用这些变量是需要带上.value才可以访问，但是在template中却可以直接使用。

询其原因，可能会说 Vue 自动进行ref解包了，那具体如何实现的呢？

proxyRefs

Vue3 中有有个方法proxyRefs，这属于底层 API 方法，在官方文档中并没有阐述，但是 Vue 里是可以导出这个方法。

例如：

<script setup>

import { onMounted, proxyRefs, ref } from "vue";



const user = {

  name: "wendZzoo",

  age: ref(18),

};

const _user = proxyRefs(user);



onMounted(() => {

  console.log(_user.name);

  console.log(_user.age);

  console.log(user.age);

});

</script>

上面代码定义了一个普通对象user，其中age属性的值是ref类型。当访问age值的时候，需要通过user.age.value，而使用了proxyRefs，可以直接通过user.age来访问。

这也就是为何template中不用加.value的原因，Vue3 源码中使用proxyRefs方法将setup返回的对象进行处理。

实现proxyRefs

单测

it("proxyRefs", () => {

  const user = {

    name: "jack",

    age: ref(10),

  };

  const proxyUser = proxyRefs(user);



  expect(user.age.value).toBe(10);

  expect(proxyUser.age).toBe(10);



  proxyUser.age = 20;

  expect(proxyUser.age).toBe(20);

  expect(user.age.value).toBe(20);



  proxyUser.age = ref(30);

  expect(proxyUser.age).toBe(30);

  expect(user.age.value).toBe(30);

});

定义一个age属性值为ref类型的普通对象user。proxyRefs方法需要满足：

1. proxyUser直接访问age是可以直接获取到 10 。


2. 当修改proxyUser的age值切这个值不是ref类型时，proxyUser和原数据user都会被修改。


3. age值被修改为ref类型时，proxyUser和user也会都更新。

实现

既然是访问和修改对象内部的属性值，就可以使用Proxy来处理get和set。先来实现get

export function proxyRefs(objectWithRefs) {

  return new Proxy(objectWithRefs, {

    get(target, key) {}

  });

}

需要实现的是proxyUser.age能直接获取到数据，那原数据target[key]是ref类型，只需要将ref.value转成value。

使用unref即可实现，unref的实现参见本专栏上篇文章，文章地址：mp.weixin.qq.com/s/lLkjpK9TG…

get(target, key) {

  return unref(Reflect.get(target, key));

}

实现set

export function proxyRefs(objectWithRefs) {

  return new Proxy(objectWithRefs, {

    get(target, key) {

      return unref(Reflect.get(target, key));

    },

    set(target, key, value) {},

  });

}

从单侧中可以看出，我们是测试了两种情况，一种是修改proxyUser的age为ref类型， 一种是修改成不是ref类型的，但是结果都是同步更新proxyUser和user。那实现上也需要考虑这两种情况，需要判断原数据值是不是ref类型，新赋的值是不是ref类型。

使用isRef可以判断是否为ref类型，isRef的实现参见本专栏上篇文章，文章地址：mp.weixin.qq.com/s/lLkjpK9TG…

set(target, key, value) {

  if (isRef(target[key]) && !isRef(value)) {

    return (target[key].value = value);

  } else {

    return Reflect.set(target, key, value);

  }

}

当原数据值是ref类型且新赋的值不是ref类型，也就是单测中第 1 个情况赋值为 10，将ref类型的原值赋值为value，ref类型值需要.value访问；否则，也就是单测中第 2 个情况，赋值为ref(30)，就不需要额外处理，直接赋值即可。

验证

执行单测yarn test ref

你好，我是刘牌！

人生做事情失败了，拍拍裤子，站起来再试试，那么为啥软件中请求失败了为何就放弃了，而不是不再试试呢！

前言

今天分享一下重试操作，我们知道网络是不可靠的，那么在进行网络请求时，难免会出现请求失败，连接失败等情况，为了保证软件的稳定性和良好的体验，很多时候我们不应该将程序内部出现的问题都抛出给用户，而是应该尽最大可能将软件内部不可抗拒的问题在程序内部处理掉，那么很多时候我们会采取重试操作。

背景和问题

程序产生网络故障或者其他一些故障是无法避免的，可能因为一些原因导致某些服务在短时间或者一段时间断连，可能是服务器负载过高而导致的，也可能是数据库导致故障从而影响服务，也可能是GC过于频繁而导致服务很不稳定等等，总之，导致服务不可用的因素很多很多。

对于程序的出错，如果不属于业务上的异常，不应该抛给用户，比如抛出“无法连接远程服务”，“服务器负载过高”，“数据库异常”这类异常给用户实际上没有任何意义，反而会影响用户用户体验，因为用户并不关心这些，他们也读不懂这些领域词汇，所以应该去避免这些问题。

解决方案

程序发生异常是无法避免的，我们只有采取一些补救措施，在最大程度上提高程序的稳定性和用户体验，对于程序产生的问题，有一些可能只是瞬时的，系统能够很快恢复，有一些需要一定的时间，而有一些需要介入人工，所以需要花费的时间更多，那么就需要根据不同的情况来处理，下面对其进行分类。

取消

当系统中的异常是暂时无法处理的，这时候就应该直接取消任务，因为如果不取消，而是让用户一直等待，那么就会导致用户的操作无法进行下一步，而是一直等待，用户体验就会变得很差，这时候应该给用户友好的提示，提醒他们稍后再进行办理，浪费别人的时间等于谋财害命。

重试

如果请求因为网络原因或者服务短暂的不可用，这种故障时间很短，很快就能恢复，比如一些服务是多实例部署，刚好请求到的那个服务出现网络故障而没能请求成功，如果我们直接返回异常，那么肯定不合适，因为其他服务实例还能提供服务，所以应该对请求进行重试，重试后可能请求到了其他正常的服务，即使请求到了之前的服务，那么可能它已经恢复好了，能够正常提供服务了，这里重试是没有时间间隔的，是不间断地请求，直到请求成功，这种适用于服务很够很快恢复的场景。

间隔重试

间隔重试就是不会一下进行重试，而是隔一个时间段再进行重试，比如一些服务因为过于繁忙导致负载过高而暂时对外提供服务，那么这时候如果不断发起重试，只会导致服务负载更高，我们应该隔个时间段再进行重试，让服务处理堆积的任务，等服务负载降下来再重试，这个时间间隔需要我们进行考量，按照合适的值去设置，比如1s，这完全根据实际场景去衡量。

上面对三种方案进行描述，我们只描述了重试，但是重试次数也是我们要去考量的一个值，如果一个服务20s才恢复，那么我们重试20秒肯定不太合适，不过也要看具体业务，面向客户的话肯定大多客户接受不了，这时候我们应该设置重试次数，比如重试了三次还不能成功，那么久取消任务，而不是一直重试下去。

重试次数也要根据实际情况来设置，如果一直重试，而服务一直无法恢复，那么也会消耗资源，并且用户导致用户请求一直在等待，用户体验不好，设置设置次数过少，那么可能会导致没有足够重试，从而导致浪费了一些重试次数，最后还没有成功，如下，第三次就重试成功，如果设置为两次，那么前两次没有成功就返回，用户还需重新再发起请求。

从上面可以看出，这些设置都没有黄金值，而是需要我们根据业务和不断地测试才能找出合适的值。

怎么重试，参数怎么管理

上面对重试进行一些理论的讲解，那么在实际场景中我们应该如果去做呢，首先要考虑我们的业务中是否真的有必要重试，如果没必要，那么就完全没必要去增加复杂度，如果需要，那么就需要进行良好的设计，保证其优雅和扩展性。

不同的业务有不同的重试逻辑，所以我们需要在不同的地方实现不同的逻辑，但是重试次数和重试时间间隔这些参数应该是需要可动态配置的，比如今天服务负载过高，那么时间间隔可以设置稍微长一点，次数可以设置多一点，然后负载较低的时候，参数可以设置小一点，这些配置信息可以写入配置中心中。

也有一些重试框架供我们使用，比如spring-retry，我们可以借助一些框架来管理我们的重试任务，更方便管理。

总结

以上对重试的一些介绍就完了，我们介绍了重试的场景，重试产生的背景，还有一些解决方案，还对重试的一些管理进行介绍，重试的方案很多，实现方式也有很多，它不是固定的技术，而是一种思想，也是我们在软件设计中应该考虑的一个点，它能提高软件的稳定性和用户体验，但是也需要我们进行考量。

今天的分享就到这里，感谢你的观看，我们下期见！

概述

工作这10多年来，也经常做招聘的工作，面试过的人超过50人次了，而看过的候选人的简历则有几百份了，但是清晰且能突出重点的简历，确实很少遇到。这里基本可以说明一个问题，很多候选人是不太清楚如何写出一份好的简历的。

下面基于简历中的项目经历，重点铺开说一下。在社招中，项目经历面试官重点考察的地方。

写项目经历需要注意的地方

项目经历是介绍你实战经历的地方，同时也能反映你对已掌握的技能的使用情况。对于应聘偏技术类的岗位来说，这块非常的重要。

下面会以支付中心作为例子进行阐述。

• 
  

  项目背景，也即是你一定要非常清楚启动这个项目的缘由是啥。如果这个都说不清楚的话，那说明，你真的就是埋头干活，偏执行的角色。对项目并没有一个整体的认识。就算你只是这个项目的普通参与者，也需要主动的去了解和理解该项目立项的原因。有个注意的地方是，项目背景的文字描述不要太长，一两句就可以了。比如说：当前支付中心耦合在订单系统中，为了提升支付模块的稳定性、维护性、性能和扩展性，需要将支付模块独立出来，统一为其他内部系统提供支付能力;

  
  


• 
  

  项目功能介绍，介绍一下这个项目能做什么，有什么核心模块，需要应付什么量级的流量。以支付中心为例子：为内部的订单系统提供支付能力，对内提供了微信、支付宝、抖音、海外、信用卡、钱包、礼品卡以及组合支付的支付、回调、退款、查询、业务对账等能力。平时需要应付每秒1万的支付请求。

  
  


• 
  

  技术架构设计，这里考察的是技术选型的严谨性和模块设计的合理性。如果项目用到了RabbitMQ、Redis、Kafka等一些技术，你自己心里一定有个底，就是当时为什么选用这些技术，是经过深思熟虑的吗？是经过了很多轮的技术栈对比后决定使用的吗。也即是技术选型是一个严谨的论证的一个过程。而设计这块，则要说清楚模块划分的缘由以及解决方案。还是以支付中心为例子：通过支付网关，对外提供统一的接口，而内部则通过支付路由模块，进行具体的支付方式路由，并把单独的支付方式，以物理单元进行隔离，避免各种支付方式在出故障时，相互影响。为了应付高频的支付动作，采用数据库分库的方式缓解写的压力。

  
  


• 
  

  我负责的模块，如果你参与的项目是部门核心项目，但是自己参与的模块确是边缘模块或者只是参与了很小的一部分，虽然你也能在这个项目里，得到成长。但是那是称不上个人亮点的。因为面试官会更倾向于：你为这个项目做了什么贡献，因为你，项目有了什么好的改变和突破性进展。因此，做项目的时候，不妨跟自己的领导多反馈一下，希望能独立主导一些重要的模块。如果领导觉得当前的你还无法独立hold住重要的模块，你也不要气馁，平时多多提升自己，争取后续能主导一些重要模块。这个真的很重要，为了将来的自己，你必须得这么做。在做项目的时候，如果你长期一直起着螺丝钉的作用的话，对你极其不利，甚至可以说，你是在浪费时间。

  
  


• 
  

  难点和踩过的坑，难点也即是亮点。在你负责的模块里，具体的难点是什么，你是通过什么方案解决的。而解决的过程中，又遇到什么大坑？怎么优化的。这个其实是一种引导，把面试官引入到你自己比较熟悉又印象深刻的领域，如果你准备充分的话，是能给面试官一个好的印象的，是能加分的。同时能解决掉难点，对自身成长也是有利的，且还能说明的你韧性不错，有追求。

  
  


• 
  

  取得的成效，不能只是重视过程，而不重视结果，这是不可取的。你需要用结果和数据体现你的价值。比如说，支付中心上线后，你负责的业务模块，慢调用和慢SQL消失了，接口响应速度提升了10倍，上线半年，无任何大故障。等等。

  
  

项目经历写几个合适？

如果按照上面的的方式来书写项目的话，那每个项目的文字描述是不短的，一个项目的描述就大概要占用半页了。因此，简历里的项目不能太多，2到3个就可以了。项目主要在精不在多，把自己负责比较多的且能作为自己的一个亮点的核心项目，说清楚道明白，更为重要。

现在的你应该做什么？

赶紧好好总结一些当前和之前做过的项目，按照上面列的方式，好好梳理和思考一下，提炼一些重要的内容出来。争取能作为自己履历的亮点。如果你发现到目前为止，还没有能为自己带来竞争力的项目，那赶紧好好反思一下，赶紧争取去做。

小结

如果你不是什么名人或者知名大佬，学历和履历也一般般，那么你只能通过曾经做过好的项目来增强自己的竞争力了。HR也会通过你的项目经历来了解你的能力。项目经历一定要真实，要突出亮点和难点，并说清楚自己在项目起到什么作用。

1 分层疑问

无论DDD还是MVC模式构建项目，势必涉及到工程结构的分层，每一层由于定位不同，所以访问的对象也不同，那么对象在每一层传递时就会涉及到对象的转换，这时有人会产生以下疑问：

• 对象种类多，增加理解成本


• 对象之间转换，增加代码成本


• 编写代码时有时不同层对象几乎一样

即使有这样的疑问，我也认为分层是必要的，所以本文我们尝试回答上述疑问。

2 通用分层模型

两种通用模型是MVC和DDD，我之前在文章《DDD理论建模与实现全流程》也详细讨论DDD建模和落地全流程，本文只涉及对象的讨论，所以会对模型有所简化。

2.1 模型分类

• 数据对象：DO（data object）


• 业务对象：BO（business object）


• 视图对象：VO（view object）


• 数据传输对象：DTO（data transfer object）


• 领域对象：DMO（domain object）


• 聚合对象：AGG（aggregation）

2.2 MVC

MVC模型总体分为三层：

• 持久层（persistence）


• 业务层（business）


• 表现层（presentation/client）

每一层使用对象：

• 持久层
  
  
  
  • 输入对象：DO
  
  
  • 输出对象：DO
  
  
  
  


• 业务层
  
  
  
  • 输入对象：BO
  
  
  • 输出对象：BO
  
  
  
  


• 表现层
  
  
  
  • 输入对象：VO/DTO
  
  
  • 输出对象：VO/DTO
  
  
  
  

2.3 DDD

DDD模型总体分为四层：

• 基础设施层（infrastructure）


• 领域层（domain）


• 应用层（application）


• 外部访问层（presentation/client）

每一层使用对象：

• 基础设施层
  
  
  
  • 输入对象：DO
  
  
  • 输出对象：DO
  
  
  
  


• 领域层
  
  
  
  • 输入对象：DMO
  
  
  • 输出对象：DMO
  
  
  
  


• 应用层
  
  
  
  • 输入对象：AGG
  
  
  • 输出对象：DTO
  
  
  
  


• 外部访问层
  
  
  
  • 输入对象：VO/DTO
  
  
  • 输出对象：VO/DTO
  
  
  
  

3 生活实例

这些对象看起来比较复杂，理解成本很高，好像是为了分层硬造出来的概念。其实不然，这些对象在生活中司空见惯，只不过大家并没有觉察。我们设想有一家三口，小明、小明爸爸和小明妈妈，看看这些对象是怎么应用在生活中的。

3.1 MVC

3.1.1 数据对象（DO）

数据对象作用是直接持久化至数据库，是最本质的一种对象，这就像小明在卧室中穿着背心睡觉，这接近于人最本质的一种状态，小明此时是一种数据对象。

3.1.2 业务对象（BO）

小明起床走出卧室，这时小明就不仅仅是他自己了，他还多了很多身份，例如儿子、学生、足球队队员，不同身份输入和输出信息是不一样的。作为儿子要回应家长的要求，作为学生要回应老师的要求，作为足球队员要回应教练的要求。作为小明从数据对象，在不同的身份场景中变成了不同的业务对象。

3.1.3 视图对象/数据传输对象（VO/DTO）

小明吃完早饭准备去上学，但是嘴角粘上了饭粒，出门前要把饭粒擦掉。数据传输对象需要注意简洁性和安全新，最重要的是只携带必要信息，而不应该携带不必须要信息，所以此时小明变成了视图对象。

3.2 DDD

3.2.1 领域对象（DMO）

领域对象要做到领域完备，从本质上来说与业务对象相同，但是通常使用充血模型，业务对象通常使用贫血模型。

3.2.2 聚合对象（AGG）

学校要开家长会要求小明、小明妈妈和小明爸爸全部参加，其中小明负责大扫除，小明妈妈负责出黑板报，小明爸爸负责教小朋友们踢足球。此时学校和家长联系时是以家庭为单位的，家庭就是聚合对象。

4 一体多面

通过上述实例我们看到，即使是同一个自然人，在不同的场景下也有不同的身份，不同的身份对他的要求是不同的，输入和输出也是不同的。这就是一体多面。

同理对于同一个对象，即使其在数据库只有一条数据，但是由于场景的不同，输入和输出也是不同的，所以有了各种看似复杂的对象。我们再回看上面三个问题，可以尝试给出本文的答案：

对象种类多，增加理解成本：这是必须要付出的成本，小明不能嘴角挂着饭粒去上学

对象之间转换，增加代码成本：这是必须要付出的成本，不同角色切换时必须要付出切换成本，小明不能用回应足球队教练的输出回应老师或者老师，这是截然不同的角色

编写代码时有时不同层对象属性几乎一样：小明作为一个自然人，他自身固有特性也是相同的，所以表现在对象上是很多属性是一致的。但是不同的角色是有不同要求的，所以为了一些细微的差别，也是要新增对象的，这是必要的代价

描述

现在大部分企业所使用的MySQL数据库相信都已经从5.7升级到了8，性能也得到了大幅度的提升

MySQL 8.0对于数据管理带来了很多改变，使得MySQL成为一个更强大、更灵活和更易于使用的数据库管理系统。

1. 
   

   MySQL 8.0提供了更好的JSON支持，包括更快的JSON函数和表达式，以及新的JSON数据类型和索引。

   
   


2. 
   

   MySQL 8.0引入了窗口函数，这些函数可以用来计算分析函数的结果并根据指定的排序规则进行分组。

   
   


3. 
   

   MySQL 8.0提供了更好的空间数据支持，包括新的空间数据类型和函数，例如ST_Distance_Sphere函数，它可以计算两个点之间的球面距离。

   
   


4. 
   

   MySQL 8.0提供了更好的安全性，包括更安全的默认配置、更严格的密码策略、更多的SSL/TLS选项等。

   
   


5. 
   

   MySQL 8.0提供了更好的性能，包括新的索引算法、更好的查询优化器、更好的并发控制等。

   
   

MySQL5.7

查看版本号

查看编码格式

从结果可以看出，MySQL8默认字符编码为utf8mb4

查看排序规则

从结果可以看出，MySQL8默认排序规则为utf8mb4_general_ci

总结

MySQL5.7 默认字符编码是utf8mb4，默认排序规则是utf8mb4_general_ci

MySQL8

查看版本号

查看编码格式

“character_set_client” 表示客户端字符集

“character_set_connection” 表示连接字符集

“character_set_server” 表示服务器字符集

从结果可以看出，MySQL8默认字符编码为utf8mb4

查看排序规则

从结果可以看出，MySQL8默认排序规则为utf8mb4_0900_ai_ci

总结

MySQL8 默认字符编码是utf8mb4，默认排序规则是utf8mb4_0900_ai_ci

utf8 与 utf8mb4 区别

1. 
   

   存储字符范围不同：

   
   
   
   
   • utf8 编码最多能存储 3 个字节的 Unicode 字符，支持的 Unicode 范围较窄，无法存储一些辅助平面字符（如 emoji 表情）。
   
   
   • utf8mb4 编码最多能存储 4 个字节的 Unicode 字符，支持更广泛的 Unicode 范围，包括了 utf8 所不支持的一些特殊字符和 emoji 表情等。
   
   
   
   


2. 
   

   存储空间不同：

   
   
   
   
   • utf8 编码时，字符长度可以是最多 3 个字节。
   
   
   • utf8mb4 编码时，字符长度可以是最多 4 个字节。
   
   
   
   


3. 
   

   对于存储 Emoji 和特殊字符的支持：

   
   
   
   
   • utf8mb4 能够存储和处理来自辅助平面的字符，包括emoji表情，这些字符需要使用 4 个字节来编码。而 utf8 不支持这些字符。
   
   
   
   

utf8mb4_general_ci 与 utf8mb4_0900_ai_ci 区别

1. 
   

   utf8mb4_general_ci：

   
   
   
   
   • 这是MySQL中较为通用的字符集和校对规则。
   
   
   • utf8mb4 是一种用于存储 Unicode 字符的编码方式，支持更广泛的字符范围，包括 emoji 等。
   
   
   • general_ci 是一种排序规则，对字符进行比较和排序时不区分大小写，对于大多数情况来说是足够通用的。
   
   
   
   


2. 
   

   utf8mb4_0900_ai_ci：

   
   
   
   
   • 这是MySQL 8.0.0 版本后引入的校对规则。
   
   
   • 0900 表示MySQL 8.0.0 版本。
   
   
   • ai_ci 是指采用 accent-insensitive 方式，即对于一些有重音符号的字符，排序时会忽略重音的存在。
   
   
   
   

主要区别在于排序规则的不同。utf8mb4_0900_ai_ci 在排序时会对重音符号进行忽略，所以某些含有重音符号的字符在排序时可能会与 utf8mb4_general_ci 有所不同。

索引不生效问题

表结构

CREATE TABLE `user` (

 `id` bigint NOT NULL COMMENT '主键',

 `username` varchar(50) NOT NULL DEFAULT '' COMMENT '名称',

 `password` varchar(50) NOT NULL DEFAULT '' COMMENT '密码',

 `store_id` bigint NOT NULL DEFAULT 0 COMMENT '门店id',

 `is_delete` int NOT NULL DEFAULT '0' COMMENT '是否删除',

 PRIMARY KEY (`id`),

 KEY `idx_store_id` (`store_id`)

) ENGINE=InnoDB CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='用户表';





CREATE TABLE `user_role` (

 `id` bigint NOT NULL COMMENT '主键',

 `user_id` bigint NOT NULL DEFAULT 0 COMMENT '用户id',

 `role_id` bigint NOT NULL DEFAULT 0 COMMENT '角色id',

 `is_delete` int NOT NULL DEFAULT '0' COMMENT '是否删除',

 PRIMARY KEY (`id`),

 KEY `idx_user_id` (`user_id`),

 KEY `idx_role_id` (`role_id`)

) ENGINE=InnoDB CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='用户角色关系表';

查询

SELECT DISTINCT

	t1.id,

	t1.username 

FROM

	user t1

	JOIN user_role t2 ON t2.user_id = t1.id 

WHERE

	t1.is_delete = 0

	and t2.is_delete = 0

	and t1.store_id = 2 

	AND t2.role_id NOT IN (9, 6)

执行计划

通过执行计划发现明明字段上加了索引，为什么索引没有生效

explain format = tree 命令

问题找到了

(convert(t2.user_id using utf8mb4) = t1.id))

在回头看看表结构

为什么会不一致呢？

mysql5.7 升级之前 两个表都是 CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci

mysql5.7 升级到 mysql8 后，user_role 更新过表结构

修改表排序规则

ALTER TABLE user CHARACTER COLLATE = utf8mb4_0900_ai_ci;

再次查看执行计划

总结

开发一般都不太注意表结构的字符编码和排序规则，数据库升级一定要先统一字符编码和排序规则

查询的问题

由于先发布应用，后执行的脚步，没有通知测试所以没有生产验证，导致第二天一大早疯狂报警

一看就是两个表字段排序规则不一致导致的

只能修改表结构排序规则 快速解决

总结

升级MySQL是一个常见的操作，但在升级过程中可能会遇到各种问题。本文主要介绍排序规则不一致导致的问题，希望能对大家在升级MySQL时有所帮助。在进行任何升级操作之前，务必备份数据库，以防数据丢失。同时，建议定期对数据库进行性能优化，以提高系统的高可用。

最近在线看直播年会。有一个点赞的按钮，点击点赞按钮喷射表情，表情在屏幕上向上浮动之后消失。觉得这个效果挺具有代表性，所以想实现一下。

找了一个别人的效果图

就来实现这个效果。

写一个点赞按钮

  <style>

    .like-box {

      width: 48px;

      height: 48px;

      border-radius: 50%;

      background-color: #ddd;

      position: relative;

      top: 360px;

      display: flex;

      align-items: center;

      justify-content: center;

      left: 300px;

      cursor: pointer;

    }



    .like-box i {

      font-size: 25px;

    }

  </style>

  <div class="like-box" id="like-box">

    <i class="icon-dianzan iconfont"></i>

  </div>

其中中间的图标用的是阿里巴巴矢量图标库的图标字体。

动态创建表情

动态表情用一个div表示。背景是表情图片。有6个备选表情

div样式

 .like-box div {

      position: absolute;

      width: 48px;

      height: 48px;

      background-image: url("./public/images/bg1.png");

      background-size: cover;

      z-index: -1;

    }

使用js创建表情图标，并插入到点赞div中

const likeBox = document.getElementById('like-box') // id为like-box

const createFace = function () {

    const div = document.createElement('div')

    return div

}



likeBox.addEventListener('click', function () {

    const face = createFace()

    likeBox.appendChild(face)

})

实现表情动画效果

从最终效果图中可以看出，最终效果是由多个表情组成，更准确的说是由多个不同运动轨迹表情实现。所以关键是表情的轨迹实现。

而在运动轨迹过程中，有大小缩放效果、有淡出效果。所以至少有三个animation。

实现缩放效果

使用animation实现缩放效果，添加animation样式

    @keyframes scale {

      0% {

        transform: scale(0.3);

      }



      100% {

        transform: scale(1.2);

      }

    }

当动态创建表情div时，将缩放效果添加到div上，添加后效果

实现淡出效果

使用animation实现淡出效果，添加animation样式

    @keyframes opacity {

      0% {

        top: 0;

      }



      10% {

        top: -10px;

      }



      75% {

        opacity: 1;

        top: -180px;



      }



      100% {

        top: -200px;

        opacity: 0;

      }

    }

当动态创建表情div时，将淡出效果添加到div上，添加后具体效果

实现不同轨迹效果

单一轨迹

创建单一轨迹样式效果

 @keyframes swing_1 {

      0% {}



      25% {

        left: 0;

      }



      50% {

        left: 8px;

      }



      75% {

        left: -15px;

      }



      100% {

        left: 15px;

      }

    }

当动态创建表情div时，将单一轨迹样式效果添加到div上，添加后具体效果

多轨迹

多轨迹有点麻烦，但是也不是很麻烦。具体思路是创建多个轨迹样式，然后在动态创建表情时给表情div随机添加各种轨迹样式，添加后具体效果

最终js代码

const likeBox = document.getElementById('like-box')



const createFace = function () {

    // 随机表情

    const face = Math.floor(Math.random() * 6) + 1;

    // 随机轨迹

    const trajectory = Math.floor(Math.random() * 11) + 1; // bl1~bl11



    const div = document.createElement('div')



    div.className = `face${face} trajectory${trajectory}`;

    return div

}





likeBox.addEventListener('click', function () {

    const face = createFace()

    likeBox.appendChild(face)

})

移除产生的表情div

为了避免一直添加div，乃至最后降低动画性能，需要等animation结束后移除动画div

const likeBox = document.getElementById('like-box')



const createFace = function () {

    const face = Math.floor(Math.random() * 6) + 1;

    const trajectory = Math.floor(Math.random() * 11) + 1; // bl1~bl11



    const div = document.createElement('div')



    div.className = `face${face} trajectory${trajectory}`;

    // 移除div

    div.addEventListener("animationend", () => {

        if(likeBox.contains(div)){

            likeBox.removeChild(div)

        }

    });

    return div

}



likeBox.addEventListener('click', function () {

    const face = createFace()

    likeBox.appendChild(face)

})

总结

所有的效果实现都通过css的animation实现。实际还可以使用canvas实现。关键是实现的思路。

核心思路：使用css的animation实现，基于对动画效果的拆分；拆出单一效果，之后所有效果同时发挥作用。

最近想到一件事，初高中学到的数学知识应该可以应用在开发中。有些前端效果实际就是数学知识的一种应用。更准确的说是高中数学函数图形以及几何图形那块，这两块都有曲线的函数或者方程表示。

如果要实现的效果是曲线或者轨迹的话，完全可以考虑它的坐标关系是不是数学中学到的。进而知道关系，进而开发出效果。

我一直想把中学和大学的知识应用，我想上面就是应用的一个点。

代码地址：github.com/zhensg123/r…

(本文完)

参考文章

H5 直播的疯狂点赞动画是如何实现的？(附完整源码)

工作满意度是幸福感的重要预测指标。对于工作有多满意，很大程度上也决定了对人生有多满意。有研究表明，在幸福感的所有预测指标中，工作仅次于婚姻。盖洛普公司主导了一次针对全球十几万人的调查研究，包括了从原始部落到现代文明的不同工作形态，结果表明，不管在地球的哪个角落，「一份有意义的工作可以显著地预测幸福感。」

在希腊神话里有这样一个故事，一个叫西西弗斯的国王，他自作聪明，戏弄了死神和冥王等众神。众神把他抓到阴间，给他一个恶劣的惩罚，他需要每天把一块大石头从山脚推到山顶，每当他正好要到达山顶的时候，大石就会滑落回山脚，西西弗斯只有顶着烈日，日复一日地将石头从推到山顶，如此循环往复。「西西弗斯这个故事代表了没有意义工作的极致，也是一项非常残酷的惩罚。」

著名的富士康连续自杀事件，在工厂车间，几百个工人，日复一日地做着重复而简单的工作，不就是西西弗斯的神话在现实中发生？在无休止的加班和重复劳动中，不知道工作的意义是什么，如此麻木而紧张的工作状态，导致了最终的悲剧。

上班如上坟：最糟糕的工作状态

现在有一句话描述的特别贴切——“上班如上坟”，这句话非常形象地表达出了最糟糕的工作状态。

马云曾经说过一个深受大家认同的观点，一个人离职，原因无外乎两点：

• 钱没给够


• 受委屈了

其实真实发生的离职情况来看，第二点的因素占绝大多数，当我们工作中遇到了很多不快乐的事情时，就会触发大脑的情绪思维，从而产生了离职的念头。

在互联网行业，大多数产生这种“上班如上坟”的状态是以下几种情况：

• 「内卷」，一种是**「工作时长」上的卷，一天有做不完的工作，干不完的活，每天工作可能超过12个小时，甚至没有周末，类似于富士康的模式，简单低效且麻木，没有基本的休息时间保障；另一种是「内心」上的卷，可能是过高的要求，无法完成的目标，带来的无尽压力，产生了「绝望感和窒息感」**，长期在这个状态下非常容易出现心理问题。


• 「得不到认可」，一直被领导PUA，这会导致一种无论如何努力都不被认可的无力感，产生非常大的精神内耗，会怀疑自己和否定自己，有很大的负面情绪产生。

一旦达到“上班如上坟”这个状态，实际上已经是非常糟糕的情况了。往往这种状态下，大家会选择摆烂，消极对待工作，逃避，有离职冲动等等，工作和生活都会受到极大影响。

金钱不过老六

在正式工作之前，我们对于薪资有无比强烈的渴求，那时的offer选择真的很简单，哪一家给的钱多就去。在工作之后，很多公司挖人的手段也是以高薪涨幅为第一吸引力，在环境比较好的时候，往往跳槽才是获得更高薪酬的最有效手段。

大多数打工人面临的是生存问题，大城市高额的生活成本，房贷车贷子女教育，是压在每个人心头的大山，尤其在深圳这样的地方，无数人在这个地方有着共同的目标——搞钱，金钱的重要性不言而喻。

但是，我们是否过于重视金钱而忽视了其他？在赫兹伯格的研究中，「金钱排在成就、认可、工作本身、责任、晋升之后」，在第6位，「前5项因素才是真正驱动员工的动力所在」。

在赫兹伯格提出的著名的双因素理论中，金钱属于保健因素，它是必要的保障，只会让员工产生不满的情绪，而无法得到满意的情绪：

image

实际上，我们在跳槽拿到高薪的最快乐的阶段，是在拿到Offer后的那段时间，以及拿到第一个月的薪水的时候，其他的时间的情绪感受都与金钱本身关系不大了。

物质资源永远是有限的，在大幅度提高的情况下才能产生激励的效果。钱并不是万能的，从员工的角度来说，个人的身心健康应该是更重要的东西。

快乐工作的价值

谷歌在早些时候平均年薪仅在美国科技公司中排12位，但是却获得了最佳雇主排行榜的榜首。谷歌对员工开出了丰厚的条件：

• 免费用餐


• 班车接送


• 股票期权


• 发放IPad


• 社交活动，比如瑜伽、葡萄酒、足球比赛、露天烧烤、吉他等


• 健身房、免费按摩、免费理发、体能训练等等

这些福利并非浪费，盖洛普指出，员工满意度提高5%，连带提升11.9%的外部客户满意度，同时企业效益也会提升2.5%。

后来这一类的福利策略也被其他公司纷纷效仿。快乐工作的第一步是需要有一个舒心的环境，让大家能够对公司满意，才能更加自发地了解探寻工作的意义。

Denison Consulting公司调查显示，员工心情不愉快的企业年销售额仅增长了0.1%，而心情愉快的同期增长15.1%。企业若能将员工满意度提高20%，便可将财务绩效提升42%。

快乐工作，会让企业产率、质量、销售额、客户满意度、创新性、适应性都有一定的提升，降低员工缺勤率、跳槽率、紧张与疲劳感，这是雇主与雇员的双赢策略。

「我们需要追求的终极目标是，让工作成为一种享受。」

管理是控制还是服务

相信绝大多数的管理者认为管理是服务，但是在实际行为中却不一定，比如：

• 不应该对员工说“谢谢”，这种假客气只会产生距离感？


• 不需要征询员工意见，我对结果要负责应该我说了算？


• 成功来自于能力和实力，与其他因素无关？


• 无法容忍下属的挑战，有悖于合作的伦理并产生糟糕的示范效应？


• 每个人都得为自己的情绪负责，管理还有更重要的事情要做？


• 保持开放的沟通固然重要，但是很容易让员工自以为是，需要保持距离？


• 比起目标、绩效、团队的前途，友善和蔼的风格只会让权威旁落？


• 每天压力这么大，谁能有时间去培养员工提升他们的能力呢？


• 授权并不靠谱，现在这个环境，更适合各司其职，稳稳当当？


• 说实话，所谓的愿景和将来就是忽悠，我如何与员工谈论自己都不相信的未来？

这些问题能够帮助我们反思，自己究竟是在控制还是在服务，作为管理者，一个细微的举动可能在员工看来就会引起不小的情绪波动。

我们冷漠吗

工作氛围的糟糕，上班如上坟，十有八九跟管理者有很大的关系，更多的时候，冷漠与氛围直接相关，比如：

• 同事见面都会热切的打招呼吗？


• 同事们互相信任，困惑、焦虑和感受都能相互分享吗？


• 大家在各种沟通场合中能够畅所欲言吗？是否藏着掖着？


• 吃饭时会形成若干个自发团体吗？有人形单影只吗？


• 下班之后同事还有可能有聚会吗？


• 团队稳定性很高吗？团建大家都积极参与吗？


• 新人容易融入吗？会有计划培养新人吗？


• 奖励时常发生吗？无论是物质上的还是精神上的


• 大家认可自己的工作是有价值的吗？


• 领导的压力和情绪会透传给下属吗？


• 领导愿意和员工单独交流吗？


• 领导与员工相处舒服吗？


• 领导善于夸奖人吗？

这些问题有助于判别团队的氛围如何，一个好的工作氛围，才能享受工作，激发更大的动力，这样的团队才能创造更大的价值。

内心驱动模式

从个人内心的动力上，大概可以分为三类驱动模式：

恐惧驱动

• 害怕最亲近的人离开？


• 害怕失去工作，失去工作能力？


• 害怕失去健康？


• 害怕不成功，窝窝囊囊过一辈子？


• 害怕资产缩水，辛辛苦苦的钱贬值？


• 害怕晚年凄凉，孤苦伶仃？


• 害怕被领导同事瞧不起，不被认可？


• 害怕家庭解体？


• 害怕死亡？

责任驱动

• 要对工作负责，我做事是有品质的


• 要对同事负责，不能给别人带来麻烦


• 要对领导负责，不能辜负他的信任


• 要对父母负责，懂得报恩


• 要对那一位负责，已经是利益共同体


• 要对孩子负责，作好的榜样


• 要对银行负责，需要还贷


• 要对朋友负责，有真心的朋友不容易


• 要对国家负责，民族的脊梁


• 要对自己负责，希望回首往事不留遗憾

梦想驱动

• 我想赚很多钱，可以衣食无忧想要什么就有什么


• 我想成为大家都喜欢的人，因为我而快乐


• 我想周游世界，看看外面的风景


• 我想健康长寿，尽量活得久一点


• 我想每天能够幸福满足，活出质感


• 我想好日子延续下去，不要大起大落要平安喜乐


• 我想大家都能够快快乐乐在一起


• 我想做自己喜欢的事，可以不要为了钱而工作


• 我想帮助更多需要帮助的人，人本来应该善良

在工作上，「责任驱动、梦想驱动占据主导地位的人是非常稀缺的」，作为一个管理者，如果因为自己，把这类人变成了行尸走肉，只剩下恐惧驱动，真的是最大的过错，令人发指，天理难容！

个人感悟

上班如上坟这种状态，十有八九都是跟管理者有很大的关系。在目前互联网增速放缓的今天，物质金钱上已经无法带来激励的时候，这类问题尤为突出。若工作氛围很糟糕，更是雪上加霜，团队没有凝聚力，无法获得更高的产出，导致更多的裁员，形成恶性循环。

在目前的大环境下，企业面对生存压力，沉重的指标压在管理者的身上，更需要管理者能够创造快乐的工作氛围，即使在互联网这个不得不加班的大环境下，也能够让工作成为一种享受，不要再让员工产生额外的内耗，驱动团队创造更大的价值，共克时艰。

时间线

2020 年 9 月 10 日，华为召开了开发者大会，正式推出了 HarmonyOS 2.0 系统，并宣布为开发者提供完整分布式设备与应用开发生态。

2023年10月17日，小米集团首席执行官雷军正式公布了这款操作系统，并称该系统将逐步接替之前小米开发的MIUI系统，成为小米智能硬件互联生态的统一计算平台。首款搭载HyperOS的智能手机为小米14系列手机。10月20日、23日，MIUI的微信、微博等公众平台账号陆续将MIUI改为其中文名“小米澎湃OS”。

2023年11月3日消息，在此前举行的 2023 vivo 开发者大会上，vivo 已经宣布首款搭载蓝河操作系统的设备将是 vivo WATCH 3 手表。vivo 副总裁周围在接受媒体采访时明确表示，vivo 自研蓝河操作系统不兼容安卓应用。

以上这几年国内著名手机厂商公布自研操作系统的时间线。笔者最近比较对国内操作系统的发展动向比较感兴趣，所以就开始了解收集这方面的信息，想通过这篇文章帮我看清操作系统发展脉络或者说补充一些相关认知盲区。

先用一张图厘清操作系统发展脉络

大家应该都知道华为、小米和Vivo分别是国内三个著名的Android手机厂商。国内移动互联网快速的发展，也是得益于Android的开放性，国内手机厂商基本都是基于ASOP(Android Open Source Project)魔改源码逐渐形成自己的定制操作系统，比如HarmonyOS、小米的MIUI和Vivo的OriginOS。如下图所示：

iOS 是由苹果开发的移动操作系统。苹果最早于2007年1月9日的Macworld大会上公布这个系统，最初是设计给iPhone使用的，后来陆续套用到iPod touch、iPad上。iOS与苹果的macOS操作系统一样，属于类Unix的商业操作系统。苹果凭借它极具竞争力的软硬件创新产品，妥妥是一方巨头，跟Android开放生态不一样，苹果的操作系统并不开源。

但从2023年国内手机厂商公布的操作系统来看，从曾经套壳Android逐渐演变成去安卓化趋势。那为啥会有这种趋势发生，或者说这真的是未来操作系统发展趋势吗，国内厂商可能会面临什么样的挑战？这个问题的答案我们需要时间去验证，我们只能先做些畅想。

国内手机厂商是如何发展起来的？

国内手机厂商的发展主要经历了以下几个阶段：

1. 初步阶段（2000-2003年）：在这个阶段，国内手机市场刚刚起步，消费者对手机的需求逐渐增加。一些国内厂商开始生产手机，主要以低端和中端产品为主，如联想、TCL等。


2. 品牌竞争阶段（2004-2006年）：随着消费者对手机品牌的关注度增加，一些知名品牌开始崛起，如华为、中兴、酷派等。这些品牌通过自主研发、产品创新和技术积累，逐渐在中高端市场占据一席之地。


3. 智能手机时代（2007-2010年）：智能手机的兴起，为国产手机厂商提供了新的发展机遇。在这个阶段，小米、OPPO、vivo等厂商迅速崛起，通过高性价比、良好的用户体验和市场营销策略，逐渐在国内市场占据重要地位。


4. 全球化竞争（2011年至今）：随着国内手机市场的逐渐饱和，国产手机厂商开始将目光投向海外市场，如印度、东南亚等新兴市场。此外，厂商也在积极布局5G、物联网等新兴领域，以寻求新的增长点。

Android系统最早于2008年9月23日正式发布。进入中国市场的时间则是在2009年左右，随着第一款搭载Android系统的手机HTC Dream（在中国市场称为G1）的上市，Android系统开始在中国市场逐渐普及。

华为、小米和vivo这些手机厂商开始使用Android系统的时间如下：

1. 华为：华为早在2009年就推出了第一款搭载Android系统的智能手机——华为U8220。此后，华为逐步发展成为全球领先的手机厂商之一，并在Android系统上推出了自家的EMUI（Emotion UI）用户界面。


2. 小米：小米成立于2010年4月，同年8月推出了基于Android系统的MIUI定制系统。2011年8月，小米发布了第一款搭载Android系统的手机——小米1。凭借高性价比和出色的用户体验，小米迅速崛起成为国内外知名的手机品牌。


3. vivo：vivo成立于2009年，2011年推出了第一款搭载Android系统的智能手机——vivo X1。随后，vivo在Android系统上推出了自家的Funtouch OS用户界面，并逐步发展成为市场份额较高的手机厂商之一。

从上面我们回顾了下国内手机厂商的发展历史，可以说没有Android系统进入国内市场，中国的智能手机时代历史进程就不可能这么快，国内手机厂商也正是抓住了这波机遇完成了国产化，并且发展至今。

更具象化分析智能手机厂商发展

从我个人的分析理解，国内手机厂商发展分为以下几个阶段：

1. 第一阶段：本土化定制，实现自主可控
   这个阶段国内手机厂商主要关注于对Android系统进行本土化定制，通过开发自家的用户界面（如华为的EMUI、小米的MIUI、vivo的Funtouch OS等），满足国内用户的需求和使用习惯。同时，厂商也开始关注硬件研发和生产，逐步减少对外部供应商的依赖，提高自主可控能力。


2. 第二阶段：自家产品生态化拓展建设
   在第二阶段，国内手机厂商开始关注产品生态的构建，将手机作为核心，围绕其开发各类智能硬件和应用服务，如智能家居、可穿戴设备、云服务等。这有助于提高用户粘性，形成闭环的生态系统，从而提升品牌竞争力和市场份额。


3. 第三阶段：公布自研操作系统，引入AI大模型完善产品体验
   在第三阶段，国内手机厂商开始研发自家的操作系统，如华为的鸿蒙OS（HarmonyOS），以降低对Android系统的依赖，提高自主创新能力。同时，厂商也开始引入人工智能技术，通过AI大模型优化产品性能、提升用户体验，为未来5G、物联网等新技术应用做好准备。

目前手机厂商已经来到第三阶段，自华为公布鸿蒙系统之后，小米和Vivo也相继公布自家的自研操作系统，自主创新似乎是国内厂商不约而同的战略共识。

避免被“卡脖子”再发生

2019年5月15日，华为被美国正式制裁，截止目前，已经过去了4年。那么这些年华为到底被制裁了什么？

华为受到的制裁主要包括以下几个方面：

1. 美国实体清单：2019年5月，美国政府将华为及其关联公司列入实体清单，禁止美国企业与华为进行商业往来，除非获得特别许可。这意味着华为无法从美国供应商处购买关键零部件和技术，如芯片、软件等。


2. 芯片供应限制：2020年5月，美国政府进一步收紧对华为的制裁，要求全球芯片制造商在向华为供应美国技术含量超过25%的产品时，必须获得美国政府的许可。这使得华为的芯片供应受到严重影响，尤其是高端芯片。


3. 软件限制：华为受到制裁后，谷歌停止为华为新款手机提供GMS（谷歌移动服务），包括谷歌应用商店、Gmail、YouTube等关键应用。尽管华为推出了自家的HMS（华为移动服务）替代GMS，但在全球范围内，GMS仍然具有很高的市场需求和用户粘性。


4. 网络设备限制：美国政府将华为视为国家安全威胁，禁止美国电信运营商使用联邦补贴购买华为的网络设备。此外，美国还在全球范围内施压，敦促其他国家在5G网络建设中排除华为。


5. 金融制裁：美国政府还对华为进行金融制裁，限制华为及其关联公司在美国的金融交易，使其在全球范围内融资和开展业务受到限制。

这些制裁对华为的业务造成了很大影响，尤其是在芯片供应、软件服务和5G网络设备方面。然而，华为在此期间加大了自主研发投入，努力寻求突破和替代方案。

华为是如何应对技术封锁的？

• 推出麒麟9000S芯片突破5G芯片断供

今年爆火的Mate60系列手机搭载就是这款芯片，华为终于扬眉吐气了一番。

• 推出自研鸿蒙全场景分布式操作系统

• 推出HMS 替代 GMS

当然还有很多自主创新的突破，从这些战略手段来看，华为确实非常值得尊敬的企业，至少给国内众多科技企业打了个样。

从华为被制裁的案例来看，国内其他一众手机厂商谁都无法预测自己可能是下一个华为。那么实现自主可控就显得非常迫切了，除非国内一众厂商放弃海外市场这块蛋糕，但这看起来是不太可能的事情。

万物互联生态蛋糕

我们知道不管是华为还是小米，它们的产品可不仅仅只是手机和PC，还有全场景的IoT智能硬件（包括智能家居、可穿戴设备，平板等等），未来还有智能驾驶汽车业务，比如现在小米正在如火如荼正在进行的造车运动。

小米IoT平台设备接入数据

小米IoT万物互联布局

小米智能汽车

面对如此庞大的设备和连接数，小米需要一套融合的系统框架统一支持全生态设备与应用，要成为未来百亿设备、百亿连接，万物互联的公有底座。这也能理解这为什么小米会推出澎湃OS来替代MIUI，未来构建万物互联的大格局所做出的战略性布局。

然而国内手机厂商的产品布局大致相同，属于强竞争关系，虽说鸿蒙系统较早就发布，但从商业竞争来看，这是另外一个层面的自主可控，让小米、Vivo这些厂商投入到鸿蒙怀抱目前来看是不太现实的，毕竟谁都不想当谁的小弟，或许形成操作系统联盟生态更合适。

写在最后

从最开始时间线开始我们了解到国产厂商纷纷入局自研操作系统，然后通过一张图理解了操作系统的发展脉络，再了解到国产手机厂商是如何发展起来的，Android的进入让国产手机进入智能化时代，我们再具象化理解目前如华为、小米和Vivo这些手机厂商发展的几个阶段。从华为被美国制裁，国内厂商引发的担忧和战略布局万物互联生态，最终为了能够实现自主可控，摆脱外部依赖的风险，纷纷入局自研操作系统。从各家厂商分别分布自己家的自研操作系统，说明这件事相比于自研芯片的难度要小很多。从操作系统发展脉络来看至少是站在巨人的肩膀上，完全自主产权这样的说法听听就好。要撼动Android和iOS的地位，要看开发者买不买单，这么多年所沉淀下来的生态要是这么容易就能够替代，那么当年Windows Phone就不会落寞而去，相比于微软大家觉得我们的差距还有多大呢。

面试官提问

面试官：候选人你好，请解释下面的现象：

1. 数组1000个元素，shift操作和对象delete操作的benchmark 差不多。


2. 数组10w个元素时，shift操作和对象delete操作的benchmark 相差巨大。

场景如下：
数组1000个元素时：shift和delete相差无几

数组100000个元素时，shift比delete慢了100倍

开始表演！

候选人：总的来说，这是因为数组在1k长度时，v8引擎能申请到一段连续内存做shift运算，在利用L1缓存的优势下，速度能和object的delete有得一比。

顺便一提，利用L1缓存思想做性能优化，也是最近游戏界中ECS架构为何能获得如此高的关注度的原因之一。

我们回到咱们前端来讲，口说无凭，眼见为实，让我们直接打开V8引擎源码一睹为快。

第一步、我们找到[].shift相关v8引擎源码。

我们可以看到ArrayPrototypeShift代码会尝试执行TryFastArrayShift函数，若该函数抛出Slow或者Runtime标志，则运行相应的逻辑。

第二步、我们进入 TryFastArrayShift 这个函数继续看，这个函数有两个逻辑：

1. 若没有连续内存，则抛出Slow


2. 若数组长度>100，则抛出Runtime

回到我们案例：我们数组长度如果在1000，则抛出的是Runtime标志；如果在10W，则抛出的是Slow标志。

第三步、查看Slow和Runtime的逻辑。

• 
  

  slow对应的GenericArrayShift函数逻辑如下 ：

  
  
  
  
  • 先把数组转换为对象
  
  
  • 再遍历对象的key，每一个key都往前移一位。（这也是ECMAScript-262规范定义的算法）
    
  
  
  
  


• 
  

  runtime对应的ArrayShift函数逻辑如下：

  
  
  
  
  1. 申请连续内存
  
  
  2. 遍历并移位
     
     
  
  
  
  

最后总结，从上面三步我们确认了V8引擎的执行逻辑：

1. 10W数据，很难申请到连续内存，通常就无法利用L1缓存，导致比较卡慢


2. 1000数据，较容易申请到连续内存，通常能利用到L1缓存，速度较快。
   
   
   
   1. 100长度以下的数组，直接走C++逻辑。
   
   
   2. 100长度以上的数组，走汇编逻辑加速。
   
   
   
   

这也就说明了为什么1000数据和10W数据执行上有一定差异的原因。

注意：ArrayShift函数源码可能有误，也请大佬指点。

PS：这个ArrayShift源码不在v8中，而在汇编中。

PS：这是因为buitin的代码需要在vs上编译出来才能查到相关代码的引用地址，目前比较忙，先分享思路，我后续会进行更新订正。

小结

上诉面试经历是我刚编的，希望能来更多的朋友讨论，毕竟大家对v8源码或多或少有一点陌生的畏难心理，我也如此。本问题实际是来自我交流群的某一次讨论。

不过道理是真的：

平时遇到某些问题，咱们也不妨从V8源码入手分析。

有时候源码比各类文章讲得更清晰。

日积月累，总会有一些意想不到的收获。

参考文章

• chromium开源源码在线工具


• v8引擎array源码解析


• V8引擎builtin源码解析

现在当你想去找一个无感刷新的方案的时候，搜出来的大多都是教你在aioxs的相应拦截器里面去截取当前请求的config。然后当token刷新后再去请求失败的接口。首先声明，这个方案完全没有任何问题。只是有可以优化的地方，这个优化的地方可以在我将要写的第二种方案中得到解决。

准备工作

接口服务

在实行方案之前需要准备好相关的接口服务，我会用node写一些登录刷新和正常的业务接口, 点这里查看 。

简单介绍下准备的接口及其作用

• /login: 模拟登录并返回token和refreshToken


• /refreshToken: 当token过期，请求这个接口会获得新的token和refreshToken，接口需要传入通过/login接口或者/refreshToken接口返回的refreshToken。当refreshToken也判断过期，就只能去登陆页。


• /test1: 模拟正常的业务请求接口，会验证token是否有效及是否过期，过期返回401


• /test2: 模拟正常的业务请求接口，会验证token是否有效及是否过期，过期返回401


• /test3: 模拟正常的业务请求接口，会验证token是否有效及是否过期，过期返回401

token的过期时间设置为5秒。

axios的封装

我们使用axios都会进行二次封装，都会在拦截器里面处理一些逻辑。这里给出一个最基本的封装，后面都会用到。

import axios from "axios";



export const service = axios.create({

  timeout: 1000 * 30,

  baseURL: "http://192.168.0.102:9001",

});



service.interceptors.request.use(

  (config) => {

    let token = localStorage.getItem("token");

    config.headers["Authorization"] = token;

    return config;

  },

  (err) => Promise.reject(err)

);



service.interceptors.response.use(

  (res) => {

    return res.data;

  },

  (err) => {

    return Promise.reject(err);

  }

);



export const get = (url, params) => {

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

    service

      .get(url, { params })

      .then((res) => {

        resolve(res);

      })

      .catch((err) => {

        reject(err);

      });

  });

};



export const post = (url, data = {}) => {

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

    service

      .post(url, data)

      .then((res) => {

        resolve(res);

      })

      .catch((err) => {

        reject(err);

      });

  });

};

首先还是介绍下最广泛的使用方案

在axios的响应拦截器里面处理

这种方案的工作流程都是在相应拦截器里面处理的，当判断到接口401，则请求刷新token接口，并改变一个状态来表明当前正在执行刷新token，这样可以避免多个请求同时401的时候所导致的一次401就会请求一次刷新token接口。接着将紧随着报401的接口保存起来，等到刷新token接口成功后再去执行这些失败的接口。完整代码，在上文的二次封装的axios基础上进行更改。

import axios from "axios";

----------------------------------------------------------------新增

import { refreshToken } from "@/api/login";

----------------------------------------------------------------新增



export const service = axios.create({

  timeout: 1000 * 30,

  baseURL: "http://192.168.0.102:9001",

});



service.interceptors.request.use(

  (config) => {

    let token = localStorage.getItem("token");

    config.headers["Authorization"] = token;

    return config;

  },

  (err) => Promise.reject(err)

);



----------------------------------------------------------------新增

let inRefreshing = false; // 当前是否正在请求刷新token

let wating = []; // 报401的接口 加入等待列表 刷新接口成功后统一请求

----------------------------------------------------------------新增



service.interceptors.response.use(

  (res) => {

    return res.data;

  },

  (err) => {

  ----------------------------------------------------------------新增

    let { config } = err.response;



    if (inRefreshing) { // 刷新token正在请求，把其他的接口加入等待数组

      return new Promise((resolve) => {

        wating.push({

          config,

          resolve,

        });

      });

    }



    if (err?.response?.status === 401) {

      inRefreshing = true;



      refreshToken({ refreshToken: localStorage.getItem("refreshToken") }).then(

        (res) => {

          const { success, response } = res;

          if (success) {

            inRefreshing = false;



            const { token, refreshToken } = response;

            localStorage.setItem("token", token);

            localStorage.setItem("refreshToken", refreshToken);



            // 刷新token请求成功，等待数据的失败接口重新发起请求

            wating.map(({ config, resolve }) => {

              resolve(service(config));

            });

            wating = []; // 请求完之后清空等待请求的数组



            return service(config); // 当前接口重新发起请求

          } else {

            // 刷新token失败  重新登录

          }

        }

      );

    }

----------------------------------------------------------------新增

    return Promise.reject(err);

  }

);



export const get = (url, params) => {

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

    service

      .get(url, { params })

      .then((res) => {

        resolve(res);

      })

      .catch((err) => {

        reject(err);

      });

  });

};



export const post = (url, data = {}) => {

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

    service

      .post(url, data)

      .then((res) => {

        resolve(res);

      })

      .catch((err) => {

        reject(err);

      });

  });

};

有些同学可能对上面代码有些疑问，感觉wating里面的数据不对，比如同时发送三个接口报401，wating只会加入两条接口数据，还有一条在哪儿。其实就在第60行返回了。

然后再对接口进行简单的封装

import { post } from "./index";



export const login = () => post("/login");

export const refreshToken = (data) => post("/refreshToken", data);



export const test1 = () => post("/test1");

export const test2 = () => post("/test2");

export const test3 = () => post("/test3");

接下来看结果。点击按钮会发送三条接口请求。

第一次点击发送请求token还未过期，第二次点击发送请求token已过期。

完美，没啥问题！因为上面给大家展示的是最简单的axios封装，所以在响应拦截器里面加上一些接口重发的逻辑好像没啥问题。但是如果还有对接口数据的加密解密过程呢？还有控制加载的时候loading窗完美展示的问题呢？这样一看在二次封装的axios里面加上接口重发就有点儿太多了。再比如说我用的不是axios怎么办，是不是又得根据请求的插件去改一些东西。

那么与axios拦截器解耦就成了需要做的事了。

与axios拦截器解耦

我们需要创建一个构造函数，这个构造函数会将报401的接口收集起来，等到刷新token接口成功后再去请求

import { refreshToken } from "@/api/login";



function requestCollection() {

  let inRefreshing = false; // 当前是否正在请求刷新token

  let wating = []; // 报401的接口 加入等待列表 刷新接口成功后统一请求



  return (request) => {

    return new Promise((resolve) =>

      request()

        .then((res) => {

          resolve(res);

        })

        .catch(async (err) => {

          if (err.response.status == 401) {

            if (inRefreshing) {

              // 加入等待执行的数组

              return wating.push({

                request,

                resolve,

              });

            }



            inRefreshing = true;



            await RT();



            wating.map(({ resolve, request }) => {

              resolve(request());

            });

            wating = [];



            return resolve(request());

          }

        })

    );

  };

}



const RT = () => {

  return new Promise((resolve) =>

    refreshToken({

      refreshToken: localStorage.getItem("refreshToken"),

    }).then((res) => {

      const { success, response } = res;

      if (success) {

        const { token, refreshToken } = response;

        localStorage.setItem("token", token);

        localStorage.setItem("refreshToken", refreshToken);



        resolve();

      }

    })

  );

};



export default requestCollection;

其实内在的处理逻辑与第一种大同小异，主要在于将这一部分逻辑抽离出来。

使用

import { post } from "./index2";

import requestCollection from "./RequestCollection";



const check = new requestCollection();



export const login = () => check(() => post("/login"));

export const refreshToken = (data) => check(() => post("/refreshToken", data));



export const test1 = () => check(() => post("/test1"));

export const test2 = () => check(() => post("/test2"));

export const test3 = () => check(() => post("/test3"));

效果演示

这种方案存在的一个小问题
因为需要对接口进行一层包裹，所以如果你的项目已经运行有一段时间了突然来个需求说想要个无感刷新token，那其实这个方案会随着你的项目的大小而加大你的工作量。

上述两种方案都存在的不足
当我们都在讨论无感刷新token的方案都是如何接口重发的时候，大家都忽略了一个问题，那就是接口重发的过程是发送了原本两倍+1的接口数量。如果这个接口本来就慢，恰好碰上了401，那用户就得花约两倍时间去等一个结果，相信你不愿意等，我也不愿意等。

那么被大家诟病会造成一定性能浪费的定时任务刷新就可以解决这个问题，并且定时任务刷新也是解耦于二次封装的axios。 其实都到了2023年，一个定时任务会对最终用户所使用的页面造成卡顿的影响可以说完全感知不到。但是我也不推荐大家无意识的随便使用定时器或者闭包一类能通过一点点累加所造成的内存泄露的性能问题。

定时任务刷新

这个就不给代码了，主要注意几个点就行

• 后端需要配合返回一个token的过期时间


• 定时任务全局存在


• 刷新token成功后需要更新过期时间重新计算

总结

其实上面三种方案都有自己的好处和缺点，无论你使用哪一种方案，都没有问题。这些需要你结合自己的项目来选择适合你的方案。

大家好，我是鱼皮。Git 是主流的代码版本控制系统，是团队协作开发中必不可少的工具。

这篇文章，主要是给大家分享 Git 的核心功能 提交（Commit）的作用，帮助大家更好地利用 Git 这一工具来提高自己的开发工作效率。

什么是 Git 提交？

Git 提交是指将你的代码保存到 Git 本地存储库，就像用 Word 写长篇论文时进行保存文件一样。每次 Git 提交时都会创建一个唯一的版本，除了记录本次新增或发生修改的代码外，还可以包含提交信息，来概括自己这次提交的改动内容。

如下图，就是一次 Git 提交：

Git 提交的作用

Git 提交有很多作用，我将它分为 基础用法 和 其他妙用 。

基本作用

历史记录

Git 提交最基本的作用就是维护项目的历史记录。每次提交都会记录代码库的状态，包括文件的添加、修改和删除；还包括一些提交信息，比如提交时间、描述等。这使得我们可以通过查看所有的历史提交来追溯项目的开发进度和历程，了解每个提交中都发生了什么变化。

比如查看我们编程导航文档网站项目的提交记录，能看到我是怎么一步一步构建出这个文档网站的：

开源地址：github.com/liyupi/code…

在企业开发中，如果一个人写了 Bug，还死不承认，那么就可以搬出 Git 提交记录，每一行代码是谁提交的都能很快地查出来，谨防甩锅！

版本控制

另一个 Git 提交的基本作用是版本控制。每个提交都代表了代码库的一个版本，这意味着开发者可以随时切换代码版本进行开发，恢复旧版本的代码、或者撤销某次提交的代码改动。

推荐新手使用可视化工具而不是 Git 命令进行版本的切换和撤销提交，在不了解 Git 工作机制的情况下使用命令操作很容易出现问题。

如下图，在 JetBrains 系列开发工具中，右键某个提交，就可以切换版本或撤销提交了：

代码对比

你可以轻松地查看两个提交之间的所有代码更改，便于快速了解哪些部分发生了变化。这对于解决代码冲突、查找错误或审查代码非常有帮助。

在 JetBrains 系列开发工具中，只需要选中 2 个提交，然后点右键，选择 Compare Versions 就能实现代码对比了：

改动了哪些代码一目了然：

一般情况下，如果我们因为某次代码改动导致项目出现了新的 Bug。通过这种方式对比本次改动的所有代码，很快就能发现 Bug 出现的原因了。

其他妙用

除了基本作用外，Git 提交还有一些妙用~

记录信息

像上面提到的，Git 提交不仅能用于记录代码更改，我们还可以在提交信息中包含有关这次更改的重要信息。比如本次改动代码的介绍、代码更改的原因、相关的任务（需求单）或功能等。可以简单理解为给本次工作写总结和描述。

如果提交信息编写得非常清晰完善，那么项目的团队成员可以更容易地理解每个提交，甚至能做到 “提交即文档”，提高协作和项目维护效率。

正因如此，很多团队会定制自己的提交信息规范，比如之前我在鹅厂的时候，每次提交都建议带上需求单的地址，便于了解这次提交是为了完成什么需求。

这里给大家推荐一种很常用的提交信息规范 —— 约定式提交，每次提交信息都需要遵循以下的结构：

《约定式提交》文档：http://www.conventionalcommits.org/zh-hans/v1.…

<类型>[可选 范围]: <描述>



[可选 正文]



[可选 脚注]

当然，这种方式有利有弊，可能有同学会觉得 “我注释都懒得写，你还让我写提交信息？” 这取决于你们项目的规模和紧急程度等因素，反正团队内部保持一致就好。

像我在用 Git 开发个人项目时，也不是每次都写很详细的提交信息的。但是带 编程导航 的同学从 0 开发项目时，每场直播写的代码都会单独作为一次提交，如下图：

是不是很清晰呢？这样做的好处是，大家想获取某场直播对应的中间代码（而不是最终的成品代码）时，只需要点击某次提交记录就可以获取到了，很方便。

如果你的提交信息写得非常标准、统一结构，那么甚至还可以用程序自动读取所有的提交信息，生成日志、或者输出提交报告。

自动化构建部署

大厂研发流程中，一般都是使用 CI / CD（持续集成和持续部署）平台，以流水线的形式自动构建部署项目的。

Git 提交可以和 CI / CD 平台进行集成，比如自动监视代码库中的提交，并在每次提交后自动触发构建和部署任务。一个典型的使用场景是，每次代码开发完成后，先提交代码到测试分支，然后 CI / CD 平台监测到本次提交，并立即在测试环境中构建和部署，而不需要人工操作，从而提交效率。

GitHub Actions 和 GitHub Webhooks 都可以实现上述功能，感兴趣的同学可以尝试下。

GitHub Actions 文档教程：docs.github.com/zh/actions/…

检验项目真假

最后这个点就比较独特了，那就是面试官可以通过查看 Git 的提交记录来判断你的项目真假、是不是自己做的。

比如我收到一些同学的简历中，有的开源项目看起来感觉很厉害，但是点进仓库看了下提交记录，发现寥寥无几，甚至有的只有 1 次！像下图这样：

那么这个项目真的是他自己从 0 开始做的么？答案就显而易见了。

如果真的是你自己用心做的项目，提交记录绝对不止 1 次，而且面试官能够通过提交记录很清晰地了解到你的项目开发周期。

像我的 yuindex Web 终端项目一样，这才是比较真实、有说服力的：

其他人也能从你的提交记录中，感受到你对项目的用心程度。

讲到这里，是不是有些同学恍然大悟，知道为啥自己的项目明明开源了，但是没有收到面试邀请、或者被面试官觉得项目不真实了？

实践

以上就是本次分享，Git 提交的实践其实非常简单，我建议大家每次做新项目时，无论大小，都用 Git 来托管你的项目，并且每开发完一个功能或解决 Bug，都进行一次提交。等项目完成后回过头来看这些提交记录，都是自己宝贵的财富。

做客户端开发都基本都做过性能优化，比如提升自己所负责的业务的速度或流畅性，优化内存占用等等。但是大部分开发者所做的性能优化可能都是针对中小型 APP 的，大型 APP 的性能优化经验并不会太多，毕竟大型 APP 就只有那么几个，什么是大型 APP 呢？以飞书来说，他的业务有 im，邮箱，日历，小程序，文档，视频会议……等等，包体积就有大几百 M，像这种业务非常多且复杂的 APP 都可以认为是大型 APP。所以我在这篇文章主要讲一下大型 APP 是怎么做性能优化的，给大家在性能优化一块提供一个新的视角和启发。在这篇文章中，我主要会讲一下这两个主题：

1. 
   

   大型 app 相比于中小型 app 在做性能优化时的异同点

   
   


2. 
   

   大型 app 性能优化的思路

   
   

大型和小型应用性能优化的异同点

1.1 相同点

性能优化在本质上以及在优化维度上都是一样的。性能优化的本质是合理且充分的使用硬件资源，让程序表现的更好；并且都需要基于应用层、系统层、硬件层三个维度来进行优化

1.2 不同点

针对系统层和硬件层的优化都是一样，有区别的主要是针对应用层的优化。

中小型 app 做业务和做性能优化的往往是同一个人，在做优化的时候，只需要考虑单个业务最优即可，我们只需要给这些业务充足的硬件资源（比如给更多的内存资源：缓存更多的数据，给更多的 cpu 资源：用更多的线程来执行业务逻辑，给更多的磁盘资源：缓存足够的本地数据），并且合理的使用就能让业务表现的更好。只要这些单个的业务性能表现好，那么这款 app 的整体性能品质是不错

和中小型 APP 不同的是，大型 APP 业务多且复杂，各个业务的团队很可能都不在一个部门，不在同一个城市。在这种情况下，如果每个业务也去追求自己业务的性能最优，同样是在自己的业务中使用更多的线程，使用更多的缓存，使用更多 cpu 的方式来使自己业务表现更好，那么就会导致 APP 整体的性能急剧劣化。因此大型 APP 需要有一个专门团队来做性能优化的，这个团队需要脱离某一个具体业务，站在全局的视角来让 APP 整体表现更优。

大型应用性能优化方案

总的来说由于资源是有限的，在中小型 APP 上，业务少，资源往往是充足的，我们做性能优化时往往考虑的是怎么将资源充分的发挥出来，而在大型 APP 上，资源往往是不足的，做性能优化时需要考虑即能充分发挥硬件资源，又需要进行合理的分配，当我们站在全局的视角来进行资源分配时，就需要考虑到这三个点：

1. 如何管控业务对资源的使用


2. 如何度量业务对资源的消耗


3. 如何让业务在资源紧张时做出更优的策略

下面我会针对速度及流畅性优化、内存优化这两个方向，讲一讲针对这这三点的体现。

2.1 速度和流畅性优化：如何管控业务对资源的使用

在速度和流畅性方向，中小型 APP 只需要分析和优化主路径的耗时逻辑；将同步任务尽量优化成异步任务；多进行预加载等方案，即能起很好的优化效果。但是对于大型 APP 来说，异步任务往往非常多，cpu 往往都是打满的情况，这种情况下主路径得不到足够的 cpu 资源，导致速度变慢。所以大型 app 中一般都会对业务的异步任务，如启动阶段的预加载进行管控，因此需要预加载框架或者类似的框架，来收敛、管控、以及调度所有业务的预加载任务。我们来看一下在大型 APP 中，通用的预加载框架是怎么做的。

2.1.1 预加载框架

想要管控业务的预加载任务，我们需要考虑这两个点：

1. 
   

   预加载任务的添加方式

   
   


2. 
   

   预加载任务调度和管理的机制

   
   


3. 
   

   预加载任务的添加方式

   
   

首先要将业务的预加载任务和业务进行解耦，要能做到即使该预加载任务不执行，也不会影响到业务的正常使用，并且将预加载任务封装成粒度最小的 task，然后直接将这些 task 丢到到预加载框架中，我们可以通过单例提供一个 addPreloadTask 方法，业务方只需要调用该接口，并传入预加载任务 task 以及一些属性及配置参数即可。将预加载任务添加到预加载框架后，业务方就不需要进行任何其他操作了，是否执行、什么时候执行，都交给预加载框架来管理。

2. 
   

   预加载任务调度时机

   
   

那么预加载框架对于添加进来的 task 如何调度呢？这就是一个预加载框架复杂的的地方的，我们可以有很多策略，比如这三种：

1. 关键节点调度策略：比如各个生命周期阶段，页面渲染完成阶段等去执行，也可以在任务添加进来后立刻执行。


2. 性能调度策略：比如判断 cpu 是否忙碌，温度是否过高，内存是否充足等，只有在性能较好的情况下才进行调度


3. 用户行为调度策略：如果做的更复杂一些，还可以结合用户的行为指标，如该业务用户是否会使用，如果某一个用户从来不适用这个 app 里的这个功能，那么改业务添加进来的预加载任务就可以完全舍弃到，这里面可以用一些端智能的方案来精细化的控制预加载任务的调度

每种调度策略不是单独执行的，我们可以将各种策略整合起来，形成一套完善的调度策略。

2.2 速度和流畅性优化：如何让业务在资源紧张时做出更优的策略

上面提到的是站在全局的视角，如何管控预加载任务的，除了预加载任务，还有很多其他的异步任务我们都可以用一些框架来规范化的管控起来，这里再举一个例子，对于大型 APP 来说，业务在使用的过程中很容易出现因为 cpu 或内存不足导致卡顿，响应慢等性能问题，所以在做性能优化时，是需要推动业务方在资源不足时，做出相应策略的，这个时候我们就需要降级框架来处理了。降级框架需要解决这两个问题：

1. 性能指标的采集


2. 降级任务的调度

2.2.1 降级框架

1. 
   

   性能指标的采集

   
   

想要再资源紧张时让业务做出优化策略，那么对资源紧张的判断就是必不可少的一步。我们一般通过在程序运行过程中，采集设备性能指标来判断资源是否紧张，最基本的性能指标有 cpu 使用率，温度，Java 内存，机型等，除机型外其他性能指标一般都是以固定的频率进行采集，如 cpu 使用率可以 10s 采集一次，温度可以 30s 采集一次，java 内存可以 1 分钟采集一次，采集的频率需要考虑对性能的影响以及指标的敏感度，比如 cpu 的使用率采集，需要读取 proc/stat 的文件并解析，是有一定性能损耗的，所以我们在采集时，不能太频繁；温度的变化是比较慢的，我们采集的频率也可以长一些。降级框架需要整合这些性能指标的采集，减少各个业务自己采集造成不必要的性能损耗。

当降级框架采集到性能指标，并判断当前资源异常时，通用的做法是通知各个业务，业务收到通知后再进行降级。比如系统的 lowmemorykiller 机制，都是采用通知的方式。

但是在大型 APP 中，仅仅将触发性能阈值的通知给到各个业务方，效果不会太好，因为业务方可能并不会去响应通知，或者个别业务响应了，但是其他业务不响应，依然效果不佳。无法管控业务是否进行降级，这显然不符合在大型 APP 做性能优化的思路，那么我们要怎么做呢？

2. 
   

   降级任务的调度

   
   

添加任务：我们依然可以推动各个业务将降级的逻辑封装在 task 中，并且注册到降级框架中，并由降级框架来进行调度和管理。因为往降级框架注册 task 时，需要带上业务的名称，所以我们能也能清楚的知道，那些业务有降级处理逻辑，哪些业务没有，对于没有注册的业务，需要专门推动进行降级响应以及 task 的注册。

调度任务：和预加载框架一样，对于注册进来的 task，降级框架的任务调度要考虑清楚调度的时机，以 cpu 使用率为例，不同的设备下的阈值也是不一样的，高端机型可能 cpu 的使用率在 70%以上，app 还是流畅的，但是低端机在 50%以上就开始卡顿了，因此不同的机型需要根据经验值或者线上数据设置一个合理的阈值。当 cpu 到达这个阈值时，降级框架便开始执行注册到 cpu 列表中的降级任务，在执行降级任务时，不需要将队列里的 task 全部执行，我们可以分批执行，如果执行到某一批降级 task 时，cpu 恢复到阈值以下了，后面的降级 task 就可以不用在执行了。可以看到，通过降级框架，我们就可以站在全局的维度，去进行更好的管控，比如我们可以度量业务做降级任务的效果，给到一个评分，对于效果不好的，可以推动优化。

2.3 内存优化：如何度量业务对资源的消耗

上面两个例子将的是在大型 app 中，如何管控业务对资源的使用，以及如何让业务在资源紧张时做出更优的策略的思路，我接着基于内存优化的方向，讲一讲如何度量业务对资源的消耗。

当 app 运行过程中，往往只能获得整体的内存的数据占用，没法获的各个业务消耗了多少内存的，因为各个业务的数据都是放在同一个堆中的，对于小型 app 来说这种情况并不是问题，因为就那么几个业务在使用内存，但是对于大型 app 来说就是一个问题了，有些业务为了自己性能指标能更好，会占用更多的内存，导致整体的内存占用过高。所以我们需要弄清每个业务到底使用了多少内存才能推动业务进行优化。

我们可以线下通过分析 hprof 文件或者其他调试的方式来弄清楚每个 app 的内存占用，但是很多时候没有充足的时间在版本都去统计一下，或者即使统计了，也可能因为路径没覆盖全导致数据不准确。所以我们最好能通过线上监控的方式，就能统计到业务的内存消耗，并且在内存消耗异常的时候进行上报。

我在这里介绍一种思路。大部分的业务都是以 activity 呈现的，所以我们可以监听全局的 activity 创建，在业务的 onCreate 最前面统计一下 java 和 native 内存的大小，作为这个业务启动时的基准内存。然后在 acitvity 运行过程中，固定采集在当前 activity 下的内存并减去 onCreate 时的基准内存，我们就能度量出当前业务的一个内存消耗情况了。在该 acitvity 结束后，我们可以主动触发一下 gc，然后在和前面的基准内存 diff 一下，也能统计出该业务结束后的增量内存，理想情况下，增量内存应该是要小于零的，由于 gc 需要 cpu 资源，所以我们只需要开取小部分的采样率即可。

当我们能在运行过程中，统计各个业务的内存消耗，那么就可以推动内存消耗高的业务进行优化，或者当某个版本的某个业务出现较大的劣化时，触发报警等。

除了上面提到的思路，我们也可以统计在业务使用过程中的触顶次数，计算出一个触顶率的指标，触顶及 java 内存占用达到一个阈值，比如 80%，我们就可以认为触顶了，对于触顶次数高的业务，同样也可以进行异常上报，然后推动业务方进行修改。这些数据和指标的统计，都是无侵入的，所以并不需要我们了解业务的细节。

如果我们想做的更细一些，还可以 hook 图片的创建，hook 集合的 add，remove 等方法，当监控到大图片和大集合时，打印堆栈，并将关键信息上报。在飞书，如果是低端机中，图片如果占用内存过大的，都会在 hook 方法中进行一些压缩或者降低质量的兜底处理。

总结

除了速度及流畅性，内存方向的优化外，还有其他方向的优化，如包体积，稳定性，功耗等，在大型 APP 上都要基于管控业务对资源的使用；度量业务对资源的消耗；让业务在资源紧张时做出更优的策略这三个方向去进行优化，这里我就不再一一展开讲了。

当然我这里讲的优化思路并不是大型 app 做性能优化的全部，我讲的只是在做大型 app 的性能时相比于中小型 app 需要额外做的，并且也是效果最好的优化，这些方案在中小型 app 上可能并不需要。除了我这篇文章讲的内容外，还有很多优化的方案，这些方案不管是在大型 app 还是中小型 app 上都是通用的，比如深入了解业务，基于业务逻辑去做分析和优化，抓 trace，分析 trace 等等，或者基于系统层或者硬件层去做一些优化等等，这里就不再展开讲了。

提前声明： 先说好哈，不要一上来就开喷，好吧，不感兴趣的话你可以不用看下文直接划走，直接喷俺有点承受不住，心脏不好。如果你感兴趣，你可以先把这篇文章看完，看完后感觉俺讲的还挺有道理的那就不喷，如果讲的你认为啥也不是，那就往死里喷，喷不动了俺也加入。

唠叨唠叨

最近，鸿蒙开发的风头也吹到俺这里了，于是我便上网看了看，就以俺的知识面去聊一聊鸿蒙，究竟是个啥，有啥用呢。

在此之前，咱们可以先看个视频来大致了解一下鸿蒙系统究竟是干啥的，有啥好处：鸿蒙的官方定义哔哩哔哩bilibili（该视频为黑马的课程视频，原视频没暂时没找到，可跳到 03:46~12:17 和 13:27~19:35 两个时间段）。

如果你看了这个视频的话，相信你对鸿蒙也有了一定的了解了。

为啥我想说鸿蒙呢

最近一段时间，总是有人在说一些（俺认为哈，别人我就管不着了哈）有些莫名其妙的话术：什么前端以死呀、鸿蒙就是个安卓套壳呀、前端的春天要来了呀、等等之类的。是真的死了吗，俺不这样认为，只是技术门槛提高了而已，毕竟市场他是活的，人它也是活的，是活的话他就有变的时候，你的技术不变，不去进行升级的话，那就会被现有的市场所淘汰。优胜劣汰这个道理俺相信你们每个人都懂，只是有些人不想去面对而已，仅此而已。

鸿蒙系统又是个啥

俺简单来说哈，其实就一句话：鸿蒙系统是全场景 、面向未来、万物物联的

如果这句话比较难理解，或者俺通过一张图让你更直观一点：

如果你还是不理解的话，可以去华为官网看看官方对于鸿蒙系统的解释。

那鸿蒙系统的特点有啥

1. 统一OS，弹性部署

一套操作系统，满足大大小小所有设备的需求，小到耳机，大到车机，智慧屏，手机等，让不同设备使用同一语言无缝沟通。

2. 硬件互助，资源共享

搭载 HarmonyOS 的每个设备都不是孤立的，在系统层让多终端融为一体，成为“超级终端”，终端之间能力互助共享，带来无缝协同体验。手机可以连接一切设备，可以将这些设备看作一个整体，如当手机需要操作自家的音响时，直接在手机上简单动一动手指头就行了，就像操作手机上的喇叭一样方便。

3. 一次开发，多端部署

开发者基于分布式应用框架，开发者只需要写一次逻辑代码，就可以部署在多种终端上，在多个设备上安装了。

4. 应用自由跨端

HarmonyOS 原子化服务是轻量化服务的新物种，它提供了全新的服务和交互方式，可分可合，可流转，支持免安装等特性，能够让应用化繁为简，让服务触手可及。

• 咱们来以一个例子理解一下：

假设咱们要用安卓操作系统去控制一台音响，这台音响有切歌功能、点歌功能、语音聊天功能，现在俺有点寂寞，需要音响陪我聊会天，俺只需要音响的语音聊天功能，但你必须要下载他的完整APP，并不能俺需要用啥功能就下载啥功能。而鸿蒙系统就可以做到。

5. 用“简单”激活你的设备智能

HarmonyOS 是新一代智能终端操作系统。为不同设备的智能化、互联与协同提供了统一的语言。设备可实现一碰入网，无屏变有屏，操作可视化，一键直达原厂服务等全新功能。通过简单而智能的服务，实现设备智能化产业升级。

用安卓操作系统时，你需要下载设备对应的APP才能控制该设备，而鸿蒙操作系统，你直接将手机与设备上的芯片碰一碰，就可以直接通过手机来使用设备了。

小提示： 俺家也没几个鸿蒙相关的设备，具体的俺也不是特别清楚，这些都是俺从网上了解到的。手机能连接上设备的前提是该设备的厂家与华为达成了合作才行吧（好像是这样的）。但俺用的是华为手机，路由器也是华为的，就这两个华为设备从俺的体验上来说哈，那还是不错的。

可以与安卓做下对比

1. 内核方面的对比

安卓系统：

是基于linux的宏内核设计 ，宏内核包含了操作系统绝大多数的功能和模块，而且这些功能和模块都具有最高的权限，只要一个模块出错，整个系统就会崩溃，这也是安卓系统容易崩溃的原因。好处就是系统开发难度低。

鸿蒙系统：

是微内核设计：微内核仅包括了操作系统必要的功能模块（任务管理、内存分配等）处在核心地位具有最高权限，其他模块不具有最高权限，也就是说其他模块出现问题，对于整个系统的运行是没有阻碍的。微内核稳定性很高。而且鸿蒙系统包含了两个内核，如果是手机APP是基于Linux内核，而如果是其他的硬件是基于LiteOS内核。

2. 运行速度的对比

安卓系统：

安卓程序不能与系统底层直接进行通信活动，是运行在虚拟机上的。如果虚拟机出了问题话的那系统就是卡住。

鸿蒙系统：

鸿蒙系统中的方舟编译器解决了这个问题的，任何由编译器编译的软件，是直接运行在操作系统中的，可以直接与系统底层进行通信。鸿蒙的运行速度更快

3. 作为手机操作系统的对比

安卓和鸿蒙都是基于安卓开源项目（AOSP）进行开发的。

而安卓开源平台是可以在开源许可下自由使用和修改的。国内外很多手机厂商都根据这套代码制定了自己的操作系统，比如：三星、小米、魅族等。而华为也是基于这套开源体系，制定了鸿蒙操作系统。

鸿蒙操作系统的构成：

HarmonyOS = 安卓开放平台的开源代码 - GMS - 安卓UI + HMS + 鸿蒙UI + 分布式软总线 + 以Ability为核心的应用开发框架。

4. 连接其他设备的对比

安卓系统：

安卓手机连接其他设备，不管从 app 开发方面，还有使用方面都非常麻烦，而且如果换一个第三方设备，还需要把发现，配对，连接，组合，验证的过程再次操作一遍。

鸿蒙系统：

但是鸿蒙就非常简单了，从 app 开发方面，只要写很少的代码就可以调用第三方硬件，从使用的角度来讲，不管是多少设备连在一起，鸿蒙的终极目标是都能像使用一台设备那样简单。

那鸿蒙究竟是不是安卓的套壳呢

网上有很多人说鸿蒙就是安卓的套壳，还用人说人家搞安卓开发的都是这样认为的。都不太看好鸿蒙，不要跟风，好吧。别人说是就是呀。你真的有去认真了解过吗。经过俺的一番捯饬后，俺大致的讲讲俺的理解哈。

其实吧，为啥有这么多人说鸿蒙就是安卓的套壳呢，归根结底呀，是这两家的 “祖宗” 其实是一家人，也就是安卓和鸿蒙都是基于安卓开源项目 AOSP 进行开发的。而且 AOSP 里的代码，是全球很多开发者共同维护开发的，华为也是该代码的提供者之一，任何人都是可以在开源许可协议下去自由使用和二次修改的。而华为也是基于这套开源体系，制定了鸿蒙操作系统。这就是为啥都说鸿蒙是安卓的套壳的原因了。

小提示： 可能会有人问俺 AOSP 又是啥东东，俺在网上找了一篇文章，你可以看看，了解一下：鸿蒙系统不是安卓系统？AOSP 为你揭秘！ (baidu.com)

所以呢，不是套壳、不是套壳、不是套壳重要的事说三遍哈。你要是还是那样认为那话，那俺只能说，我嘞个豆！！！

就国家政策和市场形式

其实从央视力挺华为就可以看出了，我国对鸿蒙系统还是相当重视的（网传，鸿蒙系统会上交给国家，俺也不知道是真是假）。

就俺认为哈，代码这玩意都是老外搞出来的，一个操作系统能难倒他们，只是安卓和ios这两家独大，资历雄厚。可能有国外有好的操作系统出现，只是还没广为人知就已经被资本扼杀在摇篮里了。这又有谁知道呢。当然了这写只是俺的猜测而已。

如果一个国家的操作系统多了，其实也不利于社会的管理和发展，国家一定会主推一个操作系统，然后其他系统为辅，从而形成 “百家争鸣” 的形式。

另外哈，俺在招聘网上也查了看了一下，鸿蒙开发相关岗位的薪资大都与安卓开发平齐甚至有的还比安卓开发相关岗位的薪资要高得多（俺看到一家的鸿蒙开发的薪资，18~30K 16薪，说实话哈，俺是真的心动了）。

声明一下： 以上有关的国家和社会的话术，都是俺自我认为的、理解的，请广大网友不必太纠结其对错，更不要上升到国家层面去给予评论和回复。谢谢！

回归主题

回归主题： 鸿蒙开发，对于前端开发来说，究竟是福是祸呢？

看个人理解吧，俺认为哈，是福（俺已经开始学了）。就国内哈，如果明年华为推出的 HarmonyOS Next 将真的彻底抛弃 AOSP （华为的这个决定很大胆，这也是大部分的安卓开发者头痛的事，所以才会非常反感鸿蒙）。也就是说，明年，所有的安卓应用将不能在华为手机上使用，要想使用的话，就必须采用鸿蒙原生开发将应用改为鸿蒙应用程序。那你想想哈，我国有多少个应用，又有几个是用鸿蒙原生开发的或重构的，你再想想哈，这么多应用都要重构，那是不是这工作量非常之巨大，这么巨大的工作量，那公司是不是要招鸿蒙开发相关岗位了，薪资给少了你肯定不愿意去呀，那它公司又急需呀，那他的薪资待遇会不会被提高。那如果你会的话那你是不是就能上，那样的话害怕找不到工作。

这就是相当于前端开发的一个红利期，而且这个红利期至少会持续两三年势头不会淡。其实俺说它是前端开发的春天的话也不为过，至少是在国内哈，国外俺就不知道啦。

当然这还得等到明年华为推出的 HarmonyOS Next 是否真的彻底抛弃 AOSP ，如果是的话，那俺的认为就是对的。如果是假的话，那此上的一切都免谈，都是瞎扯淡。

上手试试

小提示哈： 如果你看完了上面的内容，你发现对鸿蒙开发产生了一定的好奇，你可以直接去官网注册个账号HarmonyOS应用开发官网 - 华为HarmonyOS打造全场景新服务，实名认证一下（俺建议采用银行卡的方式认证，这样通过认证更快），然后里面有在线的视频课程，它会带你具体了解如何开发鸿蒙原生应用。下面的内容你就可以忽略了。

• 注册个账号：华为HarmonyOS智能终端操作系统官网 | 应用设备分布式开发者生态、实名认证按提示填写对应信息即可。


• 下载开发工具，那必须下最新版的：HUAWEI DevEco Studio和SDK下载和升级 | HarmonyOS开发者


• 点击打开，第一次打开时，会问要不要导入一些设置，这里默认就行了

俺电脑上没装v16.19.1版本的node：俺用的是16.20.1的，不知道行不行，再装一个吧：

路径与编译工具的安装地址是一致的：

点击next，如果出现报红，选择第二个就可以了哈。

创建个应用：

创建第一个应用 FirstApp：

咻咻等待一下的啦，让项目配置一下资源。

第一次运行会有上图的提示信息，将其 × 了就可以看到 Hello World 效果了

小改一下：

使用模拟器：

登录后，选着P50机型模拟器调试：

也不知道为啥，有时候就是无法用P50机型模拟器调试。后来俺还是用了本地模拟器。

工作开始,一直被程序猿=修电脑的，厌恶感十足,很可惜打脸来的太快，经历了公司换新电脑，坏了几次，再到工作变动自己搞了新电脑，直到红盘,被迫开启了自己的电脑救赎之旅，本次以这次被迫优化为例,主要想说的是搞程序的解决红盘的问题。

装系统

    之前配备的电脑新拆就一直有莫名重启，移动电源无法使用的情况，随后到了彻底无法忍受的程度，你能想象，你正敲着代码毫无征兆就重启吗，还是一天10几次那种，好在常年随时保存的好习惯避免了重大事故,于是开始了反反复复的系统重装,直到确认是硬件问题,拿去报修，完了之后，当系统安装已经成为了本能，让我彻底的不再恐惧重装系统这个事儿，你们应该都懂，作为一名开发，系统重装这个事儿到底是有多恐惧、

    在这之后,由于工作变动的原因,又仓促的买了新电脑，安装已经驾轻就熟，大概是对纯净版，专业版系统的执着，微PE工具箱让我感觉到装系统和纯净版是一个让人愉悦的事儿,夹带私货的系统让人头皮发麻,我大概经过了这个几个阶段,
系统安装->升级专业版->C盘分区扩容->提权administrator(普通用户对权限引起的bug和问题深度受害者)->驱动/开发工具安装，一顿操作搞下来，我的C盘大概控制在了40G以内,其他软件的安装严格的装在了指定盘符，结果半年多下来，我的120G的C盘坎坎到今天只剩下了5个G,可能这个就是全栈加全干带来的深度后果吧。

C盘红盘过程

     像是npm 、cargo、vs、maven、Android Studio、python等工具C盘盘符产生缓存的问题我已经极度的进行了处理,但从120G-40G=80G的过程，你应该能想象我这大半年都经历了啥、找的c盘批处理完全解决不了我的困难，至于现有的C盘瘦身啥的软件要么收费要么夸大,感觉跟搞程序用的电脑不吻合，完全解决不了啥问题，没办法，我只能挨个的分析文件夹,定位这些内容产生自哪里。

@echo off



echo 正在清除系统垃圾文件，请稍等……



del /f /s /q %systemdrive%\*.tmp



del /f /s /q %systemdrive%\*._mp



del /f /s /q %systemdrive%\*.log



del /f /s /q %systemdrive%\*.gid



del /f /s /q %systemdrive%\*.chk



del /f /s /q %systemdrive%\*.old



del /f /s /q %systemdrive%\recycled\*.*



del /f /s /q %windir%\*.bak



del /f /s /q %windir%\prefetch\*.*



rd /s /q %windir%\temp & md %windir%\temp



del /f /q %userprofile%\cookies\*.*



del /f /q %userprofile%\recent\*.*



del /f /s /q “%userprofile%\Local Settings\Temporary Internet Files\*.*”



del /f /s /q “%userprofile%\Local Settings\Temp\*.*”



del /f /s /q “%userprofile%\recent\*.*”



echo 一键清理系统垃圾完成！



echo. & pause

优化前C盘只剩下5个G，没有先见之明，只能把优化后的结果贴图了,从D盘应该看得出端倪

在这个截图之前，C盘的用户数据大约是60多个G,20多G的优化空间也从此处来的

C盘救赎

• C:\Users\Administrator\AppData\Local如果作为前端，大概率空间的占用是从这里开始的
  


• 如果作为服务端

1. JAVA检查一下你的maven包缓存位置，我开始就设置了，因此没有占据C盘空间，很多都放在D盘了。


2. c# 检查一下nuget的包缓存，可能会很大


3. python的可以检查一下pip相关的包


4. 总之现在的开发工具都很热衷于你的用户数据存储包,你如果分析一下c盘空间会有惊喜发现

• 我之前也搜过很多教程，然并卵，很多压根没考虑过C盘用户数据造成的问题。

     整的比较简单，算是个程序猿群体避免重装系统的一个方案吧，求人不如求己，实在是在重装的边缘挣扎的老哥，可以尝试从这几个方面去做处理,尝试把相关的批处理删除加到以上的脚本中，做个自己的专清小工具，别被各种C盘瘦身垃圾软件折磨了。

结束

马上2023，还是在修电脑的过程中度过，为程序奋斗的一年画上句号、祝愿各位的电脑利器更加畅快随心，在新的一年里创造新的，专属于自己的程序传奇。
----------最后，新年快乐！！！

软件工程师在开发前要提前注意规避对 Redis 性能有影响的操作，避免走“先污染后治理”的老路。如下是整理出来6条会导致 Redis 性能下降的原因，尽量避免这些操作出现在生产环境中。

1. 大键和大值

存储大键或大值可能会消耗更多的内存，并且在 Redis 进行网络和磁盘 I/O 操作时可能会增加延迟。

创建一个大键和大值：

SET bigkey "a".repeat(5242880)  # 创建一个5MB的大值

2. 阻塞操作

某些 Redis 命令，如 BLPOP、BRPOP、BRPOPLPUSH，可能会阻塞 Redis 进程。同样，Lua 脚本执行时间过长也可能导致阻塞。

如下 BLPOP 操作会阻塞 Redis 直到有元素被推入列表或者超时：

BLPOP mylist 0  # 0表示无限期等待

3. 过期键的处理

如果有大量的键同时过期，Redis 的性能可能会受到影响，因为 Redis 需要在后台清理这些过期的键。

创建一个大量即将过期的键：

for i in range(100000):

    EXPIRE key{i} 10  # 10秒后过期

4. 持久化

Redis 提供了两种持久化选项——RDB 和 AOF。RDB 是将当前进程数据生成快照保存的方式，而 AOF 是记录服务器收到的每一条写命令。频繁的持久化操作可能会增加磁盘 I/O 负载，从而影响性能。

启用 AOF 持久化并配置为每次有数据修改都立即写入磁盘（可能会影响性能）：

CONFIG SET appendonly yes

CONFIG SET appendfsync always

5. 使用复杂度高的命令

像 KEYS、SMEMBERS 或 HGETALL 这样的命令可能需要扫描整个集合，当数据集大时，它们可能会导致 Redis 暂时停止处理其他请求。

如 KEYS 命令，它会扫描整个键空间：

KEYS *

6. 内存使用过高

如果 Redis 服务器的内存使用接近或达到了其最大值，性能可能会受到影响。此外，如果你的数据集大于可用内存，那么操作系统可能会开始进行分页，这会大大降低 Redis 的性能。

使用 INFO memory 命令可以查看 Redis 的内存使用情况：

INFO memory

写在前面：

不知不觉已工作一年有余，好像毕业后的时光是一匹发疯的马，用尽全身气力疯狂向前，人生前半段是缓慢成长，后半程却加速变老。我以为越长大越沉默，没想到我还是一以贯之的废话一大堆。他日再回首时，恐已不复如今的心境，生活是值得记录的，无论好坏呀～

正文：

校招篇：面试官，你好

校招的记忆已然有点模糊了，有点后悔之前怎么没有记录生活。但我记得每次面试时的自我介绍，开场白的第一句话就是面试官，你好。我校招那一年互联网寒冬还不太寒，至少我周围熟悉的同学基本都手握好多大厂offer，所以当时有点小沮丧，总觉得自己菜菜的。也曾想过先去北京工作，不过考虑到我的性格以及离家近，最终还是选择来到成都。其实从小到大我没有什么目标，只是跟着周围同学朋友的节奏学习与生活，不掉队一路走到了现在，我不知道我喜欢什么，只是明确的知道不接受什么，排除掉不接受的，其他范围内我都可。

工作篇：我的前端初体验

依稀记得入职第一天，leader来楼下门口接的我，然后参加早会自我介绍与相互介绍，从此就正式开启了我的搬砖之路。刚入职时有好多不懂的，不懂开会时说的许多缩略词（连PM、PRD、RD啥的都不知道），还不懂从哪里开始看项目代码，对于提交代码、联调、部署、Nginx配置等环节，我就如同面对迷雾，一片茫然。挺感谢leader和同事们的指导与帮助，不仅仅是工作上的，还有帮助我融入团队，因为刚毕业时的我有点轻微社恐，不敢也不好意思多说话（然而现在笑声最大的就是我哈哈哈哈），虽然社恐不过我也是爱笑的社恐，即使很多不会，每天也是笑嘻嘻的，后来年终述职时同事的评价，以及晋升的其中一条理由，都是说我心态好哈哈哈哈哈哈。虽然网上挺多骂我司的，但从我自己的角度来看，我司的应届生培养确实还行，会给你充足的时间学习与成长，长期有耐心不仅仅是空口号。入职3个月时，我每天的工作还是培训和学习，除了已定的学习计划，mentor也会问我还有啥想学的嘛，可以调整。

当我害怕自己做不好时，同事：领导问啥都要说“好，能做到”，反正工作又不是造火箭，不难的，而且不会就问嘛。结果真的不难耶哈哈哈，人最大的恐惧是对未知的恐惧。当我出现了线上事故时，同事：这有啥，我以前还有更严重的，大家都是这么过来的。当我提前想工作跳槽时，同事：我是一年一跳，自从帮leader筛选简历后，才发现我还可以，你也要相信你是比较靠前的。还有好多诸如此类的对话，缓解了我的焦虑与迷茫，偷偷在这里谢谢大家呀。

后来我才开始慢慢接触项目，从最开始修改一个小bug，到后来完成一个小模块的开发，再到现在可以独立负责一个项目的开发上线。与刚入职时相比，现在更大的感受可能是更从容（也可能是开始摆烂哈哈哈），不再害怕新的任务不会怎么办，不再担心我的提问在别人看来是否有点笨笨的，不再纠结晚上早10分钟走会不会不太好……原来技术方案评审、CodeReview、述职等都没有想象中的可怕，很多事经历后才发现不过如此，一切都没关系哒。

生活篇：程序媛的日常

来成都后，经历了第一次震感强烈的地震，经历了高温限电于是居家办公，也见证了从全民防疫到全面放开。新冠全面放开后，leader说：大家如果身体有不适的就请假，别硬撑着，这只是一份工作而已。其他同事基本请了将近2周的假，我申请了一周，其实我只发烧了一天就没啥症状了，中间还去了一趟都江堰玩。后来的二阳、三阳大家都波澜不惊了。

程序员只是一份工作，并不是生活的全部，周围同事有沉迷于养花的，有每周都骑行一天的，也有喜欢跳舞的……至于我，喜欢美食，喜欢小裙子，喜欢一切可爱的东东(๑• . •๑)。成都真的有好多好吃的，至少很对我的胃口，来了以后胖了8斤多呜呜呜。

还有一个绕不开的话题，可能是我一生最悲伤的事情之一，工作一年时我的奶奶去世了，我哭了好久好久，现在提起仍然很难过，个中辛酸就不在此赘述了。

其实还经历了好多事，但有些事只适合收藏。凡所发生，必有来意，不管开心还是难过，都想记下那时的感受，等我老了再来看，当时开心的事我是否依然会笑，当初觉得悲痛万分的坎坷，是否又轻舟已过万重山了(^-^)

最后：

这篇博客是我工作总结系列的第一篇，我希望通过这个平台，记录我在编程之旅中的点点滴滴，记录代码之外的日常生活。如果通过分享我的经历和感受，或多或少能够帮助和鼓励更多的人，那就更好啦。

我想以喜欢的史铁生的一段话结尾～～
我一直要活到我能够历数前生，你能够与我一同笑看，所以死与你我从不相干。