一、app优化
app优化:(工具：Hierarchy Viewer 分析布局 工具：TraceView 测试分析耗时的)
App启动优化
布局优化
响应优化
内存优化
电池使用优化
网络优化
App启动优化(针对冷启动)
App启动的方式有三种：
冷启动：App没有启动过或App进程被killed, 系统中不存在该App进程, 此时启动App即为冷启动。
热启动：热启动意味着你的App进程只是处于后台, 系统只是将其从后台带到前台, 展示给用户。
介于冷启动和热启动之间, 一般来说在以下两种情况下发生:
(1)用户back退出了App, 然后又启动. App进程可能还在运行, 但是activity需要重建。
(2)用户退出App后, 系统可能由于内存原因将App杀死, 进程和activity都需要重启, 但是可以在onCreate中将被动杀死锁保存的状态(saved instance state)恢复。
优化：
Application的onCreate（特别是第三方SDK初始化），首屏Activity的渲染都不要进行耗时操作，如果有，就可以放到子线程或者IntentService中
布局优化
尽量不要过于复杂的嵌套。可以使用，，
响应优化
Android系统每隔16ms会发出VSYNC信号重绘我们的界面(Activity)。
页面卡顿的原因：
(1)过于复杂的布局.
(2)UI线程的复杂运算
(3)频繁的GC,导致频繁GC有两个原因:1、内存抖动, 即大量的对象被创建又在短时间内马上被释放.2、瞬间产生大量的对象会严重占用内存区域。
内存优化：参考内存泄露和内存溢出部分
电池使用优化(使用工具：Batterystats & bugreport)
(1)优化网络请求
(2)定位中使用GPS, 请记得及时关闭
网络优化(网络连接对用户的影响:流量,电量,用户等待)可在Android studio下方logcat旁边那个工具Network Monitor检测
API设计：App与Server之间的API设计要考虑网络请求的频次, 资源的状态等. 以便App可以以较少的请求来完成业务需求和界面的展示.
Gzip压缩：使用Gzip来压缩request和response, 减少传输数据量, 从而减少流量消耗.
图片的Size：可以在获取图片时告知服务器需要的图片的宽高, 以便服务器给出合适的图片, 避免浪费.
网络缓存：适当的缓存, 既可以让我们的应用看起来更快, 也能避免一些不必要的流量消耗.
二、图片优化
(1)对图片本身进行操作。尽量不要使用setImageBitmap、setImageResource、BitmapFactory.decodeResource来设置一张大图，因为这些方法在完成decode后，
最终都是通过java层的createBitmap来完成的，需要消耗更多内存.
(2)图片进行缩放的比例，SDK中建议其值是2的指数值,值越大会导致图片不清晰。
(3)不用的图片记得调用图片的recycle()方法
三、Oom 是否可以try catch？为什么？
OutOfMemoryError不应该去catch,出现OutOfMemoryError不管是因为一次巨大的内存分配还是内存泄漏导致,都是程序设计的问题,如果是大内存操作,应该想办法一点点加载,或者压缩资源来加载,如果是巨大数量的排序问题,则可以选择外排序的方式进行,如果是内存泄漏,则需要寻找程序自身的设计问题.
四、Android中弱引用与软引用的应用场景
1、在Android应用的开发中，为了防止内存溢出，在处理一些占用内存大而且声明周期较长的对象时候，可以尽量应用软引用和弱引用技术。 下面以使用软引用为例来详细说明。弱引用的使用方式与软引用是类似的。
2、假设我们的应用会用到大量的默认图片，比如应用中有默认的头像，默认游戏图标等等，这些图片很多地方会用到。如果每次都去读取图片，由于读取文件需要硬件操作，速度较慢，会导致性能较低。所以我们考虑将图片缓存起来，需要的时候直接从内存中读取。但是，由于图片占用内存空间比较大，缓存很多图片需要很多的内存，就可能比较容易发生OutOfMemory异常。这时，我们可以考虑使用软引用技术来避免这个问题发生。
3、使用软引用以后，在OutOfMemory异常发生之前，这些缓存的图片资源的内存空间可以被释放掉的，从而避免内存达到上限，避免Crash发生。需要注意的是，在垃圾回收器对这个Java对象回收前，SoftReference类所提供的get方法会返回Java对象的强引用，一旦垃圾线程回收该Java对象之后，get方法将返回null。所以在获取软引用对象的代码中，一定要判断是否为null，以免出现NullPointerException异常导致应用崩溃。、
五、Android内存泄露及管理
（1）内存溢出（OOM）和内存泄露（对象无法被回收）的区别。
（2）引起内存泄露的原因
(3) 内存泄露检测工具 ------>LeakCanary
内存溢出 out of memory：是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。内存溢出通俗的讲就是内存不够用。
内存泄露 memory leak：是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光
内存泄露原因：
1）、Handler 引起的内存泄漏。
解决：将Handler声明为静态内部类，就不会持有外部类SecondActivity的引用，其生命周期就和外部类无关，
如果Handler里面需要context的话，可以通过弱引用方式引用外部类
2）、单例模式引起的内存泄漏。
解决：Context是ApplicationContext，由于ApplicationContext的生命周期是和app一致的，不会导致内存泄漏
3）、非静态内部类创建静态实例引起的内存泄漏。
解决：把内部类修改为静态的就可以避免内存泄漏了
4）、非静态匿名内部类引起的内存泄漏。
解决：将匿名内部类设置为静态的。
5）、注册/反注册未成对使用引起的内存泄漏。
注册广播接受器、EventBus等，记得解绑。
6）、资源对象没有关闭引起的内存泄漏。
在这些资源不使用的时候，记得调用相应的类似close（）、destroy（）、recycler（）、release（）等方法释放。
7）、集合对象没有及时清理引起的内存泄漏。
通常会把一些对象装入到集合中，当不使用的时候一定要记得及时清理集合，让相关对象不再被引用。
六、过度绘制、卡顿优化:
1.过度绘制：
1.移除Window默认的Background：getWidow.setBackgroundDrawable(null);
2.移除XML布局文件中非必需的Background
3.减少布局嵌套(扁平化的一个体现，减少View数的深度，也就减少了View树的遍历时间，渲染的时候，前后期的工作，总是按View树结点来)
4.在引入布局文件里面，最外层可以用merge替代LinearLayout,RelativeLayout，这样把子UI元素直接衔接在include位置
5.工具：HierarchyViewer 查看视图层级
6.卡顿优化：16ms数据更新
七、apk瘦身:
1.classes.dex：通过代码混淆，删掉不必要的jar包和代码实现该文件的优化
2.资源文件：通过Lint工具扫描代码中没有使用到的静态资源
3.图片资源：使用tinypng和webP，下面详细介绍图片资源优化的方案,矢量图
4.SO文件将不用的去掉，目前主流app一般只放一个arm的so包
八、ANR的形成，各个组件上出现ARN的时间限制是多少
1.只要是主线程耗时的操作就会ARN 如io
2.broadcast超时时间为10秒
按键无响应的超时时间为5秒
前台service无响应的超时时间为20秒，后台service为200秒
解决方式：
(1)不要在主线程中做耗时的操作，而应放在子线程中来实现。如onCreate()和onResume()里尽可能少的去做创建操作。
(2)应用程序应该避免在BroadcastReceiver里做耗时的操作或计算。
(3)避免在Intent Receiver里启动一个Activity，因为它会创建一个新的画面，并从当前用户正在运行的程序上抢夺焦点。
(4)service是运行在主线程的，所以在service中做耗时操作，必须要放在子线程中。
九、进程保活（不死进程）
此处延伸：进程的优先级是什么
当前业界的Android进程保活手段主要分为** 黑、白、灰 **三种，其大致的实现思路如下：
黑色保活：不同的app进程，用广播相互唤醒（包括利用系统提供的广播进行唤醒）
白色保活：启动前台Service
灰色保活：利用系统的漏洞启动前台Service
黑色保活
所谓黑色保活，就是利用不同的app进程使用广播来进行相互唤醒。举个3个比较常见的场景：
场景1：开机，网络切换、拍照、拍视频时候，利用系统产生的广播唤醒app
场景2：接入第三方SDK也会唤醒相应的app进程，如微信sdk会唤醒微信，支付宝sdk会唤醒支付宝。由此发散开去，就会直接触发了下面的 场景3
场景3：假如你手机里装了支付宝、淘宝、天猫、UC等阿里系的app，那么你打开任意一个阿里系的app后，有可能就顺便把其他阿里系的app给唤醒了。（只是拿阿里打个比方，其实BAT系都差不多）
白色保活
白色保活手段非常简单，就是调用系统api启动一个前台的Service进程，这样会在系统的通知栏生成一个Notification，用来让用户知道有这样一个app在运行着，哪怕当前的app退到了后台。如下方的LBE和QQ音乐这样：
灰色保活
灰色保活，这种保活手段是应用范围最广泛。它是利用系统的漏洞来启动一个前台的Service进程，与普通的启动方式区别在于，它不会在系统通知栏处出现一个Notification，看起来就如同运行着一个后台Service进程一样。这样做带来的好处就是，用户无法察觉到你运行着一个前台进程（因为看不到Notification）,但你的进程优先级又是高于普通后台进程的。那么如何利用系统的漏洞呢，大致的实现思路和代码如下：
思路一：API < 18，启动前台Service时直接传入new Notification()；
思路二：API >= 18，同时启动两个id相同的前台Service，然后再将后启动的Service做stop处理
熟悉Android系统的童鞋都知道，系统出于体验和性能上的考虑，app在退到后台时系统并不会真正的kill掉这个进程，而是将其缓存起来。打开的应用越多，后台缓存的进程也越多。在系统内存不足的情况下，系统开始依据自身的一套进程回收机制来判断要kill掉哪些进程，以腾出内存来供给需要的app。这套杀进程回收内存的机制就叫 Low Memory Killer ，它是基于Linux内核的 OOM Killer（Out-Of-Memory killer）机制诞生。
进程的重要性，划分5级：
前台进程 (Foreground process)
可见进程 (Visible process)
服务进程 (Service process)
后台进程 (Background process)
空进程 (Empty process)
了解完 Low Memory Killer，再科普一下oom_adj。什么是oom_adj？它是linux内核分配给每个系统进程的一个值，代表进程的优先级，进程回收机制就是根据这个优先级来决定是否进行回收。对于oom_adj的作用，你只需要记住以下几点即可：
进程的oom_adj越大，表示此进程优先级越低，越容易被杀回收；越小，表示进程优先级越高，越不容易被杀回收
普通app进程的oom_adj>=0,系统进程的oom_adj才可能<0
有些手机厂商把这些知名的app放入了自己的白名单中，保证了进程不死来提高用户体验（如微信、QQ、陌陌都在小米的白名单中）。如果从白名单中移除，他们终究还是和普通app一样躲避不了被杀的命运，为了尽量避免被杀，还是老老实实去做好优化工作吧。
所以，进程保活的根本方案终究还是回到了性能优化上，进程永生不死终究是个彻头彻尾的伪命题！
Android 进程拉活包括两个层面：
提供进程优先级，降低进程被杀死的概率
在进程被杀死后，进行拉活
注：
Android 进程保活招式大全
https://segmentfault.com/a/1190000006251859
关于 Android 进程保活，你所需要知道的一切
https://www.jianshu.com/p/63aafe3c12af
十、如何对Android 应用进行性能分析以及优化?
十一、ddms 和 traceView
十二、性能优化如何分析systrace？
十四、用IDE如何分析内存泄漏？
十五、Java多线程引发的性能问题，怎么解决？
十六、启动页白屏及黑屏解决？
十七、启动太慢怎么解决？
十八、怎么保证应用启动不卡顿？
十九、App启动崩溃异常捕捉
二十、自定义View注意事项
二十一、现在下载速度很慢,试从网络协议的角度分析原因,并优化(提示：网络的5层都可以涉及)。
二十二、Https请求慢的解决办法（提示：DNS，携带数据，直接访问IP）
二十三、如何保持应用的稳定性
二十四、RecyclerView和ListView的性能对比
二十五、ListView的优化
二十六、RecycleView优化
二十七、View渲染
二十八、Bitmap如何处理大图，如一张30M的大图，如何预防OOM
二十九、java中的四种引用的区别以及使用场景
三十、强引用置为null，会不会被回收？
