Il sistema operativo Android

Transcript

1 Il sistema operativo Android Kernel Android e Dalvik/ART Virtual Machine Letture consigliate: Il sistema operativo Android A.A

2 Android vs Linux (1) Il kernel di Android è una fork del kernel Linux con i seguenti vantaggi: Rilasciato con GNU General Public Licence (GPL) Gestione efficiente della memoria e dei processi Gestione della sicurezza basato sui permessi Modello consolidato dei driver Fornisce il supporto alle librerie condivise Target di dispositivi ed architetture estremamente vasto: laptop, desktop, server, tablet, sistemi embedded A.A

3 Android vs Linux (2) Piattaforma target specifica Architettura di riferimento ARM (RISC) La piattaforma ARM garantisce consumo di energia inferiore alla piattaforma Atom (x86) Gestione dei processi Binder Gestione dell energia Meccanismo di wake locks Sottoinsieme delle librerie di utilità Linux Libreria BioniC sostituisce GNU glibc, non sono incluse tutte le utility standard Linux Gestione del File System File System YAFFS/EXT4 A.A

4 Binder Isolamento dei processi: le applicazioni Android e i servizi di sistema sono eseguiti in processi separati per ragioni di sicurezza, stabilità, e gestione di memoria, ma hanno bisogno di comunicare e condividere i dati! E un driver per facilitare la comunicazione IPC (inter-process communication) Un pool di thread è associato a ciascun processo applicativo per gestire le richieste IPC References counting traccia i riferimenti degli oggetti condivisi tra i processi in modo da garantire che non vengano distrutti finché qualche processo ha un riferimento ad essi Mantiene un mapping univoco delle risorse (oggetti) fra due processi servendosi della memoria del kernel spazio condiviso tra i diversi processi (sola lettura) per il passaggio degli oggetti La comunicazione è sincrona: quando un processo A effettua una chiamata a B, A si blocca finché non riceve una risposta. A.A

5 Power Management Il gestore dell energia deriva dal Linux Power Management standard Viene adottata una politica più aggressiva per il risparmio energetico wake lock richiesta esplicita al servizio (driver) di attivare/disattivare una determinata risorsa per gestire i meccanismi di consumo Di default il sistema Android tende a mettere il sistema in pausa o in sospensione il prima possibile Android consente alle applicazioni user di inibire il passaggio del sistema allo stato sleep o suspend mediante wave lock Le wake locks possono essere acquisite sia dalle componenti del kernel che dai processi dello user space Il Power Manager è un servizio di sistema che consente alle applicazioni in esecuzione su Dalvik/ART di utilizzare le wake locks A.A

6 Power Management: Wake locks Esistono diversi tipi di wake lock: PARTIAL_WAKE_LOCK La CPU rimane attiva, anche se viene premuto il pulsante di spegnimento SCREEN_DIM_WAKE LOCK Lo schermo rimane acceso, ma oscurato SCREEN_BRIGHT_WAKE_LOCK Lo schermo resta acceso con luminosità normale FULL_WAKE_LOCK La tastiera e lo schermo rimangono accesi con retroilluminazione normale Solamente il PARTIAL_WAKE_LOCK assicura che la CPU sia completamente attiva (*) Gli altri 3 tipi consentono alla CPU di andare in sleep quando viene premuto il pulsante di spegnimento A.A

7 Power Manager: funzionamento A.A

8 Android File System (1) Flash memory: memoria a stato solido, di tipo non volatile, che può essere cancellata e riprogrammata a blocchi. Occorrono file system ottimizzati per gestire le sue caratteristiche peculiari: Accesso casuale: no seek time una memoria flash non ha alcuna latenza causata da un'operazione di ricerca. Block erasing: su disco la cancellazione è più semplice. Per flash memory i blocchi devono essere esplicitamente cancellati prima che vi sia nuovamente consentita la scrittura. Questa è una operazione che richiede tempo e pertanto deve essere eseguita negli istanti idle. Wear leveling: per le flash memory serve gestire il deterioramento. A.A

9 Android File System (2) Yet another Flash File System (YAFFS2) < Android 2.3 File System Linux ottimizzato per memorie flash di tipo NAND Journaling: file system basato su log, garantisce la robustezza in caso di cadute di alimentazione, necessita di una parte della RAM Garbage Collector: Il GC viene richiamato quando lo spazio libero diventa basso. Meccanismo di block erasure. Basso consumo di energia Flessibilità: è altamente configurabile, può essere customizzato per vari tipi di memorie flash, con differenti opzioni di correzione di errore, caching ecc. Portabilità: la struttura modulare del codice garantisce il porting su differenti sistemi operativi Robustezza: Bad Block Management (BBM) Supporto a POSIX: directory, hard link e symbolic link Fourth extended filesystem (ext4) >= Android 2.3 PROBLEMA: YAFFS2 è single-threaded collo di bottiglia per sistemi dual-core (e multi-core). Sostituito da ext4. A.A

10 Block erasing Su memoria NAND non è possibile riscrivere o cancellare un singolo chunk Per cancellare un chunk in memoria occorre cancellare l intero blocco Ciascun segmento da cancellare o riscrivere è segnato come dirty Quando tutti i segmenti di un blocco sono dirty il blocco può essere cancellato Il GC sceglie un blocco contenente pagine dirty e pagine corrette. Le pagine corrette vengono spostate in un altro blocco. Il blocco scelto viene contrassegnato come dirty ed eliminato Questa operazione viene effettuata in background mentre il dispostivo non è in uso Update: ogni volta che la memoria deve essere aggiornata il file system non aggiornerà direttamente il blocco originale, ma scriverà una nuova copia dei dati modificati su di un blocco libero, modificando i puntatori per poi cancellare i dati dal vecchio blocco, rendendolo a questo punto nuovamente libero. A.A

11 Memory wearing Le memorie flash hanno un numero limitato di cicli di lettura e scrittura Deterioramento dell integrità dei dati alla fine del ciclo di vita della memoria Tecniche di wear leveling: usate per utilizzare in modo uniforme intere sezioni ed ottimizzare la durata globale della memoria Gestione dei blocchi danneggiati (BBM): verifica delle operazioni di scrittura e rilocazioni di settori in caso di operazioni di scrittura fallite A.A

12 Dalvik e ART (1) Processi multipli indipendenti Ciascun applicazione deve essere recintata per garantire la sicurezza, le prestazioni e l affidabilità isolamento dei processi Spazio di indirizzamento separato per ciascuna applicazione Dalvik VM è ottimizzata per garantire i seguenti vantaggi: Ciascuna applicazione viene eseguita con un processo indipendente Ciascuna applicazione gira in un istanza diversa della VM. Dalvik è progettata per consentire l esecuzione efficiente di istanze multiple su dispositivo E basata su registri (register-based) Dipende dal kernel Linux per le funzionalità sottostanti come la gestione dei thread e della memoria a basso livello deprecata, sostituita da ART: La compilazione JIT è poco performante in termini di cicli di CPU e memoria Necessità di ottimizzare il Garbage Collector Dalvik VM ha un architettura a 32-bit necessità di supportare le moderne architetture a 64-bit (come ios ) A.A

13 Dalvik e ART (2) ART e Dalvik sono compatibili con il.dex bytecode quindi le applicazioni sviluppate per Dalvik dovrebbero ugualmente funzionare se eseguite con ART All avvio di una applicazione da parte dell utente Trigger ad ART per caricare il file.dex dell applicazione. Se il file.oat (il binario AOT associato al.dex) è disponibile, ART lo usa direttamente Se nessun file.oat è disponibile, ART avvia l interpretazione (affiancata eventualmente dalla compilazione JIT) ART predilige sempre i file.oat se disponibili In caso contrario, estrae il.dex dall APK overhead di memoria A.A

14 Formato DEX La parte più grande di un file.class è quella delle costanti Dalvik/ART utilizza il meccanismo di Shared Constant Pool per evitare la replicazione delle stringhe nelle costanti, nel nome delle variabili, delle classi e dei metodi Il team di sviluppo di Android ha verificato che il formato.dex dimezza la dimensione di diverse librerie di sistema e applicazioni incluse nel sistema operativo A.A

15 Stack-based vs Register-based (1) Tradizionalmente le implementazioni di JVM utilizzano l architettura stack-based tutte le operazioni agiscono sugli operandi che stanno sulla cima dello stack Maggiore semplicità nell implementazione della VM La densità del codice è inferiore l eseguibile stack-based è più piccolo del corrispondente eseguibile register-based La Dalvik/ART VM è invece stata progettata register-based le operazioni agiscono su alcuni registri virtuali L architettura stack-based presenta prestazioni inferiori L architettura register-based richiede in media il 47% in meno di istruzioni rispetto a quella stack-based La lunghezza delle istruzioni è maggiore del 25%, il tempo di fetching aumenta dell 1% per istruzione Globalmente l architettura register-based è del 33% più veloce L uso del formato.dex elimina il problema della maggiore densità del codice A.A

16 Stack-based vs Register-based (2) STACK BASED Gli operandi sono memorizzati in una struttura a stack (Last in First Out LIFO). Ciascuna operazione si traduce in: POP degli operandi dallo stack Processing PUSH del risultato L utilizzo dello stack pointer SP permette di referenziare implicitamente gli operandi =? Lines 1 POP 20 2 POP 7 Stack VM Based Pseudo Code 3 ADD 20, 7, result 4 PUSH result REGISTER BASED Gli operandi sono memorizzati nei registri della CPU. Non vi sono operazioni di PUSH e POP e ciascuna operazione indica esplicitamente lo specifico indirizzo (registro) di un operando =? Lines Register VM Based Pseudo Code 1 ADD R1, R2, R3 A.A

17 Boot di sistema: Init In modo simile ai sistemi Linux, il bootloader carica il kernel ed esegue il processo Init (l antenato di tutti i processi del sistema) Il processo Init avvia I processi demoni Linux, tra i quali: USB Daemon (usbd) per la gestione delle connessioni USB Android Debug Bridge (adbd) per la gestione delle connessioni ADB Il Debugger Daemon per gestire le rischieste di debug dei processi (dump della memoria ecc.) Radio Interface Layer Daemon (rild) per gestire la comunicazione radio (GPRS, UMTS) Il servizio di estrema importanza Zygote A.A

18 Boot di sistema: Zygote Poiché ciascuna applicazione gira nella sua istanza della VM, il tempo di avvio deve essere rapido e lo spazio occupato dalla VM deve essere minimo Android utilizza il processo Zygote Inizializza un istanza della VM Dalvik/ART Carica e inizializza le classi della Core Library Rimane in attesa di richieste su socket per lo spawn di nuove istanze partendo dall istanza iniziale, mediante fork del processo Meccanismo di copy-on-write: ogni nuovo processo generato tramite fork() condivide le medesime risorse del processo padre. Solo a seguito di modifiche queste vengono copiate nell area di memoria del processo figlio in cui gira l istanza della VM per l applicazione. A.A

19 Boot di sistema: Runtime Il processo Runtime inizializza il Service Manager, elemento chiave per l uso dei Binder e per la comunicazione IPC. Runtime richiede a Zygote di avviare una nuova istanza della VM per eseguire il System Server, il primo componente Java eseguito dal sistema. System Server inizializza i server nativi di sistema (Native System Servers) Surface Flingers Audio Flingers System Server avvia i service di sistema (Android Managed Services) Content Manager Window Manager Telephony Service Activity Manager Native Servers e Android Services si registrano con il Service Manager come service target IPC A.A

20 Interazione dei layer Esistono 3 diverse modalità di interazione fra i layer affinchè una applicazione possa interagire con le librerie native: Direct Applicazione -> Runtime Service -> libreria Attraverso un native Service Applicazione -> Runtime Service -> Native Service -> libreria Attraverso un daemon service Applicazione -> Runtime Service -> Native Daemon -> libreria A.A

21 Interazione dei layer Direct A.A

22 Interazione dei layer Native Service A.A

23 Interazione dei layer Daemon Service A.A

24 Open GL ES Android include il supporto per la grafica 2D/3D mediante la libreria OpenGL, specificatamente OpenGL ES API. OpenGL è una libreria open source multipiattaforma che specifica un interfaccia standard per l hardware grafico 3D. OpenGL ES è una variante specifica per sistemi embedded. OpenGL ES 1.0 e 1.1 >= Android 1.0 OpenGL ES 2.0 >= Android 2.2 OpenGL ES 3.0 >= Android 4.3 OpenGL ES 3.1 >= Android 5.0 Android supporta OpenGL sia nelle API del Framework sia nativamente A.A