前言
今天是程序员节，各位朋友们过得好吗？深圳的天气终于变了，现在我也穿起了长袖，距离我的GoodWeather开发已经过去一年多的时间了，这个App我是完全开源，并且把开发的步骤都公布了出来，在开发过程中我遇到过很多问题，刚好借着这个机会来说一下。
正文
GoodWeather App是一个天气的App，可以实时定位你当前的所在位置，查询到当地的天气，并且提供地图定位模式和语音输入快速查询的方式，项目的源码地址如下：GoodWeather，不方便下载源码的可以直接通过二维码下载安装体验一下：
这个项目我利用工作之余休息的时间陆陆续续的写完了，写的过程中不断的在完善和修改，也会听取读者的建议增加相应的功能，这个过程中也遇到了一些问题，例如：ANR（程序无响应）、NullPointerException（空指针异常）、RunningTimeException（运行时异常）、ArrayIndexOutOfBoundsException（数组索引越界异常）、IllegalArgumentException（非法参数）、NumberFormatException（数字格式异常）等等。
一、问题
就上述的这些异常你在日常开发中肯定会遇到的，大体说一下。
1. ANR
ANR（全称：Application Not Responding）程序无响应，要解决问题首先要知道问题出现有哪些可能性，然后在结合你当前应用的实际情况去排查，最终找到解决方法。这是我的思路，那么造成ANR有哪些可能呢？
可能性一：主线程阻塞，在主线程中进行耗时操作过多（数据库读写、文件读写、网络请求、大数据计算等）。
可能性二：内存泄漏，列如App的启动页是一个高清的图片，在有的手机上可以正常运行，有的手机机会闪退。
可能性三：过度绘制，这个说法就是上面两种可能的相结合，首先你在主线程中绘制UI，其次绘制的图比较大或者重复绘制都会有ANR可能。
实际中的可能性可不止这三点，说说怎么解决的，第一个可能性，主线程阻塞，由于执行了大量的耗时操作造成的，那么这个时候就要使用子线程去进行耗时操作的处理。例如网络请求、数据库读写、文件读写都应该开一个子线程去执行，而不应该在主线程中处理，对于Activity来说UI线程就是主线程，UI线程要负责页面UI的绘制，这里又会引发另一个问题，那就是当你的view由主线程绘制时，在子线程中进行改变时会报错，所以子线程可不可以刷新view呢？是可以的，只不过有一个前提，那就是你的子线程创建了这个view，此时这个子线程就是这个view的UI线程。
而对于内存泄漏来说，常规情况下是资源处理不当造成的。举个通俗的例子，有两座桥，A和B，A最大承重2吨，B最大承重6吨，有100辆车要过桥，车上载重1吨到6吨不等，正常的分配就是小重量走小桥，大重量走大桥，当资源分配不合理就会出现1吨的车走承重6吨的桥，然后6吨的车走承重2吨的桥，那怕桥质量再好终究会塌，可能例子不是很恰当，但是意思应该说的很清楚了，就是资源合理使用，不用就要回收，回到一个我之前遇到的问题，就是高清图片，国产手机的定制化是很多的，各个厂商都更改了Google的源码变成了定制化系统，这对用户来说没啥，但是对开发者来说就很难受了，因为一个问题你是躲不开的，那就是适配。我之前遇到的问题就是我在启动页用了一个高清图，然后在我的手机上正常运行，然后在一个读者的手机上就直接闪退了。报错的图如下：
从这个图能看出什么内容呢？
首先这是一个运行时异常，其次和图片的绘制有关系，那么这么一结合就是过度绘制的问题。
当时这个读者就找到我，然后我就开始排查，首先是启动App的时候做了什么，这里还会涉及到一个点，那就是App的启动优化，这个点很关键。不过首先要解决bug，经过排查最终定位到是图片的问题，这里就说明了国内厂商对于手机屏幕及自身系统的定制是千差万别的，最终的解决办法就是针对于高清图的文件修改到大分辨率文件夹下，这属于一个比较低级的错误，我之前放置的都是常规的文件夹，吃一堑长一智。
2. NullPointerException
NullPointerException（空指针异常），我相信用Java写Android的朋友肯定遇到过找个问题，那就是null，常说的空对象。这个问题一般来说在开发的时候做得好可以避免90%的出现概率。最大的出现情况就是赋值的时候，只要出现这个，那么对应的就是你的程序闪退了，哦豁！这个月奖金又没了，打工人的辛酸，留下了悔恨的泪水。所以使用Java开发Android的时候要特别注意这一点，注意null。这一点Kotlin就做的很好，因为空安全这个特性。那么假如出现问题了，线上的项目，用户就说会闪退，甚至都不说是什么时候闪退的，你要怎么办呢？怎么去解决呢？通过第三方SDK，例如友盟，你对接SDK之后，发布之后，报错时，平台上会有报错的信息与日志，这样开发者就可以快速定位问题，然后解决问题了，然后对App做一个更新，这就完美化解了，虽然扣的钱回不来了，但是你及时止损了。至于其他的一些异常都是常规的，发现了就能解决，在开发过程中。最麻烦的就是上线之后的问题要怎么去定位和解决。
其实在实际的App开发中，大部分的问题都能在开发和测试阶段发现并且解决，但是巧的就是在上线之后到了用户手里，就出现了之前没有发现到的问题，这个时候开发和测试就要互相甩锅了，扯皮是常事。扯完之后还是要想办法解决才行，因此对于现在的线上项目来说，上线之前对接一款性能检测，错误收集的SDK是很有必要的，下面我将针对于我的这个GoodWeather进行这个SDK的对接与使用。
二、友盟使用
点击友盟进入官网，然后注册和登录。
1. 创建平台应用
登录后点击 进入工作台，这里可以查看应用信息，如果还没有创建过应用就添加新应用。
在友盟上创建应用，获取AppKey，
注册应用。此时AppKey已经生成了，然后选择需要开通的产品，这里选择应用性能监控U-APM。
确认开通。
复制这个App Key到自己的项目中，一会儿会用到。打开项目的build.gradle，添加maven库。两处地方，同一句代码：
maven { url 'https://repo1.maven.org/maven2/' }
然后是打开app模块的build.gradle，在dependencies中添加如下代码：
// 友盟基础组件库（所有友盟业务SDK都依赖基础组件库） implementation "com.umeng.umsdk:common:9.4.2" //（必选） implementation "com.umeng.umsdk:asms:1.4.1" // asms包依赖(必选) implementation "com.umeng.umsdk:apm:1.4.2" // U-APM包依赖(必选)
然后Sync Now，同步一下项目。
由于友盟的SDK需要获取手机的设备信息和网络状态，因此需要在AndroidManifest.xml中配置相应的权限
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/> <uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/> <uses-permission android:name="android.permission.READ_PHONE_STATE"/> <uses-permission android:name="android.permission.INTERNET"/>
其中READ_PHONE_STATE需要动态申请。
然后就是初始化了，这里要注意一点就是需要在在《隐私政策》中向用户告知使用友盟SDK，参考条款如下： 使用SDK名称：友盟SDK 服务类型：请按SDK功能填写，如应用性能监控平台 U-APM 收集个人信息类型：设备信息（IMEI/MAC/Android ID/IDFA/OpenUDID/GUID/SIM 卡 IMSI 地理位置信息等） 隐私权政策链接：https://www.umeng.com/page/policy
这个隐私协议的弹窗理应做成类似这样的效果。假设这是你之前的隐私政策，
那么你需要在这个里面加上关于友盟+SDK的使用说明。然后用户同意后才能进行这个初始化的操作，在Application的onCreate中进行。这里有一个预初始化和一个正式初始化，预初始化在程序第一次安装运行时使用。
我们可以通过缓存去做处理，比如下图所示：
这里我通过缓存的方式判断用户是否有同意隐私政策，第一次进来肯定是没有同意的，因此会走else，而我们在同意隐私政策的时候再进行一次正式的初始化就可以了，可以如下图这样写。
这样就可以了，运行效果如下图所示；
至于改动的源码可以去我的GitHub上去查看，GoodWeather好了，现在基本上就完成了对接的工作，下面就来使用它。
2. 使用
① 日志使用
当对接了友盟SDK之后，就会打印友盟的相关日志，而上线的时候就不用再打印了。可以通过
UMConfigure.setLogEnabled(boolean)
设置关闭。
② 崩溃分析
完成了SDK对接之后，即可使用Java、Native崩溃分析、ANR分析功能，无需额外其他接入操作。如果需要对Native进行采集可以这样写：
//针对于Native崩溃信息采集 final Bundle customInfo = new Bundle(); customInfo.putBoolean("mCallNativeDefaultHandler",true); CrashApi.getInstance().updateCustomInfo(customInfo);
崩溃回调（自定义字段）
//崩溃回调 UMCrash.registerUMCrashCallback(new UMCrashCallback(){ @Override public String onCallback(){ return "App程序崩溃了"; } });
自定义异常接口
在开发中通常有自己异常try catch，那么也可以将catch中的异常通过友盟的接口传到后台去，然后开发者去查看。
try { // 抛出异常的代码 } catch (Exception e){ UMCrash.generateCustomLog(e,"UmengException"); }
使用
③ 自定义版本号
有时候线上可能有多个版本那么，可以通过自定义版本号API，使SDK所上报数据绑定您指定的App版本信息。
UMCrash.setAppVersion("1.0.0", "release", "0001");
使用
有了这些，你就可以等着程序报错的日志上传到友盟上了，有了这些，你就可以等着程序报错的日志上传到友盟上了，点击：https://at.umtrack.com/PXPDCu进入U-APM
立即使用。
下面就可以进行相关的日志查看了，那么先来写一个bug吧。
比如我在App的启动页的onCreate中写下这样的代码。
try { Thread.sleep(1000000); } catch (InterruptedException e) { e.printStackTrace(); }
然后运行，看AS的控制台日志
这个日志就很全面了，不过这是友盟SDK的日志打印，本地调试确实可以使用，那么它有没有传到平台上呢?毕竟线上项目的错误信息日志才是关键。
很明显，上传了这个错误，再向下滑动去查看这个错误的详情。
点击左边的蓝色报错处
这里告诉你报错的具体代码行，以及下方这里有你报错设备的信息，方便你去排查原因，再往下看。
这里告诉你报错的原因是什么？主线程睡眠时间过长，导致的线程阻塞，程序无响应，ANR。
这里右边的行为日志，也很不错，可以让你知道你在当前这个页面是在做什么。
这里对应的是页面浏览，合理，因为我确实还没有做什么。
而这个内存快照，就是方便你查看报错时的内存使用情况，可以酌情进行优化。
最后这个自定义字段，很明显就是在代码中写的一个崩溃的回调。
这说明我自己写的日志也上传了。
通过介绍、接入、使用和日志分析了解到友盟 U-APM的强大，这对于线上项目来说是一个福音，提交的错误信息能够快速上传，定位到，快速解决问题。
更多的功能使用需要开发者自行去摸索，这里只是起到一个抛砖引玉的效果，这里再次感谢友盟提供的这个机会，我们山高水长，后会有期~
