[ROM] Pure White 5.1™ [Lollipop] LMY47I

[CriGio]

Il problema è che il "carosello" del multitasking NON è pensato per chiudere tutte le schede perche è una azione SBAGLIATA in assoluto, quindi quella scheda "solitaria" non ha motivo di esistere perche dovrebbero essere lasciate dove stanno tutte o almeno la maggior parte, quindi non è un bug ma una situazione forzata ARTIFICIOSAMENTE dall'utente che non dovrebbe verificarsi, tant'è che le principali schede aperte PERSISTONO anche al reboot per precisa scelta tecnica.

Secondo me devono introdurre, per comodità di utilizzo, due livelli di "carosello", tipo "piu usati" e "tutti" e, come ultima ipotesi, nascondere del tutto la scheda "tutti" ed impedire all'utente di chiudere le app da li, ma di poterlo fare SOLO coscientemente dall'apposito menu della singola app, visto che dovrebbe essere l'eccezione e non la regola farlo, ad esempio nel caso di una app "maleducata".


Fonte di questo problema accertato? Accertato da chi?
Io invece vedo da ogni dove il riconoscimento dell'ottima gestione della RAM di L, comunque perfettibile come qualsiasi cosa in campo informatico, salvo qualche raro caso specifico, la maggior parte perche non hanno voluto fare il full wipe o usano applicazioni maleducate e non ancora adattate a L, per esempio tantissimi giochi sono "maleducati" usano un sacco di risorse e non le liberano correttamente quando non in uso, per evitare che l'utente si lamenti che il gioco si è chiuso ed ha perso il livello raggiunto perché ha risposto ad una chiamata o messaggio e il gestore è stato costretto a killare l'applicazione per far spazio ad altro.
Chi ha studiato un po di informatica sa che la gestione della memoria è un settore pernicioso e che spesso non si può fare nulla contro una app scritta con i piedi.

Dalle opzioni sviluppatore c'è scritto tutto ..se compare critica (e compare quando cominciano ad esserci questi ricaricamenti, che tu puoi avere o meno ) significa che la gestione della RAM è critica. Non penso che i Dev di google si siano divertiti a fare la distinzione tra situazione normale e situazione critica

[Pietro91]

va bene secondo voi il kernel code blue 703r? con il linear mi sto trovando male

[CriGio]

va bene secondo voi il kernel code blue 703r? con il linear mi sto trovando male

L utilizzo è soggettivo, inutile chiedere va bene col code, sicuramente funziona devi vedere tu se va bene per te (infatti più o meno tutti si trovano bene col Linear, quindi ti chiederebbero perché ti trovi male) è soggetivo

[Pietro91]

L utilizzo è soggettivo, inutile chiedere va bene col code, sicuramente funziona devi vedere tu se va bene per te (infatti più o meno tutti si trovano bene col Linear, quindi ti chiederebbero perché ti trovi male) è soggetivo

sai se va bene la versione 703r per il codeblue?

[CriGio]

sai se va bene la versione 703r per il codeblue?

Si riesci a installarla senza problemi
E non ho sentito particolari lamentele

[lostman]

Dalle opzioni sviluppatore c'è scritto tutto ..se compare critica (e compare quando cominciano ad esserci questi ricaricamenti, che tu puoi avere o meno ) significa che la gestione della RAM è critica. Non penso che i Dev di google si siano divertiti a fare la distinzione tra situazione normale e situazione critica

Parti da un assunto e da un valore sbagliato dato a quel "critica", le cose devono saper esser lette e più ci si immerge nel tecnico più si deve fare attenzione e avere le basi per la corretta "decodifica" di informazioni che si ricevono.

Per farti un esempio comparato, sulle auto c'è la spia della riserva, quando si accende vuol dire che la situazione del carburante è CRITICA (quantità di memoria allocata Critica), da questo non puoi affatto dedurre che il motore consuma troppo (il gestore della memoria non funziona bene), perchè il consumo di memoria è, in primis, causato da COME uso l'auto, se non faccio accelerate inutili, se freno in maniera moderata, da quanto peso trasporto, dallo stile di guida (applicazioni usate).

Quel valore non significa AFFATTO che il gestore della memoria non funziona MA che le applicazioni stanno usando risorse senza rilasciarle correttamente, oppure che ho troppe applicazioni attive o troppo pesanti e che quindi ci si trova in una situazione CRITICA da gestire, dove poi il gestore della memoria si trova nella malaugurata situazione di dover terminare un processo per fare memoria e spesso prende quello che ne sta occupando di più.

Detto questo, cercando fonti che avessero almeno un minimo di attendibilità e di spiegazione tecnica, ho trovato solo due issue, uno su AOSP e una sulla developer preview (quindi vecchia):

https://code.google.com/p/android-de...detail?id=1701

https://code.google.com/p/android/is...etail?id=79729

E' questo che penso sia assurdo, utenti che danno cose per certe, come gli elefanti che volano, senza neanche sapere la fonte ma perchè si basano sul blogghetto di turno e hanno pure l'impertinenza di dare le loro affermazioni come definitive "è cosi PUNTO!", in risposta a chi cerca invece di argomentare, mentre sono solo favole.

Se guardi la seconda collegata, è segnalata come "Priority-Small", continuando con la ricerca si deduce che il bug NON è confermato su L AOSP release, è segnalato "small" in quanto si verifica solo in particolari condizioni è, cosa più importante, è verificato che il GESTORE DELLA MEMORIA NON C'ENTRA NULLA e il problema cioè il "memory leak", è dovuto ANCHE alle Google Apps e al Google Framwork in particolare sono alcune applicazioni multimediali ed i contenuti multimediali "embedded" in Chrome, quelli più colpiti.

Tradotto se fai una ROM AOSP SENZA Google Framework il problema non si presenterà mai, quindi per chiuderla NON E' IL GESTORE DELLA MEMORIA.

Al prossimo aggiornamento delle Google Apps QUESTO memory leak probabilmente sarà sistemato, mentre i memory leak causati da ALTRE applicazioni (Giochi, Social Network) continueranno ad essere sempre colpa dell'applicazione specifica e NON del GESTORE DELLA MEMORIA.

Qui la gente parla senza cognizione, non è un "bug di Lollipop", non è un problema di gestione della memoria, sono memory leak dovuti alle applicazioni.

Questo è un esempio di bug che porta ad un memory leak, NON AL GESTORE DELLA MEMORIA, scovato da un developer attendibile https://code.google.com/p/android/is...etail?id=80929, capita quando si cambia l'aspetto dell'interfaccia utente ed è abbastanza serio infatti è segnalato come "medium", ma resta sempre il fatto che NON E' IL GESTORE DELLA MEMORIA il responsabile neanche di questo memory leak, cioè per dirla con l'esempio di prima NON è colpa del motore che "consuma assai" se carico 20 tonnellate di patate sulla mia fiat 500 e poi questa fa 2 al litro.

Se avete documenti a smentita sono qui per leggerli, ma parlare sul sulla sul "l'ho detto io" oppure "l'ha detto lui" non è affatto produttivo.

[CriGio]

Parti da un assunto e da un valore sbagliato dato a quel "critica", le cose devono saper esser lette e, più ci si immerge nel tecnico più si deve fare attenzione e avere le basi per la corretta "decodifica" di informazioni che si ricevono.

Per farti un esempio comparato, sulle auto c'è la spia della riserva, quando si accende vuol dire che la situazione del carburante è CRITICA (quantità di memoria allocata Critica), da questo non puoi affatto dedurre che il motore consuma troppo (il gestore della memoria non funziona bene), perchè il consumo di memoria è, in primis, causato da COME uso l'auto, se non faccio accelerate inutili, se freno in maniera moderata, dallo stile di guida (applicazioni usate).

Quel valore non significa AFFATTO che il gestore della memoria non funziona MA che le applicazioni stanno usando risorse senza rilasciarle correttamente, oppure che ho troppe applicazioni attive o troppo pesanti.

Detto questo, cercando fonti che avessero almeno un minimo di attendibilità e di spiegazione tecnica, ho trovato solo due issue, uno su AOSP e una sulla developer preview (quindi vecchia):

https://code.google.com/p/android-de...detail?id=1701

https://code.google.com/p/android/is...etail?id=79729

E' questo che penso sia assurdo, utenti che danno cose per certe, come gli elefanti che volano, senza neanche sapere la fonte ma perchè si basano sul blogghetto di turno e hanno pure l'impertinenza di dare le loro affermazioni come definitive mentre sono solo favole.

La guardi la seconda collegata, segnalata come "Priority-Small", continuando con la ricerca si deduce che il bug NON è confermato su L release, è segnalato "small" in quanto si verifica solo in particolari condizioni è, cosa più importante, è verificato che il GESTORE DELLA MEMORIA NON C'ENTRA NULLA e il problema cioè il "memory leak", è dovuto ANCHE alle Google Apps e al Google Framwork in particolare sono alcune applicazioni multimediali ed i contenuti multimediali "embedded" in Chrome, quelli più colpiti.

Tradotto se fai una ROM AOSP SENZA Google Framework il problema non si presenterà mai, quindi per chiuderla NON E' IL GESTORE DELLA MEMORIA.

Al prossimo aggiornamento delle Google Apps QUESTO memory leak probabilmente sarà sistemato, mentre i memory leak causati da ALTRE applicazioni (Giochi, Social Network) continueranno ad essere sempre colpa dell'applicazione e NON del GESTORE DELLA MEMORIA.

Qui la gente parla senza cognizione, non è un bug di lollipop, non è un problema di gestione della memoria, sono memory leak dovuti alle applicazioni.

Questo è un esempio di bug che porta ad un memory leak, NON AL GESTORE DELLA MEMORIA, https://code.google.com/p/android/is...etail?id=80929, capita quando si cambia l'aspetto dell'interfaccia utente ed è abbastanza serio infatti è segnalato come "medium", ma resta sempre il fatto che NON E' IL GESTORE DELLA MEMORIA il responsabile del memory leak, cioè per dirla con l'esempio di prima NON è colpa del motore che consuma assai se carico 20 tonnellate di patate sulla mia fiat 500 e poi questa fa 2 al litro.

Se avete documenti a smentita sono qui per leggerli, ma parlare sul sulla sul "l'ho detto io" oppure "l'ha detto lui" non è affatto produttivo.

Ripeto, i ricaricamenti ci sono, possono non succedere a te, ma ci sono, che tu lo voglia o no; posso citarti anche blog stranieri autorevoli ma appunto su google si trova tutto; dato che non siamo ingegneri non sappiamo le cose nel dettaglio, ma le testimonianze di migliaia di utenti non possono essere scartate solo perche sul proprio dispositivo non si verifica un determinato problema; i ricaricamenti del launcher o anche la chiusura di alcune app in background sono realtà, si risolve solo riavviando, c'è poco da fare
Quindi io eviterei di attaccare un utente perche ha detto quello che realmente gli è accaduto, si è generato un OT immenso in questo thread accettiamo le considerazioni di chi veramente "ha vissuto" il problema

[wmet]

Io uso lollipop dalla prima preview e non ho mai avuto nessun problema di lag o ricaricamenti. Ma di app scritte con i piedi uso solo facebook e poco per giunta. Quindi, dal basso della mia ignoranza, mi sentirei di dare ragione a lostman. Ovviamente, il fatto che io non riscontri il problema, non significa che questo non esista affatto, ma credo che la colpa non sia da attribuire a google.
Detto questo, @lostman trovo molto sensata l'idea del carosello con le sole app più usate (o anche il doppio carosello). Perché non provi a sviluppare qualcosa del genere o, qualora non ti sia possibile, che ne pensi di proporre la cosa a qualche sviluppatore che reputi capace?

EDIT: chiedo scusa per l'ot, ma dopo tutta quella discussione mi ero convinto di essere nella sezione consigli scusa zio mise

[lostman]

Quindi io eviterei di attaccare un utente perche ha detto quello che realmente gli è accaduto, si è generato un OT immenso in questo thread accettiamo le considerazioni di chi veramente "ha vissuto" il problema

Non ho attaccato proprio nessuno, ho fatto notare al primo utente che le app rimangono nel tab del multitasking per scelta precisa e non saturano affatto la memoria per il semplice fatto di essere li, e poi ho risposto con fatti dati e riferimenti a chi favoleggiava di "gestione della memoria buggata di Lollipop" e lo faceva pure con certezza matematica, sbagliando, chiedendo semplicemente le fonti delle sue affermazioni, se poi non si può neanche precisare, con dati alla mano, che si sta parlando di memory leaking di ben precise applicazioni e non di "gestione della memoria di merda" come è capitato sentire allora è inutile discutere di tecnologia e lasciamo che tutti dicano cose false senza essere smentiti, lasciando che altri utenti leggano cose false pensandole vere perchè nessuno le ha smentite con i fatti e con i dati, e senza accettare chi si prende la briga di spiegare cosa sta sbagliando e di cosa si tratta in realtà.

Chiuso OT, che poi tutto questo OT non è visto che la discussione è nata dal precisare a degli utenti che quello da loro indicati non erano un bug della gestione della memoria di Lollipo che, detto per inciso, è nettamente migliore di quella di Kitkat.

Il bug del multitasking é presente in questa ROM? La gestione della RAM é scadente come in lollipop stock oppure ci sono miglioramenti?

Non si possono cancellare tutte le app nel multitasking, rimane sempre una scheda.

È proprio quello il bug, le app chiuse in realtà restano aperte e saturano la RAM...

se gli utenti non accettano spiegazioni sensate e si "avvitano" in testa a testa su argomenti che sconoscono senza nessuna voglia di imparare come stanno davvero le cose, fidandosi di due parole messe li a caso su blogghetti di terza classe, non è colpa mia.

Non rispondo più a riguardo salvo se interpellato direttamente. Chi vuole capire di cosa si tratta davvero ha ormai ampie spiegazioni e materiale per farlo che, in fondo, è l'unica cosa che mi preme, se ci sono testedure che lo restino, pazienza.

[iEzZo]

Grazie a dio c'è gente con la testa sulle spalle e non solo ingegneri da due spicci che trasudano saccenza da ogni poro. Prova a mandare il curriculum a google lostman, secondo me ti prendono
Chiuso OT, mi sono abbassato anche troppo al livello infimo di "certi" utenti.