前言

hi大家好，我是小鱼，今天复习的是z-index。之前以为自己很了解它，可是在工作中总会遇到一些不思其解的问题，后来去深入学习了层叠上下文、层叠等级、层叠顺序，才发现z-index只是其中的一叶小舟，今天就一起来看看它背后到底隐藏着什么。

z-index

.container {

  z-index: auto | <integer> ;

}

复制代码

• z-index 属性是允许给一个负值的。


• z-index 属性支持 CSS3 animation 动画。


• 在 CSS 2.1 的时候，需要配合 position 属性且值不为 static 时使用。

这个属性大家应该都很熟悉了，指定了元素及其子元素的 在 Z 轴上面的顺序，而 Z 轴上面的顺序 可以决定当元素发生覆盖的时候，哪个元素在上面。 z-index值大的元素会覆盖较低的。

不知道大家在工作中有没有遇到过这种情况，明明给其设置了z-index并且也设置了position不为static，但是样式并不是你所想的那样。可能这里大家对z-index不太了解，判断元素在Z轴上的顺序，不仅仅是z-index值的大小，接下来给大家解释层叠上下文、层叠等级和层叠顺序。

层叠上下文

层叠上下文(stacking context)，是HTML中一个三维的概念。如果一个元素含有层叠上下文，我们可以理解为这个元素在Z轴上就“高人一等”。

大家应该都玩过王者荣耀，里面的段位就是一个层级概念。你可以把「层叠上下文」理解为上了最强王者的人，还有很多没上王者的人，我们可以看成是菜鸡。那王者选手和菜鸡之间就形成了一个差距，这个差距也就是在Z轴上的距离，王者选手离荣耀王者就更近了一步，这里的“荣耀王者”可以看成是我们的屏幕观察者。

这样抽象解释完大家应该明白了什么是层叠上下文。继续往下看↓

层叠等级

层叠等级(stacking level)，决定了同一个层叠上下文中元素在Z轴上的显示顺序。这里又牵扯出一个level，那么这个等级指的又是什么呢？

所有的元素都有层叠等级，包括层叠上下文元素，层叠上下文元素的层叠等级可以理解为是什么普通王者，无双，荣耀传奇之类。然后，对于普通元素的层叠等级，我们的探讨仅仅局限在当前层叠上下文元素中。为什么呢？因为否则没有意义。

还是回到王者荣耀，元素具有层叠上下文就相当于是王者段位，但是王者里面又分为普通王者，无双王者和荣耀王者还有传奇王者，那我们如果拿普通王者的韩信和传奇王者的韩信相比较实际上是没有意义的，那不吊打吗，那他牛不牛逼是由段位决定的（排除一些意外情况哈哈哈）。

层叠上下文的创建

说白了就是一个元素如何才能变成层叠上下文元素？

层叠上下文是由一些特点的CSS属性创建的，分为三点：

1. 页面根元素天生具有层叠上下文，称之为“根层叠上下文”。


2. 普通元素设置position属性为非static值并设置z-index属性为具体数值，产生层叠上下文。


3. 其他CSS3中的新属性也可以
   
   
   
   1. flex 容器的子元素，且 z-index 值不为 auto
   
   
   2. grid 容器的子元素，且 z-index 值不为 auto
   
   
   3. opacity 属性值小于 1 的元素
   
   
   4. transform 属性值不为 none 的元素
   
   
   5. filter 属性值不为 none 的元素
   
   
   6. isolation 属性值为 isolate 的元素
   
   
   7. -webkit-overflow-scrolling 属性值为 touch 的元素；
   
   
   
   

简单写两个例子

栗子一

.box1,.box2 {

  position: relative;

  width: 100px;

  height: 100px;

}

.a,.c {

  width: 100px;

  height: 100px;

  position: absolute;

  font-size: 20px;

  padding: 5px;

  color: white;

  border: 1px solid rgb(119, 119, 119);

}

.a {

  background-color: rgb(0, 163, 168);

  z-index: 1;

}

.c {

  background-color: rgb(0, 168, 84);

  z-index: 2;

  left: 50px;

  top: -50px;

}



<div class="box1">

    <div class="a">A</div>

</div>

<div class="box2">

    <div class="c">C</div>

</div>

复制代码

因为box1，box2都没有设置z-index，所以没有创建层叠上下文，所以其子元素都处于‘根层叠上下文’中，在同一个层叠上下文领域，层叠水平值大的那一个覆盖小的那一个。

栗子2

只帖了修改部分

.box1 {

  z-index: 2;

}

.box2 {

  z-index: 1;

}



.a {

  background-color: rgb(0, 163, 168);

  z-index: 1;

}

.b {

  background-color: rgb(21, 84, 180);

  z-index: 2;

  left: 50px;

  top: 50px;

}

.c {

  background-color: rgb(0, 168, 84);

  z-index: 999;

  left: 100px;

  top: 50px;

}

复制代码

大家可以发现我们给C盒子设置的z-index为999远大于A、B两个盒子，效果却出现在他俩下面。那是因为给两个父盒子分别设置了z-index，创建了两个不同的层叠上下文，而box1的z-index值大，所以排在上面，这里验证了层叠等级。

栗子3

有一个父元素绝对定位，它有一个子元素也是绝对定位，父元素z-index大于子元素z-index，为何子元素还是在父元素的上面？如何让这个子元素放在父元素的下面。

.parent {

    width: 100%;

    height: 500px;

    background-color: rgb(243, 151, 45);

    position: absolute;

    z-index: 1;

}



.child {

    width: 20%;

    height: 150px;

    background-color: rgb(211, 56, 56);

    position: absolute;

    z-index: 0;

}



<div class="parent">

    <div class="child">C</div>

</div>

复制代码

效果却是这样

解决方案

1. 
   

   因为父元素和子元素之间，z-index是无法对比的，同级之间的z-index才能对比。可以考虑换一种方式，两个div做同级，外面包一层父元素，根据共同的父元素定位、做层级区分就可以。

   
   


2. 
   

   父元素不指定 z-index, 而子元素 z-index 为 -1

   
   

结论

普通元素的层叠等级优先由层叠上下文决定，所以，层叠等级的比较只有在当前层叠上下文元素中才有意义。

层叠顺序

层叠顺序(stacking order)，表示元素发生层叠时候有着特定的垂直显示顺序，注意，这里跟上面两个不一样，上面的层叠上下文和层叠等级是概念，而这里的层叠顺序是规则。

上图↓

在不考虑CSS3的情况下，当元素发生层叠时，层叠顺序遵循上面图中的规则。

这里稍微解释下为什么内联元素的层叠顺序要比浮动元素和块状元素都高？有些同学可能觉得浮动元素和块状元素要更屌一点，图中我标注了内联样式是内容，因为网页中最重要的是内容，文字和浮动图片的时候优先确保显示文字。

层叠准则

1. 谁大谁上： 当具有明显层叠等级的时候，在同一个层叠上下文领域，z-indx大的那一个覆盖小的那一个。


2. 后来居上： 当元素的层叠等级一致、层叠顺序相同的时候，在DOM流中处于后面的元素会覆盖前面的元素。

栗子4

.box1,.box2 {

  position: relative;

  width: 100px;

  height: 100px;

}

.box1 {

  z-index: 0;

}

.box2 {

  z-index: 0;

}

.a,.c {

  width: 100px;

  height: 100px;

  position: absolute;

  font-size: 20px;

  padding: 5px;

  color: white;

  border: 1px solid rgb(119, 119, 119);

}

.a {

  background-color: rgb(0, 163, 168);

  z-index: 999;

}

.c {

  background-color: rgb(0, 168, 84);

  z-index: 1;

  left: 50px;

  top: -50px;

}



<div class="box1">

    <div class="a">A</div>

</div>

<div class="box2">

    <div class="c">C</div>

</div>

复制代码

上面给两个父盒子都设置了z-index为0，这里要注意z-index一旦变成数值，哪怕是0，都会创建一个层叠上下文。当然层叠规则就发生了变化，子元素的层叠顺序比较变成了优先比较其父级的层叠上下文的层叠顺序，尽管a盒子的z-index为999。又由于两个父级都是z-index：0，层叠顺序这一块一样大，这个时候就遵循后来居上原则，根据DOM流中的位置决定谁在上面。也可以说子元素上面的z-index失效了！

end

回顾自己以前使用z-index都不太规范或者滥用，以后一定改正！

前言

不知道是大数据惹的祸，还是我的被迫害妄想症犯了,总是刷到一些哭笑不得的内行笑话系列，想反驳又觉得不该年轻气盛，憋了很久,还是觉得系统性的抒发一下,今天要聊的是关于程序界的鄙视链话题,各位老哥，如果有涉及程序语言部分，欢迎来杠。

主流鄙视链

语言

    🍺鄙视链的话题由来已久也一直存在,原本只是体现在适用性和从业选择方向上,像是之前有游戏梦想的基本主攻C、C++、MFC、DirectX、MFC、 QT, C# 以PC市场为主,后来的网页应用市场php、VB.NET、perl、asp.net、jsp、flex、flash应用鼎盛时期也占据半壁江山,塞班系统,塞班开发,以及手机市场昙花一现的各种手机应用开发语言，数据库也从sqlserve,oracle,mysql感觉是一段时间之后才慢慢进入视野,mogodb,时序库InfluxDB等等,后来的JQ、node、glup、boostrap、H5、canvas、angular、react、vue,、icon、antd、elment-ui再到混合开发多端应用,再到Objective-C、python、Goland、rust、deno等等等等。

编译器

    🍺编译工具从TurboC、VC6、Dreamweaver、VS2005-VS2022、Eclipse、MyEclipse、idea、Android Studio、WebStorm、vscode、HBuilder X,编辑器换了好几轮。

个体挣扎

    🍺很难想象短短的10几年时间里,经历了这么多轮换血和语言转换,很多过了鼎盛期已经被淘汰,很多半死不过的存续着,相信很多从业者也经历过某个语言从生到死的过程，一直都秉持着技多不压身的准则,一常备、一学习、一了解，虽然很多人都在杠,那个语言更底层,那个语言常青藤，那个语言生命周期最长，入门最难，我能理解，从事某一个语言耕耘良久突然宣告没有市场那种失落感,但这就跟历史一样，有其发展规律，历史框架下的人,都是规律的适应者，并非一成不变的，语言的高度也因其活跃度，主流面临解决的问题相关,所以其实跟绝大多数从业者半毛钱关系都没有,我们也只是受益者，并不代表你的高度到了那个层级,语言鄙视的说法就好像登山的人在嘲笑下山的人,不置可否。

上清下沉

    🍺在google还没离场,淘宝还没发家的前夜,微博、金山、PC端游还火爆,工具大神,搜狐还红的时候,还没有什么大厂、外包的提法,都是搞软件的,只是主攻方向不同,能成长能学习就行，公司好有些光环,解决问题是最重要的,后来，我听过一个理论，学历和大厂,至少能保证从业者是优质里面的顶尖部分，乍一听觉得没道理,后来想想，当面试那关的能力划等号,我是选硕士更充门脸还是选专科,用脚也能做出选择，长此以往的上清下沉，盘古开天，辅助以各种奇葩的企业文化,企业鄙视链的说法也就不足为奇了。

价值化

     🍺 “更好的值得更高的待遇”,工资待遇标签化,跟房子有了商业化属性一样,我比你拿的多，说明我方方面面碾压你,即使你不想被贴标签，也会被动的贴上标签，记得我从中型互联网转到传统企业时就被强制贴了一波标签，相信很多人摆平心态，也有这种无奈的体验，体验更差就是从出了名的外包场出来的,相信体感更差，如果你真的有计较，争论着低人一等，干同样的事儿，被区别对待，就跟秀才考功能，跟人攀比吃穿用度有什么差异。

乱象

• 🍗 有大神在买课，20多岁的架构师、一问缘由,算上加班，工作10年，之前一直是把这个东西当作调侃，没想到有人正儿八经的说出来了,听说现在软件培训费用就要几万，比上个大学还贵,教人在线面试，美化简历等等乱想，“我能有啥害人的心思呢，我只是想帮你”,我只是看上了你荷包里面跳动的money。


• 🍗 有人在孜孜不倦的教人python爬虫,“线上从入门到进去”,美化点的叫法叫数据采集、预处理,至于高端点儿的识别预测，算法类的东西,tensorflow一般人先不论你的机器跟不跟得上，学历已经卡出去大半人了，如果是测试自动化,稍微还好点儿,其他的真的就有点儿居心叵测了。


• 🍗 前几年直播编程号称几天0观看,后几年突然就多了,我始终理解不了,看视频能学到啥东西，正儿八经，有目标的实现某个功能目标,不才是正途吗?不知道是不是我太肤浅了。


• 🍗可能我不分端太久了,换了环境稍稍有点儿不适应,按理说,即使技术有语言有局限性，也不该分不清楚一些常规的状态码和逻辑主次关系,活脱脱完全限制了自己，把自己封印在了一个区域,这还是工作7-8年的,语言的多样性，会让我们的世界变的更大,当你不接受外部的内容,总耕耘在自己熟悉的领域，培养傲慢的同时,也会丧失敬畏。


• 🍗我不清楚这是不是普遍现象，前端面试多数只会问技术，不会涉及到功能闭环和业务,面了好几个,可能做的事情比较边角，也不会去试图理解做某一个应用的含义,完整性闭合性都说不出来,难道面的姿势不对,没有把准备的东西发挥出来，一到业务就避而不谈或者就说只做功能不涉及到业务。


• 🍗其后也莫名其妙面了报价30-40的,应该是30多，研究生,天然条件很好,其他的不论,只以面试论，我诧异的是，岗位属于业务擅长,着重点该在业务上,却神奇的写了一些技术,占了很大篇幅,问到具体的业务，条理分明的胡扯,或者涉密,问到技术又开始顾左右而言他。


• 🍗再有就是我很难相信,一个面试时综合能力还可以的人,业务能力为0的情况,可能王者天生爱执行吧。


• 🍗以上并不针对个人,只是想说明，做软件,很多人其实只是把它当作糊口的工具，本身其实并不喜欢这份工作,只是恰好工资相对较高,而且每个人对技术的追求分阶段不同,想法认知不同,很多情况要学会保留意见停止争论,待认知线在同一水准后,再适时决定，程序做久了要适当的学会拐弯,不然人为的屏障会越来越让你放弃沟通交流。

我的经历

接触

    🍺细算下来我最早涉及到编程接触的第一门语言是java,那会刚考上大学,得知被调剂到了软件,无所事事跑到网吧了解了一哈啥是编程,跑了个java计算器的例子,第一次有种掌控的感觉,也许这就是编程带来的魅力之一，掌控感，后来上学微机原理,TurboC 输出了第一个程序标配Hello World, 我记得看过一段话，一笔一划码出一个世界，我想我原本应该就是热爱编程的,爱泡图书馆看些软件杂书,记得因为上课在看机器人人工智能算法,被老师注意到,莫名其妙的神经网络BP，从C,C++,C#薅了三遍,后面连带又薅了一波人工智能动态寻路directx渲染的规避,最终没能成功去做游戏，感觉血亏。

过程

    🍺其后的工作经历之前也又提到过,无非就是遇山开山遇水开河,值得骄傲的是从来没因工作的地狱级难度退缩过，正儿八经外头的私活也整了又10年左右了，可能驳杂的技术体系也缘于此,心态比较重要,只要是能成长的都可以去学,熟悉的多了,就不会有恐惧感,我的很多技能点都属于外部创新,工作深挖实践过来的,信心需要培养，不知道你有没有这种中二的经历,每次解决一个疑难杂症,我总是不由自主的喊出来 “我TN真是个天才”，乐此不疲,也许这就是别人说的掌控感。

接触

    🍺我看到很多人在说在中国不过20年,没看到过35岁之后还搞程序的,我本能的忽略了年龄这个问题，其实之前我确确实实看到过一个老哥60岁了,还在搞C++,烟瘾特别大,几乎很短实践就搞出了包含算法预处理的专业软件,当时可能还在自我膨胀中,没有意识到这项工作从0-1的难度有好大,之后也和一个60岁的老哥相处过一段，可能是年龄大了,有些不受招呼,风评不咋好,一块聊过一段,给我们讲了他的当年,合伙创业,失败就业,总之也是波澜壮阔，还有之前我们的总监，40多了长得跟个20多岁的人一样,为人随和，可能相处下来，感受不到年龄的隔阂,给我一种感觉,大家都差不多,提笔回顾，恍惚之间才意识到，当然现在特别是今年，经济不好,再加上各种企业文化,我对我能持续多久有过担忧,但尽最大的努力,留最小的遗憾,是我一直以来,对事儿的态度，如果沉浸在焦虑中,会错过很多风景,反而是在焦虑中浪费了时光.

▨▨▨没什么具体的该怎么做,只能说,适当的多放下身段,多听听周围不同岗位的人对实现具体某一件事情，别人的认知和评判是怎样的,和自己的认知背离是什么原因造成的,自己的原因多补充相关知识,别人的原因多吸取经验教训,如果同一件事情,自己认为很难，充满抱怨,别人觉得简单，思路清晰的解决了问题,该是你充分学习经验的时候

悟道

    🍺戾气重的环境,让我们忘记了回溯，忘记了思考,很多的事情本能的忽略,软件"工具人"的称呼我并不排斥,但之前看贴的时候,看到很多人对这个称谓很不忿,觉得很恶心,但本质上，外包、中型厂、大厂“研发资源”的叫法会更好听吗？不是别人怎么叫,而是我们要认清不足,继续抵足前行，外部的杂音不足挂齿，内心的修炼与自身能力的强大才是我们该争取的,不想当将军的士兵，必然成不了将军,但想当将军的士兵,最终不一定会成为将军,只能说,行进的策略一直让我们时刻准备,时刻充实着,可能这是精神充实的一种“信仰”,但这不妨碍我时刻划定标准在进步着,所以忙着和别人攀比比较有什么意义呢,相较于环境与别人,改变自己才是最容易的吧。

原因刨析

💪关于大厂小厂之前一番讨论：

Me:事实上、有个很严重的分歧点在于，小厂更注重的是全面性，巴不得你从业务、前后端、框架、学习能力、设计能力、甚至商务以及交付能力都具备。往往从技术到支持都是考虑最低成本实现的，需要很强的灵活性和变通能力，而且很多业务都是在软件能力之上有行业经验要求的、所以降工资是一方面，还得适应变态的差异化开发习惯、

另外前段时间面试的时候发现个问题，纯前端有个很严重的弊端，最接近业务，却最不了解业务、问业务都不了解或者说不清楚闭环、

还有就是即便是技术专家、普遍的诉求其实当下不是开拓性市场、屠龙技需要平台才施展的开

前端早早聊:很有道理，大厂面试你的屠龙技，进去后拧 180 米长的复杂螺丝，不好拧，小厂面试你的螺丝功，进去后要求你用屠龙技，一个人全套搞定空间站，全能全干，两边点亮的技能点大有不同，需要的心态也大大不同

💪鄙视链的问题

语言鄙视

    很多讨论其实集中在语言的入门难易度,应用层级的问题,其实跟用这门语言的人关系不大,最接近的关系我能一直用这门语言存续多久,也就是我的语言技能会不会随着实践继续升值。
后端、前端的问题,这个本质是技术局限性引发的,很多事情不去做，只是评价的话,这和你嘲讽搞PPT的人，外行指导内行有什么差别。

年龄鄙视

    之前看到怪谈,通过不写注释,故意错乱结构来提高自己的存在价值,就事论事,能力是能力的问题，有些行为准则是人的问题,好多论调在说过了35岁,谁还需要去投简历，投简历的都是能力不行,还有别人已经挣够了,讲真的,靠打工致富毕竟是少数,都是机缘巧合，绝大部分人还是该忧虑就忧虑,"农民想象当皇帝用金锄头"，放开眼界,总有不一样的精彩。

学历鄙视

    早先的一段面试经历，感觉有震撼到我,我没想到还有公司会这么玩,找相关领域的开源作者挨个打电话,他们找到了一位开源作者，当时面我的作者也体验了一把被标签化,他说过一段 “语言只是工具,以实现功能为目的” ,听人力小姐姐介绍情况说,这个开源作者的神奇经历,高中辍学,一直是自由开发者,看了开源内容,质量很高,起点可能比很多人要差,但通过另外一种名片找到了归属，所以能力是真的会闪光，贵在坚持，至于卡学历等等的境遇，那也只说明你和这家公司的八字不合、换家便是。

技术鄙视

    大到社会，小到公司,我们都是职能链上被需要的,很多技术经验丰富的去做架构设计,但厌恶循环往复的业务调整,很多对工作推进执行做的很好的,却没法理解架构设计中一些“脱裤子放屁”的举动,团队中成员可以被替换,但职能分工是必须的，难不成要搞一堆技术大佬天天干仗不成。

待遇鄙视

    我们要为自己的选择负责,最终选定的工作,要么因为待遇高、要么因为压力小,如果你不慎踩坑,实在无法适应,多了解了解别人坚持下去的动机是啥、看到很多在抱怨“死都不去外包,侮辱人格,低人一等”,多想想能力和待遇插值,再有就是精神压力等等之类的,也比抱怨来的实在,大厂诉说着各种福利待遇,至于最终是其内里的红线、精神压力和健康付出状况,各种技术成长之类的，若真剔除自身的向上进取,于工作层面真有那么多高端的技术需要你去钻营嘛，就稳定性而言,我反而觉得大厂是最不受控的,因为真无关你的价值和能力，所以我觉得这个问题应该论证着看,并没有绝对的定性。

你的追求是什么？

    我曾梦想着用代码改变世界,结果我改变了我的代码,我梦想竹杖芒鞋轻胜马，谁怕？一蓑烟雨任平生快意恩仇，潇洒江湖，结果只能护住身前一尺一个家。我梦想达则兼济天下，穷则独善其身,结果我依然穷着，却做不到独善其身,事到如今，我还是会经常想起我的梦想,却也不愤恨自己平凡的半生,无非是,我做着自己喜欢做的事情，这个事情恰巧又是我的工作,我用它支撑着我弱不惊风的家，仅此而已,但也不仅限于此，至少我还在我代码的江湖,追逐着...

结束吧

    有点儿跑题了,最近实在是看到了很多怪像,希望留下你的经历,形成讨论,便于形成良性的参考价值,期待你的加入!!

PPS

    本来吐槽居多,后来枚举语言更替的时候,忽然觉得,历经这么多变迁,每个挣扎着的程序员,其实也在无奈中成就了平凡的伟大,心态开阔,多点儿包容！！！

看到这个标题，你肯定觉得离谱。怎么会有公司规定所有接口都用Post，是架构菜还是开发菜。这可不是夸大其词，这样的公司不少。

在特定的情况下，规定使用Post可以减少不少的麻烦，一起看看。

Answer the question

我们都知道，get请求一半用来获取服务器信息，post一般用来更新信息。get请求能做的，post都能做，get请求不能做的，post也都能做。

如果你的团队都是大佬，或者有着良好的团队规范，所有人都在平均水平线之上，并且有良好的纠错机制，那基本不会制定这样的规则。

但如果团队成员水平参差不齐，尤其是小团队，创业团队，常常上来就开干，没什么规范，纯靠开发者个人素质决定代码质量，这样的团队就不得不制定这样的规范。

毕竟可以减少非常多的问题，Post不用担心URL长度限制，也不会误用缓存。通过一个规则减少了出错的可能，这个决策性价比极高。

造成的结果：公司有新人进来，什么lj公司，还有这种要求，回去就在群里讲段子。

实际上都是有原因的。

有些外包公司或者提供第三方接口的公司也会选择只用Post，就是图个方便。

最佳实践

可能各位大佬都懂了哈，我还是给大家科普下，GET、POST、PUT、DELETE，他们的区别和用法。

GET

GET 方法用于从服务器检索数据。这是一种只读方法，因此它没有改变或损坏数据的风险，使用 GET 的请求应该只被用于获取数据。

GET API 是幂等的。 每次发出多个相同的请求都必须产生相同的结果，直到另一个 API（POST 或 PUT）更改了服务器上资源的状态。

POST

POST 方法用于将实体提交到指定的资源，通常导致在服务器上的状态变化或创建新资源。POST既不安全也不幂等，调用两个相同的 POST 请求将导致两个不同的资源包含相同的信息（资源 ID 除外）。

PUT

主要使用 PUT API更新现有资源（如果资源不存在，则 API 可能决定是否创建新资源）。

DELETE

DELETE 方法删除指定的资源。DELETE 操作是幂等的。如果您删除一个资源，它会从资源集合中删除。

这篇文章我们来聊一个很简单，但是很多人往往分不清的一个问题，同步异步、阻塞非阻塞到底怎么区分？

开篇先问大家一个问题：IO多路复用是同步IO还是异步IO？

先思考一下，再继续往下读。

巨著《Unix网络编程》将IO模型划分为5种，分别是

• 阻塞IO


• 非阻塞IO


• IO复用


• 信号驱动IO


• 异步IO

个人认为这么分类并不是很好，因为从字面上理解阻塞IO和非阻塞IO就已经是数学意义上的全集了，怎么又冒出了后边3种模型，会给初学者带来一些困扰。

接下来进入正文。

文章首发于公众号：「蝉沐风的码场」

1. 一个简单的IO流程

让我们先摒弃我们原本熟知的各种IO模型流程图，先看一个非常简单的IO流程，不涉及任何阻塞非阻塞、同步异步概念的图。

客户端发起系统调用之后，内核的操作可以被分成两步：

• 
  

  等待数据

  
  

  此阶段网络数据进入网卡，然后网卡将数据放到指定的内存位置，此过程CPU无感知。然后经过网卡发起硬中断，再经过软中断，内核线程将数据发送到socket的内核缓冲区中。

  
  


• 
  

  数据拷贝

  
  

  数据从socket的内核缓冲区拷贝到用户空间。

  
  

2. 阻塞与非阻塞

阻塞与非阻塞在API上区别在于socket是否设置了SOCK_NONBLOCK这个参数，默认情况下是阻塞的，设置了该参数则为非阻塞。

2.1 阻塞

假设socket为阻塞模式，则IO调用如下图所示。

当处于运行状态的用户线程发起recv系统调用时，如果socket内核缓冲区内没有数据，则内核会将当前线程投入睡眠，让出CPU的占用。

直到网络数据到达网卡，网卡DMA数据到内存，再经过硬中断、软中断，由内核线程唤醒用户线程。

此时socket的数据已经准备就绪，用户线程由用户态进入到内核态，执行数据拷贝，将数据从内核空间拷贝到用户空间，系统调用结束。此阶段，开发者通常认为用户线程处于等待（称为阻塞也行）状态，因为在用户态的角度上，线程确实啥也没干（虽然在内核态干得累死累活）。

2.2 非阻塞

如果将socket设置为非阻塞模式，调用便换了一副光景。

用户线程发起系统调用，如果socket内核缓冲区中没有数据，则系统调用立即返回，不会挂起线程。而线程会继续轮询，直到socket内核缓冲区内有数据为止。

如果socket内核缓冲区内有数据，则用户线程进入内核态，将数据从内核空间拷贝到用户空间，这一步和2.1小节没有区别。

3. 同步与异步

同步和异步主要看请求发起方对消息结果的获取方式，是主动获取还是被动通知。区别主要体现在数据拷贝阶段。

3.1 同步

同步我们其实已经见识过了，2.1节和2.2节中的数据拷贝阶段其实都是同步！

注：把同步的流程画在阻塞和非阻塞的第二阶段，并不是说阻塞和非阻塞的第二阶段只能搭配同步手段！

同步指的是数据到达socket内核缓冲区之后，由用户线程参与到数据拷贝过程中，直到数据从内核空间拷贝到用户空间。

因此，IO多路复用，对于应用程序而言，仍然只能算是一种同步，因为应用程序仍然花费时间等待IO结果，等待期间CPU要么用于遍历文件描述符的状态，要么用于休眠等待事件发生。

以select为例，用户线程发起select调用，会切换到内核空间，如果没有数据准备就绪，则用户线程阻塞到有数据来为止，select调用结束。结束之后用户线程获取到的只是「内核中有N个socket已经就绪」的这么一个信息，还需要用户线程对着1024长度的描述符数组进行遍历，才能获取到socket中的数据，这就是同步。

举个生活中的例子，我们给物流客服打电话询问我们的包裹是否已到达，如果未到达，我们就先睡一会儿，等到了之后客服给我们打电话把我们喊起来，然后我们屁颠屁颠地去快递驿站拿快递。这就是同步阻塞。

如果我们不想睡，就一直打电话问，直到包裹到了为止，然后再屁颠屁颠地去快递驿站拿快递。这就是同步非阻塞。

问题就是，能不能直接让物流的人把快递直接送到我家，别让我自己去拿啊！这就是异步。

3.2 理想的异步

我们理想中的完美异步应该是用户进程发起非阻塞调用，内核直接返回结果之后，用户线程可以立即处理下一个任务，只需要IO完成之后通过信号或回调函数的方式将数据传递给用户线程。如下图所示。

因此，在理想的异步环境下，数据准备阶段和数据拷贝阶段都是由内核完成的，不会对用户线程进行阻塞，这种内核级别的改进自然需要操作系统底层的功能支持。

3.3 现实的异步

现实比理想要骨感一些。

Linux内核并没有太惹眼的异步IO机制，这难不倒各路大神，比如Node的作者采用多线程模拟了这种异步效果。

比如让某个主线程执行主要的非IO逻辑操作，另外再起多个专门用于IO操作的线程，让IO线程进行阻塞IO或者非阻塞IO加轮询的方式来完成数据获取，通过IO线程和主线程之间通信进行数据传递，以此来实现异步。

还有一种方案是Windows上的IOCP，它在某种程度上提供了理想的异步，其内部依然采用的是多线程的原理，不过是内核级别的多线程。

遗憾的是，用Windows做服务器的项目并不是特别多，期待Linux在异步的领域上取得更大的进步吧。

4. 异步阻塞？

说完了同步异步、阻塞非阻塞，一个很自然的操作就是对他们进行排列组合。

• 同步阻塞


• 同步非阻塞


• 异步非阻塞


• 异步阻塞

但是异步阻塞是什么鬼？按照上文的解释，该IO模型在第一阶段应该是用户线程阻塞，等待数据；第二阶段应该是内核线程（或专门的IO线程）处理IO操作，然后把数据通过事件或者回调的方式通知用户线程，既然如此，那么第一步的阻塞完全没有必要啊！非阻塞调用，然后继续处理其他任务岂不是更好。

因此，压根不存在异步阻塞这种模型哦～

5. 千万分清主语是谁

最后给各位提个醒，和别人讨论阻塞非阻塞的时候千万要带上主语。

如果我问你，epoll是阻塞还是非阻塞？你怎么回答？

应该说，epoll_wait这个函数本身是阻塞的，但是epoll会将socket设置为非阻塞。因此单纯把epoll认为阻塞是太委屈它，认为其是非阻塞又抬举它。

具体关于epoll的说明可以参见IO多路复用中的epoll部分。

今年正式进入不惑之年。按 2011 年统计数据，国内 40 岁以上的程序员约是 1.5%，乐观来看，我进入了前 5% 的群体。

美国 2016 年此比例已经有 12.6%，大家还是应该乐观点。

大家都知道的国内第一代程序员，求伯君/雷军已经退休或做 CEO 了，而目前还在活跃的骨灰级程序员有陈皓（左耳朵耗子）。估计之后应该也会有越来越多的老程序员，或者说是目前活跃的程序员变成老程序员，出现在大家的视野。

程序员这个职业发展起来也就 20 年，还是一个很年轻的职业，年龄焦虑这个事情着实没有必要。

换位思考一下，如果我是公司的技术招聘者，15年内工作经验的都是大有前途的，只要你技术过得去，价格合理，我都愿意招你。

相反，15年以上的程序员就没那么受欢迎了。

因为初入职场就是互联网的蓬勃发展期，人才短缺是一直存在的，知识积累不够不要紧，个人品行不妥也不要紧，只要你敢于承担一些压力，那你的职业道路都会比较顺畅。如果再幸运一些，就能进入大厂。

但是，这也造成了一些不良的现象，在这行业，投机份子其实挺多的。什么热门就跟风炒一炒，能不能做成不要紧，最主要是自己的 KPI 好看。另外，互联网企业的优待，让他们多少有些娇气。从大厂出来，薪资待遇要翻倍，要股票要期权，要好资源要好项目。

所以，一般的公司未必能容纳这些人。他们也未必愿意去这些公司。于是，35岁危机就来了。

年轻人其实是很难感受到中年危机的，中年危机与年轻失业的区别就像新冠与感冒的区别。你以为你经历了中年危机，实际上只是年轻失业。

今年经济不景气，裁员潮估计让一部分人离开了这个行业。年纪大的想要回炉再造，是很难的。但是，如果你还年轻，平时多积累，我相信能很轻松地找到一份工作的。

如何面对危机？

年轻人都会说苟住，换个正能量的说法是活在当下。

读好书、做好事，是能切切实实忘掉焦虑的。

今年读的《反脆弱》、《心流》和《毫无意义的工作》，将这三本书放在一起，还是很有意思的，能看到不同的观点：

• 
  

  《反脆弱》让我对工作也有了新认识。看似很稳定的工作，会有可能让你过度依赖，如果遭遇失业就手足无措了。而类似的士司机，饿一餐饱一顿的，反而平时就很有充足的经验应对收入不稳定的情况。

  
  

  今年的形势让人更趋于进入大公司、国企、公务员单位，然后这些稳定的工作就真的这么值得大家去追随吗？越是追求稳定，最后是否会适得其反？

  
  


• 
  

  《毫无意义的工作》今年敲醒了不少人，他提醒我们，日常琐碎的工作中消磨了我们的生命。然而这本书更多是情绪的宣泄，并没有什么好的解决方法。

  
  


• 
  

  而《心流》则希望我们投入去做事情，只有投入了才会获得心流，才会有幸福感。同时，它让我意识到，无法逃避的事实是，工作占了我们生命的 1/4 时间。如果无法从中获得乐趣，那我们的人生注定是悲剧的。

  
  

这几本书都让我重新思考我与工作的关系，即使今年外部恶劣的情况，我们也应该重拾自身的信心，重新找回我们的热情、专注。

在面对人员缩减，项目被砍的情况下，我们也许可以把目光放在现有的项目上。

就前端而言，SSR 做不了，Docker 做不了，那就看看 nginx 缓存优化能不能做；低代码做不了，那就看看页面模板能不能做；开源做不了，就看看公共组件能不能做；什么都做不了，那首屏优化，静态资源优化，图片压缩也是能做的，而且还能做得很深。

只要你想，总有做不完的事情。并且这些事情，其实是我们要还的技术债务。

而此时也是做好技术积累的时机。

面向对象、设计模式、函数式编程、类型编程、异步编程这些基础都可以恶补一下；网络安全、网络通信、内存、CPU等等向外延伸的各类计算机知识也是我们必须掌握的。

工作上认真对待自己的每一行代码，生活中认真对待自己的每一分钱。

深挖知识，深入研究，懂得越多，焦虑自然就越少。

有足够的知识与经验，你的中年危机也许永远不会来

最后，对于年龄的焦虑，再推荐大家看看方励老师在“一席”的演讲《即使是像我这把年龄的人，好奇心也从来没变过，因为我们还活在人间的》

这次我谈谈不吃亏的一种人，他们不吃亏近乎强硬。这类人一点亏都不吃，以至于过度自我保护。

我们公司人事小刘负责考勤统计。发完考勤表之后，有个员工找到他，说出勤少统计了一天。

小刘一听，感觉自己有被指控的风险。

他立刻严厉起来：“每天都来公司，不一定就算全勤。没打卡我是不统计的”。

最后小刘一查，发现是自己统计错了。

小刘反而更加强势了：“这种事情，你应该早点跟我反馈，而且多催着我确认。你自己的事情都不上心，扣个钱啥的只能自己兜着”

这就是明显的不愿意吃亏，即使自己错了，也不愿意让自己置于弱势。

你的反应，决定别人怎么对你。这种连言语的亏都不吃的人，并不会让别人敬畏，反而会让人厌恶，进而影响沟通。

我还有一个同事老王。他是一个职场老人，性格嘻嘻哈哈，业务能力也很强。

以前同事小赵和老王合作的时候，小赵宁愿经两层人传话给老王，也不愿意和他直接沟通。

我当时感觉小赵不善于沟通。

后来，当我和老王合作的时候，才体会到小赵的痛苦。

因为，老王是一个什么亏都不吃的人，谁来找他理论，他就怼谁。

你告诉他有疏漏，他会极力掩盖问题，并且怒怼你愚昧无知。

就算你告诉他，说他家着火了。他首先说没有。你一指那不是烧着的吗？他回复，你懂个屁，你知道我几套房吗？我说的是我另一个家没着火。

有不少人，从不吃亏，无论什么情况，都不会让自己处于弱势。

这类人喜欢大呼小叫，你不小心踩他脚了，他会大喊：践踏我的尊严，和你拼了！

心理学讲，愤怒源于恐惧，因为他想逃避当前不利的局面。

人总会遇到各种不公的待遇，或误会，或委屈。

遇到争议时，最好需要确认一下，排除自己的问题。

如果自己没错，那么比较好的做法就是：“我认为你说得不合理，首先……其次……最后……”。

不盲目服软，也不得理不饶人，全程平心静气，有理有据。这种人绝对人格魅力爆棚，让人敬佩。

最后，有时候过度强硬也是一种策略，可以很好地过滤和震慑一些不重要的事物。

22年，连续跳了二三家公司，辗转七八个城市。

可能还是太年轻，工作上特别急躁，加班太多会觉得太累，没事情做又觉得无聊烦躁。去年年末回老家过年因为一些巧合遇见了她。年初就润，回到了老家。当时因为苏州疫情就没回去，便开始在老家这边的坎坷之旅。

年初千里见网友

说起来也是缘分，去年年末的时候，有个人加了我微信，当时也是一头雾水，还以为是传销或者什么。一看名字微信名：“xxx”，也不像是啊，当时没放在心上就随便聊了聊，也没咋放心上。后来我朋友告诉我她推的（因为觉得我挺清秀人品也还行），就把她推给了我。但是我这人自卑又社恐，加上她在我老家那边，就想反正自己好多年也不想回老家那个地方，现在即使网恋也是耽误人家，后面就没咋搭理她。

到过年的时候，我和我妈匆匆忙忙回到了老家，当时家里宅基地刚好重建装修完，背了一屁股的债务，当时很多人劝我不要建房子在老家，有钱直接在省会那边付个首付也比老家强，可我一直觉得这个房子是我奶奶心心念念了一辈子的事情。转念一想一辈人有一辈人的使命，最多就是自己再多奋斗几年就没多去计较。


后面过年期间，我和她某明奇妙的聊起来了，可能是我觉得离她近了，然后就有一丝丝念想吧，当时因为一些特殊原因，过年的时她也在上班。那几天基本每天从早聊到晚，稍微有点暧昧，之后还一起玩游戏，玩了几局，我也很菜没能赢，就这样算是更深一步了解她吧，当时也不好断定她是怎样的人。就觉得她很温柔、活泼、可爱、直爽，后面想了想好像很久好久没用遇到这样的女孩子了吧，前几年也遇到不少女孩子都没有这种感觉。是不是自己单身太久产生的幻觉。经过一段时间的发酵，我向我朋友打听了下她。


我朋友说人品没问题，就是有点矮，我想着女孩子没啥影响，反正我也矮。就决定去见见她，她也没拒绝我。缘分到了如果不抓住的话也不知道下一次是什么时候。其实那时候我们还只是看过照片，彼此感觉都是那种一般人，到了这个年纪（毕业二三年）其实都不是太在乎颜值，只要不是丑得不能见人（颜值好的话肯定是加分项）。虽然我们都在老家，但她兼职那边还是有点远，去那边需要转很多车。但也没什么，我义无反顾去见了他，也许这就是大多数人奔现的样子吧（但我心里是比较排斥这个词的）。


那天早上一大早我就急冲冲起来了，洗个了头，吹了个自认为很帅的发型，戴上小围巾就出发了（那晚上其实下了很大的雪）。因为老家比较远我都比较害怕那边没有班车，因为当时才大年初三，我们那边的习俗是过年几天不跑车，跑车一年的财运都会受影响。到路上果然没让我失望，路上一辆车都没有，也是运气好，我前几天刚好听到我表姐说要去城里，我就问了问，果真就今天去（就觉得很巧合，跟剧本一样），他们把我送到高铁站，道了个谢，就跑去赶了最早一班的高铁。


怀着忐忑的心情出发了，那时差不多路上就是这个样子吧（手机里视频传不上去）。

在路上的时候她一直强调说自己这样不行，那样不可以怕我嫌弃，我当时倒是不自卑，直接对人家就是一顿安慰。到了省会那边，又辗转几个地方去买花，那时过年基本没什么花店开门。转了几个大的花店市场才发现一家花店，订了一束不大不小的花， 又去超市买了个玩偶和巧克力，放了几颗德芙在衣服包里面（小心机）。前前后后忙完这些已经下午一点了，对比下行程，可能有点赶不上车了。匆忙坐了班车到了她上班那个市区 ，本以为一切都会很顺利，结果到了那边转车的班车停运了，当时其实是迷茫的。不知道要不要住宿等到第二天。


那时我想起本来就是一腔热情才跑过来的，也许过了那个劲就不会有那个动力去面对了，心里默想：“所爱隔山海，山海皆可平”。心疼的打了个车花了差不多五百块（大冤种过年被宰）。就这样踏上最后一段路程。路上见到不一样的山峰，矮而尖而且很密集，那个司机说天眼好像就是建筑在这边吧，路上我就一直想：即使人家见了我嫌弃我这段旅行也算很划算的吧。最终晚上七点到达了目的地，下车了还是有点紧张，我害怕她不喜欢我这样的，毕竟了解不多，也许就是你一厢情愿的认为这就是缘分和命运的安排。

终将相遇

最后一刻，我都还在想，她会不会看到我就跑了，然后不来见我。但应该不至于此，毕竟我相信我的老朋友（七年死党），也相信她的人品。我看见一个人从前面走来我还以为是她，都准备迎上去了，走近一看咋是个阿姨（吓我一跳还以为被骗了），等我反应过来那个阿姨已经走远了。然后一个声音从我对面传来：“我在这，我在这边”，我转头过去惊艳到我了，这这这是本人吗？深邃的眼眸，樱桃小嘴，不是很尖的脸蛋，短发到肩，微风吹起刘海飘啊飘，像飘进了我的心里，头后发带将一些头发束起，然后发带结成蝴蝶结，一身长白棉袄配白皮鞋，显得俏皮又惊艳。我还来不及细想，我就迎了过去，提前想好的台词都没有说出来，倒是显得有一些尴尬。


当时自卑感油然而生，自己觉得配不上她。寒暄了几句我将花递给她，没有惊喜的表情，只有一句：我都没给你准备什么礼物，你这样我会很不好意思的，她这样说我该是开心还是难过呢？我心里觉得大概要凉了。就怕一句：你是个好人，我们就这样吧。其实当时我们也没说啥喜欢啥的就是有点暧昧。所幸没有发生她嫌弃我的事情，我们延着路边一路闲聊下去，一开始我还有点拘谨，毕竟常年当程序员社交能力不是很行。


慢慢的，我们说了很多很多，她请我吃了个饭（之前说过请她没倔过她），一路走着走着，说着大学的事，小时候的事，工作的事，一时间显得我们不是陌生人，而是多年未见的好友，一下子就觉得很轻松很幸福，反正我已经深深的迷上她的人美心善。她也说了离家老远跑来这边上班的原因（不方便透露）。走着走着我发现她的手有点红，就说道：我还给你准备了个惊喜，把手伸进我衣服包里吧，我在里面放了几颗糖，上班那么辛苦有点糖就不苦了。后面我有点唐突抓住她的手，我说给她暖一下太冰了。她说放我包里就暖和了，我看她脸都红了，也觉得有点唐突了。后面发现还是太冰了，没多想就用牵住了她，嘿嘿！她直接害羞的低下了头。一下子幸福感就涌上来了。


后面很晚的时候要分别了，送他回了宿舍，并把包里的玩偶以及剩下的零食一并给了她。她说第二天来送我，我便回了酒店。


第二天我们俩随便吃了点东西（依旧很害羞没敢坐我对面），她就送我上车了，临走时她塞了一个东西在我手里，打开一看昨天的发带，抬头她已走远她小声说了一句：我们有缘再见。也许是想着我在苏州她在遵义太远了吧，可能就是最后一面了，有点伤心也没多问。

感情生活波折

回去的第二天我便回到苏州那边，但是很久之前就谋划着辞职，一方面是觉得在这边技术得不到提升，一方面是觉得想换个环境吧，毕竟这边太闲了让我找不到价值。可能年轻急躁当时没多想就直接裸辞了，期间我对她说：我辞职后来看她，她有点不愿意（说感觉我们的感情有点空中楼阁），可能觉得见一面不足以确定什么吧，我可能觉得给不了他幸福也舍不得割舍吧。


后面裸辞后，蹭着苏州没有因为疫情封禁，直接带了二件衣服就回了老家。（具体细节不说了）


第二次见她，可能觉得有点陌生吧，不过慢慢的就过了那个尴尬期，我们一起去逛公园、去逛街、彼此送小礼物、一起吃饭，即使现在回来依旧觉得很美好。但是我依旧没有表白，可能我觉得这些事顺理成章的不需要。一次巧合我去了她家帮她做家务、洗头、做饭。哈哈哈，像一个家庭主男一样。可能就是那次她才真的喜欢上我的吧。


有一次见面之后因为一些很严重的事我们吵架了，本来以为就要在此结束了。后来我又去见她了，我觉得女孩子有什么顾虑很正常的，也许是不够喜欢啥的，准备最后见一面吧，但见面之后准备好的说辞一句没说，还是像原来那样相处，一下子心里就有点矛盾，后面敞开心扉说开了，心里纠结的问题也就解决了。慢慢的我们也彼此接受了，从一见钟情到建立关系，真的经历很多东西。不管是少了那一段经历我和她都不会有以后。我的果决她的温柔都是缺一不可的。

后续

她考研上岸，我离开苏州在贵阳上班。我们依旧还有很长一段路要走。后续把工作篇发出来（干web前端的）

前几天是 10 月 24 日，有关注股票的同学，相信大家都过了一个非常难忘的程序员节吧。在此，先祝各位朋友们身体健康，股票基金少亏点，最重要的是不被毕业。

抱歉，当了回标题党，不过在做这个决定之前确实纠结了很久，权衡了各种利弊，就我个人而言，不比「3Q 大战」时腾讯做的「艰难的决定」来的轻松。如今距离这个决定过去了快 3 个月，我也还在适应着这个决定带来的变化。

按照工作汇报的习惯，先说结论：

在北漂整整 10 年后，我回老家合肥上班了

做出这个决定的唯一原因：

没有北京户口，积分落户陪跑了三年，目测 45 岁之前落不上

户口搞不定，意味着孩子将来在北京只能考高职，这断然是不能接受的；所以一开始是打算在北京读几年小学后再回老家，我也能多赚点钱，两全其美。

因为我是一个人在北京，如果在北京上小学，就得让我老婆或者让我父母过来。可是我老婆的职业在北京很难就业，我父母年龄大了，北京人生地不熟的，而且那 P 点大的房子，住的也憋屈。而将来一定是要回去读书的，这相当于他们陪着我在北京折腾了。

或者我继续在北京打工赚钱，老婆孩子仍然在老家？之前的 6 年基本都是我老婆在教育和陪伴孩子，我除了逢年过节，每个月回去一到两趟。孩子天生过敏体质，经常要往医院跑，生病时我也帮不上忙，所以时常被抱怨”丧偶式育儿“，我也只能跟渣男一样说些”多喝热水“之类的废话。今年由于那啥，有整整 4 个多月没回家了，孩子都差点”笑问客从何处来“了。。。

5月中旬，积分落户截止，看到贴吧上网友晒出的分数和排名，预计今年的分数线是 105.4，而实际分数线是 105.42，比去年的 100.88 多了 4.54 分。而一般人的年自然增长分数是 4 分，这意味着如果没有特殊加分，永远赶不上分数线的增长。我今年的分数是 90.8，排名 60000 左右，每年 6000 个名额，即使没有人弯道超车，落户也得 10 年后了，孩子都上高一了，不能在初二之前搞到户口，就表示和大学说拜拜了。

经过我的一番仔细的测算，甚至用了杠杆原理和人品守恒定理等复杂公式，最终得到了如下结论：

我这辈子与北京户口无缘了

所以，思前想后，在没有户口的前提下，无论是老婆孩子来北京，还是继续之前的异地，都不是好的解决方案。既然将来孩子一定是在合肥高考，为了减少不必要的折腾，那就只剩唯一的选择了，我回合肥上班，兼顾下家里。

看上去是个挺自然的选择，但是：

我在腾讯是组长，团队 20 余人；回去是普通工程师，工资比腾讯打骨折

不得不说，合肥真的是互联网洼地，就没几个公司招人，更别说薪资匹配和管理岗位了。因此，回合肥意味着我要放弃”高薪“和来之不易的”管理“职位，从头开始，加上合肥这互联网环境，基本是给我的职业生涯判了死刑。所以在 5 月底之前就没考虑过这个选项，甚至 3 月份时还买了个显示器和 1.6m * 0.8m 的大桌子，在北京继续大干一场，而在之前的 10 年里，我都是用笔记本干活的，从未用过外接显示器。

5 月初，脉脉开始频繁传出毕业的事，我所在的部门因为是盈利的，没有毕业的风险。但是营收压力巨大，作为底层的管理者，每天需要处理非常非常多的来自上级、下级以及甲方的繁杂事务，上半年几乎都是凌晨 1 点之后才能睡觉。所以，回去当个普通工程师，每天干完手里的活就跑路，貌似也不是那么不能接受。毕竟自己也当过几年 leader 了，leader 对自己而言也没那么神秘，况且我这还是主动激流勇退，又不是被撸下来的。好吧，也只能这样安慰自己了，中年人，要学会跟自己和解。后面有空时，我分享下作为 leader 和普通工程师所看到的不一样的东西。

在艰难地说服自己接受之后，剩下的就是走各种流程了：

1. 5月底，联系在合肥工作的同学帮忙内推；6月初,通过面试。我就找了一家，其他家估计性价比不行，也不想继续面了

2. 6月底告诉总监，7月中旬告诉团队，陆续约或被约吃散伙饭

3. 7月29日，下午办完离职手续，晚上坐卧铺离开北京

4. 8月1日，到新公司报道

7 月份时，我还干了一件大事，耗时两整天，历经 1200 公里，不惧烈日与暴雨，把我的本田 125 踏板摩托车从北京骑到了合肥，没有拍视频，只能用高德的导航记录作为证据了：

这是导航中断的地方，晚上能见度不行，在山东花了 70 大洋，随便找了个宾馆住下了，第二天早上出发时拍的，发现居然是水泊梁山附近，差点落草为寇：

骑车这两天，路上发生了挺多有意思的事，以后有时间再分享。到家那天，是我的结婚 10 周年纪念日，我没有提前说我要回来，更没说骑着摩托车回来，当我告诉孩子他妈时，问她我是不是很牛逼，得到的答复是：

我觉得你是傻逼

言归正传，在离开北京前几天，我找团队里的同学都聊了聊，对我的选择，非常鲜明的形成了两个派系：

1. 未婚 || 工作 5 年以内的：不理解，为啥放弃管理岗位，未来本可以有更好的发展的，太可惜了，打骨折的降薪更不能接受



2. 已婚 || 工作 5 年以上的：理解，支持，甚至羡慕；既然迟早都要回去，那就早点回，多陪陪家人，年龄大了更不好回；降薪很正常，跟房价也同步，不能既要又要

复制代码

确实，不同的人生阶段有着不同的想法，我现在是第 2 阶段，需要兼顾家庭和工作了，不能像之前那样把工作当成唯一爱好了。

在家上班的日子挺好的，现在加班不多，就是稍微有点远，单趟得 1 个小时左右。晚上和周末可以陪孩子玩玩，虽然他不喜欢跟我玩🐶。哦，对了，我还有个重要任务 - 做饭和洗碗。真的是悔不当初啊，我就不应该说会做饭的，更不应该把饭做的那么好吃，现在变成我工作以外的最重要的业务了。。。

比较难受的是，现在公司的机器配置一般，M1 的 MBP，16G 内存，512G 硬盘，2K 显示器。除了 CPU 还行，内存和硬盘，都是快 10 年前的配置了，就这还得用上 3 年，想想就头疼，省钱省在刀刃上了，属于是。作为对比，腾讯的机器配置是：

M1 Pro MBP，32G 内存 + 1T SSD + 4K 显示器

客户端开发，再额外配置一台 27寸的 iMac(i9 + 32G内存 + 1T SSD)

由奢入俭难，在习惯了高配置机器后，现在的机器总觉得速度不行，即使很多时候，它和高配机没有区别。作为开发，尤其是客户端开发，AndroidStudio/Xcode 都是内存大户，16G 实在是捉襟见肘，非常影响搬砖效率。公司不允许用自己的电脑，否则我就自己买台 64G 内存的 MBP 干活用了。不过，换个角度，编译时间变长，公司提供了带薪摸鱼的机会，也可以算是个福利🐶

另外，比较失落的就是每个月发工资的日子了，比之前少了太多了，说没感觉是不可能的，还在努力适应中。不过这都是小事，毕竟年底发年终奖时，会更加失落，hhhh😭😭😭😭

先写这么多吧，后面有时间的话，再分享一些有意思的事吧，工作上的或生活上的。

遥想去年码农节时，我还在考虑把房子从昌平换到海淀，好让孩子能有个“海淀学籍”，当时还做了点笔记：

没想到，一年后的我回合肥了，更想不到一年后的腾讯，股价竟然从 500 跌到 206 了(10月28日，200.8 了)。真的是世事难料，大家保重身体，好好活着，多陪陪家人，一起静待春暖花开💪🏻💪🏻

前言

前几天写了一篇对跨端通讯的思考，当时顺便想到了数据这一块，所以也可以整理一下，单独拿出来说说平时开发中涉及到哪些对数据的处理方式。

Base64

之前详细写过一篇关于Base64的文章

juejin.cn/post/715584…

简单来说，Base64就是把你的数据转成只有64个无特殊符号的字符，主要常用于加密后之类的生成的字节数组，转成Base64方便进行数据传输，如果不转的话就会是乱码，会看得很难受，这些乱码在某些编码下展示出来的是豆腐块，有点扯远了。

还有就是比如中文啊，emoji啊这类的字符，在某些情况下也需要转成Base64进行传输。

缺点就是只用64个字符表示，还有我之前分析过base64的转换原理，通过其原理能很容易看出，最终的转换结果相比转换前的数据更加长。

JSON/XML

这些就比较常见了，对数据按照一定的格式进行封装。为什么要说这个呢？因为他这些封装是约定熟成的方式，和上面的Base64的转换方式就不同，相当于是大家约定好按照这个格式包装数据，然后传输，自己再按照这个格式去解开拿到数据。

多数用于跨端传输，像客户端请求服务端拿数据，那不也就是跨端嘛，其实这个所有人都用到，但为什么说这个呢？还是那个跨端通信的问题，跨端通信没办法直接传对象，实际传对象的效果是转json传的String，然后另外一端再创建一个自己端的对象，解析json，把json数据填充进去。

还有，既然是约定的，那其实我们自己也可以按照我们自己的约定去做跨端的数据传送，只不过json这种格式，是已经设计得很好了，你很难再去约定一种比这个格式更好的封装。

PS：不要觉得json大家都在用，都形成肌肉记忆了，没有什么难的。其实比如像gson\fastjson这些，人家去研究解析json的算法，也是一个技术点。你觉得简单，那是因为你在使用，但让你从0去做，你不一定能做出来。

URL编码

又叫做urlencode，顾名思义用于url连接中的一种对数据的操作。

它将特殊字符转成16进制并且在前面加%，那同理解析拿数据的时候也是根据%去做判断。

为什么会出现这种编码呢？主要是为了防止冲突，我们都知道比如get请求都会在url链接后面拼参数，防止在传输中出现问题，所以把特殊字符都进行编码。

比如http://www.baidu.com/?aaaaaaa 会编码成https%3A%2F%2Fwww.baidu.com%2F%3Faaaaaaa

该编码主要用于对url的处理。

驼峰和下划线

这其实是一个命名方式，不同的端有不同的命名习惯，比如java习惯就是用驼峰，但是还是跨端问题，有些时候存在写死的情况，当然这个代码不是你写的，也可能是前人留下的（我没有暗示什么）。但如果你的代码中出现两种命名方式会让代码看着比较乱。没关系我们可以做个转换，我这里以下划线转驼峰为例

private String lineToHump(String str) {

    if (TextUtils.isEmpty(str)) {

        return str;

    }



    String[] strs = str.split("_");

    if (strs.length < 2) {

        return str;

    }



    StringBuilder result = new StringBuilder(strs[0]);

    for (int i = 1; i < strs.length; i++) {

        String upper = (strs[i].charAt(0) + "").toUpperCase();

        if (strs[i].length() > 1) {

            result.append(upper).append(strs[i].substring(1));

        } else {

            result.append(upper);

        }

    }

    return result.toString();

}

可以写个转换方法，我这里只是随便写个Demo，这段代码是还能进行优化的，主要大概就是这个意思。

上面说的json主要是为了说数据的封装和解封，这里主要是说数据的转换，我的意思是在开发中，我们也会出现不同端的数据形式不同，我们不需要在代码中向其它端进行妥协，只用写个方法去做数据的转换，在本端还是正常写本端的代码就行。

摘要

摘要算法，简单来说就是将原数据以一种算法生成一段很小的新数据，这段新数据主要是用来标识这段原数据。怎么还有点绕，总之就是生成一个字符串来标识原数据 。对任意一组输入数据进行计算，得到一个固定长度的输出。

也可称之为哈希算法，最重要的是它取决于它的这个设计思想，它是一个不可能逆的过程，一般不能根据摘要拿到原数据，注意我用了一般，因为这个世界上存在很多老六。

摘要算法中当前最经典的是SHA算法和MD算法，SHA-1、SHA-256和MD5。其中他们加密过程可以单独写一篇文章来说，这里就不过多解释。

摘要算法最主要的运用场景是校验数据的完整性和是否有被篡改。比如CA证书的校验，android签名的校验，会拿原数据做摘要和传过来的摘要相对比，是否一样，如果不一样说明数据有被篡改过。再比如我本地有个视频，我怎么判断后台这个视频是不是更新了，要不要下载，可以对视频文件做MD5，然后和后台文件的MD5进行对比，如果一样说明视频没有更新，如果不一样说明视频有更新或者本地的视频不完整（PS：对文件做摘要可是一个耗时的过程。）

加密

讲完摘要可以趁热打铁说说加密，加密顾名思义就是把明文数据转成密文，然后另一方拿到密文之后再转成明文。

加密和摘要不同在于，它们的本质都不同，摘要是为了验证数据，加密是为了安全传输数据。它们在表现上的不同体现在，摘要是不可逆，加密是可逆的。

加密在当前的设计上又分为对称加密和非对称加密，主流的对称加密是AES算法，主流的非对称加密是RSA算法。对称加密的加密和解密使用的密钥是相同的，非对称是不同的 ，所以非对称加密更为安全，但是也会更耗时。

当然你也可以不用这些算法，如果你是直接接触这些算法，好像是要付专利费的，每年给多少钱别人才给你用这个算法，资本家不就喜欢搞这种东西吗？扯远了。你也可以使用自己约定的算法，只不过在高手面前可能你的算法相当于裸奔，要是你真能设计出和这些算法旗鼓相当的算法，你也不会来看我这么捞的文章。

所以加密，是为了保证数据的安全，如果你传输的数据觉得被看了也无所谓，那就不用加密，因为它耗时。如果你只是为了防止数据被改，也不用加密，用摘要就行。如果你是为了传输seed，那我建议你加密[狗头]

通信协议

json那里我们有说，它就是双方约定好的数据格式。以小见大，通信协议也是双方约定的一种数据传输的过程。通信协议会更为严谨，而且会很多不同，各家有各家的通信协议，不是像json这种就是大家都用一样的。

比如我们的网络传输，就有很多协议，http协议、tcpip协议等，这些在网络中是规定好的，大家都用这一套。再比如蓝牙协议，也是要按照同一个规范去使用。但是硬件的协议就多种多样了，不同的硬件厂商会定义不同的通信协议。

二维码

二维码也是对数据封装的一种形式，可以通过把数据变成图像，然后是扫码后再获取到数据，这么一种模式我感觉能想出这个法子的人挺牛逼的。

它所涉及的内容很多，具体可以参考这篇文章，我觉得这个大佬写得挺好的 二维码生成原理 - 知乎 (zhihu.com)

我之前自己去用java实现，最终没画出来，感觉原理是没问题的，应该是我哪里细节没处理好，这里就简单介绍一下就行。其实简单来说，它就是有一个模板的情况下，把数据填充到模板里面。

这里借大佬的图，模板就是这样的

然后按照规则去填充数据

这样去填充，其实会让黑点分布不均匀，填充之后还会做一个转换。

但是二维码也有缺点，缺点就是数据量大的时候，你的二维码很难被识别出，但是不得不说能想出这个方法，能设计出这个东西的人，确实牛逼。

马上就要到招(tiao)聘(cao)旺季金三银四了，一批一批的社会精英在寻找自己的下一家的同时，也开始着手为面试做准备，回想起自己这些年，也大大小小经历过不少面试，有被面试过，也有当过面试官，其中也总结出了两个观点，一个就是不花一定的时间背些八股文还真的不行，一些扯皮的话别去听，都是在害人，另一个就是面试造火箭，入职拧螺丝毕竟都是少数，真正一场合格的面试问的东西，都是实际开发过程中会遇到的，下面我就说几个我遇到过的面试题吧

为什么ArrayMap比HashMap更适合Android开发

我们一般习惯在项目当中使用HashMap去存储键值队这样的数据，所以往往在android面试当中HashMap是必问环节，但有次面试我记得被问到了有没有有过ArrayMap,我只能说有印象，毕竟用的最多的还是HashMap,然后那个面试官又问我，觉得Android里面更适合用ArrayMap还是HashMap,我就说不上来了，因为也没看过ArrayMap的源码，后来回去看了下才给弄明白了，现在就简单对比下ArrayMap与HashMap的特点

HashMap

• HashMap的数据结构为数组加链表的结构，jdk1.8之后改为数组加链表加红黑树的结构


• put的时候，会先计算key的hashcode,然后去数组中寻找这个hashcode的下标，如果数据为空就先resize,然后检查对应下标值(下标值=(数组长度-1)&hashcode)里面是否为空，空则生成一个entry插入，否就判断hascode与key值是否分别都相等，如果相等则覆盖，如果不等就发生哈希冲突，生成一个新的entry插入到链表后面，如果此时链表长度已经大于8且数组长度大于64，则先转成树，将entry添加到树里面


• get的时候，也是先去查找数组对应下标值里面是否为空，如果不为空且key与hascode都相等，直接返回value,否就判断该节点是否为一个树节点，是就在树里面返回对应entry,否就去遍历整个链表，找出key值相等的entry并返回

ArrayMap

• 内部维护两个数组，一个是int类型的数组(mHashes)保存key的hashcode,另一个是Object的数组(mArray)，用来保存与mHashes对应的key-value


• put数据的时候，首先用二分查找法找出mHashes里面的下标index来存放hashcode,在mArray对应下标index<<1与(index<<1)+1的位置存放key与value


• get数据的时候，同样也是用二分查找法找出与key值对应的下标index,接着再从mArray的(index<<1)+1位置将value取出

对比

• HashMap在存放数据的时候，无论存放的量是多少，首先是会生成一个Entry对象，这个就比较浪费内存空间，而ArrayMap只是把数据插入到数组中，不用生成新的对象


• 存放大量数据的时候，ArrayMap性能上就不如HashMap,因为ArrayMap使用的是二分查找法找的下标，当数据多了下标值找起来时间就花的久，此外还需要将所有数据往后移再插入数据，而HashMap只要插入到链表或者树后面即可

所以这就是为什么，在没有那么大的数据量需求下，Android在性能角度上比较适合用ArrayMap

为什么Arrays.asList后往里add数据会报错

这个问题我当初问过不少人，不缺乏一些资历比较深的大佬，但是他们基本都表示不清楚，这说明平时我们研究Glide,OkHttp这样的三方库源码比较多，而像一些比较基础的往往会被人忽略，而有些问题如果被忽略了，往往会产生一些捉摸不透的问题，比如有的人喜欢用Arrays.asList去生成一个List

val dataList = Arrays.asList(1,2,3)

dataList.add(4)

但是当我们往这个List里面add数据的时候，我们会发现，crash了，看到的日志是

不被支持的操作，这让首次遇到这样问题的人肯定是一脸懵，List不让添加数据了吗？之前明明可以的啊，但是之前我们创建一个List是这样创建的

它所在的包是java.util.ArrayList里面，我们看下里面的代码

public boolean add(E e) {

    ensureCapacityInternal(size + 1);  // Increments modCount!!

    elementData[size++] = e;

    return true;

}

public void add(int index, E element) {

    if (index > size || index < 0)

        throw new IndexOutOfBoundsException(outOfBoundsMsg(index));



    ensureCapacityInternal(size + 1);  // Increments modCount!!

    System.arraycopy(elementData, index, elementData, index + 1,

                     size - index);

    elementData[index] = element;

    size++;

}

是存在add方法的，我们再回头再去看看asList生成的List

是在java.util.Arrays包里面的，而这里面的ArrayList我们看到了，并没有去实现List接口，所以也就没有add,get等方法，另外在kotlin里面，我们会看到一个细节，当你敲完Arrays.asList的时候，编译器会提示你，可以转换成listof函数，而这个还是我们知道生成的list都是只能读取，不能往里写数据

Thread.sleep(0)到底“睡没睡”

记得在上上家公司，接手的第一个需求就是做一个动画，这个动画需要一个延迟启动的功能，我那个时候想都没想加了个Thread.sleep(3000),后来被领导批了，不可以用Thread.sleep实现延迟功能，那会还不太明白，后来知道了，Thread.sleep(3000)不一定真的暂停三秒，我们来举个例子

println("start:${System.currentTimeMillis()}")

Thread(Runnable {

    Thread.sleep(3000)

    println("end:${System.currentTimeMillis()}")

}).start()

我们在主线程先打印一条数据展示时间，然后开启一个子线程，在里面sleep三秒以后在打印一下时间，我们看下结果如何

start:1675665421590

end:1675665424591

好像对了又好像没对，为什么是过了3001毫秒才打印出来呢？有的人会说，1毫秒而已，忽略嘛，那我们把上面的代码改下再试试

println("start:${System.currentTimeMillis()}")

Thread(Runnable {

    Thread.sleep(0)

    println("end:${System.currentTimeMillis()}")

}).start()

现在sleep了0毫秒，那是不是两条打印日志应该是一样的呢，我们看看结果

start:1675666764475

end:1675666764477

这下子给整不会了，明明sleep0毫秒，那么多出来的2毫秒是怎么回事呢？其实在Android操作系统中，每个线程使用cpu资源都是有优先级的，优先级高的才有资格使用，而操作系统则是在一个线程释放cpu资源以后，重新计算所有线程的优先级来重新分配cpu资源，所以sleep真正的意义不是暂停，而是在接下去的时间内不参与cpu的竞争，等到cpu重新分配完资源以后，如果优先级没变，那么继续执行，所以sleep(0)秒的真正含义是触发cpu资源重新分配

View.post为什么可以获取控件的宽高

我们都知道在onCreate里面想要获取一个控件的宽高，如果直接获取是拿不到的

val mWith = bindingView.mainButton.width

val mHeight = bindingView.mainButton.height

println("按钮宽：$mWith,高：$mHeight")

......

按钮宽：0,高：0

而如果想要获取宽高，则必须调用View.post的方法

bindingView.mainButton.post {

    val mWith = bindingView.mainButton.width

    val mHeight = bindingView.mainButton.height

    println("按钮宽：$mWith,高：$mHeight")

}

......

按钮宽：979,高：187

很神奇，加个post就可以在同样的地方获取控件宽高了，至于为什么呢？我们来分析一下

简单的来说

Activity生命周期，onCreate方法里面视图还在绘制过程中，所以没法直接获取宽高，而在post方法中执行,就是在线程里面获取宽高，这个线程会在视图没有绘制完成的时候放在一个等待队列里面，等到视图绘制执行完毕以后再去执行队列里面的线程，所以在post里面也可以获取宽高

复杂的来说

我们首先从View.post方法里面开始看

这个代码里面的两个框子，说明了post方法做了两件事情，当mAttachInfo不为空的时候，直接让mHandler去执行线程action，当mAttachInfo为空的时候，将线程放在了一个队列里面，从注释里面的第一个单词Postpone就可以知道，这个action是要推迟进行，什么时候进行呢，我们在慢慢看，既然是判断当mAttachInfo不为空才去执行线程，那我们找找什么时候对mAttachInfo赋值，整个View的源码里面只有一处是对mAttachInfo赋值的，那就是在dispatchAttachedToWindow
这个方法里面，我们看下

void dispatchAttachedToWindow(AttachInfo info, int visibility) {

    mAttachInfo = info;

    ...省略部分源码...

  

    // Transfer all pending runnables.

    if (mRunQueue != null) {

        mRunQueue.executeActions(info.mHandler);

        mRunQueue = null;

    }



}

当走到dispatchAttachedToWindow这个方法的时候，mAttachInfo才不为空，也就是从这里开始，我们就可以获取控件的宽高等信息了，另外我们顺着这个方法往下看，可以发现，之前的那个队列在这里开始执行了，现在就关键在于，什么时候执行dispatchAttachedToWindow这个方法，这个时候就要去ViewRootIml类里面查看，发现只有一处调用了这个方法，那就是在performTraversals这个方法里面

private void performTraversals() {

        ...省略部分源码...

    host.dispatchAttachedToWindow(mAttachInfo, 0);

        ...省略部分源码...

    // Ask host how big it wants to be

    performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);

        ...省略部分源码...

    performLayout(lp, mWidth, mHeight);

        ...省略部分源码...

    performDraw();

}

performTraversals这个方法我们就很熟悉了，整个View的绘制流程都在里面，所以只有当mAttachInfo在这个环节赋值了，才可以得到视图的信息

IdleHandler到底有啥用

Handler是面试的时候必问的环节，除了问一下那四大组件之外，有的面试官还会问一下IdleHandler,那IdleHandler到底是什么呢，它是干什么用的呢，我们来看看

Message next() {

...省略部分代码...

    synchronized (this) {

        // If first time idle, then get the number of idlers to run.

        // Idle handles only run if the queue is empty or if the first message

        // in the queue (possibly a barrier) is due to be handled in the future.

        if (pendingIdleHandlerCount < 0

                && (mMessages == null || now < mMessages.when)) {

            pendingIdleHandlerCount = mIdleHandlers.size();

        }

        if (pendingIdleHandlerCount <= 0) {

            // No idle handlers to run.  Loop and wait some more.

            mBlocked = true;

            continue;

        }



        if (mPendingIdleHandlers == null) {

            mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];

        }

        mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);

    }



    // Run the idle handlers.

    // We only ever reach this code block during the first iteration.

    for (int i = 0; i < pendingIdleHandlerCount; i++) {

        final IdleHandler idler = mPendingIdleHandlers[i];

        mPendingIdleHandlers[i] = null; // release the reference to the handler



        boolean keep = false;

        try {

            keep = idler.queueIdle();

        } catch (Throwable t) {

            Log.wtf(TAG, "IdleHandler threw exception", t);

        }



        if (!keep) {

            synchronized (this) {

                mIdleHandlers.remove(idler);

            }

        }

    }



}

只有在MessageQueue中的next方法里面出现了IdleHandler,作用也很明显，当消息队列在遍历队列中的消息的时候，当消息已经处理完了，或者只存在延迟消息的时候，就会去处理mPendingIdleHandlers里面每一个idleHandler的事件，而这些事件都是通过方法addIdleHandler注册进去的

Looper.myQueue().addIdleHandler {

    false

}

addIdlehandler接受的参数是一个返回值为布尔类型的函数类型参数，至于这个返回值是true还是false,我们从next()方法中就能了解到，当为false的时候，事件处理完以后，这个IdleHandler就会从数组中删除，下次再去遍历执行这个idleHandler数组的时候，该事件就没有了，如果为true的话，该事件不会被删除，下次依然会被执行，所以我们按需设置。现在我们可以利用idlehandler去解决上面讲到的在onCreate里面获取控件宽高的问题

Looper.myQueue().addIdleHandler {

    val mWith = bindingView.mainButton.width

    val mHeight = bindingView.mainButton.height

    println("按钮宽：$mWith,高：$mHeight")

    false

}

当MessageQueue中的消息处理完的时候，我们的视图绘制也完成了，所以这个时候肯定也能获取控件的宽高，我们在IdleHandler里面执行了同样的代码之后，运行后的结果如下

按钮宽：979,高：187

除此之外，我们还可以做点别的事情，比如我们常说的不要在主线程里面做一些耗时的工作，这样会降低页面启动速度，严重的还会出现ANR,这样的场景除了开辟子线程去处理耗时操作之外，我们现在还可以用IdleHandler，这里举个例子，我们在主线程中给sp塞入一些数据，然后在把这些数据读取出来，看看耗时多久

println(System.currentTimeMillis())

val testData = "aabbbbakjsdhjkahsjkasdjasdhjakshdjkahsdjkhasjdkhjaskhdjkashdjkhasjkhas" +

        "jkhdaabbbbakjsdhjkahsjkasdjasdhjakshdjkahsdjkhasjdkhjaskhdjkashdjkhasjkhasjkhd" +

        "aabbbbakjsdhjkahsjkasdjasdhjakshdjkahsdjkhasjdkhjaskhdjkashdjkhasjkhasjkhd" +

        "aabbbbakjsdhjkahsjkasdjasdhjakshdjkahsdjkhasjdkhjaskhdjkashdjkhasjkhasjkhd" +

        "aabbbbakjsdhjkahsjkasdjasdhjakshdjkahsdjkhasjdkhjaskhdjkashdjkhasjkhasjkhd" +

        "aabbbbakjsdhjkahsjkasdjasdhjakshdjkahsdjkhasjdkhjaskhdjkashdjkhasjkhasjkhd"

sharePreference = getSharedPreferences(packageName, MODE_PRIVATE)

for (i in 1..5000) {

    sharePreference.edit().putString("test$i", testData).commit()

}

for (i in 1..5000){

    sharePreference.getString("test$i","")

}

println(System.currentTimeMillis())



......运行结果

1676260921617

1676260942770

我们看到在塞入5000次数据，再读取5000次数据之后，一共耗时大概20秒，同时也阻塞了主线程，导致的现象是页面一片空白，只有等读写操作结束了，页面才展示出来，我们接着把读写操作的代码用IdleHandler执行一下看看

Looper.myQueue().addIdleHandler {

    sharePreference = getSharedPreferences(packageName, MODE_PRIVATE)

    val editor = sharePreference.edit()

    for (i in 1..5000) {

        editor.putString("test$i", testData).commit()

    }

    for (i in 1..5000){

        sharePreference.getString("test$i","")

    }

    println(System.currentTimeMillis())

    false

}

......运行结果

1676264286760

1676264308294

运行结果依然耗时二十秒左右，但区别在于这个时候页面不会受到读写操作的阻塞，很快就展示出来了，说明读写操作的确是等到页面渲染完才开始工作，上面过程没有放效果图主要是因为时间太长了，会影响gif的体验，有兴趣的可以自己试一下

如何让指定视图不被软键盘遮挡

我们通常使用android:windowSoftInputMode属性来控制软键盘弹出之后移动界面，让输入框不被遮挡，但是有些场景下，键盘永远都会挡住一些我们使用频次比较高的控件，比如现在我们有个登录页面，大概的样子长这样

它的布局文件是这样

<RelativeLayout

    android:id="@+id/mainroot"

    android:layout_width="match_parent"

    android:layout_height="match_parent">



    <ImageView

        android:layout_width="200dp"

        android:layout_height="200dp"

        android:layout_centerHorizontal="true"

        android:layout_marginTop="100dp"

        android:src="@mipmap/ic_launcher_round" />



    <androidx.appcompat.widget.LinearLayoutCompat

        android:id="@+id/ll_view1"

        android:layout_width="match_parent"

        android:layout_height="wrap_content"

        android:layout_alignParentBottom="true"

        android:layout_marginBottom="120dp"

        android:gravity="center"

        android:orientation="vertical">



        <EditText

            android:id="@+id/main_edit"

            android:layout_width="match_parent"

            android:layout_height="40dp"

            android:hint="请输入用户名"

            android:textColor="@color/black"

            android:textSize="15sp" />



        <EditText

            android:id="@+id/main_edit2"

            android:layout_width="match_parent"

            android:layout_height="40dp"

            android:layout_marginTop="30dp"

            android:hint="请输入密码"

            android:textColor="@color/black"

            android:textSize="15sp" />



        <Button

            android:layout_width="match_parent"

            android:layout_height="50dp"

            android:layout_marginHorizontal="10dp"

            android:layout_marginTop="20dp"

            android:text="登录" />



    </androidx.appcompat.widget.LinearLayoutCompat>



</RelativeLayout>

在这样一个页面里面，由于输入框与登录按钮都比较靠页面下方，导致当输入完内容想要点击登录按钮时候，必须再一次关闭键盘才行，这样的操作在体验上就比较大打折扣了

现在希望可以键盘弹出之后，按钮也展示在键盘上面，这样就不用收起弹框以后才能点击按钮了，这样一来，windowSoftInputMode这一个属性已经不够用了，我们要想一下其他方案

• 首先，需要让按钮也展示在键盘上方，那只能让布局整体上移把按钮露出来，在这里我们可以改变LayoutParam的bottomMargin参数来实现


• 其次，需要知道键盘什么时候弹出，我们都知道android里面并没有提供任何监听事件来告诉我们键盘什么时候弹出，我们只能从其他角度入手，那就是监听根布局可视区域大小的变化

ViewTreeObserver

我们先获取视图树的观察者，使用addOnGlobalLayoutListener去监听全局视图的变化

bindingView.mainroot.viewTreeObserver.addOnGlobalLayoutListener {



}

接下去就是要获取根视图的可视化区域了，如何来获取呢？View里面有这么一个方法，那就是getWindowVisibleDisplayFrame，我们看下源码注释就知道它是干什么的了

一大堆英文没必要都去看，只需要看最后一句就好了，大概意思就是获取能够展示给用户的可用区域，所以我们在监听器里面加上这个方法

bindingView.mainroot.viewTreeObserver.addOnGlobalLayoutListener {

    val rect = Rect()

    bindingView.mainroot.getWindowVisibleDisplayFrame(rect)

}

当键盘弹出或者收起的时候，rect的高度就会跟着变化，我们就可以用这个作为条件来改变bottomMargin的值，现在我们增加一个变量oldDelta来保存前一个rect变化的高度值，用来做比较，完整的代码如下

var oldDelta = 0

val params:RelativeLayout.LayoutParams = bindingView.llView1.layoutParams as RelativeLayout.LayoutParams

val originBottom = params.bottomMargin

bindingView.mainroot.viewTreeObserver.addOnGlobalLayoutListener {

    val rect = Rect()

    bindingView.mainroot.getWindowVisibleDisplayFrame(rect)

    val deltaHeight = r.height()

    if (oldDelta != deltaHeight) {

        if (oldDelta != 0) {

            if (oldDelta > deltaHeight) {

                params.bottomMargin = oldDelta - deltaHeight

            } else if (oldDelta < deltaHeight) {

                params.bottomMargin = originBottom

            }

            bindingView.llView1.layoutParams = params

        }

        oldDelta = deltaHeight

    }

}

最终效果如下

弹出后页面有个抖动是因为本身有个页面平移的效果，然后再去计算layoutparam,如果不想抖动可以在布局外层套个scrollView,用smoothScrollTo把页面滑上去就可以了，有兴趣的可以业余时间试一下

为什么LiveData的postValue会丢失数据

LiveData已经问世好多年了，大家都很喜欢用，因为它上手方便，一般知道塞数据用setValue和postValue,监听数据使用observer就可以了，然而实际开发中我遇到过好多人，一会这里用setValue一会那里用postValue,或者交替着用，这种做法也不能严格意义上说错，毕竟运行起来的确没问题，但是这种做法确实是存在风险隐患，那就是连续postValue会丢数据，我们来做个实验，连续setValue十个数据和连续postValue十个数据，收到的结果都分别是什么

var testData = MutableLiveData<Int>()

fun play(){

    for (i in 1..10) {

        testData.value = i

    }

}



mainViewModel.testData.observe(this) {

    println("收到:$it")

}



//执行结果

收到:1

收到:2

收到:3

收到:4

收到:5

收到:6

收到:7

收到:8

收到:9

收到:10

setValue十次数据都可以收到，现在把setValue改成postValue再来试试

var testData = MutableLiveData<Int>()

fun play(){

    for (i in 1..10) {

        testData.postValue(i)

    }

}

得到的结果是

收到:10

只收到了最后一条数据10,这是为什么呢？我们进入postValue里面看看里面的源码就知道了

主要看红框里面，有一个synchronized同步锁锁住了一个代码块，我们称为代码块1，锁的对象是mDataLock,代码块1做的事情先是给postTask这个布尔值赋值，接着把传进来的值赋给mPendingData,那我们知道了，postTask除了第一个被执行的时候，值是true,结下去等mPendingData有值了以后就都为false，前提是mPendingData没有被重置为NOT_SET,然后我们顺着代码往下看，会看到代码接下来就要到一个mPostValueRunnable的线程里面去了，我们看下这个线程

发现同样的锁，锁住了另一块代码块，我们称为代码块2，这个代码块里面恰好是把mPendingData的值赋给newValue以后，重置为NOT_SET,这样一来，postValue又可以接受新的值了，所以这也是正常情况下每次postValue都可以接受到值的原因，但是我们想想连续postValue的场景，我们知道如果synchronized如果修饰一段代码块，那么当这段代码块获取到锁的时候，就具有优先级，只有当全部执行完以后才会释放锁，所以当代码块1连续被访问时候，代码块2是不会被执行的，只有等到代码块1执行完，释放了锁，代码块2才会被执行，而这个时候，mPendingData已经是最新的值了，之前的值已经全部被覆盖了，所以我们说的postValue会丢数据，其实说错了，应该是postValue只会发送最新数据

总结

这篇文章讲到的面试题还仅仅只是过去几年遇到的，现在面试估计除了一些常规问题之外，比重会更倾向于Kotlin,Compose,Flutter的知识点，所以只有不断的日积月累，让自己的知识点更加的全面，才能在目前竞争激烈的行情趋势下逆流而上，不会被拍打在沙滩上

背景

大家在日常开发中应该经常会有需要切换不同环境地址的情况。当一个项目代码切换环境地址时，vue-cli没有能够感知文件的变化，所以代理的还是旧的地址，所以通常我们需要执行npm run serve进行项目重跑，而项目重跑往往意味着长时间的等待，非常痛苦！

方案调研

事实上，其实我们只是需要重启webpack为我们启动的proxy代理服务，或许能够从webpack的代理服务插件中找到解决方法。

从webpack官网可以看到proxy服务其实是由
http-proxy-middleware提供的，或许我们能够从中找到解决方法。

初步方案

在http-proxy-middleware的配置选项中，除了我们常见的target，还有router。router返回一个字符串的服务地址，当两个选项都配置了的情况下，会优先使用router函数的返回值，只有当router的返回值不可用时，才会使用target的值。

我们可以利用这一点来重新配置我们的项目代码。参考文档在这里

// vue.config.js

const { defineConfig } = require('@vue/cli-service')

const { proxy } = require('./environments/proxy.js')

module.exports = defineConfig({

  devServer:{

    proxy

  },

})



复制代码

// proxy.js 

const fs = require('fs') 

const path = require('path') 

const encoding = 'utf-8' 

 

const getContent = filename => { 

    const dir = path.resolve(process.cwd(), 'environments') 

    return fs.readFileSync(path.resolve(dir, filename), { encoding }) 

} 



const jsonParse = obj => { return Function('"use strict";return (' + obj + ')')() } 



const getConfig = () => { try { 

    return jsonParse(getContent('proxy-config.json')) 

} catch (e) { return {} } } 



module.exports = { 

    proxy: { 

        // 接口匹配规则自行修改

        '/api': { 

            // 这里必须要有字符串来进行占位 

            // 如果报错Invaild Url，将target改成有效的url字符串即可，如http://localhost:9001

            target: 'that must have a empty placeholder', 

            changeOrigin: true, 

            router: () => (getConfig() || {}).target || ''

        } 

    } 

}



复制代码

// proxy-config.json

{ "target": "http://localhost:9001" }

复制代码

自此，当我们需要修改环境地址时，只需要修改proxy-config.json文件便能够实时生效，不再需要npm run serve！

重点代码分析

实现代码中其实最主要的就是getContent这个方法，我们项目在每次发起http请求时都会调用router中的函数，而getContent则会通过node的fs服务，对我们的环境地址文件进行实时读取，从而指向我们最新修改的环境地址。

方案总结

在按照参考文档配置了项目代码之后，我们发现确实能够及时指向新的环境地址，再也不需要重启代码，不需要长时间的等待了。但是，我们多了两个需要维护的文件，每次我们修改环境地址时，不仅需要修改config中的api，还需要修改proxy-config.json中的target！

有没有可能在只需要修改config文件的情况下，实现代理地址动态修改呢？

方案优化

从上面的重点代码分析中，可以看到只要我们可以在router函数执行时，拿到正确的config文件中导出的api属性的值，也可以实现同样的效果！

这是不是意味着只要我们在函数中对config文件进行require请求，读取api的值，再return出去就能及时修改代理指向了呢？

没错，你会发现无论你怎么修改，函数内require取到的api永远是不变的，还是服务刚启动时的环境地址。

参考源码可以知道，这是因为我们在使用require请求文件信息时，node会解析出我们传入的字符串的文件路径的绝对路径，并且以绝对路径为键值，对该文件进行缓存。

因此，如果我们在执行require函数时打断点进行观察的话，会发现require上面有一个cache缓存了已经加载过的文件。

这也恰恰说明了只要我们能够删除掉文件保存在require中的缓存，我们就能够拿到最新的文件内容，那么我们也可以据此得出我们的最终优化方案。

// vue.config.js

const hotRequire = modulePath => {

  // require.resolve可以通过相对路径获取绝对路径

  // 以绝对路径为键值删除require中的对应文件的缓存

  delete require.cache[require.resolve(modulePath)]

  // 重新获取文件内容

  const target = require(modulePath)

  return target

}



...

proxy: {

      '/api': {

        // 如果router有效优先取router返回的值

        target: 'that must have a empty placeholder',

        changeOrigin: true,

        // 每次发起http请求都会执行router函数

        router: () => (hotRequire('./src/utils/config') || {}).api || '',

        ws: true,

        pathRewrite: {

          '^/api': ''

        }

      }

}

复制代码

自此，我们项目修改环境地址将不在需要重启项目，也不需要维护额外的文件夹，再也不需要痛苦等待了！

引言

在 Android 开发的世界中，有一些组件，无论应用层技术再怎么迭代，作为基础支持，它们依然在那里。
比如当我们提到网络库时，总会下意识想到一个名字，即 OkHttp 。

尽管对于大多数开发者而言，通常情况下使用的是往往它的封装版本 Retrofit ，不过其底层依然离不开 Okhttp 作为基础支撑。而无论是自研网络库的二次封装，还是个人使用，OkHttp 也往往都是不二之选。

故本篇将以最新视角开始，用力一瞥 OkHttp 的设计魅力。

本文对应的 OkHttp 版本： 4.10.0

本篇定位 中高难度，将从背景到使用方式，再到设计思想与源码解析，尽可能全面、易懂。

背景

每一个技术都有其变迁的历史背景与特性，本小节，我们将聊一聊 Android网络库 的迭代史，作为开篇引语，润润眼。 🔖

关于 Android网络库 的迭代历史，如下图所示：

具体进展如下：

• 
  

  HttpClient

  
  

  Android1.0 时推出。但存在诸多问题，比如内存泄漏，频繁的GC等。5.0后，已被弃用；

  
  


• 
  

  HttpURLConnection

  
  

  Android2.2 时推出，比 HttpClient 更快更稳定，Android4.4 之后底层已经被 Okhttp 替代；

  
  


• 
  

  volley

  
  

  Google 2013年开源，基于 HttpURLConnection 的封装，具有良好的扩展性和适用性，不过对于复杂请求或者大量网络请求时，性能较差。目前依然有不少项目使用(通常是老代码的维护)；

  
  


• 
  

  okhttp

  
  

  Square 2013年开源，基于 原生Http 的底层设计，具有 快速 、 稳定 、节省资源 等特点。是目前诸多热门网络请求库的底层实现，比如 Retrofit、RxHttp 等；

  
  


• 
  

  Retrofit

  
  

  Square 2013年开源，基于 OkHttp 的封装，目前 主流 的网络请求库。

  
  

  通过注解方式配置网络请求、REST风格 api、解耦彻底、经常会搭配 Rx等 实现 框架联动；

  
  


• 
  

  …

  
  

上述的整个过程，也正是伴随了 Android 开发的各个时期，如果将上述分为 5个阶段 的话，那么则为：

HttpClient -> HttpURLConnection -> volley -> okhttp -> Retrofit*

通过 Android网络库 的迭代历史，我们不难发现，技术变迁越来越趋于稳定，而 OkHttp 也已经成为了基础组件中不可所缺的一员。

设计思想

当聊到OkHttp的设计思想，我们想知道什么？

从应用层去看，熟练的开发者会直接喊出拦截器，巴拉巴拉…

而作为初学者，可能更希望的事广度与解惑，OkHttp 到底牛在了什么地方，或者说常说的 拦截器到底是什么 ? 🧐

在官方的描述中，OkHttp 是一个高效的 Http请求框架 ，旨在 简化 客户端网络请求，提高 请求效率。

具体设计思想与特性如下：

• 连接复用 ：避免在每个请求之间重新建立连接。


• 连接池 降低了请求延迟 (HTTP/2不可用情况下)；


• 自动重试 ：在请求失败时自动重试请求，从而提高请求可靠性。


• 自动处理缓存 ：会按照预定的缓存策略处理缓存，以便最大化网络效率。


• 支持HTTP/2, 并且允许对同一个主机的所有请求共享一个套接字(HTTP/2)；


• 简化Api：Api设计简单明了，易于使用，可以轻松发起请求获取响应，并处理异常。


• 支持gzip压缩 ：OkHttp支持gzip压缩，以便通过减少网络数据的大小来提高网络效率。

特别的，如果我们的服务器或者域名有 多个IP地址 ，OkHttp 将在 第一次 连接失败时尝试替代原有的地址(对于 IPv4+IPv6 和托管在冗余数据中心的服务是必需的)。并且支持现代 TLS 功能（TLS 1.3、ALPN、证书固定）。它可以配置为回退以实现广泛的连接。

总的来说，其设计思想是通过 简化请求过程 、提高请求效率、提高请求可靠性，从而提供 更快的响应速度 。

应用层的整个请求框架图如下：

使用方式

在开始探究设计原理与思想之前，我们还是要先看看最基础的使用方式，以便为后续做一些铺垫。

// build.gradle

implementation "com.squareup.okhttp3:okhttp:4.10.0"

复制代码

// Android Manifest

<uses-permission android:name="android.permission.INTERNET" />

复制代码

发起一个get请求

拦截器的使用

总结起来就是下面几步：

1. 创建 OkHttpClient 对象；


2. 构建 Request ;


3. 调用 OkHttpClient 执行 request 请求 ;


4. 同步阻塞 或者 异步回调 方式接收结果；

更多使用方式，可以在搜索其他同学的教程，这里仅仅只是作为后续解析原理时的必要基础支撑。

源码分析

基础配置

OkHttpClient

val client = OkHttpClient.Builder().xxx.build()

复制代码

由上述调用方式，我们便可以猜出，这里使用了 构建者模式 去配置默认的参数，所以直接去看 OkHttpClient.Builder 支持的参数即可，具体如下：

具体的属性意思在代码中也都有注释，这里我们就不在多提了。

需要注意的是,在使用过程中，对于 OkHttpClient 我们还是应该缓存下来或者使用单例模式以便后续复用，因为其相对而言还是比较重。

Request

指客户端发送到服务器的 HTTP请求。

在 OkHttp 中，可以使用 Request 对象来构建请求，然后使用 OkHttpClient 对象来发送请求。
通常情况下，一个请求包括了 请求头、请求方法、请求路径、请求参数、url地址 等信息。主要是用来请求服务器返回某些资源，如网页、图片、数据等。

具体源码如下所示：

Request.Builder().url("https://www.baidu.com").build()

复制代码

open class Builder {

  // url地址

  internal var url: HttpUrl? = null		 	

  // 请求方式

  internal var method: String					 			

  // 请求头

  internal var headers: Headers.Builder		 			

  // 请求体

  internal var body: RequestBody? = null	 			

  // 请求tag

  internal var tags: MutableMap<Class<*>, Any>  	

}

复制代码

发起请求

execute()

用于执行 同步请求 时调用，具体源码如下：

client.newCall(request).execute()

复制代码

接下来我们再去看看 client.newCall() , 即请求发起时的逻辑。

当我们使用 OkHttpClient.newCall() 方法时，实际是创建了一个新的 RealCall 对象，用于 应用层与网络层之间的桥梁，用于处理连接、请求、响应以及流 ，其默认构造函数中需要传递 okhttpClient 对象以及 request 。

接着，使用了 RealCall 对象调用了其 execute() 方法开始发起请求，该方法内部会将当前的 call 加入我们 Dispatcher 分发器内部的 runningSyncCalls 队列中取，等待被执行。接着调用 getResponseWithInterceptorChain() ，使用拦截器获取本次请求响应的内容，这也即我们接下来要关注的步骤。

enqueue()

执行 异步请求 时调用，具体源码如下：

client.newCall(request).enqueue(CallBack)

复制代码

当我们调用 RealCall.enqueue() 执行异步请求时，会先将本次请求加入 Dispather.readyAsyncCalls 队列中等待执行，如果当前请求是 webSocket 请求，则查找与当前请求是同一个 host 的请求，如果存在一致的请求，则复用先前的请求。

接下来调用 promoteAndExecute() 将所有符合条件可以请求的 Call 从等待队列中添加到 可请求队列 中，再遍历该请求队列，将其添加到 线程池 中去执行。

继续沿着上面的源码，我们去看 asyncCall.executeOn(executorService) ，如下所示：

上述逻辑也很简单，当我们将任务添加到线程池后，当任务被执行时，即触发 run() 方法的调用。该方法中会去调用 getResponseWithInterceptorChain() 从而使用拦截器链获取服务器响应，从而完成本次请求。请求成功后则调用我们开始时的 callback对象 的 onResponse() 方法，异常(即失败时)则调用 onFailure() 方法。

拦截器链

在上面我们知道，他们最终都走到了 RealCall.getResponseWithInterceptorChain() 方法，即使用 拦截器链 获取本次请求的响应内容。不过对于初看OkHttp源码的同学，这一步应用会有点迷惑，拦截器链 是什么东东👾？

在解释 拦截器链 之前，我们不妨先看一下 RealCall.getResponseWithInterceptorChain() 方法对应的源码实现，然后再去解释为什么，也许更容易理解。

具体源码如下：

上述的逻辑非常简单，内部会先创建一个局部拦截器集合，然后将我们自己设置的普通拦截器添加到该集合中，然后添加核心的5大拦截器，接着再将我们自定义的网络拦截器也添加到该集合中，最终才添加了真正用于执行网络请求的拦截器。接着创建了一个拦截器责任链 RealInterceptorChain ，并调用其 proceed() 方法开始执行本次请求。

责任链模式

在上面我们说到了，要解释 OkHttp 的拦截器链，我们有必要简单聊一下什么是责任链模式？

责任链模式（Chain of Responsibility）是一种处理请求的模式，它让多个处理器都有机会处理该请求，直到其中某个处理成功为止。责任链模式把多个处理器串成链，然后让请求在链上传递。

摘自 责任链模式 @廖雪峰

以 Android 中常见的事件分发为例：当我们的手指点击屏幕开始，用户的触摸事件从 Activity 开始分发，接着从 windows 开始分发到具体的 contentView(ViewGroup) 上，开始调用其 dispatchTouEvent() 方法进行事件分发。在这个方法内，如果当前 ViewGroup 不进行拦截，则默认会继续向下分发，寻找当前 ViewGroup 下对应的触摸位置 View ，如果该 View 是一个 ViewGroup ，则重复上述步骤。如果事件被某个 view 拦截，则触发其 onTouchEvent() 方法，接着交由该view去消费该事件。而如果事件传递到最上层 view 还是没人消费，则该事件开始按照原路返回，先交给当前 view 自己的 onTouchEvent() ，因为自己不消费，则调用其 父ViewGroup 的 onTouchEvent() ,如此层层传递，最终又交给了 Act 自行处理。上述这个流程，就是 责任链模式 的一种体现。

如下图所示：

上图来自 Android事件分发机制三：事件分发工作流程 @一只修仙的猿

看完什么是责任链模式，让我们将思路转回到 OkHttp 上面，我们再去看一下 RealInterceptorChain 源码。

上述逻辑如下:

• 
  

  当 getResponseWithInterceptorChain() 方法内部最终调用 RealInterceptorChain.proceed() 时，内部传入了一个默认的index ，这个 index 就代表了当前要调用的 拦截器item ，并在方法内部每次创建一个新的 RealInterceptorChain 链，index+1，再调用当前拦截器 intercept() 方法时，然后将下一个链传入；

  
  


• 
  

  最开始调用的是用户自定义的 普通拦截器，如果上述我们添加了一个 CustomLogInterceptor 的拦截器，当获取 response 时，我们需要调用 Interceptor.Chain.proceed() ，而此时的 chain 正是下一个拦截器对应的 RealInterceptorChain；

  
  


• 
  

  上述流程里，index从0开始，以此类推，一直到链条末尾，即 拦截器集合长度-1处；

  
  


• 
  

  当遇到最后一个拦截器 CallServerInterceptor 时，此时因为已经是最后一个拦截器，链条肯定要结束了，所以其内部肯定也不会调用 proceed() 方法。

  
  

  相应的，为什么我们在前面说 它 是真正执行与服务器建立实际通讯的拦截器？

  
  

  因为这个里会获取与服务器通讯的 response ，即最初响应结果，然后将其返回上一个拦截器，即我们的网络拦截器，再接着又向上返回，最终返回到我们的普通拦截器处，从而完成整个链路的路由。

  
  

参照上面的流程，即大致思路图如下：

拦截器

RetryAndFollowUpInterceptor

见名知意，用于 请求失败 的 重试 工作以及 重定向 的后续请求工作，同时还会对 连接 做一些初始化工作。

上述的逻辑，我们分为四段进行分析：

1. 请求时如果遇到异常，则根据情况去尝试恢复，如果不能恢复，则抛出异常，跳过本次请求；如果请求成功，则在 finally 里释放资源；


2. 如果请求是重试之后的请求，那么将重试前请求的响应体设置为null,并添加到当前响应体的 priorResponse 字段中；


3. 根据当前的responseCode判断是否需要重试，若不需要，则返回 response ；若需要，则返回 request ，并在后续检查当前重试次数是否达到阈值；


4. 重复上述步骤，直到步骤三成功。

在第一步时，获取 response 时，需要调用 realChain.proceed(request) ，如果你还记得上述的责任链，所以这里触发了下面的拦截器执行，即 BridgeInterceptor 。

BridgeInterceptor

用于 客户端和服务器 之间的沟通 桥梁 ，负责将用户构建的请求转换为服务器需要的请求。比如添加 content-type、cookie 等，再将服务器返回的 response 做一些处理，转换为客户端所需要的 response，比如移除 Content-Encoding ，具体见下面源码所示：

上述逻辑如下：

1. 首先调用 chain.request() 获取原始请求数据，然后开始重新构建请求头，添加 header 以及 cookie 等信息；


2. 将第一步构建好的新的 request 传入 chain.proceed() ,从而触发下一个拦截器的执行，并得到 服务器返回的 response。然后保存 response 携带的 cookie,并移除 header 中的 Content-Encoding 和 Content-Length,并同步修改 body。

CacheInterceptor

见名知意，其用于网络缓存，开发者可以通过 OkHttpClient.cache() 方法来配置缓存，在底层的实现处，缓存拦截器通过 CacheStrategy 来判断是使用网络还是缓存来构建 response。具体的 cache 策略采用的是 DiskLruCache 。

Cache的策略如下图所示：

具体源码如下所示：

具体的逻辑如上图所示，具体可以参照上述的 Cache 流程图，这里我们再说一下 CacheStrategy 这个类，即决定何时使用 网络请求、响应缓存。

CacheStrategy

ConnectInterceptor

实现与服务器真正的连接。

上述流程如下：

• 初始化 一个 exchange 对象；


• 根据 exchange 对象来复制创建一个新的连接责任链；


• 执行该连接责任链。

那 Exchange 是什么呢？

在官方的解释里，其用于 传递单个 HTTP 请求和响应对，在 ExchangeCode 的基础上担负了一些管理及事件分发的作用。

具体而言，Exchange 与 Request 相对应，新建一个请求时就会创建一个 Exchange，该 Exchange 负责将这个请求发送出去并读取到响应数据，而具体的发送与接收数据使用的则是 ExchangeCodec。

相应的，ExchangeCode 又是什么呢？

ExchangeCodec 负责对 request 编码及解码 Response ,即写入请求及读取响应，我们的请求及响应数据都是通过它来读写。

通俗一点就是，ExchangeCodec 是请求处理器，它内部封装了 OkHttp 中执行网络请求的细节实现，其通过接受一个 Request 对象，并在内部进行处理，最终生成一个符合 HTTP 协议标准的网络请求，然后接受服务器返回的HTTP响应，并生成一个 Response 对象，从而完成网络请求的整个过程。

额外的，我们还需要再提一个类，ExchangeFinder 。

用于寻找可用的 Exchange ，然后发送下一个请求并接受下一个响应。

虽然上述流程看起来似乎很简单，但我们还是要分析下具体的流程，源码如下所示：

RealCall.initExchange()

初始化 Exchage 的过程。

从 ExchangeFinder 找到一个新的或者已经存在的 ExchangeCodec，然后初始化 Exchange ，以此来承载接下来的HTTP请求和响应对。

ExchangeFinder.find()

查找 ExchangeCodec(请求响应编码器) 的过程。

接下来我们看看查找 RealConnection 的具体过程：

上述的整个流程如下：

上述会先通过 ExchangeFinder 去 RealConnecionPool 中尝试寻找已经存在的连接，未找到则会重新创建一个 RealConnection(连接) 对象，并将其添加到连接池里，开始连接。然后根据找到或者新创建 RealConnection 对象，并根据当前请求协议创建不同的 ExchangeCodec 对象并返回，最后初始化一个 Exchange 交换器并返回，从而实现了 Exchange 的初始化过程。

在具体找寻 RealConnection 的过程中，一共尝试了5次，具体如下：

1. 尝试重连 call 中的 connection，此时不需要重新获取连接；


2. 尝试从连接池中获取一个连接，不带路由与多路复用；


3. 再次尝试从连接池中获取一个连接，带路由，不带多路复用；


4. 手动创建一个新连接；


5. 再次尝试从连接池中获取一个连接，带路由与多路复用；

当 Exchange 初始化完成后，再复制该对象创建一个新的 Exchange ，并执行下一个责任链，从而完成连接的建立。

networkInterceptors

网络拦截器，即 client.networkInterceptors 中自定义拦截器，与普通的拦截器 client.interceptors 不同的是：

由于网络拦截器处于倒数第二层，在 RetryAndFollowUpInterceptor 失败或者 CacheInterceptor 返回缓存的情况下，网络拦截器无法被执行。而普通拦截器由于第一步就被就执行到，所以不受这个限制。

CallServerInterceptor

链中的最后一个拦截器，也即与服务器进行通信的拦截器，利用 HttpCodec 进行数据请求、响应数据的读写。

具体源码如下：

先写入要发送的请求头，然后根据条件判断是否写入要发送的请求体。当请求结束后，解析服务器返回的响应头，构建一个新的 response 并返回；如果 response.code 为 100，则重新读取响应体并构建新的 response。因为这是最底层的拦截器，所以这里肯定不会再调用 proceed() 再往下执行。

小结

至此，关于 OkHttp 的分析，到这里就结束了。为了便于理解，我们再串一遍整个思路：

在 OkHttp 中，RealCall 是 Call 的实现类，其负责 执行网络请求 。其中，请求 request 由 Dispatcher 进行调度，其中 异步调用 时，会将请求放到到线程池中去执行; 而同步的请求则只是会添加到 Dispatcher 中去管理，并不会有线程池参与协调执行。

在具体的请求过程中，网络请求依次会经过下列拦截器组成的责任链，最后发送到服务器。

1. 普通拦截器，client.interceptors()；


2. 重试、重定向拦截器 RetryAndFollowUpInterceptor；


3. 用于客户端与服务器桥梁，将用户请求转换为服务器请求，将服务器响应转换为用户响应的的 BridgeInterceptor；


4. 决定是否需要请求服务器并写入缓存再返回还是直接返回服务器响应缓存的 CacheInterceptor;


5. 与服务器建立连接的 ConnectInterceptor；


6. 网络拦截器，client.networkInterceptors();


7. 执行网络请求的 CallServerInterceptor;

而相应的服务器响应体则会从 CallServerInterceptor 开始依次往前开始返回，最后由客户端进行处理。

需要注意的是，当我们 RetryAndFollowUpInterceptor 异常或者 CacheInterceptor 拦截器直接返回了有效缓存，后续的拦截器将不会执行。

常见问题

OkHttp如何判断缓存有效性？

这里其实主要说的是 CacheInterceptor 拦截器里的逻辑，具体如下：

OkHttp 使用 HTTP协议 中的 缓存控制机制 来判断缓存是否有效。如果请求头中包含 "Cache-Control" 和 "If-None-Match" / "If-Modified-Since" 字段，OkHttp 将根据这些字段的值来决定是否使用缓存或从网络请求响应。

Cache-Control 指 包含缓存控制的指令，例如 "no-cache" 和 "max-age" ;

If-None-Match 指 客户端缓存的响应的ETag值，如果服务器返回相同的 ETag 值，则说明响应未修改，缓存有效;

If-Modified-Since 指 客户端缓存的响应的最后修改时间，如果服务器确定响应在此时间后未更改，则返回304 Not Modified状态码，表示缓存有效。

相应的，OkHttp 也支持自定义缓存有效性控制，开发者可以创建一个 CacheControl 对象，并将其作为请求头添加到 Request 中，如下所示:

// 禁止OkHttp使用缓存

val cacheControl = CacheControl.Builder()

            .noCache()

            .build()

val request = Request.Builder()

            .cacheControl(cacheControl)

            .url("https://www.baidu.com")

            .build()

复制代码

OkHttp如何复用TCP连接？

这个其实主要说的是 ConnectInterceptor 拦截器中初始化 Exchange 时内部做的事，具体如下：

OkHttp 使用连接池 RealConnectionPool 管理所有连接，连接池将所有活动的连接存储在池中，并维护了一个空闲的连接列表(TaskQueue)，当需要新的连接时，优先尝试从这个池中找，如果没找到，则 重新创建 一个 RealConnection 连接对象，并将其添加到连接池中。在具体的寻找连接的过程中，一共进行了下面5次尝试：

1. 尝试重连 RealCall 中的 connection，此时不需要重新获取连接；


2. 尝试从连接池中获取一个连接，不带路由与多路复用；


3. 再次尝试从连接池中获取一个连接，带路由，不带多路复用；


4. 手动创建一个新连接；


5. 再次尝试从连接池中获取一个连接，带路由与多路复用；

当然 OkHttp 也支持自定义连接池，具体如下：

上述代码中，创建了一个新的连接池，并设置其保留最多 maxIdleConnections 个空闲连接，并且连接的存活期为 keepAliveDuration 分钟。

OKHttp复用TCP连接的好处是什么？

OkHttp 是由连接池管理所有连接，通过连接池，从而可以限制连接的 最大数量，并且对于空闲的连接有相应的 存活期限 ，以便在长时间不使用后关闭连接。当请求结束时，并且将保留该连接，便于后续 复用 。从而实现了在多个请求之间共享连接，避免多次建立和关闭TCP连接的开销，提高请求效率。

OkHttp中的请求和响应 与 网络请求和响应，这两者有什么不同？

OkHttp 中的的请求和响应指的是客户端创建的请求对象 Request 和 服务端返回的响应对象 Response，这两个对象用于定义请求和响应的信息。网络请求和响应指的是客户端向服务端发送请求，服务端返回相应的过程。

总的来说就是，请求和响应是应用程序内部自己的事，网络请求和响应则是发生在网络上的请求和响应过程。

OkHttp 应用拦截器和网络拦截器的区别？

• 从调用方式上而言，应用拦截器指的是 OkhttpClient.intercetors ，网络拦截器指的是 OkHttpClient.netIntercetors 。


• 从整个责任链的调用来看，应用拦截器一定会被执行一次，而网络拦截器不一定会执行或者执行多次情况，比如当我们 RetryAndFollowUpInterceptor 异常或者 CacheInterceptor 拦截器直接返回了有效缓存，后续的拦截器将不会执行，相应的网络拦截器也自然不会执行到；当我们发生 错误重试 或者 网络重定向 时，网络拦截器此时可能就会执行多次。


• 其次，除了 CallServerInterceptor 与 CacheIntercerceptor 缓存有效之外，每个拦截器都应该至少调用一次 realChain.proceed() 方法。但应用拦截器可以调用多次 processed() 方法，因为其在请求流程中是可以递归调用；而网络拦截器只能调用一次 processed() 方法，否则将导致请求重复提交，影响性能，另外，网络拦截器没有对请求做修改的可能性，因此不需要再次调用 processed() 方法。


• 从 使用方式的 本质而言，应用拦截器可以 拦截和修改请求和响应 ，但 不能修改网络请求和响应 。比如使用应用拦截器添加请求参数、缓存请求结果；网络拦截器可以拦截和修改网络请求和响应。例如使用网络拦截器添加请求头、修改请求内容、检查响应码等。


• 在相应的执行顺序上，网络拦截器是 先进先出(FIFO) ，应用拦截器是 先进后出(FILO) 的方式执行。

结语

本篇中，我们从网络库的迭代历史，一直到 OkHttp 的使用方式、设计思想、源码探索，最后又聊了聊常见的一些问题，从而较系统的了解了 OkHttp 的方方面面，也解释了 OkHttp应用层 的相关问题，当然这些问题我相信也仅仅只是冰山一角🧩。 更多面试相关，或者实际问题，仍需要我们自己再进行完善，从而形成全面的透析力。

这篇文章断断续续写了将近两周，其中肯定有不少部分存在缺陷或者逻辑漏洞，如果您发现了，也可以告诉我。

通过这篇文章，于我个人而言，也是完成了对于 OkHttp应用层 一次较系统的了解，从而也完善了知识拼图中重要的一块，期待作为读者的你也能有如此或者更深的体会。🏃🏻

更多

这是 解码系列 - OkHttp 篇，如果你觉得这个系列写的还不错，不妨点个关注催更一波，当然也可以看看其他篇：

• 由浅入深，详解 Lifecycle 的那些事


• 由浅入深，详解 LiveData 的那些事


• 由浅入深，详解 ViewModel 的那些事


• 由浅入深，详解 LeakCanary 的那些事

参阅

• 深入理解OkHttp源码及设计思想


• OkHttp源码走心解析（很细 很长）


• 拆轮子系列：拆 OkHttp


• OkHttp 源码分析