@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 、显卡、网卡等。这个就看具体设备的驱动是否有缺陷、是否经过完备的测试了。

天气软件最重要的还是数据源和准确度吧。

当地气象局：应用商店搜 xx （城市名）+ 气象。特点：第一手信息，天气实况最为及时；

中国气象局公共气象服务中心：中国天气网、MSN 天气。特点：国家官方，较为权威；

国家气象信息中心：气象实况 METEO LIVE 小程序。特点：国家官方，信息较为专业丰富。

AccuWeather （华风爱科合作）：中国天气 App 。特点：使用 AccuWeather 技术，相对准确；

墨迹风云：墨迹天气 App 、小米天气 App 。特点：服务时间长的商业产品，较为稳定；

彩云科技：彩云天气 App 。特点：自研 AI 模型预测，较为准确。

莉景科技：莉景天气 App 。特点：侧重气象对自然摄影和天文摄影的影响，提供云量、霞、雾凇预测服务。

其他来源：Open Weather 、Weather Channel 、AccuWeather 、Flowx 、天文通、晴天钟…… 一般都是 NCEP GFS 之类的通用国际气象模型，看看就行了。


可能整理有误，烦请指正。

AnyType 理念先进得多，还是去中心化+加密。可以了解一下。