VSCode 应该有端口映射功能。你把本地的代理端口映射过去就好了。

ssh 命令行也可以，开个 ssh -R <远程端口>:127.0.0.1:<本地端口> <主机 IP> 命令即可。

要完全无感自动化的话，ssh_config 估计也支持添加额外选项，可以看一下它的文档。

@othercat #9

> 大概判断出如果不用这些协议，使用其他 SSDP 到底是自己造轮子方便，还是借鉴代码方便了吧

你的逻辑我似乎没理解。要实现一个协议，除了「造轮子」和「借鉴代码」，还有一个选项是「调库」。我最后提的是调库最方便。

另外，我再强调一次：这不是重点…… 以下讨论我们就按你的来，默认全部是他自己写的好了。

> cocoapods 包这些东西，核心在这里

核心多半不在这里，网络请求 API 在 Dart Runtime 本身就有，为什么要依赖三方库？

> 在 cocoapods 里面实现的

我对比了 LocalSend 和 AirClap 的依赖原生库（即你说的 cocapods 依赖库）。很遗憾，所有库我都用过，并没有哪个和 UDP 有特别的关系。你列出的几个都是获取平台信息的，比如 WiFi 名称、5G 情况、检查是否联网等。

其次明确一点，这里不是他的依赖库列表，充其量是个子集。你可以再看看 Flutter packages 依赖进入打包的过程。

@othercat #5

> 认为有规范的人都可以写的相似

所有文件名都相似的概率太低了。我是 Flutter 开发者，我很清楚至少在列出的那些文件名上，并没有听说过什么「规范」。

> 主程序说老实话，只有 UI ，因为协议层都不在这里

协议层可以就在这里。请不要把 Flutter 当成 HTML 那样的前端标记语言，它没有什么「主程序」、「前端」、「后端」的概念，编写一个操作系统模拟器都不在话下，实现一个网络协议还是非常容易的。

例如，LocalSend 的协议实现就是纯 Dart 编写的。

> 协议层面自己造轮子实现，如果用 LocalSend 的代码二次开发

「二次开发」的意思你可能弄错了。并不是必须全部代码照搬，自己一行都不写，然后改两行加上「 VIP 充值」按钮才叫「二次开发」，理论上借鉴（即：再演绎）任何代码全都是「二次开发」。既然是二次开发，就必须遵守协议。

再强调一次：关心的重点不是「抄不抄袭」，抄袭本来就是一个感情用事的词语。

@w568w 注：第一句没有说楼主故意混淆视听的意思。

大家关心的问题不在于「抄没抄」，而是「遵没遵守协议」。不要打烟雾弹。

LocalSend 使用的 MIT 协议本来就是允许抄、欢迎抄的。退一万步说，就算他抄了，抄袭不可耻，闭源也不可耻，盈利更没有违反任何协议，完全是他的营销本事。

现在的关键是：他是否基于 LocalSend 代码二次开发，以及是否履行 MIT 协议。

其项目源代码结构被逆向工程发现和 LocalSend 的目录结构、文件名完全一致，这基本确定是基于 LocalSend 源代码。然而其三番五次声称自己和 LocalSend 「没有任何关系」，也没有看到任何协议标注和版权署名，这才是问题所在。

至于核心代码如何变化，我想这并非目前的重点。SSDP Flutter 方面的库也很多很成熟了，LocalSend 的 Provider 架构写得很好，加个协议只是复制粘贴的时间。

回声：

从 @LuLiangDev 的 GitHub 主页 [1] 可以看到其昨天向 Gentleflow/Airclap 和 lex-1919/airclap-landingpage 各提交了一次 commit 。然而，分别点进去后发现这两个仓库最后提交时间均为两天前，昨天并没有提交 [2]，推测其昨天看到消息后回滚了最后一次 commit 并 force-push 。

目前，其在 GitHub 可查到的最后一次活动是 6 月 23 日 12：03 ，向 lex-1919/airclap-landingpage 提交了 Pull Request [3]，该仓库目前禁止非协作者评论。

在 V2EX 和 Airclap 反馈平台最后活动都是一天前 [4, 5]。官方 Discord 目前仍在活跃（收割）中。

[1] https://github.com/LiangLuDev?tab=overview&from=2024-05-01&to=2024-05-31
[2] https://github.com/lex-1919/airclap-landingpage/commits?author=LiangLuDev&since=2024-06-24&until=2024-06-25
[3] https://github.com/lex-1919/airclap-landingpage/pull/1
[4] https://www.v2ex.com/member/LuLiangDev
[5] https://airclap.canny.io/feedback/p/ios-transfers-dont-work

@dragondove 是的，所以微软的成功很大程度上不是因为（像 macOS 那样）关注体验，而是人海战术：用户越多，其中有能力为自己需求编写程序的用户（专家用户）就越多。对一个用户的任意需求，发现已经有人找到/制作了解决方案的可能性就越高。这方面 Windows 反而像 Linux 。macOS 才是纯靠苹果堆用户体验堆出来的市场认可度，完全封闭。

Linux 在极少的用户基数下还能取得目前的成功，是靠专家用户的占比远超其他系统的事实。

@w568w #33 https://github.com/Gentleflow/Airclap/issues/5 已 post 。

@zaidawesterfield 这基本可以确定了，看看 @LuLiangDev 怎么辩解吧。哪有源码目录结构都一样的。

你的要求反了。proot 已经在桌面端用了很多年了，termux 才是「来者」。

我推荐几个替换方案：

- Docker：udocker ，支持 proot 作为后端，可以直接跑一些对系统要求不高的镜像（例如 ubuntu 、debian ）；
- apt：nix-portable ，单文件、无需 root 权限安装 Nix Packages （目前数量最大的包仓库）。可以用来装普通应用，也是基于 proot 类似的技术；
- ArchLinux：junest ，也有 proot 模式；

如果你富有挑战精神的话，还有 Gentoo Prefix 可以研究。

https://wiki.gentoo.org/wiki/Project:Prefix/Use_cases

再多嘴一句，（ LocalSend 的）这些库确实都是 Flutter must-use 的库。你随便找个正经功能的应用，基本都会有。说服力不强。

@w568w #23

Flutter 逆向难度很大，完全是混淆过的原生代码，而且每代 Dart Compiler 都在变化。想逆向实锤恐怕还要再等等。我也没 Apple 和 Windows 设备，就不掺和了。

一个思路：可以用 Wiresharks 抓包，从广播报文和收发数据报文结构来对比。Plist 的描述信息相同确实问题不大，我做 Flutter 开发又不熟悉 Apple 系的配置的话，确实可能会找一个类似的应用把他的描述复制过来。

开发者能出来自证是最好的，当然他没有举证的义务。实锤之前，别急着上有色眼镜……

@sucaiking #9 imgur 可能把你 block 了。换个节点试试

开源的另一层意思是：本质上没有人为你的体验负责，你需要为自己负责；因为你有查看、修改所有东西的自由，你也要为之付出代价。

如果一个发行版什么都不需要用户做就能满足大多数人需求，它必定是高度耦合的、定制化的、难以修改的。例如 Ubuntu 等，macOS 也算一个这样的系统。Windows 则是因为用户基数太大了，前人栽树后人乘凉。

如果你连「安装桌面主题」「下很多插件」的时间成本都难以负担，也不能接受 Ubuntu 的极少「小 bug 」（相对其他发行版来说真的很少了），并且没有动力去付出学习新知识的成本，那么我觉得 Linux 并不适合你。还是老老实实用原来的系统吧。

先纠正 1 楼的回答。

> 久了卡应该是常驻的应用被优先安排到了虚拟内存

「虚拟内存」是指「用户进程不能访问真实物理内存地址，只能看到分给自己的内存映射」，是操作系统的一种设计。你指的应该是「交换空间」/「页面文件」这种技术。

在 SSD 上，一般应用（如 QQ 、微信）换入/换出交换空间只需不到 200 毫秒时间，和楼主说的「十几天」的跨度应该对不上。

> 久了后还是会被移动到虚拟内存里

操作系统一般不会闲着没事把软件移动到交换空间里，最多在闲时进行内存压缩。但这也不影响性能。

----

然后回答楼主的问题。对系统流畅度造成压力的一般就是 CPU 、内存和 I/O 三大部件。先说结论：最可能出问题的是内存。

1. CPU：随着运行时间增长，一些设计不良的软件更可能进入一些错误状态（例如某软件每小时发生一次并发访问，而开发者根本没考虑并发问题。随着运行时间增长，程序越来越可能发生死锁或死循环）。然而这样的情况少之又少，一般来说异常的进程会直接占满 CPU ，很容易被察觉。

楼主说的「占用接近 100% 的 cpu 」「所有软件 cpu 没怎么占用(10%)」，我猜是指看到的瞬时占用。这个数值没多大意义，和卡顿与否无关，需要取一段时间的平均值。可参考 Linux 上的 load 。

2. 内存：类似的，一些设计不良的软件可能发生内存泄露（微软自己的 explorer.exe 和 dwm.exe 到今天还会偶发内存泄漏问题，更不要说一般开发者了），这是最主要的原因。内存泄漏将持续增加资源占用，最终触发内存交换，拖慢系统速度。

这里比较重要的指标可能是提交总量，75% 应该是物理内存的实际占用，大量交换可能已经发生了。

3. I/O：主要是 SSD 、显卡、网卡等。这个就看具体设备的驱动是否有缺陷、是否经过完备的测试了。