@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 块, 不过这样将不再线程安全.

@okakuyang 芯片是台积电的功劳啊, 东南方向大事发生, 台积电被美国"毁台计划"炸了, 苹果还能生产一片 A 芯片和 M 芯片? 而且领先一年从何说起, 最多暂时领先 2 个月. 极客湾的评测是跟上代安卓旗舰芯片去比的, 上代安卓还在用 N4P 工艺, 今年 8gen4 和 9400 也会用 N3E, 泄露跑分都比 A18 Pro 高很多.

不会使用 N2, 而是会使用 N3P. 最快是 A20 Pro 用上 N2. 其实不用太纠结 N2 还是 N3, 现在半导体制程基本到头了, 不但两个工艺节点之间的时间明显变长, 而且两个工艺节点之间的能效提升 (同功耗的性能提升, 或同性能的功耗下降) 也明显变小了.

钟文泽的视频已经被实锤造假了: https://www.zhihu.com/question/667397781

仅限 4060 来说确实是这样, 这是因为台式机 4060 跟笔记本 4060 同规格, 又因为 4060 规模小, 120W 左右就能喂饱, 所以笔记本比台式机散热差也不会影响性能释放.

但 4070 以上就完全是另一个故事了, 4070 以上的笔记本显卡不但规模比同型号名称的台式机小很多, 而且价格也要贵很多. 而且如果不排斥 A 卡的话 (别问为什么喜欢 A 卡, 问就是不喜欢黄狗, 问就是没钱), 更有 6750 GRE 这种 4060 价格, 4060 Ti 性能的东西可选, 这都是只在台式机上的.

Android 看多大的项目了, 我搞编译时间 15-20 分钟那种的项目, 48GB 内存都紧张, 主要还是 Java 虚拟机太吃内存了, 比不上 Xcode LLVM 原生编译.

孟加拉就是日本, 日本就是孟加拉, 看看它们的国旗就知道 2333

Xcode AI 功能锁国行 Mac 硬件不能用吧