1、图像的加载 P336 - 342
（1）如果要处理一个非常大图像，可以使用 BitmapRegionDecoder 将图片进行区域解码，得到部分图像。
（2）通过设置 BitmapFactory.Options.inJustDecodeBounds 可以只得到图像的分辨率而防止其加载到内存中。
（3）BitmapFactory.Options.inSampleSize 与图片的缩小比例有关，该值必须是 2 的整数次幂，如果不是，则会自动向下取得符合要求的值，如 inSampleSize 如果设置为 7，则会取成 4，最终缩放的时候就会使宽、高都变为原来的 1/4，因此，所得到的位图的像素数量是原始的 1/16。而当 inSampleSize <= 1时， 按 1 处理。
优点：计算速度快；缺点：不能达到精确的预期缩放大小。
（4）也可以使用下面的参数进行精确的缩放：
参考代码：
优点：计算速度慢；缺点：能达到精确的预期缩放大小。
2、图像的缓存 P343 - 348
可以利用 LruChche 和 DiskLruChche 进行内存和磁盘缓存。
引用自：https://www.jianshu.com/p/c545f2a6cafc
3、图像的显示 P348 - 350
在通过 BitmapFactory 加载位图的时候，可以使用 BitmapFactory.Options.inPreferredConfig 设置格式。
4、Bitmap与管理内存 P350 - 354
通过 BitmapFactory.Options.inBitmap 属性，可以实现 Bitmap 对象的复用，使用的时候需要提供一个已存在的位图对象，让解码器重用该对象的内存空间，达到减少对象销毁与创建的目的。
限制：
第二点的意思是，比如，ARGB_8888 像素格式的位图，只能被同为 ARGB_8888 格式的位图对象复用，而不能被其它格式的重用。
具体的重用实现，自行谷歌，因为个人觉得书上的代码示例存在问题。
5、序列化 P336 - 342
JSON 的改进
在 JSON 结构中避免不必要的数据，即客户端用不到的数据。
通过定义属性数组，而非对象数组来减少属性名的重复。如下：
6、JSON 的替代品 P358 - 365
（1）Protocol buffers
与 XML 类似，都提供了一种定义数据结构都方法，但更小，使用 .proto 作为文件扩展名，最终被创建并传输的，是一个不可读的二进制数据流。
但是，其实现需要使用大量的内存和代码，不太适合移动设备的地方。
具体实现自行谷歌。
（2）Flat buffers
是 Google 创建的，有一个扁平化的二进制一维数组组成。
它需要的内存分配低，同时在字段定义方面，提供了高度的灵活性，代码开销也非常小。而且相对于其他解析器，它能以一种更高效快速的方式解析 JSON 文本。
具体实现自行谷歌。
7、本地序列化 P365
使用数据库来保存数据，避免用序列化的方式