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。

2022最新Android 大厂高频面试题

这里给大家分享一份2246页《2022最新Android 大厂高频面试题解析大全》(持续更新中~)

包含了腾讯、百度、小米、阿里、乐视、美团、58、猎豹、360、新浪、搜狐等一线互联网公司面试被问到的题目。熟悉本文中列出的知识点会大大增加通过前两轮技术面试的几率。

内容概要：包括 Handler、Activity相关、Fragment、service、布局优化、AsyncTask相关、Android 事件分发机制、 Binder、Android 高级必备 ：AMS,WMS,PMS、Glide、 Android 组件化与插件化等面试题和技术栈！内容特点：条理清晰，含图像化表示更加易懂。

由于文章篇幅有限，需要完整版《2022最新Android中高级面试题汇总》的小伙伴，可以【】。

Java基础

  • 第一节静态内部类和非静态内部类的比较
  • 第二节多态的理解与应用
  • 第三节java方法的多态性理解
  • 第四节java中接口和继承的区别
  • 第五节线程池的好处，详解，单例(绝对好记)
  • 第六节线程池的优点及其原理
  • 第七节线程池的优点（重点)
  • 第八节为什么不推荐通过Executors直接创建线程池
  • 第九节不怕难之BlockingQueue及其实现
  • 第十节深入理解ReentrantLock与Condition
  • 第十—节Java多线程:线程间通信之Lock
  • 第十二节 Synchronized 关键字原理
  • 第十三节 ReentrantLock原理
  • 第十四节HashMap中的Hash冲突解决和扩容机制
  • 第十五节JVM常见面试题
  • 第十六节JVM内存结构
  • 第十七节类加载机制/双亲委托

Android基础

UI控件篇

网络通信篇

架构设计篇

性能优化篇

源码流程篇

新技术篇

面试篇

请添加图片描述

最后

在这里小编分享一份之前在网上查找收集的往年常见面试题，整理成了一些文档。希望能够对大家有所帮助，在面试中能顺利通过。

资料都可以【】。