# Memory Leaks Published articles for Memory Leaks. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## GNOME Shotwell 33 Photo Manager Released With GTK4 Port DevFeed: [GNOME Shotwell 33 Photo Manager Released With GTK4 Port]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-13T10:40:50Z Content type: news Language: en Sources: [Phoronix]() Topics: [releases](), [Memory Leaks](), [bug]() Tags: [bug-fixes](), [desktop-linux](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [memory-leaks](), [news](), [open-source-graphics](), [phoronix](), [phoronix-test-suite](), [release](), [releases](), [ubuntu-benchmarks](), [ubuntu-hardware](), [ui]() ### AI overview Shotwell 33 is a major release of the GNOME photo manager that ports its user interface from GTK3 to GTK4. It also adds URI opening in the viewer, reworked printing, memory-leak and potential-crash fixes, and other minor improvements. ### Source excerpt It's been quite some time since hearing any news out of the Shotwell photo manager project for GNOME, but out today is Shotwell 33 with the long-awaited GTK4 port... ## One Decade of Rustls: Evolution, Benchmarks, and Future Roadmap DevFeed: [One Decade of Rustls: Evolution, Benchmarks, and Future Roadmap]() Original publisher: [Read original article]() Author: Olimpiu Pop Published: 2026-09-12T07:07:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [Cryptography](), [Security, Privacy and Abuse Prevention](), [interoperability](), [Refactoring]() Tags: [benchmarks](), [development](), [memory-leaks](), [memory-safety](), [news](), [open-source](), [performance](), [post-quantum](), [release](), [retrospective](), [rust](), [rustls-one-decade](), [security](), [tls]() ### AI overview Rustls marks its tenth anniversary with a retrospective on its growth, funding, security work, and performance. The article compares Rustls 0.23.37 with OpenSSL and BoringSSL and notes architectural changes planned for version 0.24. ### Source excerpt Rustls, a Rust TLS library, marks its decade-long progression from a grassroots project to a funded open-source initiative. Key contributions from organisations boosted development, resulting in features like post-quantum cryptography and robust performance. The upcoming 0.24 release aims to enhance architecture and flexibility, including new input buffering and improved session handling By Olimpiu Pop ## Preparing your app for broader memory limits DevFeed: [Preparing your app for broader memory limits]() Original publisher: [Read original article]() Author: Android Developers (noreply@blogger.com) Published: 2026-08-19T19:00:00Z Content type: article Language: en Sources: [Android Developers Blog](), [Android Developers Blog]() Topics: [App](), [Memory Leaks](), [Processes](), [cpu]() Tags: [android](), [app](), [cpu](), [memory](), [memory-leaks](), [metrics](), [monitoring](), [optimization](), [os](), [performance](), [process](), [user-experience]() ### AI overview Android 17 broadens per-app memory limits across devices. The article explains how exceeding a memory budget can cause zRAM swapping, slowdowns, and process termination, and recommends measuring and reducing an app's memory footprint. ### Source excerpt Posted by Blair Harmon, Director of Product Management, Android Platform A great user experience is central to Android's mission, and delivering on that promise requires keeping devices fast, responsive, and reliable. This is why memory optimization is more critical than ever. Across the ecosystem, new devices are maintaining or even decreasing their physical memory capacity in response to memory price increases, yet users continue to expect the same seamless, high-performance app experience. In Android 17, we introduced per-app memory limits, starting with Pixel devices, to help protect the overall user experience from applications using excess memory and causing system-wide slowdowns. Over the coming year, an increasing number of manufacturers will leverage the Android per-app memory limits across their portfolio of device RAM configurations from 4GB to 16GB+ devices. If your app exceeds these limits, it will be slowed down and may be terminated. Optimizing your app's memory footprint is essential to preventing OS throttling and maintaining a seamless user experience. In this post, we'll explore how these limits work under the hood, how to measure your memory footprint using new Android vitals metrics, and actionable steps to optimize your app or game. Understanding Memory Limits When your app exceeds its memory budget, Android takes progressive action to protect device responsiveness: zRAM Swapping: If your app reaches its allocated limit, the system forces your app's pages into zRAM (compressed RAM). While zRAM prevents immediate eviction, compressing and decompressing pages adds CPU overhead, which can result in noticeable UI jank and experience slowdowns. Process Termination: If your app continues to increase its memory usage beyond the zRAM threshold, it will be terminated by the system. To determine if your app session was impacted by these constraints in the field, you can call getDescription() within ApplicationExitInfo. If the system applied a limit, the ## Preparing your app for broader memory limits DevFeed: [Preparing your app for broader memory limits]() Original publisher: [Read original article]() Author: Android Developers (noreply@blogger.com) Published: 2026-08-19T19:00:00Z Content type: tutorial Language: en Sources: [Android Developers Blog]() Topics: [Android](), [Optimization](), [User Experience](), [Memory Leaks](), [memory price increases]() Tags: [adb](), [android](), [memory-leaks](), [memory-optimization](), [optimization](), [user-experience](), [vitals]() ### AI overview This Android Developers article explains how Android 17 per-app memory limits are expanding beyond Pixel devices across a range of RAM configurations. It describes the effects of exceeding memory budgets, including zRAM swapping, CPU overhead, UI jank, throttling, and possible process termination, and outlines ways to measure and optimize app memory usage. ### Source excerpt Posted by Blair Harmon, Director of Product Management, Android Platform A great user experience is central to Android's mission, and delivering on that promise requires keeping devices fast, responsive, and reliable. This is why memory optimization is more critical than ever. Across the ecosystem, new devices are maintaining or even decreasing their physical memory capacity in response to memory price increases, yet users continue to expect the same seamless, high-performance app experience. In Android 17, we introduced per-app memory limits, starting with Pixel devices, to help protect the overall user experience from applications using excess memory and causing system-wide slowdowns. Over the coming year, an increasing number of manufacturers will leverage the Android per-app memory limits across their portfolio of device RAM configurations from 4GB to 16GB+ devices. If your app exceeds these limits, it will be slowed down and may be terminated. Optimizing your app's memory footprint is essential to preventing OS throttling and maintaining a seamless user experience. In this post, we'll explore how these limits work under the hood, how to measure your memory footprint using new Android vitals metrics, and actionable steps to optimize your app or game. Understanding Memory Limits When your app exceeds its memory budget, Android takes progressive action to protect device responsiveness: zRAM Swapping: If your app reaches its allocated limit, the system forces your app's pages into zRAM (compressed RAM). While zRAM prevents immediate eviction, compressing and decompressing pages adds CPU overhead, which can result in noticeable UI jank and experience slowdowns. Process Termination: If your app continues to increase its memory usage beyond the zRAM threshold, it will be terminated by the system. To determine if your app session was impacted by these constraints in the field, you can call getDescription() within ApplicationExitInfo. If the system applied a limit, the ## jetc.dev Newsletter Issue #325 DevFeed: [jetc.dev Newsletter Issue #325]() Original publisher: [Read original article]() Author: CommonsWare Published: 2026-08-04T14:00:00Z Content type: article Language: en Sources: [jetc.dev | Issues]() Topics: [Jetpack Compose](), [releases](), [debug](), [Memory Leaks](), [multiplatform]() Tags: [2026](), [agents](), [compose](), [compose-multiplatform](), [debugging](), [dev](), [jetbrains](), [memory-leaks](), [multiplatform](), [published](), [remote]() ### AI overview jetc.dev Newsletter Issue #325 reviews recent Jetpack Compose releases and related artifacts, including BOM, Material3, Remote Compose, and Wear Compose updates. It also covers the five-year anniversary of Compose 1.0, composition debugging research, Compose Multiplatform content, and a reported memory leak in a Compose for Desktop design system. ### Source excerpt Compose 1.0 five-year anniversary! 1.12.0 RC! Memory leaks! Remote Compose for debugging! And... have you been through the desert with a state with no name?!? ## Bun's migration from Zig to Rust reduced the estimated timeline from 1-2 years to 11 days DevFeed: [Bun's migration from Zig to Rust reduced the estimated timeline from 1-2 years to 11 days]() Original publisher: [Read original article]() Author: Ivan Klaric Published: 2026-07-16T16:50:20Z Content type: opinion Language: en Sources: [The Pragmatic Engineer]() Topics: [Bun](), [migration](), [Rust](), [Zig](), [Fable](), [Memory Leaks]() Tags: [bun](), [fable](), [memory-leaks](), [migration](), [rust](), [zig]() ### AI overview The article examines Bun's rewrite from Zig to Rust, focusing on memory-safety problems and the migration approach. It reports that the migration timeline was shortened from an estimated 1-2 years to 11 days, while emphasizing that thorough testing was required. ### Source excerpt To a sceptic, spending $165K to migrate Bun from Zig to Rust sounds very expensive. But to a realist, shortening a 1-2 year migration down to 11 days opens amazing new opportunities for devs. However, a thoroughly-tested project is required to pull it off. ## Android Studio Quail 2 is Stable: Multi-task with the Android Studio AI agent DevFeed: [Android Studio Quail 2 is Stable: Multi-task with the Android Studio AI agent]() Original publisher: [Read original article]() Author: Android Developers (noreply@blogger.com) Published: 2026-07-14T11:00:00Z Content type: release Language: en Sources: [Android Developers Blog](), [Android Developers Blog]() Topics: [AI-assisted coding](), [debugging]() Tags: [agentic](), [ai-agent](), [android](), [android-studio](), [debugging](), [memory-leaks]() ### AI overview Android Studio Quail 2 is a stable release that adds parallel AI-agent chats, integrated LeakCanary memory-leak profiling, and Agent Mode support for crash investigation through App Quality Insights. ### Source excerpt Posted by Amman Asfaw, Product Manager, Android Studio Android Studio Quail 2 is now stable and ready for you to use in production, bringing a shift to your IDE with concurrent agentic workflows, natively integrated memory leak profiling, and context-aware crash remediation. Whether you are performing a sweeping architectural overhaul, tracing a memory leak, or resolving a critical production crash, Android Studio keeps you anchored in your workspace by reducing manual friction. Here's a deep dive into what's new: Multi-tasking with parallel chats In Android Studio Quail 2, we've been hard at work redesigning Agent Mode from the ground up. This new architecture provides better performance, offers more flexibility for decomposing complex tasks, and improves the suite of internal tools the agent uses to do its work. In addition to these behind-the-scenes improvements, these changes also allow you to converse across multiple agent chats simultaneously. Waiting for the Android Studio agent to finish a task before you can ask another question or initiate a separate task in Agent Mode is a bottleneck of the past. You can multi-task seamlessly: kick off a UI refactor in one tab, fix a ProGuard rule in a second, and generate documentation in a third. You can also change which models the agent uses from chat to chat based on the requests you have. Take a look at Android Bench for an analysis of how LLMs perform Android development tasks. How to use: Click the "+" icon to start a new parallel conversation, and use the History icon to navigate between active tasks. Alternatively, select File > New > New Agent Tab to open a conversation in a dedicated tab. Note: Worktree support is currently unavailable. Exercise caution when running concurrent chats that modify the same project files, which can potentially lead to editor conflicts. Run multiple agent tasks in parallel with different models of your choice. Use the History icon to navigate between active tasks. Memory leak detec ## v20.2.2 Tentacle released DevFeed: [v20.2.2 Tentacle released]() Original publisher: [Read original article]() Author: Yuri Weinstein, Patrick Donnelly Published: 2026-06-16T00:00:00Z Content type: release Language: en Sources: [Ceph Blog]() Topics: [bug](), [Vulnerabilities](), [Memory Leaks](), [Encryption](), [configuration](), [IO]() Tags: [2026](), [aio](), [blog-post](), [bug](), [ceph](), [configuration](), [en-article](), [en-blog-post](), [encryption](), [io](), [memory-leaks](), [rados](), [release](), [rgw](), [storage](), [tentacle](), [ui](), [update](), [vulnerabilities]() ### AI overview Ceph v20.2.2 Tentacle is a minor release that adds Rocky 10 package-install support and recommends updating. It fixes issues across MDS, OSD, RGW, RADOS libraries, watch/notify operations, asynchronous utilities, and the dashboard, including security vulnerabilities, memory leaks, encrypted-object lifecycle problems, and UI and configuration improvements. ### Source excerpt This is the second minor release in the Tentacle series. We recommend that all users update to this release. Release Date ¶ June 16, 2026 Notable Changes ¶ Rocky 10 package-based installs are now supported starting with v20.2.2. Please see the supported platforms for current and planned support in Ceph. MDS (Metadata Server) ¶ Segmentation fault fixed due to incorrect queueing of request retries. OSD (Object Storage Daemon) ¶ PGLog Missed List: Fixed a bug to ensure the correct version is attached to the missing list when ignoring log entries. Data Integrity Asserts: Added assertions to explicitly catch potential corruption in the OSD missing list. RGW (RADOS Gateway) ¶ Lifecycle Management: Fixed lifecycle transition issues affecting encrypted multipart objects. REST & Query Handling: RESTArgs::get_string() now properly URL-decodes incoming query parameters. RADOS / librados / neorados ¶ Linger Operations: Rewrote safety checks to eliminate use-after-free vulnerabilities and LingerOp memory leaks when an unwatch operation returns ENOTCONN. Replaced the flawed is_valid_watch() check with a safe linger_by_cookie() lookup which safely manages LingerOp references using intrusive_ptr. Ensured librados linger callbacks hold a persistent reference to LingerOp to protect against races with simultaneous linger_cancel() requests. Configured librados::IoCtxImpl::aio_unwatch() to asynchronously deliver ENOTCONN to AioCompletion instead of returning the error directly. Watch/Notify: Fixed neorados notification queue bounds enforcement so that an overflow marker is only appended on the first message exceeding capacity, rather than duplicating it on every subsequent message. Prevented double-cleanup triggers in watch/notify operations when incoming errors arrive after maybe_cleanup() runs. Fixed a bug where notify would lose original error values by ensuring it no longer attempts to decode empty responses. Enhanced io_context shutdown procedures to clear handlers and route cleanl ## Hunting iOS Memory Leaks: S1E1 DevFeed: [Hunting iOS Memory Leaks: S1E1]() Original publisher: [Read original article]() Author: Amanjeet Singh Gurtatta Published: 2026-05-09T09:43:49Z Content type: article Language: en Sources: [Amanjeet Singh]() Topics: [Memory Leaks](), [iOS](), [Automation](), [GitHub Actions](), [Claude Code](), [test]() Tags: [automation](), [claude-code](), [engineering](), [github-actions](), [ios](), [memory](), [memory-leak](), [memory-leaks](), [mobile](), [traces](), [unit-test]() ### AI overview The first edition of Hunting Memory Leaks describes development of XCTestLeaks, a tool that runs unit test schemes, checks for retain cycles with leaks(1), and produces HTML leak reports. The author reports fixing two memory leaks in Firefox-iOS-related code and outlines a workflow using project-specific GitHub Actions, Claude Code, and optional upstream issues or pull requests. ### Source excerpt Welcome to the first edition of Hunting Memory Leaks. Another wild week, mostly battling with XCTestLeaks, the tool I've been building on the side. I'll release it once I'm confident the workflow holds up across at least 5 repos. For context, I've ## 20 Mistakes That Quietly Destroy JavaScript/TypeScript Codebases (Part 2) DevFeed: [20 Mistakes That Quietly Destroy JavaScript/TypeScript Codebases (Part 2)]() Original publisher: [Read original article]() Author: The T-Shaped Dev Published: 2026-05-09T02:19:51Z Content type: tutorial Language: en Sources: [The T-Shaped Dev]() Topics: [JavaScript](), [TypeScript](), [Code](), [Node.js](), [Testing]() Tags: [async](), [code](), [javascript](), [memory-leaks](), [mistakes](), [node-js](), [patterns](), [test](), [typescript]() ### AI overview Part 2 of a JavaScript and TypeScript code-quality series presents common runtime and code-quality mistakes, including mutating function parameters, memory leaks from uncleared listeners, timers and subscriptions, and async cancellation issues. It includes fixes and testing or debugging guidance. ### Source excerpt Common JS/TS patterns that feel fine until they don't. 11 mistakes, before/after code for each. (11 min) ## Structured Concurrency DevFeed: [Structured Concurrency]() Original publisher: [Read original article]() Published: 2026-04-13T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Structured concurrency](), [Coroutines](), [kotlin-coroutines](), [Concurrency](), [Error Handling]() Tags: [coroutines](), [error-handling](), [guide](), [kotlin](), [memory-leaks](), [processes](), [structured-concurrency](), [workshop-learning-programming]() ### AI overview A Kotlin-focused guide to structured concurrency explains how coroutine hierarchies establish ownership and completion guarantees. It covers cancellation of child coroutines, avoiding unnecessary work and resource leaks, awaiting completion, and handling errors. ### Source excerpt The only guide to structured concurrency you'll ever need. ## Discovering iOS Memory Leaks IV: Detecting via Unit Tests DevFeed: [Discovering iOS Memory Leaks IV: Detecting via Unit Tests]() Original publisher: [Read original article]() Author: Amanjeet Singh Gurtatta Published: 2026-01-07T01:46:06Z Content type: tutorial Language: en Sources: [Amanjeet Singh]() Topics: [iOS](), [Memory Leaks](), [unit tests](), [Xcode](), [macOS]() Tags: [ios](), [macos](), [memory](), [memory-leak](), [memory-leaks](), [tests](), [unit-tests](), [xcode]() ### AI overview This article explores detecting real iOS memory leaks with unit tests instead of UI tests. It describes running the macOS leaks tool against the Firefox process during unit-test teardown in the iOS simulator to shorten the feedback cycle and broaden coverage. ### Source excerpt Using unit tests and macOS leaks tool to catch real iOS memory leaks. ## Subverting control with weak references DevFeed: [Subverting control with weak references]() Original publisher: [Read original article]() Author: James Long Published: 2025-02-24T12:00:00Z Content type: tutorial Language: en Sources: [James Long]() Topics: [JavaScript](), [Data structures](), [Memory Leaks]() Tags: [article](), [data-structure](), [javascript](), [memory](), [memory-leaks](), [reference]() ### AI overview This JavaScript article explains weak references, WeakRef, and WeakMap. It describes how weak references interact with garbage collection and how WeakMap can avoid retaining objects and causing memory leaks. ### Source excerpt Weak references are neat. The best language features unlock different kinds of abstractions, and weak references do exactly that. Let me show you why. In JavaScript we have two APIs to work with weak references: WeakMap and WeakRef. (Before I wrote this article I thought WeakRef was only a proposal, but it turns out most browsers have already implemented it) One of the more common use cases uses WeakMap. This data structure keeps a weak reference to the keys in the map, and a strong reference between the keys and values. I guess I should explain what a "weak reference" is: usually if you have a reference to an object in a variable, it stops the garbage collector from deleting it (which makes sense). It'd be weird if suddenly your variable pointed to nothing right? A "weak reference" doesn't stop the object from being garbage collected. Usually languages' semantics don't allow a variable to change in the middle of execution however: // this doesn't exist, but what if we could create a weak reference like this? let weak trans = new Transaction(); // do a bunch of things... // error! trans is... nothing? it got garbage collected trans.transfer(); ^3d7637 Wouldn't it be weird if trans changed in the middle of execution? If that was possible all bets would be off for everything in the entire program because these weak references could be passed anywhere. Instead, APIs for weak references force you to call a function to get the value. The WeakRef class has a deref method to get the object. const ref = new WeakRef(obj) // get the object ref.deref() // do a bunch of things... ref.deref() ^ae238d In the above example, if nothing has a reference to obj, it'll eventually get garbage collected. That means deref might return obj the first time, but the second time it might return undefined. Let's get back to WeakMap which is the more common usage of weak references. (Direct weak references have a lot of weird behaviors and they should be considered very low-level.) A WeakMap has ## Simplify ViewBinding in Android with ViewBindingPropertyDelegate 2.0 DevFeed: [Simplify ViewBinding in Android with ViewBindingPropertyDelegate 2.0]() Original publisher: [Read original article]() Author: Kirill Rozov Published: 2025-02-04T13:30:45Z Content type: release Language: en Sources: [Stories by Kirill Rozov on Medium]() Topics: [Android](), [Library](), [Jetpack](), [Refactoring](), [Memory Leaks](), [recyclerview]() Tags: [android](), [android-jetpack](), [fragments](), [jetpack](), [library](), [memory-leaks](), [open-source](), [performance](), [recyclerview](), [refactoring](), [release](), [ui](), [view-binding]() ### AI overview This article announces ViewBindingPropertyDelegate 2.0, a release that refactors how the Android library manages ViewBinding lifecycles. It replaces Jetpack Lifecycle-based detection with component lifecycle callbacks for Fragments and Activities, improving the timing of reference clearing and addressing issues related to Fragment animations. The release also supports lazy ViewBinding creation and aims to prevent memory leaks. ### Source excerpt I'm excited to announce the release of ViewBindingPropertyDelegate 2.0, which introduces significant under-the-hood refactoring to enhance the library's stability and performance. In this article, I'll highlight the most important changes and explain how they improve the library's functionality. Brief Introduction ViewBindingPropertyDelegate(VBPD) is a lightweight library designed to simplify the use of Android's ViewBinding by: Managing the ViewBinding lifecycle and clearing references to prevent memory leaks. Eliminating the need to maintain nullable references to Views or ViewBindings. Creating ViewBindings lazily. The library supports usage in various components, including Activities, Fragments, ViewGroups, and RecyclerView.ViewHolders. class ProfileFragment : Fragment(R.layout.profile) { private val profileBinding: ProfileBinding by viewBinding(ProfileBinding::bind) override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) // ProfileBinding instance will be created lazily on first access profileBinding.name.text = ... } override fun onDestroyView() { super.onDestroyView() // profileBinding reference will be cleared after onDestroyView() } }Changes in 2.0Transition from Lifecycle to Component Callbacks In previous versions (1.x), VBPD relied on Jetpack's Lifecycle to detect when a View was being destroyed. This approach had a limitation: the Lifecycle callback methods could be invoked before Fragment.onDestroyView(), while the ViewBinding reference was still needed. To address this, VBPD postponed clearing the ViewBinding reference using an Android Handler after onDestroyView(), when the Fragment's View LifecycleOwner transitioned to the DESTROYED state. In version 2.0, VBPD now utilizes FragmentManager.FragmentLifecycleCallbacks to detect when a Fragment's view is destroyed. The key difference lies in the timing of these callbacks, allowing for more precise management of the ViewBinding lifecycle. // Sou ## Identifying insecure C Code with Valgrind and fixing with Snyk Code DevFeed: [Identifying insecure C Code with Valgrind and fixing with Snyk Code]() Original publisher: [Read original article]() Author: Liran Tal Published: 2024-09-24T05:00:00Z Content type: tutorial Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [C](), [Static code analysis](), [Memory Leaks](), [Vulnerabilities](), [C++](), [Security](), [snyk-code]() Tags: [analysis](), [awareness](), [blog](), [c](), [c-cpp](), [c-plus-plus](), [code-security](), [developer](), [devops](), [devrel](), [docker](), [how-to](), [memory-leaks](), [memory-management](), [programming](), [security](), [snyk-code](), [vulnerabilities]() ### AI overview This tutorial explains how insecure C and C++ code can introduce memory leaks and other vulnerabilities, and describes using Valgrind and Snyk Code's static code analysis to identify and fix them. It also discusses dynamic memory allocation, memory exhaustion, and relevant MISRA guidance. ### Source excerpt Discover how to secure your C and C++ code with Snyk. Learn about common vulnerabilities like memory leaks and buffer overflows in C and C++ and how Snyk's static code analysis tool can help you identify and fix them. Protect your critical software from security threats. ## Discovering iOS memory leaks: A case study with Firefox app II DevFeed: [Discovering iOS memory leaks: A case study with Firefox app II]() Original publisher: [Read original article]() Author: Amanjeet Singh Gurtatta Published: 2024-02-24T11:22:22Z Content type: article Language: en Sources: [Amanjeet Singh]() Topics: [Firefox](), [iOS](), [Memory Leaks](), [Open Source](), [Pull Request](), [GitHub](), [Refactoring]() Tags: [firefox](), [github](), [ios](), [leak](), [memory](), [memory-leak](), [memory-leaks](), [mobile-performance](), [open-source](), [release]() ### AI overview A case study of contributing a memory-leak fix to Firefox for iOS. The article describes the pull-request process, an initially unmerged approach, the eventual fix involving a UI kit retain cycle, and lessons about coordinating with open-source maintainers. ### Source excerpt Discover my experience in contributing to Firefox ios fixing their memory leaks ## Discovering iOS memory leaks: A case study with Firefox app DevFeed: [Discovering iOS memory leaks: A case study with Firefox app]() Original publisher: [Read original article]() Author: Amanjeet Singh Gurtatta Published: 2023-12-25T21:07:16Z Content type: tutorial Language: en Sources: [Amanjeet Singh]() Topics: [iOS](), [Memory Leaks](), [Command-line interface](), [Firefox](), [App](), [Monitoring]() Tags: [command-line](), [crashlytics](), [firebase](), [firefox](), [ios](), [leak](), [memory](), [memory-leak](), [memory-leaks](), [tool]() ### AI overview A case study on detecting and prioritizing memory leaks in iOS apps. It explains automatic reference counting, recommends prioritizing production leaks and monitoring core flows, and uses a Firefox iOS app with UI tests and the macOS leaks command-line tool. ### Source excerpt Discover how to efficiently detect and manage memory leaks in iOS apps using the leaks command line tool with example ## Apollo Client 3.9 Feature Spotlight - The memory story DevFeed: [Apollo Client 3.9 Feature Spotlight - The memory story]() Original publisher: [Read original article]() Author: Lenz Weber-Tronic Published: 2023-12-20T16:02:32Z Content type: article Language: en Sources: [Apollo Blog]() Topics: [apollo-client](), [Memory Leaks](), [Caching](), [Open Source](), [Maintainers]() Tags: [apollo-client](), [cache](), [feature](), [issue](), [leak](), [memory](), [memory-leak](), [memory-leaks](), [open-source](), [spotlight]() ### AI overview Apollo Client 3.9 is released in beta with fixes for various memory leaks, more granular control over internal cache sizes, and deprecation of canonizeResults because of a conceptual, non-fixable memory leak. The article also asks users to help determine appropriate default cache sizes. ### Source excerpt Apollo Client 3.9 is out in beta now, and it fixes various memory leaks, adds granular control over internal cache sizes, and deprecates the canonizeResults option due to a conceptual and non-fixable memory leak associated with it. We want your help to find the correct default cache sizes - see the last paragraph for details on that. The memory story Sometimes, in an open source project, you have that issue that sticks around for a long time because it's not clear how you would tackle it. ## Node.js 20.8.0 (Current) DevFeed: [Node.js 20.8.0 (Current)]() Original publisher: [Read original article]() Published: 2023-09-29T03:26:00Z Content type: release Language: en Sources: [Node.js Blog]() Topics: [Node.js](), [JavaScript](), [Memory Leaks](), [Streams](), [cross-platform](), [Open Source](), [Command-line interface](), [debug]() Tags: [cross-platform](), [debugger](), [javascript](), [memory-leaks](), [node-js](), [open-source](), [performance](), [release](), [streams]() ### AI overview Node.js 20.8.0 is a Current release focused on performance and stability. It improves writable, readable, and web stream performance, reduces stream memory overhead, addresses memory leaks and use-after-free issues, and includes updates to the test runner, snapshots, debugging, and V8 integration. ### Source excerpt Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts. ## How Android Memory Leaks Cause Jank, Freezes, and ANRs DevFeed: [How Android Memory Leaks Cause Jank, Freezes, and ANRs]() Original publisher: [Read original article]() Author: Pierre-Yves Ricau Published: 2023-07-20T22:09:53Z Content type: tutorial Language: en Sources: [Py's blog]() Topics: [Android](), [Memory Leaks](), [Latency](), [navigation](), [Java]() Tags: [android](), [jank](), [latency](), [main-thread](), [memory-leak](), [memory-leaks](), [navigation](), [outofmemory](), [performance]() ### AI overview This article explains how Android memory leaks can cause jank, freezes, and ANRs rather than immediate crashes. It describes tracking memory usage per navigation, correlating memory growth with navigation latency, and how garbage collection blocking the main thread affects UI responsiveness near the app memory limit. ### Source excerpt In this article, I show how Android memory leaks lead to jank, freezes and ANRs more often than they lead to OutOfMemoryError crashes. Navigation Latency At Square, we've been tracking a User-Centric performance metric: Interaction Latency. We track ... ## Detect small memory leaks DevFeed: [Detect small memory leaks]() Original publisher: [Read original article]() Author: Vadzimv Dev Blog Published: 2022-10-10T08:20:00Z Content type: tutorial Language: en Sources: [vadzimv Dev Blog]() Topics: [Memory Leaks](), [Android](), [App](), [SDK]() Tags: [analysis](), [android](), [applications](), [batch](), [memory-leaks](), [sdk](), [trace]() ### AI overview This tutorial explains how to detect small, long-term memory leaks in Android applications by recording memory traces, reviewing process RSS in Perfetto, and using queries and batch processing to analyze multiple traces. ### Source excerpt Detect small memory leaks in Android applications. ## ViewLifecycleLazy and other ways to avoid View memory leaks in Android Fragments DevFeed: [ViewLifecycleLazy and other ways to avoid View memory leaks in Android Fragments]() Original publisher: [Read original article]() Author: Christophe Beyls Published: 2022-09-28T06:12:25Z Content type: tutorial Language: en Sources: [Stories by Christophe Beyls on Medium]() Topics: [Android](), [Memory Leaks](), [Kotlin]() Tags: [android](), [android-app-development](), [androiddev](), [architecture](), [architecture-components](), [fragments](), [kotlin](), [lifecycle](), [memory](), [memory-leak](), [memory-leaks](), [view-binding]() ### AI overview This article presents ViewLifecycleLazy, a Kotlin delegated property for Android Fragments that lazily initializes values tied to the current Fragment view lifecycle and clears them when the view hierarchy reaches the DESTROYED state. It explains how this approach helps prevent view-related memory leaks and compares it with AutoClearedValue and manual clearing in onDestroyView(). ### Source excerpt Yet another take on AutoClearedValueAre your Fragments leaking? Handling the lifecycle of Android Fragments is difficult. I already covered this topic in an article I wrote in 2017, before Google added a View-specific Lifecycle to Fragments in an attempt to solve some issues. Until now, the number one cause of memory leaks when using Fragments remains the same: not properly clearing all direct and indirect View references in onDestroyView(). Tools like Leak Canary can help detecting some of these cases. And of course, Jetpack Compose represents a big paradigm change which completely removes the need to keep View references but hey, we still have our legacy codebases to maintain! I recently came across a Medium blog post from Gabor Varadi describing an issue he encountered with a custom Kotlin delegated property he created to simplify managing view bindings in Fragments. His solution is based on a class named AutoClearedValue from the architecture components samples. The purpose of AutoClearedValue is to provide a delegate that will automatically clear a value tied to one or more Views when the Fragment View hierarchy gets destroyed, in order to avoid the aforementioned memory leaks. This is an elegant alternative to declaring a Fragment property as nullable and manually setting it to null in onDestroyView(), which can be easily forgotten. It turns out I had already come up with my own solution to do the exact same thing. And since my version is simpler and generates more optimized bytecode compared to AutoClearedValue and what Mr Varadi published, I decided to share it with you. I named this delegate ViewLifecycleLazy. Like the name implies, the delegated property value is computed lazily and the Fragment's current view lifecycle is observed in order to automatically clear the value when it moves to the DESTROYED state. https://medium.com/media/17c61e41a0f2d3e17c63e3bcf8f6376c/href This is how it's used in Fragments, for example with View Binding: class MyFragment : ## 🙅♂ Don't let ViewModel know about framework level dependencies DevFeed: [🙅♂ Don't let ViewModel know about framework level dependencies]() Original publisher: [Read original article]() Author: Shreyas Patil Published: 2021-09-17T12:18:27Z Content type: tutorial Language: en Sources: [Shreyas Patil's Blog]() Topics: [Android](), [android-app-development](), [Memory Leaks](), [Testing]() Tags: [android](), [android-app-development](), [framework](), [kotlin](), [maintainability](), [memory-leaks](), [mvvm](), [software-architecture](), [testing](), [unit-tests]() ### AI overview This Android development article explains why ViewModels should avoid holding Android framework references such as Activity, Context, View, or Drawable. It connects framework-aware ViewModels with memory leaks and reduced testability, modularity, and maintainability. ### Source excerpt Explore best practices for Android ViewModels. Learn why keeping framework references out of ViewModels is crucial for testing and preventing memory leaks. ## Effective Kotlin Item 53: Eliminate obsolete object references DevFeed: [Effective Kotlin Item 53: Eliminate obsolete object references]() Original publisher: [Read original article]() Published: 2021-09-13T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Memory Leaks](), [Kotlin](), [Android](), [classes](), [function]() Tags: [android](), [gc](), [how-to](), [kotlin](), [memory](), [memory-leaks](), [workshop-learning-programming]() ### AI overview This article explains how obsolete object references can cause memory leaks in Java and Android applications. It discusses retaining large or no-longer-needed objects, including activities stored in companion objects or top-level properties, and shows how stale references in a stack implementation keep removed elements reachable by the Garbage Collector. ### Source excerpt How to help our garbage collector and avoid memory leaks. [Next page]()