接上篇文章:Android开发常见异常与错误系列(一)
运行在Linux系统上的Java程序可能会出现”Too many open files”的异常情况,且常见于高并发访问文件系统,多线程网络连接等场景。
程序经常访问的文件、socket在Linux中都是文件file,系统需要记录每个当前访问file的name、location、access authority等相关信息,这样的一个实体被称为file entry。“open files table”(图中橙色标识)存储这些file entry,以数组的形式线性管理。文件描述符(file descriptor)作为进程到open files table的指针,也就是open files table的下标索引,将每个进程与它所访问的文件关联起来了。
每个进程中都有一个file descriptor table管理当前进程所访问(open or create)的所有文件,文件描述符关联着open files table中文件的file entry。细节不表,对于open files table能容纳多少file entry。Linux系统配置open files table的文件限制,如果超过配置值,就会拒绝其它文件操作的请求,并抛出Too many open files异常。这种限制有系统级和用户级之分。
系统级:
系统级设置对所有用户有效。可通过两种方式查看系统最大文件限制
1 cat /proc/sys/fs/file-max
2 sysctl -a 查看结果中fs.file-max这项的配置数量
如果需要增加配置数量就修改/etc/sysctl.conf文件,配置fs.file-max属性,如果属性不存在就添加。
配置完成后使用sysctl -p来通知系统启用这项配置
用户级:
Linux限制每个登录用户的可连接文件数。可通过 ulimit -n来查看当前有效设置。如果想修改这个值就使用 ulimit -n 命令。
对于文件描述符增加的比例,资料推荐是以2的幂次为参考。如当前文件描述符数量是1024,可增加到2048,如果不够,可设置到4096,依此类推。
在出现Too many open files问题后,首先得找出主要原因。最大的可能是打开的文件或是socket没有正常关闭。为了定位问题是否由Java进程引起,通过Java进程号查看当前进程占用文件描述符情况:
Java代码
lsof -p javapid每个文件描述符的具体属性lsof−p java_pid | wc -l 当前Java进程file descriptor table中FD的总量
分析命令的结果,可判断问题是否由非正常释放资源所引起。
这也是刚开始从事android开发时遇到的问题。贴出来纪念一下:
今天 在更新apk时,在安装到最后一步的时候,它突然报“已安装了存在签名冲突的同名数据包”;
开始以为是我签名有问题,所以就围绕着这个keystore就瞎折腾了一上午,后面,突然发现,其实我的签名是正确的,不存在任何问题。
原因如下:
因为我自己手机上的所有版本都是在eclipse上直接运行的,没有问题后,再放到服务器上的,
而eclipse它有自己默认的签名:debug.keystore,
但是我放到服务器上的apk的签名则是自己定义的,**.keystore,
因此,当我要从服务器上把最新版本更新到我手机上由eclipse安装的旧版本时,由于两者的签名不同,所以就会报“已安装了存在签名冲突的同名数据包”的错误。
这个如果理解了View的事件派发,就很容易了,无奈当时是小白呀,一穷二白的,
一句话,如果点击没反应,肯定事件被派发下去了,即子控件去处理了。解决办法:
1、可以自定义ListView,重写onTouch方法,使其返回return false,即事件不派发,由自己处理。
2、不自定义ListView的话,可以让item布局中的子控件不具有焦点。即onFocus = false
enum constant INSTANT_RUN_REPLACEMENT does not exist in class com.android.manifmerger.ManifestMerger2 Invoker Feature
这个问题经常会在gradle build 构建失败的时候出现。原因是从缓存文件tashArtifacts.bin中读取元素时失败,因为tashArtifacts.bin被锁住了,找到其所在项目的文件目录:E:\studio_workspace\CGlass.gradle\2.10\taskArtifacts
把目录下的cache.properties.lock删掉,就ok了。
这个错误一般是在Activity里面嵌套Fragment,采取commit()来操作事务时出现。
错误提示的意思:不能在Activity保存状态后调用此方法。
下面看下源码的注解:
/**
* Schedules a commit of this transaction. The commit does
* not happen immediately; it will be scheduled as work on the main thread
* to be done the next time that thread is ready.
*
* class="note">A transaction can only be committed with this method
* prior to its containing activity saving its state. If the commit is
* attempted after that point, an exception will be thrown. This is
* because the state after the commit can be lost if the activity needs to
* be restored from its state. See {@link #commitAllowingStateLoss()} for
* situations where it may be okay to lose the commit.
*
* @return Returns the identifier of this transaction's back stack entry,
* if {@link #addToBackStack(String)} had been called. Otherwise, returns
* a negative number.
*/
public abstract int commit();
大概意思如下:
commit()方法的调用应该在Activity保存它的状态前完成,反之,则会抛出异常。这是因为如果commit()在Activity保存自身状态后再调用的话,Activity的状态可能被销毁,从而导致Activity无法从onSavedInstanceState中去恢复状态而crash。 而解决这个问题的方法,就是调用commitAllowingStateLoss()。
下面看下commitAllowingStateLoss()方法的注解:
/**
* Like {@link #commit} but allows the commit to be executed after an
* activity's state is saved. This is dangerous because the commit can
* be lost if the activity needs to later be restored from its state, so
* this should only be used for cases where it is okay for the UI state
* to change unexpectedly on the user.
*/
public abstract int commitAllowingStateLoss();
意思就是:这个方法允许在Activity保存状态后调用。其实就相当于是commit方法的一个补丁吧。
这以前是没问题,可能是前两天我更新了Android SDK 至最新版本,然后genmotion自带的sdk版本比AndroidStudio的版本低,就造成这个问题。
因此:解决办法,打开Genymotion客户端—》Settings—>ADB—->User custom Android SDK tools,选则自己本地的sdk路径,重启Genymotion,搞定。
未完待续!!!!!!!