荣耀500 Pro MOLLY震撼登场！最新消息速览
|
亲历现场。那天下午三点十七分，我盯着编译窗口卡在 dexmerge 的最后一行，光标一动不动，窗外洒水车刚好碾过小区东门减速带，哗啦——滋——哗啦——滋——，像给这破编译配了个循环采样音效。王工蹲在工位隔断底下换网线，说荣耀那版系统里某个隐藏的 dex2oat 策略变了，但没给文档，只甩了句“你们自己扒”。我信了，真去扒了，扒了十八秒后发现是 build.gradle 里一个 deprecated 的 packagingOptions 配置被新 aapt2 当成 fatal error 处理——可这玩意儿上个月还在跑，连个 warning 都没亮。 桌上机械键盘青轴敲得啪啪响，不是我在敲，是坐我斜后方的外包同事小陈，他正狂按回车刷 gradle daemon 进程列表，想 kill 掉某个残留的 3.5.1 版本 daemon。我原以为是 gradle 版本冲突，结果翻日志才发现，根本不是 daemon 的事，是 MOLLY 启动时偷偷调了两次 ActivityManager.getService()，第二次调用直接 trigger 了那版系统里新增的 Binder 引用计数校验，返回 null —— 而我们那个 launcher Activity 的 onNewIntent() 里还硬 dereference 了它。这个我敢打包票，Logcat 里 dump 出来的 binder node address 对得上，地址末尾两个字节全零，就是空指针前夜的标准胎记。 楼下便利店关东煮炉子咕嘟着，我下去买了根竹轮，回来时测试妹子小杨已经把六台测试机全摆窗台上了，MOLLY、X100、Find X8、Mate 60 Pro+、Redmi K70、还有台早该退役的 NEX 3S。阳光晒得机背发烫，尤其那台 MOLLY，银色中框反光刺眼，她一边擦屏幕一边念叨：“这壳子抗刮是真抗刮，昨天我拿钥匙划了三道，光看不出来。”我说你划的是膜吧？她摇头，掏出那台机子翻过来给我看摄像头环——确实没划痕，连镀膜层都没崩。可就在这会儿，MOLLY 第四次启动崩溃弹出的 Toast 闪了一下，“优胜劣汰”四个字刚显出来半秒，就黑屏重启了。真就半秒，连截屏都来不及按。 而更离谱的是，同一套 APK，在 Find X8 上点开新闻频道能自动折叠标题栏，在 MOLLY 上必须点两下才响应；但在 Mate 60 Pro+ 上，同样的点击，它反而多触发一次 FragmentTransaction.commitNowAllowingStateLoss()——导致一个空 ViewGroup 突然往 view tree 里插了个 null child。这个我说不准，因为 debug track 没开全，只能靠 Logcat 里拼出来的栈帧顺序猜：大概率是某次 WindowManagerService.injectInputEvent 调用时机和 SurfaceFlinger 的 buffer swap 周期撞上了，但谁也拿不出 trace。厂商对接人老李微信回我：“你们用的是哪个 input method service 的 callback hook？” 我回：“没 hook，纯 system ui 自己调的。” 他隔了四十分钟回了个“哦”，再没下文。
产品概念图，仅供参考 我后来把那行 dexmerge 卡住的命令手动拆开，先跑 d8，再跑 r8，最后 zipalign，结果发现真正拖住的是 r8 的 @Keep 注解解析器——它居然在遍历 assets 目录下的某个 json 文件，里面嵌了二十一个字符串字段，其中第十七个字段叫 "molly_special_optimization_flag"，值是 false。我删掉那整个 JSON，编译快了四百一十三毫秒，但 MOLLY 启动还是崩。所以这个 flag 是干什么的？没人知道。测试妹子小杨试了三次，每次崩的位置都不一样：第一次卡在 ContentProvider init，第二次卡在 NotificationManager.getService，第三次直接卡在 System.loadLibrary("webviewchromium") 的 JNI_OnLoad 里，日志里只有一行 “JNI ERROR (app bug): local reference table overflow (max=512)”。我查了 webviewchromium.so 的 soinfo，符号表里确实有五百零九个未释放的 jni local ref，但这锅该算到 chromium 自己头上，还是算到 MOLLY 加的那个预加载代理类上？我没动它，怕改出新问题，就让它挂着。对了，我桌右上角那杯冰美式已经化成温水，糖浆沉底了，褐色的圈糊在纸杯壁上，像某种没画完的状态机图。刚才小陈又换了一根网线，这次是绿皮屏蔽线，插进去之后 Android Studio 居然自动识别出了 MOLLY 的 adb 设备，虽然还是连不上 logcat。老李又发来一条：“你们确认没打 signature v2？” 我回复：“v2/v3 都打了，MD5 和 SHA256 校验全过。” 他回了个“……”。这个省略号我熟，意思是“你们自己再想想”，而不是“我们查查”。 其实吧，MOLLY 的“优胜劣汰”不是功能层面的，是调度策略——它的 binder thread pool 被砍到只剩两个，而我们有个广播接收器非得用 IntentService 启动一个 Service，Service 里又开了 handlerThread 来处理数据流。两个 binder 线程扛不住三路并发请求，第三路就排队，排到超时，然后整个 AMS 把这进程标为 unresponsive。这不是 Bug，是设计。就像你非要用 USB 2.0 的线插 USB 4.0 的口，它通电，它握手，它甚至能传文件，但只要你传大于一百二十三兆的东西，它就强制降速到 38MB/s 并且不告诉你为什么。这种东西写进 spec 里叫“弹性约束”，写进测试报告里叫“不可复现”，写进上线通告里就叫“震撼登场”。 我现在要把这行 r8 参数临时注释掉，加个 -keep class .MOLLYFlag { ; }，再重跑一遍 full build。不保证有用，但至少能让它编过。小陈说他那边发现个更邪门的事：MOLLY 的 /proc/sys/kernel/msgmax 返回值比标准值小七百五十二，但他没截图，我也没让他重放。先跑编译吧。 （编辑：52刷机网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
