I have an Electron app (running on a Mac) that waits in the background for a key press, before showing a window.
If I leave it in the background overnight and then use it, it will be very slow for the first 10 seconds or so. It seems like updating the DOM and inter-process communication are both slow. The delay isn't coming from my code, and it seems to affect the renderer process primarily. After the initial slowness, it starts working normally.
Is there any reason that an Electron app would do this? Is it getting unloaded from memory somehow?
What's odd is that the initial display of the window happens instantly; it's just after I start to do some inter-process communication that it slows down.
There are a few possible answers to this, but after spending countless hours figuring it out, I thought I'd share the one that worked for me.
I was showing an animated SVG when I put the app in the foreground, and hiding it when I put it in the background. Apparently this was queueing up animation frames even while hidden, and then un-queueing them when it was shown, causing the delay.
It was fixed by upgrading Electron from 8.5.5 to 9.0.0, which I believe upgraded Chromium from 80.0.3987.165 to 83.0.4103.64. Not sure what the exact fix was, but it worked.
Related
I am working on a SwiftUI app that has a lot of animation components to it. When the app is in foreground, the Custom Animation on Shapes work fine, no latency. They run smoothly at 60 FPS.
When the app comes to foreground after going from background, the app freezes for a few seconds and becomes completely non-responsive. Then it comes back to normal behavior.
I tried running the Time profiler instrument but the main thread is not blocked. Seems like there is no work happening on the CPU. What is interesting is that there is a gap between the background state and the foreground state (In the app lifecycle track) of the app as shown in the image.
What might be causing the app to freeze? Any ideas on how to debug this issue?
If it helps, the app also has a core-motion component to it which I am not pausing when the app goes to background.
I considered a similar issue. In my case it turned out that the modifier .drawingGroup() caused the issue. If I start my app everything was fine, but if I put it to background and bring it to foreground again it stopped for 4 seconds. I removed the drawingGroup modifier and this issue was solved.
I have a app that opens straight to a camera that is based on this WWDC sample: https://developer.apple.com/library/ios/samplecode/AVCam/Introduction/Intro.html
A few users have been experiencing a bug where the camera does not turn on and does not allow them to capture content.
I just ran into the same issue last night and this is what I observed:
I was debugging a separate issue and the camera was working 100% ok, then all of a sudden, it stopped working.
Every time I would open the app or navigate back to the camera, it would show a dark view of whatever it was currently pointing at, but the image was frozen. Its like it worked for 1 second, then the capture preview would freeze.
I tried force closing and reopening, same problem.
I tried uninstalling and reinstalling, same problem.
I then restarted my phone and the issue was solved.
How is it possible that this bug persists between separate installs?
Does anyone know what might be causing the camera to fail?
How should I go about debugging it if it only occurred once after months of using it and I have no idea what triggers it?
Are you running iOS 9?
That might be an iOS 9 software internal bug.
I had exactly the same non-reproducible issues but with MapKit's map view rendering.
In my case map view was showing just rectangle grid without any map objects - no streets, lakes, rivers, etc.
I've tried to google over internet to find potential reason of such weird issue, but without any luck. Then I've restarted device and that helped, the same as in your case.
Sure, my info is not a full answer, just want to share my experience.
Your process does not have direct access to the camera hardware, but rather through a device manager. It is the state of that manager that determines if things will work.
To confirm, when your app is experiencing issues, kill it then open the default Camera app. If it shows a blank or still frame preview, then you know it's not necessarily a problem in your app.
I have an iOS Xcode project that previously would load fast, but from time to time, now will hang for five seconds or more during loading. When the app is run on an iPhone, the launch screen displays instantly, but sometimes, not always, and unpredictably, the app just hangs for around 5 seconds or more until the actual interface is displayed. It occurs both on the simulator and device across different iOS versions 7, 8, 9.
Recently, a UIView's class that contains a drawRect function was changed slightly, it has an outlet connection to one of the ViewControllers, but no significant changes made overall. One ViewController has code in the ViewDidLoad, ViewWillAppear, ViewDidAppear functions. All these things I'm investigating if they are impacting the load time.
When I terminate the app, the next time I try running it, it loads super fast without issue. I have no idea what to make of this load behaviour.
Questions
1 - What methods can I use in Xcode to debug an app that loads slowly at irregular and unpredictable times?
2 - What obvious items should I be on the look out in the project that typically cause slow or prolonged load times?
3 - Does Xcode include tools to monitor the processes operating live while loading occurs?
4 - Is it possible to print output for load processes I can review?
Any experienced advice really appreciated. Thanks.
Not sure if you have looked instrumentation. It is the best way to determine this kind of issues with your app.
https://developer.apple.com/library/watchos/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/index.html
When I terminate the app, the next time I try running it, it loads super fast without issue. I have no idea what to make of this load behavior.
Do you mean exiting the app? Or actually killing it? Cause if it is the former, then the reason is the app was just launched from a suspended state.
I would suggest take a closer look at didFinishLaunchingWithOptions:, and check if you are doing something that takes more time than needed. Run your app with the time profiler instrument, it will tell you where is your bottleneck.
I'm experiencing intermittent hard freezing of multiple apps on UITextFields, UITextViews and UISearchBars becomingFirstResponder. The freeze happens before the keyboard comes onto the screen. The app does eventually seem to recover, but takes a very long time. Most users will loose patience before this happens however.
The common factor between the apps seems to be registering for UIKeyboardWillShowNotifications, but a trivial amount of work is done in the selectors registered for this notification.
Is anyone else seeing this and/or found a solution?
I had same problem. In my case, it wan only iPad and stuck on [textView becomeFirstResponder] for about 3 minutes. I delete the app and downloaded my app from app store and confirmed the live version does not have the issue. I went back to Xcode and run after restoring all changes I made to fix the bug. Everything works fine now.
I am getting a strange behavior when I reopen my app after it loses focus from the home button. On the simulator the app screen goes black for 5 seconds or more before the application is resumed. On the test device, the application either does the long delay or quits entirely and resets to starting state. I have put NSLog debug comments in the “applicationWillEnterForeground” and “applicationDidBecomeActive” but these only appear after the long delay so I will assume for now that nothing in these functions cause this delay.
I am using the following components in my program:
* a Tab Bar Controller
* 2 Timers, the Map kit
* IP socket streams
* 24 ViewControllers strung together on a storyboard.
* quite a few background images and image buttons
I would happily post code if I know what parts of the program was causing this error, but as it is I am clueless. Has anyone else experienced this type of error? Do any of the components I have listed have a history of causing similar errors?
I was quite far in development when this bug was discovered and I did not test for loss of focus via home button during the incremental development process. Other, smaller projects (which used sockets and timers) did not suffer from the same bug on the same test hardware.
I am using “applicationWillResignActive” to disable the timers, and close the streams. I am using “applicationDidBecomeActive” to restart the timers, and reopen the streams. The delay is occurring before “applicationWillEnterForeground” and “applicationDidBecomeActive” is run. Further more I tried disabling the code that initiates the streams and timers, but this did not have any effect on the bug.
I am using xCode4.4.1, ios6, and am building exclusively for iPads.
It's possible that the debugger is playing tricks with your mind regarding when it shows that you hit a breakpoint and the code execution of applicationWillEnterForeground. I suggest you commit your most recent code to source control and start deleting sections one at a time till you see the behavior go away.