最近博客写的少了，以后还得经常更新才行。
------------------------------------------------------------
1.特定业务需求下try cath 异常需要catch可能的RuntimeException，否则可能出现catch不全导致的意外问题（如app崩溃）。
之所以将此问题放在第一位，是因为前阵子中项目中出现了此类情况，并且这种情况很容易不注意或遗忘，但其错误却是致命的。
在Java/Android开发中，当调用一个函数时，此函数抛出一个A类型的异常，很自然的，在调用的地方我们会try.. catch此异常，并且绝大多数情况下，捕获异常是由Eclispe自动提示并生成的，函数抛出A异常，则调用的地方catch A，实际上，我们最好必须在catch A后再加上一个catch(Exception ex){}。原因在于防范于某些不可确定发生的问题而导致可能抛出的其他异常类型(实际上是特定的RuntimeException异常/unchecked异常，编码时本不推荐catch RuntimeException，但在移动开发特定业务场景中加上对其捕获可以有效防止App意外崩溃)。
上次就遇到了在接收推送消息时，new JSONObject()时，很自然的只catch了JSONException，而没有进一步的catch Exception，而实际上由于服务端传过来的数据格式错误后导致其抛出了java.lang.NumberFormatException，一步步跟踪代码后发现在源代码中确实存在可能抛出此异常的情形，而没被catch到，直接将导致app崩溃。此后谨记！
2.因so文件目录引起的UnsatisfiedLinkError: … :findLibrary returned null问题。
Android开发中，不可避免的可能会引用到外部so文件，设置一个项目中可能需要引用多个不同的外部so文件。因为不同的引入库中so文件的目录可能不同，导致打包后生成的项目lib目录中的目录结构是不同的外部so文件目录的合集。可能会出现armabi/armeabi-v7a/x86/mips等，一般情况下，armabi应该是有的，当此三个目录下的文件可能不同时，在某些特定机型下很可能会出现如上错误。原因在于不同的机型CPU结构不同导致搜寻不同的目录下面的包，而由于外部库不同的so文件目录可能armabi下还有a、b so文件，而x86下可能只含有a，此时解决方案如下：
直接删除其他目录（如armabi-v7a/mips/x86等），只保持armabi目录即可，当不存在x86目录时，相应机型也自然会取armabi目录下搜寻相应so文件。
3.Can't create handler inside thread that has not called Looper.prepare。
这个问题其实也比较经典了，原因在于，Android中的非UI线程不能进行修改UI操作（当然，严格意义上来说SurfaceView和TextureView除外），一般常见于在子线程中执行了如 Toast.makeText 等操作。一般借助于子线程和主线程消息通信机制来解决。
常见解决方法如：
1).Handler - Message方式；
2).Handler - postDelay方式；
3).activity.runOnUiThread(runnable)方式等。
4.RadioGroup中的RadioButton check()方法调用引发的onCheckedChanged()多次回调问题。
RadioGroup-RadioButton非常适合于多个选项中只选择一个的情形，对其默认样式进行改变可以方便的用于导航菜单的选项卡等需求中。setOnCheckedChangeListener()为其内部的单选按钮check状态的改变提供了方便实用的回调。编码中，如果直接写成radioGroup.check(xxx)，其中参数为RadioButton的id，经常会发现onCheckedChanged()回到被执行了多次。通过查看源码发现，当执行check()方法时，RadioGroup对单选前后不同的状态都进行了回调。实际逻辑中，一般的都是希望只回调当前选中的单选按钮即可。
可以通过如下方式解决：radioButton.setChecked(true);其中，radioButton为当前选中的radioGroup。
5.Notification传参覆盖问题
在App中，当显示多个Notification时，notification id作为当前App内Notification标识，具有不同的Notification id表示通知栏中可以同时显示此应用中多个不同的Notification。当用户点击各个Notification时，通过此Notification设置的pendingIntent响应用户的点击操作，在设置pendingIntent时，尤其需要注意其中的参数传参问题。
当有多个通知时，如果后面的通知点击后获取的参数值都是第一个通知的参数值，则是没有正确设置pendingIntent的flags参数。一般应该设置成PendingIntent.FLAG_UPDATE_CURRENT， 设置此参数后，则会形成相反的情形，前面的通知获取的参数值都变成了最后一个通知传递的参数值，此时则是因为没有正确设置requestCode参数。将requestCode参数设置成Notification id相同的值即可。
6.从AndroidManifest.xml中获取channel出现错误提示：Key xx expected String but value was a java.lang.Integer. The default value <null> was reurned。
对于AndroidManifest.xml配置channel名称时，当直接使用数字字符串时，会出现如上所示，获取到的channel值为null。
修正如下：
1 public String getChannel() {
2 String channel = null;
3 try {
4 ApplicationInfo ai = getPackageManager().getApplicationInfo(getPackageName(), PackageManager.GET_META_DATA);
5 channel = ai.metaData.getString("UMENG_CHANNEL");
6 if (channel == null) {
7 channel = String.valueOf(ai.metaData.getInt("UMENG_CHANNEL"));
8 }
9 } catch (NameNotFoundException e) {
10 e.printStackTrace();
11 }
12
13 return channel;
14 }
或者说，并不建议使用数字字符串直接作为渠道名称。