Mobiele AI met ONNX Runtime: hoe u realtime ruisonderdrukking bouwt die werkt

Je telefoon is krachtiger dan een desktopcomputer van vijf jaar geleden. De nieuwste Android-vlaggenschepen zijn uitgerust met neurale verwerkingseenheden (NPU's), multi-core CPU's waar laptops uit 2019 jaloers op zouden zijn, en RAM-configuraties die een paar jaar geleden nog onmogelijk leken. Waarom voelt het dan alsof we nog maar aan het begin staan van wat AI op mobiele apparaten mogelijk maakt? Natuurlijk kun je nu zelfs gekwantiseerde versies van Llama- en DeepSeek-modellen lokaal op je apparaat draaien. Maar laten we eerlijk zijn: die gesprekken voelen nog steeds onhandig, traag en lang niet zo soepel aan als gebruikers van hun apps verwachten. De hype rond conversationele AI op het apparaat is reëel, maar de praktijk? Zover zijn we nog niet. Hier laten de meeste ontwikkelaars hun kans liggen: conversationele AI is niet de enige optie. Terwijl iedereen op jacht is naar de volgende ChatGPT-kloon, ligt er een enorm onbenut potentieel in gespecialiseerde AI-toepassingen die uitstekend werken op mobiele hardware. momenteel Neem ruisonderdrukking. Uw gebruikers hebben constant last van achtergrondgeluid tijdens gesprekken, opnames en voicemailberichten. Wind, verkeer, huilende baby's, blaffende honden - het is een eindeloze strijd tegen audiochaos. Maar wat als uw app dat geluid in realtime, lokaal, zou kunnen elimineren zonder ook maar één byte naar de cloud te sturen? Dit is geen sciencefiction. Het gebeurt vandaag al en elke Android-ontwikkelaar kan het implementeren. De tools zijn volwassen, de prestaties zijn er en uw gebruikers zullen het verschil direct merken. ONNX Runtime: uw toegangspoort tot mobiele AI Het mobiele AI-landschap is gefragmenteerd. PyTorch domineert onderzoek, de productie van TensorFlow-regels en er ontstaan talloze gespecialiseerde frameworks voor specifieke use cases. Voor Android-ontwikkelaars leidt dit tot een lastige keuze: zich vastleggen op één ecosysteem of aparte pipelines voor verschillende modellen onderhouden. Nadat we mobiele AI-frameworks hadden geëvalueerd, kozen we voor ONNX Runtime om verschillende dwingende redenen die een directe impact hebben op Android-ontwikkeling. Bredere compatibiliteit tussen Android-versies In tegenstelling tot Google's LiteRT (voorheen TensorFlow Lite), dat een minimaal SDK-niveau van 31 (Android 12) vereist, ondersteunt ONNX Runtime moeiteloos Android API-niveaus vanaf 24 (of zelfs 21, als je een expert bent). De minimaal ondersteunde versie van ons project was API 28, waardoor ONNX Runtime de duidelijke keuze was om een breder publiek te bereiken zonder miljoenen actieve gebruikers op Android 10 en oudere apparaten uit te sluiten. Naadloze cross-framework-integratie De grootste kracht van ONNX Runtime schuilt in het framework-onafhankelijke karakter. Of uw AI-modellen nu afkomstig zijn van PyTorch, TensorFlow of zelfs traditionele ML-bibliotheken zoals scikit-learn, het exporteren van modellen naar ONNX maakt een uniforme implementatie mogelijk in Android-, iOS-, desktop- en cloudomgevingen. Deze flexibiliteit vereenvoudigt het onderhoud aanzienlijk, waardoor een uniforme pipeline mogelijk is in plaats van het jongleren met meerdere framework-specifieke tools. Lichtgewicht en modulaire implementatie Integratie met ONNX Runtime is eenvoudig. Met een compacte Maven AAR (ongeveer 5-7 MB voor CPU-builds) integreert de bibliotheek naadloos in je bestaande Android-app zonder onnodige afhankelijkheden zoals Google Play Services te introduceren of extra gebruikersrechten te vereisen. Deze gestroomlijnde implementatie houdt je app slank, performant en veilig. Bewezen realtime prestaties ONNX Runtime heeft zich in de praktijk bewezen in veeleisende realtime scenario's. Audioverwerkingsmodellen, zoals ruisonderdrukking of spraakverbetering, leveren consistent inferentiesnelheden van minder dan 4 ms per audioframe op standaard mobiele hardware – ruimschoots binnen de realtime prestatievereisten. Ons team heeft deze functionaliteit optimaal benut voor betrouwbare ruisonderdrukking met lage latentie. Uiteindelijk bood ONNX Runtime ons team niet alleen gemak, maar ook strategisch voordeel. Hierdoor konden we compatibiliteit, prestaties en eenvoud garanderen zonder compromissen. Als uw project toegankelijke, performante en schaalbare mobiele AI vereist, is ONNX Runtime wellicht de beste keuze voor u. Integratieplan: ONNX Runtime instellen Het standaard ONNX Runtime-pakket weegt maar liefst 27 MB. Voor een mobiele app is dat niet zomaar een verspilling, maar een dooddoener voor gebruikers. Onderzoek toont aan dat voor elke 6 MB toename in APK-grootte de installatieconversie met 1% daalt (ik moet erbij zeggen dat het onderzoek niet het nieuwste is en zich voornamelijk niet richt op de meest ontwikkelde landen, maar het is desondanks het overwegen waard). De oplossing? Een minimalistische build op maat die uw implementatie terugbrengt tot precies wat u nodig hebt. Onze implementatie voor DTLN-ruisonderdrukking is slechts 7,1 MB groot - een reductie van 70%, waardoor uw app compact blijft en uw gebruikers tevreden zijn. De architectuur van ONNX Runtime is modulair van opzet. Het complete pakket bevat uitvoeringsproviders voor GPU-acceleratie (NNAPI, Vulkan), tientallen operators die u nooit zult gebruiken en compatibiliteitslagen voor randgevallen die niet van toepassing zijn op uw specifieke model. Door alleen te bouwen wat u nodig hebt, elimineert u deze overhead volledig. Stap 1: Converteer uw modellen naar ORT-formaat Converteer uw ONNX-modellen vóór het bouwen naar ORT-formaat. Deze geoptimaliseerde indeling verwijdert ongebruikte grafiekknooppunten en operatordefinities, waardoor de uiteindelijke binaire grootte verder wordt verkleind. Stap 2: Operatorconfiguratie maken python -m onnxruntime.tools.convert_onnx_models_to_ort --target_platform {arm,amd64} Nadat alle benodigde modellen zijn geconverteerd, worden ook configuratiebestanden gegenereerd met de benodigde operatoren die nodig zijn voor de minimale build van ONNX. Wanneer u meerdere modellen gebruikt, combineert u alle configuratiebestanden tot één bestand. Het uiteindelijke bestand ziet er ongeveer zo uit: # 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 Stap 3: Voer aangepaste build uit # 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 Zodra uw operatorconfiguratie gereed is, kunt u ONNX Runtime vanuit de broncode bouwen met minimale afhankelijkheden: --minimal_build: Sluit onnodige uitvoeringsproviders en operatoren uit ./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: Neemt alleen operatoren op die in uw configuratiebestand zijn opgegeven --android_abi armeabi-v7a: richt zich op ARM32 voor maximale apparaatcompatibiliteit --android_api 24: Behoudt compatibiliteit met Android 7.0+ Als u ook oude apparaten wilt ondersteunen, herhaalt u stap 3 met –android_abi armeabi-v7a en voegt u vervolgens beide resulterende aar-bestanden samen met het volgende script: De minimale build-aanpak transformeert ONNX Runtime van een implementatieprobleem naar een strategisch voordeel. Uw gebruikers krijgen de volledige AI-mogelijkheden zonder de overbodige rommel, en uw app behoudt het slanke profiel dat moderne mobiele ontwikkeling vereist. #!/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" Laten we nu deze geoptimaliseerde runtime in actie zien, met realtime DTLN-ruisonderdrukking. Waarom audioverwerking de waarde van AI laat zien Audioverwerking is de perfecte introductie tot mobiele AI. Het levert direct tastbare waarde op, terwijl uw concurrenten worstelen met opgeblazen taalmodellen die de batterij leegtrekken en constante internetverbindingen vereisen. De dagelijkse audiooorlog die uw gebruikers voeren Sarah neemt voicemailberichten op terwijl ze door een drukke straat loopt. Tussen toeterende taxi's, bouwlawaai en gerommel in de metro door, neemt ze drie keer opnieuw berichten op voordat ze het opgeeft en in plaats daarvan typt. Marcus neemt deel aan klantgesprekken vanuit zijn thuiskantoor, dat tevens dienstdoet als speelkamer voor zijn peuter. Elke presentatie wordt een cyclus van "geluid uitzetten, geluid aanzetten, excuses voor het huilen." Elena maakt YouTube-content in haar appartement, maar besteedt uren aan de postproductie om burenlawaai, verkeer en het gezoem van de airconditioning op te ruimen. Dit zijn geen uitzonderlijke gevallen. Het is de realiteit van modern mobiel computergebruik, waarbij iedereen professionele resultaten verwacht van consumentenhardware in chaotische omgevingen. Waarom ruisonderdrukking direct een 'wow'-moment creëert Verbeteringen in de audiokwaliteit veroorzaken onmiddellijke emotionele reacties. In tegenstelling tot andere AI-toepassingen die uitleg vereisen, biedt ruisonderdrukking directe bevrediging die gebruikers binnen enkele seconden kunnen waarnemen. Speel iemands eigen stem af - kristalhelder - na het verwijderen van achtergrondgeluid, en bekijk hun reactie. Ze hoeven geen LSTM-netwerken te begrijpen; ze weten gewoon dat hun audio professioneel klinkt. De schoonheid van audioverwerking als AI-voorbeeld schuilt in de universaliteit. Iedereen begrijpt goede audio, iedereen heeft slechte audio ervaren en iedereen ziet direct verbetering wanneer ruis verdwijnt. Je vraagt gebruikers niet om je AI te vertrouwen - je bewijst de waarde ervan op de meest directe manier mogelijk. Een productieklare demo bouwen: realtime ruisonderdrukking Laten we nu een voorbeeldproject bouwen dat de praktische kracht van ONNX Runtime op Android demonstreert. In plaats van een standaard "hello world"-voorbeeld, maken we iets dat de productiekwaliteit benadert: een realtime demonstratie van ruisonderdrukking waarbij gebruikers audio kunnen opnemen in een rumoerige omgeving en het opvallende verschil kunnen ervaren tussen hun originele opname en de door AI gecorrigeerde versie. Een compleet voorbeeld vind je hier, op mijn Github: . https://github.com/linreal/android-onnx-showcase De in het voorbeeld gebruikte modellen zijn afkomstig van https://github.com/breizhn/DTLN Snel implementatieoverzicht Voordat we dieper ingaan op de dual-path-architectuur van DTLN, laten we eerst eens kijken hoe de verschillende onderdelen in elkaar passen. Het mooie van deze implementatie is de heldere scheiding van taken: elk onderdeel heeft één verantwoordelijkheid, waardoor het systeem zowel testbaar als onderhoudbaar is. De kerncomponenten De kern van ons ruisonderdrukkingstraject bestaat uit drie belangrijke interfaces die samenwerken: De NoiseSuppressor bundelt alle complexiteit van ONNX Runtime achter een eenvoudige interface. Voer audiofragmenten in en ontvang ruisvrije audio terug. De stateful aard van DTLN is volledig verborgen: de implementatie behoudt intern LSTM-statussen tussen aanroepen. 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 } Gegevensstroomarchitectuur De ConcurrentAudioProcessor orkestreert de volledige pijplijn. Hij abonneert zich op de Flow van de audiorecorder, converteert audioformaten, verwerkt fragmenten via de ruisonderdrukker en schrijft zowel originele als bewerkte audio gelijktijdig naar bestanden. AudioRecorder → Flow → ConcurrentAudioProcessor → NoiseSuppressor → Processed Audio Files Waarom deze architectuur werkt 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) } } het Flow-gebaseerde ontwerp zorgt ervoor dat je gebruikersinterface responsief blijft. Audioverwerking vindt plaats op achtergrondthreads, terwijl de hoofdthread de gebruikersinteracties afhandelt. Reactieve verwerking: Elk onderdeel werkt met zijn eigen voorkeursaudioformaat. produceert ShortArray (16-bits PCM), terwijl FloatArray (genormaliseerde samples) verwacht. Conversie vindt plaats op de grens. Formaatisolatie: AudioRecorder NoiseSuppressor Als de ONNX-initialisatie mislukt, heeft dit alleen invloed op het onderdeel NoiseSuppressor. De audiorecorder en bestandsschrijvers blijven functioneren, wat zorgt voor een soepele degradatie. Foutgrenzen: Elk onderdeel beheert zijn eigen resources. De coördineert levenscyclusgebeurtenissen, maar is niet de eigenaar van de onderliggende implementaties. Resourcebeheer: ConcurrentAudioProcessor Dankzij deze modulaire aanpak kunt u de DTLN-implementatie vervangen door elk ander ONNX-model, de audiorecorder vervangen door een bestandsgebaseerde bron of het uitvoerformaat wijzigen zonder andere componenten aan te raken. De architectuur is schaalbaar van proof-of-concept tot productie-implementatie. Vervolgens verkennen we de DTLN-architectuur die deze magie mogelijk maakt. Inzicht in DTLN-architectuur Traditionele ruisonderdrukkingsmethoden hebben te maken met een fundamenteel nadeel. Frequentiedomeinmethoden zijn uitstekend in het verwijderen van stationair geluid (airconditioning, ventilatorgezoem), maar hebben moeite met dynamische geluiden zoals spraak of muziek die doorsijpelt. Tijddomeinmethoden kunnen complexe, veranderende signalen goed verwerken, maar introduceren vaak artefacten of falen bij consistente achtergrondruis. DTLN omzeilt deze beperking volledig dankzij de dual-path-architectuur: Het eerste model werkt in het frequentiedomein en analyseert de spectrale kenmerken van uw audio. Het genereert een onderdrukkingsmasker dat identificeert welke frequentiecomponenten ruis bevatten en welke spraak. Deze fase blinkt uit in het verwijderen van stationaire achtergrondruis - het constante gezoem van airconditioning, verkeer of gepraat op kantoor. Fase 1: Frequentiedomeinverwerking. // 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 } Fase 2: Verfijning van het tijdsdomein // 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 } Het gemaskeerde frequentiedomeinsignaal wordt teruggeconverteerd naar het tijdsdomein en vervolgens ingevoerd in een tweede model dat direct op de audiogolfvorm werkt. Deze fase vangt op wat de frequentieanalyse gemist heeft: dynamische ruispatronen worden verwerkt, de natuurlijkheid van de spraak behouden en eventuele artefacten uit de eerste fase worden opgeschoond. De Mobile-First Designfilosofie // 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)) De architectuur van DTLN weerspiegelt jarenlange praktische ervaring met de implementatie van mobiele AI. Bij elke ontwerpbeslissing geven we prioriteit aan realistische beperkingen boven academische benchmarks. het model verwerkt audio in chunks van 512 samples (32 ms bij 16 kHz), waarmee de optimale balans tussen latentie en context wordt bereikt. Deze chunkgrootte is klein genoeg voor realtime verwerking, maar groot genoeg om zinvolle temporele context te bieden voor de LSTM-netwerken. Chunk-gebaseerde verwerking: companion object { private const val BLOCK_LEN = 512 // 32ms chunks private const val BLOCK_SHIFT = 128 // 75% overlap for smooth processing } Stateful LSTM-netwerken companion object { private const val BLOCK_LEN = 512 // 32ms chunks private const val BLOCK_SHIFT = 128 // 75% overlap for smooth processing } Beide modellen maken gebruik van LSTM-netwerken (Long Short-Term Memory) die de interne status tussen fragmenten bijhouden. Dit tijdelijke geheugen stelt het model in staat om onderscheid te maken tussen spraak en ruis op basis van context, en niet alleen op basis van directe audiokarakteristieken. Prestatiekenmerken die ertoe doen 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 } } Inzicht in de architectuur van DTLN helpt bij het voorspellen van het gedrag ervan in uw applicatie. Deze prestatiekenmerken hebben een directe invloed op de gebruikerservaring: Latentieprofiel Algoritmische vertraging: 32 ms (verwerkingstijd van één blok) Inferentietijd: 3-4 ms per blok op Android-hardware uit het middensegment Totale latentie: ~35 ms van begin tot eind (voor de meeste gebruiksgevallen onmerkbaar) Resourcegebruik Geheugenvoetafdruk: ~28 MB tijdens actieve verwerking CPU-gebruik: 12-18% op een typisch mid-range apparaat Impact op de batterij: verwaarloosbaar bij typische opnamesessies Dankzij deze eigenschappen is DTLN bijzonder geschikt voor mobiele toepassingen waarbij gebruikers direct resultaat verwachten, zonder dat dit ten koste gaat van de apparaatprestaties of de batterijduur. ONNX Runtime Integratiestrategie ONNX Runtime op Android laten werken, gaat niet alleen over het toevoegen van een afhankelijkheid aan je build.gradle. Het verschil tussen een proof-of-concept dat crasht onder belasting en een productieklare implementatie zit in de sessieconfiguratie, het geheugenbeheer en de strategie voor resourcetoewijzing. Omdat we al een minimale runtime-build hebben voorbereid, is het tijd om te kijken wat er hierna komt. Sessieconfiguratie voor mobiele realiteit De standaard ONNX Runtime-sessieconfiguratie gaat ervan uit dat u op een server met voldoende resources draait. Mobiele apparaten werken onder heel andere omstandigheden: beperkt geheugen, thermische throttling en gebruikers die verwachten dat apps responsief blijven tijdens AI-verwerking. Je eerste reactie is misschien om alle beschikbare CPU-cores te gebruiken voor maximale prestaties. Weersta deze drang. Mobiele apparaten geven prioriteit aan batterijduur boven pure rekensnelheid, en Android's thermische beheersysteem remt agressief CPU-gebruik binnen enkele seconden af. 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) } De ideale verhouding voor realtime audioverwerking ligt tussen de 2 en 4 threads, afhankelijk van het aantal cores van uw apparaat: Deze configuratie levert 95% van de maximale prestaties en verbruikt 60% minder batterij dan een onbeperkte threadpool. Uw gebruikers merken de efficiëntiewinst meer dan het kleine verschil in latentie. private val numThreads = Runtime.getRuntime().availableProcessors().coerceIn(1, 4) activeert de meest effectieve mobiele optimalisatie van ONNX Runtime. Deze instelling analyseert de geheugentoegangspatronen van uw model tijdens de eerste paar inferentieaanroepen en wijst vervolgens vooraf geheugenpools toe om de druk op garbage collection tijdens realtimeverwerking te minimaliseren. setMemoryPatternOptimization(true) Sequentiële uitvoering lijkt misschien contra-intuïtief wanneer parallelle verwerking een hogere doorvoer biedt. Realtime audioverwerking vereist echter voorspelbare latentie boven piekprestaties. Parallelle uitvoering veroorzaakt latentiepieken wanneer threadsynchronisatie plaatsvindt - precies wat u wilt vermijden tijdens live audioverwerking. setExecutionMode(OrtSession.SessionOptions.ExecutionMode.SEQUENTIAL) Sequentiële uitvoering levert consistente inferentietijden van 3-4 ms op, terwijl parallelle uitvoering varieert van 2-8 ms met onvoorspelbare pieken. Gebruikers ervaren consistentie als kwaliteit. Geheugentoewijzing vooraf: de prestatievermenigvuldiger De meest cruciale optimalisatie voor mobiele ONNX Runtime-applicaties betreft het vooraf toewijzen van tensors die hergebruikt worden in inferentieaanroepen. Het creëren van tensors tijdens inferentie activeert geheugentoewijzingen die zich opstapelen tot aanzienlijke prestatieknelpunten. // 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) } Drukvermindering bij afvalinzameling // 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) } - Het creëren van tensoren tijdens de inferentie genereert objecten die door de garbage collector moeten worden opgehaald. Pre-allocatie verplaatst deze kosten naar de initialisatietijd, waardoor inferentiepaden vrij blijven van toewijzing. - Herhaalde tensorcreatie fragmenteert het geheugen, wat leidt tot onverwachte toewijzingsfouten. Vooraf toegewezen tensors behouden een consistente geheugenindeling. Preventie van geheugenfragmentatie - Toewijzingskosten zijn onvoorspelbaar en kunnen latentiepieken veroorzaken tijdens realtimeverwerking. Voorafgaande toewijzing zorgt voor een consistente timing van de inferentie. Consistente latentie Deze integratiestrategieën transformeren ONNX Runtime van een onderzoekstool tot een productieklare component. De configuratiekeuzes, geheugenbeheerpatronen en foutafhandelingsmethoden hebben een directe impact op de gebruikerservaring, op manieren die pas onder praktijkomstandigheden merkbaar worden. Je kunt kijken in voor de volledige broncode. https://github.com/linreal/android-onnx-showcase/blob/main/app/src/main/java/gos/denver/onnxshowcase/audio/impl/NoiseSuppressorImpl.kt Conclusie: AI als concurrentievoordeel Het mobiele AI-landschap ondergaat een fundamentele verschuiving. Terwijl concurrenten jagen op resource-intensieve taalmodellen en cloud-afhankelijke oplossingen, liggen er enorme kansen in gespecialiseerde AI op het apparaat zelf die gebruikers direct waarde oplevert. Belangrijkste punten voor Android-ontwikkelaars De combinatie van de optimalisatiemogelijkheden van ONNX Runtime en speciaal ontwikkelde modellen zoals DTLN levert prestaties die cloudoplossingen evenaren of overtreffen, terwijl latentie en connectiviteitsvereisten worden geëlimineerd. Uw gebruikers krijgen direct resultaat en u krijgt een functie die overal werkt - van metrotunnels tot vliegtuigmodus. AI op het apparaat is nu klaar voor productie. Onze minimale ONNX Runtime-build verkleinde de bibliotheekgrootte met 70% zonder in te leveren op functionaliteit. Dit gaat niet alleen over opslag, maar heeft ook direct invloed op de gebruikersacquisitie. Wanneer AI-functies 7 MB in plaats van 27 MB aan uw app toevoegen, verandert de kosten-batenverhouding aanzienlijk in uw voordeel. Optimalisatie van de APK-grootte transformeert de implementatiestrategie. DTLN is niet het meest geavanceerde ruisonderdrukkingsmodel dat er is, maar het biedt de perfecte balans tussen kwaliteit, prestaties en resourceverbruik voor mobiele implementatie. Gebruikers hechten geen waarde aan de architectuur van het model - ze hechten waarde aan kristalheldere audio in rumoerige omgevingen. Gebruikerservaring gaat boven algoritmische verfijning. Apps die AI op het apparaat implementeren, profiteren van drie concurrentievoordelen: privacy by design (geen gevoelige gegevens verlaten het apparaat), offline betrouwbaarheid (consistente ervaring, ongeacht de netwerkomstandigheden) en kostenstructuurvoordelen (geen kosten voor cloud-inferentie of operationele uitgaven die met het gebruik meeschalen). Volgende stappen en verkenning De hier gedemonstreerde technieken gaan veel verder dan ruisonderdrukking. ONNX Runtime maakt praktische implementatie van modellen mogelijk voor audioverwerking, computer vision, natuurlijke taaltaken en sensorfusietoepassingen. De volledige implementatie is beschikbaar op GitHub: Gebruik het als basis voor uw eigen AI-gestuurde functies. android-onnx-showcase Uw Android-app verdient AI die de gebruikerservaring verbetert zonder dat dit ten koste gaat van prestaties, privacy of betrouwbaarheid. ONNX Runtime maakt deze visie vandaag nog haalbaar. De tools zijn klaar, de prestaties zijn bewezen - tijd om iets geweldigs te bouwen. Vond je deze implementatie nuttig? Geef de en deel je resultaten. De mobiele AI-community wordt sterker wanneer we praktische kennis delen. GitHub-repository Volg mij voor meer diepgaande inzichten in productieklare mobiele AI-implementaties die uw gebruikers daadwerkelijk zullen opmerken en waarderen.