其实就是开发水平达不到，开发精力全用来适配各种网盘播放器了。这种底层功能，用户感知不强，但是对开发人员要求很高，一旦数据损坏厂商风险也高。自然优先级就延后了。

@miniliuke 照片存哪都会丢 存 iCloud 会被删 本地文件也会坏 只能说多存几份

用过 不靠谱 会丢 尤其是代码 别用

太麻烦了，还搞这些。你只需要笔记本连公网，然后随便写个 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 线连接，理论上主机可以迁到沙发附近，无论有线无线效果都更好啊

我之前也尝试过串流，用 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 。根本没法防的。