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. WBS GRUPPE, deutschlandweit (Home-Office)
  2. Dürr AG, Bietigheim-Bissingen
  3. VITRONIC Dr.-Ing. Stein Bildverarbeitungssysteme GmbH, Wiesbaden
  4. SV Informatik GmbH, Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 23,99€
  2. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


Raspberry Pi: Spieglein, Spieglein, werde smart!
Raspberry Pi
Spieglein, Spieglein, werde smart!

Ein Spiegel, ein ausrangierter Monitor und ein Raspberry Pi sind die grundlegenden Bauteile, mit denen man sich selbst einen Smart Mirror basteln kann. Je nach Interesse können dort dann das Wetter, Fahrpläne, Nachrichten oder auch stimmungsvolle Bilder angezeigt werden.
Eine Anleitung von Christopher Bichl

  1. IoT mit LoRa und Raspberry Pi Die DNA des Internet der Dinge
  2. Bewegungssensor auswerten Mit Wackeln programmieren lernen
  3. Raspberry Pi Cam Babycam mit wenig Aufwand selbst bauen

Ottobock: Wie ein Exoskelett die Arbeit erleichtert
Ottobock
Wie ein Exoskelett die Arbeit erleichtert

Es verleiht zwar keine Superkräfte. Bei der Arbeit in unbequemer Haltung zum Beispiel mit dem Akkuschrauber unterstützt das Exoskelett Paexo von Ottobock aber gut, wie wir herausgefunden haben. Exoskelette mit aktiver Unterstützung sind in der Entwicklung.
Ein Erfahrungsbericht von Werner Pluta


    Elektromobilität: Der Umweltbonus ist gescheitert
    Elektromobilität
    Der Umweltbonus ist gescheitert

    Trotz eines spürbaren Anstiegs zum Jahresbeginn kann man den Umweltbonus als gescheitert bezeichnen. Bislang wurden weniger als 100.000 Elektroautos gefördert. Wenn der Bonus Ende Juni ausläuft, sind noch immer einige Millionen Euro vorhanden. Die Fraktion der Grünen will stattdessen Anreize über die Kfz-Steuer schaffen.
    Eine Analyse von Dirk Kunde

    1. Elektromobilität Nikola Motors kündigt E-Lkw ohne Brennstoffzelle an
    2. SPNV Ceské dráhy will akkubetriebene Elektrotriebzüge testen
    3. Volkswagen Electrify America nutzt Tesla-Powerpacks zur Deckung von Spitzen

    1. Indiegames-Rundschau: Von Weltraumlokomotiven und Affenkönigen
      Indiegames-Rundschau
      Von Weltraumlokomotiven und Affenkönigen

      Sunless Skies und Battlefleet Gothic Armada 2 zeigen bizarre Science-Fiction, Spinnortality verknüpft Cyberpunk und Wirtschaftssimulation: Golem.de stellt spannende neue Indiegames vor.

    2. Honor View 20 im Test: Schluss mit der Wiederverwertung
      Honor View 20 im Test
      Schluss mit der Wiederverwertung

      Mit dem View 20 weicht Huawei mit seiner Tochterfirma Honor vom bisherigen Konzept ab, altgediente Komponenten einfach neu zu verpacken: Das Smartphone hat nicht nur erstmals eine Frontkamera im Display, sondern auch eine hervorragende neue Hauptkamera, wie unser Test zeigt.

    3. Play Store: Google will App-Updates auch ohne Google-Konto erlauben
      Play Store
      Google will App-Updates auch ohne Google-Konto erlauben

      Google will App-Updates über den Play Store auch dann ermöglichen, wenn der Nutzer nicht mit einem Google-Konto angemeldet ist. Wer sein Android-Gerät partout ohne Google-Konto betreiben möchte, ist demnach nicht länger von Updates abgehängt.


    1. 10:07

    2. 09:00

    3. 08:29

    4. 07:48

    5. 07:35

    6. 07:20

    7. 13:49

    8. 13:20