关于本书的任何意见和建议都可以在这里讨论~

可以在这里免费阅读本书第九章：http://www.ituring.com.cn/book/tupubarticle/25715

书中的代码：https://github.com/berwin/easy-to-understand-Vue.js-examples

也可以加入本书的微信讨论群（群已满100人，添加微信 Berwin1995 我拉进群，加我好友时建议说明自己是Vue.js读者）。

需求分析与开发时间评估

今天想谈一谈关于“需求分析”和“开发时间”这两个话题，工作这么些年还是头一次公然讨论这个话题，今天聊一下我对这两个话题的浅见。

需求分析

早些年在我刚开始工作时，我认为“需求分析”就是听一听产品经理提的需求，评估下开发可行性和难度，把实现不了的需求砍掉。

这么多年过去了，我发现这是最Low Level的需求分析。

原因在于当时的我完全不知道产品经理为什么要提出这个需求，我甚至压根没有关注过这个问题，当时的我只关注这个需求如何实现，难度如何。所以我很难理解产品经理，甚至经常站在技术的角度认为产品经理提出的这个需求好SB啊，他是智障吗？

但其实产品经理和工程师不应该是敌对关系，应该是“搭档”，现在我和我们的产品经理一直是搭档关系，我们的关系很融洽，因为我们的目标是一致的：让我们的产品，满足用户的需求。

但有时候产品经理提出的需求可能不是很正确，这个时候需要工程师进行辅助。这里面有很多原因：

1. 产品经理可能对技术的边界不是很了解，所以无法充分利用技术解决用户需求
2. 对用户原始需求的理解是很难传递的
3. 产品经理对用户需求的理解有误
4. 其他

我们先讨论第一点：“产品经理可能对技术的边界不是很了解”。

产品经理可能对技术的边界不是很了解

优秀的产品经理是需要有技术广度的，他不一定要深入了解技术的原理，但一定要理解技术的边界。某个技术能做什么，不能做什么，最近是不是又有新技术了，和我的产品有关系吗？

但通常大多数产品经理都比较缺乏技术广度，所以这个时候需要工程师去补位。

但工程师去补位有一个前提，那就是工程师真的理解产品经理，理解他在想什么。这就要谈到第二点：对用户原始需求的理解很难传递。

对用户原始需求的理解很难传递

很多时候，产品只是发了个产品文档过来，然后就拉着技术做“需求评审”，但其实这份需求文档，是产品经理对用户需求理解的二次加工。工程师在这份需求文档里是很难看清用户的原始需求的。

比如：用户需要一个消息提醒。产品经理可能是不知道有Web Push Notifications这项技术，也可能是对用户需求理解有误，总之最终提出来的需求是在网页的最顶部添加一个消息通知功能。

所以工程师应该主动去了解用户的原始需求是什么，当工程师能理解用户的原始需求是什么时，也就能理解产品经理为什么提这个需求了，就可以在这个时候成为产品经理的搭档，提醒他，有一项技术叫做Web Push Notifications，它的能力边界是什么。

一个好的需求，应该是技术深度参与，而不是产品经理单方面输出一个产品需求文档，因为产品经理有时候也会犯错，这就是我们要谈论的第三点：产品经理对用户需求的理解有误。

产品经理对用户需求的理解有误

有时候用户反馈需求，或者产品经理在推测用户想要什么的时候，往往得到的答案是不正确的。因为有时候用户自己也不知道他需要什么。有一句名言非常有名：你如果问用户想要什么，他的回答是“一匹更快的马”，而不是汽车。

所以工程师要理解用户的原始需求，并且有自己的看法，这样不光可以给产品经理提出建设性意见，并且还可以对技术方案进行“预判”，如何设计项目的架构？最重要的就是要对产品未来的发展方向进行“预判”，一方面要对未来的改动 “做足准备”，另一方面也要避免 “过度设计”。

小结

总之需求分析不是简单的听一听产品经理提的需求，评估下开发可行性和难度，把实现不了的需求砍掉。而是去理解用户的原始需求，和产品经理成为“搭档”，在产品经理因为缺乏技术广度或其他原因导致提出坏需求时，给出提醒并提供建设性意见。

所以你会发现我的标题叫做“需求分析”而不是“需求评审”，因为“需求评审”的潜台词是：我不知道用户需要什么，我只知道产品如果提出了SB需求我就给这个需求砍掉。

讨论完需求分析，接下来讨论下“开发时间评估”。

开发时间评估

工作这么些年，直到今天我依然无法“准确”评估开发时间。

我认为是我的问题，是我没有掌握某些评估开发时间的方法论，为此我找了组内的技术专家和我的Leader请教他们是如何评估开发时间的。技术专家告诉我，可以用自己估算出的时间，乘以一个系数。我的Leader告诉我，可以根据以往的经验，来评估某个需求需要开发多少个“工作日”。

比如评估了5个工作日，但实际开发可能需要一个10个工作日。因为每天不一定一整天都在开发，还会去开会和处理其他杂事。

我评估的不是自然日什么时间完成，而是这个需求要多少个“有效工作日”可以完成。

评估好了有效工作日数，就可以根据工作日看需求的类型，有些需求是绝对不允许延期的，比如618，双十一这种需求都是不可能延期的，对于不可以延期的需求，如果评估出的有效工作日已经超出Deadline，那么这时候需要让产品经理把这个需求需要完成的所有功能的“重要程度”列出来，优先开发最重要的功能。如果评估后发现连最重要的功能都无法在Deadline之前完成，那么解决方案有两种，一种是寻求更多的资源，另一种是这个需求就整个砍掉。

听完之后，我学到了很多知识，“除了预估开发时间，别的我都学会了”。无论是“用评估的时间乘以一个系数”还是“根据经验评估有效工作日”，都没有正面回答如何准确预估开发时间的问题。

后来我又看了一些书，得出了一个结论：没有人可以准确估算出开发时间，准确估算开发时间是不可能的。

即使是特别简单的需求，也是无法准确评估开发时间的，例如：我可以准确的评估出我用一个工作日可以封装一个JSONP，但我无法准确评估几个小时能完成。

这不是抬杠，这是一个道理，我虽然不知道我几个小时能完成，但是我知道我一天可以完成，我虽然不知道几天可以完成，但我知道一个星期肯定可以完成。

既然结论是评估的时间根本不准，那就不评估了么？和产品经理说我不知道需要多久，开发完了我再找你？肯定不行，产品经理一定会要一个开发时间，必须得给一个，哪怕不准。

既然开发时间是无法准确评估的，而我们又必须给一个开发时间，那么我们要做的事就不再是如何评估开发时间了，而是变成了“风险管理”。

风险管理

风险管理最常用的方法叫：留点余地。

这种方法的**是，我知道自己评估的工作日不准，那么为了应对各种意料之外的事发生，我需要安排一些额外的时间来以备不测。

可能遇到的风险：

1. 这个功能比我预期的要难，需要更多的开发时间
2. 团队成员有急事请了两天假
3. 其他

用自己评估的工作日乘以一个系数，就属于这种类型。有一篇文章《我在淘宝做前端的这三年——第二年》里也介绍了一种方法也属于这种类型：

• 需求非常明确而且经常这样做：评估的工作日*1.5
• 需求不清晰，有可能变，但代码和技术方案熟悉：评估的工作日*2
• 需求不清晰，代码和技术方案也不熟悉需要探索：评估的时间*2.5

越不确定的事，未知的东西越多，风险越高，所以需要留有更多的时间以备不测。

我一般会问产品经理一个问题，我会和他说：你想要保守点的时间还是正常点的时间？保守点的是我用系数乘后的结果，正常点的是我凭经验和感觉认为多久能完成。

然后我会和他说：正常的时间，不一定准，我不能保证这个时间一定会完成，我只能尽力去完成，但保守的时间一定会完成。

通常最终商量后的结果就是把时间定到保守的时间上，然后开发尽量提前完成，但是最晚也不会超过保守的时间。

如果连不准确的开发时间都评估不出来，上面的方案不就失效了，那怎么办？

还有一个非常简单粗暴的方法：可以把需求难度分为三个等级：简单、中等、困难。

• 简单需求：需要2~3个有效工作日
• 中等需求：需要2~3周
• 困难需求：需要2~3个月

对于简单和中等难度的需求，在需求有DeadLine并且评估后发现最重要的功能也无法在Deadline之前完成，那么可以靠“堆人”来换取时间，但只适用于简单和中等难度的需求。对于复杂的需求，人员的数量根本没用，唯一可以让开发时间提前两个月以上，并且技术方案和质量都有保障的方案是：需要一个该领域的专家。

小结

经过我自己的经验和我请教的各种专家来看，结论是：开发时间的评估完全靠感觉，感觉是不靠谱的，所以最重要的事是做风险管理。

时间好快，眨眼间，加入阿里已经一年了。这一年发生了很多事，整体上非常地充实且精彩，在一件又一件事情中，我不停地犯错，一路走来，步履蹒跚，也收获到了很多成长。每次结束一件事后，经过短暂宁静的生活便再次踏上新的征程。

之前写过一篇《我在阿里半年收获的成长》，因此文本主要讲述“后半年”收获的成长。

1. 关于“思考”

• Mentor：你平时周末都做些什么？
• 我：没事的时候通常会看看书，写写代码，研究一些自己感兴趣的东西
• Mentor：可以把一些平时做事的时间换成什么都不做，坐在那“思考”，想一些东西

以上对话来自一次我向导师询问的一个问题：“我应该如何再进一步，7和8的区别是什么”（大致是这个问题，原问题记不清了😿）。

7和8之间就级别本身的区别优势是 “可以调动更多资源”。之所以需要调动更多资源是因为需要做更复杂的事。复杂的事哪来？ “思考得来”，当然也可以靠主管分配，但谁又能保证主管一定会把那个机遇分配给自己。

完全靠主管分配机遇，这也违背我内心一直以来所坚定的信念： “让事情因为自己而与众不同”。今天能通过面试进入到阿里巴巴的同学，能力都不差，主管把机遇分配给另一个人绝大概率拿到的结果不会比我差多少，一件事情究竟是因为我去做才拿到好结果，还是大家去做都能拿到好结果，不太好说，这达不到 “让事情因为自己而与众不同” 的标准。

只有自己凭空创造出的机遇并最终拿到了结果，才符合 “让事情因为自己而与众不同”，也更能展现出自己的水平。

所以一个更可靠的发展路径是：

1. 多思考项目未来的发展方向和现有技术体系的问题
2. 做判断并按照正确的方向执行
3. 事情足够大就会衍生出调动更多资源的需求
4. 时机成熟后，可能会晋升到下一个级别以方便调动更多资源

这会衍生出一个新问题，“如果自己思考的项目未来发展方向和大团队方向不一致怎么办？”

其实不用担心，可以和主管多沟通对焦，如果自己思考得来的方向客观事实上是正确的方向（各方面受益都更高）或者是绝大多数人都信任是一个正确的方向，那么正确的方向一定会替换掉错误的方向。

2. 技术与业务两跳腿走路

一定要 “技术与业务两跳腿走路”。这是我主管和我导师对我的忠告，当两个经验丰厚的大佬不约而同地给了相同的建议，足以证明这句话的分量，这也引起我深思。

自从我开始工作，我都是只搞技术，我对业务其实不太感兴趣，我很崇拜那些知名的技术很强的世界顶级工程师，一直以来我的梦想都是想成为他们中的一员，想成为前端行业技术吊炸天的世界顶级工程师。

但现在我渐渐意识到，不能只搞技术，也要多思考思考自己的业务，这对自己是有好处的，对业务多思考的好处是：

1. 提前对技术体系做布局，引领技术与项目，避免业务突然变化时陷入被动
2. 对现有支撑业务“较为成熟”的“有瓶颈”的技术体系做出改革与突破
3. 避免让自己成为“工具人”

让“技术”和“业务”互相成就彼此，共同成长。业务发展倒逼技术改进，技术改进成就业务，相佐相成。身为技术同学，可以基于对业务的预判用技术落地项目辅佐业务，业务的成功再反过来成就技术。

千万不要陷入到一个巨大的误区：技术的自嗨，其实并没有多大贡献。

所有伟大的技术创新，都是那些对社会有巨大贡献的技术，伟大技术的诞生，都是基于一个不被满足的“需求”，基本上伟大的技术都是这样被创造出来的（Git、React、Vue又或是支撑公司业务背后的技术体系）。

只有对业务足够了解，思考的足够深，才能知道用户需要什么，才有可能引领未来支撑业务的技术体系，才有可能创造出改变世界的伟大的技术。

一门心思只搞技术，很难做到“引领”和“创新”。大概率只能做到学习现有已被其他人创造出来的技术，学到精通，成为某领域专家，但很难引领某个技术领域。

3. 稳定发挥

发挥稳定型（线性增长）选手比阶段性发挥波峰波谷选手更有优势，稳定（可预测性）本身就是一种优点。发挥不稳定的选手，缺点是不可预测，换位思考如果自己是主管，有一件很重要的事，你敢交给发挥不稳定的选手么，万一碰上发挥较弱的时间段，就悲剧了。

这个道理，在电子竞技、体育竞技等领域都相通，发挥不稳定是不可能拿到冠军的。

刚进入一家公司，在一个新环境都会有点着急，急于拿到成绩得到认可，这本身其实是件好事，但不要把劲使大了，把自己变成了那个波峰波谷型选手。放轻松一点，少使点劲，让自己线性成长稳定发挥。毕竟，职业生涯本就是一场“没有终点的长跑”，大家比拼的并不是短期内谁跑的更快，而是“坚持”，在这条赛道上能跑赢的，不是那些跑得快的人，而是为数不多坚持跑的人，他们能跑赢，只是因为还在跑。

4. 求同尊异

某一刻，我终于理解了这四个字，这要从一件事说起。

最开始，为了帮助团队成员“提升个人写作”、“提升表达能力”、“提升个人技术成长”，我提出了文章计划，团队成员每个人大概每5个月写一篇文章，同时发明了 “贝利体系” 作为奖惩机制，每人每月按照一定的数量自动掉贝利，贝利掉多了需要接受惩罚，发表了文章后奖励贝利，只要保证每5个月写一篇文章贝利就不会达到惩罚线，具体数值都是我计算好的，并写了段程序自动执行，拿到手里的贝利可以用来兑换一些礼物，有HHKB、AirPods等可以兑换。

后来“文章计划”受到了大家的集体挑战，觉得给大家照成了非常大的压力和负担，“文章计划”就宣告结束，不过 “贝利体系” 被我保留了下来，虽然不强制大家写文章了，但依然鼓励自愿写文章的同学，并给予贝利奖励。

这时我对贝利体系进行了一些思考，并重新定位：“衡量体系”，衡量团队成员对“团队建设”、“组织文化”、“横向贡献”的贡献值，助力团队和文化的横向建设。简单来说，就是所有对团队横向有付出的同学，我都会按照贡献的大小付出的多少来奖励贝利，且有一个排名，排名高代表横向贡献多，我会给予贡献多的一些同学发一些礼品，贝利本身也可以自行兑换礼物：HHKB、AirPods等。

我希望贝利体系和团队横向的事情，例如：团建、招聘、安全生产、写文章、技术分享、对现有产品提改进建议、组织大家健身、组织大家玩桌游等有更深度的结合。

因此，有一天，我提出一个想法：让贝利少的人举办团队的团建，并给予举办团建的人奖励贝利，主要考虑给团队横向贡献少的同学多些机会做些贡献。且在团建过程中结合贝利有一些有趣的玩法，例如可以按照贝利的多少设定初始装备（贝利高，团建玩游戏时略有优势，但又不失平衡）。

但这个提议被团队负责团建的同事拒绝（因为他认为贝利不客观公正，无法客观衡量谁贡献少）。当时我觉得这是一个对团队有帮助的好事，可能它暂时不完美，但我会持续优化，我是在“坚持做正确的事”。而且当场我问同事觉得哪里有缺陷需要改进也说不上来，再加上我觉得自己在做正确的事，在让这个团队变得更好，所以我就和同事大吵了一架，对，我又双叒叕和人吵架了，而且这次格外激烈。

我对自己进行了深度的反思，“贝利体系”打被我凭空创造出来之后，无论是面向用户，还是面向合作方，都不是很受欢迎。面向客户，团队成员觉得这是一种压力和负担。面向合作方，团队横向负责人没有与贝利体系合作的动力和需求。这件事本身不是大事，但做这件事却非常难，贝利诞生到现在一直被大家抵触，被大家无视，还有人觉得这是几个人之间的小众游戏。

但我又不想放弃，我想让我们团队因为我的存在变得不一样，而我又坚信这是正确的事，是一件好事。为此我和主管聊了两三次，学到了一些知识和做事的方法，总结提炼出精华：

• 不要以自己为中心去思考问题，要换位到“团队视角”，“合作视角”全方位立体多维度思考问题
• 推进事情要考虑：“共赢”，“利他”

贝利体系诞生以来，所有的“规则”（包括哪些贡献应该奖励，奖励多少）都是我一个人定，大家内心是“不认可”的，因此外在表现就是“你自己玩你自己的，我不参与”。换位思考，每个人都会抵触自己“不认可”的事情。

这一刻我终于体会到，也理解了什么叫 “求同尊异”，每个人都不一样，也不是所有人都和自己想法一样，要尊重不同的建议和声音。一件事，只有大家认可了才能赢得尊重和成功，要赢得客户的认可，赢得合作伙伴的认可。

后续：

这件事之后，现有的“规则”我都通过匿名调查问卷的方式投票决定，调查大家认为哪些应该奖励，应该奖励多少，哪些不应该奖励，并根据调查问卷的结果进行了修改。

所有的规则，完全由匿名投票大家共同决定，规则制度“公开透明”，由全体成员“共同参与”。并且提供了日常的“实名”和“匿名”双通道接收意见反馈，并给反馈意见的同学奖励贝利。获取贝利和消耗贝利的方式也变得更加的多样化。且这些新的多元化的获取和消耗贝利的方式都是由团队成员大家共同贡献出来的。经过一系列的调整，整体认可度相比之前有了很大的改善，贝利体系在向着更好的方向迈进。

年前也按照大家的贝利数量给大家发放了同等价值的礼品，并启动新一轮周期，大家都很开心。

这件事虽然不大，但是它教会了我 “如何推进事情”，未来我大概率会打破现有已经“成熟”甚至“固化”的技术体系，为现有技术体系做一些改进，让它变的更好，那么推进并赢得大家的“认可”和“尊重”与这件事是相同的，通过这件事，我提前得到了锻炼，这是无价的宝藏。

5. 身为PM如何做事

感谢主管的培养和信任，不止给我很多试错空间，还在我犯错后教我如何做才是正确的做法。

5.1 “风险”和“进展”及时同步

关于风险同步在《我在阿里半年收获的成长》有提到过，最近又有了新的感悟：不要担心“做的不好”或“不完美”而不敢同步进展和风险，因为“差的信息”比“没有信息”要好很多！

及时同步“风险”和“进展”的好处是：如果真的做错了，会得到及时的纠正和帮助，可以保证项目是安全的，项目安全永远是第一位。不要担心大家会觉得自己菜，自己菜不菜根本没人关心，大家关心是：

1. 项目能不能“按期”、“高质”交付
2. 你是否在成长

哪怕中途做一步错一步，也比中途“毫无音讯”强无数倍。 即便是中途做一步错一步，但由于及时同步了风险和进度，在不停地犯错中一点点把项目做好，最终大家也会看到自己的成长。会对自己很放心，下次类似的事情交给自己会让人安心，因为再差再差，自己也不会把事情搞砸。

5.2 线上问题如何应对

线上出了事故后，立刻向上汇报，不要自己先闷着头去修复！避免业务方找过来时主管完全不知情，这种情况整体都会很被动！

反馈问题的方式：

1. 站在用户视角描述发生的问题
2. 影响面预估（面向用户的影响面，不是判断技术哪里报错，判断不清楚默认当做重大影响处理）
3. 处理策略
4. 如果有原因，提供原因

5.3 不要把自己当做唯一的资源

当接到一个任务后，首先考虑的是 “怎样把这件事做的更好”，“谁来做更合适”，不要把自己当做唯一的资源。

合适的事让合适的人来负责，接到任务后第一个想的是如何把事做好，谁来做更合适，如果自己擅长某一块可以自己去做，如果某一块有更合适的人选，那就应该找到合适的人来做，而不是自己去做。

5.4 “悲观”态度给答复

如果评估不准某个功能是否可以按期上线，一律按 “悲观” 态度给反馈（本质其实是：提升专业性，预判风险，做好预期管理）。新手PM都会犯一个错，那就是，虽然心里感觉大概率在Deadline前开发不完，但还是会和产品说：“我试试”。

我见过的，除了我还有新手PM也犯了这个错，那就是一句：“我试试”（觉得大概率来不及，但还是和产品说感觉来不及，但我努努力试试）。最终没有按期上线时产品就会找过来问为什么没有上线，“不认可”这个结果。

所以，如果评估不准，或感觉有风险，一律给悲观答复。如果一开始有来不及的可能，在一开始就给来不及的 “明确反馈”。

5.5 做技术判断

技术PM最重要的核心竞争力和职责叫做：技术判断。像双11这种级别的大促，每个功能所涉及的上下游链路都会非常复杂，横跨N多个团队，这就意味着，同一件事，可以有N种解决方案，而不同团队看待问题的视角不同，因此大家给出的方案和倾向性很多时候会有冲突，这时候技术PM要做的就是给一个技术判断，方案1、2、3、优缺点是什么，让高年级同学拍板。而不是把一个问题抛上去让高年级同学们想方案。因为信息是越底层知道的越多，越上层对细节的信息越少。

6. 总结

不知不觉，来阿里已经一年了。这一年是我近几年来成长最快的一年，自己的思维和想法，都有了质的提升。非常感谢舒文把我带到这个团队，以我的学历正常很难进到这个团队，经常感叹自己真的是凭运气遇到贵人。还非常感谢墨冥（我的主管），这一年来不断地言传身教并给予机会试错，这一年来的成长（可参考这两篇文章《我在阿里半年收获的成长》、《我在阿里一年收获的成长》）绝大部分来自墨冥的教导，再次感叹自己的好运气。

相信未来，我会在实战中承担更大的职责，相信未来，我会让我们团队因为我的存在变得不一样。

最后，在舒文身上学到了一个原则，特别认同：

学会坚持，“长时间的积累”永远比“为了短期高收益频繁切换”收益高，无论是“日常做事”、“投资”还是“职业规划”、“人生规划”等。

舒文经常说：“做成一件事情”有很多因素，“坚持”是成本最低的一种。

前端工程师如何在业余时间提升自己？

其实提升自己没有秘籍和诀窍，只要愿意花业余时间去学习，再加上长时间的坚持，就可以成为大神。

读书

我个人比较喜欢读书，喜欢读纸质的书，记得刚开始工作的时候，很多东西都不会，只会写CSS切页面，是一名真切图仔，同时自己又特别想成为大神，然后就每天中午吃完饭在工位上看一个小时的书，下班后也会留在公司看两个小时的书再回家，就这样每天中午和晚上一边看书一边写Demo，前期的提升速度还是非常明显的，基本上每天都能感觉到自己学会了新知识。

我比较推荐多读一些技术书，特别是纸质书，熟悉我的同学都知道我有非常多的书。一本书从填选题表到最终出版，中间会经历很多步骤，出版社专业的编辑也会和作者一起反复的校验和修改好多遍，上市之后再经过读者的认可，这样一本书的内容质量是非常有保障的。根据经验图灵出版的书质量都非常高。

学习资料

学习资料非常重要，要阅读高质量的第一手资料，很多时候我们学习某个技术发现怎么都学不会搞不懂时可能不一定是我们笨，也有可能是学习资料有问题。

我见过很多文章讲某个技术，即使那个技术我事先已经会了，也确实看不懂文章里在说些什么。我也见过很多文章可能作者自己也不是很懂某个技术，他只是把一些其他文章拼凑起来。

不好的学习资料通常内容晦涩难懂且没有把技术讲清楚，而高质量的学习资料通常会很清晰且精准地把一个技术讲透，因为讲解清晰明确，所以学习起来也不会太复杂枯燥。

JS框架、库、工具等，我一般会从官网和口碑较好的纸质书籍中学习。基础知识我一般通过阅读高质量的纸质书籍 + 阅读W3C的规范来学习。Web性能领域我通常在Chrome开发者官网和web.dev里的文章来学习。

具备了一定的基础知识后就可以判断出学习资料的质量，这时候就可以关注一些公众号或者明星程序员来获取一些知识。

写作与分享

除了学习，我还会利用业余时间写文章，做技术分享等，将自己学到的知识分享出去。切身体会，将自己学到的知识分享出去对自己的成长有很大帮助，有时候写文章的过程中会发现自己对某个知识也没有真的学透。

而且写作和分享可以让自己学会思考并锻炼思考能力，而思考能力其实很重要。

坚持

最后，坚持才是最重要的，我们的职业生涯，其实是一场没有终点的长跑比赛，很多人可能想问怎样才能跑得更快，把这场比赛跑赢。其实在这条没有终点的赛道上在短期内快一些没有任何意义。大部分人跑到中途就主动放弃了，这就是为什么大牛那么少。唯一能决定这场比赛输赢的，只有两个字叫 “坚持”。在这条赛道上跑赢的，不是那些跑得快的人，而是为数不多坚持跑的人。他们能跑赢，只是因为他们还在跑。

书单推荐

最后推荐一些书单，全都是我自己看过的觉得非常不错的书。

JavaScript相关的书籍：《你不知道的JavaScript》上中下共三本、《深入理解ES6》、《JavaScript高级程序设计》

CSS相关的书我都没有亲自看过，但我是看张鑫旭博客学的CSS，他出版的书我虽然没看，但凭着对作者的信任，而且作者还专门为这本书做了个官网感觉还是蛮用心的，质量应该是可以保障的：《CSS世界》。

JS框架相关的书籍，React相关我没有看过不做推荐，Vue相关的推荐一本：《深入浅出Vue.js》（真不是打广告，内容质量和深度确实是目前市面上最好的一本）。

Node.js相关的书籍，只看过一本朴灵大大写的质量还行，别的没看过，所以只推荐这本：《深入浅出Node.js》。

再分享下其他我看过的觉得不错的书：《算法4》、《Web性能权威指南》（作者是前任W3C性能工作组主席，译者是李松峰老师，虽然这本书出版快10年了，但我感觉还是值得一看的）、《重构》、《码农翻身》、《代码整洁之道》、《软技能 - 代码之外的生存指南》、《金字塔原理》。

Vue 项目架构设计与工程化实践

转载文章请注明出处，谢谢 #14

文中会讲述我从0~1搭建一个前后端分离的vue项目详细过程

Feature：

• 一套很实用的架构设计
• 通过 cli 工具生成新项目
• 通过 cli 工具初始化配置文件
• 编译源码与自动上传CDN
• Mock 数据
• 反向检测server api接口是否符合预期

前段时间我们导航在开发一款新的产品，名叫 快言，是一个主题词社区，具体这个产品是干什么的就不展开讲了，有兴趣的小伙伴可以点进去玩一玩~

这个项目的1.0乞丐版上线后，需要一个管理系统来管理这个产品，这个时候我手里快言项目的功能已经上线，暂时没有其他需要开发的功能，所以我跑去找我老大把后台这个项目给拿下了。

技术选型

接到这个任务后，我首先考虑这个项目日后会变得非常复杂，功能会非常多。所以需要精心设计项目架构和开发流程，保证项目后期复杂度越来越高的时候，代码可维护性依然保持最初的状态

后台项目需要频繁的发送请求，操作dom，以及维护各种状态，所以我需要先为项目选择一款合适的mvvm框架，综合考虑最后项目框架选择使用 Vue，原因是：

• 上手简单，团队新人可以很容易就参与到这个项目中进行开发，对开发者水平要求较低（毕竟是团队项目，门槛低我觉得非常重要）
• 我个人本身对Vue还算比较熟悉，一年前2.0还没发布的时候阅读过vue 1.x的源码，对vue的原理有了解，项目开发中遇到的所有问题我都有信心能解决掉
• 调研了我们团队的成员，大部分都使用过vue，对vue多少都有过开发经验，并且之前团队内也用vue开发过一些项目

所以最终选择了Vue

选择vue周边依赖（全家桶）

框架定了Vue 后，接下来我需要挑选一些vue套餐来帮助开发，我挑选的套餐有：

• vuex - 项目复杂后，使用vuex来管理状态必不可少
• element-ui - 基于vue2.0 的组件库，饿了么的这套组件库还挺好用的，功能也全
• vue-router - 单页应用必不可少需要使用前端路由（这种管理系统非常适合单页应用，系统经常需要频繁的切换页面，使用单页应用可以很快速的切换页面而且数据也是按需加载，不会重复加载依赖）
• axios - vue 官方推荐的http客户端
• vue-cli 的 webpack 模板，这套模板是功能最全的，有hot reload，linting，testing，css extraction 等功能

架构设计

在开发这个项目前，我去参加了北京的首届 vueconf 大会，其中有一个主题是阴明讲的《掘金 Vue.js 2.0 后端渲染及重构实践》，讲了掘金重构后的架构设计，我觉得他们的架构设计的挺不错，所以参考掘金的架构，设计了一个更适合我们自己业务场景的架构

整体架构图

目录结构

.
├── README.md
├── build                   # build 脚本
├── config                  # prod/dev build config 文件
├── hera                    # 代码发布上线
├── index.html              # 最基础的网页
├── package.json
├── src                     # Vue.js 核心业务
│   ├── App.vue             # App Root Component
│   ├── api                 # 接入后端服务的基础 API
│   ├── assets              # 静态文件
│   ├── components          # 组件
│   ├── event-bus           # Event Bus 事件总线，类似 EventEmitter
│   ├── main.js             # Vue 入口文件
│   ├── router              # 路由
│   ├── service             # 服务
│   ├── store               # Vuex 状态管理
│   ├── util                # 通用 utility，directive, mixin 还有绑定到 Vue.prototype 的函数
│   └── view                # 各个页面
├── static                  # DevServer 静态文件
└── test                    # 测试

从目录结构上，可以发现我们的项目中没有后端代码，因为我们是纯前端工程，整个git仓库都是前端代码，包括后期发布上线都是前端项目独立上线，不依赖后端~

代码发布上线的时候会先进行编译，编译的结果是一个无任何依赖的html文件 index.html，然后把这个 index.html 发布到服务器上，在编译阶段所有的依赖，包括css，js，图片，字体等都会自动上传到cdn上，最后生成一个无任何依赖的纯html，大概是下面的样子：

<!DOCTYPE html><html><head><meta charset=utf-8><title>快言管理后台</title><link rel=icon href=https://www.360.cn/favicon.ico><link href=http://s3.qhres.com/static/***.css rel=stylesheet></head><body><div id=app></div><script type=text/javascript src=http://s2.qhres.com/static/***.js></script><script type=text/javascript src=http://s8.qhres.com/static/***.js></script><script type=text/javascript src=http://s2.qhres.com/static/***.js></script></body></html>

表现层

• store/ - Vuex 状态管理
• router/ - 前端路由
• view/ - 各个业务页面
• component/ - 通用组件

业务层

• service/ - 处理服务端返回的数据（类似data format），例如 service 同时调用了不同的api，把不同的返回数据整合在一起在统一发送到 store 中

API 层

• api/ - 请求数据，Mock数据，反向校验后端api

util 层

• util/ - 存放项目全局的工具函数
• … 如果后期项目需要，例如需要写一些vue自定义的指令，可以在这个根据需要自行创建目录，也属于util层

基础设施层

• init - 自动化初始化配置文件
• dev - 启动dev-server，hot-reload，http-proxy 等辅助开发
• deploy - 编译源码，静态文件上传cdn，生成html，发布上线

全局事件机制

• event-bus/ - 主要用来处理特殊需求

关于这一层我想详细说一下，这一层最开始我觉得没什么用，并且这个东西很危险，新手操作不当很容易出bug，所以就没加，后来有一个需求正好用到了我才知道event-bus是用来干什么的

event-bus 我不推荐在业务中使用，在业务中使用这种全局的事件机制非常容易出bug，而且大部分需求通过vuex维护状态就能解决，那 event-bus 是用来干什么的呢？

用来处理特殊需求的，，，，那什么是特殊需求呢，我说一下我们在什么地方用到了event-bus

场景：
我们的项目是纯前端项目，又是个管理系统，所以登陆功能就比较神奇

上面是登陆的整体流程图，关于登陆前端需要做几个事情：

1. 监听所有api的响应，如果未登录后端会返回一个错误码
2. 如果后端返回一个未登录的错误码，前端需要跳转到公司统一的登陆中心去登陆，登陆成功后会跳转回当前地址并在url上携带sid
3. 监听所有路由，如果发现路由上带有sid，说明是从登陆中心跳过来的，用这个sid去请求一下用户信息
4. 登陆成功并拿到用户信息

经过上面一系列的登陆流程，最后的结果是登陆之后会拿到一个用户信息，这个获取用户信息的操作是在router里发起的执行，那么问题就来了，router中拿到了用户信息我希望把这个用户信息放到store里，因为在router中拿不到vue实例，无法直接操作vuex的方法，这个时候如果没有 event-bus 就很难操作。

所以通常 event-bus 我们都会用在表现层下面的其他层级（没有vue实例）之间通信，而且必须要很清楚自己在做什么

为什么 event-bus 很容易出问题？好像它就是一个普通的事件机制而已，为什么那么危险？

这是个好问题，我说一下我曾经遇到的一个问题。先描述一个很简单的业务场景：“进入一个页面然后加载列表，然后点击了翻页，重新拉取一下列表”

用event-bus来写的话是这样的：

watch: {
  '$route' () {
    EventHub.$emit('word:refreshList')
  }
},
mounted () {
  EventBus.$on('word:refreshList', _ => {
    this.changeLoadingState(true)
      .then(this.fetchList)
      .then(this.changeLoadingState.bind(this, false))
      .catch(this.changeLoadingState.bind(this, false))
  })
  EventBus.$emit('word:refreshList')
}

watch 路由，点击翻页后触发事件重新拉取一下列表，

功能写完后测试了发现功能都好使，没什么问题就上线了

然后过了几天偶然一次发现怎么 network 里这么多重复的请求？点了一次翻页怎么发了这么多个 fetchList 的请求？？？什么情况？？？？

这里有一个新手很容易忽略的问题，即便是经验非常丰富的人也会在不注意的情况犯错，那就是生命周期不同步的问题，event-bus 的声明周期是全局的，只有在页面刷新的时候 event-bus 才会重置内部状态，而组件的声明周期相对来说就短了很多，所以上面的代码当我进入这个组件然后又销毁了这个组件然后又进入这个组件反复几次之后就会在 event-bus 中监听了很多个 word:refreshList 事件，每次触发事件实际都会有好多个函数在执行，所以才会在 network 中发现N多个相同的请求。

所以发现这个bug之后赶紧加了几行代码把这个问题修复了：

destroyed () {
  EventHub.$off('word:refreshList')
}

自从出了这个问题之后，我就像与我一同开发后台的小伙伴说了这个事，建议所有业务需求最好不要在使用event-bus了，除非很清楚的知道自己正在干什么。

发布上线

项目架构搭建好了之后已经可以开始写业务了，所以我每天的白天是在开发业务功能，晚上和周末的时间用来开发编译上线的功能

编译源码

前面说了我们的项目是纯前端工程，所以期望是编译出一个无任何依赖的纯html文件

在使用 vue-cli 初始化项目的时候，官方的 webpack 模板会把webpack的配置都设置好，项目生成好了之后直接运行 npm run build 就可以编译源码，但是编译出来的html中依赖的js、css是本地的，所以我现在要做的事情就是想办法把这些编译后的静态文件上传cdn，然后把html中的本地地址替换成上传cdn之后的地址

项目是通过webpack插件 HtmlWebpackPlugin 来生成html的，所以我想这个插件应该会有接口来辅助我完成任务，所以我查看了这个插件的文档，发现这个插件会触发一些事件，我感觉这些事件应该可以帮助我完成任务，所以我写了demo来尝试一下各个事件都是干什么用的以及有什么区别，经过尝试发现了一个事件名叫 html-webpack-plugin-alter-asset-tags的事件可以帮助我完成任务，所以我写了下面这样的代码：

var qcdn = require('@q/qcdn')

function CdnPlugin (options) {}

CdnPlugin.prototype.apply = function (compiler) {
  compiler.plugin('compilation', function(compilation) {
    compilation.plugin('html-webpack-plugin-alter-asset-tags', function(htmlPluginData, callback) {
      console.log('> Static file uploading cdn...')

      var bodys = htmlPluginData.body.map(upload(compilation, htmlPluginData, 'body'))
      var heads = htmlPluginData.head.map(upload(compilation, htmlPluginData, 'head'))

      Promise.all(heads.concat(bodys))
        .then(function (result) {
          console.log('> Static file upload cdn done!')
          callback(null, htmlPluginData)
        })
        .catch(callback)
    })
  })
}

var extMap = {
  script: {
    ext: 'js',
    src: 'src'
  },
  link: {
    ext: 'css',
    src: 'href'
  },
}

function upload (compilation, htmlPluginData, type) {
  return function (item, i) {
    if (!extMap[item.tagName]) return Promise.resolve()
    var source = compilation.assets[item.attributes[extMap[item.tagName].src].replace(/^(\/)*/g, '')].source()
    return qcdn.content(source, extMap[item.tagName].ext)
      .then(function qcdnDone(url) {
        htmlPluginData[type][i].attributes[extMap[item.tagName].src] = url
        return url
      })
  }
}

module.exports = CdnPlugin

其实原理并不复杂，compilation.assets 里保存了文件内容，htmlPluginData 里保存了如何输出html， 所以从 compilation.assets 中读取到文件内容然后上传CDN，然后用上传后的CDN地址把htmlPluginData 中的本地地址替换掉就行了。

然后将这个插件添加到build/webpack.prod.conf.js配置文件中。

这里有个关键点是，html中的依赖和静态文件中的依赖是不同的处理方式。

什么意思呢，举个例子：

源码编译后生成了几个静态文件，把这些静态文件上传到cdn，然后用cdn地址替换掉html里的本地地址（就是上面CdnPlugin刚刚做的事情）

你以为完事了？ No！No！No！

CdnPlugin 只是把在html中引入的编译后的js，css上传了cdn，但是js，css中引入的图片或者字体等文件并没上传cdn

如果代码中引入了本地的某个图片或字体，编译后这些地址还是本地的，此时的html是有依赖的，是不纯的，如果只把html上线了，代码中依赖的这些图片和字体在服务器上找不到文件就会有问题

所以需要先把源码中依赖的静态文件（图片，字体等）上传到cdn，然后在把编译后的静态文件（js，css）上传cdn。

代码中依赖的静态文件例如图片，怎么上传cdn呢？

答案是用 loader 来实现，webpack 中的 loader 以我的理解它是一个filter，或者是中间件，总之就是 import 一个文件的时候，这个文件先通过loader 过滤一遍，把过滤后的结果返回，过滤的过程可以是 babel 这种编译代码，当然也可以是上传cdn，所以我写了下面这样的代码：

var loaderUtils = require('loader-utils')
var qcdn = require('@q/qcdn')

module.exports = function(content) {
  this.cacheable && this.cacheable()
  var query = loaderUtils.getOptions(this) || {}

  if (query.disable) {
    var urlLoader = require('url-loader')
    return urlLoader.call(this, content)
  }

  var callback = this.async()
  var ext = loaderUtils.interpolateName(this, '[ext]', {content: content})

  qcdn.content(content, ext)
    .then(function upload(url) {
      callback(null, 'module.exports = ' + JSON.stringify(url))
    })
    .catch(callback)
}

module.exports.raw = true

其实就是把 content 上传CDN，然后把CDN地址抛出去

有了这个loader 之后，在 import 图片的时候，拿到的就是一个cdn的地址~

但是我不想在开发环境也上传cdn，我希望只有在生成环境才用这个loader，所以我设置了一个 disable 的选项，如果 disable 为 true，我使用 url-loader 来处理这个文件内容。

最后把loader也添加到配置文件中：

rules: [
  ...,
  {
    test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
    loader: path.join(__dirname, 'cdn-loader'),
    options: {
      disable: !isProduction,
      limit: 10000,
      name: utils.assetsPath('img/[name].[hash:7].[ext]')
    }
  }
]

写好了 cdn-loader 和 cdn-plugin 之后，已经可以编译出一个无任何依赖的纯html，下一步就是把这个html文件发布上线

发布上线

我们部门有自己的发布上线的工具叫 hera 可以把代码发布到docker机上进行编译，然后把编译后的纯html文件发布到事先配置好的服务器的指定目录中

编译的流程是先把代码发布到编译机上 -> 编译机启动 docker （docker可以保证编译环境相同） -> 在 docker 中执行 npm install 安装依赖 -> 执行 npm run build 编译 -> 把编译后的 html 发送到服务器

因为每次编译都需要安装依赖，速度非常慢，所以我们有一个 diffinstall 的逻辑，每次安装依赖都会进行一次 diff，把有缓存的直接用缓存copy到node_modules，没缓存的使用qnpm安装，之后会把这次新安装的依赖缓存一份。依赖缓存了之后每次安装依赖速度明显快了很多。

现在项目已经可以正常开发和上线啦~

api-proxy

虽然项目可以正常开发了，但我觉得还不够，我希望项目可以有 mock 数据的功能并且可以检查服务端返回的数据是否正确，可以避免因为接口返回数据不正确的问题debug好久。

所以我开发了一个简单的模块 api-proxy ，就是封装了一个http client，可以配置请求信息和Mock 规则，开启Mock的时候使用Mock规则生成Mock数据返回，不开启Mock的时候使用Mock规则来校验接口返回是否符合预期。

那么 api-proxy 怎样使用呢？

举个例子：

.
└── api
    └── log
        ├── index.js
        └── fetchLogs.js

/*
 * /api/log/fetchLogs.js
 */
export default {
  options: {
    url: '/api/operatelog/list',
    method: 'GET'
  },
  rule: {
    'data': {
      'list|0-20': [{
        'id|3-7': '1',
        'path': '/log/opreate',
        'url': '/operate/log?id=3',
        'user': 'berwin'
      }],
      'pageData|7-8': {
        'cur': 1,
        'first': 1,
        'last': 1,
        'total_pages|0-999999': 1,
        'total_rows|0-999999': 1,
        'size|0-999999': 1
      }
    },
    'errno': 0,
    'msg': '操作日志列表'
  }
}

/*
 * /api/log/index.js
 */
import proxy from '../base.js'
import fetchLogs from './fetchLogs.js'

export default proxy.api({
  fetchLogs
})

使用：

import log from '@/api/log'
log.fetchLogs(query)
  .then(...)

考虑到特殊情况，也并不是强制必须这样使用，我还是抛出了一个 api方法来供开发者正常使用，例如：

// 不使用api-proxy的api
import {api} from './base'

export default {
  getUserInfo (sid) {
    return api.get('/api/user/getUserInfo', {
      params: {
        sid
      }
    })
  }
}

这个 api 就是 axios ，并没做什么特殊处理。

初始化配置文件

项目开发中会用到一些配置文件，比如开发环境需要配置一个server地址用来设置api请求的server。开发环境的配置文件每个人都不一样，所以我在 .gitignore 中把这个dev.conf 屏蔽掉，并没有入到版本库中，所以就带来了一个问题，每次有新人进入到这个项目，在第一次搭建项目的时候，总是要手动创建一个 dev.conf 文件，我希望能自动创建配置文件

正巧之前我写了一个类似于 vue-cli 的工具 speike-cli，也是通过模板生成项目的一个工具，所以这一次正好派上用场，我把配置文件定义了一个模板，然后使用 speike 来生成了一个配置文件

// package.json
{
  "scripts": {
    "init": "speike init ./config/init-tpl ./config/dev.conf"
  }
}

初始化项目

这次该有的都有了，可以愉快的写码了，为了以后有类似的管理系统创建项目方便，我把这次精心设计的架构，编译逻辑等定制成了模板，日后可以直接使用speike 选择这个模板来生成项目。

整理与总结

经过上面一系列做的事，最后整理一下项目工程化的生命周期

了解更多可以看我写过的 PPT

谈谈我对函数式编程的思考

今天在公司内部听月影讲《如何写“好” JavaScript》，其中重点提到了函数式编程，听完之后很有感想，于是写一篇文章来谈谈我对函数式编程的理解

对前面的例子不感兴趣的同学可以直接拉到最后看结论。

聊函数式编程前，先看几个高阶函数的例子，月影的PPT中也是从高阶函数讲起的

高阶函数

执行一次

block.onclick = function (evt) {
  block.onclick = null;
  evt.target.className = 'hide';
  setTimeout(function () {
    document.body.removeChild(block);
  }, 2000);
};

这样这个 block 的点击事件只能生效一次，有些同学可能还会写出下面的代码实现同样的功能

let clicked = false;
block.onclick = function (evt) {
  if (clicked === false) {
    clicked = true
    evt.target.className = 'hide';
    setTimeout(function () {
      document.body.removeChild(block);
    }, 2000);
  }
};

月影说写出这样代码的同学是要被开除的。😂😂😂

使用高阶函数实现：

function once (fn) {
  return function (...args) {
    if (fn) {
      let ret = fn.apply(this, args);
      fn = null;
      return ret;
    }
  }
}

block.onclick = once(function (evt) {
  console.log('hide');
  evt.target.className = 'hide';
  setTimeout(function () {
    document.body.removeChild(block);
  }, 2000);
});

点我可以看demo

把执行一次的功能抽象成一个高阶函数 once，然后把原始功能函数传入 once 得到一个新的功能函数，新的功能函数只能执行一次。

节流

节流的意思是不管函数调用的速度有多快，函数执行最多n毫秒执行一次（调用一次后n毫秒内不在执行）

例如用鼠标快速点击按钮：

function throttle (fn, time = 500) {
  let timer;
  return function (...args) {
    if (timer == null) {
      fn.apply(this,  args);
      timer = setTimeout(() => {
        timer = null;
      }, time)
    }
  }
}

btn.onclick = throttle(function (e) {
  circle.innerHTML = parseInt(circle.innerHTML) + 1;
  circle.className = 'fade';
  setTimeout(() => circle.className = '', 250);
});

点我可以看demo

可以看出 节流 和 点击一次 是同一个逻辑，将 节流 抽象成高阶函数 throttle，然后把原始功能函数传入 throttle 得到一个新的功能函数，新的功能函数具有节流的功能。

连击

连击效果类似直播送礼物一个礼物送了多次的那个效果，查看DEMO

function consumer (fn, time) {
  let tasks = [],
      timer;
  
  return function (...args) {
    tasks.push(fn.bind(this, ...args));
    if (timer == null) {
      timer = setInterval(() => {
        tasks.shift().call(this)
        if (tasks.length <= 0) {
          clearInterval(timer);
          timer = null;
        }
      }, time)
    }
  }
}

btn.onclick = consumer((evt) => {
  let t = parseInt(count.innerHTML.slice(1)) + 1;
  count.innerHTML = `+${t}`;
  count.className = 'hit';
  let r = t * 7 % 256,
      g = t * 17 % 128,
      b = t * 31 % 128;
  
  count.style.color = `rgb(${r},${g},${b})`.trim();
  setTimeout(() => {
    count.className = 'hide';
  }, 500);
}, 800)

连击 其实也是在 节流 的基础上加工一下

好了高阶函数先说到这，从上面三个例子可以看出，高阶函数就是一个函数return了另一个函数，用月影的话来说就是：它们自身输入函数或返回函数，被称为高阶函数

函数式编程

看完了高阶函数的几个例子后，在看几个函数式编程的例子：

Toggle

switcher.onclick = function (evt) {
  if (evt.target.className === 'on') {
    evt.target.className = 'off';
  } else {
    evt.target.className = 'on';
  }
}

点我查看DEMO

使用函数式实现：

function toggle (...actions) {
  return function (...args) {
    let action = actions.shift();
    actions.push(action);
    return action.apply(this, args);
  }
}

switcher.onclick = toggle(
  evt => evt.target.className = 'off',
  evt => evt.target.className = 'on'
);

点我查看DEMO

用函数式实现后扩展性强了很多，比如说三态：

function toggle (...actions) {
  return function (...args) {
    let action = actions.shift();
    actions.push(action);
    return action.apply(this, args);
  }
}

switcher.onclick = toggle(
  evt => evt.target.className = 'warn',
  evt => evt.target.className = 'off',
  evt => evt.target.className = 'on'
);

点我查看DEMO

使用函数式方式实现可以实现N多态，而不需要改动代码，抽象的很完美

批量操作

function batch (fn) {
  return function (target, ...args) {
    if (target.length >= 0) {
      return Array.from(target).map(item => fn.apply(this, [item, ...args]));
    } else {
      return fn.apply(this, [target, ...args]);
    }
  }
}

function setColor (el, color) {
  el.style.color = color;
}

function setFontSize (el, fontSize) {
  el.style.fontSize = fontSize;
}

setColor = batch(setColor);
setFontSize = batch(setFontSize);

let items1 = document.querySelectorAll('ul > li:nth-child(2n + 1)');
let items2 = document.querySelectorAll('ul > li:nth-child(3n + 1)');

setColor(items1, 'red');
setColor(items2, 'green');
setFontSize(items2, '22px');

点我查看DEMO

这个例子有两个功能单一的函数 setColor 和 setFontSize，然后写了一个高阶函数 batch，将原始功能函数传入高阶函数 batch 里，然后返回一个函数可以支持批量操作的功能

基于这个例子在加工一下：

可查询

function batch (fn) {
  return function (target, ...args) {
    if (target.length >= 0) {
      return Array.from(target).map(item => fn.apply(this, [item, ...args]));
    } else {
      return fn.apply(this, [target, ...args]);
    }
  }
}

function queriable (fn) {
  return function (selector, ...args) {
    if (typeof selector === 'string') {
      selector = document.querySelectorAll(selector);
    }
    return fn.apply(this, [selector, ...args]);
  }
}

function setColor (el, color) {
  el.style.color = color;
}

function setFontSize (el, fontSize) {
  el.style.fontSize = fontSize;
}

setColor = queriable(batch(setColor));
setFontSize = queriable(batch(setFontSize));

setColor('ul > li:nth-child(2n + 1)', 'red');
setColor('ul > li:nth-child(3n + 1)', 'green');
setFontSize('ul > li:nth-child(3n + 1)', '22px');

点我查看DEMO

这个例子新增了一个高阶函数 queriable，实现了查询功能。将 batch 传入 queriable 后生成一个新函数支持查询功能。

在加工一下：

打包

function batch (fn) {
  return function (target, ...args) {
    if (target.length >= 0) {
      return Array.from(target).map(item => fn.apply(this, [item, ...args]));
    } else {
      return fn.apply(this, [target, ...args]);
    }
  }
}

function queriable (fn) {
  return function (selector, ...args) {
    if (typeof selector === 'string') {
      selector = document.querySelectorAll(selector);
    }
    return fn.apply(this, [selector, ...args]);
  }
}

function pack (map) {
  return function (el, obj) {
    for (let key in obj) {
      map[key].call(this, el, obj[key]);
    }
  }
}

function setColor (el, color) {
  el.style.color = color;
}

function setFontSize (el, fontSize) {
  el.style.fontSize = fontSize;
}

let css = pack({color: setColor, fontSize: setFontSize});
css = queriable(batch(css));

css('ul > li:nth-child(2n + 1)', {color: 'red'});
css('ul > li:nth-child(3n + 1)', {color: 'green', fontSize: '22px'});

点我查看DEMO

这个例子又新增了一个高阶函数 pack，将功能单一的函数通过对象的方式传入到 pack 后生成了新函数，新函数可以接受对象类型的值来设置颜色和字体大小。

最后在加工一下：

链式调用

function batch (fn) {
  return function (target, ...args) {
    if (target.length >= 0) {
      return Array.from(target).map(item => fn.apply(this, [item, ...args]));
    } else {
      return fn.apply(this, [target, ...args]);
    }
  }
}

function queriable (fn) {
  return function (selector, ...args) {
    if (typeof selector === 'string') {
      selector = document.querySelectorAll(selector);
    }
    return fn.apply(this, [selector, ...args]);
  }
}

function pack (map) {
  return function (el, obj) {
    for (let key in obj) {
      map[key].call(this, el, obj[key]);
    }
  }
}

function methodize (fn, prop) {
  return function (...args) {
    fn.apply(null, [prop ? this[prop] : this, ...args]);
    return this;
  }
}

function setColor (el, color) {
  el.style.color = color;
}

function setFontSize (el, fontSize) {
  el.style.fontSize = fontSize;
}

function setText (el, text) {
  el.innerHTML = text;
}

let css = pack({color: setColor, fontSize: setFontSize});
css = queriable(batch(css));

let text = queriable(batch(setText));

function E (selector) {
  this._selector = selector;
}

E.prototype.css = methodize(css, '_selector');
E.prototype.text = methodize(text, '_selector');

function $(selector){
  return new E(selector);
}

$('ul > li:nth-child(2n + 1)').css({color: 'red'}).text('abc');
$('ul > li:nth-child(3n + 1)').css({color: 'green', fontSize: '22px'});

这个例子新增了一个高阶函数 methodize，函数中的 return this 很关键，这个函数主要的功能就是使用 return this，来实现链式调用。

我对函数式编程的理解

前面写了那么多例子，看起来复杂，但其实我反而觉得很简单，因为在我的眼里，函数式编程其实就是无数个高阶函数组装在一起完成一个很复杂的功能。

而这些高阶函数我把它理解成下面这张图的样子：

你会发现，当滚球兽一步一步进化到战斗暴龙兽之后，它已经具备了 pack，batch，queriable，methodize 这些高阶函数所提供的所有功能。

所以简单来说，就是可以把 pack，batch，queriable，methodize 理解成类似于中间件、插件，或者 webpack中的loader（webpack 中的loader也是前一个loader的处理结果丢给下个loader继续处理），例如我手里拿着一个最原始的功能函数，比如 setColor，先丢给pack处理生成一个新函数，然后把处理后的新函数在丢给 batch 以此类推

简单说就是上一个高阶函数的输出是下一个高阶函数的输入，而这个输出和输入不仅仅是数据，也可以是函数

所以函数式编程，抽象的过程很重要，例如哪些逻辑是需要抽象成高阶函数的。还有就是玩参数，如果在自己的业务当中使用函数式编程的话，我觉得保证上一个函数的输出丢到下一个函数的输入是否能正常工作是一个需要注意的事。

理解了我说的内容，在回到文章的开头把这些例子重新看一遍，你会发现好像世界都不一样了。

我对函数式编程也不是特别的精，目前还在研究阶段，，，，，

声明：如果您觉得我理解的不对，请大佬指点~

捕获FMP的原理

FMP（全称“First Meaningful Paint”，翻译为“首次有效绘制”）表示页面的“主要内容”开始出现在屏幕上的时间点。它是我们测量用户加载体验的主要指标。

通常我们使用测评工具（例如：Lighthouse）就可以得到FMP值。但是这里有一个问题是：不同产品的“主要内容”是不一样的；对于博客，主要内容是文章标题+首屏文本（可见的文本）、对于搜索引擎主要内容就是搜索结果。

只有我们自己最清楚我们产品的主要内容是什么，那么测评工具是如何捕获出FMP值的？它捕获出的这个FMP准么？

本文我们将针对这两个问题进行详细的讨论。

基于布局的方法捕获FMP

本小节我们将介绍一种基于布局的方法来捕获FMP，它的准确率可以达到77%。

随着网页的加载与解析，浏览器会将布局对象（Layout Object）逐步添加到布局树（Layout Tree）上进行布局。

以Google搜索结果页为例，下图给出了该页面在加载时布局对象被添加到布局树中的数量和时间（横坐标为时间，纵坐标为数量）。

图1 - 布局对象

FCP（First Contentful Paint）的时间在1.577秒，此时已经有60个布局对象被添加到了布局树中，这时候页面只渲染了一个Header；在1.86秒的时候，有261个布局对象被添加到布局树中，这些对象是搜索结果，随后在1.9秒进行了一个绘制（Paint），这个绘制是FMP；随后一些剩余的页面底部等部分的布局对象被添加到布局树中并进行绘制，最终页面在2.425秒完成。

从这个例子中我们会发现，布局对象的数量与页面加载的完整性密切相关。

经过大量试验与测试，最终发现大量的新布局对象被添加到布局树中的时间，和FMP非常接近。并且在FMP这个场景下，新布局对象的数量比重新布局的布局对象数量更重要。

所以我们得出一个关于FMP的公式：

FMP = 最大布局变动之后的那个绘制（Paint）

最大布局变动指的是哪个时间点布局对象被添加到布局树中的数量是最大的。

如图1所示，最大布局变动在1.86秒，而下一个绘制时间是1.907秒，所以1.907这个时间是FMP。

通过这种方式捕获出来的FMP，精准度大概在57.1%，比单纯的FCP强很多，但是在多数情况下，它还是没有办法捕获出真正有意义的绘制。

假设我们有一个很长的页面，下图给出了这个页面的布局对象被添加到布局树中的数量和时间：

图2 - 布局对象2

在图2中，该页面最主要的内容在6.047秒被绘制出来，所以这个页面的FMP应该是6.047秒，但是如果按照我们前面的算法，则给出的FMP是24.25秒，因为23.8秒是最大布局变动，而最大布局变动的下一个绘制时间是24.25秒。

但事实是24.25秒这个绘制并不重要，因为它在屏幕之外的区域进行绘制，用户根本看不到这部分内容。

如何防止这些屏幕外的布局扰乱测量FMP的精准度？最理想的方式是计算元素是否可见，但是在布局期间进行昂贵的计算也不是一个好办法。所以解决方案是使用“权重”，当布局对象的位置超过屏幕的高度时，降级它的权重。所以现在我们使用布局的“意义”来捕获FMP，而不是布局对象的“数量”。

所以我们可以得出一个改进后的计算FMP的公式：

意义 = 当前时间布局对象的数量 / max(1, 页面高度/屏幕高度)
FMP = 意义值最大的一次布局变动之后的那个绘制（Paint）

注意：在这个公式中，页面高度 = 当前布局对象在页面中的位置

下图给出了使用该公式计算出的“布局意义”流线图：

图5 - 布局意义

现在，意义最大的一次布局变动在5.89秒，下一次绘制的时间是6.047秒，而这个时间就是FMP。通过这个算法捕获出的FMP准确率可以达到62.1%。

Web字体可以打破这个算法捕获FMP的准确率，假设某个网页的最大布局变动是在2.51秒，但是这个时候屏幕上没有任何内容，因为Web字体还在加载中。

Web字体为什么会导致这种情况以及如何优化，不在本文的讨论范围

Blink的布局层逻辑根本不关心文字是否显示，但是字体是否显示对于用户体验却至关重要，所以在计算FMP时，应该把字体的可见性也考虑进去。

当布局发生时，如果有Web字体在加载中，那么应该延迟记录布局变动，直到字体加载完毕，但是需要设置3秒钟的超时时间，不然无限制的等下去也不行。但是如果把这个规则应用于所有Web字体有些过于激进，因为有一些icon字体其实也不是很重要，它不应该影响FMP的时间，所以最终选了200多个可以阻塞记录FMP时间的字符。现在计算FMP的准确率可以达到77%。

总结

本文介绍了基于布局的方式捕获FMP的原理，现在我们应该明白使用工具捕获出的FMP到底是什么。

本质上这个数字并不是真正的FMP，它只是通过算法来猜测某个时间点可能是FMP，而这个时间点，是依靠布局对象的数量、意义、以及Web字体推算出来的，目前准确率可以达到77%。

让你的网页更丝滑（一）

前段时间，我将精力专注在Web性能领域；在这个领域下有个重要的课题是如何让网页更丝滑（流畅）。

想让网页变得丝滑，首先，我们需要一个标准来判断什么样的网页是丝滑的；其次，我们要准确的测量出网页的性能数据；最后，使用有效的方法让网页变得丝滑。

本篇文章将针对这三个方面进行详细的介绍。

1. RAIL

到底怎样的网页是丝滑的？我们需要一个标准来辅助判断我们的网页是否丝滑。

Chrome团队提出了一个以用户为中心的性能模型被称为RAIL，它为工程师提供一个目标，只要达到目标的网页，用户就会觉得很流畅；它将用户体验拆解为一些关键操作，例如：点击，加载等；并给这些操作规定一个目标，例如：点击一个按钮后，多长时间给反馈用户会觉得流畅。

RAIL将影响性能的行为划分为四个方面，分别是：Response（响应）、Animation（动画）、Idle（空闲） 与Load（加载）。没错，RAIL这个名字来自于这四个单词的首字母，方便记忆。

1.1 响应（Response）

研究表明，100ms内对用户的输入操作进行响应，通常会被人类认为是立即响应。时间再长，操作与反应之间的连接就会中断，人们就会觉得它的操作有延迟。例如：当用户点击一个按钮，如果100ms内给出响应，那么用户就会觉得响应很及时，不会察觉到丝毫延迟感。

1.2 动画（Animation）

现如今大多数设备的屏幕刷新频率是60Hz，也就是每秒钟屏幕刷新60次；因此网页动画的运行速度只要达到60FPS，我们就会觉得动画很流畅。

(1 秒 = 1000 毫秒) / 60 帧 = 16.66 毫秒/帧

但通常浏览器需要花费一些时间将每一帧的内容绘制到屏幕上（包括样式计算、布局、绘制、合成等工作），所以通常我们只有10毫秒来执行JS代码。

1.3 空闲（Idle）

为了更好的性能，通常我们会充分利用浏览器空闲周期（Idle Period）做一些低优先级的事情。例如：在空闲周期预请求一些接下来可能会用到的数据或上报分析数据等。

RAIL规定，空闲周期内运行的任务不得超过50ms，当然不止RAIL规定，W3C性能工作组的Longtasks标准也规定了超过50毫秒的任务属于长任务，那么50ms这个数字是怎么得来的呢？

浏览器是单线程的，这意味着同一时间主线程只能处理一个任务，如果一个任务执行时间过长，浏览器则无法执行其他任务，用户会感觉到浏览器被卡死了，因为他的输入得不到任何响应。

为了达到100ms内给出响应，将空闲周期执行的任务限制为50ms意味着，即使用户的输入行为发生在空闲任务刚开始执行，浏览器仍有剩余的50ms时间用来响应用户输入，而不会产生用户可察觉的延迟。如图1-1所示：

图1-1

事实上，不论是空闲任务还是高优先级的其他任务，执行时间都不得超过50ms。

1.4 加载（Load）

如果不能在1秒钟内加载网页并让用户看到内容，用户的注意力就会分散。用户会觉得他要做的事情被打断，如果10秒钟还打不开网页，用户会感到失望，会放弃他们想做的事，以后他们或许都不会再回来。

1.5 小结

通过RAIL，我们可以判断出我们的网页是否丝滑。RAIL从用户感知角度出发规定了一些指标，只要我们的网页符合标准，则我们的网页是丝滑的，用户会觉得我们的网页很流畅。

2. 像素管道

像素管道是制作丝滑网页的灵魂，我们后面将要介绍的技术都与它有关。

上图就是像素管道，通常我们会使用JS修改一些样式，随后浏览器会进行样式计算，然后进行布局，绘制，最后将各个图层合并在一起完成整个渲染的流程，这期间的每一步都有可能导致页面卡顿。

注意，并不是所有的样式改动都需要经历这五个步骤。举例来说：如果在JS中修改了元素的几何属性（宽度、高度等），那么浏览器需要需要将这五个步骤都走一遍。但如果您只是修改了文字的颜色，则布局（Layout）是可以跳过去的，如下图所示：

除了最后的合成，前面四个步骤在不同的场景下都可以被跳过。例如：CSS动画就可以跳过JS运算，它不需要执行JS。

css-triggers给出了不同的CSS属性被更改后会触发像素管道的哪些步骤。

简单来说，像素管道经历的步骤越多，渲染时间就越长，单个步骤内可能也会因为某种原因而变得耗时很长；所以不管是步骤多还是单个步骤耗费的时间长，最终都会导致整体渲染时间变长。整体时间越长就越有可能超出RAIL所规定的指标。

举个简单的例子：网页动画的渲染若是达到60FPS，则动画不会丢帧。假设渲染管道的布局与绘制耗费了10ms，那么加上样式计算与合成的时间，则留给JS处理动画的时间就只有几毫秒，如果JS的执行超过了几毫秒那么该动画每一帧所耗费的时间就会超过16ms，这时候动画一定会丢帧，用户用肉眼就可以看到明显的卡顿。

当然，即便能保证每一帧的总耗时小于16ms，依然无法保证不会丢帧。关于这点后面我们会详细介绍。

3. 如何让动画更丝滑

动画需要达到60FPS才能变得丝滑，本节我们介绍如何让动画在不丢帧的情况下稳定保持在60FPS。

3.1 使用Chrome开发者工具测量动画性能

在评估动画性能时，通常需要逐帧评估像素管道的开销；使用 Chrome 开发者工具可以辅助我们进行精准的测量。

在Chrome开发者工具中，点击Performance面板，然后选中Screenshots复选框，。如图3-1所示：

图3-1Chrome开发者工具Performance面板

然后点击录制按钮，录制完毕后点击停止按钮就可以捕获当前页面的性能数据。如图3-2所示：

图3-2捕获性能数据

捕获出的结果如图3-3所示：

图3-3捕获出的性能结果

我们可以放大主线程从而精准的看到每一帧浏览器都执行了哪些任务以及每个任务耗费了多长时间。如图3-4所示：

图3-4性能面板最主要的部分

从上图可以看到，浏览器每一帧渲染所执行的任务与前面我们介绍的像素管道是相同的。上图中因为是CSS动画，所以没有运行JS，但每一帧都需要计算样式、布局、绘制与合成。

3.2 如何让JS动画更丝滑

JS动画是使用定时器不停的执行JS，通过在JS中修改样式完成网页动画；若想保证动画流畅，从JS的执行到最终浏览器显示出画面，每一帧总耗时最多16ms，这样动画才能达到60FPS。

如图3-4所示，即便是在不执行JS的情况下，浏览器计算样式、布局、绘制等工作也是需要时间的，所以需要给浏览器预留出 充分的时间（6ms） 做这些事情，现在留给JS的执行时间就只有 10ms。

图3-5每一帧总体耗时必须小于16ms，JS运行时间小于10ms

一旦JS运行时间超过10ms，就很有可能导致这一帧的像素管道整体耗时超过16ms，从而无法达到60FPS，但你以为只要保证JS的运行时间小于10ms就一定能保证不丢帧？Naive~

3.2.1 使用requestAnimationFrame

即便你能保证每一帧的总耗时都小于16ms，也无法保证一定不会出现丢帧的情况，这取决于触发JS执行的方式。

假设使用 setTimeout 或 setInterval 来触发JS执行并修改样式从而导致视觉变化；那么会有这样一种情况，因为setTimeout 或 setInterval没有办法保证回调函数什么时候执行，它可能在每一帧的中间执行，也可能在每一帧的最后执行。所以会导致即便我们能保障每一帧的总耗时小于16ms，但是执行的时机如果在每一帧的中间或最后，最后的结果依然是没有办法每隔16ms让屏幕产生一次变化。如图3-6所示：

图3-6使用定时器触发动画

也就是说，即便我们能保证每一帧总体时间小于16ms，但如果使用定时器触发动画，那么由于定时器的触发时机不确定，所以还是会导致动画丢帧。现在整个Web只有一个API可以解决这个问题，那就是requestAnimationFrame，它可以保证回调函数稳定的在每一帧最开始触发。如图3-7所示：

图3-7使用requestAnimationFrame触发动画

3.2.2 避免FSL

先执行JS，然后在JS中修改了样式从而导致样式计算，然后样式的改动触发了布局、绘制、合成。但JavaScript可以强制浏览器将布局提前执行，这就叫
F （强制）
S （同步）
L （布局）
。

图3-8强制同步布局

通常我们一不小心就造成了FSL，请看下面代码：

box.classList.add('big');
const width = box.offsetWidth;

代码中通过新增class修改了元素的样式，随后使用offsetWidth读取元素的宽度。乍一看似乎没什么问题，但这段代码会导致FSL。

在 JavaScript 运行时，上一帧已经渲染好的所有布局值都是已知的，我们可以使用offsetWidth这样的语法获得值；但这一帧刚修改完的样式浏览器还没渲染呢，这时候使用offsetWidth这样的语法读取元素的宽度，那么浏览器为了告诉我们宽度值，它必须先计算该宽度，这就需要布局。如图3-8所示，布局跑到了样式计算的前面。

所以正确的做法是先获取宽度，然后再更改样式：

const width = box.offsetWidth;
box.classList.add('big');

看起来，似乎即使触发了FSL也不过就是管道的顺序变了而已，影响好像并没有那么大。🤔

单个FSL对性能的影响确实不大，但如果触发了布局抖动，则影响会变得非常大。看下面代码：

const container = document.querySelector('.container');
const boxes = document.querySelectorAll('p');

for (var i = 0; i < boxes.length; i++) {
  // Read a layout property
  const newWidth = container.offsetWidth;
    
  // Then invalidate layouts with writes.
  boxes[i].style.width = newWidth + 'px';
}

上面代码的作用是批量修改N个P元素的宽度；在循环中我们先获取容器元素的宽度，随后设置了P元素的样式。这会导致浏览器去布局，然后计算样式。每次更改样式，都会导致刚刚执行的布局失效，因为我们又改了新的样式，所以下一轮循环读取宽度时，浏览器又要执行一次布局，如此反复直到循环结束。在循环期间，浏览器不停地执行无效布局，这被称为 布局抖动（Layout Thrashing）；这种错误导致的性能问题非常高。

如果我们不小心触发了FSL，Chrome开发者工具会给出红色的线提示，如图3-9所示：

图3-9开发者工具提示FSL

同时任务的右上角会有红色的三角形表示，我们可以放大任务进一步查看，如图3-10所示：

图3-10开发者工具提示FSL详情

若想看Demo可以点击我，在Demo中点击按钮可以让P标签的宽度变长。

为了避免布局抖动，我们可以将读取元素宽度的代码放到循环的外面。代码如下：

const container = document.querySelector('.container');
const boxes = document.querySelectorAll('p');

// Read a layout property
const newWidth = container.offsetWidth;

for (var i = 0; i < boxes.length; i++) {    
    // Then invalidate layouts with writes.
    boxes[i].style.width = newWidth + 'px';
}

若想看Demo可以点击我，可以看到这个Demo与前一个demo一模一样，甚至我们无法用肉眼分辨出哪个更快，这是因为DOM元素少，所以总体时间都比较少，但我们可以通过Chrome开发者工具来捕获性能数据。

图3-11优化后的时间

图3-11可以看到，优化后这一帧的总时间用了4.7ms，而优化前的是101ms，如图3-12所示：

图3-12优化前的时间

优化后比优化前，每帧所耗费的时间快了21.7倍，数字非常惊人。

3.3 如何让CSS动画更丝滑

CSS动画通常使用@keyframe或transition结合样式的变动来实现视觉变化的效果。我们同样可以通过减少像素管道的步骤和每个步骤所耗费的时间让CSS动画更流畅。

本节介绍的CSS动画的优化方式同样适用于JS动画，但上一节介绍的JS动画优化方法不适用于CSS动画，它们是包含关系。

绘制（Paint）通常需要花费很长时间，我们可以通过Chrome开发者工具来观察正在绘制的区域。打开开发者工具，按下键盘上的 Esc 键。在出现的面板中，切换到“rendering”标签，然后选中“Paint flashing”。如图3-13所示：

图3-13开启绘制闪烁

开启绘制闪烁（Paint flashing）后，每当页面发生绘制时，我们都可以在屏幕上看到绘制发生区有绿色在闪烁。如图3-14所示：

图3-14绘制区域闪烁

如图3-14所示，当我们开启了绘制闪烁，则会绘制区域出现了绿色的闪烁，可以点击我查看Demo。

当我们看到我们认为不应该绘制的区域时，我们应该进一步研究并取消绘制区域。

如何才能避免绘制的发生呢？答案是：图层。

事实上浏览器在渲染页面时，可以将页面分为很多个图层，有点类似于PhotoShop，一张图片在PotoShop中是由多个图层组合而成，而浏览器最终显示的页面实际也是由多个图层构成的。如图3-15所示：

图3-15图层

将原本不断发生变化的元素提升到单独的图层中，就不再需要绘制了，浏览器只需要将两个图层合并在一起即可，查看Demo请狠狠的点击我。

如果您点击了上面的Demo地址，并开启了绘制闪烁，您会发现没有任何闪烁发生，因为浏览器没有进行绘制。如果您查看Layers面板，你会看到这样的场景，如图3-16：

3-16图层

当我们使用Performance面板捕获性能数据时会发现绘制（Paint）已经不见了。如图3-17所示：

图3-17捕获不到绘制

创建图层的最佳方式是使用will-change，但某些不支持这个属性的浏览器可以使用3D 变形（transform: translateZ(0)）来强制创建一个新层。

在Chrome开发者工具“rendering”标签中，选中“Layer borders”。可以看到页面中有哪些合成层。合成层会使用橘黄色的边框，如图3-18所示：

图3-18显示合成层

为了减少绘制，可以通过新增图层，但是图层的管理也是需要成本的，所以要避免滥用，通常需要具体情况具体分析，做出合适的选择。

前面我的Demo都是修改元素的left属性让方块移动，这避免不了需要进行布局操作，最佳的方法是使用transform属性，这个属性是由合成器单独处理的，所以使用这个属性可以避免布局与绘制。

总结

RAIL可以帮助我们判断什么样的网页是丝滑的，而开发者工具可以让我们进一步准确的捕获出网页的性能数据。

JS动画要保证预留出6ms的时间给浏览器处理像素管道，而自身执行时间应该小于10ms来保证整体运行速度小于16ms。但触发动画的时机也很重要，定时器无法稳定的触发动画，所以我们需要使用requestAnimationFrame触发JS动画。同时我们应该避免一切FSL，它对性能的影响非常大。

CSS动画我们可以通过降低绘制区域并且使transform属性来完成动画，同时我们需要管理好图层，因为绘制和图层管理都需要成本，通常我们需要根据具体情况进行权衡并做出最好的选择。

为什么Vue使用异步更新队列？

本文假设你已经对Vue的变化侦测和渲染机制有一些了解。
如果不了解请移步《深入浅出 - vue变化侦测原理》、《PPT：深入浅出Vue.js - VirtualDOM篇》

异步更新队列指的是当状态发生变化时，Vue异步执行DOM更新。

我们在项目开发中会遇到这样一种场景：当我们将状态改变之后想获取更新后的DOM，往往我们获取到的DOM是更新前的旧DOM，我们需要使用vm.$nextTick方法异步获取DOM，例如：

Vue.component('example', {
  template: '<span>{{ message }}</span>',
  data: function () {
    return {
      message: '没有更新'
    }
  },
  methods: {
    updateMessage: function () {
      this.message = '更新完成'
      console.log(this.$el.textContent) // => '没有更新'
      this.$nextTick(function () {
        console.log(this.$el.textContent) // => '更新完成'
      })
    }
  }
})

我们都知道这样做很麻烦，但为什么Vue还要这样做呢？

首先我们假设Vue是同步执行DOM更新，会有什么问题？

如果同步更新DOM将会有这样一个问题，我们在代码中同步更新数据N次，DOM也会更新N次，伪代码如下：

this.message = '更新完成' // DOM更新一次
this.message = '更新完成2' // DOM更新两次
this.message = '更新完成3' // DOM更新三次
this.message = '更新完成4' // DOM更新四次

但事实上，我们真正想要的其实只是最后一次更新而已，也就是说前三次DOM更新都是可以省略的，我们只需要等所有状态都修改好了之后再进行渲染就可以减少一些无用功。

而这种无用功在Vue2.0开始变得更为重要，Vue2.0开始引入了Virtualdom，每一次状态发生变化后，状态变化的信号会发送给组件，组件内部使用VirtualDOM进行计算得出需要更新的具体的DOM节点，然后对DOM进行更新操作，每次更新状态后的渲染过程需要更多的计算，而这种无用功也将浪费更多的性能，所以异步渲染变得更加至关重要。

组件内部使用VIrtualDOM进行渲染，也就是说，组件内部其实是不关心哪个状态发生了变化，它只需要计算一次就可以得知哪些节点需要更新。也就是说，如果更改了N个状态，其实只需要发送一个信号就可以将DOM更新到最新。例如：

this.message = '更新完成'
this.age =  23
this.name = berwin

代码中我们分三次修改了三种状态，但其实Vue只会渲染一次。因为VIrtualDOM只需要一次就可以将整个组件的DOM更新到最新，它根本不会关心这个更新的信号到底是从哪个具体的状态发出来的。

那如何才能将渲染操作推迟到所有状态都修改完毕呢？很简单，只需要将渲染操作推迟到本轮事件循环的最后或者下一轮事件循环。也就是说，只需要在本轮事件循环的最后，等前面更新状态的语句都执行完之后，执行一次渲染操作，它就可以无视前面各种更新状态的语法，无论前面写了多少条更新状态的语句，只在最后渲染一次就可以了。

将渲染推迟到本轮事件循环的最后执行渲染的时机会比推迟到下一轮快很多，所以Vue优先将渲染操作推迟到本轮事件循环的最后，如果执行环境不支持会降级到下一轮。

当然，Vue的变化侦测机制决定了它必然会在每次状态发生变化时都会发出渲染的信号，但Vue会在收到信号之后检查队列中是否已经存在这个任务，保证队列中不会有重复。如果队列中不存在则将渲染操作添加到队列中。

之后通过异步的方式延迟执行队列中的所有渲染的操作并清空队列，当同一轮事件循环中反复修改状态时，并不会反复向队列中添加相同的渲染操作。

所以我们在使用Vue时，修改状态后更新DOM都是异步的。

说到这里简单介绍下什么是事件循环。

事件循环机制

JS中存在一个叫做执行栈的东西。JS的所有同步代码都在这里执行，当执行一个函数调用时，会创建一个新的执行环境并压到栈中开始执行函数中的代码，当函数中的代码执行完毕后将执行环境从栈中弹出，当栈空了，也就代表执行完毕。

这里有一个问题是代码中不只是同步代码，也会有异步代码。当一个异步任务执行完毕后会将任务添加到任务队列中。例如：

setTimeout(_=>{}, 1000)

代码中setTimeout会在一秒后将回调函数添加到任务队列中。事实上异步队列也分两种类型：微任务、宏任务。

微任务和宏任务的区别是，当执行栈空了，会检查微任务队列中是否有任务，将微任务队列中的任务依次拿出来执行一遍。当微任务队列空了，从宏任务队列中拿出来一个任务去执行，执行完毕后检查微任务队列，微任务队列空了之后再从宏任务队列中拿出来一个任务执行。这样持续的交替执行任务叫做事件循环。

属于微任务（microtask）的事件有以下几种：

• Promise.then
• MutationObserver
• Object.observe
• process.nextTick

属于宏任务（macrotask）的事件有以下几种：

• setTimeout
• setInterval
• setImmediate
• MessageChannel
• requestAnimationFrame
• I/O
• UI交互事件

彩蛋

通过前面介绍的内容，我们知道Vue的更新操作默认会将执行渲染操作的函数添加到微任务队列中，而微任务的执行时机优先于宏任务。所以有一个很有意思的事情是，我们在代码中如果先使用setTimeout将函数注册到宏任务中，然后再去修改状态，在setTimeout注册的回调中依然可以获取到更新后的DOM，例如：

new Vue({
  // ...
  methods: {
    // ...
    example: function () {
      // 先使用setTimeout向宏任务中注册回调
      setTimeout(_ => {
        // DOM现在更新了
      }, 0)
      // 后修改数据向微任务中注册回调
      this.message = 'changed'
    }
  }
})

之所以会出现这种现象原因前面我们也提到过，是因为修改数据默认会将更新DOM的回调添加到微任务（microtask）队列中，如果我们将获取DOM的操作放到宏任务（macrotask）中，那么注册的位置就变得不那么重要了，无论在哪里注册都是先更新DOM然后再获取DOM。因为微任务（microtask）中的任务比宏任务（macrotask）中的任务先执行。

而如果使用vm.$nextTick向微任务队列中插入任务，则代码中注册的顺序就非常重要，因为渲染操作和使用vm.$nextTick注册的回调都是向微任务队列中添加任务，那么执行回调的顺序就会按照插入队列中的循序去执行，也就是说，先插入队列的先执行。例如：

new Vue({
  // ...
  methods: {
    // ...
    example: function () {
      // 先使用nextTick注册回调
      this.$nextTick(function () {
        // DOM没有更新
      })
      // 后修改数据
      this.message = 'changed'
    }
  }
})

代码中先使用vm.$nextTick注册任务，后修改数据，所以在微任务队列中它比渲染操作的位置更靠前，所以优先执行，所以在回调执行的时候页面中的DOM并没有发生变化。

必须先修改数据后使用vm.$nextTick注册回调才能获取到更新后的DOM，例如：

new Vue({
  // ...
  methods: {
    // ...
    example: function () {
      // 先修改数据
      this.message = 'changed'

      // 后使用nextTick注册回调
      this.$nextTick(function () {
        // DOM已经更新
      })
    }
  }
})

代码中可以看到，先修改数据，后使用vm.$nextTick注册回调，那么在微任务队列中渲染操作比vm.$nextTick注册的回调位置更靠前，所以先执行渲染后，在执行vm.$nextTick注册的回调，所以在回调中可以获取到更新后的DOM。

小程序底层实现原理及一些思考

两月以后，看着电脑，我回想起接到通知说要开发小程序引擎的那个下午。当时的我以为，这个小程序和其他小程序都不一样，因为它是个假的，其实是个网页。两月之后，我才发现，“噢~原来大家都是这么做的啊”。

最近一直在做小程序的底层实现，过程中磕磕绊绊也多次进行架构方向上的转型，趁着周末抽空写一篇文章记录一下开发过程中遇到的问题和一些思考与决策。

本篇文章更多的是在描述架构与技术方向层面的思考和决策，不会过多介绍具体某个问题是如何解决的，因为细节实在太多。

1. 单线程

当时的我将我们的小程序定位成一个SPA（单页应用），因为我们的小程序的宿主环境是浏览器。

它只是看起来像小程序（因为这个窗口没有地址栏什么的），但其实包括UI渲染和事件交互在内的绝大部分功能都是基于Web技术，虽然会提供Native和OS的一些能力与API，但本质上其实是个网页。又考虑到目前很多人使用第三方工具用Vue或React写小程序，我就在思考：“反正本质上就是一个网页，那为什么不原生内置Vue让用户直接用Vue的语法写小程序呢？”。

所以当时定了一个基本方向：让开发者使用Vue开发我们的小程序，开发体验完全与Web保持一致。

虽然开发体验与Web保持一致，但是Web技术实在是太开放了，开发者可以为所欲为。这种情况在小程序中是不允许的，不允许使用<iframe>、不允许<a>直接外跳到其他在线网页、不允许开发者触碰DOM、不允许使用某些未知的危险API等。

所以遇到的第一个问题是如何禁止用户在Vue的模板中使用iframe或a或其他不允许使用的东西。

若想做到这一点就不得不对Vue的渲染层进行一个托管与改造。

1.1 改造Vue

对Vue进行改造通常有两种方案：

1. 使用类似polyfill的手法覆盖一些Vue原生提供的API
2. Fork一个Vue出来自己改

第一个方案能力有限，有一些Vue内部的逻辑没有办法通过polyfill的形式更改。第二种方案的缺陷是如果我只想修改Vue中的某一块逻辑，其他我不修改的部分如果有Bug，Vue官方更新了版本我没有办法同步。

这两种方案都有缺陷和不足，所以我没有使用这两个其中的任何一个，我使用了另一个方案，我觉得应该是目前为止最好的一种方案。

我简单介绍一下这种方案：

1. 把Vue.js装到node_modules里
2. 项目里使用webpack，并设置上别名
3. 把自己想改造的那部分代码copy到自己的项目目录中进行修改

因为我需要对渲染层进行改造，所以我需要重设web这个别名，如下：

const path = require('path')

module.exports = {
  'vue$': path.resolve(__dirname, '../src/web/entry-runtime-with-compiler'),
  compiler: 'vue/src/compiler',
  core: 'vue/src/core',
  shared: 'vue/src/shared',
  web: path.resolve(__dirname, '../src/web'),
  weex: 'vue/src/platforms/weex',
  server: 'vue/src/server',
  sfc: 'vue/src/sfc'
}

大致原理是：如果import了一个不需要改造的，那其实是import了node_modules里的原始Vue的文件，如果是import了需要改造的，那其实import的是我的目录，文件也是我修改后的文件。

对这方面技术有兴趣可以留言详细讨论，由于不是本文重点，不再展开。

1.2 为标签设置黑名单

Vue通过一系列计算之后最终产出的结果是一些指令，比如创建一个DOM元素，移除一个DOM元素，插入到某个位置等。

所以当时的做法就简单在创建DOM元素时，用tagName校验是否在黑名单中，如果在黑名单中就触发警告并怎么怎么样。

但其实这种做法只能是：防君子不防小人。

1.3 遇到的问题

项目做到这里遇到一个问题是不论怎样，都没有办法防止开发者做一些我们想禁用的功能。因为是一个网页，开发者可以执行JS，可以操作DOM，可以操作BOM，可以做一切事情。

所以我们开始考虑将用户的代码放到一个绝对安全的沙箱中去执行。

2. 双线程

在Web技术下，可以将用户的代码放到Web Worker中去执行，也可以放到一个隐藏的iframe中去执行，或者宿主环境提供一个环境。无论怎样，目的都是相同的，就是把用户的代码放到一个绝对安全的沙箱中执行。

由于开发者是基于Vue.js开发，用户的代码是没有办法单独放到沙箱中去执行的，所以我把Vue也放到沙箱中去执行。

这个时候技术架构和技术方向被调整成了Master-Slave的双线程模式。

沙箱中的代码我称为Master，它通过一系列计算，最终输出一些指令：创建元素、修改元素、插入元素、路由跳转、事件绑定等一些基础指令。这些指令从沙箱中通过线程间的消息机制传递到网页中，这个网页有一个模块叫做Slave，它负责监听Master发过来的指令并根据指令做指定操作。

把Vue放到Web Worker中执行需要解决非常多的问题，比如：原本Vue直接对DOM的操作需要转换成向另一个线程发送指令，还有事件绑定问题，事件的Event对象问题，事件修饰符（event.preventDefault）问题，路由控制（双向的）问题，表单元素的双向绑定问题、ref问题等。因为线程间的消息传递只能传递字符串，所以很多东西就会变得非常麻烦。

不过这些具体的技术问题都是比较容易解决的，比较难的问题是两个：“性能”和“原生能力受限”。

2.1 性能

在这种架构下，当页面有大范围UI变化时（例如首次渲染），Logic线程需要往UI线程发送大量的指令，包括：创建DOM，插入DOM，绑定事件等，每条指令都是一个单独的跨线程的消息通信，当消息数量庞大时，性能问题就会暴露出来，而且非常明显。

如果去Chrome DevTools的Performance面板看，会发现UI线程其实很闲，但是渲染的就是很慢。因为消息传递的代价，而且每次encode与decode也都需要代价，我自己写DEMO时没发现问题，但是投放到生产环境下去渲染一个真实的组件时，就会发现性能问题非常明显。

这个架构下虽然有性能问题，但以我的能力想解决这个问题也并不是太困难。另一个问题（原生能力受限）是这个架构下永远都无法解决的一个问题。

2.2 原生能力受限

为了安全，需要把用户的代码放到沙箱中去执行，但因为想让用户使用Vue开发，所以Vue也得放到沙箱中，这就导致了一个无法解决的问题是：我们官方提供的原生组件，也会受限。

道理很简单，假设用户在模板中使用了一个官方原生提供的组件，那么这个组件一定是需要提前注册到Vue中的，那就代表，我们官方提供的组件，也得放在沙箱中，所以把我们自己也给限制住了。

导致我们官方想提供视频组件，音频组件就很困难，因为我们官方组件也不能碰DOM和BOM，就更不用说提供其他Native能力的组件了。

当然这个问题在不改架构的情况下还是有办法强行解决的，解决方案是这样的：

官方组件先在沙箱中注册一个Vue的组件，然后这个组件不去实现具体的功能，只是接收用户传递的数据，然后把数据传递给UI线程，然后UI线程有一个这个组件对应的真实的组件去做具体的功能并最终渲染到UI上。

每一个组件都需要这样做，这对开发组件的同学非常不友好，他们需要理解这个小程序底层的架构是如何运行的，而且还会增加很多工作量。

这不是我想要的，我希望的是不管我底层是单线程还是双线程，对上层开发是无感知的。而且因为Vue.js是在沙箱中做各种操作，也不确定未来会不会有什么需求是无法满足的，技术风险太高了。

到了这一步，我已经慢慢的开始感受到，Vue已经成为瓶颈，它限制了我。

3. 回归单线程

不只是因为技术原因，也因为一些其他原因，比如风险太高，时间紧，最终决定先将方案切换回单线程，这样至少说可以保证这个项目不用延期。然后另一边再去慢慢调研并研究出一个技术方案可以解决之前遇到的所有问题。

似乎又回到了起点，因为单线程有单线程的问题，那就是Web技术太开放了，我们无法做到“安全”和对开发者进行“管控”。

不过我们还是在单线程模式下找到了可以提高一定安全性的方案，方案是通过ShadowDOM的Close模式把Body锁住。这样开发者自己的代码是无法操作DOM的，因为被我锁住了，但是开发者的JavaScript是自由的。

在这个架构下，开发者可以操作DOM，可以操作BOM，可以操作Vue.js，什么都可以干，但它无法直接操作被我锁住的ShadowDOM，想操作这个ShadowDOM，必须通过合法的途径操作，而这个ShadowDOM才是小程序用于展示的主要的窗口。

然后对于BOM上的某些危险API，会被提前禁用掉。

这个方案似乎解决了所有问题，但还是为未来留下了一点隐患，只要开发者的JavaScript是自由的，你就永远无法知道他会用他的JavaScript做什么。对于某些未知的漏洞，可能非常危险，这为日后留下了一个风险，事情会变成一场官方和开发者之间持久的攻防战。

无论怎样，这个方案解决了目前遇到的所有问题，这也为我留下了非常多的时间去研究真正的小程序应该怎样做。

4. 回归双线程

最终，我发现双线程才是正确的方向，只有把用户的代码放到沙箱里执行才能真正的做到：“安全”和“管控”。

不过这一次我决定不再使用Vue.js，我需要开发一个全新的框架来支持双线程这种模式。上一次的双线程之所以会失败，主要原因是上一次是UI线程比较轻，而Logic线程比较重，用户的代码，Vue.js，官方的组件都跑在Logic线程下，而这个线程只是一个JS运行时，所以我们的原生能力会受到限制。

而这一次我决定让UI重一点，Logic轻一点。只把用户的代码和框架的一部分下放到Logic线程，大部分操作和原生组件都放在UI线程下执行。

Worker线程只是做一些计算然后把数据传递到UI线程，然后大部分工作都在UI下面执行，并且官方的组件在UI这边执行。

这样可以解决之前遇到的两个问题：性能和原生能力受限。

因为线程之间的消息通道只传递数据，而数据不会像绘制UI指令数量那么多，可以说根本不在一个数量级，性能问题解决了，而且不光解决了性能问题，还顺带着提升了性能，因为无论用户代码写的执行效率再怎么低，都不会卡死UI线程。

原生能力受限的问题也解决了，因为官方提供的组件根本不在这个线程下运行，安全和管控的问题也解决了。

5. 一些思考

之前我一直以为其他小程序是Native渲染的，而我是基于Web技术实现的，但偶然有一次看到一些资料，才发现，原来大家都是基于Web技术实现的小程序，而实现方式也大致相同，遇到的问题也都一样。

可能唯一的区别是，我不需要多个webview，我只需要一个网页就够了，所以我可以把Logic线程的代码放到Web Worker里，而其他小程序是多个webview，所以他们不能用Web Worker，不过没有本质区别。

5.1 关于小程序跨平台的一些看法

前一段时间各种小程序多端框架满天飞，准确的说，这些框架都是“翻译”器，就我个人觉得，以翻译为基础在不同小程序之间进行跨端，只能算是一种临时性技术方案。

我觉得真正的终极技术方案，有两种：

1. 从渲染引擎层面抹平平台间的差异，例如：Flutter
2. 各个小程序开发商共同制定一些标准和规范，例如：浏览器

第一种，使用小程序提供的canvas的一些API实现一个渲染引擎，然后在渲染引擎上实现一些布局引擎，在此基础上提供的框架和其他能力都是统一的，不同平台之间只需要实现不同的渲染引擎即可。不过我不确定小程序提供的canvas能不能做到这一点，不过Web浏览器提供的canvas可以做到，像SpriteJS就做到了。

第二种，各大小程序厂商共同制定一套标准，按照标准实现各自的API，这种情况是比较好的，而且也不是完全没有可能。最近各大小程序厂商已经在W3C起草了小程序白皮书。

我捡重要的列一下白皮书中的内容：

1. 标准化小程序包（就是说一份小程序代码，可以在各大小程序平台解析，使用统一的.ma后缀的文件）
2. 标准化小程序页面的URI Scheme（就是说定义一份协议，然后同一个URI地址可以在不同的小程序平台打开相同的页面）
3. 标准化小程序Widgets

6. 总结

仔细看到这里的读者应该会对我开发小程序的整个过程和一些决策有一个大致的了解。

大家对小程序的底层实现都是使用双线程模型，大家对外宣称都会说是为了：

1. 方便多个页面之间数据共享和交互
2. 为native开发者提供更好的编码体验
3. 为了性能（防止用户的JS执行卡住UI线程）
4. 其他好处

但其实真正的原因其实是：“安全”和“管控”，其他原因都是附加上去的。

因为Web技术是非常开放的，JavaScript可以做任何事。但在小程序这个场景下，它不会给开发者那么高的权限：

• 不允许开发者把页面跳转到其他在线网页
• 不允许开发者直接访问DOM
• 不允许开发者随意使用window上的某些未知的可能有危险的API

当然，想解决这些问题不一定非要使用双线程模型，但双线程模型无疑是最合适的技术方案。

声明，本文仅限学习使用，最终会使用什么方案目前还无法明确表示。技术因素以及非技术因素都会影响最终技术方案的决策。

koa

学习koa需要一些相关知识，有两个关键词

• generator
• promise

本文主要针对koa的原理进行讨论，属于深度篇，并不会对koa的使用过多介绍。

如果在阅读过程中，发现有哪些地方我写的不太清楚，不容易理解，希望能提出，我会参考建议并进行修改~~

koa总体流程图

让我们从一张图开始

上图中，详细说明了koa从启动server之前，到接受请求在到响应请求的过程中，经历了哪些步骤。

那我们按照时间线说起~

启动前

图中有三个蓝色的方块，分别代表三个静态类。

什么是静态类？这个是我自己给起的名，哈哈

静态类就是程序运行前就存在的方法集合，动态类就是通过代码生成出的方法集合。额，都是我自己起的名，概念也是我自己琢磨的，就是简单归个类。

三个静态类分别是Request，Context，Response

Request

Request中包含了一些操作 Node原生请求对象的非常有用的方法。例如获取query数据，获取请求url等，更多方法去查API

Response

Response中包含了一些用于设置状态码啦，主体数据啦，header啦，等一些用于操作响应请求的方法。更多方法去查API

Context

Context是koa中最重要的概念之一，Context字面意思是上下文，也有环境等意思，koa中的操作都是基于这个context进行的，例如

this.body = 'hello world';

从前面的图中，启动前的三个蓝色方块可以看到，左边的Request和右边的Response各有一个箭头指向Context，表示Request和Response自身的方法会委托到Context中。

Context中有两部分，一部分是自身属性，主要是应用于框架内部使用，一部分是Request和Response委托的操作方法，主要为提供给用户更方便从Request获取想要的参数和更方便的设置Response内容。

下面是Context源码片段。

var delegate = require('delegates');
var proto = module.exports = {}; // 一些自身方法，被我删了

/**
 * Response delegation.
 */

delegate(proto, 'response')
  .method('attachment')
  .method('redirect')
  .method('remove')
  .method('vary')
  .method('set')
  .method('append')
  .access('status')
  .access('message')
  .access('body')
  .access('length')
  .access('type')
  .access('lastModified')
  .access('etag')
  .getter('headerSent')
  .getter('writable');

/**
 * Request delegation.
 */

delegate(proto, 'request')
  .method('acceptsLanguages')
  .method('acceptsEncodings')
  .method('acceptsCharsets')
  .method('accepts')
  .method('get')
  .method('is')
  .access('querystring')
  .access('idempotent')
  .access('socket')
  .access('search')
  .access('method')
  .access('query')
  .access('path')
  .access('url')
  .getter('origin')
  .getter('href')
  .getter('subdomains')
  .getter('protocol')
  .getter('host')
  .getter('hostname')
  .getter('header')
  .getter('headers')
  .getter('secure')
  .getter('stale')
  .getter('fresh')
  .getter('ips')
  .getter('ip');

delegates是第三方npm包，功能就是把一个对象上的方法，属性委托到另一个对象上

对了，你猜对了，上面那一排方法，都是Request和Response静态类中的方法，有点看目录的感觉~

method方法是委托方法，getter方法用来委托getter，access方法委托getter+setter

下面是源码片段

function Delegator(proto, target) {
  if (!(this instanceof Delegator)) return new Delegator(proto, target);
  this.proto = proto;
  this.target = target;
  this.methods = [];
  this.getters = [];
  this.setters = [];
  this.fluents = [];
}

Delegator.prototype.method = function(name){
  var proto = this.proto;
  var target = this.target;
  this.methods.push(name);

  proto[name] = function(){
    return this[target][name].apply(this[target], arguments);
  };

  return this;
};

从上面的代码中可以看到，它其实是在proto上新建一个与Request和Response上的方法名一样的函数，然后执行这个函数的时候，这个函数在去Request和Response上去找对应的方法并执行。

简单来个栗子

var proto = {};

var Request = {
  test: function () {
    console.log('test');
  }
};

var name = 'test';
proto[name] = function () {
  return Request[name].apply(Request, arguments);
};

我们在来看看getter方法

Delegator.prototype.getter = function(name){
  var proto = this.proto;
  var target = this.target;
  this.getters.push(name);

  proto.__defineGetter__(name, function(){
    return this[target][name];
  });

  return this;
};

可以看到，在proto上绑定个getter函数，当函数被触发的时候去，会去对应的request或response中去读取对应的属性，这样request或response的getter同样会被触发~

我们在来看看access

Delegator.prototype.access = function(name){
  return this.getter(name).setter(name);
};

可以看到，这个方法是getter+setter，getter上面刚说过，setter与getter同理，不多说了，心好累....

应用启动前的内容到现在就说完了，接下来我们看看使用koa来启动一个app的时候，koa内部会发生什么呢？

启动server

我们使用koa来启动server的时候有两个步骤。第一步是init一个app对象，第二步是用app对象监听下端口号，一个server就启动好了。

// 第一步 - 初始化app对象
var koa = require('koa');
var app = koa();

// 第二步 - 监听端口
app.listen(1995);

简单吧？

不了解内部机制的同学，通常会认为server是在koa()这个时候启动的，app.listen只是监听下端口而已~

事实上。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。并不是。

有木有被刷新三观？？？

我们看下源码片段

module.exports = Application;

function Application() {
  if (!(this instanceof Application)) return new Application;
  this.env = process.env.NODE_ENV || 'development';
  this.subdomainOffset = 2;
  this.middleware = [];
  this.proxy = false;
  this.context = Object.create(context);
  this.request = Object.create(request);
  this.response = Object.create(response);
}

从源码中可以看到，执行koa()的时候初始化了一些很有用的东西，包括初始化一个空的中间件集合，基于Request，Response，Context为原型，生成实例等操作。

Request和Response的属性和方法委托到Context中也是在这一步进行的

并没有启动server

我们看第二步，在看一段源码

app.listen = function(){
  debug('listen');
  var server = http.createServer(this.callback());
  return server.listen.apply(server, arguments);
};

可以看到，在执行app.listen(1995)的时候，启动了一个server，并且监听端口。熟悉nodejs的同学知道http.createServer接收一个函数作为参数，每次服务器接收到请求都会执行这个函数，并传入两个参数（request和response，简称req和res），那么现在重点在this.callback这个方法上。

我们一起看一下this.callback是何方神圣

app.callback = function(){
  if (this.experimental) {
    console.error('Experimental ES7 Async Function support is deprecated. Please look into Koa v2 as the middleware signature has changed.')
  }
  var fn = this.experimental
    ? compose_es7(this.middleware)
    : co.wrap(compose(this.middleware));
  var self = this;

  if (!this.listeners('error').length) this.on('error', this.onerror);

  return function(req, res){
    res.statusCode = 404;
    var ctx = self.createContext(req, res);
    onFinished(res, ctx.onerror);
    fn.call(ctx).then(function () {
      respond.call(ctx);
    }).catch(ctx.onerror);
  }
};

这个方法其实可以分成两部分，一部分是执行函数的那一瞬间所执行的代码，另一部分是接收请求的时候所执行的代码。

而前一部分就是总体流程图中，启动server这个时间段，黄色椭圆形所执行的那一部分，初始化中间件！！！

第一部分

先说第一部分，很明显，这环节是在初始化中间件，那为什么要初始化中间件呢？处理后的中间件与处理之前的中间件又有什么不同呢？？？？

童鞋，，，不要着急，听我慢慢道来~~

我们添加中间的时候使用app.use方法，其实这个方法只是把中间件push到一个数组，然后就没有然后了。。(⊙﹏⊙)

很明显，所有中间件都在数组中，那么它们之间是没有联系的，如果没有联系，就不可能实现流水线这样的功能。。。。

那么这些中间件处理之后会变成什么样的？？？？

我们先看代码，上面的代码中用this.experimental这个属性做了一个判断。这个属性是什么鸟。

this.experimental 关于这个属性我并没有在官方文档上看到说明，但以我对koa的了解，这个方法是为了判断是否支持es7，默认是不支持的，如果想支持，需要在代码中明确指定this.experimental = true，开启这个属性之后，中间件可以传入async函数。

我想说的是，无论是否开启ES7，原理都是相同的，只是因为语法特性的不同，需要不同的处理，核心**不会因为不同的语言特性而改变，支持ES7显然处理起来更方便，因为默认不开启this.experimental，所以这里我们针对不开启的情况进行讨论~

这样一来，第一部分的代码就简化成了这样

var fn = co.wrap(compose(this.middleware));

虽然只剩下一行代码，但不要小瞧它哦~~

我们先看compose(this.middleware)这部分，compose的全名叫koa-compose，他的作用是把一个个不相干的中间件串联在一起。。

例如

// 有3个中间件
this.middlewares = [function *m1() {}, function *m2() {}, function *m3() {}];

// 通过compose转换
var middleware = compose(this.middlewares);

// 转换后得到的middleware是这个样子的
function *() {
  yield *m1(m2(m3(noop())))
}

有木有很神奇的感觉？？更神奇的是，generator函数的特性是，第一次执行并不会执行函数里的代码，而是生成一个generator对象，这个对象有next，throw等方法。

这就造成了一个现象，每个中间件都会有一个参数，这个参数就是下一个中间件执行后，生成出来的generator对象，没错，这就是大名鼎鼎的 next

那compose是如何实现这样的功能的呢？？我们看一下代码

/**
 * Expose compositor.
 */

module.exports = compose;

/**
 * Compose `middleware` returning
 * a fully valid middleware comprised
 * of all those which are passed.
 *
 * @param {Array} middleware
 * @return {Function}
 * @api public
 */

function compose(middleware){
  return function *(next){
    if (!next) next = noop();

    var i = middleware.length;

    while (i--) {
      next = middleware[i].call(this, next);
    }

    return yield *next;
  }
}

/**
 * Noop.
 *
 * @api private
 */

function *noop(){}

这是这个模块的所有代码，很简单，逻辑是这样的

先把中间件从后往前依次执行，并把每一个中间件执行后得到的generator对象赋值给变量next，当下一次执行中间件的时候（也就是执行前一个中间件的时候），把next传给第一个参数。这样就保证前一个中间件的参数是下一个中间件生成的generator对象，第一次执行的时候next为noop，noop是空的generator函数。

koa的中间件必须为generator函数（就是带星号的函数），否则无法顺利的执行中间件逻辑

最后，有一个非常巧妙的地方，就是最后一行return yield *next;

这行代码可以实现把compose执行后return的函数变成第一个中间件，也就是说，执行compose之后会得到一个函数，执行这个函数就与执行第一个中间件的效果是一模一样的，这主要依赖了generator函数的yield *语句的特性。

现在中间件的状态就已经从不可用变成可用了。不可用的中间件是一个数组，可用的中间件是一个generator函数。

我们接着说刚才没说完的

var fn = co.wrap(compose(this.middleware));

上面这段代码现在就可以理解成下面这样

var fn = co.wrap(function *() {yield *m1(m2(m3(noop())))});

里面的函数刚刚已经说过是可用状态的中间件，那么co.wrap是干什么用的呢？？

co是TJ大神基于Generator开发的一款流程控制模块，白话文就是：就是把异步变成同步的模块。。。（感觉逼格瞬间拉低了。。。）

看下源码

co.wrap = function (fn) {
  createPromise.__generatorFunction__ = fn;
  return createPromise;
  function createPromise() {
    return co.call(this, fn.apply(this, arguments));
  }
};

从源码中可以看到，它接收一个参数，这个参数就是可用状态下的中间件，返回一个函数createPromise，当执行createPromise这个函数的时候，调用co并传入一个参数，这个参数是中间件函数执行后生成的Generator对象。

这意味着，返回的这个函数是触发执行中间件逻辑的关键，一旦这个函数被执行，那么就会开始执行中间件逻辑

app.callback = function(){
  if (this.experimental) {
    console.error('Experimental ES7 Async Function support is deprecated. Please look into Koa v2 as the middleware signature has changed.')
  }
  var fn = this.experimental
    ? compose_es7(this.middleware)
    : co.wrap(compose(this.middleware));
  var self = this;

  if (!this.listeners('error').length) this.on('error', this.onerror);

  return function(req, res){
    res.statusCode = 404;
    var ctx = self.createContext(req, res);
    onFinished(res, ctx.onerror);
    fn.call(ctx).then(function () {
      respond.call(ctx);
    }).catch(ctx.onerror);
  }
};

从源码中，可以看到这个函数赋值给fn，fn是在下面那个函数中执行的，下面那个函数是接下来要说的内容~

到现在，我们的koa已经处于一种待机状态，所有准备都以准备好（中间件和context），万事俱备，只欠东风。。。。。。

东风就是request请求~~

接收请求

前面说了启动前的一些准备工作和启动时的初始化工作，现在最后一步就是接收请求的时候，koa要做的事情了，这部分也是koa中难度最大的一部分。不过认真阅读下去会有收获的。。

上面我们说this.callback这个方法有两个部分，第一个部分是初始化中间件，而另一部分就是接收请求时执行的函数啦。

简单回顾下

// 创建server并监听端口
app.listen = function(){
  debug('listen');
  var server = http.createServer(this.callback());
  return server.listen.apply(server, arguments);
};

// 这个方法返回的函数会被传递到http.createServer中，http.createServer这个方法的作用是每当服务器接收到请求的时候，都会执行第一个参数，并且会传递request和response
app.callback = function(){
  if (this.experimental) {
    console.error('Experimental ES7 Async Function support is deprecated. Please look into Koa v2 as the middleware signature has changed.')
  }
  var fn = this.experimental
    ? compose_es7(this.middleware)
    : co.wrap(compose(this.middleware));
  var self = this;

  if (!this.listeners('error').length) this.on('error', this.onerror);

  return function(req, res){
    res.statusCode = 404;
    var ctx = self.createContext(req, res);
    onFinished(res, ctx.onerror);
    fn.call(ctx).then(function () {
      respond.call(ctx);
    }).catch(ctx.onerror);
  }
};

所以第二部分的重点就是下面段代码啦~

return function(req, res){
  res.statusCode = 404;
  var ctx = self.createContext(req, res);
  onFinished(res, ctx.onerror);
  fn.call(ctx).then(function () {
    respond.call(ctx);
  }).catch(ctx.onerror);
}

我们先看这段代码

var ctx = self.createContext(req, res);

不知道各位童鞋还记不记得文章一开始的时候那个总体流程图下面的那个类似于八卦一样的东西？？？

这行代码就是创建一个最终可用版的context。

从上图中，可以看到分别有五个箭头指向ctx，表示ctx上包含5个属性，分别是request，response，req，res，app。request和response也分别有5个箭头指向它们，所以也是同样的逻辑。

这里需要说明下

• request - request继承于Request静态类，包含操作request的一些常用方法
• response - response继承于Response静态类，包含操作response的一些常用方法
• req - nodejs原生的request对象
• res - nodejs原生的response对象
• app - koa的原型对象

不多说，咱们观摩下代码

app.createContext = function(req, res){

  // 继承
  var context = Object.create(this.context);
  var request = context.request = Object.create(this.request);
  var response = context.response = Object.create(this.response);

  // 往context，request，response身上挂载属性
  context.app = request.app = response.app = this;
  context.req = request.req = response.req = req;
  context.res = request.res = response.res = res;
  request.ctx = response.ctx = context;
  request.response = response;
  response.request = request;
  context.onerror = context.onerror.bind(context);
  context.originalUrl = request.originalUrl = req.url;
  context.cookies = new Cookies(req, res, {
    keys: this.keys,
    secure: request.secure
  });
  context.accept = request.accept = accepts(req);
  context.state = {};

  // 最后返回完整版context
  return context;
};

讲到这里其实我可以很明确的告诉大家，，，koa中的this其实就是app.createContext方法返回的完整版context

又由于这段代码的执行时间是接受请求的时候，所以表明每一次接受到请求，都会为该请求生成一个新的上下文

上下文到这里我们就说完啦。我们接着往下说，看下一行代码

onFinished(res, ctx.onerror);

这行代码其实很简单，就是监听response，如果response有错误，会执行ctx.onerror中的逻辑，设置response类型，状态码和错误信息等。

源码如下：

onerror: function(err){
  // don't do anything if there is no error.
  // this allows you to pass `this.onerror`
  // to node-style callbacks.
  if (null == err) return;

  if (!(err instanceof Error)) err = new Error('non-error thrown: ' + err);

  // delegate
  this.app.emit('error', err, this);

  // nothing we can do here other
  // than delegate to the app-level
  // handler and log.
  if (this.headerSent || !this.writable) {
    err.headerSent = true;
    return;
  }

  // unset all headers
  this.res._headers = {};

  // force text/plain
  this.type = 'text';

  // ENOENT support
  if ('ENOENT' == err.code) err.status = 404;

  // default to 500
  if ('number' != typeof err.status || !statuses[err.status]) err.status = 500;

  // respond
  var code = statuses[err.status];
  var msg = err.expose ? err.message : code;
  this.status = err.status;
  this.length = Buffer.byteLength(msg);
  this.res.end(msg);
}

我们接着说，还有最后一个知识点，也是本章最复杂的知识点，关于中间件的执行流程，这里会说明为什么koa的中间件可以回逆。

我们先看代码

fn.call(ctx).then(function () {
  respond.call(ctx);
}).catch(ctx.onerror);

• fn - 我们上面讲的co.wrap返回的那个函数
• ctx - app.createContext执行后返回的完整版context对象

总体上来说，执行fn.call(ctx)会返回promise，koa会监听执行的成功和失败，成功则执行respond.call(ctx);，失败则执行ctx.onerror，失败的回调函数刚刚已经讲过。这里先说说respond.call(ctx);。

我们在写koa的时候，会发现所有的response操作都是
this.body = xxx; this.status = xxxx;这样的语法，但如果对原生nodejs有了解的童鞋知道，nodejs的response只有一个api那就是res.end();，而设置status状态码什么的都有不同的api，那么koa是如何做到通过this.xxx = xxx来设置response的呢？

先看一张图，，我盗的图

从图中看到，request请求是以respond结束的。

是滴，所有的request请求都是以respond这个函数结束的，这个函数会读取this.body中的值根据不同的类型来决定以什么类型响应请求

我们来欣赏一下源码

function respond() {
  // allow bypassing koa
  if (false === this.respond) return;

  var res = this.res;
  if (res.headersSent || !this.writable) return;

  var body = this.body;
  var code = this.status;

  // ignore body
  if (statuses.empty[code]) {
    // strip headers
    this.body = null;
    return res.end();
  }

  if ('HEAD' == this.method) {
    if (isJSON(body)) this.length = Buffer.byteLength(JSON.stringify(body));
    return res.end();
  }

  // status body
  if (null == body) {
    this.type = 'text';
    body = this.message || String(code);
    this.length = Buffer.byteLength(body);
    return res.end(body);
  }

  // responses
  if (Buffer.isBuffer(body)) return res.end(body);
  if ('string' == typeof body) return res.end(body);
  if (body instanceof Stream) return body.pipe(res);

  // body: json
  body = JSON.stringify(body);
  this.length = Buffer.byteLength(body);
  res.end(body);
}

仔细阅读的童鞋会发现，咦，，，，为毛没有设置status和header等信息的代码逻辑？这不科学啊。我分明记得状态码是rs.statusCode = 400这样设置的，为啥代码中没有？？

这就要从最开始的上下文说起了。为什么Response静态类中添加req和res属性？就是因为添加了req和res之后，response和request类就可以直接操作req和res啦。。我们看一段源码就明白了

set status(code) {
  assert('number' == typeof code, 'status code must be a number');
  assert(statuses[code], 'invalid status code: ' + code);
  this._explicitStatus = true;
  this.res.statusCode = code;
  this.res.statusMessage = statuses[code];
  if (this.body && statuses.empty[code]) this.body = null;
},

主要是this.res.statusCode = code; this.res.statusMessage = statuses[code];这两句，statusCode和statusMessage都是nodejs原生api。有兴趣可以自行查看~

接下来我们开始说说koa的中间件为什么可以回逆，为什么koa的中间件必须使用generator，yield next又是个什么鬼？

我们看这段代码

fn.call(ctx)

fn刚刚上面说过，就是co.wrap返回的那个函数，上面也说过，一旦这个函数执行，就会执行中间件逻辑，并且通过.call把ctx设为上下文，也就是this。

那中间件逻辑是什么样的呢。我们先看一下源码：

co.wrap = function (fn) {
  createPromise.__generatorFunction__ = fn;
  return createPromise;
  function createPromise() {
    return co.call(this, fn.apply(this, arguments));
  }
};

先回顾下，createPromise就是fn，每当执行createPromise的时候，都会执行co，中间件是基于co实现的、所以我们接下来要说的是co的实现逻辑。而执行co所传递的那个参数，我们给它起个名，就叫中间件函数吧，中间件函数也是一个generator函数，因为在执行co的时候执行了这个中间件函数，所以实际上真正传递给co的参数是一个generator对象，为了方便理解，我们先起个名叫中间件对象吧

那我们看co的源码：

function co(gen) {
  var ctx = this;
  var args = slice.call(arguments, 1)

  // we wrap everything in a promise to avoid promise chaining,
  // which leads to memory leak errors.
  // see https://github.com/tj/co/issues/180
  return new Promise(function(resolve, reject) {
    if (typeof gen === 'function') gen = gen.apply(ctx, args);
    if (!gen || typeof gen.next !== 'function') return resolve(gen);

    onFulfilled();

    /**
     * @param {Mixed} res
     * @return {Promise}
     * @api private
     */

    function onFulfilled(res) {
      var ret;
      try {
        ret = gen.next(res);
      } catch (e) {
        return reject(e);
      }
      next(ret);
    }

    /**
     * @param {Error} err
     * @return {Promise}
     * @api private
     */

    function onRejected(err) {
      var ret;
      try {
        ret = gen.throw(err);
      } catch (e) {
        return reject(e);
      }
      next(ret);
    }

    /**
     * Get the next value in the generator,
     * return a promise.
     *
     * @param {Object} ret
     * @return {Promise}
     * @api private
     */

    function next(ret) {
      if (ret.done) return resolve(ret.value);
      var value = toPromise.call(ctx, ret.value);
      if (value && isPromise(value)) return value.then(onFulfilled, onRejected);
      return onRejected(new TypeError('You may only yield a function, promise, generator, array, or object, '
        + 'but the following object was passed: "' + String(ret.value) + '"'));
    }
  });
}

可以看到，代码并不是很多。

首先执行co会返回一个promise，koa会对这个promise的成功和失败都准备了不同的处理，上面已经说过。

我们在看这段代码

function onFulfilled(res) {
  var ret;
  try {
    ret = gen.next(res);
  } catch (e) {
    return reject(e);
  }
  next(ret);
}

这个函数最重要的作用是运行gen.next来执行中间件中的业务逻辑。

通常在开发中间件的时候会这样写

yield next;

所以ret中包含下一个中间件对象（还记得上面我们初始化中间件的时候中间件的参数是什么了吗？？）

然后把下一个中间件对象传到了next(ret)这个函数里，next函数是干什么的？我们看看

function next(ret) {
  if (ret.done) return resolve(ret.value);
  var value = toPromise.call(ctx, ret.value);
  if (value && isPromise(value)) return value.then(onFulfilled, onRejected);
  return onRejected(new TypeError('You may only yield a function, promise, generator, array, or object, '
    + 'but the following object was passed: "' + String(ret.value) + '"'));
}

可以看到，逻辑是这样的

如果中间件已经结束（没有yield了），那么调用promise的resolve。

否则的话把ret.value（就是下一个中间件对象），用co在包一层toPromise.call(ctx, ret.value);

if (isGeneratorFunction(obj) || isGenerator(obj)) return co.call(this, obj);

上面是toPromise中的一段代码

既然是用co又执行了一遍，那么co是返回promise的。所以返回的这个value就分别被监听了成功和失败的不同处理。

value.then(onFulfilled, onRejected);

所以我们可以看到，如果第二个中间件里依然有yield next这样的语句，那么第三个中间件依然会被co包裹一层并运行.next方法，依次列推，这是一个递归的操作

所以我们可以肯定的是，每一个中间件都被promise包裹着，直到有一天中间件中的逻辑运行完成了，那么会调用promise的resolve来告诉程序这个中间件执行完了。

那么中间件执行完了之后，会触发onFulfilled，这个函数会执行.next方法。

所以有一个非常重要的一点需要注意，onFulfilled这个函数非常重要，重要在哪里？？？重要在它执行的时间上。

onFulfilled这个函数只在两种情况下被调用，一种是调用co的时候执行，还有一种是当前promise中的所有逻辑都执行完毕后执行

其实就这一句话就能说明koa的中间件为什么会回逆。

回逆其实是有一个去和一个回的操作

请求的时候经过一次中间件，响应的时候在经过一次中间件。

而onFulfilled的两种被调用的情况正好和这个回逆的过程对应上。

前方高能预警！！！

比如有3个中间件，当系统接收到请求的时候，会执行co，co会立刻执行onFulfilled来调用.next往下执行，将得到的返回结果（第二个中间件的generator对象，上面我们分析过）传到co中在执行一遍。以此类推，一直运行到最后一个yield，这个时候系统会等待中间件的执行结束，一旦最后一个中间件执行完毕，会立刻调用promise的resolve方法表示结束。（这个时候onFulfilled函数的第二个执行时机到了，这样就会出现一个现象，一个generator对象的yield只能被next一次，下次执行.next的时候从上一次停顿的yield处继续执行，所以现在当有一个中间件执行完毕后，在执行.next就会在前一个中间件的yield处继续执行）当最后一个中间件执行完毕后，触发promise的resolve，而别忘了，第二个中间件可是用then监听了成功和失败的不同处理方法，一旦第三个中间件触发成功，第二个中间件会立刻调用onFulfilled来执行.next，继续从第二个中间件上一次yield停顿处开始执行下面的代码，而第二个中间件的逻辑执行完毕后，同样会执行resolve表示成功，而这个时候第一个中间件正好也通过.then方法监听了第二个中间件的promise，也会立刻调用onFulfilled函数来执行.next方法，这样就会继续从第一个中间件上一次yield的停顿处继续执行下面的逻辑，以此类推。

这样就实现了中间件的回逆，通过递归从外到里执行一遍中间件，然后在通过promise+generator从里往外跳。

所以如果我们在一个中间件中写好多yield，就可以看出关键所在，先通过递归从外往里（从第一个中间件运行到最后一个中间件）每次遇到yield next就会进入到下一个中间件执行，当运行到最后发现没有yield的时候，会跳回上一个中间件继续执行yield后面的，结果发现又有一个yield next，它会再次进入到下一个中间件，进入到下一个中间件后发现什么都没有，因为yield的特性（一个generator对象的yield只能被next一次，下次执行.next的时候从上一次停顿的yield处继续执行），所以便又一次跳入上一个中间件来执行。以此类推。

我们试一下：

var koa = require('koa');
var app = koa();

app.use(function* f1(next) {
  console.log('f1: pre next');
  yield next;
  console.log('f1: post next');
  yield next;
  console.log('f1: fuck');
});

app.use(function* f2(next) {
  console.log('  f2: pre next');
  yield next;
  console.log('  f2: post next');
  yield next;
  console.log('  f2: fuck');
});

app.use(function* f3(next) {
  console.log('  f3: pre next');
  yield next;
  console.log('  f3: post next');
  yield next;
  console.log('  f3: fuck');
});

app.use(function* (next) {
  console.log('hello world')
  this.body = 'hello world';
});


app.listen(3000);

上面的代码打印的log是下面这样的

f1: pre next
  f2: pre next
  f3: pre next
hello world
  f3: post next
  f3: fuck
  f2: post next
  f2: fuck
f1: post next
f1: fuck

如果非要画一个图的话，我脑海中大概长这样

其实刚刚那么一通复杂的逻辑下来，好多同学都会懵逼，那么我用白话文来说一下中间件的逻辑，大概是这样的

第一个中间件代码执行一半停在这了，触发了第二个中间件的执行，第二个中间件执行了一半停在这了，触发了第三个中间件的执行，然后，，，，，，第一个中间件等第二个中间件，第二个中间件等第三个中间件，，，，，，第三个中间件全部执行完毕，第二个中间件继续执行后续代码，第二个中间件代码全部执行完毕，执行第一个中间件后续代码，然后结束

用一张图表示大概是这样的。

为了方便理解，伪代码大概是下面这样

new Promise(function(resolve, reject) {
  // 我是中间件1
  yield new Promise(function(resolve, reject) {
    // 我是中间件2
    yield new Promise(function(resolve, reject) {
      // 我是中间件3
      yield new Promise(function(resolve, reject) {
        // 我是body
      });
      // 我是中间件3
    });
    // 我是中间件2
  });
  // 我是中间件1
});

这就是最核心的**！！！

总结

简单总结一下，其实也很简单，只是第一次接触的同学可能暂时没有理解透彻。

其实就是通过generator来暂停函数的执行逻辑来实现等待中间件的效果，通过监听promise来触发继续执行函数逻辑，所谓的回逆也不过就是同步执行了下一个中间件罢了。

比如有几个中间件，mw1,mw2,mw3,mwn...

站在mw1的角度上看，它是不需要关系mw2里面有没有mw3，它只需要关心mw2何时执行完毕即可，当mw2执行完毕mw1继续执行yield之后的代码逻辑。其实很简单，callback也是这个原理，当mw2执行完毕执行下callback，mw1是不需要关心mw2里面究竟是怎样运行的，只要知道mw2执行完会执行回调就行了。mw2也是同样的道理不需要关心mw3。

到这里，关于koa我们就已经差不多都说完了。当然还有一些细节没有说，比如koa中的错误处理，但其实都是小问题啦，关于generator的错误处理部分弄明白了，自然就明白koa的错误处理是怎样的。这里就不在针对这些讲述了，一次写这么多确实有点累，或许后期会补充进来吧。。

两个重要技术点

最后，如果认真阅读下来的同学能感觉出来，koa中有两个最重要的地方，无论是使用上，还是**上，这两个点都非常重要，koa也只有这两个概念

• Middleware - 中间件
• Context - 上下文

最后说一些自己对koa的感觉，真他妈的是赏心悦目啊，真他妈的是优雅啊！！！每一行代码都浓缩了很多层含义，通过最少的代码实现最复杂的功能，对于我这种追求代码的极致优雅的人，看完koa之后，真的是感触良多，泪流满面啊。。。。

ppt：http://berwin.github.io/ppts/koa/

转载请注明出处

小程序底层实现原理及一些思考（2）

写在前面的话，最近频繁出现有人盗版我的原创文章、盗版我出版的书、抄袭我的文章、根据我的文章又写了一篇新的文章然后说是自己的研究成果、根据我的文章写了一个开源项目然后说是自己原创、根据我出版的书二次改写并开源到Github获得好几千Star等情况。

我愿意写硬核知识分享给大家是给大家学习与成长用的，也仅限于学习与学术交流使用。

我不希望我的文章以任何形式被转载、被二次改写、被盗版、被抄袭、或者根据我的文章开发了一个小程序框架开源出去骗star等侵占我版权的行为，一经发现必追究责任。

如果无法控制盗版行为，我将考虑关闭博客，开启白名单模式，只有白名单内的人可以阅读我的文章。为了帮助更多的人学习与进步，请大家拒绝盗版！

去年九月份写了篇文章 《小程序底层实现原理及一些思考》，讲述了我实现（探索）小程序的过程及一些思考，并揭露了一个事实：小程序是基于Web技术实现的。

兜兜转转尝试了很多方案，但不同的方案均存在一些问题，我试图找到完美的解决方案，功夫不负有心人，最终找到了。

在前文的最后，我提到最终还是要回到双线程，双线程才是正确的方向，现在经过验证这个方向非常正确。

但如何基于双线程实现小程序前文只是略微提及，因为当时也只是一个初步的设想，并没有实现出来。

为什么是双线程

当反复尝试了很多方案后，我开始重新思考，到底什么是小程序。

思考后得到的结论是，站在产品角度思考技术，小程序有两个特点：

1. 免安装
2. 具备通过宿主APP访问OS的能力

小程序的定义和特点有很多，但我认为最根本的特点是以上两点

站在技术角度思考，小程序至少要保证四点：安全、稳定、性能、简单。

• 安全，指的是小程序的安全性，由于小程序提供给开发者更高的权限，小程序开发者拥有很多OS能力的API，如果开发者利用这些API做些恶意的事情，那么对用户来说将是一场灾难（随便打开一个小程序，结果被黑客攻击了）。
• 稳定，指的是小程序的稳定性，某个小程序崩溃或者卡死，不应该影响宿主APP及其他小程序。手机上的小程序大部分只能同时打开一个小程序，所以读者可能无法理解什么是稳定性。PC上可以同时打开很多个小程序，根据产品形态不同，有的产品形态的小程序可能在一个网页里面运行（多个小程序同时在同一个网页里运行），这时候某个小程序卡死（例如写一个死循环），它不应该导致其他的小程序和宿主环境也跟着卡死。
• 性能，要保证小程序的执行、渲染等效率要足够高效。
• 简单，小程序对于开发者要足够简单，最好无需学习直接上手。

如果只是站在产品角度思考如何实现小程序其实非常简单。

基于宿主环境的不同可能实现方式不同

如果宿主环境是浏览器，任何一个网页都具备 “免安装” 的特点，浏览器只需提供一些拥有OS能力的API，这就是小程序了。

这和PWA区别不大，或许这也是很多人会拿小程序和PWA进行对比的原因。

如果宿主环境是一个超级APP（iOS或Android），任何一个WebView都具备免 “免安装” 的特点，超级APP只需提供一些拥有OS能力的API给WebView里面的代码用就可以了，套路都是一样的。

站在技术角度思考，为了保证安全性与稳定性问题，单线程这个方向就要完全放弃，这也是为什么上一篇文章的最后提到“双线程”是正确的方向。

事实上，双线程并不够，如果允许多个小程序同时运行，那么双线程无法解决稳定性的问题，正确的做法是使用 “多线程” ，将不同小程序的代码在不同的线程下执行。

如果同一时间只执行一个小程序，那么双线程（UI线程与逻辑线程）就可以满足“安全性”与“稳定性”的需求。但同时运行多个小程序，则需要多个逻辑线程同时执行不同小程序的逻辑，以及多个UI线程同时渲染不同小程序的UI。

多线程

多线程不只是解决多个小程序并存的问题，每个小程序还需要有自己的多个UI线程。

也就是说要完全抛弃SPA（单页应用），小程序应该做成多页应用，而不是单页应用。

之所以采用多UI线程的原因是单页应用很难模拟原生应用切换页面的体验。单页应用在从A页面跳转到B页面时，其实画布还是那块画布，只是把A页面的内容擦掉把B页面的UI画上去了。这种原理在很多场景下很尴尬，举个例子：用户开发一款新闻信息流小程序，它有两个页面，A页面是新闻信息流，B页面是新闻详情页。那么当用户往下滑了很久后发现一个感兴趣的新闻，点击跳转到详情页，看完之后想回到A页面刚才的位置继续浏览。单页应用由于把A页面给擦掉了，所以这种场景下当从B回到A时，会发现A又重新刷新了一遍，体验非常糟糕。

采用多UI线程则可以解决这个问题，实现多UI线程并不复杂，如果宿主环境是浏览器，则可以在页面中使用多个iframe叠在一起，每当跳转页面时，创建一个新的iframe盖在最上面，当回退时，把最上层的iframe删除即可。如果宿主环境是手机上的超级APP，则把iframe改成WebView，套路都是一样的。

双线程的关键在于逻辑线程要尽可能的 “轻” ，并且要尽量 减少 线程间通信的 频率 ，曾经在双线程上失败主要在于逻辑线程非常重，并且线程间通信非常频繁，上一篇文章有提到。

多线程架构

为了做到让逻辑线程尽可能的 “轻” ，且 减少 逻辑线程与UI线程的通信 频率 ，那么逻辑线程的职责应该设计成只做两件事：

1. 执行用户的函数（生命周期、方法等）
2. 收发状态数据

执行用户的函数是为了让开发者有能力修改状态数据，状态数据只在组件初始化以及开发者修改状态数据后发送至UI线程。其余全部逻辑均在UI线程下完成。

通过这样的方案达到了让逻辑线程尽可能的 “轻” （只是执行开发者提供的函数而已），且 减少 逻辑线程与UI线程的通信 频率 （只在初始化及状态数据发生变化时产生通信）目的。

之所以把架构设计成这样是因为如果不这样，则会有两个致命问题：“性能”和“原生能力受限”。

上一篇文章《小程序底层实现原理及一些思考》有提到另一种方案（及逻辑线程重而UI线程轻）的问题，这里简单回顾一下这个失败的方案：

UI线程只负责接收指令（创建元素、修改元素、插入元素、路由跳转、事件绑定等一些基础指令），剩余的一切都有逻辑线程执行（用开发者提供的状态数据计算应该发出哪些指令）。这个方案有两个致命问题：“性能”和“原生能力受限”。

因为逻辑线程经过计算后，若想渲染一个完整的UI页面，需要发送大量的绘制指令（创建元素、修改元素、插入元素、修改属性等），指令在线程间传输是异步的，也就导致指令信号的传输间有间隔，由于指令很小，导致间隔的时间比指令的时间还长，如下图所示：

黄色的JavaScript执行方块是指令的执行，而两个指令之间有很多空闲的时间，因为执行信号的传递需要时间。所以背后的执行过程是，接受一个指令绘制一下，然后等一会又接收一个新的指令然后再绘制下，当指令数量庞大的时候，性能问题非常明显，绘制一整个UI界面非常慢。

所以让逻辑线程尽可能的 “轻” ，且将线程间传输的“指令”改为“数据”来 减少 逻辑线程与UI线程的通信 频率 是非常重要的。

通讯模块

谈完了整体架构的设计和考虑，再谈谈通讯模块，顾名思义，通信模块的职责是负责不同线程之间的通信功能。

在多线程架构下，通讯模块至关重要，但通讯模块的实现并不复杂，底层依赖宿主环境提供的消息通道。例如：Master层控制iframe时底层可以使用postMessageAPI。

有一点需要注意：通信模块在通讯时，为了将信号准确地发送到指定位置，需要根据频道号发送，频道号的规范应该设置为[mid]_[pid]_[cid]。

• mid = MiniApp ID
• pid = Page ID
• cid = Component ID

之所以将信号规范成这样，是为了同时执行多个小程序时，信号依然可以准确地找到指定位置。

另一个需要注意的地方是，官方组件的逻辑执行环境和开发者的组件逻辑执行环境不在一个地方， 通信模块需要负责分辨并将信号发送到指定位置 。

通信的逻辑大致如下：