Witam,
Chciałem przekompilować moją aplikację na androida, lecz okazało się że pracuje bardzo wolno.
Zrobiłem więc testy z prostymi rzeczami jak np: wypisanie 100 liczb, wyznaczenie 100 początkowych liczb pierwszych.
Na Win32 działa to w ułamku sekundy, a na android kilka, kilkanaście sekund. Dołożyłem pomiar czasu i pierwsze 10000 liczb pierwszych PC wylicza w 2 sekundy, a android w 1min 32 sek. Używam do testów tablet z androidem 4.2.2.
Czy to normalne? Czy Delphi nie nadaje się do kompilowania na ten system?
Pozdrawiam.
0
2
Klakierus napisał(a)
Napisałem jakąś aplikację i działa ona wolno. Co może być przyczyną? Nie podam nazwy tabletu, ani jego specyfikacji, ani wersji Delphi, ani kodu źródłowego, ani w ogóle niczego konkretnego, bo nie.
0
Podejrzewam, że wolno chodzi nie liczenie, a samo wyświetlanie.
Zmierz czas bez wyświetlania (ale wyświetl np. sumę wszystkich wyliczonych liczb, żeby kompilator nie wyciął "zbędnych" operacji).
0
Po pierwsze podałem że robiłem testowe aplikacje na wypisanie 100 liczb, którym to zajmuje kilka sekund. Oto przykładowy kod:
For n:=0 to 100 do Memo1.Lines.Add(Inttostr(n))
Ciekawy jesteś jaki tablet mam czy co? Stary z ww systemem 4.2.2! Nie jest to wina powolnego tabletu, bo na Sony Xperia Z1 działa tak samo wolno.
Moje pytanie dotyczyło czy aplikacje pisane na android zawsze pełzają, czy Delphi XE7 dobrze kompiluje na androida.
Dzięki Azarien, pewne jest, że czas wypisywania jest stanowczo za długi, czy to wina używania TMemo? Test bez wypisywania wszystkich liczb na PC: 0:00 sek, na androidzie 1:08.
dodanie znacznika <code class="delphi"> - @furious programming
2
Zablokuj odświeżanie na czas wypisywania - Memo1.Lines.BeginUpdate;, potem pętla, a potem Memo1.Lines.EndUpdate; - powinno pomóc.
0
Ogólnie przekonałem się kiedyś i to pod Windowsem, że dodawanie do TMemo trwało wolniej nawet z [Begin/End]Update niż do TListBox. Ja na razie dla swojego tabletu Lenovo Yoga 2 z Androidem Kitkat 4.4 bodajże napisałem prostą apkę, która z logów KODI wycina mi linki do odtworzonych rzeczy. I Jeśli adres zaczyna się od HTTP to można go otworzyć w domyślnym btowserze. a jeżeli to będzie wpis z wtyczki do TV online (na przykład RTMP) to skopiuje go do schowka. Wpisów jest na ogół góra kilka w jednym logu, także ciężko sprawdzić prędkośc.
Może zatem jeśli nie potrzebujesz edycji treści tych wyników, spróbuj z TListBox. Ja wprawdzie używam XE8 i jedyny problem jaki zauważyłem, to taki że aby mieć działający apk trzeba zrobić Develop dla wersji Debug. Bo kiedy robimy Develop dla Release to stworzony apk nie uda się zainstalować, otrzymymy błąd. I nie wiem z czego to wynika. W LazToApk dało się zrobić o wiele mniejszy apk i instalować go bez problemów. Ale tam nie da się tak łatwo używać kontrolek i nie ma dostępu, a przynajnniej nikt mi z tym nie pomógł na forum Lazarusa, aby uzyskać ścieżki do folderów specjalnych. Nie da się też wygodnie otwierać linków HTTP z użyciem Intent, tylko jakąś pokrętną metodą, która po slasku dodaje do wyświetlanego linku #, ale link się otiwera.
0
Dziękuję za odpowiedzi, też zauważyłem że dla Release nie da się instalować, wywala błąd certyfikatu, lecz nie interesowałem się rozwiązaniem tego problemu, bo szybkość działania jest nie do przyjęcia.
Nie podałem danych tabletu, bo na kilku urządzeniach działa tak samo. Nie chodzi mi też o optymalizację kodu, tylko ewentualnie czego nie używać (dzięki za podpowiedź z TListBox). Podałem różnice szybkości działania tego samego kodu na PC i na systemie android. Mój PC też nie jest najnowszy: procesor Intel Core 2 Duo 2.53GHz, 4GB RAM (rozbudowuję go tylko pozostałościami z rozbudowy komputerów synów), lecz zdziwiła mnie powolność aplikacji na androidzie. Podam moje wyniki programu testowego, który tylko wypisuje liczby pierwsze od 1 do 10 000 (PC w 2 sek), na androidzie:
- czas obliczeń, bez wyświetlania: 1 min 8 sek
- używając TMemo bez Begin/EndUpdate: 1 min 32 sek
- TMemo z Begin/EndUpdate: 1:11
- ListBox: 1:15
Ponownie zapytam: czy to normalne że android tak pełza? Czy wasze aplikacje działają wolniej na androidzie niż na windows?
Pozdrawiam.
0
Jeżeli możesz pokazać jakim kodem dodajesz Itemy do TListBox łączenie z tymi przykładowymi obliczeniami to sprawdzę u siebie na tablecie dokładając button do swojej aplikacji. Tylko nie wiem czy wynik będzie wymierny, bo mój tablet ma cztero rdzenowiowy procesor. A i pewnie brak certyfikatu jest chyba problemem do pomyślnego zainstalowania aplikacji z pliku .apk, skoro Ty napotkałeś ten sam problem, że pomyslnie instaluje się Tobie tylko wersja Debug apk. I jeszze kwestia jak mierzysz czas? Fizycznie stoperem na przykład w telefonie? Bo pod Windows zawsze mierzyłem czas GetTickCount, a nie wiem jak to zrobić prawidłowo pod kątem Androida. A i oczywiście pomyłiłem słowka w poprzednim swoim postcie. Chodziło mi o Deploy, czyli sam proces tworzenia pliku *9.apk, a nie Develop.
0
Oczywiście podaję kod swojego testu:
procedure TForm1.Button1Click(Sender: TObject);
var m,n:integer;
pier:boolean;
t1,t2:Ttime;
begin
t1:=now;
for n:=1 to 10000 do begin
pier:=true;
for m:=2 to n-1 do
if (n/m)=trunc(n/m) then pier:=false;
if pier then begin
ListBox1.Items.Add(inttostr(n));
end;
end;
t2:=now;
Listbox1.Items.Add(timetostr(t2-t1));
end;
Proszę nie zwracać uwagi, na to że może być on wydajniejszy, chodziło mi o porównanie szybkości tabletu i PC-ta. Nie jest to też część mojej aplikacji. Ten kod pokazuje mi tylko różnicę szybkości urządzeń. Jak już pisałem różnica czasu samych obliczeń bez wypisywania jest ogromna (PC: 0:00, tablet 1:08). Czy trzeba może zoptymalizować ustawienia kompilatora?
I proszę o odpowiedź na moje podstawowe pytanie, czy Wy zaobserwowaliście różnice szybkości działania kompilacji pod Win32/64 w stosunku do Android, jeśli nie to jakie Delphi używacie? Ja używam XE7.
dodanie znacznika <code class="delphi"> - @furious programming
1
Faktycznie, to dziwne zachowanie. Na moim tablecie do aplikacji dodałem przycisk testowy. I po kilku sekundach od kliknięcia dla Twojego kodu dostałem odpowiedź, że aplikacja nie odpowiada, ale kazałem czekać. Przed chwilą skończył i taki kod podsumowujący z modułu dateutils: ShowMessage(IntToStr(SecondsBetween(T2, T1))); pokazał mi przed chwilą wynik 123. Podejrzewam, że problemem jest każda kontrolka do której dodajemy dane aby je pokazać. Chyba po prostu nie są one przystosowane do pokazania tak dużej ilości elementów. Taki kod jak poniżej zwrócił 63 sekundy.
procedure TMainForm.Button1Click(Sender: TObject);
var
Pier : boolean;
M, N : integer;
T1, T2 : Ttime;
SL : TStringList;
begin
SL := TStringList.Create;
SL.Clear;
SL.BeginUpdate;
T1 := Now;
for N := 1 to 10000 do
begin
Pier := True;
for M := 2 to N - 1 do
if (N / M) = trunc(N / M) then
begin
Pier := False;
end;
if Pier then
begin
SL.Add(IntToStr(N));
end;
end;
T2 := Now;
SL.EndUpdate;
UrlsLB.Items.Assign(SL);
ShowMessage(IntToStr(SecondsBetween(T2, T1)));
end;
Dla stu liczb do sprawdzenia jest to chwila. Nie potrafię Tobie nic innego doradzić. Używam XE 8. Ale skoro pod starszymi kod kompilujący się pod Windows działa w oka mgnieniu, a używamy podstawowych kontrolek i elementów VCL oraz obiektowości. To według mnie musi zawodzić ich implementacja pod FMX czy jak się to tam zwie oraz Androida.
Jedyne co jeszcze można wykombinować to zrobić powyższy kod bez linijki UrlsLB.Items.Assign(SL);. Wtedy u mnie wykonuje się on w 0 sekund czyli wiadomo bardzo szybko. I później na jakiejś kontrolce pokazywać nie wiem po kilkadziesiąt może kilkanaście góra elementów. Odowłując się do zmiennej globalnej typu TStringlist. Należy też zauważyć, że w kodzie nie zwalniam wcale TStringList. Nie jestem ekspertem w pisaniu pod Androida, ale zauważyłem, że wywoływanie destruktorów czy tez FreeAndNil(X); powoduje wywalenie się aplikacji.
0
Dziękuję olesio za informacje.
Pozdrawiam,
Piotr.
0
@olesio, masz wyciek pamięci z tym SL - dlatego właśnie stosowanie Try Finally jest dobrym nawykiem, bo praktycznie uniemożliwia zapomnienie zwolnienia pamieci po obiektach itp.; Poza tym wywołanie metody Clear tuż po stworzeniu obiektu jest zbędne; No i nie wiem też po co w ogóle używać obiektu SL, skoro można wszystko wykonać bezpośrednio na właściwości Items komponentu (która de facto także posiada metody BeginUpdate i EndUpdate);
@Klakierus - nie rozumiem też jakie zastosowanie ma druga pętla For i flaga Pier; Jeśli warunek nie zostanie spełniony, zmienna Pier dostanie wartość False, ale pętla nie zostaje przerwana; Wszystko można wykonać od razu w tej drugiej pętli, już nie pisząc o tym, że warunek znajdujący się w niej można w ogóle wykluczyć i zastąpić go zwykłym przypisaniem:
Pier := (N/M) <> Trunc(N/M);
0
Masz rację, ale to był tylko test porównawczy prędkości PC-tablet, program który ma zająć procesor, a nie szybko działać. Inaczej na PC miałem czas 0:00.
0
@furious programming: chodzi o to że cokolwiek zwalniałem poprzez Free pisząc apkę dla Androida ta się wywalała. I to nie z wyjątkiem od skompilowanego programu, tylko po prostu dostałem info od Androida, że aplikacja przestała działać. A po to kombinowałem z dodaniem do StringListy żeby zobaczyć efekt. To Clear byłko tylko dla pewności gdyby SL przenieść jako zmienną globalną. Poza tym wtedy czas wypełniania przy użyciu Assign wyniósł połowę tego. Ty piszesz nam pod kątem Windows i wtedy się zgadza, ale jak widać, przy kompilacji pod Androida albo też i pewnie IOS'a, nic nie jest już takie oczywiste, stąd też i ten wątek.
0
Witam.
Podobny problem zaobserwowałem przy użyciu TVertScrollBox.
Nawet skompilowanie dołączonego sampla ScrollableFormDemo (C:\Users\****\Documents\RAD Studio\12.0\Samples\FireMonkeyMobile\ScrollableForm) działa powolnie - przewijanie box'a z tekstem ślimaczy się strasznie.
Szukamy powodu i rozwiązania problemu...