Skip to content

Commit

Permalink
update to v1.1.1;
Browse files Browse the repository at this point in the history
 fix reasve; optimized android .so files size;
  • Loading branch information
sisong committed Jun 10, 2023
1 parent b4c3483 commit 342ff10
Show file tree
Hide file tree
Showing 5 changed files with 5 additions and 5 deletions.
4 changes: 2 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
# sfpatcher:针对应用商店的apk增量算法
**v1.0.15 已正式上线**为亿级手机终端用户提供更新服务,当前最新版本 v1.1.0
**v1.0.15 已正式上线**为亿级手机终端用户提供优化的更新服务,当前最新版本 v1.1.1
[**sfpatcher** 命令行工具下载](https://github.com/sisong/sfpatcher/releases)(支持Windows、Linux、MacOS),
[命令行使用说明](https://github.com/sisong/sfpatcher/blob/master/cmdline_doc.md)
需要商业授权(含源代码&培训),请联系作者: <housisong@hotmail.com>
Expand Down Expand Up @@ -41,7 +41,7 @@
- 针对应用商店的场景专门设计,优化补丁大小,支持大型游戏,patch时精确快速还原任意apk文件,能够用于用户交互场景。
- 多级可选的补丁包大小,极致的patch速度:提供比谷歌**archive-patcher**方案(+brotli-9压缩)下载补丁小10%的情况下,手机上patch速度是其8倍(这时补丁比BsDiff方案小约50%并且速度快得多)!补丁比其略大1%的情况下,手机上速度是其21倍!补丁比其小21%的情况下,平均速度是其3.5倍! (注1)
- patch时的内存等资源占用可控;diff时支持多种方案限制patch时的最大内存占用到合适的约定水平。即支持patch时O(1)平均内存占用的优化补丁包(并且patch不使用临时文件)!
- 优化的用户体验:支持下载数据的同时就可以开始patch,不用将补丁文件保存到内存或硬盘上,结合快速的patch,很多时候下载完成时,就可以得到了完整的新版本apk文件。因为补丁变小,下载时间也会变短,从而可能缩短整体更新时间。)
- 优化的用户体验:支持下载数据的同时就可以开始patch,不用将补丁文件保存到内存或硬盘上,结合快速的patch,很多时候下载完成时,就可以得到了完整的新版本apk文件。因为补丁变小,下载时间也会变短,从而可能缩短整体更新时间,也更省电省流量。
- 利用精确还原算法,对于初次下载的apk文件也能进行解压后的重压缩;从而节省用户初次下载apk时的流量。最多情况下平均比直接下载apk文件减少22%的数据,部分文件能减少35%以上的数据!
- 支持从中断的位置继续patch的特性,节省程序被终止后再次执行程序时的打补丁时间。
- 高扩展性,框架支持多种压缩档案格式(apk、zip、zip64、jar、gz、tar等)和其嵌套(如apk中多个子apk); 档案格式本身和档案中数据的压缩算法都只是以插件的形式获得支持。patch端的执行,设计上不依赖于具体的档案格式。
Expand Down
6 changes: 3 additions & 3 deletions cmdline_doc.md
Original file line number Diff line number Diff line change
Expand Up @@ -59,7 +59,7 @@ options:
if newData not similar to oldData then diff speed++,
big cache max used O(oldFileSize) memory, and build slow(diff speed--)
-step-patchStepMemroySize
set patch step memory size, DEFAULT -sm-2m, recommended: 64k,512k,8m etc...
set patch step memory size, DEFAULT -step-2m, recommended: 64k,512k,8m etc...
-pre
set is always decode newArchiveFile (precompress), DEFAULT false;
if set this option, outDiffFile maybe smaller, but maybe slower when patch;
Expand Down Expand Up @@ -131,7 +131,7 @@ options:

* **-pre 选项**:设置是否始终让新版本数据处于解压缩状态,默认不(即保持原压缩状态不解压);一般在diff过程中新旧数据都在解压缩状态进行匹配,当解压状态的部分新数据没有搜寻到匹配数据时,默认就会还原成压缩状态,这样有利于优化patch时的速度,减少需要重新压缩的数据量。 打开的情况下(即始终解压),一般输出文件会小一些(相当于解压后用更好的压缩算法重新压缩了数据)。
推荐用于当旧版本文件为空,并和-o-2和-c-lzma2一起用于新版本的初次下载优化,比如:
`$ sf_diff "" "new.apk" "recompressed.pat" -pre o-2 -c-lzma2-9-32m -p-8`
`$ sf_diff "" "new.apk" "recompressed.pat" -pre -o-2 -c-lzma2-9-32m -p-8`

* **-lp 选项**:设置解压出临时数据的最大内存占用;该值可以控制patch时的最大内存占用值。当设置-o-2或-o-3时默认值为最大2文件解压缩后数据大小的和;而使用-o-1时一般不用设置(推荐-lp-512k);如果patch时使用临时文件来存放临时解压出的old数据,那-lp的设置值无意义;设置过小,可能会使输出的补丁包变大。
为了控制patch时的最大内存,推荐始终设置该值,比如:
Expand Down Expand Up @@ -228,7 +228,7 @@ patch端建议参数:`$ sf_patch "old.apk" "diff.pat" "out_new.apk" -lp -p-12`
patch端建议参数:`$ sf_patch "old.apk" "diff.pat" "out_new.apk" -lp -p-14`

* 对新版本的初次下载大小优化,并且保持最差patch速度勉强可接受:
`$ sf_diff "" "new.apk" "recompressed.pat" -pre o-2 -c-lzma2-9-16m`
`$ sf_diff "" "new.apk" "recompressed.pat" -pre -o-2 -c-lzma2-9-16m`
(patch时内存占用估算:0m+0m+16m,最大约30MB左右。)
patch端建议参数:`$ sf_patch "" "recompressed.pat" "out_new.apk" -p-10`

Expand Down
Binary file modified img/com.tripadvisor.tripadvisor.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file modified img/com.ubercab.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file modified img/tv.danmaku.bili.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit 342ff10

Please sign in to comment.