android访问网络优化

Ⅰ android网络优化(二)DNS解析错误 备用域名顶上

网络不通，能访问其他网络，但是访问不了我们app，你觉得我们跟客户说网络不好，客户会信吗？
这就可能 我们域名解析可能不成功
先简单看图了解一下DNS解析

这样我们就可以减少网络失败导致我们的原因！

Ⅱ Android性能优化总结

常用的Android性能优化方法：

一、布局优化：

1）尽量减少布局文件的层级。

层级少了，绘制的工作量也就少了，性能自然提高。

2）布局重用 <include标签>

3）按需加载：使用ViewStub,它继承自View,一种轻量级控件，本身不参与任何的布局和绘制过程。他的layout参数里添加一个替换的布局文件，当它通过setVisibility或者inflate方法加载后，它就会被内部布局替换掉。

二、绘制优化：

基于onDraw会被调用多次，该方法内要避免两类操作：

1）创建新的局部对象，导致大量垃圾对象的产生，从而导致频繁的gc，降低程序的执行效率。

2）不要做耗时操作，抢CPU时间片，造成绘制很卡不流畅。

三、内存泄漏优化：

1）静态变量导致内存泄漏   比较明显

2）单例模式导致的内存泄漏 单例无法被垃圾回收，它持有的任何对象的引用都会导致该对象不会被gc。

3）属性动画导致内存泄漏  无限循环动画，在activity中播放，但是onDestroy时没有停止的话，动画会一直播放下去，view被动画持有，activity又被view持有，导致activity无法被回收。

四、响应速度优化：

1）避免在主线程做耗时操作 包括四大组件，因为四大组件都是运行在主线程的。

2）把一些创建大量对象等的初始化工作放在页面回到前台之后，而不应该放到创建的时候。

五、ListView的优化：

1）使用convertView，走listView子View回收的一套：RecycleBin 机制

主要是维护了两个数组，一个是mActiveViews,当前可见的view,一个是mScrapViews，当前不可见的view。当触摸ListView并向上滑动时，ListView上部的一些OnScreen的View位置上移，并移除了ListView的屏幕范围，此时这些OnScreen的View就变得不可见了，不可见的View叫做OffScreen的View，即这些View已经不在屏幕可见范围内了，也可以叫做ScrapView，Scrap表示废弃的意思，ScrapView的意思是这些OffScreen的View不再处于可以交互的Active状态了。ListView会把那些ScrapView（即OffScreen的View）删除，这样就不用绘制这些本来就不可见的View了，同时，ListView会把这些删除的ScrapView放入到RecycleBin中存起来，就像把暂时无用的资源放到回收站一样。

当ListView的底部需要显示新的View的时候，会从RecycleBin中取出一个ScrapView，将其作为convertView参数传递给Adapter的getView方法，从而达到View复用的目的，这样就不必在Adapter的getView方法中执行LayoutInflater.inflate()方法了。

RecycleBin中有两个重要的View数组，分别是mActiveViews和mScrapViews。这两个数组中所存储的View都是用来复用的，只不过mActiveViews中存储的是OnScreen的View，这些View很有可能被直接复用；而mScrapViews中存储的是OffScreen的View，这些View主要是用来间接复用的。

2）使用ViewHolder避免重复地findViewById

3)快速滑动不适合做大量异步任务，结合滑动监听，等滑动结束之后加载当前显示在屏幕范围的内容。

4）getView中避免做耗时操作，主要针对图片：ImageLoader来处理(原理：三级缓存)

5）对于一个列表，如果刷新数据只是某一个item的数据，可以使用局部刷新，在列表数据量比较大的情况下，节省不少性能开销。

六、Bitmap优化：

1）减少内存开支：图片过大，超过控件需要的大小的情况下，不要直接加载原图，而是对图片进行尺寸压缩，方式是BitmapFactroy.Options 采样，inSampleSize 转成需要的尺寸的图片。

2）减少流量开销：对图片进行质量压缩，再上传服务器。图片有三种存在形式：硬盘上时是file，网络传输时是stream，内存中是stream或bitmap，所谓的质量压缩，它其实只能实现对file的影响，你可以把一个file转成bitmap再转成file，或者直接将一个bitmap转成file时，这个最终的file是被压缩过的，但是中间的bitmap并没有被压缩。bitmap.compress(Bitmap.CompressFormat.PNG,100,bos);

七、线程优化：

使用线程池。为什么要用线程池？

1、从“为每个任务分配一个线程”转换到“在线程池中执行任务”

2、通过重用现有的线程而不是创建新线程，可以处理多个请求在创建销毁过程中产生的巨大开销

3、当使用线程池时，在请求到来时间 ，不用等待系统重新创建新的线程，而是直接复用线程池中的线程，这样可以提高响应性。

4、通过和适当调整线程池的大小 ，可以创建足够多的线程以使处理器能够保持忙碌状态，同时还可以防止过多线程相互竞争资源而使应用程序耗尽内存或者失败。

5、一个App里面所有的任务都放在线程池中执行后，可以统一管理 ，当应用退出时，可以把程序中所有的线程统一关闭，避免了内存和CPU的消耗。

6、如果这个任务是一个循环调度任务，你则必须在这个界面onDetach方法把这个任务给cancel掉，如果是一个普通任务则可cancel，可不cancel，但是最好cancel

7、整个APP的总开关会在应用退出的时间把整个线程池全部关闭。

八、一些性能优化建议：

1）避免创建过多对象，造成频繁的gc

2)不要过多使用枚举，枚举占用的空间比整型大很多

3）字符串的拼接使用StringBuffer、StringBuilder来替代直接使用String,因为使用String会创建多个String对象，参考第一条。

4）适当使用软引用，（弱引用就不太推荐了）

5）使用内存缓存和磁盘缓存。

Ⅲ 如何通过技术优化让 Android 程序变得流畅

Android APP优化的几点考量：

高效的使用多线程

1.在后台取消一些线程中的动作

App运行过程中所有的操作都默认在主线程（UI线程）中进行的，这样App的响应速度就会受到影响。会导致程序陷入卡顿、死掉甚至会发生系统错误。

为 了加快响应速度，需要把费时的操作（比如网络请求、数据库操作或者复杂的计算）从主线程移动到一个单独的线程中。最高效的方式就是在类这一级完成这项操作，可以使用AsyncTask或者IntentService来创建后台操作。

2.保持响应不发生ANR

从UI线程中移除费时操作这个方式还可以防止用户操作出现系统不响应（ANR）对话框。需要做的就是继承AsyncTask来创建一个后台工作线程，并实现doInBackground()方法。

3.在线程中初始化查询操作

当查询操作正在后台处理时，展示数据也不是即时的，可以使用CursorLoader对象来加快速度，这个操作可以使Activity和用户之间的互动不受影响。

使用这个对象后， App会为ContentProvider初始化一个独立的后台线程进行查询，当查询结束后就会给调用查询的Activity返回结果。

4.其它需要注意的方面

使用StrictMode来检查UI线程中可能潜在的费时操作；

使用一些特殊的工具如Safe.ijiami、Systrace或者Traceview来寻找在你的应用中的瓶颈；

优化设备的电池寿命

对于电池使用来说，主要费电情况如下：

更新数据时经常唤醒程序；

用EDGE或者3G来传递数据；

文本数据转换，进行非JIT正则表达式操作。

5.优化网络

如果没有网络连接，让应用跳过网络操作；只在有网络连接并且无漫游的情况下更新数据；

选择兼容的数据格式，把含有文本数据和二进制数据的请求全部转化成二进制数据格式请求；

使用高效的转换工具，多考虑使用流式转换工具，少用树形的转换工具；

为了更快的用户体验，减少重复访问服务器的操作；

如果可以的话，使用framework的GZIP库来压缩文本数据以高效使用CPU资源。

其他的优化方面还有低内存实现UI效果，优化的方面有很多，需要逐步来进行。

Ⅳ android性能优化07-电量网络优化

当用户有一段时间未触摸应用并且应用没有以下表现，则Android系统就会使应用进入空闲状态

系统提供了一个可配置的白名单，将部分免除低电耗模式和应用待机模式优化的应用列入其中，app可以使用网络并保留部分唤醒锁定，其他限制任然受限

PowerManager.() 来检查应用当前是否在豁免白名单中。

对话框方式，跳转方式意义不大

以前有Battery Historian 等其他工具；8.0以上用energy profiler 即可，看下cpu的情况和各种电量模式下的状态些，可以选中区域看

keep-alive 保持socket的长链接
http1.1上面同时发送多个请求：串行可以共用，并行还是得走3次握手
http2 用多路复用解决了并行问题
okhttp3以上支持http2
需要服务端配合，如果服务端不开启keep-alive 无用

Ⅳ 如何通过技术优化让 Android 程序变得流畅

安卓程序并不能完完全全变得像iOS那样流程，这是安卓本身的设计的限制。安卓程序的后台运行是真的后台运行，就算你关了程序，但是程序还是会在后台运行的。所以，安卓注定会越用越卡，这是避免不了的，我们能做的只有尽量优化一下，以下是一些建议。
1.优化APP设计。减少代码冗余.比如重复性的代码可以写在函数里,每次只需调用同一块代码.更不要为实现一个功能而图方便引入一个庞大的库(有很多功能可能用不上,却降低执行代码的效率)
2.用户要经常释放内存。某些功能在用不上时绝对不要霸占着宝贵的内存空间。
3.多了解一下计算机工作原理的知识,理解实现同一功能的两段代码背后运行效率的区别。

Ⅵ Android性能优化之网络优化DNS和HttpDNS知识详解

前言小计

本文已在在公众号【Android开发编程】发表

一、什么是DNS

二、DNS域名结构

1、DNS域名命名

2、域名的分级

域名可以划分为各个子域，子域还可以继续划分为子域的子域，这样就形成了顶级域名、二级域名、三级域名等

顶级域名可以分为三大类：

国家顶级域名：cn、us、uk等

通用域名：常见的有7个，com、net、org、e、int、gov、mil

方向域名： arpa,用于将ip地址转为域名

域名服务器

域名服务器按照由高到低进行层次划分：

注意： 一个域名服务器所负责的范围，称为区

三、域名解析过程

域名解析的重要两点：

以上两点是域名解析的重要两步。但是这并不是解析ip地址的完整过程，如果浏览器的缓存中有该域名对应的ip地址，就不需要向本地域名服务器请求了等等。下面来看详细过程:

例如要解析：www.example.com该域名的ip地址;

四、DNS安全和优化

1、dns安全问题

2、DNS优化

DNS解析是一个漫长的过程，那么它的优化有哪些？

1、网页端

用户在请求请求某个链接之前，浏览器先尝试解析该链接的域名再将其进行缓存。

可以这样做：

(1) 在服务器中响应设置X-DNS-Prefetch-Control的值为on启动预解析

(2) 在HTML中，

(3) 在head中加入link标签：

如

不过现在的Chrome浏览器会自动将当前页面的所有带href的dns都prefetch一遍。需要手动添加上面的link标签的场景是：你后面访问的域名不在当前页面的所有链接中;

正确使用link标签的姿势：

域名收敛:建议将静态资源只放在一个域名下面，可以减少DNS的请求

2、客户端

HttpDNS

HttpDNS是使用HTTP协议向阿里云的HTTPDNS服务器的80端口直接进行请求，代替传统的DNS协议向LDNS服务器的53端口进行请求。从而可以绕过LDNS，可以避免运行商的域名劫持和调度不精准的问题;

五、HttpDNS介绍

总结：

网络优化的知识点很多，今天主要介绍了dns的知识点

下次继续介绍Android网络优化的具体实现方案

Ⅶ 针对Android的性能优化集中哪些方面

一、概要：

本文主要以Android的渲染机制、UI优化、多线程的处理、缓存处理、电量优化以及代码规范等几方面来简述Android的性能优化

二、渲染机制的优化：

大多数用户感知到的卡顿等性能问题的最主要根源都是因为渲染性能。

Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染， 如果每次渲染都成功，这样就能够达到流畅的画面所需要的60fps，为了能够实现60fps，这意味着程序的大多数操作都必须在16ms内完成。

*关于JobScheler的更多知识可以参考http://hukai.me/android-training-course-in-chinese/background-jobs/scheling/index.html

七、代码规范

1）for loop中不要声明临时变量，不到万不得已不要在里面写try catch。

2）明白垃圾回收机制，避免频繁GC，内存泄漏，OOM(有机会专门说)

3）合理使用数据类型，StringBuilder代替String，少用枚举enum，少用父类声明(List,Map)

4）如果你有频繁的new线程，那最好通过线程池去execute它们，减少线程创建开销。

5）你要知道单例的好处，并正确的使用它。

6）多用常量，少用显式的"action_key"，并维护一个常量类，别重复声明这些常量。

7）如果可以，至少要弄懂设计模式中的策略模式，组合模式，装饰模式，工厂模式，观察者模式，这些能帮助你合理的解耦，即使需求频繁变更，你也不用害怕牵一发而动全身。需求变更不可怕，可怕的是没有在写代码之前做合理的设计。

8）View中设置缓存属性.setDrawingCache为true.

9）cursor的使用。不过要注意管理好cursor,不要每次打开关闭cursor.因为打开关闭Cursor非常耗时。Cursor.require用于刷cursor.

10）采用SurfaceView在子线程刷新UI,避免手势的处理和绘制在同一UI线程（普通View都这样做）

11）采用JNI，将耗时间的处理放到c/c++层来处理

12）有些能用文件操作的，尽量采用文件操作，文件操作的速度比数据库的操作要快10倍左右

13）懒加载和缓存机制。访问网络的耗时操作启动一个新线程来做，而不要再UI线程来做

14）如果方法用不到成员变量，可以把方法申明为static，性能会提高到15%到20%

15）避免使用getter/setter存取field，可以把field申明为public，直接访问

16）私有内部类要访问外部类的field或方法时,其成员变量不要用private，因为在编译时会生成setter/getter,影响性能。可以把外部类的field或方法声明为包访问权限

17）合理利用浮点数，浮点数比整型慢两倍

18）针对ListView的性能优化，ListView的背景色与cacheColorHint设置相同颜色，可以提高滑动时的渲染性能。ListView中getView是性能是关键，这里要尽可能的优化。

getView方法中要重用view；getView方法中不能做复杂的逻辑计算，特别是数据库操作，否则会严重影响滑动时的性能

19）不用new关键词创建类的实例，用new关键词创建类的实例时，构造函数链中的所有构造函数都会被自动调用。但如果一个对象实现了Cloneable接口，我们可以调用它的clone()方法。

clone()方法不会调用任何类构造函数。在使用设计模式（Design Pattern）的场合，如果用Factory模式创建对象，则改用clone()方法创建新的对象实例非常简单。例如，下面是Factory模式的一个典型实现：

20）public static Credit getNewCredit() {
return new Credit();
}
改进后的代码使用clone()方法，如下所示：
private static Credit BaseCredit = new Credit();
public static Credit getNewCredit() {
return (Credit) BaseCredit.clone();
}
上面的思路对于数组处理同样很有用。

21）乘法和除法

考虑下面的代码：

22）ViewPager同时缓存page数最好为最小值3，如果过多，那么第一次显示时，ViewPager所初始化的pager就会很多，这样pager累积渲染耗时就会增多，看起来就卡。

23）每个pager应该只在显示时才加载网络或数据库(UserVisibleHint=true)，最好不要预加载数据，以免造成浪费

24）提高下载速度：要控制好同时下载的最大任务数，同时给InputStream再包一层缓冲流会更快(如BufferedInputStream)

25）提供加载速度：让服务端提供不同分辨率的图片才是最好的解决方案。还有合理使用内存缓存，使用开源的框架

引用：Android性能优化的浅谈

Ⅷ Android-网络优化

APP的优化是任重而道远的过程，必须在意每一个环节，否者当你想要优化的时候，发现到处都是坑，已经不知道填补哪里了，所以我们必须一点一滴的做起。

网络优化

正常一条网络请求需要经过的流程是这样：

①DNS 解析，请求DNS服务器，获取域名对应的 IP 地址。

②与服务端建立连接，包括 tcp 三次握手，安全协议同步流程。

③连接建立完成，发送和接收数据，解码数据。

这里有明显的三个优化点：

①直接使用 IP 地址，去除 DNS 解析步骤。

②不要每次请求都重新建立连接，复用连接或一直使用同一条连接(长连接)或合并接口。

③压缩数据，减小传输的数据大小。

DNS优化

DNS：它的作用是根据域名查出IP地址。

DNS 完整的解析流程很长，会先从本地系统缓存取，若没有就到最近的 DNS 服务器取，若没有再到主域名服务器取，每一层都有缓存，但为了域名解析的实时性，每一层缓存都有过期时间。

DNS的缺点：

①缓存时间设置得长，域名更新不及时，设置得短，大量 DNS 解析请求影响请求速度。

②域名劫持，容易被中间人攻击，或被运营商劫持，把域名解析到第三方 IP 地址，据统计劫持率会达到7%。

③DNS 解析过程不受控制，无法保证解析到最快的IP。

④一次请求只能解析一个域名。

HTTPDNS

原理很简单，就是自己做域名解析的工作，通过 HTTP 请求后台去拿到域名对应的 IP 地址，直接解决上述所有问题。

HTTPDNS的好处总结就是：

①Local DNS 劫持：由于 HttpDns 是通过 IP 直接请求 HTTP 获取服务器 A 记录地址，不存在向本地运营商询问domain 解析过程，所以从根本避免了劫持问题。

②DNS 解析由自己控制，可以确保根据用户所在地返回就近的 IP 地址，或根据客户端测速结果使用速度最快的IP。

③一次请求可以解析多个域名。

PS：HTTPDNS 几乎成为中大型 APP 的标配。解决了第一个问题， DNS 解析耗时的问题，顺便把DNS 劫持也解决了。

连接优化

连接建立耗时的问题，这里主要的优化思路是复用连接，不用每次请求都重新建立连接，如何更有效率地复用连接，可以说是网络请求速度优化里最主要的点了。

keep-alive ：

HTTP 协议里有个 keep-alive，HTTP1.1默认开启，一定程度上缓解了每次请求都要进行TCP三次握手建立连接的耗时。原理是请求完成后不立即释放连接，而是放入连接池中，若这时有另一个请求要发出，请求的域名和端口是一样的，就直接拿出连接池中的连接进行发送和接收数据，少了建立连接的耗时。 实际上现在无论是客户端还是浏览器都默认开启了keep-alive，对同个域名不会再有每发一个请求就进行一次建连的情况，纯短连接已经不存在了。

但有 keep-alive 的连接一次只能发送接收一个请求，在上一个请求处理完成之前，无法接受新的请求。若同时发起多个请求，就有两种情况：

①若串行发送请求，可以一直复用一个连接，但速度很慢，每个请求都要等待上个请求完成再进行发送。

②若并行发送请求，那么只能每个请求都要进行tcp三次握手建立新的连接。

多路复用

对并行请求的问题，新一代协议 HTTP2 提出了多路复用去解决。 HTTP2 的多路复用机制一样是复用连接，但它复用的这条连接支持同时处理多条请求，所有请求都可以并发在这条连接上进行，也就解决了上面说的并发请求需要建立多条连接带来的问题。

多路复用把在连接里传输的数据都封装成一个个stream，每个stream都有标识，stream的发送和接收可以是乱序的，不依赖顺序，也就不会有阻塞的问题，接收端可以根据stream的标识去区分属于哪个请求，再进行数据拼接，得到最终数据。Android 的开源网络库OKhttp默认就会开启keep-alive ，并且在Okhttp3以上版本也支持了 HTTP2。

数据压缩

传输数据大小的问题。数据对请求速度的影响分两方面，一是压缩率，二是解压序列化反序列化的速度。目前最流行的两种数据格式是 json 和 protobuf，json 是字符串，protobuf 是二进制，即使用各种压缩算法压缩后，protobuf 仍会比 json 小，数据量上 protobuf 有优势，序列化速度 protobuf 也有一些优势 。

除了选择不同的序列化方式（数据格式）之外，Http可以对内容（也就是body部分）进行编码，可以采用gzip这样的编码，从而达到压缩的目的。如在开源网络库OKhttp的 BridgeInterceptor 中会自动为我们开启gzip解压的支持。

其他优化方式

1、使用webp代替png/jpg。

2、不同网络的不同图片下发，如（对于原图是300x300的图片）：

（1）2/3G使用低清晰度图片：使用100X100的图片;

（2）4G再判断信号强度为强则使用使用300X300的图片，为中等则使用200x200，信号弱则使用100x100图片;

（3）WiFi网络：直接下发300X300的图片

3、不同需求的不同图片下发，如（对于原图是300x300的图片），若实际只需要25X25，则向服务器请求该尺寸的图片

4、http开启缓存,根据应用的实际情况并和协商缓存方案。什么情况下读取缓存，针对部分接口直接采取长缓存机制。通过缓存时间控制缓存的使用。

5. 通过okhttp拦截器设置，模拟网络环境，让你更好的找到发现问题。

Ⅸ 如何对Android进行性能优化

不知道你是说对系统优化还是什么app优化，

系统优化就只能找底层人员的了，我也不是很了解。

app优化的话，大体有以下几个方面

1. ui优化，去除累赘的布局，优化初始化的速度，提高apk流畅性。

2. 网络交互优化，好的网络和数据处理方式决定了app的体验性能。

3. 检查内存是否有泄漏，人们常说的anr详细。

如何你问的是android手机优化。

平常人只能下载手机管家这种软件进行清除内存，垃圾，卸载无用的apk，保持android系统的流畅性。