Android 面试经历复盘整理~

此次面试一共4面4小时，中间只有几分钟间隔。对持续的面试状态考验还是蛮大的。

关于面试的心态，保持悲观的乐观主义心态比较好。面前做面试准备时保持悲观，尽可能的做足准备。面后积极做复盘，乐观的接受最终结果。

切忌急于下结论，哪怕面试当场明显感觉好或不好。快思考时我常会放大积极面信息而缩小负面影响，导致做了过于乐观的抉择，回来后或者隔一天以后再思考，这时候可以做到慢思考，通过复盘来下一个更为理智的决断。

面试准备，自我模拟提问：（复盘评价：还是不够悲观）

之前贴出JD描述的行为略欠考虑，已删。虽然多数JD比较通用，不过还是要不贴为好。

JD拆解

组件化的经验

• 什么是组件化

组件化最早在上世纪被提出用于unix系统模块设计，后来广泛应用于前端与后端模块。

目前在移动端组件化方案是对模块化的一个升级性的架构方案，提高通用组件，中台服务，跨业务线组件复用。目的是在多模块之间形成接口隔离，提供下沉接口而非下沉实现类，或者采用静默注册直服务器托管网接提供功能，降低模块之间的耦合，保持各组件可独立编译发布版本。

• 有哪些解决方案

用过ARouter一段时间，了解其核心基础后，后来针对公司项目体量开发了更轻量的版本，提供可完全自主支持的PRouter。其核心还是通过APT 完成注解代码生成与路由编排，自动解析路由参数。更像是web页面路由在native的应用。主要包含activity，fragment，deeplink这几个入口。

Router库的组成：processor 用于读取注解，生成class文件，annotation 库声明注解，path公共库声明path（复杂场景需要降级拆分）

APM的经验

应用性能检测分为2个大的环境，分别是测试环境，生产环境。在再分下面几个方向

• 异常：崩溃检测，ANR检测，网络异常
• 启动耗时检测，页面（打开速度，帧率），大图检测，内测溢出，OOM
• 日志（APM日志与数据统计日志）

既要满足自身需要又要避免刻意重复造轮子

测试环境自动集成debug组件，静默初始化。记录页面操作路径，全局拦截异常，在crash时在JVM推出前拉起新进程展示异常信息，可以分享至工作群。

线上环境采用bugly，阿里云EMAS等平台进行监控，阿里云EMAS相对更稳定。

移动DevOps经验

DevOps是一种工程师文化，同时也是通过优秀的流程交付优秀的产品的最佳实践之一，已经广泛应用在各个前后端产品里，但是移动DevOps开放的解决方案并不多，大厂基本都在自建，需要的人力与技术储备也较大，这也造成了比较大的一个壁垒。

CI/CD是对DevOps的实现方式。

关于移动CI/CD看过蛮多资料，觉得最好的是Jetbrains类似白皮书的形式的内容，这也是我主要的学习资料。

在整个敏捷开发中有哪些低效率痛点：

开发阶段，代码分支管理，代码合并前卡点，产物构建环境

测试阶段，环境切换，bug修复，代码合并，新版本提交

发布阶段，发布信息，构建正式版本

发布后质量监控，数据监控，性能预警

讲一讲完成过的CI/CD

• 分支管理包含保护分支合并规则
• 开发发布MP 触发，Git Hook ,code review 卡点，lint扫描卡点（增量扫描，报告发送至办公IM），master分支同步卡点。合并成功后触发构建，构建产物同步，创建构建信息同步至办公IM @ 负责人
• 本地开发，本地Lint 实时提醒错误，实时拉取最新Lint配置
• 测试，debug辅助工具，新包自动推送至测试机
• 产品发布，创建 简道云发布流程，设定更新信息，更新策略，选定版本上线的开发，测试，运营（一般默认配好的）
• 开发触发构建正式包，扭转至测试测试，完成验收后自动扭转至运营发布上线，流程扭转至开发主管合并发布过的分支至master

构建正式包，自动创建tag推送至仓库，保留版本标记

数据埋点 神策，热修复阿里云EMAS（因为腾讯bugly与Tinker不稳定）

安卓端性能优化

• 兼容性测试：云测，阿里云，umeng，真机top100 monkey测试（尤其是针对版本更新）

• Crash

  • 可修复性异常
  • 可忽略性异常：使用 Looper Hook
  • 测试环境多进程 异常捕获

• ANR

  • 应用层：主线程阻塞（死循环，IO，超级计算，主线线程等待子线程的锁）
  • 系统层：CPU资源优先级过低，导致应用在后台ANR（当应用进入后台时，它可能会被系统赋予更低的CPU资源优先级，以便其他前台应用可以使用更多的资源。但是，这并不意味着应用的CPU资源优先级一定过低，因为系统的资源分配取决于多种因素，包括应用的优先级、当前系统负载等。如果应用在后台中运行了长时间的工作，并且消耗了大量的CPU资源，那么它可能会受到ANR的影响，即使它在后台中运行。）

• ANR触发场景

  • Service forground 绑定前台通知，5s
  • 广播，前台10s，后台60
  • 事件输入反馈，5s（个别手机ROM会自行拦截，无提示）
  • contentProvider 也会导致(很少用，未处理过）

• ANR 检测方法(local 与线上)

  • watch-dog,通过向主线程插入线程并在子线程做等待检查判断是否有可能发生了ANR
  • Matrix
  • 第三方crash平台，bugly，阿里云emas，umeng等等

• 启动优化

隐私策略，启动任务管理（有向无环图，多线程初始化，多进程管理，延时初始化，递进初始化），第三方初始化管理，排除ContentProvider流氓初始化行为

• 首屏加载优化

配合启动优化后，权衡业务与用户体验。优化布局，class初始化（减少巨型class，比如retrofit的service），分屏加载，布局预初始化（这部分时间从启动优化哪里并行扣出来）

• 卡顿
  • 卡顿监听（本地编舞者（测试小米120fps是有水分的），线上阿里云，umeng等）
  • UI布局性能，重绘，重测（降低布局层级，自定义view 无xml化，或constrantlayout，禁止relativelayout）
  • 内存使用：内存滥用（view 不重用，滥用静态存储，数据缓存无释放策略）主要是导致频繁GC造成卡顿
    • 代码质量，框架
    • 多进程分担主进程内存压力
  • 内存泄漏：在充分接入 lifecycle 之后这两年很少再碰到了
  • 内存抖动：典型的是draw方法中 创建大量新对象导致，触发年轻代gc，造成一定的卡顿
• 网络
  • 网络协议层错误上报（http,tcp,dns)
  • 业务侧接口数据异常解析报错监听上报，预警
  • 用户网络场景质量 ping值
  • 网络服务容灾，多域名，多资源（最早是在广告业务中应用）

研发流程优化，提升研发效率

深入参与不同的项目，深入参与各个环节的协作过程，收集分析问题，优化流程制度。配合工具与团队协作流程一起发力，核心是：为团队的每个角色服务，而不是角色为流程服务

Gradle插件，插桩

用kotlin写极大的降低插件开发门槛，提升效率

在CI建设中大量开发Gradle插件，打包插件，lint插件重写，lint支持动态从服务器读取lint配置，支持局部降级容错，支持增量扫描（自定义扫描范围）（自定义lint task 继承自BaseTask，在super.configure之前加载自己重写的lint gradle 库，分为 打包发布插件，lint gradle 插件）

appplugin,libraryplugin

插件开发文档较少除了gradle官方文档剩下的就是读源码，结合androidbuild流程进行方案设计与开发

• 插桩

使用 Transform 与ASM 修改 .class文件

写过 打印方法耗时的demo，前置需要2个知识点，一个是插件开发，rigisterTransform，一个是会读字节码文件（学习jvm时掌握）

transform有class访问器跟 方法访问器，来命中目标方法，ASMified可以讲目标class的改写指令进行可视化，copy进行调试。

Flutter开发经验

去年为团队培养出了一个flutter中级开发，3个初级开发，制定阶梯式学习项目 ladder-flutter，亲自参与到有 native 通信，getX状态管理，多引擎管理，banner+信息流开发。搭建 flutter 网络框架，利用范型与分层架构提供快速的数据解析能力，与流式API

面试过程：主要是记录下回答得不好的地方

带了ipad，用于讲解时展示一些图片资料，与用画图的方式更清晰的方式回复面试问题

一面：基础技术（JVM，多线程偏多）

• 说一下JVM的结构

说了堆，方法区，线程栈三个块的介绍。这里漏掉了说太快漏掉了程序计数器跟本地方法栈，但在面试官特地的问的时候也正确回答了作用。

• volatile 的作用与实现原理

用于变量修改时在多线程场景下保持修改的可见性，但并不能完全解决多线程并发修改的问题。举例了两个线程访问 i++的例子。

• 那介绍一下为什么说 i++是两步操作

介绍了i++字节码指令执行顺序以及方法栈执行细节

• Volatile 修饰的变量在修改时具体如何实现可见性的

这一步我直接回复不知道了，没有特地看过 volatile 修饰的字节码，不瞎说。面试官便给我进行了简单的介绍，我当时就想着回来一定要自己也看一看，之前为啥没看，哎。

首先在字节码中 针对Volatile修饰的变量会有一个 ACC_VOLATILE 标志：

• 可见性：当前线程修改后其他线程堆修改后的值立即可见，线程修改值之后立即写入到主存区，不用等到线程出栈的时候才同步到主存区。（线程工作区内存中保存的值要等待线程出栈时才写回主存区，在此之前其他线程对修改是不可见的）

• 顺序性：即读写的顺序性，而不会出现 读的过程中写入，或写入过程中被读取

• 不保证原子性：比如i++

// 读-写顺序性，假设有一个被 ACC_VOLATILE 标志修饰的 volatile 字段 v

// 线程 1
getfield v    // 读取字段 v 的值
iconst_2      // 将常量值 2 压入操作数栈
putfield v    // 将操作数栈顶的值存入字段 v 中

// 线程 2
getfield v    // 读取字段 v 的值

//写-读顺序性，假设有一个被 ACC_VOLATILE 标志修饰的 volatile 字段 v

// 线程 1
iconst_1      // 将常量值 1 压入操作数栈
putfield v    // 将操作数栈顶的值存入字段 v 中

// 线程 2
getfield v    // 读取字段 v 的值

• 那如何保证原子性

加锁跟使用Atomic类

• Atomic 是如何保证原子性的，或者说如何实现CAS的

这里太久没碰这块代码，听到CAS蒙了，问了一下原来是说CompareAndSet。不过这里依然是没准备，直接回答了未深入研究。

gpt：CAS底层采用CPU原子指令或锁机制来实现，多数情况采用cpu原子指令，通过硬件级别的操作来完成对一个内存位置的读写比较。

服务器托管网

这个快确实深啊，而且这种信息不太容易记忆。作为一个了解性内容吧。并不会产生二次开发所以应用比原理要重要。

• 你刚讲到了堆，锁，那你了解过对象的markword吗，它里面有什么信息

markword有了解，但是没有特别深。记得比较清楚的是有age 用于垃圾回收判断，有锁的标记位。

• 那对于偏向锁是如何转到轻量锁的

坦诚了一下想不起来，这里我自己虽然学习过，但是没作为重点知识准备。

markword中32位中会有几位来标记锁信息，其中包含当前持锁的线程ID

分为 无锁状态（对象无锁），偏向锁（单线程访问有锁对象），轻量锁（多线程访问有锁对象），重量级锁（轻量级锁无法解决竞争问题时上升到重量级锁，借助操作系统完成锁机制）。这里又能展开，锁竞争原理，锁开销不同的原因。默认在竞争锁时，为获取到锁的线程会进行Spin(自旋，最大10次)，在无阻塞情况下尝试获取锁，超过次数阈值后，膨胀为重量级锁，基于操作系统的锁机制，进行阻塞式等待锁的释放，减少自旋开销（开销具体是什么？不想挖了）

应用到代码里完成知识从理解到应用的闭环：

使用synchronized 修饰方法，类来设置轻量级锁

使用 object.lock（）或者可重用锁，读写分离锁，都是重量级锁

• 说说 age在垃圾回收中如何应用

这里回答比较清晰，从垃圾回收分区到age增长到对象换内存区

• 另外还问了handler消息机制

这部分主要是讲了ThreadLocal的特性，以及结合它如何完成多线程通信的。包括messageQueue的消息处理方式。对于native层nativePollOnce机制直接回复了未深入。我也不打算深入，集中在应用层的使用上收益比较大。

• 问了app启动流程，与启动优化

• TLS/TCP的 部分里拥塞控制跟流量控制部分没有回答上来

传输数据时数据包是被切成小块的（减少重传次数），切多大则是根据下面的两个策略进行平衡的。

拥塞控制：这在接受数据方，这部分是因为在做面试准备的时候没有刻意看，导致面试的时候没有结构化的进行表述。整体可以总结为在做数据传输时，每一个tcp链接都有窗口大小平衡每个tcp的的传输速率（分配到的带宽窗口），窗口大小自然是动态的，通过控制窗口大小避免单个tcp占用过大带宽，导致传输拥塞。

流量控制：发送方会根据接收方允许的窗口大小，调整自己发送的数据包大小，避免拥塞，这一步则是流量控制。

日常开发中针对这个优化则是降低接口数据体量，做接口拆分，分批次请求等等。

• Retrofit用过吧，说下他动态代理的实现原理

这里确实很深，我简单说了下自己学习掌握的原理概论与一些API与使用 ，因为这个要获取运行时字节码才可以搞明白。

面试官为我慷慨讲解了一些细节，没太记清楚，但我自己对于字节码理解还行，所以相对的给了一些临场反馈，全当学习了。当然，非常感谢他与我分享。就冲这些，这波面试已经不算白来了。

二面：TL

• 问了组件化经验，实现方式
• DevOps搭建思路

这部分其实是在我的能力与他们目前需要最契合的部分，我也没有卖关子。直接用ipad连画带讲，整个分享了一下。对就是分享了一下，结合团队技术能力，资源掌握情况，项目阶段等等给出整体的建设节奏。

• 启动优化
• 字节码插桩
• APP 打包流程
• 线程池的的运行原理

这里确实大意了，核心线程，非核心现场，任务队列三个之间的扭转关系，就是先入队再分配执行。

一个是之前学习是更多的是关注针对业务场景做配置，但是没有深入到源码去看。

• 对IOS的熟悉程度，主要是CI部分

这里整体流程没有少说，但是顺序是在面试官的提醒下纠正对的。不过我袒露了资源文件合并跟javac编译的顺序可能记错了。

整体上还是保持坦诚谦虚的态度。

• 动态Dex加载（插件化部分），问加载Dex的类叫啥
• 分代垃圾回收的不同算法
• 什么对象会被回收

其实就是GCRoot，这里没回答特别好，忘了1-2个比较重要的。

首先是存活的线程，被存活的线程引用的对象。其次还有系统Class，被线程访问的方法内的局部变量，被当作锁或在执行wait或notify的对象。还有一些其他的记不住那么多了，主要是用太少了。

• 如何完成Lint二开的，完成了那些功能

三面：HRD

• 询问了离职原因
• 询问我对前两轮的面试表现自我评价如何

他们两位在各自的领域展现的能力都非常出色，我对自己的整体评价不是特别好。但跟他们聊得蛮好，已经学到了很多知识，并且在后续沟通中对一些技术方案做了交换性讨论，这感觉非常好。

• 我咨询了公司文化，公司历史。日常工作流程制度，绩效考核等信息。

这块相互交流了一些工作方式方法，大概了解公司目前的协作流程制度，可能是她很忙所以薪资部分还没聊就到下一面了。

四面：部门BOSS（管理技能与解决问题的闭环能力）

• 如何做团队人员建设
• 参与极限开发时如何做管理，保证项目按时交付
• 从用户体验角度如何优化避免接口长时间的loading
• DevOps是如何建立的，做了哪些计划与安排
• 薪资期望（坦诚自己的一些预估，别表示愿意再聊，因为在目前这个薪资包范围下，小浮动我是不太在乎的）

这部分回答整体都没啥问题，本身也是我较为擅长的部分，几乎不用做太多准备。

另外延伸聊到了通勤时间看书效率低，都喜欢看纸质书，公司同事周边租房的一些现状。

最后面试官送我到了电梯口，帮我按了电梯，我便主动握手告别，算是结束了今天长达4小时的4轮面试。

次日补充，昨天还是写得过于乐观轻飘了。

这部分回答虽然是开放式的，但从一个管理问题出发，应该放在管理框架中系统性的进行回复，这样才能展现自己完整的管理经验。

团队scope要说清楚，以结果为导向的目标管理团队文化基调

人才盘点，根据什么盘点，如何确认招聘目标，招聘安排，面试安排，试用期安排，这都是自己做过的完整的流程

日常管理，人员安排，从知人善用出发，采用绩效考核，培训分享，以及自己在团队变大后的角色转变，团队成员单面能力超过我，我如何辅助他们做的更好，比如提拔为单方向负责人

项目管理，敏捷开发模式，需求评审，技术预研，工时审核，deadline模式下的区别管理

这中间会涉及到研发流程，CI等等，都可以提一下，有兴趣面试官自然会细问

自己在这个过程中做得比较好的就是带领团队整体完成从过程管理到目标管理的转变，取消了日报，改为了早晨共享今日todolist

最后引出自己的底层管理思维：为团队成员服务，通过团队去拿结果，减少成员工作的干扰

总结：乐观接受

• java侧针对基础技术还是要做为重点准备，对准备的每个点做做自我穷问，能有效发现自己那块儿忘记深入。
• Android侧 应用层知识不多，不需要花太多功夫，看看之前整理的文章就行
• 在DevOps侧要突出表现一些，多引导面试官了解这部分内容，本身自己对这块兴趣最大，思路比较完整。

虽然不一定100%能拿offer，但这次面试非常值，远超来回100多的车费了。

但是整体面下来节奏自己把握的还不错，自己掌握的东西基本都引导面试官进行了了解。针对面试没答上来的问题梳理下，觉得需要深入学的已经学习了，不需要深入学的暂时也不该花精力扎进去。

知识梳理完之后，也准备了不少的电子书和面试笔记等学习文档，这些笔记将各个知识点进行了完美的总结(包含了很多内容：Android 基础、Java 基础、Android 源码相关分析、常见的一些原理性问题等等)。

• Android 知识点汇总：https://qr18.cn/CyxarU
• 面试题笔记：https://qr18.cn/CgxrRy

服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net