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_TASKFLAG_ACTIVITY_CLEAR_TOP一起使用,并且要启动的activity的taskAffinity和当前activity的taskAffinity不一样才会和singleTask一样的效果,因为要启动的activity和原先的activity不在同一个taskAffinity中,所以能启动该activity,这个地方有点绕,写个简单的公式:

  • FLAG_ACTIVITY_NEW_TASK如果启动同一个不同taskAffinity的activity才会有效果。
  • FLAG_ACTIVITY_NEW_TASKFLAG_ACTIVITY_CLEAR_TOP如果一起使用要开启的activity和现在的activity处于同一个taskAffinity,那么效果还是跟没加FLAG_ACTIVITY_NEW_TASK是一样的效果。
  • FLAG_ACTIVITY_NEW_TASKFLAG_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控件篇

网络通信篇

架构设计篇

性能优化篇

源码流程篇

新技术篇

面试篇

请添加图片描述

最后

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

资料都可以【】。