Activity中的几种启动模式

activity的几种启动模式是android中常考的知识点，一般会考察有哪几种启动模式，以及每种启动模式在什么场景下使用：

standard:这个是android默认的Activity启动模式，每启动一个Activity都会被实例化一个Activity，并且新创建的Activity在堆栈中会在栈顶。

singleTop:如果当前要启动的Activity就是在栈顶的位置，那么此时就会复用该Activity，并且不会重走onCreate方法，会直接它的onNewIntent方法，如果不在栈顶，就跟standard一样的。如果当前activity已经在前台显示着，突然来了一条推送消息，此时不想让接收推送的消息的activity再次创建，那么此时正好可以用该启动模式，如果之前activity栈中是A–>B–>C如果点击了推动的消息还是A–>B–C，不过此时C是不会再次创建的，而是调用C的onNewIntent。而如果现在activity中栈是A–>C–>B，再次打开推送的消息，此时跟正常的启动C就没啥区别了，当前栈中就是A–>C–>B–>C了。

singleTask:该种情况下就比singleTop厉害了，不管在不在栈顶，在Activity的堆栈中永远保持一个。这种启动模式相对于singleTop而言是更加直接，比如之前activity栈中有A–>B–>C—D，再次打开了B的时候，在B上面的activity都会从activity栈中被移除。下面的acitivity还是不用管，所以此时栈中是A–>B，一般项目中主页面用到该启动模式。

singleInstance:该种情况就用得比较少了，主要是指在该activity永远只在一个单独的栈中。一旦该模式的activity的实例已经存在于某个栈中，任何应用在激活该activity时都会重用该栈中的实例，解决了多个task共享一个activity。其余的基本和上面的singleTask保持一致。

上面的各种启动模式主要是通过配置清单文件，常见还有在代码中设置flag也能实现上面的功能：

FLAG_ACTIVITY_CLEAR_TOP：这种启动的话，只能单纯地清空栈上面的acivity，而自己会重新被创建一次，如果当前栈中有A–>B–>C这几种情况，重新打开B之后，此时栈会变成了A–>B，但是此时B会被重新创建，不会走B的onNewIntent方法。这就是单独使用FLAG_ACTIVITY_CLEAR_TOP的用处，能清空栈上面的activity，但是自己会重新创建。

如果在上面的基础上再加上FLAG_ACTIVITY_SINGLE_TOP此时就不重新创建B了，也就直接走B的onNewIntent。它两者结合着使用就相当于上面的singleTask模式。如果只是单独的使用FLAG_ACTIVITY_SINGLE_TOP跟上面的singleTop就没啥区别了。

FLAG_ACTIVITY_CLEAR_TOP+FLAG_ACTIVITY_SINGLE_TOP=singleTask,此时要打开的activity不会被重建，只是走onNewIntent方法。

FLAG_ACTIVITY_SINGLE_TOP=singleTop

FLAG_ACTIVITY_NEW_TASK

• 在相同taskAffinity情况下：启动activity是没有任何作用的。

• 在不同taskAffinity情况下：如果启动不同栈中的activity已经存在了某一个栈中的activity，那么此时是启动不了该activity的，因为栈中已经存在了该activity；如果栈中不存在该要启动的activity，那么会启动该acvitity，并且将该activity放入该栈中。

FLAG_ACTIVITY_NEW_TASK和FLAG_ACTIVITY_CLEAR_TOP一起使用，并且要启动的activity的taskAffinity和当前activity的taskAffinity不一样才会和singleTask一样的效果，因为要启动的activity和原先的activity不在同一个taskAffinity中，所以能启动该activity，这个地方有点绕，写个简单的公式:

• FLAG_ACTIVITY_NEW_TASK如果启动同一个不同taskAffinity的activity才会有效果。

• FLAG_ACTIVITY_NEW_TASK和FLAG_ACTIVITY_CLEAR_TOP如果一起使用要开启的activity和现在的activity处于同一个taskAffinity，那么效果还是跟没加FLAG_ACTIVITY_NEW_TASK是一样的效果。

• FLAG_ACTIVITY_NEW_TASK和FLAG_ACTIVITY_CLEAR_TOP启动和现在的activity不是同一个taskAffinity才会和singleTask一样的效果。

FLAG_ACTIVITY_CLEAR_TASK

• 在相同taskAffinity情况下：和FLAG_ACTIVITY_NEW_TASK一起使用，启动activity是没有任何作用的。

• 在不同taskAffinity情况下：和FLAG_ACTIVITY_NEW_TASK一起使用，如果要启动的activity不存在栈中，那么启动该acitivity，并且将该activity放入该栈中，如果该activity已经存在于该栈中，那么会把当前栈中的activity先移除掉，然后再将该activity放入新的栈中。

FLAG_ACTIVITY_NEW_TASK+FLAG_ACTIVITY_SINGLE_TOP 用在当app正在运行点击push消息进到某个activity中的时候，如果当前处于该activity，此时会触发activity的onNewIntent。

FLAG_ACTIVITY_NEW_TASK+FLAG_ACTIVITY_CLEAR_TOP用在app没在运行中，启动主页的activity，然后在相应的activity中做相应的activity跳转。

Android消息机制

消息机制指Handler、Looper、MessageQueue、Message之间如何工作的。

• handler是用来处理消息和接收消息的中间者，handler的创建会伴随着handler中产生looper和MessageQueue，handler依赖于looper，looper依赖于MessageQueue，所以在子线程中使用handler抛出异常是因为子线程中没有初始化looper对象，而主线程中looper是在ActivityThread中已经初始化过了，所以能直接在主线程中能拿到Handler。

• Looper是用来轮询消息，说白了就是通过loop方法实现死循环，有消息的时候，通过MessageQueue.next方法取出message，没有消息的时候，线程处于阻塞的状态。在有消息的时候获取到消息，将消息交给了handler，handler会根据消息中有没有callback，如果有callback会直接callback，否则通过handleMessage处理。

• MessageQueue是一个单链表结构来存储Message，每次通过next方法取出Message消息后，取完之后将message.next给当前的message，再将message.next=null，实际上就是移除当前的message。但是在looper里面每次在next取出message后，放到了message的sPool里面，缓存起来方便使用。

• Message就没什么好说的，主要存储平常经常用的obj和what信息，以及我们不用关心的target和callback等。

这里会问到，一个线程会有几个Looper，几个Handler，以及Looper会存在线程哪里？

一个线程一个Looper，可以有多个Handler，Looper会存在线程的ThreadLocal对象里，该对象是线程的缓存区

ThreadLocal:它是和线程一一对应的，从Thread类可以看出来，ThreadLocal是作为Thread变量来使用。ThreadLocal只是ThreadLocalMap的一个包装类，实现了get和set方法，而ThreadLocalMap实际是一个由Entry内部类组成的数组，Entry是继承自弱应用，弱引用里面放的就是ThreadLocal当前对象，Entry的value存的是当前线程要存储的对象，value作为Entry的成员变量。

ThreadLocal经常会问到内存泄漏的问题，从上面分析可以发现ThreadLocalMap里面的Entry对象存储的ThreadLocal弱引用，而value直接作为Entry的强引用，因此在用到了ThreadLocal的地方，防止内存泄漏，手动调用remove方法。

IntentService

IntentService是google在原生的Service基础上通过创建子线程的Service。也就是说IntentService是专门为android开发者提供的能在service内部实现耗时操作的service。我们可以通过重写onHandleIntent方法实现耗时操作的回调处理，而且IntentService在耗时操作完成后，会主动销毁自己，IntentService可以通过多次启动来完成多个任务，而IntentService只会被创建一次，每次启动的时候只会触发onStart方法。内部是实现了Handler异步处理耗时操作的过程，一般多用在Service中需要处理耗时操作的功能。

提问：为什么IntentService中能实现耗时操作?

• 在onCreate中，通过HandlerThread来开启一条线程，而HandlerThread线程中会跟我们平常用的Handler不太一样，在run方法中创建了looper对象，所以HandlerThread能让IntentService在子线程中使用handler达到耗时操作。

HandlerThread

HandlerThread本身也是Thread，只是在Thread基础上封装上了Handler的载体，并且在run方法中创建了looper对象，这也是为什么在IntentService中能在HandlerThread中直接用handler的原因。而我们知道一个线程是可以有多个handler，所以用HandlerThread更加方便我们不用关心Handler的创建，一般用在多线程中直接处理任务。

事件分发

事件分发主要分三块:分发、拦截、消费； 当我们触摸到屏幕的时候，默认会先走Activity的分发，接着走ViewGroup的分发，然后到ViewGroup的拦截，后面再到View的分发事件，最后会传到View的消费事件，如果View不消费，紧接着回传到ViewGroup的消费事件，如果ViewGroup也不消费，最后回到View的消费事件。整个事件分发构成了一个u型结构，下面总结了分发的细节流程：

• 如果ViewGroup的dispatchTouchEvent返回true或false，touch事件不会往子view中传递，false的时候只会触发action_down，ViewGroup的onTouchEvent事件也不会被触发。只有在返回super.dispatchTouchEvent时候touch事件才会传递到子view。

• 如果ViewGroup的onInterceptTouchEvent返回false或者super.onInterceptTouchEvent时，touch事件会传递到子view。返回true事件不会向下传递，交给自己的ontouchEvent处理。

• 如果view的dispatchTouchEvent返回true或false，touch事件不会传给自己的ontouchEvent事件，返回false，只会触发action_down，move和up不会触发；返回true，才会触发move和up。返回super.dispatchTouchEvent，touch事件才会交给自己的onTouchEvent处理。

• 如果view的ontouchEvent返回false，只会有action_down事件，touch事件交给上一层处理，如果返回true才会消费，事件不会向上传递，如果返回super.ontouchEvent，得看clickable是不是返回true。

这里会问到事件冲突的问题？

事件遵循一个原则，就是看他有没有事件消费。比如一个LinearLayout里面有一个Button，点击LinearLayout会触发到Button吗，这里就看LinearLayout有没有设置点击事件，如果有就不会传递到Button，如果没有就会传递给Button。

Android性能优化、内存优化

性能优化:可以从界面、apk瘦身、混淆说起，dex分包处理，插件化动态加载模块，开屏冷启动说起

界面优化：多可以使用include、merge、ViewStub、约束布局来做起，include可以提取公共的布局，merge可以减少布局层次、ViewStub是使用的时候才去创建View，减少空间的占用、约束布局一来可以减少布局的层次、二来可以提高开发的效率，在自定义view中注意view绘制过程不要做初始化的操作，一般放到view的初始化的方法里面。

apk瘦身：可以用android studio的lint检测工具检测资源文件等

混淆：可以起到文件大小减少的作用，这个在实践中可以尝试，混淆后可以反编译看看apk包的内容

dex分包：主要是apk包的结构发生了变化，如果dex包的方法数超过了最大数，需要进行分包处理

插件化：主要用到了java中动态代理模式和反射的思想，利用android的activity启动流程，通过动态代理模式动态加载我们需要插件化的activity

开屏冷启动：开屏冷启动主要针对MultiDex启动做优化，在5.0之前对dex分包是不做处理的，所以要兼容到低版本的时候需要使用MultiDex.install做兼容。而MutiDex.install将apk中的dex包获取到，然后又压缩成对应的zip文件，将dex文件通过反射转换成DexFile对象、反射替换数组。所以我们能做的优化可以通过判断如果jvm不支持dex分包处理，通过MutiDex.install做处理，通过监听MutiDex.install开启一个监听MutiDex.install的进程activity。等到MutiDex.install处理完成后，再来处理正常的逻辑。

内存优化

内存优化通常指的内存溢出，主要涉及到的问题还是该释放的资源，没有及时让GC处理器回收，通常主要表现是动画、上下文对象、EventBus、AsycTask、Handler、单例Bitmap都会影响，通常要做的是释放他们未终止的动作，释放锁定的上下文对象。

在实际项目有mvp架构的时候，需要注意内存泄漏的问题，p层如果长期持有v层的实例，导致v层的对象难以回收，而v层一般是activity或fragment作为抽象，因此需要在p层使用v层的弱应用或是在p层中实现v层的销毁方法，处理销毁的逻辑。

View的绘制

activity界面显示流程:activity启动后，不会立马去显示界面上的view，而是等到onResume的时候才会真正显示view的时机，首先会触发windowManager.addView方法，在该方法中触发代理对象WindowManagerGlobal的addView方法，代理对象的addView方法中创建了viewRootImpl，将setContentView中创建的decorView通过viewRootImpl的setView方法放到了viewRootImpl中，最终经过viewRootImpl一系列的方法最终调用performTraversals方法。

view的绘制:主要指view的onMeasure、onLayout、onDraw几个方法，其实要了解几个方法，需要追溯到android中本身界面的结构，首先整体是一个PhoneWindow的对象，然后是一个DecorView，DecorView里面包括一个ViewStub的ToolBar，然后下面是一个FramLayout，也就是我们经常在Activity中setContentView中的content内容。说完了android界面的结构，下面就是说下如何绘制的，绘制首先是触发到DecorView的onMeasure方法，它的测量规则包含了手机屏的宽高，并且测量模式是MeasureSpec.EXACTLY。所以这里明白了DecorView(FrameLayout)的测量参数是什么意思了，紧接着就是测量它下面的ViewGroup了，其中ViewGroup里面有个measureChild方法去测量孩子，这里会问到几种父布局的测量模式和子View的测量模式组合:

| ViewGroup的测量mode | MeasureSpec.EXACTLY | MeasureSpec.AT_MOST | MeasureSpec.UNSPECIFIED |

| — | — | — | — |

| childDimension>0 | size=childDimension;mode=EXACTLY | size= childDimension;mode=EXACTLY | size= childDimension;mode=EXACTLY |

| childDimension == LayoutParams.MATCH_PARENT | size=Viewgroup的size;mode=EXACTLY | size=Viewgroup的size;mode=AT_MOST | size=Viewgroup的size;mode=UNSPECIFIED |

| childDimension == LayoutParams.WRAP_CONTENT | size=Viewgroup的size;mode=AT_MOST | size=Viewgroup的size;mode=AT_MOST | size=Viewgroup的size;mode=UNSPECIFIED |

测量处理完了之后，紧接着就是View的onLayout，其中onLayout的作用是给View固定好位置，该方法传进来的几个参数是相对于自己的parent的位置，左上角是(0,0)的坐标。最后就是我们的onDraw，该方法是我们需要在画布上画东西的方法，一般包括画背景、画图层等等。

App启动流程

• 从Linux内核系统到init进程的分裂，以及后面会启动一个叫Zygote的进程开始，而Zygote会分裂出系统的核心服务进程SystemServer，也就是SystemServer里面包括了底层的ActivityManagerService、PackageManagerService、WindowManagerService等，这些核心服务都是通过Zygote.init启动的，ActivityManagerService就是我们后面通过binder的ipc通信机制来与客户端ActivityThread建立通信的。

• 当我们点击了应用之后，系统的Launcher应用会通过startActivity的方式启动应用，而Intent的获取会经过如下几部:

(1) ActivityManagerService会通过PackageManager的resolveIntent()收集这个intent对象的指向信息。

(2)指向信息被存储在一个intent对象中。

(3)下面重要的一步是通过grantUriPermissionLocked()方法来验证用户是否有足够的权限去调用该intent对象指向的Activity。

(4)如果有权限, ActivityManagerService会检查并在新的task中启动目标activity.

(5)现在, 是时候检查这个进程的ProcessRecord是否存在了。

• 所以如果ProcessRecord不是null，ActivityManagerService会创建新的进程来实例化该activity。

• ActivityManagerService调用startProcessLocked()方法来创建新的进程, 该方法会通过前面讲到的socket通道传递参数给Zygote进程. Zygote孵化自身, 并调用ZygoteInit.main()方法来实例化ActivityThread对象并最终返回新进程的pid。

• 随后就是我们熟悉的ActivityThread.main方法通过Looper.prepare和Looper.loop方法开启消息循环

• 紧接着就是创建Application对象的过程，先是创建好ContextImpl对象，然后通过makeApplication方法将app进程与Application建立联系，这里的Application创建交给了Instrumentation的对象，其实后面activity的创建，生命周期的回调都是通过它来触发的。

• 创建完Application后，紧接着就是我们熟悉的Activity，activity的创建同样交给了Instrumentation对象，上面说过ActivityManagerService会将携带的Intent对象交给了Lanucher应用，Lanucher的startActivity经过一系列的操作，最终会走Instrumentation的execStartActivity方法，该方法里面会去请求ActivityManagerService服务，最终通过binder通信将信息传给了客户端的ApplicationThread，最终会触发ApplicationThread的scheduleLaunchActivity方法，该方法将消息发送给了ActivityThread的handler对象，最终交给了Instrumentation对象创建activity。后面也就触发一系列的生命周期方法。

Eventbus原理

EventBus是一款在android开发中使用的发布/订阅事件的总线框架，基于观察者模式，将事件的接收者和发送者分开，基本包括了如下几个步骤:

注册事件的订阅方法:该步骤主要是找到订阅者下面有哪些方法需要被订阅

订阅操作:将需要被订阅的方法放到类似HashMap的数据结构中存储起来，方便后面发送事件和取消注册等资源的释放的时候使用

发送事件:该步骤首先遍历事件队列，然后从队列中取出事件，并且将事件从队列中移除，拿到事件后，判断事件处于的什么线程，如果是非UI线程，则需要Handler去处理，如果是的话，则直接通过反射调用被观察的方法。

反注册:该步骤就没什么好说的，主要是上面存储到HashMap中的被订阅的方法的移除，释放在内存中的资源。

Rxjava的操作符有哪些，说说他们的作用

just:将同种数据源组合放到被观察者上面

from:将类似数组、集合的数据源放到被观察者上面

map:将一种数据源，转化成另外一种

flatmap:将一种数据源，转化成另外一种数据，并且被转化的数据是乱序排列的

concatmap:将一种数据源，转化成另外一种数据，并且被转化的数据是按照先前的数据源顺序排序的

toList:将数组的形式转化成List集合

subscribeOn:设置Observable的call方法所在的线程，也就是数据来源的线程

observeOn:设置subscribe的call方法所在的线程，也就是数据处理的线程

filter:在被观察者的数据层过滤数据

onErrorResumeNext:出错的时候，可以指定出错的时候的被观察者

retryWhen:出错的时候，重新走一遍被订阅的过程

concat:合并相同类型的被观察者到一个被观察者身上，有点类似集合、数组拼接数据。

zip:处理多种不同结果集的数据发射，一般用得多的地方是多个网络请求组合然后统一处理业务逻辑。

还有很多操作符就自己去看，这些操作符已经够面试用的了。

线程锁 锁方法和类对象啥的有啥区别

线程锁锁方法:是需要等到该线程用完了该方法才能释放同步锁

线程锁锁类对象:是需要等到该线程用完了该类对象才能释放同步锁

区别:是锁方法的区域要小 锁类对象包括了该类的所有属性

AsyncTask原理

AsyncTask主要是对android中java的线程池的封装，该类中默认开启了两个线程池，一个线程池负责任务的排队处理，保证任务被单个处理，另外一个线程池用来专门处理任务，最后任务处理完了，交给Handler发送消息到主线程，然后Handler处理线程，交给了onPostExecute方法。

内部过程:

• AsyncTask初始化阶段创建了WorkerRunnable对象，它是处理doInBackground的Callable对象，接着创建了FutureTask对象，它是将上面WorkerRunnable包装了一层的Runnable和Future对象，实际上线程池要执行的任务就是该WorkerRunnable对象。

• 在执行任务过程中，通过SerialExecutor对象来排队处理FutureTask，里面通过ArrayDeque来按顺序取出FutureTask，取出后交给了THREAD_POOL_EXECUTOR对象，它是在静态代码块中创建的线程池，所以说THREAD_POOL_EXECUTOR才是正真执行任务的关键地方。

• 执行完后，剩下的就是主线程的Handler将消息发送到主线程去处理。

问题:

• AsyncTask内部会创建一个线程池?

两个线程池，一个线程池负责排队处理任务；另一个线程池用来负责处理FutureTask，也就是将上面WorkerRunnable包装了一层的Runnable对象。

• AsyncTask对此执行excute方法会怎样?

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）

最后

在这里我和身边一些朋友特意整理了一份快速进阶为Android高级工程师的系统且全面的学习资料。涵盖了Android初级——Android高级架构师进阶必备的一些学习技能。

附上：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题（含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

ndroid高级工程师的系统且全面的学习资料。涵盖了Android初级——Android高级架构师进阶必备的一些学习技能。**

附上：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题（含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）

[外链图片转存中…(img-5rMyefaf-1712760536101)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-ZV2QZxiH-1712760536101)]