Android fatal signal 11 sigsegv at 0x00000030 code 1 错误分析解决

fatal signal 11 sigsegv at 0x00000000 code 1这条代码很难搞，程序什么问题都没有，也没有很多的错误代码，就一条。看起来很棘手！

在android里面，这个代码代表了内存错误，我的是出在了数组的越界。但是你根本看不出来，假如你是新手。

我的业务情况是这样子的，我自己写了一个View类，继承了View，里面有个ondraw回调函数，这个函数是画图回调函数，当界面加载你自定义的View时会回调这个函数，这个函数，比mainActivity的oncreate函数的回调时间要晚，因为我是把View放在了xml布局文件里面。总的来说顺序是，xml文件加载-->View的构造函数-->mainActivity的oncreate-->View的ondraw回调函数。我在View组件里面写了一个传递数值的函数，代码如下：

public synchronized void setProgress(int progress, int N) {
		
		if ((progress / 4) != this.progress) {
			this.progress = progress / 4;
			this.progressWhich = N;
			
		SquareProgressBar.this.postInvalidate();
		}
	}

这段代码，里面的postinvalidate函数会在非UI线程内重绘view组件，也就是回调ondraw，问题出在ondraw里面，我在里面定义了一个float型的数组，当我开启新线程不断定时传入progress的时候，会回调ondraw，其实当数组溢出，你是看不出来的，因为溢出不是在java层，不会报错。

解决办法，在你出错的activity的头标签上加上一条 android:hardwareAccelerated="true"

这样虽然不能解决问题，但是但是发生在底层的数组越界错误会在log中打印出来，你就可以立马发现了。这条语句的作用是硬件加速。官方有给出解释！

Hardware acceleration is enabled by default if your Target API level is >=14, but can also be explicitly enabled. If your application uses only standard views and Drawables, turning it on globally should not cause any adverse drawing effects. However, because hardware acceleration is not supported for all of the 2D drawing operations, turning it on might affect some of your custom views or drawing calls. Problems usually manifest themselves as invisible elements, exceptions, or wrongly rendered pixels.

所以，这个只是发现这种类型错误的一种比较笨拙的办法，我测试了一下，可以发现数组越界，但是其他的就不清楚了，假如不知道你的症状，你可以试一下！但是，这条语句会使硬件加速，你可以从打印信息上看出来，一般在发现错误的同时，假如你不事后去掉，如果你数据库开关频繁，会导致程序崩溃。只是本人的一点点心得，针对底层数组越界难以被发现。