Schreiben von sauberem, leistungsfähigem Code für das iPhone

Question

Seit einigen Monaten entwickle ich mit Objective-C für das iPhone und wende dabei die Best Practices an, die ich bei der Entwicklung von Anwendungen mit Java gelernt und verfeinert habe. Dazu gehören: das Entwerfen von Klassen, die eine einzige Verantwortung haben, die Anwendung von Entwurfsmustern, wo es angebracht ist, und das Schreiben von Kurzmethoden die nur eine Sache tun. Für mich sind diese Praktiken sowohl aus einer sauberer Code und sind weitgehend bereichsunabhängig.

Ich bin mit den Ergebnissen sehr zufrieden. Allerdings haben mir einige iPhone-Entwickler unabhängig voneinander davon abgeraten, da ich ihrer Meinung nach zu viele Klassen und zu viele Methoden schreibe. Zu verschiedenen Zeiten wurde ich gewarnt:

• Der Stapel wird explodieren
• Zu viele Klassen verlangsamen das iPhone (d.h. sind für den Benutzer spürbar)
• Verschachtelte Methodenaufrufe beeinträchtigen die Leistung (d.h. sie sind für den Benutzer spürbar)

In der Praxis habe ich diese Probleme nicht erlebt. Bei oberflächlicher Betrachtung einiger iPhone-Leistungskennzahlen Es scheint mir, dass die zusätzlichen Methodenaufrufe und der Mehraufwand für den Lebenszyklus von Objekten, die für die Implementierung allgemeiner Muster und kurzer Methoden erforderlich sind, kaum zu einer für den Benutzer spürbaren Verzögerung führen werden. Die Ratschläge anderer iPhone-Entwickler haben mich jedoch ein wenig erschreckt.

Ich möchte die domänenunabhängigen Programmierpraktiken, die mir in der Vergangenheit gute Dienste geleistet haben, weiter erlernen und verfeinern, aber bei der Entwicklung auf dem iPhone möchte ich nicht einen Weg einschlagen, der mit Schmerzen endet!

Also im Hinblick auf diese Plattform - sollte ich einige gemeinsame Best-Practices aufgeben und bewusster sein der Optimierung von Methodenaufruf und Objekt-Lebenszyklus-Overheads? Oder sollte ich weiterhin folgen Knuths Ratschläge:

Vorzeitige Optimierung ist die Wurzel von allen Übels (oder zumindest des größten Teils davon) in der Programmierung

Answer 1

Für mich kommt es wirklich auf die Wartbarkeit an. Mit qualitativ hochwertigem Code kann man das System viel einfacher warten.

Ich habe Entwickler, die mit mir zusammenarbeiten, und wenn ich ihnen vorschlage, Abkürzungen zu nehmen, um ein System zum Laufen zu bringen, verhöhnen sie mich und liefern das Projekt verspätet ab - und das hat sich auf lange Sicht jedes Mal ausgezahlt!

Wenn es eine intensive App ist, mit opebGL und was nicht, dann könnte die Leistung ein Problem werden. Wenn es nur ein einfaches Dienstprogramm oder eine Daten-App ist. würde ich empfehlen, mit den besten Code-Praktiken, die Sie kennen, fortzufahren, und sie dann weiter zu lernen, da sie von unschätzbarem Wert sind. Die meisten Muster sind domänenunabhängig und für alle grundlegenden Programmiersprachen von Vorteil.

Und wenn Sie den Stapel aufblasen, dann re Faktor einige dieser Methoden/Klassen in einzelne Anrufe (zumindest wissen Sie, dass es passieren könnte und wird es bemerken, sobald es passiert) Und wenn es nicht dann haben Sie awesome Code zu pflegen, die leicht lesbar ist von jedem halb gebackenen Code-Affe, der es später zu sehen hat.

Answer 2

Das ganze Problem der Verlangsamung von OO-Anwendungen besteht einfach darin, dass Objekte leichter außer Kontrolle geraten können als strukturierte Programmierstile. Früher, bevor die Optimierung von Methodenaufrufen verbessert wurde, konnte dies einen Unterschied ausmachen, insbesondere bei indirekten (d.h. virtuellen) Aufrufen.

Wenn Ihre Objekte häufig verwendet werden und Sie einige Objekte auf niedrigerer Ebene haben, die Sie häufig aufrufen, dann kann es sein, dass Sie einen Leistungseinbruch erleiden, wenn Sie diese Objekte verwenden - aber ich spreche hier von Millionen von Aufrufen (ich habe in meiner Zeit einige schreckliche Codes gesehen, sowohl unstrukturierten als auch strukturierten und OO-Code). Sie werden auch mehr Leistungseinbußen erleiden, wenn Sie viele (sehr viele) Objekte ständig zuweisen und löschen.

Die einzige Antwort ist, dass man es sich ansehen sollte. Wenn Sie ein Objekt haben, das in schneller Folge zugewiesen und gelöscht wird, dann optimieren Sie es (auch wenn es weniger elegant aussieht), wenn Sie ein Objekt haben, dessen Methoden Tausende von Malen aufgerufen werden, dann optimieren Sie auch das. (Aber sobald Sie diese Messung durchgeführt haben, haben Sie die Leistung gemessen und werden die langsamen Teile verfeinern).

Es gibt einen Kompromiss zwischen "elegantem" Code und einem Code, der einfach und schnell funktioniert. Gehen Sie nicht in eines der beiden Extreme und Sie sollten gut zurechtkommen.

Answer 3

Eine ähnliche Erfahrung habe ich bei der Entwicklung einer ziemlich komplizierten Blackberry-Anwendung gemacht. Auch mir wurde gesagt, ich solle häufige Objektzuweisungen, innere Klassen usw. vermeiden. Die ursprüngliche Anwendung, die wir hatten, war ein unwartbares Chaos. Vor kurzem habe ich die Anwendung neu geschrieben und dabei den Schwerpunkt auf ein gutes OO-Design gelegt (Muster, wo nötig, viele zweckgebundene und oft unveränderliche Objekte usw.). An vielen Stellen habe ich gegen den Rat verstoßen, bestimmte "kostspielige" Konstrukte und Objektzuweisungen zu vermeiden. Die resultierende Anwendung war nicht nur einfacher zu warten, sondern auch kleiner. Wenn die zusätzlichen Objektzuweisungen einen Overhead verursachten, habe ich das nicht bemerkt. Ich denke, die Lektion hier ist genau das, was Knuth sagte. Konzentriere dich zuerst auf ein gutes Design und optimiere dann, wenn nötig. Außerdem haben diese mobilen Geräte heutzutage so viel Speicher, dass dieser Ratschlag hoffentlich in Vergessenheit geraten wird...

Answer 4

Generell gilt: Machen Sie sich keine Gedanken darüber. Der einzige Fall, in dem die Verwendung von Objekten und Nachrichten ein potenzielles Leistungsproblem darstellen könnte, ist, wenn Sie Hunderte oder Tausende von Zuweisungen auf einmal vornehmen oder Tausende von Nachrichten alle paar ms senden. Sie würden keine Obj-C-Objekte verwenden wollen, um Tausende von 3D-Vektoren in einer Physiksimulation darzustellen.

Selbst wenn Sie viele Nachrichten in einer Schleife senden, können Sie die Leistung verbessern, indem Sie einen Funktionszeiger auf die entsprechende Methode vor der Schleife speichern.