onStart: essensen, synligheten av Activity på Android-skärmen

Essensen av metoden onStart i Android

onStart — den andra metoden i Activitys livscykel, anropad av systemet efter onCreate (eller efter onRestart vid återgång från stoppat tillstånd). I anropsögonblicket blir Activity eller Fragment synliga på skärmen. Användaren ser gränssnittet, men skärmen är ännu inte redo för interaktion — inmatningsfokus visas först efter onResume.

Metoden onStart ingår i Activitys "synliga livslängd" (visible lifetime) — intervallet mellan onStart och onStop. Under denna period kan Activity delvis täckas av andra fönster (till exempel ett transparent Activity eller dialogruta), men dess användargränssnitt förblir synligt. Detta skiljer den synliga livslängden från "livslängden i förgrunden" (onResume — onPause), när Activity har fullt inmatningsfokus.

Att förstå denna tre-nivåers hierarki är kritiskt viktigt för korrekt fördelning av kod. onCreate — engångsinitiering, onStart — anslutning av synliga resurser, onResume — monopolåtkomst till exklusiva resurser. En utvecklare som blandar ihop dessa nivåer riskerar att skapa minnesläckor eller felaktigt beteende hos appen vid växling mellan skärmar.

onStart i Activity

I Activity anropas metoden onStart varje gång skärmen visas på displayen — både vid första start (efter onCreate) och vid återgång från bakgrundsläge (efter onRestart). Till skillnad från onCreate kan onStart anropas flera gånger under en Activity-instans livstid, därför placeras här kod som ska utföras varje gång skärmen visas.

class DashboardActivity : AppCompatActivity() {
    private val connectivityReceiver = object : BroadcastReceiver() {
        override fun onReceive(context: Context?, intent: Intent?) {
            val isConnected = ... // kontroll av ConnectivityManager
            binding?.statusIndicator?.setColor(
                if (isConnected) Color.GREEN else Color.RED
            )
        }
    }

    override fun onStart() {
        super.onStart()
        registerReceiver(
            connectivityReceiver,
            IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION)
        )
        SensorManager.getInstance().registerStepCounter()
    }

    override fun onStop() {
        unregisterReceiver(connectivityReceiver)
        SensorManager.getInstance().unregisterStepCounter()
        super.onStop()
    }
}

Huvudregel: alla resurser som anslutits i onStart måste frigöras i onStop. Detta garanterar att när Activity är dold från skärmen, förbrukar den inte batteri, lyssnar inte på systemhändelser och upptar inte minne. Android Studio innehåller lint-regler som varnar för registrering av BroadcastReceiver utan motsvarande avregistrering.

onStart i Fragment

onStart i Fragment är nära kopplat till livscykeln för container-Activity. Fragment får onStart-anropet efter att Activity som innehåller det har fått onStart. Men om Fragment har lagts till i uppskjutet läge (FragmentTransaction.commit() utan addToBackStack), kan onStart anropas med fördröjning.

class MapFragment : Fragment() {
    private var mapView: MapView? = null

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        mapView = MapView(requireContext())
        return mapView!!
    }

    override fun onStart() {
        super.onStart()
        mapView?.onStart()
        LocationService.connect(requireContext())
    }

    override fun onStop() {
        mapView?.onStop()
        LocationService.disconnect()
        super.onStop()
    }
}

Specificitet för Fragment.onStart: om Fragment befinner sig i en ViewPager med offscreenPageLimit = 1, kommer angränsande fragment också att få onStart innan de blir synliga. Detta kan leda till förtida registrering av lyssnare. För sådana fall, använd metoden setUserVisibleHint() eller kontroll av isVisible inuti onStart för att registrera lyssnare endast för verkligt synliga fragment.

Skillnad mellan onStart och onResume

Huvudskillnaden mellan onStart och onResume — nivån av skärmaktivitet. onStart signalerar att Activity är synligt på skärmen, men inte nödvändigtvis i förgrunden. onResume signalerar att Activity är i förgrunden och har inmatningsfokus. Skillnaden demonstreras med exemplet på en dialogruta: när en Dialog visas ovanför Activity, förlorar Activity onResume (onPause anropas), men förblir synlig — onStart/onStop anropas inte.

Skillnadstabellen visar tydligt i vilka scenarier varje metod anropas:

Denna tabell hjälper utvecklaren att besluta i vilken metod specifik kod ska placeras. Om appen till exempel måste pausa videouppspelning vid varje övertäckning av skärmen (även med en dialog), placeras koden i onPause. Om videon endast ska stoppas vid fullständig döljning av skärmen — placeras koden i onStop.

Registrering av lyssnare och tjänster

onStart — optimal plats för registrering av lyssnare som endast ska fungera medan Activity är synligt på skärmen. Detta gäller tre huvudtyper av systemkomponenter: BroadcastReceiver för systemhändelser, LocationListener för geolokalisering och SensorListener för enhetssensorer.

BroadcastReceiver i onStart

BroadcastReceiver registreras dynamiskt via Context.registerReceiver() i onStart och avregistreras i onStop via unregisterReceiver(). Dynamisk registrering är att föredra framför statisk (i manifestet), eftersom den begränsar mottagarens livslängd till Activitys synlighetsperiod — appen vaknar inte av systemets broadcast-meddelanden när Activity är dolt.

private val batteryReceiver = object : BroadcastReceiver() {
    override fun onReceive(context: Context?, intent: Intent) {
        val level = intent.getIntExtra(BatteryManager.EXTRA_LEVEL, -1)
        binding?.batteryText?.text = "$level%"
    }
}

override fun onStart() {
    super.onStart()
    registerReceiver(batteryReceiver, IntentFilter(Intent.ACTION_BATTERY_CHANGED))
}

override fun onStop() {
    unregisterReceiver(batteryReceiver)
    super.onStop()
}

LocationListener och SensorListener

Geolokalisering och sensorer — resurskrävande operationer. Begäran av GPS-uppdateringar i onStart och annullering i onStop garanterar att appen inte förbrukar batteri när skärmen är dold. För finjustering används requestLocationUpdates med minimalt intervall och distans — till exempel 10 sekunder och 10 meter, vilket ger en optimal balans mellan noggrannhet och energiförbrukning.

Animationer och onStart

Start av animationer i onStart, inte i onCreate, garanterar att animationen startar varje gång skärmen visas. Om du startar animationen i onCreate fungerar den endast vid första skapandet av Activity, men inte vid återgång från bakgrundsläge. onStart anropas varje gång Activity blir synligt, vilket gör det till en idealisk plats för start av cykliska animationer och övergångar.

private lateinit var pulseAnimator: ValueAnimator

override fun onStart() {
    super.onStart()
    pulseAnimator.start()
    binding?.loadingIndicator?.animate()?.alpha(1f)?.start()
}

override fun onStop() {
    pulseAnimator.cancel()
    binding?.loadingIndicator?.animate()?.cancel()
    super.onStop()
}

För animationer som använder ObjectAnimator eller ValueAnimator är det viktigt att anropa cancel() i onStop. Om animationen fortsätter att fungera efter att Activity dolts, förbrukar den onödigt GPU- och CPU-resurser, vilket minskar enhetens prestanda och påskyndar batteriurladdningen. Android Studio Profiler (GPU-graf) gör det möjligt att spåra aktiva animationer och upptäcka läckor.

Regeln om paret onStart/onStop gäller även arbete med kamera för förhandsvisning (CameraX). Öppning av kameran i onStart och stängning i onStop garanterar att kameran inte är blockerad för andra appar när din app inte är synlig på skärmen. Överträdelse av denna regel är en av de vanliga orsakerna till negativa recensioner på Google Play.