Ps: 这里会让面试官感觉你对 App 应用的启动流程研究的比较深，有过真实的翻阅底层源码，而并不是背诵答案。
- 知道了 attachBaseContext 、onCreate 在应用中最先启动，那么我们就可以通过 TreceView 等性能检测工具，来检测具体函数耗时时间，然后来对其做具体的优化：
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.在第五点面试官会觉得你比较关注该圈子的动态，发现好的解决方案，并能用在自己项目上。这一点是加分项!
- Application 启动完之后，AMS 会找出前台栈顶待启动的 Activity , 最后也是通过 AIDL 通知 ActivityThread#H 来进行对 Activity 的实例化并依次执行生命周期
onCreate、onStart、onRemuse函数，那么这里由于 onCreate 生命周期中如果调用了setContentView函数，底层就会通过将 XML2View 那么这个过程肯定是耗时的。所以要精简 XML 布局代码，尽可能的使用ViewStub、include、merge标签来优化布局。接着在 onResume 声明周期中会请求 JNI 接收 Vsync (垂直同步刷新的信号) 请求，16ms 之后如果接收到了刷新的消息，那么就会对DecorView 进行 onMeasure->onLayout->onDraw绘制。最后才是将 Activity 的根布局 DecorView 添加到 Window 并交于 SurfaceFlinger 显示。
所以这一步除了要精简 XML 布局，还有对自定义 View 的测量，布局，绘制等函数不能有耗时和导致 GC 的操作。最后也可以通过 TreaceView 工具来检测这三个声明周期耗时时间，从而进一步优化，达到极限。
这一步给面试官的感觉你对整个 Activity 的启动和 View 的绘制还有刷新机制都有深入的研究，那么此刻你肯定给面试官留了一个好印象，说明你平时对这些源码级别的研究比较广泛，透彻。
最后我基于以上的优化减少了 50% 启动时间。
面试官:
嗯，研究的挺深的，源码平时不少看吧。
二、App稳定性优化
1、你们做了哪些稳定性方面的优化？
随着项目的逐渐成熟，用户基数逐渐增多，DAU持续升高，我们遇到了很多稳定性方面的问题，对于我们技术同学遇到了很多的挑战，用户经常使用我们的App卡顿或者是功能不可用，因此我们就针对稳定性开启了专项的优化，我们主要优化了三项：
-
Crash专项优化（=>2)
-
性能稳定性优化（=>2)
-
业务稳定性优化（=>3)
通过这三方面的优化我们搭建了移动端的高可用平台。同时，也做了很多的措施来让App真正地实现了高可用。
2、性能稳定性是怎么做的？
-
全面的性能优化：启动速度、内存优化、绘制优化
-
线下发现问题、优化为主
-
线上监控为主
-
Crash专项优化
我们针对启动速度，内存、布局加载、卡顿、瘦身、流量、电量等多个方面做了多维的优化。
我们的优化主要分为了两个层次，即线上和线下，针对于线下呢，我们侧重于发现问题，直接解决，将问题尽可能在上线之前解决为目的。而真正到了线上呢，我们最主要的目的就是为了监控，对于各个性能纬度的监控呢，可以让我们尽可能早地获取到异常情况的报警。
同时呢，对于线上最严重的性能问题性问题：Crash，我们做了专项的优化，不仅优化了Crash的具体指标，而且也尽可能地获取了Crash发生时的详细信息，结合后端的聚合、报警等功能，便于我们快速地定位问题。
3、业务稳定性如何保障？
-
数据采集 + 报警
-
需要对项目的主流程与核心路径进行埋点监控，
-
同时还需知道每一步发生了多少异常，这样，我们就知道了所有业务流程的转换率以及相应界面的转换率
-
结合大盘，如果转换率低于某个值，进行报警
-
异常监控 + 单点追查
-
兜底策略
移动端业务高可用它侧重于用户功能完整可用，主要是为了解决一些线上一些异常情况导致用户他虽然没有崩溃，也没有性能问题，但是呢，只是单纯的功能不可用的情况，我们需要对项目的主流程、核心路径进行埋点监控，来计算每一步它真实的转换率是多少，同时呢，还需要知道在每一步到底发生了多少异常。这样我们就知道了所有业务流程的转换率以及相应界面的转换率，有了大盘的数据呢，我们就知道了，如果转换率或者是某些监控的成功率低于某个值，那很有可能就是出现了线上异常，结合了相应的报警功能，我们就不需要等用户来反馈了，这个就是业务稳定性保障的基础。
同时呢，对于一些特殊情况，比如说，开发过程当中或代码中出现了一些catch代码块，捕获住了异常，让程序不崩溃，这其实是不合理的，程序虽然没有崩溃，当时程序的功能已经变得不可用，所以呢，这些被catch的异常我们也需要上报上来，这样我们才能知道用户到底出现了什么问题而导致的异常。此外，线上还有一些单点问题，比如说用户点击登录一直进不去，这种就属于单点问题，其实我们是无法找出其和其它问题的共性之处的，所以呢，我们就必须要找到它对应的详细信息。
最后，如果发生了异常情况，我们还采取了一系列措施进行快速止损。（=>4）
4、如果发生了异常情况，怎么快速止损？
-
功能开关
-
统跳中心
-
动态修复：热修复、资源包更新
-
自主修复：安全模式
首先，需要让App具备一些高级的能力，我们对于任何要上线的新功能，要加上一个功能的开关，通过配置中心下发的开关呢，来决定是否要显示新功能的入口。如果有异常情况，可以紧急关闭新功能的入口，那就可以让这个App处于可控的状态了。
然后，我们需要给App设立路由跳转，所有的界面跳转都需要通过路由来分发，如果我们匹配到需要跳转到有bug的这样一个新功能时，那我们就不跳转了，或者是跳转到统一的异常正处理中的界面。如果这两种方式都不可以，那就可以考虑通过热修复的方式来动态修复，目前热修复的方案其实已经比较成熟了，我们完全可以低成本地在我们的项目中添加热修复的能力，当然，如果有些功能是由RN或WeeX来实现就更好了，那就可以通过更新资源包的方式来实现动态更新。而这些如果都不可以的话呢，那就可以考虑自己去给应用加上一个自主修复的能力，如果App启动多次的话，那就可以考虑清空所有的缓存数据，将App重置到安装的状态，到了最严重的等级呢，可以阻塞主线程，此时一定要等App热修复成功之后才允许用户进入。
三、有做过相关的内存优化吗?
程序员:
有做过，目前的项目内存优化还是挺多的，要不我先说一下优化内存有什么好处吧？咱们不能盲目的去优化！
有的时候对于自己熟悉的领域，一定要主动出击，自己主导这场面试。
面试官:
可以。
Ps：这里大多数面试官会同意你的请求，除非遇见装B的。
程序员:
好处:
-
减少 OOM ，可以提高程序的稳定性。
-
减少卡顿，提高应用流畅性。
-
减少内存占用，提高应用后台存活性。
-
减少程序异常，降低应用 Crash 率, 提高稳定性。
那么我基于这四点，我的程序做了如下优化:
- 1.减少 OOM
在应用开发阶段我比较喜欢用 LeakCanary 这款性能检测工具，好处是它能实时的告诉我具体哪个类发现了内存泄漏(如果你对 LeakCanary 的原理了解的话，可以说一说它是怎么检测的)。
还有我们要明白为什么应用程序会发送 OOM ，又该怎么去避免它？
发生 OOM 的场景是当申请 1M 的内存空间时，如果你要往该内存空间存入 2M 的数据，那么此时就会发生 OOM。
在应用程序中我们不仅要避免直接导致 OOM 的场景还要避免间接导致 OOM 的场景。间接的话也就是要避免内存泄漏的场景。
内存泄漏的场景是这个对象不再使用时，应用完整的执行最后的生命周期，但是由于某些原因，对象虽然已经不再使用，仍然会在内存中存在而导致 GC 不会去回收它，这就意味着发生了内存泄漏。(这里可以介绍下 GC 回收机制，回收算法，知识点尽量往外扩展而不脱离本题)
最后在说一下在实际开发中避免内存泄漏的场景:
-
资源型对象未关闭: Cursor,File
-
注册对象未销毁: 广播，回调监听
-
类的静态变量持有大数据对象
-
非静态内部类的静态实例
-
Handler 临时性内存泄漏: 使用静态 + 弱引用，退出即销毁
-
容器中的对象没清理造成的内存泄漏
-
WebView: 使用单独进程
其实这些都是基础，把它记下就行了。记得多了在实际开发中就有印象了。
- 2.减少卡顿
怎么减少卡顿? 那么我们可以从 2 个原理方面来探讨卡顿的根本原因，第一个原理方面是绘制原理，另一个就是刷新原理。
- 绘制原理:
- 刷新原理:
View 的 requestLayout 和 ViewRootImpl##setView 最终都会调用 ViewRootImpl 的 requestLayout 方法，然后通过 scheduleTraversals 方法向 Choreographer 提交一个绘制任务，然后再通过 DisplayEventReceiver 向底层请求 vsync 垂直同步信号，当 vsync 信号来的时候，会通过 JNI 回调回来，在通过 Handler 往消息队列 post 一个异步任务，最终是 ViewRootImpl 去执行绘制任务，最后调用 performTraversals 方法，完成绘制。
详细流程可以参考下面流程图:
卡顿的根本原因:
从刷新原理来看卡顿的根本原理是有两个地方会造成掉帧:
一个是主线程有其它耗时操作，导致doFrame 没有机会在 vsync 信号发出之后 16 毫秒内调用；
还有一个就是当前doFrame方法耗时，绘制太久，下一个 vsync 信号来的时候这一帧还没画完，造成掉帧。
既然我们知道了卡顿的根本原因，那么我们就可以监控卡顿，从而可以对卡顿优化做到极致。我们可以从下面四个方面来监控应用程序卡顿:
- 基于 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);
}
}
}
- 基于 Choreographer 回调函数 postFrameCallback 来监控
-
基于开源框架 BlockCanary 来监控
-
基于开源框架 rabbit-client 来监控
怎么避免卡顿：
一定要避免在主线程中做耗时任务，总结一下 Android 中主线程的场景:
-
UI 生命周期的控制
-
系统事件的处理
-
消息处理
-
界面布局
-
界面绘制
-
界面刷新
-
…
还有一个最重要的就是避免内存抖动，不要在短时间内频繁的内存分配和释放。
基于这几点去说卡顿肯定是没有问题的。
- 3.减少内存占用
可以从如下几个方面去展开说明:
-
AutoBoxing(自动装箱): 能用小的坚决不用大的。
-
内存复用
-
使用最优的数据类型
-
枚举类型: 使用注解枚举限制替换 Enum
-
图片内存优化（这里可以从 Glide 等开源框架去说下它们是怎么设计的）
-
选择合适的位图格式
-
bitmap 内存复用，压缩
学习福利
【Android 详细知识点思维脑图（技能树）】
其实Android开发的知识点就那么多，面试问来问去还是那么点东西。所以面试没有其他的诀窍，只看你对这些知识点准备的充分程度。so，出去面试时先看看自己复习到了哪个阶段就好。
虽然 Android 没有前几年火热了，已经过去了会四大组件就能找到高薪职位的时代了。这只能说明 Android 中级以下的岗位饱和了，现在高级工程师还是比较缺少的，很多高级职位给的薪资真的特别高（钱多也不一定能找到合适的），所以努力让自己成为高级工程师才是最重要的。
这里附上上述的面试题相关的几十套字节跳动，京东，小米，腾讯、头条、阿里、美团等公司19年的面试题。把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。
由于篇幅有限，这里以图片的形式给大家展示一小部分。
详细整理在GitHub可以见；
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级安卓工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Android移动开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Android）
经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。**
深知大多数初中级安卓工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Android移动开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
[外链图片转存中…(img-GdUmGMVf-1711015575554)]
[外链图片转存中…(img-JRa9Lpoz-1711015575555)]
[外链图片转存中…(img-lszaFqAG-1711015575555)]
[外链图片转存中…(img-InunTVOV-1711015575555)]
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Android）
[外链图片转存中…(img-BgrOtXol-1711015575556)]
1507
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
