Blog site moved to new place…

As wordpress is blocked by the Wall in China, now my new blog posts currently are written in Zhihu Column: 技术宅

由于众所周知的原因，中国内地无法访问wordpress站点，目前本博客新增内容转到知乎专栏 技术宅

Advertisements

Has your iOS app been “stripped”?

各位iOS开发同学们，你们打出来的iOS的ipa包真的已经不能再小了么？如果你也像题图一样，.ipa文件比AppStore上显示的大小相差太多，那你应该对我说的有兴趣。
以下是从一个QA的角度作出的从发现问题到解决问题的整个详细历程，对ObjC的编译连接方式可能理解是错误的，还请各位ObjC大牛指正。文章较长，我尽量讲得更清楚些。为了防止大家对这种长文直接放弃，我先上一个优化前后对比结果图:

对比结果

以阿里旅行5.2.0发布到Appstore的版本为例，对比结果如下：

对比	优化前	优化后	减少了
二进制文件大小	46.6M	31.7M	14.9M
.ipa文件大小（本身就是zip格式）	25.2M	22.3M	2.9M
手机“用量”中显示的大小	57.2M	43.0M	14.2M

注：前两项大小都是Mac OS X 10.10中，通过命令行ls命令查询得到
如果你还是没兴趣看长篇大论，直接看最后“我找到的优化方法”那段就行。

为什么苹果商店包与我们产出的ipa大小有差别

为了方便大家理解，先对Xcode生成的各种包进行说明：

iOS的各种结果文件：

1) .app

iOS编译以后生成的原始文件，实际是一个文件夹，里面包含各种资源文件（图片，第三方bundle，plist等文件），程序的可执行文件(二进制格式)以及对所有文件的签名记录（_CodeSignature）
不能上传AppStore

2) .dSYM

生成.app时的附属产物。本质是一个文件夹，其中只有一个最大的文件，作用是对iOS程序闪退后产生的log文件进行符号化（desymbolicate）；通俗的说，就是把无意义的内存地址变成可读的程序中的类和方法以及代码行数
不能上传AppStore

3) .ipa

实际上就是把.app放到Payload文件夹后，对Payload就行了zip操作，最后改了下扩展名。
可通过Application Loader上传AppStore

4) .xcarchive

实际上也是一个文件夹，包含.ipa和.dSYM文件
可通过Xcode上传AppStore

原因

由于上传AppStore速度很慢，我们一般选择上传.ipa文件到AppStore。那为什么从苹果商店看到的包大小和我们的.ipa大小不一致呢。下面是苹果官方的说法(注意黑体字，后面会用到)：

When your application is approved by Apple to sell on the App Store, it is encrypted for DRM purposes and re-compressed. When the encryption is added, the size of the compressed file will increase. The exact size of the increase will vary from app to app, however, the size increase can be large when the binary contains a lot of contiguous zeros. We are unable to guarantee the size of your file after the encryption has been added.

也就是说，苹果获取上传的ipa文件后，进行解压缩成.app，然后对其中二进制文件进行Apple FairPlay DRM加密，最后重新压缩成.ipa，此时生成的.ipa作为AppStore上的显示程序的大小。

分析

回到我们阿里旅行的包：我们v5.1.1生成的.ipa文件是23.9M左右，而苹果商店上显示的是36.9M
为什么会有这么大差距呢，我们来看看我们的二进制文件AliTrip的前后大小对比：
adding: Payload/Alitrip.app/AliTrip …. (in=42806208) (out=14899495) (deflated 65%)
上面是打包机使用PackageApplication对.app进行压缩成zip（即ipa）时的日志。可以看到我们的二进制文件高达42.8M，经过zip压缩后变为14.8M左右，缩小了65%的体积。
为什么我们的文件压缩比率可以这么高呢。我们使用Sublime Text打开此文件就会发现，果不其然！连续的0数都数不过来。

大胆的猜想

• 因为是重复的0，在被zip压缩时可以直接写作“n个0”来保存，所以压缩比率很高；
• 而在进行DRM加密时，这些重复的0生成了非0字段，再进行压缩时，压缩比上不去了

验证

以上猜想可以通过iTunes下载ipa文件来看：
通过iTunes下载阿里旅行，找到下载到的ipa文件，解压缩后，对其中的Payload文件夹中进行zip压缩，发现二进制的压缩比与之前相比，已经下降了30%：
adding: Payload/Alitrip.app/AliTrip (deflated 35%)
从42806064压缩到27654347
所以DRM操作是导致.ipa文件变大的原因

解决思路

我们现在要做的就是如果减少和消除我们二进制文件中多出的哪些连续的0：

• 从Xcode编译阶段着手，研究连续的0产生的原因
  • 从生成的二进制文件着手，删除多余的0
  • 删除是可行的，但是上面提到，.app里面会对生成的文件进行签名，如果我们修改了二进制文件，签名就失效了。修改过得ipa文件不能通过苹果审核

我找到的优化方法

对与iOS的编译和连接等操作我完全是门外汉，经过几天的搜索整理，我找到的突破口就是 Strip 。strip从字面意思上其实就是“脱光”的意思（嗯，点题了…），也就是把生成的 对象文件 (.o文件)中不必要的 符号（symbols）去掉的意思。所以从Xcode的Strip相关配置下手进行优化。以上是我对strip的理解，可能不完全对，望大家指正。
在Xcode项目的Build Settings中，搜索Strip：我们可以看到，程序默认做了一些配置，相关strip选项解释如下(BuildSettings所有选项的官方点这里)。

选项	意义
Deployment Postprocessing	strip所有选项的总开关，如果选NO，以下选项均无效
Strip Debug Symbols During Copy	文件拷贝编译阶段时是否进行strip，你的工程中有CopyFilesBuildPhase才有意义
Strip Linked Product	这个选项才对最后生成的二进制文件进行strip
Strip Style	all，non-global，debugging strip程度依次降低：all一般用于最后生成.app的工程；non-global用于bundle和framework，debugging一般都可以。虽然all是strip最多的选项，但是选择错误会导致strip失败
Dead Code Stripping	用于删除对象文件中不需要加载的符号，减小二进制文件大小

这是阿里旅行其中两个工程的strip设置截图（其中 粗体 是优化过的选项）：

• Portal工程是生成.app的工程：
  
• CommonUI是其中一个底层framework工程：
  

可以看到阿里旅行的strip设置基本正确，但是最关键的strip总开关Deployment Postprocessing没有打开。然后就是Strip Style对线上包的strip程度不够（framework工程只选择了debugging级别，改为non-global）
这个strip总开关在Xcode的Release配置中本身也是默认关闭的，需要我们手动打开。另外其实strip除了降低app大小外，一定程度上提高了从app获得更多信息的难度，安全性更佳。
以上strip优化只针对内测包和商店包。

结论与思考

由于iOS工程的线上配置中使用了Xcode的默认设置，导致没有开启strip开关，最后生成的二进制文件偏大。
由于我对ObjectiveC编译、连接的实现完全不理解，我这种方式不一定是最优化的选择；也可能除了strip外，BuildSetting还有其他的优化方式。在此抛砖引玉，欢迎大家讨论。
最后，这种处理后会不会对我们crash日志解析产生影响，还需要开发同学来确认下。优化过的app可以正常运行，我已经试验过了。​

Jenkins Clang Scan-Build Plugin support for Xcode5 and later

The Jenkins Clang Scan-Build Plugin have not been updated for years. I fixed existing bugs to make it usable in Xcode 5,6 and latest clang-static-analyzer. I have published on Github, you could check out for more details.

Fixed Bugs:

• Fix “404 not found” bug when click “Details” in scan-build bug report
• Fix incorrect logic of finding xcode workspace
• added default argument for scan-build and xcodebuild additional arguments
  • added --use-analyzer Xcode in scan-build additional arguments: this would make scan-build use clang executable from Xcode instead of its own
  • added -derivedDataPath $WORKSPACE/build in xcodebuild additional arguments: this will save build products and other derived data to ‘build’ directory under current worksapce

How to use:

• git clone https://github.com/truebit/clang-scanbuild-plugin.git
• cd clang-scanbuild-plugin
• mvn clean package -Dmaven.test.skip=true
• find clang-scanbuild-plugin.hpi in target directory
• upload this .hpi file via "Manage Plugins">"Advanced">"Upload Plugin"
• restart Jenkins to update the plugin

Setting in Jenkins job:

• Add build step “Clang Scan-Build”, example below:
• As above image displays, you can leave workspace empty, thus the plugin would search workspace location in Xcode project directory ( a.k.a the jenkins workspace directory plus “Xcode project sub-path”)
• Add post-build action: “Publish Clang Scan-Build Results”

Any concerns, you could fire an issue 🙂

xUnique – Xcode project file merge with no conflicts

Introduction

---

If you are an Objective C developer using Xcode, and push your code to Git/SVN like other guys did in the team, I think you most probably have encountered the merge conflicts of project.pbxproj file.

It’s such a pain to merge this file by searching the file with <<<,>>> and ===, and then deleting and keeping lines by your judge. It would leave some unused lines or even make Xcode build fail due to wrong decision.

Since UUID generated by Xcode in project.pbxproj file is not unique for all machines, different Xcode got different UUID for the same file or filegroup. That’s why it created conflicts.

xUnique

---

I just found that Xcode does not care the UUID in the file, it just needs to be unique in the file. So I made xUnique to fix the merge conflicts issue.

How it works

• All elements in project file are actually connected as a tree
• We give a path to every node of the tree using its unique attribute; this path is the absolute path to the root node connected by these attributes
• Apply MD5 hex digest to the path for the node
• these digests are the new UUIDs in the project file
• Sort project file using my pure Python implementation of my modified sort-Xcode-project-file, supports following new features:
  • sort PBXFileReference and PBXBuildFile sections
  • avoid modified changes in Git/SVN if no change made in the project file

How to use

1. Put xUnique.py file in your project repository somewhere and add it as track file via git add path/to/xUnique.py, so all members could use the same script
2. create a git hook: ln -s path/to/xUnique.py .git/hooks/pre-push
3. Add permission chmod 555 .git/hooks/pre-push
   • use hook pre-push instead of pre-commit is a safe consideration: you decide to commit the newly generated project file or not
4. In all your branches, uniquify project.pbxproj file in either way:
   • make some changes and commit. Try to push, git hook would be triggered
   • manually run script: python path/to/xUnique.py path/to/MyProject.xcodeproj and then committing changes.
5. All Done;)

Notice

---

• 中文版 is here
• Check Github homepage for more details and updates

Python bottle support for JSONP

最近用bottle写后台api接口，返回的都是json格式。后来写前端的同学说不能解析json，然后搜了下终于知道有JSONP这个东东，然后知道jsonp的格式原来就是一个callback函数名称xxx（请求中带有callback=xxx）包着一个json数据的方法的形式。其实JSONP只是用来跨域通信用的，虽然现在的需求不需要用jsonp，不过某同学没有研究出来js里面怎么直接获得同一域JSON数据，所以我还是折腾了一下。挺好，又学到些东西:P

直接上代码：如果使用的是default_app，则直接把下面代码贴进对应的py文件中就ok了

from bottle import response, request, install
def jsonp(callback):
    def wrapper(*args, **kwargs):
        resp = callback(*args, **kwargs)
        if isinstance(resp, (dict,list)):
            #response.charset='utf-8' # set property error , do not know why
            response.content_type = 'application/json;utf-8' # after added this line, we do not need to mess with character encoding in json.dumps; the commented out code is what i did before
            callback_arg = request.query.get('callback')
            if callback_arg:
                resp= '{}({})'.format(callback_arg, json.dumps(resp))#,ensure_ascii=False))#.encode('utf-8')
        return resp
    return wrapper

install(jsonp) # install the plugin in the bottle app

另外就是发现，处理jsonp为这样的字符串以后，返回的结果数据的中文直接显示为unicode的字符串形式(\uxxxx形式)。解决方法：

• 最开始我是让json模块dumps处理的字符串进行解码，然后encode成utf-8，这样输出就正常了（代码见被注释掉的倒数第五行）
• 后来发现只需要对返回的内容格式content-type限定为json和utf-8，就自动解析正常了（代码见倒数第八行）

Python Bottle+virtualenv+uWSGI+Nginx installation on Ubuntu 12.04.1 LTS

为了造福世界人民，我觉得还是用英语写吧 XD

Today I got a request to write a backend server to provide interface access from frontend. I determined to use Python and  RESTful api firstly . I hate writing Java code…

After some investigation, I picked up Bottle. It is very neat and small. And I also read that with nginx and uWSGI, the performance is good too.

My environment is Ubuntu 12.04.1 LTS; but after followed several posts, my environment still did not work. I want to share my findings to save others’ time:)

Let’s cut to the chase:

• Note:

My application would be in below directory constructure, all following commands and configurations are based on below:
/var/www/myapp would be the root directory of my bottle app
/var/www/myapp/env would be the virtualenv for the app
/var/www/myapp/index.py would be main .py file of bottle

• Install nginx and uwsgi:

sudo apt-get update
sudo apt-get install -y nginx uwsgi
sudo apt-get install uwsgi-plugin-python

• Install pip to help install python modules

sudo apt-get install python-pip

• Install virtualenv: virtualenv to seperate the Python environment for different deployments

sudo pip install virtualenv

• Set up app virtualenv:

sudo mkdir -p /var/www/myapp
sudo virtualenv /var/www/myapp/env
source /var/www/myapp/env/bin/activate
pip install bottle
deactivate

• Change the permission of the app directory so that uWSGI can read it and Python can write in it

sudo chown -R www-data:www-data /var/www/myapp

• OK, the most important part: the configuration of nginx and uWSGI. These two recipes would worth some money XD

1. nginx config:

sudo gedit /etc/nginx/sites-enabled/default

copy below config in opend file:

server {

     listen   80;
     charset utf-8;
     root /var/www/myapp;
     server_name localhost;

location / {
     include uwsgi_params;
     uwsgi_pass unix:/tmp/uwsgi.myapp.socket;
     uwsgi_param UWSGI_PYHOME /var/www/myapp/env;
     uwsgi_param UWSGI_CHIDIR /var/www/myapp;
     uwsgi_param UWSGI_SCRIPT index; # this should be the .py file name without suffix that your bottle will use to launch
     }
}

2.uWSGI config:

sudo gedit /etc/uwsgi/apps-enabled/uwsgi.ini

copy below config in opend file:

[uwsgi]
plugins=python
socket=/tmp/uwsgi.myapp.socket
pythonpath=/var/www/myapp

• Now we are one step to success. In order to verify the setup, we need a sample index.py file ( the file name must be consistent with the one in UWSGI_SCRIPT in nginx config).

Put index.py under /var/www/myapp

#!/usr/bin/env python
from bottle import route, run, default_app
@route('/')
def index():
    return "Aloha, world~"

if __name__ == "__main__":
    run(host="localhost", port=8081)
else:
    application = default_app()

• Finally, Restart/start nginx and uWSGI services:

sudo service nginx restart
sudo service uwsgi restart

Now “it’s the moment to witness the miracle!” 😀  Access http://localhost/ in your browser, you should  see “Aloha, world~”.  If not, comment below:)

Get lucky room IP address in Diablo 3 using Sikuli

Oct/7/2012 update:

I just wrote this for fun and did not want to be in any trouble so I did not upload the script. But it seems that many guys really typed it character by character, I think I should upload it 🙂

Here is the download link. Have fun. By the way, my battle tag is SeanWang#1150, usually play on US Server, also Asia Server sometimes.

After I noticed that guys  posted that certain servers of Diablo 3 have good drops (orginal post and battlenet quote) than others, I observed this ip address stuff when repeatedly running Warrior’s Rest using a monk with all MF items

My conclusion is that it is some sort of correct! especially the part about ” last number of the ip address that is over 80 is not good”.

certain servers have good drops and some have bad drops, each time you log in you are connected to a random server this is how you can find servers with better drops than others.
1) go to your cmd promt while logged into a game (not at the log in screen or at char screen but in a game)
2) type in “netstat -n” into your cmd promt to find what server you are connected to the last 4 digits of the ip are what matter. anything with 3 digits sucks and typically games with 2 digit ending in even numbers are good loot games. The best ones are “74:1119” and “76:1119” but 72-78 even work also, games like 46 also work.

So based on this theory, I wrote a Sikuli script to get the ip address less than 80. In my script, I did not judge for even number, because I think that it may be too long to get a even number AND less than 80. Too many times creating and quiting games may trigger the Blizzard anti-bot mechanism…

Here comes the script:)

NOTICE： Above script should only work in windowed game mode.

Have fun:)