1.创建子模块

这里我们创建一个子模块

1
2

group = 'com.ray.study'
artifact ='spring-boot-03-muti-view-resolver'

1.创建子模块

这里我们创建一个子模块

1
2

group = 'com.ray.study'
artifact ='spring-boot-03-freemarker'

1.创建子模块

这里我们创建一个子模块

1
2

group = 'com.ray.study'
artifact ='spring-boot-03-thymeleaf'

前言

尝试使用Spring MVC来实现一组对User对象操作的RESTful API，配合注释详细说明在Spring MVC中如何映射HTTP请求、如何传参、如何编写单元测试。

一、构建Restful API

1.创建子模块

1.1 创建项目

这里我们创建一个项目

一、前言

本文我们将开始总结springboot的相关知识，通过一个入门小示例来了解springboot的快速开发。

二、简介

1.设计目的

简化 Spring 应用的初始搭建以及开发过程

DiskLruCache : https://github.com/JakeWharton/DiskLruCache

DiskLruCache 在 Android 开发中应用的非常广泛，比较常用的就是图片的三级缓存中。比如在 Glide 中，图片在硬盘上的缓存就是采用了 DiskLruCache 。

在 DiskLruCache 中有三种文件，

• journal 文件，里面是记录着我们的操作日志；
• journal.tmp 文件，这个文件是临时文件；
• journal.bkp 文件，这个文件是备份文件。

本篇是 Glide 系列的最后一篇，主要讲一下 into 方法里面的逻辑。into 的逻辑也是最多最复杂的，可能需要反复阅读源码才能搞清楚。

Glide : https://github.com/bumptech/glide

version : v4.9.0

RequestBuilder

1
2
3
4
5
6
7
8
9
10
11
12
13

@NonNull
public <Y extends Target<TranscodeType>> Y into(@NonNull Y target) {
  return into(target, /*targetListener=*/ null, Executors.mainThreadExecutor());
}

@NonNull
@Synthetic
<Y extends Target<TranscodeType>> Y into(
    @NonNull Y target,
    @Nullable RequestListener<TranscodeType> targetListener,
    Executor callbackExecutor) {
  return into(target, targetListener, /*options=*/ this, callbackExecutor);
}

之前已经讲过 Glide.with 了，那么今天就来讲讲 load 方法。

Glide : https://github.com/bumptech/glide

version : v4.9.0

源码解析

load 重载的方法有很多，这里就挑一个看了。来看看 load(String string) 内部的代码。

RequestManager

1
2
3
4
5
6

@NonNull
@CheckResult
@Override
public RequestBuilder<Drawable> load(@Nullable String string) {
  return asDrawable().load(string);
}

前言

Glide是一个快速高效的Android图片加载库，注重于平滑的滚动。Glide提供了易用的API，高性能、可扩展的图片解码管道（decode pipeline），以及自动的资源池技术。

Glide 充分考虑了Android图片加载性能的两个关键方面：

• 图片解码速度
• 解码图片带来的资源压力

为了让用户拥有良好的App使用体验，图片不仅要快速加载，而且还不能因为过多的主线程I/O或频繁的垃圾回收导致页面的闪烁和抖动现象。

Glide使用了多个步骤来确保在Android上加载图片尽可能的快速和平滑：

MultiDex 是什么？

当Android系统安装一个应用的时候，有一步是对Dex进行优化，这个过程有一个专门的工具来处理，叫DexOpt。DexOpt的执行过程是在第一次加载Dex文件的时候执行的。这个过程会生成一个ODEX文件，即Optimised Dex。执行ODex的效率会比直接执行Dex文件的效率要高很多。

但是在早期的Android系统中，DexOpt有一个问题，DexOpt会把每一个类的方法id检索起来，存在一个链表结构里面。但是这个链表的长度是用一个short类型来保存的，导致了方法id的数目不能够超过65536个。当一个项目足够大的时候，显然这个方法数的上限是不够的。尽管在新版本的Android系统中，DexOpt修复了这个问题，但是我们仍然需要对低版本的Android系统做兼容。