在 Android 岗位的技术面试里，第一道题往往不是架构设计，也不是性能优化，而是最基础的变量与基本类型。
不少候选人一听这个题目就松了口气，觉得「这么简单，稳了」。但在有经验的面试官手里，这道开场题恰恰是信息量最大的一道：它能在十分钟内分辨出候选人是「用过 Java」，还是「理解 Java」。
典型的面试场景是这样的。面试官问：「你在项目里，用户的累计步数用什么类型存？为什么不用 int？」候选人脱口而出：「用 int 吧，步数又不会特别大。」这个回答一出口，面试官心里基本就有了判断，随后只需追问一句——「那这个 App 要显示用户从注册那天到今天的总步数，一天按一万步算，坚持十年是多少？中间有没有哪一步可能出问题？」能不能接住，水平立刻见分晓。
其实这道题不算难。一天一万步，十年是三千六百多万，int 的二十多亿上限完全装得下。真正的问题不在答案本身，而在「脱口而出」这四个字——它暴露了一个很普遍的情况：很多人写了好几年 Java，对变量和基本类型的理解，还停留在「int 存整数、double 存小数」的层面。一到 Android 方向的面试，这种基础认知反而成了最容易翻车的地方。面试官往往不用问多深，一句追问就能探出底。
机制拆解
很多资深工程师在带新人时都会强调一句话：「写的每一行代码，本质上都是在跟数据打交道。连数据是什么类型、能装多大、会怎么算错都没搞清楚，后面的逻辑全白搭。」
这句话听起来朴素，落到实处却是一次次的线上教训。有一个流传很广的真实案例：某团队给内部工具做倒计时功能，剩余毫秒数随手用了 int。测试阶段一切正常，倒计时都是几秒、几十秒的量级，没有人会多想。工具上线几个月后，某个环节的倒计时被配置成了三十天，页面上的数字直接变成了负数。
根因就在 int 的上限：2147483647，换算成毫秒大约二十四天半。倒计时一超过这个长度，int 就悄悄溢出——不会抛异常，不会打日志，只是从最大值绕回最小值继续数，一个「剩余时间」就这样变成了巨大的负数。这种坑在测试环境几乎无法复现，因为没有人真的会盯着界面等三十天。
这正是面试官反复考基础类型的原因：数据类型不是课本上用来背的表格，它是每个数据的「身份证」——决定了这个数据能装多大、能精确到什么程度、在内存里占多少空间、参与运算的时候会不会悄悄出错。在开发机上写错一个类型，跑一百次测试可能都没事；到了线上，它就是一张用户报障单，而且是最难查的那一种。
整型、浮点、boolean 与包装类型，每一类都有必须门清的点
整型家族：byte、short、int、long
byte 八位，short 十六位，int 三十二位，long 六十四位，表示范围一格比一格大。日常业务里 int 是默认选择；long 用在时间戳、文件大小、流量统计这些 int 装不下的场景。System.currentTimeMillis() 返回的就是 long——毫秒级时间戳早就超过了 int 的上限，这一点在面试里常被拿来当开场题。
比「记住范围」更重要的，是理解溢出本身的行为：int 溢出是取模回绕，没有任何异常提示。所以凡是计数可能超过二十亿的场景，要主动用 long 承接，而不是等出了问题再回头查。这个意识，比背十遍范围表值钱。
浮点型：float 与 double
float 是三十二位，大约七位有效数字；double 是六十四位，十五到十六位有效数字。面试里问「float 和 double 怎么选」，只回答「double 精度高」基本过不了关——面试官要听的是分场景的权衡。
View 的坐标、动画的插值进度、手势的位移量，这些场景用 float 完全够用——屏幕横竖也就几千个像素，float 的精度远远富余，而一个 Bitmap 动辄几百万个像素，用 float 省下来的内存是实打实的收益。但涉及金额、积分、任何需要精确累加的数值，float 和 double 都不能碰。0.1 加 0.2 不等于 0.3，这不是 Java 的 bug，是二进制浮点数的天性——很多十进制小数在二进制里是无限循环小数，存进去的那一刻就带了误差，累加只会越滚越大。业务金额要么用 BigDecimal，要么用以「分」为单位的 long。
boolean 与 char
boolean 只有 true 和 false 两个值，它是所有状态判断的地基，用对了可读性远胜于用 0 和 1 硬凑。char 是十六位的 Unicode 字符，平时用得不多，但要知道它本质上是一个数值，可以参与运算——这也是为什么 char 和 int 之间的转换是「隐式放行」的。
包装类型：Integer 与它的缓存池
基本类型和包装类型的区别，是 Java 面试绕不开的一题。这里先记住一个数字：127。Integer 对 -128 到 127 范围内的值做了缓存，Integer a = 127 和 Integer b = 127 指向同一个对象，a == b 是 true；换成 128，就成了两个独立对象，a == b 立刻变成 false。这个「127 相等、128 不相等」的坑，几乎是包装类型面试题的标准剧情，后面还会反复提到它。
这些坑的正确绕法
最常见的坑是整型静默溢出：int 的上限是 2147483647，换算成毫秒大约只有二十四天半。一旦倒计时、累计计数超过这个长度，它不会抛异常、不会打日志，只是悄悄从最大值绕回最小值，一个「剩余时间」就变成巨大负数。正确绕法是：凡是计数或时间可能超过二十亿的场景，主动用 long 承接，而不是等线上报障才回头查。
其次是把浮点当精确值用：0.1 + 0.2 不等于 0.3，动画插值算出来的进度 0.9999999 和 1.0 画等号也不会相等。正确绕法是：浮点只用于「够用的精度」场景（如屏幕坐标、插值进度），金额、积分这类需要精确累加的数值一律用 BigDecimal 或「以分为单位的 long」；判等用 Math.abs(a - b) < 1e-6 或 Double.compare，绝不写 ==。
还有一个更隐蔽的坑：一上来就「脱口而出」。面试官问「用户步数用什么类型存」，随口答 int，暴露的是把基础当语法背、从没想过边界。正确绕法是：回答带场景、带边界、带踩坑经历——「步数用 int 够，但累计总步数要算十年量级就得 long」，一句话就把理解深度亮出来。
再一个是char 与 int 的隐式放行：char 本质是十六位的 Unicode 数值，可以参与运算，新手常在类型转换时踩到这层隐性强转。正确绕法是：记住 char 是数值而非字符，跨类型运算时显式处理类型，别被「字符」两个字骗了。
代码里见真章
看一段能直接跑的代码，把上面的机制落到具体写法上：
// 001：四类八种、溢出与精度，一行一个考点
long dayMs = 24L * 60 * 60 * 1000; // 先转 long 再乘，防 int 溢出
long stamp = System.currentTimeMillis(); // 毫秒时间戳，必须 long
int back = Integer.MAX_VALUE + 1; // 悄悄回绕成负数，无任何提示
double bad = 0.1 + 0.2; // 0.30000000000000004
System.out.println(dayMs + " " + stamp + " " + back + " " + bad);
这段代码值得盯三处：第一处，long dayMs = 24L * 60 * 60 * 1000 先把因子转成 long 再乘，避开了「两个 int 先乘后溢出」的经典陷阱；第二处，Integer.MAX_VALUE + 1 悄悄回绕成负数，不抛异常、不打日志，这正是整型溢出最阴险的地方；第三处，0.1 + 0.2 得到 0.30000000000000004，二进制浮点的精度误差在赋值那一刻就埋下了。把这四个类型的基本功写顺，面试讲到这一层，基本就稳了。
这题在面试里怎么问、怎么答
从大量真实面试来看，变量与基本类型的考题集中在三个方向。
第一个：自动装箱与拆箱
「Integer 和 int 有什么区别？什么时候会出问题？」
区别谁都答得上来：int 是基本类型，Integer 是对象，可以有 null。真正拉开差距的是拆箱那一下——Integer 一旦是 null 还去自动拆箱，直接抛 NullPointerException。
线上有一个典型崩溃案例：三方统计 SDK 的接口返回 Integer 类型的埋点数值，网络异常时返回 null，业务代码顺手把它赋给了 int 局部变量，Crash 平台里清一色 NullPointerException，堆栈却指向一行看起来毫无风险的业务赋值。修复方式很简单：取值之后先判空，是 null 就走默认值，有值再拆箱。面试中能把这个案例讲清楚，比背十遍「包装类型是对象」有用得多——它证明候选人真的处理过线上问题。
第二个：精度与类型转换
「float 转 int 会四舍五入吗？」
不会，是直接截断。(int) 3.7 的结果是 3，不是 4。反过来，整数除法也是截断：5 / 2 的结果是 2。这两条规则合在一起，就是无数精度 bug 的源头。
Android 开发里天天在用的 dp 转 px 就藏着一个细节：标准写法是 (int) (dp * density + 0.5f)。为什么要加 0.5f？因为浮点数乘完 density 之后大概率带一长串小数，直接截断会整体偏小，加 0.5 再截断才等价于四舍五入。很多工程师天天调这个方法，被问到为什么这么写反而答不上来——这种「天天用却没想过为什么」的地方，恰恰是面试官最爱追问的。
还有一个容易忽略的点：混合运算的类型提升。写 double d = 1 / 3，先做整数除法得 0，再提升为 0.0；写成 1.0 / 3 才是 0.3333。传感器数据的归一化、比例计算里，这种坑特别容易踩，而且看起来代码完全「合理」。
第三个：作用域与生命周期
「static 变量在 Android 里有什么特殊性？」
普通 Java 程序里，static 变量的生命周期跟着类走，类加载了它就在。但在 Android 里，static 变量的生命周期跟进程走——进程不死，它就不死。这句话背后藏着两个面试必问的问题。
一个是配置变更问题。旋转屏幕、切深色模式，Activity 会销毁重建，但 static 变量原封不动。如果里面缓存了跟旧界面绑定的数据，新界面读到的就是过期值，表现为「转个屏数据就乱了」。
另一个是内存泄漏。static 变量持有 Activity 或 View 的引用，界面销毁了引用还在，GC 没法回收。修法是静态变量只持有 ApplicationContext，或者用 WeakReference 包一层。
还有进程被杀的场景。Android 在内存紧张时随时可能杀掉后台进程，static 变量随之重置，用户回到 App 时界面要靠 savedInstanceState 恢复状态。所以不要拿 static 变量当持久化存储用——它比想象中脆弱得多。
给正在准备面试的你
可能有人觉得：这不就是基础语法嘛，至于这么较真？
至于。
大量真实面试给出的规律是：基础扎实的候选人，后面的项目问得再深都能接住；基础不牢的候选人，项目经验讲得再好，两个底层问题追问下去就露馅了。变量与基本类型，就是 Java 最底层的基础之一。能在面试中把它讲清楚、讲出场景、讲出踩坑经历，面试官给出的第一印象立刻不一样——「这个人基础扎实，可以培养」。
具体怎么做？把八种基本类型的宽度、范围、默认值整理成一张表，不用死背，但要理解为什么毫秒时间戳 int 装不下、为什么金额不能交给浮点。然后去翻 Android 源码里的真实例子：MeasureSpec 为什么能用一个 int 同时装下模式和尺寸，SystemClock.elapsedRealtime() 为什么返回 long。做完这一步，对数据类型的理解就不只是「语法」层面了，而是真正跟工程实践挂上了钩。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：无（系列开篇）
下一篇预告：运算符与表达式：整除、短路、位运算与优先级
有任何问题欢迎在评论区留言交流。
