Cleaner Go frigjør lagringsplass på en iPhone. Appen skanner kamerarullen på enheten, grupperer doble og nesten identiske bilder, finner skjermbilder og seriebilder og lar brukeren gjennomgå resultatet med et sveip — høyre for å beholde, venstre for å slette. Et rutenett med lignende bilder gir en annen måte å velge bildet som skal beholdes på. Det samme produktet har også videokomprimering, et privat hvelv og opprydding i innboksen. Ingenting slettes uten gjennomgang, og bildematchingen krever ikke at biblioteket lastes opp.
Kundearbeid. Clutch Developer gjør mobilutvikling på denne appen med LabHouse sammen med Inés Salvans. Appen tilhører Labhouse Mobile.
Dette gjør appen
- Gjenkjenning av doble og lignende bilder i hele biblioteket, med åpenbare duplikater, visuelt lignende bilder, skjermbilder og seriebilder gruppert for en menneskelig beslutning.
- Sveipegjennomgang — behold eller slett én beslutning om gangen, velg en beholder fra et rutenett med lignende bilder og angre når et sveip må korrigeres.
- Videokomprimering som lar folk velge store klipp som skal krympes, mens originalen er under deres kontroll og presset på lagringsplassen reduseres.
- Et privat hvelv for bilder og videoer som skal holdes utenfor hovedbiblioteket, beskyttet av appens private tilgangsflyt.
- Opprydding i innboksen, fordi nyhetsbrev og reklamevedlegg kan ta plass selv når kamerarullen ikke er det eneste problemet.
Den vanskelige delen
Eksakte duplikater er enkle — hash filen og sammenlign. Det er ikke den nyttige funksjonen. Det nyttige er nesten-duplikater: flere bilder fra samme serie, det samme bildet lagret på nytt av en meldingsapp med en annen komprimering eller et skjermbilde som er beskåret litt annerledes. Filene har forskjellige bytes, men er åpenbart det samme bildet for et menneske. Brukeren trenger et gruppert forslag, et tydelig valg av hvilket bilde som skal beholdes og en reversibel beslutning, ikke en liste med hash-treff som fortsatt må tolkes fra grunnen av.
Det betyr å sammenligne visuelt innhold i stedet for bare filidentitet, og kostnaden vokser raskt med størrelsen på biblioteket. En naiv implementasjon sammenligner hvert bilde med alle andre, noe som vokser kvadratisk og raskt blir sløsende. Det praktiske arbeidet er å redusere hvert bilde til en kompakt signatur, bruke kandidatgrupper slik at bare sannsynlige par møtes og sammenligne kandidatene uten å dekode hvert fulloppløselige bilde på nytt hver gang. Resultatet må gruppere lignende bilder godt nok, samtidig som den endelige beslutningen blir hos personen som tok dem.
Deretter må arbeidet få plass i en telefon. Den første skanningen berører hele biblioteket, er den dyreste delen av opplevelsen og skjer når en ny bruker har minst tålmodighet. Fremdriften må være synlig, tusenvis av fulloppløselige bilder må ikke holdes i minnet, og appen må oppføre seg fornuftig når den går i bakgrunnen eller enheten begynner å håndtere varme og batteri. Etter skanningen må brukeren også få en forståelig gjennomgang: grupper, valg av bildet som skal beholdes, sveipebeslutninger, angre og et uttrykkelig bekreftelsestrinn.
Grensen for lokal analyse er konkret. Bildeskanningen og likhetsarbeidet skjer på enheten, så biblioteket trenger ikke lastes opp til en server for matching. Det må ikke bli til en generell påstand om at appen ikke har noen datapraksis: Den offentlige personverndelen i App Store oppgir separat identifikatorer, bruk og diagnostikk, i tillegg til data knyttet til brukerstøtte. Den presise påstanden i denne casen handler om hvor den tunge bildeanalysen kjøres.
Dette krever det
- Perseptuelle signaturer per bilde, ikke bare filhash — billige å beregne og sammenligne.
- Kandidatgrupper slik at sammenligningen ikke blir kvadratisk på tvers av et stort bibliotek.
- Nedskalert dekoding, slik at minnet holdes under kontroll selv når kildebildene har høy oppløsning.
- Inkrementell behandling som holder grensesnittet responsivt mens enheten skanner og komprimerer.
- Ingenting destruktivt uten gjennomgang — grupperte forslag, uttrykkelig bekreftelse, valg av bilde som skal beholdes og angre.
Dette er hva ytelsesarbeid i native apputvikling faktisk innebærer: ikke å mikrooptimalisere en gjengivelsesløkke, men å velge en algoritme og en gjennomgangsflyt med kostnad og risiko som passer i en telefon du ikke kontrollerer. Leveransen lykkes når det tunge arbeidet forsvinner bak en beslutning brukeren forstår.
Omfang og prosjektrolle
Clutch Developer bidro med mobilutvikling til denne kundeeide appen, blant annet gruppering av bilder på enheten og gjennomgangsflyten som beskrives her. Labhouse Mobile eier appen; Labhouse og Inés Salvans er kreditert i notatet ovenfor. Casen beskriver dette bidraget, ikke eneansvar for hele produktet.
Dokumentasjon og begrensninger
De lagrede appbildene viser lagringsoversikter og handlinger for bildegjennomgang; den lenkede butikkoppføringen beskriver matching på enheten. Det gjør den synlige flyten og den publiserte informasjonen mulig å kontrollere, men er ingen uavhengig vurdering av nøyaktighet, hastighet eller sikkerhet. Sletting krever fortsatt brukerens gjennomgang og bekreftelse.