Android应用程序的生命周期；
在大部份情况下，每个Android应用都将运行在自己的Linux进程当中。当这个应用的某些代码需要执行时，进程就会被创建，并且将保持运行，直到该进程不再需要，而系统需要释放它所占用的内存，为其他应用所用时，才停止。
Android一个重要并且特殊的特性就是，一个应用的进程的生命周期不是由应用自身直接控制的，而是由系统，根据运行中的应用的一些特征来决定的，包括：这些应用对用户的重要性、系统的全部可用内存。
对于应用开发者来说，理解不同的应用组件（特别是Activity、Service、IntentReceiver）对应用进程的生命周期的影响，这是非常重要的。如果没有正确地使用这些组件，将会导致当应用正在处理重要的工作时，进程却被系统消毁的后果。
对于进程生命周期，一个普遍的错误就是：当一个IntentReceiver在它的onReceiveIntent()方法中，接收到一个intent后，就会从这个方法中返回。而一旦从这个方法返回后，系统将会认为这个IntentReceiver不再处于活动状态了，也就会认为它的宿主进程不需要了（除非宿主进程中还存在其它的应用组件）。从而，系统随时都会消毁这个进程，收回内存，并中止其中还在运行的子线程。问题的解决办法就是，在IntentReceiver中，启动一个Service，这样系统就会知道在这个进程中，还有活动的工作正在执行。
为了决定在内存不足情况下消毁哪个进程，Android会根据这些进程内运行的组件及这些组件的状态，把这些进程划分出一个“重要性层次”。这个层次按顺序如下：
1、前端进程是拥有一个显示在屏幕最前端并与使用者做交互的Activity（它的onResume已被调用）的进程，也可能是一个拥有正在运行的IntentReceiver（它的onReceiveIntent()方法正在运行）的进程。在系统中，这种进程是很少的，只有当内存低到不足于支持这些进程的继续运行，才会将这些进程消毁。通常这时候，设备已经达到了需要进行内存整理的状态，为了保障用户界面不停止响应，只能消毁这些进程；
2、可视进程是拥有一个用户在屏幕上可见的，但并没有在前端显示的Activity（它的onPause已被调用）的进程。例如：一个以对话框显示的前端activity在屏幕上显示，而它后面的上一级activity仍然是可见的。这样的进程是非常重要的，一般不会被消毁，除非为了保障所有的前端进程正常运行，才会被消毁。
3、服务进程是拥有一个由startService()方法启动的Service的进程。尽管这些进程对于使用者是不可见的，但他们做的通常是使用者所关注的事情（如后台MP3播放器或后台上传下载数据的网络服务）。因此，除非为了保障前端进程和可视进程的正常运行，系统才会消毁这种进程。
4、后台进程是拥有一个用户不可见的Activity（onStop()方法已经被调用）的进程。这些进程不直接影响用户的体验。如果这些进程正确地完成了自己的生命周期（详细参考Activity类），系统会为了以上三种类型进程，而随时消毁这种进程以释放内存。通常会有很多这样的进程在运行着，因些这些进程会被保存在一个LRU列表中，以保证在内存不足时，用户最后看到的进程将在最后才被消毁。
5、空进程是那些不拥有任何活动的应用组件的进程。保留这些进程的唯一理由是，做为一个缓存，在它所属的应用的组件下一次需要时，缩短启动的时间。同样的，为了在这些缓存的空进程和底层的核心缓存之间平衡系统资源，系统会经常消毁这些空进程。
当要对一个进程进行分类时，系统会选择在这个进程中所有活动的组件中重要等级最高的那个做为依据。可以参考Activity、Service、IntentReceiver文档，了解这些组件如何影响进程整个生命周期的更多细节。这些类的文档都对他们如何影响他们所属的应用的整个生命周期，做了详细的描述。
针对移动端的网络优化，适用Android，同样适用于iOS和H5
一个网络请求可以简单分为连接服务器->获取数据两个部分。
其中连接服务器前还包括DNS解析的过程；获取数据后可能会对数据进行缓存。
一、连接服务器优化策略
1.不用域名，用IP直连
省去DNS解析过程，DNS全名DomainNameSystem，解析意指根据域名得到其对应的IP地址。如http://www.codekk.com的域名解析结果就是104.236.147.76。
首次域名解析一般需要几百毫秒，可通过直接向IP而非域名请求，节省掉这部分时间，同时可以预防域名劫持等带来的风险。
当然为了安全和扩展考虑，这个IP可能是一个动态更新的IP列表，并在IP不可用情况下通过域名访问。
2.服务器合理部署
服务器多运营商多地部署，一般至少含三大运营商、南中北三地部署。
配合上面说到的动态IP列表，支持优先级，每次根据地域、网络类型等选择最优的服务器IP进行连接。
对于服务器端还可以调优服务器的TCP拥塞窗口大小、重传超时时间(RTO)、最大传输单元(MTU)等。
二、获取数据优化策略
1.连接复用
节省连接建立时间，如开启keep-alive。
Http1.1默认启动了keep-alive。对于Android来说默认情况下HttpURLConnection和HttpClient都开启了keep-alive。只是2.2之前HttpURLConnection存在影响连接池的Bug，具体可见：AndroidHttpURLConnection及HttpClient选择
2.请求合并
即将多个请求合并为一个进行请求，比较常见的就是网页中的CSSImageSprites。如果某个页面内请求过多，也可以考虑做一定的请求合并。
3.减小请求数据大小
(1)对于POST请求，Body可以做Gzip压缩，如日志。
(2)对请求头进行压缩
这个Http1.1不支持，SPDY及Http2.0支持。Http1.1可以通过服务端对前一个请求的请求头进行缓存，后面相同请求头用md5之类的id来表示即可。
4.CDN缓存静态资源
缓存常见的图片、JS、CSS等静态资源。
5.减小返回数据大小
(1)压缩
一般API数据使用Gzip压缩，下图是之前测试的Gzip压缩前后对比图。android-http-compare
(2)精简数据格式
如JSON代替XML，WebP代替其他图片格式。关注公众号codekk，回复20查看关于WebP的介绍。
(3)对于不同的设备不同网络返回不同的内容如不同分辨率图片大小。
(4)增量更新
需要数据更新时，可考虑增量更新。如常见的服务端进行bsdiff，客户端进行bspatch。
(5)大文件下载
支持断点续传，并缓存HttpResonse的ETag标识，下次请求时带上，从而确定是否数据改变过，未改变则直接返回304。
6.数据缓存
缓存获取到的数据，在一定的有效时间内再次请求可以直接从缓存读取数据。
关于Http缓存规则Grumoon在Volley源码解析最后杂谈中有详细介绍。
三、其他优化手段
这类优化方式在性能优化系列总篇中已经有过完整介绍
1.预取
包括预连接、预取数据。
2.分优先级、延迟部分请求
将不重要的请求延迟，这样既可以削峰减少并发、又可以和后面类似的请求做合并。
3.多连接
对于较大文件，如大图片、文件下载可考虑多连接。需要控制请求的最大并发量，毕竟移动端网络受限。
四、监控
优化需要通过数据对比才能看出效果，所以监控系统必不可少，通过前后端的数据监控确定调优效果。