On 2015-08-09 09:22, J.F. wrote:
>> To bez znaczenia. Liczy się responsywnośc a nie szybkość. Róznica jest -
>> powiedzmy- na poziomie kodu aplikacji i OSa.
> No to wiesz - przewijanie ekranow z ikonkami - ujdzie, w zasadzie w
> sam raz.
> Aplikacje rozne - w normie. Jakis zauwazalnych lagow nie ma.
> Gry zrecznosciowe dzialaja dobrze, wiec da sie dobrze aplikacje
> napisac.

Przeciętna aplikacja na windowsie z gatunku IE potrafi zaciąć się na
odczycie kilku bajtów obrazka na minutę oferując śliczną zwiechę. To
jest brak responsywności i wynika on z faktu ze nikt o tym nie mysli,
liczy się że ten obrazek jak już ściągniesz wyświetli się w nanosekundę
i tu się dostaje pochwały od managmentu. Na tym polegala poczatkowa
przewaga Apple, że dostrzegli potrzebe bycia responsywnym a nie szybkim
na czym bazowała cala płynność pierwszego iPhone. Oszukiwanie okazalo
się bardziej skuteczne i wygodniejsze dla usera.

Niestety aby calośc systemu byla resposnsywna wiele zależy od
pojedynczych programistow aplikacji. A tu jest kłopot - jesli
implementuje się calość logiki w onKlikach to trudno o responsywność.
Świadomośc tego że mozna inaczej jest mizerna. Dlatego wiele aplikacji
na dowolny system jest zrobionych źle pod kątem responsywności. To
wymaga zupełnie innego podejścia na poziomie budowy app.

> Ale aparat startuje 2-3s i potem jeszcze sekunde lapie focus.
> To jest responsywnosc, czy jej brak ?

To jest:
a) dziadostwo programistow którzy w ogole nie rozumieją potrzeby
optymalizacji zlożoności ładowania niektórych istotnych elementow
systemu. Dziadostwo tolerowane, ponieważ managment jest za tępy aby
pojąć że są alternatywy. Naciska się więc na szybsze cpu.

b) ogranicznienie mechaniczne obiektywu z którym nic nie zrobisz od
strony software.

do góry

On 2015-08-09 14:14, the_foe wrote:
> android cierpi na chorobę wieku dzieciecego: niebyt efektywną obsługę
> RAMu. Mówi się, ze urządzenie z andkiem musi miec 2x wiecej RAMu by w
> płynnosci dorównać sprzetowi z iOS.

Nie widzę żadnego związku płynności interfejsu z ilością RAM. Żadnego w
sensie teoretycznym, bo nie wykluczam że w praktycznym się coś znajdzie
w postaci kilogramów idiotycznego kodu w androidzie. To jest wyłacznie
problem budowy OSa i interfejsu użytkownika i da się uzyskać bajeczną
responsywnośc na dowolnie słabym hardware. Istota tkwi głównie w
technikach programowania a nie hardware.

PS. bajki o "nieefektywnej obsłudze RAMu" slyszę od bardzo dawna, ale
jakoś nikt nie wyjasnia na czym polega ten brak efektywności. garbage
collecting nie jest odpowiedzią bo już od wiekow radzimy sobie z tym nie
najgorzej wliczając w to systemy RT.

do góry

On Sun, 09 Aug 2015 20:00:12 +0200, Sebastian
Biały<h...@p...onet.pl> wrote:
> Dziadostwo tolerowane, ponieważ managment jest za tępy aby
> pojąć że są alternatywy.

Jakie alternatywy byś zaproponował?

--
Marek

do góry

On 2015-08-10 00:52, Marek wrote:
>> Dziadostwo tolerowane, ponieważ managment jest za tępy aby pojąć że
>> są alternatywy.
> Jakie alternatywy byś zaproponował?

Wątki. Tylko że nie tyle *ja* co zdrowy rozsądek. Jak się nie da wątków
to kooperatywny multitasking co jest rozwiązaniem prawie zawsze gorszym.
Jak się i tego nie da to zmienić zawód na kopanie rowów.

do góry

On Mon, 10 Aug 2015 15:52:30 +0200, Sebastian
Biały<h...@p...onet.pl> wrote:
> Wątki.

Przecież w javie (nawet Dalvikowej) są wątki, to stanfard. I to
dość mocno używane w każdej aplikacji.
A.może masz jakieś wątpliwości co do ich samej implementacji? Opisz
szczegółowo.

--
Marek

do góry

On 2015-08-10 22:09, Marek wrote:
>> Wątki.
> Przecież w javie (nawet Dalvikowej) są wątki

Nie chodzi o ich obecnośc tylko złe uzycie.

Na PC wszystkie 3 wiodące przeglądarki otwierają pluginy w wątku GUI co
zamraża mi je na kilka sekund jesli dysk jest zajety. Chrome na androida
przy wolnmym laczu (np. lejek 4kB/s) szarpie interfejsem bo coś czeka na
dane w wątku gui, inne przeglądarki mają gorzej. 99% aplikacji obrabia
dane w onkilkach co powoduje nieznośne lagi w GUI. Nikt nie deleguje
akcji od razu w tlo, tylko z lenistwa obrabia sie dane w tych onklikach.
Wliczając w to "wiodące aplikacje na androida" jak choćby liczenie
zajętości aplikacji w pamieci.

Oni wszyscy uzywają gui i watków ale byle jak.

Nawet OSy są spieprzone, że przypomnę że głupi windows czeka kilka
sekund na odpowiedź czy w napędzie jest płyta jesli własnie jest
detektowana, a starsze windowsy zamarzaly się na czas odczytu dyskietki.

Pisanie responsywnych aplikacji nie polega na uzyciu tu i tam watku, ale
na zmienie sposobu patrzenia na GUI. Prywatnie, gdybym był złośliwym
OSem, ubijałbym aplikacje które czakają dłużej niż 50ms ze zwrotem
sterowania do pętli komunikatów. Ale OSy sa milutkie i *ewentualnie*
ubijają gdy nie zwrócisz po paru sekundach.

do góry

Sebastian Biały <h...@p...onet.pl> wrote:
> On 2015-08-10 22:09, Marek wrote:
>>> Wątki.
>> Przecież w javie (nawet Dalvikowej) są wątki
>
> Nie chodzi o ich obecnośc tylko złe uzycie.
>
> Na PC wszystkie 3 wiodące przeglądarki otwierają pluginy w wątku GUI co
> zamraża mi je na kilka sekund jesli dysk jest zajety. Chrome na androida
> przy wolnmym laczu (np. lejek 4kB/s) szarpie interfejsem bo coś czeka na
> dane w wątku gui, inne przeglądarki mają gorzej. 99% aplikacji obrabia
> dane w onkilkach co powoduje nieznośne lagi w GUI. Nikt nie deleguje
> akcji od razu w tlo, tylko z lenistwa obrabia sie dane w tych onklikach.
> Wliczając w to "wiodące aplikacje na androida" jak choćby liczenie
> zajętości aplikacji w pamieci.
>
> Oni wszyscy uzywają gui i watków ale byle jak.
>
> Nawet OSy są spieprzone, że przypomnę że głupi windows czeka kilka sekund
> na odpowiedź czy w napędzie jest płyta jesli własnie jest detektowana, a
> starsze windowsy zamarzaly się na czas odczytu dyskietki.
>
> Pisanie responsywnych aplikacji nie polega na uzyciu tu i tam watku, ale
> na zmienie sposobu patrzenia na GUI. Prywatnie, gdybym był złośliwym
> OSem, ubijałbym aplikacje które czakają dłużej niż 50ms ze zwrotem
> sterowania do pętli komunikatów. Ale OSy sa milutkie i *ewentualnie*
> ubijają gdy nie zwrócisz po paru sekundach.

Nie wszyscy programiści "czują" wielowątkowość...

To samo było przy pisaniu interrupt handlers...

do góry

On Wed, 12 Aug 2015 17:50:50 +0200, Sebastian
Biały<h...@p...onet.pl> wrote:
> Na PC wszystkie 3 wiodące przeglądarki otwierają pluginy w wątku
GUI co
> zamraża mi je na kilka sekund jesli dysk jest zajety. Chrome na
androida
> przy wolnmym laczu (np. lejek 4kB/s) szarpie interfejsem bo coś
czeka na
> dane w wątku gui, inne przeglądarki mają gorzej. 99% aplikacji
obrabia
> dane w onkilkach co powoduje nieznośne lagi w GUI. Nikt nie
deleguje
> akcji od razu w tlo, tylko z lenistwa obrabia sie dane w tych
onklikach.
> Wliczając w to "wiodące aplikacje na androida" jak choćby liczenie
> zajętości aplikacji w pamieci.
> Oni wszyscy uzywają gui i watków ale byle jak.

Jak sobie wyobrażasz synchronizacje gui->user gdy wszystko wrzucisz
w tło? Przecież musi to być zsynchronizowane. Wynik zadania w tle w
99% ma być jakoś odzwierciedlony w zmianie stanu w gui (coś ma się
"narsować").
Najprostrzy sposób to progress bar (długa operacja) lub zamrożenie
gui (krótka operacja). Co wybierasz? Wszędzie progress bary??
Jeśli ani jedno i ani drugie to wtedy gui aplikacji będzie dla usera
zachowywać się kompletnie niedetermistycznie, To pozbawienie usera
sprzężenia zwrotnego z gui. User nie będzie wiedział czy już może coś
kliknąć czy poczekać, czy w ogóle coś się dzieje.

--
Marek

do góry

Marek wrote:

> On Wed, 12 Aug 2015 17:50:50 +0200, Sebastian
> Biały<h...@p...onet.pl> wrote:
>> Na PC wszystkie 3 wiodące przeglądarki otwierają pluginy w wątku
> GUI co
>> zamraża mi je na kilka sekund jesli dysk jest zajety. Chrome na
> androida
>> przy wolnmym laczu (np. lejek 4kB/s) szarpie interfejsem bo coś
> czeka na
>> dane w wątku gui, inne przeglądarki mają gorzej. 99% aplikacji
> obrabia
>> dane w onkilkach co powoduje nieznośne lagi w GUI. Nikt nie
> deleguje
>> akcji od razu w tlo, tylko z lenistwa obrabia sie dane w tych
> onklikach.
>> Wliczając w to "wiodące aplikacje na androida" jak choćby liczenie
>> zajętości aplikacji w pamieci.
>> Oni wszyscy uzywają gui i watków ale byle jak.
>
> Jak sobie wyobrażasz synchronizacje gui->user gdy wszystko wrzucisz
> w tło? Przecież musi to być zsynchronizowane. Wynik zadania w tle w
> 99% ma być jakoś odzwierciedlony w zmianie stanu w gui (coś ma się
> "narsować").
> Najprostrzy sposób to progress bar (długa operacja) lub zamrożenie
> gui (krótka operacja). Co wybierasz? Wszędzie progress bary??
> Jeśli ani jedno i ani drugie to wtedy gui aplikacji będzie dla usera
> zachowywać się kompletnie niedetermistycznie, To pozbawienie usera
> sprzężenia zwrotnego z gui. User nie będzie wiedział czy już może coś
> kliknąć czy poczekać, czy w ogóle coś się dzieje.

a co za problem wyszarzyć guzik i włączyć go z powrotem po powricie z
tła?
Bo jak watek wisi to i tak uzytkownik nie ma pojęcia czy może coś
nacisnąć czy nie. Do tego czesto nie może wykonać żadnej innej akcji

--
mst <at> gazeta <.> pl
"-Mam lęk gruntu! -Chyba wysokości?
-Wiem co mówię. To grunt zabija!" T.Pratchett

do góry

W dniu 2015-08-12 o 17:50, Sebastian Biały pisze:
> On 2015-08-10 22:09, Marek wrote:
>>> Wątki.
>> Przecież w javie (nawet Dalvikowej) są wątki
>
> Nie chodzi o ich obecnośc tylko złe uzycie.
>
> Na PC wszystkie 3 wiodące przeglądarki otwierają pluginy w wątku GUI co
> zamraża mi je na kilka sekund jesli dysk jest zajety. Chrome na androida
> przy wolnmym laczu (np. lejek 4kB/s) szarpie interfejsem bo coś czeka na
> dane w wątku gui, inne przeglądarki mają gorzej. 99% aplikacji obrabia
> dane w onkilkach co powoduje nieznośne lagi w GUI. Nikt nie deleguje
> akcji od razu w tlo, tylko z lenistwa obrabia sie dane w tych onklikach.
> Wliczając w to "wiodące aplikacje na androida" jak choćby liczenie
> zajętości aplikacji w pamieci.
>
> Oni wszyscy uzywają gui i watków ale byle jak.
>
> Nawet OSy są spieprzone, że przypomnę że głupi windows czeka kilka
> sekund na odpowiedź czy w napędzie jest płyta jesli własnie jest
> detektowana, a starsze windowsy zamarzaly się na czas odczytu dyskietki.
>
> Pisanie responsywnych aplikacji nie polega na uzyciu tu i tam watku, ale
> na zmienie sposobu patrzenia na GUI. Prywatnie, gdybym był złośliwym
> OSem, ubijałbym aplikacje które czakają dłużej niż 50ms ze zwrotem
> sterowania do pętli komunikatów. Ale OSy sa milutkie i *ewentualnie*
> ubijają gdy nie zwrócisz po paru sekundach.

Lejesz miód na moje serce swoim pisaniem. Bałem się, że takich
programistów już nie ma. Dziś zawaleni jesteśmy programami pełnymi
błędów i niedoróbek tak dużych, że wstyd się podpisać pod czymś takim
jako autor. Nawet duzi producenci takiego sprzętu jak TV czy radio -
coraz częściej korzystają z oprogramowania tak niskiej jakości, jakby
było pisane przez licealistów na zaliczenie na słabą tróję.


--
MN

do góry