Mobil AI med ONNX Runtime: Hur man bygger brusreducering i realtid som fungerar

Din telefon är kraftfullare än en stationär dator från för fem år sedan. De senaste flaggskepps-Android-enheterna har neurala processorer, flerkärniga processorer som skulle göra bärbara datorer från 2019 avundsjuka och RAM-konfigurationer som verkade omöjliga för bara några år sedan. Så varför känns det som att vi knappt skrapar på ytan av vad som är möjligt med AI på mobilen? Visst, du kan nu till och med köra kvantiserade versioner av Llama- och DeepSeek-modeller lokalt på din enhet. Men låt oss vara ärliga – de där konversationerna känns fortfarande klumpiga, långsamma och inte alls i närheten av den sömlösa upplevelse som användarna förväntar sig av sina appar. Hajpen kring konversations-AI på enheter är verklig, men den praktiska verkligheten? Vi är inte riktigt där än. Det är här de flesta utvecklare missar möjligheten: konversationsbaserad AI är inte det enda spelet i stan. Medan alla jagar nästa ChatGPT-klon finns det en enorm outnyttjad potential i specialiserade AI-applikationer som faktiskt fungerar briljant på mobil hårdvara . just nu Ta brusreducering. Dina användare kämpar ständigt mot bakgrundsljud under samtal, inspelningar och röstmeddelanden. Vind, trafik, gråtande bebisar, skällande hundar – det är ett oändligt krig mot ljudkaos. Men tänk om din app kunde eliminera det bruset i realtid, lokalt, utan att skicka en enda byte till molnet? Det här är inte science fiction. Det händer idag, och vilken Android-utvecklare som helst kan implementera det. Verktygen är mogna, prestandan finns där, och dina användare kommer omedelbart att märka skillnaden. ONNX Runtime: Din port till mobil AI Det mobila AI-landskapet är fragmenterat. PyTorch dominerar forskning, TensorFlow-regler produceras och otaliga specialiserade ramverk dyker upp för specifika användningsfall. För Android-utvecklare skapar detta ett smärtsamt val: att binda sig till ett ekosystem eller att underhålla separata pipelines för olika modeller. Efter att ha utvärderat mobila AI-ramverk valde vi ONNX Runtime av flera övertygande skäl som direkt påverkar Android-utveckling. Bredare kompatibilitet mellan Android-versioner Till skillnad från Googles LiteRT (tidigare TensorFlow Lite), som kräver en lägsta SDK-nivå på 31 (Android 12), stöder ONNX Runtime enkelt Android API-nivåer så låga som 24 (eller till och med 21, om du är en trollkarl). Vårt projekts lägsta stödda version var API 28, vilket gör ONNX Runtime till det självklara valet för att nå en bredare publik utan att exkludera miljontals aktiva användare på Android 10 och tidigare enheter. Sömlös integration mellan olika ramverk ONNX Runtimes största styrka ligger i dess ramverksagnostiska natur. Oavsett om dina AI-modeller kommer från PyTorch, TensorFlow eller till och med traditionella ML-bibliotek som scikit-learn, möjliggör export av modeller till ONNX enhetlig distribution över Android-, iOS-, dator- och molnmiljöer. Denna flexibilitet förenklar underhållet avsevärt och möjliggör en enhetlig pipeline snarare än att jonglera flera ramverksspecifika verktyg. Lätt och modulär implementering Integrationen med ONNX Runtime är enkel. Med en kompakt Maven AAR (cirka 5–7 MB för CPU-versioner) integreras biblioteket smidigt i din befintliga Android-app utan att introducera onödiga beroenden som Google Play Services eller begära ytterligare användarbehörigheter. Denna strömlinjeformade distribution håller din app smidig, effektiv och säker. Bevisad prestanda i realtid ONNX Runtime är testad i krävande realtidsscenarier. Ljudbehandlingsmodeller, som brusreducering eller talförbättring, levererar konsekvent inferenshastigheter under 4 ms per ljudbildruta på standard mobil hårdvara – bekvämt inom realtidsprestandakraven. Vårt team utnyttjade just denna funktion för pålitlig brusreducering med låg latens. I slutändan gav ONNX Runtime vårt team inte bara bekvämlighet, utan även strategiska fördelar – vilket gjorde det möjligt för oss att upprätthålla kompatibilitet, prestanda och enkelhet utan kompromisser. Om ditt projekt kräver tillgänglig, effektiv och skalbar mobil AI kan ONNX Runtime mycket väl vara ditt optimala val. Integrationsplan: Konfigurera ONNX Runtime Standardpaketet för ONNX Runtime väger in på rejäla 27 MB. För en mobilapp är det inte bara en uppsvällning – det är en källa till användarförvärv. Forskning visar att för varje 6 MB ökning av APK-storleken minskar installationskonverteringsfrekvensen med 1 % (jag bör notera att studien inte är den nyaste och främst inte gäller de mest utvecklade länderna, men det är ändå värt att överväga). Lösningen? En anpassad minimalistisk version som reducerar din implementering till exakt vad du behöver. Vår DTLN-brusreduceringsimplementering klockar in på bara 7,1 MB – en 70 % storleksminskning som håller din app smidig och dina användare nöjda. ONNX Runtimes arkitektur är modulär till sin design. Hela paketet inkluderar exekveringsleverantörer för GPU-acceleration (NNAPI, Vulkan), dussintals operatorer som du aldrig kommer att använda och kompatibilitetslager för edge-fall som inte gäller för din specifika modell. Genom att bara bygga det du behöver eliminerar du denna overhead helt. Steg 1: Konvertera dina modeller till ORT-format Innan du bygger, konvertera dina ONNX-modeller till ORT-format. Detta optimerade format tar bort oanvända grafnoder och operatordefinitioner, vilket ytterligare minskar din slutliga binära storlek. Steg 2: Skapa operatörskonfiguration python -m onnxruntime.tools.convert_onnx_models_to_ort --target_platform {arm,amd64} Efter att alla nödvändiga modeller har konverterats kommer även konfigurationsfiler med de nödvändiga operatorerna som krävs för den minimala versionen av ONNX att genereras. När du använder flera modeller, kombinera alla konfigurationsfiler till en. Den slutliga filen kommer att se ut ungefär så här: # 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 Steg 3: Kör en anpassad version # 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 Med din operatörskonfiguration klar, bygg ONNX Runtime från källkod med minimala beroenden: --minimal_build: Exkluderar onödiga exekveringsleverantörer och operatorer ./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: Inkluderar endast operatorer som anges i din konfigurationsfil --android_abi armeabi-v7a: Riktar sig mot ARM32 för maximal enhetskompatibilitet --android_api 24: Bibehåller kompatibilitet med Android 7.0+ Om du även vill stödja gamla enheter, upprepa steg 3 med –android_abi armeabi-v7a och sammanfoga båda resulterande aar-filerna med följande skript: Den minimalistiska byggmetoden förvandlar ONNX Runtime från en distributionsbelastning till en strategisk fördel. Dina användare får full AI-kapacitet utan överflöd, och din app bibehåller den smidiga profil som modern mobilutveckling kräver. #!/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" Låt oss nu se denna optimerade körtid i aktion med DTLN-brusundertryckning i realtid. Varför ljudbehandling visar upp AI-värde Ljudbehandling är den perfekta introduktionen till mobil AI – den levererar omedelbart och konkret värde medan dina konkurrenter brottas med uppblåsta språkmodeller som tömmer batterier och kräver konstanta internetanslutningar. Det dagliga ljudkriget som dina användare utkämpar Sarah spelar in röstmeddelanden medan hon går genom en trafikerad gata. Mellan tutande taxibilar, vägarbeten och tunnelbanebuller spelar hon in meddelanden igen tre gånger innan hon ger upp och skriver istället. Marcus deltar i kundsamtal från sitt hemmakontor, som även fungerar som hans småbarns lekrum. Varje presentation blir en cykel av "ljudlös, ljudlös och be om ursäkt för gråten". Elena skapar YouTube-innehåll i sin lägenhet men tillbringar timmar i efterproduktionen med att städa upp grannarnas buller, trafik och luftkonditioneringens brummande. Det här är inte marginalfall – det är verkligheten inom modern mobil databehandling där alla förväntar sig professionella resultat från konsumenthårdvara i kaotiska miljöer. Varför brusreducering skapar omedelbara "wow"-ögonblick Förbättringar av ljudkvaliteten utlöser omedelbara känslomässiga reaktioner. Till skillnad från andra AI-applikationer som kräver förklaring ger brusreducering omedelbar tillfredsställelse som användarna kan uppfatta inom några sekunder. Spela upp någons egen röst – kristallklart – efter att bakgrundsljud har tagits bort och se deras reaktion. De behöver inte förstå LSTM-nätverk; de vet bara att deras ljud låter professionellt. Det fina med ljudbehandling som ett AI-exemplar ligger i universaliteten. Alla förstår bra ljud, alla har upplevt dåligt ljud, och alla ser omedelbart en förbättring när bruset försvinner. Du ber inte användarna att lita på din AI – du bevisar dess värde på det mest direkta sättet. Bygga en produktionsklar demo: Brusreducering i realtid Nu ska vi bygga ett exempelprojekt som demonstrerar den praktiska kraften hos ONNX Runtime på Android. Istället för ett grundläggande "hej världen"-exempel ska vi skapa något som liknar produktionskvalitet – en demonstration av brusreducering i realtid där användare kan spela in ljud i bullriga miljöer och uppleva den slående skillnaden mellan originalinspelningen och den AI-rengjorda versionen. Du kan hitta ett komplett exempel här, på min Github: . https://github.com/linreal/android-onnx-showcase Modeller som används i exemplet är från https://github.com/breizhn/DTLN Snabb implementeringsöversikt Innan vi dyker in i DTLN:s dual-path-arkitektur, låt oss se hur delarna passar ihop. Det fina med denna implementering ligger i dess tydliga separation av bekymmer – varje komponent har ett enda ansvar, vilket gör systemet både testbart och underhållbart. Kärnkomponenterna I hjärtat av vår pipeline för brusreducering finns tre viktiga gränssnitt som samverkar: NoiseSuppressorn kapslar in all ONNX Runtime-komplexitet bakom ett enkelt gränssnitt. Mata in ljudbitar och få tillbaka brusreducerat ljud. DTLN:s tillståndskänsliga natur är helt dold – implementeringen upprätthåller LSTM-tillstånd internt mellan anrop. 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 } Dataflödesarkitektur ConcurrentAudioProcessor orkestrerar hela pipelinen. Den prenumererar på ljudinspelarens flöde, konverterar ljudformat, bearbetar segment genom brusreduceraren och skriver både original- och bearbetat ljud till filer samtidigt. AudioRecorder → Flow → ConcurrentAudioProcessor → NoiseSuppressor → Processed Audio Files Varför den här arkitekturen fungerar 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) } } Den flödesbaserade designen säkerställer att ditt användargränssnitt förblir responsivt. Ljudbearbetning sker i bakgrundstrådar medan huvudtråden hanterar användarinteraktioner. Reaktiv bearbetning: Varje komponent arbetar med sitt föredragna ljudformat. producerar ShortArray (16-bitars PCM), medan förväntar sig FloatArray (normaliserade samplingar). Konvertering sker vid gränsen. Formatisolering: AudioRecorder NoiseSuppressor Om ONNX-initieringen misslyckas påverkas endast NoiseSuppressor-komponenten. Ljudinspelaren och filskrivarna fortsätter att fungera, vilket säkerställer en smidig nedbrytning. Felgränser: Varje komponent hanterar sina egna resurser. koordinerar livscykelhändelser men äger inte de underliggande implementeringarna. Resurshantering: ConcurrentAudioProcessor Denna modulära metod innebär att du kan byta ut DTLN-implementeringen mot vilken annan ONNX-modell som helst, ersätta ljudinspelaren med en filbaserad källa eller ändra utdataformatet utan att behöva röra andra komponenter. Arkitekturen skalas från koncepttest till produktionsdistribution. Härnäst ska vi utforska DTLN-arkitekturen som gör denna magi möjlig. Förstå DTLN-arkitekturen Traditionella brusreduceringsmetoder står inför en grundläggande avvägning. Frekvensdomänmetoder utmärker sig på att ta bort stationärt brus (luftkonditionering, fläktbrus) men har svårt att dynamiska ljud som tal eller musik ska tränga igenom. Tidsdomänmetoder hanterar komplexa, föränderliga signaler väl men introducerar ofta artefakter eller misslyckas med ihållande bakgrundsbrus. DTLN kringgår denna begränsning helt genom sin dual-path-arkitektur: Den första modellen arbetar i frekvensdomänen och analyserar ljudets spektrala egenskaper. Den genererar en dämpningsmask som identifierar vilka frekvenskomponenter som innehåller brus kontra tal. Detta steg utmärker sig på att ta bort stationärt bakgrundsbrus – det stadiga surret från luftkonditionering, trafik eller kontorsprat. Steg 1: Frekvensdomänbehandling // 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 } Steg 2: Förfining av tidsdomänen // 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 } Den maskerade frekvensdomänsignalen konverteras tillbaka till tidsdomänen och matas sedan in i en andra modell som arbetar direkt med ljudvågformen. Detta steg fångar upp det som frekvensanalysen missade – hantering av dynamiska brusmönster, bevarande av talets naturlighet och rensning av eventuella artefakter från det första steget. Mobil-först-designfilosofin // 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)) DTLN:s arkitektur återspeglar många års praktisk erfarenhet av mobil AI-implementering. Varje designbeslut prioriterar verkliga begränsningar framför akademiska riktmärken. Modellen bearbetar ljud i 512-samplingsbitar (32 ms vid 16 kHz) och uppnår den optimala balansen mellan latens och kontext. Denna bitstorlek är tillräckligt liten för realtidsbearbetning men tillräckligt stor för att ge meningsfull tidsmässig kontext för LSTM-nätverken. Chunk-baserad bearbetning companion object { private const val BLOCK_LEN = 512 // 32ms chunks private const val BLOCK_SHIFT = 128 // 75% overlap for smooth processing } Tillståndskänsliga LSTM-nätverk companion object { private const val BLOCK_LEN = 512 // 32ms chunks private const val BLOCK_SHIFT = 128 // 75% overlap for smooth processing } Båda modellerna använder LSTM-nätverk (Long Short-Term Memory) som upprätthåller internt tillstånd mellan segment. Detta temporala minne gör det möjligt för modellen att skilja mellan tal och brus baserat på kontext, inte bara momentana ljudegenskaper. Prestandaegenskaper som är viktiga 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 } } Att förstå DTLN:s arkitektur hjälper till att förutsäga dess beteende i din applikation. Dessa prestandaegenskaper påverkar direkt användarupplevelsen: Latensprofil Algoritmisk fördröjning: 32 ms (behandlingstid för en bit) Inferenstid: 3–4 ms per bit på mellanstor Android-hårdvara Total latens: ~35 ms från början till slut (omärkbar i de flesta användningsfall) Resursanvändning Minnesutrymme: ~28 MB under aktiv bearbetning CPU-användning: 12–18 % på en typisk mellanklassenhet Batteripåverkan: Försumbar för typiska inspelningssessioner Dessa egenskaper gör DTLN särskilt väl lämpad för mobila applikationer där användare förväntar sig omedelbara resultat utan att offra enhetens prestanda eller batteritid. ONNX Runtime-integrationsstrategi Att få ONNX Runtime att fungera på Android handlar inte bara om att lägga till ett beroende till din build.gradle. Skillnaden mellan ett proof-of-concept som kraschar under belastning och en produktionsklar implementering ligger i sessionskonfigurationen, minneshanteringen och resursallokeringsstrategin. Eftersom vi redan förberett en minimal runtime-version är det dags att titta på vad som väntar härnäst. Sessionskonfiguration för mobil verklighet Standardkonfigurationen för ONNX Runtime-sessioner förutsätter att du kör på en server med rikliga resurser. Mobila enheter fungerar under helt andra begränsningar: begränsat minne, termisk strypning och användare som förväntar sig att appar ska förbli responsiva under AI-bearbetning. Din första instinkt kan vara att använda alla tillgängliga CPU-kärnor för maximal prestanda. Motstå denna impuls. Mobila enheter prioriterar batteritid framför rå beräkningshastighet, och Androids värmehantering kommer att strypa aggressiv CPU-användning inom några sekunder. 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) } Den optimala punkten för realtidsljudbehandling ligger mellan 2–4 trådar, bestämt av enhetens kärnantal: Den här konfigurationen ger 95 % av maximal prestanda samtidigt som den förbrukar 60 % mindre batteri än en obegränsad trådpool. Dina användare märker effektivitetsvinsterna mer än den lilla skillnaden i latens. private val numThreads = Runtime.getRuntime().availableProcessors().coerceIn(1, 4) aktiverar ONNX Runtimes mest effektiva mobiloptimering. Den här inställningen analyserar din modells minnesåtkomstmönster under de första inferensanropen och förallokerar sedan minnespooler för att minimera skräpinsamlingstrycket under realtidsbearbetning. setMemoryPatternOptimization(true) Sekventiell exekvering kan verka kontraintuitivt när parallell bearbetning erbjuder högre dataflöde. Ljudbearbetning i realtid kräver dock förutsägbar latens framför topprestanda. Parallell exekvering skapar latenstoppar när trådsynkronisering sker – precis vad man vill undvika under live-ljudbearbetning. setExecutionMode(OrtSession.SessionOptions.ExecutionMode.SEQUENTIAL) Sekventiell exekvering ger konsekventa inferenstider på 3–4 ms, medan parallellt läge varierar från 2–8 ms med oförutsägbara toppar. Användare uppfattar konsekvens som kvalitet. Minnesförallokering: Prestandamultiplikatorn Den viktigaste optimeringen för mobila ONNX Runtime-applikationer involverar förallokering av tensorer som återanvänds vid olika inferensanrop. Att skapa tensorer under inferens utlöser minnesallokeringar som ackumuleras till betydande prestandaflaskhalsar. // 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) } Tryckreducering för sophämtning // 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) } - Att skapa tensorer under inferens genererar objekt som måste skräpsamlas. Förallokering flyttar denna kostnad till initialiseringstiden, vilket håller inferensvägarna fria från allokering. - Upprepade tensorfragment skapas och lagrar minne, vilket leder till oväntade allokeringsfel. Förallokerade tensorer upprätthåller en konsekvent minneslayout. Förebyggande av minnesfragmentering – Allokeringskostnader är oförutsägbara och kan orsaka latenstoppar under realtidsbehandling. Förallokering säkerställer konsekvent inferenstidpunkt. Latenskonsekvens Dessa integrationsstrategier omvandlar ONNX Runtime från ett forskningsverktyg till en produktionsklar komponent. Konfigurationsvalen, minneshanteringsmönstren och felhanteringsmetoderna påverkar direkt användarupplevelsen på sätt som bara blir uppenbara under verkliga användningsförhållanden. Du kan titta in för en fullständig källkod. https://github.com/linreal/android-onnx-showcase/blob/main/app/src/main/java/gos/denver/onnxshowcase/audio/impl/NoiseSuppressorImpl.kt Slutsats: AI som konkurrensfördel Det mobila AI-landskapet upplever ett fundamentalt skifte. Medan konkurrenterna jagar resurskrävande språkmodeller och molnberoende lösningar, finns det en enorm möjlighet inom specialiserad, enhetsbaserad AI som ger omedelbart värde till användarna. Viktiga lärdomar för Android-utvecklare Kombinationen av ONNX Runtimes optimeringsfunktioner och specialbyggda modeller som DTLN levererar prestanda som matchar eller överträffar molnlösningar samtidigt som den eliminerar latens- och anslutningskrav. Dina användare får omedelbara resultat, och du får en funktion som fungerar överallt – från tunnelbanetunnlar till flygplansläge. AI på enheter är produktionsklar idag. Vår minimalistiska ONNX Runtime-version minskade biblioteksstorleken med 70 % utan att offra funktionalitet. Det här handlar inte bara om lagring – det påverkar direkt användarförvärv. När AI-funktioner lägger till 7 MB istället för 27 MB till din app, förändras kostnads-nytto-ekvationen dramatiskt till din fördel. Optimering av APK-storlek förändrar distributionsstrategin. DTLN är inte den mest avancerade brusreduceringsmodellen som finns, men den hittar den perfekta balansen mellan kvalitet, prestanda och resursförbrukning för mobil distribution. Användare bryr sig inte om modellarkitekturen – de bryr sig om kristallklart ljud i bullriga miljöer. Användarupplevelsen trumfar algoritmisk sofistikering. Appar som implementerar AI på enheten får tre konkurrensfördelar: Inbyggd integritet (ingen känslig data lämnar enheten), tillförlitlighet offline (konsekvent upplevelse oavsett nätverksförhållanden) och kostnadsstrukturfördelar (inga kostnader för molninferens eller driftskostnader som skalas med användningen). Nästa steg och utforskning Teknikerna som demonstreras här sträcker sig långt bortom brusreducering. ONNX Runtime möjliggör praktisk implementering av modeller för ljudbehandling, datorseende, naturligt språk och sensorfusionsapplikationer. Den fullständiga implementeringen finns tillgänglig på GitHub: Använd den som en grund för dina egna AI-drivna funktioner. android-onnx-showcase Din Android-app förtjänar AI som förbättrar användarupplevelsen utan att kompromissa med prestanda, integritet eller tillförlitlighet. ONNX Runtime gör denna vision möjlig idag. Verktygen är redo, prestandan är bevisad – dags att bygga något fantastiskt. Tyckte du att den här implementeringen var användbar? Markera med stjärnan och dela dina resultat. Den mobila AI-gemenskapen blir starkare när vi delar praktisk kunskap. GitHub-arkiv Följ mig för fler djupdykningar i produktionsklara mobila AI-implementeringar som dina användare faktiskt kommer att märka och uppskatta.