在上篇《ActiveMQ MQTT Server 搭建》中我们已经搭建好了 MQTT Server，本篇我们将在 Android 上建立 MQTT Client 与 MQTT Server 进行通讯。

1. 执行流程

1.1 引入依赖

在 build.gradle 中引入依赖项。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

 android {
     ...
 }
 
 repositories {
    maven {
        url "https://repo.eclipse.org/content/repositories/paho-snapshots/"
    }
}

dependencies {
    ...
    implementation 'org.eclipse.paho:org.eclipse.paho.client.mqttv3:1.1.0'
    implementation 'org.eclipse.paho:org.eclipse.paho.android.service:1.1.1'
}
 

Android 开发中需要和 MQTT Server 进行交互，在此之前需要先搭建 MQTT Server 来协助开发。本文演示了在 Windows 11 中使用 Apache ActiveMQ 来搭建服务的全过程。

1. 下载 ActiveMQ

2. 启动 ActiveMQ

本例中使用 ActiveMQ Classic 5.18.3 进行搭建，解压下载的 ActiveMQ 包，切换至 ActiveMQ 的 bin 目录，输入 activemq start 命令启动服务。

内部类也叫做嵌套类，在 Java 中是一个被大家经常使用到的东西。内部类除了匿名内部类外还分为三种：一种是可以被独立构造实例且和外部类完全剥离的静态内部类，一种是可以自由访问外部类成员变量和方法的成员内部类，一种是作用域和生命周期都只处在一个方法中的方法内部类，但这种内部类我们不讨论。

在 Kotlin 中，内部类默认是静态内部类，只有用 inner 修饰符声明静态内部类，才能让 Kotlin 中默认的静态内部类变为非静态的成员内部类。

1 静态内部类

Kotlin 中，类可以嵌套。一个类可以嵌套在其他类中，而且可以嵌套多层。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

class NestedClass {

    class Outer {
        private val zero: Int = 0
        val one: Int = 1

        class Inner {
            fun getTwo() = 2
            
            class Deep {
                val three = 3
                fun getFour() = 4
            }
        }
    }

}

在使用 Java 的时候，我们经常使用诸如 StringUtil、DateUtil 等工具类，代码写起来比较冗长。举个例子，获取一个字符串的第一个字符值、最后一个字符值。如果我们用 Java 代码来写通常要先声明一个 StingUtil 类，然后在里面写相应的方法。那么，我们能不能直接在 String 类上增加获取第一个字符值、最后一个字符值的方法呢？非常遗憾的是，在 Java 中我们无法给 String 类增加一个自定义方法。因为 String 类是 JDK 中内置的基础类，而且为 final，不能修改。所以，在 Java 中通常需要引入一个工具类来封装对应的方法，而不是修改或继承 String 类。

而在 Kotlin 中，情况就完全不一样了，我们完全可以自由扩展任何类的方法和属性。在不修改原类的情况下，Kotlin 能给一个类扩展新功能而无须继承该类。

1. 扩展函数

Kotlin 中提供了非常实用的扩展函数功能。它允许你在不修改原始类的情况下，为该类添加新的函数。通过扩展函数，你可以为任何类添加新的行为，包括标准库中的类、第三方库中的类，甚至是你自己定义的类。

Kotlin 提供了丰富的数据处理功能，包括数据的映射、过滤、查找、排序、求和、字符连接、转换、循环等。这些功能可以帮助开发者更加方便地处理数据，而不用关心具体的实现过程，开发者可以将更多的关注放在业务逻辑本身。此外，这些功能还能极大简化代码，提升代码的可读性。下面是一些数据操作的常用模版代码：

1. 映射操作

1
2
3
4
5
6
7
8
9
10
11
12

// 将集合转换为 MAP

class Member(var id: Int, var name: String)

val data = mutableListOf(
    Member(1, "Tom"),
    Member(2, "Tim"),
    Member(3, "Tom")
)

val map: Map<Long, Member> = data.associateBy { it.id }
val map: Map<Long, String> = data.associate { it.id to it.name }

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 将集合中的元素按照某个条件分组，返回 MAP

class Member(var id: Int, var name: String)

val data = mutableListOf(
    Member(1, "Tom"),
    Member(2, "Tim"),
    Member(3, "Tom")
)

val map = data.groupBy { it.id }
map.forEach {
    print("${it.key} - ${it.value.count()}")
}

这篇文章得从一个 BUG 说起，UI 是由 Viewpager2 嵌套两个 Fragment 构成的。然而，就是这再平常不过的功能以及接近模版化的代码，竟然因为偷懒产生了异常。为了省去繁琐的 Arguments 传值，在 Fragment 的实例化过程中增加了有参构造函数。正是这一操作为后续的应用崩溃埋下了坑，Fragment 源码正在等待合适的时机将异常抛出。

1. 崩溃信息

采用有参构造函数实例化 Fragment 后，进行了功能测试。由于在测试过程中应用一直在前台，所以也就没有发现这一BUG，但当应用上线后，陆续收到了应用崩溃的反馈，查看 BUG 统计得到了如下的崩溃信息：

看到标题就应该知道，这又是一篇 BUG 修复的复盘文章。这个 BUG 起源于 Google 程序员多年前埋的坑【FLAG_TEST_ONLY】，这是一个 API 级别 4 时候就存在的属性。这是一个没有存在感的属性，以至于十几年的时间内都没有引起多少人注意。直到 Android Studio 3.0 的发布，这个版本的 IDE 会在测试版 APK 的清单文件中自动注入 android:testOnly="true" 属性配置。如果清单文件中有这样的配置，那就意味着 APK 只能通过 adb 的方式安装。为了更加精准的了解这个属性的作用，我们还是看下官方文档是怎么描述的。

✦ 官方文档 | android:testOnly 指示此应用是否仅用于测试目的。例如，它可能会在自身之外公开功能或数据，这样会导致安全漏洞，但对测试很有用。此类 APK 只能通过 adb 安装，您不能将其发布到 Google Play。当您点击 Run 图标时，Android Studio 会自动添加此属性。

文档的描述简洁干练，提供的信息也乏善可陈。那么，应该怎么解决这个问题呢？通过考古，网上普遍流行两种方法：

如果通过这两种方式就能解决应用安装失败的话，就不会有这篇文章了。下面，我们正式开始复盘问题的定位和解决过程。

SQLite 中的 IFNULL() 函数是一个 IF-ELSE 的函数，如果第一个参数为 NULL，返回第二个参数，否则返回第一个参数。

应用访问文件和目录最便捷的方式是使用 Context 类提供的方法。Context 类是所有关键应用组件的超类，常见的几个应用组件有：Application、Activity 和 Service。因此，这些子类可使用 Context 类提供的方法（如下表所示）轻松访问文件和目录。

Android 下载引擎的组件化源于应用场景的广泛性和存储字段的固定性。起初，下载引擎是通过 Module 的形式引入项目的，这种方式的引入在形式上起到了解耦作用，同时，也可针对项目个性化的存储字段进行增减。但随着下载引擎复用需求的增加和业务的积淀，Module 不再是下载引擎的最优引用方式了。首先，随着业务的积淀，存储字段的数量逐渐趋于稳定，这意味着下载引擎已经可以满足大部分的应用场景了；其次，Module 引入项目的方式不利于源码的维护。试想下，如果下载引擎出现了问题，并且修复过程异常复杂，那么每个以 Module 方式引入下载引擎的应用在修复同类问题的时候将会非常痛苦，如果再考虑个性化存储字段，这个修复过程将会变成一场灾难。所以，需要一种更加便捷的引用方式来改变现状，比如：AAR 或者 Maven。

引用方式的改变还是比较棘手的。为了理解这里的困惑，需要了解一下下载引擎的实现方式。下载引擎是通过服务启动下载线程来下载内容的，如果下载的信息有变更，这些信息在入库的同时会通知已注册的观察者，前台会通过内容提供者获取下载信息，并展示在界面上。这里需要注意的是内容提供者，也就是 ContentProvider，同一部手机上是不允许同时存在拥有相同 Authorities 的两个应用的。这意味着下载的引擎的内容提供者应该同时具备动态配置和动态读取 Authorities 的能力。下面，就通过改造让下载引擎来具备这些能力。