Android性能优化之弱网优化详解

  目录

  弱网优化

  汇总了一下众多大佬的性能优化文章,知识点,主要包含:

  UI优化/启动优化/崩溃优化/卡顿优化/安全性优化/弱网优化/APP深度优化等等等~

  本篇是第五篇:弱网优化 [非商业用途,如有侵权,请告知我,我会删除]

  强调一下: 性能优化的开发文档跟之前的面试文档一样,需要的跟作者直接要。

  1、Serializable原理

  通常我们使用Java的序列化与反序列化时,只需要将类实现接口即可,剩下的事情就交给了jdk。今天我们就来探究一下,Java序列化是怎么实现的,然后探讨一下几个常见的集合类,他们是如何处理序列化带来的问题的。

  1.1 分析过程

  几个待思考的问题

  接下来我们就带着问题,在源码中找寻答案吧。

  1.2 Serializable接口

  先看接口,源码很简单,一个空的接口,没有方法也没有成员变量。但是注释非常详细,很清楚的描述了怎么用、能做什么,很值得一看,我们捡几个重点的翻译一下,

  /**

  * Serializability of a class is enabled by the class implementing the

  * java.io.Serializable interface. Classes that do not implement this

  * interface will not have any of their state serialized or

  * deserialized. All subtypes of a serializable class are themselves

  * serializable. The serialization interface has no methods or fields

  * and serves only to identify the semantics of being serializable.

  */

  类的可序列化性通过实现接口开启。未实现序列化接口的类不能序列化,所有实现了序列化的子类都可以被序列化。接口没有方法和属性,只是一个识别类可被序列化的标志。

  /**

  * Classes that require special handling during the serialization and

  * deserialization process must implement special methods with these exact

  * signatures:

  *

  *

  * private void writeObject(java.io.ObjectOutputStream out)

  * throws IOException

  * private void readObject(java.io.ObjectInputStream in)

  * throws IOException, ClassNotFoundException;

  * private void readObjectNoData()

  * throws ObjectStreamException;

  *

  */

  在序列化过程中,如果类想要做一些特殊处理,可以通过实现以下方法, , ,其中,

  1.3 ObjectOutputStream

  //我们要序列化对象的方法实现一般都是在这个函数中

  public final void writeObject(Object obj) throws IOException {

  ...

  try {

  //写入的具体实现方法

  writeObject0(obj, false);

  } catch (IOException ex) {

  ...

  throw ex;

  }

  }

  private void writeObject0(Object obj, boolean unshared) throws IOException {

  ...省略

  Object orig = obj;

  Class<?> cl = obj.getClass();

  ObjectStreamClass desc;

  for (;;) {

  // REMIND: skip this check for strings/arrays?

  Class<?> repCl;

  //获取到ObjectStreamClass,这个类很重要

  //在它的构造函数初始化时会调用获取类属性的函数

  //最终会调用getDefaultSerialFields这个方法

  //在其中通过flag过滤掉类的某一个为transient或static的属性(解释了问题3)

  desc = ObjectStreamClass.lookup(cl, true);

  if (!desc.hasWriteReplaceMethod() ||

  (obj = desc.invokeWriteReplace(obj)) == null ||

  (repCl = obj.getClass()) == cl)

  {

  break;

  }

  cl = repCl;

  }

  //其中主要的写入逻辑如下

  //String, Array, Enum本身处理了序列化

  if (obj instanceof String) {

  writeString((String) obj, unshared);

  } else if (cl.isArray()) {

  writeArray(obj, desc, unshared);

  } else if (obj instanceof Enum) {

  writeEnum((Enum<?>) obj, desc, unshared);

  //重点在这里,通过`instanceof`判断对象是否为`Serializable`

  //这也就是普通自己定义的类如果没有实现`Serializable`

  //在序列化的时候会抛出异常的原因(解释了问题1)

  } else if (obj instanceof Serializable) {

  writeOrdinaryObject(obj, desc, unshared);

  } else {

  if (extendedDebugInfo) {

  throw new NotSerializableException(

  cl.getName() + "

  " + debugInfoStack.toString());

  } else {

  throw new NotSerializableException(cl.getName());

  }

  }

  ...

  }

  private void writeOrdinaryObject(Object obj,

  ObjectStreamClass desc,

  boolean unshared)

  throws IOException

  {

  ...

  try {

  desc.checkSerialize();

  //写入二进制文件,普通对象开头的魔数0x73

  bout.writeByte(TC_OBJECT);

  //写入对应的类的描述符,见底下源码

  writeClassDesc(desc, false);

  handles.assign(unshared ? null : obj);

  if (desc.isExternalizable() && !desc.isProxy()) {

  writeExternalData((Externalizable) obj);

  } else {

  writeSerialData(obj, desc);

  }

  } finally {

  if (extendedDebugInfo) {

  debugInfoStack.pop();

  }

  }

  }

  private void writeClassDesc(ObjectStreamClass desc, boolean unshared)

  throws IOException

  {

  //句柄

  int handle;

  //null描述

  if (desc == null) {

  writeNull();

  //类对象引用句柄

  //如果流中已经存在句柄,则直接拿来用,提高序列化效率

  } else if (!unshared && (handle = handles.lookup(desc)) != -1) {

  writeHandle(handle);

  //动态代理类描述符

  } else if (desc.isProxy()) {

  writeProxyDesc(desc, unshared);

  //普通类描述符

  } else {

  //该方法会调用desc.writeNonProxy(this)如下

  writeNonProxyDesc(desc, unshared);

  }

  }

  void writeNonProxy(ObjectOutputStream out) throws IOException {

  out.writeUTF(name);

  //写入serialVersionUID

  out.writeLong(getSerialVersionUID());

  ...

  }

  public long getSerialVersionUID() {

  // 如果没有定义serialVersionUID

  // 序列化机制就会调用一个函数根据类内部的属性等计算出一个hash值

  // 这也是为什么不推荐序列化的时候不自己定义serialVersionUID的原因

  // 因为这个hash值是根据类的变化而变化的

  // 如果你新增了一个属性,那么之前那些被序列化后的二进制文件将不能反序列化回来,Java会抛出异常

  // (解释了问题2)

  if (suid == null) {

  suid = AccessController.doPrivileged(

  new PrivilegedAction() {

  public Long run() {

  return computeDefaultSUID(cl);

  }

  }

  );

  }

  //已经定义了SerialVersionUID,直接获取

  return suid.longValue();

  }

  //分析到这里,要插一个我对序列化后二进制文件的一点个人见解,见下面

  1.4 序列化后二进制文件的一点解读

  如果我们要序列化一个, 其中如下,

  class PhoneItem implements Serializable {

  String phoneNumber;

  }

  构造List的代码省略,假设我们序列化了一个为5的,查看二进制文件大概如下所示,

  7372 xxxx xxxx

  7371 xxxx xxxx

  7371 xxxx xxxx

  7371 xxxx xxxx

  7371 xxxx xxxx

  通过刚才的源码解读,开头的魔数0x73表示普通对象,72表示类的描述符号,71表示类描述符为引用类型。管中窥豹可知一点薄见,在解析二进制文件的时候,就是通过匹配魔数 (magic number) 开头方式,从而转换成Java对象的。当在序列化过程中,如果流中已经有同样的对象,那么之后的序列化可以直接获取该类对象句柄,变为引用类型,从而提高序列化效率。

  //通过writeSerialData调用走到真正解析类的方法中,有没有复写writeObject处理的逻辑不太一样

  //这里以默认没有复写writeObject为例,最后会调用defaultWriteFields方法

  private void defaultWriteFields(Object obj, ObjectStreamClass desc)

  throws IOException

  {

  ...

  int primDataSize = desc.getPrimDataSize();

  if (primVals == null || primVals.length < primDataSize) {

  primVals = new byte[primDataSize];

  }

  desc.getPrimFieldValues(obj, primVals);

  //写入属性大小

  bout.write(primVals, 0, primDataSize, false);

  ObjectStreamField[] fields = desc.getFields(false);

  Object[] objVals = new Object[desc.getNumObjFields()];

  int numPrimFields = fields.length - objVals.length;

  desc.getObjFieldValues(obj, objVals);

  for (int i = 0; i < objVals.length; i++) {

  ...

  try {

  //遍历写入属性类型和属性大小

  writeObject0(objVals[i],

  fields[numPrimFields + i].isUnshared());

  } finally {

  if (extendedDebugInfo) {

  debugInfoStack.pop();

  }

  }

  }

  }

  由于反序列化过程和序列化过程类似,这里不再赘述。

  1.5 常见的集合类的序列化问题

  1.5.1 HashMap

  Java要求被反序列化后的对象要与被序列化之前的对象保持一致,但因为hashmap的key是通过hash计算的。反序列化后计算得到的值可能不一致(反序列化在不同的jvm环境下执行)。所以HashMap需要重写序列化实现的过程,避免出现这种不一致的情况。

  具体操作是将要自定义处理的属性定义为,然后复写,在其中做特殊处理

  private void writeObject(java.io.ObjectOutputStream s)

  throws IOException {

  int buckets = capacity();

  // Write out the threshold, loadfactor, and any hidden stuff

  s.defaultWriteObject();

  //写入hash桶的容量

  s.writeInt(buckets);

  //写入k-v的大小

  s.writeInt(size);

  //遍历写入不为空的k-v

  internalWriteEntries(s);

  }

  1.5.2 ArrayList

  因为在ArrayList中的数组容量基本上都会比实际的元素的数大, 为了避免序列化没有元素的数组而重写和

  private void writeObject(java.io.ObjectOutputStream s)

  throws java.io.IOException{

  ...

  s.defaultWriteObject();

  // 写入arraylist当前的大小

  s.writeInt(size);

  // 按照相同顺序写入元素

  for (int i=0; i

  s.writeObject(elementData[i]);

  }

  ...

  }

  2、Parcelable

  Parcelable是Android为我们提供的序列化的接口,Parcelable相对于Serializable的使用相对复杂一些,但Parcelable的效率相对Serializable也高很多,这一直是Google工程师引以为傲的,有时间的可以看一下Parcelable和Serializable的效率对比号称快10倍的效率

  Parcelable接口的实现类是可以通过Parcel写入和恢复数据的,并且必须要有一个非空的静态变量 CREATOR, 而且还给了一个例子,这样我们写起来就比较简单了,但是简单的使用并不是我们的最终目的

  通过查看Android源码中Parcelable可以看出,Parcelable实现过程主要分为序列化,反序列化,描述三个过程,下面分别介绍下这三个过程

  2.1 Parcel的简介

  在介绍之前我们需要先了解Parcel是什么?Parcel翻译过来是打包的意思,其实就是包装了我们需要传输的数据,然后在Binder中传输,也就是用于跨进程传输数据

  简单来说,Parcel提供了一套机制,可以将序列化之后的数据写入到一个共享内存中,其他进程通过Parcel可以从这块共享内存中读出字节流,并反序列化成对象,下图是这个过程的模型。

  Parcel可以包含原始数据类型(用各种对应的方法写入,比如writeInt(),writeFloat()等),可以包含Parcelable对象,它还包含了一个活动的IBinder对象的引用,这个引用导致另一端接收到一个指向这个IBinder的代理IBinder。

  Parcelable通过Parcel实现了read和write的方法,从而实现序列化和反序列化。可以看出包含了各种各样的read和write方法,最终都是通过native方法实现

  2.2 Parcelable的三大过程介绍(序列化、反序列化、描述)

  到这里,基本上关系都理清了,也明白简单的介绍和原理了,接下来在实现Parcelable之前,介绍下实现Parcelable的三大流程

  首先写一个类实现Parcelable接口,会让我们实现两个方法

  2.2.1 描述

  其中describeContents就是负责文件描述,首先看一下源码的解读

  通过上面的描述可以看出,只针对一些特殊的需要描述信息的对象,需要返回1,其他情况返回0就可以

  2.2.2 序列化

  我们通过writeToParcel方法实现序列化,writeToParcel返回了Parcel,所以我们可以直接调用Parcel中的write方法,基本的write方法都有,对象和集合比较特殊下面单独讲,基本的数据类型除了boolean其他都有,Boolean可以使用int或byte存储

  2.2.3 反序列化

  反序列化需要定义一个CREATOR的变量,上面也说了具体的做法,这里可以直接复制Android给的例子中的,也可以自己定义一个(名字千万不能改),通过匿名内部类实现Parcelable中的Creator的接口

  2.3 Parcelable的实现和使用

  根据上面三个过程的介绍,Parcelable就写完了,就可以直接在Intent中传输了,可以自己写两个Activity传输一下数据试一下,其中一个putExtra另一个getParcelableExtra即可

  这里实现Parcelable也很简单:

  1.写一个类实现Parcelable然后alt+enter 添加Parcelable所需的代码块,AndroidStudio会自动帮我们实现(这里需要注意如果其中包含对象或集合需要把对象也实现Parcelable)

  2.4 Parcelable中对象和集合的处理

  如果实现Parcelable接口的对象中包含对象或者集合,那么其中的对象也要实现Parcelable接口

  写入和读取集合有两种方式:

  一种是写入类的相关信息,然后通过类加载器去读取, –> writeList | readList

  二是不用类相关信息,创建时传入相关类的CREATOR来创建 –> writeTypeList | readTypeList | createTypedArrayList

  第二种效率高一些,但一定要注意如果有集合定义的时候一定要初始化

  like this –>

  public ArrayList authors = new ArrayList<>();

  2.5 Parcelable和Serializable的区别和比较

  Parcelable和Serializable都是实现序列化并且都可以用于Intent间传递数据,Serializable是Java的实现方式,可能会频繁的IO操作,所以消耗比较大,但是实现方式简单 Parcelable是Android提供的方式,效率比较高,但是实现起来复杂一些 , 二者的选取规则是:内存序列化上选择Parcelable, 存储到设备或者网络传输上选择Serializable(当然Parcelable也可以但是稍显复杂)

  3、http与https原理详解

  3.1 概述

  早期以信息发布为主的Web 1.0时代,HTTP已可以满足绝大部分需要。证书费用、服务器的计算资源都比较昂贵,作为HTTP安全扩展的HTTPS,通常只应用在登录、交易等少数环境中。但随着越来越多的重要业务往线上转移,网站对用户隐私和安全性也越来越重视。对于防止恶意监听、中间人攻击、恶意劫持篡改,HTTPS是目前较为可行的方案,全站HTTPS逐渐成为主流网站的选择。

  3.2 HTTP简介

  HTTP(HyperText Transfer Protocol,超文本传输协议),是一种 协议,提供了一组规则和标准,从而让信息能够在互联网上进行传播。在HTTP中,客户端通过Socket创建一个TCP/IP连接,并连接到服务器,完成信息交换后,就会关闭TCP连接。(后来通过实现长连接)

  3.2.1 HTTP消息组成

  HTTP头部

  HTTP头部由一系列的键值对组成,允许客户端向服务器端发送一些附加信息或者客户端自身的信息,如:等。http头后面必须有一个空行

  请求行

  请求行由方法、URL、HTTP版本组成。

  响应行

  响应行由HTTP版本、状态码、信息提示符组成。

  3.3 HTTP2.0和HTTP1.X相比的新特性

  3.4 HTTP安全问题

  3.5 HTTPS协议

  HTTPS 是最流行的 HTTP 安全形式。使用 HTTPS 时,所有的 HTTP 请求和响应数据在发送到网络之前,都要进行加密。 HTTPS 在 HTTP 下面提供了一个传输级的密码安全层——可以使用 SSL,也可以使用其后继者——传输层安全(TLS)。

  相关术语

  3.5.1 TLS/SSL协议

  TLS/SSL协议包含以下一些关键步骤:

  TLS/SSL协议核心就三大步骤:。

  3.5.2 RSA握手

  握手阶段分成五步:

  握手阶段有三点需要注意:

  3.5.3 DH握手

  RSA整个握手阶段都不加密,都是明文的。因此,如果有人窃听通信,他可以知道双方选择的加密方法,以及三个随机数中的两个。整个通话的安全,只取决于能不能被破解。为了足够安全,我们可以考虑把握手阶段的算法从默认的算法,改为 算法(简称DH算法)。采用DH算法后,不需要传递,双方只要交换各自的参数,就可以算出这个随机数。

  4、protobuffer

  protobuffer是一种语言无关、平台无关的数据协议,优点在于压缩性好,可扩展,标准化,常用于数据传输、持久化存储等。

  4.1 实现原理

  4.1.1 protobuffer协议

  1.压缩性好(相比于同样跨平台、跨语言的json)

  varint和zigzag算法:对数字进行压缩

  protobuffer协议去除字段定义,分隔符

  2.可拓展

  protobuffer并不是一个自解析的协议(json自解析key),需要pb的meta数据解析,牺牲了可读性,但在大规模的数据处理是可以接受的。可拓展性在于protobuffer中追加定义,新旧版本是可以兼容的,但是定义是严格有序的。

  3.标准化

  protobuffer生态提供了完整的工具链,protobuffer提供官方的生成golang/java等实现插件,这样protobuffer字节码的各语言版本的序列化、反序列化是标准化的,也包括插件生成代码封装。以及标准化的常用工具,比如doc-gen、grpc-gen、grpc-gateway-gen等工具。

  4.1.2 典型应用

  gRPC

  protobuffer封装

  需要注意:

  1.pb结构封装的字段标序是不能更改的,否则解析错乱;

  2.pb结构尽量把必选类型,比如int、bool放在filedNum<=16;可得到更好的varint压缩效果;

  3.grpc-client使用时,req是指针类型,务必不要重复复制,尽量new request,否则编码时会错乱;

  4.2 protobuffer 编码原理

  protobuffer(以下简称为PB)两个重要的优势在于高效的序列化/反序列化和低空间占用,而这两大优势是以其高效的编码方式为基础的。PB底层以二进制形式存储,比binary struct方式更加紧凑,一般来讲空间利用率也比binary struct更高,是以Key-Value的形式存储【图1】。

  PB示例结构如下:

  //示例protobuf结构

  message Layer1

  {

  optional uint32 layer1_varint = 1;

  optional Layer2 layer1_message = 2;

  }

  message Layer2

  {

  optional uint32 layer2_varint = 1;

  optional Layer3 layer2_message = 2;

  }

  message Layer3

  {

  optional uint32 layer3_varint = 1;

  optional bytes layer3_bytes = 2;

  optional float layer3_float = 3;

  optional sint32 layer3_sint32 = 4;

  }

  PB将常用类型按存储特性分为数种Wire Type【图 2】, Wire Type不同,编码方式不同。根据Wire Type(占3bits)和field number生成Key。

  Key计算方式如下,并以Varint编码方式序列化【参考下面Varint编码】,所以理论上[1, 15]范围内的field, Key编码后占用一个字节, [16,)的Key编码后会占用一个字节以上,所以尽量避免在一个结构里面定义过多的field。如果碰到需要定义这么多field的情况,可以采用嵌套方式定义。

  //Key的计算方式

  Key = field_number << 3 | Wire_Type

  TypeValueMeaningContainVarint0varintint32,int64,sint32,sint64,uint32,uint64,bool,enumFixed64164-bitfixed64,sfixed64,double,floatLengthDelimited2length-delimistring,message,bytes,repeatedStartGroup3start groupgroups(deprecated)EndGroup4end groupgroups(deprecated)Fixed32532-bitfixed32,float

  4.2.1 Varint编码

  inline uint8* WriteVarint32ToArray(uint32 value, uint8* target) {

  while (value >= 0x80) {

  *target = static_cast(value | 0x80);

  value >>= 7;

  ++target;

  }

  *target = static_cast(value);

  return target + 1;

  }

  Layer1 obj;

  obj.set_layer1_varint(12345);

  Varint编码只用每个字节的低7bit存储数据,最高位0x80用做标识,清空:最后一个字节,置位:还有数据。以上述操作为例,设uint32类型为12345,其序列化过程如下:

  该字段的, , 则。那么在内存中, 其序列为应该为0x20B960,占3Bytes。对比直接用struct存储会占4Bytes;

  如果struct是用 uint64呢,将占8Bytes,而PB占用内存仍是3Bytes。

  下表是PB数值范围与其字节数对应关系。实际应用中,我们用到的数大概率是比较小的,而且可能 动态范围比较大(有时需要用64位存储),对比struct的内存占用,PB优势很明显。

  数值范围占用字节数0-1272128-16383316384-209715142097152-2684354555

  4.2.2 ZigZag编码

  ZigZag编码是对Varint编码的补充与优化。负数在内存中以前补码形式存在,但不管是负数的原码还是补码,最高位都是1;那么问题来了,如果以上述Varint编码方式,所有负数序列化以后都会以最大化占用内存(32位占用6Bytes, 64位占用11Btyes)。所以,细心的同学会发现,对于有符号数的表示有两种类型,int32和sint32。对,sint32就是对这种负数序列化优化的变种。

  inline uint32 WireFormatLite::ZigZagEncode32(int32 n) {

  // Note: the right-shift must be arithmetic

  return (static_cast(n) << 1) ^ (n >> 31);

  }

  sint32uint3200-1112-23……21474836474294967294-21474836484294967295

  对于sint32类型的数据,在varint编码之前,会先进行zigzag编码,上图是其映射关系。编码后,较小的负数,可以映射为较小的正数,从而实现根据其信息量决定其序列化后占用的内存大小。

  所以聪明的同学们已经知道该如何选择了,对于有符合数尽量选择sint32,而不是int32,不管从空间和时间上,都是更优的选择

  4.2.3 length-delimi编码

  length-delimi编码方式比较简单,是建立在varint编码基础上的,主要是针对message、bytes、repeated等类型,与TLV格式类似。先以varint编码写入tag即Key,再以varint编码写入长度,最后把内容memcpy到内存中。

  inline uint8* WriteBytesToArray(int field_number,

  const string& value,

  uint8* target) {

  target = WriteTagToArray(field_number, WIRETYPE_LENGTH_DELIMITED, target);

  return io::CodedOutputStream::WriteStringWithSizeToArray(value, target);

  }

  uint8* WriteStringWithSizeToArray(const string& str,

  uint8* target) {

  GOOGLE_DCHECK_LE(str.size(), kuint32max);

  target = WriteVarint32ToArray(str.size(), target);

  return WriteStringToArray(str, target);

  }

  4.2.4 fixed编码

  fixed编码很简单,主要针对类型有fixed32、fixed64、double、float。由于长度固定,只需要Key + Value即可。对于浮点型会先强制转换成相对应的整形,反序列化时则反之。

  inline uint32 EncodeFloat(float value) {

  union {float f; uint32 i;};

  f = value;

  return i;

  }

  inline uint64 EncodeDouble(double value) {

  union {double f; uint64 i;};

  f = value;

  return i;

  }

  inline void WireFormatLite::WriteFloatNoTag(float value,

  io::CodedOutputStream* output) {

  output->WriteLittleEndian32(EncodeFloat(value));

  }

  inline void WireFormatLite::WriteDoubleNoTag(double value,

  io::CodedOutputStream* output) {

  output->WriteLittleEndian64(EncodeDouble(value));

  }

  4.2.5 整个编码流程

  4.3 protobuf解码过程

  上面已经介绍了编码原理,那么解码的流程也就很简单了。解码是一个递归的过程,先通过Varint解码过程读出Key, 取出field_number字段,如果不存在于message中,就放到UnKnownField中。如果是认识的field_number,则根据wire_type做具体的解析。对于普通类型(如整形,bytes, fixed类型等)就直接写入Field中,如果是嵌套类型(一般特指嵌套的Message),则递归调用整个解析过程。解析完一个继续解析下一个,直到buffer结束。

  5、gzip压缩方案

  5.1 gzip介绍

  gzip是GNU zip的缩写,它是一个GNU自由软件的文件压缩程序,也经常用来表示gzip这种文件格式。软件的作者是Jean-loup Gailly和Mark Adler。1992年10月31日第一次公开发布,版本号是0.1,目前的稳定版本是1.2.4。

  Gzip主要用于Unix系统的文件压缩。我们在Linux中经常会用到后缀为.gz的文件,它们就是GZIP格式的。现今已经成为Internet 上使用非常普遍的一种数据压缩格式,或者说一种文件格式。 当应用Gzip压缩到一个纯文本文件时,效果是非常明显的,经过GZIP压缩后页面大小可以变为原来的40%甚至更小,这取决于文件中的内容。

  HTTP协议上的GZIP编码是一种用来改进WEB应用程序性能的技术。web开发中可以通过gzip压缩页面来降低网站的流量,而gzip并不会对cpu造成大量的占用,略微上升,也是几个百分点而已,但是对于页面却能压缩30%以上,非常划算。

  利用Apache中的Gzip模块,我们可以使用Gzip压缩算法来对Apache服务器发布的网页内容进行压缩后再传输到客户端浏览器。这样经过压缩后实际上降低了网络传输的字节数(节约传输的网络I/o),最明显的好处就是可以加快网页加载的速度。

  网页加载速度加快的好处不言而喻,除了节省流量,改善用户的浏览体验外,另一个潜在的好处是Gzip与搜索引擎的抓取工具有着更好的关系。例如 Google就可以通过直接读取gzip文件来比普通手工抓取更快地检索网页。在Google网站管理员工具(Google Webmaster Tools)中你可以看到,sitemap.xml.gz 是直接作为Sitemap被提交的。

  而这些好处并不仅仅限于静态内容,PHP动态页面和其他动态生成的内容均可以通过使用Apache压缩模块压缩,加上其他的性能调整机制和相应的服务器端缓存规则,这可以大大提高网站的性能。因此,对于部署在Linux服务器上的PHP程序,在服务器支持的情况下,我们建议你开启使用Gzip Web压缩。

  5.2 Web服务器处理HTTP压缩的过程如下:

  下面是两个演示图:

  未使用Gzip:

  开启使用Gzip后:

  5.3 启用apache的gzip功能

  Apache上利用Gzip压缩算法进行压缩的模块有两种:mod_gzip 和mod_deflate。要使用Gzip Web压缩,请首先确定你的服务器开启了对这两个组件之一的支持。

  虽然使用Gzip同时也需要客户端浏览器的支持,不过不用担心,目前大部分浏览器都已经支持Gzip了,如IE、Mozilla Firefox、Opera、Chrome等。

  通过查看HTTP头,我们可以快速判断使用的客户端浏览器是否支持接受gzip压缩。若发送的HTTP头中出现以下信息,则表明你的浏览器支持接受相应的gzip压缩:

  Accept-Encoding: gzip 支持mod_gzip

  Accept-Encoding: deflate 支持mod_deflate

  Accept-Encoding: gzip,deflate 同时支持mod_gzip 和mod_deflate

  如firebug查看:

  Accept-Encoding: gzip,deflate 是同时支持mod_gzip 和mod_deflate

  如果服务器开启了对Gzip组件的支持,那么我们就可以在http.conf或.htaccess里面进行定制,下面是一个.htaccess配置的简单实例:

  mod_gzip 的配置:

  # mod_gzip:

  

  mod_gzip_on Yes

  mod_gzip_dechunk Yes

  mod_gzip_item_include file .(html?|txt|css|js|php|pl)$

  mod_gzip_item_include handler ^cgi-script$

  mod_gzip_item_include mime ^text/.*

  mod_gzip_item_include mime ^application/x-javascript.*

  mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*

  

  mod_deflate的配置实例:

  打开打开apache 配置文件httpd.conf

  将#LoadModule deflate_module modules/mod_deflate.so去除开头的#号

  # mod_deflate:

  

  DeflateCompressionLevel 6 #压缩率, 6是建议值.

  AddOutputFilterByType DEFLATE text/plain

  AddOutputFilterByType DEFLATE text/html

  AddOutputFilterByType DEFLATE text/xml

  AddOutputFilterByType DEFLATE text/css

  AddOutputFilterByType DEFLATE text/javascript

  AddOutputFilterByType DEFLATE application/xhtml+xml

  AddOutputFilterByType DEFLATE application/xml

  AddOutputFilterByType DEFLATE application/rss+xml

  AddOutputFilterByType DEFLATE application/atom_xml

  AddOutputFilterByType DEFLATE application/x-javascript

  AddOutputFilterByType DEFLATE application/x-httpd-php

  AddOutputFilterByType DEFLATE image/svg+xml

  

  里面的文件MIME类型可以根据自己情况添加,至于PDF 、图片、音乐文档之类的这些本身都已经高度压缩格式,重复压缩的作用不大,反而可能会因为增加CPU的处理时间及浏览器的渲染问题而降低性能。所以就没必要再通过Gzip压缩。通过以上设置后再查看返回的HTTP头,出现以下信息则表明返回的数据已经过压缩。即网站程序所配置的Gzip压缩已生效。

  Content-Encoding: gzip

  firebug查看:

  注意:

  1)不管使用mod_gzip 还是mod_deflate,此处返回的信息都一样。因为它们都是实现的gzip压缩方式。

  2)CompressionLevel 9是指压缩程度的等级(设置压缩比率),取值范围在从1到9,9是最高等级。据了解,这样做最高可以减少8成大小的传输量(看档案内容而定),最少也能够节省一半。 CompressionLevel 预设可以采用 6 这个数值,以维持耗用处理器效能与网页压缩质量的平衡. 不建议设置太高,如果设置很高,虽然有很高的压缩率,但是占用更多的CPU资源. 3) 对已经是压缩过的图片格式如jpg,音乐档案如mp3、压缩文件如zip之类的,就没必要再压缩了。

  5.4 mod_gzip 和mod_deflate的主要区别是什么?使用哪个更好呢?

  第一个区别是安装它们的Apache Web服务器版本的差异:

  Apache 1.x系列没有内建网页压缩技术,所以才去用额外的第三方mod_gzip 模块来执行压缩。

  Apache 2.x官方在开发的时候,就把网页压缩考虑进去,内建了mod_deflate 这个模块,用以取代mod_gzip。虽然两者都是使用的Gzip压缩算法,它们的运作原理是类似的。

  第二个区别是压缩质量:

  mod_deflate 压缩速度略快而mod_gzip 的压缩比略高。一般默认情况下,mod_gzip 会比mod_deflate 多出4%~6%的压缩量。

  那么,为什么使用mod_deflate?

  第三个区别是对服务器资源的占用:

  一般来说mod_gzip 对服务器CPU的占用要高一些。mod_deflate 是专门为确保服务器的性能而使用的一个压缩模块,mod_deflate 需要较少的资源来压缩文件。这意味着在高流量的服务器,使用mod_deflate 可能会比mod_gzip 加载速度更快。

  不太明白?简而言之,如果你的网站,每天不到1000独立访客,想要加快网页的加载速度,就使用mod_gzip。虽然会额外耗费一些服务器资源, 但也是值得的。如果你的网站每天超过1000独立访客,并且使用的是共享的虚拟主机,所分配系统资源有限的话,使用mod_deflate 将会是更好的选择。

  另外,从Apache 2.0.45开始,mod_deflate 可使用DeflateCompressionLevel 指令来设置压缩级别。该指令的值可为1(压缩速度最快,最低的压缩质量)至9(最慢的压缩速度,压缩率最高)之间的整数,其默认值为6(压缩速度和压缩质 量较为平衡的值)。这个简单的变化更是使得mod_deflate 可以轻松媲美mod_gzip 的压缩。

  P.S. 对于没有启用以上两种Gzip模块的虚拟空间,还可以退而求其次使用php的zlib函数库(同样需要查看服务器是否支持)来压缩文件,只是这种方法使用起来比较麻烦,而且一般会比较耗费服务器资源,请根据情况慎重使用。

  5.5 zlib.output_compression和ob_gzhandler编码方式压缩

  服务器不支持mod_gzip、mod_deflate模块,若想通过GZIP压缩网页内容,可以考虑两种方式,开启zlib.output_compression或者通过ob_gzhandler编码的方式。

  1)zlib.output_compression是在对网页内容压缩的同时发送数据至客户端。

  2)ob_gzhandler是等待网页内容压缩完毕后才进行发送,相比之下前者效率更高,但需要注意的是,两者不能同时使用,只能选其一,否则将出现错误。

  两者的实现方式做简单描述:

  5.5.1 zlib.output_compression实现方式

  在默认情况下,zlib.output_compression是关闭:

  ; Transparent output compression using the zlib library

  ; Valid values for this option are 'off', 'on', or a specific buffer size

  ; to be used for compression (default is 4KB)

  ; Note: Resulting chunk size may vary due to nature of compression. PHP

  ; outputs chunks that are few hundreds bytes each as a result of

  ; compression. If you prefer a larger chunk size for better

  ; performance, enable output_buffering in addition.

  ; Note: You need to use zlib.output_handler instead of the standard

  ; output_handler, or otherwise the output will be corrupted.

  ; http://php.net/zlib.output-compression

  zlib.output_compression = Off

  ; http://php.net/zlib.output-compression-level

  ;zlib.output_compression_level = -1

  如需开启需编辑php.ini文件,加入以下内容:

  zlib.output_compression = On

  zlib.output_compression_level = 6

  可以通过phpinfo()函数检测结果。

  当zlib.output_compression的Local Value和MasterValue的值同为On时,表示已经生效,这时候访问的PHP页面(包括伪静态页面)已经GZIP压缩了,通过Firebug或者在线网页GZIP压缩检测工具可检测到压缩的效果。

  5.5.2 ob_gzhandler的实现方式

  如果需要使用ob_gzhandler,则需关闭zlib.output_compression,把php.ini文件内容更改为:

  zlib.output_compression = Off

  zlib.output_compression_level = -1

  通过在PHP文件中插入相关代码实现GZIP压缩P压缩:

  if (extension_loaded('zlib')) {

  if ( !headers_sent() AND isset($_SERVER['HTTP_ACCEPT_ENCODING']) &&

  strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') !== FALSE)

  //页面没有输出且浏览器可以接受GZIP的页面

  {

  ob_start('ob_gzhandler');

  }

  }

  //待压缩的内容

  echo $context;

  ob_end_flush();

  如何浏览器提示:内容编码错误,应该是:

  使用ob_start('ob_gzhandler')时候前面已经有内容输出,检查前面内容以及require include调用文件的内容。若无法找到可以在调用其它文件前使用ob_start(),调用之后使用 ob_end_clean () 来清除输出的内容:

  if (extension_loaded('zlib')) {

  if ( !headers_sent() AND isset($_SERVER['HTTP_ACCEPT_ENCODING']) &&

  strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') !== FALSE)

  //页面没有输出且浏览器可以接受GZIP的页面

  {

  ob_end_clean ();

  ob_start('ob_gzhandler');

  }

  }

  或者我们使用gzencode来压缩:

  <?php

  $encoding = 'gzip';

  $content = '123456789';

  ob_end_clean ();

  header('Content-Encoding: '.$encoding);

  $result = gzencode($content);

  echo $result;

  exit;

  不管是zlib.output_compression还是ob_gzhandler,都仅能对PHP文件进行GZIP压缩,对于HTML、CSS、JS等静态文件只能通过调用PHP的方式实现。

  最后想说的是,现在主流的浏览器默认使用的是HTTP1.1协议,基本都支持GZIP压缩,对于IE而言,假如你没有选中其菜单栏工具-》Internet 选项-》高级-》HTTP 1.1 设置-》使用 HTTP 1.1,那么,你将感受不到网页压缩后的速度提升所带来的快感!

  以上就是Android性能优化之弱网优化详解的详细内容,更多关于Android 性能弱网优化的资料请关注脚本之家其它相关文章!

  您可能感兴趣的文章: