Android, memoria e task killer: facciamo chiarezza

qui sta al programmatore prendere una decisione
devi aspettarti che la tua app possa essere killata in qualsiasi momento quindi sarebbe bene salvare lo stato per riprendere da dove si era terminato

ad esempio se sei un browser e hai una pagina aperta salvi subito l'URL cosi sei in grado di riaprire l'ultima pagina visitata
purtroppo non tutte le app lo fanno e a volte la cosa diventa seccante
ad esempio molti giornali (parlo di iOS ma penso che il comportamento sia simile su Android) quando chiudi l'app in background non si ricordano l'articolo che stavi leggendo cosi magari rispondi a un sms, torni all'app e riparti da capo

sui telefoni Android che ho avuto e che ho usato si aprono da sole 30-50 apps... senza Task Killer non potrei vivere. I cell di fascia bassa si "fermano" letteralmente (vedi Ideos) e se non usi un Task Killer si blocca tutto. E poi vuoi mettere che su un Liquid Metal fai un app-kill e il sistema torna a ruggire?

Ps: WP o Android?
Semplice: Android con interfaccia WP7 (launcher7),
così si ha una GUI utilizzabile velocemente con un pollice
e un sistema con migliaia di Apps (il market di WP7 fa piangere).

Se non fosse che il Task Killer è assolutamente necessario, sull GS2 mi partono in continuazione applicazioni quali Radio (mai aperta manualmente), Maps, SocialHub e robacce varie.
Tutta roba che difficilmente è fondamentale per il sistema operativo.

Si' quoto. Mappe non lo apro mai e comunque il processo e' li'. Pure Radio, Ricerca, Ricerca Google, Galleria, Compositore vocale, Calendario e pure sto Let's Golf 3 che non l'ho mai aperto ma continua a stare li' e ora lo disinstallo.

Comunque tutta roba che non uso mai e sono sempre aperte...

Per mia esperienza personale, i task killer in automatico sono inutili ma averne uno da avviare manualmente può venire utile.
In ogni caso il problema resta l'apertura automatica di certi processi senza che ce ne sia un reale bisogno, problema che in parte si risolve con root + Gemini App Manager (permette di disabilitare l'autorun per determinati processi/applicazioni, non funziona con tutti ma quasi), e qualora non si risolvesse resta l'ottimo Titanium Backup, via il dente via il problema

Non mi piace Java, però per correttezza bisogna ammettere che a forza di limare dalvik è diventato particolarmente veloce (se non ricordo male il codice nativo è in media 1/3 più veloce del codice java)

Bisognerebbe però guardare la cosa dal punto di vista dell'utente finale medio e non quello del programmatore:
1) Compatibilità: cosa te ne fai di uno smartphone superveloce se non ci puoi installare con un paio di click l'ultimo giochino stupido? (indipendentemente da se hai l'ultima verisione o quella di due anni fa, schermo da 4 o 10 pollici, etc.)
2) Sicurezza: non è carino se l'ultimo giochino stupido installa a tua insaputa qualche trojan e ti ciulla carta di credito, dati di accesso bancari, etc..

E' vero che l'iPhone usa codice nativo, ma è anche vero che i clienti Apple sono gente particolare. Ad esempio mi risulta che le nuove App non funzionano su iPhone 3: cosa direbbe un utente normale di uno smartphone da 6/700 euro con vita media di un paio d'anni? (L'utente Apple sostiene che il problema non esiste, barbone, vai nell'App Store e ti compri l'ultima versione)

Non sottovaluterei il futuro Windows-Nokia.
Ad esempio in Windows 8 sembra che abbiano puntato molto su javascript (come tutti del resto in questo momento; anche i più insoliti sospetti, gnome ad esempio) e magari potrebbe essere anche la scelta vincente per gli smartphone.

titaniumct: Sai di cosa stai parlando? Conosci Android? E le VM di Java 6? HotSpot?

persevero con il mio OT (ma prometto che è l'ultima volta!)

non parlo per partito preso, dato che sono DAVVERO dubbioso su quale smartphone scegliere, ma quello che mi ha impressionato di WP (ho visto un lumia 800) non è tanto l'interfaccia utente (comunque gradita) ma l'impareggiabile sensazione di fluidità e robustezza.
sarà stata la suggestione, ma pure l'iphone 4 (non 4s, però...) mi è parso più "lento" con una maggior tendenza a impuntarsi..,.

(è anche vero che quando si inizia a diventare esigenti non la si finisce più; per dire, io sto andando avanti da 5 anni con un nokia e50, che a volte si impunta anche 10 secondi per aprire i messaggi...)

quanto al market hai ovviamente ragione; ma anche in questo caso si impone una domanda: "quali apps potrei rimpiangere davvero?
Ecco, forse quella per riprodurre i filmati senza convertirli con Zune (non mi sembra esista ancora), quella sì...

Adesso è inutile che certi difendano android a spada tratta, andrebbe riveduto molto nel profondo; un sistema in cui solo per accedere in lettura ad un file di testo carica tutto l'editor evidentemente qualcosa che non và ce l'ha. Lo sò che ci sono migliaia di workaround semplicissimi ma ciò non và bene, il problema è che certe cose di default sono concettualmente sbagliate.
Ho galaxy e il sistema già out-of-the-box ogni tanto si piantava o smetteva di rispondere per qualche secondo anche nelle sue funzioni base come nel riaggancio di una chiamata o nello switch tra 3g/wifi, se ci aggiungiamo tutte le applicazioni installate è evidente che parte dei malfunzionamenti che ho sono dovuti ad esse, solo che giustamente come osservava un altro utente Cazzo trecento e passa euro e il telefono si pianta! chi sono io un betetester? Quindi non non posso che concordareE aggiungo che è anche perchè chiunque può pubblicare applicazioni e c'è un controllo poco rigoroso sulle stesse che la qualità delle applicazioni è bassa (se ci mettessimo a guardare il codice cidi tante app ci sarebbe da mettersi le mani nei capelli). Ci vorrebbe innanzitutto maggior dedizione a fare le cose per bene da parte di chi sviluppa e maggior controllo da chi fornisce il sistema, ad esempio con il rilascio di una sorta di patente che permetta la pubblicazione di applicazioni solo dopo aver frequentato un corso certificato apposito ed aver superato un test finale. Mi rendo conto che una cosa del genere in un mercato così agguerrito non è attuabile perchè rallenterebbe lo sviluppo e la proliferazione di applicazioni e quindi del sistema stesso, ma sarebbe uno dei pochi metodi per garantire prodotti stabili e di qualità, un'operazione che però non paga nell'immediato, e per questo scartata a priori da qualsiasi manager 2.0

@Mitchn82
E tu la capisci la differenza tra codice nativo e codice assistito? Tra bytecode e istruzioni macchina? Tra esecuzione ed interpretazione?
Un cattivo programma in C++ ( il C non lo tiro neanche in ballo che sarebbe come sparare ai pesci in un barile ) può comportarsi come un buon programma Java, ma se il programmatore C++ ha i cosiddetti, Java scompare come una stella viene eclissata dal sole, e questo per un motivo molto semplice: Java non fu progettato per essere veloce, C e C++ ( intrinsecamente ) si. Oltre all'overhead introdotto dal thread del gc, bisogna tener presente che ogni singola istruzione Java-like necessita di almeno una fetch in più rispetto alla corrispondente istruzione ( macchina ) C/C++, il che da solo comporta un rallentamento del 10/20% in base all'architettura, sempre che essa supporti l'esecuzione nativa di codice Java ( vedi l'instruction set Jazelle della ARM ). Quello che nell'articolo non viene detto è che a causa della iper frammentazione dello heap le prestazioni di un sistema basato su gc diminuiscono esponenzialmente con il passare del tempo ( più che con il saturarsi della memoria ), per questo un task manager/killer è in realtà molto efficace, permette infatti di depaginare tutta una porzione di memoria in blocco, a prescindere dal gc. iOS usa uno schifo di linguaggio che è a metà strada tra C++ e Java, ma nonostante la sua mostruosa runtime machine objective-C è comunque un 50% più veloce di Java ( nella peggiore delle ipotesi, anche 200% nella migliore ) immagina cosa succederebbe con un'applicazione C++...
Il linguaggio di programmazione FA la differenza eccome, così come il framework del s.o.
Credi davvero che sarebbe necessario un dual ( se non penta ) core per far girare un sistema Linux su una macchina RISC decentemente, se non fosse per l'overhead del framework?