如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更
缩放后文字模糊是gpu插值导致的正常现象，因transform: scale()触发合成层使文字降级为双线性滤波渲染；应将scale上移至父容器、用font-size过渡或js截断小数像素来确保整数像素对齐。
缩放后模糊不是 CSS 写错了，而是浏览器把文字渲染到了非整数物理像素位置，触发了 GPU 插值——这是硬件加速的默认行为，不是 bug，也压根不会报错。
transform: scale() 触发 GPU 合成层导致文字降级渲染
文字原本在主图层用亚像素抗锯齿（如 macOS 的 -webkit-font-smoothing: antialiased），但一旦加了 transform: scale()，浏览器就会把它拎进独立合成层，转成 GPU 纹理再缩放。GPU 默认用双线性滤波插值，一遇到 scale(1.2) 这种非整数比，边缘就被平滑糊掉。
验证很简单：Chrome DevTools → Layers 面板 → 悬停模糊文字，如果框出红色图层，说明你正在跟 GPU 光栅化硬刚，所有字体平滑设置都已失效。
- 直接对
<p></p>或<h2></h2>加scale()是最危险操作，文字立刻被隔离 - 正确做法是把
scale()上移到父容器（比如.card），让文字始终和背景共处同一图层 - 必须用
font-size过渡替代scale()时，transition: font-size虽性能略低，但渲染质量稳定
小数像素位移让坐标永远落不整
transform: translateX(50%) 看似安全，但在 199px 宽的容器里算出来是 99.5px；scale(1.25) 在 16px 字体上得 20px 是整数，但 scale(1.23) 就是 19.68px —— 浏览器光栅化阶段只能插值，没有“四舍五入”选项。
- 用
calc(50% - 0.5px)替代translateX(50%)，强制结果落在整数像素 - 动态计算位移或角度时，必须用 JS 截断：
Math.round(value * window.devicePixelRatio) / window.devicePixelRatio - 移动端 Safari 对 sub-pixel 更敏感，0.1px 偏差就可能引发明显锯齿
will-change: transform 和 translateZ(0) 不是解药
will-change: transform 只是提前声明“我要动了”，它不解决像素对齐、不干预字体光栅化、也不重置坐标精度。单独加它，模糊照旧；滥用还会让图层数爆炸，内存飙升。
- 真正起效的前提是三者同时满足：
el.style.willChange = 'transform'（动画前一刻）、el.style.willChange = 'auto'（动画结束帧清除）、且transform值本身是整数（如rotate(90deg)） -
transform: translateZ(0)比will-change更轻量，它强制重走光栅化流程，有时能恢复亚像素渲染，但仅在 Windows Chrome 110+ 上偶有改善，macOS Safari 基本无效 - 若父容器已设
will-change: transform，再加translateZ(0)可能引发图层嵌套，糊得更明显
最隐蔽的点在于：模糊只在特定 DPR、特定缩放比、特定浏览器版本下偶然出现。一旦依赖 translateZ(0) 这类“看起来有效”的权宜之计，后续在 iOS 或高分屏上大概率翻车。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
