Rain科技 4 月 12 日消息，微软资深工程师 Dave Plummer 近日在视频中分享了 Windows 任务管理器的开发幕后，Plummer 同时也是 ZIP 文件支持等多项 Windows 经典功能的开发者。
这款他亲手打造的系统工具最初体积仅有 80KB，而如今的版本已膨胀至约 4MB。
Plummer 表示，在 90 年代开发任务管理器时面临的核心目标是：这台工具必须在系统其他一切都已卡死的情况下，依然保持流畅响应。
为此他采取了一系列极致的优化手段，在启动检测方面，任务管理器并非简单地检查是否已有实例在运行，而是向已有实例发送一条私有消息并等待回复。
如果收到回应，说明现有实例正常运行，直接激活即可；如果没有任何回应，则判定现有实例也已卡死，随即启动新实例来救场。
在资源管理方面，Plummer 将常用字符串一次性加载到全局变量中，避免重复获取；对于低频功能，则采用按需加载策略。
进程树的构建方式也经过精心设计，采用的是直接向内核请求完整的进程表，而非逐个查询每个程序，大幅减少了 API 调用次数，如果缓冲区不足，则自动扩容后重试。
Plummer 还对现代软件开发的膨胀趋势直言不讳，他将框架依赖比作“吃你食物却从不付房租的室友”，并指出现代工具往往”从框架起步，加九层舒适配置、六层面向未来设计，然后惊讶于它吃掉了 800MB 内存，还需要一场励志演讲才能显示几个数字”。
从客观角度分析，软件体积与性能的博弈始终是计算机工程领域的核心矛盾。随着硬件性能的摩尔定律式增长，开发者往往倾向于利用冗余资源换取开发效率，各种高级框架虽然降低了编程门槛，却也带来了层层封装的开销。Plummer 的批评虽显犀利，却点出了当前行业普遍存在的“资源浪费”现象。然而，完全回归手工优化也不现实，关键在于根据应用场景选择合适的技术栈。
他坦言不希望回到 90 年代的硬件限制，但认为开发者应当保留当年的”品味”：批量处理工作、缓存正确的东西、跳过不可见的计算、在重绘前做差异比对、一次向内核请求而非一百次。
