Android应用程序的生命周期；

在大部份状况下，每一个Android应用都将运行在我们的Linux进程当中。当这个应用的某些代码需要实行时，进程就会被创建，并且将维持运行，直到该进程不再需要，而系统需要释放它所占用的内存，为其他应用所用时，才停止。

Android一个要紧并且特殊的特质就是，一个应用的进程的生命周期不是由应用自己直接控制的，而是由系统，依据运行中的应用的一些特点来决定的，包含：这类应用对用户的重要程度、系统的全部可用内存。

对于应用开发者来讲，理解不一样的应用组件（尤其是Activity、Service、Intent Receiver）对应用进程的生命周期的影响，这是尤为重要的。假如没正确地用这类组件，将会致使当应用正在处置要紧的工作时，进程却被系统消毁的后果。

对于进程生命周期，一个常见的错误就是：当一个Intent Receiver在它的onReceiveIntent办法中，接收到一个intent后，就会从这个办法中返回。而一旦从这个办法返回后，系统将会觉得这个Intent Receiver不再处于活动状况了，也就会觉得它的宿主进程无需了（除非宿主进程中还存在其它的应用组件）。从而，系统随时都会消毁这个进程，收回内存，并暂停其中还在运行的子线程。问题的解决方法就是，在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、连接服务器优化方案
1. 不需要域名，用 IP 直连
省去 DNS 分析过程，DNS 全称 Domain Name System，分析意指依据域名得到其对应的 IP 地址。 如 http://www.codekk.com 的域名分析结果就是 104.236.147.76。
初次域名分析一般需要几百毫秒，可通过直接向 IP 而非域名请求，节省掉这部分时间，同时可以预防域名劫持等带来的风险。
当然为了安全和扩展考虑，这个 IP 可能是一个动态更新的 IP 列表，并在 IP 不可用状况下通过域名访问。
2. 服务器合理部署
服务器多运营商多地部署，一般至少含三大运营商、南中北三地部署。
配合上面说到的动态 IP 列表，支持优先级，每次依据地域、互联网种类等选择最佳的服务器 IP 进行连接。
对于服务器端还可以调优服务器的 TCP 拥塞窗口大小、重传超时时间、最大传输单元等。

2、获得数据优化方案
1. 连接复用
节省连接打造时间，如开启 keep-alive。
Http 1.1 默认启动了 keep-alive。对于 Android 来讲默认状况下 HttpURLConnection 和 HttpClient 都开启了 keep-alive。只不过 2.2 之前 HttpURLConnection 存在影响连接池的 Bug，具体可见：Android HttpURLConnection 及 HttpClient 选择
2. 请求合并
马上多个请求合并为一个进行请求，经常见到的就是网页中的 CSS Image Sprites。 假如某个页面内请求过多，也可以考虑做肯定的请求合并。
3. 减小请求数据大小
对于 POST 请求，Body 可以做 Gzip 压缩，如日志。
对请求头进行压缩
这个 Http 1.1 不支持，SPDY 及 Http 2.0 支持。 Http 1.1 可以通过服务端对前一个请求的请求头进行缓存，后面相同请求头用 md5 之类的 id 来表示即可。
4. CDN 缓存静态资源
缓存容易见到的图片、JS、CSS 等静态资源。
5. 减小返回数据大小
压缩
一般 API 数据用 Gzip 压缩，下图是之前测试的 Gzip 压缩前后对比图。 android-http-compare
精简数据格式
如 JSON 代替 XML，WebP 代替其他图片格式。关注公众号 codekk，回复 20 查询关于 WebP 的介绍。
对于不一样的设施不同互联网返回不一样的内容 如不同分辨率图片大小。
增量更新
需要数据更新时，可考虑增量更新。如容易见到的服务端进行 bsdiff，推广客户端进行 bspatch。
大文件下载
支持断点续传，并缓存 Http Resonse 的 ETag 标识，下次请求时带上，从而确定是不是数据改变过，未改变则直接返回 304。

6. 数据缓存
缓存获得到的数据，在肯定的有效时间内第三请求可以直接从缓存读取数据。
关于 Http 缓存规则 Grumoon 在 Volley 网站源码分析最后杂谈中有详细介绍。

3、其他优化方法
这种优化方法在性能优化系列总篇中已经有过完整介绍
1. 预取
包含预连接、预取数据。
2. 分优先级、延迟部分请求
将无关紧要的请求延迟，如此既能够削峰降低并发、又可以和后面类似的请求做合并。
3. 多连接
对于较大文件，如大图片、文件下载可考虑多连接。 需要控制请求的最大并发量，毕竟手机端互联网受限。
4、监控
优化需要通过数据对比才能看出成效，所以监控系统必不可少，通过前后端的数据监控确定调优成效。


如没特殊注明，文章均为建站宝盒原创,转载请注明来自https://www.wcxywh.com/news/youhua/20250626/2220.html