92 lines
8.4 KiB
Markdown
92 lines
8.4 KiB
Markdown
|
# 结束语 | 真正的高贵，不是优于别人，而是优于过去的自己
|
|||
|
|
|
|||
|
|
你好，我是袁武林。
|
|||
|
|
|
|||
|
|
不知不觉中，在大家的耐心陪伴下，即时消息专栏的更新马上就要结束了。
|
|||
|
|
|
|||
|
|
首先，要感谢各位同学对我的信任和宽容，给我这个机会，让我能够在这段短暂的时间里，带领大家一起来学习即时消息这一门古老但又充满活力的技术。
|
|||
|
|
|
|||
|
|
对我来说，这是一段非常特别和有趣的体验，我也第一次尝试通过专栏的方式，将自己了解的知识进行体系化的输出。
|
|||
|
|
|
|||
|
|
当然这并不是一件简单的事情，知识点整理、稿件打磨、录音、留言反馈等等，背后的艰辛可能也只有经历过的人才能体会到。但每次专栏更新上线，看到自己的付出有帮助到一些同学，并且得到肯定的时候，我瞬间感觉又充满了战斗的能量。
|
|||
|
|
|
|||
|
|
## 关于专栏的落地
|
|||
|
|
|
|||
|
|
实际上，在开始筹备这个专栏的时候，我个人是比较没有信心的。
|
|||
|
|
|
|||
|
|
原因倒不是说技术层面的问题，而是担心即时消息这个话题，因为受众相对没有那么广泛，在推出之后，如何让更多非IM行业的小伙伴，也能够感兴趣并且参与进来，一直是我和极客时间团队需要认真考虑的一个事情。
|
|||
|
|
|
|||
|
|
因为一直没有想到更好的办法，所以这个专栏甚至中途一度停滞中断。直到6月下旬，经过和极客时间小伙伴们的多次讨论，我们才最终决定继续推进这个专栏的落地。
|
|||
|
|
|
|||
|
|
## 关于即时消息技术的前景
|
|||
|
|
|
|||
|
|
从我们的角度看，随着4G网络的普及和5G网络的逐步推广，在移动网络场景中，不管是流量资费还是网络的稳定性和速度、带宽，相比几年前都有了非常明显的提升。
|
|||
|
|
|
|||
|
|
在这样的大环境下，原本更多被用于聊天等社交场景的即时通讯技术，也被大范围应用于“万物互联”的物联网场景，以及新型社交模式，如直播互动、游戏互动等。而且，还有越来越多对实时性要求高的业务场景，也都开始引入即时通讯技术，来提升用户的使用体验。
|
|||
|
|
|
|||
|
|
因此，我们觉得，开设一门即时通讯技术相关的课程，不仅能够让同学们从基础原理层面上更体系化地了解即时通讯底层核心的技术实现，并且能够帮助大家在各自从事的业务系统中，结合实际场景，来尝试引入课程中介绍到的某些适合自己业务的技术点。
|
|||
|
|
|
|||
|
|
专栏真正开始落地后，在一系列自我摧残式的存稿，以及逐字逐句和编辑的磨稿过程中，我才切身体会到做一个专栏有多不容易。
|
|||
|
|
|
|||
|
|
和以前随意写写博客相比，一个严谨的专栏需要耗费大量的时间和精力去提炼技术点，并且要尽量用“通俗易懂”的文字来组织语言。
|
|||
|
|
|
|||
|
|
专栏的落地对于我自己来说，也是一个成长和学习的过程。
|
|||
|
|
|
|||
|
|
特别是在留言区，就某些技术点和各位同学们的讨论，大家的一些有趣、富有想象力的观点，也能让我重新思考，涉及的这些技术点是不是某些方面的考虑还不够，或者是否还有更好的实现落地方案。
|
|||
|
|
|
|||
|
|
在专栏即将结束的时候，我也想借这个机会，和参与到这门课程学习中的你，聊一聊我对技术和学习方法的一些个人的思考。
|
|||
|
|
|
|||
|
|
## 学习方法论：知识的广度和深度问题
|
|||
|
|
|
|||
|
|
很多时候，我们搞技术的小伙伴经常会听到人们对于知识的两种学习路径：一种是追求知识的广度，力图多点开花，前后端通吃；另一种是追求某一个知识点的深度，从对某一个小知识点的“了解和会用”，到“底层原理分析”，再到“思考优化”的这种路径来学习知识。
|
|||
|
|
|
|||
|
|
但是对于很多从事技术的小伙伴们来说，这样很容易陷入到一个“两难”的学习方法论的抉择中，毕竟现在的新技术层出不穷。
|
|||
|
|
|
|||
|
|
就拿即时消息的技术体系来说，暂且不去讲多种语言实现的问题，光是Java体系下网络通信的NIO框架就有好几种，要选择哪个框架就是一个让人很纠结的问题。
|
|||
|
|
|
|||
|
|
这种情况下，很容易让人陷入一个怪圈：就是我们可能花费了大量的精力，放在框架特性介绍对比、框架使用方法研究等知识上面，力求通过掌握更多的NIO框架的使用，来提升自己这方面知识的广度。但从我个人角度来看，是不推荐这种学习和研究方式的。
|
|||
|
|
|
|||
|
|
我认为所谓的知识广度是一个伪命题，换句话说，知识的广度只是一个结果，而不是一种学习的方法。
|
|||
|
|
|
|||
|
|
我更推荐的是：**针对某一个特定的技术点，从使用方法下沉到原理层面上，再逐步去拓展和了解研究学习过程中碰到的各种疑问与实现细节，从而“由点到面”地去吃透该知识点。**
|
|||
|
|
|
|||
|
|
打个比方，要对NIO框架进行研究，我觉得没必要先去纠结各种框架的优劣，而是可以选择一种比较主流大众的框架去做实践；然后，逐步去了解这个NIO框架使用到的JDK的IO库的实现方式。
|
|||
|
|
|
|||
|
|
比如，搞明白JDK的IO库模型，是从传统的阻塞型的BIO，发展到JDK 1.4开始支持多路复用的NIO，再发展到JDK 1.7继续改进的异步的AIO，以此来了解这几种模型的区别和迭代改进的地方。
|
|||
|
|
|
|||
|
|
最后，再深入到底层的操作系统层，了解它们是如何支持这些IO模型的。
|
|||
|
|
|
|||
|
|
比如，要了解Linux的select和epoll的实现原理，可能还需要了解IO过程中涉及到的IO事件、最终的TCP连接的状态，以及与数据收发之间的关系。因此，你还可以对TCP协议进行体系化的了解。
|
|||
|
|
|
|||
|
|
通过这种层层深入的学习方式，我们就能较为扎实地掌握一个NIO框架涉及到的垂直知识体系。
|
|||
|
|
|
|||
|
|
这样，你在掌握知识点的同时，知识广度方面也能自然而然地充实起来，以后再切换到其他NIO框架，就相对简单了很多，也能更客观和精确地对这些框架从底层原理层面来进行比对了。
|
|||
|
|
|
|||
|
|
当然，这种逐层深入的学习方法，在前期可能需要花费大量的精力和时间，因此需要你一定的耐心和坚持，但在对底层原理层知识有一定的积累之后，这种学习的方法也会越来越轻松。
|
|||
|
|
|
|||
|
|
## 学习方法论：碎片化知识和系统化学习
|
|||
|
|
|
|||
|
|
关于技术学习路径的另一个小小的建议是：从了解碎片化的知识开始，逐步扩大你在某一方面的技能树，然后再对这方面的整体知识进行系统化的学习和总结沉淀。
|
|||
|
|
|
|||
|
|
随着现在各种技术博客、技术类公众号、技术站点等等的普及和传播，大部分时候，我们只能通过工作之余的些许碎片化时间，来了解某些细碎的知识点。
|
|||
|
|
|
|||
|
|
当然，这些碎片化的知识点是一种不错的积累，但这些零散的知识点，在碎片化学习的时候，由于学习时间短、文章内容比较聚焦于一个小点，很容易让我们看完之后产生一种“我知道了”，然后就没有后续了，难以进行复杂的思考。
|
|||
|
|
|
|||
|
|
所以，我个人的建议是，**对于某一技术点方面的碎片化的知识，在一段时间的学习后，还是需要进行系统化的“复盘”**，一来可以补充遗漏的某些技术细节，二来能够形成对这个知识点的整理和总结思考，最终沉淀成自己的文档或者代码输出。
|
|||
|
|
|
|||
|
|
另外，你也可以尽量优先地去选择学习与自己工作内容息息相关的技术点，这样在理解知识和后续的输出实践上，也会更有帮助。
|
|||
|
|
|
|||
|
|
## 写在最后
|
|||
|
|
|
|||
|
|
对于从事技术工作的我们来说，技术探索的道路总是显得如此漫长，不断迭代更新的技术时常会让我们眼花缭乱，各种技术知识产品的爆炸式推广，让我们获取知识的方式变得如此简单。
|
|||
|
|
|
|||
|
|
但另一方面，在快节奏的生活方式下，在繁重的工作、与家人朋友的相处时间之外，我们的时间总是显得远远不够用。
|
|||
|
|
|
|||
|
|
如何保持一颗对新鲜事物的好奇心，如何高效有序地管理时间，如何形成一套适合自己的学习方法，这个时候可能往往比技术本身更重要。
|
|||
|
|
|
|||
|
|
海明威说：**“真正的高贵，不是优于别人，而是优于过去的自己。”**
|
|||
|
|
|
|||
|
|
无论如何，可能我们在一开始的时候，学习的技巧并不是那么高明，**但只要我们保持终身学习的姿态，持续地投入到真正喜欢的事情上，就能让今天的我们比昨天进步一点点。**
|
|||
|
|
|
|||
|
|
**我相信，时间的复利最终能让你真正采撷到成功的芬芳玫瑰！**
|
|||
|
|
|