@droppedbytech 其实我也不太确定一些细节对不对，因为没有看过内核源码……

@wuqiangroy 其实已经出现因为内存不足而影响性能的情况了
苹果的文档： https://support.apple.com/zh-cn/guide/activity-monitor/actmntr1004/mac

截图的数据解读如下：
整台电脑一共有 8GB 的物理内存
被使用的部分为：
作为支持程序运行的部分：7.01 GB
作为缓存，以提升程序或者文件的访问速度的部分：956.4 MB ÷ 1024 = 0.93 GB
实际剩余的物理内存大小：8 - 7.01 - 0.93 = 0.06 GB

在 7.01GB 的数据中，有 3.37GB 是不能直接访问的，而是被压缩的。
内存压缩是什么：由于在 SSD 上使用交换文件的性能比较低，因此，可以在内存上开辟交换空间来提升系统的响应速度。数据存储进去之前需要进行压缩，读取之前需要解压缩，并放在苹果所说的“App 内存”区域，才能被程序使用。
这样做可以在比较小的内存下获得比较不错的性能。Windows 和 Linux 都支持这样的技术。

对于大多数程序和文本数据，可以压缩到原本的 1/3 大小，因此，其中包含的内存数据解压缩之后约有 3.37 × 3 = 10.11GB 。

如果你有用过内存超级大的 Mac 机，会发现“被压缩”部分的内存很少，甚至是 0 。因为内存负载还没有达到换页的阈值，系统只会直接使用物理内存。压缩和解压需要消耗 CPU 资源。

剩下 7.01 - 3.37 = 3.64 GB 可供系统和应用程序使用
其中包含了被苹果称为“联动内存”的数据，有 1.57 GB ，即“无论如何都无法放到交换中，只能保留在物理内存里的数据”。一般都是系统的核心进程数据，显存，或者硬件虚拟化使用的内存空间。
注：上面所述的交换包含两部分，一部分在硬盘文件里，另一部分压缩后保存在内存上。“联动内存”无法被换页到这些地方。

最后真正能被程序使用的部分，只有物理内存上面的 1.54 GB 那么大。
而且实际上这部分空间已经不能再增长了，如果想增长，有两个方法：
1. 放弃文件缓存，这可能会导致非常糟糕的硬盘 IO 性能，使系统卡顿更加严重。
2. 把“被压缩”部分展开到 10.11GB ，并且写到交换文件里。这样就腾出了 3.37 GB 可供使用。这会使得系统发生缺页中断时，换页的效率更低，因为从 SSD 中读写数据比在内存中压缩 /解压缩要慢。
对于第 2 点，若腾出的内存空间不足以减少换页的频率，同样会使得系统卡顿更加严重。

有两种情况：
1. 如果程序要访问的内存在很长一段时间里都比较固定，并且大小只有 4GB 左右，这么做就有正面的影响。
2. 如果各种程序都频繁访问交换中的任意内存数据，那么保持现状才能获得较好的性能。

macOS 提供了一个指标来更好地衡量目前的换页情况，即“内存压力”。当系统的内存不足并且又频繁发生缺页中断时，“内存压力”的数值就会上升。在截图里，“内存压力”的数值已经超过了一半以上，说明目前各种程序都在频繁地访问交换中不同区域的内存数据。因此对应情况 2 。

由于内存过小，已经影响了系统性能。

根据这张图，也可以估算出多大的内存才能完全不影响系统性能。
目前物理内存中没有被压缩的数据占据了 1.54 + 1.57 + 0.93 = 4.04 GB
压缩的部分要计算解压缩后的大小，即 3.37 × 3 = 10.11 GB
硬盘中有 1.48GB 的交换文件
所以实际内存需求一共有 4.04 + 10.11 + 1.48 = 15.63 GB

只要 16 GB 的内存就可以满足当前的使用场景，而不会感受到因内存导致的性能问题。当然，无法解决因为软件 bug 导致的卡顿。

@xooass M1 刚发布的时候确实有很多帖子中有不少用户在说“8GB 等效于 16GB”。当然，也有人指出了问题，得到的回复大多是“不卡就行，没必要关心这么多，macOS/M1 的机制不一样”。

随后就冒出不少抱怨“SSD 写入量过大”的帖子了。
再往后才是“8GB 不够用”的时代……

swapfile 读写太过频繁，而且没有可用的内存空间，这会导致硬盘 IO 性能显著降低。
如果内存充足，除了不会发生缺页中断，内存读写速度都更快以外，还有一个额外的好处是空闲内存可以缓存磁盘文件。

@Ayersneo iPhone 13 刚发售的时候就有人讨论了屏闪的问题……
还有不少人说“心理作用”
其实是真的伤眼

@goodhellonice 我正在用 iPhone SE 2020 。
推荐等后面天玑 8100 SoC 的手机出来之后再看看，高通这两年的 SoC 不太行。
当然联发科处理器的第三方 ROM 适配会比较少。如果有这方面的需求，而且想现在就买的话，可以考虑红米 K40 ，有很丰富的第三方 ROM 可选。

不是很好用，原因如下：
1. 返回逻辑混乱。如果不熟悉各种软件界面怎么返回，那么返回操作就变成了一个有随机概率失败的操作；
2. 系统的返回手势只能从屏幕最左侧返回，部分应用自己实现了可以从中间侧滑返回。因此，大多数时候需要把手够到最左侧，手感很差；
3. 信号差。不是界面显示的问题，是在某些地方上不了网的问题；
4. 本地化不完善。系统日历没有放假安排，通讯录找联系人不方便，不支持直接在拨号键盘输入首字母找联系人，而通讯录也不能用拼音每个字的首字母搜索，需要准确输入姓名；
5. 系统不支持通话录音，需要借助能录音的耳机来录音；
6. 因为散热设计的原因，尽管 SoC 性能非常强，但游戏体验依然较差，只有前几分钟有不错的体验，之后降频掉帧降低亮度；
7. 国内的手机号使用微信不支持 Callkit ，因此接微信电话的体验变差了，需要点开通知，而且静音状态下无任何提醒；
8. APNS 的及时性和到达率不佳，经常错过微信消息提醒和微信电话。所谓的“微信不提醒”；
9. 系统通知不支持分类，因此不能针对不同类型的通知设置接收 /不接收以及是否使用声音和震动提醒。只能全部都接受或者全部不接收。总体来看，收到的垃圾信息更多了；
10. 也是通知相关的问题。在静音模式下，无法像 Android 一样让某些重要应用无视静音状态，发出通知提示。为了避免错过消息，此时只能关闭静音模式；
11. 长截图不方便，需要借助第三方应用和屏幕录像，操作繁琐；
12. 不支持复制门禁卡，出门需要多带几张卡；
13. 内存小，杀后台严重。有时候需要在微信小程序里填写一些信息并上传照片，切到相机拍照，再切回来发现微信已经重启了，之前填写的信息丢失了；
14. 相关配件价格普遍更加昂贵，使用 Android 设备则可以花更少的钱满足需求；
15. 一些应用的内购价格会更贵，只能用电脑或者 Android 设备来绕过；
16. “APP 资源库”的交互体验不佳，不能代替 Android 的应用抽屉。它需要划动桌面到最后一页才能进入，而且还会自动分组，有些应用猜不到放在哪个分组中。需要点击搜索框才能使用首字母查找应用；
17. 充电速度慢，使用习惯又改回去了。

其他一些可能因人而异的地方：
1. 少了一些比较小众的软件，当然相应地，也多出了一些独占软件。例如，Android 上我使用的 Xmp Mod Player 和 ZXTune ，在 iOS 上无任何替代品。modizer 这款软件是同类软件，但存在严重 bug ；
2. 应用安装管控更严格，一些应用（例如滴滴出行）如果从未下载过，就没有办法下载了；
3. 文件管理不方便。每个应用的存储空间是隔离的。有时将应用更新到新版本，可能会因为新的 bug 而闪退。这时候恰好出门在外，手头没有电脑，应用又没有适配 iOS 的文件管理应用，则完全没有办法访问应用内的文件。如果是 Android ，此时还可以手动从 Android/data 目录中复制出来；
4. iOS 上任何第三方应用的 WebView 只能使用 Safari 内核，有时候浏览一些页面会出现莫名其妙的 bug ，然而没有任何办法；
5. 浏览器上传文件时可选的文件来源有限。从 QQ 或者微信上接收到的文件，如果不是媒体文件，则不能在 Safari 里上传到其他网站；
6. 支持的音视频格式更少，有时候在 QQ 上接收到的音视频不能直接预览；
7. 不能使用类似于“自动跳过”这样的应用来跳过许多 APP 的开屏广告；
8. 滚动的体验很差，很难做到像 Android 一样的高速滚动。我的音乐播放列表就非常长，滚动起来得花不少时间。

以前 Finder 没有合并文件夹的功能，我在 AppStore 上找了个叫做“Commander One”的软件作为替代。

其实问题的根源在于 macOS 安装应用程序的方式。应用程序包实际上是.app 结尾的文件夹，每次手动更新都是把新版本拖拽进去顶替旧版本。对应的操作就是把旧目录删掉，再把新的目录放进去。

另外，Finder 这个人机交互确实反人类……
给没有用过旧版本 MacOSX 用户说一下，实际上你看到的是：
该位置已经存在名称为“……”的较旧项目，您要用正在移动的新项目替换它吗？ [停止] [替换]
没有关于“合并”的功能介绍，因此大多数人并不知道 [替换] 是什么样的行为。

情况 1:
如果你没有看过项目 A 的代码，只是看过项目 A 的接口，自己写出它的实现，那么这个情况和微软 WSL 1 类似，而 WSL 是闭源的。
情况 2：
所有的自由软件许可协议都基于版权。一般来说，版权保护的并不是“创意”之类的东西，而是作品里的原始内容。
对于这种情况，如果不使用项目 A 的代码，则不需要遵守 BSD 协议。
当然，不同的国家和地区，相关的法律会有一些差异。
有些地方的法律规定对某种类型的作品构成侵权与否，都有明确的规定。而有些地方没有，只是“由专业机构鉴定”。只要在当地法律中没有被判定为侵犯版权 /著作权的情况，则认定另一个项目和项目 A 本身无关。

只考虑问题本身，答案就是：
任何许可协议，无论自由与否，都无法保护你的创意。

iPhone 12 以后的 iPhone 在这方面已经无敌了……
如果不想破坏手机，只能把手机放进信号屏蔽袋中才能阻止手机定位。

大多数手机处于拿不到数据但可以使用的情况
解锁 BL 都会触发清空 Data 分区
有些比较新的手机可能仍然有漏洞，足够不解锁获取数据：
https://www.xda-developers.com/oneplus-nord-2-vulnerability-root-shell/

大多数 MTK 设备都可以秒解 BL ，因为这个漏洞：
https://forum.xda-developers.com/t/mod-dev-mediatek-mtk-auth-bypass-sla-daa-utility.4232377/

@bkmi 它的代码里校验了证书链，没法在劫持 HTTPS 请求的情况下让它走完整个流程……
上报的数据估计都是加密后的一些本机硬件信息和其他可能用来识别设备的信息，如果当场卸载重装那肯定不怎么会变。

但它的宣传是用于反作弊 /风控用的，这意味着只需要做到能检测出黑产刷单薅羊毛的行为就算达到目的了。
也许旧版本 Android/iOS 上限制不够严格，可信 ID 还能做到准确标识一台设备。
如果是目前的版本，根据各种“不那么唯一”的信息，综合起来确实能够在一定程度上区分设备。然而问题在于：
1. 不能确保不同的设备拿到的 ID 也一定不同，可能有一定的碰撞概率（至少要比广告 ID 的碰撞概率高，毕竟它主要用于识别相同设备，同时还没法拿到真正的设备唯一 ID ，只能靠其他数据来猜）；
2. 对于同一台设备，在不同时间地点，用户做了许多操作（清理垃圾，更换 SIM 卡，升级系统版本，跌落，部分硬件老化或故障），然后重装了应用，得到的新的可信 ID 有可能会发生变化。

一个可靠的用来跟踪用户设备的 ID ，应该是能避免上述两种问题的。我公司的内部 APP 可能也接入了类似的东西。自从我最近换了手机，升级到 Android 12 并折腾好各种权限之后，信息部时不时给我打电话说我打卡记录异常，检测到我使用另一个同事的手机打卡，是不是有代打卡的行为……我说没有，对方说建议我重装一下应用。
我猜测他们很可能把这类东西当作真正的设备跟踪 ID 来用，然后误报了。

如果应用场景仅仅是反作弊 /风险检测而不是广告跟踪，只要能大幅增加黑产的操作成本就能达到效果了。
那技术应该都在检测设备有没有安装 xposed/越狱 /处于调试模式 /是虚拟机 /APP 被篡改，以及自身的协议和库的反破解上。

@ysc3839 自动清理那些玩意有个好办法：
https://www.coolapk.com/feed/25908320?shareKey=NTA2YjY3Y2YwOTllNjIxYjZiODA~

@bkmi 广告的原文是这么说的：

可信 ID 3.0 成功迭代上线，数字联盟研发了弱特征归因技术，弱特征指的是单一或者组合无法识别设备唯一性的特征，比如电量、屏幕亮度等，在弱特征归因的过程中，多维度采集环境和设备层中隐私敏感度不高的信息，利用长期积累的环境数据，与设备行为数据的拟合，通过深度机器学习与严密的算法，为设备颁发准确唯一的设备 ID 。

听起来就不太可靠……

@bkmi 我去了解了一下“数字联盟可信 ID”，但没找到相关技术资料。找到的大多数是其产品的广告宣传，在广告中吹嘘得神乎其神。
我倾向于它其实不能保证获取到的 ID 可靠且不可变，只是会额外做一些检查，判断运行环境是否存在作弊。
如果可以，希望能稍微讲讲它是如何在权限限制下保证 ID 不可变的。

看到有人说 Siri 保护隐私，我想起了这新闻：
http://society.people.com.cn/n1/2019/0902/c428181-31332431.html
对此，苹果的回应：
https://www.apple.com.cn/newsroom/2019/08/improving-siris-privacy-protections/

@ochatokori 试过一圈手机，只有小米手机能解锁 BL 之后用微信指纹……
或许其他手机解锁 BL 之后会清空某个分区，或者删除某些数据，或者改变某些开关

@timpaik 这个问题的根本原因在于 HEVC Advance 专利池伸手太黑，导致几乎没有浏览器厂商愿意支付专利费。
若 H265 全面铺开，对许多小厂商的来说反而是一种不公平的对待。它们付不起专利费，从而使得这些厂商的浏览器，比起财大气粗的厂商，在播放视频时更加耗电。
另一方面是苹果不乐意支持那些免费的编码格式（自己的硬件和自己写的显卡驱动不提供支持)，使得苹果用户反而更倾向于 H265 这种格式。
当然因为许多流媒体服务提供了 AV1 编码（之前 VP9 也就 YouTube 用），苹果还是在 M1 上给了 AV1 支持。不过这玩意还是有 bug ，safari 看 YouTube 开 HDR 有时候会 Kernel Panic……

其实我更希望免专利费的编码格式能普及，而不是 H265 这种。