Expo Bildauswahl: Eine umfassende Anleitung für 2026

Sie sind wahrscheinlich an dem Punkt, an dem die Benutzeroberfläche fertig ist, der Profilbildschirm hat einen „Bild hochladen“-Button und jetzt ist das Leichtgewicht plötzlich nicht mehr leicht. Die tatsächliche Bildauswahl-Fluss berührt native Berechtigungen, OS-gesteuerte Schnittstellen, verschiedene Rückgabeformen als viele Entwickler erwarten und eine Handvoll Build-Zeit-Details, die nur nach dem Versand eines realen Builds auftauchen.

Dass ist, wo Expo Bildauswahl passt. Es ist die offizielle Expo-Bibliothek für die Öffnung der System-Benutzeroberfläche, um Bilder und Videos aus der Gerätebibliothek auszuwählen oder eine Fotografie mit der Kamera zu machen, wie in der Expo Paket-Repository. In der Praxis bedeutet das, dass Sie eine zuverlässige Brücke in die native Medieneingabe erhalten, aber nicht eine benutzerdefinierte Medienexperience, die auf jedem Gerät identisch verhält.

Diese Anleitung ist für die erste Implementierung geschrieben, nicht für die Demo. Sie konzentriert sich auf die Entscheidungen, die in der Produktion relevant sind: Verwaltung versus Bare-Workflow-Einrichtung, Berechtigungsverwaltung, die Sie später nicht überraschen wird, sichere Ergebnisinterpretation und ein praktischer Upload-Muster nachdem der Benutzer ein Datei ausgewählt hat. Expo-Entwicklungsklient-Workflow.

Inhaltsübersicht

• Einführung in Expo Bildauswahl
• Installation und grundlegende Konfiguration
  • Verwaltung-Workflow-Einrichtung
  • Bare React Native-Einrichtungsdetails
• Zugriff auf die Kamera und Medienbibliothek
  • Ein minimaler aber sicherer Komponent
  • Bibliothek und Kamera-Flüsse
  • Was Sie von der System-UI erwarten können
• Hantering von Picker-Ergebnissen und -Optionen
  • Lesen Sie das Ergebnisobjekt richtig
  • Optionen, die das Downstream-Verhalten ändern
  • URI gegenüber base64
  • Eine sichere Ergebnismuster für echte Apps
• Erweiterte Muster und Plattformunterschiede
  • Ein praktischer Uploadmuster
  • Wo Plattformunterschiede tatsächlich zählen
  • Verwaltetes gegenüber bare Workflow-Unterschiede
• Schrittweise Fehlerbehebung
  • Schnelle Überprüfungen für häufige Fehler
  • Ein kurzer Produktionscheckliste

Mit Expo Bildwähler beginnen

Eine Produktmanagerin bittet um Profilbilder. Eine Woche später benötigt dieselbe Funktion auch die Hochladen von Rechnungen, die Kamerafunktion für Vorfälle und Wiederholungen, wenn Benutzer die erste Zeit die Erlaubnis verweigern.

expo-image-picker ist der Expo SDK-Modul für diese Aufgabe. Es öffnet den Plattformpicker oder die Kamera-UI und gibt die ausgewählte Medien in einer Form zurück, die Ihr React Native code verarbeiten kann. Die JavaScript API ist klein. Der Hauptwettbewerb liegt darin, die native Einstellung, die Erlaubnisablauf und die Ergebnisbearbeitung auf beiden verwalteten und freien Projekten richtig zu bekommen.

Die Hauptentscheidung ist einfach. Sie lassen iOS und Android ihre eigenen Medien-UI präsentieren, anstatt eine benutzerdefinierte Picker zu bauen. Das gibt normalerweise ein besseres Ergebnis: Benutzer verstehen die Systemeinstellungen, Erlaubnisanfragen verhalten sich wie die OS erwartet und Ihr Team vermeidet die Wartung einer Galerieimplementierung in JavaScript.

Behandeln Sie dies als eine native Integration mit einer React-Oberfläche.

Dieser Geisteszustand hilft, weil die Fehlerquellen selten in der Schaltfläche liegen, die den Picker aufruft. Sie kommen normalerweise aus einer der drei Orte:

• Native Konfiguration: fehlende Plugin-Einstellungen, falsche Erlaubnisstrings oder ein veralteter Build nach einer Änderung der Konfiguration
• Laufzeitverhalten: Benutzer können den Zugriff verweigern, auf iOS nur begrenzten Zugriff auf die Bibliothek gewähren oder den Ablauf ohne Auswahl abbrechen
• Ergebnisbearbeitung: Die aktuelle API gibt ein assets array, also ältere Beispiele, die direkt result.uri versagen

Die Wahl des Workflows ändert auch den Pfad der Einrichtung. In einem verwalteten Expo-App leben die meisten native Arbeiten in der App-Konfiguration und erfordern einen Neubau, wenn sich diese Konfiguration ändert. In einer Bare-App erhalten Sie den Expo-Modul API, aber Sie müssen die zugrunde liegenden iOS- und Android-Projekt-Einstellungen direkt überprüfen. Wenn Ihr Team ein benutzerdefiniertes Client-Tool verwendet, anstatt Expo Go, passt sich diese Anleitung gut mit Capgo’s Erklärung der Änderung der native Modulprüfung für einen Expo-Entwicklungsklienten an Das getrennte Szenario spielt für den Rest der Anleitung eine Rolle, weil der glückliche Weg nur die Hälfte der Geschichte ist. Eine Picker-Implementierung ist solide, wenn sie in beiden Workflows funktioniert, Plattform-spezifische Berechtigungs-Quirks ohne Überraschung des Benutzers handhabt und einen verwendbaren Datei an die Upload-Schicht übermittelt, anstatt bei einer lokalen Voransicht zu stoppen.

Installation und Wesentliche Konfiguration

Die Installation erfordert nur einen Befehl. Die richtige native Konfiguration bestimmt, ob der Picker auf einem echten Gerät, in einem benutzerdefinierten Entwicklungsclient und in Ihrer Produktionsversion funktioniert

bietet eine React-freundliche __CAPGO_KEEP_0__ über die Plattform-Picker für Fotos, Videos und Kamera-Aufnahmen. Die JavaScript-Anweisung ist einfach. Die Einrichtung ist nicht, weil der Zugriff auf Fotos und die Kamera von iOS und Android, nicht von React Native, gesteuert werden

expo-image-picker Ein Entwickler, der an der Implementierung von Expo-Bildauswahl arbeitet, indem er API auf einem Laptop-Computerbildschirm tippt

Stattdessen

npx expo install expo-image-picker

Verwenden expo install anstatt npm install oder yarn addExpo passt die Paketversion mit Ihrem SDK überein, was eine häufige Klasse von Problemen bei der nativen Kompatibilität vermeidet. Wenn Sie vergleichen, wie Expo-Module in Ihrem Release-Prozess passen, ist dies Übersicht über Expo-Tools Einrichtung des verwalteten Workflows

Im verwalteten Workflow deklarieren Sie den Plugin in der App-Konfiguration, damit Expo die nativen Änderungen bei der Buildzeit anwenden kann.

Beispiel mit

Das ist die Mindestanforderung. In der Praxis fügen Teams üblicherweise auch Erlaubnistext hinzu, insbesondere auf iOS, wo der Systemanzeiger erklären soll, warum die App Zugriff benötigt. Halten Sie die Wortwahl spezifisch für die Benutzeraktion. 'Ein Profilbild hochladen' ist besser als 'Zugriff auf Medien benötigt'. app.json:

{
  "expo": {
    "plugins": ["expo-image-picker"]
  }
}

Eine operative Details verursacht viel Zeitverschwendung. Änderungen an

Zugriffsrechten, Erlaubnistexten oder anderen nativen Konfigurationen erfordern einen Neubau. Eine erneute Ausführung von JavaScript wirkt sich nicht auf diese Änderungen aus. In Expo Go sind Sie auch durch die bereits enthaltenen Client-Elemente eingeschränkt. In einem Entwicklungsbuild oder einem Produktionsbuild spiegelt sich die native Projekt nur nach einem neuen Build Ihre Konfiguration wider. pluginsEinzelheiten zur Einrichtung eines Bare-React-Native-Setup

Im Bare-App ist der Paket __CAPGO_KEEP_0__ gleich, aber Sie müssen mehrere Teile des nativen Projekts selbst überprüfen. Die iOS-Benutzungsbeschreibungen sind das erste, was Sie überprüfen sollten. Wenn Ihr Fluss die Bibliothek öffnen, die Kamera starten oder Video mit Audio aufnehmen kann, benötigt Ihre App die entsprechenden Erlaubnistexte in

In a bare app, the package API is the same, but you need to verify more of the native project yourself. iOS usage descriptions are the first thing to check. If your flow can open the library, launch the camera, or record video with audio, your app needs the corresponding permission strings in Info.plist Bevor Sie neu bauen.

Ein praktischer Checkliste für bare Projekte sieht so aus:

1. Installieren expo-image-picker mit npx expo install expo-image-picker.
2. Fügen Sie die Plugin-Konfiguration hinzu, wenn Ihr Projekt Expo-Konfigurationsplugins verwendet.
3. Stellen Sie sicher, dass die iOS-Benutzungsbeschreibungen den von Ihnen angebotenen Funktionen entsprechen.
4. Bauen Sie die iOS- und Android-Apps nach jeder native Konfigurationsänderung neu.

Der Text für fehlende Berechtigungen sieht oft wie ein Laufzeitfehler aus, weil die UI code in Ordnung ist und der Button-Handler ausgeführt wird. Der Fehler liegt tiefer in der Stack. Ich überprüfe normalerweise Info.plist, die App-Konfiguration und ob die aktuelle Build die neuesten native Änderungen enthält, bevor ich die Komponente code anfasse.

Einige Gewohnheiten machen die Einrichtung vorhersehbarer:

• Schreiben Sie den Berechtigungstext für die tatsächliche Aktion: Benutzer sollten verstehen, warum sie den Hinweis sehen.
• Kamera und Bibliothek separat konfigurieren: Ein funktioniert, während der andere noch nicht funktioniert.
• Rebuild nach native Änderungen: Hot Reload und schnelle Aktualisierung aktualisieren die native Berechtigungen nicht.
• Testen auf Gerät: Der Simulatorverhalten kann Berechtigungs- und Kamera-Probleme verbergen.

Wenn der Picker während der Entwicklung funktioniert, aber bei TestFlight oder der Play Store-Buildung bricht, betrachten Sie das als Konfigurationsproblem zuerst. Die meisten der Zeit ist es das.

Zugriff auf die Kamera und die Medienbibliothek

Eine Benutzer klickt auf „Foto hochladen“, erwartet, dass die Kamera oder Bibliothek geöffnet wird, und Ihre App hat in diesem Moment eine Aufgabe. Öffnen Sie das richtige System-UI, behandeln Sie das Ablehnen oder die Abbrechung ohne das Bildschirm zu brechen und geben Sie einen verwendbaren lokalen Dateireferenz für die Voransicht oder den Upload zurück.

Das klingt einfach, bis Sie beide verwalteten und bare Builds auf iOS und Android testen. Der JavaScript API bleibt kompakt, aber die Laufzeitverhalten hängt immer noch von den OS-Anfragen, dem Gerätehardware und wie Ihre native Berechtigungen zuvor konfiguriert wurden.

Ein minimaler aber sicherer Komponente

Der Kernfluss ist in Projekten sowohl für Expo- als auch für bare Workflow konsistent. Stellen Sie die relevanten Berechtigungen an, starten Sie den Picker, überprüfen Sie, ob der Benutzer abgebrochen hat, und lesen Sie dann das erste Asset von result.assets.

Eine Basiskomponente sieht so aus:

import { useState } from 'react';
import { View, Button, Image, Alert } from 'react-native';
import * as ImagePicker from 'expo-image-picker';

export default function PhotoInput() {
  const [imageUri, setImageUri] = useState<string | null>(null);

  const pickFromLibrary = async () => {
    const permission = await ImagePicker.requestMediaLibraryPermissionsAsync();

    if (!permission.granted) {
      Alert.alert('Permission required', 'Please allow photo library access.');
      return;
    }

    const result = await ImagePicker.launchImageLibraryAsync({
      mediaTypes: ['images'],
      allowsEditing: true,
      quality: 1,
    });

    if (result.canceled) return;

    const asset = result.assets?.[0];
    if (!asset?.uri) return;

    setImageUri(asset.uri);
  };

  const takePhoto = async () => {
    const permission = await ImagePicker.requestCameraPermissionsAsync();

    if (!permission.granted) {
      Alert.alert('Permission required', 'Please allow camera access.');
      return;
    }

    const result = await ImagePicker.launchCameraAsync({
      allowsEditing: true,
      quality: 1,
    });

    if (result.canceled) return;

    const asset = result.assets?.[0];
    if (!asset?.uri) return;

    setImageUri(asset.uri);
  };

  return (
    <View>
      <Button title="Choose from library" onPress={pickFromLibrary} />
      <Button title="Take photo" onPress={takePhoto} />
      {imageUri ? (
        <Image
          source={{ uri: imageUri }}
          style={{ width: 200, height: 200 }}
        />
      ) : null}
    </View>
  );
}

Drei Details sind hier wichtig.

• Berechtigungen für Bibliothek und Kamera sollten separat angefordert werden. Sie scheitern unabhängig voneinander.
• Behandeln Sie die Abbruchaktion als normale Benutzeraktion und nicht als Fehlerzustand.
• Lesen Sie aus assets[0], weil der Picker eine Asset-Array zurückgibt und nicht ein oberstes uri.

Bibliothek- und Kamera-Flüsse

Beginnen Sie mit dem Bibliothek-Fluss, wenn Sie den schnellsten Weg zu einer funktionierenden Funktion wollen. Es ist einfacher zu testen, es funktioniert in mehreren Simulator-Setup, und es umgeht Kamera-Hardware-Edge-Fälle. Fügen Sie Kamera-Funktionen einmal, wenn der Ergebnis-Handling-Weg stabil ist.

Der Kamera-Weg hat mehr Möglichkeiten, in der Entwicklung zu scheitern. Die iOS-Simulator-Unterstützung ist limitiert. Android-Emulatoren mögen die Kamera-Verhalten nicht so genau wie ein echter Gerät ausgeben. In bare Projekten können diese Lücken Sie dazu bringen, sich die Komponente code anzusehen, obwohl das tatsächliche Problem in der native Konfiguration oder im Testumgebung liegt.

Eine saubere UI-Muster ist, den Benutzer vor dem Aufrufen des Pickers um die Quelle zu fragen API:

const showPickerOptions = () => {
  Alert.alert('Upload image', 'Choose a source', [
    { text: 'Camera', onPress: takePhoto },
    { text: 'Photo Library', onPress: pickFromLibrary },
    { text: 'Cancel', style: 'cancel' },
  ]);
};

Diese Trennung hält jede Funktion konzentriert. Es macht es auch einfacher, Analytics, Feature-Flags oder Backend-spezifische Regeln später hinzuzufügen. Zum Beispiel ermöglichen einige Teams die Bibliothek-Aufladung für Profilbilder, aber erfordern frische Kamera-Aufnahmen für die Identitätsprüfung.

Wenn Ihre breitere App auch Dateizugriffsverhaltensmuster außerhalb von Expo unterstützt oder Sie Konventionen zwischen nativen Stapeln vergleichen, ist dies Capacitor Fotobibliotheksreferenz ist nützlicher Kontext.

Ein kurzer Demo hilft, wenn Sie dieses Fluss Ihren Teamkollegen oder QA zeigen:

Was Sie von der System-UI erwarten

expo-image-picker Öffnet die Plattform- oder Kamera-UI. Ihre App kontrolliert nicht jede Seite in diesem Fluss. Diese Unterscheidung ist wichtig, weil "funktioniert auf meinem Gerät" oft bedeutet "das Betriebssystem hat dem Pfad, den ich getestet habe, zugestimmt."

Auf iOS können Benutzer begrenzten Bibliothekszugriff statt vollem Zugriff gewähren. Auf Android kann sich das Verhalten des Pickers je nach Betriebssystemversion und -Hülle des Herstellers unterscheiden. In Projekten mit verwaltetem Workflow handhabt Expo mehr der nativen Verdrahtung für Sie. In Projekten mit Bare-Workflow müssen Sie bestätigen, dass Ihre gebaute App die nativen Berechtigungsänderungen enthält, die Sie vorgenommen haben. Die JavaScript-Anrufliste kann in beiden Fällen identisch sein, während sich die Ausführungszeitpunkt unterscheidet.

Ich teste diese Fälle normalerweise, bevor ich die Funktion als abgeschlossen betrachte:

• erste Berechtigungsanfrage
• abgelehnte Berechtigung
• Benutzerkündigung
• erfolgreiche Bibliotheksauswahl
• Erfolgreiche Kameraaufnahme auf einem physischen Gerät
• Unmittelbare Vorschau der zurückgegebenen lokalen URI

Diese Fälle entsprechen direkt der realen Produktionsverhalten. Sie setzen auch den nächsten Schritt sauber ein, wenn Sie das Datei an einen Server, einen Moderationspipeline oder einen Veröffentlichungs-Endpunkt wie den Instagram-Medienveröffentlichungs API.

Behandlung von Picker-Ergebnissen und Optionen

Das Picker-Ergebnis ist der Teil, der normalerweise echte Produktionslogik benötigt. Das System-UI gibt ein strukturiertes Objekt zurück, nicht nur einen Dateipfad, und kleine Fehler hier führen zu gebrochenen Vorschauen, leeren Uploads oder Abstürzen, wenn der Benutzer den Picker abbricht.

Lesen Sie das Ergebnisobjekt richtig

Die Ergebnisform, die in aktuellen Expo-Anwendungen relevant ist, ist result.assets[0].urinicht ein oberstes result.uri. Diese Details wirken sich auf beide verwalteten und bare Workflow-Projekte aus, da der JavaScript API gleich bleibt, obwohl die native Setup unterschiedlich ist.

Verwenden Sie ein Wächtermuster zuerst:

const result = await ImagePicker.launchImageLibraryAsync({
  mediaTypes: ['images'],
  allowsEditing: true,
  quality: 1,
});

if (result.canceled) {
  return;
}

const asset = result.assets?.[0];
if (!asset) {
  return;
}

const { uri } = asset;
setImageUri(uri);

Dies handhabt die beiden häufigsten Fehlerfall. Ein abgebrochener Picker gibt Ihnen kein Asset zum Lesen, und code das annehmen würde result.assets[0] immer existiert, wird bei der Ausführung fehlschlagen.

Sobald Sie die URI haben, ist die Darstellung eines Vorschaubildes unkompliziert:

<Image source={{ uri: imageUri }} style={{ width: 240, height: 240 }} />

Wenn Sie später hochladen planen, sollten Sie das ganze Objekt aufbewahren, nicht nur die URI. In der Praxis asset sind und fileName, mimeType, width, heightsind oft nützlich für die Validierung, Protokollierung oder die Erstellung eines sauberen multipart-Anforderung. fileSize Optionen, die die Abhängigkeit beeinflussen

Einige Auswahlmöglichkeiten beeinflussen mehr als nur das Auswahlbildschirm. Sie bestimmen die Dateigröße, das Bearbeitungsverhalten und, was Ihr Backend akzeptieren muss.

Option

Auf ein paar Kompromisse ist leicht zu verpassen:

• allowsEditing ist nützlich, wenn das Bildschlitze eine fixe Form oder Größe hat. Es ist weniger nützlich, wenn Ihr Server seine eigene Pipeline für die Bildbearbeitung durchführt und Sie das Originalfile wollen.
• quality beeinflusst die Uploadzeit, den Speicherdruck und den Speicherplatz des Servers. quality: 1 ist nicht automatisch die richtige Wahl.
• mediaTypes sollte den Regeln des Servers entsprechen. Wenn der Server Videos ablehnt, lassen Sie den Picker keine Videos zurück.
• base64 erhöht die Größe des Payloads im Speicher. Vermeiden Sie es, es zu verwenden, es sei denn, der empfangende Service erfordert es.

Das letzte Punkt ist auf Geräten mit geringer Speicherkapazität wichtig. Eine lokale Datei-URI ist in der Regel die bessere Übergabe für die Vorschau und die multipart-Upload. Base64 hat gültige Verwendung, aber es ist im Vergleich zum Übergeben einer Dateireferenz teuer.

URI gegenüber Base64

Für die meisten Apps ist die Regel einfach:

• Verwenden Sie URI für Vorschauen.
• Werden Sie URI zur Dateiübertragung verwenden.
• Werden Sie base64 nur verwenden, wenn das empfangende System explizit nach kodiertem Inhalt fragt.

Dieser Musterhaltung ermöglicht es, den Picker code klein und einfacher zu testen. Es passt auch mit der Bauweise vieler Backend-Medienströme überein, einschließlich Diensten, die letztendlich auf externe Plattformen wie dem Instagram-MedienveröffentlichungsAPI.

Wenn Ihr Team häufig OTA-Updates oder Bildschwerpunkte über App-Delivery versendet, haben die Dateigrößenentscheidungen hier Auswirkungen auf den Rest des Pipelines. Diese Anleitung zum Optimieren von Bildern für App-Updates ist ein nützliches Begleitwerk zur Picker-Konfiguration.

Ein sichereres Ergebnismuster für reale Apps

Für Demo code, wird nur gespeichert imageUri Ist in der Produktion ausreichend. Speichern Sie ein normalisiertes Objekt, damit der nächste Schritt, Vorschau, Validierung, Upload oder Wiederholung, nicht jedes Mal die Rohauswahl interpretieren muss.

const result = await ImagePicker.launchImageLibraryAsync({
  mediaTypes: ['images'],
  allowsEditing: true,
  quality: 0.8,
});

if (result.canceled || !result.assets?.length) {
  return;
}

const asset = result.assets[0];

setSelectedImage({
  uri: asset.uri,
  fileName: asset.fileName ?? 'upload.jpg',
  mimeType: asset.mimeType ?? 'image/jpeg',
  width: asset.width,
  height: asset.height,
  fileSize: asset.fileSize ?? null,
});

Das gibt Ihnen eine vorhersehbare Form innerhalb der App. Es macht auch die Verwaltung und die Bare-Projekte einfacher, sie zu synchronisieren, da die App code stabil bleibt, während Sie durch natürliche Unterschiede arbeiten.

Ein letzter Check hilft. Aktivieren Sie keine zusätzlichen Ergebnisfelder nur aus Sicherheitsgründen. Fordern Sie die Daten ab, die Sie benötigen, und halten Sie den Picker auf die Auswahl konzentriert, anstatt ihn in einen allgemeinen Dateiverarbeitungsschritt umzuwandeln.

Erweiterte Muster und Plattformunterschiede

Ein Picker-Funktion wird normalerweise nicht mehr einfach, wenn die erste ausgewählte Bild das Überleben von Wiederholungen, Auth-Header, natürlichen Berechtigungsdifferenzen und einem echten Upload-Endpunkt überleben muss. expo-image-picker verwaltet die Auswahl gut. Der Rest der Funktion liegt an Ihrer App.

Ein praktisches Upload-Muster

Für APIs, die ein Dateiupload erwarten FormData ist immer noch der sicherste Standard. Es funktioniert über gemeinsame Rails, Node, Laravel, Django und Go-Backends und hält den Picker von Transport-Bedürfnissen getrennt.

async function uploadImage(imageUri: string) {
  const formData = new FormData();

  formData.append('file', {
    uri: imageUri,
    name: 'upload.jpg',
    type: 'image/jpeg',
  } as any);

  const response = await fetch('https://your-api.example.com/uploads', {
    method: 'POST',
    body: formData,
    headers: {
      Accept: 'application/json',
    },
  });

  if (!response.ok) {
    throw new Error('Upload failed');
  }

  return response.json();
}

Das code reicht aus, um den Weg zu beweisen, aber Produktionsanwendungen benötigen normalerweise einen zusätzlichen Schritt. Ableiten Sie name und type Wenn möglich, wird der ausgewählte Asset verwendet, Auth außerhalb der Picker-Funktion angehängt und der Upload-Zustand getrennt vom Picker-Zustand gehalten, damit ein fehlgeschlagener Anfrage-Antrag nicht zwingt, den Benutzer, den Bibliothek zu öffnen.

Einige Überprüfungen verhindern die häufigen Fehler, die ich in der Überprüfung sehe:

• Bestätige die lokale uri existiert, bevor du den Anfrageaufbau erstellst
• Zeichne einen Vorschau vor dem Upload, damit die Benutzer frühzeitig erkennen, dass sie den falschen Datei ausgewählt haben
• Verhindere wiederholte Tasten, während die Anfrage in der Luft ist
• Behandle Netzwerkfehler separat von Picker-Stornierung oder Berechtigungsfehlern
• Erwarte, dass der Backend-Validierung große Dateien, nicht unterstützte MIME-Typen oder fehlende Authentifizierung ablehnt

Wenn dein Backend Base64 anstatt Multipart erwartet, ist das in der Regel eine Server-Beschränkung und nicht eine Picker-Anforderung. Multipart ist günstiger in Bezug auf Speicher und einfacher zu verstehen auf mobilen Geräten.

Wo Plattformunterschiede tatsächlich zählen

Die Picker-UI ist native, also erbt sie native Verhaltensweisen. Das wirkt sich sowohl auf das, was die Benutzer sehen, als auch auf das, was dein code annehmen sollte.

On iOS folgen die Bearbeitungsflüsse und die Berechtigungsanfragen den Konventionen von Apple. Die Zugriffseinschränkung auf Fotos kann eine engerere Auswahl an Assets liefern als Ihr Testkonto auf einem vollständig genehmigten Gerät sah. Auf Android variiert das Verhalten des Pickers mehr je nach Betriebssystemversion und Hersteller-Haut, insbesondere um Alben, Dateinamen und wie Kamera-Aufnahmen zurückgegeben werden. Bare React Native-Anwendungen spüren diese Unterschiede direkt mehr, weil Sie mehr des nativen Setups besitzen, aber verwaltete Expo-Anwendungen benötigen code , das den Picker als plattformabhängig und nicht als perfekt gleichmäßig behandelt.

Die praktische Regel ist einfach. Verlassen Sie sich auf die Felder, die Sie validieren können, und nicht auf identische Benutzeroberflächen oder identische Metadaten auf verschiedenen Geräten.

Einige Beispiele zählen in realen Apps:

• Die Bearbeitung und das Schneiden: Die Benutzeroberfläche und das Schneideverhalten sind nicht identisch zwischen iOS und Android
• Die zurückgegebenen Metadaten: fileName, mimeType, und fileSize können fehlen oder ungleichmäßig sein, daher sollten Sie Ersatzmöglichkeiten hinzufügen
• Die Berechtigungen: Die Zugriffsberechtigung auf Fotos kann auf ausgewählte Artikel beschränkt sein, während das Verhalten von Android mehr von der Betriebssystemversion und der Unterstützung des Systems durch den Picker abhängt
• Die Kameraausgabe: Die aufgenommenen Bilder können mit unterschiedlichen Namens, Orientierung oder Kompressionsmerkmalen als Bibliotheksassets zurückgegeben werden

If Ihr Team auch außerhalb von Expo arbeitet, ist dies Entwicklerleitfaden für DesignStack Dies gibt nützliche Android-Kontext für Entscheidungen zum Medienhandling, die sich außerhalb einer einzelnen Bibliothek zeigen.

Unterstützte vs. bare Workflow-Unterschiede

Zu diesem Zeitpunkt beginnen die Setup-Optionen, operativ zu zählen.

In dem verwalteten Workflow leben die Berechtigungszeichen und die Plugin-Konfiguration normalerweise in der App-Konfiguration, und native Änderungen werden bei der Erstellung einer neuen Build angewendet. Das hält die JavaScript-Oberfläche sauber, aber es bedeutet auch, dass eine Konfigurationsänderung erst bei der nächsten native Build sichtbar ist. OTA-Updates patchen fehlende native Berechtigungen nicht.

In dem bare Workflow hat das gleiche Feature mehr bewegliche Teile. Sie müssen die native iOS-Benutzungsbeschreibungen, die Android-Manifestverhalten, die Paketinstallation und die Rebuild-Zeit selbst überprüfen. Der Vorteil ist die Kontrolle. Der Nachteil ist, dass ein Picker-Fehler durch native Konfiguration verursacht werden kann, nicht durch die JavaScript-Anrufliste.

Teams, die zwischen Expo und Capacitor hin- und herswitchen, unterschätzen oft, wie unterschiedlich diese Abstraktionslagen sind. Capgo hat eine nützliche Erklärung, wie Capacitor Plattformunterschiede handhabt, und es ist ein gutes Vergleichspunkt, wenn Sie entscheiden, wie viel native Setup Ihr Team besitzen möchte. Meine Vorliebe ist konsistent in beiden Workflows. Halten Sie den Picker Capacitor eng, normalisieren Sie das Ergebnis einmal, laden Sie es über eine dedizierte __CAPGO_KEEP_1__-Schicht hoch und behandeln Sie plattformspezifische Verhaltensweisen als etwas, das konfiguriert und explizit getestet werden soll, anstatt sie mit Annahmen zu glätten.Häufige Probleme lösen

My preference is consistent across both workflows. Keep picker code narrow, normalize the result once, upload through a dedicated API layer, and treat platform-specific behavior as something to configure and test explicitly rather than smooth over with assumptions.

Troubleshooting Common Issues

Die meisten Expo-Bildwählerfehler fallen in eine kleine Anzahl von Kategorien. Die schnellste Lösung ist meistens, zu identifizieren, welcher Layer fehlschlägt: Konfiguration, Berechtigung, Ergebnisbearbeitung oder Rendering.

Schnelle Überprüfungen für häufige Fehlschläge

Wenn der Picker nicht öffnet oder die Berechtigungen fehlschlagen, überprüfen Sie zunächst die native Einstellungen. In barre Apps sind insbesondere fehlende iOS-Benutzungsbeschreibungen eine häufige Ursache.

Wenn das App nach dem Schließen des Pickers abstürzt, überprüfen Sie Ihre Ergebnisbearbeitung. Viele Implementierungen nehmen an, dass eine direkte URI vorhanden ist und die Überprüfung auslässt. canceled Einige schnelle Zuweisungen helfen:

Berechtigungsfehler:

• Überprüfen Sie Ihre App-Konfiguration und native Berechtigungssätze, dann neu erstellen. Bild-URI:
• undefined Aus nicht result.assets?.[0]?.uri, not result.uri.
• Nichts passiert nach Abbruch: Das mag korrekt sein. Behandle Abbruch als Zustand ohne Funktion.
• Bild wird nicht angezeigt: Bestätige, dass die URI im Zustand gespeichert und in <Image source={{ uri }} />.
• Die Kamera verhält sich seltsam im Simulator: Teste auf einem physischen Gerät, bevor du dich auf einen Bibliotheksfehler einlässt.

Ein kurzer Produktionscheckliste

Verwende dies als letzte Überprüfung vor dem Versand:

• Installieren mit Expo-Tooling: Verwende npx expo install expo-image-picker.
• Konfiguriere native Teile: Füge das Plugin und die erforderlichen Berechtigungsbeschreibungen hinzu.
• Bitte genehmige die erforderlichen Berechtigungen: Kameras und Medienbibliotheken sollten getrennt behandelt werden.
• Jedes Ergebnis sollte geschützt werden: Überprüfen result.canceled und sicher lesen assets[0].
• URI-basierte Uploads bevorzugen: Base64 nur für besondere Fälle verwenden.
• Realgeräte testen: Besonders für die Kameraaufnahme und die Berechtigungsanfragen.

Wenn Ihr Team Capacitor oder Electron-Apps neben React-Native-Projekten ausliefern möchte Capgo Wenn Ihre Team __CAPGO_KEEP_0__ oder Electron-Apps neben React-Native-Projekten ausliefern möchte, ist Capgo eine Option für die Bereitstellung von JavaScript, CSS, Konfiguration und Asset-Updates ohne auf jede Änderung im Store warten zu müssen. Es ist relevant, wenn imagebezogene Fixes im Weblayer leben, wie z.B. Upload-UI, Validierungsregeln, Kopien oder Asset-Handling um den Picker-Flow herum.