移动开发最新Android 程序员们的现状通病！，字节跳动面试真题-CSDN博客

本文链接：https://blog.csdn.net/2401_84556528/article/details/138730729

最后

跳槽季整理面试题已经成了我多年的习惯！在这里我和身边一些朋友特意整理了一份快速进阶为Android高级工程师的系统且全面的学习资料。涵盖了Android初级——Android高级架构师进阶必备的一些学习技能。

附上：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题（含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

架构( Architecture)这个词，来自于建筑领域。我们经常将编程比喻成造建筑。工地上分工明确，各有等级，按照一所建筑的流程来看：

首先是开发商提出需求（公司客户）

到承包商拦下项目（公司本身）

总工程师画出建筑图纸，这一步最为关键，房子的总体框架，模型，建好后长什么样子，钢筋水泥瓷砖地板装修用料都要给出明确的流程和步骤（架构师）

工头领队施工（TL）

和水泥的和水泥，砌砖师傅砌砖等等（码农，业务代码）

可以说，建房子和编程开发的流程，完美的契合。

插一个自己的小故事

要明白一点：写业务代码和做架构是两个完全不同的事情。

刚踏进大学入门Android开发的时候，对架构师这个词并没有太多的概念，就觉得肯定很牛13，我以后工作了也肯定是个架构师。

后来开始写代码，从Java学起，然后四大组件，写Activity，然后学UI，学布局等等等。

学校毕业出来，我已经能独立开发自己的APP，虽然就是些什么图书借还APP，壁纸下载APP。但我依旧觉得自己很牛13。但是这份资历加上科班出身，毕业后我还是轻松得到了一家小公司的offer。工作一年后，我已经能基本上独立解决自己开发岗位上的问题了。

我贼牛逼。但是我不会口头上说出来，我要跳槽，这家小公司的舞台已经不够我发挥了，但我不会说出来，先找好下家，再提辞职，刚步入社会的我，就有如此远见，佩服自己。

于是我拿着自己1年工作经验的简历，投给了阿里巴巴，Android研发工程师。淦，面试都没收到。

然后我又投了当时如日中天的字节跳动，号称年轻人的天下。淦，又没收到面试。

是我眼高手低了？投了一家上市公司，金融行业，程序员最赚钱的行业，我**，又不给面试。

？？？

最后终于面到了一家中大型的企业，嗯…中级Android工程师。

自我介绍完，说了一下我做过的项目后，leader脸上一副：就这？就这？的表情。

当然，作为成年人的他，还是有着该有的涵养和礼貌，并没有打断我说话之类的。

然后到面试问题环节

leader一上来就问：看你简历上写熟悉 AIDL，说一说 oneway 吧

我：啊？oneway 是什么？跟 AIDL 没关系吧，我熟悉 AIDL 指的是使用 AIDL 接口进行跨进程通信。

面试官：…

啊哈，接下来的15分钟我羞耻的恨不得立马破门而出！binder通信原理是什么？说不清。子线程可以创建Handler吗？母鸡啊。activity启动流程总能说一说吧？哈哈哈，忘记了…

我人生中的第一次跳槽就这样羞辱的结束了。。。。。。。

这件事过后，我如梦方醒。光会砌砖（写业务代码）就想当总工头（架构师）？不可能。

这也是大部分码农无法成为架构师的一个原因。一直停留在业务层面，把砖砌的再好，终究只是砌砖师傅。

怎样能成为一名架构师？

我们依旧比喻成造房子，也就是说，从一个砌砖师傅怎么才能一步步成为总工头呢？

一、把砖砌好

代码是写给别人看的，写好业务代码是成为架构师的第一步。

没有哪一个架构师不是从写业务代码成长过来的。没有不懂业务的架构师，所有的架构，都依赖于业务。所有的架构师，也必须要去写业务代码，不把自己设计的东西，用在真正的项目里，恐怕他们自己都不会知道，这种架构设计的合理性在哪里。

这里我想表达的代码质量优化，并不单指日常编程。

我想表达的是一种架构思想：面向未来编程

一个好的工程师，在听到需求的时候，可以根据自己的业务能力，判断出来这些需求中，哪些是有可能变化的，哪些是不太可能变化的。

针对这些变化的内容，在编写的过程中，不会写死，而反复确认不可能会变化的需求，会写的简单一些，防止过度设计引起的复杂度。

简单说，当他拿到需求时，并不单纯是考虑这个需求怎么实现，还会考虑，自己设计的架构体系，扩展性在哪里，在他的眼里，看到的需求会被分解，折分，然后自己的技术方案，会挨个分解，分配。

在完成设计之后，他会很清楚的知道，自己设计的系统里，哪些变化是支持的，随便你改，我只需要改动一个很简单的内容，哪些是你绝对不能改的，你要改，我就必须花很大的代价，特别是在已经有线上数据的时候。

而且会拿着自己的架构体系跟 PM 沟通，讲清楚。

如果你编程时已经有了这种思想，说明你已经具备了一名架构师的基本素养。

二、清楚砖头钢筋水泥的成分

房子要建好，必定要选用好的材料。这些便是房子的底层、基础。

在编程中，我们所用的语言便是砖头，各种工具类便是水泥，各种框架便是钢筋。

光会用当然不行，必然要“知其然，知其所以然”，“所以然”便是各种方法、工具类、应用框架的底层源码以及他的实现原理。

对于绝大多数编程从业开发者而言都面临一个普遍的问题：广度与深度难以兼顾。

每个企业的业务方向都不一样，用的技术也不一样。运气好，面试的时候甲方公司用的技术刚好跟你学的一样，结果技术面一问，你只答的出四大组件有哪些，生命周期支支吾吾也说不太清楚，view的绘制流程模棱两可，垃圾回收算法一知半解，性能优化一窍不通。这要是能找到offer，那就见鬼了。

很多人在开发过程中只是浮在表面，忽略底层源码分析，面试求职的简历也没有进行修缮和突出重点，自然求职不顺，加薪无望。

所以解决这个问题的最好办法就是：**抓住不变量。**要知道，底层知识永远都不过时。算法数据结构永远都不过时。基本的程序设计理论永远都不过时。良好的编码习惯永远都不过时。分析问题和解决问题的能力永远都不过时。强大的学习能力和旺盛的求知欲永远都不过时。你大脑的思维方式永远都不过时。

举个栗子

大家应该知道也懂得性能优化的重要性，可工作中由于对整个知识掌握不够，所以会在性能优化上没有自己的理解。比如，Glide，这个是我们经常用的技术，相信大家都会用：

Glide.with(context).load(“图片url”).into(imageView)

但是大家谁知道这个里面有性能上面的坑啊？

如果我们不能体系的去掌握activity，fragment，application的生命周期，而且也不了解glide源码，因而我们可能是直接在context的地方传this，或者，直接给application的context，那么此时Glide的生命周期就和this，或者application绑定了，那么结果大家可想而知，在嵌套的fragment+viewPager的代码结构中，生命周期的管理不到位，就会带来生命周期问题的内存碎片。自然大家就知道，类似的情况多了性能就会一点一点的损失，最后导致app的运行过程中偶现的OOM，结果可想而知。

底层知识学扎实了，上层的东西像风筝一般千变万化，而你是在底下扯线的那个人，顺着线往下拉，便能轻松看清楚这个风筝长什么样。