android ui布局中不用float计算，因其精度误差大、不省资源且非为ui设计：系统全程基于int或dp转int，float引入ieee 754误差并最终截断，内存占用相同；应优先使用constraintlayout百分比、dimen资源、typedvalue换算等原生整数机制。
Android 界面布局中几乎不用 float 做计算 —— 它既不精确，也不省资源，更不是为 UI 量身设计的类型。
为什么 float 在 layout 计算中既不准又不省
Android 的 View 测量和布局系统全程基于 int（像素单位）或 dp（经密度换算后仍转为 int）。所有 LayoutParams、MeasureSpec、getMeasuredWidth() 返回值都是 int。你强行用 float 存一个 dp 值再参与运算，只会引入 IEEE 754 二进制表示误差（比如 0.1f + 0.2f == 0.30000001f），而最终赋给 ViewGroup.LayoutParams.width 时又会强制截断为 int，白忙一场。
内存上，float 占 4 字节，int 也占 4 字节 —— 并不节省；若你本意是“用 float 存小数 dp 值”，那不如直接用 TypedValue.applyDimension() 拿 int 像素，或用 Resources.getDimensionPixelSize()，一步到位。
远程控制 Android 设备，支持截图、自动化操作手机 App 等功能。本应用使用 uiautomator2 作为底层框架，通过 ADB 连接设备，用户无需 Root（1）查看手机屏幕；（2）自动化操作手机 App；（3）远程安装/卸载应用……
-
float无法精确表示多数常见 dp 值（如8.5fdp → 乘以 density 后可能变成12.75f→ 转int就是 12，而非期望的 13） - 所有
View.setTranslationX(float)这类 API 接收float是为动画插值服务，不是为布局计算准备的 - 在
onMeasure()中用float算尺寸，再 cast 成int，等于主动把精度误差塞进 layout pass
真正该用什么替代 float 做 UI 尺寸计算
需要“带小数的尺寸逻辑”（比如按比例缩放、响应式 padding），优先走 Android 原生机制，而不是手写 float 公式：
- 用
ConstraintLayout的app:layout_constraintWidth_percent或Guideline百分比定位，底层由 framework 用高精度整数运算保障一致性 - 自定义
ViewGroup中做比例计算时，用long或BigDecimal临时存放大数值（如总宽 × 1000），最后除以 1000 再转int，规避浮点截断抖动 - 读取 dimen 资源：用
@dimen/space_medium（XML 中定义为8.5dp），系统自动按 density 换算成最接近的int像素，且多设备一致 - 动态计算 dp → px：必须用
TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_DIP, value, resources.displayMetrics)，它内部用float但只用于一次换算，不参与后续逻辑链
float 唯一合理出现在 UI 计算中的场景
仅限于动画插值器输出或传感器数据映射，且必须明确接受“视觉可接受的抖动”：
-
ValueAnimator.ofFloat(0f, 1f)+setUpdateListener更新translationX，因为人眼对 sub-pixel 移动不敏感 -
SensorEvent.values[0]（加速度）是float[]，你把它映射到 view 位移时，应先做阈值过滤（如Math.abs(delta) > 0.5f），再累加到int偏移量，而不是让 float 误差持续累积 - 绝对不要在
onLayout()或onDraw()中用float维护累计偏移、缩放因子等状态变量 —— 下一次触发时初始值可能已漂移
真正难的不是选 float 还是 double，而是意识到：UI 布局的本质是离散像素网格上的整数约束问题。任何试图用浮点中间态“提高精度”的做法，都在对抗 framework 的设计前提。
