-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix retain cycles preventing objects from being deallocated after logging out #21047
Fix retain cycles preventing objects from being deallocated after logging out #21047
Conversation
…shboardStatsCardCell
…MySiteViewController
@guarani Just informing you that it's still in progress, although most of the classes are finally released after the logout:
|
📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.
|
📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.
|
Problem: - RootViewCoordinator is a singleton - RootViewCoordinator holds a strong reference to RootViewPresenter - WPTabBarController implements RootViewPresenter and is presenter as rootViewController - When WPTabBarController is dismissed, RootViewCoordinator continues to hold a strong reference to a WPTabBarController creating a memory leak Solution: - Move presentation logic from WindowsManager to RootViewCoordinator - Only initialize RootViewPresenter when needed - Release RootViewPresenter after logging out. Not making RootViewPresenter weak or unowned to avoid further cascading changes through the codebase to handle RootViewPresenter being optional - RootViewPresenter should not be accessed before the root view is presented. If it happens - print a warning. All the issues should be addressed with further improvements.
880e34c
to
daf8e08
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only did a partial review since you mention this isn't ready yet. I just went through the code changes but didn't test it. Once it's ready I can dive deeper and actually test the changes, let me know if this works for you.
I left some comments with first impressions, but they're things I might be able to answer myself after spending more time review and testing.
WordPress/Classes/ViewRelated/Blog/Blog Dashboard/Cards/Prompts/DashboardPromptsCardCell.swift
Show resolved
Hide resolved
WordPress/Classes/ViewRelated/Blog/Blog Dashboard/ViewModel/BlogDashboardViewModel.swift
Show resolved
Hide resolved
…logout - Made WordPressAuthenticator injectable - Checking if rootViewController is deinitialized after presenting signInUI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Login & Logout (On both Jetpack and WordPress apps)
- Login
- Logout
3 Check Memory Graph- WPTabBarController and other non-login related view controllers should be deallocated
Here the app's starting memory was 155 MB, went to 313 MB after logging in, and stayed high (323 MB) after logging out (the increase is explained by navigating to the log out screen). I saw you mention how there's many other retain cycles that are out of scope of this PR and that could explain this. I checked the Memory Graph and indeed WPTabBarController
is no longer there (this was while testing the Jetpack app), which is a good sign.
This PR does appear to fix a retain cycle, but it might not be reducing the app's memory consumption overall. If so, putting this in the release notes as I suggested earlier might more sense once we've addressed some of the other retain cycles. What do you think?
It's not easy to grok how the window management works (especially across the two apps + the migration flow). However, I think the approach is promising. I'm happy to approve this once I can spend more time on the regression testing tomorrow and can get a bit more confidence in the fix. On a side note, splitting this into multiple PRs could be an option so that if for example a change needs to be reverted, we won't need to revert all these separate fixes.
Thanks for the review, @guarani !
Yes, you're right. I had the expectation of fixing these retain cycles to clean the memory but there're more issues that I will address with future PRs. I didn't want to make this one too big. I will update the release notes.
A lot of the small retain cycle improvements include retain cycles with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Finished manual testing and everything is working as before.
Tested on iPhone:
- Login & Logout (On both Jetpack and WordPress apps). Tested:
- Tested WP app
- Tested WP to JP app migration
- Tested JP app
- Regression test: WordPress without static posters
- Regression test: WordPress with static posters
- Regression test: Dashboard Blaze card
Tested on iPad:
- Regression test: Dashboard Quick Actions
- Regression test: Dashboard navigation
- Regression test: Reader navigation
The code changes look good and I think this is ready to merge 👍
Fixes #21010
Memory is not deallocated after logging out.
It is caused by 2 main issues:
WPTabBarController
held strongly by singletonRootViewCoordinator
after logging out (see more details)Solution
To address issues in
RootViewCoordinator
I decided to limit the changes as much as possible to avoid cascading code changes throughout the codebase. For now, I decided to manually release a reference toRootViewPresenter
(WPTabBarController
) once logging out. See more info in commit message.To test:
Login & Logout (On both Jetpack and WordPress apps)
3 Check Memory Graph
Regression: WordPress without static posters
Regression: WordPress with static posters
Regression: Dashboard Blaze card
Regression: Dashboard Quick Actions
Regression: Dashboard navigation
Regression: Reader navigation
Regression Notes
Breaking the currently existing functionality, especially root navigation
None for now but It may be worth considering about performance tests or tests confirming the deallocation of main VCs
PR submission checklist:
RELEASE-NOTES.txt
if necessary.