原有的bootloader方案是在片内FLASH上面分成3块，bootloader区占一小块，然后剩下区域平分成两块，一块是运行区，一块是新固件临时存储区。
好在现在FLASH在系统成本中占的比例越来越低了，不然这样用肯定很奢侈浪费了。
在此方案基础上，我们还可以使用压缩功能，这样临时存储区可以更小一些，可以释放出更多空间给运行区。
压缩算法格式综合考虑后使用gzip，解压程序使用zlib。
因为gzip格式比较通用，方便压缩和调试。而解压所消耗的资源也尚可接受。
一般测试下来，gz所用的 deflate 压缩算法大概有75%的压缩率。
所以建议使用压缩后的运行区与临时存储区的大小比例为 4:3 比较合适。
不过压缩率跟原文特征有很大关系，
因此，生成固件时，除原文不能大于运行区的大小以外，还要限制压缩后的体积不能大于临时存储区的大小。
另外，如果系统传输有使用加密技术的话，一定要先压缩再加密。
因为加密后的数据压缩率很小，甚至会有压缩后的体积大于原文的情况。
最后看下zlib解压消耗资源情况：
实测在某cortex-M3/4的系统上面，zlib只启用解压功能，CRC32把table放在RAM中，在末进行其它特别优化的情况占用FLASH在15KB左右。
而解压文件时，消耗的RAM在32KB+9KB，不过一般bootloader或IAP时，其它功能处于禁用状态，所以RAM一般都是可以满足的。
所以，只要固件被压缩下来的体积大于20～30KB就可以考虑使用压缩算法了。
解压速度（120Mhz cortex-M3）：
输入输出缓冲块均为16字节
初始化5us，解压1.8KB数据2.1ms，结束上下文7us.
初始化5us，解压150KB数据150ms，结束上下文7us.
输入输出缓冲块均为64字节
初始化5us，解压150KB数据100ms，结束上下文7us.