36194
-
#18744
Meg is vettem, mint minden filléres szart. :D Ha lát valaki profi időjárás jelzőt ami akciós. Tell me. -
TLOTR #18743 koszi kituno valaszt adtal -
#18742
Super Hexagon learazva -
#18741
Mert a mai telefonokat rendkívül nehéz rákötni egy TV-re :) -
#18740
Kérdés továbbá, hogy szükséges-e, ha a kijelző felbontása kisebb, ugye... -
#18739
Lathato akadasok sztem nelkul biztosan nem viszi egy mai teloban levo 2 magos proci az 1080p-t. Az egy 2 GHz-es core 2 duo-t is meg tudna izzasztani. Esetleg az abszolut csucs telokbam levo 2 ghz kornyeki a15 procik, de abban is ketelkednek. Szoval az ilyen videok lejatszasa minden esetben a gpu-n szokott tortenni, es igy tudnak tenylegesen tokeletesen akadas nelkul lejatszodni.
Egy mai 2 magos telo melle szoktak olyan gpu-t h ezzel ne legyen gond, ha erre iranyul a kerdes, de nem biztos h minden esetben. Amelyik telok pl 1080p-ben vesznek fel videot (GS2, Galaxy Nexus es kesobbi modellek), azok vissza is tudjak azt jatszani :) -
TLOTR #18738 de azert meg varom az ehhez kapcsolatos infokat, elvileg akkor egy 2magos 1Ghz-es telo siman viszi a full hd-t igaz?es amugy a teloba beepitett gpu-k reszt vesznek a feldolgozasban?(lehet hule kerdes) -
TLOTR #18737 koszi -
#18736
Ha jól tudom elvileg egy Motorola Defy is le tudja azt játszani, mert a legtöbb mobil/normális processzorba direkt van bele építve népszerű kodekekhez dekóder. -
TLOTR #18735 sziasztok, azt szeretnem megkerdezni, mekkora proci kell egy teloba h gond nelkul lejatszon egy full hd (1920x1080p)-s filmet? -
#18734
Felig off, de ez valami oriasi:
-
Dodo55 #18733 Sikerült mégis, még talán GB-re való VoiceSearch.apk, és amúgy igen diktálni lehet neki :)
Sajnos magyarul általában kurva nagy hülyeségeket hoz ki :D -
Dodo55 #18732 Nem lenne rossz, de valamiért Voice Search kell neki a hangjegyzetekhez (lehet nem is hangjegyzet funkció az, hanem beszédfelismerés? :D).
Sajnos a 4.2.2-es custom ROM-omon az nincs, GApps-ből nem tudtam ráerőszakolni (elég fura FC-t produkál, nem Java stacktrace-t nyom a logcatbe, hanem memory dumpot). Azért még a ROM installerbe belenézek hátha volt mégis benne, csak én pucoltam ki valamiért a systemből :) -
#18731
Egyszeru, puritan, letisztult ahogy Guglitol megszokhattuk :) Jo cucc. Widgetje is van termeszetesen. -
#18730
nem nagyon használtam jegyzet appokat, de pár napja mikor ezt megláttam már töltöttem is le :D Google minőség, ez mindent elárul :) -
![[HUN]FaTaL](https://media.sg.hu/forum/avatars/10557508481320070594.gif "[HUN]FaTaL")
#18729
Igen erre is gondoltam, 100-200 órát elmegy (kivéve amikor csinál vmit a cpu, akkor akad az egész, de butter nélkül gondolom ilyen).
Meg az is gond, hogy ezeréves szar kernelre tákolták (állítólag Froyo kernel) rá az ICS-t, mert GB alatt nem volt ennyi lassulás. -
#18728
Ú köszi szépen!
Eddig a szintén Google féle jegyzetek alkalmazást használtam.
Azzal sincs bajom, de az kicsit fapadosnak tűnik ehhez képest. Mindenképp kipróbálom. -
#18727
Nem nagyon kene ilyen lassulasnak tortennie, de tippre hosszabb tavon pl az is okozhat ilyen, hogy a nativ kodoknal elszivarog a memoria, igy az OS-nek kevesebbel kell gazdalkodnia, kevesebb progit tud bent tartani a memoriaban, tobb mindent ujra kell tolteni, stb. Egy par 100 orat azert illene elmennie ujrainditas nelkul, erezheto lassulas nelkul.
Mas jegyzet progi a Google-tol:
Keep -
#18726
Én vótam.
há-há :P -
ldavid #18725 azzal én is szórakoztam pár hétig :) de aztán meguntam -
hugopareiros #18724 Nem tudom már, hogy ki de aki a Hill Climb Racing játékot ajánlotta itt valaki másnak az elmehet a sunyiba :D
már 30 órát beleöltem kb a játékba, most csináltam meg fullosra az 5. járművet -.- :D
-
#18723
Konkrétan pl buszon fordult elő meg gyár melletti dohányzóban. :)
Szóval mondhatjuk igen, mind a két esetben fémes burkolattal voltam körülvéve.
Viszont amikor gyáron belül próbáltam eddig néhányszor, ott mindig működött, pedig ott is van fém jócskán.
Böngészés minden esetben gyors, csak youtube kínlódik néha. -
#18722
volt rá példa, főleg árnyékolt helyeken (pl cégben, ahol sok a fémburkolat a falakon) -
#18721
Olyanom van, hogy 3G-H erősségű T-mobilos mobilnettel néha youtube videók lejátszásánál csak annyi történik, hogy forog a karika pár másodpercig, majd kiírja, hogy "Gond volt a hálózattal".
Természetesen nem életbevágó probléma, csak érdekelne, hogy olykor esetleg más is szokott-e még ilyet tapasztalni? -
#18720
"Egyaltalan nem hibas feltetelezes, nagyon sok esetben gyorsit, es effektive semmibe nem kerul"
Akkor friss bekapcsolás után miért indulnak gyorsabban a programok, mint akkor, amikor a rendszer már egy csomó szart a memóriában tart? :) Most egy egy magos, régi telefonról beszélek, az új szörnyeken lehet, hogy nem kerül semmibe.
"A GC tipikusan 5 ms-en belul lefut, raadasul gingerbread ota konkurrensen fut, igy ha nincs valami brutalis szemetmennyiseg, gyakorlatilag kizart hogy eszrevedd hogy egyaltalan fut."
Nem kizárt, hogy a telefonom ROM-ja egy kalap szar, főleg a régi kernel miatt.
"Siman lehet egyebkent hogy a Process-ed ures, csak epp meg nem lett felszabaditva, ezek nem azonnal mennek."
Ez lehet. :)
Lifecyclet ismerem, a killprocesst nem tudtam, hogy nem azonnal szabadít.
-
#18719
Egyaltalan nem hibas feltetelezes, nagyon sok esetben gyorsit, es effektive semmibe nem kerul. Naplozas pl tuti nem lenne ingyen, a szokasaid alapjan be kene toltenie elore programokat, a betoltes enne az aksit (sokszor feleslegesen), meg sokkal komplexebb es ezer masik problemat felvet, ha rosszul tudja a szokasaid, rosszabb mintha nem is lenne.
A GC tipikusan 5 ms-en belul lefut, raadasul gingerbread ota konkurrensen fut, igy ha nincs valami brutalis szemetmennyiseg, gyakorlatilag kizart hogy eszrevedd hogy egyaltalan fut.
Siman lehet egyebkent hogy a Process-ed ures, csak epp meg nem lett felszabaditva, ezek nem azonnal mennek.
Lasd itt meg itt -
#18718
Hat de most is tarhelyre kell irogatni, mert bármikor kiloheti. Egyébként meg root nélkül nem baszogat senki semmit, amit nem akarsz. -
#18717
Így látatlanban ha valami kiírsz tárhelyre, azt onnantól bármi baszogathatja, míg a Dalvik VM-ben szépen elfutogat magában, ő se borít meg senki mást, meg őt se :) -
#18716
Egyébként én az állandó fájlba írkálást (az activity állapotát) tartom baromságnak, sokkal jobb lenne, ha valami fájlba hibernálná az egészet, amikor kilövi, aztán azt töltené vissza. Bár gondolom oka van, hogy nem így lett az API megcsinálva. -
#18715
"Nem tudom, legtöbb alkalmazást elnézve ekkor ugyanaz az xml kerül betöltésre"
Ilyen alkalmazást én még egyet sem láttam. Konkrétan melyik barom fejlesztő tölti be az álló nézetet fekvőnek is? Ha mégis ezt csinálja, akkor meg miért nem tiltotta le a manifestben?
Az, hogy ugyanúgy néz ki az nem jelenti, hogy nem kell újratölteni, pl. ha szélesebb egy edittext akkor ugye az másik xml (vagy legalábbis a forgatástól a mérete megváltozik).
A többit passzolom, nem nagyon használtam még ezt a részét az SDK-nak. XML-t nézegetni tudsz szerintem, de akkor neked kell lekezelni mindent az onConfigurationChange metódusban.
"-programozónak explicite kelljen jeleznie, hogy újrapéldányosítást kér (feltételezve, hogy valóban helytálló a megfigyelésem)"
Szerintem ez nem megoldható. -
Dodo55 #18714 "Nem tudom, legtöbb alkalmazást elnézve ekkor ugyanaz az xml kerül betöltésre, és nekem sem kellett eddig még újat létrehoznom emiatt"
Nagyon durván flexibilis az Android layout kezelése, eddig max talán a WPF féle xaml layoutoknál láttam ekkora flexibilitást, mióta ismerem ezeket sokszor egyenesen gagyinak érzem a HTML5/CSS3 adta lehetőségeket, persze JS-el megoldható sok minden de azért akkor is. -
Dodo55 #18713 "Bár gondolom a butterrel reszeltek rajta, nekem még ICS van."
Nekem mióta 4.2.2 van a "szegény" (a Samsung szerint már az ICS futtatására is teljesen alkalmatlan...) Gio-mon, azóta nagyon ritkán tapasztalok GC okokra visszavezethető lassulásokat, max kb hetente 1x amikor van úgy 8-10 alkalmazás az alkalmazásválasztó listában (ezek szerint így mondják szépen a taskváltót :)) és valami kövérebb dolgot indítanék hirtelen.
Ha megpróbálok visszaemlékezni annak idején GB romokkal ezerszer szarabb volt a helyzet. ICS-t azt nem sokáig használtam, de azzal sem volt ennyire még fényes a helyzet. -
#18712
"Képernyő elforgatáskor muszáj újratöltenie az activityt, mi mást csináljon?"
Nem tudom, legtöbb alkalmazást elnézve ekkor ugyanaz az xml kerül betöltésre, és nekem sem kellett eddig még újat létrehoznom emiatt - neked mik az ilyen irányú tapasztalataid? Megoldható lenne pl, hogy:
-programozónak explicite kelljen jeleznie, hogy újrapéldányosítást kér (feltételezve, hogy valóban helytálló a megfigyelésem)
-forgatásnál megnézi, van-e másik, jobban megfelelő XML, és csak akkor történjen meg az újraindítás (szerintem tökéletes lenne)
Manifestes workaroundot ismerem, használom is, csak arra lettem volna kíváncsi, hogy miért így oldották meg pl a forgatás kezelést, ahogy (biztos vagyok benne, hogy kimerítően elemezték az esetleges alternatívákat).
Én az összes hosszú ideig tartó műveletet service-ben futtatnám, ha jól rémlik, Android kilövési sorban az hátrébb is van, mint az onDestroy-olt Activity. -
#18711
Képernyő elforgatáskor muszáj újratöltenie az activityt, mi mást csináljon? Nem tudja kitalálni, hogy fektetve hogy néz ki, újratölt egy másik xml-t. Ha meg mégsem akarod, hogy újratöltsön akkor kilövöd a manifestben, beállítod, hogy orientationchangenél ne töltse újra és kész. :)
Akkor maradjon a sima másolás. -
#18710
Nézd, nálam nem a memóriafoglalás okozza a problémákat (bár ott sem értem, hogy miért kell egy már bezárt Activity példányhoz tartozó objektumokat (nem a .class-eket!) tárolni, hisz úgyis újak fognak létrejönni következő onCreate során), hanem hogy egy destroy-olt Activity-hez tartozó szálak miért kerülnek még ütemezésre, hiszen Activity újraindításakor egy új példány fog létrejönni, és onDestroy előtt már megtörténik a bundle elmentése, ergo háttérszál nem sok hasznos dolgot csinálhat - SDK ajánlásai szerint. Engem ez az egész kicsit a cooperative multitaskra emlékeztet jellegében. Ott is ugye, amíg minden alkalmazás megfelelően működött, nem volt gond. Csak ha előfordult egy gányul megírt, vagy hibás alkalmazás... Itt persze messze nem olyan súlyosak a következmények, "csak" az erőforrások pazarlódnak.
API dokumentáció általában valóban jó, de az csak azt írja, hogy mivel mit lehet elérni, de azt nem, hogy mi a mögötte meghúzódó koncepció. Lásd még képernyő elforgatáskori onDestroy-onCreate páros. Értem én, hogy ekkor esetleg már más layout lehet a megfelelő, de szerintem messze nem ez a jellemző, és elég nagy lehet az ebből adódó overhead (még szerencse, hogy erre is van workaround).
[HUN]FaTaL (#18707):
Szerintem speciel pont a fájlletöltés a legjobb példa a service használatára:) -
#18709
"-ami appot nemreg hasznaltal, nagyobb esellyel fogod ujra elinditani a kozeljovobe"
Ez egy eleve hibás feltételezés. Inkább naplózná miket használok gyakran.
"-amint memoriara van szukseg, a rendszer felszabaditja a bezart programok altal lefoglalt memoriat a legregebbivel kezdve, igy effektive semmi hatranya a dolognak."
Csak épp a GC baromi lassú, ez a probléma. Bár gondolom a butterrel reszeltek rajta, nekem még ICS van. -
#18708
Ha eppen nem fut az Activity, akkor legalabb az onPause-nak meg kellett hivodnia, ahol illik gondoskodni rola, hogy ne nagyon fusson hosszabb ideig terhelo dolog. Hosszabb ideig a hatterben futasra egyebkent is Service-ek hasznalandok.
Annak pedig hogy mi az oka, hogy a memoriaban marad egy app kilepes utan:
-ami appot nemreg hasznaltal, nagyobb esellyel fogod ujra elinditani a kozeljovoben (akkor is ha elotte kifejezetten kileptel belole), igy gyorsitja az ujboli inditast
-amint memoriara van szukseg, a rendszer felszabaditja a bezart programok altal lefoglalt memoriat a legregebbivel kezdve, igy effektive semmi hatranya a dolognak.
Egyebkent (mint kb mindenrol) egy rakas nagyon jol osszeszedett tema van rola a neten, es az API-k is nagyon jol dokumentaltak, pelda kodok is vannak, szoval felesleges talalgatni rola, egyszerubb utananezni :) -
#18707
Hm, ebben van igazság. De én tudok olyan dolgot, amihez háttérszál kell. Pl. tegyük fel másolsz valami nagy fájlt (vagy töltesz le ftpről) és háttérbe rakod az appot. Gondolom én attól még örülsz neki, ha másol. Viszont nem hiszem, hogy ez service-szel jó megoldás lenne, az inkább időzített folyamatokhoz való, nem? -
#18706
"Ezt szerintem máshogy nem is lehetne megoldani, különben a háttérben semmit sem tudnál csinálni."
Háttérben végrehajtott komolyabb műveletekre nem a Service-t kéne használni? Egyáltalán, egy activity két példánya (másodszori onCreate után) hogy kommunikál, onSaveInstance Bundle-ba raksz egy referenciát a worker szálra?
Egyébként ha valaki a vissza gombbal zár be egy Activity-t (amellyel ekvivalens emlékeim szerint az Activity.finish, tehát killProcess hatékonyabb), akkor feltehetően nem kíváncsi az ottani műveletek eredményére, felesleges tovább engedni a szálakat... -
#18705
Akkor ezekszerint kilő mindent. Akkor már csak azt nem tudom, hogy a leállítás gomb miért marad aktív, mintha még futna valami.
"és ugye a szálak (és úgy általában, minden) leállításáról a programozónak kell explicite gondoskodnia"
Ezt szerintem máshogy nem is lehetne megoldani, különben a háttérben semmit sem tudnál csinálni.
" Viszont ezt csúnya megoldásnak tartom, és jobb szeretnék ajánlások szerint dolgozni, csak néha tényleg elgondolkozom, hogy mi is lehet a megfontolás a hasonló dolgok mögött..."
Valóban nem olyan szép, viszont többen is megköszönték már, hogy nem rohasztom a memóriában feleslegesen az appot kilépés után. Persze elméletben elég lenne az activity.finish() is, gondolkodtam már rajta, hogy átírom.