-- 开启事务

start transaction;



-- 若干条执行sql

-- 提交/回滚事务

commit/rollback;

KRouter（Kotlin-Router） 是一个非常轻量级的 Kotlin 路由框架。

具体而言，KRouter 是一个通过 URI 发现接口实现类的框架。就像这样：

val homeScreen = KRouter.route<Screen>("screen/home?name=zhangke")

起因是段时间用 Voyager 时发现模块间的互相通信没这么灵活，需要一些配置，以及 DeepLink 的使用也有点奇怪，相比较而言我更希望能用路由的方式来实现模块间通信，于是就有了这个库。

github.com/0xZhangKe/K…

主要通过 KSP、ServiceLoader 以及反射实现。

使用

上面的那行代码几乎就是全部的使用方式了。

正如上面说的，这个是用来发现接口实现类并且通过 URI 匹配目的地的库，那么我们需要先定义一个接口。

interface Screen

然后我们的项目中与很多各自独立的模块，他们都会实现这个接口，并且每个都有所不同，我们需要通过他们各自的路由（即 URI ）来进行区分。

// HomeModule

@Destination("screen/home")

class HomeScreen(@Router val router: String = "") : Screen



// ProfileModule

@Destination("screen/profile")

class ProfileScreen : Screen {

    @Router

    lateinit var router: String

}

现在我们的两个独立的模块都有了各自的 Screen 了，并且他们都有自己的路由地址。

val homeScreen = KRouter.route<Screen>("screen/home?name=zhangke")

val profileScreen = KRouter.route<Screen>("screen/profile?name=zhangke")

现在就可以通过 KRouter 拿到这两个对象了，并且这两个对象中的 router 属性会被赋值为具体调用 KRouter.route 时的路由。这样你就可以在 HomeScreen 以及 ProfileScreen 拿到通过 uri 传的参数了，然后可以使用这些参数做一些初始化之类的操作。

@Destination

Destination 注解用于注解一个目的地，它包含两个参数：

• route: 目的地的唯一标识的路由地址，必须是个 URI 类型的 String，不需要包含 query。
• type : 路由目的地的接口，如果这个类只有一个父类或接口的话是不用设置这个参数的，可以自动推断出来，但如果包含多个父类就需要通过 type 显示指定了。

然后还有个很重要的点，Destination 注解的类，也就是目的地类，必须包含一个无参构造器，否则 ServiceLoader 无法创建对象，对于 Kotlin 类来说，需要保证构造器中的每个入参都有默认值。

@Router

Router 注解用于表示目的地类中的那个属性是用来接受传入的 router 参数的，该属性必须是 String 类型。

标记了该注解的属性会被自动赋值，也可以不设置改注解。

举例来说，上面的例子中的 HomeScreen 对象被创建完成后，其 router 字段的值为 screen/home?name=zhangke。

特别注意，如果 @Router 注解的属性不在构造器中，那么需要设置为可修改的，即 Kotlin 中的 var 修饰的变量属性。

KRouter

KRouter 是个单例类，其中只有一个方法。

inline fun <reified T : Any> route(router: String): T?

包含一个范形以及一个路由地址，路由地址可以包含 query 也可以不包含，匹配目的地时会忽略 query 字段。

匹配成功后会通过这个 uri 构建对象，并将 uri 传递给改对象中的 @router 注解标注的字段。

集成

首先需要在项目中集成 KSP。

然后添加依赖：

// module's build.gradle.kts

implementation("com.github.0xZhangKe.KRouter:core:0.1.5")

ksp("com.github.0xZhangKe.KRouter:compiler:0.1.5")

因为是使用了 ServiceLoader ，所以还需要设置 SourceSet。

// module's build.gradle.kts

kotlin {

    sourceSets.main {

        resources.srcDir("build/generated/ksp/main/resources")

    }

}

或许你还需要添加 JitPack 仓库：

maven { setUrl("https://jitpack.io") }

原理

正如上面所说，本框架主要使用 ServiceLoader + KSP + 反射实现。

框架主要包含两部分，一是编译阶段的部分，二是运行时部分。

KSP 插件

KSP 插件相关的代码在 compiler 模块。

KSP 插件的主要作用是根据 Destination 注解生成 ServiceLoader 的 services 文件。

KSP 的其他代码基本都差不多，主要就是先配置 services 文件，然后根据注解获取到类，然后通过 Visitor 遍历处理，我们直接看 KRouterVisitor 即可。

override fun visitClassDeclaration(classDeclaration: KSClassDeclaration, data: Unit) {

    val superTypeName = findSuperType(classDeclaration)

    writeService(superTypeName, classDeclaration)

}

在 visitClassDeclaration 方法主要做两件事情，第一是获取父类，第二是写入或创建 services 文件。

流程就是先获取 type 指定的父类，没有就判断只有一个父类就直接返回，否则抛异常。

// find super-type by type parameter

val routerAnnotation = classDeclaration.requireAnnotation<Destination>()

val typeFromAnnotation = routerAnnotation.findArgumentTypeByName("type")

        ?.takeIf { it != badTypeName }



// find single-type

if (classDeclaration.superTypes.isSingleElement()) {

    val superTypeName = classDeclaration.superTypes

        .iterator()

        .next()

        .typeQualifiedName

        ?.takeIf { it != badSuperTypeName }

    if (!superTypeName.isNullOrEmpty()) {

        return superTypeName

    }

}

获取到之后我们需要按照 ServiceLoader 的要求将接口或抽象类的权限定名作为文件名创建一个文件。

然后再将实现类的权限定名写入该文件。

val resourceFileName = ServicesFiles.getPath(superTypeName)

val serviceClassFullName = serviceClassDeclaration.qualifiedName!!.asString()

val existsFile = environment.codeGenerator

    .generatedFile

    .firstOrNull { generatedFile ->

        generatedFile.canonicalPath.endsWith(resourceFileName)

    }

if (existsFile != null) {

    val services = existsFile.inputStream().use { ServicesFiles.readServiceFile(it) }

    services.add(serviceClassFullName)

    existsFile.outputStream().use { ServicesFiles.writeServiceFile(services, it) }

} else {

    environment.codeGenerator.createNewFile(

        dependencies = Dependencies(aggregating = false, serviceClassDeclaration.containingFile!!),

        packageName = "",

        fileName = resourceFileName,

        extensionName = "",

    ).use {

        ServicesFiles.writeServiceFile(setOf(serviceClassFullName), it)

    }

}

这样就自动生成了 ServiceLoader 所需要的 services 文件了。

KRouter

KRouter 主要做三件事情：

• 通过 ServiceLoader 获取接口所有的实现类。
• 通过 URI 匹配具体的目的地类。
• 通过 URI 构建目的地类对象。

第一件事情很简单：

inline fun <reified T> findServices(): List<T> {

    val clazz = T::class.java

    return ServiceLoader.load(clazz, clazz.classLoader).iterator().asSequence().toList()

}

获取到之后就可以通过 URL 来开始匹配。

匹配方式就是获取每个目的地类的 Destination 注解中的 router 字段，然后与路由进行对比。

fun findServiceByRouter(

    serviceClassList: List<Any>,

    router: String,

): Any? {

    val routerUri = URI.create(router).baseUri

    val service = serviceClassList.firstOrNull {

        val serviceRouter = getRouterFromClassAnnotation(it::class)

        if (serviceRouter.isNullOrEmpty().not()) {

            val serviceUri = URI.create(serviceRouter!!).baseUri

            serviceUri == routerUri

        } else {

            false

        }

    }

    return service

}



private fun getRouterFromClassAnnotation(targetClass: KClass<*>): String? {

    val routerAnnotation = targetClass.findAnnotation<Destination>() ?: return null

    return routerAnnotation.router

}

因为匹配策略是忽略 query 字段，所以只通过 baseUri 匹配即可。

下面就是创建对象，这里有两种情况需要考虑。

第一是 @Router 注解在构造器中，这种情况需要重新使用构造器创建对象。

第二种是 @Router 注解在普通属性中，此时直接使用 ServiceLoader 创建好的对象然后赋值即可。

如果在构造器中，先获取 routerParameter 参数，然后通过 PrimaryConstructor 重新创建对象即可。

private fun fillRouterByConstructor(router: String, serviceClass: KClass<*>): Any? {

    val primaryConstructor = serviceClass.primaryConstructor

        ?: throw IllegalArgumentException("KRouter Destination class must have a Primary-Constructor!")

    val routerParameter = primaryConstructor.parameters.firstOrNull { parameter ->

        parameter.findAnnotation<Router>() != null

    } ?: return null

    if (routerParameter.type != stringKType) errorRouterParameterType(routerParameter)

    return primaryConstructor.callBy(mapOf(routerParameter to router))

}

如果是普通的变量属性，那么先获取到这个属性，然后做一些类型权限之类的校验，然后调用 setter 赋值即可。

private fun fillRouterByProperty(

    router: String,

    service: Any,

    serviceClass: KClass<*>,

): Any? {

    val routerProperty = serviceClass.findRouterProperty() ?: return null

    fillRouterToServiceProperty(

        router = router,

        service = service,

        property = routerProperty,

    )

    return service

}



private fun KClass<*>.findRouterProperty(): KProperty<*>? {

    return declaredMemberProperties.firstOrNull { property ->

        val isRouterProperty = property.findAnnotation<Router>() != null

        isRouterProperty

    }

}



private fun fillRouterToServiceProperty(

    router: String,

    service: Any,

    property: KProperty<*>,

) {

    if (property !is KMutableProperty<*>) throw IllegalArgumentException("@Router property must be non-final!")

    if (property.visibility != KVisibility.PUBLIC) throw IllegalArgumentException("@Router property must be public!")

    val setter = property.setter

    val propertyType = setter.parameters[1]

    if (propertyType.type != stringKType) errorRouterParameterType(propertyType)

    property.setter.call(service, router)

}

OK，以上就是关于 KRouter 的所有内容了。

Kotlin 泛型类型

Kotlin 的泛型特性允许我们编写出更加灵活和通用的代码，提高了代码的可重用性和类型安全性。

本文将介绍 Kotlin 中的四种泛型类型

• 类型参数
• 星号投影
• 型变
• 泛型限制

类型参数

定义一个泛型类或函数时，使用尖括号 < > 来指定类型参数。例如，以下是一个将泛型类型 T 用作参数的示例：

class MyList<T> { ... }

在这个示例中，T 是一个占位符类型参数，用于表示某个类型。在使用该类时，可以通过指定实际的类型参数来创建具体类型的实例。例如：

val list = MyList<String>()

在这个示例中，我们创建了一个 MyList 类型的实例，并将 String 类型指定为其类型参数。这意味着 list 变量可以存储 String 类型的元素。

星号投影

星号投影是一种特殊语法，用于表示您不关心实际类型参数的情况。通过使用 * 替代类型参数，您可以指定该参数将被忽略。例如，以下是一个使用星号投影的示例：

fun printList(list: List<*>) {

  for (item in list) {

    println(item)

  }

}

在这个示例中，printList 函数接收一个 List<*> 类型的参数，该类型使用星号投影来表示它可以存储任何类型的元素。循环遍历该列表，并将每个元素输出到控制台。

型变

型变是指泛型类型之间的继承关系。在 Kotlin 中，有三种型变：in、out 和 invariant。这些型变用于描述子类型和超类型之间的关系，并影响如何将泛型类型赋值给其他类型。

1. in 型变：用于消费型位置（比如方法参数），表示只能从泛型类型中读取数据，不能写入数据。

   interface Source<out T> {
   
     fun next(): T
   
   }
   
   
   
   fun demo(strs: Source<String>) {
   
     val objects: Source<Any> = strs 
   
     // ...
   
   }
   
   

   在这个示例中，我们定义了一个泛型接口 Source，并使用 out 关键字将其标记为协变类型。这意味着我们可以将 Source<String> 类型的对象视为 Source<Any> 类型的对象，并将其赋值给 objects 变量。

2. out 型变：用于生产型位置（比如返回值），表示只能向泛型类型中写入数据，不能读取数据。

   interface Sink<in T> {
   
     fun put(element: T)
   
   }
   
   
   
   fun demo(sinkOfAny: Sink<Any>) {
   
     val sinkOfString: Sink<String> = sinkOfAny 
   
     // ...
   
   }
   
   

   在这个示例中，我们定义了一个泛型接口 Sink，并使用 in 关键字将其标记为逆变类型。这意味着我们可以将一个 Sink<Any> 类型的对象视为 Sink<String> 类型的对象，并将其赋值给 sinkOfString 变量。

3. invariant 型变：默认情况下，Kotlin 中的泛型类型都是不变（invariant）的。这意味着不能将一个 List<String> 类型的对象视为 List<Any> 类型的对象。

泛型限制

泛型限制用于约束泛型类型可以具体化为哪些类型。例如，使用 where 关键字可以给泛型类型添加多个限制条件。以下是一个使用泛型限制的示例：

fun <T> showItems(list: List<T>) where T : CharSequence, T : Comparable<T> {

    list.filter { it.length > 5 }.sorted().forEach(::println)

}

在这个示例中，我们定义了一个名为 showItems 的函数，它接受一个 List<T> 类型的参数，并对该列表进行过滤、排序和输出操作。其中，T 是一个泛型类型参数，用于表示列表中的元素类型。

为了限制 T 的类型，我们使用 where 关键字并添加了两个限制条件：T 必须实现 CharSequence 接口和 Comparable 接口。这意味着当我们调用 showItems 函数时，只能传递那些既实现了 CharSequence 接口又实现了 Comparable 接口的类型参数。

需要注意的是，在 Kotlin 中使用泛型限制时，限制条件必须放在 where 关键字之后，并且使用逗号 , 分隔各个限制条件。如果有多个限制条件，建议将它们放在新行上，以提高代码的可读性。

前言

Hi,大家好,我是你们的秃头朋友程序员小甲,相信各位码农朋友在搭建从0到1项目时在搭建完基建等任务后,最先去做的都是去搭建系统的用户体系,那么每一个码农朋友都会去编码属于自己系统的一套用户登录注册体系;但是登录方式极其多样,光小甲一个人对接的就有google登录,苹果登录,手机验证码,微信验证码登录,微博登录等各种各样的登录;

针对这么多的登录方式,小甲是如何进行功能接入的呢?(Ps:直接switch-case和if-else接入不香吗,又不是不能用,这其实是小甲做功能时最真实的想法了,但是迫于团队老大哥的强大气场,小甲自然不敢这样硬核编码了),接下来就让秃头小甲和大伙一起分享一下是怎么让普普通通的登录也能玩出逼格的!(由于篇幅过长,接下来进入硬核时刻,希望各位能挺住李云龙二营长的意大利跑前进哈)

功能实现

技术栈:SpringBoot,MySQL,MyBatisPlus,hutool,guava,Redis,Jwt,Springboot-emial等;

sdk组件架构

项目结构包:

1.    tea-api(前台聚合服务)

2.    tea-mng(后管聚合服务)

3.    tea-sdk(SpringBoot相关组件模块)

4.    tea-common(公共模块,提供一些工具类支持和公有类引用)
   
   

项目结构引用关系: sdk引入了common包,api和mng引入了sdk包；

封装思路

思路一:通过前端登录路由请求头key值通过反射生成对应的LoginProvider类来进行登录业务逻辑的执行。具体的做法如下:

1. 在classPath路径下新增一个json/Provider.json文件,json格式如下图所示:

2. 定义具体的Provider继承基类Provider,秃头小甲这里定义了一般业务系统最常对接的集中Provider(PS:由于google登录和App登录主要是用于对接海外业务,因此小甲这里就没把集成代码放出来了)如下图是小甲定义的几个Provider:

其中UserLoginService是所有Provider的基类接口,封装了模板方法。EmialLoginProvider类主要是实现邮箱验证码登录,PasswordProvider用于实现账号密码登录,PhoneLoginProvider是用于手机号验证码登录.WbLoginProvider用于实现PC端微博授权登录,WxLoginPrvider用于实现微信PC端授权登录;

3.EmailLoginProvider和PhoneLoginProvider需要用到验证码校验,因此需要实现UserLoginService接口的验证码获取,并将获取到的验证码存储到redis中;

4.将前端的路由gateWay作为key值,需要加载的动态类名作为value值。定义一个LoginService业务处理类,类中定义一个Map缓存对象,在bean注入加载到ioc容器时,通过读取解析json文件对Map缓存进行反射属性注入,该设计理念参考了Springboot的SPI注入原理以此实现对Provider的可拔插操作;

思路二:

1. 通过SpringBoot事件监听机制,通过前端路由请求头的key值发布生成不同的ApplicationEvent事件,利用事件监听对业务处理解耦;
2. 定义具体的Event事件以及Listener;
3. 根据前端路由gateWay值生成需要发布的Event事件基类,在具体的listener类上根据@EventListener注解来对具体的事件进行监听处理;

思路对比

思路一通过模板+工厂+反射等设计模式的原理对多方式登录方式来达到解耦和拓展,从而规避了开发人员大量的if-else或switch等硬编码的方式,思路二通过模板+工厂+事件监听机制等设计模式也做到了对多方式登录的解耦和拓展,两种思路均能做到延伸代码的拓展性的作用;

封装源码

1.基类UserLoginService

/**

 * 登录

 *

 * @param req 登录请求体

 * @return

 */

LoginResp login(LoginReq req);





/**

 * 验证码获取

 *

 * @param req 登录请求体

 * @return

 */

LoginResp vertifyCode(LoginReq req);

2.拓展类Provider代码

public class EmailLoginProvider implements UserLoginService {



    @Override

    public LoginResp login(LoginReq req) {

        UserService userService = SpringUtil.getBean(UserService.class);

        User user = userService.getOne(Wrappers.lambdaQuery(new User()).eq(User::getEmail, req.getEmail()).eq(User::getStatus, 1));

        if (Objects.isNull(user)) {

            return null;

        }

        String redisKey = req.getEmail();

        RedisTemplate redisTemplate = SpringUtil.getBean(StringRedisTemplate.class);

        String code = (String) redisTemplate.opsForValue().get(redisKey);

        if (StringUtils.isEmpty(code)||!code.equals(req.getCode())) {

            return null;

        }

        String token = JwtParse.getoken(user);

        LoginResp resp = new LoginResp();

        resp.setToken(token);

        return resp;

    }



    @Override

    public LoginResp vertifyCode(LoginReq req) {

        String redisKey = req.getEmail();

        LoginResp resp = new LoginResp();

        RedisTemplate redisTemplate = SpringUtil.getBean(StringRedisTemplate.class);

        String code = (String) redisTemplate.opsForValue().get(redisKey);

        if (StringUtils.isNotEmpty(code)) {

            resp.setCode(code);

            return resp;

        }

        MailService mailService = SpringUtil.getBean(MailService.class);

        String mailCode = CodeUtils.make(4);

        mailService.sendMail(req.getEmail(), "邮箱验证码", mailCode);

        redisTemplate.opsForValue().set(req.getEmail(), mailCode);

        return resp;

    }

}

public class PasswordProvider implements UserLoginService {



    @Override

    public LoginResp login(LoginReq req) {

        UserService userService = SpringUtil.getBean(UserService.class);

        User user = userService.getOne(Wrappers.lambdaQuery(new User()).eq(User::getPassword, req.getPassword()).eq(User::getStatus, 1));

        if (Objects.isNull(user)) {

            return null;

        }

        String token = JwtParse.getoken(user);

        LoginResp resp = new LoginResp();

        resp.setToken(token);

        return resp;

    }



    @Override

    public LoginResp vertifyCode(LoginReq req) {

        return null;

    }

}

public class PhoneLoginProvider implements UserLoginService {



    @Override

    public LoginResp login(LoginReq req) {

        UserService userService = SpringUtil.getBean(UserService.class);

        User user = userService.getOne(Wrappers.lambdaQuery(new User()).eq(User::getPhone, req.getPhone()).eq(User::getStatus, 1));

        if (Objects.isNull(user)) {

            return null;

        }

        String redisKey = req.getPhone();

        RedisTemplate redisTemplate = SpringUtil.getBean(RedisTemplate.class);

        String code = (String) redisTemplate.opsForValue().get(redisKey);

        if (!code.equals(req.getCode())) {

            return null;

        }

        String token = JwtParse.getoken(user);

        LoginResp resp = new LoginResp();

        resp.setToken(token);

        return resp;

    }



    @Override

    public LoginResp vertifyCode(LoginReq req) {

        String redisKey = req.getPhone();

        LoginResp resp = new LoginResp();

        RedisTemplate redisTemplate = SpringUtil.getBean(RedisTemplate.class);

        String code = (String) redisTemplate.opsForValue().get(redisKey);

        if (StringUtils.isNotEmpty(code)) {

            resp.setCode(code);

            return resp;

        }

        MailService mailService = SpringUtil.getBean(MailService.class);

        String mailCode = CodeUtils.make(4);

        mailService.sendMail(req.getPhone(), "手机登录验证码", mailCode);

        redisTemplate.opsForValue().set(req.getEmail(), mailCode);

        return resp;

    }

}

public class WxLoginProvider implements UserLoginService {



    @Override

    public LoginResp login(LoginReq req) {

        WxService wxService = SpringUtil.getBean(WxService.class);

        WxReq wxReq = new WxReq();

        wxReq.setCode(req.getAuthCode());

        WxResp token = wxService.getAccessToken(wxReq);

        String accessToken = token.getAccessToken();

        if (StringUtils.isEmpty(accessToken)) {



        }

        wxReq.setOpenid(token.getOpenid());

        WxUserInfoResp userInfo = wxService.getUserInfo(wxReq);

        //根据unionId和openid查找一下当前用户是否已经存在系统,如果不存在,帮其注册这里单纯是为了登录;

        UserService userService = SpringUtil.getBean(UserService.class);

        User user = userService.getOne(Wrappers.lambdaQuery(new User()).eq(User::getOpenId, token.getOpenid()).eq(User::getUnionId, token.getUnionId()));

        if (Objects.isNull(user)) {



        }

        String getoken = JwtParse.getoken(user);

        LoginResp resp = new LoginResp();

        resp.setToken(getoken);

        return resp;

    }



    @Override

    public LoginResp vertifyCode(LoginReq req) {

        return null;

    }

}

3.接口暴露Service--LoginService源码

@Service

@Slf4j

public class LoginService {



    private Map<String, UserLoginService> loginServiceMap = new ConcurrentHashMap<>();



    @PostConstruct

    public void init() {

        try {

            List<JSONObject> jsonList = JSONArray.parseObject(ResourceUtil.getResource("json/Provider.json").openStream(), List.class);

            for (JSONObject object : jsonList) {

                String key = object.getString("key");

                String className = object.getString("value");

                Class loginProvider = Class.forName(className);

                UserLoginService loginService = (UserLoginService) loginProvider.newInstance();

                loginServiceMap.put(key, loginService);

            }

        } catch (Exception e) {

            log.info("[登录初始化异常]异常堆栈信息为:{}", ExceptionUtils.parseStackTrace(e));

        }

    }



    /**

     * 统一登录

     *

     * @param gateWayRoute 路由路径

     * @param req          登录请求

     * @return

     */

    public RetunrnT<LoginResp> login(String gateWayRoute, LoginReq req) {

        UserLoginService userLoginService = loginServiceMap.get(gateWayRoute);

        LoginResp loginResp = userLoginService.login(req);

        return RetunrnT.success(loginResp);

    }





    /**

     * 验证码发送

     *

     * @param gateWayRoute 路由路径

     * @param req          登录请求

     * @return

     */

    public RetunrnT<LoginResp> vertifyCode(String gateWayRoute, LoginReq req) {

        UserLoginService userLoginService = loginServiceMap.get(gateWayRoute);

        LoginResp resp = userLoginService.vertifyCode(req);

        return RetunrnT.success(resp);

    }



}

4.邮件发送Service具体实现--MailService

public interface MailService {



    /**

     * 发送邮件

     *

     * @param to      收件人

     * @param subject 主题

     * @param content 内容

     */

    void sendMail(String to, String subject, String content);

}

@Service

@Slf4j

public class MailServiceImpl implements MailService {



    /**

     * Spring Boot 提供了一个发送邮件的简单抽象，直接注入即可使用

     */

    @Resource

    private JavaMailSender mailSender;

    /**

     * 配置文件中的发送邮箱

     */

    @Value("${spring.mail.from}")

    private String from;



    @Override

    @Async

    public void sendMail(String to, String subject, String content) {

//创建一个邮箱消息对象

        SimpleMailMessage message = new SimpleMailMessage();

        //邮件发送人

        message.setFrom(from);

        //邮件接收人

        message.setTo(to);

        //邮件主题

        message.setSubject(subject);

        //邮件内容

        message.setText(content);

        //发送邮件

        mailSender.send(message);

        log.info("邮件发成功:{}", message.toString());

    }

}

5.token生成JsonParse类

private static final String SECRECTKEY = "zshsjcbchsssks123";



public static String getoken(User user) {

    //Jwts.builder()生成

    //Jwts.parser()验证

    JwtBuilder jwtBuilder = Jwts.builder()

            .setId(user.getId() + "")

            .setSubject(JSON.toJSONString(user))    //用户对象

            .setIssuedAt(new Date())//登录时间

            .signWith(SignatureAlgorithm.HS256, SECRECTKEY).setExpiration(new Date(System.currentTimeMillis() + 86400000));

    //设置过期时间

    //前三个为载荷playload 最后一个为头部 header

    log.info("token为:{}", jwtBuilder.compact());

    return jwtBuilder.compact();

}

6.微信认证授权Service---WxService

public interface WxService {



    /**

     * 通过code获取access_token

     */

    WxResp getAccessToken(WxReq req);



    /**

     * 通过accessToken获取用户信息

     */

    WxUserInfoResp getUserInfo(WxReq req);

}

@Service

@Slf4j

public class WxServiceImpl implements WxService {



    @Resource

    private WxConfig wxConfig;





    @Override

    public WxResp getAccessToken(WxReq req) {

        req.setAppid(wxConfig.getAppid());

        req.setSecret(wxConfig.getSecret());

        Map map = JSON.parseObject(JSON.toJSONString(req), Map.class);

        WxResp wxResp = JSON.parseObject(HttpUtil.createGet(wxConfig.getTokenUrl()).formStr(map).execute().body(), WxResp.class);

        return wxResp;

    }



    @Override

    public WxUserInfoResp getUserInfo(WxReq req) {

        req.setAppid(wxConfig.getAppid());

        req.setSecret(wxConfig.getSecret());

        Map map = JSON.parseObject(JSON.toJSONString(req), Map.class);

        return JSON.parseObject(HttpUtil.createGet(wxConfig.getGetUserUrl()).formStr(map).execute().body(), WxUserInfoResp.class);

    }

}

功能演练

项目总结

相信很多小伙伴在平时开发过程中都能看到一定的业务硬核代码,前期设计不合理,后续开发只能在前人的基础上不断的进行if-else或者switch来进行业务的功能拓展,千里之行基于跬步,地基不稳注定是要地动山摇的,希望在接下来的时光,秃头小甲也能不断提升自己的水平,写出更多有水准的代码;

碎碎念时光

首先很感谢能看完全篇幅的各位老铁兄弟们,希望本篇文章能对各位和秃头小甲一样码农有所帮助,当然如果各位技术大大对这模块做法有更优质的做法的,也欢迎各位技术大大能在评论区留言探讨,写在最后~~~~~~ 创作不易,希望各位老铁能不吝惜于自己的手指,帮秃头点下您宝贵的赞把！

JYM大家好，好久没来写文了。

今天带给大家 Kotlin 的内容，可能一些常关注我的朋友也发现了，在我之前的文章中就开始用 Kotlin 代码做代码示例了，这是因为最近一年我都在高强度使用 Kotlin 进行后端开发。

相信很多安卓开发的朋友早就开始用上 Kotlin 了，但是许多后端对这门语言应该还是不太了解，反正在我的朋友圈里没有见到过用 Kotlin 写后端的程序员存在，在我亲身用了一年 Kotlin 之后已经不太想用 Java 进行代码开发了，起码在开发效率方面就已经是天差地别了，所以今天特地给大家分享一下 Kotlin 的好，希望能带领更多人入坑。

1. 第一段代码

很多人说 Kotlin 就是披了一层语法糖的 Java，因为它百分百兼容 Java，甚至可以做到 Kotlin 调用 Java 代码。

其实我对这个说法是赞同的，但是又不完全一样，因为 Kotlin 有自己的语法、更有自己的编译器、还有着多端支持，更有着自己的设计目标。

我更倾向于把 Kotlin 看成一个 JVM 系语言，就像 Scala 语言一样，只是恰好 Kotlin 有一个设计目标就是百分百兼容 Java。

在语言层面，Kotlin 几乎是借鉴了市面上所有的现代化语言的强大特性，协程、函数式、扩展函数、空安全，这些广受好评的特性全部都有。

而且从我个人感受来看，我用过 Java、Kotlin、JS、Go、Dart、TS、还有一点点 Python，我觉得 JS 和 Kotlin 的语法是比较方便易用的，Dart、Java 和 Go 的语法都不是太方便易用，语法的简单也在一定程度上减少了开发者的心智负担。

下面我将用一段代码，来简单说明一下 Kotlin 常见的语法特性：

fun main(args: Array<String>) {

    val name = "Rookie"



    // Hello World! Rookie

    println("Hello World! $name")



    // Hello World! 82,111,111,107,105,101

    println("Hello World! ${name.chars().toList().joinToString(",")}")

    

    test(createPerson = { Person("Rookie", 25) })



}



data class Person(

    var name: String = "",

    var age: Int = 0,

)



fun test(createPerson: () -> Person, test : String = "test"): Person {



    val person = createPerson()



    // Person(name=Rookie, age=25)

    println(person)



    return person

}

上面是一段简简单单的 Kotlin 代码，但是却可以看出 Kotlin 的很多特性，请听我娓娓道来～

1. Kotlin 的启动方法也是 main 函数，但是 Kotlin 移除了所有基础类型，一切皆对象，比如 Java 中的数组对应的就是 Array 类，int 对应的是 Int 类。
2. Kotlin 使用类型推断来声明类型，一共有两个关键字，val 代表这是一个不可变变量，var 代表这是一个可变的变量，这两个关键字选用我感觉比 JS 还要好。
3. Kotlin 代码每一行不需要英文分号结尾。
4. Kotlin 支持字符串模板，可以直接字符串中使用 '$' 符号放置变量，如果你想放置一个函数的计算结果，需要用 '${}' 来包裹。
5. Kotlin 是一个函数式语言，支持高阶函数，闭包、尾递归优化等函数式特性。
6. Kotlin 为了简化 Java Bean，支持了数据类 data class，它会自动生成无参构造、getter、setter、equals()、hashCode()、copy()、toJSON()、toString() 方法。
7. Kotlin 的函数关键字是 fun，返回值在函数的最后面，变量名在类型的前面，几乎新兴语言都是这样设计的，可以明显感受到语言设计者想让我们更多关注业务含义而非数据类型。
8. Kotlin 具有一些类似 go 和 Python 的内置函数，比如 println。
9. Kotlin 的函数参数支持默认值。
10. Kotlin 不支持多参数返回，但是为了解决这个问题它内置了两个类：Pair 和 Triple，分别可以包装两个返回值和三个返回值。

2. 基础常用特性

了解了一些 Kotlin 的基础语法之后，我再来介绍一些常用的基础特性。

第一个就是空安全和可空性。

Kotlin 中的变量可以声明为非空和可空，默认的声明都是非空，如果需要一个变量可空的，需要在类型后面加一个问号，就像这样：

fun start() {

    val name1 : String = ""

    val name : String? = null

}

函数的参数声明也一样，也会区分非空和可空，Kotlin 编译器会对代码上下文进行检查，在函数调用处也会对变量是否可空进行一致性检查，如果不通过则会有编译器提醒，我是强烈建议不用可空变量，一般都可以通过默认值来处理。

那么如果你接手的是前人代码，他声明变量为可空，但是希望为空的时候传递一个默认值，则可以使用这个语法进行处理：

fun start() {

    val name : String? = null

    println(name ?: "Rookie")

}

这是一个类似三元表达式的语法（Elvis 运算符），在 Kotlin 中极其常见，除此之外你还可以进行非空调用：

fun start() {

    val name : String? = null

    println(name?.chars() ?: "Rookie")

}

这段代码就表示：如果变量不为空就调用 chars 方法，如果为空则返回默认值 Rookie，在所有可空变量上都支持这种写法，并且支持链式调用。

第二个常用特性是异常处理, 写到这里突然想到了一个标题，Kotlin 的异常处理，那叫一个优雅！！！

fun start() {

    val person = runCatching {

        test1()

    }.onFailure {



    }.onSuccess {



    }.getOrNull() ?: Person("Rookie", 25)

}



fun test1() : Person {

    return Person()

}

这一段代码中的 test1 方法你可以当作一个远程调用方法或者逻辑方法，对了，这里隐含了一个语法，就是一个函数中的最后一行的计算结果是它的返回值，你不需要显示的去写 return。

我使用 runCatching 包裹我们的逻辑方法，然后有三个链式调用：

1. onFailure：当逻辑方法报错时会进入这个方法。
2. onSuccess：当逻辑方法执行成功时会进入这个方法。
3. getOrNull：当逻辑方法执行成功时正常返回，执行失败时返回一个空变量，然后我们紧跟一个 ?: ，这代表当返回值为空时我们返回自定义的默认值。

如此一来，一个异常处理的闭环就完成了，每一个环节都会被考虑到，这些链式调用的方法都是可选的，如果你不手动调用处理会有默认的处理方式，大家伙觉得优雅吗？

第三个特性是改进后的流程控制。

fun start() {

    val num = (1..100).random()

    val name = if (num == 1) "1" else { "Rookie" }

    val age = when (num) {

        1 -> 10

        2 -> 20

        else -> { (21..30).random() }

    }

}

我们先声明一个随机数，然后根据条件判断语句返回不同的值，其中 Java 中的 Switch 由 When 语法来替代。

而且这里每一段表达式都可以是一个函数，大家可以回忆一下，如果你使用 Java 来完成通过条件返回不同变量的逻辑会有多麻烦。

如果大家在不了解 Kotlin 的情况下尝试用更简单的方式来写逻辑，可以问问类似 ChatGPT 这种对话机器人来进行辅助你。

3. 常用内置函数

就像每个变量类型都有 toString 方法一样，Kotlin 中的每个变量都具有一些内置的扩展函数，这些函数可以极大的方便我们开发。

apply和also

fun start() {

    val person = Person("Rookie", 25)



    val person1 = person.apply {

        println("name : $name, age : $age, This : $this")

    }



    val person2 = person.also {

        println("name : ${it.name}, age : ${it.age}, This : $it")

    }

}

这两个函数调用之后都是执行函数体后返回调用变量本身，不同的是 apply 的引用为 this，内部取 this 变量时不需要 this.name 可以直接拿 name 和 age 变量。

而 also 函数则默认有一个 it，it 就是这个变量本身的引用，我们可以通过这个 it 来获取相关的变量和方法。

run 和 let

fun start() {

    val person = Person("Rookie", 25)



    val person1 = person.run {

        println("name : $name, age : $age, This : $this")

        "person1"

    }



    val person2 = person.let {

        println("name : ${it.name}, age : ${it.age}, This : $it")

        "person2"

    }

}

run 函数和 let 函数都支持返回与调用变量不同的返回值，只需要将返回值写到函数最后一行或者使用 return 语句进行返回即可，上例中 person 变量进行调用之后的返回结果就是一个 String 类型。

在使用上的具体差异也就是引用对象的指向不同，具体更多差异可以看一下网络上总结，我这里表明用法就可以了。

除了这四个函数之外，还有许多的类似函数帮我们来做一些很优雅的代码处理和链式调用，但是我根本没有用过其它的函数，这四个函数对我来说已经足够了，有兴趣的朋友可以慢慢发掘。

4. 扩展函数与扩展属性

上文了我们举了几个常见的内置函数，其实他们都是使用 Kotlin 的扩展函数特性实现的。

所谓扩展函数就是可以为某个类增加扩展方法，比如给 JDK 中的 String 类增加一个 isRookie 方法来判断某个字符串是否是 Rookie：

fun start() {

    val name = "rookie"

    println(name.isRookie())

}



fun String.isRookie(): Boolean {

    return this == "Rookie"

}

this 代表了当前调用者的引用，利用扩展函数你可以很方便的封装一些常用方法，比如 Long 型转时间类型，时间类型转 Long 型，不比像以前一样再用工具类做调用了。

除了扩展函数，Kotlin 还支持扩展属性：

fun start() {

    val list = listOf(1, 2, 3)

    println(list.maxIndex)

}



val <T> List<T>.maxIndex: Int

    get() = if (this.isEmpty()) -1 else this.size - 1

通过定义一个扩展属性和定义它的 get 逻辑，我们就可以为 List 带来一个全新属性——maxIndex，这个属性用来返回当前 List 的最大元素下标。

扩展函数和扩展属性多用于封闭类，比如 JDK、第三方 jar 包作为扩展使用，它的实际使用效果其实和工具类是一样的，只不过更加优雅。

不过借用这个能力，Kotlin 为所有的常用类都增加了一堆扩展，比如 String：

基本上你可以想到的大部分函数都已经被 Kotlin 内置了，这就是 Kotlin 的语法糖。

5. Kotlin的容器

终于来到我们这篇文章的大头了，Kotlin 中的容器基本上都是：List、Map 扩展而来，作为一个函数式语言，Kotlin 将容器分为了可变与不可变。

我们先来看一下普遍的用法：

fun start() {

    val list = listOf(1, 2, 3)

    val set = setOf(1, 2, 3)

    val map = mapOf(1 to "one", 2 to "two", 3 to "three")

}

上面的例子中，我们使用三个内置函数来方便的创建对应的容器，但是此时创建的容器是不可变的，也就是说容器内的元素只能读取，不能添加、删除和修改。

当然，Kotlin 也为此类容器增加了一些方法，使其可以方便的增加元素，但实际行为并不是真的往容器内增加元素，而是创建一个新的容器将原来的数据复制过去：

fun start() {

    val list = listOf(1, 2, 3).plus(4)

    val set = setOf(1, 2, 3).plus(4)

    val map = mapOf(1 to "one", 2 to "two", 3 to "three").plus(4 to "four")

}

如果我们想要创建一个可以增加、删除元素的容器，也就是可变容器，可以用以下函数：

fun start() {

    val list = mutableListOf(1, 2, 3)

    val set = mutableSetOf(1, 2, 3)

    val map = mutableMapOf(1 to "one", 2 to "two", 3 to "three")

}

讲完了，容器的创建，可以来聊聊相关的一些操作了，在 Java 中有一个 Stream 流，在 Stream 中可以很方便的做一些常见的函数操作，Kotlin 不仅完全继承了过来，还加入了大量方法，大概可以包含以下几类：

1. 排序：sort
2. 乱序：shuffle
3. 分组：group、associate、partition、chunked
4. 查找：filter、find
5. 映射：map、flatMap
6. 规约：reduce、min、max

由于函数实在太多，我不能一一列举，只能给大家举一个小例子：filter：

一个 filter 有这么多种多样的函数，几乎可以容纳你所有的场景，这里说两个让我感觉到惊喜的函数：chunked 和 partition。

chunked 函数是一个分组函数，我常用的场景是避免请求量过大，比如在批量提交时，我可以将一个 list 中的元素进行 1000 个一组，每次提交一组：

fun start() {

    val list = mutableListOf(1, 2, 3)



    val chunk : List<List<Int>> = list.chunked(2)

}

示例代码中为了让大家看的清楚我故意声明了类型，实际开发中可以不声明，会进行自动推断。

在上面这个例子中，我将一个 list 进行每组两个进行分组，最终得到一个 List<List> 类型的变量，接下来我可以使用 forEach 进行批量提交，它底层通过 windowed 函数进行调用，这个函数也可以直接调用，有兴趣的朋友可以研究一下效果，通过名字大概可以知道是类似滑动窗口。

partition 你可以将其看作一个分组函数，它算是 filter 的补充：

fun start() {

    val list = mutableListOf(1, 2, 3)



    val partition = list.partition { it > 2 }

    

    println(partition.first)

    println(partition.second)

}

它通过传入一个布尔表达式，将一个 List 分为两组，返回值是上文提到过的 Pair 类型，Pair 有两个变量：first 和 second。

partition 函数会将符合条件的元素放到 first 中去，不符合条件的元素放到 second 中，我自己的使用的时候很多是为了日志记录，要把不处理的元素也记录下来。

容器与容器之间还可以直接通过类似：toList、toSet之类的方法进行转换，非常方便，转换 Map 我一般使用 associate 方法，它也有一系列方法，主要作用就是可以转换过程中自己指定 Map 中的 K 和 V。

6. 结束语

不知不觉都已经快四千字了，我已经要结束这篇文章了，但是仍然发现几乎什么都没写，也对，这只是一篇给大家普及 Kotlin 所带来效率的提升的文章，而不是专精的技术文章。

正如我在标题中写的那样：Kotlin 的语法糖到底有多甜？Kotlin 的这一切我都将其当作语法糖，它能极大提高我的开发效率，但是一些真正 Kotlin 可以做到而 Java 没有做到的功能我却没有使用，比如：协程。

由于我一直是使用 Kotlin 写后端，而协程的使用场景我从来没有遇到过，可能做安卓的朋友更容易遇到，所以我没有对它进行举例，对于我来说，Kotlin 能为我的开发大大提效就已经很不错了。

使用 Kotlin 有一种使用 JS 的感觉，有时候可以一个方法开头就写一个 return，然后链式调用一直到方法结束。

我还是蛮希望 Java 开发者们可以转到 Kotlin，感受一下 Kotlin 的魅力，毕竟是百分百兼容。

在这里要说一下我使用的版本，我使用的是 JDK17、Kotlin 1.8、Kotlin 编译版本为 1.8，也就是说 Kotlin 生成的代码可以跑在最低 JDK1.8 版本上面，这也是一个 Kotlin 的好处，你可以通过升级 Kotlin 的版本体验最新的 Kotlin 特性，但是呢，你的 JDK 平台不用变。

对了，Kotlin 将反射封装的极好，喜欢研究的朋友也可以研究一下。

好了，这篇文章就到这里，希望大家能帮我积极点赞，提高更新动力，人生苦短，我用KT。

Join的类型

1. left join，以左表为驱动表，以左表作为结果集基础，连接右表的数据补齐到结果集中

2. right join，以右表为驱动表，以右表作为结果集基础，连接左表的数据补齐到结果集中

3. inner join，结果集取两个表的交集

4. full join，结果集取两个表的并集

1. 1. mysql没有full join，union取代
   2. union与union all的区别为，union会去重

5. cross join 笛卡尔积

1. 1. 如果不使用where条件则结果集为两个关联表行的乘积
   2. 与，的区别为，cross join建立结果集时会根据on条件过滤结果集合

7. straight_join

1. 1. 严格根据SQL顺序指定驱动表，左表是驱动

Join原理

本质上可以理解为嵌套循环的操作，驱动表作为外层for循环，被驱动表作为内层for循环。根据连接组成数据的策略可以分为三种算法。

Simpe Nested-Loop Join

1. 连接比如有A表，B表，两个表JOIN的话会拿着A表的连表条件一条一条在B表循环，匹配A表和B表相同的id 放入结果集，这种效率是最低的。

Index Nested-Loop Join

1. 执行流程（磁盘扫描）

1. 1. 从表t1中读入一行数据 R；
   2. 从数据行R中，取出a字段到表t2里进行树搜索查找；
   3. 取出表t2中满足条件的行，跟R组成一行，作为结果集的一部分；
   4. 重复执行步骤1到3，直到表t1的末尾循环结束。

2. 而对于每一行R，根据a字段去表t2查找，走的是树搜索过程。

Block Nested-Loop Join

1. mysql使用了一个叫join buffer的缓冲区去减少循环次数，这个缓冲区默认是256KB，可以通过命令show variables like 'join_%'查看
2. 其具体的做法是，将第一表中符合条件的列一次性查询到缓冲区中，然后遍历一次第二个表，并逐一和缓冲区的所有值比较，将比较结果加入结果集中
3. 只有当JOIN类型为ALL，index，rang或者是index_merge的时候才会使用join buffer，可以通过explain查看SQL的查询类型。

Join优化

1. 为了优化join算法采用Index nested-loop join算法，在连接字段上建立索引字段
2. 使用数据量小的表去驱动数据量大的表
3. 增大join buffer size的大小（一次缓存的数据越多，那么外层表循环的次数就越少）
4. 注意连接字段的隐式转换与字符编码，避免索引失效

为什么很多公司都开始使用Go语言了？

写在前面

最近和几个小伙伴们在写字节跳动第五届青训营后端组的大作业。

接近尾期了，是时候做一些总结了，那从什么地方开始呢？那就从我们为什么要选择Go语言开始吧~

• 🌐项目地址
• 📝项目文档

越来越多的互联网大厂开始使用Go语言了，譬如腾讯、美团、滴滴、百度、Google、bilibili...

还有最初使用Python的字节跳动，甚至已经全面拥向Go了。这么多国内外首屈一指的公司，都在开始使用它了，它到底有什么优势呢？这就得谈谈它的一些优势了。

ps：当然了，还有Go-To-Byte的成员，想要学习go语言，并且用它完成青训营的大项目呐~

Go的一些优势

说起优势，在某些方面多半是因为它有一些别人没有的特性，或者优化了别人麻烦的地方，相比起来，才会更胜一筹。那我们来了解一下Go的一些特点吧，但在了解生硬的特点之前，我们先来看看其它几种常见的语言：

常见的一些语言

这里不是对比哟，不是说谁好谁坏，而是小马过河，因人而异~

1、C/C++

C语言是在1971年的时候，被大神Ken Thompson和Dennis Ritchie发明的，而Go语言的主导开发者之一就是Ken Thompson，所以在很多地方和C语言类似，（比如struct、Printf、&取值符）

C/C++也作为很多初学初学的语言，它们都是直接编译为机器码，所以执行效率会更高，并且都不需要执行环境，用户的使用成本会更低，不像很多语言还需要安装所需的环境。

也因为这些原因，它们的一次编码或编译只适用于一种平台，对于不同操作系统而言，有时需要修改编码再编译，有时直接重新编译即可。

而且对于开发者也"很不友好"😒，需要自己处理垃圾回收（GC）的问题。编码时，还需要考虑，堆上的内存什么时候free、delete？代码会不会造成内存泄露、不安全？

2、Java

自己作为一个从Java来学习Go的菜鸟，还未正式开发，就感到开发效率会比Java低了（个人感觉，不喜勿喷）~😁

Java是直接编译成字节码（.class），这种编译产物是介于原始编码和机器码的一种中间码。这样的话，Java程序就需要特定的执行环境（JVM）了，执行效率相比会低一些，还可能有虚拟化损失。但是这样也有一个好处就是可以编译一次，多处执行（跨平台）。而且它也是自带GC的。

3、JavaScript

和Python一样，JS是一种解释型语言，它们不需要编译，解释后即可运行。所以Js也是需要特定的执行环境（浏览器引擎） 的。

将其代码放入浏览器后，浏览器需要解析代码，所以也会有虚拟化损失。Js只需要浏览器即可运行，所以它也是跨平台的。

再谈Go

看完了前面几种常见语言的简单介绍。C/C++性能很高，因为它直接编译为二进制，且没有虚拟化损失，Go觉得还不错；Java的自动垃圾回收机制很好，Go觉得也不错；Js的一次编码可以适用可以适用多种平台，Go觉得好极了；而且Go天然具备高并发的能力，是所有语言无可比及的。那我们来简单总结一下吧！

1. 自带运行环境Runtime，且无须处理GC问题

Go程序的运行环境可厉害了，其实大部分语言都有Runtime的概念，比如Java，它程序的运行环境是JVM，需要单独安装。对于Java程序，如果不经过特殊处理，只能运行在有JMV环境的机器上。

而Go程序是自带运行环境的，Go程序的Runtime会作为程序的一部分打包进二进制产物，和用户程序一起运行，也就是说Runtime也是一系列.go代码和汇编代码等，用户可以“直接”调用Runtime的函数（比如make([]int, 2, 6)，这样的语法，其实就是去调用Runtime中的makeslice函数）。对于Go程序，简单来说就是不需要安装额外的运行环境，即可运行。除非你需要开发Go的程序。

正因为这样，Go程序也无须处理GC的问题，全权交由Runtime处理（反正要打包到一起）。

2. 快速编译，且跨平台

不同于C/C++，对于多个平台，可能需要修改代码后再编译。也不同于Java的一次编码，编译成中间码运行在多个平台的虚拟机上。Go只需要一次编码，就能轻松在多个平台编译成机器码运行。

值得一提的就是它这跨平台的能力也是Runtime赋予的，因为Runtime有一定屏蔽系统调用的能力。

3. 天然支持高性能高并发，且语法简单、学习曲线平缓

C++处理并发的能力也不弱，但由于C++的编码要求很高，如果不是很老练、专业的C++程序员，可能会出很多故障。而Go可能经验不是那么丰厚，也能写出性能很好的高并发程序。

值得一提的就是它这超强的高并发，也是Runtime赋予的去处理协程调度能力。

4. 丰富的标准库、完善的工具链

对于开发者而言，安装好Golang的环境后，就能用官方的标准库开发很多功能了。比如下图所示的很多常用包：

而且Go自身就具有丰富的工具链，（比如：代码格式化、单元测试、基准测试、包管理...）

5. 。。。。。。

很多大厂开始使用Go语言、我们团队为什么使用GoLang，和这些特性，多少都有一些关系吧~

自动化测试有以下几个概念：

1. 单元测试
2. 集成测试
3. E2E 测试
4. 快照测试
5. 测试覆盖率
6. TDD 以及 BDD 等

简述

项目开发过程中会有几个经历。

1. 版本发布上线之前，会有好几个小时甚至是更长时间对应用进行测试，这个过程非常枯燥而痛苦
2. 代码的复杂度达到了一定的级别，当维护者的数量不止一个人，你应该会逐渐察觉到你在开发新功能或修复 bug 的时候，会变得越发小心翼翼，即使代码看起来没什么问题，但你心里还是会犯嘀咕：会不会引起其他的bug。
3. 对项目中的代码进行重构的时候，会花费大量的时间进行回归测试

这些问题都是由于大多数使用最基本的手动测试的方式所带来的问题，解决它可以引入自动化测试方式。

我们日常的开发中，代码的完工其实并不等于开发的完工。如果没有测试，不能保证代码能够正常运行。

如何进行应用程序测试？

• 手动测试：通过测试人员与应用程序的交互来检查其是否正常工作。
• 自动化测试：编写应用程序来替代人工检验。

手动测试

开发者都懂得手动测试代码。在编写完源代码之后，下一步理所当然就是去手动测试它。

手动测试的优势在于足够简单灵活，但是缺点也很明显：

• 手动不适合大型项目
• 忘记测试某项功能
• 大部分时间都在做回归测试

虽然有一部分手动测试时间是花在测试新特性上，但是大部分时间还是用来检查之前的特性是否仍正常工作。这种测试被称为回归测试。回归测试对人来说是非常困难的任务————它们是重复性的，要求投入很多注意力，而且没有创造性的输入。总之，这种测试太枯燥了。幸运的是，计算机特别擅长此类工作，这也是自动化测试可以大展身手的地方！

自动化测试

自动化测试是利用计算机程序检查软件是否运行正常的测试方法。换句话说，就是用其他额外的代码检查被测软件的代码。当测试代码编写完之后，就可以不费吹灰之力地进行无数次重复测试。

可使用多种不同的方法来编写自动化测试脚本：

• 可以编写通过浏览器自动执行的程序
• 可以直接调用源代码里的函数
• 也可以直接对比程序渲染之后的截图

每一种方法的优势各不相同，但它们有一大共同点：相比手动测试而言节省了大量时间以及提高了程序的稳定性。

自动化测试还有很多优点，比如：

• 尽早的发现程序的 bug 和不足
• 增强程序员对程序健壮性、稳定性的信心
• 改进设计
• 快速反馈，减少调试时间
• 促进重构

当然，自动化测试不可能保证一个程序是完全正确的，而且事实上，在实际开发过程中，编写自动化测试代码通常是开发者不太喜欢的一个环节。大多数情况下，前端开发者在开发完一项功能后，只是打开浏览器手动点击，查看效果是否正确，之后就很少对该块代码进行管理。造成这种情况的原因主要有两个：

• 一个是业务繁忙，没有时间进行测试的编写
• 另一个是该如何编写测试

测试类型

前端开发最常见的测试主要是以下几种：

• 单元测试：验证独立的单元是否正常工作
• 集成测试：验证多个单元协同工作
• 端到端测试：从用户角度以机器的方式在真实浏览器环境验证应用交互
• 快照测试：验证程序的 UI 变化

单元测试

单元测试是对应用程序最小的部分（单元）运行测试的过程。通常，测试的单元是函数，但在前端应用中，组件也是被测单元。

单元测试可以单独调用源代码中的函数并断言其行为是否正确。

// sum.js

function sum(a, b) {

  return a + b;

}

module.exports = sum;

// sum.test.js

const sum = require('./sum');



test('adds 1 + 2 to equal 3', () => {

  expect(sum(1, 2)).toBe(3);

});

PASS  ./sum.test.js

✓ adds 1 + 2 to equal 3 (5ms)

与端到端测试不同，单元测试运行速度很快，只需要几秒钟的运行时间，因此可以在每次代码变更后都运行单元测试，从而快速得到变更是否破坏现有功能的反馈。

单元测试应该避免依赖性问题，比如不存取数据库、不访问网络等等，而是使用工具虚拟出运行环境。这种虚拟使得测试成本最小化，不用花大力气搭建各种测试环境。

单元测试的优点：

• 提升代码质量，减少 bug
• 快速反馈，减少调试时间
• 让代码维护更容易
• 有助于代码的模块化设计
• 代码覆盖率高

单元测试的缺点：

• 由于单元测试是独立的，所以无法保证多个单元运行到一起是否正确

常见的 JavaScript 单元测试框架：

• Jest
• Mocha
• Jasmine
• Karma
• ava
• Tape

Mocha 跟 Jest 是用的较多的两个单元测试框架，基本上前端单元测试就在这两个库之间选了。总的来说就是 Jest 功能齐全，配置方便，Mocha 灵活自由，自由配置。

推荐使用Jest。

集成测试

定义集成测试的方式并不相同，尤其是对于前端。有些人认为在浏览器环境上运行的测试是集成测试；有些人认为对具有模块依赖性的单元进行的任何测试都是集成测试；也有些人认为任何完全渲染的组件测试都是集成测试。

优点：

• 由于是从用户使用角度出发，更容易获得软件使用过程中的正确性
• 集成测试相对于写了软件的说明文档
• 由于不关注底层代码实现细节，所以更有利于快速重构
• 相比单元测试，集成测试的开发速度要更快一些

缺点：

• 测试失败的时候无法快速定位问题
• 代码覆盖率较低
• 速度比单元测试要慢

端到端测试（E2E）

E2E（end to end）端到端测试是最直观可以理解的测试类型。在前端应用程序中，端到端测试可以从用户的视角通过浏览器自动检查应用程序是否正常工作。

想象一下，你正在编写一个计算器应用程序，并且你想测试两个数求和的运算方法是否正确。你可以编写一个端到端测试，打开浏览器，加载计算器应用程序，单击“1”按钮，单击加号“+”按钮，再次单击“1”按钮，单击等号“=”，最后检查屏幕是否显示正确结果“2”。

编写完一个端到端测试后，可以根据自己的需求随时运行它。想象一下，相比执行数百次同样的手动测试，这样一套测试代码可以节省多少时间！

优点：

• 真实的测试环境，更容易获得程序的信心

缺点：

• 首先，端到端测试运行不够快。启动浏览器需要占用几秒钟，网站响应速度又慢。通常一套端到端测试需要 30 分钟的运行时间。如果应用程序完全依赖于端到端测试，那么测试套件将需要数小时的运行时间。
• 端到端测试的另一个问题是调试起来比较困难。要调试端到端测试，需要打开浏览器并逐步完成用户操作以重现 bug。本地运行这个调试过程就已经够糟糕了，如果测试是在持续集成服务器上失败而不是本地计算机上失败，那么整个调试过程会变得更加糟糕。

一些流行的端到端测试框架：

• Cypress
• Nightwatch
• WebdriverIO
• playwright

快照测试

快照测试类似于“找不同”游戏。快照测试会给运行中的应用程序拍一张图片，并将其与以前保存的图片进行比较。如果图像不同，则测试失败。这种测试方法对确保应用程序代码变更后是否仍然可以正确渲染很有帮助。

传统快照测试是在浏览器中启动应用程序并获取渲染页面的屏幕截图。它们将新拍摄的屏幕截图与已保存的屏幕截图进行比较，如果存在差异则显示错误。这种快照测试在操作系统或浏览器存在版本间差异时，即使快照并没有改变，也会遇到测试失败问题。

使用 Jest 测试框架编写快照测试。取代传统对比屏幕截图的方式，Jest 快照测试可以对 JavaScript 中任何可序列化值进行对比。可以使用它们来比较前端组件的 DOM 输出。

应用场景：

• 开发纯函数库，建议写更多的单元测试 + 少量的集成测试
• 开发组件库，建议写更多的单元测试、为每个组件编写快照测试、写少量的集成测试 + 端到端测试
• 开发业务系统，建议写更多的集成测试、为工具类库、算法写单元测试、写少量的端到端测试

测试覆盖率

测试覆盖率是衡量软件测试完整性的一个重要指标。掌握测试覆盖率数据，有利于客观认识软件质量，正确了解测试状态，有效改进测试工作

度量测试覆盖率：

• 代码覆盖率
• 需求覆盖率

代码覆盖率

一种面向软件开发和实现的定义。它关注的是在执行测试用例时，有哪些软件代码被执行到了，有哪些软件代码没有被执行到。被执行的代码数量与代码总数量之间的比值，就是代码覆盖率。

根据代码粒度的不同，代码覆盖率可以进一步分为四个测量维度。它们形式各异，但本质是相同的。

• 行覆盖率（line coverage）：是否每一行都执行了？
• 函数覆盖率（function coverage）：是否每个函数都调用了？
• 分支覆盖率（branch coverage）：是否每个if代码块都执行了？
• 语句覆盖率（statement coverage）：是否每个语句都执行了？

如何度量代码覆盖率呢？一般可以通过第三方工具完成，比如 Jest 自带了测试覆盖率统计。

这些度量工具有个特点，那就是它们一般只适用于白盒测试，尤其是单元测试。对于黑盒测试(例如功能测试/系统测试)来说，度量它们的代码覆盖率则相对困难多了。

需求覆盖率

对于黑盒测试，例如功能测试/集成测试/系统测试等来说，测试用例通常是基于软件需求而不是软件实现所设计的。因此，度量这类测试完整性的手段一般是需求覆盖率，即测试所覆盖的需求数量与总需求数量的比值。视需求粒度的不同，需求覆盖率的具体表现也有不同。例如，系统测试针对的是比较粗的需求，而功能测试针对的是比较细的需求。当然，它们的本质是一致的。

如何度量需求覆盖率呢？通常没有现成的工具可以使用，而需要依赖人工计算，尤其是需要依赖人工去标记每个测试用例和需求之间的映射关系。

对于代码覆盖率来说，广为诟病的一点就是 100% 的代码覆盖率并不能说明代码就被完全覆盖没有遗漏了。因为代码的执行顺序和函数的参数值，都可能是千变万化的。一种情况被覆盖到，不代表所有情况被覆盖到。

对于需求覆盖率来说，100% 的覆盖率也不能说“万事大吉”。因为需求可能有遗漏或存在缺陷，测试用例与需求之间的映射关系，尤其是用例是否真正能够覆盖对应的测试需求，也可能是存在疑问的。

总结

适用于不同的场景，有各自的优势与不足。需要注意的是，它们不是互相排斥，而是相互补充的。

关于测试覆盖率，最重要的一点应该是迈出第一步，即有意识地去收集这种数据。没有覆盖率数据，测试工作会有点像在“黑灯瞎火”中走路。有了覆盖率数据，并持续监测，利用和改进这个数据，才是一条让测试工作越来越好的光明大道。

是不是所有代码都要有测试用例支持呢？

测试覆盖率还是要和测试成本结合起来，比如一个不会经常变的公共方法就尽可能的将测试覆盖率做到趋于 100%。而对于一个完整项目，前期先做最短的时间覆盖 80% 的测试用例，后期再慢慢完善。

经常做更改的活动页面我认为没必要必须趋近 100%，因为要不断的更改测试永用例，维护成本太高。

大多数情况下，将 100% 代码覆盖率作为目标并没有意义。

实现 100% 代码覆盖率不仅耗时，而且即使代码覆盖率达到 100%，测试也并非总能发现 bug。有时你可能还会做出错误的假设，当你调用一个 API 代码时，假定的是该 API 永远不会返回错误，然而当 API确实在生产环境中返回错误时，应用就崩溃了。

前言##

之前看到一篇介绍 IntelliJ IDEA 配置的文章，它里面用的是 gif 动态图片进行展示，我觉得很不错。所以在我今天以及以后的博文中，我也会尽量使用 gif 动图进行展示。制作 gif 动图很花时间，为了把我的博客打造成精品我也是蛮拼的了。使用动图的优点是演示效果好，缺点是动图体积过大，为了降低图片体积，我只能降低分辨率了。

关于高效使用命令行这个话题，在网上已经是老生常谈了。而且本文也借鉴了 CSDN 极客头条中推荐了的《像黑客一样使用 Linux 命令行》。但是在本文中，也有不少我自己的观点和体会，比如我会提到有些快捷键要熟记，有些则完全不需要记，毕竟我们的记忆力也是有限的，我还会提到一些助记的方法。所以，本文绝对不是照本宣科，值得大家拥有，请大家一定记得点赞。

使用 tmux 复用控制台窗口##

高效使用命令行的首要原则就是要尽量避免非命令行的干扰，什么意思呢？就是说一但开启了一个控制台窗口，就尽量不要再在桌面上切换来切换去了，不要一会儿被别的窗口挡住控制台，一会儿又让别的窗口破坏了控制台的背景，最好是把控制台最大化或全屏，最好连鼠标都不要用。只有这样，才能达到比较高的效率。但是在实际工作中，我们又经常需要同时在多个控制台中进行工作，例如：在一个控制台中运行录制屏幕的命令，在另外一个控制台中工作，或者在一个控制台中工作，在另外一个控制台中阅读文档。如果既想在多个控制台中工作，又不想一大堆窗口挡来挡去、换来换去的话，就可以考虑试试 tmux 了。如下图：

tmux 的功能很多，什么 Session 啊、Detach 啊、Atach 啊什么的我们暂时不用去关心，只用好它的控制台窗口复用功能就行了。tmux 中有 window 和 pane 的概念，tmux 可以创建多个 window，这些 window 是不会互相遮挡的，每次只显示一个 window，其它的 window 会自动隐藏，可以使用快捷键在 window 之间切换。同时，可以把一个 window 切分成多个 pane，这些 pane 同时显示在屏幕上，可以使用快捷键在 pane 之间切换。

tmux 的快捷键很多，要想全面了解 tmux 的最好办法当然是阅读 tmux 的文档了，使用命令 man tmux 就可以了。但是我们只需要记住少数几个重要的快捷键就可以了，如下表：

tmux 的快捷键比较特殊，除了调整 pane 大小的快捷键之外，其它的都是先按 Ctrl+B，再按一个字符。先按 Ctrl+B，再按 c，就会创建一个 window，这里 c 就是 create window。先按 Ctrl+B，再按 n 或者 p，就可以在窗口之间切换，它们是 next window 和 previous window 的意思。关闭窗口是先按 Ctrl+B，再按 &，这个只能死记。先按 Ctrl+B，再按 " ，表示上下拆分窗口，可以想象成单引号和双引号在键盘上是上下铺关系。先按 Ctrl+B，再按 % 表示左右拆分窗口，大概是因为百分数都是左右书写的吧。至于在 pane 之间移动和调整 pane 大小的方向键，就不用多说了吧。

在命令行中快速移动光标##

在命令行中输入命令时，经常要在命令行中移动光标。这个很简单嘛，使用左右方向键就可以了，但是有时候我们输入了很长一串命令，却突然要修改这个命令最开头的内容，如果使用向左的方向键一个字符一个字符地把光标移到命令的开头，是否太慢了呢？有时我们需要直接在命令的开头和结尾之间切换，有时又需要能够一个单词一个单词地移动光标，在命令行中，其实这都不是事儿。如下图：

这几种移动方式都是有快捷键的。其实一个字符一个字符地移动光标也有快捷键 Ctrl+B 和 Ctrl+F，但是这两个快捷键我们不需要记，有什么能比左右方向键更方便的呢？我们真正要记的是下面这几个：

这几个快捷键太好记了，A 代表 ahead，E 代表 end，B 代表 back,F 代表 forward。为什么按单词移动光标的快捷键都是以 Alt 开头呢？那是因为按字符移动光标的快捷键把 Ctrl 占用了。但是按字符移动光标的快捷键我们用不到啊，因为我们有左右方向键啊。

在命令行中快速删除文本##

对输入的内容进行修改也是我们经常要干的事情，对命令行进行修改就涉及到先删除一部分内容，再输入新内容。我们碰到的情况是有时候只需要修改个别字符，有时候需要修改个别单词，而有时候，输入了半天的很长的一段命令，我们说不要就全都不要了，整行删除。常用的删除键当然是 BackSpace 和 Delete 啦，不过一次删除一个字符，是否太慢了呢？那么，请熟记以下几个快捷键吧：

效果请看下图：

这几个快捷键也是蛮好记的，U 代表 undo，K 代表 kill，W 代表 word，D 代表 delete， Y 代表 yank。其中比较奇怪的是 Alt+D 又是以 Alt 开头的，那是因为 Ctrl+D 又被占用了。Ctrl+D 有几个意思，在编辑命令行的时候它代表删除一个字符，当然，这个快捷键其实我们用不到，因为 BackSpace 和 Delete 方便多了。在某些程序从 stdin 读取数据的时候，Ctrl+D 代表 EOF，这个我们偶尔会用到。

快速查看和搜索历史命令##

对于曾经运行过的命令，除非特别短，我们一般不会重复输入，从历史记录中找出来用自然要快得多。我们用得最多的就是 ↑ 和 ↓，特别是不久前才刚刚输入过的命令，使用 ↑ 向上翻几行就找到了，按一下 Enter 就执行，多舒服。但是有时候，明明记得是不久前才用过的命令，但是向上翻了半天也没找到，怎么办？那只好使用 history 命令来查看所有的历史记录了。历史记录又特别长，怎么办？可以使用 history | less 和 history | grep '...'。但是还有终极大杀招，那就是按 Ctrl+R 从历史记录中进行搜索。按了 Ctrl+R 之后，每输入一个字符，都会和历史记录中进行增量匹配，输入得越多，匹配越精确。当然，有时候含有相同搜索字符串的命令特别多，怎么办？继续按 Ctrl+R，就会继续搜索下一条匹配的历史记录。如下图：

这里，需要记住的命令和快捷键如下表：

这里需要注意的是，当我们在历史记录中搜索的时候，是有位置标记的，Ctrl+R 是指从当前位置开始，逆向搜索，R 代表的是 reverse，每搜索一条记录，位置标记都会向历史记录的头部移动，下次搜索又从这里开始继续向头部搜索。所以，我们一定要记住快捷键 Alt+>，它可以把历史记录的位置标记还原。另外需要注意的是停止搜索历史记录的快捷键有三个，如果按 Enter 键，匹配的命令就立即执行了，如果你还想有修改这条命令的机会的话，一定不要按 Enter，而要按 Esc。如果什么都不想要，就按 Ctrl+G 吧，它会还你一个空白的命令行。

快速引用和修饰历史命令##

除了查看和搜索历史记录，我们还可以以更灵活的方式引用历史记录中的命令。常见的简单的例子有 !! 代表引用上一条命令，!$代表引用上一条命令的最后一个参数，^oldstring^newstring^代表将上一条命令中的 oldstring 替换成 newstring。这些操作是我们平时使用命令行的时候的一些常用技巧，其实它们的本质，是由 history 库提供的 history expansion 功能。Bash 使用了 history 库，所以也能使用这些功能。其完整的文档可以查看 man history 手册页。知道了 history expansion 的理论，我们还可以做一些更加复杂的操作，如下图：

引用和修饰历史命令的完整格式是这样的：

![!|[?]string|[-]number]:[n|x-y|^|$|*|n*|%]:[h|t|r|e|p|s|g]

可以看到，一个对历史命令的引用被 : 分为了三个部分，第一个部分决定了引用哪一条历史命令；第二部分决定了选取该历史命令中的第几个单词，单词是从0开始编号的，也就是说第0个单词代表命令本身，第1个到最后一个单词代表命令的参数；第三部分决定了对选取的单词如何修饰。下面我列出完整表格：

表格一、引用哪一条历史命令：

表格二、选取哪一个单词：

表格三、对选取的单词做什么修饰：

这几个命令其实挺好记的，h 代表 head，只要路径开头不要文件名，t 代表 tail，只要路径结尾的文件名，r 代表 realname，只要文件名不要扩展名，e 代表 extension，只要扩展名不要文件名，s 代表 substitute，执行替换功能，g 代表 global，全局替换，p 代表 print，只打印不执行。有时候光使用 :p 还不够，我们还可以把这个经过引用修饰后的命令直接在当前命令行上展开而不立即执行，它的快捷键是：

这两个快捷键，记住一个就行。这样，当我们对历史命令的引用修饰完成后，可以先展开来看一看，如果正确再执行。眼见为实嘛，反正我是每次都展开看看才放心。

录制屏幕并转换为 gif 动画图片##

最后，给大家展示我做 gif 动画图片的过程。我用到的软件有 recordmydesktop、mplayer 和 convert。使用 recordmydesktop 时需要一个单独的控制台来运行录像功能，录像完成后需要在该控制台中输入 Ctrl+C 终止录像。所以我用到了 tmux 。首先，我启动 tmux，然后运行 recordmydesktop --full-shots --fps 2 --no-sound --no-frame --delay 5 -o ~/图片/record_to_gif.ogv命令开始录像。由于 recordmydesktop 运行后不会马上退出，录像开始后，这个 window 就被占用了，所以我按 Ctrl+B c 让 tmux 再创建一个 window，然后在这个 window 中做的任何操作都会被录制下来。被录制的操作完成后，按 Ctrl+B n 切换到 recordmydesktop 命令运行的窗口，按 Ctrl+C 终止录像。然后，使用 mplayer -ao null record_to_gif.ogv -vo jpeg:outdir=./record_to_gif 将录制的视频提取为图片。当然，这时的图片比较多，为了缩减最后制作成的 gif 文件的大小，我们可以删掉其中无关紧要的帧，只留下关键帧。最后使用命令 convert -delay 100 record_to_gif/* record_to_gif.gif 生成 gif 动画。整个过程如下图：

最后生成的 gif 图片一般都比较大，往往超过 20M，如果时间长一点，超过 60M 也是常事儿。而制作成 gif 之前每一帧图片也就 200k 左右而已。我想可能是因为 gif 没有像 jpeg 或 png 这么好的压缩算法吧。gif 对付向量图效果很不错，对付照片和我这样的截图，压缩就有点力不从心了。博客园允许上传的图片每张不能超过 10M，所以，为了减小 gif 文件的体积，我只有用 convert -resize 1024x576 record_to_gif.gif record_to_gif_small.gif 命令将图片变小后再上传了。

总结##

使用 Linux 命令行的技巧还有很多，我这里不可能全部讲到。学习 Linux 命令行的最好办法当然还是使用 man bash 查看 Bash 的文档。但是我这里讲的内容已经可以显著提高使用命令行的效率了，至少这两天下来，我觉得我自己有了质的飞跃。另外，在博客中使用 gif 动态图片做示例，我觉得也是我写博客以来一个质的飞跃。希望大家喜欢。

得益于 Flutter 优秀的跨平台表现，混合开发在如今的 App 中随处可见，如最近微信公布的小程序新渲染引擎 Skyline 发布正式版也在底层渲染上使用了 Flutter，号称渲染速度提升50%。

在现有的原生 App 中引入 Flutter 来开发不是一件简单的事，需要解决混合模式下带来的种种问题，如路由栈管理、包体积和内存突增等；另外还有一种特殊的情况，一个最初就由 Flutter 来开发的 App 也有可能在后期混入、原生 View 去开发。

我所在的团队目前就是处于这种情况，Flutter 目前在性能表现上面还不够完美，整体页面还不够流畅，并且在一些复杂的页面场景下会出现比较严重的发热行为，尽管目前 Flutter 团队发布了新的渲染引擎 impeller，它在 iOS 上表现优异，流畅度有了质的提升，但还是无法完全解决一些性能问题且 Android 下 impeller 也还没开发完成。

为了应对当下出现的困局和以后可能出现的未知问题，我们期望通过混合模式来扩宽更多的可能性。

路由管理

混合开发下最难处理的就是路由问题了，我们知道原生和 Flutter 都有各自的路由管理系统，在原生页面和 Flutter 页面穿插的情况下如何统一管理和互相交互是一大难点。目前比较流行的单引擎方案，代表框架是闲鱼团队出品flutter_boost；flutter 官方代表的多引擎解决方案 FlutterEngineGroup。

单引擎方案 flutter_boost

flutter_boost 通过复用 Engine 达到最小内存的目的

在引擎处理上，flutter_boost 定义了一个通用的 CacheId："flutter_boost_default_engine"，当原生需要跳转到 Flutter 页面时，通过FlutterEngineCache.getInstance().get(ENGINE_ID); 获取同一个 Engine，这样无论打开了多少如图中的 A、B、C 的 Flutter 页面时，都不会产生额外的Engine内存损耗。

public class FlutterBoost {

    public static final String ENGINE_ID = "flutter_boost_default_engine";

    ...

}

另外，双端都注册了导航的接口，通过Channel来通知，用于请求路由变化、页面返回以及页面的生命周期处理等。在这种模式下，这一层Channel的接口处理是重点。

多引擎方案 FlutterEngineGroup

为了应对内存爆炸问题，官方对多引擎场景做了优化，FlutterEngineGroup应运而生，FlutterEngineGroup下的 Engine 共用一些通用的资源，例如GPU 上下文、线程快照等，生成额外的 Engine 时，号称内存占用缩小到 180k。这个程度，基本可以视为正常的损耗了。

以上图中的 B、C 页面为例，两者都是 Flutter 页面，在 FlutterEngineGroup 这种处理下，因为它们所在的 Engine 不是同一个，这会产生完全的隔离行为，也就是 B、C 页面使用不同的堆栈，处在不同的 Isolate 中，两者是无法直接进行交互的。

多引擎的优点是：它可以抹掉上图所示的 F、E、C 和 D、A 等内部路由，每次新增 Flutter 页面时，全部回调到原生，让原生生成新的 Engine 去承载页面，这样路由的管理全部由原生去处理，一个 Engine 只对应一个 Flutter 页面。

但它也会带来一些额外的处理，像上面提到的，处在不同 Engine 下的Flutter 页面之间是无法直接交互的，如果涉及到需要通知和交互的场景，还得通过原生去转发。

关于FlutterEngineGroup的更多信息，可以参考官方说明。

性能对比

官方号称 FlutterEngineGroup 创建新的 Engine 只会占用 180k 的内存，那么是不是真就如它所说呢？下面我们来针对上面这两种方案做一个内存占用测试

flutter_boost

测试机型：OPPO CPH2269

测试代码：github.com/alibaba/flu…

内存 dump 命令： adb shell dumpsys meminfo com.idlefish.flutterboost.example

第一次加载 Flutter 页面时，增加 27M 左右内存，此后多开一个页面内存增加呈现从 1M -> 2M -> 2.6 M 这种越来越陡的趋势（数值只是参考，因为其中有 Native 页面，只看趋势变化上看）

FlutterEngineGroup

测试机型：OPPO CPH2269

测试代码：github.com/flutter/sam…

内存 dump 命令： adb shell dumpsys meminfo dev.flutter.multipleflutters

第一次加载 Flutter 页面时，增加 31M 左右内存，此后多开一个页面内存增加呈现从 1M -> 1.2M -> 1.6 M 这种越来越陡的趋势（数值只是参考，因为其中有 Native 页面，只看趋势变化上看）

结论

两个测试使用的是不同的 demo 代码，不能通过数值去得出孰优孰劣。但通过数值的表现，我们基本可以确认，两个方案都不会带来异常的内存暴涨，完全在可以接受的范围。

PlatformView

PlatformView 也可实现混合 UI，Flutter 中的 WebView 就是通过 PlatformView 这种方式引入的。

PlatformView 允许我们向 Flutter 界面中插入原生 View，在一个页面的最外层包裹一层 PlatformView，路由的管理都由 Flutter 来处理。这种方式下没有额外的 Engine 产生，是最简单的混合方式。

但它也有缺点，不适合主 Native 混 Flutter 的场景，而现在大多都是以主 Native 混 Flutter的场景为主。另外，PlatformView 因其底层实现，会出现兼容性问题，在一些机型下可能会出现键盘问题、闪烁或其它的性能开销，具体可看这篇介绍

数据共享

原生和 Flutter 使用不同的开发语言去开发，所以在一侧定义的数据结构对象和内存对象对方都无法感知，在数据同步和处理上必须使用其它手段。

MethodChannel

Flutter 开发者对 MethodChannel 一定不陌生，开发当中免不了跟原生交互，MethodChannel 是双向设计，即允许我们在 Flutter 中调用原生的方法，也允许我们在原生中调用 Flutter 的方法。对 Channel 不太了解的可以看一下官方文档，如文档中提到的，这个通道传输的过程中需要将数据编解码，对应的关系以kotlin为例(完整的映射可以查看文档)：

Dart                         | Kotlin      |

| -------------------------- | ----------- |

| null                       | null        |

| bool                       | Boolean     |

| int                        | Int         |

| int, if 32 bits not enough | Long        |

| double                     | Double      |

| String                     | String      |

| Uint8List                  | ByteArray   |

| Int32List                  | IntArray    |

| Int64List                  | LongArray   |

| Float32List                | FloatArray  |

| Float64List                | DoubleArray |

| List                       | List        |

| Map                        | HashMap     |

本地存储

这种方式比较容易理解，将本地存储视为中转站，Flutter中将数据操作存储到本地上，回到原生页面时在某个时机（如onResume）去查询本地数据库即可，反之亦然。

问题

不管是MethodChannel或是本地存储，都会面临一个问题：对象的数据结构是独立的，两边需要重复定义。比如我在 Flutter 中有一个 Student 对象，Android 端也要定义一个同样结构的 Student，这样才能方便操作，现在我将Student student转成Unit8List传到Android，Channel中解码成Kotlin能操作的ByteArray，再将ByteArray转译成Android中Student对象。

class Student {

  String name;

  int age;

  Student(this.name, this.age);

}

对于这个问题最好的解决办法是使用DSL一类的框架，如Google的ProtoBuf，将同一份对象配置文件编译到不同的语言环境中，便能省去这部分双端重复定义的行为。

图片缓存

在内存方面，如果同样的图片在两边都加载时，会使得原生和 Flutter 都会产生一次缓存。在 Flutter 下默认就会缓存在ImageCache中，原生下不同的框架由不同的对象负责，为了去掉重复的图片缓存，势必要统一图片的加载管理。

阿里的方案也是如此，通过外接原生图片库，共享图片的本地文作缓存和内存缓存。它的实现思路是通过自定义ImageProvider和Codec，对接外部图库，获取到图片数据做解析，对接的处理是通过扩展 Flutter Engine。

如果期望不修改Flutter Engine，也可通过外接纹理的方式去处理。通过PlatformChannel去请求原生，使到图片的外接纹理数据，通过TextTure组件展示图片。

// 自定义 ImageProvider 中，通过 Channel 去请求 textureId

var id = await _channel.invokeMethod('newTexture', {

  "imageUrl": imageUrl,

  "width": width ?? 0,

  "height": height ?? 0,

  "minWidth": constraints.minWidth,

  "minHeight": constraints.minHeight,

  "maxWidth": constraints.maxWidth,

  "maxHeight": constraints.maxHeight,

  "cacheKey": cacheKey,

  "fit": fit.index,

  "cacheOriginFile": cacheOriginFile,

});



// ImageWidget 中展示时通过 textureId 去显示图片

SizedBox(

  width: width,

  heigt: height,

  child: Texture(

    filterQuality: FilterQuality.high,

    textureId: _imageProvider.textureId.value,

  ),

)

总结

不同业务对于混合的程度和要求有所要求，并没有万能的方案。比如我团队的情况就是主Flutter混原生，在路由管理上我选择了PlatformView这种处理模式，这种方式更容易开发和维护，后期如果发现有兼容性问题，也可过渡到flutter_boost和FlutterEngineGroup上。

对于Android开发者来说，Glide是最常使用的库。这里介绍了开发过程中，7个使用Glide的技巧。

不要使用wrap_content

不清楚你是否这样使用过，把 ImageView 的宽和高设置成 wrap_content，并通过Glide来加载图片

<ImageView

    android:id="@+id/image"

    android:layout_width="wrap_content"

    android:layout_height="wrap_content"/>



Glide.with(context)

    .load(url)

    .into(image)        

为什么不建议把ImageView设置成 wrap_content，我们看一下Glide的文档是怎么说的（文档地址中文地址 最新英文地址）：

文档上写得很明显，在某些情况下会使用屏幕的尺寸代替 wrap_content，这可能导致原来的小图片变成大图，Glide transform 问题分析这篇文章就介绍了这种问题。为了避免这种情况发生，我们最好是不要使用 wrap_content。当然如果你实在是需要使用 wrap_content，你可以按照Glide的建议，使用Target.SIZE_ORIGINAL。

需要注意的是：使用Target.SIZE_ORIGINAL 在加载大图时可能造成oom，因此你需要确保加载的图片不会太大。

自定义内存缓存大小

在某些情况下，我们可能需要自定义Glide的内存缓存大小和Bitmap池的大小，比如图片显示占大头的app，就希望Glide的图片缓存大一些。Glide内部使用MemorySizeCalculator类来决定内存缓存和Bitmap池的大小。

@GlideModule

class MyGlideModel: AppGlideModule() {



    override fun applyOptions(context: Context, builder: GlideBuilder) {

        super.applyOptions(context, builder)

        //通过MemorySizeCalculator获取MemoryCache和BitmapPool的size大小

        val calculator = MemorySizeCalculator.Builder(context).build()

        val defaultMemoryCacheSize = calculator.memoryCacheSize

        val defaultBitmapPoolSize = calculator.bitmapPoolSize



        //根据业务计算出需要的缓存大小，这里简化处理，都乘以1.5

        val customMemoryCacheSize = (1.5 * defaultMemoryCacheSize).toLong()

        val customBitmapPoolSize = (1.5 * defaultBitmapPoolSize).toLong()

        //设置缓存

        builder.setMemoryCache(LruResourceCache(customMemoryCacheSize))

        builder.setBitmapPool(LruBitmapPool(customBitmapPoolSize))

    }

}

memoryCache 和 BitmapPool 的区别：

• memoryCache：通过key-value才缓存数据，缓存之前用过的Bitmap
• BitmapPool：重用Bitmap对象的对象池，根据Bitmap的宽高来复用。复用的原理可以看Bitmap全解析

具体区别见What is difference between MemoryCacheSize and BitmapPoolSize in Glide

自定义磁盘缓存

Glide 使用 DiskLruCacheWrapper 作为默认的 磁盘缓存 。 DiskLruCacheWrapper 是一个使用 LRU 算法的固定大小的磁盘缓存。默认磁盘大小为 250 MB ，位置是在应用的 缓存文件夹 中的一个 特定目录 。我们也可以自定义磁盘缓存，代码如下：

@GlideModule



class MyGlideModel: AppGlideModule() {



    override fun applyOptions(context: Context, builder: GlideBuilder) {

        super.applyOptions(context, builder)

        val size: Long = 1024 * 1024 * 100 //100MB

        builder.setDiskCache(InternalCacheDiskCacheFactory(context, cacheFolderName, size))

    }

}

牢记在onLoadCleared释放图片资源

如上图Glide的官方文档所示，我们在使用Target时，必须在重新绘制（通常是View）或改变其可见性之前，你必须确保在onResourceReady中收到的任何当前Drawable不再被使用。这是因为Glide内部缓存在内存不足或者主动回收Glide.get(context).clearMemory()时，会回收Bitmap，如果此时ImageView还使用被回收的Bitmap，就会发生 trying to use a recycled bitmap 的错误。

解决办法是不再使用在onResourceReady中获取的Bitmap，代码如下：

        Glide.with(this)

            .load(Url)

            .into(object : CustomTarget<Bitmap>(width, height) {

                override fun onResourceReady(

                    resource: Bitmap,

                    transition: Transition<in Bitmap>?,

                ) {

                    mBitmap = resource

                }



                override fun onLoadCleared(placeholder:Drawable?){

                    mBitmap = null

                }

            })

优先加载指定图片

如上图所示，当一个页面有多个图片时，我们希望某些图片优先被加载出来（这个界面里面是上面的一拳超人的封面），某些图片后加载，比如这个界面里的互动点评的用户头像列表。Glide提供了优先级来解决这个问题，它的优先级如下：

• Priority.LOW
• Priority.NORMAL
• Priority.HIGH
• Priority.IMMEDIATE

使用代码如下：

    Glide

        .with(context)

        .load("url")

        .priority(Priority.LOW)//底优先级的图片

        .into(imageView);

        

    Glide

        .with(context)

        .load("url")

        .priority(Priority.HIGH)//高优先级的图片

        .into(imageView);

注意：优先级高的加载任务会尽量首先启动，但是无法保证加载开始或完成的顺序。

使用Glide前，先判断页面是否回收

一般我们会通过网络请求来获取图片的链接，再通过Glide来加载图片，代码如下：

service?.fetchUserProfile(id) { result, errMsg, icon ->

    if (result == 200) {

        Glide.with(context)

            .load(icon)

            .into(view)

    }

}

但是这里有个问题，当界面被destory后，这个网络请求刚好成功了，调用Glide.with就会发生 You cannot start a load for a destroyed activity错误。解决方法是在调用Glide.with前先判断，代码如下：

service?.fetchUserProfile(id) { result, errMsg, icon ->

    if (result == 200) {

       if (context is FragmentActivity) {

            if ((context as FragmentActivity).isFinishing || (context as FragmentActivity).isDestroyed) {

                return

            }

        }

        Glide.with(context)

            .load(icon)

            .into(view)

    }

}

加载大图时使用skipMemoryCache

当我们使用Glide加载大图时，应该避免使用内存缓存，如果不好好处理可能发生oom。在Glide中，我们可以使用skipMemoryCache来跳过内存缓存。代码如下：

    Glide.with(context)

        .load(url)

        .skipMemoryCache(true)

        .into(imageview)

与skipMemoryCache对应的是 onlyRetrieveFromCache，它只从缓存中获取对象，不会从网络或者本地缓存中就直接加载失败。

问题描述

做需求开发时，遇到RecyclerView刷新时，通常会使用notifyItemXXX方法去做局部刷新。但是刷新后，有时会遇到RecyclerView定位到我们不希望的位置，这时候就会很头疼。这周有时间深入了解了下RecyclerView的源码，大致梳理清楚刷新后位置跳动的原因了。

原因分析

先简单描述下RecyclerView在notify后的过程：

1. 根据是否是全量刷新来选择触发RecyclerView.RecyclerViewDataObserver的onChanged方法或onItemRangeXXX方法

onChanged会直接调用requestlayout来重新layuout。 onItemRangeXXX会先把刷新数据保存到mAdapterHelper中，然后再调用requestlayout 2. 进入dispatchLayout流程 这一步分为三个步骤：

• dispatchLayoutStep1：处理adapter的更新、决定哪些view执行动画、保存view的信息
• dispatchLayoutStep2：真正执行childView的layout操作
• dispatchLayoutStep3：触发动画、保存状态、清理信息

需要注意的是，在onMeasure的过程中，如果传入的measureMode不是exactly，会去调用dispatchLayoutStep1和dispatchLayoutStep2从而取得真正需要的宽高。 所以在dispatchLayout会先判断是否需要重新执行dispatchLayoutStep1和dispatchLayoutStep2

重点分析dispatchLayoutStep2这一步： 核心操作在 mLayout.onLayoutChildren(mRecycler, mState)这一行。以LinearLayoutManager为例继续往下挖：

public void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) {

    ...

    final View focused = getFocusedChild();

    if (!mAnchorInfo.mValid || mPendingScrollPosition != RecyclerView.NO_POSITION

                || mPendingSavedState != null) {

            mAnchorInfo.reset();

            mAnchorInfo.mLayoutFromEnd = mShouldReverseLayout ^ mStackFromEnd;

            // 关键步骤1，寻找锚点View位置

            updateAnchorInfoForLayout(recycler, state, mAnchorInfo);

            mAnchorInfo.mValid = true;

        } else if (focused != null && (mOrientationHelper.getDecoratedStart(focused)

                >= mOrientationHelper.getEndAfterPadding()

                || mOrientationHelper.getDecoratedEnd(focused)

                <= mOrientationHelper.getStartAfterPadding())) {

            mAnchorInfo.assignFromViewAndKeepVisibleRect(focused, getPosition(focused));

        }

        ...

            // fill towards end

            updateLayoutStateToFillEnd(mAnchorInfo);

            mLayoutState.mExtraFillSpace = extraForEnd;

            //关键步骤2，从锚点View位置往后填充

            fill(recycler, mLayoutState, state, false);

            endOffset = mLayoutState.mOffset;

            final int lastElement = mLayoutState.mCurrentPosition;

            if (mLayoutState.mAvailable > 0) {

            //如果锚点位置后面数据不足，无法填满剩余的空间，那把剩余空间加到顶部

                extraForStart += mLayoutState.mAvailable;

            }

            // fill towards start

            updateLayoutStateToFillStart(mAnchorInfo);

            mLayoutState.mExtraFillSpace = extraForStart;

            mLayoutState.mCurrentPosition += mLayoutState.mItemDirection;

            //关键步骤3，从锚点View位置向前填充

            fill(recycler, mLayoutState, state, false);

            startOffset = mLayoutState.mOffset;



            if (mLayoutState.mAvailable > 0) {

            //如果锚点View位置前面数据不足，那把剩余空间加到尾部再做一次尝试

                extraForEnd = mLayoutState.mAvailable;

                // start could not consume all it should. add more items towards end

                updateLayoutStateToFillEnd(lastElement, endOffset);

                mLayoutState.mExtraFillSpace = extraForEnd;

                fill(recycler, mLayoutState, state, false);

                endOffset = mLayoutState.mOffset;

            }

}

先解释一下锚点View，锚点View在一次layout过程中的位置不会发生变化，即之前在哪里显示，这次layout完还在哪，从视觉上看没有位移。

总结一下，mLayout.onLayoutChildren主要做了以下几件事：

1. 调用updateAnchorInfoForLayout方法确定锚点view位置
2. 从锚点view后面的位置开始填充，直到后面空间被填满或者已经遍历到最后一个itemView
3. 从锚点view前面的位置开始填充，直到空间被填满或者遍历到indexe为0的itemView
4. 经过第三步后仍有剩余空间，则把剩余空间加到尾部再做一次尝试

所以回到一开始的问题，RecyclerView在notify之后位置跳跃的关键在于锚点View的确定，也就是updateAnchorInfoForLayout方法，所以下面重点看下这个方法：

private void updateAnchorInfoForLayout(RecyclerView.Recycler recycler, RecyclerView.State state,

        AnchorInfo anchorInfo) {

    if (updateAnchorFromPendingData(state, anchorInfo)) {

        if (DEBUG) {

            Log.d(TAG, "updated anchor info from pending information");

        }

        return;

    }



    if (updateAnchorFromChildren(recycler, state, anchorInfo)) {

        if (DEBUG) {

            Log.d(TAG, "updated anchor info from existing children");

        }

        return;

    }

    if (DEBUG) {

        Log.d(TAG, "deciding anchor info for fresh state");

    }

    anchorInfo.assignCoordinateFromPadding();

    anchorInfo.mPosition = mStackFromEnd ? state.getItemCount() - 1 : 0;

}

这个方法比较短，所以代码全贴出来了。如果是调用了scrollToPosition后的刷新，会通过updateAnchorFromPendingData方法确定锚点View位置，否则调用updateAnchorFromChildren来计算：

private boolean updateAnchorFromChildren(RecyclerView.Recycler recycler,

        RecyclerView.State state, AnchorInfo anchorInfo) {

    if (getChildCount() == 0) {

        return false;

    }

    final View focused = getFocusedChild();

    if (focused != null && anchorInfo.isViewValidAsAnchor(focused, state)) {

        anchorInfo.assignFromViewAndKeepVisibleRect(focused, getPosition(focused));

        return true;

    }

    if (mLastStackFromEnd != mStackFromEnd) {

        return false;

    }

    View referenceChild =

            findReferenceChild(

                    recycler,

                    state,

                    anchorInfo.mLayoutFromEnd,

                    mStackFromEnd);

    if (referenceChild != null) {

        anchorInfo.assignFromView(referenceChild, getPosition(referenceChild));

        ...

        return true;

    }

    return false;

}

代码比较简单，如果有焦点View，并且焦点View没被remove，则使用焦点View作为锚点。否则调用findReferenceChild来查找：

View findReferenceChild(RecyclerView.Recycler recycler, RecyclerView.State state,

        boolean layoutFromEnd, boolean traverseChildrenInReverseOrder) {

    ensureLayoutState();



    // Determine which direction through the view children we are going iterate.

    int start = 0;

    int end = getChildCount();

    int diff = 1;

    if (traverseChildrenInReverseOrder) {

        start = getChildCount() - 1;

        end = -1;

        diff = -1;

    }



    int itemCount = state.getItemCount();



    final int boundsStart = mOrientationHelper.getStartAfterPadding();

    final int boundsEnd = mOrientationHelper.getEndAfterPadding();



    View invalidMatch = null;

    View bestFirstFind = null;

    View bestSecondFind = null;



    for (int i = start; i != end; i += diff) {

        final View view = getChildAt(i);

        final int position = getPosition(view);

        final int childStart = mOrientationHelper.getDecoratedStart(view);

        final int childEnd = mOrientationHelper.getDecoratedEnd(view);

        if (position >= 0 && position < itemCount) {

            if (((RecyclerView.LayoutParams) view.getLayoutParams()).isItemRemoved()) {

                if (invalidMatch == null) {

                    invalidMatch = view; // removed item, least preferred

                }

            } else {

                // b/148869110: usually if childStart >= boundsEnd the child is out of

                // bounds, except if the child is 0 pixels!

                boolean outOfBoundsBefore = childEnd <= boundsStart && childStart < boundsStart;

                boolean outOfBoundsAfter = childStart >= boundsEnd && childEnd > boundsEnd;

                if (outOfBoundsBefore || outOfBoundsAfter) {

                    // The item is out of bounds.

                    // We want to find the items closest to the in bounds items and because we

                    // are always going through the items linearly, the 2 items we want are the

                    // last out of bounds item on the side we start searching on, and the first

                    // out of bounds item on the side we are ending on.  The side that we are

                    // ending on ultimately takes priority because we want items later in the

                    // layout to move forward if no in bounds anchors are found.

                    if (layoutFromEnd) {

                        if (outOfBoundsAfter) {

                            bestFirstFind = view;

                        } else if (bestSecondFind == null) {

                            bestSecondFind = view;

                        }

                    } else {

                        if (outOfBoundsBefore) {

                            bestFirstFind = view;

                        } else if (bestSecondFind == null) {

                            bestSecondFind = view;

                        }

                    }

                } else {

                    // We found an in bounds item, greedily return it.

                    return view;

                }

            }

        }

    }

    // We didn't find an in bounds item so we will settle for an item in this order:

    // 1. bestSecondFind

    // 2. bestFirstFind

    // 3. invalidMatch

    return bestSecondFind != null ? bestSecondFind :

            (bestFirstFind != null ? bestFirstFind : invalidMatch);

}

解释一下，查找过程会遍历RecyclerView当前可见的所有childView，找到第一个没被notifyRemove的childView就停止查找，否则会把遍历过程中找到的第一个被notifyRemove的childView作为锚点View返回。

这里需要注意final int position = getPosition(view);这一行代码，getPosition返回的是经过校正的最终position，如果ViewHolder被notifyRemove了，这里的position会是0，所以如果可见的childView都被remove了，那最终定位的锚点View是第一个childView，锚点的position是0，偏移量offset是这个被删除的childView的top值，这就会导致后面fill操作时从位置0开始填充，先把position=0的view填充到偏移量offset的位置，再往后依次填满剩余空间，这也是导致画面上的跳动的根本原因。

这是我一个朋友在美团面试中遇到的一个问题，今天拿出来解析一下

正文

如何开启一个线程

如何开启一个线程，再JDK中的说明为：

/**

 * ...

 * There are two ways to create a new thread of execution. One is to

 * declare a class to be a subclass of <code>Thread</code>. 

 * The other way to create a thread is to declare a class that

 * implements the <code>Runnable</code> interface.

 * ....

 */

public class Thread implements Runnable{

      

}

Thread源码的类描述中有这样一段，翻译一下，只有两种方法去创建一个执行线程，一种是声明一个Thread的子类，另一种是创建一个类去实现Runnable接口。

继承Thread类

public class ThreadUnitTest {



    @Test

    public void testThread() {

        //创建MyThread实例

        MyThread myThread = new MyThread();

        //调用线程start的方法，进入可执行状态

        myThread.start();

    }



    //继承Thread类，重写内部run方法

    static class MyThread extends Thread {



        @Override

        public void run() {

            System.out.println("test MyThread run");

        }

    }

}

实现Runnable接口

public class ThreadUnitTest {



    @Test

    public void testRunnable() {

        //创建MyRunnable实例，这其实只是一个任务，并不是线程

        MyRunnable myRunnable = new MyRunnable();

        //交给线程去执行

        new Thread(myRunnable).start();

    }



    //实现Runnable接口，并实现内部run方法

    static class MyRunnable implements Runnable {



        @Override

        public void run() {

            System.out.println("test MyRunnable run");

        }

    }

}

实现Callable

其实实现Callback接口创建线程的方式，归根到底就是Runnable方式，只不过它是在Runnable的基础上又增加了一些能力，例如取消任务执行等。

public class ThreadUnitTest {



    @Test

    public void testCallable() {

        //创建MyCallable实例，需要与FutureTask结合使用

        MyCallable myCallable = new MyCallable();

        //创建FutureTask，与Runnable一样，也只能算是个任务

        FutureTask<String> futureTask = new FutureTask<>(myCallable);

        //交给线程去执行

        new Thread(futureTask).start();



        try {

            //get方法获取任务返回值，该方法是阻塞的

            String result = futureTask.get();

            System.out.println(result);

        } catch (ExecutionException e) {

            e.printStackTrace();

        } catch (InterruptedException e) {

            e.printStackTrace();

        }

    }



    //实现Callable接口，并实现call方法，不同之处是该方法有返回值

    static class MyCallable implements Callable<String> {



        @Override

        public String call() throws Exception {

            Thread.sleep(10000);

            return "test MyCallable run";

        }

    }

}

Callable的方式必须与FutureTask结合使用，我们看看FutureTask的继承关系:

//FutureTask实现了RunnableFuture接口

public class FutureTask<V> implements RunnableFuture<V> {



}



//RunnableFuture接口继承Runnable和Future接口

public interface RunnableFuture<V> extends Runnable, Future<V> {

    void run();

}

开启大量线程会引起什么问题

在Java中，调用Thread的start方法后，该线程即置为就绪状态，等待CPU的调度。这个流程里有两个关注点需要去理解。

start内部怎样开启线程的？看看start方法是怎么实现的。

// Thread类的start方法

public synchronized void start() {

        // 一系列状态检查

        if (threadStatus != 0)

            throw new IllegalThreadStateException();

   

        group.add(this);

           

        boolean started = false;

        try {

             //调用start0方法，真正启动java线程的地方

            start0();

            started = true;

        } finally {

            try {

                if (!started) {

                 group.threadStartFailed(this);

                }

            } catch (Throwable ignore) {

            }

        }

    }

   

//start0方法是一个native方法

private native void start0();

JVM中，native方法与java方法存在一个映射关系，Java中的start0对应c层的JVM_StartThread方法，我们继续看一下:

JVM_ENTRY(void, JVM_StartThread(JNIEnv* env, jobject jthread))

  JVMWrapper("JVM_StartThread");

  JavaThread *native_thread = NULL;

  bool throw_illegal_thread_state = false;

  {

   

    MutexLocker mu(Threads_lock);

    // 判断Java线程是否已经启动，如果已经启动过，则会抛异常。

    if (java_lang_Thread::thread(JNIHandles::resolve_non_null(jthread)) != NULL) {

      throw_illegal_thread_state = true;

    } else {

      //如果没有启动过，走到这里else分支，去创建线程

      //分配c++线程结构并创建native线程

      jlong size =

             java_lang_Thread::stackSize(JNIHandles::resolve_non_null(jthread));

   

      size_t sz = size > 0 ? (size_t) size : 0;

      //注意这里new JavaThread

      native_thread = new JavaThread(&thread_entry, sz);

      if (native_thread->osthread() != NULL) {

        native_thread->prepare(jthread);

      }

    }

  }

  ......

  Thread::start(native_thread);

走到这里发现，Java层已经过渡到native层，但远远还没结束:

JavaThread::JavaThread(ThreadFunction entry_point, size_t stack_sz) :

                          Thread()

   {

     initialize();

     _jni_attach_state = _not_attaching_via_jni;

     set_entry_point(entry_point);

     os::ThreadType thr_type = os::java_thread;

     thr_type = entry_point == &compiler_thread_entry ? os::compiler_thread :

                                                        os::java_thread;

     //根据平台，调用create_thread，创建真正的内核线程                       

     os::create_thread(this, thr_type, stack_sz);

   }

   

   bool os::create_thread(Thread* thread, ThreadType thr_type,

                          size_t req_stack_size) {

       ......

       pthread_t tid;

       //利用pthread_create（）来创建线程

       int ret = pthread_create(&tid, &attr, (void* (*)(void*)) thread_native_entry, thread);

       ......

       return true;

}

pthread_create方法，第三个参数表示启动这个线程后要执行的方法的入口，第四个参数表示要给这个方法传入的参数:

static void *thread_native_entry(Thread *thread) {

  ......

  //thread_native_entry方法的最下面的run方法，这个thread就是上面传递下来的参数，也就是JavaThread

  thread->run();

  ......

  return 0;

}

终于开始执行run方法了:

//thread.cpp类

void JavaThread::run() {

  ......

  //调用内部thread_main_inner  

  thread_main_inner();

}

   

void JavaThread::thread_main_inner() {

  if (!this->has_pending_exception() &&

   !java_lang_Thread::is_stillborn(this->threadObj())) {

    {

      ResourceMark rm(this);

      this->set_native_thread_name(this->get_thread_name());

    }

    HandleMark hm(this);

    //注意：内部通过JavaCalls模块，调用了Java线程要执行的run方法

    this->entry_point()(this, this);

  }

  DTRACE_THREAD_PROBE(stop, this);

  this->exit(false);

  delete this;

}

一条U字型代码调用链至此结束：

• Java中调用Thread的star方法，通过JNI方式，调用到native层。
• native层，JVM通过pthread_create方法创建一个系统内核线程，并指定内核线程的初始运行地址，即一个方法指针。
• 在内核线程的初始运行方法中，利用JavaCalls模块，回调到java线程的run方法，开始java级别的线程执行。

线程如何调度

计算机的世界里，CPU会分为若干时间片，通过各种算法分配时间片来执行任务，有耳熟能详时间片轮转调度算法、短进程优先算法、优先级算法等。当一个任务的时间片用完，就会切换到另一个任务。在切换之前会保存上一个任务的状态，当下次再切换到该任务，就会加载这个状态， 这就是所谓的线程的上下文切换。很明显，上下文的切换是有开销的，包括很多方面，操作系统保存和恢复上下文的开销、线程调度器调度线程的开销和高速缓存重新加载的开销等。

经过上面两个理论基础的回顾，开启大量线程引起的问题，总结起来，就两个字——开销。

消耗时间：线程的创建和销毁都需要时间，当数量太大的时候，会影响效率。 消耗内存：创建更多的线程会消耗更多的内存，这是毋庸置疑的。线程频繁创建与销毁，还有可能引起内存抖动，频繁触发GC，最直接的表现就是卡顿。长而久之，内存资源占用过多或者内存碎片过多，系统甚至会出现OOM。 消耗CPU。在操作系统中，CPU都是遵循时间片轮转机制进行处理任务，线程数过多，必然会引起CPU频繁的进行线程上下文切换。这个代价是昂贵的，某些场景下甚至超过任务本身的消耗。

如何优化

线程的本质是为了执行任务，在计算机的世界里，任务分大致分为两类，CPU密集型任务和IO密集型任务。

CPU密集型任务，比如公式计算、资源解码等。这类任务要进行大量的计算，全都依赖CPU的运算能力，持久消耗CPU资源。所以针对这类任务，其实不应该开启大量线程。因为线程越多，花在线程切换的时间就越多，CPU执行效率就越低，一般CPU密集型任务同时进行的数量等于CPU的核心数，最多再加个1。 IO密集型任务，比如网络读写、文件读写等。这类任务不需要消耗太多的CPU资源，绝大部分时间是在IO操作上。所以针对这类任务，可以开启大量线程去提高CPU的执行效率，一般IO密集型任务同时进行的数量等于CPU的核心数的两倍。 另外，在无法避免，必须要开启大量线程的情况下，我们也可以使用线程池代替直接创建线程的做法进行优化。线程池的基本作用就是复用已有的线程，从而减少线程的创建，降低开销。在Java中，线程池的使用还是非常方便的，JDK中提供了现成的ThreadPoolExecutor类，我们只需要按照自己的需求进行相应的参数配置即可，这里提供一个示例。

/**

 * 线程池使用

 */

public class ThreadPoolService {



    /**

     * 线程池变量

     */

    private ThreadPoolExecutor mThreadPoolExecutor;



    private static volatile ThreadPoolService sInstance = null;



    /**

     * 线程池中的核心线程数，默认情况下，核心线程一直存活在线程池中，即便他们在线程池中处于闲置状态。

     * 除非我们将ThreadPoolExecutor的allowCoreThreadTimeOut属性设为true的时候，这时候处于闲置的核心         * 线程在等待新任务到来时会有超时策略，这个超时时间由keepAliveTime来指定。一旦超过所设置的超时时间，闲     * 置的核心线程就会被终止。

     * CPU密集型任务  N+1   IO密集型任务   2*N

     */

    private final int CORE_POOL_SIZE = Runtime.getRuntime().availableProcessors() + 1;

    /**

     * 线程池中所容纳的最大线程数，如果活动的线程达到这个数值以后，后续的新任务将会被阻塞。包含核心线程数+非*      * 核心线程数。

     */

    private final int MAXIMUM_POOL_SIZE = Math.max(CORE_POOL_SIZE, 10);

    /**

     * 非核心线程闲置时的超时时长，对于非核心线程，闲置时间超过这个时间，非核心线程就会被回收。

     * 只有对ThreadPoolExecutor的allowCoreThreadTimeOut属性设为true的时候，这个超时时间才会对核心线       * 程产生效果。

     */

    private final long KEEP_ALIVE_TIME = 2;

    /**

     * 用于指定keepAliveTime参数的时间单位。

     */

    private final TimeUnit UNIT = TimeUnit.SECONDS;

    /**

     * 线程池中保存等待执行的任务的阻塞队列

     * ArrayBlockingQueue  基于数组实现的有界的阻塞队列

     * LinkedBlockingQueue  基于链表实现的阻塞队列

     * SynchronousQueue   内部没有任何容量的阻塞队列。在它内部没有任何的缓存空间

     * PriorityBlockingQueue   具有优先级的无限阻塞队列。

     */

    private final BlockingQueue<Runnable> WORK_QUEUE = new LinkedBlockingDeque<>();

    /**

     * 线程工厂，为线程池提供新线程的创建。ThreadFactory是一个接口，里面只有一个newThread方法。 默认为DefaultThreadFactory类。

     */

    private final ThreadFactory THREAD_FACTORY = Executors.defaultThreadFactory();

    /**

     * 拒绝策略，当任务队列已满并且线程池中的活动线程已经达到所限定的最大值或者是无法成功执行任务，这时候       * ThreadPoolExecutor会调用RejectedExecutionHandler中的rejectedExecution方法。

     * CallerRunsPolicy  只用调用者所在线程来运行任务。

     * AbortPolicy  直接抛出RejectedExecutionException异常。

     * DiscardPolicy  丢弃掉该任务，不进行处理。

     * DiscardOldestPolicy   丢弃队列里最近的一个任务，并执行当前任务。

     */

    private final RejectedExecutionHandler REJECTED_HANDLER = new ThreadPoolExecutor.AbortPolicy();



    private ThreadPoolService() {

    }



    /**

     * 单例

     * @return

     */

    public static ThreadPoolService getInstance() {

        if (sInstance == null) {

            synchronized (ThreadPoolService.class) {

                if (sInstance == null) {

                    sInstance = new ThreadPoolService();

                    sInstance.initThreadPool();

                }

            }

        }

        return sInstance;

    }



    /**

     * 初始化线程池

     */

    private void initThreadPool() {

        try {

            mThreadPoolExecutor = new ThreadPoolExecutor(

                    CORE_POOL_SIZE,

                    MAXIMUM_POOL_SIZE,

                    KEEP_ALIVE_TIME,

                    UNIT,

                    WORK_QUEUE,

                    THREAD_FACTORY,

                    REJECTED_HANDLER);

        } catch (Exception e) {

            LogUtil.printStackTrace(e);

        }

    }



    /**

     * 向线程池提交任务,无返回值

     *

     * @param runnable

     */

    public void post(Runnable runnable) {

        mThreadPoolExecutor.execute(runnable);

    }



    /**

     * 向线程池提交任务,有返回值

     *

     * @param callable

     */

    public <T> Future<T> post(Callable<T> callable) {

        RunnableFuture<T> task = new FutureTask<T>(callable);

        mThreadPoolExecutor.execute(task);

        return task;

    }

}

在Android中，Handler是一个使用的非常频繁的东西，输入事件机制和系统状态，都通过Handler来进行流转，而在Handler中，有一个很少被人提起但是却很有用的东西，那就是IdleHandler，它的源码如下。

/**

 * Callback interface for discovering when a thread is going to block

 * waiting for more messages.

 */

public static interface IdleHandler {

    /**

     * Called when the message queue has run out of messages and will now

     * wait for more.  Return true to keep your idle handler active, false

     * to have it removed.  This may be called if there are still messages

     * pending in the queue, but they are all scheduled to be dispatched

     * after the current time.

     */

    boolean queueIdle();

}

从注释我们就能发现，这是一个IdleHandler的静态接口，可以在消息队列没有消息时或是队列中的消息还没有到执行时间时才会执行的一个回调。

这个功能在某些重要但不紧急的场景下就非常有用了，比如我们要在主页上做一些处理，但是又不想影响原有的初始化逻辑，避免卡顿，那么我们就需要等系统闲下来的时候再来执行我们的操作，这个时候，我们就可以通过IdleHandler来进行回调。

它的使用也非常简单，代码示例如下。

Looper.myQueue().addIdleHandler {

    // Do something

    false

}

在Handler的消息循环中，一旦队列里面没有需要处理的消息，该接口就会回调，也就是Handler空闲的时候。

这个接口有返回值，代表是否需要持续执行，如果返回true，那么一旦Handler空闲，就会执行IdleHandler中的回调，而如果返回false，那么就只会执行一次。

当返回true时，可以通过removeIdleHandler的方式来移除循环的处理，如果是false，那么在处理完后，它自己会移除。

综上，IdleHandler的使用主要有下面这些场景。

• 低优先级的任务处理：替换之前为了不在初始化的时候影响性能而使用的Handler.postDelayed方法，通过IdleHandler来自动获取空闲的时机。
• Idle时循环处理任务：通过控制返回值，在系统空闲时，不断重复某个操作。

但是要注意的是，如果Handler过于繁忙，那么IdleHandler的执行时机是有可能被延迟很久的，所以，要注意一些比较重要的处理逻辑的处理时机。

在很多第三方库里面，都有IdleHandler的使用，例如LeakCanary，它对内存的dump分析过程，就是在IdleHandler中处理的，从而避免对主线程的影响。

介绍 Handler

Handler 是一个常见的组件，它在 Android 应用程序开发中被广泛使用。Handler 可以将消息传递给主线程，使开发者能够在子线程中进行长时间的耗时操作，同时也避免了因在主线程中更新 UI 而出现的卡顿和 ANR 问题。

Handler 的问题

尽管 Handler 能够帮助处理一些繁琐的任务，然而如果不进行优化，Handler 自身却可能成为你应用程序的问题所在。

以下列出一些常见的 Handler 问题：

内存泄漏

因为 Handler 实例通常会保留对主线程的引用，而主线程通常不会被销毁，所以你在应用程序中使用 Handler时，很有可能会遇到内存泄漏的问题。

ANR

在处理大量消息时，使用 Handler 造成运行过程变慢。此时，当主线程无法在规定时间内完成属于它的操作时，就会发生一种无法响应的情况 ANR。

线程安全问题

如果你没有很好地处理并发问题，Handler 在多个线程中对同一实例的使用，可能会引发线程的安全问题。

优化方法

为了避免以上问题，可以尝试以下优化方法：

使用静态内部类

一个优化处理内存泄漏的方法是将 Handler 实例声明为静态内部类。这样，Handler 将不会保留对外部类的引用，从而避免了内存泄漏。

public class MyActivity extends Activity {



    private static class MyHandler extends Handler {

        private final WeakReference<MyActivity> mActivity;



        public MyHandler(MyActivity activity) {

            mActivity = new WeakReference<MyActivity>(activity);

        }



        @Override

        public void handleMessage(Message msg) {

            MyActivity activity = mActivity.get();

            if (activity != null) {

                // do something

            }

        }

    }



    private final MyHandler mHandler = new MyHandler(this);

}

移除Handler的回调

为了避免Handler泄露，可以再在Activity或Fragment的生命周期方法中移除Handler的回调。

@Override

protected void onDestroy() {

    super.onDestroy();

    handler.removeCallbacksAndMessages(null);

}

使用子线程与消息延迟

为避免 Handler 运行缓慢和 ANR 的问题， 可以将耗时任务放在子线程中执行，并在需要更新UI时使用Handler进行线程间通信。 如果消息队列中的消息太多，可以让主线程先处理其他任务，再延迟消息的处理时间。

Handler handler = new Handler(Looper.getMainLooper()) {

    @Override

    public void handleMessage(Message msg) {

        // 在主线程更新UI

    }

};



// 在子线程中执行耗时任务

new Thread(new Runnable() {

    @Override

    public void run() {

        // 执行耗时操作



        handler.sendMessage(handler.obtainMessage());

    }

}).start();

private static final int MAX_HANDLED_MESSAGE_COUNT = 500;



private Handler mHandler = new Handler() {

    private int mHandledMessageCount = 0;



    @Override

    public void handleMessage(Message msg) {

        // do something



        mHandledMessageCount++;

        if (mHandledMessageCount > MAX_HANDLED_MESSAGE_COUNT) {

            mHandler.postDelayed(new Runnable() {

                @Override

                public void run() {

                    mHandledMessageCount = 0;

                }

            }, 1000);

        }

    }

};

使用 HandlerThread

为了避免出现线程安全问题，可以使用 HandlerThread 来创建线程从而处理消息。这样做的好处是不必担心多个线程同时访问同一个 Handler 实例的问题。

public class MyHandlerThread extends HandlerThread {

    private static final String TAG = "MyHandlerThread";



    private Handler mHandler;



    public MyHandlerThread() {

        super(TAG);

    }



    @Override

    protected void onLooperPrepared() {

        mHandler = new Handler(getLooper()) {

            @Override

            public void handleMessage(Message msg) {

                // do something

            }

        };

    }



    public Handler getHandler() {

        return mHandler;

    }

}

使用 SparseArray

如果你的应用程序中有多个 Handler，可以使用 SparseArray 来管理它们。SparseArray 是一个类似于 HashMap的数据结构，它可以非常高效地管理多个 Handler 实例。

private SparseArray<Handler> mHandlerArray = new SparseArray<>();



private void initHandlers() {

    mHandlerArray.put(1, new Handler() {

        @Override

        public void handleMessage(Message msg) {

            // do something

        }

    });



    mHandlerArray.put(2, new Handler() {

        @Override

        public void handleMessage(Message msg) {

            // do something

        }

    });



    // add more handlers

}



private void handleMessages(int handlerId, Message msg) {

    Handler handler = mHandlerArray.get(handlerId);

    if (handler != null) {

        handler.handleMessage(msg);

    }

}

使用 MessageQueue.IdleHandler

如果你的应用程序中有长时间运行的任务，可以使用 MessageQueue.IdleHandler 来执行它们。MessageQueue.IdleHandler 是一个回调接口，它可以在没有消息时执行任务。

private void executeLongRunningTask() {

    Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {

        @Override

        public boolean queueIdle() {

            // do something

            return false; // remove the idle handler

        }

    });

}

结论

Handler 作为 Android 应用程序中非常重要的一个组件，但如果不进行优化，将可能影响应用程序的性能和稳定性。通过这篇文章，我们可以有效地避免问题的出现，让应用程序更加高效稳定。

推荐

android_startup: 提供一种在应用启动时能够更加简单、高效的方式来初始化组件，优化启动速度。不仅支持Jetpack App Startup的全部功能，还提供额外的同步与异步等待、线程控制与多进程支持等功能。

AwesomeGithub: 基于Github的客户端，纯练习项目，支持组件化开发，支持账户密码与认证登陆。使用Kotlin语言进行开发，项目架构是基于JetPack&DataBinding的MVVM；项目中使用了Arouter、Retrofit、Coroutine、Glide、Dagger与Hilt等流行开源技术。

flutter_github: 基于Flutter的跨平台版本Github客户端，与AwesomeGithub相对应。

android-api-analysis: 结合详细的Demo来全面解析Android相关的知识点, 帮助读者能够更快的掌握与理解所阐述的要点。

daily_algorithm: 每日一算法，由浅入深，欢迎加入一起共勉。

都2023年了，新建的项目还是Java项目，或者你还在写Java样式的Kotlin项目，仔细看完这篇文章，带你从Java转到Kotlin，带你学会Koltin，从入坑到脱坑

为什么要学习Kotlin

1. Kotlin是Andorid官方推荐语言
2. 最年来Google发布很多新玩意，都是Kotlin写的，对Kotlin支持比较友好
3. Compose你不会Kotlin怎么学习
4. 一些大型开源项目，比如Okhttp，Retrofit，Glide都改成了Kotlin版本
5. 使用协程，让你切换线程更加方便，摆脱回调地狱
6. 让你的代码更简洁

综上所示，笔者认为，Kotlin如今是一名Android开发工程师所必须要掌握的技能，但是偏偏还是有很多人不用，不学，所以就写下来这篇文章，带你快速入门Kotlin，也算是对自己知识的一遍巩固

基础

何为Kotlin,笔者认为是如何快速定义变量，常量，new一个对象，调用一个方法，来看一下Java是怎么做的

int a = 10;

a = 11;

TextView textView = new TextView(context);

textView.setText(a);

嗯，还是比较简洁的，但是还可以更简洁，看一下相同的代码使用Kotlin如何完成

fun Test(context: Context?) {

    var a = 10

    a = 11

    val textView = TextView(context)

    textView.text = a.toString()

}

解释一下，Kotlin定义常量是val，变量为,var,什么类型，根本不需要，它会通过后面得内容自动推导出来是什么类型的，但是从本质来说，Kotlin是还是强类型语言，只不过编译器会自动推导出来他真的类型而已，然后是不用写new关键字了，不用写;结尾了，get、set方法也不用写，直接等，实际上还是调用了真的get和set，原因是通过了属性访问器（accessor）的语法糖形式直接使用等号进行赋值和获取

类

接下来看一下类，点即创建一个Kotlin类型得File，会出来如下弹框

• Class 和Java的Class没什么两样，一般就是一个类
• File 如果当一个Class中有两个同级别的类，这个时候就会变为File，这个一般在写扩展函数的时候使用，扩展函数后面会讲到
• Interface 和Java的Interface一样，一个接口
• Sealed interface 封闭接口，防止不同model之间的互相调用，比如你再B Model中定义 B Sealed interface，那么你只能在B Model中使用这个接口，除此之外，还是使用此接口完成多继承的操作
• Data class 实体类，和Java实体类有什么不同呢，不用写get，set方法和普通Kotlin Class有什么不同呢，首先是必须要有有参构造方法，然后重写了hashCode和equals方法
• Enum class 枚举类，和Java一样
• Sealed class 和Sealed interface差不多，都是限制只能在一个Model中使用
• Annotation 定义一个注解
• Object 这个笔者最喜欢，常用来定义一个单例类，相当于Java的饿汉式 其中比较常用的有Class，Data class,Object总的来说还是比Java的类型多一点

返回值

为什么要单写一个返回值，因为Kotlin的所有方法都有返回值，常规的就不说，看下面代码

val a: Unit = printA()



private fun printA() {

    print("A")

}

这里面定义了函数，没有定义任何返回值，但是其实的类型是Unit，我的理解是Unit就代表它是一个函数类型和String一样都是Koltin类型中的一种，明白了这点就可以理解接下来的操作

val a = if ( x > y) x else y

相当于Java的三元换算符，如果x大于y就等于x，否则就等于y，对了Kotlin是没有三元换算符这个概念的，如果要达到相同效果只有使用if...else...，同理when也同样适用于这种操作

还是一种建立在编译器类型推导的基础上一种写法

private fun getA() = {

    val a = 0

    a

}

这个函数的意义就是返回了一个数字a，为什么没有return 它却拥有返回值返回值，请注意看这个=号，编译器给他推导出来了，并且通过lamaba返回值 还有一个非常特殊的返回值 Nothing 什么意思呢 不是null 就是什么也没有 具体可以看一下这篇文章

NULL安全处理

Kotlin是一个null安全的语言下面详细看一下

//定义一个变量

private var a: String? = null

String后面有个？代表，这个变量是可能为null的那么就需要在使用的时候处理它，不然会报错

if (a != null){

    //不为null

}else{

    //为null

}

//或者加上!!,代表这个时候肯定不为null，但是一般不建议这样写，玩出现null，就会空指针异常

a!!

当然如果确定使用的时候肯定部位null也可以这样写

private lateinit var a: String

代表定义了一个变量，我不管之前对它做了什么操作，反正我使用的时候，它一定是不为null的，当然与之的对应的还有by lazy延迟初始化，当第一次使用的时候才会初始化，比如这样，当我第一次调用a的时候，by lazy的括号内容即委托就会执行给a赋值,值得注意的是by lazy不是绑定在一起的 也可以只使用by意思也是委托，不过要单独写一个委托的实现

private val a: String by lazy { "123" }

扩展函数

扩展函数可以说是Kotlin比较爽的部分，他的本质其实是一个Kotlin的静态方法然后返回了它原本得了类型，比如这段代码

fun String?.addPlus(number: Int): String? {

    if (this == null){

        return null

    }

    return this.toInt().plus(number).toString()

}

扩展了String的方法，在String的基础上添加了一个addPlus方法，然后接受一个number参数，然后强转为int类型之后加上number并返回，这样扩展不用继承也可以在一些类中添加方法，减少了出BUG的可能性

val str = "1"

val str2 = str.addPlus(2)

看一这段代码的本质，可以知道Koltin和Java是可以互相转换的

public static final String addPlus(@Nullable String $this$addPlus, int number) {

   return $this$addPlus == null ? null : String.valueOf(Integer.parseInt($this$addPlus) + number);

}

可以看到，扩展函数的本质是一个静态方法，并且多了一个String类型的参数，这个参数其实就是扩展函数类的实体，利用扩展函数可以实现简化很多操作，比如金额计算就可以扩展String，然后接收一个String，又或者是给textView添加一个功能，同样可以使用，我认为它差不多就是简化了静态工具类的使用，让其更方便，更快捷

扩展函数二 let also run apply

还记得上面提到的Kotlin对于null的判断吗，其实拥有更快快捷的方法就是使用扩展函数看这一段代码

fun stringToInt(str: String?): Int {

    return str?.let {

        it.toIntOrNull() ?: -1

    } ?: run {

        -1

    }

}

一段链式调用，这也是Kotlin的特性之一，后续有时间会讲，链式调用有好处也有坏处，好处是可以更好的代码，坏处是一旦使用了过长的链式调用，后期代码维护就会很麻烦，为什么我会知道，因为我就写过，后期维护的时候痛不欲生，开发一时爽维护两行泪，但是适量使用这种，会让你的代码变得更简洁，维护更方便，主要还是看工程师的把握度。

好了具体看一下代码做了什么工作，首先定义了一个stringToInt的函数，然后接受了一个String参数，这个参数可以为null，然后判断是否等于null，等于null返回-1，不能转化为int返回-1，可以正常转化返回int值 Ok 先解释一下如何利用扩展函数做null判断 ?.let代表如果str这个值不为null，那么就执行it.toIntOrNull() ?: -1,否则这里用 ?:来处理即为null 就走run 然后返回-1

• let 提供了一个以默认值it的空间，然后返回值的是当前执行控件的最后一行代码
• also 提供了一个以默认值it的空间，然后返回值是它本身
• run 提供了一个this的命名空间，然后返回最后一行代码
• apply 提供了一个this的命名空间，然后返回它本身 这里贴出Kotlin的实现，源码其实很简单

@kotlin.internal.InlineOnly

public inline fun <T, R> T.let(block: (T) -> R): R {

    contract {

        callsInPlace(block, InvocationKind.EXACTLY_ONCE)

    }

    return block(this)

}



@kotlin.internal.InlineOnly

@SinceKotlin("1.1")

public inline fun <T> T.also(block: (T) -> Unit): T {

    contract {

        callsInPlace(block, InvocationKind.EXACTLY_ONCE)

    }

    block(this)

    return this

}



@kotlin.internal.InlineOnly

public inline fun <T, R> T.run(block: T.() -> R): R {

    contract {

        callsInPlace(block, InvocationKind.EXACTLY_ONCE)

    }

    return block()

}





@kotlin.internal.InlineOnly

public inline fun <T> T.apply(block: T.() -> Unit): T {

    contract {

        callsInPlace(block, InvocationKind.EXACTLY_ONCE)

    }

    block()

    return this

}

代码其实很简单，有兴趣可以自己随便玩玩，这里就以apply为例分析一下，首先返回一个泛型T，这个T就是调用者本身，然后接口了一个black的函数，这个函数就是实际在代码中apply提供的空间，然后执行完成后，然后调用者本身,这样就和上文对应上了，apply 提供了一个this的命名空间，然后返回它本身，也可以仿照实现一个自己myApply哈哈哈，

结语

这篇文章其实原本想写的非常多，还有很多关键字没有介绍，比如by,inline,受限于篇幅问题，暂时把最基础的写了一写，以后会逐步完善这个系列，在写的过程，也有一些是笔者使用起来相对来说比较少的，就比如Sealed interface这个接口，之前就完全不理解，在写的时候特意去查询了一下资料，然后自己测试了一番，才理解，也算是促进了自己学习，希望可以共同进步