前端实现桌面远程（一）

---

---

前言

曾经有人说过，能用JavaScript实现的东西，最终大多都会用JavaScript实现；

一直有个想法，想完成一个通网页来实现桌面远程控制的玩意，要实现桌面远程控制，需要满足2个基本条件。
（1）要有被控制桌面的画面；
（2）控制键鼠操作；

作为一个全栈工程师，目前掌握的技能有js、node.js以及golang，结合目前我所掌握的技能，我能想到的方法只有2种：

1.客户端通过webrtc传送桌面视频流；

2.客户端通过截屏传送图片；

以上两种方案都需要有一个桌面应用程序的客户端，作为前端工程师，不得不使用到Electron.js来完成

---

一、需要的条件？

1.桌面客户端（负责将桌面的画面传送出去，并且等待接收控制指令）

2.服务器（负责转发各种操作）

3.控制端（接收画面，并发出控制指令）

技术条件

(1)：桌面客户端可以通过Electron.js来实现桌面应用程序，它内含node.js，桌面画面可通过webrtc获取桌面流或者通过screenshot-desktop库来截取图片，控制键鼠可以通过 robot-js等库来实现

(2)：服务器可用node.js、golang实现，本人比较喜欢用go

(3)：控制端可直接使用前端完成，在canvas上完成

(4)：通信上，需要实时性，使用webscoket

二、方案对比

1.webrtc视频流

第一种webrtc视频流方案我曾经也试过，但感觉这种流不可控因素太多，需要点对点建立连接，当多人同时连时效果不太理想；

2.截屏传送

第二种截屏传送的方案是最近想的，网上查阅的资料，大多数人的做法都是直接截图，获取base64的图片数据，然后直接发送给控制端，控制端直接通过img标签绑定实时传过来的图片数据显示即可。

弊端：
但我觉得这种直接传送的桌面截屏数据量挺大的，一张图片就2m，而且为了流畅，截屏的频率会比较快，这样的话，传送的数据量会很大，网络带宽会顶不住。

优化：
但其实一般来说，每次截屏桌面的画面与上一次截屏画面大部分是相同，只有小部分画面发生变化，如果可以只发送发生改变部分的数据，这样应该可以减少很多数据量的传送，降低带宽的负担。

---

总结

以上的2个方案中，从可行性以及实现效果来看，我个人觉得方案2更占有优势，目前方案2的主要难点在于需要识别出这次截图与上次截图的不同的区域。

在后续的文章中将实现方案2中的内容