Vantaggi dell'utilizzo di Binder per IPC in Android

Question

Qual è il vantaggio dell'utilizzo di Binder per IPC su (Semafori, Coda messaggi, PIPES) nello stack Android?

Answer 1

I raccoglitori vengono utilizzati per abilitare le chiamate di procedura remota. Potresti implementare RPC usando gli strumenti di sincronizzazione che hai citato ma avresti anche bisogno di scrivere molto codice per farlo venire insieme ... con un Raccoglitore (normalmente usato solo in un Servizio Android) hai molto meno codice da scrivere; a malapena più delle tue effettive funzioni a distanza.

Answer 2

I raccoglitori sono utilizzati per comunicare oltre i limiti del processo poiché i diversi processi non condividono un contesto VM comune => nessun accesso diretto agli altri Oggetti (memoria). Entrambe le parti all'interno dello stesso processo (di solito le cose che si trovano all'interno della stessa app) significano (imho) che non si dovrebbero usare i raccoglitori poiché rallentano/complicano le cose inutili.

I raccoglitori di solito non vengono utilizzati direttamente ma tramite le classi "Servizio" o "Messenger". Mentre la comunicazione con un servizio avviene tramite un intero pacchetto di funzioni, la comunicazione con un Messenger deve utilizzare "Messaggi". Messaggeri molto più semplici da implementare.

Oltre ad utilizzare Leganti è possibile utilizzare tutto ciò che è disponibile da qualsiasi istanza VM come s "LocalSocket", file, ContentProviders, Intenti, ...

Leganti non sono l'ideale per il trasferimento di flussi di dati di grandi dimensioni (come l'audio/video) dal momento che ogni oggetto deve essere convertito in (e ritorno da) un pacco. Tutta la conversione richiede tempo. Molto meglio in questo caso sarebbe un LocalSocket per esempio.

Answer 3

Da docs/system/libc/SYSV-IPC.html il file della NDK:

Android non supporta System V IPC, vale a dire i servizi forniti dalle seguenti intestazioni standard POSIX:

<sys/sem.h> /* SysV semaphores */ 
<sys/shm.h> /* SysV shared memory segments */ 
<sys/msg.h> /* SysV message queues */ 
<sys/ipc.h> /* General IPC definitions */ 

La ragione di questo è dovuto al fatto che , in base alla progettazione, portano a una perdita di risorse del kernel globale.

Ad esempio, non v'è alcun modo per rilasciare automaticamente un semaforo SysV allocato nel kernel quando:

• un buggy o processo maligno uscite
• un non-buggy e non dannosi interruzione del processo o è ucciso esplicitamente.

L'abbattimento automatico dei processi per creare spazio per quelli nuovi è una parte importante dell'implementazione del ciclo di vita delle applicazioni di Android. Questo significa che , anche assumendo solo codice non buggato e non dannoso, è molto probabile che nel tempo le tabelle globali del kernel utilizzate per implementare IPC SysV riempiranno .

A questo punto, è probabile che si verifichino strani errori e impediscano ai programmi che li utilizzano di funzionare correttamente fino al successivo riavvio del sistema.

Answer 4

vecchia questione (e probabilmente non monitorato dal poster), ma vale la pena di rispondere:

A) Tutti i meccanismi IPC filesystem-based o filesystem-rappresentabile (in particolare tubi), non può essere utilizzato a causa di una mancanza di una directory scrivibile in tutto il mondo, in cui tutti i processi possono mkfifo/creare la rappresentazione del filesystem/socket della loro porta IPC (nonostante sia/dev/socket, che viene utilizzato per i processi di sistema, ad esempio rile, zygote e il loro ilk).

B) Nessuno dei meccanismi suggeriti ha la capacità di "posizione servizio" richiesta per Android. In UNIX, c'è un portmapper RPC e Android ha bisogno di funzionalità simili. Immettere: il ServiceManager, che può utilizzare il raccoglitore per registrarsi come gestore di contesto, per registrare/cercare maniglie di servizio al volo

C) C'è una necessità estesa per la serializzazione - sia essa intenti, o altri messaggi. Binder fornisce l'astrazione del pacco, che può essere utilizzata per il marshaling dei dati da parte di Parcel.java.

D) SysV ha altre questioni oltre alla risposta del Sig. Lambada che sono più importanti, in particolare le condizioni di gara e la mancanza di autorizzazione.

E) Le code di messaggi e le pipe non possono passare i descrittori. I socket di dominio UNIX possono, ma non possono essere usati a causa di (A) (di nuovo, a meno che tu non sia root/system, come zygote, rild, installd ..)

F) Binder è davvero leggero e ha costruito -in meccanismi di autorizzazione. Ha anche funzioni eleganti come svegliare il processo del destinatario, così come la condivisione della memoria, che gli altri meccanismi semplicemente non hanno. (e ricorda, no mmap (2), a causa del problema del file in (A) per i mapping con nome).

e - non dimentichiamo

G) Binder è stato avviato a Palm (ah, nostalgia) (q.v. OpenBinder). Gli ex-palmer arrivarono su Android e portarono il loro codice con loro.