The code is too huge to post it here. My problem is the following. When I call animateWithDuration:animations:completion: (maybe with options) with duration == 0.3 it doesn't mean that the completion block will be called through the same delay. It is called through 2 seconds instead and it is too long for me.
This big delay usually appears before memory warnings but sometimes may work as expected.
Could anybody explain what may cause such a strange behaviour?
Are there any timers involved, like is the animation timer-triggered?
I had a similar problem when my animation was timer-triggered. It turned out the animation was started more than once. animationOngoing flag stopped animation from being started again before finishing.
// Timer function
func timerTextToggle(timer: NSTimer) {
if self.animationOngoing == false {
self.flipAnimation()
}
}
// Animation function
func flipAnimation() {
// important note: it's UIViewAnimationOptions,
// not UIViewAnimationTransition
self.animationOngoing = true
if self.animationToggle == false {
UIView.transitionFromView(self.singleTapLabel!,
toView: self.doubleTapLabel!,
duration: animDuration,
options: UIViewAnimationOptions.TransitionFlipFromBottom,
completion: {
(value: Bool) in
self.animationOngoing = false
})
} else {
UIView.transitionFromView(self.doubleTapLabel!,
toView: self.singleTapLabel!,
duration: animDuration,
options: UIViewAnimationOptions.TransitionFlipFromTop,
completion: {
(value: Bool) in
self.animationOngoing = false
})
}
self.animationToggle = !self.animationToggle
}
I experienced a similar problem to this, although without further information on your scenario, I don't know if this also applies to your issue.
I was calling becomeFirstResponder on a UITextField in the completion block of my animateWithDuration:delay:options:animations:completion. Logging showed the completion block was being called in a timely manner, but the keyboard was taking several seconds to show. This was only occurring on first launch of the keyboard.
This answer helped me solve this... turned out this was somehow linked to the iOS Simulator. This issue did not occur when I wasn't debugging the app... another classic example of chasing a bug for hours in the simulator that didn't actually exist.
The cause of this problem is found out. It is a lot of UIWebView objects rendered in the main thread. And it seems impossible to prevent their loading. Anyways time profiler show that a lot of time is spent to render them even if they are not visible on the screen.
And yes, I can't release them before memory warning event because of requirements
Related
When I want to pause the session, this was the only solution for me:
func pauseSession () {
self.sessionQueue.async {
if self.session.isRunning {
self.session.stopRunning()
}
}
}
func resumeSession () {
self.sessionQueue.async {
if !self.session.isRunning {
self.session.startRunning()
}
}
}
This seems to completely stop the session, which is fine, yet looks expensive.
The issue I seem to have is if pause and resume are called near each other in time, the whole app freezes for about 10 seconds, till going back to being responsive. This is mostly due to it still hasn't finished the last process (whether to stop or start).
Is there a solution to this?
The native camera app seems to do this fine. If you open it, open the last photo, you can see the green indicator on the top right going off, meaning the session has paused/stopped. If you swipe down on the photo, the session resumes. If you swipe and let it get canceled, quickly swipe again you can see the session pauses and resumes quickly over and over without any issues.
You may need to change async to sync
self.sessionQueue.sync {
I have a watchOS 4 app which displays SpriteKit animations (SKActions) on top of the UI. Everything works fine in simulator and also on device first couple of times, then after some time when app is in background, and it is started, animations just freeze and completion block for the most long-lasting animation is not called. Any idea what might be the issue?
This is how I run my actions, caller is waiting for completion closure in order to hide the spritekit scene:
private func runActions(with icon: SKShapeNode?, completion: #escaping () -> Void) {
if let icon = icon, let scaleAction = scaleAction, let bg = background {
self.label?.run(fadeInOutAction)
icon.run(scaleAction)
icon.run(fadeInOutAction)
bg.run(backgroundAction, completion: completion)
} else {
completion()
}
}
And yes, I am aware that SKScene is paused when app moves to background. I am doing this in willActivate of my InterfaceController:
if scene.scene?.isPaused == true {
scene.scene?.isPaused = false
}
I want to emphasize that this works first always. It begins to fail after the app has been backgrounded for some time. Especially if I start the app from complication and try to immediately fire these animations, then this freezing happens.
Can I answer my own question? I guess I can? Here goes:
I finally solved this. It turns out that the WKInterfaceScene in WatchKit has ALSO an isPaused property that you need to turn false sometimes. So now in willActivate of my InterfaceController I will also check that and turn it false if it is true. Since I made this change, I haven't seen a single hiccup, freeze or anything weird anymore.
Case closed, I guess. I leave this here for future generations who might face this issue.
I am making my SpriteKit game. When the player dies, my goal is to have the game transition back to the start screen. This is accomplished by the code below. However, I notice that the memory increases each time a new game begins. Xcode Instruments is not showing a memory leak. When the memory reaches roughly 150mb the games frame rate drops and the game become unplayable.
In the GameScene I call this function when the player dies
func gameOver(){
if let block = gameOverBlock {
worldNode.removeAllChildren()
worldNode.removeAllActions()
worldNode.removeFromParent()
self.removeAllChildren()
block()
}
}
Back in the GameViewController the following functions get called
scene!.gameOverBlock = {
[weak self] in
self!.goBack()
}
}
func goBack(){
scene!.removeFromParent()
navigationController!.popToRootViewControllerAnimated(false)
return
}
If anyone has any ideas as to how I can accomplish this without a memory leak, it would much be appreciated.
After commenting out tons of code, I have found the problem. The methods that I have posted above were not causing the leak, as Matthew suggested, there was a strong reference in the middle of my code that was stopping the ARC from releasing memory. Ill post the problem code incase anyone else may have a similar problem.
In my GameViewController, I had the following block:
scene!.zoomInBlock = {
self.scene!.size = CGSizeMake(self.scene!.size.width / 2, self.scene!.size.height / 2)
}
The correct way (without causing a strong reference) to write this would be:
scene!.zoomInBlock = {
[unowned self] in self.scene!.size = CGSizeMake(self.scene!.size.width / 2, self.scene!.size.height / 2)
}
I call a function to open a subview from my parent view.
I see that viewDidLoad is called. In my viewDidLoad is no code.
The strange behaviour is, that sometimes viewDidAppear: is not called even I have not change any code.
Of course there can be a lot of reasons, but I do not know how to debug. I am looking for a way to find out where the process hangs at the time when viewDidLoad is finished.
Does anyone have a hint for me or does anyone know what could be the problem? I mean sometimes it works sometime not. Is viewDidAppear: depending on the parentsview or is there something wrong in the subview?
func showSubview() {
let storyboard = UIStoryboard(name: "Main", bundle: nil)
let vc = storyboard.instantiateViewControllerWithIdentifier("Subview") as! SubViewController
self.presentViewController(vc, animated: true, completion: nil)
//self.showViewController(vc, sender: self);
}
UPDATE
I am calling the showSubview from a async task , I guess this is not good. What do you think and how shall I do it better ? Is there any complition handler with dispatch_async ?
dispatch_async(backgroundQueue, {
dosomething_long();
showSubview();
})
UPDATE 2
The problem is, that I am opening the subview from a background task. I should not do this. But the question is how can I call the subview when the background task is finished. Is there any completion handler for dispatch_async call ?
SOLVED WITH HELP OF GANDALF
I am stupid :-) I should call the subview in the main thread:
dispatch_async(backgroundQueue, {
dosomething_long();
dispatch_async(dispatch_get_main_queue(), {
showsubview();
});
})
The very obvious reason for why program counter may not go inside methods is that app could be running in the release mode.
Now as we can see after updated question that this is not the reason and there is a UI operation happening at background queue.
As per iOS development guidelines all UI operation should happen on main thread, you should try executing that on main thread instead of a background thread.
Try the below code:
dispatch_async(backgroundQueue, {
dosomething_long();
dispatch_async(dispatch_get_main_queue(), {
showsubview();
});
})
The question is; is the view created before? Is it caused when you reopen your app from background?
You can check the lifecycle from here and I think your problem is occurred because of that.
iOS 7 - Difference between viewDidLoad and viewDidAppear
Does any body know what I need to check if app freezes after some time? I mean, I can see the app in the iPhone screen but no view responds.
I did some google and i found that, i've blocked the main thread somehow.
But my question is how to identify which method causes blocking of main thread? is there any way to identify?
Launch your app and wait for it to freeze. Then press the "pause" button in Xcode. The left pane should show you what method is currently running.
Generally, it is highly recommended to perform on the main thread all animations method and interface manipulation, and to put in background tasks like download data from your server, etc...
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
//here everything you want to perform in background
dispatch_async(dispatch_get_main_queue(), ^{
//call back to main queue to update user interface
});
});
Source : http://www.raywenderlich.com/31166/25-ios-app-performance-tips-tricks
Set a break point from where the freeze occurs and find which line cause that.
Chances may be,Loading of large data,disable the controls,overload in main thread,Just find out where that occurs using breakpoints and rectify based on that.
I believe it should be possible to periodically check to see if the main thread is blocked or frozen. You could create an object to do this like so:
final class FreezeObserver {
private let frequencySeconds: Double = 10
private let acceptableFreezeLength: Double = 0.5
func start() {
DispatchQueue.global(qos: .background).async {
let timer = Timer(timeInterval: self.frequencySeconds, repeats: true) { _ in
var isFrozen = true
DispatchQueue.main.async {
isFrozen = false
}
DispatchQueue.global(qos: .background).asyncAfter(deadline: .now() + self.acceptableFreezeLength) {
guard isFrozen else { return }
print("your app is frozen, so crash or whatever")
}
}
let runLoop = RunLoop.current
runLoop.add(timer, forMode: .default)
runLoop.run()
}
}
}
Update October 2021:
Sentry now offers freeze observation, if you don't wanna roll this yourself.
I reached an error similar to this, but it was for different reasons. I had a button that performed a segue to another ViewController that contained a TableView, but it looked like the application froze whenever the segue was performed.
My issue was that I was infinitely calling reloadData() due to a couple of didSet observers in one of my variables. Once I relocated this call elsewhere, the issue was fixed.
Most Of the Time this happened to me when a design change is being called for INFINITE time. Which function can do that? well it is this one:
override func viewDidLayoutSubviews() {
super.viewDidLayoutSubviews()
}
Solution is to add condition where the function inside of viewDidLayoutSubviews get calls only 1 time.
It could be that another view is not properly dismissed and it's blocking user interaction! Check the UI Debugger, and look at the top layer, to see if there is any strange thing there.