Mobile KI mit ONNX Runtime: So erstellen Sie eine funktionierende Echtzeit-Rauschunterdrückung

Ihr Smartphone ist leistungsstärker als ein Desktop-Computer von vor fünf Jahren. Die neuesten Android-Flaggschiffe verfügen über neuronale Prozessoren, Multi-Core-CPUs, die selbst Laptops von 2019 neidisch machen würden, und RAM-Konfigurationen, die noch vor wenigen Jahren unmöglich schienen. Warum also haben wir das Gefühl, wir kratzen gerade erst an der Oberfläche dessen, was mit KI auf Mobilgeräten möglich ist? Natürlich können Sie jetzt sogar quantisierte Versionen von Llama- und DeepSeek-Modellen lokal auf Ihrem Gerät ausführen. Aber seien wir ehrlich: Diese Konversationen fühlen sich immer noch klobig und langsam an und bieten bei weitem nicht das nahtlose Erlebnis, das Benutzer von ihren Apps erwarten. Der Hype um geräteinterne Konversations-KI ist real, aber wie sieht die praktische Realität aus? So weit sind wir noch nicht. Und genau hier verpassen die meisten Entwickler die Chance: Konversations-KI ist nicht die einzige Lösung. Während alle dem nächsten ChatGPT-Klon hinterherjagen, steckt ein riesiges ungenutztes Potenzial in spezialisierten KI-Anwendungen, die auf mobiler Hardware hervorragend funktionieren. bereits jetzt Nehmen wir die Geräuschunterdrückung. Ihre Benutzer kämpfen bei Anrufen, Aufnahmen und Sprachnachrichten ständig mit Hintergrundgeräuschen. Wind, Verkehr, schreiende Babys, bellende Hunde – es ist ein endloser Kampf gegen das Audiochaos. Doch was wäre, wenn Ihre App diese Geräusche in Echtzeit und lokal eliminieren könnte, ohne ein einziges Byte in die Cloud zu senden? Das ist keine Science-Fiction. Es passiert heute, und jeder Android-Entwickler kann es umsetzen. Die Tools sind ausgereift, die Leistung ist vorhanden, und Ihre Benutzer werden den Unterschied sofort bemerken. ONNX Runtime: Ihr Tor zur mobilen KI Die mobile KI-Landschaft ist fragmentiert. PyTorch dominiert die Forschung, TensorFlow bestimmt die Produktion, und unzählige spezialisierte Frameworks entstehen für spezifische Anwendungsfälle. Für Android-Entwickler bedeutet dies eine schwierige Entscheidung: sich auf ein Ökosystem festzulegen oder separate Pipelines für verschiedene Modelle zu pflegen. Nach der Evaluierung mobiler KI-Frameworks haben wir uns aus mehreren zwingenden Gründen, die sich direkt auf die Android-Entwicklung auswirken, für ONNX Runtime entschieden. Größere Kompatibilität zwischen Android-Versionen Im Gegensatz zu Googles LiteRT (ehemals TensorFlow Lite), das ein SDK-Mindestlevel von 31 (Android 12) vorschreibt, unterstützt ONNX Runtime problemlos Android-API-Level bis 24 (oder sogar 21, wenn Sie ein Zauberer sind). Die minimal unterstützte Version unseres Projekts war API 28. Damit ist ONNX Runtime die klare Wahl, um ein breiteres Publikum zu erreichen, ohne Millionen aktiver Nutzer auf Geräten mit Android 10 und früheren Versionen auszuschließen. Nahtlose Cross-Framework-Integration Die größte Stärke von ONNX Runtime liegt in seiner Framework-unabhängigen Natur. Unabhängig davon, ob Ihre KI-Modelle aus PyTorch, TensorFlow oder sogar traditionellen ML-Bibliotheken wie scikit-learn stammen, ermöglicht der Export von Modellen nach ONNX eine einheitliche Bereitstellung in Android-, iOS-, Desktop- und Cloud-Umgebungen. Diese Flexibilität vereinfacht die Wartung erheblich und ermöglicht eine einheitliche Pipeline, anstatt mit mehreren Framework-spezifischen Tools jonglieren zu müssen. Leichtgewichtige und modulare Bereitstellung Die Integration mit ONNX Runtime ist unkompliziert. Mit einem kompakten Maven AAR (ca. 5–7 MB für CPU-Builds) lässt sich die Bibliothek nahtlos in Ihre bestehende Android-App integrieren, ohne unnötige Abhängigkeiten wie Google Play Services einzuführen oder zusätzliche Benutzerberechtigungen anzufordern. Diese optimierte Bereitstellung sorgt dafür, dass Ihre App schlank, leistungsstark und sicher bleibt. Bewährte Echtzeitleistung ONNX Runtime hat sich in anspruchsvollen Echtzeitszenarien bewährt. Audioverarbeitungsmodelle wie Rauschunterdrückung oder Sprachverbesserung liefern auf Standard-Mobilhardware konstant Inferenzgeschwindigkeiten von unter 4 ms pro Audioframe – und liegen damit bequem im Rahmen der Echtzeit-Leistungsanforderungen. Unser Team nutzte genau diese Fähigkeit für eine zuverlässige Rauschunterdrückung mit geringer Latenz. Letztendlich bot ONNX Runtime unserem Team nicht nur Komfort, sondern auch strategische Vorteile – es ermöglichte uns, Kompatibilität, Leistung und Einfachheit ohne Kompromisse beizubehalten. Wenn Ihr Projekt zugängliche, leistungsstarke und skalierbare mobile KI erfordert, könnte ONNX Runtime die optimale Wahl für Sie sein. Integrationsplan: Einrichten der ONNX-Laufzeit Das standardmäßige ONNX Runtime-Paket ist stolze 27 MB groß. Für eine mobile App ist das nicht nur überladen, sondern ein echter Gewinnkiller. Untersuchungen zeigen, dass die Installationsrate pro 6 MB, die die APK-Größe erhöhen, um 1 % sinkt (die Studie ist zwar nicht die neueste und betrifft nicht die am weitesten entwickelten Länder, ist aber dennoch eine Überlegung wert). Die Lösung? Ein maßgeschneiderter Minimal-Build, der Ihre Bereitstellung auf das Wesentliche reduziert. Unsere DTLN-Rauschunterdrückungsimplementierung ist nur 7,1 MB groß – eine Größenreduzierung von 70 %, die Ihre App schlank und Ihre Benutzer zufrieden hält. Die Architektur von ONNX Runtime ist modular aufgebaut. Das Gesamtpaket umfasst Ausführungsanbieter für die GPU-Beschleunigung (NNAPI, Vulkan), Dutzende von Operatoren, die Sie nie verwenden werden, und Kompatibilitätsebenen für Randfälle, die für Ihr spezifisches Modell nicht relevant sind. Indem Sie nur das erstellen, was Sie benötigen, vermeiden Sie diesen Aufwand vollständig. Schritt 1: Konvertieren Sie Ihre Modelle in das ORT-Format Konvertieren Sie Ihre ONNX-Modelle vor dem Erstellen in das ORT-Format. Dieses optimierte Format entfernt nicht verwendete Graphknoten und Operatordefinitionen und reduziert so die endgültige Binärgröße weiter. Schritt 2: Operatorkonfiguration erstellen python -m onnxruntime.tools.convert_onnx_models_to_ort --target_platform {arm,amd64} Nach der Konvertierung aller erforderlichen Modelle werden auch Konfigurationsdateien mit den erforderlichen Operatoren generiert, die für den minimalen Build von ONNX erforderlich sind. Wenn Sie mehrere Modelle verwenden, fassen Sie alle Konfigurationsdateien in einer zusammen. Die endgültige Datei sieht ungefähr so aus: # Generated from model/s: ai.onnx;1;Transpose ai.onnx;6;Sigmoid ai.onnx;7;Add,LSTM ai.onnx;9;MatMul ai.onnx;11;Concat,Slice,Squeeze,Unsqueeze ai.onnx;1;Transpose ai.onnx;5;Reshape //other operators Schritt 3: Benutzerdefinierten Build ausführen # Generated from model/s: ai.onnx;1;Transpose ai.onnx;6;Sigmoid ai.onnx;7;Add,LSTM ai.onnx;9;MatMul ai.onnx;11;Concat,Slice,Squeeze,Unsqueeze ai.onnx;1;Transpose ai.onnx;5;Reshape //other operators Wenn Ihre Operatorkonfiguration bereit ist, erstellen Sie ONNX Runtime aus der Quelle mit minimalen Abhängigkeiten: --minimal_build: Schließt unnötige Ausführungsanbieter und -operatoren aus ./build.sh --android \ --android_sdk_path ~/Library/Android/sdk \ --android_ndk_path ~/Library/Android/sdk/ndk/28.0.12674087 \ --android_abi arm64-v8a \ --android_api 24 \ --minimal_build \ --include_ops_by_config path/to/required_operators.config \ --build_java \ --config=Rel ./build.sh --android \ --android_sdk_path ~/Library/Android/sdk \ --android_ndk_path ~/Library/Android/sdk/ndk/28.0.12674087 \ --android_abi arm64-v8a \ --android_api 24 \ --minimal_build \ --include_ops_by_config path/to/required_operators.config \ --build_java \ --config=Rel --include_ops_by_config: Schließt nur die in Ihrer Konfigurationsdatei angegebenen Operatoren ein --android_abi armeabi-v7a: Zielt auf ARM32 für maximale Gerätekompatibilität --android_api 24: Behält die Kompatibilität mit Android 7.0+ bei Wenn Sie auch alte Geräte unterstützen möchten, wiederholen Sie Schritt 3 mit –android_abi armeabi-v7a und führen Sie dann die beiden resultierenden AAR-Dateien mit dem folgenden Skript zusammen: Der minimale Build-Ansatz verwandelt ONNX Runtime von einem Bereitstellungsrisiko in einen strategischen Vorteil. Ihre Benutzer erhalten die volle KI-Funktionalität ohne unnötigen Ballast, und Ihre App behält das schlanke Profil, das die moderne mobile Entwicklung erfordert. #!/usr/bin/env sh # Clean up from previous runs, if any rm -rf merge-tmp mkdir -p merge-tmp cd merge-tmp echo "Unzipping each ABI-specific AAR..." mkdir a64 unzip ../onnxruntime-arm64-v8a.aar -d a64 mkdir a32 unzip ../onnxruntime-armeabi-v7a.aar -d a32 echo "Preparing universal base from arm64 AAR..." mkdir universal cp -r a64/* universal rm -rf universal/jni mkdir -p universal/jni echo "Merging native libs from each architecture..." mkdir -p universal/jni/arm64-v8a cp a64/jni/arm64-v8a/*.so universal/jni/arm64-v8a mkdir -p universal/jni/armeabi-v7a cp a32/jni/armeabi-v7a/*.so universal/jni/armeabi-v7a # Re-zip contents of 'universal' to create a new AAR echo "Creating universal AAR..." cd universal zip -r onnxruntime-universal.aar ./* echo "Done! The merged AAR is at:" echo "$(pwd)/onnxruntime-universal.aar" #!/usr/bin/env sh # Clean up from previous runs, if any rm -rf merge-tmp mkdir -p merge-tmp cd merge-tmp echo "Unzipping each ABI-specific AAR..." mkdir a64 unzip ../onnxruntime-arm64-v8a.aar -d a64 mkdir a32 unzip ../onnxruntime-armeabi-v7a.aar -d a32 echo "Preparing universal base from arm64 AAR..." mkdir universal cp -r a64/* universal rm -rf universal/jni mkdir -p universal/jni echo "Merging native libs from each architecture..." mkdir -p universal/jni/arm64-v8a cp a64/jni/arm64-v8a/*.so universal/jni/arm64-v8a mkdir -p universal/jni/armeabi-v7a cp a32/jni/armeabi-v7a/*.so universal/jni/armeabi-v7a # Re-zip contents of 'universal' to create a new AAR echo "Creating universal AAR..." cd universal zip -r onnxruntime-universal.aar ./* echo "Done! The merged AAR is at:" echo "$(pwd)/onnxruntime-universal.aar" Als Nächstes sehen wir uns diese optimierte Laufzeit mit Echtzeit-DTLN-Rauschunterdrückung in Aktion an. Warum die Audioverarbeitung den Wert von KI unterstreicht Die Audioverarbeitung ist der perfekte Einstieg in die mobile KI – sie liefert sofortigen, greifbaren Mehrwert, während Ihre Konkurrenz mit aufgeblähten Sprachmodellen kämpft, die Akkus leeren und eine ständige Internetverbindung erfordern. Der tägliche Audiokrieg, den Ihre Benutzer führen Sarah nimmt Sprachnachrichten auf, während sie durch eine belebte Straße geht. Zwischen hupenden Taxis, Baulärm und U-Bahn-Gerumpel nimmt sie die Nachrichten dreimal neu auf, bevor sie aufgibt und stattdessen tippt. Marcus nimmt von seinem Homeoffice aus an Kundengesprächen teil, das gleichzeitig das Spielzimmer seines Kleinkindes ist. Jede Präsentation wird zu einem Kreislauf aus „Stummschalten, Stummschalten, Entschuldigen für das Weinen“. Elena erstellt YouTube-Inhalte in ihrer Wohnung, verbringt jedoch Stunden in der Nachbearbeitung, um Nachbarslärm, Verkehr und das Brummen der Klimaanlage zu beseitigen. Dies sind keine Grenzfälle, sondern die Realität des modernen mobilen Computing, wo jeder in chaotischen Umgebungen professionelle Ergebnisse von Verbraucherhardware erwartet. Warum Geräuschunterdrückung sofortige „Wow“-Momente erzeugt Verbesserungen der Audioqualität lösen unmittelbare emotionale Reaktionen aus. Im Gegensatz zu anderen erklärungsbedürftigen KI-Anwendungen bietet die Rauschunterdrückung sofortige Befriedigung, die Nutzer innerhalb von Sekunden wahrnehmen können. Spielen Sie jemandem seine eigene Stimme – kristallklar – vor, nachdem Sie Hintergrundgeräusche entfernt haben, und beobachten Sie seine Reaktion. Sie müssen LSTM-Netzwerke nicht verstehen; sie wissen einfach, dass ihr Audio professionell klingt. Das Schöne an der Audioverarbeitung als KI-Vorzeigebeispiel ist ihre Universalität. Jeder versteht guten Ton, jeder kennt schlechten Ton und jeder erkennt sofort eine Verbesserung, wenn das Rauschen verschwindet. Sie verlangen von den Nutzern nicht, Ihrer KI zu vertrauen – Sie beweisen ihren Wert auf direkteste Weise. Erstellen einer produktionsreifen Demo: Rauschunterdrückung in Echtzeit Erstellen wir nun ein Beispielprojekt, das die praktische Leistungsfähigkeit von ONNX Runtime auf Android demonstriert. Anstelle eines einfachen „Hallo Welt“-Beispiels erstellen wir etwas, das der Produktionsqualität nahekommt – eine Demonstration der Echtzeit-Rauschunterdrückung, bei der Benutzer Audio in lauten Umgebungen aufnehmen und den deutlichen Unterschied zwischen ihrer Originalaufnahme und der KI-bereinigten Version erleben können. Ein vollständiges Beispiel finden Sie hier auf meinem Github: . https://github.com/linreal/android-onnx-showcase Die im Beispiel verwendeten Modelle stammen von https://github.com/breizhn/DTLN Schnelle Implementierungsübersicht Bevor wir uns mit der Dual-Path-Architektur von DTLN befassen, wollen wir klären, wie die einzelnen Teile zusammenpassen. Das Besondere an dieser Implementierung ist die klare Trennung der Aufgabenbereiche – jede Komponente trägt eine einzelne Verantwortung, wodurch das System sowohl testbar als auch wartbar ist. Die Kernkomponenten Das Herzstück unserer Rauschunterdrückungs-Pipeline bilden drei wichtige Schnittstellen, die zusammenarbeiten: Der NoiseSuppressor kapselt die gesamte ONNX-Runtime-Komplexität hinter einer einfachen Schnittstelle. Geben Sie ihm Audio-Chunks und erhalten Sie rauschfreies Audio zurück. Die zustandsbehaftete Natur von DTLN ist vollständig verborgen – die Implementierung behält die LSTM-Zustände intern zwischen den Aufrufen bei. interface NoiseSuppressor { suspend fun initialize() fun processChunk(audioChunk: FloatArray): FloatArray fun release() } interface AudioRecorder { suspend fun startRecording(): Flow suspend fun stopRecording() } interface ConcurrentAudioProcessor { suspend fun startProcessing( suppressor: NoiseSuppressor, rawOutputFile: File, processedOutputFile: File ) suspend fun stopProcessing(): ProcessingResult } interface NoiseSuppressor { suspend fun initialize() fun processChunk(audioChunk: FloatArray): FloatArray fun release() } interface AudioRecorder { suspend fun startRecording(): Flow suspend fun stopRecording() } interface ConcurrentAudioProcessor { suspend fun startProcessing( suppressor: NoiseSuppressor, rawOutputFile: File, processedOutputFile: File ) suspend fun stopProcessing(): ProcessingResult } Datenflussarchitektur Der ConcurrentAudioProcessor orchestriert die gesamte Pipeline. Er abonniert den Flow des Audiorecorders, konvertiert Audioformate, verarbeitet Blöcke durch den Rauschunterdrücker und schreibt sowohl Original- als auch verarbeitetes Audio gleichzeitig in Dateien. AudioRecorder → Flow → ConcurrentAudioProcessor → NoiseSuppressor → Processed Audio Files Warum diese Architektur funktioniert rawAudioRecorder.startRecording().collect { audioChunk -> // Convert format for processing val floatChunk = AudioConversionUtils.shortArrayToFloatArray(audioChunk) // Process through DTLN val processedChunk = suppressor.processChunk(floatChunk) // Save both versions concurrently launch { rawFileWriter.writeAudioData(floatChunk) } launch { processedFileWriter.writeAudioData(processedChunk) } } rawAudioRecorder.startRecording().collect { audioChunk -> // Convert format for processing val floatChunk = AudioConversionUtils.shortArrayToFloatArray(audioChunk) // Process through DTLN val processedChunk = suppressor.processChunk(floatChunk) // Save both versions concurrently launch { rawFileWriter.writeAudioData(floatChunk) } launch { processedFileWriter.writeAudioData(processedChunk) } } Das Flow-basierte Design sorgt dafür, dass Ihre Benutzeroberfläche reaktionsfähig bleibt. Die Audioverarbeitung erfolgt in Hintergrund-Threads, während der Haupt-Thread die Benutzerinteraktionen verarbeitet. Reaktive Verarbeitung: Jede Komponente arbeitet mit ihrem bevorzugten Audioformat. erzeugt ShortArray (16-Bit PCM), während FloatArray (normalisierte Samples) erwartet. Die Konvertierung erfolgt an der Grenze. Formatisolierung: AudioRecorder NoiseSuppressor Wenn die ONNX-Initialisierung fehlschlägt, ist nur die NoiseSuppressor-Komponente betroffen. Der Audiorecorder und die Dateischreiber funktionieren weiterhin und gewährleisten eine reibungslose Verschlechterung. Fehlergrenzen: Jede Komponente verwaltet ihre eigenen Ressourcen. Der koordiniert Lebenszyklusereignisse, besitzt jedoch nicht die zugrunde liegenden Implementierungen. Ressourcenverwaltung: ConcurrentAudioProcessor Dank dieses modularen Ansatzes können Sie die DTLN-Implementierung durch ein beliebiges anderes ONNX-Modell ersetzen, den Audiorecorder durch eine dateibasierte Quelle ersetzen oder das Ausgabeformat ändern, ohne andere Komponenten zu berühren. Die Architektur ist vom Proof-of-Concept bis zur Produktionsbereitstellung skalierbar. Als Nächstes erkunden wir die DTLN-Architektur, die diese Magie möglich macht. DTLN-Architektur verstehen Herkömmliche Ansätze zur Rauschunterdrückung stehen vor einem grundlegenden Kompromiss. Frequenzbereichsmethoden eignen sich hervorragend zum Entfernen stationärer Geräusche (Klimaanlage, Lüfterbrummen), haben jedoch Probleme mit dem Durchdringen dynamischer Geräusche wie Sprache oder Musik. Zeitbereichsmethoden verarbeiten komplexe, sich ändernde Signale gut, führen jedoch häufig zu Artefakten oder versagen bei konstantem Hintergrundrauschen. DTLN umgeht diese Einschränkung vollständig durch seine Dual-Path-Architektur: Das erste Modell arbeitet im Frequenzbereich und analysiert die spektralen Eigenschaften Ihres Audiomaterials. Es generiert eine Unterdrückungsmaske, die erkennt, welche Frequenzkomponenten Rauschen und welche Sprache enthalten. Diese Stufe eignet sich hervorragend zum Entfernen stationärer Hintergrundgeräusche – dem stetigen Summen der Klimaanlage, des Verkehrs oder des Bürogeplappers. Stufe 1: Frequenzbereichsverarbeitung // Stage 1: Frequency domain mask estimation val (magnitude, phase) = fftProcessor.forward(inBuffer) val outMask = model1.run(mapOf("input_2" to magnitudeTensor, "input_3" to lstmState)) for (i in magnitude.indices) { magnitude[i] *= outMask[i] // Apply suppression mask } Phase 2: Verfeinerung des Zeitbereichs // Stage 1: Frequency domain mask estimation val (magnitude, phase) = fftProcessor.forward(inBuffer) val outMask = model1.run(mapOf("input_2" to magnitudeTensor, "input_3" to lstmState)) for (i in magnitude.indices) { magnitude[i] *= outMask[i] // Apply suppression mask } Das maskierte Frequenzbereichssignal wird zurück in den Zeitbereich konvertiert und anschließend in ein zweites Modell eingespeist, das direkt auf die Audiowellenform einwirkt. Diese Phase erfasst, was bei der Frequenzanalyse übersehen wurde: die Verarbeitung dynamischer Rauschmuster, die Wahrung der Natürlichkeit der Sprache und die Beseitigung aller Artefakte aus der ersten Phase. Die Mobile-First-Designphilosophie // Stage 2: Time domain refinement val estimatedBlock = fftProcessor.inverse(magnitude, phase) val finalBlock = model2.run(mapOf("input_4" to estimatedTensor, "input_5" to lstmState)) // Stage 2: Time domain refinement val estimatedBlock = fftProcessor.inverse(magnitude, phase) val finalBlock = model2.run(mapOf("input_4" to estimatedTensor, "input_5" to lstmState)) Die Architektur von DTLN spiegelt jahrelange praktische Erfahrung im Einsatz mobiler KI wider. Bei jeder Designentscheidung werden reale Einschränkungen gegenüber akademischen Benchmarks berücksichtigt. Das Modell verarbeitet Audio in 512 Sample-Chunks (32 ms bei 16 kHz) und erreicht so ein optimales Gleichgewicht zwischen Latenz und Kontext. Diese Chunk-Größe ist klein genug für die Echtzeitverarbeitung, aber groß genug, um einen aussagekräftigen zeitlichen Kontext für die LSTM-Netzwerke bereitzustellen. Chunk-basierte Verarbeitung: companion object { private const val BLOCK_LEN = 512 // 32ms chunks private const val BLOCK_SHIFT = 128 // 75% overlap for smooth processing } Stateful LSTM-Netzwerke companion object { private const val BLOCK_LEN = 512 // 32ms chunks private const val BLOCK_SHIFT = 128 // 75% overlap for smooth processing } Beide Modelle verwenden LSTM-Netzwerke (Long Short-Term Memory), die den internen Zustand zwischen den Blöcken aufrechterhalten. Dieses zeitliche Gedächtnis ermöglicht es dem Modell, kontextbezogen zwischen Sprache und Lärm zu unterscheiden, nicht nur anhand der momentanen Audiomerkmale. Leistungsmerkmale, die wichtig sind class NoiseSuppressorImpl { // These tensors maintain LSTM state between processing calls private var input3Tensor: OnnxTensor? = null // Model 1 LSTM state private var input5Tensor: OnnxTensor? = null // Model 2 LSTM state fun processChunk(audioChunk: FloatArray): FloatArray { // State automatically carries forward to next chunk val result1 = model1.run(mapOf("input_3" to input3Tensor)) input3Tensor?.close() input3Tensor = result1[1] as OnnxTensor // Update state // State continuity ensures smooth, artifact-free processing } } class NoiseSuppressorImpl { // These tensors maintain LSTM state between processing calls private var input3Tensor: OnnxTensor? = null // Model 1 LSTM state private var input5Tensor: OnnxTensor? = null // Model 2 LSTM state fun processChunk(audioChunk: FloatArray): FloatArray { // State automatically carries forward to next chunk val result1 = model1.run(mapOf("input_3" to input3Tensor)) input3Tensor?.close() input3Tensor = result1[1] as OnnxTensor // Update state // State continuity ensures smooth, artifact-free processing } } Das Verständnis der DTLN-Architektur hilft Ihnen, das Verhalten in Ihrer Anwendung vorherzusagen. Diese Leistungsmerkmale wirken sich direkt auf die Benutzererfahrung aus: Latenzprofil Algorithmische Verzögerung: 32 ms (Verarbeitungszeit eines Blocks) Inferenzzeit: 3–4 ms pro Block auf Android-Hardware der Mittelklasse Gesamtlatenz: ~35 ms End-to-End (für die meisten Anwendungsfälle nicht wahrnehmbar) Ressourcennutzung Speicherbedarf: ~28 MB während der aktiven Verarbeitung CPU-Auslastung: 12–18 % auf einem typischen Mittelklassegerät Auswirkungen auf die Batterie: Vernachlässigbar für typische Aufnahmesitzungen Aufgrund dieser Eigenschaften eignet sich DTLN besonders gut für mobile Anwendungen, bei denen Benutzer sofortige Ergebnisse erwarten, ohne dabei die Geräteleistung oder die Akkulaufzeit zu beeinträchtigen. ONNX Runtime-Integrationsstrategie Damit ONNX Runtime unter Android funktioniert, reicht es nicht aus, einfach eine Abhängigkeit zu Ihrem Build.gradle hinzuzufügen. Der Unterschied zwischen einem Proof-of-Concept, der unter Last abstürzt, und einer produktionsreifen Implementierung liegt in der Sitzungskonfiguration, der Speicherverwaltung und der Strategie zur Ressourcenzuweisung. Da wir bereits einen Build mit minimaler Laufzeit vorbereitet haben, ist es an der Zeit, uns anzusehen, was als Nächstes kommt. Sitzungskonfiguration für Mobile Reality Die standardmäßige ONNX Runtime-Sitzungskonfiguration geht davon aus, dass Sie auf einem Server mit reichlich Ressourcen arbeiten. Mobile Geräte unterliegen jedoch ganz anderen Einschränkungen: begrenzter Speicher, thermische Drosselung und Benutzer, die erwarten, dass Apps während der KI-Verarbeitung reaktionsfähig bleiben. Ihr erster Instinkt könnte sein, alle verfügbaren CPU-Kerne für maximale Leistung zu nutzen. Widerstehen Sie diesem Drang. Bei Mobilgeräten ist die Akkulaufzeit wichtiger als die reine Rechengeschwindigkeit, und das Wärmemanagement von Android drosselt die aggressive CPU-Auslastung innerhalb von Sekunden. private val sessionOptions = OrtSession.SessionOptions().apply { setIntraOpNumThreads(numThreads.coerceIn(1, 4)) setInterOpNumThreads(numThreads) setMemoryPatternOptimization(true) setOptimizationLevel(OrtSession.SessionOptions.OptLevel.ALL_OPT) setExecutionMode(OrtSession.SessionOptions.ExecutionMode.SEQUENTIAL) } private val sessionOptions = OrtSession.SessionOptions().apply { setIntraOpNumThreads(numThreads.coerceIn(1, 4)) setInterOpNumThreads(numThreads) setMemoryPatternOptimization(true) setOptimizationLevel(OrtSession.SessionOptions.OptLevel.ALL_OPT) setExecutionMode(OrtSession.SessionOptions.ExecutionMode.SEQUENTIAL) } Der optimale Wert für die Echtzeit-Audioverarbeitung liegt zwischen 2 und 4 Threads, abhängig von der Anzahl der Kerne Ihres Geräts: Diese Konfiguration liefert 95 % der maximalen Leistung und verbraucht dabei 60 % weniger Akku als ein uneingeschränkter Thread-Pool. Ihre Benutzer bemerken die Effizienzsteigerungen stärker als den geringfügigen Latenzunterschied. private val numThreads = Runtime.getRuntime().availableProcessors().coerceIn(1, 4) aktiviert die wirkungsvollste mobile Optimierung der ONNX-Runtime. Diese Einstellung analysiert die Speicherzugriffsmuster Ihres Modells während der ersten Inferenzaufrufe und weist dann Speicherpools vorab zu, um den Druck der Garbage Collection während der Echtzeitverarbeitung zu minimieren. setMemoryPatternOptimization(true) Die sequentielle Ausführung mag kontraintuitiv erscheinen, da die parallele Verarbeitung einen höheren Durchsatz bietet. Die Echtzeit-Audioverarbeitung erfordert jedoch eine vorhersehbare Latenz gegenüber Spitzenleistung. Die parallele Ausführung erzeugt Latenzspitzen bei der Thread-Synchronisierung – genau das, was Sie bei der Live-Audioverarbeitung vermeiden möchten. setExecutionMode(OrtSession.SessionOptions.ExecutionMode.SEQUENTIAL) Die sequentielle Ausführung liefert konsistente Inferenzzeiten von 3–4 ms, während der Parallelmodus zwischen 2–8 ms mit unvorhersehbaren Spitzen liegt. Benutzer empfinden Konsistenz als Qualität. Speichervorbelegung: Der Leistungsmultiplikator Die wichtigste Optimierung für mobile ONNX Runtime-Anwendungen besteht in der Vorabzuweisung von Tensoren, die bei Inferenzaufrufen wiederverwendet werden. Das Erstellen von Tensoren während der Inferenz löst Speicherzuweisungen aus, die sich zu erheblichen Leistungsengpässen summieren. // Pre-allocate tensors during initialization input3Tensor = createZeroTensor(INP_SHAPE_2) // Model 1 LSTM state input5Tensor = createZeroTensor(INP_SHAPE_2) // Model 2 LSTM state private fun createZeroTensor(shape: LongArray): OnnxTensor { val env = requireNotNull(env) { "ONNX Environment not initialized" } val size = shape.reduce { acc, i -> acc * i }.toInt() return OnnxTensor.createTensor(env, FloatBuffer.allocate(size), shape) } Reduzierung des Müllabfuhrdrucks // Pre-allocate tensors during initialization input3Tensor = createZeroTensor(INP_SHAPE_2) // Model 1 LSTM state input5Tensor = createZeroTensor(INP_SHAPE_2) // Model 2 LSTM state private fun createZeroTensor(shape: LongArray): OnnxTensor { val env = requireNotNull(env) { "ONNX Environment not initialized" } val size = shape.reduce { acc, i -> acc * i }.toInt() return OnnxTensor.createTensor(env, FloatBuffer.allocate(size), shape) } - Das Erstellen von Tensoren während der Inferenz erzeugt Objekte, die einer Garbage Collection unterzogen werden müssen. Durch die Vorabzuweisung wird dieser Aufwand auf die Initialisierungszeit verschoben, sodass Inferenzpfade zuweisungsfrei bleiben. – Wiederholte Tensor-Erstellung fragmentiert den Heap-Speicher, was zu unerwarteten Zuordnungsfehlern führt. Vorab zugewiesene Tensoren sorgen für ein konsistentes Speicherlayout. Verhinderung von Speicherfragmentierung – Zuweisungskosten sind unvorhersehbar und können bei der Echtzeitverarbeitung zu Latenzspitzen führen. Die Vorabzuweisung gewährleistet eine konsistente Inferenzzeit. Latenzkonsistenz Diese Integrationsstrategien verwandeln ONNX Runtime von einem Forschungstool in eine produktionsreife Komponente. Die Konfigurationsoptionen, Speicherverwaltungsmuster und Fehlerbehandlungsansätze wirken sich direkt auf die Benutzererfahrung aus, und zwar auf eine Weise, die nur unter realen Nutzungsbedingungen deutlich wird. Sie können einen Blick in für einen vollständigen Quellcode. https://github.com/linreal/android-onnx-showcase/blob/main/app/src/main/java/gos/denver/onnxshowcase/audio/impl/NoiseSuppressorImpl.kt Fazit: KI als Wettbewerbsvorteil Die mobile KI-Landschaft erlebt einen grundlegenden Wandel. Während die Konkurrenz ressourcenintensiven Sprachmodellen und Cloud-basierten Lösungen hinterherjagt, bietet spezialisierte, geräteinterne KI, die Nutzern einen unmittelbaren Mehrwert bietet, enorme Chancen. Wichtige Erkenntnisse für Android-Entwickler Die Kombination aus den Optimierungsfunktionen von ONNX Runtime und speziell entwickelten Modellen wie DTLN bietet eine Leistung, die Cloud-Lösungen ebenbürtig oder sogar überlegen ist, und eliminiert gleichzeitig Latenz- und Konnektivitätsanforderungen. Ihre Benutzer erhalten sofortige Ergebnisse und Sie erhalten eine Funktion, die überall funktioniert – vom U-Bahn-Tunnel bis zum Flugmodus. On-Device-KI ist heute produktionsreif. Unser minimaler ONNX Runtime-Build reduzierte die Bibliotheksgröße um 70 %, ohne die Funktionalität zu beeinträchtigen. Dies betrifft nicht nur den Speicherplatz, sondern wirkt sich direkt auf die Nutzergewinnung aus. Wenn KI-Funktionen Ihre App um 7 MB statt 27 MB erweitern, verschiebt sich das Kosten-Nutzen-Verhältnis deutlich zu Ihren Gunsten. Die Optimierung der APK-Größe verändert die Bereitstellungsstrategie. DTLN ist zwar nicht das fortschrittlichste Rauschunterdrückungsmodell auf dem Markt, bietet aber die perfekte Balance zwischen Qualität, Leistung und Ressourcenverbrauch für den mobilen Einsatz. Benutzer interessieren sich nicht für die Modellarchitektur – sie wollen kristallklaren Klang in lauten Umgebungen. Das Benutzererlebnis ist wichtiger als die algorithmische Raffinesse. Apps, die KI auf dem Gerät implementieren, haben drei Wettbewerbsvorteile: Privacy by Design (keine sensiblen Daten verlassen das Gerät), Offline-Zuverlässigkeit (konsistente Erfahrung unabhängig von den Netzwerkbedingungen) und Kostenstrukturvorteile (keine Cloud-Inferenzkosten oder Betriebskosten, die mit der Nutzung skalieren). Nächste Schritte und Erkundung Die hier gezeigten Techniken gehen weit über die Rauschunterdrückung hinaus. ONNX Runtime ermöglicht den praktischen Einsatz von Modellen für die Audioverarbeitung, Computer Vision, natürliche Sprachaufgaben und Sensorfusionsanwendungen. Die vollständige Implementierung ist auf GitHub verfügbar: . Verwenden Sie es als Grundlage für Ihre eigenen KI-gestützten Funktionen. Android-Onnx-Showcase Ihre Android-App verdient KI, die das Benutzererlebnis verbessert, ohne Leistung, Datenschutz oder Zuverlässigkeit zu beeinträchtigen. ONNX Runtime macht diese Vision heute realisierbar. Die Tools sind bereit, die Leistung ist bewährt – Zeit, etwas Außergewöhnliches zu entwickeln. Fanden Sie diese Implementierung hilfreich? Markieren Sie die und teilen Sie Ihre Ergebnisse. Die Mobile-KI-Community wird stärker, wenn wir praktisches Wissen teilen. GitHub-Repository Folgen Sie mir für weitere detaillierte Einblicke in produktionsreife mobile KI-Implementierungen, die Ihren Benutzern tatsächlich auffallen und gefallen werden.