交付测试还在手动拷贝安装包?更高效的方式来了!

近期开发 Android TV 平台应用,编译后通过 adb tcpip 端口推送到 TV 或盒子上的上传速率简直分分钟让人抓狂。这样开发的效率极低,尤其是适配那些老旧的盒子,一次推送十几分钟都是正常的,分分钟血压180。怎样才能减少这个时间呢?实际上这些设备在观看视频是并不慢,这就说明下载速度是正常的。这样我们可以通过下载的方式将我们的应用下载并安装到设备中,具体实现就是后面要写的”应用分发器“了。

应用分发器潜在的用户

如果是简单写一个apk下载安装器似乎没啥太大的意义,既然写了,不妨完善一下它的功能。哪些人会使用分发器呢?

  1. 开发人员:
    正如上面我遇到的问题,TV推送效率极低,使用分发器可以将应用编译打包后,通过下载的方式安装到设备中,提高开发效率。如过不需要调试的话,可以实现不连接设备的情况下查看开发效果。如果需要调试,就必须链接设备了,启动调试可以通过adb shell am -d 命令以调试的方式启动应用。
  2. 测试人员:
    一个应用的开发往往伴随着开发团队和测试团队的配合。开发人员发布应用,通过某种方式发送给测试人员,测试人员需要连接设备或者其他通信工具发送到设备进行安装测试。这个过程同样十分耗时。而且到真正发版前,这个过程往往需要多次的迭代,十分痛苦。应用分发器可以极大的简化这个流程,去除很多重复劳动!开人员只需发布应用,然后开发人员便可以直接在安装过分发器的设备上安装测试!
  3. 普通用户:
    设计分发器的初衷是给团队开发测试使用的,但同样可以用于给普通用户分发应用。比如内测用户,或者一些无法正常上架应用市场的应用。

应用分发器功能分析:

分发包括四个部分:

  • 分发器主动获取发布者有哪些可用的应用
  • 发布者主动推送应用到各个设备
  • 可以动态设置发布者
  • 应用下载安装

分发器主动获取发布者有哪些可用的应用:

这种主动获取的方式实现起来比较简单,只需在分发器启动和用户主动点击时获取可用列表既可以

发布者主动推送应用到各个设备:

这种分发机制实现有一定困难,首先是应用”保活“,然后使用心跳方式获取发布至”推送“的应用

可以动态设置发布者:

每个使用分发器的团队的发布者都是不同的,所以应当可以动态设置发布者。这里所说的发布者,实际就是存储应用信息的服务器地址或者网盘地址

应用下载安装

这个功能没啥可解释的,干活吧!

实现技术分析

  • 首先得存储应用信息:应用信息可以存储在Json里,具体结构,在后面具体功能实现中详细分析。然后把JSON放到可一个可以下载的地方就可以了。可以自己建立一个小服务器或者直接使用网盘地址。百度网盘地址不稳定,而且下载很慢。可以自己使用 nextcloud 搭建一个。nextcloud 可以保持文件下载地址不变的情况下,更新文件。上传也有简单的api可用,写个20行左右的Python脚本就可以,如果有想用可以留言讨论下。
  • 获取应用列表,展示应用信息,获取推送通知,下载安装这几个功能没有太大的技术障碍。
  • 推送:这个实现比较困难,这也是Android的一大痛点。要实现推送,首先是应用保活,实现方式有很多,但大多有缺陷,择优选择一种实现。其次是开机启动,在高版本的系统实现起来比较麻烦。
  • 动态配置发布者:这个可以通过分发器端的设置里动态设置。

功能实现

分发器我已经写了一段时间了,目前功能已经基本实现。

  • 可用应用列表和推送信息通过两个JSON存储:
{
        "flag": 1,
        "pkg": "com.jepack.dispatcher",
        "url": "http://192.168.31.92/dispatcher.apk",
        "md5": "91377cf93d7c510f745d2a7192602245",
        "app_code": 1,
        "force": true,
        "title": "APK Dispatcher 0.1.0",
        "desc": "Function done!"
}
[
    {
            "url": "http://192.168.1.217/cache.apk",
            "md5": "fe4aa390ba7fb86fa05256bd2bd8d1a2",
            "title": "应用1-修复xx",
            "desc": ""
    },
    {
            "url": "http://192.168.1.217/cache1.apk",
            "md5": "fe4aa390ba7fb86fa05256bd2bd8d1a2"
    }
]
  • 分发器客户端实现

    如下图,

    • 工程使用了DaemonService做应用保活。
    • receiver 是开机启动的 receiver;
    • service包含保活的service,其中通过心跳的方式获取推送内容并作出相应操作;settings包含动态修改发布者等的设置;
    • Activity包含应用列表的显示及对应操作;
    • AppUtil实现了应用的通知、下载、安装等操作。
    • fi.iki.elonen 为在手机里建立的局域网服务器,不想在手机里输入发布者地址可痛苦局域网api实习修改,具体参见工程README

《交付测试还在手动拷贝安装包?更高效的方式来了!》 工程结构

  • 下图是设置页面:

    《交付测试还在手动拷贝安装包?更高效的方式来了!》 设置页面

  • 具体功能代码
    源码已发布到我的Github

下载功能用到了Rxjava/RxAndroid,其中的filter功能最近开始使用。如果大家同意使用Rxjava/RxAndroid,可以试试,非常实用。有其他使用新得也欢迎大家一起讨论!工程中大部分代码使用kotlin语言编写,有不足之处还请指正!

downloadDisposable = downloadSubject.observeOn(Schedulers.io()).filter {
          it.action in arrayOf(ACTION.ACTION_PAUSE, ACTION.ACTION_START, ACTION.ACTION_STOP, ACTION.ACTION_CONTINUE)
      }.subscribe( {dlMsg->
          when(dlMsg.action){
              ...
          }
      }, {})
  • 已实现功能:
    1. 固定应用列表获取并显示
    2. 简单的应用保活
    3. 推送机制
    4. 动态配置发布者
    5. 应用下载(可设置MD5校验策略,建议稳定的局域网可不校验)、通知、安装
    6. 手动输入一个特殊地址安装
    7. 简单的开机启动实现(未测试)

目前功能已经基本可以使用了(我自己的团队也正在用,如果配合Gradle 插件、Jenkins持续交付机制就更完美了),欢迎使用和留言探讨!

    原文作者:Jepack
    原文地址: https://www.jianshu.com/p/1c74c31ceed7
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞