Android系统耗电异常怎么解决

若使用的是vivo手机，Android系统是多个功能和服务的集合体，比如权限管理、蓝牙设置、电话服务、指纹与密码等常用功能有关的耗电会被计入Android系统，如果第三方软件使用到这些功能，电量也会被计入Android系统，所以我们看到Android系统程序耗电较高，实际和第三方软件的使用情况有关，您可以使用“一键加速”清理后台不必要的程序，适当调低屏幕亮度和音量；另外进入设置--电池，根据手机电量情况选择合适的省电模式，延长手机续航时间。

在芮城等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供网站制作、网站建设 网站设计制作按需网站设计,公司网站建设,企业网站建设,成都品牌网站建设,全网营销推广,外贸网站建设,芮城网站建设费用合理。

Android开发常见异常与错误系列（一）

一、前言

这系列文章是自己在平时开发过程中遇到的问题。之前只是记在云笔记上面，现在整理一下，发出来共享。

ps:像那些什么没有注册Activity呀，权限呀等最基本的就不再赘述。

二、ADB连接异常

有时我们发现，即使自己从任务管理器里面把adb.exe给干掉了，但还是不行，这时，你就可以尝试以下操作：

[2014-07-30 17:09:11 - QtActivity] The connection to adb is down, and a severe error has occured.

[2014-07-30 17:09:11 - QtActivity] You must restart adb and Eclipse.

[2014-07-30 17:09:11 - QtActivity] Please ensure that adb is correctly located at ‘D:\InstallFile\AndroidDevelop\ADT\sdk\platform-tools\adb.exe’ and can be executed.

adb起动失败：

1，杀掉其它的adb.exe看，如果不行，

2，看sdk\tools路径下面有没有

hprof-conv.exe

如果有，则把它复制到sdk\platform_tools下

3，如果没有，刚看sdk\platform_tools下有没有

hprof-conv.exe

如果有，刚复制到tools下。

4，如果两者都没有，刚下一个

hprof-conv.exe

三、java.lang.IllegalStateException: Activity has been destroyed

这个异常在切换Fragment中比较容易出现，稍不注意就会出现如下异常：

FATAL EXCEPTION: main12-0909:20:14.689: E/AndroidRuntime(31223): java.lang.IllegalStateException: Activity has been destroyed12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.FragmentManagerImpl.enqueueAction(FragmentManager.java:1365)12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.BackStackRecord.commitInternal(BackStackRecord.java:595)12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.BackStackRecord.commit(BackStackRecord.java:574)12-0909:20:14.689: E/AndroidRuntime(31223): at cn.com.topsky.community.tfd.DongTaiFragment.init(DongTaiFragment.java:209)12-0909:20:14.689: E/AndroidRuntime(31223): at cn.com.topsky.community.tfd.DongTaiFragment.onCreateView(DongTaiFragment.java:68)12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.Fragment.performCreateView(Fragment.java:1500)12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:927)12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1104)12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.BackStackRecord.run(BackStackRecord.java:682)12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:1467)12-0909:20:14.689: E/AndroidRuntime(31223): at android.support.v4.app.FragmentManagerImpl$1.run(FragmentManager.java:440)12-0909:20:14.689: E/AndroidRuntime(31223): at android.os.Handler.handleCallback(Handler.java:605)12-0909:20:14.689: E/AndroidRuntime(31223): at android.os.Handler.dispatchMessage(Handler.java:92)12-0909:20:14.689: E/AndroidRuntime(31223): at android.os.Looper.loop(Looper.java:154)12-0909:20:14.689: E/AndroidRuntime(31223): at android.app.ActivityThread.main(ActivityThread.java:4624)12-0909:20:14.689: E/AndroidRuntime(31223): at java.lang.reflect.Method.invokeNative(Native Method)12-0909:20:14.689: E/AndroidRuntime(31223): at java.lang.reflect.Method.invoke(Method.java:511)12-0909:20:14.689: E/AndroidRuntime(31223): atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:809)12-0909:20:14.689: E/AndroidRuntime(31223): atcom.android.internal.os.ZygoteInit.main(ZygoteInit.java:576)12-0909:20:14.689: E/AndroidRuntime(31223): at dalvik.system.NativeStart.main(Native Method)

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

经查，说这个是当前android-support-v4版本的一个bug,因为在当fragment进行到detached状态时，它会重置它的内部状态。

然而，它并没有重置mChildFragmentManager.这导致在Fragment重新attach时，它(fragment)没有重新attachm childFragmentManager，从而引发了上面的异常.

解决方案：

在每个调用getChildFragmentManager()的fragment中复写onDetach()方法：

@OverridepublicvoidonDetach() {super.onDetach();try{Field childFragmentManager = Fragment.class.getDeclaredField("mChildFragmentManager");childFragmentManager.setAccessible(true);childFragmentManager.set(this,null);}catch(NoSuchFieldException e) {thrownewRuntimeException(e);}catch(IllegalAccessException e) {thrownewRuntimeException(e);}}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

四、java.lang.IllegalArgumentException: Illegal character in query at index

这个异常，在我们拼接请求参数时，可能会碰到，原因是里面的特殊字符转换异常。解决办法如下：

url转换问题

String url = baseUrl + “?” + “name=” + name + “age=” + age;

url = url.replaceAll(“”, “%26”);

url = url.replaceAll(” “, “%20”);

解释如下：

特殊符号替换符号

?%3F

%26

|%124

=%3D

#%23

/%2F

+%2B

%%25

空格%20

五、eclipse连接小米2S调试程序的问题

虽然快2年没用过eclipse了，但这个问题还是贴出来，也许正好有正在用eclipse的同学遇到了此问题：

小米Mi2S连接到eclipse上无法识别。即使开启了调试模式，也无法识别.终于找到了一个可用的方法。

方法

用数据线连接手机和电脑。

打开手机拨号界面。

在拨号界面按 # #717717# # 自动就开启了。

在通知栏会出现一个 Diag USB port enable。

当然，应该是需要ROOT权限的。

这时候你的PC机会弹出安装设备驱动。

如果不成功，多插拔几次试试。

ok！安装完就搞定了！这时候打开eclipse就会在Driver里面看到你的手机了。

注意事项

在PC机上安装新硬件向导时候可能会遭遇到缺少dll文件，比如我就遇到缺少了WinUSBCoInstaller2.dll，这个问题。这时候就要去网上找找喽。这个东西分x64 和 x86的，注意不要搞错了！

如果先打开eclipse，再安装的话，可能导致eclipse挂掉，不明原因，可能是我机器配置不行。两次均有这种状况。所以建议先安装后再开eclipse。

Android BLE蓝牙连接异常处理

蓝牙通信过程中异常很常见，大致有以下几种：

1，连接

2，发现服务

3，读写

4，通知

连接失败可能是设备端原因，也可能是手机端原因。不同的手机来自不同的厂家，用的不同的芯片和蓝牙协议栈都会导致蓝牙功能的表现不一致，这都会导致各式各样的兼容性问题，可能有的手机连接成功率高，有的成功率低。设备端原因可能有些时候出现异常导致死机无响应，或某些参数设置得有问题。但对于Android应用层开发来说，能做的很有限，蓝牙通信是在系统服务进程中处理的，我们无法跨进程改变系统的行为，如果是在一个进程我们还可能通过Hook等手段来调整其内在逻辑。另外应用层的接口只是将请求封装传递给系统服务进程，并未做一些实质性的通信，所以应用层虽然是同一个进程的，但是Hook意义也不大。所以我们能做的仅仅是看怎样调整接口的调用，使得整体稳定性更好一点而已。

连接失败分两种，一种是超时，一种是提前返回失败。

关于超时，一般是设备不在周围，或设备断电未发广播，或设备当前被其他人连接。系统默认超时为30s，通常返回133，我们也可以自己设置更短的超时时间，超时则closeGatt，然后重新连接。

关于提前返回失败，一般是有明确的异常，可能是手机蓝牙的异常或者设备异常。

这两种情况建议closeGatt，延时500ms，然后重试。如果重试三次仍然失败，则可以考虑提示用户重启手机蓝牙，或者检查设备是否正常工作。

还有一种情况，连接成功后没过多久连接又断开了，这有可能是设备主动断开，连接成功后有的设备会等待鉴权，如果一定时间内手机端还未发起鉴权则设备端主动断开。也可能连接信道不够稳定导致断开的，此时closeGatt并重新连接即可。

当连接断开时，会收到onConnectionStateChanged回调，这个回调可能会有一定延时，甚至有5s以上。解决的办法是轮询，如每隔1s发起一次读请求，如果连接断了会立即返回失败。

如果蓝牙连接不稳定，可以考虑关掉WIFI，因为WIFI通常和蓝牙共用一个天线。

有的手机上discoverService可能会回调不止一次onServiceDiscover，这个要注意防御。

当连接建立后，可以由设备端发起更改连接间隔，这样能加快后续发现服务以及数据读写的速度。有的手机discover service很慢，原因是connect interval太大了，有的手机会主动向设备发起更改connect interval，而有的手机却不会。这样的话connect interval相差就会很大，实践中发现有的手机是7ms，有的手机是默认的50ms，所以发现service都要8s，甚至20s的都很寻常，这对用户来说是无法忍受的。所以比较好的办法是设备主动发起更改connect interval，而Android系统是没有提供对应API的。

如果发现服务失败，通常来说不用closeGatt，重试一下就好了。如果重试三次还失败，建议清一下缓存，再closeGatt，重新连接。

读写失败要看失败的原因是什么，如果是权限问题，则需要和设备端确认是否开放了相应的读写权限。也可能是要读写的character不存在，可能是设备端修改了固件，手机端需要刷新一下蓝牙缓存，closeGatt再重新连接。如果是其它未知错误，则重试三次，仍然失败则closeGatt。不过通常来说如果是因为连接出了问题导致读写失败的，会收到onConnectionStateChanged回调，此时就不用再无谓的重试了，直接closeGatt，重新连接。

打开/关闭character的notify，必须等收到onDescriptorWrite回调之后才算结束，才能开始下一个任务。

如果打开notify失败，则可以改成周期性轮询的方式去查询character的值。

可参考该文章

Android-BLE-Issues

Android开发 - 处理 null 和 预防空指针异常(NullPointerException) 的一些经验

在实际编码中总是会遇到 空指针异常 ，本文总结了一些处理空指针的个人经验。

尽早的检查，尽早的失败。

比如： 通过intent传参到新的目标 activity，而且一定需要这个参数，那么在新的目标activity中 onCreate方法中 判断中这个参数，如果null，直接抛出空指针异常让程序崩溃。取代在使用该参数时进行检查，这样能更早的发现问题。或者在 一个普通的方法中，一个 参数必须不能为null ，那么我们在这个方法的第一行就做出判断，如果参数为null，抛出空指针异常。

1.不要在Set中使用null

2.不要把null作为map的键值。

3.尽可能的尽早检查，如果为 null 不执行或者 结束本方法

4.遇到必须的参数，比如通过intent传参到新的目标 activity，而且一定需要这个参数，那么在新的目标activity中判断是否有参数

5.判断字符串是否空

6.对字符串比较时，如果和常量进行比较，把常量放在前面，比如：

7.将某个对象 toString时，比如：

8.使用注解 @NonNull 和 @Nullable 配合AndroidStudio 帮你检查你是否没有检查可能为null的对象，或者你是否做了多余的检查。

9.我们引用Guava来帮忙检查 null 的情况，我们使用 checkNotNull 方法来替代写 if( obj == null) throw new NullPointExcetion(); ，示例：

Guava是什么：

网站标题：android异常,android异常分类有哪四种
转载注明：http://kswjz.com/article/dsidoeo.html