housisong

用-b来表达需要更好(better)的结果，以更长diff时间为代价； 即 -s[-b][-matchSize] 来设置

obb是一个固定路径的可读写文件，下载新版本替换不就行了

为什么是1000ms，而不能是100ms？

0.9.3已经优化了部分该问题，去掉了sameList中被引用到的序号； 任务算部分解决 后续需要继续优化： decompressList

尝试了一下“计算相关性”，综合效果不太好； 另一个思路，当patch时，用到某文件时才解压，用完后立即释放； 结合“引用到的文件的最大区域”的概念； 测试了一下：内存节约效果有一些但没有突破性；

apkdiff时限制为同时解压引用个数为1，补丁可能会变大一些； 方案1. 原始hdiff算法需要定制，match时支持按规则动态限制匹配区域；耦合有点重； 2. 设计新的格式，不再用整体diff，而是分单个文件分别diff，生成的补丁包会变大,需要升级patch客户端有一个兼容过渡问题。

apkdiff时限制为同时解压引用个数为1，方案3,重构核心diff算法，开放更细粒度的API： 返回覆盖线和后续处理的API

call _file_append_part() return a false --> call self->_curNewFile->write() return a false Here, we know that fwrite() return a false, but code unknow this: not sure about _curNewFile is a file...

call ferror() ? I did not find the meaning of the return value. change file API to OS file API, such as: windows API CreateFile\WriteFile\... then call GetLastError() get why...

v4.2.3 test dir patch, when disk full print log: ``` hpatch_TFileStream ERROR! errno: 28, errmsg: No space left on device. dir_patch check self->_listener->closeNewFile(self->_listener,self->_curNewFile) error! check _file_append_end(self) error! dir_patch TDirPatcher_patch() patch_decompress_with_cache...