先硬广一波：RCViewer的开发启动了。虽然不能说是划时代屌炸天的技术和产品，但是对于现有被折磨的人群，我抱着最大的善意启动这一个项目，对于个人版预计全功能终身免费，并且不会做包括广告一类的商业化，只希望跟我一样被折磨的人能够在世界的各个角落，都可以不受限制的、自由的、愉快的访问放在某个场所的设备。底层的传输是在百万级节点的P2P通信网络中验证过的超高码率高性能多径传输技术----这么一说还真的是有点屌炸天了----RCViewer将基于对网络基础设施的有效利用，确保复杂网络也能带来感人的协作体验。

现代码农很难想象上古时代的应用开发模式。想当年，施乐（为什么是施乐？）或者其他什么公司为了开发一款新打印机，硬件方案选型确定后，施乐将不得不从最底层的MCU微码开始，构建驱动，构建系统，最后才到打印机业务，这个过程实在是很感人，所以上古时代的计算机公司都是全产业链公司，他们具有实现一切的能力。他们不得不如此，半导体方兴未艾，通用芯片尚未萌芽，一个新业务的开展，伴随的是一系列从芯片、存储器、通信等器件的重新设计。彼时标准尚缺，每一颗新芯片都可能带来一个新的体系架构。早年的穿孔纸带应用在不同体系架构的使用体验当然是感人的，然而即便是在不那么蛮荒的年代，将代码翻译成机器成看懂的二进制串也不是一件简单的事情。所以一个新设备的出现，并不是组装了一台机器，而是生产了一颗新的芯片，诞生了新的体系架构，开发了针对该体系架构的编译器，开发了多任务系统，驱动，和应用。你看，所有的东西都完成了，应用才能开始开发。

可是这么做就太太太低效了，所以软件先驱抽象出了硬件隔离层，抽象出了系统层，抽象出了中间件，甚至弄出了让现代码农完全无需了解软件制作机理的IDE----我对强大的IDE对于工程师的作用一直持否定态度----现代码农的所谓开发应用，就是打开IDE，写下int main() { printf("hello world!"); }，然后鼠标点下三角形的运行按钮。然而IDE告诉他：printf未定义，他只能一脸懵逼的看着IDE，骂道：这IDE真不好用。所以当我们说到应用框架的时候，其中其实蕴含了整个计算机体系发展过程中不断抽象，不断分层，不断分工细化带来的社会效率的提升。裸系统上当我们要去开发一个图形窗口应用，应用需要自己操作显示器件，在指定区域更新内存，刷新出一个新的button。在成熟的应用框架上，你甚至不需要了解你的控件最终将被composite在哪里，你只需要拖动控件，调整属性即可。但作为现代工程师，失去了了解系统在做什么的机会，最终沦为996的码兽，比起上古时代的先驱来说，实在是幸福感缺缺啊。

可是应用框架终究能够带来效率的提升，怎么选择应用框架就成了最应该考虑清楚的事情，否则很快的选了，用到一般发现选错了，这简直不是不幸福能够形容的。以RCViewer来说，应用框架的选择经历了三个阶段，然而并不能保证现在的选择一定完美，只是现在的选择能满足我对系统需要的能力，实现的工作量也可以接受。

第一个阶段是一脸懵逼的阶段。早期开始RCViewer开发的时候，因为要以代理模式来处理多径传输和纠错，我天真的认为nodejs能够满足编解码和数据共享的需求（性能和便捷性），所以我选用electron作为应用框架。如果只是做一个业务型的应用，electron一定是不错的选择，异步，跨平台，自带浏览器内核，免费，组件丰富，不要太完美。然而硬伤是多任务能力和数据共享，对于cpu密集型的任务，实现难度大，性能差，不要说达到200ms的屏幕延迟，能做到3秒以内，我就应该很佩服我自己了。所以我最终放弃了electron和nodejs。

第二个阶段是自认为可以掌控全局的阶段。经历了electron的挫败后，我开始重新寻找一个既简单又能跨平台且能力强大的方案。golang是性能强大的服务端语言，RCViewer在客户端需要实现部分服务端的功能，我想何不在golang上搭一层浏览器的皮，借助浏览器的能力做前端，golang实现需要的cpu密集型任务，再结合便捷强大的vue，简直太完美了。所以我在这个方案上实现了基础的信令、网络、UI操作原型，然后始料未及的是，不做深度定制的浏览器内核对于超低延时视频的支持实在是不够强大，空有ffmpeg这么强大的武器，在浏览器上却是无能为力。再一次的挫败让我知道对于RCViewer的技术方向和局限在哪里。

我最终选择了QT。所以，对于应用框架选择，如果是业务型应用，所有浏览器引擎作为内核的框架都可以选择，然而如果涉及到底层深度优化，浏览器实在是不太能提供足够的支持能力。