Einer der großen, herzzerreißenden Rückschläge bei der Einführung des neuen Designs war, dass der Ankündigungs-Blogbeitrag Safari auf einigen Mobilgeräten zum Absturz bringen würde. Er brachte mein iPhone 4S zum Absturz, ich hörte Berichte über Abstürze auf anderen Android-Geräten, aber er brachte mein iPad 2 nicht zum Absturz. Debugging auf Mobilgeräten ist bereits schwierig genug, aber das Debugging einer Seite, die die gesamte Anwendung zum Absturz bringt, ist noch schwieriger.
Also habe ich natürlich reduzierte Testfälle erstellt!
Mein Prozess bestand darin, die abstürzende Seite zu kopieren und dann langsam Elemente zu entfernen, bis der Punkt erreicht war, an dem sie nicht mehr abstürzte. Ich kam zu dem Punkt, an dem ich einen Kommentar aus dem Kommentar-Thread entfernte und er aufhörte abzustürzen. Diese beiden Dokumente stellen den Punkt dar, der dem Wendepunkt am nächsten kam. Beide haben die gesamte JavaScript entfernt. Beide verwenden exakt dasselbe CSS.
Hier sind einige Details zu den beiden Dokumenten.
| STÜRZT ab | STÜRZT NICHT ab | |
|---|---|---|
| Dokumentgröße (un-gezippt) | 131 KB | 123 KB |
| Dokumentgröße (gezippt) | 20,21 KB | 19,55 KB |
| Anzahl der Anfragen | 98 | 92 |
| Gesamtseitengröße | 1,42 MB | 1,40 MB |
Ein weiteres wichtiges Detail: Wenn Sie den Kommentarbereich auf einer der beiden Seiten ausblenden, stürzt diese nicht ab.
Das habe ich als Notlösung auf der Live-Seite implementiert. Es gibt eine Schaltfläche "Kommentare anzeigen", auf die Sie klicken können, um den Kommentar-Thread anzuzeigen. Wenn Sie auf dieser Seite darauf klicken, wird sie zum Absturz gebracht.
Nur weil Elemente versteckt sind, heißt das nicht, dass sie nicht im DOM vorhanden sind, daher können wir die DOM-Größe als Absturzfaktor ausschließen.
Alle sichtbaren Kommentare verbrauchen zwar mehr Speicher (wahrscheinlich viel) und erhöhen auch die Seitenhöhe extrem.
Eine weitere relevante Tatsache: Das Entfernen des CSS stoppt die Abstürze. Das CSS ist nur 37 KB un-gezippt und 7,32 KB gezippt. Es enthält jedoch einige CSS3-Funktionen wie Verläufe und Schatten.
Warum poste ich das?
Wissenschaft! Ich möchte, dass mehr Augen auf diese reduzierten Testfälle fallen, um zu sehen, ob wir sie noch weiter reduzieren und einige Ursachen dafür entdecken können. Es ist schon ein bisschen schade, dass man mit nur ziemlich einfachem HTML und CSS das mobile Webkit zum Absturz bringen kann. Vielleicht ist es etwas sehr Einfaches und wir können die Nachricht verbreiten. Und für meine eigenen Zwecke kann ich das verdammte Absturzproblem beheben, ohne auf etwas wie paginierte Kommentare zurückgreifen zu müssen, was ich wirklich vermeiden möchte.
Chris, nur zur Info, auf iOS 6 (Beta) Safari &/oder Chrome stürzt es beim Laden der Kommentare nicht ab.
Eine Sache ist jedoch erwähnenswert und es hat zu Verzerrungen geführt: Wenn der Name des Kommentators zu lang ist, stört das das Layout der Seite. Ich weiß nicht, ob das Probleme verursachen könnte, da es effektiv alles um einen einzelnen Kommentar zentrieren würde?
Bild: http://d.pr/i/NOLJ
{
word-wrap: break-word;
}
Zur Info: Es gibt Unterschiede zwischen den beiden Versionen. Laden Sie beide Seiten in Chrome und behalten Sie die Scrollleiste im Auge. Wechseln Sie zwischen den Tabs. Es gibt Inhalte in einer Version, die in der anderen nicht vorhanden sind, nach allem Anschein.
Ich würde weiter debuggen, aber das ist eine MENGE an Seite zum Scrollen, um den Unterschied zu erkennen.
Ja, das ist genau der Unterschied. In der Version, die nicht abstürzt, habe ich einen zusätzlichen Kommentar von der Seite entfernt.
Schneller mit WinMerge vergleichen – die Dateien sind identisch, bis auf die „yes-crash“-Datei, die einen zusätzlichen Codeblock zwischen den Zeilen 1359-1475 enthält. Das Problem liegt also höchstwahrscheinlich in diesen etwa 110 Zeilen.
Es beinhaltet auch die Verwendung von Gravataren, wie andyunleashed in einem späteren Beitrag erwähnt.
Das Erste, was ich versuchen würde, ist, den Kommentarbereich komplett zu entfernen und erneut zu testen, um zu sehen, ob er immer noch abstürzt. Ich wette, dort geht etwas Seltsames vor.
Er stürzt nicht ab, wenn Sie den Kommentarbereich entfernen. Das ist der Kern des Problems. Ein zusätzlicher kleiner Kommentar kann den Ausschlag geben zwischen kein Absturz und Absturz.
Es könnte sich lohnen, auch ein Zurücksetzen auf Werkseinstellungen und Neuladen deines iPhones zu versuchen. Ich habe vor ein paar Monaten ein Produkt im Beta-Test gehabt und es stürzte ohne Vorwarnung auf meinem iPad ab. Nach einiger Recherche habe ich festgestellt, dass mobiles Safari dies auch tat, aber das Zurücksetzen und Neuladen von Apps schien es zu beheben. Es hat vielleicht nicht alle Fälle behoben, aber meins schon.
Soweit wir feststellen konnten, hinterlässt das Installieren und Löschen von Apps ohne gelegentliches Zurücksetzen den Speicher fragmentiert (ähnlich wie früher Festplatten) und es kommt zu Abstürzen ohne ordnungsgemäße Beendigung und Schutzmaßnahmen.
Ich bin absolut offen für solche Lösungen, aber in diesem Fall war es nicht nur mein Telefon, sondern viele Leute berichteten über das Problem auf einer Vielzahl von Geräten.
Übrigens – Chris, wenn es Ihnen auf Ihrem iPhone passiert, gehen Sie zu Einstellungen > Info > Diagnostik & Nutzung (ganz unten) > Diagnostik- & Nutzungsdaten. Suchen Sie hier nach den Safari-Absturzberichten, sie sollten Details darüber enthalten, was genau die Ursache sein könnte.
Sehr interessant.
Dies scheint der relevante Absturzbericht zu sein: https://gist.github.com/3691938
Screenshot der Fehler: http://cl.ly/JLo2
„Jettisoned“ im Absturzbericht bedeutet, dass es von iOS beendet wurde – im Grunde, höchstwahrscheinlich, um Speicher freizugeben.
„Count“ ist die Anzahl der Speicherseiten, also in diesem Fall 12131 * 4 (KB) / 1024 = 47,38 MB Speicher wurden verwendet.
Warum es 47,38 MB Speicher zum Laden der Seite verwendet – das weiß ich nicht!
Ich habe gerade das hier gefunden, könnte relevant sein – http://stackoverflow.com/questions/11462691/rapidly-setting-image-srcs-with-dataurl-causes-memory-leak
Verwenden Sie Daten-URLs für Bilder, die in Kommentaren geladen werden?
Haben Sie versucht, Gravatar zu deaktivieren, nur um zu sehen, ob es einen Effekt hat?
Es funktioniert sowohl in Chrome 18 für Android als auch im Android-Standardbrowser (auf einem Galaxy Note, 4.0.4) einwandfrei.
Die Seite ist sehr lang, vielleicht zu viel für mobile Browsing-Standards, aber sie lädt einwandfrei.
(Nebenbemerkung: Der Text der Schaltfläche „Kommentar senden“ sieht auf Chrome 23 Dev unter Windows XP schrecklich aus.)
Hallo Chris,
Wenn ich raten müsste, würde ich @andyunleash zustimmen. Als ich zum ersten Mal von meinem iPhone 4S zum Redesign kam, hat es meinen Browser zum Absturz gebracht. Könnten Sie vielleicht versuchen, den Browser zum Absturz zu bringen, indem Sie Elemente zur funktionierenden Version hinzufügen (vorzugsweise nicht zum Kommentarbereich, da Sie diesen als Ursache des Problems isoliert haben). Wenn es sich um ein Speicherproblem handelt, wird die Erhöhung der Dokumentgröße es sicherlich zum Absturz bringen? Wenn die Erhöhung der DOM-Größe außerhalb des Kommentarbereichs den Browser nicht zum Absturz bringt, dann liegt Ihr Problem bei Ihren Kommentaren.
Könnte die Art und Weise, wie Sie Ihre Website cachen, mobile Browser beeinträchtigen? Ich weiß, dass sie diese Dinge anders behandeln.
Nur zur Notiz: Das Menü bricht auch unter Windows zusammen (mein Mac ist zu Hause) Safari 5.1.7 (schneidet die letzten beiden ab, wenn Sie verkleinern)
Ich weiß, dass dies mit diesem Problem überhaupt nichts zu tun hat, aber ich dachte, da Sie versuchen zu debuggen…
Stürzt auch Chrome 21 bei Fenster ziehen & Größenänderung auf meinem Windows 7 Rechner ab. Dachte nur, das könnte Sie interessieren.
Seltsam, ich konnte das auf meiner Win7-Kiste in Chrome 21 nicht reproduzieren?
Chrome 21.0.1180.89 m lässt den Tab hängen, ist aber schließbar, wenn die Größe schnell/gewaltsam geändert wird.
Ich mag es auch nicht wirklich, wie die gesamte Seite beim Ändern der Browserfenstergröße neu skaliert/zoomt.
Hallo Chris,
Auf mobilem Chrome auf meinem Samsung Galaxy S 2 stürzt die Seite nicht ab
Ich surfe auf der Website mit meinem iPhone 4s mit iOS5.1 und habe keine Probleme, derzeit sind noch 120 MB RAM frei
Ho! Auf meinem Nexus 7 mit Android Jelly Bean stürzt es mit Chrome nicht ab. Aber beim Tippen dieses Kommentars wird er – plötzlich – sehr sehr langsam! Vielleicht ist ein Skript schuld? Ich glaube, das ist die Kommentarvorschau.
Haben Sie versucht, Ihr CSS zu reduzieren, anstatt es vollständig zu entfernen? Entfernen Sie zum Beispiel zuerst Übergänge, dann Verläufe, dann Media Queries, dann die Hälfte des Stylesheets, dann wieder die Hälfte usw. Naja, das sollten Sie ja wissen. ;-)
Ich bemerke eine ziemlich deutliche Leistungssteigerung auf meinem 17-Zoll-MacBook Pro durch das Entfernen des Schatten auf .page-wrap::before, .page-wrap::after
Ich hatte ruckartiges Scrollen und verzögertes Tippen, das alles verschwindet, wenn man es entfernt.
Übermäßiger Gebrauch von Schatten ist dafür bekannt, Rendering-Probleme zu verursachen. Insbesondere wenn er mit Übergängen und Animationen verbunden ist.
Tatsächlich habe ich gerade das hier gefunden: cubiq, das besagt, dass Schatten Retina-Displays besonders schlechter beeinflussen.
Ohne die Seiten zu prüfen und ehrlich gesagt nur den Artikel zu überfliegen, wette ich 1 $, dass es sich um ein Problem mit Innenschatten handelt. Verwenden Sie irgendwo Innenschatten?
Auf meinem Windows Phone 7.5/IE9 stürzte es nicht ab. Aber der Kommentarbereich lädt etwas langsam. Beim Scrollen nach unten überlappen sich Anzeigenbits kurzzeitig mit den Kommentaren, für 1-2 Sekunden, bevor sie angepasst werden. Nach etwa 20-30 Sekunden hört dies auf (wenn alles in den Speicher geladen ist, vermute ich).
Unverbundene Beobachtung: Die Icon-Schriftart für die Navigation wird nicht geladen. Anstelle von Symbolen sehe ich große Buchstaben (fast oben und unten der Schaltflächen aufliegend) in Segoe UI Light, die Symbole sind: k, 9, Q, p, q, ó, w, 6. Auch gelegentlich springt das Tippen auf „Navigation & Suche“ direkt zu einem der Links (zweimal zur Galerie, einmal zu den Foren). Vielleicht habe ich unwissentlich doppelt getippt, kann es nicht zuverlässig reproduzieren.
Ich hatte ein ähnliches Problem mit dem iPad und langen Foren-Threads. Habe immer noch einige Probleme, aber nicht mehr so viele. Aber ich habe herausgefunden, dass das Einblenden eines einzelnen Buttons mit -webkit-transform die Seite zum Absturz brachte.
Weiß immer noch nicht, warum das den Browser nur zum Absturz bringen würde, wenn ich über 100 Kommentare hatte.
Wenn es eine Lösung gibt, wäre es schön, diese auf Twitter zu teilen oder einen neuen Blogbeitrag zu schreiben.
Die Seite funktioniert auf meinem iPhone 4S (Safari) einwandfrei, und ich habe auch iOS Chrome ausprobiert, und es funktioniert dort auch großartig!
Hast du mit backface-visibility herumgespielt?
Hab gerade den Artikel gelesen & befolgt :)
Meine mobilen Safaris (iPhone 4s/iPad3 neuestes iOS) stürzen heute auch ab, mit einer langen Seite, die auf einem Element border-radius hatte. Nachdem ich diese eine CSS-Definition entfernt habe, funktioniert alles perfekt.
Ich poste dies von meinem iPhone 4 mit iOS 6, das einzige Problem ist, dass einer der Kommentatoren seine E-Mail-Adresse als Namen hat, sie ist so lang, dass die Hauptspalte nur etwa 2/3 der Breite einnimmt, das rechteste 1/3 ist dunkelgrau.