能耗比方面:

1, 90% 以上原因是 M1 的台积电 5nm 相对于 9980HK 的 Intel 14nm 的巨大能耗比优势. Intel 2019 年时新制程研发受阻. 目前台积电的先进制程 T0 断崖式领先其他所有代工厂 (三星, Intel, 中芯国际) 一个段位. 那些能耗比好的芯片 (A 系列, M 系列, 8 Elite, 9400, Zen4, etc...) 的共同特点是用了台积电, 那些能耗比差的芯片 (888, 8gen1, Intel 8-11 代酷睿) 的共同特点是没用台积电. M3 和 M4 系列更是都用了台积电 3nm (N3B 和 N3E). 但台积电具有重大地缘政治风险, 由于众所周知的风险, 安全性远不如在美国本土的英特尔.

2, 10% 的原因是 ARM 比 x86 的精简和高效性. 这并非主要原因, X Elite (ARM) 能耗比的菜, 和 Lunar Lake (x86) 能耗比的强, 已经充分证明了指令集并非决定能耗比的关键因素, ARM 也可以很菜, x86 也可以很强. 指令集就像人说的语言, 就道理就像说英文的人不一定比说中文的人更聪明或更笨一样.

纯性能方面:

目前 M 芯片相对于 Intel 和 AMD 的芯片并没有优势, 这点去看 Cinebench 跑分就知道. 如果考虑到价格, 相比 x86 阵营来说, 更是 3 倍左右的劣势 (基础款 4000 vs 12000, Max 款 11000 vs 33000, Mac 加内存和存储更是金子价). 对于非买 MacBook 不可的人来说, 确实 M 系强, 因为最后一代大尺寸 Pro 是 2019 年的 9980HK. 但如果不是非要买 MacBook 的话, 那选择有很多, 因为 M 系是要跟今天的 Intel 和 AMD (还有英伟达独显生态) 去比的, 而不是永远跟 2019 年比.

忙着开发 Project Nimbus 呢, 可能没时间做这个无关紧要的翻译功能.

不如国产平板 +1. 可以去看看 MatePad 11.5 2024 和 Redmi Pad Pro. 现在国产平板也可以开启增强防护模式, 不用担心乱下载/自动下载应用.

价格方面只说一点, 2023 年 9 月 iPad 9 的百亿补贴价格就已经是 2000 了, 现在还要 1700, 是完全不值的.

除非做 iOS / xCode 开发, 有啥是非要 macOS 的. 现在 macOS 咖喱味很重, Windows 现在有 WSL, 终端, 和包管理器也很香.

Google 没有强制力, 要想强制 SDK 提供方, 还能看 iOS 和未来的鸿蒙, 强力管控.

没用的, 一般人是不敢往一个项目上投很多钱的, 给一个项目投本金 5 万的话, 就算 10 倍也才 50 万, 够干嘛的, 还没一年工资高. 投 50 万本金往一个篮子里, 你敢嘛? 现在觉得攒钱还得靠工资.

@honhon 这个 IActivityController 的实际实现者既不在 system_server 进程中 (从 IActivityController$Stub$Proxy 和 BinderProxy 可以看出), 在 AOSP 中也没找到. 应该是一个单独的 signature 权限的 APK, 运行在单独的进程中.

activityStarting() 调到 registerContentObserver() 是否合理要看这个 IActivityController 的具体实现, 可以在系统启动时在 ActivityTaskManagerService.setActivityController() 里面打个断点看看 Binder.getCallingPid() 是哪个 APK.

这个调用栈看上去是运行在 system_server 的 ActivityTaskManagerService 通过 Binder 远程调用到 IActivityController 的实现 APK, IActivityController 的实现代码又通过 Binder 远程调用到 ContentService.registerContentObserver(), 又回到了 system_server.

Android 12 修改了 ActivityTaskManagerService, 缓存了 mTopApp 的值, 从而在调用 ActivityTaskManagerService.getTopApp() 时不再需要获取 WindowManagerGlobalLock:

https://cs.android.com/android/platform/superproject/+/android-12.0.0_r33:frameworks/base/services/core/java/com/android/server/wm/ActivityTaskManagerService.java;bpv=0;bpt=0

相应的 Google Patch:

https://cs.android.com/android/_/android/platform/frameworks/base/+/8f7dd59911eef213c0d1b5db460f6e8114aeeea0

里面明确提到了改动是为了避免锁住 WindowManager.

如果没办法适配 Android 12, 那只能自己做 Patch 把 Android 12 的这部分改动尝试 pick 进 Android 11, 或者去掉 getTopApp() 里的 synchronized 块, 不过这样将不再线程安全.