1. 并不是每个算法都适用于所有的使用场景2. 关注点2.1. 数据是在哪里压缩、存储和解压的2.2. 数据是从哪里来的、到哪里去3. 数据压缩的使用场景3.1. 线下压缩，客户端解压3.1.1. 打包的应用程序或者电子游戏3.1.2. 艺术家创作并共享他们的作品3.1.3. 原始的作品都是使用高分辨率、高保真的工具制作的，然后再输出并压缩以供分发3.1.4. 目的是使多媒体文件尽可能地小3.1.5. 权衡取舍的是多媒体文件的品质3.2. 客户端压缩，云端解压3.2.1. 在客户端进行初步压缩，以节省出站通信的流量费用3.2.2. 目的是减少用户的费用3.2.3. 权衡取舍是对于移动设备，需要消耗电池的电量去压缩数据3.3. 云端压缩，客户端解压3.3.1. 由云端资源生成的动态数据3.3.1.1. 在客户端请求数据库操作的结果3.3.1.2. 服务器发送了动态布局的数据3.3.1.3. 平衡压缩后的大小与所需要的时间3.3.1.4. 目的就是让通过网络传输的内容变得更小3.3.1.5. 权衡取舍的是时间3.3.2. 为提高计算效率而传输到云端的大量数据3.3.2.1. 需要确保手边的媒体文件尽量地小3.3.2.2. 由云端传输出去的每个二进制位都需要所有者付费3.3.2.3. 客户端也需要为从云端获取的每个二进制位付费3.3.2.4. 目标就是高效地将大量的数据压缩为最少的二进制位数3.3.2.5. 权衡取舍的是成本和效率（也就是计算资源的价格）3.4. 客户端压缩，客户端解压3.4.1. 客户端应用程序相互之间需要通信3.4.2. 难点是客户端通常是移动设备，没有优化转换和压缩数据所需要的大量资源3.4.3. 需要权衡设备的功能、压缩和解压需要的时间以及需要数据的迫切性4. 数据压缩的需求4.1. 对图像数据应用哈夫曼编码，那么压缩的结果肯定达不到应用有损图像压缩算法的水平4.2. 与全屏显示的图片相比，缩略图对图片质量的要求就会比较低4.2.1. 缩略图可以使用有损的JPEG编码压缩4.2.2. 对质量有更高要求的图片则应该使用无损的WebP编解码器编码4.3. 了解要处理的数据4.3.1. 数据的类型4.3.2. 内部结构4.3.3. 使用方式4.4. 了解算法的各项指标4.4.1. 选出正确的算法系列4.5. 了解在给定的情况下你需要的是什么4.5.1. 有些算法能节省特别多的空间5. 压缩率5.1. 最重要的指标5.2. 内容压缩后的大小与压缩前大小之比5.3. 压缩的最主要目的就是让数据变得最紧凑，在网络传输中二进制位数总是越少越好5.4. 1GB的文本文件，用ZPAQ算法压缩，压缩后的文件通常会最小，但同时需要2GB的内存以及3个小时才能在台式计算机上完成压缩，解压时需要的资源时间大致相同5.4.1. 当关注的主要是压缩后的文件大小时，ZPAQ算法是很不错，但它不适用于在移动设备上压缩数据5.5. 对那些在线下或者云端进行压缩的服务来说，压缩率就是最重要的考虑因素5.5.1. 有资源、有时间将数据压缩得最小，同时这样做还能减少传输数据所需的费用6. 压缩性能6.1. 将数据转换为压缩后的形式需要多长时间6.2. 评价指标6.2.1. CPU速度6.2.1.1. 决定了数据可以压缩得多快6.2.2. 内存6.2.2.1. 它十分有限，特别是对移动设备来说7. 解压性能7.1. 对所有重点关注性能的环境来说，解压速度的重要性超过其他所有指标7.2. 选择压缩算法主要是根据该算法的解压性能而不是压缩后文件的大小7.3. 那些能将文件压缩得最小的算法，通常也需要花最长的时间去解压7.4. GZIP之所以成为当前世界上使用较多的通用文档压缩算法，解码性能是其中最主要的原因之一7.4.1. GZIP算法生成的压缩文件大小合适且解压速度很快，这使得它适用于各种类型的嵌入式设备和非嵌入式设备8. 解码流的能力8.1. 数据流通常是解压时容易被忽略的一个方面8.2. 完整的数据包8.2.1. 解码前所有的数据都必须在内存中8.3. 数据以分块的形式发送到客户端，一到客户端就开始解码（即分块解码）9. 比较压缩算法9.1. Squash压缩基准测试9.1.1. 测试各种算法在压缩XML、文本、图像以及其他数据格式时的表现9.2. Squeeze Chart9.2.1. 比较算法在压缩各种文本、音频以及位图时的表现9.3. 不同的算法和不同的设置，都会影响到开发的应用程序的压缩质量