Hadoop2.4 支持snappy_服务器应用_Linux公社-Linux系统门户网站
你好，游客
Hadoop2.4 支持snappy
来源：Linux社区&
作者：bigdatahappy
我们 2.4集群默认不支持snappy压缩，但是最近有业务方说他们的部分数据是snappy压缩的（这部分数据由另外一个集群提供给他们时就是snappy压缩格式的）想迁移到到我们集群上面来进行计算，但是直接运行时报错：
Failed with exception java.io.IOException:java.lang.RuntimeException: native snappy library not available: this version of libhadoop was built without snappy support
根据报错信息显示snappy本地库不可用，同时似乎在编译libhadoop的时候需要特别指定以支持snappy，这一点不同于hadoop1.0，hadoop1.0只需要将snappy的本地库文件往指定目录一拷贝就行，不需要重新编译libhadoop本地库文件。
由于snappy压缩算法压缩比不是很高，虽然在解压缩效率上又一点优势，所以我们集群默认没有支持snappy，我们集群的数据要求是RCFile+Gzip，以下是几种压缩格式在hadoop中的优缺点对比：
参考地址：
目前在Hadoop中用得比较多的有lzo，gzip，snappy，bzip2这4种压缩格式，笔者根据实践经验介绍一下这4种压缩格式的优缺点和应用场景，以便大家在实践中根据实际情况选择不同的压缩格式。
1、gzip压缩
优点：压缩率比较高，而且压缩/解压速度也比较快；hadoop本身支持，在应用中处理gzip格式的文件就和直接处理文本一样；有hadoop native库；大部分linux系统都自带gzip命令，使用方便。
缺点：不支持split。
应用场景：当每个文件压缩之后在130M以内的（1个块大小内），都可以考虑用gzip压缩格式。譬如说一天或者一个小时的日志压缩成一个gzip文件，运行mapreduce程序的时候通过多个gzip文件达到并发。hive程序，streaming程序，和java写的mapreduce程序完全和文本处理一样，压缩之后原来的程序不需要做任何修改。
2、lzo压缩
优点：压缩/解压速度也比较快，合理的压缩率；支持split，是hadoop中最流行的压缩格式；支持hadoop native库；可以在linux系统下安装lzop命令，使用方便。
缺点：压缩率比gzip要低一些；hadoop本身不支持，需要安装；在应用中对lzo格式的文件需要做一些特殊处理（为了支持split需要建索引，还需要指定inputformat为lzo格式）。
应用场景：一个很大的文本文件，压缩之后还大于200M以上的可以考虑，而且单个文件越大，lzo优点越越明显。
3、snappy压缩
优点：高速压缩速度和合理的压缩率；支持hadoop native库。
缺点：不支持split；压缩率比gzip要低；hadoop本身不支持，需要安装；linux系统下没有对应的命令。
应用场景：当mapreduce作业的map输出的数据比较大的时候，作为map到reduce的中间数据的压缩格式；或者作为一个mapreduce作业的输出和另外一个mapreduce作业的输入。
4、bzip2压缩
优点：支持split；具有很高的压缩率，比gzip压缩率都高；hadoop本身支持，但不支持native；在linux系统下自带bzip2命令，使用方便。
缺点：压缩/解压速度慢；不支持native。
应用场景：适合对速度要求不高，但需要较高的压缩率的时候，可以作为mapreduce作业的输出格式；或者输出之后的数据比较大，处理之后的数据需要压缩存档减少磁盘空间并且以后数据用得比较少的情况；或者对单个很大的文本文件想压缩减少存储空间，同时又需要支持split，而且兼容之前的应用程序（即应用程序不需要修改）的情况。
最后用一个表格比较上述4种压缩格式的特征（优缺点）：
4种压缩格式的特征的比较
压缩格式splitnative压缩率速度是否hadoop自带linux命令换成压缩格式后，原来的应用程序是否要修改
是，直接使用
和文本处理一样，不需要修改
否，需要安装
需要建索引，还需要指定输入格式
否，需要安装
和文本处理一样，不需要修改
是，直接使用
和文本处理一样，不需要修改
注意：以上几种压缩算法都是在压缩普通文本的前提下来说的是否支持split，如果是RCFile、Sequence Files等，本身就支持split，经过压缩之后一样是支持split的。
综上，我们hadoop2.4集群要求RCFile+gzip是有一定道理的，首先RCFile格式的文件支持按列存储，同时支持split，而gzip的压缩率比较高，而且压缩/解压速度也比较快，所以RCFile格式的文件经过gzip压缩后既能保证文件能split，还能保证很高???缩/解压速度和压缩比。
以上说了半天题外话，以下来进入主题来说一下怎样在不替换集群本地库文件，不重启hadoop进程，也即在hadoop的客户端就能解决支持snappy压缩的问题的方法：
1、编译snappy本地库，编译之后snappy本地库文件地址：/data0/liangjun/snappy/
参考地址：
2、重新编译libhadoop.so文件，编译时通过-Dsnappy.prefix指定snappy本地库文件地址编译：
mvn clean package -Pdist -Dtar -Pnative -Dsnappy.prefix=/data0/liangjun/snappy/ -DskipTests
注：我测试了一下，通过-Drequire.snappy编译的libhadoop.so也是可行的：
mvn clean package -Pdist,native -DskipTests -Drequire.snappy
3、执行完上面两步之后，最终只需要拿到libhadoop.so和libsnappy.so.1两个文件（只需要这两个文件，其他得经过我测试都过滤掉了），以下是MapReduce和hive的使用snappy压缩的例子：
(1)、MapReduce，将编译好的本地库加到DistributedCache中就可以：
在测试环境的客户端mapred-site.xml文件添加以下两个配置项以支持map端数据的时候按snappy压缩：
&property&& & &name&mapreduce.press&/name&& & &value&true&/value&& & &final&true&/final&& &/property&& &property&& & &name&mapreduce.press.codec&/name&& & &value&org.apache.press.SnappyCodec&/value&& & &final&true&/final&& &/property&
上传libhadoop.so和libhadoop.so到指定hdfs目录/test/snappy/下，通过-files指定文件：
hadoop jar hadoop-mapreduce-examples-2.4.0.jar wordcount -files hdfs://ns1/test/snappy/libhadoop.so,hdfs://ns1/test/snappy/libsnappy.so.1& /test/missdisk/ /test/wordcount
(2)、hive，通过add file指定文件：
hive &add file libhadoop.hive &add file libsnappy.so.1;hive &select count(*) from ct_tmp_
表ct_tmp_objrec的数据是文本文件经过snappy压缩的数据，ct_tmp_objrec存储格式是普通的文本格式。
运行hql之后，发现snappy格式的数据能够正常处理计算了，但是200+M的文件只能由一个map任务处理，既不支持split。
==========================================================
以下部分是就RCFile+snappy的数据是否支持split的测试：
1、创建测试表snappy_test，该表和前面的ct_tmp_objrec列完全相同，只是hive表存储格式换成了RCFile：
CREATE EXTERNAL TABLE `snappy_test`(& `from_id` string,& `to_id` string,& `mention_type` bigint,& `repost_flag` bigint,& `weight` double,& `confidence` double,& `from_uid` string,& `to_object_label` string,& `count` bigint,& `last_modified` string,& `time` string,& `mblog_spam` bigint,& `mblog_simhash` string,& `mblog_dupnum` bigint,& `mblog_attribute` bigint,& `user_quality` bigint,& `user_type` bigint,& `old_weight` double,& `obj_pos` bigint,& `quality` bigint)ROW FORMAT SERDE& 'org.apache.hadoop.hive.serde2.columnar.LazyBinaryColumnarSerDe'STORED AS INPUTFORMAT& 'org.apache.hadoop.hive.ql.io.RCFileInputFormat'OUTPUTFORMAT& 'org.apache.hadoop.hive.ql.io.RCFileOutputFormat'LOCATION& 'hdfs://ns1/user/liangjun/warehouse/tables/snappy_test'
2、将ct_tmp_objrec中plain text+snappy压缩的数据转成snappy_test中RCFile+gzip压缩的数据：
hive &add file libhadoop.hive &add file libsnappy.so.1;hive &set press.output=hive &set pression.codec=org.apache.press.SnappyChive &INSERT OVERWRITE table snappy_test select from_id,to_id,mention_type,repost_flag,weight,confidence,from_uid,to_object_label,count,last_modified,time,mblog_spam,mblog_simhash,mblog_dupnum,mblog_attribute,user_quality,user_type,old_weight,obj_pos,quality from ct_tmp_
3、查询snappy_test中的RCFile+snappy数据看是否能split
hive &add file libhadoop.hive &add file libsnappy.so.1;hive &select count(*) from snappy_
运行hql之后，发现RCFile+snappy的数据能够正常处理计算，同时200+M的文件split成两个map任务处理，测试完成。
Hadoop2.5.2 新特性&
安装和配置Hadoop2.2.0&
13.04上搭建Hadoop环境
Ubuntu 12.10 +Hadoop 1.2.1版本集群配置
Ubuntu上搭建Hadoop环境（单机模式+伪分布模式）
Ubuntu下Hadoop环境的配置
单机版搭建Hadoop环境图文教程详解
搭建Hadoop环境（在Winodws环境下用虚拟机虚拟两个Ubuntu系统进行搭建）
更多Hadoop相关信息见 专题页面
本文永久更新链接地址：
相关资讯 & & &
& (05/06/:21)
& (09/07/:03)
& (08/28/:58)
& (04/23/:58)
& (09/07/:48)
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款
匿名 发表于 2、重新编译libhadoop.so文件，编译时通过-Dsnappy.prefix指定snappy本地库文件地址编译：是在哪里呀React-Native 实现增量热更新的思路(1) - 简书
React-Native 实现增量热更新的思路(1)
所谓热更新就是在不重新安装的前提下进行代码和资源的更新，相信在整个宇宙中还不存在觉得热更新不重要的程序猿。
增量热更新就更牛逼了，只需要把修改过和新增的代码和资源推送给用户下载即可，增量部分的代码和资源都比较小，所以整个热更新流程可以在用户无感的情况下完成，我已经想不到更好的更新方式可以让我装更大的逼了。
一.实现脚本的热更新
1.为什么可以热更新
简单地说，因为RN是使用脚本语言来编写的，所谓脚本语言就是不需要编译就可以运行的语言，也就是“即读即运行”。我们在“读”之前将之替换成新版本的脚本，运行时执行的便是新的逻辑了，稍微抽象一下，图片资源是不是也是“即读即运行”？所以脚本本质上和图片资源一样，都是可以进行热更新的。
2.RN加载脚本的机制
要实现RN的脚本热更新，我们要搞明白RN是如何去加载脚本的。在编写业务逻辑的时候，我们会有许多个js文件，打包的时候RN会将这些个js文件打包成一个叫index.android.bundle(ios的是index.ios.bundle)的文件，所有的js代码(包括rn源代码、第三方库、业务逻辑的代码)都在这一个文件里，启动App时会第一时间加载bundle文件，所以脚本热更新要做的事情就是替换掉这个bundle文件。
3.生成bundle文件
我们在RN项目根目执行以下命令来得到bundle文件和图片资源:
react-native bundle --entry-file index.android.js --bundle-output ./bundle/index.android.bundle --platform android --assets-dest ./bundle --dev false
其中--entry是入口js文件，android系统就是index.android.js，ios系统就是index.ios.js，--bundle-output就是生成的bundle文件路径，--platform是平台，--assets-dest是图片资源的输出目录，这个在后面的图片增量更新中会用到，--dev表示是否是开发版本，打正式版的安装包时我们将其赋值为false。生成的bundle文件体积还是不小的，空项目的话恐怕至少也有900K，所以我们将其打成zip包并放到web服务器上以供客户端去下载。
4.下载bundle文件
下载文件可以使用原生语言来写，也可以使用js实现，我个人推荐使用来实现下载功能。实现方法很简单：
import FileTransfer from 'react-native-file-transfer';
let fileTransfer = new FileTransfer();
fileTransfer.onprogress = (progress) =& {
console.log(parseInt(progress.loaded * 100 / progress.total))
// url：新版本bundle的zip的url地址
// bundlePath：存在新版本bundle的路径
// unzipJSZipFile：下载完成后执行的回调方法，这里是解压缩zip
fileTransfer.download(url, bundlePath, unzipJSZipFile, (err) =& {
console.log(err);
解压缩的工作我们可以使用来完成。
import Zip from 'react-native-zip';
function unzipJSZipFile() {
// zipPath：zip的路径
// documentPath：解压到的目录
Zip.unzip(zipPath, documentPath, (err)=&{
if (err) {
// 解压失败
// 解压成功，将zip删除
fs.unlink(zipPath).then(() =& {
// 通过解压得到的补丁文件生成最新版的jsBundle
解压成功后，我们使用来将zip删除。
5.替换bundle文件
安装包中的bundle文件是在asset目录下的，而asset目录我们是没有写权限的，所以我们不能修改安装包中的bundle文件。好在RN中提供了修改读取bundle路径的方法。以android为例(ios的类似)，在ReactActivity类中有这么一个方法：
* Returns a custom path of the bundle file. This is used in cases the bundle should be loaded
* from a custom path. By default it is loaded from Android assets, from a path specified
* by {@link getBundleAssetName}.
* e.g. "file://sdcard/myapp_cache/index.android.bundle"
protected @Nullable String getJSBundleFile() {
该方法返回了一个自定义的bundle文件路径，如果返回默认值null，RN会读取asset里的bundle。我们在MainActivity类中重写这个方法，返回可写目录一下的bundle文件路径：
protected @Nullable String getJSBundleFile() {
String jsBundleFile = getFilesDir().getAbsolutePath() + "/index.android.bundle";
File file = new File(jsBundleFile);
return file != null && file.exists() ? jsBundleFile :
如果可写目录下没有bundle文件，还是返回null，RN依然读取的是asset中的bundle，如果可写目录下存在bundle，RN就会读取可写目录下的bundle文件。
我们将下载好的zip解压到getFilesDir().getAbsolutePath()目录下，再次启动App时便会读取该目录下的bundle文件了，以后再有新版本的bundle文件，依然是下载、解压并覆盖掉这个bundler文件，至此，我们便完成了代码的热更新工作。
6.图片不见了
当我们使用可写目录下的bundle文件时会出现一个很严重的问题：所有的本地图片资源都无法显示了。
我们的图片资源都是通过require来获取的：
&Image source={require('./imgs/test.png')} /&
为了找到图片消失的原因，我们打开image.android.js或者image.ios.js，找到渲染图片的方法：
render: function() {
var source = resolveAssetSource(this.props.source);
var loadingIndicatorSource = resolveAssetSource(this.props.loadingIndicatorSource);
原来是通过resolveAssetSource方法来获取资源，那么找到resolveAssetSource方法：
function resolveAssetSource(source: any): ?ResolvedAssetSource {
if (typeof source === 'object') {
var asset = AssetRegistry.getAssetByID(source);
if (asset) {
return assetToImageSource(asset);
function assetToImageSource(asset): ResolvedAssetSource {
var devServerURL = getDevServerURL();
__packager_asset: true,
width: asset.width,
height: asset.height,
uri: devServerURL ? getPathOnDevserver(devServerURL, asset) : getPathInArchive(asset),
scale: pickScale(asset.scales, PixelRatio.get()),
又发现是通过getPathInArchive方法来获取资源的，那么继续找到getPathInArchive方法：
* Returns the path at which the asset can be found in the archive
function getPathInArchive(asset) {
var offlinePath = getOfflinePath();
if (Platform.OS === 'android') {
if (offlinePath) {
// E.g. 'file:///sdcard/AwesomeModule/drawable-mdpi/icon.png'
return 'file://' + offlinePath + getAssetPathInDrawableFolder(asset);
// E.g. 'assets_awesomemodule_icon'
// The Android resource system picks the correct scale.
return assetPathUtils.getAndroidResourceIdentifier(asset);
// E.g. '/assets/AwesomeModule/icon@2x.png'
return offlinePath + getScaledAssetPath(asset);
该方法的逻辑是如果有离线脚本，那么就从该脚本所在目录里寻找图片资源，否则就从asset中读取图片资源，所谓离线脚本就是我们刚刚下载并解压的bundle文件，而我们并没有将图片资源放在这个目录下，所以所有的图片都不见了。找到原因就好办了，我们在使用bundle命令生成bundle文件的时候也将图片资源输出出来了，那打包bundle文件的时候我们将所有图片也一并打包进zip，客户端下载zip并解压缩后，客户端可写目录下也就有了所有的图片资源，这样就即实现了脚本的热更新又实现了图片的热更新。
二.减小更新包体积
将一个完整bundle文件和所有图片都打成zip，zip的体积让人不敢直视。
1.增量更新图片
每一次的版本更新我们都将所有图片装进zip包未免有点太任性了，其实我们只需要将修改过和新增的图片资源放进zip就行了。我们修改一下获取图片资源的方法里的逻辑：
* Returns the path at which the asset can be found in the archive
function getPathInArchive(asset) {
var offlinePath = getOfflinePath();
if (Platform.OS === 'android') {
if (offlinePath) {
// 热更新修改
if(global.patchList){
let picName = `${asset.name}.${asset.type}`;
for (let i = 0; i & global.patchList. i++) {
if(global.patchList[i].endsWith(picName)){
return 'file://' + offlinePath + getAssetPathInDrawableFolder(asset);
// 热更新修改
// E.g. 'file:///sdcard/AwesomeModule/drawable-mdpi/icon.png'
// return 'file://' + offlinePath + getAssetPathInDrawableFolder(asset);
// E.g. 'assets_awesomemodule_icon'
// The Android resource system picks the correct scale.
return assetPathUtils.getAndroidResourceIdentifier(asset);
// E.g. '/assets/AwesomeModule/icon@2x.png'
return offlinePath + getScaledAssetPath(asset);
其中global.patchList是一个数组，里面放的是自安装包版本以来所有修改过和新增的图片名，如果访问的图片名在这个数组中就从离线脚本所在目录里寻找图片资源，否则还是从asset中寻找图片资源。我们在打包zip的时候，就只装修改过和新增的图片，并将这些图片名记录在更新配置文件里，客户端去读取更新配置文件时将配置中的图片名读取到并生成global.patchList，这样我们的更新包就小了许多了。这么做的缺点就是每次更新RN版本的时候，都需要修改下RN的源码，不过我觉得这点小麻烦还是可以接受的，毕竟已上线的产品，我们还是以稳定为主，能不升级RN就不升级RN。
2.增量更新脚本
bundle文件的体积，我们也得想想办法去减少它。有两种思路：
分离bundle。bundle里存放了RN源码、第三方库代码和业务逻辑代码，其中频繁更新的就只有业务逻辑代码，所以我们将RN源码和第三方库代码打包成一个bundle，业务逻辑打包成一个bundle，热更新的时候就只更新业务逻辑的bundle即可。
打包补丁文件。我们可以使用对比两个版本的bundle文件得到差异文件，也就是“补丁”，客户端下载好补丁文件，将其与本地的bundle进行融合从而得到最新版本的bundle文件。
这里重点讲解第二个思路的做法。
1) 生成补丁。
我们从上下载到最新的源码，然后进行编译就得到可执行的二进制文件了。
如果是win系统，可以直接到我的下载，下载密码：zq1x。解压下载好的zip，使用命令行进入到bsdiff的目录，输入命令：
bsdiff a.txt b.txt c.pat
上面的命令就是生成a.txt、b.txt两个文件的补丁c.pat。
如果是linux系统，可以依次执行以下命令:
yum install bzip2-devel
wget http://www.daemonology.net/bsdiff/bsdiff-4.3.tar.gz
tar zxvf bsdiff-4.3.tar.gz
cd bsdiff-4.3
编译完成后，会在目录下生成2个二进制文件：bsdiff、bspatch，这2个二进制文件可以直接使用，不过推荐拷贝到/usr/local/sbin/下：
cp bsdiff /usr/local/sbin/
cp bspatch /usr/local/sbin/
这样就可以在命令行中直接使用了:
bsdiff a.txt b.txt c.pat
2) 使用补丁。得到了补丁文件，下一步就会使用补丁了，拿上面的a.txt、b.txt、c.pat做测试：
bspatch a.txt d.txt c.pat
得到文件d.txt，将其开打看看是否和b.txt一样，如果一样，说明测试成功。
3) 在RN中使用bsdiff。待续。。。
三.制作一键热更新工具
待续。。。拒绝访问 | www. | 百度云加速
请打开cookies.
此网站 (www.) 的管理员禁止了您的访问。原因是您的访问包含了非浏览器特征(37f9c5cbf0676610-ua98).
重新安装浏览器，或使用别的浏览器博客访问： 114938
博文数量： 467
博客积分： 0
博客等级： 民兵
技术积分： 10
注册时间：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： C/C++
原文地址： 作者：
JPEG是Joint Photographic Experts Group(联合图像专家组)的缩写，文件后辍名为".jpg"或".jpeg"，是网上比较常见的图像文件格式，以小尺寸著称，但其最大的缺点是它是一种有损压缩的图像格式，能够将图像压缩在很小的储存空间，图像中重复或不重要的资料会被丢失，因此容易造成图像数据的损伤。尤其是使用过高的压缩比例，将使最终解压缩后恢复的图像质量明显降低，如果追求高品质图像，不宜采用过高压缩比例。但是JPEG压缩技术十分先进，它用有损压缩方式去除冗余的图像数据，在获得极高的压缩率的同时能展现十分丰富生动的图像，换句话说，就是可以用最少的磁盘空间得到较好的图像品质。JPEG2000作为JPEG的升级版，其压缩率比JPEG高约30％左右，同时支持有损和无损压缩。JPEG2000格式有一个极其重要的特征在于它能实现渐进传输，即先传输图像的轮廓，然后逐步传输数据，不断提高图像质量，让图像由朦胧到清晰显示。此外，JPEG2000还支持所谓的"感兴趣区域" 特性，可以任意指定影像上感兴趣区域的压缩质量，还可以选择指定的部分先解压缩。本文只讨论JPEG的编码及解码，不包括JPEG2000，如果大家兴趣，可以网上找一些资料。JPEG官方网站（http://www.jpeg.org）并不负责JPEG文件编码及解码的实现，只是制定标准，呵呵，应了那句话：一流的厂商订标准。JPEG的源码请从IJG（Independent JPEG Group，独立JPEG小组）的网站：http://www.ijg.org/下载，如果是支持tar及gz格式的下：http://www.ijg.org/files/jpegsrc.v6b.tar.gz，如果是Windows请下Zip格式：ftp://ftp.simtel.net/pub/simtelnet/msdos/graphics/jpegsr6.zip。下完后，解压之，得一目录：jpeg-6b，参见目录下的文件 jversion.h，发现JPEG库的版本是：6b 27-Mar-1998，可见此库是多么的古老与稳定，10多年前的东西了！下完解完之后第一步，老规矩，先改makefile，将makefile.ansi复制一份，改名为 makefile，并改动如下行:#09：CC= arm-none-linux-gnueabi-gcc将gcc编译器改成 android arm的。#12：CFLAGS= -O2优化代码，据说 -O2（注意是字母“O”，不是数字“0”）在尺寸及效率上比较好。#17：LDFLAGS= -s -staticAndroid Native必加链接参数 -static，-s 是将小库尺寸，去除调试信息。#33：AR= arm-none-linux-gnueabi-ar rc#35：AR2= arm-none-linux-gnueabi-ranlib将AR及AR2库打包程序换成Android Native的。试下在Cygwin下输入：make呵呵，太心急了，得到提示如下：You must prepare a system-dependent jconfig.h file.Please read the installation directions in install.doc.就是说 jconfig.h 不存在，我们要准备一个才能编译。找了一遍没打到适合Unix/Linux的，就直接打开 jconfig.doc，将所有内容copy出来，存成了 jconfig.h，因为里面的很详细的宏定义介绍。当然你可以将所有的宏定义都打开，再一个一个试，哪个出了问题就取消哪个。再输入：make一切OK，得到了库文件：libjpeg.a及 Andorid Native 可执行文件：cjpeg, djpeg, jpegtran, rdjpgcom, wrjpgcom。看名字就知道cjpeg应该就是一个jpeg文件的compressor（压缩器），将其他文件压缩成jpeg格式，djpeg肯定就是解压缩的了，传到 Android Emulator试下！（其中“&”为普通命令提示符，“#”为模拟器命令提示符）&adb push cjpeg /dev/sample/cjpeg&adb push testimg.bmp /dev/sample/testimg.bmp&adb shell#cd /dev/sample#chmod 777 cjpeg#./cjpeg -quality 90 -outfile testimg.jpg testimg.bmp#exit&adb pull /dev/sample/testimg.jpg testimg.jpg将cjpeg及测试图片 testimg.bmp push到模拟器，再执行cjpeg得到压缩图片 testimg.jpg，发现高质量（quality = 90）jpg格式图片的大小是bmp格式图片的 25%左右。有兴趣的朋友也可以试下djpeg及其他测试程序。如下是通过 Android 模拟器压缩出来的jpg文件。
阅读(205) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。}