1. Introduction

Today to fill out the resignation form, to help the company interview a few help to fill the pit of the peer, talking about the Glide, and I said, very familiar with this piece, before in the gold community, read a called blue master to write this article, the basic details are mastered 😏. (a look of victory, ok, I happen to have seen it, let’s ask to see the situation carefully)


2. Let’s briefly introduce Glide cache

2.1 analysis

(This guy goes on and on, from LruCache to LinkedHashMap, blah blah blah… Personal advice to this part must be brief, the interview principle said too much, first, many details will be interrupted to ask, second point, say so much, give people the feeling is reciting things, principle generalization ability is weak or feel that they do not have their own experience.

2.2 the answer

Glide’s cache mechanism, mainly divided into two kinds of cache, one is memory cache, one is disk cache.

The memory cache is used to prevent the application from repeatedly reading images into memory, which can waste memory resources.

The reason for using disk caching is to prevent applications from repeatedly downloading and reading data from the network or elsewhere.

Because of the combination of these two caches, Glide has an excellent cache effect.

(Tell the interviewer what types of caches are available and for what purpose, then look at the interviewer or wait for him to ask more questions, or if he doesn’t, wait for you, at which point you can go into more detail.)


3. Well, let’s talk about Glide’s level 3 cache principle specifically

3.1 analysis

(Remember, if you need to talk about the principles in detail, first the macro, then the details)

3.2 the answer

When reading an image, get it in the following order: Lru algorithm cache – weak reference cache – Disk cache (if set)

When we want to load a picture in our APP, first go to LruCache to look for the picture. If there is one in LruCache, then directly take it out and use it, and put the picture into WeakReference. If there is no one in LruCache, then go to WeakReference to look for it. If there is a picture in WeakReference, then take out the picture from WeakReference to use, if there is no picture in WeakReference, then load the picture from the disk cache/network.

Note: The image exists in the activeResources weak reference Map when it is in use

The process is as follows:

When caching images, write order: weak reference cache – Lru algorithm cache – disk cache

When the image does not exist, firstly download the image from the network, and then store the image in the weak reference. Glide will adopt an acquired (int) variable to record the number of times the image is referenced. When the acquired variable is greater than 0, it means the image is in use, that is, put the image in the weak reference cache. If the acquired variable equals 0, the image is no longer in use, then the method is called to release the resource, first removing the cached image from the weak reference, and then putting it into LruResourceCache. In this way, the image in use is cached with weak reference, and the image not in use is cached with LruCache.

Lead depth: about LruCache

The least recently used algorithm, set a cache size, when the cache reached this size, the oldest data will be removed, to avoid images occupy too much memory caused by OOM. LruCache internally uses LinkHashMap to access data. On the premise of two-way linked list to ensure the old and new order of data, set a maximum memory. When putting data into it, when the data reaches the maximum memory, the oldest data will be removed to ensure that the memory does not exceed the set maximum.

About the LinkedHashMap

LinkHashMap inherits HashMap, and adds a bidirectional linked list structure on the basis of HashMap. Every time the data is accessed, it updates the list pointer of the accessed data. Specifically, it deletes the node in the list first, and then adds it to the list before the header. This ensures that all data before the header node is recently accessed (deleting from the list doesn’t actually remove the data, it just moves the list pointer, and the data itself stays in the map).


4. Glide load a Megabyte image (100 * 100), whether will be compressed after loading, put in a 300 * 300 view will be what, 800*800, the image will be very blurred, how to deal with?

4.1 analysis

(because some caching mechanism whether blogs or look at your bible of the interview, if only does principle or definition, recite the words down light is ok, but to recite and real understanding are two different things, they do not have the formation of comprehension, don’t understand this framework, just cater to the interview, this problem can get stuck, you also don’t show off in an ostentatious manner and the interviewer, and sure enough, The brothers of this interview, this piece of stuck, hesitated for a long time did not answer, as expected is only read the blog, did not really read the source code)

4.2 the answer

When we resize the imageView, Picasso will always directly cache the entire image regardless of the size of the imageView. Glide, on the other hand, will cache one image for each imageView of a different size, which means that whether your image has been loaded or not, Glide will reload as long as the size of the ImageView is different. In this case, it will reload from the network before loading the ImageView and then cache it.

For example, if the imageView on one page is 300 * 300 pixels and the imageView on the other page is 100 * 100 pixels, Glide needs to download the image twice and cache both images to make the two imageViews look like the same image.

public <R> LoadStatus load(a) {
    // Get the cached key based on the request parameter
    EngineKey key = keyFactory.buildKey(model, signature, width, height, transformations,
        resourceClass, transcodeClass, options);
}
Copy the code

As you can see, one of the criteria for generating a cache Key is the width and length of the control.


5. Briefly talk about the memory leak scenario, if you use Glide to load an image in a page, the image is getting, if you suddenly close the page, will the page cause memory leak?

5.1 analysis

(note that must be the topic, because before asked the guy, the cause of memory leaks, are nothing more than a short life cycle refers to the long life cycle of object and so on, then suddenly a humorous, directly ask the Glide pictures load will cause leakage, this guy want to also do not want to, answered directly cause a memory leak, can use LeakCanary detection, Bala bala…)

5.2 the answer

Glide creates a transparent RequestManagerFragment and adds it to the FragmentManager to be aware of the lifecycle when loading resources on a component with a lifecycle, such as an Activity or Fragment. Glide stops loading resources when an Activity, Fragment, or other component becomes invisible or has been destroyed.

However, if it is done on a non-lifecycle component, the Application lifecycle is adopted throughout the Application, so the Application Manager terminates the loading only when the Application is closed.


6. How to design a large image loading framework

6.1 analysis

(The child, finally is ashamed to lower his head, a face of meng and said to me, THIS I forgot)

6.2 the answer

In general, image loading includes encapsulation, parsing, downloading, decoding, transforming, caching, displaying, and so on.

  1. Encapsulating parameters: There are many processes between specifying the source and the output, so the first thing is to encapsulate the parameters, which will be used throughout the process.
  2. Parsing path: there are many sources of pictures, the format is not the same, need to be normalized;
  3. Read cache: In order to reduce computation, it is usually done to cache; For the same request, get the Bitmap from the cache.
  4. Find/download files: if it is a local file, it can be decoded directly; If the image is from the Internet, download it first.
  5. Decoding: This step is one of the most complicated in the process, with a lot of detail, as the next blog will cover;
  6. Transform: After decoding the Bitmap, you may need to perform some transformations (rounded corners, filters, etc.).
  7. Cache: After the final bitmap is obtained, it can be cached so that the results can be fetched directly on the next request.
  8. Display: Display the result, which may require some animation (fade animation, crossFade, etc.).

END

First wrote this, basically ask so much, if again fine clasp, feel some intentionally difficult, the interview is usually within 30 minutes, feel each other, I will skip, as you will, I don’t need to ask, a waste of time, feel no, asked you say won’t or don’t know, I also can’t again in this fine clasp, the reason is the same, Waste of time. The main thing is to find the strengths of each person, and the attitude towards things.

In addition, in fact, not all the answer up to want you, not because the answer is not up to do not want you, mainly, or by feeling, easy to get along with, people are not too slippery, nice personality, give people the feeling of practical, will open one side.

Next time I will imitate a Glide, will Glide the main process involved, will be added, so convenient for everyone to understand. Those who are interested can follow me.

Or that sentence Although it may be updated, fast the along while, slow is half a year, but each article, I am a simple, or rich flow chart, a see to understand, step by step or modeled after the writing, learning framework principle again, first make clear why design, can you don’t write or so without this feature, according to the situation analysis, Then to read the source logic, so that it will remember the firm