Bis vor kurzem hatte Dropbox eine technische Strategie zur Verwendung von allgemeinem C ++ - Code für mobile iOS- und Android-Anwendungen. Die Idee ist klar: Schreiben Sie Code einmal in C ++, anstatt ihn separat in Java und Objective C zu duplizieren. Wir haben diese Strategie bereits 2013 übernommen, als die Gruppe der Ingenieure für mobile Entwicklung relativ klein war und das Produkt schnell entwickeln musste. Mit einer solchen Lösung konnte die Kraft eines kleinen Teams sowohl auf Android als auch auf iOS eine große Menge Code erzeugen.

Jetzt haben wir diese Strategie zugunsten der Muttersprachen jeder Plattform (hauptsächlich Swift und Kotlin, die zu Beginn nicht existierten) vollständig aufgegeben. Die Lösung beinhaltet die (nicht so) versteckten Kosten für die gemeinsame Nutzung von Code.

Alle Probleme ergeben sich aus der Hauptsache : Der Overhead war mehr als nur das zweimalige Schreiben des Codes .

Bevor ich die verschiedenen Arten von Overhead analysiere, möchte ich klarstellen, dass wir nie an den Punkt gekommen sind, an dem sich der größte Teil der Codebasis in C ++ befand. Die Kosten haben uns tatsächlich daran gehindert, uns in diese Richtung zu bewegen.

Es ist auch erwähnenswert, dass viel größere Unternehmen wie Google und Facebook seit mehreren Jahren skalierbare Code-Sharing-Lösungen entwickeln. Solche Lösungen sind nicht sehr verbreitet. Obwohl Systeme von Drittanbietern wie React Native oder Flutter einen Teil des Overheads vermeiden, bleiben einige Kosten bestehen (zumindest bis eine dieser Technologien populär und ausgereift genug wird). Zum Beispiel lehnte Airbnb die Verwendung von React Native aus den gleichen Gründen ab, die in diesem Artikel beschrieben werden.

Alle Kosten können in vier Hauptkategorien eingeteilt werden.

Overhead von benutzerdefinierten Frameworks und Bibliotheken

Der einfachste Weg, die Kosten für die Erstellung von Frameworks und Bibliotheken vorherzusagen. Sie sind grob in zwei Unterkategorien unterteilt:

• Frameworks, mit denen Sie mit der Hostumgebung interagieren können, um eine vollwertige mobile Anwendung zu erstellen. Zum Beispiel:
  
  • Djinni , ein Tool zum Erstellen von mehrsprachigen Deklarationen von Verbindungstypen und Schnittstellen
    
  • Ein Framework zum Ausführen von Aufgaben im Hintergrund vor dem Hauptthread (trivial in den Muttersprachen der Plattform)
  
  
• Bibliotheken als Ersatz für Sprachstandards oder Open Source-Lösungen, die in Muttersprachen verwendet werden können, zum Beispiel:
  
  • json11 für die ( De- ) Serialisierung von JSON
    
  • nn Nicht-Null-Zeiger für C ++

Nichts davon ist erforderlich, wenn Sie in den Muttersprachen der Plattform bleiben. Und unsere Teilnahme an Open Source-Projekten in Muttersprachen wäre für Entwickler wahrscheinlich vorteilhafter. In der C ++ - Community war (und ist es?) Die Open Source-Kultur nicht so entwickelt wie in der Community für mobile Entwickler, zumal die mobile C ++ - Community praktisch nicht existiert.

Bitte beachten Sie, dass dieser Overhead für C ++ besonders hoch ist (im Gegensatz zu anderen möglichen nicht-muttersprachlichen Sprachen wie Python oder C #), da es keine voll funktionsfähige Standardbibliothek gibt. Da jedoch nur C / C ++ einen Compiler hat, der sowohl von Google als auch von Apple unterstützt wird, verursacht der Wechsel zu einer anderen Sprache eine Reihe anderer Probleme.

Übergroße benutzerdefinierte Entwicklungsumgebung

Im mobilen Ökosystem gibt es viele Tools zur Verbesserung der Entwicklungseffizienz. Mobile IDEs sind sehr funktional und Google und Apple haben viele Ressourcen investiert, um sie ideal für ihre Plattformen zu machen. Wenn wir uns von den Standardeinstellungen entfernen, geben wir einige Vorteile auf. Erstens übertrifft das Debuggen in der Muttersprache normalerweise das C ++ - Debugging in der IDE standardmäßig.

Ich erinnere mich besonders an einen Fehler, der zu einer Blockierung der Hintergrund-Streaming-Struktur führte und zu versehentlichen Abstürzen der Anwendung führte. Solche Fehler sind selbst mit einem einfachen Standardstapel schwer zu verfolgen. Da das Problem das Debuggen von Multithread-Code zwischen C ++ und Java beinhaltete, dauerte die Verfolgung Wochen!

Zusätzlich zum Verlust der Standardtools musste ich Zeit in die Erstellung eigener Tools investieren, um gängigen C ++ - Code zu unterstützen. Am wichtigsten war, dass ein benutzerdefiniertes Build-System erforderlich war, um Bibliotheken zu erstellen, die C ++ - Code sowie Java- und Objective-C-Shells enthielten. Es sollte Ziele generieren, die sowohl Xcodebuild als auch Gradle verstehen. Das Erstellen eines solchen Systems hat uns viele Ressourcen gekostet, da es ständig aktualisiert werden musste, um Änderungen in den beiden Build-Systemen zu unterstützen.

Plattformüberschreibung für Plattformunterschiede

Obwohl iOS und Android „mobile Anwendungen“ sind, die normalerweise dieselben Funktionen bieten, gibt es einige Unterschiede bei den Plattformen selbst, die sich auf die Implementierung auswirken. Zum Beispiel, wie eine Anwendung Hintergrundaufgaben ausführt. Sogar ähnliche Dinge können sich im Laufe der Zeit stark unterscheiden (z. B. Interaktion mit der Kamera).

Daher können Sie Code nicht nur einmal schreiben und auf einer anderen Plattform ausführen. Sie müssen viel Zeit für die Integration und Codierung einer bestimmten Plattform aufwenden, und manchmal endet dieser Code direkt auf C ++ - Ebene!

Theoretische Einsparungen durch das nur einmalige Schreiben von Code entsprechen nicht der Realität, was die Effektivität dieses Ansatzes sofort erheblich verringert.

Gemeinkosten für die Einstellung, Schulung und Bindung von Entwicklern

Last but not least sind die Kosten für die Schulung und / oder Einstellung von Entwicklern für die Arbeit mit unserem sehr eigenartigen Stack. Als Dropbox diese mobile Strategie einsetzte, hatten wir eine Kerngruppe erfahrener C ++ - Entwickler. Diese Gruppe startete das C ++ - Projekt und schulte andere mobile Entwickler.

Im Laufe der Zeit gingen diese Entwickler zu anderen Teams und anderen Unternehmen. Der Rest hatte nicht genug Erfahrung, um die Lücke in der technischen Führung zu schließen, und es wurde zunehmend schwieriger, erfahrene Ingenieure mit der entsprechenden C ++ - Erfahrung zu finden, die an der Entwicklung für mobile Geräte interessiert sind.

Infolgedessen waren wir mit einem echten Mangel an kritischem Wissen zur Aufrechterhaltung der C ++ - Codebasis konfrontiert. Es blieben nur zwei Optionen übrig, die jeweils erhebliche Anstrengungen erforderten:

1. Finden und stellen Sie Kandidaten mit ganz bestimmten Fähigkeiten ein (wir haben es ein Jahr lang erfolglos versucht).
   
2. Trainieren Sie Ihre eigenen mobilen (oder C ++) Entwickler, was ohne Senioren mit den richtigen Fähigkeiten für den Abschluss des Trainings fast unmöglich ist. Selbst wenn sich die Hauptgruppe noch nicht aufgelöst hatte, waren mobile Entwickler normalerweise nicht an C ++ interessiert, daher war es auch ein großes Problem, Leute zum Lernen zu finden.

Zusätzlich zur Einstellung verursachte die Veröffentlichung eines eigenen Technologie-Stacks ein Problem bei der Aufbewahrung - mobile Entwickler wollten einfach nicht an einem C ++ - Projekt arbeiten. Dies führte dazu, dass viele talentierte Ingenieure das Projekt verließen, anstatt weiterhin unter einem schlecht gewarteten benutzerdefinierten Stapel zu leiden. Im Allgemeinen ist die Community der mobilen Entwickler sehr dynamisch - neue Technologien und Modelle erscheinen häufig und werden schnell implementiert. Top-Ingenieure lieben es, ihre Fähigkeiten auf dem neuesten Stand zu halten.

Ein ausgereiftes Produkt mit einem Standardstapel ist nicht einfach auf dem neuesten Stand zu halten. Sie opfern Neuheit für Stabilität. Dieses Problem nimmt erheblich zu, wenn Sie sich in einem benutzerdefinierten Stapel außerhalb des breiteren mobilen Ökosystems einschließen.

Fazit

Einmal schien das einmalige Schreiben von Code für verschiedene Plattformen sehr viel zu sein, aber die damit verbundenen Kosten überwogen die Vorteile (die auf jeden Fall geringer waren als erwartet). Am Ende verwenden wir keine gemeinsame Codebasis mehr über C ++ (oder eine andere nicht standardmäßige Methode), sondern schreiben Code in unseren Muttersprachen für jede Plattform.

Darüber hinaus möchten wir, dass sich unsere Ingenieure wohl fühlen und einen Beitrag zur Gemeinschaft leisten können. Aus diesem Grund haben wir uns entschlossen, unsere Praxis an die Industriestandards anzupassen.