Überblick über plattformübergreifende mobile Entwicklungsframeworks

Einführung


Bei der Arbeit musste ich mich wiederholt mit der Auswahl geeigneter Technologien für die mobile Entwicklung befassen. Im Folgenden habe ich versucht, die wichtigsten Frameworks nach den verwendeten Ansätzen, Vor- und Nachteilen zu sammeln und zu klassifizieren.


Wenn einige meiner Informationen falsch oder veraltet sind, sind Kommentare willkommen.


Häufige Nachteile der plattformübergreifenden Entwicklung


Eingeschränkte Plattformunterstützung


Jedes plattformübergreifende Framework ist eine Abstraktionsschicht über der nativen Plattform und ermöglicht den Zugriff auf nur die Funktionen, die direkt vom Framework unterstützt werden.


In den meisten Fällen ist es möglich, die Unterstützung für die Plattform zu erweitern, indem native Plugins für das Framework geschrieben werden. In einigen Fällen kann dies jedoch die Entwicklung erheblich erschweren. Ein neues Beispiel aus dem sensationellen AirBnb-Artikel ist React Native, das derzeit nicht weiß, wie es mit 64-Bit-Android-Bibliotheken sofort funktioniert.


Sie müssen auch darauf achten, dass native Plugins und der Hauptcode einer plattformübergreifenden Anwendung in der Regel in unterschiedlichen Prozessen ausgeführt werden und die Interaktion zwischen ihnen Leistungsprobleme verursachen kann. Für die Arbeit mit Sensoren oder SQLite ist dies normalerweise kein Problem. Wenn Sie jedoch beispielsweise die OpenCV-Bibliothek als natives Plugin verwenden und ein Video zwischen sie und die Hauptanwendung werfen, kann die Verlangsamung erheblich sein.


Begrenztes Angebot auf dem Arbeitsmarkt


Erstens hängt die Anwesenheit von Entwicklern von der Verbreitung des Frameworks ab. Das Finden von Personen unter React Native kann noch einfacher sein als bei nativen Entwicklern, aber zum Beispiel ist es mit Flutter viel schwieriger.


Wie viel dieser Faktor berücksichtigt werden muss, hängt von den Aufgaben ab. Die meisten Startups achten möglicherweise nicht darauf, da das Erlernen einer neuen Technologie eher ein Bonus für bestehende und potenzielle Mitarbeiter ist. Auf der anderen Seite ist das Großunternehmen gezwungen, den Arbeitsmarkt zu berücksichtigen.


Risiken unterstützen


Es wird angenommen, dass die Wahrscheinlichkeit, dass die Unterstützung für das plattformübergreifende Framework endet, viel höher ist als die Wahrscheinlichkeit desselben Ereignisses in Bezug auf das mobile Betriebssystem.


In der Tat ist die Frage ziemlich kompliziert. Das Betriebssystem kann genau wie Frameworks geschlossen werden (das Beispiel von Windows Phone ist völlig neu). Darüber hinaus können innerhalb der nativen Entwicklung auch bestimmte Technologien geschlossen werden, und manchmal ist der Code auf plattformübergreifenden Frameworks überlebensfähiger.


Ein Beispiel hierfür ist der Bereich Spiele und Multimedia: Apple wird die OpenGL-Technologie an sein Betriebssystem senden, und jeder, der native 3D-Anwendungen geschrieben hat, muss diese vollständig neu schreiben, um neue Versionen zu veröffentlichen. Gleichzeitig erfordert die Aktualisierung für diejenigen, die plattformübergreifende Spiel-Engines (z. B. Unity) verwendet haben, keinen zusätzlichen Aufwand.


Die Hauptrichtungen


Hybride Entwicklung, HTML + JavaScript


Technisch gesehen sind Hybridanwendungen HTML-Seiten, die in einem eingebetteten Browser angezeigt werden. Im Allgemeinen ist das Framework für diesen Ansatz nicht erforderlich, aber Cordova bietet eine Reihe von Plugins für den Zugriff auf die Plattformfunktionen, weshalb diese normalerweise verwendet werden.


Hauptvorteile


Minimale Entwicklungskosten


Mit dem hybriden Ansatz können Sie nicht nur die Fähigkeiten von Entwicklern, sondern auch den für Websites geschriebenen Code wiederverwenden.


Möglichkeit zur Integration von Webelementen


Die Anzahl der Bibliotheken für HTML / JS übersteigt die Anzahl der Bibliotheken für native Anwendungen erheblich. Interessant sind beispielsweise Google Analytics oder eine große Auswahl an Werbenetzwerken.


Wichtige Nachteile


Geringe Produktivität


Modernes JavaScript selbst verwendet die JIT-Kompilierung, ist gut optimiert und funktioniert schnell, aber das Erstellen einer Schnittstelle basierend auf dem DOM-Baum ist kein sehr effizienter Prozess. Die Verwendung moderner JS-Frameworks bietet eine zusätzliche Laststufe. Bei schwachen Telefonen und / oder bei aktiver Verwendung interaktiver Elemente kann dies ein Problem sein.


"Einheimisches Gefühl"


Dies ist ein eher informeller, aber sehr wichtiger Punkt. Die Site im Browser reagiert auf Gesten und wird etwas anders angezeigt als eine mobile Anwendung. Das auffälligste Element dieses Gefühls, eine Verzögerung von 300 ms beim Drücken, entscheidet Cordova, aber viele andere Details bleiben erhalten.


Problem mit der Browserkompatibilität


In älteren Android-Versionen (vor Version 5) war WebView Teil der Plattform und wurde nicht automatisch aktualisiert. Dementsprechend wird es nicht möglich sein, moderne Browserfunktionen in Hybridanwendungen auf diesen Geräten zu verwenden.


Infolgedessen begrenzen Hybridanwendungen entweder die Mindestversion von Android (wobei derzeit etwa 13% der Geräte zurückbleiben) oder nehmen WebView in den Anwendungscode auf (CrossWalk-Projekt), wodurch die Anwendungsgröße um mehrere zehn Megabyte erhöht wird.


Ziel


Erstellen Sie schnell einmalige Apps. Wenn es ein beträchtliches Entwicklungsbudget gibt, wird ein hybrider Ansatz normalerweise verachtet.


Grundlegende Frameworks


Der Kern aller wichtigen Hybrid-Frameworks ist Cordova, das Zugriff auf native Plugins bietet. PhoneGap bietet Tools zum Aufbauen auf Cordova, während Ionic ein Framework und eine Reihe von Komponenten zum Erstellen von Benutzeroberflächen ist.


Native Benutzeroberfläche, allgemeiner Code


Es ist wichtig zu beachten, dass bei diesem Ansatz die Benutzeroberfläche und die Geschäftslogik in verschiedenen Prozessen ausgeführt werden, die über eine Brücke interagieren. Damit sind eine Reihe von Nachteilen des Ansatzes verbunden.


Dieser Ansatz bietet mehrere Implementierungsoptionen.


Klassifizierung des ausführbaren Codes


Kompilierter Code


Xamarin verwendet die C # -Sprache und kompiliert sie in nativen Plattformcode. Im Allgemeinen bietet dieser Ansatz eine relativ kleine Anwendungsgröße und eine ziemlich hohe Geschwindigkeit.


Interpretierte Sprache mit JIT-Kompilierung


Die meisten Frameworks in diesem Ansatz verwenden JavaScript zur Verarbeitung der Geschäftslogik.


Klassifizierung nach Schnittstellenbeschreibungsmethode


Native Tools


Xamarin verwendet nicht nur native Schnittstellenkomponenten, sondern beschreibt sie auch in dem für jede Plattform akzeptierten Format.


Universelle Schnittstellenelemente


Xamarin Forms und Appcelerator verwenden ihre eigenen Widgets, die in die entsprechenden Schnittstellenkomponenten jeder Plattform konvertiert werden.


Unterschiedliche Schnittstelle für unterschiedliche Plattformen, aber ein gemeinsamer Ansatz


React Native verwendet Wrapper um native Schnittstellenkomponenten. Dementsprechend wird die Schnittstelle für jede Plattform separat beschrieben, die Beschreibungsmethode ist jedoch dieselbe.


Hauptvorteile


Vollständig native Schnittstelle


Erstens stimmen das Erscheinungsbild und das „Gefühl“ der Anwendung vollständig mit den nativen Anwendungen überein.


Zweitens können native Schnittstellenbibliotheken in Anwendungen verwendet werden. Die Verwendung nativer Anzeigen (Native Ads), die sich auf mobile Anwendungen konzentrieren, funktioniert in anderen Ansätzen nicht. Für diesen Ansatz ist der Satz relevanter Bibliotheken zwar sehr begrenzt. Ich weiß nur über die Unterstützung von Facebook Native Ads in React Native Bescheid.


Fähigkeit, Entwicklerfähigkeiten wiederzuverwenden


Viele Frameworks dieser Gruppe sind so konzipiert, dass Entwickler aus anderen Bereichen lernen können, wie mobile Anwendungen mit minimalen Kosten erstellt werden. Für React ist Native React, für Xamarin, .NET usw.


Wichtige Nachteile


Einschränkung der Schnittstellenfunktionen oder zusätzliche Kosten für die separate Entwicklung


Das Format dieses Minus hängt von der Klassifizierung des Frameworks gemäß der Beschreibung der Schnittstelle ab:


Mit Xamarin können Sie fast alle Funktionen der Plattformen nutzen, müssen jedoch viel Zeit für die Schnittstellen der einzelnen Plattformen aufwenden. Infolgedessen sind die Arbeitskosten nicht viel geringer als bei der einheimischen Entwicklung.


Mit Xamarin Forms und Appcelerator können Sie Schnittstellen nur einmal beschreiben, sie arbeiten jedoch mit einer sehr begrenzten Teilmenge nativer Funktionen (nicht mehr als der minimale Schnittpunkt der Funktionssätze jeder Plattform, um formal zu sein).


React Native befindet sich in der Mitte und kombiniert beide Mängel, jedoch in einer weniger ausgeprägten Form.
Interaktionsleistung der Schnittstelle
Hier kommt der Faktor der Ausführung von Schnittstellen und Geschäftslogik in verschiedenen Prozessen ins Spiel. Wenn es notwendig ist, große Informationsmengen mit hoher Geschwindigkeit über eine Brücke auszutauschen (komplexe Animation mit hoher Frequenz), können bei diesem Ansatz Schwierigkeiten auftreten.


Speicherlecks


Speicherverluste können in jeder Anwendung auftreten, aber die meisten Standardsituationen werden von Garbage Collectors behandelt.


Das Problem bei plattformübergreifenden Anwendungen mit einer nativen Schnittstelle besteht wiederum darin, dass sie in zwei Prozessen mit separaten Garbage Collectors ausgeführt werden. Wenn sich das Geschäftslogikobjekt auf ein Schnittstellenobjekt bezieht, ist dieses Schnittstellenobjekt kein Müll, weil Von der Brücke gibt es einen Link dazu. Wenn das Schnittstellenobjekt auf das Geschäftslogikobjekt verweist, werden sie auch dann nicht als Müll betrachtet, wenn keine Verweise mehr auf sie vorhanden sind.


Die Wahrscheinlichkeit, auf ein Problem zu stoßen, und sein Ausmaß hängen direkt von der Anwendung ab. Wenn Objekte, die der Schnittstelle zugeordnet sind, aktiv darin erstellt und gelöscht werden (wie beim endlosen Scrollen), steigt die Wahrscheinlichkeit eines Lecks. Wenn diese Objekte groß sind (z. B. Bilder), nimmt der Effekt der Leckage zu.


Tatsächlich tritt dieses Problem auch bei der Arbeit mit nativen Plugins auf, die ebenfalls in einem separaten Prozess ausgeführt werden. In den meisten Fällen findet jedoch entweder keine derart intensive Manipulation großer Objekte statt, oder die Interaktion erfolgt in einem streng prozeduralen Ansatz ohne Querverweise.


Ziel


Anwendungen mit einer vollständig nativen Schnittstelle, insbesondere wenn es Spezialisten für verwandte Technologien gibt.


Grundlegende Frameworks


Native reagieren


Es hat Facebook-Unterstützung und verwendet den Ansatz des beliebtesten React JS-Frameworks, aufgrund dessen es sehr beliebt ist. Ein kürzlich veröffentlichter Artikel über die Aufgabe von React Native durch AirBnb hat viel Lärm gemacht, aber wenn man sich der Risiken bewusst ist, kann dies eine sehr effektive Lösung sein.


Xamarin


Zusätzlich zum Hauptansatz verfügt es über die Xamarin.Forms-Bibliothek, mit der Sie einfache Schnittstellen effizient und plattformübergreifend entwerfen können. Wird von Microsoft aktiv unterstützt. Wenn Sie mit ASP.NET auf dem Server arbeiten, können Sie durch die Verwendung gängiger Geschäftslogikklassen auf dem Server und in der mobilen Anwendung zusätzlich einen bestimmten Arbeitsaufwand sparen.


Nativecript


Es basiert auf React Native für Entwickler, die andere JS-Frameworks (Angular und Vue.js) besitzen. Weniger beliebt, hat aber eine Reihe moderner Lösungen in der Architektur.


Native Benutzeroberfläche, allgemeiner Code


Fast alle Spiele-Engines verwenden diesen Ansatz, aber sie gehen über den Rahmen dieses Artikels hinaus.


Das Prinzip dieses Ansatzes besteht darin, dass die Anwendung ihren eigenen Code und ihr eigenes Rendering der Benutzeroberfläche verwendet.


Hauptvorteile


Hochleistungsschnittstellen


Tatsächlich führt eine Anwendung, die ihre eigene Schnittstelle selbst zeichnet, dieselben Vorgänge aus wie das Betriebssystem in der nativen Schnittstelle. Theoretisch kann es sogar noch schneller gehen, weil Es gibt kein Umschalten zwischen dem Prozess und dem Kernel, aber in der Praxis spielen andere Faktoren, die die Rendergeschwindigkeit einer bestimmten Schnittstelle beeinflussen, eine viel größere Rolle.


"Design-Schnittstellen"


Native Anwendungen verwenden vorgefertigte Schnittstellenkomponenten und haben einige Einschränkungen, was mit ihnen gemacht werden kann. Anwendungen, die ihre eigene Oberfläche selbst zeichnen, unterliegen keinen solchen Einschränkungen und können vorgefertigte Elemente mit individuellem Rendering frei mischen.


Wichtige Nachteile


Diese Nachteile sind nur für Anwendungen relevant, die die Standard-Betriebssystemschnittstelle imitieren. Wie bereits erwähnt, ist dieser Ansatz für Designschnittstellen und Spiele optimal.


Anwendungsgröße


Anwendungen mit diesem Ansatz müssen Code zum Rendern aller Schnittstellenelemente enthalten, einschließlich der bedingt standardmäßigen. Dies wirkt sich sowohl auf die Größe der Anwendung während der Installation als auch auf den Arbeitsspeicher während des Betriebs aus.


Wenn das erste Problem durch effektives Tree Shaking minimiert werden kann (wie es die neuesten Versionen von Flutter tun), verlieren diese Anwendungen ihren nativen Speicher durch RAM stabil. Dieses Problem ist jedoch auch für andere plattformübergreifende Frameworks charakteristisch.


Native Schnittstelle


Standardmäßig sieht die Anwendung auf allen Plattformen gleich aus, was für Benutzer unangenehm sein kann. Themen werden verwendet, um diese Probleme zu lösen, können jedoch nicht das Gefühl einer vollständig nativen Anwendung erzeugen.


Es gibt jedoch ein größeres Minus: Bei diesem Ansatz ist es am schwierigsten, Schnittstellenelemente von Drittanbietern zu verwenden, die für native Anwendungen (einschließlich der zuvor erwähnten nativen Anzeigen) erstellt wurden.


Ziel


Öffentliche Anwendungen, insbesondere mit einer Designschnittstelle.


Grundlegende Frameworks


Flattern


Flutter wird von Google als zentrales plattformübergreifendes Entwicklungsframework und Schnittstelle für das zukünftige Fuscia-Betriebssystem beworben. Das Framework ist zwar sehr jung (in der Release Preview-Phase) und nicht sehr verbreitet, gewinnt jedoch schnell an Popularität. Verwendet die Dart-Sprache (mit Kompilierung in nativen Code).


Es hat alle Vor- und Nachteile der Jugend - eine durchdachte Architektur, die die Fehler seiner Vorgänger berücksichtigt, aber ein eher begrenztes Ökosystem.


QT Mobile


Es ist beliebt bei Entwicklern von Desktop-QT. In der Entwicklung kann JavaScript verwendet werden. Ohne die Unterstützung großer Unternehmen ist nicht sehr beliebt.


Kivy


Ein weiteres nicht sehr beliebtes Framework, das interessant ist, vor allem, weil es das einzige Framework auf der Liste ist, das Python verwendet. Für Entwickler, die nur mit dieser Sprache vertraut sind (und in einigen Bereichen der Informationstechnologie gibt es viele), kann dies von entscheidender Bedeutung sein.


Verwandte Materialien


Zum Speicher in Xamarin und ähnlichen Frameworks
Vergleich der Leistung nativer Anwendungen, Flutter und React Native

Source: https://habr.com/ru/post/de421227/


All Articles