Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Touchpad im Test: iPad-Klon von HP…

Träge trotz mehr PS

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Träge trotz mehr PS

    Autor: scrumm3r 13.07.11 - 12:58

    Das deckt sich mit meinen eigenen Erfahrungen. Apple macht alles richtig, wenn sie Programmierer dazu zwingen mit hardwarenahen Programmiersprachen wie C, C++ und Objective-C zu programmieren. Trotz deutlich weniger RAM und CPU-Power ziehen die iGeräte hoffnungslos übervorteilt an der Konkurrenz vorbei.

    Java und JavaScript sind die 2 Stricke, mit denen Android und WebOS sich die Beine zusammenbinden.

  2. Re: Träge trotz mehr PS

    Autor: Junior-Consultant 13.07.11 - 13:36

    Apple zwingt niemanden.

    Man kann für das iPhone auch sehr gut native Apps in Javascript, HTML5 und CSS3 schreiben.

    Siehe:
    http://www.phonegap.com/apps

  3. Leider falsch

    Autor: scrumm3r 13.07.11 - 13:39

    Da liegst du leider falsch. iApps auf Basis von Titanium oder PhoneGap sind allesamt ganz schlechte Beispiele für gute Bedienbarkeit. Sie sind all das, was man von WebOS und Android nur zu geht kennt und hasst: träge und hemmungslose Batteriesauger.



    1 mal bearbeitet, zuletzt am 13.07.11 13:40 durch scrumm3r.

  4. Re: Träge trotz mehr PS

    Autor: Wahrheitssager 13.07.11 - 13:43

    JavaScript muss nicht unbedingt langsamer sein.

  5. Re: Träge trotz mehr PS

    Autor: AndyGER 13.07.11 - 14:15

    Weil? Mir fehlt da irgendwo jetzt die Begründung und das Beispiel ... :)

    ===============================================================
    Its Time to think. More Different ...

  6. Re: Leider falsch

    Autor: Yeeeeeeeeha 13.07.11 - 14:56

    Ich programmiere gerade eine App mit Phonegap und Sencha Touch (Portierung eines Programms, das normalerweise in einem Java mit Webkit-Window läuft). Nebenbei portiere ich die GUI testweise in eine native GUI, also reines Objective-C mit dem GUIKit von iOS,

    Es ist ein Unterschied wie Tag und Nacht. Zwar Ist die Bedienung an sich fast identisch (Sencha Touch baut das GUIKit quasi nach), die Performance ist aber verglichen unterirdisch.
    Der große Unterschied ist halt, dass native GUIs in iOS komplett GPU-beschleunigt sind.

    Yeeeeeeeeha - Nur echt mit 2^3 e
    Perl-Monk, Java-Trinker, Objective-C Wizard, PHP-Kiddie, unfreiwilliger FreeBSD-/Linux-Teilzeitadmin

  7. Re: Träge trotz mehr PS

    Autor: gorsch 13.07.11 - 15:36

    >Der große Unterschied ist halt, dass native GUIs in iOS komplett GPU-beschleunigt sind.
    Das ist eben genau der Punkt. Solange die drawing Routinen fein vom Applikationsthread entkoppelt sind und auf die Hardware zurückgreifen kann man ohne weiteres auch in Java oder Javascript völlig flüssige Anwendungen entwickeln. (Die Anwendungslogik ist ja bei den meisten Apps auch wenig aufwendig)
    Das Problem ist aber, dass z.B. Android das ganze System oftmals auf die Garbage Collection warten muss und dann stockt es eben.
    Und inwiefern man jetzt Objective-C als hardwarenah bezeichnen kann, sei mal dahingestellt, aber reiner Objective-C code ist wohl kaum schneller als Javascript auf modernen JIT engine.

  8. Re: Träge trotz mehr PS

    Autor: Yeeeeeeeeha 13.07.11 - 16:14

    gorsch schrieb:
    --------------------------------------------------------------------------------
    > Das ist eben genau der Punkt. Solange die drawing Routinen fein vom
    > Applikationsthread entkoppelt sind und auf die Hardware zurückgreifen kann
    > man ohne weiteres auch in Java oder Javascript völlig flüssige Anwendungen
    > entwickeln. (Die Anwendungslogik ist ja bei den meisten Apps auch wenig
    > aufwendig)

    Jup. In iOS läuft zwar das Aktualisieren der GUI im Hauptthread, so etwas wie Animationen oder Scrollen aber eben nebenläufig.

    > Das Problem ist aber, dass z.B. Android das ganze System oftmals auf die
    > Garbage Collection warten muss und dann stockt es eben.

    Richtig. Deshalb läuft es ja auch den Tablets mit DualCore-ARM auch deutlich durchgängiger flüssig (zudem bei Honeycomb zumindest teilweise die GPU benutzt wird).

    > Und inwiefern man jetzt Objective-C als hardwarenah bezeichnen kann, sei
    > mal dahingestellt, aber reiner Objective-C code ist wohl kaum schneller als
    > Javascript auf modernen JIT engine.

    Hmmm naja, JIT Engines sind schon sehr schnell, trotzdem gibt es noch immer einen recht großen Unterschied.
    Objective-C ist eigentlich nichts anderes als eine Erweiterung von C (man kann auch stinknormales C reinprogrammieren, benutze ich z.B. für SQLite und JSON-Libs) und wird dementsprechend optimiert compiliert. Wirklich hardwarenah ist es nicht, da man in der Regel sehr viel die Libs wie das GUIKit benutzt. Allerdings gibt es einen gewaltigen Unterschied zu Javascript: Die dynamische Typisierung. Dabei fällt eine Menge Konvertierungsfoo weg, was - je nach App - durchaus einen größeren Unterschied machen kann.

    Yeeeeeeeeha - Nur echt mit 2^3 e
    Perl-Monk, Java-Trinker, Objective-C Wizard, PHP-Kiddie, unfreiwilliger FreeBSD-/Linux-Teilzeitadmin

  9. Re: Leider falsch

    Autor: scrumm3r 13.07.11 - 17:17

    Dann haben wir ja was gemeinsam. Ich benutze Titanium nurnoch für Prototypen und halte es für eine Sünde am Kunden, ihm sowas aufzuschwatzen ...

  10. Re: Träge trotz mehr PS

    Autor: scrumm3r 13.07.11 - 17:21

    gorsch schrieb:
    --------------------------------------------------------------------------------
    > ... aber reiner Objective-C code ist wohl kaum schneller als
    > Javascript auf modernen JIT engine.

    Und das weißt du weshalb so genau?

    Das die Wahrheit komplett anders aussieht, merke ich jeden Tag bei der Arbeit ...

  11. Re: Träge trotz mehr PS

    Autor: Junior-Consultant 13.07.11 - 17:36

    "Da liegst du leider falsch. iApps auf Basis von Titanium oder PhoneGap sind allesamt ganz schlechte Beispiele für gute Bedienbarkeit. Sie sind all das, was man von WebOS und Android nur zu geht kennt und hasst: träge und hemmungslose Batteriesauger."

    Kompletter Unsinn. Ich habe bereits Apps auf Basis von Objective C, Sencha Touch und JQTouch / PhoneGap entwickelt und bei richtiger Herangehensweise stimmt das einfach überhaupt nicht. Gerade bei den GPU-beschleunigten CSS3 Transitions sehe ich keinen Unterschied mehr zur nativen Anwendung.



    1 mal bearbeitet, zuletzt am 13.07.11 17:38 durch Junior-Consultant.

  12. Re: Träge trotz mehr PS

    Autor: .ldap 13.07.11 - 17:47

    Core Graphics ist zum Beispiel 100% C#/C++. Einfach, weil die Animationen dann viel schneller dargestellt werden können.

  13. Re: Träge trotz mehr PS

    Autor: scrumm3r 13.07.11 - 20:46

    Dann hast du leider noch nichts geschrieben, dass über einen gewissen Grad an Komplexität hinausgeht.

  14. Re: Träge trotz mehr PS

    Autor: scrumm3r 13.07.11 - 20:49

    CopreGraphics ist nicht in C# geschrieben. Es besteht hauptsächlich aus reinem C, OpenCL und beinhaltet ein paar Spuren von C++. Wie kommst du dazu, solche Behauptungen aufzustellen?

  15. Re: Träge trotz mehr PS

    Autor: Schnarchnase 13.07.11 - 21:29

    scrumm3r schrieb:
    --------------------------------------------------------------------------------
    > Dann hast du leider noch nichts geschrieben, dass über einen gewissen Grad
    > an Komplexität hinausgeht.

    Wie flüssig sich die Oberfläche der Anwendung bedienen lässt, hat nicht unbedingt etwas mit der Komplexität zu tun. Wir haben für einen Kunden eine App in Objective-C und eine mit Phonegap/Javascript umgesetzt, beide lassen sich exakt gleich flüssig bedienen, letztere startet allerdings etwas langsamer/länger.

  16. Re: Träge trotz mehr PS

    Autor: scrumm3r 14.07.11 - 09:12

    Das ist schön für euch, sagt aber noch nichts über die Komplexität aus. Spätestens wenn es um größere Datenmengen und/oder etwas kompliziertere Grafiken geht, hat JavaScript eindeutig das Nachsehen. Beides war bei euch wohl nicht der Fall. Ich muss also davon ausgehen, dass ihr minderkomplexe Anforderungen umzusetzen hattet.

  17. Re: Träge trotz mehr PS

    Autor: Schnarchnase 14.07.11 - 09:23

    scrumm3r schrieb:
    --------------------------------------------------------------------------------
    > Das ist schön für euch, sagt aber noch nichts über die Komplexität aus.

    Ich würde sagen beide Anwendungen sind recht komplex, es sind jedenfalls keine 0815-Apps die man mal schnell runtergeschrieben hat.

    > Spätestens wenn es um größere Datenmengen und/oder etwas kompliziertere
    > Grafiken geht, hat JavaScript eindeutig das Nachsehen.

    Große Datenmengen haben absolut nichts mit Komplexität zu tun.

  18. Re: Träge trotz mehr PS

    Autor: scrumm3r 14.07.11 - 09:29

    Insofern du mit den Datenmengen was kompliziertes machst, schon. Einen Auswertungsalgorithmus für nicht vernachlässigbare Datenmengen mit grafischer Darstellung auf einem Telefon performant zu bekommen, ist jedenfalls mit Objective-C deutlich besser machbar, als mit JavaScript. In solche Fällen zeigt sich sehr schnell, dass es da um stellenweise im den Faktor 1000 geht, den JavaScript langsamer ist, als eine kompilierte Programmiersprache.

    Selbst mit den neuesten VMs ist das so.

  19. Re: Leider falsch

    Autor: Yeeeeeeeeha 14.07.11 - 09:37

    Macht Titanium nicht so eine seltsame JS-Native-Verschwurbelung? Irgendwie machen die immer Werbung mit dem Wort "native", was genau das in dem Moment bedeutet, habe ich aber noch nicht herausgefunden. Wie läuft das denn da?

    Yeeeeeeeeha - Nur echt mit 2^3 e
    Perl-Monk, Java-Trinker, Objective-C Wizard, PHP-Kiddie, unfreiwilliger FreeBSD-/Linux-Teilzeitadmin

  20. Re: Leider falsch

    Autor: scrumm3r 14.07.11 - 09:56

    Titanium benutzt native UI-Elemente. D.h. du musst die Konfiguration und das Styling des UI und stellenweise ein paar Events für jede Zielplattform neu schreiben. Das Ergebnis verhält sich deutlich performanter als JS in Verbindung mit HTML. Zudem muss man nicht alles eigenhändig nachbasteln.
    Zu meiner Erheiterung musste ich schon einige Male feststellen, dass die Verwendung von JavaScript zusammen mit Titanium oder PhoneGap die Entwicklungszeit nicht verkürzt. Unter der Voraussetzung, dass man die APIs gut kennt und weiß, was man tut, entwickelt es sich mit den plattform-nativen Sprachen und APIs (Android -> Java/XML, iOS -> Obj-C) immer deutlich schneller, als mit einem Drittanbieter-Aufsatz.

  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. DEKRA SE, Stuttgart
  2. BWI GmbH, Bonn, München, Schwielowsee
  3. SCHOTT Schweiz AG, St. Gallen (Schweiz)
  4. KRÜSS GmbH, Hamburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 1,24€
  2. 59,99€ für PC/69,99€ für PS4, Xbox (Release am 4. Oktober)
  3. (-71%) 11,50€
  4. 2,22€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Mobile-Games-Auslese: Magischer Dieb trifft mogelnden Doktor
Mobile-Games-Auslese
Magischer Dieb trifft mogelnden Doktor

Ein Dieb mit Dolch in Daggerhood, dazu ein (historisch verbürgter) Arzt in Astrologaster sowie wunderschön aufbereitetes Free-to-Play-Mittelalter in Marginalia Hero: Golem.de stellt die spannendsten neuen Mobile Games vor.
Von Rainer Sigl

  1. Hyper Casual Games 30 Sekunden spielen, 30 Sekunden Werbung
  2. Mobile-Games-Auslese Rollenspiel-Frühling mit leichten Schusswechseln
  3. Gaming Apple Arcade wird Spiele-Flatrate für iOS und MacOS

Ada und Spark: Mehr Sicherheit durch bessere Programmiersprachen
Ada und Spark
Mehr Sicherheit durch bessere Programmiersprachen

Viele Sicherheitslücken in Software sind auf Programmierfehler zurückzuführen. Diese Fehler lassen sich aber vermeiden - und zwar unter anderem durch die Wahl einer guten Programmiersprache. Ada und Spark gehören dazu, leider sind sie immer noch wenig bekannt.
Von Johannes Kanig

  1. Das andere How-to Deutsch lernen für Programmierer
  2. Programmiersprachen, Pakete, IDEs So steigen Entwickler in Machine Learning ein
  3. Software-Entwickler Welche Programmiersprache soll ich lernen?

Ocean Discovery X Prize: Autonome Fraunhofer-Roboter erforschen die Tiefsee
Ocean Discovery X Prize
Autonome Fraunhofer-Roboter erforschen die Tiefsee

Öffentliche Vergaberichtlinien und agile Arbeitsweise: Die Teilnahme am Ocean Discovery X Prize war nicht einfach für die Forscher des Fraunhofer Instituts IOSB. Deren autonome Tauchroboter zur Tiefseekartierung schafften es unter die besten fünf weltweit.
Ein Bericht von Werner Pluta

  1. JAB Code Bunter Barcode gegen Fälschungen

  1. Verbraucherschutz: Vodafone-Pass muss auch im EU-Ausland gelten
    Verbraucherschutz
    Vodafone-Pass muss auch im EU-Ausland gelten

    Wer einen Vodafone-Tarif mit Vodafone-Pass hat, kann bestimmte Apps ohne Anrechnung auf das Datenvolumen nutzen. Das ging bisher nur in Deutschland, muss aber auch für das EU-Ausland gelten, hat das Landgericht Düsseldorf entschieden.

  2. HPE Primera: Perfekte Verfügbarkeit mit Fußnote
    HPE Primera
    Perfekte Verfügbarkeit mit Fußnote

    Mit einem neuen Angebot will HPE potenzielle Kunden locken. Im Vordergrund steht das Versprechen einer perfekten Verfügbarkeit des Primaer-Storage-Systems. Im Hintergrund: die Fußnoten.

  3. Werbung: AR-Lippenstift für Youtube-Influencer
    Werbung
    AR-Lippenstift für Youtube-Influencer

    Influencer können künftig auf Youtube nicht mehr nur einfach für bestimmte Produkte werben, Zuschauer sollen diese auch virtuell ausprobieren. Möglich macht das Augmented Reality.


  1. 11:35

  2. 11:03

  3. 10:48

  4. 10:36

  5. 10:10

  6. 09:40

  7. 09:24

  8. 09:12