[google_maps_ios] Cache +[GMSServices sharedServices] when first map is created

[jmagman]

Previously, every MapView creation would reinitialize the underlying Google Maps services:

21.00 ms   10.1%	0 s	 	                -[GMSMapView initWithFrame:camera:]
21.00 ms   10.1%	0 s	 	                 +[GMSServices sharedServicesSync]
16.00 ms    7.7%	0 s	 	                  -[GMSAsyncInitServices services]
16.00 ms    7.7%	0 s	 	                   CompleteInit(GMSAsyncInitServices*)
16.00 ms    7.7%	0 s	 	                    invocation function for block in CompleteInit(GMSAsyncInitServices*)
15.00 ms    7.2%	0 s	 	                     -[GMSServices initWithDisplayLink:resourceCache:clearcutClient:dataURL:cachesURL:options:]
4.00 ms    1.9%	0 s	 	                      -[GMSClientParameters startWithCompletionHandler:]
4.00 ms    1.9%	0 s	 	                       -[GMSClientParameters performFirstUpdateFromLastSavedTime]
4.00 ms    1.9%	0 s	 	                        -[GMSClientParameters reloadSavedClientParameters]
4.00 ms    1.9%	0 s	 	                         -[GMSClientParameters updateAllParamsGroupsToDefault]
3.00 ms    1.4%	0 s	 	                          -[GMSClientParameters updateParamGroup:]
3.00 ms    1.4%	0 s	 	                           -[GMSAPIClientParameters updateTypedParamGroup:]
3.00 ms    1.4%	0 s	 	                            -[GMSCoreClientParameters updateTypedParamGroup:]
2.00 ms    0.9%	0 s	 	                             GMSx_GPBGetObjectIvarWithField
2.00 ms    0.9%	0 s	 	                              _objc_msgSend_uncached
2.00 ms    0.9%	0 s	 	                               lookUpImpOrForward
2.00 ms    0.9%	0 s	 	                                initializeAndMaybeRelock(objc_class*, objc_object*, locker_mixin<lockdebug::lock_mixin<objc_lock_base_t> >&, bool)

Retain opaque object +[GMSServices sharedServices] when the first map is created. This must be called on the main thread, but kicks off background initialization of service syncing. Docs say:

This is an opaque object. If your application often creates and destroys view or service classes provided by the Google Maps SDK for iOS, it may be useful to hold onto this object directly, as otherwise your connection to Google may be restarted on a regular basis. It also may be useful to take this object in advance of the first map creation, to reduce initial map creation performance cost.

Just retaining it is enough to cache for subsequent views, without needing to pass it into the view itself.

See also GM source (internal links)
cs/piper///depot/google3/googlemac/iPhone/Maps/SDK/Maps/GMSServices+Google.h;l=15-20
cs/piper///depot/google3/googlemac/iPhone/Maps/SDK/Maps/GMSServices.mm;l=259-269;bpv=1;bpt=1

Part of flutter/flutter#109057

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
• I signed the CLA.
• The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
• I listed at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[cyanglaz]

LGTM

[stuartmorgan-g]

If this is expensive enough to warrant precaching, it's probably expensive enough that we don't want to kick it off before main. Even though it's a background thread, adding resource contention that early will likely cause a startup time hit for any application using the plugin (and I would expect that most clients of the plugin aren't showing a map immediately on launch, making it an entirely avoidable hit).

I would vote for only automatically caching when the plugin gets its first message, and then adding explicit API to allow precaching, so that app developers can decide when to take that cost.

[jmagman]

If this is expensive enough to warrant precaching, it's probably expensive enough that we don't want to kick it off before main. Even though it's a background thread, adding resource contention that early will likely cause a startup time hit for any application using the plugin (and I would expect that most clients of the plugin aren't showing a map immediately on launch, making it an entirely avoidable hit).

This is a good point. I looked at more traces, I was hoping the maps SDK would essentially be doing what you describe and lazily initialize more when the map is actually created, but it does indeed do a bit of work just setting up, which would be a startup cost.

I would vote for only automatically caching when the plugin gets its first message, and then adding explicit API to allow precaching, so that app developers can decide when to take that cost.

Will move to the first time a map is created. Re: adding an API that's more work than I'm willing to spend on @jonahwilliams's nerd snipe, I'll file a new issue for that. 🙂
Edit: will just use flutter/flutter#109057 instead of filing a new issue.

[stuartmorgan-g]

Sounds good!