Reduce NSURLSession memory footprint #969
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Adds method to add default stripe headers to any request Setting the headers on requests instead of re-instantiating NSURLSession with new default headers avoids memory accumulation from the security framework (see https://developer.apple.com/library/archive/qa/qa1727/_index.html)
danj-stripe
approved these changes
Jun 15, 2018
Stripe/STPAPIClient.m
Outdated
| @@ -160,7 +174,7 @@ - (void)setStripeAccount:(NSString *)stripeAccount { | |||
| _stripeAccount = stripeAccount; | |||
|
|
|||
| // Regenerate url session configuration | |||
| self.urlSession = [NSURLSession sessionWithConfiguration:[self sessionConfiguration]]; | |||
| // self.urlSession = [NSURLSession sessionWithConfiguration:[self sessionConfiguration]]; | |||
There was a problem hiding this comment.
These should be deleted, not commented out.
Stripe/STPAPIClient.m
Outdated
| return [additionalHeaders copy]; | ||
| } | ||
|
|
||
| - (void)setUrlSession:(NSURLSession *)urlSession |
There was a problem hiding this comment.
Is this needed/ever called? I saw you made the urlSession readonly.
There was a problem hiding this comment.
ah yeah, this is a vestige of a previous experimient. Guess I forgot to clean up the branch before making this PR :P
| @@ -63,7 +63,7 @@ - (void)testInitWithConfiguration { | |||
| STPAPIClient *sut = [[STPAPIClient alloc] initWithConfiguration:config]; | |||
| XCTAssertEqualObjects(sut.publishableKey, config.publishableKey); | |||
| XCTAssertEqualObjects(sut.stripeAccount, config.stripeAccount); | |||
| NSString *accountHeader = sut.urlSession.configuration.HTTPAdditionalHeaders[@"Stripe-Account"]; | |||
| NSString *accountHeader = [sut configuredRequestForURL:[NSURL URLWithString:@"https://www.stripe.com"]].allHTTPHeaderFields[@"Stripe-Account"]; | |||
There was a problem hiding this comment.
Nit: Might be nice to extract this into a helper method on the test case.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Don't create a new NSURLSession instance for each ephemeral key request
Motivation
https://jira.corp.stripe.com/browse/IOS-773
Creating NSURLSessions induces a memory overhead because iOS allocates and saves cache space (ref. https://developer.apple.com/library/archive/qa/qa1727/_index.html). We were also not properly invalidating old sessions as we replaced them, aggravating the problem.
The other option which appears to remove all memory leaks is to use the shared instance of NSURLSession, but we want to keep a private instance. Using an ephemeral configuration (see link below) can also remove any of the reported links, but does not suit our use case.
More references:
https://stackoverflow.com/questions/42780244/swift-3-urlsession-memory-leak
https://stackoverflow.com/questions/28223345/memory-leak-when-using-nsurlsession-downloadtaskwithurl/35757989#35757989
http://footle.org/2015/10/10/fixing-a-swift-memory-leak/
Testing
I used the standard integration demo and was able to easily reproduce the reported leaks just by viewing an item. With the changes all leaks attributed to the Stripe library were gone.