我正在参加「启航计划」

前语

  之前在GoodWeather2.6的时分陆陆续续呈现了一些小bug，只不过是一句话就能改好，所以就没有独自写一篇文章来阐明，不过当问题积累的多了之后，就有这个必要了。当然这些问题许多并不是我发现的，而是细心的读者发现的。那就不说废话了，进入正题。

正文

  这些问题的呈现一般来说是我其时写代码没有注意到的细节，假如你是仿制粘贴我的代码或许也会呈现相同的问题。

一、显现bug

  这个问题由一个读者发现后反馈给我，在之前的代码中，MainActivity中的空气质量显现，我两个TextView显现了一个值，被指出，然后我就马上改了，文章也做了更新。

这个图便是github上的修正记载，赤色的代表去掉的代码，绿色代表添加或修正的代码。

然后是方法名的修正，在更多日子质量页面，所写的方法名不符合当前地点页面，容易形成误导，因而修正。 这个bug是在2021年4月1号的时分改的。

还有一个显现bug，是在查询城市失利的时分没有封闭加载弹窗，导致无法操作页面。修正代码如下：

二、数据拜访bug

  在之前的网络恳求中，每一次恳求都会履行两次，这个问题由一个读者发现，和我反应出来，我更换了网络结构，其实便是在原来的基础上添加了RxJava的运用，新的网络结构在源码中的mvplibrary模块的newnet包下。

这个结构其实我独自写过一篇文章来介绍，文章地址如下： Android OkHttp+Retrofit+RxJava搭建网络拜访结构（含源码）

想要详细了解里面进程的能够看看，不打算了解的，直接仿制代码到运用的当地就能够了，针对于这个结构来说，改变的当地相对于原来的结构有一些差异，但整体差异不大，就拿主页面的恳求来阐明一下：

在新的结构中是由NetworkApi去构建网络恳求的，在之前是经过ServiceGenerator，这儿就要做修正。

新结构需要在Application中进行一个初始化，这和之前有所不同，在app模块下新建一个NetworkRequiredInfo类，完成INetworkRequiredInfo，代码如下：

/**
 * 网络拜访信息
 * @author llw
 */
public class NetworkRequiredInfo implements INetworkRequiredInfo {
    private Application application;
    public NetworkRequiredInfo(Application application){
        this.application = application;
    }
    /**
     * 版本名
     */
    @Override
    public String getAppVersionName() {
        return BuildConfig.VERSION_NAME;
    }
    /**
     * 版本号
     */
    @Override
    public String getAppVersionCode() {
        return String.valueOf(BuildConfig.VERSION_CODE);
    }
    /**
     * 是否为debug
     */
    @Override
    public boolean isDebug() {
        return BuildConfig.DEBUG;
    }
    /**
     * 运用大局上下文
     */
    @Override
    public Application getApplicationContext() {
        return application;
    }
}

然后在WeatherApplication中完成初始化。

仍是一个当地便是ApiService的修正，之前用的是Retrofit2的Call来进行回调，现在是运用RxJava的Observable来进行。

因而每一个接口都需要更改。下面就用一个最简略的页面来阐明：欢迎页面。

SplashContract，首先是这个页面的订阅器。

这是一个获取App版本号的恳求，修正的内容如上图所示。 回调接口如下图：

页面中运用。

那么相对于这一个接口，其他的接口修正方式一样，假如还不清楚能够查看我的源码。在我修正网络结构之前，我特意保存了一个之前的未修正网络结构的源码。之前的源码地址如下：GoodWeather

这个下载是0积分，能够直接下载，你现在从GitHub上看到的代码是修正了网络结构之后的。

好了，对于网络结构的的修正就说到这儿。

三、程序溃散

  程序溃散对于App来说便是大问题了，因而要在开发时做反复的测验，这一点我有所疏忽。这个问题是我在调试的时分发现的，溃散的原因源自于App中讯飞语音的运用，这和讯飞没啥关系，完全是我运用的问题。

问题呈现的原因便是讯飞语音辨认是弹窗的调用，context重复运用，导致当第一个页面调用了语音辨认之后，第二个页面调用时引用的context仍是之前的，但是之前的页面销毁了，则弹窗找不到显现的页面，页面溃散报错。解决方法是，每次调用弹窗时传入当前页面的context，这样就能够防止了。

然后是调用的当地。有三处，如下图所示，一一修正即可。

四、小米8上的溃散

  此问题由一个读者发现，问题呈现原因是在小米8手机上，运行到主页面时会溃散，但是在我自己的手机和测验机上都不会溃散，这个就很奇怪了。 这是其时的报错信息： java.lang.RuntimeException: Canvas: trying to draw too large(125452800bytes) bitmap.

现在能够得出是页面制作的问题，因而这儿就要解决，其实最简略的办法便是修正资源文件目录，之前我的大图片都放在drawable下的，这其实有问题。只不过之前没有报错就没有注意到，这一次添加一个drawable-nodpi文件夹，这样当屏幕制作就按照大的分辨率去进行，防止程序溃散。

源码地址：GoodWeather 欢迎 Star 和 Fork

天长地久，后会有期~