Android Performance Problem

[Peter666]

Hi,

ich hab hier ein riesen Problem mit einem zu betreuenden Projekt. Auf meinem Entwicklungstablet (Nexus7) läuft die Anwendung akzeptabel. Die Anzeige besteht aus einer eigenen Komponente und einerm Listview, sowie 4 Comboboxen und einem Button. Bei der Präsentation beim Kunden wurde mir allerdings schlecht. Der nutzt ein aktuelles Tablet Z von Sony und dort läuft das ganze unter aller Sau. Freundlich ausgedrückt mit einer Performance die geht überhaupt nicht.
Das Backend ist Gottseihdank unabhängig von der Anzeige und so ist der Aufwand das ganze Nativ zu gestalten hoffentlich übersichtlich. Meine Frage ist ob jemand mit der DPF Android Komponente Erfahrungen gesammelt hat? Ich finde da keine Combobox und gerade bekomme ich gefühlt nen halben Herzkasper da das Projekt eigentlich schon im März hätte fertig sein müssen. Der Kunde hat sich nur erst heute gemeldet und da ich eigentlich der Meinung war das ganze ist abgeschlossen hab ich die Zeit für andere Projekte verwendet

[mkinzler]

Unter Android heisst das Control Spinner. Der Wrapper von DPF nennt sich deshalb TDPFJSpinner

[Peter666]

Ah danke, ich hab mal grob das Design nachgebaut. Das wirkt jetzt ziemlich bunt im Vergleich du dem schwarzen Kitkat Style. Wenigstens weiß ich nun das das ganze zumindest mit halbwegs überschaubaren Aufwand machbar ist.

[CHackbart]

Echt so schlimm? Ich hab die Erfahrung gemacht das man im ungünstigen Fall die Performance von FM zumindest unter Android extrem in den Keller ziehen kann. Android zwingt einen die Applikation von der UI zu trennen. Also alles was nicht in ein paar Millisekunden berechnet werden kann, sollte man in einen Extra Thread packen. Ansonsten kommt nach 5 Sekunden die "Applikation reagiert nicht" Anzeige.
Man sollte beachten das bei jeder Änderung die komplette Anzeige neu berechnet wird und FillText ist nicht wirklich schnell. Bei einigen Geräten scheint außerdem das Verwenden von Farbverläufen nicht zu gehen (oder aber ich hab in meiner Klasse Murx gemacht, was auch sein kann). Der Screenshot im Anhang zeigt das Problem:

Delphi-Quellcode:

 Canvas.Fill.Kind := TBrushKind.bkGradient;
 Canvas.Fill.Gradient.Color := (GlossAlpha and $FF) shl 24 or $FFFFFF;
 Canvas.Fill.Gradient.Color1 := $00FFFFFF;

 X := R.Left + (Width * 0.10);
 Y := R.Top + (Width * 0.07);
 Canvas.FillEllipse(RectF(X, Y, X + (Width * 0.80), Y + (Width * 0.7)), 1);

 Canvas.Fill.Gradient.Color := $00FFFFFF;
 Canvas.Fill.Gradient.Color1 := ((GlossAlpha div 3) and $FF) shl 24 or
      FBackColor and $FFFFFF;

 X := R.Left + Width * 0.25;
 Y := R.Top + Width * 0.77;
Canvas.FillEllipse(RectF(X, Y, X + Width * 0.5, Y + Width * 0.2), 1);

GlossAlpha ist ein Bytewert und FBackcolor die Hintergrundfarbe in der unteren Ellipse. Ich habe keine Ahnung warum sich das Rot verfärbt.
Was unter iOS super läuft zuckelte Anfangs in Android vor sich hin und ich war auch extrem nah dran die nativen DPF Routinen zu verwenden.
Übrigens waren die beiden Gauges der Performancekiller wie sich herausgestellt hat. Ich rendere diese jetzt in eine Bitmap wenn sich der
anzuzeigende Wert verändert und zeichne die Bitmap und nicht die komplette Anzeige. Die Komponente kann ich bei Bedarf gerne zur
Verfügung stellen.
Damit die Anzeige auf dem Zielgerät nicht zu verwaschen aussieht muss man die Bitmap übrigens skalieren. Den dazugehörigen Wert bekommt man via:
  if TPlatformServices.Current.SupportsPlatformService(IFMXScreenService,IInterface(ScreenSvc)) then FScale := ScreenSvc.GetScreenScale