context 切换

概念

context，以前理解成上下文，但总觉得还是差点意思。所以我还是选择直接用 context 这个单词表达。生活中，涉及到的 context 切换的场景可太多了，这篇持续维护，将 context 切换的场合不断收录，争取达到效率最优。

分析

目前感觉除了肌肉锻炼，有待分析外。其他场合，都是避免 context 切换，能带来更高的效率。

📚思考·快与慢 里面提到的系统 1 和系统 2。目前感觉如果切换时，是对快通道系统 1 的切换，对效率影响不大。但如果打断了慢通道系统 2，则会需要时间才能恢复回来。

场合

• 生活
  • 平静状态和运动状态切换
    • 运动后，根本无法短时间回到平静时候的那种思考状态和水平来。
• 工作
  • 干到一半被微信，邮件消息推送影响，造成 context 切换
  • 会议过程被其他无关事物打断，造成 context 切换
  • 给同事发任务、工作、资料等，应该把 context 一同发送，避免来回沟通损失时间。
• 科技使用
  • 手机、平板、pc 切换着用
    • 除了用笔绘画场合，pc 各方面完爆手机和平台
    • pc 开微信效率＞pc 切换到用手机开微信
  • 鼠标、触摸板和键盘切换着用
    • 目前公认的效率方式，都是通过一个 command console 实现最高效率。比如 mac 中的Alfred。obsidian 里面的 cmd + p，vscode 里面的 cmd+p。
    • 但是如果纯用键盘，不用鼠标和触摸板，很多时候需要记忆太多的快捷键，这是否值得，是否本末倒置，得具体问题具体分析
    • 目标：将来生活和工作中，尽量地找到快捷键记忆量和不用鼠标触摸板之间的平衡点。
      • 初级目标：obsdian，onenote，vscode，想办法全部快捷键化键盘化，避免 context 切换，中断创作节奏。
• 健身运动
  • 无氧有氧来回切换可行性？
  • 无氧运动，各个部位来回锻炼？
• 计算机领域
  • 进程，线程出栈入栈，也都是带来一定 cpu 时长损耗
  • 编程时，现在开源盛行，可引用的模块和轮子很多，这时候，也许写到一半，去找轮子而造成的 context 切换，最后带来的效率，反而是高于一直埋头写代码。但这本质上，context 切换还是损耗的，只是引用了轮子，节约下了大量自己造轮子的时间。
  • 浏览器找资料时，经常会被文章各种引用点开链接，导致 tab 栏爆炸，甚至找不回当初打开这几十个 tab 页的初衷是啥，这个问题本质也是 context 切换带来了效率损失，想办法解决 #