On 11 Nov 2018 09:38:21 GMT, Piotr Karocki <p...@i...org> wrote:
> A teraz jeden kamyczek do ogrodka.

[ ciach lamerskie tłumaczenie czemu gorzej jest lepiej]

Gdzie jest dobrze? To jest dobrze, że jak zostawię na moment
przeglądarkę w tle na urządzeniu z 2GB ram a za chwilę wywołam ja na
front to ładuje wszystko od nowa (bo została wywalona z ram)  w
sytuacji gdy system raportuje 1GB wolnego? To jest dobrze?? To, że
nie mogę wpisać nowego url, bo stary się musi załadować i do tego
momentu
aplikacja jest praktycznie nieresponsywna? 2GB ram to mało by
zostawićna chwilę w ram aplikację?? Serio? Takie samo zachowanie na
innym
urządzeniu, innego producenta, więc jest to problem systemowy a nie
osobniczy. To też nie jest problem jednej aplikacji, bo wszystkie
przeglądarki na Androidzie zachowują się identycznie.

Ten mechanizm schedulera może i był dobry  w  czasach gdy ramu było
256MB i faktycznie trzeba by było robić szpagat. Aktualnie są nawet
urządzenia z 8GB RAM, po ma wyszarpywać przy 8GB RAM?? Czy widziałeś
gdzieś takie idiotyczne zachowanie w schedulerze
desktopa (z połową tej pamięci)?

Inne systemy jakoś przy 2GB ramu nie muszą "wyszarpywać" pamięci ani
deaktywować aplikacji. Ale Android dzielnie, niczym socjalizm
dzielnie rozwiązuje problemy nieistniejące w innych systemach bo
jakiś debil
uznał, że trzeba stworzyć scheduler działający na innych zasadach bo
"środowisko o ograniczonych zasobach" (mało ram, słaba bateria,słaby
CPU itp). Zapamiętać radzę to zdanie w cytacie bo to jest clue całości
problemu.  "Środowisko o ograniczonych zasobach" to było tylko,
uwaga, w momencie określania zarysu architektury Androida i może w
pierwszyc generacjach urządzeń mogło to być przydatne. Jak trzeba być
ograniczonym, by nie uwzględnić, że za technologiczny moment
urządzenia mobilne przekroczą wydajność i zasoby  AKTUALNYCH wtedy
desktopów, a owe "zalety" schedulera staną się wadą?
Weźmy scheduler w kernelu Linuxa, on nic nie musi wyszarpywać, bo
uwaga (developerzy Androida skupić się) ma... paging. Ale oczywiście
nie można było tego wykorzystać w Androidzie bo a) aplikacje Androida
nie są  procesem z pkt widzenia schedulera kernela (w uproszczeniu)
b) działa  mit "środowisko o ograniczonych zasobach". Nie może mieć
swapa na flashu, bo flash się wytrze, za wolny i  inne tego typu
nieaktualne
współcześnie bzdury, o których nie wie byle paparazzi ze swoim
Canonem 1D, którego karta flash przewala gigabajty dziennie i jakoś
co miesiąc karty nie wymienia. Można? Można, ale nie w Androidzie.
Po xuj wywalać aplikację z ram jak ma się GIGABAJTY (oprócz niej)
wolnego ramu? A moment faktycznie. Przecież to java. Żeby uruchomić
przysłowiowy "Hello word" musi wstać cały sandbox JVM potrzebujący min
256MB ram per proces. Skoro mamy "środowisko o ograniczonych zasobach"
to ja się pytam czemu akurat uznano, że jvm będzie akurat świetnym
wyborem na ekosystem dla Androida?   ROTFL!

Ale tu nie tylko problem z schedulerem Androida. Kolejny problem to
sprawa wakelocków. Ile to krwi (czyt. baterii) napsuło użytkownikom.
Czy to nieznamienne, że googole zwraca 18 milionów wyników dla hasła
"android app battery draining"?  Już nie będę się wyżywać wskazując
personalnie idiotę, który wakelocki wymyślił (swoją drogą była ostra
dyskusja na kernel-list jak chciano wakelocki wprowadzić, było wiele
głosów przeciw). Na pierwszy rzut oka (pozornie) pomysł wygląda
rozsądnie. Ponieważ Android to system robiący wiele rzeczy w tle w
sieci (ale domyślnie
aplikacje w tle chodzić nie mogą, taki kurde żarcik twórców) nagłe
przechodzenie w sleep może generować problemy, np. przerywanie
transmisji, zrywanie sesji itp. Zgoda, niech aplikacja ma możliwość
wstrzymania sleep aż skończy.  Mądre założenie ale tylko dla mądrych
programistów a nie dla debili! Którzy nie dość, że wakelocka nie
zdejmują gdy trzeba to jeszcze ustawiają wakeup alarm. Czemu np.
aplikacja do oglądania zdjęć zrobiła 20 alarmów wake na godzinę
praktycznie uniemożliwiając sleep i tym drenując baterię? Oczywiście
mogą  tez to być celowe działania, aplikacje muszą wyświetlać reklamy,
śledzić użytkowników. Świetnie ale dla przeciwwagi użytkownik nie ma
możliwości zrobienia "overdirve" sleep (jak jest w najnowszym to
chętnie się o tym dowiem).
Dlaczego nie mogę np. w tablecie zrobić twardy sleep BEZWARUNKOWY (mam
to gdzieś, że jakaś aplikacja próbuje coś wysłać) ponieważ odkładam
tablet na półkę i dopiero za 10h będę go ponownie używał a nie chcę
robić off bo wstaje za długo? Jakoś w laptopach/desktopach twórcy
systemu i aplikacji nie mają z tym problemu, że robiąc sleep system
jest fizycznie zatrzymywany do wybudzenia przez hardware lub usera
INTENCJONALNIE. Ale w Androidzie się nie da.

--
Marek