一个三非渣本的Android校招秋招之路，一线互联网公司面经总结

最新推荐文章于 2024-03-23 02:28:20 发布

左夜天

最新推荐文章于 2024-03-23 02:28:20 发布

阅读量83

点赞数

分类专栏：程序员文章标签： android

本文链接：https://blog.csdn.net/pkpir/article/details/115790242

版权

程序员专栏收录该内容

1014 篇文章 1 订阅

订阅专栏

背景

小程序从首次发布至今，经过了几十个版本的迭代。随着业务发展，页面功能内容的不断增多，相关性能数据不断变差，核心性能数据 FMP 长期处在 2000ms 以上。

在该项目之前，我们团队也对小程序做了一定的性能调优工作，内容包括：

包体积优化，去除了不少引用在项目中的图片素材文件，将包体积优化至 500kb 以下；
联合后端对耗时较高的业务接口做优化，单个接口返回速度需要控制在 100ms 左右；
优化了部分业务逻辑，小程序启动时减少了一些不必要的操作逻辑；
使用了小程序框架提供的最新生命周期 onInit ，可提前 100ms 左右发起业务网络请求；
使用 prelink 预连接网络，提升数据接口的请求效率。

经过上述手段之后，FMP 降到了 1900ms 左右，后续再也无法产生优化效果。

以上优化手段，基本排除了网络连接，包体积优化不到位引起的性能不佳。那么我们就只有一个问题需要仔细排查 —— 内容的渲染效率。

一、Android基础

Android基础知识点比较多，看图。

建议阅读：

《Android开发艺术探索》

1. Activity

# Activity的四大启动模式，以及应用场景？

Activity的四大启动模式：

standard：标准模式，每次都会在活动栈中生成一个新的Activity实例。通常我们使用的活动都是标准模式。
singleTop：栈顶复用，如果Activity实例已经存在栈顶，那么就不会在活动栈中创建新的实例。比较常见的场景就是给通知跳转的Activity设置，因为你肯定不想前台Activity已经是该Activity的情况下，点击通知，又给你再创建一个同样的Activity。
singleTask：栈内复用，如果Activity实例在当前栈中已经存在，就会将当前Activity实例上面的其他Activity实例都移除栈。常见于跳转到主界面。
singleInstance：单实例模式，创建一个新的任务栈，这个活动实例独自处在这个活动栈中。

# Activity中onStart和onResume的区别？onPause和onStop的区别？

首先，Activity有三类：

前台Activity：活跃的Activity，正在和用户交互的Activity。
可见但非前台的Activity：常见于栈顶的Activity背景透明，处在其下面的Activity就是可见但是不可和用户交互。
后台Activity：已经被暂停的Activity，比如已经执行了onStop方法。

所以，onStart和onStop通常指的是当前活动是否位于前台这个角度，而onResume和onPause从是否可见这个角度来讲的。

2. 屏幕适配

# 平时如何有使用屏幕适配吗？原理是什么呢？

平时的屏幕适配一般采用的头条的屏幕适配方案。简单来说，以屏幕的一边作为适配，通常是宽。

原理：设备像素px和设备独立像素dp之间的关系是

px = dp * density

假设UI给的设计图屏幕宽度基于360dp，那么设备宽的像素点已知，即px，dp也已知，360dp，所以density = px / dp，之后根据这个修改系统中跟density相关的知识点即可。

3. Android消息机制

# Android消息机制介绍？

Android消息机制中的四大概念：

ThreadLocal：当前线程存储的数据仅能从当前线程取出。
MessageQueue：具有时间优先级的消息队列。
Looper：轮询消息队列，看是否有新的消息到来。
Handler：具体处理逻辑的地方。

过程：

准备工作：创建Handler，如果是在子线程中创建，还需要调用Looper#prepare()，在Handler的构造函数中，会绑定其中的Looper和MessageQueue。
发送消息：创建消息，使用Handler发送。
进入MessageQueue：因为Handler中绑定着消息队列，所以Message很自然的被放进消息队列。
Looper轮询消息队列：Looper是一个死循环，一直观察有没有新的消息到来，之后从Message取出绑定的Handler，最后调用Handler中的处理逻辑，这一切都发生在Looper循环的线程，这也是Handler能够在指定线程处理任务的原因。

# Looper在主线程中死循环为什么没有导致界面的卡死？

导致卡死的是在Ui线程中执行耗时操作导致界面出现掉帧，甚至ANR，Looper.loop()这个操作本身不会导致这个情况。
有人可能会说，我在点击事件中设置死循环会导致界面卡死，同样都是死循环，不都一样的吗？Looper会在没有消息的时候阻塞当前线程，释放CPU资源，等到有消息到来的时候，再唤醒主线程。
App进程中是需要死循环的，如果循环结束的话，App进程就结束了。

# IdleHandler介绍？

介绍： IdleHandler是在Hanlder空闲时处理空闲任务的一种机制。

执行场景：

MessageQueue没有消息，队列为空的时候。
MessageQueue属于延迟消息，当前没有消息执行的时候。

会不会发生死循环：答案是否定的，MessageQueue使用计数的方法保证一次调用MessageQueue#next方法只会使用一次的IdleHandler集合。

4. View事件分发机制和View绘制原理

刚哥的《Android开发艺术探索》已经很全面了，建议阅读。

5. Bitmap

# Bitmap的内存计算方式？

在已知图片的长和宽的像素的情况下，影响内存大小的因素会有资源文件位置和像素点大小。

像素点大小：常见的像素点有：

ARGB_8888：4个字节
ARGB_4444、ARGB_565：2个字节

资源文件位置：不同dpi对应存放的文件夹

比如一个一张图片的像素为180*180px，dpi(设备独立像素密度)为320，如果它仅仅存放在drawable-hdpi，则有：

横向像素点 = 180 * 320/240 + 0.5f = 240 px
纵向像素点 = 180 * 320/240 + 0.5f = 240 px

如果如果它仅仅存放在drawable-xxhdpi，则有：

横向像素点 = 180 * 320/480 + 0.5f = 120 px
纵向像素点 = 180 * 320/480 + 0.5f = 120 px

所以，对于一张180*180px的图片，设备dpi为320，资源图片仅仅存在drawable-hdpi，像素点大小为ARGB_4444，最后生成的文件内存大小为：

横向像素点 = 180 * 320/240 + 0.5f = 240 px
纵向像素点 = 180 * 320/240 + 0.5f = 240 px
内存大小 = 240 * 240 * 2 = 115200byte 约等于 112.5kb

# Bitmap的高效加载？

Bitmap的高效加载在Glide中也用到了，思路：

获取需要的长和宽，一般获取控件的长和宽。
设置BitmapFactory.Options中的inJustDecodeBounds为true，可以帮助我们在不加载进内存的方式获得Bitmap的长和宽。
对需要的长和宽和Bitmap的长和宽进行对比，从而获得压缩比例，放入BitmapFactory.Options中的inSampleSize属性。
设置BitmapFactory.Options中的inJustDecodeBounds为false，将图片加载进内存，进而设置到控件中。

二、Android进阶

Android进阶中重点考察Android Framework、性能优化和第三方框架。

1. Binder

# Binder的介绍？与其他IPC方式的优缺点？

Binder是Android中特有的IPC方式，引用《Android开发艺术探索》中的话(略有改动)：

从IPC角度来说，Binder是Android中的一种跨进程通信方式；Binder还可以理解为虚拟的物理设备，它的设备驱动是/dev/binder；从Android Framework来讲，Binder是Service Manager连接各种Manager和对应的ManagerService的桥梁。从面向对象和CS模型来讲，Client通过Binder和远程的Server进行通讯。

基于Binder，Android还实现了其他的IPC方式，比如AIDL、Messenger和ContentProvider。

与其他IPC比较：