性能优化

页面优化

Android的绘制原理
首先了解fps（Frames Per Second 每秒传递的帧数），通俗来讲就是指动画或视频的画面数，在Android如果让用户感觉到页面不卡顿，那么需要的fps是60fps，也就是每一帧的绘制需要在16ms内完成，如果传递的帧数低于50fps的话，那么用户就会觉得很卡了，此时就要做一些优化了。Android 系统每隔16ms发出 vsync （Vertical Synchronization 垂直同步)信号，cpu收到这些信号会对UI进行更新，如果此时某个layout的绘制有24ms，那么用户在下次更新的32秒之内观察到的还是上一个帧的视图。(简单点说就是我传递了60帧的信号，但是你只绘制了50帧的信号，丢帧了，导致界面看上去很卡)。
通常的引起卡顿的原因有：

页面的层级太多，嵌套太深了。
在绘制过程中进行了耗时操作。
布局的layout太过复杂，无法在16ms内完成。
同一时间进行的动画太多，导致cpu或者gpu负载过重
方法：使用HierarchyView 查看页面层级，开启手机的gpu绘制

电量优化

尽量减少一些不必要的刷新，当应用退到后台之后，一切的界面刷新都是无意义的而且浪费内存和电量的，如通过广播监听网络的变化，刷新页面。

布局优化

include（共享标签），merge（合并标签），viewstub（延迟加载）标签的使用。

网络请求方面

避免DNS解析，因为通过DNS域名URL需要去在网络上面映射表中查找对应的IP地址，这个过程可能需要上百秒的时间，而且有可能存在DNS劫持的危险，根据具体的业务要求，可以用过IP直连的方法，达到更快的网络请求，坏处是不够灵活，因此IP方法需要增加动态更新的能力，或者在IP方法失败后，切换到域名访问的方式。

图片的优化

JPEG:是一种有损压缩图像的标准格式，它不支持透明和多帧动画。
PNG：是一种无损压缩图片格式，JPEG是RGB三个通道，而PNG是ARGB四个通道，由于是无损压缩图片，因此PGG的图片占用的空间比较大。
打包时候的通过微信的图片混淆工具优化，
使用webp代替png或者jpg格式

内存优化释放掉没有用掉的资源。主要有集合内泄露，单利模式的内存泄漏，内部类/匿名内部类的泄漏，以及资源忘记关掉导致的泄漏。

MVP

View层：视图层，包含界面相关的功能，改层专注于用户的交互，实现设计师给出的界面，以及一些动画，View层一般会包含一个Presenter层的引用，将非UI的逻辑操作委托给Presenter
Persenter层：逻辑控制层，充当中间人的角色，用来隔离View层和Model层，主要负责View层和model层的交互
Model层：封装各种数据来源，例如远程网络数据，本地数据库数据等，对Presenter层提供简单易用的接口.

MVP的好处：

如果只是界面发生了变化，或者界面全部改版，那么只需要改对应的view就可以了，Presenter和Model无须改动。
如果业务逻辑或者取数方式发生变化，那么只需要改动对应的model就行了。
如果控制逻辑发生变化，只需要改动Presenter层就行了。
Presenter层和View层以及Model层的交互都是机遇接口实现的，有助于单元测试。
团队的新成员能够快速读懂逻辑，容易入手。

MVP的缺点：

增对接口编程，增加代码类的数量。
由于增加了三层划分，函数的调用栈变深了，如果开发人员没非常了解那一层的具体的功能，会导致新写入的代码混乱，没能达到MVP充分节藕各层的目的。

ANR(Application Not Response)产生的原因：

只有应用的主线程相应超时才会引起ANR，超时原因一般有俩种：

当前的事件没有机会处理，例如UI线程正在处理其他事件，当前事件由于某些原因被堵塞了
当前事件正在被处理，但是由于处理的时间比较长，没有及时完成。
产生ANR的原因不同，超时时间也不尽相同，从本质上来讲共有3种，对应Android4大组件的（Actiivty /View，BroadCasetReceiver 和 Service）
KeyDispatchTimeout 最常见的一种，是view的按键或者触摸事件在5秒内没有相应
BroadcastTimeout 原因是BroadCastReceiver中的onReceiver （）函数运行在主线程中，在特定的时间（10S）内无法完成处理。
ServiceTimeout 是Service个生命周期函数在特定的时间内（20S）内无法完成处理。