Preface
As we all know, the reading and understanding of excellent source code is the best way to improve one's own skills . If you want to become an excellent Android engineer, then the analysis and understanding of the source code of excellent tripartite libraries in Android is an essential skill . Take the more popular image loading framework Glide, I believe many students have used it, so when others ask you the following questions, can you answer them? (Glide five in a row)
- 1. Why use this library in the project?
- 2. What are the usages of this library? What kind of usage scenario does it correspond to?
- 3. What is the core implementation principle of this library? If you are asked to implement certain core functions of this library, how would you consider how to implement it?
- 4. What is the core idea of Glide source code mechanism?
- 5. How is the size of a picture calculated in Glide?
I believe there are not many students who can answer all of them. Let me answer the above questions.
1. Why use this library in the project?
- 1. Diversified media loading: not only image caching, but also Gif, WebP, thumbnail, and even Video.
- 2. By setting the binding life cycle: the life cycle of loading pictures can be dynamically managed.
- 3. Efficient caching strategy: Supports memory and Disk caching, and Picasso only caches pictures of the original size, while Glide caches a variety of specifications, that is, Glide will cache the image size of the corresponding size according to the size of your ImageView.
- 4. Small memory overhead: We can manually configure the default Bitmap decoding format to be RGB_565 format to reduce the memory overhead occupied by images.
2. What are the usages of this library? What kind of usage scenario does it correspond to?
- 1、图片加载：Glide.with(this).load(imageUrl).override(800, 800).placeholder().error().animate().into()。
- 2. Multi-style media loading: asBitamp, asGif.
- 3. Life cycle integration.
- 4. Disk caching strategy ALL, NONE, SOURCE, RESULT can be configured.
3. What is the core implementation principle of this library? If you are asked to implement certain core functions of this library, how would you consider how to implement it?
To understand the core implementation principle of Glide, you must first analyze it from its loading API Glide.with().into().
1、Glide&with：
- 1. Initialize various configuration information (including cache, request thread pool, size, image format, etc.) and glide objects.
- 2. Bind the glide request to the life cycle of application/SupportFragment/Fragment.
2、Glide&load：
Set the request url, and record the status that the url has been set.
3、Glide&into：
- 1. First, return different ImageViewTargets according to the transcodeClass type: BitmapImageViewTarget, DrawableImageViewTarget.
- 2. Recursively create a thumbnail request. If there is no thumbnail request, the normal request will be made directly.
- 3. If the width and height are not specified, the image width and height will be calculated according to the width and height of the ImageView, and finally executed to the engine.load() method in the onSizeReay() method.
- 4. Engine is a class responsible for loading and managing cached resources
Among them, Glide's three-level cache mechanism is worthy of our repeated study and contemplation. Here we first understand what a conventional three-level cache is like.
The conventional three-level cache process: strong reference -> soft reference -> hard disk cache
When we want to load a certain picture in our APP, first go to LruCache to find the picture. If it is in LruCache, it will be directly taken out and used. If it is not in LruCache, it will be searched in SoftReference (soft references are suitable for cache and memory It will be recycled when it is tight. And weakReference will be recycled every time system.gc()) (When LruCache is tight, the least recently used data will be placed in the SoftReference). Take out the picture from SoftReference and use it, and put the picture back into LruCache at the same time. If there is no picture in SoftReference, search it in the hard disk cache. If there is, take it out and use it. At the same time, add the picture to LruCache. If not, then Connect to the Internet to download pictures from the Internet. After the picture is downloaded, save the picture to the hard disk cache, and then put it in LruCache.
Glide's three-tier caching mechanism
The Glide cache mechanism is roughly divided into three layers: weak reference cache, memory cache, and disk cache.
- The order is: weak reference, memory, disk.
- The order of storage is: weak reference, memory, disk.
The three-tier storage mechanism is implemented in Engine. Let me talk about what Engine is? The Engine layer is responsible for the logic of managing the memory cache during loading. Hold MemoryCache, Map<Key, WeakReference<EngineResource<?>>>. Load the picture through load(), and the logic of memory storage will be done before and after loading. If it is not in the memory cache, then the EngineJob layer will be used to asynchronously obtain hard disk resources or network resources. EngineJob is similar to an asynchronous thread or observable. Engine is a globally unique one and is obtained through Glide.getEngine().
A picture resource is needed. If there is a corresponding resource picture in Lrucache, then return it and clear it from Lrucache and put it in activeResources. The activeResources map is the full display of the resources being used and exists in the form of weak references. At the same time, there is a referenced record inside the resource. If the resource has no reference record, then put it back into Lrucache and clear it from activeResources. If not in Lrucache, find it from activeResources, and add 1 to the corresponding resource reference when found. If Lrucache and activeResources are not available, then an asynchronous resource request (network/diskLrucache) is performed. After the request is successful, the resources are placed in diskLrucache and activeResources.
4. The core idea of Glide source code mechanism:
Use a weak reference map activeResources to contain the resources being used in the project. Lrucache does not contain any resources being used. There is a counter inside the resource to show whether it is still being referenced. What is the advantage of separating the resource being used from the resource that is not being used? ? Because when Lrucache needs to remove a cache, it calls the resource.recycle() method. Note that the comment above the method states that this method can only be called when there is no consumer referencing the resource. So why does calling resource.recycle() need to ensure that the resource does not have any consumer references? What the recycle() defined by resource in glide does is to put this unused resource (assuming bitmap or drawable) into bitmapPool. bitmapPool is a library for bitmap recycling and reuse. When transforming, a bitmap will be taken from this bitmapPool for reuse. This avoids re-creating the bitmap and reduces memory expenses. And since the bitmap in bitmapPool will be reused, it must be ensured that when the resource is recycled (that is, when the resource's recycle() is called), it must be guaranteed that there is no external reference to the resource. This is why glide spends so much logic to ensure that the resources in Lrucache are not referenced by outsiders.
5. How is the size of a picture calculated in Glide?
The formula for calculating the memory occupied by a picture: picture height * picture width * memory size occupied by one pixel. Therefore, when calculating the memory size of a picture, you must consider the directory where the picture is located and the device density. These two factors actually affect the width and height of the picture. Android will upscale and compress the picture.
The author just briefly explained the internal implementation mechanism of Glide, but this is far from enough. If you want to have a concrete understanding of Glide or other popular third-party libraries , you must go deep into the source code to experience the art .
Help a collection of source code interviews for Android popular tripartite libraries
Therefore, in order to systematically integrate the knowledge involved in the popular third-party libraries , the author spent nearly half a month to integrate the Android hot fix framework, plug-in framework, component framework, image loading framework, network access framework, RxJava responsive programming Framework, IOC dependency injection framework, recent architecture component Jetpack and other Android third-party open source frameworks are integrated into a set of system knowledge notes PDF, up to 1042 pages! I believe that after reading this document, you will have a deeper and more systematic understanding of these Android third-party frameworks.
Chapter 1: Hot Repair
1. AOT/JIT & dexopt and dex2oat
2. CLASS_ISPREVERIFIED problem of hot fix common problems
3. Hot fix principle
4. Tinker integration and use (automatic patch package generation)
Chapter 2: Pluginization
1. Interpretation of the structure of Class file and Dex file
2. Detailed explanation of Android resource loading mechanism
3. Calling principle of four major components
4. So file loading mechanism
5. Implementation principle of Android system service
Three: componentized framework design
1. Alibaba open source routing box-ARouter principle analysis
2. Automatic code generation & dynamic class loading during APT compilation
3. Java SPI mechanism
4. AOP&IOC
5. Handwritten component architecture
Four, picture loading frame
1. Picture loading frame selection
2. Glide principle analysis
3. Handwritten picture loading frame actual combat
Five, network request framework
1. Essential foundation for network communication
2. Interpretation of OkHttp source code
Six, RXJava responsive programming framework design
1. Chained call
2. Extended observer mode
3. Event transformation design
4. Scheduler thread control
Seven, IOC architecture design
1. Dependency injection and inversion of control
2. ButterKnife principle
3. Dagger architecture design core decryption
8. Android architecture component Jetpack
1.
How does LiveData work ? 2. How does Navigation solve the problem of tabLayout
? 3. How does ViewModel perceive the view life cycle and core principles?
4. Room architecture method
5. Why does DataBinding support MVVM?
6, WorkManager kernel decryption
7, Lifecycles life cycle
