Skip to content

WeKite 3.14 (CI 构建成功)

Choose a tag to compare

View all tags
@SymonChu SymonChu released this 15 Sep 16:49
· 138 commits to master since this release
v3.14
5985924

WeKite v3.14 (CI 构建成功)

本次修联系人/资料页那片灰底没染上色（v3.12、v3.13 连续两版都没修好）。

先说清楚: 前两版为什么又没修好

v3.11 / v3.12 是「猜类型」，v3.13 改成了「量图案自己的像素」——方向是对的，但尺子本身是坏的：

  • 量之前要先把图案渲染成一张小图，再读中心像素。渲染尺寸取自图案自己声明的尺寸（intrinsicWidth/Height），并且被夹在 8~64 像素之间。
  • 这一类图案根本不声明尺寸（返回 -1），于是被夹到垫底的 8 像素；而它四周的 inset / 边框通常比 4 像素还宽，8 像素整个被边吃光，中心啥也没画上去。
  • 结果就是「量出来是透明」。程序把「透明」当成了「这个图案没有颜色可量」，于是退回旧的中性解——也就是给半透明蒙层解算的那个解，叠在不透明灰板上必然偏亮。

这不是推测，是日志直接给出的：v3.13 那版日志里，这类图案的测量结果就是 pixels=#00000000（三行：InsetDrawable、NinePatchDrawable、一个混淆名的 wrapper）。测量失败，量到的不是颜色。

修复内容

🎨 那片灰底（占屏 22.9%）实测 (223,234,238)，正确应为 (188,228,236)

  • 🐛 根因：测量尺寸垫底 8 像素，被 inset/边框吃光 → 中心恒透明 → 误判为「量不出来」→ 退回错误的中性解。
  • ✅ 修法只改「量」，不改「解」：
    1. 图案不声明尺寸时，退到 128 像素（不再退到 8 像素垫底）——不声明尺寸恰恰就是 inset 超过几像素的那种图案；
    2. 中心像素透明不再直接放弃，按 128 / 256 再各渲染一次，拿到填充色为止。透明只说明「这次渲染太小、没剩下内部区域」，不等于图案没有颜色。
  • 🔒 第一次尝试逐字保留：图案声明尺寸时仍按原样夹取。凡是原先就量得出来的图案，走的还是同一条路，行为不可能变。
  • 🔒 暗色分支未改动；白面（话筒）与半透明蒙层（横幅）两条已实测正确的路径一行未动。
  • 🔍 新增一行诊断 pattern measure retry: <类名> at <尺寸>px，让「只有大尺寸才量得出」与「根本量不出」从此可区分——v3.13 正是栽在这两者无法区分。

数学验证（primary 取你日志里的 #00677e）：

资源路径 recolorSurface(#EDEDED, 0.21)  = (187.2, 227.9, 237.0)   ← 旁边已经染对的面 (188,228,236)
修复后: 量到灰底 → 解混合      合成 = (187.2, 227.9, 237.0)   误差 0，与旁边的面完全一致
修复前: 误走中性解             叠加 = (222.0, 234.3, 237.0)   与截图实测 (223,234,238) 差 1 → 就是它

说明

  • 本版 APK 与 Zygisk 模块均由 CI 构建，签名与 v3.13 一致，可直接覆盖安装。
  • 莫奈取色的颜色在微信启动时解析一次，修改开关或种子色后需重启微信生效。
  • 若还有哪个表面颜色不对，把日志发回来——现在诊断行会同时给出类名、量到的像素、以及是否靠放大渲染才量到，一次定位，不用再猜。

构建：GitHub Actions run 156（commit 59859245）

Assets 5
Loading