Android面经| 问题归纳

面经专题系列：
Android面经| 问题归纳
Android面经| 回顾展望
Android面经| 算法题解

Android相关

AMS相关

ActivityManagerService是Android中最核心的服务 ， 主要负责系统中四大组件的启动、切换、调度及应用进程的管理和调度等工作，其职责与操作系统中的进程管理和调度模块类似。
看源码谈谈AMS启动过程：ActivityManagerService分析——AMS启动流程

Activity相关

SingleTask优化

//如果标签为singleTask的activity在栈顶
onNewIntent()
//如果标签为singleTask的activity不在栈顶
onNewIntent() -> onStart() -> onResume() -> ...

回退栈中的activity不会调用onCreate()，但是这里虽然onNewIntent被调用了，但是Intent中所保存的数据却仍然还是旧数据，因此需要进一步重写。

/***
* 将activity 的创建模式设置为singletask, 
* 使用这个方法可以再其他activity想这个activity发送Intent时，这个Intent能够及时更新
*/
@Override
protected void onNewIntent(Intent intent)
{
     super.onNewIntent(intent);
     setIntent(intent); //这一句必须的，否则Intent无法获得最新的数据
}

SingleTask优化搭配：

<activity
      android:launchMode="singleTask"
      android:taskAffinity="com.renly.MainActivity"
      android:name="com.renly.MainActivity"
      android:screenOrientation="portrait" />

taskAffinity，可以翻译为任务相关性。这个参数标识了一个 Activity 所需要的任务栈的名字，默认情况下，所有 Activity 所需的任务栈的名字为应用的包名，当 Activity 设置了 taskAffinity 属性，那么这个 Activity 在被创建时就会运行在和 taskAffinity 名字相同的任务栈中，如果没有，则新建 taskAffinity 指定的任务栈，并将 Activity 放入该栈中。另外，taskAffinity 属性主要和 singleTask 或者 allowTaskReparenting 属性配对使用，在其他情况下没有意义。

allowTaskReparenting = "true"

在这种情况下，Activity 可以从其启动的任务移动到与其具有关联的任务（如果该任务出现在前台）。

启动模式应用场景

launchMode	使用场景
singleTop	适合启动同类型的 Activity，例如接收通知启动的内容显示页面
singleTask	适合作为程序入口
singleInstance	适合需要与程序分离开的页面，例如闹铃的响铃界面

Intent

显式启动：
一般用于启动应用内的Activity

隐式启动：
a.例子：Intent intent = new Intent(String action，Uri uri);

b.一般用于启动应用外的Activity,操作系统会自动把匹配隐式Intent的Acttivity显
示出来供用户选择，匹 配的规则跟Activity声明的 Intent-filter 有关

c.主要组成部分：

（1）action 要执行的操作。也可以通过 setAction() 设置

（2）uri待访问数据的位置。也可以通过 setData() 和 setDataAndType() 设
置。可以是网页的URL，某个文件的，或指向 ContentProvider 的某个内容 URI

（3）操作涉及的的数据类型。setType() 和 setDataAndType()设置。如intent.setType(“text/html”)

（4）可选类别。描述何时，何地或者如何启动某个 Activity。
intent.addCategory(Intent.CATEGORY_LAUNCHER)

参考博客

Service相关

两种启动方式

1.startService()启动方式：主要用于执行后台计算
2.bindService()启动方式：主要用于和其它组件的交互
说明：这两种状态是可以共存的，即一个Service既可以处于启动状态，也可以同时处于绑定状态。

生命周期

startService() -> onCreate() -> onStartCommand() -> Service运行 -> onDestroy()
bindService() -> onCreate() -> onBind() -> Service运行 -> onUnBind() -> onDestroy()

service 运行于主线程

int onStartCommand(Intent intent, int flags, int startId)会在每次调用startService时回调

FLAG使用START_FLAG_REDELIVERY，意味着当Service因内存不足而被系统kill后，则会重建服务，并通过传递给服务的最后一个 Intent 调用 onStartCommand()

onStartCommand()返回值：
START_STICKY，START_NOT_STICKY，START_REDELIVER_INTENT

service详细介绍

Service 如何和 Activity 进行通信？

① 通过绑定服务的方式。在绑定的服务中声明一个Binder类，并创建一个Binder对象，在onBind()函数中返回这个对象，并让Activity实现ServiceConnection接口，在OnServiceConnected方法中获取到Service提供的这个Binder对象，通过这个对象的各种自定义的方法就能完成Service与Activity的通信。
② 通过Intent的方式，在StartService()中需要传入一个Intent对象作为参数，通过这个Intent实例对象进行实现通信。
③ 通过Callback和Handler的方式，在绑定的服务中声明一个Binder类，并创建一个Binder对象，在onBind()函数中返回这个对象，让Activity实现ServiceConnection接口，并且在OnserviceConnected方法中实例化Service中的CallBack接口，并且实现OnDataChange()方法，其中的实质是一段Handler代码，可以在其中完成耗时操作，以这种方式完成通信。

BroadcastReciever相关

写一个类继承BroadcastReceiver重写onReceive方法，注意onReceive是主线程不要做耗时操作否则阻塞10s会ANR，onReceive()中耗时操作不能开线程做，可以使用goAsync()或使用service来做（由于onReceive在结束后会释放资源，依赖线程也很有可能会被释放）

通过LocalBroadcastManager动态注册的Receiver只会在App应用内广播。

两种注册方式

1.静态注册，在注册清单文件进行声明
2.动态注册，在代码中动态进行注册

//静态注册
<receiver android:name=".MyReceiver">
            <intent-filter>
                <action android:name="kt.com.MyReceiver"/>
            intent-filter>
receiver>

//动态注册
IntentFilter intentFilter = new IntentFilter();
intentFilter.addAction("kt.com.MyReceiver");
registerReceiver(new MyReceiver(),intentFilter);

两种注册方式的区别

1.动态注册的广播是非常驻型广播，此时广播是跟随宿主的生命周期的，宿主不在了广播也就不在了。
2.静态注册的广播是常驻型广播，即应用程序关闭后，依然能够收到广播。

参考博客

ContentProvider相关

ContentProvider管理android以结构化方式存放的数据。他以相对安全的方式封装数据并且提供简易的处理机制。Content provider提供不同进程间数据交互的标准化接口。
参考博客

Broadcast的分类？有序，无序？粘性，非粘性？本地广播？

• 广播可以分为有序广播、无序广播、本地广播、粘性广播。其中无序广播通过sendBroadcast(intent)发送，有序广播通过sendOrderedBroadcast(intent)发送。

• 有序广播。
  (1) 有序广播可以用priority来调整优先级 取值范围-1000~+1000，默认为0，数值越大优先级越高，优先级越高越优先获得广播响应。
  (2) abortBroadcast()可来终止该广播的传播，对更低优先级的屏蔽，注意只对有序广播生效。
  (3) 有序广播在传播数据中会发生比如setResultData()，getResultData()，在传播过程中，可以从新设置数据

• 关于本地广播，可以查看这篇文章。总的来说，本地广播是通过LocalBroadcastManager内置的Handler来实现的，只是利用了IntentFilter的match功能，至于BroadcastReceiver 换成其他接口也无所谓，顺便利用了现成的类和概念而已。在register()的时候保存BroadcastReceiver以及对应的IntentFilter，在sendBroadcast()的时候找到和Intent对应的BroadcastReceiver，然后通过Handler发送消息，触发executePendingBroadcasts()函数，再在后者中调用对应BroadcastReceiver的onReceive()方法。

• 粘性消息：粘性消息在发送后就一直存在于系统的消息容器里面，等待对应的处理器去处理，如果暂时没有处理器处理这个消息则一直在消息容器里面处于等待状态，粘性广播的Receiver如果被销毁，那么下次重建时会自动接收到消息数据。(在 android 5.0/api 21中deprecated,不再推荐使用，相应的还有粘性有序广播，同样已经deprecated)

自定义View的步骤

参考博客

Android中的事件传递机制？

当我们的手指触碰到屏幕，事件是按照Activity->ViewGroup->View这样的流程到达最终响应触摸事件的View的。而在事件分发过程中，涉及到三个最重要的方法：dispatchTouchEvent()、onInterceptTouchEvent()、onTouchEvent。我们的手指触摸到屏幕的时候，会触发一个Action_Down类型的事件，当前页面的Activity会首先做出相应，也就是说会走到Activity的dispatchTouchEvent()方法内。在这个方法内部有下面两个逻辑：

• 调用getWindow.superDispatchTouchEvent()。

• 如果上一步返回true，则直接返回true；否则return自己的onTouchEvent()。显然，当getWindow.superDispatchTouchEvent()返回true，表示当前事件已经被消费掉，无需调用onTouchEvent；否则代表事件并没有被处理，因此需要调用Activity的onTouchEvent进行处理。
  我们都知道，getWindow()返回的是PhoneWindow，因此这句代码本质上调用了PhoneWindow中的superDispatchTouchEvent()。而后者实际上调用了mDecor.superDispatchTouchEvent(event)。这个mDecor也就是DecorView，它是FrameLayout的一个子类。在DecorView中的superDispatchTouchEvent(event)中调用的是super.dispatchTouchEvent()。因此，本质上调用的是ViewGroup的dispatchTouchEvent()。
  到这里，事件已经从Activity传递到ViewGroup了。接下来我们分析ViewGroup。
  在ViewGroup的dispatchTouchEvent()中逻辑大致如下：

• 通过onInterceptTouchEvent()判断当前ViewGroup是否拦截，默认的ViewGroup都是不拦截的；

• 如果拦截，则return自己的onTouchEvent()；

• 如果不拦截，则根据child.dispatchTouchEvent()的返回值判断。如果返回true，则return true；否则return自身的onTouchEvent()，在这里实现了未处理事件的向上传递。

通常情况下，ViewGroup 的 onInterceptTouchEvent() 都返回 false，表示不拦截。这里需要注意的是事件序列，比如Down事件、Move事件…Up事件，从 Down到 Up 是一个完整的事件序列，对应着手指从按下到抬起这一系列事件，如果ViewGroup 拦截了 Down 事件，那么后续事件都会交给这个 ViewGroup 的onTouchEvent。如果 ViewGroup 拦截的不是 Down 事件，那么会给之前处理这个Down 事件的 View发送一个Action_Cancel 类型的事件，通知子View这个后续的事件序列已经被 ViewGroup 接管了，子 View 恢复之前的状态即可。

这里举一个常见的例子：在一个 Recyclerview 中有很多的 Button，我们首先按下了一个 button，然后滑动一段距离再松开，这时候 Recyclerview 会跟着滑动，并不会触发这个 button 的点击事件。这个例子中，当我们按下 button 时，这个 button 接收到了 Action_Down 事件，正常情况下后续的事件序列应该由这个 button处理。但我们滑动了一段距离，这时 Recyclerview 察觉到这是一个滑动操作，拦截了这个事件序列，走了自身的 onTouchEvent()方法，反映在屏幕上就是列表的滑动。而这时 button 仍然处于按下的状态，所以在拦截的时候需要发送一个 Action_Cancel 来通知 button 恢复之前状态。

事件分发最终会走到View的dispatchTouchEvent()中。在View的dispatchTouchEvent()中没有onInterceptTouchEvent()，这里很容易理解，View没有child，也就不存在拦截。View的dispatchTouchEvent()直接return了自己的onTouchEvent()。如果onTouchEvent()返回true代表事件被消费，否则未消费的事件会向上传递，直到有View处理了事件或一直没有消费，最终回到Activity的onTouchEvent()终止。

有时候会有人混淆onTouchEvent和onTouch。首先，这两个方法都在View的dispatchTouchEvent()中：

• 如果touchListener不为null，并且这个View是enable的，而且onTouch返回true，都满足时直接return true，走不到onTouchEvent()方法。

• 否则，就会触发onTouchEvent()。因此onTouch优先于onTouchEvent获得事件处理权。

最后附上流程图总结：
touch事件传递流程

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性能有过多的消耗。

ANR出现的情况有几种？ 怎么分析解决ANR问题？

ANR(Application Not responding)。Android中，主线程(UI线程)如果在规定时内没有处理完相应工作，就会出现ANR。具体来说，ANR会在以下几种情况中出现:
(1) 输入事件(按键和触摸事件)5s内没被处理
(2) BroadcastReceiver的事件(onRecieve方法)在规定时间内没处理完(前台广播为10s，后台广播为60s)
(3) service 前台20s后台200s未完成启动
(4) ContentProvider的publish在10s内没进行完

内存泄露的场景有哪些？内存泄漏分析工具使用方法？

常见的内存泄露有：
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也需要及时移除

而对于内存泄露的检测，常用的工具有LeakCanary、MAT（Memory Analyer Tools）、Android Studio自带的Profiler。

如何避免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的方法

如何实现进程保活

a: Service 设置成 START_STICKY kill 后会被重启(等待5秒左右)，重传Intent，保持与重启前一样
b: 通过 startForeground将进程设置为前台进程， 做前台服务，优先级和前台应用一个级别，除非在系统内存非常缺，否则此进程不会被 kill
c: 双进程Service： 让2个进程互相保护对方，其中一个Service被清理后，另外没被清理的进程可以立即重启进程
d: 用C编写守护进程(即子进程) : Android系统中当前进程(Process)fork出来的子进程，被系统认为是两个不同的进程。当父进程被杀死的时候，子进程仍然可以存活，并不受影响(Android5.0以上的版本不可行）联系厂商，加入白名单
e.锁屏状态下，开启一个一像素Activity

数据库如何进行升级？SQLite增删改查的基础sql语句?

/**
     * Create a helper object to create, open, and/or manage a database.
     * This method always returns very quickly.  The database is not actually
     * created or opened until one of {@link #getWritableDatabase} or
     * {@link #getReadableDatabase} is called.
     *
     * @param context to use to open or create the database
     * @param name of the database file, or null for an in-memory database
     * @param factory to use for creating cursor objects, or null for the default
     * @param version number of the database (starting at 1); if the database is older,
     *     {@link #onUpgrade} will be used to upgrade the database; if the database is
     *     newer, {@link #onDowngrade} will be used to downgrade the database
     */
    public SQLiteOpenHelper(Context context, String name, CursorFactory factory, int version) {
        this(context, name, factory, version, null);
    }

    public SQLiteDatabase getWritableDatabase() {
        synchronized (this) {
            return getDatabaseLocked(true);
        }
    }

  private SQLiteDatabase getDatabaseLocked(boolean writable) {
      .......
      db.beginTransaction();
      try {
              if (version == 0) {
                   onCreate(db);
              } else {
                   if (version > mNewVersion) {
                         onDowngrade(db, version, mNewVersion);
                   } else {
                         onUpgrade(db, version, mNewVersion);
                   }
              }
               db.setVersion(mNewVersion);
                db.setTransactionSuccessful();
              } finally {
                 db.endTransaction();
              }
  }

在 SQLiteOpenHelper 的构造函数中，包含了一个 version 的参数。这个参数即是数据库的版本。 所以，我们可以通过修改 version 来实现数据库的升级。 当version 大于原数据库版本时，onUpgrade()会被触发，可以在该方法中编写数据库升级逻辑。具体的数据库升级逻辑示例可参考这里。

常用的SQL增删改查：

• 增：INSERT INTO table_name (列1, 列2,…) VALUES (值1, 值2,….)

• 删： DELETE FROM 表名称 WHERE 列名称 = 值

• 改：UPDATE 表名称 SET 列名称 = 新值 WHERE 列名称 = 某值

• 查：SELECT 列名称（通配是*符号） FROM 表名称

ps:操作数据表是:ALTER TABLE。该语句用于在已有的表中添加、修改或删除列。
ALTER TABLE table_name ADD column_name datatype
ALTER TABLE table_name DROP COLUMN column_name

Android屏幕适配

一种极低成本的Android屏幕适配方式 - 字节跳动技术团队

AsyncTask、HandlerThread、IntentService区别和使用

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按顺序一个个的取出并执行，执行完成后自动结束自己，不需要开发者手动关闭
  IntentService分析

Bitmap优化

主动释放Bitmap资源

bitmap.recycle(); 
bitmap = null; 

在不加载图片的前提下获得图片的宽高

BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;

图片大小压缩,采样率一般是2的指数，即1、2、4、8、16……

bitmapFactoryOptions.inSampleSize = 2;

图片像素压缩
Android中图片有四种属性，分别是：
ALPHA_8：每个像素占用1byte内存
ARGB_4444：每个像素占用2byte内存
ARGB_8888：每个像素占用4byte内存 （默认）
RGB_565：每个像素占用2byte内存
Android默认的颜色模式为ARGB_8888，这个颜色模式色彩最细腻，显示质量最高。但同样的，占用的内存也最大。 所以在对图片效果不是特别高的情况下使用RGB_565（565没有透明度属性），如下：

        public static Bitmap readBitMap(Context context, intresId) {
            BitmapFactory.Options opt = newBitmapFactory.Options();
            opt.inPreferredConfig = Bitmap.Config.RGB_565;
            opt.inPurgeable = true;
            opt.inInputShareable = true;
            //获取资源图片 
            InputStreamis = context.getResources().openRawResource(resId);
            returnBitmapFactory.decodeStream(is, null, opt);
        }

Android框架相关

LeakCanary相关

相关播客

Retrofit相关

RxJava相关

okHttp相关

rxjava相关

mvp相关

以上移步笔者博客 学习笔记| OkHttp+Retrofit+Dagger2+RxJava+MVP架构

Java相关

该部分内容笔者按照该博客集合顺序+阅读源码进行复习。
Java相关博客专题

collection里面有什么子类？

（其实面试的时候听到这个问题的时候，你要知道，面试官是想考察List，Set）
list和set是实现了collection接口的。

• List：
  1.可以允许重复的对象。
  2.可以插入多个null元素。
  3.是一个有序容器，保持了每个元素的插入顺序，输出的顺序就是插入的顺序。
  4.常用的实现类有 ArrayList、LinkedList 和 Vector。ArrayList 最为流行，它提供了使用索引的随意访问，而 LinkedList 则对于经常需要从 List 中添加或删除元素的场合更为合适。

• Set：
  1.不允许重复对象
  2.无序容器，你无法保证每个元素的存储顺序，TreeSet通过 Comparator 或者 Comparable 维护了一个排序顺序。
  3.只允许一个 null 元素
  4.Set 接口最流行的几个实现类是 HashSet、LinkedHashSet 以及 TreeSet。最流行的是基于HashMap 实现的 HashSet；TreeSet 还实现了 SortedSet 接口，因此 TreeSet 是一个根据其compare() 和 compareTo() 的定义进行排序的有序容器。

什么场景下使用list，set，map？

• 如果你经常会使用索引来对容器中的元素进行访问，那么 List 是你的正确的选择。如果你已经知道索引了的话，那么 List 的实现类比如 ArrayList 可以提供更快速的访问,如果经常添加删除元素的，那么肯定要选择LinkedList。
• 如果你想容器中的元素能够按照它们插入的次序进行有序存储，那么还是 List，因为 List 是一个有序容器，它按照插入顺序进行存储。
• 如果你想保证插入元素的唯一性，也就是你不想有重复值的出现，那么可以选择一个 Set 的实现类，比如 HashSet、LinkedHashSet 或者 TreeSet。所有 Set 的实现类都遵循了统一约束比如唯一性，而且还提供了额外的特性比如 TreeSet 还是一个 SortedSet，所有存储于 TreeSet 中的元素可以使用 Java 里的 Comparator 或者 Comparable 进行排序。LinkedHashSet 也按照元素的插入顺序对它们进行存储。
• 如果你以键和值的形式进行数据存储那么 Map 是你正确的选择。你可以根据你的后续需要从 Hashtable、HashMap、TreeMap 中进行选择。

fail-fast机制

“快速失败”也就是fail-fast，它是Java集合的一种错误检测机制。当多个线程对集合进行结构上的改变的操作时，有可能会产生fail-fast机制。记住是有可能，而不是一定。例如：假设存在两个线程（线程1、线程2），线程1通过Iterator在遍历集合A中的元素，在某个时候线程2修改了集合A的结构（是结构上面的修改，而不是简单的修改集合元素的内容），那么这个时候程序就会抛出ConcurrentModificationException 异常，从而产生fail-fast机制。
相关博客

ArrayList和LinkedList的区别

• Arraylist
  底层是基于动态数组，根据下表随机访问数组元素的效率高，向数组尾部添加元素的效率高；但是，删除数组中的数据以及向数组中间添加数据效率低，因为需要移动数组。例如最坏的情况是删除第一个数组元素，则需要将第2至第n个数组元素各向前移动一位。而之所以称为动态数组，是因为Arraylist在数组元素超过其容量大，Arraylist可以进行扩容（针对JDK1.8? 数组扩容后的容量是扩容前的1.5倍）

• Linkedlist
  基于链表的动态数组，数据添加删除效率高，只需要改变指针指向即可，但是访问数据的平均效率低，需要对链表进行遍历。

HashMap、Hashtable、ConcurrentHashMap的原理与区别

HashTable

• 底层数组+链表实现，无论key还是value都不能为null，线程安全，实现线程安全的方式是在修改数据时锁住整个HashTable，效率低，ConcurrentHashMap做了相关优化
• 初始size为11，扩容：newsize = olesize*2+1
• 计算index的方法：index = (hash & 0x7FFFFFFF) % tab.length

HashMap

• 底层数组+链表实现，可以存储null键和null值，线程不安全
• 初始size为16，扩容：newsize = oldsize*2，size一定为2的n次幂
• 扩容针对整个Map，每次扩容时，原来数组中的元素依次重新计算存放位置，并重新插入
• 插入元素后才判断该不该扩容，有可能无效扩容（插入后如果扩容，如果没有再次插入，就会产生无效扩容）
• 当Map中元素总数超过Entry数组的75%，触发扩容操作，为了减少链表长度，元素分配更均匀
• 计算index方法：index = hash & (tab.length – 1)
  HashMap面试题

ConcurrentHashMap

• 底层采用分段的数组+链表实现，线程安全
• 通过把整个Map分为N个Segment，可以提供相同的线程安全，但是效率提升N倍，默认提升16倍。(读操作不加锁，由于HashEntry的value变量是 volatile的，也能保证读取到最新的值。)
• Hashtable的synchronized是针对整张Hash表的，即每次锁住整张表让线程独占，ConcurrentHashMap允许多个修改操作并发进行，其关键在于使用了锁分离技术
• 有些方法需要跨段，比如size()和containsValue()，它们可能需要锁定整个表而而不仅仅是某个段，这需要按顺序锁定所有段，操作完毕后，又按顺序释放所有段的锁
• 扩容：段内扩容（段内元素超过该段对应Entry数组长度的75%触发扩容，不会对整个Map进行扩容），插入前检测需不需要扩容，有效避免无效扩容

详细原理区别内容

Hash冲突如何解决？

开放定址法

这种方法也称再散列法，其基本思想是：当关键字key的哈希地址p=H（key）出现冲突时，以p为基础，产生另一个哈希地址p1，如果p1仍然冲突，再以p为基础，产生另一个哈希地址p2，…，直到找出一个不冲突的哈希地址pi ，将相应元素存入其中。这种方法有一个通用的再散列函数形式：
Hi=（H（key）+di）% m i=1，2，…，n
其中H（key）为哈希函数，m 为表长，di称为增量序列。增量序列的取值方式不同，相应的再散列方式也不同。主要有以下三种：

• 线性探测再散列
  dii=1，2，3，…，m-1
  这种方法的特点是：冲突发生时，顺序查看表中下一单元，直到找出一个空单元或查遍全表。
• 二次探测再散列
  di=12，-12，22，-22，…，k2，-k2 ( k<=m/2 )
  这种方法的特点是：冲突发生时，在表的左右进行跳跃式探测，比较灵活。
• 伪随机探测再散列

再哈希法

这种方法是同时构造多个不同的哈希函数：

Hi=RH1（key） i=1，2，…，k

当哈希地址Hi=RH1（key）发生冲突时，再计算Hi=RH2（key）……，直到冲突不再产生。这种方法不易产生聚集，但增加了计算时间。

链地址法

这种方法的基本思想是将所有哈希地址为i的元素构成一个称为同义词链的单链表，并将单链表的头指针存在哈希表的第i个单元中，因而查找、插入和删除主要在同义词链中进行。链地址法适用于经常进行插入和删除的情况。

如何理解Java的多态？其中，重载和重写有什么区别？

多态是同一个行为具有多个不同表现形式或形态的能力，多态是同一个接口，使用不同的实例而执行不同操作，多态就是程序运行期间才确定，一个引用变量倒底会指向哪个类的实例对象，该引用变量发出的方法调用到底是哪个类中实现的方法。
多态存在的三个必要条件是：继承，重写，父类引用指向子类引用。
多态的三个实现方式是：重写，接口，抽象类和抽象方法。

final关键字的用法？

final 可以修饰类、变量和方法。修饰类代表这个类不可被继承。修饰变量代表此变量不可被改变。修饰方法表示此方法不可被重写 (override)。

死锁是怎么导致的？如何定位死锁？

某个任务在等待另一个任务，而后者又等待别的任务，这样一直下去，直到这个链条上的任务又在等待第一个任务释放锁。这得到了一个任务之间互相等待的连续循环，没有哪个线程能继续。这被称之为死锁。当以下四个条件同时满足时，就会产生死锁：
(1) 互斥条件。任务所使用的资源中至少有一个是不能共享的。
(2) 任务必须持有一个资源，同时等待获取另一个被别的任务占有的资源。
(3) 资源不能被强占。
(4) 必须有循环等待。一个任务正在等待另一个任务所持有的资源，后者又在等待别的任务所持有的资源，这样一直下去，直到有一个任务在等待第一个任务所持有的资源，使得大家都被锁住。
首先模拟问题定位，使用jstack，使用 jps或者系统的ps命令、任务管理器等工具，确定进程ID。
然后获取线程栈：

${JAVA_HOME}\bin\jstack your_pid

避免死锁的方法思路：

尽量避免使用多个锁，并且只有需要的时候才持有锁。
如果使用多个锁，尽量设计好锁的获取顺序。例如银行家算法。
使用带超时的方法，为程序带来更多的可控性。

反射【待补全】

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

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

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

线程池的工作原理：线程池可以减少创建和销毁线程的次数，从而减少系统资源的消耗，当一个任务提交到线程池时
a. 首先判断核心线程池中的线程是否已经满了，如果没满，则创建一个核心线程执行任务，否则进入下一步
b. 判断工作队列是否已满，没有满则加入工作队列，否则执行下一步
c. 判断线程数是否达到了最大值，如果不是，则创建非核心线程执行任务，否则执行饱和策略，默认抛出异常

进程与线程的区别

进程是资源（CPU、内存等）分配的基本单位，它是程序执行时的一个实例。
线程是程序执行时的最小单位，它是进程的一个执行流，是CPU调度和分派的基本单位，一个进程可以由很多个线程组成，线程间共享进程的所有资源，每个线程有自己的堆栈和局部变量。线程由CPU独立调度执行，在多CPU环境下就允许多个线程同时运行。同样多线程也可以实现并发操作，每个请求分配一个线程来处理。

设计模式相关

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

建造者模式

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
使用场景比如最常见的AlertDialog,拿我们开发过程中举例，比如Camera开发过程中，可能需要设置一个初始化的相机配置，设置摄像头方向，闪光灯开闭，成像质量等等，这种场景下就可以使用建造者模式

装饰者模式

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

生产者消费者模式

生产者消费者模式并不是GOF提出的23种设计模式之一，23种设计模式都是建立在面向对象的基础之上的，但其实面向过程的编程中也有很多高效的编程模式，生产者消费者模式便是其中之一，它是我们编程过程中最常用的一种设计模式。

在实际的软件开发过程中，经常会碰到如下场景：某个模块负责产生数据，这些数据由另一个模块来负责处理（此处的模块是广义的，可以是类、函数、线程、进程等）。产生数据的模块，就形象地称为生产者；而处理数据的模块，就称为消费者。

单单抽象出生产者和消费者，还够不上是生产者／消费者模式。该模式还需要有一个缓冲区处于生产者和消费者之间，作为一个中介。生产者把数据放入缓冲区，而消费者从缓冲区取出数据。

JVM相关

谈一下JVM内存区域划分？哪部分是线程公有的，哪部分是私有的？

JVM 的内存区域可以分为两类：线程私有和区域和线程共有的区域。
线程私有的区域：程序计数器、JVM 虚拟机栈、本地方法栈；
线程共有的区域：堆、方法区、运行时常量池。

• 程序计数器，也有称作PC寄存器。每个线程都有一个私有的程序计数器，任何时间一个线程都只会有一个方法正在执行，也就是所谓的当前方法。程序计数器存放的就是这个当前方法的JVM指令地址。当CPU需要执行指令时，需要从程序计数器中得到当前需要执行的指令所在存储单元的地址，然后根据得到的地址获取到指令，在得到指令之后，程序计数器便自动加1或者根据转移指针得到下一条指令的地址，如此循环，直至执行完所有的指令。

• JVM虚拟机栈。创建线程的时候会创建线程内的虚拟机栈，栈中存放着一个个的栈帧，对应着一个个方法的调用。JVM 虚拟机栈有两种操作，分别是压栈和出站。栈帧中存放着局部变量表(Local Variables)、操作数栈(Operand Stack)、指向当前方法所属的类的运行时常量池的引用(Reference to runtime constant pool)、方法返回地址(Return Address)和一些额外的附加信息。

• 本地方法栈。本地方法栈与Java栈的作用和原理非常相似。区别只不过是Java栈是为执行Java方法服务的，而本地方法栈则是为执行本地方法（Native Method）服务的。在JVM规范中，并没有对本地方发展的具体实现方法以及数据结构作强制规定，虚拟机可以自由实现它。在HotSopt虚拟机中直接就把本地方法栈和Java栈合二为一。

• 堆。堆是内存管理的核心区域，用来存放对象实例。几乎所有创建的对象实例都会直接分配到堆上。所以堆也是垃圾回收的主要区域，垃圾收集器会对堆有着更细的划分，最常见的就是把堆划分为新生代和老年代。java堆允许处于不连续的物理内存空间中，只要逻辑连续即可。堆中如果没有空间完成实例分配无法扩展时将会抛出OutOfMemoryError异常。

• 方法区。方法区与堆一样所有线程所共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、及时编译器编译后的代码等数据。在Class文件中除了类的字段、方法、接口等描述信息外，还有一项信息是常量池，用来存储编译期间生成的字面量和符号引用。

其实除了程序计数器，其他的部分都会发生 OOM。

• 堆。 通常发生的 OOM 都会发生在堆中，最常见的可能导致 OOM 的原因就是内存泄漏。

• JVM虚拟机栈和本地方法栈。 当我们写一个递归方法，这个递归方法没有循环终止条件，最终会导致 StackOverflow 的错误。当然，如果栈空间扩展失败，也是会发生 OOM 的。

• 方法区。方法区现在基本上不太会发生 OOM，但在早期内存中加载的类信息过多的情况下也是会发生 OOM 的。

GC的两种判定方法（对象存活判定）：

引用计数和可达性分析。

引用计数方式

最基本的形态就是让每个被管理的对象与一个引用计数器关联在一起，该计数器记录着该对象当前被引用的次数，每当创建一个新的引用指向该对象时其计数器就加1，每当指向该对象的引用失效时计数器就减1。当该计数器的值降到0就认为对象死亡。

可达性分析算法

将GC Roots对象作为起始节点，向下搜索，搜索走过的路径为引用链；当一个对象到GC Roots没有引用链时，则该对象是不可用的；

可作为GC Roots的对象：

1. 方法区中静态属性引用的对象

2. 方法区中常量引用的对象

3. 虚拟机栈引用的对象 (栈帧中本地变量表)

4. 本地方法栈中JNI引用的对象 (Native方法)

GC的三种收集方法：

标记清除、标记整理、复制算法的原理与特点，分别用在什么地方，如果让你优化收集方法，有什么思路？

标记清除算法

最基础的收集算法，其他收集算法都是基于这种思想。标记清除算法分为“标记”和“清除”两个阶段：首先标记出需要回收的对象，标记完成之后统一清除对象。
它的主要缺点：
①.标记和清除过程效率不高 。
②.标记清除之后会产生大量不连续的内存碎片。

标记整理

标记操作和“标记-清除”算法一致，后续操作不只是直接清理对象，而是在清理无用对象完成后让所有存活的对象都向一端移动，并更新引用其对象的指针。主要缺点：在标记-清除的基础上还需进行对象的移动，成本相对较高，好处则是不会产生内存碎片。

复制算法

它将可用内存容量划分为大小相等的两块，每次只使用其中的一块。当这一块用完之后，就将还存活的对象复制到另外一块上面，然后在把已使用过的内存空间一次理掉。这样使得每次都是对其中的一块进行内存回收，不会产生碎片等情况，只要移动堆订的指针，按顺序分配内存即可，实现简单，运行高效。主要缺点：内存缩小为原来的一半。

双亲委派模型：

Bootstrap ClassLoader、Extension ClassLoader、ApplicationClassLoader。

启动类加载器，负责将存放在\lib目录中的，或者被-Xbootclasspath参数所指定的路径中，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即时放在lib目录中也不会被加载）类库加载到虚拟机内存中。启动类加载器无法被java程序直接引用。
扩展类加载器：负责加载\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用该类加载器。
应用程序类加载器：负责加载用户路径上所指定的类库，开发者可以直接使用这个类加载器，也是默认的类加载器。 三种加载器的关系：启动类加载器->扩展类加载器->应用程序类加载器->自定义类加载器。
这种关系即为类加载器的双亲委派模型。其要求除启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不以继承关系实现，而是用组合的方式来复用父类的代码。

双亲委派模型的工作过程：如果一个类加载器接收到了类加载的请求，它首先把这个请求委托给他的父类加载器去完成，每个层次的类加载器都是如此，因此所有的加载请求都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它在搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。

好处：java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar中，无论哪个类加载器要加载这个类，最终都会委派给启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果用户自己写了一个名为java.lang.Object的类，并放在程序的Classpath中，那系统中将会出现多个不同的Object类，java类型体系中最基础的行为也无法保证，应用程序也会变得一片混乱。

实现：在java.lang.ClassLoader的loadClass()方法中，先检查是否已经被加载过，若没有加载则调用父类加载器的loadClass()方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父加载失败，则抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。

高并发相关

ThreadLocal的设计理念与作用

ThreadPool用法与优势（这里在Android SDK原生的AsyncTask底层也有使用）

线程池的底层实现和工作原理（建议写一个雏形简版源码实现）

计算机网络相关

TCP/IP五层模型

在TCP/IP四层协议中，网络层又被称为网际层（用网际层这个名字是强调这一层是为了解决不同网络的互连问题），而数据链路层与物理层合并为网络接口层。

TCP协议

• Transmission Control Protocol，传输控制协议
• 面向连接的协议
• 需要三次握手建立连接
• 需要四次挥手断开连接
• TCP报头最小长度：20字节

三次握手过程

1. 客户端发送：SYN = 1, SEQ = X, 端口号
2. 服务器回复：SYN = 1, ACK = X + 1, SEQ = Y
3. 客户端发送：ACK = Y + 1, SEQ = X + 1

确认应答信号ACK = 收到的SEQ + 1。 连接建立中，同步信号SYN始终为1。连接建立后，同步信号SYN=0。

四次挥手过程

1. A向B提出停止连接请求，FIN = 1
2. B收到，ACK = 1
3. B向A提出停止连接请求，FIN = 1
4. A收到，ACK = 1

SYN:同步位
seq:编号位
ACK:确认位
ack:确认编号位

算法相关

面试中的 10 大排序算法总结