转自http://blog.csdn.net/johnjobs/article/details/8102787
java.lang.RuntimeException: Unable to start activityComponentInfo{com.example.newsreader/com.example.newsreader.NewsReaderActivity}: android.view.InflateException: Binary XML file line #45: Error inflating class fragment,这个错误是在做一个android的多屏幕设计的时候运行时发生的。
这个错误说的很清楚,无法启动组件详情。并在下面报出了at com.example.newsreader.NewsReaderActivity.onCreate(NewsReaderActivity.java:79),在onCreate初始化的时候,setContentView(R.layout.main_layout);的时候,报错了。于是我在这行打断点之后发现,这行的时候,main_layout并不是我设置的那个布局页面,于是我开始有些明白了,因为我的项目是为了适配所有的屏幕大小的,所以我的这个main_layout并不是一个具体的xml布局,而是指定的一系列布局的引用。当我改成具体的简单无误xml布局后,该错误就没有了。
后来,经查阅资料发现,我已知的,有下面几类情况发生时,会报出这个错误:
1.setContentView()中指定的布局对象不是具体布局文件,而是一个引用,而该引用或许存在错误。系统加载时因不能分辨故而运行时异常
2.指定的xml是一个具体的布局文件,但是布局文件写的不对,如标签结束不对,<imageView>标签的结束不对,即组件使用方式不对
3.引用的资源未初始化,导致运行时异常,如R.string.XXX或者R.resource.XXX
4.指定的布局xml既是具体的一个xml,其中的组件也没错,再来引用资源也是对的,那么,唯一可能的就是这个布局view中引用的图片的尺寸太大,设备无法识别,固然运行时异常。
ps:以上的错误我都是在模拟器上运行所得的,手机或平板上并未测试,可能不具备代表性。观点也是个人之见,不知道是否正确,如有不对,欢迎指正。
另有:http://k-beta.com/android-os-networkonmainthreadexception.html
今天在使用nexus s测试android应用程序时,发现,在连接网络时,竟然出现了个android.os.NetworkOnMainThreadException异常。仔细查阅代码之后,发现和书上或者网络上的代码是一致的,而且也已经在AndroidManifest.xml中经过授权。但是,后台仍然抛出了如下异常:
LogCat提示,系统抛出了android.os.NetworkOnMainThreadException异常。经过反复实验,发现,当我们用数据流方式获取网络资源(比如一个页面的源文件)的时候,系统会抛出此异常通过查阅相关资料,发现,自从Android 2.3之后,系统增加了一个类:StrictMode。这个类对网络的访问方式进行了一定的改变。Android的官方文档给出了这个类设置的目的:StrictMode是一个系统提供的开发工具,用以检测在开发过程中因为偶然的事故从而造成的系统潜在的问题,进而提示开发者对其进行修复。StrictMode通常用于捕获磁盘访问或者网络访问中与主进程之间交互产生的问题,因为在主进程中,UI操作和一些动作的执行是最经常用到的,它们之间会产生一定的冲突问题。将磁盘访问和网络访问从主线程中剥离可以使磁盘或者网络的访问更加流畅,提升响应度和用户体验。显然,大多数初学者在进行网络开发时,会选择将访问网络的代码直接放到主进程中,由于和主进程的首要工作——UI交互——相矛盾,因此,必须设置一定的检测机制,以保证系统运行的流畅,所有的异常都可以被检测。Android文档建议我们增加这两条命令:
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectDiskReads()
.detectDiskWrites()
.detectNetwork() // or .detectAll() for all detectable problems
.penaltyLog()
.build());
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
.detectLeakedSqlLiteObjects() //探测SQLite数据库操作
.penaltyLog() //打印logcat
.penaltyDeath()
.build());
现在让我们看看它们都是做什么的。
public static voidsetThreadPolicy(StrictMode.ThreadPolicy policy)
这个方法允许我们为当前应用设置一组线程运行策略机制。其中的参数是一个策略组(即一组策略)。
public static finalclass StrictMode.ThreadPolicy.Builder()
Builder是StrictMode中内嵌类ThreadPolicy的一个内嵌类,在此我们调用了它的默认构造方法。
detectDiskReads().detectDiskWrites().detectNetwork().penaltyLog().build()
通过这种方式,我们设置了一组监控模式,我们要检测磁盘的读写,网络的访问, Log中的违规等。
第二条语句设置了虚拟机的一组监控策略,参数一致,因此不再赘述。
这样,在保证了网络和磁盘访问受控之后,主线程就允许我们对网络资源进行访问。
最后,需要说的是,策略限制只需要在主线程运行开始阶段,也就是onCreate刚被调用的时候使用添加,其后的所有方法都将遵循这一规则。
http://geeksun.iteye.com/blog/1447708
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
// 启动线程执行下载任务
new Thread(downloadRun).start();
}
/**
* 下载线程
*/
Runnable downloadRun = new Runnable(){
@Override
public void run() {
// TODO Auto-generated method stub
updateListView();
}
};