Diskussion: Om Android minnes hantering och iOS. Intressant läsning.

För de som fortfarande använder tasker killer dylikt. Läs hur RAM minnen hanteras i Android.

View: https://www.reddit.com/r/explainlikeimfive/comments/7pvzmu/eli5_what_does_ios_do_differently_to_android_for/dskn9ir/


Android was built to run Java applications across any processor - X86, ARM, MIPS, due to decisions made on the early days of Android's development. Android first did this via a virtual-machine (Dalvik), which is like a virtual computer layer between the actual hardware and the software (Java software in Android's case).

Lots of memory was needed to manage this virtual machine and store both the Java byte-code and the processor machine-code as well as store the system needed for translating the Java byte-code into your device's processor machine-code. These days Android uses a Runtime called ART for interpreting (and compiling!) apps - which still needs to sit in a chunk of memory, but doesn't consume nearly as much RAM as the old Dalvik VM did.

Android was also designed to be a multi-tasking platform with background services, so in the early days extra memory was needed for this (but it's less relevant now with iOS having background-tasks).

Android is also big on the garbage-collected memory model - where apps use all the RAM they want and the OS will later free unused memory at a convenient time (when the user isn't looking at the screen is the best time to do this!).

iOS was designed to run Objective-C applications on known hardware, which is an ARM processor. Because Apple has full control of the hardware, they could make the decision to have native machine code (No virtual machine) run directly on the processor. Everything in iOS is lighter-weight in general due to this, so the memory requirements are much lower.

iOS originally didn't have background-tasks as we know them today, so in the early days it could get away with far less RAM than what Android needed. RAM is expensive, so Android devices struggled with not-enough-memory for quite a few years in the early days, with iOS devices happily using 256MB and Android devices struggling with 512MB.

In iOS the memory is managed by the app, rather than a garbage collector. In the old days developers would have to use alloc and dealloc to manage their memory themselves - but now we have automatic reference counting, so there is a mini garbage collection system happening for iOS apps, but it's on an app basis and it's very lightweight and only uses memory for as long as it is actually needed (and with Swift this is even more optimised).

EXTRA (for ages 5+): What does all this mean?

Android's original virtual machine, Dalvik, was built in an era when the industry did not know what CPU architecture would dominate the mobile world (or if one even would). Thus it was designed for X86, ARM and MIPS with room to add future architectures as needed.

The iPhone revolution resulted in the industry moving almost entirely to use the ARM architecture, so Dalvik's compatibility benefits were somewhat lost. More-so, Dalvik was quite battery intensive - once upon a time Android devices had awful battery life (less than a day) and iOS devices could last a couple of days.

Android now uses a new Runtime called Android RunTime (ART). This new runtime is optimised to take advantage of the target processors as much as possible (X86, ARM, MIPS) - and it is a little harder to add new architectures.

ART does a lot differently to Dalvik; it stores the translated Java byte-code as raw machine-code binary for your device. This means apps actually get faster the more you use them as the system slowly translates the app to machine-code. Eventually, only the machine code needs to be stored in memory and the byte-code can be ignored (frees up a lot of RAM). (This is Dalvik, not ART). Art compiles the Java byte-code during the app install (how could I forget this? Google made such a huge deal about it too!) but these days it also uses a JIT interpreter similar to Dalvik to save from lengthy install/optimisation times.

In recent times, Android itself has become far more power aware, and because it runs managed code on its Runtime Android can make power-efficiency decisions across all apps that iOS cannot (as easily). This has resulted in the bizarre situation that most developers thought they'd never see where Android devices now tend to have longer battery life (a few days) than iOS devices - which now last less than a day.

The garbage collected memory of Android and its heavy multi-tasking still consumes a fair amount of memory, these days both iOS and Android are very well optimised for their general usage. The OS tend to use as much memory as it can to make the device run as smoothly as possible and as power-efficient as possible.

Remember task managers on Android? They pretty much aren't needed any more as the OS does a fantastic job on its own. Task killing in general is probably worse for your phone now as it undoes a lot of the spin-up optimisation that is done on specific apps when they are sent to the background. iOS gained task killing for some unknown reason (probably iOS users demanding one be added because Android has one) - but both operating systems can do without this feature now. The feature is kept around because users would complain if these familiar features disappear. I expect in future OS versions the task-killers won't actually do anything and will become a placebo - or it will only reset the app's navigation stack, rather than kills the task entirely.

Så sluta använda tasker managers och låt Android hantera det istället om man vill ha längre batteritid.

 

nu ska de bara kunna presentera lite snyggt vad som drar batteri ist för att göra det svårare som de gör version för version. ios får fler och fler plus och android gräver sig längre och längre in i arslet för egen del

 

Det är väl inte särskilt svårt att se vad som drar batteri i Android, finns ganska detaljerad information i inställningarna. Inte riktigt vad inlägget handlade om heller, handlade om minneshantering.

 

true dat det var mer en reflektion på inte använda task kilelrs för bättre batteritid..
för övrigt så så intåget av allt fler funktioner som bakas in i google services även från andra utvecklares appar gjort det betydligt svårare att se vad som drar batteri och från vilken app problemet kommer. Det är inte ens jämförbart med hur det var för 2 versioner sedan.

 

Jag förstår inte alls. Vad är det som drar batteri som du inte får vetskap om? Google Play Services?

 

att reda ut vad för app som drar batteri eller vad i en app som drar batteri är inte en lika exakt vetenskap idag som för ett par år sedan iom att så mycket bakas in under google services. Information kan många ggr oxå hittas om vad för service i google services som drar batteri men helt utan hänvisning till vilken eller vilka appar som användts sig av funktionen.