Skip to content
This repository has been archived by the owner on May 3, 2024. It is now read-only.

Terrible message: Skipped 119 frames! The application may be doing too much work on its main thread. #27

Open
SergeyBurlaka opened this issue Feb 26, 2018 · 3 comments
Labels
Milestone

Comments

@SergeyBurlaka
Copy link

SergeyBurlaka commented Feb 26, 2018

Hi there is a very fat issue in you lib.

First i am registrate service :
private var disposableBonjourBradcast: Disposable = Disposables.empty()

val chatNameCode = PrefProvider.getInstance().currentTourCode
      val broadcastConfig = BonjourBroadcastConfig(
              type = "_$chatNameCode._tcp",
              name = PrefProvider.getInstance().userId,
              address = inetAddress,
              port = tcpServerPort,
              txtRecords = mapOf(
                      HOST to inetAddress.hostAddress!!,
                      TCP_PORT to tcpServerPort.toString(),
                      UDP_PORT to udpServerPort.toString(),
                      USER_ID to PrefProvider.getInstance().userId,
                      USER_TYPE to PrefProvider.getInstance().myCurrentRole,
                      USER_NAME to PrefProvider.getInstance().userName,

              ))

      disposableBonjourBradcast = rxBonjour.newBroadcast(broadcastConfig)
              .onErrorComplete { throw ConnectionException(it) }
              .subscribeOn(Schedulers.io())
              .subscribe()

It is work ok.

But when i try to unsubscribe for re -register service for example to pull to-refresh by this :

disposableBonjourBradcast.dispose()

My screen became freeze some during milliseconds. In logcat i see terrible message:

I/Choreographer: Skipped 119 frames! The application may be doing too much work on its main thread.

@mannodermaus
Copy link
Owner

Thanks for reporting. I'm assuming you're using version 2.0.0-RC1 of the library? What Driver do you use? Could you use the performance monitors to pin-point what methods might cause this lag?
I know that tearing down a JmDNS instance on disposal is quite costly, but that work is already supposed to be deferred to an I/O thread.

@SergeyBurlaka
Copy link
Author

Use "de.mannodermaus.rxjava2:rxbonjour:2.0.0-RC1" version
Use JmDNS

private val rxBonjour: RxBonjour = RxBonjour.Builder() .driver(JmDNSDriver.create()) .platform(AndroidPlatform.create(MyApplication.getInstance())) .create()
As for performans i can show screen:
lag

I hope this may help you

@mannodermaus
Copy link
Owner

mannodermaus commented Feb 27, 2018

Thank you for the information! Looks like indeed the library's deferring of the JmDNS instance teardown isn't working as expected in your case. JmDNS#close() taking a long time to complete isn't necessarily an issue with RxBonjour, but rather related to how it's written in JmDNS (related issue: jmdns/jmdns#82). I'll review why the computation thread assigned to that work blocks the main thread.

To be assured of this, can you place a breakpoint into JmDNSBroadcastEngine on line 37 (the body of the Completable used to close the JmDNS instance, inside the teardown() method)? I'll try to reproduce the issue as well.

@mannodermaus mannodermaus added this to the 2.0.0 milestone Feb 27, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants