2017-09-15 56 views
22

Więc skonwertowałem teraz mój projekt, aby używać Swift 4 w Xcode 9, i zacząłem testować moją aplikację. Jest to duża aplikacja z czterema różnymi kartami i prawie wszystko działa zgodnie z oczekiwaniami. Jedną z kart jest mapa za pomocą GoogleMaps. Nigdy nie miałem z tym żadnych problemów, ale kiedy zbudowano go z Xcode 9 i pokazałem w Symulatorze, używa on przez 100% CPU podczas przesuwania mapy, i to jest bardzo opóźnione. Oto nawigator debugowania podczas działania na symulatorze. Wykonujemy rysunki niestandardowe, ale nie rysujemy wartości 102%.GoogleMaps na symulatorze w Xcode 9 używa ponad 100% procesora podczas przenoszenia mapy

CPU usage

tylko to zaczęło się dziać po I zaktualizowany do Xcode 9 i Swift 4. Gdy debugowanie w Xcode 9 na iPhone 7, 8 lub X symulatorze, wszystkie z iOS 11, przechodzi właśnie nad 100% CPU i całkowicie zatrzymuje aktualizację interfejsu na około jedną sekundę za każdym razem, gdy próbuję go przenieść. Uruchamiam gest przeciągania, ale interfejs aktualizuje się tylko raz na sekundę. Skutecznie daje mi około 1fps.

Jednak podczas debugowania w Xcode 9 na iPhone 6 symulatorze z iOS 9, to dostaje się do ~ 90% przy przesuwaniu mapy i nie pozostaje prawie tyle. Zgaduję, że mam tutaj około 20-30 fps. (Może to być ta sama liczba klatek na sekundę, jaką dostaję w symulatorze na Xcode 8. Map nigdy nie była naprawdę gładka na symulatorze.)

Podczas pracy na rzeczywistym urządzeniu (iPhone 7, iOS 11), procesor zużywa około 40% gdy ciągle porusza się po mapie i działa bardzo płynnie bez żadnych opóźnień (60fps).

Ja też się to na wyjściu, jak tylko otworzyć zakładkę z mapą, ale myślę, że to bez znaczenia dla tego konkretnego pytania:

Main Thread Checker: UI API called on a background thread: -[UIApplication applicationState] 
PID: *****, TID: *******, Thread name: com.google.Maps.LabelingBehavior, Queue name: com.apple.root.default-qos.overcommit, QoS: 21 

Ten mówi, że GoogleMapsAPI wzywa [UIApplication applicationState] na wątek tła.

Używam najnowszej wersji GoogleMaps: 2.4.0. O ile mi wiadomo, ta wersja może nie obsługiwać Xcode 9/Swift 4 itd., Ale nie mogę znaleźć nic na temat nowej wersji.

+0

myślę, że należy zwrócić ten temat form rozwoju google zbyt . Ponieważ mogliby nam dać odpowiedź. –

+0

@AbuUlHassan Pomyślałem o tym, ale podali na stronie wsparcia dla GoogleMapsAPI, że StackOverflow i te niestandardowe tagi (mapy google) są monitorowane przez kilku członków zespołu GoogleMapsAPI i zachęcamy nas do korzystania z niego (https: // developers.google.com/maps/documentation/ios-sdk/support) Naprawdę nie podoba mi się ich tracker problemów. – Sti

+0

@Sti Czy testowałeś to na prawdziwym urządzeniu? – Aznix

Odpowiedz

17

Aktualizacja: Ten problem został rozwiązany w Xcode 9.1 beta 2

Jest to błąd w OpenGLES.framework że powoduje pominięcie ładowania JIT LLVM i spaść z powrotem do interpretacji shaderów. Ma to poważny wpływ na wydajność symulatora, ponieważ jest on w całości renderowany przez oprogramowanie OpenGL (w tym CoreAnimation, SceneKit itp.).

edycja: Aby wyjaśnić, objawy tego są dokładnie to, co opisujesz: 100% lub więcej użycie procesora i < rendering 1 fps. Wpływa to na Google Maps SDK i MapKit.

Jako tymczasowe obejście możesz skopiować libCoreVMClient.dylib z Beta 3 do Xcode 9 GM i wydajność powinna zostać przywrócona do poprzedniej wersji. Należy to zrobić oddzielnie dla każdego środowiska wykonawczego platformy.

Dla iOS ten znajduje się pod adresem: Xcode[-beta].app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/OpenGLES.framework/libCoreVMClient.dylib

Dla tvOS ten znajduje się pod adresem: Xcode[-beta].app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/OpenGLES.framework/libCoreVMClient.dylib

Dla watchOS ten znajduje się pod adresem: Xcode[-beta].app/Contents/Developer/Platforms/WatchOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/watchOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/OpenGLES.framework/libCoreVMClient.dylib

+0

Nadal jestem nieco zdezorientowany ... czy ten błąd ma jakikolwiek wpływ na prawdziwe urządzenia, czy tylko na symulator? Rozumiem, że nie używa 100% procesora na prawdziwym urządzeniu, ale czy w ogóle ma to wpływ? I jeśli użyję dylib z b3 - następnie skompiluję i zbuduję i wyeksportuję swoją aplikację do AppStore, czy ta kompilacja będzie inna niż kompilacja używająca GM-dylib? Nie jestem do końca pewien, jaki to jest plik, i niechętnie go wyłączę na wypadek nieprzewidzianych skutków ubocznych. – Sti

+1

Ten błąd nie wpływa na wydajność urządzenia. Zastąpienie dylib nie ma wpływu na to, co zostanie zbudowane lub przesłane do sklepu z aplikacjami. Jest to wyłącznie środowisko wykonawcze Simulatora. Możesz również pobrać i używać środowiska wykonawczego iOS 10.3 (które nie ma tego błędu) z Xcode 9. – russbishop

+0

Dobra odpowiedź, ale gdzie możemy pobrać stary plik? Przesyłanie byłoby bardzo doceniane. –