It's a left over from Eclipse project https:/eclipse/paho.mqtt.android/blob/a6496553bd07886bb1608e6e3aa739c38f26700a/org.eclipse.paho.android.service/src/main/java/org/eclipse/paho/android/service/MqttAndroidClient.java#L136-L138

If you have a better idea, please make a pull request

This is a minor improvement #680

But the main question is still there: Why they handle token by tokenNumber and access it by tokenNumber instead of using token itself instead and use a mutableList ?

can you merged into branch v3.x ?

and is it resolve the memory problem？ i can see u are only change SparseArray to MutableList.

eclipse/paho.mqtt.android#455

i was use qos 0

@baneyue
Please test it with
implementation 'com.github.hannesa2:paho.mqtt.android:TokenListByMuteable-3.x-SNAPSHOT'

When your test is successful, I will merge it into 3.x branch

What is the reason for the continuous increase in objects in the tokenMap during long-term application operation. Running 12 will take up a lot of memory

Btw, how to see the content of this table on my local running instance ?

I found this problem. When I use the master branch, I won't have this issue, but when I use 3. x, I have this problem.

This should be caused by broadcastReceiver, because my usage scenario is sending a string of data in 1 second.
It is estimated that when the performance is tight on Android 6,
broadcastReceiver is easily lost, resulting in tokenMap not receiving callbacks

so i think need not to replace SparseArray to List。

you can merge the flow to 3.x branch to replace the BroadcastReceiver

I'm somehow lost here

The pull request solves nothing, but I should merge it? -no-

Master comes with another issue, means a lost receiver? But 3.x us fine?

It's another blueprint that I only should merge existing pull requests and anything else is a waste of time. Right?

Wait, I'm still testing

@hannesa2 this problem may be the qos =0 and when send failure，it will not callback deliveryComplete

Nice.
To have a clear understanding:

The causing issue is a resulting non-remove of these in popSendDetails ? Am I right ?

        val topic = mapTopics.remove(messageToken)
        val activityToken = mapActivityTokens.remove(messageToken)
        val invocationContext = mapInvocationContexts.remove(messageToken) 

yes, there have two leak place :

`
//MqttConnection.kt

private val mapTopics: MutableMap<IMqttDeliveryToken?, String> = HashMap()
private val mapSentMessages: MutableMap<IMqttDeliveryToken?, MqttMessage> = HashMap()
private val mapActivityTokens: MutableMap<IMqttDeliveryToken?, String> = HashMap()
private val mapInvocationContexts: MutableMap<IMqttDeliveryToken?, String> = HashMap()

`

`
// MqttAndroidClient.kt

private val tokenMap = SparseArray<IMqttToken?>()

`

otherwise

1. I think it's better to use HashMap or SparseArray instead of MutableList
2. also, I suggest that all of project use Dispatchers IO replaces Dispatchers Main

This all comes with uncertain actions, so it's worth to have a test for it in advance and surveil the memory usage in this test. Any ideas how to do so ?

u can publish a message set qos =0, and u device is low network style, run your app long time.

My current plan is to set qos=0 without caching, so there will be no callbacks; A better approach would be to specify a timeout period, after which the token will be removed if there is no callback.

As far as I understand, you run into this with a lot of publishes qos =0,, which all run into (network?) errors. Am I right ?
The next thing is, how do you measure the memory usage. #679 (comment)

The network is weak or congested, and there has been no disconnection

Actually, I'm not sure what the root cause is, but after running for a long time, some callbacks cannot be received, causing those caches to be unable to be released, and the memory growth is not fast. Through profile analysis, the object continues to grow, which is quite observable for our low-end devices, causing the application to slow down

It's not a miracle, when you do a lot on low end device, that it will become slow.
Solutions have different faces, but to know, if a solution is useful, you need an evidence.
I still wait for #679 (comment)