一加Turbo 6V深度评测：性能强、价格香！

　　亲历现场。那版系统推出来第三天，我正对着一加Turbo 6V的SystemUI改状态栏高度适配，测试妹子在隔壁工位吼了句“又崩了”，我就知道今晚没戏了。她喊完把耳机一扯，转身去翻日志——这姑娘连崩溃堆栈都懒得等Logcat自动滚动，直接Ctrl+F搜“WindowManager”。

　　桌上机械键盘声一直没停过，青轴，咔哒咔哒，像有人在敲核桃。我原以为是外包同事小陈在赶推送栏折叠逻辑，结果抬头一看，他早溜去楼下便利店买关东煮了，手里拎着纸袋，萝卜块还往外冒热气。我盯着他后脑勺看了三秒，突然意识到自己昨天改的StatusIconController根本没触发onDensityChanged回调——不是没写，是那个方法在那版系统里压根没被调用过，连trace都没进。我敢打包票，这个我试了七遍，每次都是空跑。

产品概念图，仅供参考

　　窗外洒水车这时候经过，声音拖得老长，“滋——哗——”，喷头转一圈，水雾蹭过窗台那堆测试机。四台Turbo 6V全搁那儿晒着，屏幕朝上，白边反光刺眼。其中一台壳子已经有点发烫，我伸手摸了下，温的，不烫手但绝对不该是室温。这事儿没人管，测试妹子说“发热不影响验证”，我说“发热影响TouchTargetSize计算”，她点点头又低头划屏去了，指甲油掉了一小块，在屏幕边缘留下半枚月牙印。

　　厂商对接人老张来过两次。第一次带了个PDF，标题叫《Turbo系列一致性适配白皮书V2.3》，封面上印着“深度优化·无感体验”，我翻到第十七页，发现他们把NotificationShadeController里setExpandedHeight()的调用链图标的颜色标错了——灰蓝混成了蓝灰，字体用的思源黑体Medium，不是Regular。我没吭声。第二次他带了新方案：让所有SystemUI组件继承一个BaseSystemUIView，然后重写dispatchDraw做统一阴影裁剪。我听着，点头，顺手把他刚递来的保温杯往右挪了八厘米，避开键盘右下角那个翘起的键帽。杯子底下压着半张便签，上面是我手写的“check density = 320 vs 480”——可那版系统根本没跑320dpi的机型，全是480起步。我忘了划掉。

　　“优胜劣汰”？对。但这四个字不是夸它跑分高、不是夸它便宜，是说它砍掉了所有你靠惯性活着的地方。比如那个StatusBarTransitions类，我们原来习惯在onConfigurationChanged里resetTransitionState，Turbo 6V不认——它只在windowDecorView的onAttachedToWindow之后才发transition-ready广播。我改完第一遍，测了，正常；第二遍，改回原逻辑再测，也正常；第三遍……算了，第三遍是我喝完半杯凉透的枸杞茶，盯着屏幕反光里自己的黑眼圈看出来的：它根本没走你写的路径。它走的是ViewRootImpl那边私有hook，代码埋得比小米的Launcher3里getHomeAppIntent还深。

　　楼下便利店关东煮的汤底味飘上来的时候，我已经删了三次NotificationPanelViewController里的mPendingAnimationFlag赋值逻辑。第一次删完，下拉卡顿；第二次删，状态栏闪两下；第三次删，动画干脆没了，但通知点进去能展开——这事儿我说不准，真不确定是AMS侧提前abort了，还是WMS在performLayout阶段把AnimationHandler给清掉了。反正日志里没报错，就一行debug级log：“[TURBO] Shade sync hint ignored — density mismatch”。密度不匹配？可我刚才切过十六次dpi，从360到560，每档都跑了onDensityChanged，就差拿热敏纸贴屏幕测像素点了。

　　小陈回来的时候给我捎了串竹轮，插着竹签，酱汁滴在测试机A102的USB-C口胶垫上，慢慢渗下去，像墨迹。他问我“要不要重启AS”，我说“别动IDE，AS正在编译R.java”。其实没在编译，只是Gradle daemon卡在generateDebugResValues，窗口左下角写着“Processing resources…”已经停了十八秒。我盯着那个省略号，数了三遍，没动。洒水车又来了，这次声音短些，“滋——”，没哗出来。

　　最离谱的是那个悬浮球。我们原来默认监听SYSTEM_ALERT_WINDOW权限状态变化去show/hide，Turbo 6V根本不走这个BroadcastReceiver。它读的是一个隐藏的ContentProvider，uri路径是content://com.oneplus.systemui/permission/suspend_state，返回的cursor里只有一列：value，int类型，0或1。我试过registerContentObserver，试过bindService，最后发现必须等它那个SystemUI服务真正冷启动完成之后——不是onCreate，是Application.attach完毕之后——才能读到有效值。谁会等SystemUI Application attach完再去初始化悬浮球？没人。所以全厂适配的悬浮球，现在都在开机十分钟内随机消失，直到用户手动下拉一次通知栏，才“啪”地弹出来。测试妹子说：“哎哟，它还挺懂事。”

　　我原以为是SELinux策略收紧，查了selinux log，一条没中。后来抓strace才发现，它在system_server里fork了一个轻量级子进程专门轮询那个Provider，每三百七十二毫秒一次，轮五次没响应就切到备选路径——而备选路径压根没实现。这段代码不在AOSP，也不在oneplus-public，甚至没出现在他们给的vendor.img symbol table里。是个纯runtime patch。我问老张，他说“这个我们不提供symbol，你们按行为对齐就行”。行，我对齐。我把那个轮询改成主动poll，加了指数退避，第五次失败后弹Toast：“悬浮球加载中，请稍候…（本提示不可关闭）”。测试妹子看见直接笑出声，说这比他们客服电话还倔。

　　现在窗台那堆机器还在晒，其中一台屏幕朝下扣着，应该是小陈拿去拍短视频用了。他刚发群里一张图：Turbo 6V亮着屏，显示“性能强、价格香！”，底下P了行小字：“优胜劣汰——淘汰的是你的适配惯性”。我截图发给了厂商，没说话。老张回了个表情包，熊猫头，叼着烟，烟头明明灭灭。我没回。这事儿没法回。我连“这个我敢打包票”都不敢说了——刚收到消息，Turbo 6V Pro明天上午十点 OTA 推送，base还是那版系统，但SystemUI换了新APK。SDK level没变，签名没变，包名没变，唯独resources.arsc里所有drawable的md5全变了。

　　今晚先重刷一遍res/values下的dimen.xml，至少先把status_bar_height那些值对齐。别的……等烧录完再说。我先去把窗台上那台发烫的机器翻个面。

（编辑：52刷机网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!