Quote (Majonez @ 22 Mar 2016 12:32)
Gc?
e/ moja historia napraw sprzetow od apple dosyc mocno zaprzecza tej "bezawaryjnosci".
GC = Garbace Collection
Tutaj w miare krótki i przystępny opis:
https://www.quora.com/Whats-the-difference-between-Java-garbage-collection-and-Objective-C-ARCGeneralnie jak programujesz, a potem uruchamiasz ten program na jakiejś platformie to w trakcie pracy on zajmuje, modyfikuje i zwalnia jakieś fragmenty pamięci operacyjnej.
No i teraz sposób zarządzania tymi procesami jest różny, problemem jest tak naprawde ich zwalnianie.
iOS:W Objective-C programista musiał to zwolnić ręcznie jak tylko przestawała być potrzebna, jeśli zapomniał (a o to łatwo) to pojawiały się różne błędy typu wycieki pamięci. Powiedzmy, że masz prosty program, który pobiera obrazki z imgura i wyświetla je na ekranie, po jego wyświetleniu powinieneś usunąć go z pamięci, jeśli zapomnisz to zrobić to on mimo tego, że jest już do niczego nie potrzebny zostaje w RAMie i zajmuje pamięć. Tak powstają wycieki pamięci i czasami prosty program potrafi wpierdolić cały RAM. Za to jest szybszy i jeśli działa dobrze to zajmuje tylko tyle, ile potrzebuje bo wszystko co zbędne zwalniane jest natychmiast.
W Swift (język, który zastąpił ObjC) nad wykonywanym programem siedzi mechanizm nazywany ARC (automatic reference counting), który pilnuje, żeby każdy blok pamięci został jak najszybciej zwolniony, nie robisz tego ręcznie, ale jest jakiś dodatkowy narzut performance'u przez tę warstwę, która pilnuje pamięci.
W każdym razie szybkość działania programu jest raczej stała, tzn. to wszystko dzieje się real-time.
Android:Za to Java i jej wirtualne maszyny mają zupełnie inne podejście do tego, one nie sprawdzają tych rzeczy natychmiast tylko co jakiś czas (przyjmijmy, że co kilka sekund) cały program się zatrzymuje, pamięć jest skanowana, zaznaczane są fragmenty pamięci, które są już niepotrzebne i zwalniane. To się dzieje w cyklach i one mogą być widoczne właśnie jako ścięcia systemu.
To działa po prostu na innej zasadzie, bo przez chwile program po prostu robi co chce i szybko, a spowolnienie pojawia się rzadziej i często masz kompletne tzw. stop-the-world.
Problem jest też taki, że to wszystko potrzebuje więcej RAMu do dyspozycji, bo program działa, zajmuje coraz więcej i więcej pamięci, potem włącza się GC i część czyści i tak w kółko.
Jak narysujesz wykres zużycia pamięci podobnego programu na obu platformach to w iPhone to może być stabilna pozioma linia, a w Androidzie zygzak latający z góry na dół.
U Apple zużycie pamięci jest po prostu stabilniejsze i bardziej przewidywalne stąd szybkim iPhone'om wystarcza po 1GB pamięci, a Androidy mają zwykle po dwa razy więcej.
Dlatego porównywanie takich specyfikacji między platformami jest często bez sensu bo filozofia ich działania i radzenia sobie z pamięcią jest skrajnie inna i tyle.
(Nie wiem co prawda czy to zupełne zatrzymanie systemu w Androidzie 6.0 nadal jest prawdą, bo są na pewno jakieś minor-gc-scan, major-gc-scan, full-gc-scan, nie chce mi się teraz doczytywać, nie śledzę tego na bieżąco bo nie potrzebuje.)
Do tego z tego co pamiętam w iOS wątek odpowiadający za user interface ma zawsze najwyższy priorytet, więc interfejs zawsze jest płynny i nie ma takich przycięć. Android zachowuje się inaczej.
To wszystko oczywiście jest wkurwilion razy bardziej skomplikowane i działa nie do końca tak jak ja napisałem, ale nie ma to tutaj wielkiego znaczenia.
https://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29 - wiki nawet sensownie tłumaczy GC.
Jako, że na codzień zajmuje się raczej innego rodzaju developerką to bardzo proszę wypomnieć błędy w moim poście wyżej, jeśli ktoś coś znajdzie.
Kiedyś kodowałem iPhone w ObjC, miałem bardzo krótkie spotkanie ze Swiftem, w tej chwili znowu trafił mi się Android.
pozdrawiam, tępy użytkownik ajfona