使用xctool自动打包,测试xcode项目

xctool是facebook开源的一个命令行工具,用来替代苹果的xcodebuild工具。 功能如下: 像xcode一样跑测试用例 结构化输出编译测试结果 彩色且方便阅读的编译内容输出 示例截图: 如何安装xctool 最简单的办法是通过homebrew安装xctool brew update brew install xctool 搞定 如何使用xctool 打包 path/to/xctool.sh -workspace YourWorkspace.xcworkspace -scheme YourScheme archive build path/to/xctool.sh -workspace YourWorkspace.xcworkspace -scheme YourScheme build 测试 path/to/xctool.sh -workspace YourWorkspace.xcworkspace -scheme YourScheme test 作者: Volcano 发表于May 14, 2013 at Read More …

【转】iOS抓包利器Charles

转自:http://wonderffee.github.io/blog/2013/07/13/best-packet-capture-tool-charles-in-ios/ 看唐巧的分析支付宝客户端的插件机制一文发现他使用了抓包工具Charles,想起去年有人给我推荐过这个工具,但是当时我觉得WireShark就够用了就没尝试。这次看到又有人使用Charles我就重视起来了,Charles到底有什么好? 搜了一下,发现大多数使用者都是将Charles作为移动端抓包工具使用的,这样就意味着我们可以用Charles来截取iPhone/iPad上app所发出的网络请求来进行分析,分析支付宝客户端的插件机制一文就是这么用的。WireShark显然做不到这一点,优势一下子就体现出来了。 在Mac上安装Charles后,启动Charles,首先弹出一个框提示是否允许Charles有自动修改网络设置的权限,选择允许后出现Charles主界面。Charles主界面左侧有Structure和Sequence,你会发现会发现Structure这一栏里会逐步出现当前我的mac正在请求的链接,也就是说Charles一启动就自动进行抓包了。不过遗憾的是Structure栏里没有过滤选项,意味着你不能过滤特定网站。切换到Sequence栏,这个就容易懂了,按时间顺序来排列的,与WireShark一致。下方的Filter可以过滤,而是还是实时过滤的,这一点就比WireShark强多了。 如何在Mac上用Charles远程抓iPhone上app的网络请求呢?方法相当简单,下面就提供了HTTP和HTTPS抓包的操作步骤,简单几步就搞定了。 HTTP抓包 打开Charles程序 查看Mac电脑的IP地址,如192.168.1.7 打开iOS设置,进入当前wifi连接,设置HTTP代理Group,将服务器填为上一步中获得的IP,即192.168.1.7,端口填8888 iOS设备打开你要抓包的app进行网络操作 Charles弹出确认框,点击Allow按钮即可 HTTPS抓包 下载Charles证书http://www.charlesproxy.com/ssl.zip,解压后导入到iOS设备中(将crt文件作为邮件附件发给自己,再在iOS设备中点击附件即可安装;也可上传至dropbox之类的网盘,通过safari下载安装) 在Charles的工具栏上点击设置按钮,选择Proxy Settings… 切换到SSL选项卡,选中Enable SSL Proxying,别急,选完先别关掉,还有下一步 这一步跟Fiddler不同,Fiddler安装证书后就可以抓HTTPS网址的包了,Charles则麻烦一些,需要在上一步的SSL选项卡的Locations表单填写要抓包的域名和端口,点击Add按钮,在弹出的表单中Host填写域名,比如填api.instagram.com,Port填443 我简单试用了一下Charles的远程抓包功能,发现Charles比WireShark还有一个优势是能对JSON数据(在JSON Text栏)进行解析,从而让我们可以更直观地查看JSON串信息(在JSON 栏)。此外Charles对中文支持比较好,JSON串中的中文信息一般会显示为一长串的\ug开头的字符,解析之后就能显示出中文了。平常总头痛Wireshark对中文支持不好,用Charles就完全没有这个问题了。 参考资料: 使用Charles远程调试iOS移动应用 mac下的抓包工具Charles

(转)当程序崩溃的时候怎么办 Part-2

原文地址:http://www.raywenderlich.com/10209/my-app-crashed-now-what-part-2 欢迎回到当程序崩溃的时候怎么办 教程! 在这个教程的第一部分,我们介绍了SIGABRT和EXC_BAD_ACCESS错误,并且举例说明了一些使用xcode调试器(Xcode debugger)和异常断点(Exception Breakpoints)解决问题的策略。 但是我们的app仍然有一些问题!就像我们看到的,他工作的并不是很好,并且这里仍然有许多潜在的可能崩溃的问题。 幸运的是,在这个教程的第二部分,也是最后一部分,我们可以学习更多的技术来处理这些问题。 所以我们就不在啰嗦了,让我们回到继续修正这个充满bug的app中吧! Getting Started: When What’s Supposed to Happen, Doesn’t   在第一部分我们停止的地方,经过许多的调试工作之后,我们运行这个程序他是不会崩溃的。但是他却展现了一个没有预料到的空的table,就像下面一样: 当你觉得一些事情应该发生,但是却没有发生的时候,这里有些你可以使用一些技巧来排除问题。在这个教程里面,我们首先是学习使用NSlog来解决这个问题。 这个table view controller的类是ListViewController。在一系列的任务执行之后,这个app应该装载ListViewController,并且在屏幕上面显示出来。你可以做一个测试,来确定view controller的方法是执行了的。所以viewDidLoad这个方法看起来应该是一个好地方来做测试。 在ListViewController.m,增加一个NSLog()到viewDidload,就像下面一样: – (void)viewDidLoad { [super viewDidLoad]; NSLog(@”viewDidLoad is called”); } 当你运行这个app时,你应该期望当我们点击了“Tap Me”按钮后在调试窗口看到“viewDidLoad is called”这样文字。现在就来试试,点都不惊讶,在调试窗口什么也没有出现。那就意味着ListViewController类根本没有被使用! 这个多半意味着,你可能忘记了告诉storyboard你想要为table view Read More …

(转)当程序崩溃的时候怎么办 part-1

有这样一种情形:当我们正在快乐的致力于我们的app时,并且什么看都是无比顺利,但是突然,坑爹啊,它崩溃了。(悲伤地音乐响起) 我们需要做的第一件事就是:不要惊慌。 修复崩溃不是很困难的。假如你崩溃了,并且胡乱的改些东西,而且还在不停的念着咒语希望bug神奇的自动消失,你大多数情况下都会使情况更麻烦。相反的,你需要知道一些系统的方法,并且学习怎么找到崩溃和他的原因。   第一件需要知道的就是在你的代码中准确的找到crash发生的地方:在那个文件,那一行。Xcode debugger将会帮助你,但是你需要懂得怎么样最好的使用它,这也是这篇教程展示给你的。 这篇教程对于所有的开发者都是有利的。即使你是一个很有经验的ios开发者,你也可能会从中学习到一些你不知道的小窍门。 准备开始 下载这个例子程序。你将会看到这是一个有bug的程序。当你打开这个项目的时候,xcode会显示至少8个编译警告,这个通常都是危险的信号。顺便说一下,我们使用xcode4.3来做这篇教程,4.2的版本也应该没有什么问题。 注意:为了跟随这篇教程,这个编译生成的app需要运行在ios5的模拟器上面。假如你运行这个app到你的设备上,你也会崩溃,但是他们可能不会发生和教程一样的情况。 在模拟器上面运行你的app,你将会看到发生了什么。 嘿,他崩溃了。 有两种最基本的crash类型常发生:SIGABRT(也叫EXC_CRASH)和EXC_BAD_ACCESS(也可能会是SIGBUS或者SIGSEGV)。 就crash而言,SIGABRT是一个比较好解决的,因为他是一个可掌控的crash。App会在一个目的地终止,因为系统意识到app做了一些他不能支持的事情。 EXC_BAD_ACCESS是一个比较难处理的crash了,当一个app进入一种毁坏的状态,通常是由于内存管理问题而引起的时,就会出现出现这样的crash。 幸运的是,第一种崩溃(也是大多数崩溃)是SIGABRT,SIGABRT通常会在xcode的Debug Output窗口(在窗口的右下角)输出一些错误的信息。假如你没有看到Debug Output窗口,在你的xcode窗口的右上角一组图标中点击中间那个,假如还是没有看到Debug Output窗口,你需要点击这个小窗口的右上角的中间那个图标,他靠近搜索框。在这个情况下,会展示一些下面东西: Problems[14465:f803] -[UINavigationController setList:]: unrecognized selector sent to instance 0x6a33840 Problems[14465:f803] *** Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘-[UINavigationController setList:]: Read More …