关于android:由一个进度条更新所引发的思考

6次阅读

共计 3013 个字符，预计需要花费 8 分钟才能阅读完成。

事件是这样子的，我前阵子在 Github 上开源了一个 Android 全量版本更新的框架 XUpdate, 受到了大家统一的好评。

然而随着使用者基数的一直增大，两头也裸露了很多问题，其中问的最多的就是：” 为啥我的版本更新进度条不显示或者不更新呢？”

如果是我遇到了这个问题，我想我最间接的解决形式就是浏览源码或者打断点、打日志去定位问题了。

为啥他人都能够，而我却不行呢？

然而遗憾的是，我发现很多人呈现问题的第一反馈就是：这什么破玩意儿，怎么不起作用。而后就开始去百度各种搜，又或者加 QQ 交换群上来就 @我一下，把我整得很懵，具体可参考下图：

起初对于这类问题，我也是十分苦恼：

首先，导致版本更新进度条不显示或者不更新的起因会有很多种状况，上来什么上下文都没有就让我帮忙剖析问题，那几乎就如同你是独身，却问同样是独身狗的我如何解脱独身是一个级别的问题，你让我怎么答复你呢？
其次，我的很多开源框架都会有丰盛的 wiki 材料，外面会有常见问题一栏，外面都列举了很多使用者常犯的谬误曾经解决办法。例如 XUpdate，就有一份具体的常见问题阐明，外面就介绍了进度条不更新的起因以及解决方案。然而很遗憾，很多人都抉择熟视无睹。很显著的，答案都给你了，你却不违心去抄，我是真的无能为力。
最初，当问题没有失去解决，绝大多数人会抉择默默来到，转身去寻找一个更为适宜本人的框架，而另一部分人就没有那么友善了，他会对你的框架进行恶语相向，一直贬斥你的框架，搞得一副我欠他的样子 … 就相似上面这位网友这样：

做开源我的项目这么多年，我始终在思考两个问题：

为什么要做开源？
怎样才能做好开源？

在这里我不得不抵赖，最后我做开源我的项目的目标就是想晋升本人在行业内的知名度，这样也不便当前找工作。然而随着我的开源我的项目被越来越多的人认可和应用之后，这种观点就慢慢发生变化了，尤其是当我得悉有人通过我的开源框架，在短短几天内就写出了一个商用级的 App 利用后，我的心田其实是十分喜悦的。

当初的我做开源我的项目，目标十分纯正：就是想尽可能地帮忙大家更好地进行开发，晋升开发的效率和能力，让大家有更多的工夫用来学习和生存，而不是在公司无尽地反复搬砖。

然而据我察看，很多人在利用开源我的项目方面，只是为了解决他们遇到的问题，正所谓拿来主义，他们并不会去对我的项目的设计构造或者实现原理加以钻研和学习，这其实齐全背离了我做开源我的项目的初衷。

我始终强调，会用框架并不代表你把握了框架。只会用框架而不去学习框架的设计思维和实现原理，那么你就是用得再纯熟，框架仍旧还是他人的，你仍旧还只是个高级开发工程师。

更何况你在齐全不理解原理的状况下，就冒然去应用一个框架，那么等当前开发遇到坑了之后你咋办，难道筹备持续换框架吗？

所以，我当初还是激励我的框架使用者遇到问题本人解决，激励他们多看文档、源码，多学习框架中奇妙的设计思维，而不是单纯为了解决问题而解决问题。

我在做开源之初，犯了一个开源者常犯的一个谬误：认知谬误！

我天真的认为，我的开源我的项目使用者都是和本人程度差不多的专业人士，很多行话或者基础知识默认他们都是晓得的，因而导致了开源我的项目初期产生很多破绽或者形容不清的中央。

就拿我的 XUpdate 我的项目来说，三年间我陆陆续续地解了 100+ 的 issue，你能置信吗，一个简简单单的 Android 版本更新我能够解决这么多的问题。

有一天，一位使用者在 qq 交换群外面又是上来就间接 @我：有下载进度，然而进度条为什么不显示？并且发了本人下载性能的实现逻辑代码如下图：

刚开始看这串代码，我就发现不对劲：这小伙子不讲武德啊，怎么能在子线程外面间接回调进度更新呢，这怕是没写过 Android 吧 …

于是，我间接在群里回了一句 ” 你真的人才, 在子线程外面回调 ”，而后就默默关上 XUpdate 的源码，给所有的回调波及到 UI 更新的中央都加了一下线程判断，保障在主线程解决 UI。

然而写着写着，我又开始感觉不对劲，如果真是在子线程里解决 UI 的话，为啥程序没崩呢？

果不其然，我的纳闷是对的。小伙在听取了我的倡议：将回调放到了主线程之后，仍旧还是不能显示进度条。

看到这儿，直觉通知我可能和这边的进度回调无关。于是我又从新关上进度条更新的源码，认真看了一遍之后，而后又比照了他之前发来的代码，我豁然开朗：

这里 handleStart 对应的是下载回调的 onStart，而handleProgress 对应的是下载回调的onProgress，下载回调接口的残缺定义如下：

/**
 * 下载回调
 */
interface DownloadCallback {
    /**
     * 下载之前
     */
    void onStart();

    /**
     * 更新进度
     *
     * @param progress 进度 0.00 - 0.50  - 1.00
     * @param total    文件总大小 单位字节
     */
    void onProgress(float progress, long total);

    /**
     * 后果回调
     *
     * @param file 下载好的文件
     */
    void onSuccess(File file);

    /**
     * 谬误回调
     *
     * @param throwable 谬误提醒
     */
    void onError(Throwable throwable);
}

很显著，这个小伙儿只实现了 onProgress 的回调接口，却没有实现 onStart 的回调接口，这就导致了 handleStart 办法外面的 mNumberProgressBar.setVisibility(View.VISIBLE); 始终没有失去执行，而在 handleProgress 办法外面又没有对进度条设置显示的办法，所以进度条当然始终不显示啦 …

看到这儿，我只想说一句 ” 我粗心了，没有闪啊！”。要不是这位小伙儿贴出了他那段骚气的代码，我是怎么也不会想到竟然有人会这样写！

吐槽归吐槽，但这里的确有逻辑破绽，所以还是须要兼容一下的。于是乎我就在更新进度条的中央减少了一层判断：如果进度条以后不在显示，那么就先显示它，再更新进度。代码变动如下：

在通过这次惨痛的教训之后，让我更加深彻地领悟了一点：你永远都猜测不到电脑的那头是谁，以及如何应用你的开源我的项目。

为此，我顺便为 XUpdate 开源我的项目做了如下改良措施：

转变思维，站在小白的角度，从新梳理一下现有的应用文档, 让文档更加简略易懂。
编写了一个 XUpdate 的简化库 XUpdateAPI:https://github.com/xuexiangjys/XUpdateAPI，升高 XUpdate 的应用难度。
陆续做了几期 XUpdate 相干的教学视频: https://space.bilibili.com/483850585/channel/detail?cid=164280

说了这么多，让咱们来简略总结一下我的几点反思：