面试题总结

Java基础

1. synchronized关键字

synchronized关键字.png

2. synchronized 关键字和 volatile 关键字的区别？

• volatile 是变量修饰符；synchronized 是修饰类、方法、代码段。
  volatile 仅能实现变量的修改可见性，不能保证原子性；而 synchronized 则可以保证变量的修改可见性和原子性。
  volatile不会造成线程的阻塞；synchronized可能会造成线程的阻塞。

3. ArrayList 和 LinkList 区别、优劣势

• 数据结构不同
  ArrayList是Array(动态数组)的数据结构，LinkedList是Link(链表)的数据结构。
• 效率不同
  当随机访问List（get和set操作）时，ArrayList比LinkedList的效率更高，因为LinkedList是线性的数据存储方式，所以需要移动指针从前往后依次查找。
  当对数据进行增加和删除的操作(add和remove操作)时，LinkedList比ArrayList的效率更高，因为ArrayList是数组，所以在其中进行增删操作时，会对操作点之后所有数据的下标索引造成影响，需要进行数据的移动。
• 自由性不同
  ArrayList自由性较低，因为它需要手动的设置固定大小的容量，但是它的使用比较方便，只需要创建，然后添加数据，通过调用下标进行使用；而LinkedList自由性较高，能够动态的随数据量的变化而变化，但是它不便于使用。
• 主要控件开销不同
  ArrayList主要控件开销在于需要在lList列表预留一定空间；而LinkList主要控件开销在于需要存储结点信息以及结点指针信息。

Android基础

1. 实现一个自定义View的基本流程

• 三部分:Measure - Layout - Draw
• ① 自定义View的属性 编写attr.xml文件
  ② 在layout布局文件中引用，同时引用命名空间
  ③ 在View的构造方法中获得我们自定义的属性,在自定义控件中进行读取（构造方法拿到attr.xml文件值）
  ④ 重写onMesure
  ⑤ 重写onDraw方法

2. Android异步消息处理机制

• 主要是用来解决子线程更新UI的问题
• 四个部分：
  ①Message（消息）在线程之间传递，可在内部携带少量信息，用于不同线程之间交换数据 可以使用what、arg1、arg2字段携带整型数据 obj字段携带Object对象
  ② Handler（处理者）主要用于发送和处理消息，sendMessage（）用来发送消息，最终会回到handleMessage（）进行处理
  ③ MessageQueue（消息队列）主要存放所有通过Handler发送的消息，它们会一直存在于队列中等待被处理 每个线程只有一个MessageQueue
  ④ Looper（循环器）调用loop（）方法后，会不断从MessageQueue 取出待处理的消息，然后传递到handleMessage进行处理

3. Android Handler消息机制？

• 多个线程并发更新UI的同时 保证线程安全。
• 作用： Handler主要作用用于定时任务和实现了不同线程间的通信（跨线程通信）。
• 四要素： Message（消息）：需要被传递的消息，其中包含了消息ID，消息处理对象以及处理的数据等，由MessageQueue统一列队，最终由Handler处理。 MessageQueue（消息队列）：用来存放Handler发送过来的消息，内部通过单链表的数据结构来维护消息列表，等待Looper的抽取。
  Handler（处理者）：负责Message的发送及处理。通过 Handler.sendMessage() 向消息池发送各种消息事件；通过 Handler.handleMessage() 处理相应的消息事件。 Looper（消息泵）：通过Looper.loop()不断地从MessageQueue中抽取Message，按分发机制将消息分发给目标处理者。
  过程：
  Handler.sendMessage()发送消息时，会通过MessageQueue.enqueueMessage()向MessageQueue中添加一条消息； 通过Looper.loop()开启循环后，不断轮询调用MessageQueue.next()； 调用目标Handler.dispatchMessage()去传递消息，目标Handler收到消息后调用Handler.handlerMessage()处理消息

Handler 内存泄漏原因?：
将 Handler 定义成静态的内部类，在内部持有 Activity 的弱引用，并在Acitivity的onDestroy()中调用handler.removeCallbacksAndMessages(null)及时移除所有消息。

4. 图片适配怎么做的？

屏幕尺寸适配.png

5. 图片加载与优化怎么做的?
优化: 图片的三级缓存 好处:减少不必要的网络交互。从加载的图片的本身和手机的存储两方面考虑。
使用图片压缩:通过BitmapFactory.Options就可以按一定的采样率来加载缩小后的图片。

图片加载与优化.png

6.Android三级缓存？
网络加载： 不优先加载，速度慢，浪费流量
本地缓存： 次优先加载，速度快
内存缓存： 优先加载，速度最快
首次加载Android App时，肯定要通过网络交互来获取图片，之后我们可以将图片保存至本地SD卡和内存中，之后运行APP时，优先访问内存中的图片缓存，若内存中没有，则加载本地SD卡中图片，最后选择访问网络

7. Parcelable 和 Serializable的区别和使用

• Parcelable和Serializable都是实现序列化并且都可以用于Intent间传递数据。
• Serializable是Java的实现方式,可能会频繁的IO操作,所以消耗比较大,但是实现方式简单。
  Parcelable是Android提供的方式,效率比较高,但是实现起来复杂一些，二者的选取规则是:内存序列化上选择Parcelable, 存储到设备或者网络传输上选择Serializable(当然Parcelable也可以但是稍显复杂)

8. 性能优化，具体做了哪儿些操作？
卡顿优化:UI 绘制、应用启动、页面跳转、事件响应、布局优化

9. binder消息机制
Binder是Android系统进程间通信（IPC）方式之一 ,Binder更加简洁和快速,消耗的内存资源更小。
Binder主要能提供以下一些功能：
用驱动程序来推进进程间的通信。
通过共享内存来提高性能。
为进程请求分配每个进程的线程池。
针对系统中的对象引入了引用计数和跨进程的对象引用映射。

10. 事件分发机制

10. 内存泄漏与内存溢出的原因及解决方案？
内存泄漏（Memory leak）: 当一个对象不在使用了，本应该被垃圾回收器（JVM）回收，但是这个对象由于被其他正在使用的对象所持有，造成无法被回收的结果，通俗点就是系统把一定的内存值A借给程序，但是系统却收不回完整的A值，那就是内存泄漏。

内存溢出（Out of memory）: 系统会给每个APP分配内存也就是Heap size值，当APP所需要的内存大于了系统分配的内存，就会造成内存溢出；就是程序A找系统借内存实例化对象，但是系统没有那么多内存可借。导致功能实现失败。这就是内存溢出。

<u>内存泄漏是造成内存溢出（OOM）的主要原因，因为系统分配给每个程序的内存也就是Heap size的值都是有限的，当内存泄漏到一定值的时候，最终会发生程序所需要的内存值加上泄漏值大于了系统所分配的内存额度，就是触发内存溢出。</u>

Android中内存泄漏、内存溢出的原因以及解决方案
1、大量的图片、音频、视频处理，当在内存比较低的系统上也容易造成内存溢出
建议使用第三方，或者JNI来进行处理
2、Bitmap对象的不正确处理（内存溢出）

• 不要在主线程中处理图片

• 使用Bitmap对象要用recycle释放

• 大图处理

3、非静态匿名内部类Handler由于持有外部类Activity的引用所造成的内存泄漏
根据WeakReference对象，对handler使用弱引用，并且调用removeCallbacksAndMessages移除
4、线程由于匿名内部类runnable持有activity的引用，从而关闭activity，线程未完成造成内存泄漏
把线程改成静态内部类，调用WeakReference来持有外部资源
5、BraodcastReceiver、File、Cursor等资源的使用未及时关闭
在销毁activity时，应该及时销毁或者回收
6、static关键字修饰的变量由于生命周期过长，容易造成内存泄漏
尽量少使用静态变量，一定要使用要及时进行制null处理
7、单列模式造成的内存泄漏
如context的使用，单列中传入的是activity的context，在关闭activity时，activity的内存无法被回收，因为单列持有activity的引用
在context的使用上，应该传入application的context到单列模式中，这样就保证了单列的生命周期跟application的生命周期一样
单列模式应该尽量少持有生命周期不同的外部对象，一旦持有该对象的时候，必须在该对象的生命周期结束前制null

在Android中实现异步任务机制有两种方式，Handler和AsyncTask。

Android Handler消息机制？

• 多个线程并发更新UI的同时 保证线程安全。
• 作用： Handler主要作用用于定时任务和实现了不同线程间的通信（跨线程通信）。
• 四要素： Message（消息）：需要被传递的消息，其中包含了消息ID，消息处理对象以及处理的数据等，由MessageQueue统一列队，最终由Handler处理。 MessageQueue（消息队列）：用来存放Handler发送过来的消息，内部通过单链表的数据结构来维护消息列表，等待Looper的抽取。
  Handler（处理者）：负责Message的发送及处理。通过 Handler.sendMessage() 向消息池发送各种消息事件；通过 Handler.handleMessage() 处理相应的消息事件。 Looper（消息泵）：通过Looper.loop()不断地从MessageQueue中抽取Message，按分发机制将消息分发给目标处理者。
  过程：
  Handler.sendMessage()发送消息时，会通过MessageQueue.enqueueMessage()向MessageQueue中添加一条消息； 通过Looper.loop()开启循环后，不断轮询调用MessageQueue.next()； 调用目标Handler.dispatchMessage()去传递消息，目标Handler收到消息后调用Handler.handlerMessage()处理消息

Handler 内存泄漏原因?：
将 Handler 定义成静态的内部类，在内部持有 Activity 的弱引用，并在Acitivity的onDestroy()中调用handler.removeCallbacksAndMessages(null)及时移除所有消息。
AsyncTask也一样，应被声明为Activity的静态内部类。

AsyncTask
作用：
实现多线程
在工作线程中执行任务，如 耗时任务
异步通信、消息传递
实现工作线程 & 主线程（UI线程）之间的通信，即：将工作线程的执行结果传递给主线程，从而在主线程中执行相关的UI操作，从而保证线程安全。
优点：

• 方便实现异步通信，不需使用 “任务线程（如继承Thread类） + Handler”的复杂组合。
• 节省资源
• 采用线程池的缓存线程 + 复用线程，避免了频繁创建 & 销毁线程所带来的系统资源开销

使用步骤有3个：
创建 AsyncTask 子类 & 根据需求实现核心方法

类中参数为3种泛型类型
整体作用：控制AsyncTask子类执行线程任务时各个阶段的返回类型
具体说明：
a. Params：开始异步任务执行时传入的参数类型，对应excute（）中传递的参数
b. Progress：异步任务执行过程中，返回下载进度值的类型
c. Result：异步任务执行完成后，返回的结果类型，与doInBackground()的返回值类型保持一致
注：
a. 使用时并不是所有类型都被使用
b. 若无被使用，可用java.lang.Void类型代替
c. 若有不同业务，需额外再写1个AsyncTask的子类
创建 AsyncTask子类的实例对象（即 任务实例）
手动调用execute（）从而执行异步线程任务

跨进程通信
Intent，比如拨打电话
ContentProvider，数据库存储数据
Broadcast，广播通信
AIDL通信，通过接口共享数据

设计模式

1. 简述单例模式
单例模式1
单例模式2

2. 简述观察者模式
观察者模式

3. 简述责任链模式
责任链模式

框架类

图片类框架

图片加载框架有哪些？他们之间的区别是什么？

• ImageLoader ：
  优点: ①　支持下载进度监听； ②　可以在 View 滚动中暂停图片加载； ③　默认实现多种内存缓存算法这几个图片缓存都可以配置缓存算法，不过 ImageLoader 默认实现了较多缓存算法，如 Size 最大先删除、使用最少先删除、最近最少使用、先进先删除、时间最长先删除等； ④　支持本地缓存文件名规则定义；
  缺点: 缺点在于不支持GIF图片加载, 缓存机制没有和http的缓存很好的结合, 完全是自己的一套缓存机制

• Picasso：
  优点: ①　自带统计监控功能，支持图片缓存使用的监控，包括缓存命中率、已使用内存大小、节省的流量等。 ②　支持优先级处理 ③　支持延迟到图片尺寸计算完成加载 ④　支持飞行模式、并发线程数根据网络类型而变，手机切换到飞行模式或网络类型变换时会自动调整线程池最大并发数。 ⑤ “无”本地缓存。Picasso 自己没有实现本地缓存，而由okhttp 去实现，这样的好处是可以通过请求 Response Header 中的 Cache-Control 及 Expired 控制图片的过期时间。
  缺点: 不支持GIF，默认使用ARGB_8888格式缓存图片，缓存体积大。

• Glide：
  优点: ①　图片缓存->媒体缓存 ，支持 Gif、WebP、缩略图。甚至是 Video。 ②　支持优先级处理 ③　与 Activity/Fragment 生命周期一致，支持 trimMemory ④　支持 okhttp、Volley。Glide 默认通过 UrlConnection 获取数据，可以配合 okhttp 或是 Volley 使用。实际 ImageLoader、Picasso 也都支持 okhttp、Volley。 ⑤　内存友好，内存缓存更小图片，图片默认使用默认 RGB565 而不是 ARGB888
  缺点: 清晰度差，但可以设置

• Fresco：
  优点: ①　图片存储在安卓系统的匿名共享内存, 而不是虚拟机的堆内存中,所以不会因为图片加载而导致oom, 同时也减少垃圾回收器频繁调用回收Bitmap导致的界面卡顿,性能更高. ②　渐进式加载JPEG图片, 支持图片从模糊到清晰加载 ③　图片可以以任意的中心点显示在ImageView, 而不仅仅是图片的中心. ④ JPEG图片改变大小也是在native进行的, 不是在虚拟机的堆内存, 同样减少OOM ⑤　很好的支持GIF图片的显示
  缺点: 框架较大, 影响Apk体积，使用较繁琐

网络类框架

网络框架有哪些？他们之间的区别是什么？

• Xutils：
  这个框架非常全面，可以进行网络请求，可以进行图片加载处理，可以数据储存，还可以对view进行注解，使用这个框架非常方便，但是缺点也是非常明显的，使用这个项目，会导致项目对这个框架依赖非常的严重，一旦这个框架出现问题，那么对项目来说影响非常大的。

• OKhttp：
  Android开发中是可以直接使用现成的api进行网络请求的。就是使用HttpClient,HttpUrlConnection进行操作。okhttp针对Java和Android程序，封装的一个高性能的http请求库，支持同步，异步，而且okhttp又封装了线程池，封装了数据转换，封装了参数的使用，错误处理等。API使用起来更加的方便。但是我们在项目中使用的时候仍然需要自己在做一层封装，这样才能使用的更加的顺手。

• Volley：
  Volley是Google官方出的一套小而巧的异步请求库，该框架封装的扩展性很强，支持HttpClient、HttpUrlConnection， 甚至支持OkHttp，而且Volley里面也封装了ImageLoader，所以如果你愿意你甚至不需要使用图片加载框架，不过这块功能没有一些专门的图片加载框架强大，对于简单的需求可以使用，稍复杂点的需求还是需要用到专门的图片加载框架。Volley也有缺陷，比如不支持post大数据，所以不适合上传文件。不过Volley设计的初衷本身也就是为频繁的、数据量小的网络请求而生。

• ❤️Retrofit：
  Retrofit是Square公司出品的默认基于OkHttp封装的一套RESTful网络请求框架，RESTful是目前流行的一套api设计的风格， 并不是标准。Retrofit的封装可以说是很强大，里面涉及到一堆的设计模式,可以通过注解直接配置请求，可以使用不同的http客户端，虽然默认是用http ，可以使用不同Json Converter 来序列化数据，同时提供对RxJava的支持，使用Retrofit + OkHttp + RxJava + Dagger2 可以说是目前比较潮的一套框架，但是需要有比较高的门槛。

retrofit使用
1.在retrofit中通过一个接口作为http请求的api接口;
2.创建一个Retrofit实例
3.调用API接口(调用网络请求的接口获取网络请求)

Volley VS OkHttp Volley的优势在于封装的更好，而使用OkHttp你需要有足够的能力再进行一次封装。而OkHttp的优势在于性能更高，因为 OkHttp基于NIO和Okio ，所以性能上要比 Volley更快。IO 和 NIO这两个都是Java中的概念，如果我从硬盘读取数据，第一种方式就是程序一直等，数据读完后才能继续操作这种是最简单的也叫阻塞式IO,还有一种是你读你的,程序接着往下执行，等数据处理完你再来通知我，然后再处理回调。而第二种就是 NIO 的方式，非阻塞式， 所以NIO当然要比IO的性能要好了,而 Okio是 Square 公司基于IO和NIO基础上做的一个更简单、高效处理数据流的一个库。理论上如果Volley和OkHttp对比的话，更倾向于使用 Volley，因为Volley内部同样支持使用OkHttp,这点OkHttp的性能优势就没了， 而且 Volley 本身封装的也更易用，扩展性更好些。
OkHttp VS Retrofit 毫无疑问，Retrofit 默认是基于 OkHttp 而做的封装，这点来说没有可比性，肯定首选 Retrofit。
Volley VS Retrofit 这两个库都做了不错的封装，但Retrofit解耦的更彻底,尤其Retrofit2.0出来，Jake对之前1.0设计不合理的地方做了大量重构， 职责更细分，而且Retrofit默认使用OkHttp,性能上也要比Volley占优势，再有如果你的项目如果采用了RxJava ，那更该使用 Retrofit 。所以这两个库相比，Retrofit更有优势，在能掌握两个框架的前提下该优先使用 Retrofit。但是Retrofit门槛要比Volley稍高些，要理解他的原理，各种用法，想彻底搞明白还是需要花些功夫的，如果你对它一知半解，那还是建议在商业项目使用Volley吧。