一. ANR异常

1. 什么是ANR： 在Android中，如果应用程序有一段时间响应不够灵敏，系统会向用户显示应用无响应对话框（ANR：Application Not Responding）。用户可以选择让程序继续运行或者关闭程序。
2. ANR产生的原因：主线程中被耗时操作阻塞(网络请求、IO流读取等操作)。
3. 怎样避免ANR：
   • 使用Asynctask处理耗时IO操作。(灵活切换线程)
   • 使用Thread或者HandlerThread 提高优先级。
   • 使用Handler来处理工作线程的耗时任务。
   • Activity的onCreate和onResume回调中尽量避免耗时的代码。
4. Android哪些操作是在主线程中：
   • Activity的所有生命周期回调都是执行在主线程的。
   • Service默认是执行在主线程的。
   • BroadCastReceiver的onReceive回调是执行在主线程的。
   • 没有使用子线程的Looper的Handler的handleMessage、post(Runnable)是执行在主线程的。
   • AsyncTask的回调除了 doInBackground，其他都是执行在主线程。
   • ContentProvider的onCreate()是运行在UI线程的，而query()，insert()，delete()和update()是运行在线程池中的工作线程的。

二、OOM内存溢出异常

1. 什么是OOM：当前占用的内存加上申请的内存资源超过了 Dalvik 虚拟机的最大内存限制就会抛出的 Out of Memory 异常。(堆内存上有些资源没被释放，从而失去控制，造成程序使用的内存越来越少，导致程序运行速度减慢，严重情况会导致程序的奔溃。)

2. 为什么会OOM，如何解决：

   1. 瞬时加载了大内存的资源，例如：视频、图片和音频等等的内存申请大小超过了App的额定内存值，解决方案：对资源进行压缩处理。
   2. Bitmap对象及时recycle()释放内存，解决方案：在Bitmap不在需要被加载到内存中的时候，做回收处理。
   3. 未关闭 InputStream/OutputStream , 解决方案：在使用到I/O 流的时候，及时关闭。
   4. 调用 registerRecevier() 动态注册后未调用 unregisterReceiver(), 解决方案：在每一次动态注册的时候，记得在onStop/onDestroy取消注册。
   5. 查询数据库后没有关闭游标cursor，解决方案：使用完cursor及时关闭。
   6. 构造Adapter没有使用缓存 contentview重用， 解决方案：在构造Adapter的时候，使用ContentView缓存页面，节省内存。
   7. 减少onDraw的执行次数。
   8. Context泄露，内部类持有外部类的引用。 解决方案： 第一： 将线程的内部类，改为静态内部类 第二：在线程内部采用弱引用保存Context引用。
   9. static 原因。 解决方案：（1）应该尽量避免static成员变量引用资源耗费过多的实例，比如Context。（2）Context尽量使用Application Context，因为Application的Context的生命周期比较长，引用它不会出现内存泄露的问题。（3）使用WeakReference代替强引用。比如可以使用WeakReference<Context> mContextRef；（4）查找内存泄漏可以使用Android Profiler工具或者利用LeakCanary工具。

3. 为什么Android会有APP的内存限制：

   1. 要开发者使用内存更加合理。限制每个应用可用内存上限，避免恶意程序或单个程序使用过多内存导致其他程序的不可运行。有了限制，开发者就必须合理使用资源，优化资源使用
   2. 屏幕显示内容有限，内存足够即可。即使有万千图片千万数据需要使用到，但在特定时刻需要展示给用户看的总是有限的，因为屏幕显示就那么大，上面可以放的信息就是很有限的。大部分信息都是处于准备显示状态，所以没必要给予太多heap内存。必须一个ListView显示图片，打个比方这个ListView含有500个item，但是屏幕显示最多有10调item显示，其余数据是处于准备显示状态。
   3. Android多个虚拟机Davlik的限制需要。android设备上的APP运行，每打开一个应用就会打开至少一个独立虚拟机。这样可以避免系统崩溃，但代价是浪费更多内存。

4. 一些容易混淆的概念：

• 内存溢出：当前占用的内存加上申请的内存资源超过了 Dalvik 虚拟机的最大内存限制就会抛出的 Out of Memory 异常。(非常恐怖)
• 内存抖动：短时间内大量的对象被创建，然后又被马上释放，瞬间产生的对象会严重占用内存区域，随即触发GC回收。
• 内存泄露：进程中某些对象，它没有被其他地方引用到了，但是他们可以直接或间接引用到其他还没被回收的对象，导致GC回收无法产生作用。一旦内存泄露达到一定的程度，就会造成内存溢出OOM。

三、Bitmap异常

1. recycle：内存回收，释放C内存中的内存。
2. Lru算法：最近最少使用的缓存给清理，主要是用put/get方法存入缓存，当缓存快要满的时候用trimToSize清理缓存。
3. 计算inSampleSize：合适的缩放比例来加载图片到内存，避免OOM。
4. 缩略图：inJustDecodeBounds。
5. 三级缓存：网络、本地和内存，当App首次加载一张图片的时候，会从网络中请求图片加载，当图片请求成功后会把这个Bitmap保存到 SD卡和内存中各一份，当我们需要请求这张相同URL的图片的时候，就会直接从内存或SD卡中获取。而不用走网络，好处是减少了用户的使用流量 。

四、UI卡顿异常

1. UI卡顿原理
   • 60fps -> 16ms
   • overdraw：过度绘制
2. UI卡顿原因分析
   1. 人为在UI线程中做了轻微的耗时操作，导致UI线程卡顿。
   2. 布局Layout过于复杂，无法在16ms内完成渲染。
   3. 同一时间动画执行的次数过多，导致CPU或GPU负载过重。
   4. View过度绘制，导致某些像素在同一帧时间内被多次绘制，从而使CPU或GPU负载过重。
   5. View频繁的出发measure、layout，导致measure、layout累计耗时过多及整个View频繁的重新渲染。
   6. 内存频繁触发GC过多，导致暂时阻塞渲染操作。
   7. 冗余资源及逻辑等导致加载和执行缓慢。
   8. ANR主线程做耗时操作。
3. UI卡顿避免方法
   1. 布局优化：优先使用Relativelayout，使用布局标签include(重复利用)、merge(继承父控件)、ViewStub(动态加载显示)，使用最新的布局方式ConstaintLayout，利用Android Lint工具寻求可能优化布局的层次。
   2. 列表及Adapter优化：复用实例、滑动不要加载更新(监听滑动停止才加载数据，滑动的时候只显示默认值或缩略图)。
   3. 背景和图片等内存分配优化：减少布局中不必要的背景设置。图片要压缩处理。
   4. 避免ANR：不要在UI线程做耗时操作(Handler,AsyncTask,IntentService,HandlerThread等等)。

五、内存泄露异常

1.Java内存泄露

• Java内存的分配策略：
  - 静态存储区：主要存放一些静态数据、全局变量等等，生命周期是整个应用。
  - 栈区：在方法执行的时候，方法体内的局部变量会在栈创建内存空间，并在方法结束后内存会自动释放。(高效，内存大小有限)
  - 堆区：又称为动态内存分配，就是new出来的对象存放的地方，在不使用的时候由Java的垃圾回收器负责回收。

• Java是如何管理内存的
  - 通过new为每个对象申请内存空间，所有对象都是在堆中分配空间。
  - 对象的释放是由GC垃圾回收器来决定和执行的。
  - 好处是GC简化了程序员的工作，能正确的释放对象。GC对每个对象进行监控(申请、引用、被引用和赋值)，但这样也加重了虚拟机的工作。

• Java中的内存泄露
  - 内存泄露就是指无用对象(不再使用的)持续占用内存，使内存无法得到及时的释放，从而造成内存空间的浪费称为内存泄露。

2.Android内存泄露

1. 单例：应该使用Application Context。
2. 匿名内部类：应该设为静态类。
3. Handler：当Activity要销毁的时候，mHandler 中还有未处理或正在处理的消息，Message 持有 mHandler 的实例引用，mHandler 又是非静态内部类，持有外部类Activity引用，导致了Activity想回收时无法回收，造成内存泄露。应该把Handler改为静态内部类，同时mHandler持有外部类的弱引用，或者在onDestroy方法中mHandler.removeCallBackAndMessage(null)。
4. 避免使用static变量：static变量的生命周期和App是一致的，无论在什么情况下，这部分内存都是不会释放的。在App内存管理机制占内存较大的后台App将会优先被回收，被回收的变量是不安全的。应该可以考虑懒加载，必须对static生命周期管理起来。
5. 资源未关闭造成内存释放：广播、文件、Bitmap、游标cursor
6. AsycnTask造成的内存泄露：在onDestroy方法中cancel任务。

六、内存管理

1.内存管理机制的概述

1. 分配机制：系统会为每一个进程分配合理的大小，从而保证每个进程能正常运行，而不至于内存不够使用或占用太多。
2. 回收机制：在系统内存不足的时候会有一个合理的回收再分配的机制，从而保证新的进程能正常运行。

2.Android内存管理机制

1. 分配机制：弹性分配机制，初始化的时候分配较少的量，随着运行内存紧张的时候Android系统会额外分配内存大小(有限制)。目的是让更多进程存活在内存当中，当用户下一次启动App的时候就不用重新创建进程，只需要恢复已有的进程即可。
2. 回收机制：App在每次退出的时候，依然保存在进程当中，为了能更快的再次启动。但当前内存不够用的时候，就会以“杀死最少的进程获得最大的内存”原则进行内存的回收，还遵循前台进程>可见进程>服务进程>后台进程>空进程的优先级进行回收。

3.内存管理机制的期望

1. 更少的占用内存
2. 在合适的时候，合理的释放系统资源。
3. 在系统内存紧张的情况下，能释放掉大部分不重要的资源来为Android系统提供可用的内存。
4. 能够很合理的在特殊生命周期中，保存或者还原重要数据，以至于系统能够正确的重新恢复该应用。

4.内存优化方法

1. 当Service完成任务后，尽量停止它(IntentService替代)。
2. 在UI不可见的时候，释放一些只用UI使用的资源。
3. 在系统内存紧张的时候，尽可能多的释放掉一些非重要资源。
4. 避免Bitmap导致的内存浪费(压缩、回收)。
5. 使用针对内存优化过的数据容器。
6. 避免使用依赖注入的框架(需要额外资源)。
7. 使用ZIP对其的APK
8. 使用多线程。

6.内存溢出VS内存泄露

1. 使用第三方框架来解决泄露。

七、冷启动优化

1.什么是冷启动

1. 冷启动/热启动的定义：
   - 冷启动：在应用启动前，系统中没有该应用的任何进程信息。
   - 热启动：是指用户退出应用后，然后马上又重新启动应用。

2. 冷启动/热启动的区别：
   - 从定义上：冷启动启动的时候，系统会重新创建新的进程分配给该应用。热启动的时候，后台已经有了该应用的进程(由于内存不会马上释放上一次启动该进程，除非内存紧张)。
   - 从启动特点上：冷启动的时候，在重新创建的时候，先会创建和初始化MyApplication类，然后创建MainActivity类和进行一些测量布局等等。热启动的时候只需要创建MainActivity类和进行一些测量布局等等。

3. 冷启动时间的计算：这个时间值从应用启动(创建进程)开始计算，到完成视图的第一次绘制(即Activity内容可见)为止。

2.冷启动流程

1. Zygote进程中fork创建出一个新的进程；
2. 创建和初始化Application类、创建MainActivity类；
3. inflate布局、当onCreate/onStart/onResume方法都走完；

3.如何对冷启动的时间进行优化

1. 减少onCreate()方法的工作量；
2. 不要让Application参与业务的操作，也不能做耗时操作；
3. 不要以静态变量的方式在Application中保存数据；
4. 尽量减少布局所耗费的时间、减少层数(ViewStab动态加载)。
5. 主线程也会影响(懒加载解决)。

八、其他优化

1.Android不用静态变量存储数据

2.有关sp的安全问题

3.内存对象序列化

4.避免在UI线程中做繁重的操作。