Nije odgovor na pitanje ali probaj Mantano ebook reader.
Meni najvise odgovara za citanje pdf-a, ima finu navigaciju i dobro je odradjen crop.

Za sve ostalo je djubre najgore. Npr kada iz Chrome-a skidan pdf i kazem da skine mantanom, OBAVEZNO ga spuca...

Na iPadu koristim Dropbox za PDFove, možda je dobar i na Androidu.

Mogu da preporucim PDF view-er iz OfficeSuite 7-ce i Acrobat Reader.

Kod prvog sve deluje bolje jer se strane menjaju sa desna na levo, tako da ima manje scroll-a i manje 'krzanja'. U officesute-u pdf reader nije primarna stvar vec vrlo dobro handle-ovanje office dokumentima, ali se hvale kako su update-vali pdf engine.

Vredi probati:
https://play.google.com/store/...or.office_registered&hl=en



Mislim da je u pitanju cache strategija koja vazi za razlicite uredjaje, mislim da se ne menja dinamicki u zavisnosti od hardvera, vec je u pitanju 'najmanji zajednicki sadrzalac'.

Meni licno na novom nexusu 7 (2013), stvari po ovom pitanju deluju prilicno dobro.

Mislim da to nema veze, Dropbox sigurno koristi WebKit API da prikaže PDF, kao da si PDF otvorio iz Maila ili Safarija. Nativno PDF otvaraju Acrobat Reader i PDFPen Pro sigurno, za druge ne znam.

@Dimković
Ako bih morao da pogađam rekao bih da je to zato što android ima garbage collector, iOS nema (radi samo ARC). To "seckanje" koje pominješ tačno zvuči kao GC u akciji.

Veliki pdf-ovi popune memoriju uređaja i onda GC postaje jako spor. izvor: http://www-cs.canisius.edu/~hertzm/gcmalloc-oopsla-2005.pdf

Upravo sam probao - i mogu reci da je ovo najprihvatljiviji reader sto se performansi tice.

Prilikom skrolovanja definitivno malo umanjuje rezoluciju, ali daleko manje nego drugi readeri koji to rade.

Inace, saznao sam i razlog - raspitao sam se malo kod kolega Android developera.

Naime, za razliku od iOS-a, Android nema sistemski PDF renderer, vec svako pise svoj. Vecina tih implementacija nisu nesto preterano optimizovane za GPU ocigledno.

Cisto da se razumemo, renderovanje kompleksnih strana tako da se ne primeti krzavost i prilikom "dugackog" skrola je umetnost (u programerskom smislu).

IMHO, mislim da je dobra ideja da OS sistemski servisi nude PDF rendering, posto je to daleko od trivijalnog, a OS vendori imaju resursa da to implementiraju kako treba.

@ZaMpA, mislim da nije GC vec pristup renderu. Problem je sto kada imas "klizav" ekran koji se skroluje prstom, potencijalno moras renderovati daleko vise od jedne strane. Ako ti je render takav da renderuje samo jednu stranu, imaces prazan prostor kada "povuces" prst. Ako, sa druge strane, renderujes previse - GPU ti pocne da secka.

Postoje razni pristupi i optimizacije ovog problema - generalno, to spada u "umetnicki" deo sw. inzenjeringa i nije cudo da neki prosecni app developer pojma nema o tome, vec je samo ukljucio neki PDF widget ili lib u svoj kod.

U iOS-u / Mac OS X-u imas sistemski PDF renderer, koji je odlican - zato sto je Apple, iz specificnih razloga, veoma veliki akcenat dao na graficki deo price i PDF podrzavaju kao native format istorijski (npr. Quartz interno od samog pocetka jeste dizajniran da izlaz na PDF bude lak). Tako da, kao iOS app developer, ne moras da lupas glavu oko optimizovanog renderinga PDF dokumenata posto je sam OSV to resio za tebe.

Rešavanje tog problema i nije neka umetnost. Problem je podržati PDF format, koji je vrlo složen, a ostalo i nije neka umetnost.

Dovoljno je da osim strana koje se prikazuju renderuješ jednu napred i jednu nazad i da to pomeraš, s tim da rendering ne radiš uvek od nule, nego da za svaku stranicu zapamtiš niz informacija "ovo slovo u ovoj transformaciji prikazati na ovom mestu u ovom fontu i ovoj boji" i "ovu sliku prikazati na ovom mestu u ovoj veličini" pri čemu ne pamtiš sadržaj slike, nego gde da je nađeš.