• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    LWEEKAndroid development
    GORG
    GORG --- ---
    A taky se mi nezdá, že by to přímo leakovalo. GC tu paměť vždy všechnu úspěšně uvolní. Akorát nechápu, kde se co alokuje zbytečně navíc.

    Jinak trochu jsem narazil v tomhle směru na rozpor doporučení (Iterator vs ruční procházení pole [])

    Coding for performance and avoiding garbage collection in Android | devahead BLOG
    http://www.devahead.com/blog/2011/12/coding-for-performance-and-avoiding-garbage-collection-in-android/

    Iterator 481 ms 100 slower than both manual iterations and 100 objects allocated (an Iterator instance for each test repetition)

    vs

    Performance Tips | Android Developers
    http://developer.android.com/training/articles/perf-tips.html

    public void two() {
    int sum = 0;
    for (Foo a : mArray) {
    sum += a.mSplat;
    }
    }
    two() is fastest for devices without a JIT, and indistinguishable from one() for devices with a JIT. It uses the enhanced for loop syntax introduced in version 1.5 of the Java programming language.
    GORG
    GORG --- ---
    ZACK: No ale když vymažuju úplně všechen svůj kód.. nechám prázdný update(), po spuštění nespustím ani žádnou inicializaci čehokoliv (prostě jen černou obrazovku s prázdnou smyčkou), tak to leakuje úplně stejně :) Tak leda, že by to leakovalo někde v té knihovně libgdx, kterou používám jako framework?
    ZACK
    ZACK --- ---
    GORG: Nekde ti to proste tece... hledej smudlo. To co popisujes rozhodne neni normalni :)
    GORG
    GORG --- ---
    Zajímalo by mě, co si myslíte o volání system.gc() ručně? Řeším situaci, kdy občas/opakovaně aplikace vytuhne na pár sekund. Napadlo mě, že je to kvůli Garbage collectoru. Soudě dle analýzy VisualVM se nsutále pozvolna plní heap (asi tak o 100KB) až nakonec, když už má třeba 35 MB nebo míň, jde vynášet odpadky. A uvolní tím asi 30 MB, takže hodně. zdá se, že to typicky pak spadne na nějakých 3 MB

    To je ohromný množství a vysvětlovalo by to, proč na chvíli úplně vytuhne? Zkusil jsem udělat, aby se GC volal řekněmě každých 5 sekund, a tak se heap drží stále někde kolem 3 - 4 MB.

    Zdá se, že to pomohlo, anebo jsem zatím nepozoroval už znovu to zatuhnutí. Napadá mě k tomu:

    1) Proč se neustále alokuje nějaká paměť, jde tomu zabránit nebo je to normální?
    2) Podezíral jsem, že jsou tam nějaké alokace při každém tiku, ale žádné nenacházím, tak nevím,
    3) Po "celém internetu" se píše, že by se ručně GC _nikdy_ volat nemělo. Takže mi to moje řešení mate hlavu, protože to zní jako antipattern. Ale z mojí logiky mi přijde, že lepší uvolnit menší množství, než když pak nakonec vysypává celý heap. Ze stackoverflow.com apod jsem se dočetl, že ten růst heapu je normální
    4) GC prý zablokuje všechny thready a objekty, takže to není dobré třeba na webovou službu, ale na android aplikaci to asi není relevantní.
    FALCO
    FALCO --- ---
    SIRLOON: Zbytek je pravda jenom k IDE dodam ze neni jen Eclipse ;)
    ROTTWEILER
    ROTTWEILER --- ---
    SIRLOON: Tak jasně, já netvrdil, že vývoj pro Android je dobrý, a že ostatní jsou horší. Také se mi vyvíjí lépe pro iOS než pro Android, ale i přesto mám Android rád a líbí se mi, že tam zase mohu dělat věci, které na iOS nejdou a rozhodně pro něj nepřestanu vyvíjet. Spíš s každým problémem se učím novým věcem jak problém obejít.
    SIRLOON
    SIRLOON --- ---
    ROTTWEILER: no, v praci mame projekt, kterej je zamyslenej na android 2.2 a vyse, tj. mobily i tablety. Mame cca 8 devicu. Na kazdym z nich je rozbity neco jinyho. Kdyz se device pripoji na debug monitor tak se zacne taky chovat jinak, takze neni mozne nasimulovat nezadouci chovani, ktere jinak nastava. Testovani inapp purchase je uplne nonsense protoze musime pokazdy restartovat zarizeni do tovarniho nastaveni a zadnej vylozene sandbox jako u iOS a WP8 proste neni. Tohle jsou proste zbytecny klacky pod nohama. O eclipsu a jeho naladovosti nemluve
    ROTTWEILER
    ROTTWEILER --- ---
    SPIRAL_FORCE: Když už jsme u těch ORM, tak v dnešním Android Weekly byl http://siminov.github.io/android-orm Celkem zaujal.
    PISKVOR
    PISKVOR --- ---
    ROTTWEILER: Psal to Hulán.
    SPIRAL_FORCE
    SPIRAL_FORCE --- ---
    Cus, hodil sem na github takovou malou knihovnu pro praci s DB (ORM) v androidu. Myslim, ze dokaze usetrit spoustu zbytecne prace pri mapovani db tabulek na objekty. Najit ji muzete tady: https://github.com/biokys/simple-droid-dao . Budu vdecny za pripominky. BTW ten tutorial urcite obsahuje spoustu gramatickych chyb ;-). To casem opravim
    ROTTWEILER
    ROTTWEILER --- ---
    SIRLOON: Můžeš to podložit nějakými podklady? Nebo to pouze vychází z toho, že ty a tvůj kamarád jste se na to vykašlali?
    REDGUY
    REDGUY --- ---
    ARCAO: No, nevim. Kdyz je to standardni, defaultni Androidi font, tak bych skoro ten Android trochu blejmoval 8)
    ARCAO
    ARCAO --- ---
    REDGUY: To ale není problém Unicode, ani Androidu. IMHO použitý font nejspíš nebude podporovat COMBINING CARON.
    SIRLOON
    SIRLOON --- ---
    WAKI: to ne, spis na nej prestali vyvijet. android jako myslenka neni spatna, jen to zpracovani SDK a toolu pro ladeni neni optimalni. Jinak ovce si budou brzo kupovat i WP a BB :)
    PISKVOR
    PISKVOR --- ---
    WAKI: Nekrmit!
    WAKI
    WAKI --- ---
    SIRLOON: A koupili si ovčí iphone
    SIRLOON
    SIRLOON --- ---
    REDGUY: mno, chytri lide se uz na android vysrali a uz se tu jen bavi temi, co k tomu rozhodnuti teprve miri ;)
    REDGUY
    REDGUY --- ---
    ARCAO: Nevim jestli ti spravne rozumim, ale neprijde mi ze to s tim souvisi. Hlavicka xml uplne spravne rikala "utf-8". Zadna http hlavicka tam nebyla, ten vstupni xml soubor byl na disku, odkud se pri buildu (ne pri behu) cetl, zpracoval a zapsal do jsonu, kterej skoncil v raw resourcich. JSON escapovat muzes (ale nemusis, http://tools.ietf.org/html/rfc4627 ) a i kdybych ho escapoval, tak mi to nepomuze.

    Problem je tohle:

    perl -MUnicode::Normalize -e 'use utf8; my $x="š"; binmode(STDOUT, ":utf8"); print $x, " ", NFC($x), " ", NFD($x), "\n";' | xxd -g1
    0000000: c5 a1 20 c5 a1 20 73 cc 8c 0a


    Kdyz to spustis bez toho xxd, tak to vypise "š š š". Jenomze kdyz kouknes na ten dump, tak je videt, ze pismeno "š" muzes v utf8 vyjadrit bud jako 0xc5 0xa1 (coz je jeden znak, "LATIN SMALL LETTER S WITH CARON"), ale i jako 0x73 0xcc 0x8a (coz jsou dva znaky "LATIN SMALL LETTER S" a "COMBINING CARON").

    No a android proste to druhy neumi vykreslit, i kdyz je to normalni, platny unicode.
    ARCAO
    ARCAO --- ---
    REDGUY: Já v tom nevidím problém. Xml hlavička definuje kódování (vícebajtové kódování se zjistí jednoduchým přečtením prvních pár znaků, také se případně využívá Content-type z HTTP hlavičky) a u JSON se všechny speciální znaky nad 0x7F escapují přes Unicode zápis \uXXXX.
    REDGUY
    REDGUY --- ---
    FUCK FUCK FUCK FUCK FUCKING FUCK.

    Zkurveny Unicode mi sezralo tri hodin zivota.

    Zasranej debilni kram.

    Aaaanway, aspon se pochlubim.

    Androidi verze aplikace, kterou prave pisu, pouziva data z iOSovy verze. Tam jsou vpodstate v XML. Parsovat XML je voser (a XPath je pomalej jak ... hmm, neco hrozne pomalyho), takze je nejdriv prekonvertuju do JSON a ten teprv nahravam.

    Jenze to fungovalo jen trochu. Diakritika tam byla, ale tu a tam chybela, nekde byly extra mezery, nekde hacek o fous posunutej, proste to bylo blbe.

    Tri posrany hodiny jsem hledal kde je problem. V konvertovacim programu, v kodovani streamu, v JSON dekoderu, ve fontu co pouziva TextView... nic.

    A pak jsem si nastesti vzpomel, ze utf-8 neni uplne jednoznacny kodovani, ve smyslu ze stejnej logickej text jde zakodovat vice posloupnostma bajtu. Chvile googleni, nalezeni perlovyho modulo Unicode::Normalize, prohnat skrz nej ten json a pak pokus omyl. Na prvni pokus jsem zjistil, ze "Normalization Form D" nefunguje, resp. dava stejny vysledky jako predtim. A na druhej pokus jsem zjistil, ze "Normalization Form C" funguje jako kouzlo.

    Cili proste existuje urcitej dialekt utf-8, kterej iOS zkousne, ale Android je z nej vedle sebe 8(

    Kdybyste nekdy narazili na neco podobneho, tak mantra je "use Unicode::Normalize; print NFC(...whatever...);".

    Zasranej Jan Hus a vsechny jeho pojebany nabodenicka. A to jsem si myslel, ze s utf-8 je problemum s cestinou konec.
    Kliknutím sem můžete změnit nastavení reklam