太麻烦了，还搞这些。你只需要笔记本连公网，然后随便写个 API ，用 TTS 说出指令，然后电脑旁边放一个小爱同学就可以了，用不着注入啥的，而且批量执行啥的都能搞定。

好像能把之前没加 AC+的设备也加进去，这个很好啊

我建议 API 。mac 性能太低，模型太小不实用，太大跑不动，ram 装得下并发也低，训练也跑不动。除了玩一下子没啥大用。

安全隐私问题先放一放，你不用 AppleID ，你还怎么用 Apple 配件，怎么下 Apple 程序，这些玩意不是绑定 ID 才能用吗，尤其是 AirTag 。

@labdum 哦哦，看掉了，那个横坐标被字幕遮住了...我以为他在做横向对比

他好像在看 WindowServer 的 RAM 占用，怎么说呢...和我使用体验不太符吧，一般屏幕/窗口多了，吃的好像是显存，但是活动监视器里看的是内存，看不到显存占用。如果看他总的 RAM 占用的话，我感觉多少还是能看出一点端倪。

@labdum 见上

你这个视频第一段 m2 max macbook pro(6:31 的时候),接了 4 个全分辨率屏幕的时候,内存就已经从 32G 涨到了 35G 了,这还没开窗口,这四个屏幕要是铺满窗口,占用的内存更多.7 个的时候涨的少点,也有 36G,那怕还是托了 displaylink 和低分辨率的福

你这个视频恰好证明接显示屏真耗内存...其实严格来说是显存,但是现在显存内存一体了嘛

让我说一个暴论：

其实 mac 就是比 Windows 耗内存！
什么“尽可能使用的多一些”“Windows 尽可能少占用些“Linux 内存调度是尽可能吃满””都是扯淡
就是内存小了！
Windows 窗口重绘逻辑是按屏幕的，mac 窗口重绘逻辑是按窗口的
再加上 macOS 用高 DPI 的屏幕人又多，动画特效阴影半透明又多，占用的内存必然大，光接一个 4k 屏幕内存占用就多一个 G

16G 一天到晚有人在说 mac 要吃满，你把内存加到 128G 试试？还不是和 Windows 一样的工作模式，用多少占多少

只是说 mac 做内存压缩做的比较早（ 10.9 就开始了），用 ssd 做虚拟内存载体比较早，部分程度 Cover 了这个缺点而已！

16G 为什么今年作为标配，就是因为 mac 耗内存越来越大，在 8G 内存下连压缩内存+虚拟内存都慢慢不够调度了！什么 AI 都得往后稍一稍

@iceloon 没太听懂。用长 hdmi 线连接，理论上主机可以迁到沙发附近，无论有线无线效果都更好啊

@iceloon 2.4G 的手柄嘛，无线键鼠延迟就小多了，总不能接受得了无线投屏但接受不了无线键鼠/手柄吧

我之前也尝试过串流，用 atv 用采集卡都试过了，都不行。问题在于串流这个动作本身，把 40G 的带宽压缩到 40M ，能做到绝大部分环境不卡已经很了不起了，但惟独玩游戏这种变化复杂的场景根本不行。后来我放弃了，直接牵了一根超长的 hdmi 线。供参考。

40g 的和 10g 的硬盘盒我都试过，随机读写差距很大，估计是走 pcie 和走 usb 协议的区别。如果追求随机读写的话，建议换 40g 的试。

Mac 可以关 sip 不过你搞这么复杂干什么 直接把 qq 音乐设置自启动就可以了

@wyd011011daniel 是 你时间宝贵 有法律效应的隐私协议都没有这种开源有安全感，那我还能说啥。反正对我来说，这种开源我安心不了一点，开源的项目和商店里完全可以是两个不相干的项目。你安心你随意吧...

@wyd011011daniel 我认为至少要是“理论成立”的技术信任链，才是证明。否则就是宣传，说得再好听，也是宣传。尤其是开源。其实完全不开放服务端，只开源客户端，同样是一种开源（这不就是 tg 和以前的 iMessage ），而且是“理论成立”的。客户端可以完成加密工作，密钥交换可以私底下进行。只需要客户端做好端到端加密，服务器做什么都无所谓。用户拿开源的代码一样可以接入到服务器，这才是“理论成立”的信任链。CloudKit 的问题就在于，只有开发者用自己证书签名过的代码，才能运行，而这个步骤开发者做了什么是完全不可知的。当然，这不是说 CloudKit 真有问题。CloudKit 应该是一种帮助开发者“尽到保护隐私责任”的工具，而不是“免除隐私泄露责任”的挡箭牌。保护隐私的责任仍必须在开发者。

当然，像楼主说的，他是“为了减少服务器维护成本”，这当然没问题，而且是好事情。但是一定要和隐私联系上，不太现实。而且这个数据同步的实时性，可能还有点挑战。

@wyd011011daniel 我为什么感觉我和你观点一样但是结论不一样

"只要用户期望使用第三方联网的服务，独立个体用户也不可能审计所有代码并且对开发者的服务器也没有任何审计能力。"
对啊，正因如此，开发者无论用什么技术都无所谓啊，反正用户信任的也是这个 App 。

问题就在于“他宣传 xxx”和“他实际 xxx”不一定是匹配的。开发者无论宣传的多好，都有可能做出额外的行为来泄露隐私，这本来就是无解的，用户只能选择“相信这个 App”或者“不用这个 App”。
至于他用不用 CloudKit...真没那么重要，开发者想传隐私信息，怎么都是能传的。方式有太多种了。
万一他接入了三方统计 SDK ，把数据发给他们了呢？
万一他用 AppLink 或者剪贴板传递隐私信息，实际发起请求的是别的程序呢？
哪怕就把它加密传在崩溃日志里，发给 Apple ，也是可以的啊。
这些需求都是合情合理的啊，防不住的。
更别提不合理的方式了：我检测到抓包我就不传隐私数据，没有抓包我再传。除非你在网络层抓包，那网络层同一个手机那么多 App 请求，谁知道是哪个 App 发出来的？开发者完全可以检测到手机上装了 qq 我再传，然后我还把隐私信息发给腾讯的统计 sdk ，诸如此类。域名看不出来，内容也是加密的，证书可能还做了 ssl pinning 。根本没法防的。

@SingeeKing 而且他们不可能搞真的端到端加密的，相比加密和隐私，他们承担不起“用户忘记唯一的密钥，数据丢失”的风险。我记得苹果 iOS10 还是 11 的时候搞了个 像那么回事的 端到端加密的钥匙串，一旦密码想不起来，他就给你钥匙串全删掉。估计后来因为太多人忘记密码，被人喷狠了，逻辑就改了很多。

@andyzhshg 你说的这个其实就比较像微信小程序，或者 iMessage 里的小插件。完美符合“不存储聊天记录，但是提供额外功能”这一点。甚至不联网。不然，如果你不保存，不拥有聊天记录，只提供额外功能，你完全没必要设计聊天程序本体，承担不必要的责任。

@wyd011011daniel 可以分析一下这个信任链：

1. 开发者开源=>用户可以审计代码
用户会吗？每个用户都审计代码吗？

2. 开发者开源=>用户信任
用户怎么知道，开发者上传到商店的二进制，是开源的代码编译成的二进制？二进制需要签名的，校验哈希都没法用。做 GitHub Actions 自动打包？那先不说可不可行，是不是又引入了一个新的，需要信任的对象呢？

3. 审计
无论什么审计方法，都引入了额外需要信任的对象。而对于终端用户而言，信任的对象越少越好。不然安全性从何而来呢？苹果的 CloudKit 也会用 Azure ，也会用 AWS ，但是苹果没有要求你额外信任这些公司，只是自己承担了责任。


@SingeeKing 我感觉他们很多是想从代码层面证明，这是一个比较 Geek 且可行的想法，但是和现实应用差距很大。

@SingeeKing 他觉得他回复了。实际操作上，用户无法一直抓包检查看开发者是否做了坏事，用户即使抓包了，也无法得知他到底是这时候没传，还是一直没传。用户也没办法单独把这个程序的网络权限给关掉。程序在无网环境其实也无法运行。所以说，他说的只是开发者的角度“理论上”可以这么做。

这从来就不是技术问题，作为开发者本来就应该为程序的隐私背书，也必然是保管隐私的第一责任人。什么技术反而是其次，假设开发者用了“安全”CloudKit ，但是犯了一些代码上的错误，或者错误接入三方 SDK ，导致隐私泄露，这种可能性也是有的，但那也是不行的啊，也不能说“我用 CloudKit 所以我安全”。归根结底，责任人是程序发行商。用户也只会信这个。