{"source":{"id":"mb-20260827-1b87b1","title":"全世界每天播放的上百亿次视频，几乎都必须从同一个免费程序里穿过去","url":"https://mubeitech.com/p/mb-20260827-1b87b1"},"method":"semantic-similarity","count":2,"items":[{"rank":1,"id":"mb-20260827-585bbd","account":"mubei","brand":"","title":"一台五年前的老电脑，跑不动每月收费 22.99 美元的 After Effects，却能把一个开源动画工具跑出 60 帧","summary":"一台五年前的老电脑，跑不动每月收费 22.99 美元的 After Effects，却能把一个开源动画工具跑出 60 帧","body":"一台五年前的老电脑，跑不动每月收费 22.99 美元的 After Effects，却能把一个开源动画工具跑出 60 帧满速。\n这个开源项目叫 Friction。\n矢量绘图、关键帧、曲线调整、时间轴、表达式绑定，做的全都是动效设计的核心工作。\n很多人的第一反应，是开源社区又出了什么技术天才，或者是 Adobe 的工程师集体偷懒。\n两个猜测都不对。\n几千名顶尖工程师维护了三十年的工业标准，为什么在底层运行效率上，会被一个独立开源项目直接超车？\n秘密不在代码技巧。\n在一台困住所有商业软件巨头的冰冷机器：向下兼容税。\n要看懂这台机器，得把时间推回 1993 年。\n那一年，罗德岛一家叫 CoSA 的四人团队，写下了 After Effects 1.0 的第一行代码。\n当时的个人电脑只有单核处理器，内存只有十几兆。\n软件底层的渲染管道和内存调度，天然建立在单线程、同步阻塞的逻辑上。\n1994 年，Adobe 收购了它，并围绕这套底座建起了一座价值数百亿美元的软件帝国。\n数万个第三方插件、几百万套商业工程模板、全球影视工业通用的工程格式。\n这些资产构成了商业巨头不可撼动的护城河。\n也成了它今天无论如何也卸不下来的沉重锁链。\nAdobe 敢不敢把底层架构彻底推倒重写？\n根本不敢。\n一旦推倒重来，几十年的旧插件生态会瞬间瓦解，好莱坞工作室的历史工程无法向下兼容，核心商业客户会立刻集体反弹。\n于是它只能在 1993 年的地基上，一层又一层往上打补丁。\n为了吃上多核处理器的性能，它早年甚至用过一种极度笨拙的方案：在后台同时启动多个完整的软件实例去抢内存。\n直到近几年强推多帧渲染，只要工程里挂进一个二十年前写的旧滤镜，整个主线程依然会被瞬间卡死。\n再加上后台常驻的云端鉴权、防盗版守护进程、数据遥测，软件还没画出第一条曲线，先吃掉几个 G 的内存。\n反观 Friction，根本没有这笔三十年的历史旧账。\n它不需要向 1993 年的代码妥协。\n它的底层直接接入了 Google 开发的现代图形引擎 Skia，也就是 Chrome 浏览器和安卓系统底层的 GPU 硬件加速管线，全套用现代 C++ 重写。\n没有历史插件要兼容，没有旧格式要顾及，没有防盗版程序在后台偷抢算力。\n它省下的，就是那笔昂贵沉重的向下兼容税。\n商业巨头的护城河，往往也会变成它的绞刑架。\n用户每个月交的订阅费，换来的未必是顶尖效率。\n那笔钱里，相当一部分是在替巨头维护三十年前的旧生态。\n当一个庞然大物把大半算力耗在维持旧包袱和防盗门槛上，一个轻装上阵的现代引擎，只要实现核心工作流，就能在底层性能上把巨人甩开。","category":"科技","score":null,"translated_x_url":null,"translated_status_id":null,"published_at":"2026-08-27 21:12:45","created_at":"2026-08-27 21:12:45","url":"https://mubeitech.com/p/mb-20260827-585bbd","markdown_url":"https://mubeitech.com/p/mb-20260827-585bbd/markdown"},{"rank":2,"id":"mb-20260827-5f4919","account":"mubei","brand":"","title":"在一个 30MB 的程序里，哪怕只改动一行代码","summary":"在一个 30MB 的程序里，哪怕只改动一行代码","body":"在一个 30MB 的程序里，哪怕只改动一行代码。\n整整 4MB 的底层字节全被重新洗了一遍。\n13% 的机器指令、所有的跨函数调用、以及整张函数表，瞬间全部变样。\n如果改动涉及几个功能模块，超过 70% 的字节都会面目全非。\n可你在源码里，明明只是修改了一个字符。\n为什么一个微小的改动，会引发整座二进制大厦的雪崩？\n因为现代编译系统在排布代码时，所有函数都是首尾相连紧密贴合的。\n排在中间的函数稍微变长了几个字节。\n排在它后面的成千上万个函数，在内存里的物理地址全被硬生生往后推了一格。\n每一个跳向这些函数的调用指令。\n每一个跨区域的指针引用。\n全都被链接器重新修改了一遍地址。\n更要命的是 Go 语言的自身机制。\n为了在程序崩溃时能打印出精准的堆栈和行号。\n编译器在程序里塞进了一张庞大的函数元数据表。\n这张表独占了整个程序将近三分之一的体积。\n骨牌一旦倒下，整张表里的几十万个偏移量记录，瞬间全被重写。\n过去二十年里，全世界分发软件更新，用的都是通用的二进制差分工具。\n比如经典的 bsdiff。\n这类工具的底层逻辑。\n是把编译好的可执行文件，当成一串毫无意义的黑盒字节流。\n面对这种雪崩式的地址移位，通用算法根本看不懂发生了什么。\n它只能老老实实把每一个变动过的地址当成全新的数据，打包进补丁文件里。\n结果就是：哪怕只改动一行代码。\n通用压缩工具生成的增量补丁，依然高达 150KB 到 500KB。\n如果是在机房之间分发还好。\n但在弱网环境或者跨国网络中。\n遇到 1% 的网络丢包。\n每多几十 KB 的冗余数据，传输耗时就会从几秒直接飙升到几分钟。\n解开这个死结的钥匙，藏在 Google 早年间做的一个精巧设计里。\n2009 年，Google 遇到了同样的难题。\n为了给全球数亿用户静默推送 Chrome 浏览器更新。\n工程师研发了一套名为 Courgette 的差分算法。\nGoogle 的核心洞见切中了要害：\n可执行文件不是随机生成的噪音，它是由严密的编译器逻辑塑造出来的结构体。\n既然两台机器都知道编译器是怎么工作的。\n为什么要在网络上传输那些本来就能推算出来的地址变化？\nGoogle 的做法很大胆：\n把旧版本和新版本全部反汇编。\n将所有具体的内存地址抹平，换成抽象的符号标签。\n只在纯逻辑层面做差分。\n补丁体积瞬间从几百 KB 砍到了几十 KB。\n而开源项目 go-binsync 把这个思路推到了更深处。\n它甚至不需要做繁琐且容易出错的反汇编。\n因为 Go 语言哪怕剥离了所有调试符号。\n内部依然完整保留着那张结构规整的函数表。\n新旧两个版本的程序一碰头。\n工具直接读取这张函数表，按函数名对齐每一个代码块。\n只要知道哪几个函数变长了。\n接收端直接在本地模拟编译器的排布规则。\n分毫不差地预测出后面每一个函数挪到了什么新地址。\n它根本不需要在网线上传输那几十万处被挪动的指针。\n它只需要传输真正新增的几行机器码，外加一份极短的预测纠偏记录。\n这台机器跑出来的数字相当惊人。\n在一个 30MB 的程序里改动一行代码：\n通用差分工具 bsdiff 生成的补丁是 150,475 字节。\n而采用结构预测编码的补丁，只有 2,262 字节。\n补丁体积瞬间缩小了 67 倍。\n哪怕只是在一个字符串里加了 3 个字节。\n补丁更是直接被压到了 438 个字节。\n在 Prometheus 监控系统的真实版本升级中：\n从 3.13.1 到 3.13.2，面对 94MB 剥离符号后的程序。\n全量压缩下载需要传输 20.6MB。\n通用差分需要 2.69MB。\n而结构预测补丁只有 95KB，体积缩小了整整 28 倍。\n在 20Mbps 带宽加 1% 丢包率的常规网络下。\n全量下载需要 2.4 分钟。\n通用差分需要 15 秒。\n而它只需要 1.0 秒。\n甚至因为省去了构建全文件后缀数组的暴力计算。\n补丁的生成速度反而比传统工具快了三倍。\n过去半个世纪的信息论，习惯把压缩当成纯粹的统计学博弈。\n数据被视作黑盒，算法在字节与概率之间寻找重复的模式。\n可软件从来不是无规律的黑盒。\n最高级的压缩，从来不是在传输通道里寻找统计冗余。\n是把生成端的确定性逻辑，直接变成接收端的推演引擎。\n当通信的两端共享了同一套编译规律。\n物理网络真正需要承载的，就只剩下那些无法被逻辑推演出来的意外。","category":"科技","score":null,"translated_x_url":null,"translated_status_id":null,"published_at":"2026-08-27 22:36:41","created_at":"2026-08-27 22:36:41","url":"https://mubeitech.com/p/mb-20260827-5f4919","markdown_url":"https://mubeitech.com/p/mb-20260827-5f4919/markdown"}]}