[Enhancement] Add memory pressure auto-cleanup service to prevent OOM kills on low-end devices

[RUKAYAT-CODER]

Overview

The app targets users on low-end Android devices (2GB RAM common in target markets). Long sessions accumulate memory from image caches, metrics buffers, search indexes, and Redux-like subscription closures. No cleanup mechanism exists to respond to OS memory pressure warnings. iOS calls didReceiveMemoryWarning and Android fires onTrimMemory; ignoring these leads to OOM process kills.

Specifications

Features:

• memoryPressureService subscribes to native memory warning events
• On warning: flush metrics buffers, clear non-critical image cache, compact search index
• Expose memoryPressureLevel in deviceStore (normal, warning, critical)
• critical level triggers degradationStore.disableFeature for high-memory features

Tasks:

• Create src/services/memoryPressureService.ts
• Use AppRegistry.registerHeadlessTask or RN's internal 'memoryWarning' event
• On warning, call imageCache.clearNonCritical(), metricsService.flush(), searchIndex.compact()
• Dispatch setMemoryPressureLevel to deviceStore
• Add unit test simulating memory warning event

Impacted Files:

• src/services/memoryPressureService.ts (create)
• src/store/slices/deviceStore.ts
• src/store/slices/degradationStore.ts

Acceptance Criteria

• Memory warning event triggers cleanup of non-critical caches
• deviceStore.memoryPressureLevel updates on warning
• Critical pressure disables at least one high-memory feature via degradationStore
• Unit test confirms cleanup methods called on warning event

[Guddy1-tech]

@Guddy1-tech has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

I’d like to work on this issue because it matches my current learning path and will help me improve my software engineering skills. I have experience with Java, Python, JavaScript, React, APIs, and Git/GitHub, and I’m currently building real-world projects. I’m eager to contribute.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Guddy1-tech to this issue.

[AGWAM001]

@AGWAM001 has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Please assign, I can work on it

ℹ️ Repo Maintainers: To accept this application, review their application or assign @AGWAM001 to this issue.

[rosemary21]

@rosemary21 has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

I'd like to work on this issue because it improves the application's stability on resource-constrained devices, which are common in the target user base. React Native applications that run for extended periods can accumulate memory through caches, subscriptions, and in-memory indexes, and responding appropriately to operating system memory pressure events is essential to reducing the likelihood of process termination. Implementing a centralized memory pressure service will make the app more resilient while providing a clear foundation for future optimizations.

I have experience developing React Native applications with TypeScript, implementing platform-aware services, optimizing application performance, and working with state management solutions such as Redux and Redux Toolkit. I've built services that respond to application lifecycle events, optimized image caching strategies, managed background tasks, and written unit tests for event-driven functionality. I'm also familiar with designing features that degrade gracefully under constrained system resources without affecting core functionality.

For this issue, I would:

Create src/services/memoryPressureService.ts to centralize memory pressure handling.
Subscribe to the appropriate React Native memory warning events, ensuring compatibility with both iOS (memoryWarning) and Android's memory pressure mechanisms where supported by the project's native integration.
On receiving a warning, invoke the required cleanup operations:
imageCache.clearNonCritical()
metricsService.flush()
searchIndex.compact()
Dispatch setMemoryPressureLevel to deviceStore, exposing the current state (normal, warning, or critical) for use throughout the application.
Integrate with degradationStore so that critical memory pressure automatically disables high-memory features while preserving essential functionality.
Keep the service modular so additional cleanup handlers can be registered in the future without modifying core logic.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @rosemary21 to this issue.

[MoscowDev]

@MoscowDev has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

I’d love to take this issue on. I’ve worked on production-ready applications and collaborated extensively through GitHub workflows. I’ll dig into the current setup, implement a solid and reliable fix, and deliver a well-tested PR. My focus is on clean, maintainable code and fast, dependable delivery.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @MoscowDev to this issue.

[xtrial01]

@xtrial01 has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Hi, I would like to resolve this issue

kindly assign and i will get it done

ℹ️ Repo Maintainers: To accept this application, review their application or assign @xtrial01 to this issue.

[boalambo]

@boalambo has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Hello maintainer, I would like to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @boalambo to this issue.

[collinsezedike]

@collinsezedike has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

GM Rukayat,

I've built memory pressure response systems for low-end Android targets before. The cleanup order matters here: flushing the metrics buffer and compacting the search index can themselves allocate memory briefly, so they need to run before the cache clear, not after, or you risk a momentary spike right as you're trying to recover.

Here's my plan:

• src/services/memoryPressureService.ts: subscribe to the native memory warning event (RN's memoryWarning event on iOS, onTrimMemory equivalent on Android)
• On warning: run metricsService.flush() and searchIndex.compact() first since they free their own working memory as a side effect, then imageCache.clearNonCritical() last, to net out lower peak memory during cleanup
• Map the warning severity to normal/warning/critical and dispatch setMemoryPressureLevel to deviceStore
• On critical, call degradationStore.disableFeature for at least one identified high-memory feature
• Unit test simulating the warning event at each severity level, asserting the correct cleanup methods fire and the store updates accordingly

Happy to start as soon as I'm assigned.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @collinsezedike to this issue.