Android开发经验谈Android技术知识Android面试

Android-面试官：性能优化我就问这些问题！能不能刷到我就看

2020-10-12  本文已影响0人  码农小陈

前言

如题，这是一篇关于Android面试-性能优化最常问的面试题、面试点的文章。这也是“Android-面试官”系列的第二篇文章。对Java模块比较薄弱的小伙伴可以去看一下我的上一篇文章：
Android-面试官：这些Java知识点我必问

好了，废话不多说，直接冲冲冲！

前排温馨提示：阅读本文前，请自备豆浆！

如果你已经有 2 - 3 年以上Android开发经验还不懂的怎么去优化自己的项目，那就有点说不过去了。无论是日常工作中还是跳槽面试的时候，性能优化都是我们打怪成长为一名优秀的高级开发工程师所必备的技能。下面是我总结了一套通用级别的 Android 性能优化知识点以及大小厂高频的性能优化面试真题。

一、APP启动优化

1、 你对 APP 的启动有过研究吗? 有做过相关的启动优化吗?

之前做热修复的时候研究过 Application 的启动原理。项目中也做过一些启动优化。

面试官:

哦，你之前研究过热修复? (这个时候有可能就会深入的问问热修复的原理，这里咱们就不讨论热修复原理) 那你说说对启动方面都做了哪些优化?

程序员：

Ps：这里会让面试官感觉你是一个注重用户体验的

Ps: 这里会让面试官感觉你对 App 应用的启动流程研究的比较深，有过真实的翻阅底层源码，而并不是背诵答案。

1、项目不及时需要的代码通过异步加载。
2、将对一些使用率不高的初始化，做懒加载。
3、将对一些耗时任务通过开启一个 IntentService来处理。
4、还通过 redex 重排列 class 文件，将启动阶段需要用到的文件在 APK 文件中排布在一起，尽可能的利用 Linux 文件系统的 pagecache 机制，用最少的磁盘 IO 次数，读取尽可能多的启动阶段需要的文件，减少 IO 开销，从而达到提升启动性能的目的。
5、通过抖音发布的文章知晓在 5.0 低版本可以做 MultiDex 优化，在第一次启动的时候，直接加载没有经过 OPT 优化的原始 DEX，先使得 APP 能够正常启动。然后在后台启动一个单独进程，慢慢地做完 DEX 的 OPT 工作，尽可能避免影响到前台 APP 的正常使用。

Ps：1. 面试官这里会觉得你对启动优化确实了解的不错，有一定的启动优化经验。
2.在第五点面试官会觉得你比较关注该圈子的动态，发现好的解决方案，并能用在自己项目上。这一点是加分项!

所以这一步除了要精简 XML 布局，还有对自定义 View 的测量，布局，绘制等函数不能有耗时和导致 GC 的操作。最后也可以通过 TreaceView 工具来检测这三个声明周期耗时时间，从而进一步优化，达到极限。

这一步给面试官的感觉你对整个 Activity 的启动和 View 的绘制还有刷新机制都有深入的研究，那么此刻你肯定给面试官留了一个好印象，说明你平时对这些源码级别的研究比较广泛，透彻。

最后我基于以上的优化减少了 50% 启动时间。

面试官:

嗯，研究的挺深的，源码平时不少看吧。

二、App稳定性优化

1、你们做了哪些稳定性方面的优化？

随着项目的逐渐成熟，用户基数逐渐增多，DAU持续升高，我们遇到了很多稳定性方面的问题，对于我们技术同学遇到了很多的挑战，用户经常使用我们的App卡顿或者是功能不可用，因此我们就针对稳定性开启了专项的优化，我们主要优化了三项：

通过这三方面的优化我们搭建了移动端的高可用平台。同时，也做了很多的措施来让App真正地实现了高可用。

2、性能稳定性是怎么做的？

我们针对启动速度，内存、布局加载、卡顿、瘦身、流量、电量等多个方面做了多维的优化。

我们的优化主要分为了两个层次，即线上和线下，针对于线下呢，我们侧重于发现问题，直接解决，将问题尽可能在上线之前解决为目的。而真正到了线上呢，我们最主要的目的就是为了监控，对于各个性能纬度的监控呢，可以让我们尽可能早地获取到异常情况的报警。

同时呢，对于线上最严重的性能问题性问题：Crash，我们做了专项的优化，不仅优化了Crash的具体指标，而且也尽可能地获取了Crash发生时的详细信息，结合后端的聚合、报警等功能，便于我们快速地定位问题。

3、业务稳定性如何保障？

移动端业务高可用它侧重于用户功能完整可用，主要是为了解决一些线上一些异常情况导致用户他虽然没有崩溃，也没有性能问题，但是呢，只是单纯的功能不可用的情况，我们需要对项目的主流程、核心路径进行埋点监控，来计算每一步它真实的转换率是多少，同时呢，还需要知道在每一步到底发生了多少异常。这样我们就知道了所有业务流程的转换率以及相应界面的转换率，有了大盘的数据呢，我们就知道了，如果转换率或者是某些监控的成功率低于某个值，那很有可能就是出现了线上异常，结合了相应的报警功能，我们就不需要等用户来反馈了，这个就是业务稳定性保障的基础。

同时呢，对于一些特殊情况，比如说，开发过程当中或代码中出现了一些catch代码块，捕获住了异常，让程序不崩溃，这其实是不合理的，程序虽然没有崩溃，当时程序的功能已经变得不可用，所以呢，这些被catch的异常我们也需要上报上来，这样我们才能知道用户到底出现了什么问题而导致的异常。此外，线上还有一些单点问题，比如说用户点击登录一直进不去，这种就属于单点问题，其实我们是无法找出其和其它问题的共性之处的，所以呢，我们就必须要找到它对应的详细信息。

最后，如果发生了异常情况，我们还采取了一系列措施进行快速止损。（=>4）

4、如果发生了异常情况，怎么快速止损？

首先，需要让App具备一些高级的能力，我们对于任何要上线的新功能，要加上一个功能的开关，通过配置中心下发的开关呢，来决定是否要显示新功能的入口。如果有异常情况，可以紧急关闭新功能的入口，那就可以让这个App处于可控的状态了。

然后，我们需要给App设立路由跳转，所有的界面跳转都需要通过路由来分发，如果我们匹配到需要跳转到有bug的这样一个新功能时，那我们就不跳转了，或者是跳转到统一的异常正处理中的界面。如果这两种方式都不可以，那就可以考虑通过热修复的方式来动态修复，目前热修复的方案其实已经比较成熟了，我们完全可以低成本地在我们的项目中添加热修复的能力，当然，如果有些功能是由RN或WeeX来实现就更好了，那就可以通过更新资源包的方式来实现动态更新。而这些如果都不可以的话呢，那就可以考虑自己去给应用加上一个自主修复的能力，如果App启动多次的话，那就可以考虑清空所有的缓存数据，将App重置到安装的状态，到了最严重的等级呢，可以阻塞主线程，此时一定要等App热修复成功之后才允许用户进入。

三、有做过相关的内存优化吗?

程序员:

有做过，目前的项目内存优化还是挺多的，要不我先说一下优化内存有什么好处吧？咱们不能盲目的去优化！

有的时候对于自己熟悉的领域，一定要主动出击，自己主导这场面试。

面试官:

可以。

Ps：这里大多数面试官会同意你的请求，除非遇见装B的。

程序员:

好处:

  1. 减少 OOM ，可以提高程序的稳定性。
  2. 减少卡顿，提高应用流畅性。
  3. 减少内存占用，提高应用后台存活性。
  4. 减少程序异常，降低应用 Crash 率, 提高稳定性。

那么我基于这四点，我的程序做了如下优化:

  1. 刷新原理:

View 的 requestLayout 和 ViewRootImpl##setView 最终都会调用 ViewRootImpl 的 requestLayout 方法，然后通过 scheduleTraversals 方法向 Choreographer 提交一个绘制任务，然后再通过 DisplayEventReceiver 向底层请求 vsync 垂直同步信号，当 vsync 信号来的时候，会通过 JNI 回调回来，在通过 Handler 往消息队列 post 一个异步任务，最终是 ViewRootImpl 去执行绘制任务，最后调用 performTraversals 方法，完成绘制。

详细流程可以参考下面流程图:

卡顿的根本原因:

从刷新原理来看卡顿的根本原理是有两个地方会造成掉帧:

一个是主线程有其它耗时操作，导致doFrame 没有机会在 vsync 信号发出之后 16 毫秒内调用；

还有一个就是当前doFrame方法耗时，绘制太久，下一个 vsync 信号来的时候这一帧还没画完，造成掉帧。

既然我们知道了卡顿的根本原因，那么我们就可以监控卡顿，从而可以对卡顿优化做到极致。我们可以从下面四个方面来监控应用程序卡顿:

  1. 基于 Looper 的 Printer 分发消息的时间差值来判断是否卡顿。
//1. 开启监听
  Looper.myLooper().setMessageLogging(new
                    LogPrinter(Log.DEBUG, "ActivityThread"));

//2. 只要分发消息那么就会在之前和之后分别打印消息
public static void loop() {
   final Looper me = myLooper();
   if (me == null) {
       throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");        }    final MessageQueue queue = me.mQueue;       ...

    for (;;) {
        Message msg = queue.next(); // might block
        ...
      //分发之前打印
      final Printer logging = me.mLogging;     if (logging != null) {        logging.println(">>>>> Dispatching to " + msg.target + " " +                        msg.callback + ": " + msg.what);      }

            ...
      try {
       //分发消息
       msg.target.dispatchMessage(msg);
            ...
      //分发之后打印
            if (logging != null) {
        logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
            }
        }
    }
  1. 基于 Choreographer 回调函数 postFrameCallback 来监控

  1. 基于开源框架 BlockCanary 来监控

  2. 基于开源框架 rabbit-client 来监控

怎么避免卡顿：

一定要避免在主线程中做耗时任务，总结一下 Android 中主线程的场景:

  1. UI 生命周期的控制

  2. 系统事件的处理

  3. 消息处理

  4. 界面布局

  5. 界面绘制

  6. 界面刷新

  7. ...

还有一个最重要的就是避免内存抖动，不要在短时间内频繁的内存分配和释放。

基于这几点去说卡顿肯定是没有问题的。

如果说出这些，再实际开发中举例说明一下怎么解决的应该是没有问题的。

歇会儿

四、App绘制优化

1、你在做布局优化的过程中用到了哪些工具？

我在做布局优化的过程中，用到了很多的工具，但是每一个工具都有它不同的使用场景，不同的场景应该使用不同的工具。下面我从线上和线下两个角度来进行分析。

比如说，我要统计线上的FPS，我使用的就是Choreographer这个类，它具有以下特性：

同时，在线下，如果要去优化布局加载带来的时间消耗，那就需要检测每一个布局的耗时，对此我使用的是AOP的方式，它没有侵入性，同时也不需要别的开发同学进行接入，就可以方便地获取每一个布局加载的耗时。如果还要更细粒度地去检测每一个控件的加载耗时，那么就需要使用LayoutInflaterCompat.setFactory2这个方法去进行Hook。

此外，我还使用了LayoutInspector和Systrace这两个工具，Systrace可以很方便地看到每帧的具体耗时以及这一帧在布局当中它真正做了什么。而LayoutInspector可以很方便地看到每一个界面的布局层级，帮助我们对层级进行优化。

2、布局为什么会导致卡顿，你又是如何优化的？

分析完布局的加载流程之后，我们发现有如下四点可能会导致布局卡顿：

对此，我们的优化方式有如下几种：

3、做完布局优化有哪些成果产出？

4、你是怎么做卡顿优化的？

从项目的初期到壮大期，最后再到成熟期，每一个阶段都针对卡顿优化做了不同的处理。各个阶段所做的事情如下所示：

我做卡顿优化也是经历了一些阶段，最初我们的项目当中的一些模块出现了卡顿之后，我是通过系统工具进行了定位，我使用了Systrace，然后看了卡顿周期内的CPU状况，同时结合代码，对这个模块进行了重构，将部分代码进行了异步和延迟，在项目初期就是这样解决了问题。但是呢，随着我们项目的扩大，线下卡顿的问题也越来越多，同时，在线上，也有卡顿的反馈，但是线上的反馈卡顿，我们在线下难以复现，于是我们开始寻找自动化的卡顿监测方案，其思路是来自于Android的消息处理机制，主线程执行任何代码都会回到Looper.loop方法当中，而这个方法中有一个mLogging对象，它会在每个message的执行前后都会被调用，我们就是利用这个前后处理的时机来做到的自动化监测方案的。同时，在这个阶段，我们也完善了线上ANR的上报，我们采取的方式就是监控ANR的信息，同时结合了ANR-WatchDog，作为高版本没有文件权限的一个补充方案。在做完这个卡顿检测方案之后呢，我们还做了线上监控及线下检测工具的建设，最终实现了一整套完善，多维度的解决方案。

5、你是怎么样自动化的获取卡顿信息？

我们的思路是来自于Android的消息处理机制，主线程执行任何代码它都会走到Looper.loop方法当中，而这个函数当中有一个mLogging对象，它会在每个message处理前后都会被调用，而主线程发生了卡顿，那就一定会在dispatchMessage方法中执行了耗时的代码，那我们在这个message执行之前呢，我们可以在子线程当中去postDelayed一个任务，这个Delayed的时间就是我们设定的阈值，如果主线程的messaege在这个阈值之内完成了，那就取消掉这个子线程当中的任务，如果主线程的message在阈值之内没有被完成，那子线程当中的任务就会被执行，它会获取到当前主线程执行的一个堆栈，那我们就可以知道哪里发生了卡顿。

经过实践，我们发现这种方案获取的堆栈信息它不一定是准确的，因为获取到的堆栈信息它很可能是主线程最终执行的一个位置，而真正耗时的地方其实已经执行完成了，于是呢，我们就对这个方案做了一些优化，我们采取了高频采集的方案，也就是在一个周期内我们会多次采集主线程的堆栈信息，如果发生了卡顿，那我们就将这些卡顿信息压缩之后上报给APM后台，然后找出重复的堆栈信息，这些重复发生的堆栈大概率就是卡顿发生的一个位置，这样就提高了获取卡顿信息的一个准确性。

6、卡顿的一整套解决方案是怎么做的？

首先，针对卡顿，我们采用了线上、线下工具相结合的方式，线下工具我们册中医药尽可能早地去暴露问题，而针对于线上工具呢，我们侧重于监控的全面性、自动化以及异常感知的灵敏度。

同时呢，卡顿问题还有很多的难题。比如说有的代码呢，它不到你卡顿的一个阈值，但是执行过多，或者它错误地执行了很多次，它也会导致用户感官上的一个卡顿，所以我们在线下通过AOP的方式对常见的耗时代码进行了Hook，然后对一段时间内获取到的数据进行分析，我们就可以知道这些耗时的代码发生的时机和次数以及耗时情况。然后，看它是不是满足我们的一个预期，不满足预期的话，我们就可以直接到线下进行修改。同时，卡顿监控它还有很多容易被忽略的一个盲区，比如说生命周期的一个间隔，那对于这种特定的问题呢，我们就采用了编译时注解的方式修改了项目当中所有Handler的父类，对于其中的两个方法进行了监控，我们就可以知道主线程message的执行时间以及它们的调用堆栈。

对于线上卡顿，我们除了计算App的卡顿率、ANR率等常规指标之外呢，我们还计算了页面的秒开率、生命周期的执行时间等等。而且，在卡顿发生的时刻，我们也尽可能多地保存下来了当前的一个场景信息，这为我们之后解决或者复现这个卡顿留下了依据。

五、说说你在项目中网络优化?

程序员:

有，这一点其实可以通过 OKHTTP 连接池和 Http 缓存来说一下(当然这里不会再展开分析 OKHTTP 源码了)

面试官:

那你具体说一下吧

程序员

移动端获取网络数据优化的几个点

说了这些之后，再说一下你当前使用网络框架它们做了哪些优化比如 OKHTTP(Socket 连接池、Http缓存、责任链)、Retrofit(动态代理)。说了这些一般这关也算是过了。

六、在项目中有用过哪些存储方式? 对它们的性能有过优化吗？

程序员:

主要用过 sp,File,SQLite 存储方式。其中对 sp 和 sqlite 做了优化。

面试官:

那你说说都做了哪些优化?

程序员:

这一块如果你使用过其它第三方的数据库，可以说说它们的原理和它们存取的方式。

七、用过自定义 View 吧？对它做过什么优化？

程序员:

有做过。比如重复绘制，还有大图长图有过优化。

面试官:

那具体说一说

程序员:

最后也是结合真实场景具体说一个。

如何优化自定义View？
为了加速你的view，对于频繁调用的方法，需要尽量减少不必要的代码。先从onDraw开始，需要特别注意不应该在这里做内存分配的事情，因为它会导致GC，从而导致卡顿。在初始化或者动画间隙期间做分配内存的动作。不要在动画正在执行的时候做内存分配的事情。

你还需要尽可能的减少onDraw被调用的次数，大多数时候导致onDraw都是因为调用了invalidate().因此请尽量减少调用invaildate()的次数。如果可能的话，尽量调用含有4个参数的invalidate()方法而不是没有参数的invalidate()。没有参数的invalidate会强制重绘整个view。

另外一个非常耗时的操作是请求layout。任何时候执行requestLayout()，会使得Android UI系统去遍历整个View的层级来计算出每一个view的大小。如果找到有冲突的值，它会需要重新计算好几次。另外需要尽量保持View的层级是扁平化的，这样对提高效率很有帮助。

如果你有一个复杂的UI，你应该考虑写一个自定义的ViewGroup来执行他的layout操作。与内置的view不同，自定义的view可以使得程序仅仅测量这一部分，这避免了遍历整个view的层级结构来计算大小。

八、有做过日志优化吗?

程序员:

有优化，在之前没有考虑任何性能的情况下，我是直接有 log 就写入文件，尽管我开了线程池去写文件，只要软件在运行那么就会频繁的使 CPU 进行工作。这也间接的导致了耗电。

传统日志打印有两个性能问题，一个是反复操作文件描述符表，一个是反复进入内核态。所以需要使用mmap的方式去直接读写内存。

面试官:

那你具体说一下，最后怎么解决这个问题的?

程序员:

展开上面这些点说明之后，面试官一般不会为难你。

九、做过 APK 体积相关的优化吗?

程序员:

有过优化，在没有优化之前项目的包体积大小是 80M,优化之后是 50M.

面试官:

说一说是怎么优化的

程序员:

基于这几点优化方案，一般都能解决 APK 体积问题。最后再把自己项目 APK 体积优化步骤结合上面点说一下就行。

十、为什么WebView加载会慢呢？

这是因为在客户端中，加载H5页面之前，需要先初始化WebView，在WebView完全初始化完成之前，后续的界面加载过程都是被阻塞的。

优化手段围绕着以下两个点进行：

因此常见的方法是：

除此之外还有一些其他的优化手段：

其实性能优化点都是息息相关的，比如卡顿会涉及内存、显示，启动也会涉及 APK dex 的影响。所以说性能优化不仅仅是单方面的优化，一定要掌握最基本的优化方案，才能更加深入探讨性能原理问题。

【360°全方位性能调优】
性能优化相关所有知识点已经为你们整理成了PDF，从理论着手，利用大量实战案例带你全方位掌握APP性能优化的各个知识点和思路，需要的小伙伴点赞+关注后简信【1】即可无偿获取~

文末

我一直觉得技术面试不是考试，考前背背题，发给你一张考卷，答完交卷等通知。

首先，技术面试是一个 认识自己 的过程，知道自己和外面世界的差距。

更重要的是，技术面试是一个双向了解的过程，要让对方发现你的闪光点，同时也要 试图去找到对方的闪光点，因为他以后可能就是你的同事或者领导，所以，面试官问你有什么问题的时候，不要说没有了，要去试图了解他的工作内容、了解这个团队的氛围。

找工作无非就是看三点：和什么人、做什么事、给多少钱，要给这三者在自己的心里划分一个比例。

最后，祝愿大家在这并不友好的环境下都能找到自己心仪的归宿！

感谢大家关注我，分享Android干货，交流Android技术。
对文章有何见解，或者有何技术问题，都可以在评论区一起留言讨论，我会虔诚为你解答。
也欢迎大家来我的B站找我玩，有各类Android架构师进阶技术难点的视频讲解，助你早日升职加薪。
B站直通车：https://space.bilibili.com/544650554

上一篇下一篇

猜你喜欢

热点阅读