I have sometimes app freezing I do not know what is the source of problem.
It happens rarely but happens. I consider how to track such issue
I have crashlytics from firebase but there is no errors as freezing is I suppose something with threads maybe some deadlocks or infinite loops.
Is there way to track such things?
What maybe reasons of app freezing and being inactive (it is SwiftUI app) ?
Are there possibilities to track/profile apps installed on devices (not connected via Xcode) and send informations such that are available in Instrument to something like firebase console or other 3rd party tools.
Update
I think I do not indicated important fact.
It freezes UI definitely not for a few seconds but app need do be killed and restarted again.
There might be some heavy process that locks your main thread, so it freezes your UI.
You track the problems, performance, leaks and more using Instruments.
There are sample topics:
Instruments Tutorial with Swift: Getting Started
How to find and fix slow code using Instruments
And WWDC videos like
Using Time Profiler in Instruments
Creating Custom Instruments
I have experienced some of these weird behaviours before. And mostly the reason behind it was a task that is blocking the main thread making it unresponsive. Pause the app and check the stack trace. Also make sure all your UI operations are done on the main thread. Hope this helps!
Related
I am developing a live platform using amazon IVS player SDK.
But I have a little problem.
The ui freezing phenomenon occurs intermittently, but it is difficult to debug because the clear call stack is not visible.
I have doubts, but I can't see it as open source.
mainThread callstack
Suspicious thread
The situation is as follows, but my expectation is that "psync_mutexwait" occurs on the "AVSampleBufferDisplayLayer" side on the open source side and freezes.. I am not sure if this is correct.
So, I'm going to do more debugging, but if there is any reason to think about it or any tips for debugging when the call stack is as follows in the state of ui freezing,
Please let me know that knowledge.
thank you.
Use XCode profiler. Go to Product > Profile and select Game Performance. It should help you to detect UI freezes at runtime. Detailed guide here.
Users are getting this crash in testing. My first guess was that it's memory-related but I don't have much more to go off of than that. Looking deeper into the code, I thought this might have been a Main Thread issue but it looks like listeners are removed on a background thread, so I'm skeptical that that's the reason.
I thought that removing any active listeners when the app backgrounds and re-adding them when the app foregrounds might negate this crash but it doesn't seem to have helped.
Any advice on how to fix this crash? Thanks!
Edit: I left the simulator open for long enough and I got this, which is probably the same crash.
Edit 2: Profiling with the Leaks Instrument didn't turn up anything related to Firestore. It only had 7 small leaks related to Foundation and UIKit after the app closed
Looks like this was introduced in 0.15.0 – https://github.com/firebase/firebase-ios-sdk/issues/2138
Since moving to iOS 8.3, I'm encountering this error where the main thread will get stuck in this call. A few other threads are also stuck in that call. There is none of my code in any thread that leads to this call, so I'm stumped as to why this is happening. It happens randomly, sometimes, when tapping a button bar item, sometimes while redrawing charts (using ShinobiCharts), etc.
Here is the stack trace from Xcode:
Anybody has any clue as to why this is happening and how to fix it? It's very annoying because when I get stuck there, I have to relaunch the app. Note that this is happening in the simulator so far. I'm in the early stage of developing this app and spend most of my time in the simulator. I haven't seen the error happening yet on a real device but, again, I haven't run the app that often on the device.
Knock on wood, but I think I figured it out (at least in my instance).
What led to the solution was a search for syscall_thread_switch, which led me to this answer here:
https://stackoverflow.com/a/30333203/978509
Which, if you look at the backtrace I linked (https://gist.github.com/Shalmezad/65ff89d20aa7e0a9d094), every syscall_thread_switch is preceded by OSSpinLockLockSlow, which the answer notes looks like Livelock, but due to the low CPU usage, is more evident of a deadlock.
Going through my code, I found that for every background task, I created a new dispatch_queue_t each time. I since redid how that works to use the same queue, which seems to have fixed the issue.
Without further information from nemesis (mainly some code snippets showing how he's setting up background tasks), I cannot answer their specific question, however this should point people in the right direction for fixing the issue.
I have an iOS app with some performance issues. In particular, when the user selects an item in a particular Core Data-backed UITableView there's a delay before the UI updates. Since there's very little multithreading in the app at the moment, I'm guessing I'm making a method call somewhere that's taking too long and blocking the UI thread.
Stepping through the code isn't revealing anything to me. (Perhaps because the problem is on another trip through the run loop? Not sure...I'm a solid iOS developer but a novice when it comes to the debugging and profiling tools.)
What's the best way to tackle a problem like this? Some way to step through or trace what the thread is doing in order and how long each call is taking, or something?
Thanks.
Check out the Time Profiler in Instruments. See WWDC 2012 - Building Concurrent User Interfaces on iOS for a practical demonstration of how you can use profiler to identify candidate methods that you might want to put in a background queue to avoid blocking the main queue.
See the Instruments User Guide for a basic description of the Instruments tool, but I think that WWDC video is a more effective way to gain familiarity with this particular instrument, the Time Profiler. Also, if you've never done concurrent Core Data, you might also want to see the Concurrency with Core Data section of the Core Data Programming Guide.
I will second what's Rob said: you will find more easily what's the bottleneck of your app using Time Profiler in Instruments. All references from Rob are good specially the one from WWDC. I also run into this tut in mobile tuts which covers the basics.
I have a game that I'm getting ready to submit. I've tested it a lot and it seems to be solid -- no crashes and no unexpected behavior. I am not forcing anything to run on the main thread (except for one place where I followed a sample in a book) and now I'm concerned that under some circumstance, on somebody else's device, the game will not work right or crash because I'm not doing something on the main thread that should be on the main thread. But I don't understand what needs to be run on the main thread. I googled for a checklist or summary of what methods need run on the main thread and didn't find anything useful. Is this something I need to worry about? The app is for iOS 5.1 and up and it uses in-app purchases and Game Center. I use the cocos2d framework and also a lot of UIKit stuff.
most methods running on the main thread are fine,
especially the UI,
you want to use the back thread for processes that can take long, like http requests, database or data sorting, or any other process that can pause the user experience while is processing.
if you load lots of objects you can produce a memory warning that can result in a crash,
so you can release non needed objects when you get a memory release.
good luck