原来的vps（justhost）主机到期了，续费价格翻了4倍几乎300刀两年，这不宰人么，弃之。
听说hostigation.com不错，且我测试ping值是比较快的，200ms平均，就买下了，30刀一年128M内存，想想一个小博客应该够了。
而今：
ping值奇怪的平均400ms，内存不是很够，mysql使用的最小内存配置，还是不行，经常无反应，现在博客响应速度很慢呢。还真不如我当初使用的某个二道贩子的20软妹币一年的，真上当了。
折腾一番后，把apache一些模块禁止掉了，一下在节约了60M内存，再一测，速度还行。但是运行个查询就又没内存了。
ping值按时间段不是很稳定，上次测得很慢，这次测又回到了200ms。
参见：
基于wordpress优化apache性能：
https://thethemefoundry.com/blog/optimize-apache-wordpress/
Continue reading hostigation.com vps主机使用吐槽
in 默认分类 on google drive, mac, onenote
onenote mac版推出了，马上使用一下，结果发现功能很多被阉割。但是还是不错的。
我还是决定弃用：
1：不能粘贴网页格式，网页上粘贴的内容拷贝进去格式全没了。
2：不能插入图片，点击插入图片，只见一个红叉叉，这有什么用？
还是用google drive。
google drive mac版居然能下载下来，居然速度还可以。但是文件同步什么的还是不喜欢，直接网页版上写吧。
=======================================
今天通知onenote更新了，居然添加了上面的两个功能，难道微软在倾听用户的声音？
纠结要不要把google上的都转过来！！
=============================
发现onenote急需要改进的地方：表格功能太弱，不能合并单元格等等……
Continue reading onenote mac 免费版使用
转自 jloser.com/java对象占用内存大小的分析与计算/ （不知为什么google 报攻击站点）
new Object()将占用多少bytes的内存空间？可能大部分时候我们并不是很关心，但是经常有Java开发人员抱怨我们的应用程序越来越慢、越来越消耗内存，特别是在我们面临有限内存和应用功能不断增加的情况下；另一方面，我们在设计应用程序时又常常为对象创建是采用prototype还是singleton方式而犹豫不决。此时，我们有必要搞清楚，运行我们的应用程序究竟需要多少内存预算，而最消耗内存的又是哪些地方和哪些对象。通常，我们遇到这样的问题首先会想到使用Profiler工具来剖析下我们的应用程序，如JProfiler、VisualVM之类，这类工具能够胜任这项工作，但它们具有一定的学习门槛、操作过于复杂、无法与应用集成、本身也很耗内存。如果我们有个像c中的sizeof函数就好了，很不幸，Java没有，好在JDK1.5中发布了一个Instrumentation组件，我们可以借此来自定义一个sizeof工具来测量对象占用的内存大小。首先，在测试之前让我们理论分析下不同Java对象对内存的占用。
一. 须知事项:
——————————————————————————————–
1. 我们所说的Java对象占用内存大小仅是指分配在heap上的对象，在某些情况下JVM可能会在stack上或register上直接为对象分配存储区域，此外静态变量(static)是分配在method area上的；
2. Java对象占用的内存大小在同一JVM内不同时间可能会发生变化, 这主要是内存占用还跟对象的状态有关，如当前对象内置锁的状态、是否正在等待GC回收等；
3. 不同JVM里同样数据结构的对象占用的内存大小也有可能不一样大，这主要是内存占用还跟JVM实现、操作系统等有关。
二. 计算方法:
——————————————————————————————–
1. 通常我们想到的是借助Runtime#freeMemory(), 伪代码如下：
long before = Runtime.getRuntime().freeMemory();
Object obj = new Object();
long after = Runtime.getRuntime().freeMemory();
System.out.println("Object size: [" + (after - before) + "]");
2. 使用序列化技术将对象序列化成byte数组，再检查数组的长度。
3. 使用Reflection API遍历对象所有的fields然后累加。
4. 借助Instrumentation#getObjectSize(Object objectToSize) 计算。
方法1受GC的影响，准确度较低，有时会得出负值；方法2是错误的，序列化的结果是种特定格式的数据，这种格式在多JVM间兼容，但是这种格式的数据在内存中占用的空间大小与序列化后的结果无关；方法3设计复杂，且需要了解JVM实现；方法4简单明了，官方API，可靠，也是本文底层采用的方法。
三. 计算范围:
——————————————————————————————–
1. Shallow, 仅计算为本对象本身新分配的内存大小。
2. Deep, 计算本对象本身及引用对象、引用对象的引用…所有关联对象占用的内存大小。
四. 原生类型(primitive type)的内存占用
Primitive Type Memory Required(bytes)
—————————————————————
boolean 1
byte 1
short 2
char 2
int 4
float 4
long 8
double 8
—————————————————————
五. 对象类型(reference type)的内存占用
下文中的32位（64位）系统是指32位（64位）的JVM。
——————————————————————————————–
1. 一个object header, 也称object overhead, 保存当前实例的type信息和内置monitor信息等, 32位系统上占用8bytes，64位系统上占用16bytes；
2. 0到多个fields, reference类型在32位系统上每个占用4bytes, 在64位系统上每个占用8bytes; primitive类型参考上面；
3. padding, 对步骤1、2之和的补长。CPU从内存中读取数据是以word为基本单位, 32位的系统中word宽度为32bits, 64位的系统中word宽度为64bits, 将整个Java对象占用内存补长为word的整倍数大大提高了CPU存取数据的性能，参考维基百科关于数据alignment的说明 。 就Hotspot而言，不管是32位系统还是64位系统要求（步骤1 + 步骤2 + padding） % 8等于0且0 <= padding < 8。例如在64位系统上:
public class Student {
private int age;
}
如new Student()则其占用内存: 16 + 4 = 20，按照3中的说明则padding为4bytes，这样整个内存占用为24bytes。
六. 一维原生数组的内存占用
——————————————————————————————–
1. 在32位的系统中, 占用内存为: 型别占用内存 * 数组长度 + 8（数组在JVM中被当成特殊的对象, object overhead占用8bytes） + 4（数组长度） + padding。如：
byte[2], 型别占用内存，即byte型别占用1byte，数组长度为2，这样占用的总内存为1 * 2 + 8 + 4 = 14，padding上2bytes为16bytes，所以byte[2]占用内存为16bytes。
2. 在64位的系统中, 占用内存为: 型别占用内存 * 数组长度 + 16（object overhead占用16bytes） + 8（数组长度） + padding。如：
byte[2], 型别占用内存，即byte型别占用1byte，数组长度为2，这样占用的总内存为1 * 2 + 16 + 8 = 26，padding上6bytes，26 + 6 = 32bytes，所以byte[2]占用内存为32bytes
七. 多维数组和一维对象数组
——————————————————————————————–
1. 在32位的系统中, 占用内存为: reference占用内存 * 数组第1维长度 +12(数组本身被当做reference占8bytes，数组长度占4bytes)。如：
byte[3][7], reference占用内存4byte，数组第1维长度为3，这样占用的总内存为4 * 3 + 12 = 24，所以byte[3][7]占用内存为24bytes。再如byte[7][3], reference占用内存4byte，数组第1维长度为7，这样占用的总内存为4 * 7 + 12 = 40，所以byte[7][3]占用内存为40bytes。再如new HashMap[7][6][4]，reference占用内存4byte，数组第1维长度为7，这样占用的总内存为4 * 7 + 12 = 40，所以HashMap[7][6][4]占用内存为40bytes。
2. 在64位的系统中, 占用内存为: reference占用内存 * 数组第1维长度 +24(数组本身被当做reference占16bytes，数组长度占8bytes)。如：
byte[3][7], reference占用内存8byte，数组第1维长度为3，这样占用的总内存为8 * 3 + 24 = 48，所以byte[3][7]占用内存为48bytes。
八. 编码计算
——————————————————————————————–
1. java.lang.instrument.Instrumentation实例由JVM产生，我们需实现一个代理(agent)，根据java.lang.instrument的package specification说明，这个代理里需有个public static void premain(String agentArgs, Instrumentation inst); 方法，这样在JVM初始化后在调用应用程序main方法前，JVM将调用我们agent里的这个premain方法，这样就注入了Instrumentation实例。
2. 计算实例的内存大小，通过Instrumentation#getObjectSize(Object objectToSize)获得。
3. 注意: 如果有field是常量（如, Boolean.FALSE），因为多实例共享，所以算其占用内存为0。
4. 如计算对象Deep范围内存占用的话则需递归计算引用对象占用的内存，然后进行累加。
5. 代码实现如下MemoryCalculator.java：
/*
* @(#)MemoryCalculator.java 1.0 2010-11-8
*
* Copyright 2010 Richard Chen([email protected]) All Rights Reserved.
* PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
*/
package charpter.memory;
import java.lang.instrument.Instrumentation;
import java.lang.reflect.Array;
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;
import java.util.IdentityHashMap;
import java.util.Map;
import java.util.Stack;
/**
* 提供实例占用内存大小的计算功能. 内部借助JVM的{@link Instrumentation}实现.
*
* @author Rich, 2010-11-8.
* @version 1.0
* @since 1.0
*/
public final class MemoryCalculator {
/**
* JVM在初始化后在调用应用程序main方法前将调用本方法, 本方法中可以写任何main方法中可写的代码.
*
* @param agentArgs 命令行传进行来的代理参数, 内部需自行解析.
* @param inst JVM注入的句柄.
*/
public static void premain(String agentArgs, Instrumentation inst) {
instrumentation = inst;
}
/**
* 计算实例本身占用的内存大小. 注意:
* 1. 多次调用可能结果不一样, 主要跟实例的状态有关
* 2. 实例中成员变量如果是reference类型, 则reference所指向的实例占用内存大小不统计在内
*
* @param obj 待计算内存占用大小的实例.
* @return 内存占用大小, 单位为byte.
*/
public static long shallowSizeOf(Object obj) {
if (instrumentation == null) {
throw new IllegalStateException("Instrumentation initialize failed");
}
if (isSharedObj(obj)) {
return 0;
}
return instrumentation.getObjectSize(obj);
}
/**
* 计算实例占用的内存大小, 含其成员变量所引用的实例, 递归计算.
*
* @param obj 待计算内存占用大小的实例.
* @return 内存占用大小, 单位为byte.
*/
public static long deepSizeOf(Object obj) {
Map calculated = new IdentityHashMap();
Stack unCalculated = new Stack();
unCalculated.push(obj);
long result = 0;
do {
result += doSizeOf(unCalculated, calculated);
} while (!unCalculated.isEmpty());
return result;
}
/**
* 判断obj是否是共享对象. 有些对象, 如interned Strings, Boolean.FALSE和Integer#valueOf()等.
*
* @param obj 待判断的对象.
* @return true, 是共享对象, 否则返回false.
*/
private static boolean isSharedObj(Object obj) {
if (obj instanceof Comparable) {
if (obj instanceof Enum) {
return true;
} else if (obj instanceof String) {
return (obj == ((String) obj).intern());
} else if (obj instanceof Boolean) {
return (obj == Boolean.TRUE || obj == Boolean.FALSE);
} else if (obj instanceof Integer) {
return (obj == Integer.valueOf((Integer) obj));
} else if (obj instanceof Short) {
return (obj == Short.valueOf((Short) obj));
} else if (obj instanceof Byte) {
return (obj == Byte.valueOf((Byte) obj));
} else if (obj instanceof Long) {
return (obj == Long.valueOf((Long) obj));
} else if (obj instanceof Character) {
return (obj == Character.valueOf((Character) obj));
}
}
return false;
}
/**
* 确认是否需计算obj的内存占用, 部分情况下无需计算.
*
* @param obj 待判断的对象.
* @param calculated 已计算过的对象.
* @return true, 意指无需计算, 否则返回false.
*/
private static boolean isEscaped(Object obj, Map calculated) {
return obj == null || calculated.containsKey(obj)
|| isSharedObj(obj);
}
/**
* 计算栈顶对象本身的内存占用.
*
* @param unCalculated 待计算内存占用的对象栈.
* @param calculated 对象图谱中已计算过的对象.
* @return 栈顶对象本身的内存占用, 单位为byte.
*/
private static long doSizeOf(Stack unCalculated, Map calculated) {
Object obj = unCalculated.pop();
if (isEscaped(obj, calculated)) {
return 0;
}
Class clazz = obj.getClass();
if (clazz.isArray()) {
doArraySizeOf(clazz, obj, unCalculated);
} else {
while (clazz != null) {
Field[] fields = clazz.getDeclaredFields();
for (Field field : fields) {
if (!Modifier.isStatic(field.getModifiers())
&& !field.getType().isPrimitive()) {
field.setAccessible(true);
try {
unCalculated.add(field.get(obj));
} catch (IllegalAccessException ex) {
throw new RuntimeException(ex);
}
}
}
clazz = clazz.getSuperclass();
}
}
calculated.put(obj, null);
return shallowSizeOf(obj);
}
/**
* 将数组中的所有元素加入到待计算内存占用的栈中, 等待处理.
*
* @param arrayClazz 数组的型别.
* @param array 数组实例.
* @param unCalculated 待计算内存占用的对象栈.
*/
private static void doArraySizeOf(Class arrayClazz, Object array,
Stack unCalculated) {
if (!arrayClazz.getComponentType().isPrimitive()) {
int length = Array.getLength(array);
for (int i = 0; i < length; i++) {
unCalculated.add(Array.get(array, i));
}
}
}
/** JVM将在启动时通过{@link #premain}初始化此成员变量. */
private static Instrumentation instrumentation = null;
}
以上代码请参考: http://www.javaspecialists.eu/archive/Issue142.html。
九. 打包及测试
——————————————————————————————–
1. 将MemoryCalculator.java编译后打包为javatutorial.jar，修改jar中的META-INF/MANIFEST.MF文件，在文件结尾处添加新的一行Premain-Class: charpter.memory.MemoryCalculator，注意冒号后有一个空格，行尾有回车。
2. 编写测试代码TestMem.java，如下:
/*
* @(#)TestMem.java 1.0 2010-11-8
*
* Copyright 2010 Richard Chen(email: [email protected]) All Rights Reserved.
* PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
*/
package charpter.mem;
import java.util.HashMap;
import charpter.memory.MemoryCalculator;
/**
* Java对象内存占用的测试.
*
* @author Rich, 2010-11-8.
* @version 1.0
* @since 1.0
*/
public class TestMem {
public static void main(String[] args) {
long result = MemoryCalculator.shallowSizeOf(new Object());
System.out.println(result);
result = MemoryCalculator.shallowSizeOf(new byte[1000]);
System.out.println(result);
result = MemoryCalculator.shallowSizeOf(new byte[2]);
System.out.println(result);
result = MemoryCalculator.shallowSizeOf(new byte[2][3]);
System.out.println(result);
result = MemoryCalculator.shallowSizeOf(new byte[3][3]);
System.out.println(result);
result = MemoryCalculator.shallowSizeOf(new byte[9][3]);
System.out.println(result);
result = MemoryCalculator.shallowSizeOf(new byte[2][3][3]);
System.out.println(result);
result = MemoryCalculator.shallowSizeOf(new byte[7][3]);
System.out.println(result);
result = MemoryCalculator.shallowSizeOf(new byte[3][7]);
System.out.println(result);
result = MemoryCalculator.shallowSizeOf(new byte[7][6][4]);
System.out.println(result);
result = MemoryCalculator.shallowSizeOf(new HashMap[7][6][4]);
System.out.println(result);
result = MemoryCalculator.shallowSizeOf(new HashMap[7]);
System.out.println(result);
}
}
3. 编译TestMem.java，然后执行之。注意在命令行要指定代理类，即: -javaagent:javatutorial.jar，以下为本人在自己测试环境下的执行结果
a. Linux, 64bits, 64位JDK1.5, 执行命令: java -javaagent:/home/adapp/javatutorial.jar -cp /home/adapp/javatutorial.jar:/home/adapp/ charpter.mem.TestMem
结果输出：
16
1024
32
40
48
96
40
80
48
80
80
80
b. Windows 7, 32bits, 32位JDK1.5, 配置的命令行参数为: -javaagent:D:/Temp/javatutorial.jar，执行结果
8
1016
16
24
24
48
24
40
24
40
40
40
c. Windows 7, 64bits, 32位JDK1.5, 配置的命令行参数为: -javaagent:D:/Temp/javatutorial.jar，执行结果
8
1016
16
24
24
48
24
40
24
40
40
40
d. Windows 7, 64bits, 64位JDK1.7.0_09, 配置的命令行参数为: -javaagent:D:/Temp/javatutorial.jar，执行结果
16
1016
24
24
32
56
24
48
32
48
48
48
从上述输出结果可以看出，案例a, b, c与步骤四至七的理论分析一致。案例d与理论分析不完全一致，但是大小比例关系依然存在，这主要是Hotspot对对象指针采用了压缩算法，由官方资料关于Compressed oops（ordinary object pointer）的说明 可以看出，从Java SE 6u23之后的64位版本就默认打开了对象指针压缩。
十. Compressed oops的内存占用
注意，Compressed oops只在64位的JVM中才会有，另外，在Java SE 6u23之前的1.6版本中需要通过-XX:+UseCompressedOops参数开启。压缩算法对对象内存占用计算的影响主要在于:
——————————————————————————————–
1. object header，未压缩前由一个native-sized mark word 8bytes加上一个class word 8bytes组成，共16bytes。采用压缩后，class word缩减为8bytes，现共占用12bytes；
2. reference类型，由8bytes缩减为4bytes；
3. 数组长度，由8bytes缩减为4bytes。
所以，上述测试案例中:
——————————————————————————————–
1. 原生类型，内存占用大小不变。
2. 对象类型，object header由16bytes变更为12bytes，reference类型的fields由8bytes变更为4bytes，primitive类型的fields保持不变，padding不变。
3. 一维原生数组，如new byte[2]占用内存的计算公式由：型别占用内存 * 数组长度 + 16 + 8 + padding变更为: 型别占用内存 * 数组长度 + 12 + 4 + padding，这样得到: 1byte * 2 + 12 + 4 = 18，padding上6bytes等于24bytes。
4. 多维数组和一维对象数组，如new byte[3][7]，计算公式由: reference占用内存 * 数组第1维长度 +24(数组本身被当做reference占16bytes，数组长度占8bytes) 变更为: reference占用内存 * 数组第1维长度 + 16(object header 12bytes，数组长度占4bytes) + padding，这样得到：4bytes * 3 + 16 = 28，padding上4bytes等于32bytes。 再如new HashMap[7]，7 * 4bytes + 16 = 44bytes，padding上4bytes为48bytes。
十一. 总结
通过上述Java内存占用大小的理论分析与实际测试，给我们实际开发带来几点重要的启发:
——————————————————————————————–
1. 同样的程序在不同环境下运行，占用的内存不一样大小，64位系统上占用的内存要比在32位系统上多1至1.5倍；
2. n个元素的数组要比n个单独元素占用更大的内存，特别是primitive类型的数组；
3. 定义多维数组时，要尽可能把长度小的放在第1维，即int[9][1]要比int[1][9]占用更多内存，Integer[1000][4][3]远比Integer[3][4][1000]占用的内存要多得多；
4. Java SE 6u23之后的64位版本要比之前的版本在对象内存占用方面小得多。
十二. 参考资源
1. http://www.javamex.com/tutorials/memory/object_memory_usage.shtml
2. https://wikis.oracle.com/display/HotSpotInternals/CompressedOops
Continue reading 【转】Java对象占用内存大小的分析与计算
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
其中 ${project.build.directory}是指当前工程的target目录，运行package则会将所有依赖包拷贝到lib目录下。
参见：
http://stackoverflow.com/questions/97640/force-maven2-to-copy-dependencies-into-target-lib
Continue reading maven 拷贝所有依赖到指定目录
in Web前端 on javascript
这次遇到个问题，子窗体脚本向父窗体添加了个脚本，但是添加的脚本的上下文却是子窗体！也就是说，在被添加的脚本中操作dom其实是操作的子窗体的dom，window对象也是子窗体的window。
为什么这样我还没找到文档。
类似这样：
子窗体脚本：
$(‘head’,parent.document).append(‘<script src=”xxxx.js”></script>’);
xxx.js里:
log(window);
会发现是子窗体的window对象。
Continue reading 同源跨窗口添加脚本的上下文
in 默认分类
今天试用了一下Evernote， 界面做的不错，国内也没被墙，很想将被兲朝虐的不行Google Drive里的资料导进去，发现居然不可以。PDF，word什么的都不支持。
网上所抱怨的格式兼容什么的确实不假，想想还是算了，难道还一篇篇重写不成，我还那么多图片在文档里。果断删了。
还是凑合着用Google吧，虽然那动不动就“正在联系服务器”的提示让人咬牙切齿，但还是很强大的。
Continue reading Evernote 使用后感
mac osx下要活的当前文件夹路径不是个很方便的事情，因为它没有winows那样的地址栏，那么：
方法一：
command+I获得简介，从里面copy路径 这个不好用
方法二：
网上找到的
在launchpad里打开Automator，在实用工具里找到Run AppleScript，选择no input，从左边Run AppleScript拖到右边，就会出现脚本编辑。
拷贝脚本
try
tell application "Finder" to set the clipboard to POSIX path of (target of window 1 as alias)
on error
beep
end try
替换(* Your script goes here *)
command+save 保存一个名字。
然后你就可以在系统设置、键盘快捷键、通用下 找到你创建的服务，给它一个快捷键，那么在任何文件夹下只要这个快捷键就可以将其拷贝到粘贴板上了。
具体参见：
http://apple.stackexchange.com/questions/47216/copying-the-current-directorys-path-to-the-clipboard
Continue reading mac osx 拷贝当前文件夹路径
往往导入一个新工程，发现很多语法验证错误，但那本不是错误。看的很烦心，这个问题我以前碰到过，只是没有烂一下笔头，这次又出现了，弄了半天，才发现在problems里点击这些错误，右键删除即可。
Continue reading eclipse 遇到很多验证错误
碰到这样的问题真让人捉急啊，什么线索也没有。只能靠猜测了，尝试多种办法都不行，最后试试网上有没有解决方案，居然有：
将工程下 .setting 和.project文件删除再重新配置即可。
参见：
Continue reading eclipse An internal error occurred during: "Updating Maven Project". java.lang.NullPointerException 问题
转载作为备份，建议看原文。
原文转自：
http://www.ityran.com/archives/1006
http://www.ityran.com/archives/1143
本文由 大侠自来也 翻译（泰然翻译组），转载请注明出处并通知泰然。
有这样一种情形：当我们正在快乐的致力于我们的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窗口，你需要点击这个小窗口的右上角的中间那个图标，他靠近搜索框。在这个情况下，会展示一些下面东西：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
了解这些错误消息是非常重要的，因为他们包含了错误在那里的重要线索，一下就是需要关注的部分：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
“unrecognized selector sent to instance XXX” 这条错误消息意味着你的app正在试着执行一个不存在的方法。这种情况的发生，主要是都是一个方法被错误的对象调用了（也就是这个对象没有这个方法，但是你调用了他，就错了）。例如在这里这个问题上，对象就是UINavigationController （在内存地址0x6a33840上），方法就是setList:。
知道crash的原因是很好的，但是你的第一行动目的就是指出这个错误的发生在代码的那个地方。你需要找到源文件的名字和这个错误方法在那一行。你通过使用call stack（就像堆栈跟踪（stacktrace）或者回溯（backtrace））就可以知道这些东西。
当你的程序crash了时，在xcode窗口的左边小窗口会启动Debug Navigator（调试导航）。他会展示在这个app中那个线程是活动的，并且高亮显示crash了的线程。通常他会是线程1，这个app的主线程，这个线程也是你会做最多工作的线程。假如你的代码里面使用了队列（queues）或者后台线程（background threads），这个app也可能会在其他的线程里面崩溃。
当前xocde就高亮显示了main.m里面的main()函数。但是那些东西并没有告诉你很多，所以你需要继续的向深层次的挖掘。
为了看到堆栈的更多信息，拖拽Debug Navigator底部的滑块到最右边。它将会展示出崩溃时全部的堆栈信息：
这个列表里面的每一项都是一个来这个app或者ios的framework里的方法或者函数。堆栈展示了当前活跃在这个app里面的方法或者方法。调试器（debugger）已经暂停了这个程序，并且所有的这些方法和函数在这个时候也被冻结了。
在底部的函数start()，第一个被调用。在他的执行里面的有些地方，，main()函数在他之前。（Somewhere in its execution it called the function above it, main().）。他是应用程序的开始入口点，并且它经常在底部附近。Main()也叫UIApplicationMain()（这个针对的是ios哈，并不是其他所有程序都是这样的）。在这个编辑窗口里面用绿色箭头指示的那一行（就是在这个教程最开始前面程序崩溃时停止在那个图片上，高亮显示的部分）。
进一步来看看这个堆栈，UIApplication()在UIApplication对象里调用_run方法，_run方法里面又调用CFRunLoopRunInMode()方法，CFRunLoopRunInMode()方法里面又调用CFRunLoopSpecific()方法，就这样一直向下调用，一直到__pthread_kill。
所有在这个堆栈里面的函数和方法都是灰色的，除了main()函数。那是因为他们都来自内置的ios frameworks(ios内置框架)。所以没有针对他们可见的源码。
在这个堆栈里面唯一的东西就是你有main.m的源码，因此xcode的代码编辑器就显示了它，即使他不是这个崩溃的真正原因。但是这个经常混淆初学者，但是马上我将展示怎么样来弄懂它。
开个玩笑，点击这个堆栈里面的任意一项，你将会看到许多的汇编代码，这些你可能完全不理解：
加入我们得到那样的源码，我想很多人都会说：坑爹啊。
异常断点
你怎么样找到是代码里面的哪一行使app崩溃的？无论什么时候，你得到的一个想这样的堆栈路径，一个异常通过这个app抛出。（你多半会说因为堆栈里面有一个函数叫objc_exception_rethrow。）
当程序由于做了一些他不能完成的事情时，一个异常就会发生。你所看到的就是这个异常的结果：app做了一些错的事情，异常被抛出，xcode展示异常的结果。理想情况下，你想要的准确的看到异常在那里抛出的。
幸运的是，通过使用Exception Breakpoint（异常断点），你可以告诉xcode在一个特定的时候暂停这个程序。断点是一个在特定时刻暂停你的程序的调试工具。你将会第二篇教程里面看到更多关于他们的信息，但是现在你将会使用一个特殊的断点，它将会在抛出异常前暂停你的程序。
为了设置异常断点，我们不得不切换到Breakpoint Navigator（断点导航器）：
在底部有一个小的加号（“+”）按钮。点击它，并且选择Add Exception Breakpoint：
一个新的断点将会被增加到这个列表里：
点击Done按钮使弹出的窗口消失。注意在xcode工具栏上面Breakpoints button（断点按钮）是有效的。加入你不想要带着任何断点运行你的app，你可以简单的开关这个按钮到off。但是现在，让它打开，并且再一次运行这个app。
太好了！代码编辑器现在停止并且指到了代码中的其中一行，不再在令人烦躁的汇编代码了，并且注意在在左边的的Debug Navigatot（调试导航器）里面显示的堆栈信息也不一样了。
显然的，问题就出在AppDelegate里面的application:didFinishLaunchingWithOptions：方法里：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
仔细再次看看这个错误消息：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
在这个代码里面，“viewController.list = something”这种方式隐式的调用了setList:方法，也就是set方法，因为“list”是MainViewController类的一个属性。然而，通过这个错误消息，我们知道viewController这个变量没有指向MainViewController对象，而是指向了UINavigationController，所以显然的，UINavigationController没有“list”属性！所以这些变量在这里混淆了。
打开Storyboard文件，看看window的rootViewController属性实际上是指向那个的：
哈哈！Storyboard的最初的view controller是一个Navigation controller。这就是为什么window.rootViewController是一个UINavigationController对象，而不是你自认为的MainViewController。为了修改这里，使用下面的代码来替代application:didFinishLaunchingWithOptions：里面的：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
通过代码可以看出，首先你通过self.window.rootViewController得到UINavigationController，一旦你得到了上面的。你就可以通过请求navigation controller来得到topViewController，进而得到MainViewController。现在viewController变量就是指向了正确的对象了。
注意：一旦你得到“unrecognized selector sent to instance XXX”错误，你就需要检查这个对象是不是正确类型，并且检查它真的是有那个名字的方法么。你会经常发现你调用一个你认为是这个对象的方法，因为指针变量可能没有包含这个正确值，所以导致很多的错误。
另外一个经常出现错误的原因就是将方法名称拼写错误。一会儿你将会看到一个这样的例子。（译者：我个人认为有xcode的代码提示功能，这种错误应该还是比较少吧，多数应该出现在通过selector，或者传递函数指针的时候，应该会多点这个错误）。
你的第一个内存错误
你可能已经修复了你的第一个问题。再一次运行这个程序。坑爹啊，在同样的一行，又崩溃了，但是现在是EXC_BAD_ACCESS错误。那意味着这个app有内存管理的问题。
一个和内存相关的崩溃一般很难定位到源代码，因为这个恶魔可能很早就在程序中做了坏事了。假如一段有问题的代码混乱了内存结构，这样产生的蝴蝶效应可能会在之后很久才表现出来，并且总在不同的地方。
实际上，在你所有的测试中，这个bug可能永远不会出现，但是却在你的客户的设备上展露出它丑陋的脑袋。这种是很多人都不想的。
这种特别的崩溃但是却很容易修复。假如你看到你的代码编辑器，xcode其实一直就在警告你这一行代码。看到左边靠近行号的那个黄色三角形没有？那个指出一个编译警告。假如你点击那个黄色的三角形，xcode将会弹出一个“Fix-it”的建议，就像下面的一样：
这个代码使用了一系列的对象来初始化一个数组（NSArray），并且像那样的一系列的对象应该使用nil来终止，这个警告的标记就是想要表达一个这样的意思。但是代码却没有那样做，所以NSArray就很困惑，很迷茫。它试着读取一个不存在的对象，最后这个app艰难的崩溃了。
这种错误，你真的不应该犯，特别是xcode已经警告了你。修复这个错误，通过像下面一样增加一个nil（或者你可以简单的选择刚刚弹出来的菜单里面“Fix-it”）：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
“This class is not key value coding-compliant”
重新运行这个程序，看看为你准备的其他有趣的bug。信不信由你?它又在main.m里面崩溃了。虽然Exception Breakpoint任然起作用了，但是我们没有看见任何高亮的程序代码，这次的崩溃真的没有发生在任何程序代码里。这个调用堆栈证实了这点：这里面的方法没有一个属于的程序的，除了main()：
假如你从上到下浏览一下这些方法的名字，有些问题发生在NSObject和Key-Value Coding。在那之下调用了[UIRuntimeOutletConnection connect]。我不知道那个是干什么的，但是看起来好像它做了连接outlet的一些事情。在那之下的一些方法是从nib中加载view。因此以上那些也给你一些线索。
但是，在xcode的调试窗口，并没有易懂的错误消息。那是因为没有异常被抛出。在xcode告诉你异常的原因之前，Exception Breakpoint已经暂停了这个程序。有些时候你会从Exception Breakpoint得到一些局部的错误消息，但是有些时候就得不到。
为了得到全部的错误消息，点击调试器工具栏上的“Continue Program Execution”按钮：
你可能需要点击好几次才可以，然后你将会得到错误消息：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
就像之前的一样，你可以忽略下面的那些数字。他们展示了调用堆栈，但是在调试导航器的左边有更加直观的堆栈调用展示。
有趣的部分是：
NSUnknowKeyException
MainViewController
“this class is not key value coding-compliant for the key button”
这个异常的名字为NSUnknownKeyException，它是这个错误很好的指示器。它告诉你在某个地方有一个“unknown key”。这个某一个地方通常就是MainViewController，并且这个key就是“button”。
既然我们已经确定了，所有这些都是发生在装载nib的时候。这个应用使用的是storyboard，而不是nib文件，但是其实storyboard内部就是nib的集合（也就是可以有很多的nib），因此这个错误就在这个storyboard中。
检查一下MainViewController的outlets：
在Connections Inspector（连接检测器）里，你可以看见在viewcontroller中间的UIButton是连接到MainViewController的“button”outlet上的。因此storyboard引用了一个名叫“button”的outlet，但是通过这个错误消息说明它找不到这个outlet。
让我们来看看MainViewController.h：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
这里是为这个“button”定义了外部连接属性的（@property），因此这个问题是什么呢？假如你仔细观察了编译警告的话，你可以已经知道是什么地方的问题了。
假如还不知道的话，检查一下MainViewController.m的@synthesize的内容的话。你现在看出问题没有啊？
这个代码其实没有@synthesize这个button的属性。它（@synthesize）其实是告诉MainVIewController他自己有个“button”的属性，提供一个后台实例变量，并且提供getter和setter方法（这就是@synthesize所做的）。
把下面的增加到MainViewController.m里面已经存在的@synthesize行的下面来修复这个问题：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
现在这个app应该不会在你运行的时候崩溃了！
注意：“this class is not key value coding-compliant for the key XXX”的错误经常都是由于你装载这个nib，但是里面引用的一些熟悉可能不存在。特别是当你在代码中移除了outlet属性后，但是你却没有在nib中移除这个连接。
Push the Button
现在这个app正常工作，或者至少说启动的时候没有问题。是时候来点击这个按钮了。
哇!这个app崩溃在main.m里面，并且伴随着SIGABRT。在调试窗口打印出的错误消息是：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
堆栈跟踪也不是很有启发。只是列出了一些和一个方法相关的或者发送了事件并且执行了动作的方法，但是你已经知道到了被涉及的动作了。毕竟，你点击了一个按钮，这个按钮的IBAction方法应该被调用。
当然你之前应该已经看过了这个错误消息。一个被调用的方法不存在。这个时候目标对象应该是MainViewController，由于动作方法经常存在于一个包含按钮的view controller里面，所以这个看起来是正确。并且你看MainViewController.h文件，这个IBAction方法确实在里面：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
是这样的吗？错误消息显示这个方法的名字是buttonTapped，但是MainViewController的方法却是buttonTapped：（注意冒号）,由于这个方法需要接受一个参数（名字是sender），所以在方法名字后面有个冒号。从这个错误消息看出，这个方法没有冒号，因此不需要参数。所以这个方法看其实应该是这样的：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
这个里发生了什么？这个方法最初的时候不需要参数（有些时候这样动作方法是被允许的），并且在那个时候，他为这个按钮在storyboard里面连接了Touch Up Inside的时间方法。然而，在那之后某个时候，这个方法的形式被修改为包含了一个“sender”参数，但是，却没有去更新storyboard。
你可以在storyboard里面看看，在这个按钮的连接检测器：
第一，断开Touch Up Inside 事件（点击这个小“X”），然后再次连接它到MainViewController里，但是这次选择这个buttonTapped：方法。注意在连接检查器里面看看这个方法后面是有一个冒号的。
运行这个app，再一次点击按钮。我们又得到了这个“unrecognized selector”消息，但是这次他正确的定位到了buttonTapped：方法里面。class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
假如你仔细看的话，编译器警告应该又给你指出解决方案。Xcode提出MainViewController的实现是不完整的。特别的，buttonTapped：方法没有被发现。
是时候看看MainViewController.m了，在这里确实是有buttonTapped：方法啊……………..等等，拼写错误了：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
很简单的修改，重命名这个方法：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
提示：你没必要声明这个方法为IBAction，假如你觉得这样是很优雅的，你可以这样做。
注意：假如你仔细注意到这些编译器警告的话，这些问题很容易看出来的。就个人而言，我把所有的警告当成严重的错误（在xcode里面的编译设置（Build Settings）里面可以设置警告作为错误提示的），在运行程序以前，我会修改所有的。Xcode在指出愚蠢的错误表现的相当好，就像这里这样，并且注意到这些提示是很明智的。
Messing with Memory（混乱内存）
经过了这么多，你知道崩溃一直在继续从未停止过。运行这个app，点击按钮，然后等待崩溃。好，现在就来了：
这里是另一种EXC_BAD_ACCESS崩溃。幸运的是，xcode已经准确给你指示出位置在那里了，在这个buttonTapped：方法里面：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
有些时候，你可能在上面花费一些时间才会反应过来，但是xcode提供了帮助，仅仅需要点击这个黄色的三角形来看这个错误是什么：
NSLog呈现一个Objective-c类型的字符串，而不是一个c字符串，因此插入一个@符号来修改它：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
你将会注意到这个警告的黄色三角形依然没有消失。这是因为在这行还有另外一个bug，这个bug可能会或者可能不会使你的程序崩溃。有些时候这个代码工作很好，或者现在看起来很好，但是有些时候他就会崩溃。（特别是有些时候只在你的客户的设备上面，绝不会在你的设备上）。
让我们来看看这个新的警告：
这个“%s”专门为c语言类型的字符串。一个c类型的字符串就是把这个内存分成片段（一个老式的字节数组），通过一个所谓的”NUL character”（其实就是一个为0的值）来终止。例如这个“Crash！”看起来就是这样的：
无论是什么时候，你使用一个函数或者方法来操作这个c类型的字符串，你不得不确定这个字符串是以一个0值来结尾的，否则这个函数将不知道这个字符串已经结束了。
现在来看看，当你指定了在NSlog（）中用“%s”来格式化字符串，或者在NSString 的stringWithFormat里面，这个变量将会被当做是一个c类型的字符串。假如这个“sender”指向一个包含0字节的内存，这个NSlog（）将不会崩溃，但是输出的东西就会像这样：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
再一次运行这个app，点击这个按钮，等待它崩溃。现在在Debug窗口的左边部分，右击“sender”，并且选择“view Memory of “*sender””选项（确保是选择的是带有星号的sender）。
Xcode将会展示出这个内存地址的内容，恰恰这个就是NSlog（）打印出来的内容。
然而，这里并不能保证这里有空位（结束标志位），所以你完全很容易执行到一个EXC_BAD_ACCESS的错误。 假如你经常在模拟器上面测试的话，这个很长时间都可能不会发生，然而这种情况一般都是在很特殊的情况环境下就可能发生。所以这种类型的bug很难跟踪。
当然，在这种情况下，xcode已经警告你这个错误的格式化字符串，因此这个特别的bug是很容易发现的。但是无论什么时候，你使用c类型的字符串或者手动直接操作内存的，都应该非常的小心的不要混乱了其他的内存。
假如你非常的幸运，这个app将会经常崩溃，这个bug很容易找到，但是通常情况是这个app会崩溃在某个时候，而且这个问题很难重现!之后寻找这个bug将会是一个史诗般的工程，十分麻烦。
修复这个NSLog（）的形式，就像下面的一样：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
运行这个app，并且再一次点击这个按钮。现在这个NSLog（）做了他能做的了，并且看起来好像不会崩溃在buttonTapped:这个函数里面了。
和调试器交朋友（Making Friends With the Debugger）
看看这最近的崩溃，xcode指示到了这一行：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
在Debug窗口里面没有消息打印出来。你可以点击这个继续执行这个程序的按钮，就像前面一样，但是你也可以在调试器里面输入一个命令来得到这个错误消息。这样做的好处就是，这个app可以保持暂停在这个同样的地方。
假如你准备在模拟器里面运行这个，你可以在“（lldb）”提示的后面输入下面的：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
LLDB在xcode4.3或者之后的版本里面是默认的调试器。假如你正在使用老一点版本的xcode的话，你又GDB调试器。他们有一些基本的相同的命令，因此假如你的xcode使用的是“（gdb）”提示，而不是“（lldb）”提示的话，你也能够更随一起做，而没有问题。
“po”命令是“print object”（打印对象）的简写。“$eax”是cup的一个寄存器。在一个异常的情况下，这个寄存器将会包含一个异常对象的指针。注意：$eax只会在模拟器里面工作，假如你在设备上调试，你将需要使用”$r0″寄存器。
例如，假如你输入：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
你将会看像这样的东西：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
这些数字不重要，但是很明显的是你正在处理的NSException对象在这里。
你可以对这个对象调用任何方法。例如：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
这个将会输出这个异常的名字，在这里是NSInvalidArgumentException，并且：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
这个将会输出错误消息：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
注意：当你仅仅使用了“po $eax”，这个命令将会对这个对象调用“description”方法和打印出来，在这个情况下，你也会得到错误的消息。
因此解释下那是什么情况：你正在尝试执行一个名叫“ModalSegue”的segue，但是很显然，在MainViewController里面并没有这样的的segue。
Storyboard展示出来这个segue是存在的，但是你忘记了设置它的标示，一个典型的错误：
改变这个segue的标示为“ModalSegue”。再一次运行这个app，等待一下，点击这个按钮 ，这个时候不再有crash了！但是这里只是我们下个部分的开端——-tableview不应该是空的！
何去何从？
在第二部分的教程里面，我们将会遇到更多的bug。并且学习到更多关于调试的工具，包括NSLog()陈述，断点和僵尸对象。
泰然教程组出品，转载请保留出处并通知泰然！翻译：大侠自来也；校对：Iven
原文地址：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，就像下面一样：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
当你运行这个app时，你应该期望当我们点击了“Tap Me”按钮后在调试窗口看到“viewDidLoad is called”这样文字。现在就来试试，点都不惊讶，在调试窗口什么也没有出现。那就意味着ListViewController类根本没有被使用！
这个多半意味着，你可能忘记了告诉storyboard你想要为table view controller场景使用ListViewController类。
由上图我们可以看出，在身份检查器（Identity Inspector）的类属性区域是设置的默认值UITableViewController。改变这个Custom Class下面的class为ListViewController，然后再一次运行这个app。现在在调试窗口应该就会出现“viewDidLoad is called”文字：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
但是这次app将会再一次崩溃，但是却是一个新的问题。
注意：一旦你的代码好像没起什么什么作用的话，放置一些NSLog（）在确切的地方，来看看是否这个方法是被执行了的和cpu通过怎么样路径执行这个方法。使用NSLog（）来测试你假设将会执行的代码。
Assertion Failures
这个新的有趣的崩溃。它是一个SIGABRT，并且在调试窗口打印出来的是以下消息：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
我们得到的是一个执行UITableView的一些方法的一个“断言错误（assertion failure）”。当某些东西出错了之后，一个断言是一个内部相容性的检查器，并且会抛出一个异常。你也可以放置断言在你的代码里。例如：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
在上面的方法里面，我们让一个NSString对象作为这个函数的变量，但是代码却不允许调用者传递一个nil或者长度小于3的字符串。假如这些条件中的一个不匹配的话，这个app将会终止，并且抛出一个异常。
你可以使用断言来作为一个防御性编程技术，因此你应该确定这个就是我们想要的代码行为。断言通常只在调试编译下有用的，因此他们对发布到app store的最终的app是没有运行时的影响的。
在这个情况下，某些情况触发了一个UITableView的断言错误，但是你并没有完全确定在那个地方。App也是停止在main.m里面，并且在执行堆栈里面只包含了框架（framework）的方法。
从这些方法的名字，我们可以猜测这个错误发生在重画这个tableview的某些地方。例如，我们可以看到layoutSubviews和_updateVisibleCellsNow:这些名字的方法。
继续运行这个app来看看是否可以得到一些比较好的错误消息—–记住，现在只是在抛出异常的时候暂停了程序，并没有崩溃。点击继续程序按钮，或者在调试窗口键入下面的命令：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
你可能不得不多点击几次继续按钮，“c”命令也是一个简短的继续指令，和点击继续按钮一个效果，并不是就直接执行到最后。
现在这个调试窗口喷发出一些比较有用的信息：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
太好了，这是一个相当好的一个线索。显然这个UITableView的数据源没有从tableView:cellForRowAtIndexPath:方法返回一个有效的cell，因此在ListViewController.m方法里面增加一些调试输出信息来看看：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
你增加一个NSLog（）标记。再一次运行这个app，看看输出了什么：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
从以上信息我们可以看出，调用dequeueReusableCellwithIdentifier：返回的却是nil，这就意味着使用“Cell”作为标识符的cell可能不存在（因为这个app使用的是标准的cell的storyboard）。
当然，这也是愚蠢的bug，并且毫无疑问的是，在以前解决这个需要很长的时间，但是现在却不是了，因为xcode已经通过静态编译警告了你：“Prototype cells must have reuse identities。（标准的cell必须有重用的标识）”。这个是不能忽视的警告：
打开storyboard，选择这个标准的cell（在tableview的顶端，并且显示的是“Title”的单独的一个cell），并且设置cell的标识符为“Cell”：
将那个修复了之后，所以的编译警告应该没有了。运行这个app，现在这个调试窗口应该会打印出来：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
Verify Your Assumptions
你的NSLog（）打印出来的消息，已经告诉我们6个table view cell被创建了，但是在table上面什么都看不见。怎么回事呢？假如你在模拟器里面到处点击一下，你将会注意到tableview中6个cell中的第一个却能够被选中。所以，显然cells都是存在的，只是他们都是空的：
是时候需要更多的调试记录了。将先前的NSLog（）标记改变一下：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
现在你打印出来就是你的数据模块的内容。运行这个app，看看显示出来的是什么：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
上面的很好的解释了为什么在cell里面什么都没有看到的原因：因为这个文字（text）始终是nil。然而，假如你检查你的代码，并且在initWithStyle：方法里面显示的添加了很多的字符串到list array里面：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
就像上面那样，这是测试你的假设是不是正确的一个很好的方法。可能你还想更准确的看看这个array里面到底有什么东西。改变先前在tableView:cellForRowAtIndexPath:里面的NSLog（）为这样：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
至少这样可以给你展示一些东西。运行这个app。假如你还没准备好猜测会发生什么情况，调试窗口已经给你打印出来了：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
哈哈，你的脸色瞬间阴沉下来。上面的代码居然没有起作用，因为你可能忘了在首先为这个array对象申请内存空间。这个“list”所以一直为nil，因此调用addObject: 和objectAtIndex:不会起任何的作用。
你应该在你的view controller被装载的时候为这个list对象分配空间，因此在initWithStyle:方法里面应该是一个不错的选择。修改那个方法为：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
试一试。我晕，依然什么都没有！调试窗口输出依然是：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
经过了这么多假设和修改，但是还是什么都没有，这些真的是非常令人沮丧啊，但是请记住你可能会一直继续到最后，直到你弄清楚了所有的假设。所以现在的问题就是难道initWithStyle:没有被调用？
Working With Breakpoints
你可能又会在代码里面放置另外一个NSLog（）标志，但是其实你完全可以使用另外的工具：断点（ breakpoints）。你已经看到过无论什么时候只要有异常抛出的时候，程序就会终止的异常断点（Exception Breakpoint）了。你其实也可以增加其他的断点，并且可以放置到代码的任何地方。一旦你的程序运行到断点的地方，这个断点就会被触发，并且程序就会进入调试模式。
你可以通过点击代码编辑区前面的行号来放置特殊的断点：
这个蓝色的箭头所指示的那一行就有一个断点了。你也可以在断点导航器（Breakpoint Navigator）里面看到这个新的断点：
再一次运行这个app。假如initWithStyle:确实是会被调用的话，那么你点击了“Tap Me！”按钮之后，当这个ListViewController被装载的时候，这个app将会暂停，并且会进入调试器。
可能正如你所料的，什么事情也没有发生。initWithStyle:没有被调用。其实这个是可以讲得通的，因为view controller是从storyboard（或者xib）中装载的，所以使用的应该是initWithCoder:方法。
将之前initWithStyle:方法替换为initWithCoder:：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
并且保持断点在这个方法上面，来看看它是怎么工作的：
一旦你点击了那个按钮，这个app将会进入调试器：
以上的情况并不是意味着这个app崩溃了！它只是在这个断点处暂停了。在左边的执行堆栈里面（假如你没有看到执行堆栈的话，你可能需要切换到调试导航器），你可以看到你是从buttonTapped：到这里的。这个调试导航器里面，我们看到执行了一系列的UIKit的方法，并且装载了一个新的view controller。（顺便说句，断点是一个非常好的工具来指出这个系统是怎么工作的。）
如果想要离开你之前停留的地方，继续运行这个程序，简单的就是点击继续程序运行按钮，或者在调试控制台中输入“c”。
显然的是，一切并没有如我们料想的一样，这个app又奔溃了。我告诉过你，它有很多bug的。
注意：在你继续之前，在initWithCoder：移除断点或者使断点无效。因为他已经展现了他的目的，所以现在它可以离开了。
你可以在显示行号的的地方右击断点，并且在弹出的菜单中选择删除断点。你也可以拖出这个断点离开窗口，或者在断点调试器里面移除。
假如你并不想移除这个断点，你可以简单的使断点无效。为了达到这个目的，你可以使用右击弹出菜单，或者左击一次这个断点。判断这个断点是否有效，你可以看看这个断点的颜色，当为浅蓝色了就是无效了，深蓝色就是有效的。
Zombies！
回到这个崩溃。它是一个EXC_BAD_ACCESS，幸运的是调试器指到了他发生在那里，在tableView:cellForRowAtIndexPath:
这是一个EXC_BAD_ACCESS崩溃，意味着在你的内存管理里面有bug。不像SIGABRT，你将不会得到很明朗的错误消息。然而你可以使用一个让你看到曙光的调试工具：Zombies！
打开这个项目的scheme editor：
选择Run 选项，然后选择Diagnosics标签。勾上Enable Zombie Objects选项：
现在运行这个app。这个app仍然崩溃，但是现在你将会得到下面的错误消息：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
上面这个就是zombie enable 工具所做的，做个小概括:无论什么时候你创建了一个新对象（通过发送“alloc”消息），一块内存将会为这个对象的实例变量保留。当这个对象被释放，他的保留计数（retain count）变成0，这块内存将会被释放。
但是，你可能仍然有许多的指针指向这个已经失效的内存，这些都是建立在假设这里有一个有效的对象存在的情况下。假如你程序的某些部分试着使用这个野指针，这个app将会伴随着EXC_BAD_ACCESS的错误崩溃掉。
（假如你是很幸运的话，这个程序将会崩溃。假如你没那么幸运的哈，这个app将会使用这个死亡的对象，各种各样的破坏可能相继发生，特别是某个指针所指向的这个内存区域已经被一个新的对象重新分配了。）
当这个zombie工具被启用之后，即使这个对象被释放了，这个对象的内存也不会被清理。所以，那块内存将会被标记为“长生不死的”。假如你试着之后又去使用这块内存，这个app能够意识到你的错误操作，并且app将会抛出“message sent to daellocated instance”错误并且终止运行。
因此这就是之前发生的事。这行就是使用了不死的对象：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
这个cell对象和他的textLabel应该是好的，那么indexPath也应该是正确的，因此我猜测在这个问题下，这个不死的对象应该是“list”。
你多半其实已经有个很好的线索来怀疑这个“list”，因为这个错误消息说：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
这个不死的对象的类是__NSArrayM。假如你已经有一段时间的cocoa编程经验，你应该就会知道一些基本的类，就像NSString和NSArray实际上是“class clusters”，这就意味着就像NSString或者NSArray这些原始的类在一些底层的地方会被特殊的类代替。所以在这里你可以看到一些NSArray类型的对象，也就是这个“list”其实应该是一个NSMutableArray。
假如你却是想要确认一下，你可以增加一个NSLog()在分配了“list”数组那行代码之后：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
这里将会打印出和错误消息一样的内存地址（在我这里的情况下是0x6d84980，但是你自己测试的时候，地址就会不一样的）。
你也可以在调试器里面使用“p”的命令来打印出这个“list”变量的地址（和这个相对的命令就是“po”，这个命令将会打印出这个实际的对象，而不是地址）。这样方便的地方就是你可以省略很多额外增加NSLog（）的步骤和从新编译这个app、class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
注意：非常不幸的是，上面这些命令在xcode4.3里面并没有执行的很好。由于一些原因，这个地址一直都是展示的0×00000001，可能是因为这个class cluster吧。
在GDB调试器下面，那些命令就执行的很好，在调试器的变量窗口展示出“list”都是zombie。因此我觉得这个是LLDB的bug。
为这个list 数组分配空间的地方就在initWithCoder:，就是下面这样：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
由于这里不是ARC（Automatic Reference Counting）(自动引用计数)项目，所以是人工管理内存，所以这里你需要retain这个变量：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
为了避免内存泄露，你也不得不在dealloc函数中释放这个对象，就像下面这个：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
再一次运行这个app。它又崩溃在这同样的一行，但是注意这个调试窗口输出的东西改变了：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
由上面信息可以知道这个array已经分配了内存空间和包含了字符串的。这个崩溃的提示不再是EXC_BAD_ACCESS，而是SIGABRT，所以你需要再一次设置这个Exception Breakpoint。将这个解决了，继续找其他的bug！
注意：即使你使用了ARC，在这样的内存管理错误下也是一个非常大的事，你也会崩溃，得到一个EXC_BAD_ACCESS的错误，特别是假如你使用了不安全保留属性。
我的小提议：无论你什么时候得到一个EXC_BAD_ACCESS错误，你都可以开启zombie objects，然后再试试。
注意一点：你不应该一直启用zombie objects。因为这个工具将永远不会释放内存，只是简单标记一下这个内存是不死的，你最终将会在某个时候耗尽所有的内存。因此你应该在排查内存相关的错误的时候才开启zombie objects，其他时候应该关闭它。
Stepping Through the App(单步调试)
使用断点来解决这个新的问题。将断点放置在刚刚崩溃那一行：
重新运行这个程序，点击按钮。你将会在第一次执行tableView:cellForRowAtIndexPath:的时候进入调试器。注意啊，这个时候，app只是因为断点暂停了，并没有崩溃。
你想要准确的知道这个程序崩溃时的一些细节。请点击继续执行按钮，或者在（lldb）的提示后输入“c”来继续执行。程序将会从暂停的地方继续执行。
什么事情也没有发生，你仍然暂停在tableView:cellForRowAtIndexPath:这个函数的断点处。但是在调试窗口却显示：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
这就意味着tableView:cellForRowAtIndexPath:在第一次执行的时候没有任何问题，因为NSLog（）在断点之后执行了。因此这个app能够很好地创建第一个cell。
假如你键入以下的到调试提示之后：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
在调试窗口应该可以输出下面的：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
以上重要的部分是[0, 1]。就是这个NSIndexPath对象为section 0和row 1。换句话说，这个tableview现在就在请求第二行。从这里我们可以推测这个app在第一次创建cell的时候没有任何问题，正如刚刚这里就没有发生崩溃。
多点几次这个继续按钮。在某一个特定的时候，这个程序崩溃了，并且输出一下错误消息:class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
假如你检查这个indexpath对象的话，你可以看到：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
Section依然是0，但是这个row的索引是5。注意哦，这个错误的消息也是说“index 5”。因为计数是从0开始的，当到5的时候实际上意味着已经是6的位置了。但是这里只有5项。显然这个tableview认为这里实际上有更多的行。
所以这个犯人就是下面的方法：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
这个方法其实应该被写成这样的：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
删除断点或者使断点无效，然后再次运行这个程序。终于这个tableview显示出来了，并且没有了崩溃！
注意：这个“po”命令对于检查你的对象是非常有用的。你可以在程序暂停在调试器的时候，或者在设置一个断点的时候，或者在崩溃的时候，使用这个命令。你需要确定的是这个方法当前在调用堆栈里面是高亮的，否则这个调试器将找不到这个变量。
你也可以在调试窗口的左边看到这些变量，但是就算看到了也不是很方便就能知道细节的：
Once more， with feeling
我刚刚说了没有崩溃的现象了？好，现在我们来试试滑动删除。这个app又终止了在tableView:commitEditingStyle:forRowAtIndexPath:
错误消息是：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
这个错误看起来像是来自UIKit，并不是来自app的代码。多次输入几次“c”来让系统抛出异常，这样可以你可以得到更多有用的信息：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
经过这些，上面给你一个非常漂亮的解释。这个app告诉这个tableview里面一行要删除，但是某人却忘记从数据源里面移除这行的数据。因此这个table view看起来没有什么改变。修改这个这方法：class="wp-code-highlight prettyprint linenums:1 prettyprinted" />
太好了，看起来这样做起效了，你终于有一个不会崩溃的app了。
Where to go from here？(何去何从)
记住下面几点：
假如你的app崩溃了，第一件事就是找到是哪里崩溃了，为什么崩溃了。一旦你知道了这两点，修复这个崩溃就很简单了。调试器可以帮助你，但是你需要知道怎么样让他帮助你。
有些崩溃可能是随机出现的，这个也是最困难的一个，特别是当你正在使用多线程。但是大多数，你可以试试，会发现一些固定的方法来让你的程序每次崩溃。
你可以想出怎么使用最少的步骤来减少崩溃的现象，这样你将找到一个好的方法来修复这个bug（也就是说他将不会发生）。但是假如你没有确定不会再生了这个错误，你就绝不能确定你的修改已经修复了这个bug。
秘诀：
1.假如崩溃在main.m里面，就可以设置全局异常断点（Exception Breakpoint）。
2.在异常断点开启的状态下，你也没有得到得到有用的信息。在这种情况下，多继续几次运行这个app，或者在调试提示后面输入“po $eax”命令。
3.大多数崩溃的一般原因和一些bug都是在你的xib中或者storyboard中的连接丢失了或者是错误的连接。这些情况不会在编译错误里面显示，因此你一般不知道。
4.不要忽略编译警告。假如你有编译警告，就说明你有些东西可能会出错。假如你不知道为什么你会到一个编译警告，最好去搞明白它. 这些都是安全的做法!
5.在设备上调试可能会和在模拟器上面有些微的不同。这两个环境不是完全一样，你将会得到不同的结果。
例如，当你运行一个有问题的程序在iphone4上的时候，这第一个崩溃就会发生在NSArray初始化的时候，因为你缺少一个nil标记，而不是会因为当这个app执行setList：的时候的时候崩溃。所以说上面那个原则方法就可以帮你找到崩溃问题的根源本质。
不要忘记静态分析工具（static analyzer tool），这个工具将会捕获更多的错误。假如你是一个初学者，推荐你开启它。你可以在Build Settings界面上为你的工程设置：
调试愉快吧！
Continue reading 【转】当程序崩溃的时候怎么办
