2019年Android中高级工程师部分面试题

一、中级面试题

1、Activity生命周期

2、onStart()与onResume()有什么区别？

onStart()是activity界面被显示出来的时候执行的，但不能与它交互；
onResume()是当该activity与用户能进行交互时被执行，用户可以获得activity的焦点，能够与用户交互。

3、Activity启动流程

startActivity最终都会调用startActivityForResult，通过ActivityManagerProxy调用system_server进程中ActivityManagerService的startActvity方法，如果需要启动的Activity所在进程未启动，则调用Zygote孵化应用进程，进程创建后会调用应用的ActivityThread的main方法，main方法调用attach方法将应用进程绑定到ActivityManagerService（保存应用的ApplicationThread的代理对象）并开启loop循环接收消息。ActivityManagerService通过ApplicationThread的代理发送Message通知启动Activity，ActivityThread内部Handler处理handleLaunchActivity，依次调用performLaunchActivity，handleResumeActivity（即activity的onCreate，onStart，onResume）。

4、Android类加载器

Android平台上虚拟机运行的是Dex字节码,一种对class文件优化的产物,传统Class文件是一个Java源码文件会生成一个.class文件，而Android是把所有Class文件进行合并，优化，然后生成一个最终的class.dex,目的是把不同class文件重复的东西只需保留一份,如果我们的Android应用不进行分dex处理,最后一个应用的apk只会有一个dex文件。
Android中常用的有两种类加载器，DexClassLoader和PathClassLoader，它们都继承于BaseDexClassLoader。区别在于调用父类构造器时，DexClassLoader多传了一个optimizedDirectory参数，这个目录必须是内部存储路径，用来缓存系统创建的Dex文件。而PathClassLoader该参数为null，只能加载内部存储目录的Dex文件。所以我们可以用DexClassLoader去加载外部的apk。

5、Android消息机制

应用启动是从ActivityThread的main开始的，先是执行了Looper.prepare()，该方法先是new了一个Looper对象，在私有的构造方法中又创建了MessageQueue作为此Looper对象的成员变量，Looper对象通过ThreadLocal绑定MainThread中；
当我们创建Handler子类对象时，在构造方法中通过ThreadLocal获取绑定的Looper对象，并获取此Looper对象的成员变量MessageQueue作为该Handler对象的成员变量；
在子线程中调用上一步创建的Handler子类对象的sendMesage(msg)方法时，在该方法中将msg的target属性设置为自己本身，同时调用成员变量MessageQueue对象的enqueueMessag()方法将msg放入MessageQueue中；
主线程创建好之后，会执行Looper.loop()方法，该方法中获取与线程绑定的Looper对象，继而获取该Looper对象的成员变量MessageQueue对象，并开启一个会阻塞（不占用资源）的死循环，只要MessageQueue中有msg，就会获取该msg，并执行msg.target.dispatchMessage(msg)方法（msg.target即上一步引用的handler对象），此方法中调用了我们第二步创建handler子类对象时覆写的handleMessage（）方法，之后将该msg对象存入回收池；

6、Looper.loop()为什么不会阻塞主线程

Android是基于事件驱动的，即所有Activity的生命周期都是通过Handler事件驱动的。loop方法中会调用MessageQueue的next方法获取下一个message，当没有消息时，基于Linux pipe/epoll机制会阻塞在loop的queue.next()中的nativePollOnce()方法里，并不会消耗CPU。

7、IdleHandler （闲时机制）

IdleHandler是一个回调接口，可以通过MessageQueue的addIdleHandler添加实现类。当MessageQueue中的任务暂时处理完了（没有新任务或者下一个任务延时在之后），这个时候会回调这个接口，返回false，那么就会移除它，返回true就会在下次message处理完了的时候继续回调。

8、同步屏障机制(sync barrier)

同步屏障可以通过MessageQueue.postSyncBarrier函数来设置。该方法发送了一个没有target的Message到Queue中，在next方法中获取消息时，如果发现没有target的Message，则在一定的时间内跳过同步消息，优先执行异步消息。再换句话说，同步屏障为Handler消息机制增加了一种简单的优先级机制，异步消息的优先级要高于同步消息。在创建Handler时有一个async参数，传true表示此handler发送的时异步消息。ViewRootImpl.scheduleTraversals方法就使用了同步屏障，保证UI绘制优先执行。

9、View的绘制原理

View的绘制从ActivityThread类中Handler的处理RESUME_ACTIVITY事件开始，在执行performResumeActivity之后，创建Window以及DecorView并调用WindowManager的addView方法添加到屏幕上，addView又调用ViewRootImpl的setView方法，最终执行performTraversals方法，依次执行performMeasure，performLayout，performDraw。也就是view绘制的三大过程。
measure过程测量view的视图大小，最终需要调用setMeasuredDimension方法设置测量的结果，如果是ViewGroup需要调用measureChildren或者measureChild方法进而计算自己的大小。
layout过程是摆放view的过程，View不需要实现，通常由ViewGroup实现，在实现onLayout时可以通过getMeasuredWidth等方法获取measure过程测量的结果进行摆放。
draw过程先是绘制背景，其次调用onDraw()方法绘制view的内容，再然后调用dispatchDraw()调用子view的draw方法，最后绘制滚动条。ViewGroup默认不会执行onDraw方法，如果复写了onDraw(Canvas)方法，需要调用 setWillNotDraw(false);清楚不需要绘制的标记。

10、什么是MeasureSpec

MeasureSpec代表一个32位int值，高两位代表SpecMode（测量模式），低30位代表SpecSize（具体大小）。
SpecMode有三类：

UNSPECIFIED 表示父容器不对View有任何限制，一般用于系统内部，表示一种测量状态；
EXACTLY 父容器已经检测出view所需的精确大小，这时候view的最终大小SpecSize所指定的值，相当于match_parent或指定具体数值。
AT_MOST 父容器指定一个可用大小即SpecSize，view的大小不能大于这个值，具体多大要看view的具体实现，相当于wrap_content。

11、getWidth()方法和getMeasureWidth()区别呢？

首先getMeasureWidth()方法在measure()过程结束后就可以获取到了，而getWidth()方法要在layout()过程结束后才能获取到。另外，getMeasureWidth()方法中的值是通过setMeasuredDimension()方法来进行设置的，而getWidth()方法中的值则是通过视图右边的坐标减去左边的坐标计算出来的。

12、事件分发机制

requestLayout，invalidate，postInvalidate区别与联系

相同点：三个方法都有刷新界面的效果。
不同点：invalidate和postInvalidate只会调用onDraw()方法；requestLayout则会重新调用onMeasure、onLayout、onDraw。

调用了invalidate方法后，会为该View添加一个标记位，同时不断向父容器请求刷新，父容器通过计算得出自身需要重绘的区域，直到传递到ViewRootImpl中，最终触发performTraversals方法，进行开始View树重绘流程(只绘制需要重绘的视图)。
调用requestLayout方法，会标记当前View及父容器，同时逐层向上提交，直到ViewRootImpl处理该事件，ViewRootImpl会调用三大流程，从measure开始，对于每一个含有标记位的view及其子View都会进行测量onMeasure、布局onLayout、绘制onDraw。

13、Binder机制，共享内存实现原理

为什么使用Binder？

概念
进程隔离
进程空间划分：用户空间(User Space)/内核空间(Kernel Space)
系统调用：用户态与内核态

原理
跨进程通信是需要内核空间做支持的。传统的 IPC 机制如管道、Socket 都是内核的一部分，因此通过内核支持来实现进程间通信自然是没问题的。但是 Binder 并不是 Linux 系统内核的一部分，那怎么办呢？这就得益于 Linux 的动态内核可加载模块（Loadable Kernel Module，LKM）的机制；模块是具有独立功能的程序，它可以被单独编译，但是不能独立运行。它在运行时被链接到内核作为内核的一部分运行。这样，Android 系统就可以通过动态添加一个内核模块运行在内核空间，用户进程之间通过这个内核模块作为桥梁来实现通信。

在 Android 系统中，这个运行在内核空间，负责各个用户进程通过 Binder 实现通信的内核模块就叫 Binder 驱动（Binder Dirver）。

那么在 Android 系统中用户进程之间是如何通过这个内核模块（Binder 驱动）来实现通信的呢？难道是和前面说的传统 IPC 机制一样，先将数据从发送方进程拷贝到内核缓存区，然后再将数据从内核缓存区拷贝到接收方进程，通过两次拷贝来实现吗？显然不是，否则也不会有开篇所说的 Binder 在性能方面的优势了。

这就不得不通道 Linux 下的另一个概念：内存映射。

Binder IPC 机制中涉及到的内存映射通过 mmap() 来实现，mmap() 是操作系统中一种内存映射的方法。内存映射简单的讲就是将用户空间的一块内存区域映射到内核空间。映射关系建立后，用户对这块内存区域的修改可以直接反应到内核空间；反之内核空间对这段区域的修改也能直接反应到用户空间。
一次完整的 Binder IPC 通信过程通常是这样：

首先 Binder 驱动在内核空间创建一个数据接收缓存区；
接着在内核空间开辟一块内核缓存区，建立内核缓存区和内核中数据接收缓存区之间的映射关系，以及内核中数据接收缓存区和接收进程用户空间地址的映射关系；
发送方进程通过系统调用 copyfromuser() 将数据 copy 到内核中的内核缓存区，由于内核缓存区和接收进程的用户空间存在内存映射，因此也就相当于把数据发送到了接收进程的用户空间，这样便完成了一次进程间的通信。

Binder通讯模型
Binder是基于C/S架构的，其中定义了4个角色：Client、Server、Binder驱动和ServiceManager。

Binder驱动：类似网络通信中的路由器，负责将Client的请求转发到具体的Server中执行，并将Server返回的数据传回给Client。
ServiceManager：类似网络通信中的DNS服务器，负责将Client请求的Binder描述符转化为具体的Server地址，以便Binder驱动能够转发给具体的Server。Server如需提供Binder服务，需要向ServiceManager注册。
具体的通讯过程

Server向ServiceManager注册。Server通过Binder驱动向ServiceManager注册，声明可以对外提供服务。ServiceManager中会保留一份映射表。
Client向ServiceManager请求Server的Binder引用。Client想要请求Server的数据时，需要先通过Binder驱动向ServiceManager请求Server的Binder引用（代理对象）。
向具体的Server发送请求。Client拿到这个Binder代理对象后，就可以通过Binder驱动和Server进行通信了。
Server返回结果。Server响应请求后，需要再次通过Binder驱动将结果返回给Client。

ServiceManager是一个单独的进程，那么Server与ServiceManager通讯是靠什么呢？
当Android系统启动后，会创建一个名称为servicemanager的进程，这个进程通过一个约定的命令BINDERSETCONTEXT_MGR向Binder驱动注册，申请成为为ServiceManager，Binder驱动会自动为ServiceManager创建一个Binder实体。并且这个Binder实体的引用在所有的Client中都为0，也就说各个Client通过这个0号引用就可以和ServiceManager进行通信。Server通过0号引用向ServiceManager进行注册，Client通过0号引用就可以获取到要通信的Server的Binder引用。

14、序列化的方式

Serializable是Java提供的一个序列化接口，是一个空接口，用于标示对象是否可以支持序列化，通过ObjectOutputStrean及ObjectInputStream实现序列化和反序列化的过程。注意可以为需要序列化的对象设置一个serialVersionUID，在反序列化的时候系统会检测文件中的serialVersionUID是否与当前类的值一致，如果不一致则说明类发生了修改，反序列化失败。因此对于可能会修改的类最好指定serialVersionUID的值。
Parcelable是Android特有的一个实现序列化的接口，在Parcel内部包装了可序列化的数据，可以在Binder中自由传输。序列化的功能由writeToParcel方法来完成，最终通过Parcel的一系列write方法完成。反序列化功能由CREAOR来完成，其内部标明了如何创建序列化对象和数组，并通过Parcel的一系列read方法来完成反序列化的过程。

15、Fragment的懒加载实现

Fragment可见状态改变时会被调用setUserVisibleHint()方法，可以通过复写该方法实现Fragment的懒加载，但需要注意该方法可能在onVIewCreated之前调用，需要确保界面已经初始化完成的情况下再去加载数据，避免空指针。

16、RecyclerView与ListView(缓存原理，区别联系，优缺点)

缓存区别：

层级不同：
ListView有两级缓存，在屏幕与非屏幕内。

RecyclerView比ListView多两级缓存，支持多个离屏ItemView缓存（匹配pos获取目标位置的缓存，如果匹配则无需再次bindView），支持开发者自定义缓存处理逻辑，支持所有RecyclerView共用同一个RecyclerViewPool(缓存池)。

缓存不同：
ListView缓存View。

RecyclerView缓存RecyclerView.ViewHolder，抽象可理解为：
View + ViewHolder(避免每次createView时调用findViewById) + flag(标识状态)；

优点
RecylerView提供了局部刷新的接口，通过局部刷新，就能避免调用许多无用的bindView。
RecyclerView的扩展性更强大（LayoutManager、ItemDecoration等）。

17、Android两种虚拟机区别与联系

Android中的Dalvik虚拟机相较于Java虚拟机针对手机的特点做了很多优化。
Dalvik基于寄存器，而JVM基于栈。在基于寄存器的虚拟机里，可以更为有效的减少冗余指令的分发和减少内存的读写访问。
Dalvik经过优化，允许在有限的内存中同时运行多个虚拟机的实例，并且每一个 Dalvik应用作为一个独立的Linux进程执行。
java虚拟机运行的是java字节码。（java类会被编译成一个或多个字节码.class文件，打包到.jar文件中，java虚拟机从相应的.class文件和.jar文件中获取相应的字节码）
Dalvik运行的是自定义的.dex字节码格式。（java类被编译成.class文件后，会通过一个dx工具将所有的.class文件转换成一个.dex文件，然后dalvik虚拟机会从其中读取指令和数据）

18、adb常用命令行

查看当前连接的设备：adb devices
安装应用：adb install -r <apk_path> -r表示覆盖安装
卸载apk：adb uninstall <packagename>

ADB 用法大全

19、apk打包流程

aapt工具打包资源文件，生成R.java文件
aidl工具处理AIDL文件，生成对应的.java文件
javac工具编译Java文件，生成对应的.class文件
把.class文件转化成Davik VM支持的.dex文件
apkbuilder工具打包生成未签名的.apk文件
jarsigner对未签名.apk文件进行签名
zipalign工具对签名后的.apk文件进行对齐处理

Android应用程序（APK）的编译打包过程

20、apk安装流程

复制APK到/data/app目录下，解压并扫描安装包。
资源管理器解析APK里的资源文件。
解析AndroidManifest文件，并在/data/data/目录下创建对应的应用数据目录。
然后对dex文件进行优化，并保存在dalvik-cache目录下。
将AndroidManifest文件解析出的四大组件信息注册到PackageManagerService中。
安装完成后，发送广播。

21、apk瘦身

APK主要由以下几部分组成：

META-INF/ ：包含了签名文件CERT.SF、CERT.RSA，以及 manifest 文件MANIFEST.MF。
assets/ ：存放资源文件，这些资源不会被编译成二进制。
lib/ ：包含了一些引用的第三方库。
resources.arsc ：包含res/values/中所有资源，例如strings,styles，以及其他未被包含在resources.arsc中的资源路径信息，例如layout 文件、图片等。
res/ ：包含res中没有被存放到resources.arsc的资源。
classes.dex ：经过dx编译能被android虚拟机理解的Java源码文件。
AndroidManifest.xml ：清单文件

其中占据较大内存的是res资源、lib、class.dex，因此我们可以从下面的几个方面下手：

代码方面可以通过代码混淆，这个一般都会去做。平时也可以删除一些没有使用类。
去除无用资源。使用lint工具来检测没有使用到的资源，或者在gradle中配置shrinkResources来删除包括库中所有的无用的资源，需要配合proguard压缩代码使用。这里需要注意项目中是否存在使用getIdentifier方式获取资源，这种方式类似反射lint及shrinkResources无法检测情况。如果存在这种方式，则需要配置一个keep.xml来记录使用反射获取的资源。(https://developer.android.com/studio/build/shrink-code)[压缩代码和资源]
去除无用国际化支持。对于一些第三库来说（如support），因为国际化的问题，它们可能会支持了几十种语言，但我们的应用可能只需要支持几种语言，可以通过配置resConfigs提出不要的语言支持。
不同尺寸的图片支持。通常情况下只需要一套xxhpi的图片就可以支持大部分分辨率的要求了，因此，我们只需要保留一套图片。
图片压缩。 png压缩或者使用webP图片，完美支持需要Android版本4.2.1+
使用矢量图形。简单的图标可以使用矢量图片。

HTTP缓存机制

缓存的响应头：

Cache-control：标明缓存的最大存活时常；
Date：服务器告诉客户端，该资源的发送时间；
Expires：表示过期时间（该字段是1.0的东西，当cache-control和该字段同时存在的条件下，cache-control的优先级更高）；
Last-Modified：服务器告诉客户端，资源的最后修改时间；
还有一个字段，这个图没给出，就是E-Tag：当前资源在服务器的唯一标识，可用于判断资源的内容是否被修改了。
除以上响应头字段以外，还需了解两个相关的Request请求头：If-Modified-since、If-none-Match。这两个字段是和Last-Modified、E-Tag配合使用的。大致流程如下：
服务器收到请求时，会在200 OK中回送该资源的Last-Modified和ETag头（服务器支持缓存的情况下才会有这两个头哦），客户端将该资源保存在cache中，并记录这两个属性。当客户端需要发送相同的请求时，根据Date + Cache-control来判断是否缓存过期，如果过期了，会在请求中携带If-Modified-Since和If-None-Match两个头。两个头的值分别是响应中Last-Modified和ETag头的值。服务器通过这两个头判断本地资源未发生变化，客户端不需要重新下载，返回304响应。

23、组件化

在gradle.properties声明一个变量用于控制是否是调试模式，并在dependencies中根据是否是调试模式依赖必要组件。
通过resourcePrefix规范module中资源的命名前缀。
组件间通过ARouter完成界面跳转和功能调用。

24、MVP

三方库

okhttp原理

OkHttpClient通过newCall可以将一个Request构建成一个Call，Call表示准备被执行的请求。Call调用executed或enqueue会调用Dispatcher对应的方法在当前线程或者一步开始执行请求，经过RealInterceptorChain获得最终结果，RealInterceptorChain是一个拦截器链，其中依次包含以下拦截器：

自定义的拦截器
retryAndFollowUpInterceptor 请求失败重试
BridgeInterceptor 为请求添加请求头，为响应添加响应头
CacheInterceptor 缓存get请求
ConnectInterceptor 连接相关的拦截器，分配一个Connection和HttpCodec为最终的请求做准备
CallServerInterceptor 该拦截器就是利用HttpCodec完成最终请求的发送

okhttp源码解析

25、Retrofit的实现与原理

Retrofit采用动态代理，创建声明service接口的实现对象。当我们调用service的方法时候会执行InvocationHandler的invoke方法。在这方法中：首先，通过method把它转换成ServiceMethod，该类是对声明方法的解析，可以进一步将设定参数变成Request ；然后，通过serviceMethod, args获取到okHttpCall 对象，实际调用okhttp的网络请求方法就在该类中，并且会使用serviceMethod中的responseConverter对ResponseBody转化；最后，再把okHttpCall进一步封装成声明的返回对象（默认是ExecutorCallbackCall,将原本call的回调转发至UI线程）。

Retrofit2使用详解及从源码中解析原理
Retrofit2 完全解析探索与okhttp之间的关系

26、ARouter原理

可能是最详细的ARouter源码分析

27、RxLifecycle原理

在Activity中，定义一个Observable（Subject），在不同的生命周期发射不同的事件；
通过compose操作符（内部实际上还是依赖takeUntil操作符），定义了上游数据，当其接收到Subject的特定事件时，取消订阅；
Subject的特定事件并非是ActivityEvent，而是简单的boolean，它已经内部通过combineLast操作符进行了对应的转化。

28、RxJava

Java

类的加载机制

程序在启动的时候，并不会一次性加载程序所要用的所有class文件，而是根据程序的需要，通过Java的类加载机制（ClassLoader）来动态加载某个class文件到内存当中的，从而只有class文件被载入到了内存之后，才能被其它class所引用。所以ClassLoader就是用来动态加载class文件到内存当中用的。
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)7个阶段。其中准备、验证、解析3个部分统称为连接（Linking）。

加载：查找和导入Class文件；
链接：把类的二进制数据合并到JRE中；
(a) 验证：检查载入Class文件数据的正确性；

(b) 准备：给类的静态变量分配存储空间；
(c) 解析：将符号引用转成直接引用；

初始化：对类的静态变量，静态代码块执行初始化操作

29、什么时候发生类初始化

遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候，读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。
使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。
当使用JDK 1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例左后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄锁对应的类没有进行过初始化时。

30、双亲委派模型

Java中存在3种类加载器：
(1) Bootstrap ClassLoader : 将存放于<JAVA_HOME>lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如 rt.jar 名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用。
(2) Extension ClassLoader : 将<JAVA_HOME>libext目录下的，或者被java.ext.dirs系统变量所指定的路径中的所有类库加载。开发者可以直接使用扩展类加载器。
(3) Application ClassLoader : 负责加载用户类路径(ClassPath)上所指定的类库,开发者可直接使用。
每个ClassLoader实例都有一个父类加载器的引用（不是继承关系，是一个包含的关系），虚拟机内置的类加载器（Bootstrap ClassLoader）本身没有父类加载器，但是可以用做其他ClassLoader实例的父类加载器。
当一个ClassLoader 实例需要加载某个类时，它会试图在亲自搜索这个类之前先把这个任务委托给它的父类加载器，这个过程是由上而下依次检查的，首先由顶层的类加载器Bootstrap ClassLoader进行加载，如果没有加载到，则把任务转交给Extension ClassLoader加载，如果也没有找到，则转交给AppClassLoader进行加载，还是没有的话，则交给委托的发起者，由它到指定的文件系统或者网络等URL中进行加载类。还没有找到的话，则会抛出CLassNotFoundException异常。否则将这个类生成一个类的定义，并将它加载到内存中，最后返回这个类在内存中的Class实例对象。

31、为什么使用双亲委托模型

JVM在判断两个class是否相同时，不仅要判断两个类名是否相同，还要判断是否是同一个类加载器加载的。

避免重复加载，父类已经加载了，则子CLassLoader没有必要再次加载。
考虑安全因素，假设自定义一个String类，除非改变JDK中CLassLoader的搜索类的默认算法，否则用户自定义的CLassLoader如法加载一个自己写的String类，因为String类在启动时就被引导类加载器Bootstrap CLassLoader加载了。

32、HashMap原理，Hash冲突

在JDK1.6，JDK1.7中，HashMap采用数组+链表实现，即使用链表处理冲突，同一hash值的链表都存储在一个链表里。但是当位于一个链表中的元素较多，即hash值相等的元素较多时，通过key值依次查找的效率较低。而JDK1.8中，HashMap采用位数组+链表+红黑树实现，当链表长度超过阈值（8）时，将链表转换为红黑树，这样大大减少了查找时间。
当链表数组的容量超过初始容量*加载因子（默认0.75）时，再散列将链表数组扩大2倍，把原链表数组的搬移到新的数组中。为什么需要使用加载因子？为什么需要扩容呢？因为如果填充比很大，说明利用的空间很多，如果一直不进行扩容的话，链表就会越来越长，这样查找的效率很低，扩容之后，将原来链表数组的每一个链表分成奇偶两个子链表分别挂在新链表数组的散列位置，这样就减少了每个链表的长度，增加查找效率。
HashMap是非线程安全的，HashTable、ConcurrentHashMap是线程安全的。
HashMap的键和值都允许有null存在，而HashTable、ConcurrentHashMap则都不行。
因为线程安全、哈希效率的问题，HashMap效率比HashTable、ConcurrentHashMap的都要高。
HashTable里使用的是synchronized关键字，这其实是对对象加锁，锁住的都是对象整体，当Hashtable的大小增加到一定的时候，性能会急剧下降，因为迭代时需要被锁定很长的时间。
ConcurrentHashMap引入了分割(Segment)，可以理解为把一个大的Map拆分成N个小的HashTable，在put方法中，会根据hash(paramK.hashCode())来决定具体存放进哪个Segment，如果查看Segment的put操作，我们会发现内部使用的同步机制是基于lock操作的，这样就可以对Map的一部分（Segment）进行上锁，这样影响的只是将要放入同一个Segment的元素的put操作，保证同步的时候，锁住的不是整个Map（HashTable就是这么做的），相对于HashTable提高了多线程环境下的性能，因此HashTable已经被淘汰了。

Java中HashMap底层实现原理(JDK1.8)源码分析

33、什么是Fail-Fast机制

Fail-Fast是Java集合的一种错误检测机制。当遍历集合的同时修改集合或者多个线程对集合进行结构上的改变的操作时，有可能会产生fail-fast机制，记住是有可能，而不是一定。其实就是抛出ConcurrentModificationException 异常。
集合的迭代器在调用next()、remove()方法时都会调用checkForComodification()方法，该方法主要就是检测modCount == expectedModCount ? 若不等则抛出ConcurrentModificationException 异常，从而产生fail-fast机制。modCount是在每次改变集合数量时会改变的值。

Java提高篇（三四）-----fail-fast机制

34、Java泛型

Java泛型详解

35、Java多线程中调用wait() 和 sleep()方法有什么不同？

Java程序中wait 和 sleep都会造成某种形式的暂停，它们可以满足不同的需要。wait()方法用于线程间通信，如果等待条件为真且其它线程被唤醒时它会释放锁，而 sleep()方法仅仅释放CPU资源或者让当前线程停止执行一段时间，但不会释放锁。

36、volatile的作用和原理

Java代码在编译后会变成Java字节码，字节码被类加载器加载到JVM里，JVM执行字节码，最终需要转化为汇编指令在CPU上执行。
volatile是轻量级的synchronized（volatile不会引起线程上下文的切换和调度），它在多处理器开发中保证了共享变量的“可见性”。可见性的意思是当一个线程修改一个共享变量时，另外一个线程能读到这个修改的值。
由于内存访问速度远不及CPU处理速度，为了提高处理速度，处理器不直接和内存进行通信，而是先将系统内存的数据读到内部缓存后在进行操作，但操作完不知道何时会写到内存。普通共享变量被修改之后，什么时候被写入主存是不确定的，当其他线程去读取时，此时内存中可能还是原来的旧值，因此无法保证可见性。如果对声明了volatile的变量进行写操作，JVM就会想处理器发送一条Lock前缀的指令，表示将当前处理器缓存行的数据写回到系统内存。

37、一个int变量，用volatile修饰，多线程去操作++，线程安全吗？

不安全。volatile只能保证可见性，并不能保证原子性。i++实际上会被分成多步完成：1）获取i的值；2）执行i+1；3）将结果赋值给i。volatile只能保证这3步不被重排序，多线程情况下，可能两个线程同时获取i，执行i+1，然后都赋值结果2，实际上应该进行两次+1操作。

38、那如何才能保证i++线程安全？

可以使用java.util.concurrent.atomic包下的原子类，如AtomicInteger。
其实现原理是采用CAS自旋操作更新值。CAS即compare and swap的缩写，中文翻译成比较并交换。CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。自旋就是不断尝试CAS操作直到成功为止。

39、CAS实现原子操作会出现什么问题？

ABA问题。因为CAS需要在操作之的时候，检查值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成，有变成A，那么使用CAS进行检查时会发现它的值没有发生变化，但实际上发生了变化。ABA问题可以通过添加版本号来解决。Java 1.5开始，JDK的Atomic包里提供了一个类AtomicStampedReference来解决ABA问题。
循环时间长开销大。pause指令优化。
只能保证一个共享变量的原子操作。可以合并成一个对象进行CAS操作。

40、synchronized

Java中每个对象都可以作为锁：

对于普通同步方法，锁是当前实例对象；
对于静态同步方法，锁是当前类的Class对象；
对于同步方法块，锁是括号中配置的对象；

当一个线程试图访问同步代码块时，它首先必须得到锁，退出或抛出异常时必须释放锁。synchronized用的锁是存在Java对象头里的MarkWord，通常是32bit或者64bit，其中最后2bit表示锁标志位

java对象结构
Java SE1.6为了减少获得锁和释放锁带来的性能消耗，引入了偏向锁和轻量级锁，在1.6中锁一共有4种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这几种状态会随着竞争情况逐渐升级。锁可以升级但不能降级。

41、偏向锁

偏向锁获取过程：

访问Mark Word中偏向锁的标识是否设置成1，锁标志位是否为01，确认为可偏向状态。
如果为可偏向状态，则测试线程ID是否指向当前线程，如果是，进入步骤5，否则进入步骤3。
如果线程ID并未指向当前线程，则通过CAS操作竞争锁。如果竞争成功，则将Mark Word中线程ID设置为当前线程ID，然后执行5；如果竞争失败，执行4。
如果CAS获取偏向锁失败，则表示有竞争。当到达全局安全点（safepoint）时获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码。（撤销偏向锁的时候会导致stop the word）
执行同步代码。

42、轻量级锁

在代码进入同步块的时候，如果同步对象锁状态为无锁状态（锁标志位为“01”状态，是否为偏向锁为“0”），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝，官方称之为 Displaced Mark Word。
拷贝对象头中的Mark Word复制到锁记录中；
拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock record里的owner指针指向object mark word。如果更新成功，则执行步骤4，否则执行步骤5。
如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位设置为“00”，即表示此对象处于轻量级锁定状态。
如果这个更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。否则说明多个线程竞争锁，轻量级锁就要膨胀为重量级锁，锁标志的状态值变为“10”，Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。而当前线程便尝试使用自旋来获取锁，自旋就是为了不让线程阻塞，而采用循环去获取锁的过程。
自旋

如果持有锁的线程能在很短时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状态，它们只需要等一等（自旋），等持有锁的线程释放锁后即可立即获取锁，这样就避免用户线程和内核的切换的消耗。
但是线程自旋是需要消耗cup的，说白了就是让cup在做无用功，如果一直获取不到锁，那线程也不能一直占用cup自旋做无用功，所以需要设定一个自旋等待的最大时间。
如果持有锁的线程执行的时间超过自旋等待的最大时间扔没有释放锁，就会导致其它争用锁的线程在最大等待时间内还是获取不到锁，这时争用线程会停止自旋进入阻塞状态。

43、线程池

好处：1）降低资源消耗；2）提高相应速度；3）提高线程的可管理性。
线程池的实现原理：

当提交一个新任务到线程池时，判断核心线程池里的线程是否都在执行。如果不是，则创建一个新的线程执行任务。如果核心线程池的线程都在执行任务，则进入下个流程。
判断工作队列是否已满。如果未满，则将新提交的任务存储在这个工作队列里。如果工作队列满了，则进入下个流程。
判断线程池是否都处于工作状态。如果没有，则创建一个新的工作线程来执行任务。如果满了，则交给饱和策略来处理这个任务。

44、假如有n个网络线程，你需要当n个网络线程完成之后，再去做数据处理，你会怎么解决？

这题考的其实是多线程同步的问题。这种情况可以可以使用thread.join()；join方法会阻塞直到thread线程终止才返回。更复杂一点的情况也可以使用CountDownLatch，CountDownLatch的构造接收一个int参数作为计数器，每次调用countDown方法计数器减一。做数据处理的线程调用await方法阻塞直到计数器为0时。

45、Java中interrupted 和 isInterruptedd方法的区别？

interrupted[静态方法]()Thread.interrupted()来检查中断状态时，中断状态会被清零。而非静态方法isInterrupted()用来查询其它线程的中断状态且不会改变中断状态标识。简单的说就是任何抛出InterruptedException异常的方法都会将中断状态清零。无论如何，一个线程的中断状态有有可能被其它线程调用中断来改变。

46、懒汉式单例的同步问题

同步的懒加载虽然是线程安全的，但是导致性能开销。因此产生了双重检查锁定。但双重检查锁定存在隐藏的问题。instance = new Instance()实际上会分为三步操作：1）分配对象的内存空间；2）初始化对象；3）设置instance指向刚分配的内存地址；由于指令重排序，2和3的顺序并不确定。在多线程的情况下，第一个线程执行了1，3，此时第二个线程判断instance不为null，但实际上操作2还没有执行，第二个线程就会获得一个还未初始化的对象，直接使用就会造成空指针。
解决方案是用volatile修饰instance，在JDK 1.5加强了volatile的语意之后，用volatile修饰instance就阻止了2和3的重排序，进而避免上述情况的发生。
另一种方式则是使用静态内部类：

public class Singleton {private static class InstanceHolder {public static Singleton instance = new Singleton();}public static Singleton getInstance() {return InstanceHolder.instance;}
}

其原理是利用类初始化时会加上初始化锁确保类对象的唯一性。

47、什么是ThreadLocal

ThreadLocal即线程变量，它为每个使用该变量的线程提供独立的变量副本，所以每一个线程都可以独立地改变自己的副本，而不会影响其它线程所对应的副本。从线程的角度看，目标变量就象是线程的本地变量，这也是类名中“Local”所要表达的意思。ThreadLocal的实现是以ThreadLocal对象为键。任意对象为值得存储结构。这个结构被附带在线程上，也就是说一个线程可以根据一个ThreadLocal对象查询到绑定在这个线程上的一个值。

48、什么是数据竞争

数据竞争的定义：在一个线程写一个变量，在另一个线程读同一个变量，而且写和读没有通过同步来排序。

49、Java内存模型（Java Memory Model JMM）

JM屏蔽各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果。
线程之间的共享变量存储在主内存中，每个线程都有一个私有的本地内存，本地内存中存储了该线程以读/写共享变量的副本。本地内存是一个抽象概念，它涵盖了缓存、写缓存区、寄存器以及其他的硬件和编译器优化。
在执行程序时，为了提高性能，编译器和处理器常常会对指令做重排序。在多线程中重排序会对程序的执行结果有影响。
JSR-133内存模型采用happens-before的概念来阐述操作之间的内存可见性。happens-before会限制重排序以满足规则。
主要的happens-before规则有如下：

程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作。
监视器锁规则：对一个锁的解锁，happens-before与锁随后对这个锁的加锁。
volatile变量规则：对一个volatile域的写，happens-before与任意后续对这个volatile域的读。
传递性：如果A happens-before B，且B happens-before C，那么A happens-before C。

50、Java内存区域

程序计数器：当前线程锁执行的字节码的行号指示器，用于线程切换恢复，是线程私有的；
Java虚拟机栈（栈）：虚拟机栈也是线程私有的。每个方法在执行的同时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。
本地方法栈：与虚拟机栈类似，服务于Native方法。
Java堆：堆是被所有线程共享的一块内存，用于存放对象实例。是垃圾收集器管理的主要区域，也被称作GC堆。
方法区：与Java堆一样，是线程共享的内存区域，用于存储已被虚拟机加载的类信息、常量、静态常量、即时编译器编译后的代码等数据。
运行时常量池：是方法区的一部分，用于存放编译器生成的各种字面量和符号引用。

51、判断对象是否需要回收的方法

引用计数算法。实现简单，判定效率高，但不能解决循环引用问题，同时计数器的增加和减少带来额外开销，JDK1.1以后废弃了。
可达性分析算法/根搜索算法。根搜索算法是通过一些“GC Roots”对象作为起点，从这些节点开始往下搜索，搜索通过的路径成为引用链（Reference Chain），当一个对象没有被GC Roots 的引用链连接的时候，说明这个对象是不可用的。 Java中可作为“GC Root”的对象包括：虚拟机栈（本地变量表）中引用的对象；方法区中类静态属性和常量引用的对象。本地方法栈中引用的对象。

52、引用类型

强引用：默认的引用方式，不会被垃圾回收，JVM宁愿抛出OutOfMemory错误也不会回收这种对象。
软引用（SoftReference）：如果一个对象只被软引用指向，只有内存空间不足够时，垃圾回收器才会回收它；
弱引用（WeakReference）：如果一个对象只被弱引用指向，当JVM进行垃圾回收时，无论内存是否充足，都会回收该对象。
虚引用（PhantomReference）：虚引用和前面的软引用、弱引用不同，它并不影响对象的生命周期。如果一个对象与虚引用关联，则跟没有引用与之关联一样，在任何时候都可能被垃圾回收器回收。虚引用通常和ReferenceQueue配合使用。
ReferenceQueue

作为一个Java对象，Reference对象除了具有保存引用的特殊性之外，也具有Java对象的一般性。所以，当对象被回收之后，虽然这个Reference对象的get()方法返回null,但这个SoftReference对象已经不再具有存在的价值，需要一个适当的清除机制，避免大量Reference对象带来的内存泄漏。
在java.lang.ref包里还提供了ReferenceQueue。我们创建Reference对象时使用两个参数的构造传入ReferenceQueue，当Reference所引用的对象被垃圾收集器回收的同时，Reference对象被列入ReferenceQueue。也就是说，ReferenceQueue中保存的对象是Reference对象，而且是已经失去了它所软引用的对象的Reference对象。另外从ReferenceQueue这个名字也可以看出，它是一个队列，当我们调用它的poll()方法的时候，如果这个队列中不是空队列，那么将返回队列前面的那个Reference对象。于是我们可以在适当的时候把这些失去所软引用的对象的SoftReference对象清除掉。

53、垃圾收集算法

标记-清楚算法（Mark-Sweep）
在标记阶段，确定所有要回收的对象，并做标记。清除阶段紧随标记阶段，将标记阶段确定不可用的对象清除。标记—清除算法是基础的收集算法，有两个不足：1）标记和清除阶段的效率不高；2）清除后回产生大量的不连续空间，这样当程序需要分配大内存对象时，可能无法找到足够的连续空间。
复制算法（Copying）
复制算法是把内存分成大小相等的两块，每次使用其中一块，当垃圾回收的时候，把存活的对象复制到另一块上，然后把这块内存整个清理掉。复制算法实现简单，运行效率高，但是由于每次只能使用其中的一半，造成内存的利用率不高。现在的JVM 用复制方法收集新生代，由于新生代中大部分对象（98%）都是朝生夕死的，所以会分成1块大内存Eden和两块小内存Survivor(大概是8:1:1)，每次使用1块大内存和1块小内存，当回收时将2块内存中存活的对象赋值到另一块小内存中，然后清理剩下的。
标记—整理算法（Mark-Compact）
标记—整理算法和复制算法一样，但是标记—整理算法不是把存活对象复制到另一块内存，而是把存活对象往内存的一端移动，然后直接回收边界以外的内存。标记—整理算法提高了内存的利用率，并且它适合在收集对象存活时间较长的老年代。
分代收集（Generational Collection）
分代收集是根据对象的存活时间把内存分为新生代和老年代，根据各代对象的存活特点，每个代采用不同的垃圾回收算法。新生代采用复制算法，老年代采用标记—整理算法。

54、内存分配策略

对象优先在Eden分配。
大对象直接进入老年代。大对象是指需要大量连续内存空间的Java对象，最典型的就是那种很长的字符串以及数组。
长期存活的对象进入老年代。存活过一次新生代的GC，Age+1，当达到一定程度（默认15）进入老年代。
动态对象年龄判定。如果在Survivor空间中相同Age所有对象大小的总和大于Survivor空间一半。那么Age大于等于该Age的对象就可以直接进入老年代。
空间分配担保。在发生新生代GC之前，会检查老年代的剩余空间是否大于新生代所有对象的总和。如果大于则是安全的，如果不大于有风险。

二、高级面试题目

1、说下你所知道的设计模式与使用场景

a.建造者模式：

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

使用场景比如最常见的AlertDialog,拿我们开发过程中举例，比如Camera开发过程中，可能需要设置一个初始化的相机配置，设置摄像头方向，闪光灯开闭，成像质量等等，这种场景下就可以使用建造者模式

装饰者模式：动态的给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。装饰者模式可以在不改变原有类结构的情况下曾强类的功能，比如Java中的BufferedInputStream 包装FileInputStream，举个开发中的例子，比如在我们现有网络框架上需要增加新的功能，那么再包装一层即可，装饰者模式解决了继承存在的一些问题，比如多层继承代码的臃肿，使代码逻辑更清晰

观察者模式：
代理模式：
门面模式：
单例模式：
生产者消费者模式：

2、java语言的特点与OOP思想

这个通过对比来描述，比如面向对象和面向过程的对比，针对这两种思想的对比，还可以举个开发中的例子，比如播放器的实现，面向过程的实现方式就是将播放视频的这个功能分解成多个过程，比如，加载视频地址，获取视频信息，初始化解码器，选择合适的解码器进行解码，读取解码后的帧进行视频格式转换和音频重采样，然后读取帧进行播放，这是一个完整的过程，这个过程中不涉及类的概念，而面向对象最大的特点就是类，封装继承和多态是核心，同样的以播放器为例，一面向对象的方式来实现，将会针对每一个功能封装出一个对象，吧如说Muxer，获取视频信息，Decoder,解码，格式转换器，视频播放器，音频播放器等，每一个功能对应一个对象，由这个对象来完成对应的功能，并且遵循单一职责原则，一个对象只做它相关的事情

3、说下java中的线程创建方式，线程池的工作原理。

java中有三种创建线程的方式，或者说四种

1.继承Thread类实现多线程
2.实现Runnable接口
3.实现Callable接口
4.通过线程池

线程池的工作原理：线程池可以减少创建和销毁线程的次数，从而减少系统资源的消耗，当一个任务提交到线程池时

首先判断核心线程池中的线程是否已经满了，如果没满，则创建一个核心线程执行任务，否则进入下一步
判断工作队列是否已满，没有满则加入工作队列，否则执行下一步
判断线程数是否达到了最大值，如果不是，则创建非核心线程执行
任务，否则执行饱和策略，默认抛出异常

4、说下 handler 原理

Handler，Message，looper 和 MessageQueue 构成了安卓的消息机制，handler创建后可以通过 sendMessage 将消息加入消息队列，然后 looper不断的将消息从 MessageQueue 中取出来，回调到 Hander 的 handleMessage方法，从而实现线程的通信。

从两种情况来说，第一在UI线程创建Handler,此时我们不需要手动开启looper，因为在应用启动时，在ActivityThread的main方法中就创建了一个当前主线程的looper，并开启了消息队列，消息队列是一个无限循环，为什么无限循环不会ANR?因为可以说，应用的整个生命周期就是运行在这个消息循环中的，安卓是由事件驱动的，Looper.loop不断的接收处理事件，每一个点击触摸或者Activity每一个生命周期都是在Looper.loop的控制之下的，looper.loop一旦结束，应用程序的生命周期也就结束了。我们可以想想什么情况下会发生ANR，第一，事件没有得到处理，第二，事件正在处理，但是没有及时完成，而对事件进行处理的就是looper，所以只能说事件的处理如果阻塞会导致ANR，而不能说looper的无限循环会ANR

另一种情况就是在子线程创建Handler,此时由于这个线程中没有默认开启的消息队列，所以我们需要手动调用looper.prepare(),并通过looper.loop开启消息

主线程Looper从消息队列读取消息，当读完所有消息时，主线程阻塞。子线程往消息队列发送消息，并且往管道文件写数据，主线程即被唤醒，从管道文件读取数据，主线程被唤醒只是为了读取消息，当消息读取完毕，再次睡眠。因此loop的循环并不会对CPU性能有过多的消耗。

5、内存泄漏的场景和解决办法

1.非静态内部类的静态实例

非静态内部类会持有外部类的引用，如果非静态内部类的实例是静态的，就会长期的维持着外部类的引用，组织被系统回收，解决办法是使用静态内部类

2.多线程相关的匿名内部类和非静态内部类

匿名内部类同样会持有外部类的引用，如果在线程中执行耗时操作就有可能发生内存泄漏，导致外部类无法被回收，直到耗时任务结束，解决办法是在页面退出时结束线程中的任务

3.Handler内存泄漏

Handler导致的内存泄漏也可以被归纳为非静态内部类导致的，Handler内部message是被存储在MessageQueue中的，有些message不能马上被处理，存在的时间会很长，导致handler无法被回收，如果handler是非静态的，就会导致它的外部类无法被回收，解决办法是1.使用静态handler，外部类引用使用弱引用处理2.在退出页面时移除消息队列中的消息

4.Context导致内存泄漏

根据场景确定使用Activity的Context还是Application的Context,因为二者生命周期不同，对于不必须使用Activity的Context的场景（Dialog）,一律采用Application的Context,单例模式是最常见的发生此泄漏的场景，比如传入一个Activity的Context被静态类引用，导致无法回收

5.静态View导致泄漏

使用静态View可以避免每次启动Activity都去读取并渲染View，但是静态View会持有Activity的引用，导致无法回收，解决办法是在Activity销毁的时候将静态View设置为null（View一旦被加载到界面中将会持有一个Context对象的引用，在这个例子中，这个context对象是我们的Activity，声明一个静态变量引用这个View，也就引用了activity）

6.WebView导致的内存泄漏

WebView只要使用一次，内存就不会被释放，所以WebView都存在内存泄漏的问题，通常的解决办法是为WebView单开一个进程，使用AIDL进行通信，根据业务需求在合适的时机释放掉

7.资源对象未关闭导致

如Cursor，File等，内部往往都使用了缓冲，会造成内存泄漏，一定要确保关闭它并将引用置为null

8.集合中的对象未清理

集合用于保存对象，如果集合越来越大，不进行合理的清理，尤其是入股集合是静态的

9.Bitmap导致内存泄漏

bitmap是比较占内存的，所以一定要在不使用的时候及时进行清理，避免静态变量持有大的bitmap对象

10.监听器未关闭

很多需要register和unregister的系统服务要在合适的时候进行unregister,手动添加的listener也需要及时移除

6、如何避免OOM?

1.使用更加轻量的数据结构：如使用ArrayMap/SparseArray替代HashMap,HashMap更耗内存，因为它需要额外的实例对象来记录Mapping操作，SparseArray更加高效，因为它避免了Key Value的自动装箱，和装箱后的解箱操作

2.便面枚举的使用，可以用静态常量或者注解@IntDef替代

3.Bitmap优化:

a.尺寸压缩：通过InSampleSize设置合适的缩放
b.颜色质量：设置合适的format，ARGB_6666/RBG_545/ARGB_4444/ALPHA_6，存在很大差异
c.inBitmap:使用inBitmap属性可以告知Bitmap解码器去尝试使用已经存在的内存区域，新解码的Bitmap会尝试去使用之前那张Bitmap在Heap中所占据的pixel data内存区域，而不是去问内存重新申请一块区域来存放Bitmap。利用这种特性，即使是上千张的图片，也只会仅仅只需要占用屏幕所能够显示的图片数量的内存大小，但复用存在一些限制，具体体现在：在Android 4.4之前只能重用相同大小的Bitmap的内存，而Android 4.4及以后版本则只要后来的Bitmap比之前的小即可。使用inBitmap参数前，每创建一个Bitmap对象都会分配一块内存供其使用，而使用了inBitmap参数后，多个Bitmap可以复用一块内存，这样可以提高性能

4.StringBuilder替代String: 在有些时候，代码中会需要使用到大量的字符串拼接的操作，这种时候有必要考虑使用StringBuilder来替代频繁的“+”

5.避免在类似onDraw这样的方法中创建对象，因为它会迅速占用大量内存，引起频繁的GC甚至内存抖动

6.减少内存泄漏也是一种避免OOM的方法

7、说下 Activity 的启动模式，生命周期，两个 Activity 跳转的生命周期，如果一个 Activity 跳转另一个 Activity 再按下 Home 键在回到 Activity 的生命周期是什么样的

启动模式

Standard 模式:Activity 可以有多个实例，每次启动 Activity，无论任务栈中是否已经有这个Activity的实例，系统都会创建一个新的Activity实例

SingleTop模式:当一个singleTop模式的Activity已经位于任务栈的栈顶，再去启动它时，不会再创建新的实例,如果不位于栈顶，就会创建新的实例

SingleTask模式:如果Activity已经位于栈顶，系统不会创建新的Activity实例，和singleTop模式一样。但Activity已经存在但不位于栈顶时，系统就会把该Activity移到栈顶，并把它上面的activity出栈

SingleInstance模式:singleInstance 模式也是单例的，但和singleTask不同，singleTask 只是任务栈内单例，系统里是可以有多个singleTask Activity实例的，而 singleInstance Activity 在整个系统里只有一个实例，启动一singleInstanceActivity 时，系统会创建一个新的任务栈，并且这个任务栈只有他一个Activity

8、生命周期

onCreate onStart onResume onPause onStop onDestroy
两个 Activity 跳转的生命周期

1.启动A
onCreate - onStart - onResume

2.在A中启动B
ActivityA onPause
ActivityB onCreate
ActivityB onStart
ActivityB onResume
ActivityA onStop

3.从B中返回A（按物理硬件返回键）
ActivityB onPause
ActivityA onRestart
ActivityA onStart
ActivityA onResume
ActivityB onStop
ActivityB onDestroy

4.继续返回

ActivityA onPause
ActivityA onStop
ActivityA onDestroy

9、onRestart 的调用场景

（1）按下home键之后，然后切换回来，会调用onRestart()。
（2）从本Activity跳转到另一个Activity之后，按back键返回原来Activity，会调用onRestart()；
（3）从本Activity切换到其他的应用，然后再从其他应用切换回来，会调用onRestart()；

说下 Activity 的横竖屏的切换的生命周期，用那个方法来保存数据，两者的区别。触发在什么时候在那个方法里可以获取数据等。

是否了解SurfaceView，它是什么？他的继承方式是什么？他与View的区别(从源码角度，如加载，绘制等)。

SurfaceView中采用了双缓冲机制，保证了UI界面的流畅性，同时 SurfaceView 不在主线程中绘制，而是另开辟一个线程去绘制，所以它不妨碍UI线程；

SurfaceView 继承于View，他和View主要有以下三点区别：

（1）View底层没有双缓冲机制，SurfaceView有；

（2）view主要适用于主动更新，而SurfaceView适用与被动的更新，如频繁的刷新

（3）view会在主线程中去更新UI，而SurfaceView则在子线程中刷新；

SurfaceView的内容不在应用窗口上，所以不能使用变换（平移、缩放、旋转等）。也难以放在ListView或者ScrollView中，不能使用UI控件的一些特性比如View.setAlpha()

View：显示视图，内置画布，提供图形绘制函数、触屏事件、按键事件函数等；必须在UI主线程内更新画面，速度较慢。

SurfaceView：基于view视图进行拓展的视图类，更适合2D游戏的开发；是view的子类，类似使用双缓机制，在新的线程中更新画面所以刷新界面速度比view快，Camera预览界面使用SurfaceView。

GLSurfaceView：基于SurfaceView视图再次进行拓展的视图类，专用于3D游戏开发的视图；是SurfaceView的子类，openGL专用。
如何实现进程保活

a: Service 设置成 START_STICKY kill 后会被重启(等待5秒左右)，重传Intent，保持与重启前一样

b: 通过 startForeground将进程设置为前台进程，做前台服务，优先级和前台应用一个级别，除非在系统内存非常缺，否则此进程不会被 kill

c: 双进程Service：让2个进程互相保护对方，其中一个Service被清理后，另外没被清理的进程可以立即重启进程

d: 用C编写守护进程(即子进程) : Android系统中当前进程(Process)fork出来的子进程，被系统认为是两个不同的进程。当父进程被杀死的时候，子进程仍然可以存活，并不受影响(Android5.0以上的版本不可行）联系厂商，加入白名单

e.锁屏状态下，开启一个一像素Activity
说下冷启动与热启动是什么，区别，如何优化，使用场景等。
app冷启动：当应用启动时，后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用，这个启动方式就叫做冷启动（后台不存在该应用进程）。冷启动因为系统会重新创建一个新的进程分配给它，所以会先创建和初始化Application类，再创建和初始化MainActivity类（包括一系列的测量、布局、绘制），最后显示在界面上。

app热启动：当应用已经被打开，但是被按下返回键、Home键等按键时回到桌面或者是其他程序的时候，再重新打开该app时，这个方式叫做热启动（后台已经存在该应用进程）。热启动因为会从已有的进程中来启动，所以热启动就不会走Application这步了，而是直接走MainActivity（包括一系列的测量、布局、绘制），所以热启动的过程只需要创建和初始化一个MainActivity就行了，而不必创建和初始化Application

10、冷启动的流程

当点击app的启动图标时，安卓系统会从Zygote进程中fork创建出一个新的进程分配给该应用，之后会依次创建和初始化Application类、创建MainActivity类、加载主题样式Theme中的windowBackground等属性设置给MainActivity以及配置Activity层级上的一些属性、再inflate布局、当onCreate/onStart/onResume方法都走完了后最后才进行contentView的measure/layout/draw显示在界面上

冷启动的生命周期简要流程：

Application构造方法 –> attachBaseContext()–>onCreate –>Activity构造方法 –> onCreate() –> 配置主体中的背景等操作 –>onStart() –> onResume() –> 测量、布局、绘制显示

冷启动的优化主要是视觉上的优化，解决白屏问题，提高用户体验，所以通过上面冷启动的过程。能做的优化如下：

减少 onCreate()方法的工作量
不要让 Application 参与业务的操作
不要在 Application 进行耗时操作
不要以静态变量的方式在 Application 保存数据
减少布局的复杂度和层级
减少主线程耗时

为什么冷启动会有白屏黑屏问题？原因在于加载主题样式Theme中的windowBackground等属性设置给MainActivity发生在inflate布局当onCreate/onStart/onResume方法之前，而windowBackground背景被设置成了白色或者黑色，所以我们进入app的第一个界面的时候会造成先白屏或黑屏一下再进入界面。解决思路如下

1.给他设置 windowBackground 背景跟启动页的背景相同，如果你的启动页是张图片那么可以直接给 windowBackground 这个属性设置该图片那么就不会有一闪的效果了

<style name=``"Splash_Theme"` `parent=``"@android:style/Theme.NoTitleBar"``>`<item name=``"android:windowBackground"``>@drawable/splash_bg</item>`<item name=``"android:windowNoTitle"``>``true``</item>`
</style>`

2.采用世面的处理方法，设置背景是透明的，给人一种延迟启动的感觉。,将背景颜色设置为透明色,这样当用户点击桌面APP图片的时候，并不会"立即"进入APP，而且在桌面上停留一会，其实这时候APP已经是启动的了，只是我们心机的把Theme里的windowBackground 的颜色设置成透明的，强行把锅甩给了手机应用厂商（手机反应太慢了啦）

<style name=``"Splash_Theme"` `parent=``"@android:style/Theme.NoTitleBar"``>`<item name=``"android:windowIsTranslucent"``>``true``</item>`<item name=``"android:windowNoTitle"``>``true``</item>`
</style>`

3.以上两种方法是在视觉上显得更快，但其实只是一种表象，让应用启动的更快，有一种思路，将 Application 中的不必要的初始化动作实现懒加载，比如，在SpashActivity 显示后再发送消息到 Application，去初始化，这样可以将初始化的动作放在后边，缩短应用启动到用户看到界面的时间

11、Android 中的线程有那些,原理与各自特点

AsyncTask,HandlerThread,IntentService

AsyncTask原理：内部是Handler和两个线程池实现的，Handler用于将线程切换到主线程，两个线程池一个用于任务的排队，一个用于执行任务，当AsyncTask执行execute方法时会封装出一个FutureTask对象，将这个对象加入队列中，如果此时没有正在执行的任务，就执行它，执行完成之后继续执行队列中下一个任务，执行完成通过Handler将事件发送到主线程。AsyncTask必须在主线程初始化，因为内部的Handler是一个静态对象，在AsyncTask类加载的时候他就已经被初始化了。在Android3.0开始，execute方法串行执行任务的，一个一个来，3.0之前是并行执行的。如果要在3.0上执行并行任务，可以调用executeOnExecutor方法

HandlerThread原理：继承自 Thread，start开启线程后，会在其run方法中会通过Looper 创建消息队列并开启消息循环，这个消息队列运行在子线程中，所以可以将HandlerThread 中的 Looper 实例传递给一个 Handler，从而保证这个 Handler 的 handleMessage 方法运行在子线程中，Android 中使用 HandlerThread的一个场景就是 IntentService
IntentService原理：继承自Service，它的内部封装了 HandlerThread 和Handler，可以执行耗时任务，同时因为它是一个服务，优先级比普通线程高很多，所以更适合执行一些高优先级的后台任务

HandlerThread底层通过Looper消息队列实现的，所以它是顺序的执行每一个任务。可以通过Intent的方式开启IntentService，IntentService通过handler将每一个intent加入HandlerThread子线程中的消息队列，通过looper按顺序一个个的取出并执行，执行完成后自动结束自己，不需要开发者手动关闭

12、ANR的原因

1.耗时的网络访问
2.大量的数据读写
3.数据库操作
4.硬件操作（比如camera)
5.调用thread的join()方法、sleep()方法、wait()方法或者等待线程锁的时候
6.service binder的数量达到上限
7.system server中发生WatchDog ANR
8.service忙导致超时无响应
9.其他线程持有锁，导致主线程等待超时
10.其它线程终止或崩溃导致主线程一直等待

13、三级缓存原理

当 Android 端需要获得数据时比如获取网络中的图片，首先从内存中查找（按键查找），内存中没有的再从磁盘文件或sqlite中去查找，若磁盘中也没有才通过网络获取

LruCache 底层实现原理：

LruCache 中 Lru 算法的实现就是通过 LinkedHashMap 来实现的。LinkedHashMap 继承于 HashMap，它使用了一个双向链表来存储 Map中的Entry顺序关系

对于get、put、remove等操作，LinkedHashMap除了要做HashMap做的事情，还做些调整Entry顺序链表的工作。

LruCache中将LinkedHashMap的顺序设置为LRU顺序来实现LRU缓存，每次调用get(也就是从内存缓存中取图片)，则将该对象移到链表的尾端。
调用put插入新的对象也是存储在链表尾端，这样当内存缓存达到设定的最大值时，将链表头部的对象（近期最少用到的）移除。

14、说下你对 Collection 这个类的理解。

Collection是集合框架的顶层接口，是存储对象的容器,Colloction定义了接口的公用方法如add remove clear等等，它的子接口有两个，List和Set,List的特点有元素有序，元素可以重复，元素都有索引（角标），典型的有

Vector:内部是数组数据结构，是同步的（线程安全的）。增删查询都很慢。

ArrayList:内部是数组数据结构，是不同步的（线程不安全的）。替代了Vector。查询速度快，增删比较慢。

LinkedList:内部是链表数据结构，是不同步的（线程不安全的）。增删元素速度快。

而Set的是特点元素无序，元素不可以重复

HashSet：内部数据结构是哈希表，是不同步的。

Set集合中元素都必须是唯一的，HashSet作为其子类也需保证元素的唯一性。

判断元素唯一性的方式：

通过存储对象（元素）的hashCode和equals方法来完成对象唯一性的。

如果对象的hashCode值不同，那么不用调用equals方法就会将对象直接存储到集合中；

如果对象的hashCode值相同，那么需调用equals方法判断返回值是否为true，
若为false, 则视为不同元素，就会直接存储；
若为true，则视为相同元素，不会存储。

如果要使用HashSet集合存储元素，该元素的类必须覆盖hashCode方法和equals方法。一般情况下，如果定义的类会产生很多对象，通常都需要覆盖equals，hashCode方法。建立对象判断是否相同的依据。
TreeSet：保证元素唯一性的同时可以对内部元素进行排序，是不同步的。

判断元素唯一性的方式：

根据比较方法的返回结果是否为0，如果为0视为相同元素，不存；如果非0视为不同元素，则存。

TreeSet对元素的排序有两种方式：

方式一：使元素（对象）对应的类实现Comparable接口，覆盖compareTo方法。这样元素自身具有比较功能。

方式二：使TreeSet集合自身具有比较功能，定义一个比较器Comparator，将该类对象作为参数传递给TreeSet集合的构造函数

-END