@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