Vorwort:
Als ich kürzlich an einem Projekt im Unternehmen arbeitete, gab es ein Geschäftsszenario, bei dem dasselbe Bild an verschiedenen Standorten inkonsistente Ergebnisse zeigte. Tatsächlich ist es sehr einfach zu verstehen. Was den bekannten WeChat-Avatar betrifft, den wir verwenden Normalerweise wird in diesem Fall davon ausgegangen, dass die Größe eines WeChat-Avatars im Format 80 * 80 liegt, und das Format des Avatar-Bildes, das angezeigt wird, wenn wir auf den Avatar klicken, muss größer als 80 * 80 sein. Dann gibt es das Es besteht die Notwendigkeit, dasselbe Bild in verschiedenen Spezifikationen zu rendern. Wir haben das Bild zunächst direkt an das Front-End geworfen und es vom Front-End verarbeiten und rendern lassen. Dies führte jedoch zu einem sehr beängstigenden Phänomen: Jedes Mal, wenn die Seite leer war Beim Rendern musste das Frontend jedes Bild verarbeiten, was verwirrend ist, egal wie man es betrachtet. Unvernünftig! Was also tun?
Verwechseln:
Nach einigem Stöbern habe ich eine Verarbeitungsbibliothek für Bilder gefunden – Thumbnailator , mit der man Bildern Wasserzeichen hinzufügen oder eine bestimmte Größe festlegen oder komprimieren und zoomen kann usw. Nun, für mein Unternehmen ist diese Art der Bildverarbeitung erforderlich, aber Derzeit überlassen wir die Verarbeitung dieser Sache dem Front-End. Wenn ich also das Bild verarbeite, bevor ich es an das Front-End übertrage, wird es dann während des Übertragungsprozesses verarbeitet? Seine Effizienz optimieren? Das heißt, für die Bildverarbeitung verwenden wir derzeit das Front-End und das Back-End verarbeitet das Bild nicht. Dann denke ich, wenn ich das Bild bereits im Back-End verarbeitet habe, kann ich es übertragen in einem kleineren Volumen. zum vorderen Ende. Wäre es effizienter, direkt zu rendern? Andernfalls wird das Volumen definitiv größer, wenn es nicht verarbeitet wird, und es wird während des Übertragungsprozesses mehr Ressourcen beanspruchen. Da sie alle auf diese Weise verarbeitet werden, bedeutet dies, dass dies möglich ist, wenn ich sie im Back-End verarbeite meine Übertragung reibungsloser machen? Aber. Ich denke, die Dinge sind nicht so ideal, wie ich es mir vorgestellt habe, aber ich kann mir nicht vorstellen, dass dies schaden könnte.
Zur Bildverarbeitungsbibliothek können interessierte Partner den folgenden Artikel lesen:
Bildverarbeitungsbibliothek – Thumbnailator_Apprentice 630's Blog-CSDN-Blog
Zweifelspunkt 1: Wie lassen sich die Geschäftsanforderungen sinnvoll umsetzen, wenn das gleiche Bild an verschiedenen Positionen mit inkonsistenten Effekten angezeigt wird?
Zweifelspunkt 2: Wann wird das Frontend für Verarbeitungsvorgänge und wann das Backend für Verarbeitungsvorgänge benötigt?
Daniels Antwort:
Ich habe mit dem technischen Direktor gesprochen und festgestellt, dass es einen vernünftigeren Weg zu geben scheint, mit dieser Art von Nachfrage umzugehen.
Antwort auf Zweifelspunkt 1:
Tatsächlich hat er Bilder nach dem Hochladen bereits verarbeitet und dann gespeichert. Ich habe beispielsweise ein Bild hochgeladen, und dann wird dieses Bild an zwei Stellen verwendet, und diese beiden Stellen haben unterschiedliche Größen, was bedeutet, dass dies der Fall ist Seine Größe ändert sich. Wenn ich ein Bild wie dieses hochlade, erhalte ich es im Backend, und ich habe die beiden Bilder in zwei Formate zugeschnitten und diese beiden Bilder dann in zwei Formate gebracht. Das gleiche Bild in zwei verschiedenen Formaten Verwendet eine mit dem Frontend vereinbarte Namenskonvention, z. B. A1 und A2. Das heißt, nachdem ich das Bild im Frontend hochgeladen habe, habe ich es bereits in das endgültige Format geändert, das im Backend gerendert werden soll. , wenn Das Front-End möchte am Ende ein Bild erhalten, es kann das Bild einfach über eine URL abrufen und direkt rendern, ohne dass eine sekundäre Verarbeitung erforderlich ist. Am Ende erreichte er mit dieser Lösung ein Bild für Bild Methode : Es muss beim Hochladen und Speichern nur einmal verarbeitet werden, und dann ist keine sekundäre Verarbeitung erforderlich.
Nehmen Sie als Beispiel unseren WeChat-Avatar. Ist der WeChat-Avatar nicht ein sehr kleines Miniaturbild? Wenn wir dann darauf klicken, können wir es vergrößern, oder? Dann dachte ich ursprünglich, dass er dasselbe Bild verwendet, aber das Frontend hat einen Komprimierungsprozess durchgeführt, sodass es durch sekundäre Verarbeitung gerendert wird. , aber in Tatsächlich sind es nur zwei Bilder, ein großes und ein kleines. Wenn wir es dann normal anzeigen, greift das Frontend auf das kleine Bild zu. Wenn wir zum Vergrößern klicken möchten, ändert das Frontend direkt eine URL, um das große Bild zu erhalten. Bild von
Dann verwenden wir für diese Art von Bildern mit unterschiedlichen Spezifikationen eine reguläre Benennungsmethode für ähnliche Typen , und dann muss das Frontend nur die geänderte Pfadposition übernehmen und sie als Variable verwenden. Wenn ich auf etwas zugreifen möchte. Wenn ja, dann ich Ich muss nur die Variable bearbeiten und meine URL nicht direkt ändern, da es sich bei der Änderung nur um eine kleine Positionsänderung und nicht um eine Änderung der gesamten URL handelt.
Antwort auf Zweifelspunkt 2:
Bei dieser Art von Bildern wird das Back-End im Wesentlichen zum Komprimieren, Hinzufügen von Wasserzeichen usw. verwendet, und das Front-End führt nur einige grundlegende Überprüfungen durch , z. B. die Größe des Bildes und sein Format als JPG- oder PNG-Verifizierung. Eine andere Möglichkeit wäre zum Beispiel: Sind einige unserer APP-Avatare nicht rund? Was wir dann hochladen, ist ein quadratisches Bild. Müssen wir es also manuell auswählen und zuschneiden ? Das erledigt das Frontend. Dann diese Miniaturansichten und etwas Komprimierung in dieser Größe, das machen wir mit dem Backend.
Kernpunkt: Schauen Sie sich die Bedürfnisse an und optimieren Sie nicht blind
Die obige Lösung scheint in Ordnung zu sein, aber keine Lösung ist perfekt. Es gibt keine beste Lösung, nur die am besten geeignete Lösung!
Die oben genannten Lösungen basieren hauptsächlich auf dem Back-End, um einige Bildgeschäftsoptimierungsvorgänge zu implementieren. Tatsächlich gibt es viele Front-End-Lösungen, die optimiert werden können, wie zum Beispiel:
Rendering von Seitensymbolen – Sprite-Map. Ein Bild enthält alle Symbole. Das Frontend muss nur die Position des Symbols lokalisieren und anzeigen. Auf diese Weise kann die Anzahl der Netzwerk-IOs reduziert werden.
Für das Rendern von Ressourcen – Lazy Loading und Pre-Rendering
Lazy Loading – bezieht sich auf das Laden nur der Bilder im sichtbaren Bereich, wenn die Seite geladen wird, während das Laden von Bildern in anderen Bereichen verzögert wird. Das Prinzip besteht darin, Scroll-Ereignisse abzuhören oder die relative Position des Bildes und des sichtbaren Bereichs zu berechnen und das Bild dann zu laden, wenn es in den sichtbaren Bereich eintritt. Lazy Loading kann Netzwerkanfragen und den Ressourcenverbrauch beim ersten Seitenladen reduzieren und so die Seitenladegeschwindigkeit und das Benutzererlebnis verbessern.
Pre-Rendering – bezieht sich auf das Laden von Bildressourcen, die vom Benutzer beim Laden der Seite nicht im Voraus angefordert wurden. Das Prinzip besteht darin, dass nach dem Laden der Seite
<link rel="preload">die zu verwendenden Bildressourcen durch asynchrone Anforderungen oder dynamisch erstellte Tags vorgeladen werden. Durch das Vorrendern kann die Wartezeit des Benutzers beim Surfen verkürzt und die Ladegeschwindigkeit von Bildern sowie das Benutzererlebnis verbessert werden.
Wir können möglicherweise eine erforderliche Funktion implementieren, genau wie einen fliegenden Vogel, wir können ihn fliegen lassen, aber was wir verfolgen, sollte sein, ihn freier und einfacher fliegen zu lassen!