-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Very long launch time on iPhone 5 with iOS 10.3.3 #227
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
Comments
@artemkalinovsky Thanks for the report. We've done a few startup performance improvements in the last few updates. Would you try Firebase 4.1.1 to see if that makes a difference? |
@paulb777 I've updated Firebase SDK to version 4.1.1:
But it has no influence on launch time on iPhone 5 (still long, as it was before update) Here're my logs:
|
To help us debug more, can you please provide how you measured the launch time? How did you get 10s of delay? Did it block the app from running for 10s and no screen display at all? |
@baolocdo I'm using Time Profiler to measure launch time. During delay in my app start I see splash screen (LauchScreen.storyboard) In my app
How I can do this? I'm using CocoaPods and seems that FirebaseAnalytics.framework is part of pod 'Firebase/Core'🤔 Thanks |
@artemkalinovsky Does this happen on every start, or just after install? FWIW, the Instance ID 2.0.1 SDK had a performance regression for startup, which was fixed in Instance ID 2.0.2. As a sanity check, make sure you have IID 2.0.2 in your Podfile. Thanks! |
Looks like the InstanceID version posted is 2.0.2, not 2.0.1. Is this reproducible in a sample with just Firebase? It seems in your app there are several other frameworks doing things at startup. |
@rsattar this delay happen on every app start |
Do you mean this:
???
Please, clarify this idea. How I can check this? thanks! |
Those console logs shouldn't have any noticeable effect on launch time, though they may cause other bugs. Can you share the instruments trace, or at least dig down into the launch section and report which method calls are taking up the most time? |
There could be multiple sources that can cause slow startup time. If you uncomment [FIRApp configure], would it improve the startup time?
Are you adding those SDKs as dynamic libraries into a library that your app depends on? (Sorry if this sounds confusing). I have seen similar problem so just want to know if it is the case. |
@morganchen12 |
I'm managing all 3rd party SDKs with Cocoapods.
Ok, to check this, I should remove all Firebase frameworks from my Podfile, and compile each framework by myself from sources and by one add them to my project, right? thanks |
If you're already using CocoaPods, it would be simpler to edit the Podfile and regenerate the Xcode workspace with |
@artemkalinovsky please dig down into the heaviest call stack in Instruments by clicking the small triangle next to |
I would also drill down to expanding |
@rsattar @morganchen12 @paulb777 @baolocdo Also, now I don't use any JSON parsing library like https://github.com/evgenyneu/JsonSwiftson or https://github.com/delba/JASON and https://github.com/evgenyneu/JsonSwiftson. In your, opinion, could they help me? |
just to be clear, which libraries are parsing JSONs? If you are doing it yourself, I'd recommend to dispatch the call to some other queues asynchronously to unblock your main queue. |
Looks like NSJSONSerialization is being invoked from your app, not Firebase. It's unlikely a JSON parsing framework will help you--instead you should do your parsing asynchronously as mentioned above or wait until your app has finished launching before parsing any JSON. |
* compile and run * unit tests pass and swift target compiles * dump build version in activity log * standardize cross sdk imports in firebase iam code (#211) standardize cross sdk imports & polish with style script * using new sample app for testing non-development fiam sdk (#213) * in-app messaging public interface cleanup (#216) * slim down public header files * move testing source files to their correct folders * compiles * style script fine-tune * adding root object creation methods to follow the firebse iOS convension * IAM url following refactor (#218) * @available not supported by blaze build yet (#220) * Clearcut integration for in-app messaging (#222) * Update iam-master to catch up with latest master (#223) * Support multiple triggers defined for the same iam message (#224) * FIAM Clearcut Client Implmentation Improvement (#226) * fixing action url bug and set auto dismiss to be 12 seconds (#227) * use official public api dns name (#233) * Logging firebase analytics events for fiam (#232) * Fine tuning of fiam's code for loading data from caches (#234) * fiam ui fine tuning before EAP (#235) * allow fiam SDK functions to be disabled/enabled dynamically (#247) * analytics event parameter name tuning (#253) * migrate off @import for fiam code (#261) * different modes for fiam sdk at runtime (#262) * realtime clearcut when in running in simulator (#265) * Update interface based on the Firebase API review feedback (#267) * check existence of fiam SDK resource bundle (#268) * handling api keys with application restrictions (#269) * fixing typo and refoctor for unit testing (#270) * fix color method name clash and layout adjust (#271) * Yongmao/layout issue and class rename (#273) * fix long text height calc error * rename class * fiam modal view layout tuning (#274) * test on device for ios client (#275) * dynamic testing mode handling (#277) * main header file comment update and run style.sh (#281) * honor global firebase auto data collection flag in fiam (#283) * honor global firebase auto data collection flag in fiam * address comments * tuning * address review comments * tuning for comments * Rename Core global data collection switch (#287) * Support displaying a messages defined as recurring (#286) * continue * Adjust some inapp messaging dependeces due to the firebase core changes from the upcoming release * bump up version for in-app messaging * Fix impression log clearing race condition bug. (#289) * fix impression handling race condition bug * podspec and interacting interfaces for new firebaseinappmessagingdisplay pod (#290) * create inapp messaging display podspec * Default fiam display UI implementation (#292) * Default fiam display UI implementation. Created the new pod for FirebaseInAppMessagingDisplay * Make FirebaseInAppMessaging headless (#293) * import path tuning * log test message events (#296) * respect fetch wait time from server (#297) * add changelog.md for fiam headless sdk (#300) * port the fetch wait time change back into github (#304) * remove resource bundle check for headless sdk * fix a bug in which the test-on-device message does not follow action url * Add category on NSString to interlace two strings, use it to obfuscate clearcut host name * Use FIR prefix to avoid collisions * Change method name for getting server hostname * Delete Swift example project, its coverage is already duplicated in the FIRInAppMessagingDisplay UITests * Miscellaneous open sourcing cleanup tasks * Convert FIAM to use the Analytics connector (#336) * Convert FIAM to use Analytics connector along with converting to the FIRLibrary component registration model. * Update interop headers for missing methods * Convert existing unit tests * Fix style for fiam sources (#342) * Clean up non-idiomatic ObjC method names * Clean up Swift test target from Podfile * Use dummy GoogleService-Info.plist and don't expose api keys (#343) * Update plist to include fake API keys * Remove changes in non fiam code from iam-master branch (#350) * Fix a few method and parameter naming nits * Fix comment typos in several files * Delete remaining Swift project files
[REQUIRED] Step 2: Describe your environment
[REQUIRED] Step 3: Describe the problem
I have very long launch time for my app (around 10 seconds or even more!). I've tried to turn off Firebase Analytics logs with
-noFIRAnalyticsDebugEnabled
but it has no effect on performance.This issue appears only on iPhone 5.
Steps to reproduce:
Here's my Xcode console logs:
The text was updated successfully, but these errors were encountered: