hashmap的扩容机制，腾讯Android开发面试记录，系列篇

一、开始的开始

**Android框架体系架构（高级UI+FrameWork源码）**这块知识是现今使用者最多的，我们称之Android2013~2016年的技术，但是，即使是这样的技术，Android开发者也往往因为网上Copy代码习惯了而导致对这块经常“使用”的代码 **熟悉而又陌生：**熟悉的是几乎天天在和它们打交道，天天在复制这些代码；陌生的是虽然天天和这些代码打交道，但是并没有深入研究过这些代码的原理，代码深处的内涵。

所以我们需要从新的角度去分析这些知识点，深入研究他们，要学习源码，模仿源码，然后再hook源码，这样才能说自己懂这块的知识。这些都是做Android开发，更是做高级工程师的基础。

学会深入思考，总结沉淀

我想说的第一条就是要学会深入思考，总结沉淀，这是我觉得最重要也是最有意义的一件事。

‌先来说深入思考。在程序员这个圈子里，常能听到一些言论：我这个工作一点技术含量都没有，每天就CRUD，再写写if-else，这TM能让我学到什么东西？

抛开一部分调侃和戏谑的论调不谈，这可能确实是一部分同学的真实想法，至少曾经的我，就这么认为过。

后来随着工作经验的积累，加上和一些高level的同学交流探讨之后，我发现这个想法其实是非常错误的。之所以出现没什么可学的这样的看法，基本上是思维懒惰的结果。

任何一件看起来很不起眼的小事，只要进行深入思考，稍微纵向挖深或者横向拓宽一下，都是足以让人沉溺的知识海洋。

‌举一个例子。某次有个同学跟我说，这周有个服务OOM了，查了一周发现有个地方defer写的有问题，改了几行代码上线修复了，周报都没法写。

可能大家也遇到过这样的场景，还算是有一定的代表性。其实就查bug这件事来说，是一个发现问题，排查问题，解决问题的过程，包含了触发、定位、复现、根因、修复、复盘等诸多步骤。

花了一周来做这件事，一定有不断尝试与纠错的过程，这里面其实就有很多思考的空间。比如说定位，如何缩小范围的？走了哪些弯路？用了哪些分析工具？

**比如说根因，**可以研究的点起码有linux的OOM，k8s的OOM，go的内存管理，defer机制，函数闭包的原理等等。如果这些真的都不涉及，仍然花了一周时间做这件事，那复盘应该会有很多思考，提出来几十个WHY没问题吧…

**‌再来说下总结沉淀。**这个我觉得也是大多数程序员比较欠缺的地方，只顾埋头干活，可以把一件事做的很好。但是几乎从来不做抽象总结，以至于工作好几年了，所掌握的知识还是零星的几点，不成体系，不仅容易遗忘，而且造成自己视野比较窄，看问题比较局限。

**适时地做一些总结沉淀是很重要的，这是一个从术到道的过程，会让自己看问题的角度更广，层次更高。**遇到同类型的问题，可以按照总结好的方法论，系统化、层次化地推进和解决。

‌还是举一个例子。做后台服务，今天优化了1G内存，明天优化了50%的读写耗时，是不是可以做一下性能优化的总结？

比如说在应用层，可以管理服务对接的应用方，梳理他们访问的合理性；在架构层，可以做缓存、预处理、读写分离、异步、并行等等；在代码层，可以做的事情更多了，资源池化、对象复用、无锁化设计、大key拆分、延迟处理、编码压缩、gc调优还有各种语言相关的高性能实践…

等下次再遇到需要性能优化的场景，一整套思路立马就能套用过来了，剩下的就是工具和实操的事儿了。大家也可以关注微信公众号：Java技术栈，在后台回复：架构，可以获取我整理的 N 篇 Java 架构教程&