图片格式压缩

记录,避免自己忘记

1、http://bellard.org/bpg/ bgp压缩格式。

2、https://github.com/nagadomi/waifu2x  相关文章:http://blog.codingnow.com/2015/05/rgbyuv.html#more

3、WebP google家的图片压缩算法,facebook也在使用

 

协议压缩:

1、https://code.google.com/p/snappy/  可以考虑下这个。另外如果想要最优,可以考虑比较下各种压缩算法在实际项目中使用的效果。

今天查找unity中加载配置表卡的问题

我们游戏中第一次运行中,会下载配置表并进行加载。

但是我们发现一个现象:

第一次下载后,会在加载那里卡5秒左右。而以后再也不会遇到相同的卡的状况。

花了些时间发现了原因是c#代码导致的。

我们配置表使用csv,第一次下载后通过www类可以拿到下载的byte[],想避免一次IO操作,就使用c#写了解析为字符串数组的代码。

而非第一次下载,则使用File.ReadAllLine直接从文件中读取。

原来写时,以为能避免一次IO操作,可以提高性能,这里不能不说,C#自带的函数(底层使用c/c++实现),要远比c#的代码速度快的多。

也有可能是我写的C#代码太烂了的原因。

烂代码大家可以了解下:就是被注释掉的代码引导的卡。

string[] allDatas = null;

 	 	/*
        if (doneList != null)
        {
            for (int m = 0; m < doneList.Count; m++)
            {
                ConfigFile cf = doneList[m];
                if (cf.configName.Equals(configName+".bin"))
                {
					Debug.Log("Time1 :"+Time.realtimeSinceStartup);
                    StringReader sr = new StringReader(UTF8Encoding.UTF8.GetString(cf.content));
                    List<string> list = new List<string>();
                    string str = null;
                    while ((str = sr.ReadLine()) != null)
                    {
                        list.Add(str);
                    }
					Debug.Log("Time2:"+Time.realtimeSinceStartup);
                    allDatas = list.ToArray();
					Debug.Log("Time3:"+Time.realtimeSinceStartup+" "+configName+" "+list.Count);
                    break;
                }
            }
        }
        */
        if (allDatas == null)
        {
            string path = PathMgr.Config_Path + configName + ".bin";
            allDatas = File.ReadAllLines(path);
        }

游戏中数据包的压缩

我们游戏中数据包比较大时,就使用7z进行压缩后,再传给客户端。

最近压力测试时,发现一个坑,查了几天,才定位是使用的7z库的问题。

java中没有官方的7z库,也没有开源组织维护,只有一个作者自己写的7z库,最初没发现问题。

这次查看7z的源码,发现里面每次压缩时会分配16M内存,大量的分配释放内存导致整个jvm都被卡了。

没办法改为gzip库,来避免掉了这种问题。

关于压缩实际还有很多潜力可以挖掘。

1、比如:压缩解压每个数据块中有crc32校验,我们游戏中使用,可以直接去掉这部分计算。

2、比如:既然不使用crc32校验证,那crc32占用的那几个字节就可以省掉。

3、比如:既然前后端都知道使用相同的压缩算法,就可以把压缩文件的格式文件头去掉。

4、比如:每次压缩解压都会申请byte[],我们可以使用threadlocal复用byte[],来减少byte[]的分配。

 

 

protobuf使用遇到一个坑

项目压力测试,发现一个协议非常卡,吞吐量不足100/s,查看那个协议,发现是在玩家登陆成功后取玩家数据。

这个protobuf结构体 A 中定义了接近300个属性。

专门测试了一下,生成100000个对象,属性全不设置使用默认值,A结构体序列化是仅有几个属性的40倍消耗。

这个地方是我们之前没有想到的情况,不过这还不足已是瓶项的原因。

再继续确认,发现A里面有一个list,list中存放了271个B结构体。大约40%的时间都消耗在这里了。

基本上以下是我们之前未发现的:

1、protobuf属性多了会导致性能下载,既然属性值使用optional,而且不设置值。属性尽量控制在比较少的范围内。

2、属性多了后,感觉性能消耗是几何数级增加。

针对我们项目目前的情况,A结构体进行拆分不太可能,所以只把其中几个数量多的list拆分出来。把上面的271个使用另外一个协议发送,每次发送一条,总共发送271条。可能会感觉271条协议比一个协议要慢,实际上发现,这样做了后,问题顺利解决,271条比1条消耗的时间要小2个数量级,可能protobuf天生只适合小数据包的情况。

记一次排查内存泄露

今天一台java帐号服上报了outofmemory,这种错误出现,大多数情况都是有内存泄露导致的。

看程序运行目录下自动生成了 java_pid32123.hprof 文件。这是java自动dump出来的文件,里面记录了内存不足时的内存信息。

可以用jhat打开hprof文件。

耗时会比较长,耐心等待。

上面的7000,是指打开了一个http 7000端口,我们可以通过浏览器进行查看。

通过浏览器打开后,拉到最后面:

点击show instance counts for all classes

看到最上面几行,基本上就可以确认了SocketRunner出现了内存泄露。

生成了大量socketrunner,导致无法及时处理,最终耗尽了所有内存。

svn批量处理

批量添加文件至svn

svn update | awk ‘{if($1 == “?”){print $2}}’ | xargs svn add

svn commit

 

批量解决 : Node remains in conflict

svn resolve –accept theirs-full .
svn update | awk ‘{if($1 == “Skipped”){print $2}}’ | xargs svn resolved
svn update
svn resolve –accept theirs-full .

nginx proxy造成大量wait timeout连接

nginx使用的是1.4.5,发现产生了大量wait timeout,网上搜索得知需要指定为http 1.1及keepalive可大量减少wait-timeout连接。

修改配置添加keepalive字段到upstream。

<span class="line-number">1</span>
<span class="line-number">2</span>
<span class="line-number">3</span>
<span class="line-number">4</span>
<span class="line-number">5</span>
<code class=""><span class="line">upstream backend_abc {
</span><span class="line">    server   192.168.1.34:8086 weight=1 max_fails=2 fail_timeout=10s;
</span><span class="line">    server   192.168.1.77:8086 weight=1 max_fails=2 fail_timeout=10s;
</span><span class="line">    keepalive 16;
</span><span class="line">}</span></code>

同时修改配置添加http1.1声明和header中connection重写。

<span class="line-number">1</span>
<span class="line-number">2</span>
<span class="line-number">3</span>
<span class="line-number">4</span>
<span class="line-number">5</span>
<span class="line-number">6</span>
<span class="line-number">7</span>
<span class="line-number">8</span>
<span class="line-number">9</span>
<span class="line-number">10</span>
<span class="line-number">11</span>
<span class="line-number">12</span>
<code class=""><span class="line">server {
</span><span class="line">        listen       80;
</span><span class="line">        ....
</span><span class="line">  location / {
</span><span class="line">            proxy_pass         http://backend_abc;
</span><span class="line">            proxy_http_version 1.1;
</span><span class="line">            proxy_redirect     off;
</span><span class="line">            proxy_set_header Connection "";
</span><span class="line">            ....
</span><span class="line">  }
</span>
<span class="line">    }</span></code>

android隐藏标题栏与状态栏

requestWindowFeature(Window.FEATURE_NO_TITLE);    // 隐藏标题栏
getWindow().addFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN);  // 隐藏状态栏

上面两行注意要在setContent之前调用。

Required plug-in compatibility UUID not present in DVTPlugInCompatibilityUUIDs

上周五升级了xcode,结果打包时失败,提示错误:

2015-04-11 17:09:54.827 xcodebuild[49636:2989038] [MT] PluginLoading: Required plug-in compatibility UUID 9F75337B-21B4-4ADC-B558-F9CADF7073A7 for plug-in at path ‘~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/Unity4XC.xcplugin’ not present in DVTPlugInCompatibilityUUIDs

今天看了下,应该是因为升级导致插件的uuid对应不上。

以下脚本修复这个问题。

XCODEUUID=`defaults read /Applications/Xcode.app/Contents/Info DVTPlugInCompatibilityUUID`
for f in ~/Library/Application\ Support/Developer/Shared/Xcode/Plug-ins/*; do defaults write "$f/Contents/Info" DVTPlugInCompatibilityUUIDs -array-add $XCODEUUID; done

参考:

http://stackoverflow.com/questions/20732327/xcode-5-required-plug-in-not-present-in-dvtplugincompatibilityuuids

ipa如何确认是否为64位

打出的ipa包,实际是使用的zip格式。
在mac os下可以使用unzip直接进行解压
unzip Unity-iPhone4444.ipa
会在当前目录下生成Payload目录,
进入Payload目录
使用命令lipo来查看,通过ipa中的可执行文件放在     xiyouxiangmopian.app/xiyouxiangmopian
输出 arm64表示已经是64位包
localhost:Payload sanx$ lipo -info xiyouxiangmopian.app/xiyouxiangmopian
Architectures in the fat file: xiyouxiangmopian.app/xiyouxiangmopian are: armv7 arm64
localhost:Payload sanx$