Company products to take the following measures, nearly two weeks, only once OOM

LeakCanary detects memory leaks during development

LeakCanary is an open source library that detects memory leaks. You can easily detect memory leaks in debug packages and fix them in time during development.

Add a reference to build.gradle and use different references for different compilations:

 dependencies {

DebugCompile 'com. Squareup. Leakcanary: leakcanary - android: 1.5'

ReleaseCompile 'com. Squareup. Leakcanary: leakcanary - android - no - op: 1.5'

 }

Copy the code

In the Application:

public class ExampleApplication extends Application {



  @Override public void onCreate() {

    super.onCreate();

    LeakCanary.install(this);

  }

}

Copy the code

Build. gradle is set in the main module. Different buildTypes refer to different source paths

android {



    sourceSets {

        debug {

            java.srcDirs = ['src/debug/java']

        }

        release {

            java.srcDirs = ['src/release/java']

        }

        forTest {

            java.srcDirs = ['src/forTest/java']

        }

    }

}

Copy the code

In all three paths, there is a shconfig.java that defines the same package name and the same interface

Shconfig. Java under debug introduces Leakcanary:

package com.showjoy.shop.config;



public class SHConfig {



    public static void debugSetting(Application application) {

        com.squareup.leakcanary.LeakCanary.install(application);

    }

}

Copy the code

And then call it in Application

SHConfig.debugSetting(this);

Copy the code

Two, picture compression and picture loading

  • All local images can be compressed several times through tinypng.com/.
  • Local images can be converted to WebP, as far as possible into WebP

  • CDN image server integrates compression functions, including webP and size compression, and dynamically adds suffixes according to size requirements when clients visit pictures, such as:

    • Cdn1.showjoy.com/images/4a/4…
    • Cdn1.showjoy.com/images/b1/b…
  • Use Fresco, a powerful image-loading library that can be used directly and packagedSHImageView
    • When the picture is no longer displayed on the screen, it frees up memory and space footprint in time.
    • Under 5.0, Fresco puts images into a special memory area. Of course, when the image is not displayed, the occupied memory will be released automatically. This will make the APP more fluid and reduce the number of OOM images.
    • For systems up to 5.0, Fresco places the Bitmap cache directly into the JavaHeap memory due to the memory management optimization of Android itself. And fresco implements a true three-tier cache: two levels of in-memory cache plus one disk cache. There are two memory caches :bitmap cache and undecoded image cache, which can not only speed up the loading speed of images, but also save memory. This two-level memory cache is also not available in other image loading frameworks.
    • When the app switches to the background, Fresco automatically cleans both levels of the memory cache, no manual work required
    • Fresco works just as well on low-end machines, and you don’t have to worry about image memory footprint anymore.

3. Clear the cache in time

In ActivityLifecycleCallbacks onActivityStopped timely removal of unused cache. First of all, cache management should be unified, and cleaning rules can be customized, such as

  • Start clearing unwanted memory when you exceed 60% of the available drunk memory.
  • When you retreat to the background, clear unwanted memory
  • The implementation of cacheutil.clear () includes clearing the image cacheSHImageView.clearMemoryCaches();
public class ActivityLifecycleCallbacks implements Application.ActivityLifecycleCallbacks {

... ...



     @Override

    public void onActivityStopped(Activity activity) {



Float rateOfUsed = 1.0f * Runtime.getrunTime ().totalMemory()/Runtime.getruntime ().maxMemory(); float rateOfUsed = 1.0f * Runtime.getrunTime ().maxMemory();

Logutils. d("totalMemory/maxMemory: "+ rateOfUsed);

// Clear the cache when memory is insufficient

If (rateOfUsed > 0.6) {

            SHAnalyticManager.onEvent("out_of_memory");

            CacheUtil.clear();

        }



// Back to background, clear the cache

        if (0 >= activityList.size()) {

            LogUtils.d("app background");

            CacheUtil.clear();



            RxBus.getDefault().post(new BackgroundEvent(true));



        }

    }



Copy the code

Fourth, code optimization

  • Consider using ArrayMap/SpareseArray instead of traditional data structures such as HashMap. Android’s container ArrayMap for mobile systems is more efficient and takes less memory because HashMap requires an additional instance object to record Mapping operations. SparesArray effectively avoids automatic boxing of keys and values, and avoids unboxing after boxing.
  • Put an end to use ScrollView to realize list, with a ListView/GridView/RecycleView appear a large number of repeat child components in the view of reuse of ConvertView
  • Consider using StringBuilder instead of the frequent “+” when a lot of string concatenation is required in your code.
  • Use static objects with caution
  • Optimize layout levels to reduce memory consumption
  • Avoid using enumerated types
  • Use onLowMemory& onTrimMemory callbacks wisely

Reference links: LeakCanary 英 文 usage Description Android OOM and Bitmap Image Level 2 Cache mechanism (1) Android Performance Optimization (OOM of Memory) Fresco SHImageView application memory optimization OnLowMemory&OnTrimMemory