|
|
分析过程有点复杂，让deepseek帮忙总结了一下:
思路来源
上次版本更新时，APP没有重新下载安装包就凭空多了“专家模式”。这只能靠热更新实现。我直接打开APP的数据目录，搜索关键字"专家模式"，找到了 file/mmkv.default这个文件。
原来客户端用腾讯的MMKV框架存储配置开关。服务端下发一个标志位，写进这个文件，客户端一读，就显示专家模式入口。这说明“专家模式”的代码早就躺在安装包里了，只等他激活。
我用工具反编译了安装包的DEX（Android可执行代码），直接搜索关键字 expert。
发现了一个叫x的类（属于类 fa.b），里面存在匹配 expert 关键字并加载对应原生UI的逻辑。
我依稀记得，上次版本更新之后，客户端显示效果没有多大变化，但随后不久就出了新功能。所以我看这次依然没有什么变化，怀疑是否预埋了相同的动态启动逻辑。
探索过程
还是遵循上次的思路，猜测匹配新模式的方法和之前匹配expert关键字的方法是同一个，搜索expert，在多个搜索结果中，找到了一段非常可疑的代码
if (mode == "expert") {
// 加载专家模式图标
} else if (mode == "vision") { // ← 新出现的分支！
if (dark_mode) {
icon = 0x7f0700f6;
} else {
icon = 0x7f0700f8;
}
} else {
// 默认模式
}
在上次分析的结果中，他只会匹配两个关键字default和expert，但是在这段代码中又多了一个新的关键字vision，很自然的联想到视觉模型
而且在类a1/o0的case13中发现了这段代码
// 上报用户点击事件
m0Var.n(mode, "user_click");
// 如果用户切换到了视觉模式
if (mode == "vision") {
updateUI(4); // 更新前端UI到视觉状态
// 如果全局还不是视觉模式，立刻标记
if (!globalIsVision) {
globalState.set("switch_to_vision");
}
}
点击“视觉模式”→上报点击事件→切换UI状态→全局标记已进入视觉模式，一整套行为链路已经写死。这是要上线的功能，不是废代码。
我在资源映射文件里找到了 vision 模式对应的图标资源ID：
资源ID 图标名称 用途
0x7f0700f6 ic_photo_filled_16 选中态
0x7f0700f8 ic_photo_outline_16 未选中态
0x7f0700f2 ic_photo_empty_outline 空状态
0x7f0700f3 ic_photo_error_filled 错误状态
全都是矢量图（res/*.xml），路径已确认存在，产品级正式资源，不是占位图。从命名看，涵盖了正常、空、错误三种状态，设计周全。 |
|
苏公网安备 32010602011309号
|
苏ICP备19064627号
变色卡
