概述

工作这10多年来，也经常做招聘的工作，面试过的人超过50人次了，而看过的候选人的简历则有几百份了，但是清晰且能突出重点的简历，确实很少遇到。这里基本可以说明一个问题，很多候选人是不太清楚如何写出一份好的简历的。

下面基于简历中的项目经历，重点铺开说一下。在社招中，项目经历面试官重点考察的地方。

写项目经历需要注意的地方

项目经历是介绍你实战经历的地方，同时也能反映你对已掌握的技能的使用情况。对于应聘偏技术类的岗位来说，这块非常的重要。

下面会以支付中心作为例子进行阐述。

• 项目背景，也即是你一定要非常清楚启动这个项目的缘由是啥。如果这个都说不清楚的话，那说明，你真的就是埋头干活，偏执行的角色。对项目并没有一个整体的认识。就算你只是这个项目的普通参与者，也需要主动的去了解和理解该项目立项的原因。有个注意的地方是，项目背景的文字描述不要太长，一两句就可以了。比如说：当前支付中心耦合在订单系统中，为了提升支付模块的稳定性、维护性、性能和扩展性，需要将支付模块独立出来，统一为其他内部系统提供支付能力;

• 项目功能介绍，介绍一下这个项目能做什么，有什么核心模块，需要应付什么量级的流量。以支付中心为例子：为内部的订单系统提供支付能力，对内提供了微信、支付宝、抖音、海外、信用卡、钱包、礼品卡以及组合支付的支付、回调、退款、查询、业务对账等能力。平时需要应付每秒1万的支付请求。

• 技术架构设计，这里考察的是技术选型的严谨性和模块设计的合理性。如果项目用到了RabbitMQ、Redis、Kafka等一些技术，你自己心里一定有个底，就是当时为什么选用这些技术，是经过深思熟虑的吗？是经过了很多轮的技术栈对比后决定使用的吗。也即是技术选型是一个严谨的论证的一个过程。而设计这块，则要说清楚模块划分的缘由以及解决方案。还是以支付中心为例子：通过支付网关，对外提供统一的接口，而内部则通过支付路由模块，进行具体的支付方式路由，并把单独的支付方式，以物理单元进行隔离，避免各种支付方式在出故障时，相互影响。为了应付高频的支付动作，采用数据库分库的方式缓解写的压力。

• 我负责的模块，如果你参与的项目是部门核心项目，但是自己参与的模块确是边缘模块或者只是参与了很小的一部分，虽然你也能在这个项目里，得到成长。但是那是称不上个人亮点的。因为面试官会更倾向于：你为这个项目做了什么贡献，因为你，项目有了什么好的改变和突破性进展。因此，做项目的时候，不妨跟自己的领导多反馈一下，希望能独立主导一些重要的模块。如果领导觉得当前的你还无法独立hold住重要的模块，你也不要气馁，平时多多提升自己，争取后续能主导一些重要模块。这个真的很重要，为了将来的自己，你必须得这么做。在做项目的时候，如果你长期一直起着螺丝钉的作用的话，对你极其不利，甚至可以说，你是在浪费时间。

• 难点和踩过的坑，难点也即是亮点。在你负责的模块里，具体的难点是什么，你是通过什么方案解决的。而解决的过程中，又遇到什么大坑？怎么优化的。这个其实是一种引导，把面试官引入到你自己比较熟悉又印象深刻的领域，如果你准备充分的话，是能给面试官一个好的印象的，是能加分的。同时能解决掉难点，对自身成长也是有利的，且还能说明的你韧性不错，有追求。

• 取得的成效，不能只是重视过程，而不重视结果，这是不可取的。你需要用结果和数据体现你的价值。比如说，支付中心上线后，你负责的业务模块，慢调用和慢SQL消失了，接口响应速度提升了10倍，上线半年，无任何大故障。等等。

项目经历写几个合适？

如果按照上面的的方式来书写项目的话，那每个项目的文字描述是不短的，一个项目的描述就大概要占用半页了。因此，简历里的项目不能太多，2到3个就可以了。项目主要在精不在多，把自己负责比较多的且能作为自己的一个亮点的核心项目，说清楚道明白，更为重要。

现在的你应该做什么？

赶紧好好总结一些当前和之前做过的项目，按照上面列的方式，好好梳理和思考一下，提炼一些重要的内容出来。争取能作为自己履历的亮点。如果你发现到目前为止，还没有能为自己带来竞争力的项目，那赶紧好好反思一下，赶紧争取去做。

小结

如果你不是什么名人或者知名大佬，学历和履历也一般般，那么你只能通过曾经做过好的项目来增强自己的竞争力了。HR也会通过你的项目经历来了解你的能力。项目经历一定要真实，要突出亮点和难点，并说清楚自己在项目起到什么作用。

作者：SamDeepThinking
来源：juejin.cn/post/7200953096893136955

预编译发生在什么时候

预编译发生在函数执行的前一刻

一. 预编译的抽象理解

• 函数声明整体提升

• 变量，声明提升

举个例子

<script type="text/javascript">
    test();
    function test() {
        console.log('我是test');  
    }
    a = 10;
    var a;
    console.log(a);
</script>

这里控制台能正常输出就是因为在预编译时将函数的声明整体和变量的声明提升到了代码的最顶部，所以代码中先调用函数或者是先给变量赋值再声明都没有问题，当然这是抽象的概念，记住这个已经能解决8-90%的变成问题了，如果你想了解具体的流程，可以接着往下看。

二. 局部函数预编译过程

1. 创建AO（Activation Object）对象

2. 找形参和变量声明，将变量和形参名作为AO对象的属性名，默认值为undefind

3. 将实参值和形参相关联

4. 找函数声明，值为其函数体

例子一

<script type="text/javascript">
    function test(a) {
        var b = 10;     
        function c() {       
        }                       
    }                                   
    test(1);                    
</script>

根据过程来我们可以得出右边的AO对象中的数值，a最终保存的是1,因为第三步需要把形参和实参相关联

例子二

<script type="text/javascript">
    function test(a) {             
        var a = 10;          
        function a() {               
        }
    }
    test(1);
</script>

对象中同名的属性会只保留一个，所以经过第二步寻找变量声明和形参的时候，AO对象中会有一个a，且默认值为undefind，经过第三步实参值和形参相关联后，a的值变为1，经过第四步找函数声明的时候发现有个名字为a的函数，AO中本身就有a的属性名了，所以这个时候会将a的函数体赋值给AO中的a。

如果上面的例子能够搞懂的话，咱们就可以接着玩一个题

例子三

<script type="text/javascript">
    function test(a) {
        console.log(a);
        var a = 10;
        console.log(a);
        function a() {
            consoel.log('这是函数a');
        }
    }
    test(1);
</script>

如果你心中的结果跟答案一致，说明已经清楚了局部函数预编译的四个步骤了

到test函数执行之前AO对象中a的值为a的函数体这个应该没有什么问题吧？所以第一个log打印出来的是a的函数体，第二个log之前由于有var a = 10;，这个经过变量的声明提升后可以看做是a = 10;，走到这里这里AO中的a被赋值为10，所以第二个log打印的就是10。

二. 全局函数预编译过程

1. 创建GO（Global Object）对象

2. 找变量声明，将变量名作为GO对象的属性名，默认值为undefind

3. 找函数声明，值为其函数体

全局函数的过程跟局部函数差不多，由于全局函数没有形参和实参的传递，所以省略了一个步骤。

例子四

<script type="text/javascript">
    console.log(a);
    var a = 1111;
    console.log(a);
    function a() {
        console.log('这里是a函数');
    }
</script>

这里例子四的输出和转化结果跟例子三差不多，只不过是AO对象变成了GO对象。

例子五

<script type="text/javascript">
    console.log(a);
    var a = 10;
    function a(a) {
        console.log(a);
    }
    a(1);
</script>

这里可以看看第二个log打印的是什么，还是会报错？

第一个log打印a函数的函数体没有问题吧？第二个log为什么会报错呢？因为GO对象中保存的a属性在第一次log的时候保存的是a的函数体，但是下面有个a=10;*的赋值，这个时候GO中的a就被修改成10了，后面调用*a(1)*函数的时候，找到GO中的a，这个时候a是number数字而不是函数，所以会报错说*a is not a function。

例子六

<script type="text/javascript">
    var a = 1;
    var b = 2;
    function test(a) {
        var a;
    console.log(a);  // 输出10
    a = 100;
    console.log(a);  // 输出100
        console.log(b); // 输出2
    }
    test(10);
    console.log(a);  // 输出1
</script>

看看例子六的输出结果是不是符合自己的心里预期。我们都知道函数内部有变量会优先使用自身内部的变量，其实也可以转化成AO和GO来理解。 第一个log输出的时候找到自身的AO中有属性a，且这个值是实参传递过来的，所以是10。 第二个log由于前面有a=100所以a被赋值成了100。 第三个log会找自己的AO，发现自己的AO里没有这个b属性，就会去找到父函数的AO，由于这里父函数是全局函数了，所以就去找GO里有没有b属性，有的话就输出了GO里的b的值，所以是2。（如果这里GO中也没有b属性的话，就会报b is not defined的错误了） 第四个log输出的就是自身AO也就是GO中的a属性的值了。

看完这几个例子相信你应该对预编译有个比较清晰的认识了，这里的面试题很多，但是万变不离其中，我们只需要把AO和GO分析出来，那么就可以清晰的了解到函数运行过程中每一步的每个属性值分别是什么了。

作者：Charlin丶
来源：juejin.cn/post/7200681438315642941

序

心平气和的解决了问题，但是想吐槽

划重点 说的地方是 北京昌平沙河 永利家园, 一切都是我个人感觉，请客观看待

基本条件

我们是一室一厅，屋里一个床，客厅一个床

事件

刚来的时候 当时我说 客厅这个床不太好啊 。房东说 正常就一个屋里床，客厅这个床 不算，可以要也可以不要。当时听了这话 感觉无所谓，放这呗。

后来 没几天 就发现客厅床坏的，之前几天搬家 没关注 ，这坐坐就不行了。。。心里已经骂了，不过一想 这是送的，算了 无所谓

后台 在10月初 我们找房东 说这个客厅床我们不要了，当时说没事，能处理

我说谢谢，然后后台有事 没继续跟进，今天 我上班，我媳妇和房东联系，本来不错，然后

修床的人 说 找房东处理

房东说 找修床的人处理

然后可能合计我媳妇 好欺负，说是要赔偿，自己当时怎么拼的这个客厅床，不清楚？ 不明白？ 还用我明说？

我媳妇难受了，说不过

结尾

我这脾气欺负我媳妇，我管不了了，直接电话干过去。中间的步骤省略

结果就是 不用赔偿，丢了就行。

另外

这家还有一个问题，其他费用比较多，比较坑。

只有你最后付钱的时候 才会告诉你 每个月有一个40的什么费用来的，名头我忘了

最后

实在忍不住了，希望多一个人看到 都是好的，希望大家租房 别踩坑，自己知道就好，别说在哪知道的哈，大家都不容易

作者：雨夜之寂
来源：juejin.cn/post/7159475467987189767

前言

在我的项目 隐云图解制作 中，有一个功能是按照一定规则将多张 gif 拼接成一张 gif。

当然，这里说的拼接是类似于拼图一样的拼接，而不是简单粗暴的把多个 gif 合成一个 gif 并按顺序播放。

大致效果如下：

注意：上面的动图只展示了预览效果，没有展示实际合成效果，但是合成效果和预览效果是一摸一样的，有兴趣的话，我可以再开一篇文章讲解怎么实现这个预览效果

实现方法

FFmpeg 简介

在开始之前先简单介绍一下什么是 FFmpeg，不过我相信只要是稍微接触过一点音视频的开发者都知道 FFmpeg。

FFmpeg 是一个开放源代码的自由软件，可以执行音频和视频多种格式的录影、转换、串流功能，包含了 libavcodec ——这是一个用于多个项目中音频和视频的解码器库，以及 libavformat ——一个音频与视频格式转换库。

简单来说，只要是和音视频相关的操作，几乎都可以使用 FFmpeg 来实现。

当然，FFmpeg 是一个纯命令行工具，所以我在这里简单介绍几个本文需要用到的参数：

1. -y 若指定的输出文件已存在则强制覆盖

2. -i 设置输入文件，可以设置多个

3. -filter_complex 设置复杂滤镜，我们这次要实现的拼接 gif 就是依靠这个参数完成

在安卓中使用 FFmpeg

我现在使用的库是 ffmpeg-kit 使用这个库可以直接集成 FFmpeg 到项目中，并且能够方便的执行 FFmpeg 命令。

该库执行 FFmpeg 很简单，只需要：

val session = FFmpegKit.executeWithArguments("your cmd text")
if (ReturnCode.isSuccess(session.returnCode)) {
    Log.i(TAG, "Command execution completed successfully.")
} else if (ReturnCode.isCancel(session.returnCode)) {
    Log.i(TAG, "Command execution cancelled by user.")
} else {
    Log.e(TAG, String.format("Command execution fail with state %s and rc %s.%s", session.state, session.returnCode, session.failStackTrace))
}

因为我需要自己管理线程，所以使用的是同步执行

另外，我几乎试过当前 GitHub 上最近还在维护所有的 FFmpeg for Android 库，甚至还自己写过一个，但是都或多或少的有点问题，最终只有这个库能够适配我的需求。

在此弱弱的吐槽一下某些“开源”库，只提供二进制包，不提供编译脚本，也不提供源代码，提供的二进制包缺少了某些依赖，我想自己动手编译都没法编译，一看 README ，好嘛，定制编译请联系作者付费获取，合着这开源开了个寂寞啊。

拼接命令

我们先来看一段完整的拼接命令，我会详细讲解各个参数的作用，最后再讲解如何动态生成需要的命令。

完整命令：

# 覆盖输出文件
-y 

# 输入文件
-i jointBg.png 
-i 1.gif 
-i 2.gif 
-i 3.gif 
-i 4.gif 

# 开始进行滤镜转换
-filter_complex 
[0:v]pad=1280:2161[bg];
[1:v]scale=640:1137[gif0];
[2:v]scale=640:368[gif1];
[3:v]scale=640:1024[gif2];
[4:v]scale=640:368[gif3];

[bg][gif0] overlay=0:0[over0];
[over0][gif1] overlay=640:0[over1];
[over1][gif2] overlay=0:1137[over2];
[over2][gif3] overlay=640:368 

# 输出路径
out.gif

为了方便查看，我使用换行分割了命令，使用时可不能加换行哦

在这段代码中，我们使用 -y 参数指定如果输出文件已存在则覆盖。

接下来使用 -i 参数输入了 5 个文件，其中 jointBg.png 是我生成的一个 1x1 像素的图片，用于后面扩展成背景画布，其他的 gif 文件就是要拼接的源文件。

然后使用 -filter_complex 表示要做一个复杂滤镜，后面跟着的都是这个复杂滤镜的参数：

[0:v]pad=1280:2161[bg]; 表示将输入的第一个文件作为视频打开，并将其当成画板，同时缩放分辨率为 1280x2161 （后面会讲这些分辨率是怎么来的），最后取名为 bg 。

[1:v]scale=640:1137[gif0]; 表示将输入的第二个文件作为视频打开，并缩放分辨率至 640x1137 ， 最后取别名为 gif0 。

下面的三行语句作用相同。

然后就是开始拼接：

[bg][gif0] overlay=0:0[over0]; 表示将 gif0 覆盖到 bg 上，并且覆盖的起点坐标为 0x0 ，最后将该其取名为 over0 。

下面的三行代码作用相同。

简单理解一下这个过程：

1. 创建一个图片，并缩放尺寸至事先计算出来的最终拼接成品的尺寸作为背景

2. 依次将输入的文件缩放至事先计算好的尺寸

3. 依次将缩放后的输入文件覆盖（叠加）到背景上

动画演示：

仅作演示便于理解，实际拼接时一般都是放大 bg ， 缩小 gif，并且 gif 将完全覆盖住 bg

计算尺寸

上一节中的命令涉及到很多缩放过程，那么这个缩放的尺寸是如何得到的呢？

这一节我们将讲解如何计算尺寸。

首先，我们需要知道的是，当前这个功能，一共有三种拼接模式：

1. 横向拼接

2. 纵向拼接

3. 宫格拼接

本文主要讲解的是宫格拼接，宫格拼接的样式即文章开头的预览效果那种。

既然是宫格拼接，那么绕不开的就是如果拼接的动图尺寸不一致，怎么确保拼接出来的动图美观？

这里我们有两种策略，由用户自行选择：

1. 完全以最小尺寸的图片为基准，将所有图片强制缩放到最小尺寸，这样可能会造成部分动图被拉伸失真。

2. 以所有图片中的最小宽度为基准，等比例缩放其他图片，这样可以确保所有图片都不会失真，但是拼接出来的成品将不是一个完美的矩形，而是一个留有黑色背景的异形图片。

确定了我们使用的两种缩放策略，下面就是开始计算成品的总尺寸和每张输入图片的需要缩放尺寸。

不过在此之前，我们需要遍历所有输入图片，拿到所有图片的原始尺寸和所有图片中的最小尺寸：

val jointGifResolution: MutableList<MutableList<Int>> = ArrayList() // 所有动图的原始尺寸 list
var minValue = Int.MAX_VALUE  // 最小宽度(别问我为什么不命名成 minWidth ，问就是兼容性)
var minValue2 = Int.MAX_VALUE  // 最小高度

for (uri in gifUris) {
    val gifDrawable = GifDrawable(context.contentResolver, uri)
    val height = gifDrawable.intrinsicHeight  // 当前 gif 的原始高度
    val width = gifDrawable.intrinsicWidth  // 当前 gif 的原始宽度
    jointGifResolution.add(mutableListOf(width, height))  // 将尺寸加入 list
    
    // 计算最小宽高
    if (minValue > width) {
        minValue = width
    }
    if (minValue2 > height) {
        minValue2 = height
    }
}

其中，gifUris 即事先获取到的所有输入动图的 uri 列表。

这里我们使用到了 GifDrawable 获取动图的尺寸，因为这不是本文的重点，所以不多加解释，读者只需知道这样可以拿到 gif 的原始尺寸即可。

拿到所有动图的原始宽高和最小宽高后，下一步是计算需要的缩放值：

var totalHeight = 0
var totalWidth = 0

var squareIndex = 0
val squareTotalHeight: MutableList<Int> = arrayListOf()

jointGifResolution.forEachIndexed { index, resolution ->
    val jointWidth = minValue // 无论使用缩放策略 1 还是 2，缩放宽度都是最小宽度
    val jointHeight = when (scaleMode) {
        // 如果使用缩放策略 2 则需要按比例计算出缩放高度
        GifTools.JointScaleModeWithRatio -> resolution[1] * minValue / resolution[0]
        // 如果使用缩放策略 1 则直接强制缩放到最小高度
        else -> minValue2
    }
    // 因为宫格拼接只能使用 2 的 n 次幂张图片，所以每行图片数量可以根据图片总数算出，不过太麻烦，所以这里我打了个表，直接从表里面拿
    // val JointGifSquareLineLength = hashMapOf(4 to 2, 9 to 3, 16 to 4, 25 to 5, 36 to 6, 49 to 7, 64 to 8, 81 to 9, 100 to 10)
    var lineLength = GifTools.JointGifSquareLineLength[jointGifResolution.size]
    if (lineLength == null) {
        lineLength = sqrt(jointGifResolution.size.toDouble()).toInt()
    }
    
    if (scaleMode == GifTools.JointScaleModeWithRatio) { // 使用等比缩放策略
        
        if (index < lineLength) {  // 所有图片宽度都是一样的，所以直接加一行的宽度得到的就是最大宽度
            totalWidth += jointWidth
        }
        try {
            // 这里是获取每一列的当前行高，并将其加起来，最终遍历完会得到当前列的高度
            val tempIndex = squareIndex % lineLength
            Log.e(TAG, "getJointGifResolution: temp index = $tempIndex")
            if (squareTotalHeight.size <= tempIndex) {
                squareTotalHeight.add(tempIndex, 0)
            }
            squareTotalHeight[tempIndex] = squareTotalHeight[tempIndex] + jointHeight
        } catch (e: java.lang.Exception) {
            Log.e(TAG, "getJointGifResolution: ", e)
        }
        
        // 将缩放尺寸更新至尺寸列表
        jointGifResolution[index] = mutableListOf(jointWidth, jointHeight)
    } else {
        // 如果不是按比例缩放，则直接将最小宽高存入总宽高
        if (index < lineLength) {
            totalHeight += min(jointHeight, jointWidth)
            totalWidth += min(jointHeight, jointWidth)
        }
        
        // 将缩放尺寸更新至尺寸列表
        jointGifResolution[index] = mutableListOf(min(jointHeight, jointWidth), min(jointHeight, jointWidth))
    }
    squareIndex++
}

上面的代码我已经加了详细的注释，至此所有图片的缩放尺寸已计算出来。

即，总尺寸为：

if (scaleMode != GifTools.JointScaleModeWithRatio) {
    jointGifResolution.add(mutableListOf(totalWidth, totalHeight))
}
else {
    Log.e(TAG, "getJointGifResolution: $squareTotalHeight")
    jointGifResolution.add(mutableListOf(totalWidth, Collections.max(squareTotalHeight)))
}

最小宽高为：

jointGifResolution.add(mutableListOf(minValue, minValue2))

对了，你可能会奇怪，为什么我要把总尺寸和最小宽高存入缩放尺寸 list，哈哈，这是因为我懒，所以我对这个 list 的定义是：

/**
 *
 * 遍历获取所有 gifUris 中的动图分辨率
 *
 * 并将经过处理后的所有长、宽之和存入 [size-2] ；
 *
 * 将最小的长宽存入 [size-1]
 * */

动态生成命令

完成了尺寸的计算，下一步是按照输入文件和计算出来的尺寸动态的生成 FFmpeg 命令。

不过在这之前，我们需要先创建一个 1x1 的图片，用来扩展成背景：

private suspend fun createJointBgPic(context: Context): File? {
    val drawable = ColorDrawable(Color.parseColor("#FFFFFFFF"))
    val bitmap = Bitmap.createBitmap(1, 1, Bitmap.Config.ARGB_8888)
    val canvas = Canvas(bitmap)
    drawable.draw(canvas)
    return try {
        Tools.saveBitmap2File(bitmap, "jointBg", context.externalCacheDir)
    } catch (e: Exception) {
        log2text("Create cache bg fail!", "e", e)
        null
    }
}

然后从尺寸列表中取出并删除追加在末尾的总尺寸和最小尺寸：

// 别看了，没写错，就是两个 size-1 ，为啥？你猜

val minResolution = gifResolution.removeAt(gifResolution.size - 1)

val totalResolution = gifResolution.removeAt(gifResolution.size - 1)

然后，就是开始拼接命令，这里我为了方便使用，自己写了一个 FFmpeg 命令的 Builder：

/**

 * @author equationl

 * */

public class FFMpegArgumentsBuilder {

    private final String[] cmd;



    public static class Builder {

        private final ArrayList<String> cmd = new ArrayList<>();



        /**

        * Such as add [arg, value] to cmd[]

        * */

        public Builder setArgWithValue(String arg, String value) {

            this.cmd.add(arg);

            this.cmd.add(value);

            return this;

        }



        /**

         * Such as add arg to cmd[]

         * */

        public Builder setArg(String arg) {

            this.cmd.add(arg);

            return this;

        }



        /**

        * Such as "-ss time"

        * */

        public Builder setStartTime(String time) {

            this.cmd.add("-ss");

            this.cmd.add(time);

            return this;

        }



        /**

         * Such as "-to time"

         * */

        public Builder setEndTime(String time) {

            this.cmd.add("-to");

            this.cmd.add(time);

            return this;

        }



        /**

        * Such as "-i input"

        * */

        public Builder setInput(String input) {

            this.cmd.add("-i");

            this.cmd.add(input);

            return this;

        }



        /**

        * <p>Such as "-t time"</p>

         * <p>Note: call this before addInput() will limit input duration time; call before addOutput() will limit output duration time.</p>

        * */

        public Builder setDurationTime(String time) {

            this.cmd.add("-t");

            this.cmd.add(time);

            return this;

        }



        /**

         * <p>if isOverride is true, add "-y"; else add "-n"</p>

         * <p>if do not set this arg, FFMpeg may ask for if override existed output file</p>

         * */

        public Builder setOverride(Boolean isOverride) {

            if (isOverride) {

                this.cmd.add("-y");

            }

            else {

                this.cmd.add("-n");

            }

            return this;

        }



        /**

         * Add output file to cmd[].<b>You must call this at end.</b>

         * */

        public Builder setOutput(String output) {

            this.cmd.add(output);

            return this;

        }



        /**

        * <p>Set input/output file format</p>

         * <p>Such as "-f format"</p>

        * */

        public Builder setFormat(String format) {

            this.cmd.add("-f");

            this.cmd.add(format);

            return this;

        }



        /**

         * Set video filter

         * Such as "-vf filter"

         * */

        public Builder setVideoFilter(String filter) {

            this.cmd.add("-vf");

            this.cmd.add(filter);

            return this;

        }



        /**

         * Set frame rate, Such as "-r frameRate"

        * */

        public Builder setFrameRate(String frameRate) {

            this.cmd.add("-r");

            this.cmd.add(frameRate);

            return this;

        }



        /**

         * Set frame size, Such as "-s frameSize"

         * */

        public Builder setFrameSize(String frameSize) {

            this.cmd.add("-s");

            this.cmd.add(frameSize);

            return this;

        }



        public FFMpegArgumentsBuilder build() {

            return new FFMpegArgumentsBuilder(this, false);

        }



        /**

         * Build cmd

         *

         * @param isAddFFmpeg true: Add a ffmpeg flag in first

        * */

        public FFMpegArgumentsBuilder build(Boolean isAddFFmpeg) {

            return new FFMpegArgumentsBuilder(this, isAddFFmpeg);

        }

    }



    public String[] getCmd() {

        return this.cmd;

    }



    private FFMpegArgumentsBuilder(Builder b, Boolean isAddFFmpeg) {

        if (isAddFFmpeg) {

            b.cmd.add(0, "ffmpeg");

        }

        this.cmd = b.cmd.toArray(new String[0]);

    }



}

开始生成命令文本：

首先是输入文件等，

val cmdBuilder = FFMpegArgumentsBuilder.Builder()

cmdBuilder.setOverride(true) // -y

        .setInput(jointBg.absolutePath)  // -i 输入背景



for (uri in gifUris) {  //输入GIF

    cmdBuilder.setInput(FileUtils.getMediaAbsolutePath(context, uri)) // -i

}



cmdBuilder.setArg("-filter_complex")  //添加过滤器

然后是添加过滤器参数，

//过滤器参数

var cmdFilter = ""



//设置背景并扩展分辨率到 total

cmdFilter += "[0:v]pad=${totalResolution[0]}:${totalResolution[1]}[bg];"



//将输入文件缩放并取别名为 gifX (X为索引）

gifResolution.forEachIndexed { index, mutableList ->

    cmdFilter += "[${index+1}:v]scale=${mutableList[0]}:${mutableList[1]}[gif$index];"

}



cmdFilter += "[bg][gif0] overlay=0:0[over0];"   //将第一个GIF叠加 bg 的 0:0 （即画面左下角）



//开始叠加剩余动图

cmdFilter += getCmdFilterOverlaySquare(gifUris, gifResolution)

其中，getCmdFilterOverlaySquare 用于计算 gif 的摆放坐标，并合成参数命令，实现如下：

private fun getCmdFilterOverlaySquare(gifUris: ArrayList<Uri>, gifResolution: MutableList<MutableList<Int>>): String {

    //     "[bg][gif0] overlay=0:0[over0];"

    var cmdFilter = ""

    var h: Int

    var w: Int

    var index = 0

    var lineLength = GifTools.JointGifSquareLineLength[gifUris.size]

    if (lineLength == null) {

        lineLength = sqrt(gifUris.size.toDouble()).toInt()

    }



    for (i in 0 until lineLength) {

        for (j in 0 until lineLength) {

            if ((i==lineLength-1 && j==lineLength-1) || (i==0 && j==0)) { //最后一张单独处理,第一张已处理

                continue

            }

            if (j==0) { //竖排第一个，w当然等于 0

                w = 0

            } else {

                w = 0

                for (k in 0 until j) {

                    w += gifResolution[i*lineLength+k][0]

                }

            }

            if (i==0) {  //横排第一个，h等于0

                h = 0

            } else {

                h = 0

                for (k in j until index step lineLength) {

                    h += gifResolution[k][1]

                }

            }



            cmdFilter += "[over${index}][gif${index+1}] overlay=$w:$h[over${index + 1}];"

            index++

        }

    }



    w = 0

    for (i in 0 until lineLength-1) {

        w += gifResolution[i+lineLength*(lineLength-1)][0]

    }



    h = 0

    for (i in lineLength-1 until lineLength*lineLength-1  step lineLength) {

        h += gifResolution[i][1]

    }



    cmdFilter += "[over${index}][gif${index+1}] overlay=$w:$h"



    return cmdFilter

}

上述代码不难理解，总之就是根据遍历到的 gif 索引，判断它应该所处的坐标，然后加入过滤器参数。

最后，将过滤参数加入命令，加入输出文件路径，即可拿到最终命令文本 cmd：

cmdBuilder.setArg(cmdFilter)
cmdBuilder.setOutput(resultPath)

val cmd = cmdBuilder.build(false).cmd

最后，只要将这个命令文本仍给 FFmpeg 执行即可！

总结

虽然本文仅仅说的是如何拼接 Gif ， 但是 FFmpeg 是十分强大的，我这个属于是抛砖引玉。

相信各位有过这样一种需求，那就是做一个多人同屏的实时会议功能，如果在看本文之前你可能不知所措，但是看完本文你一定会觉得这是小菜一碟。

因为 FFmpeg 原生支持串流，支持视频处理，你只要把我这里的输入文件改成串流，输出文件改成串流，再按照你的需求改一下坐标，那不就完成了吗？

作者：equationl
来源：juejin.cn/post/7136325945937362952

虾扯淡

很多人都介绍过Gradle 7.+提供新依赖管理工具VersionCatalog，我就不过多介绍这个了。我们最近也算是成功接入了VersionCatalog,过程也还是有点曲折的，总体来说我觉得确实比我们当前的ext，或者说是用buildSrc的形式进行依赖管理是个更成熟的方案吧。下面是几个介绍的文章，尤其可以看看三七哥哥的。

之前大部分文章只介绍了技术方案，很少会去横向对比几个技术方案之间的优劣。从我们最近一个月的使用结果上来看吧，接下来我给大家分析下实际的优劣，仅仅只代表个人看法, 上表格了。

因为VersionCatalog使用的文件格式是toml,所以后续可能会用toml进行简称。

声明域: 指的是我们在哪里声明这些依赖管理。其中ext可以在绝大部分的.gradle中去进行声明，所以就会导致依赖声明的过于零散。而这部分问题就不存在于buildSrc和toml中,他们只能被声明在固定的位置上。

可修改性: 特制声明的依赖能否被修改，ext声明是在内存空间内，而ext的本质其实就是一个Any他可以存放任意的东西，如果出现同名的则会是后面声明的把前面声明的覆盖掉，这就是一个非常不稳定的属性，而buildSrc则是由class来声明的，我们没有办法在gradle中去修改这部分，所以相对来说是稳定的。而toml也类似，基于固定格式反序列化成代码。不具备修改的能力。

写法: ext这方面是真的拉胯，比如支持libs.abc或者libs."abc"或者libs.["abc"]还可以单引号，就非常的随意,而且极为不统一。这也是我们本次改动中碰到问题最多的时候。其他两种写法都相对比较固定，类似java/kt 中的静态常量。

校验: ext就是爱咋写咋写吧，反正也没有很好的校验啥的。而buildSrc则是基于java的代码编译来的，toml因为是一个新的文件格式，所以内置了一套相对比较强的语法校验，如果不合规则会报错，并显示错误行数。

据说buildSrc对于增量编译的适配等其实不太良好，而且我们是一个复杂的巨型复合构建的工程，所以个人并不太推荐buildSrc。

可以参考这篇文章第二章 Stop using Gradle buildSrc. Use composite builds instead

由此可证哦，VersionCatalog雀食是一个非常好的选择，尤其如果你们当前还是在使用的是ext的情况下。

巨型工程最麻烦的事情其实另外一点就是技术栈的切换，因为要改起来的地方可真的就是太多了，首先就是要先解决复合构建的情况下全局只有一份注册的逻辑，其二就是把当前工程的ext全部转移到toml中,然后要最好和之前的方式接近，尽量保证最小改动。最后则是所有工程都改一下！！！！！！！！（要我狗命）

共享配置

GradleSample demo 工程如下，其中plugin-version就是

我们也采取了之前Gradle 奇淫技巧之initscript pluginManagement一样的方式，通过initscript做到复合构建内共享插件的能力。

另外我们把VersionCatalog作为一个extension抛出来在外部完成注册。

catalogs {
    script = new File(rootProjectDir, "depencies.gradle")

    versionCatalogs {
        create("libs") { from(files("${rootProjectDir.path}/toml/dependencies.versions.toml")) }
        create("module") { from(files("${rootProjectDir.path}/toml/module.versions.toml")) }
    }
    dependencyResolutionManagement {
        repositories {
            maven { setUrl("https://maven.aliyun.com/repository/central/") }
            maven {
                setUrl("https://storage.googleapis.com/r8-releases/raw")
            }
            gradlePluginPortal()
            google()
            mavenLocal()
            maven {
                url "https://dl.bintray.com/kotlin/kotlin-eap"
            }
        }
    }

}

通过这部分配置就可以把共享的部分注入进工程内。然后就是很沙雕的改改改了，把所有的ext全部迁移到我们新的toml上去，然后注册出多个。

命令行工具

TheNext 虾开发的撒币cli工具 专门解决虾的撒币问题

以前也说过了我们工程的模块数量巨大，然后又因为ext的写法风骚，所以我们基本所有的写依赖的地方都要改，就是真的工作量巨大。

一个优秀的摸鱼工程师最重要的天赋就是要学会转化生产力，把这种简单又繁琐的工作交给命令行来解决。所以这就有了TheNext的一个新能力，基于当前的文件目录修改所有的.gradle文件，然后把非标准的ext的写法全部进行一次替换。

效果如图所示。

代码逻辑如下，我们首先会遍历整个工程的文件目录，然后发现.gradle后缀的文件，之后通过正则匹配出dependencies，然后进行把一些"" '' []等等都删掉，然后把- _更换成.，这样就能完成简单的自动替换了。

package com.kronos.mebium.android

import com.beust.jcommander.JCommander
import com.kronos.mebium.action.Handler
import com.kronos.mebium.entity.CommandEntity
import com.kronos.mebium.file.getRootProjectDir
import com.kronos.mebium.utils.green
import com.kronos.mebium.utils.red
import com.kronos.mebium.utils.yellow
import java.io.File
import java.util.Scanner

/**
 *
 *  @Author LiABao
 *  @Since 2022/12/8
 *
 */
class DependenciesHandler : Handler {

    val scanner = Scanner(System.`in`)
    var isSkip = false

    override fun handle(args: Array<String>) {
        isSkip = args.contains(skip)
        val realArgs = if (isSkip) {
            arrayListOf<String>().apply {
                args.forEach {
                    if (it != skip) {
                        add(it)
                    }
                }
            }.toTypedArray()
        } else {
            args
        }
        val commandEntity = CommandEntity()
        JCommander.newBuilder().addObject(commandEntity).build().parse(*realArgs)
        val first = commandEntity.file
        val name = commandEntity.name
        val root = first
        val files = root.walkTopDown().filter {
            it.isFile && it.name.contains(".gradle")
        }
        val overrideList = mutableListOf<Pair<File, File>>()
        files.forEach {
            onGradleCheck(it)?.apply {
                overrideList.add(it to this)
            }
        }
        confirm(overrideList)
    }

    private fun confirm(overrideList: MutableList<Pair<File, File>>) {
        if (overrideList.isEmpty()) {
            return
        }
        println("if you want overwrite all this file ? input y to confirm \r\n".red())
        val input = scanner.next()
        if (input == "y") {
            overrideList.forEach {
                it.first.delete()
                it.second.renameTo(it.first)
            }
            print("replace success \r\n ".green())
        } else {
            print("skip\r\n ".yellow())
        }
    }

    private val pattern =
        "(\\D\\S*)(implementation|Implementation|compileOnly|CompileOnly|test|Test|api|Api|kapt|Kapt|Processor)([ (])(\\D\\S*)".toPattern()

    private fun onGradleCheck(file: File): File? {
        var override = false
        val lines = file.readLines()
        val newLines = mutableListOf<String>()
        lines.forEach { line ->
            val matcher = pattern.matcher(line)
            if (matcher.find()) {
                val libs = matcher.group(4)
                if (!libs.contains(":") && !libs.contains("files(")) {
                    val newLibs =
                        libs.replace("\'", "").replace("\"", "").replace("-", ".").replace("_", ".")
                            .replace("kotlin.libs", "kotlinlibs").replace("[", ".").replace("]", "")
                    if (newLibs == libs) {
                        newLines.add(line)
                        return@forEach
                    }
                    print("fileName: ${file.name} dependencies : $line \r\n")
                    if (isSkip) {
                        override = true
                        newLines.add(line.replace(libs, newLibs))
                        print("$libs do you want replace to $newLibs    \r\n ".green())
                        return@forEach
                    }
                    print("$libs do you want replace to $newLibs  ? input  y to replace  \r\n ".red())
                    while (true) {
                        val input = scanner.next()
                        if (input == "y") {
                            print("replace success\r\n".green())
                            override = true
                            newLines.add(line.replace(libs, newLibs))
                            return@forEach
                        } else {
                            print("skip\r\n ".yellow())
                            break
                        }
                    }
                }
            }
            newLines.add(line)
        }
        if (override) {
            val newFile = File(file.parent, file.name.removeSuffix(".gradle") + ".temp")
            newLines.forEach {
                newFile.appendText(it + "\r\n")
            }
            return newFile
        }
        return null
    }
}

const val skip = "--skip"

代码就基本是这样，如果有正则带佬可以帮忙优化下正则的。

然后这个工具也可以多次复用，因为我这个需求没有办法很快的被合入，需要频繁的rebase master的代码，每次rebase完之后都要进行二次修改，真的吐了。

验收

每个新功能开发最后都是要进行验收的，尤其是技改需求，你到时候把功能搞坏了到时候可是要背黑锅的啊。而且这种需求也没有办法要求测试进行特别系统性的测试，所以还是要开发自己想办法了。

我们拉取了apk包的依赖，然后用HashSet进行了拉平，去除重复依赖，然后通过diff对比前后差异，在基本符合预期的情况下我们就可以进行快速的合入。

结尾

其实本文的核心是给大家分析下几种依赖管理方式的优劣，然后对于还在使用gradle ext的大佬，其实可以逐渐考虑进行替换了。

作者：究极逮虾户
来源：juejin.cn/post/7190277951614058555

前言

在上一篇文章中我们讲解了关于串口的基础知识，没有看过的同学推荐先看一下，否则你可能会不太理解这篇文章所述的某些内容。

这篇文章我们将讲解安卓端的串口通信实践，即如何使用串口通信实现安卓设备与其他设备例如PLC主板之间数据交互。

需要注意的是正如上一篇文章所说的，我目前的条件只允许我使用 ESP32 开发版烧录 Arduino 程序与安卓真机（小米10U）进行串口通信演示。

准备工作

由于我们需要使用 ESP32 烧录 Arduino 程序演示安卓端的串口通信，所以在开始之前我们应该先把程序烧录好。

那么烧录一个怎样的程序呢？

很简单，我这里直接烧了一个 ESP32 使用 9600 的波特率进行串口通信，程序内容就是 ESP32 不断的向串口发送数据 “e” ，并且监听串口数据，如果接收到数据 “o” 则打开开发版上自带的 LED 灯，如果接收到数据 “c” 则关闭这个 LED 灯。

代码如下：

#define LED 12

void setup() {
  Serial.begin(9600);
  pinMode(LED, OUTPUT);
}

void loop() {
  if (Serial.available()) {
    char c = Serial.read();
    if (c == 'o') {
      digitalWrite(LED, HIGH);
    }
    if (c == 'c') {
      digitalWrite(LED, LOW);
    }
  }

  Serial.write('e');

  delay(100);
}

上面的 12 号 Pin 是这块开发版的 LED。

使用 Arduino自带串口监视器测试结果：

可以看到，确实如我们设想的通过串口不断的发送字符 “e”，并且在接收到字符 “o” 后点亮了 LED。

安卓实现串口通信

原理概述

众所周知，安卓其实是基于 Linux 的操作系统，所以在安卓中对于串口的处理与 Linux 一致。

在 Linux 中串口会被视为一个“设备”，并体现为 /dev/ttys 文件。

/dev/ttys 又被称为字符终端，例如 ttys0 对应的是 DOS/Windows 系统中的 COM1 串口文件。

通常，我们可以简单理解，如果我们插入了某个串口设备，则这个设备与 Linux 的通信会由 /dev/ttys 文件进行 “中转”。

即，如果 Linux 想要发送数据给串口设备，则可以通过往 /dev/ttys 文件中直接写入要发送的数据来实现，如：

echo test > /dev/ttyS1 这个命令会将 “test” 这串字符发送给串口设备。

如果想读取串口发送的数据也是一样的，可以通过读取 /dev/ttys 文件内容实现。

所以，如果我们在安卓中想要实现串口通信，大概率也会想到直接读取/写入这个特殊文件。

android-serialport-api

在上文中我们说到，在安卓中也可以通过与 Linux 一样的方式--直接读写 /dev/ttys 实现串口通信。

但是其实并不需要我们自己去处理读写和数据的解析，因为谷歌官方给出了一个解决方案：android-serialport-api

为了便于理解，我们会大致说一下这个解决方案的源码，但是就不上示例了，至于为什么，同学们往下看就知道了。另外，虽然这个方案历史比较悠久，也很长时间没有人维护了，但是并不意味着不能使用了，只是使用条件比较苛刻，当然，我司目前使用的还是这套方案（哈哈哈哈）。

不过这里我们不直接看 android-serialport-api 的源码，而是通过其他大佬二次封装的库来看： Android-SerialPort-API

在这个库中，通过

// 默认直接初始化，使用8N1(8数据位、无校验位、1停止位)，path为串口路径（如 /dev/ttys1），baudrate 为波特率
SerialPort serialPort = new SerialPort(path, baudrate);

// 使用可选参数配置初始化，可配置数据位、校验位、停止位 - 7E2(7数据位、偶校验、2停止位)
SerialPort serialPort = SerialPort 
    .newBuilder(path, baudrate)
// 校验位；0:无校验位(NONE，默认)；1:奇校验位(ODD);2:偶校验位(EVEN)
//    .parity(2) 
// 数据位,默认8；可选值为5~8
//    .dataBits(7) 
// 停止位，默认1；1:1位停止位；2:2位停止位
//    .stopBits(2) 
    .build();

初始化串口，然后通过：

InputStream in = serialPort.getInputStream();
OutputStream out = serialPort.getOutputStream();

获取到输入/输出流，通过读取/写入这两个流来实现与串口设备的数据通信。

我们首先来看看初始化串口是怎么做的。

首先检查了当前是否具有串口文件的读写权限，如果没有则通过 shell 命令更改权限为 666 ，更改后再次检查是否有权限，如果还是没有就抛出异常。

注意这里的执行 shell 时使用的 runtime 是 Runtime.getRuntime().exec(sSuPath); 也就是说，它是通过 root 权限来执行这段命令的！

换句话说，如果想要通过这种方式实现串口通信，必须要有 ROOT 权限！这就是我说我不会给出示例的原因，因为我手头的设备无法 ROOT 啊。至于为啥我司还能继续使用这种方案的原因也很简单，因为我们工控机的安卓设备都是定制版的啊，拥有 ROOT 权限不是基本操作？

确定权限可用后通过 open 方法拿到一个类型为 FileDescriptor 的变量 mFd ，最后通过这个 mFd 拿到输入输出流。

所以核心在于 open 方法，而 open 方法是一个 native 方法，即 C 代码：

private native FileDescriptor open(String absolutePath, int baudrate, int dataBits, int parity,
    int stopBits, int flags);

C 的源码这里就不放了，只需要知道它做的工作就是打开了 /dev/ttys 文件（准确的说是“终端”），然后通过传递进去的这些参数去按串口规则解析数据，最后返回一个 java 的 FileDescriptor 对象。

在 java 中我们再通过这个 FileDescriptor 对象可以拿到输入/输出流。

原理说起来是十分的简单。

看完通信部分的原理后，我们再来看看我们如何查找可用的串口呢？

其实和 Linux 上也一样：

public Vector<File> getDevices() {
    if (mDevices == null) {
        mDevices = new Vector<File>();
        File dev = new File("/dev");
        
        File[] files = dev.listFiles();

        if (files != null) {
            int i;
            for (i = 0; i < files.length; i++) {
                if (files[i].getAbsolutePath().startsWith(mDeviceRoot)) {
                    Log.d(TAG, "Found new device: " + files[i]);
                    mDevices.add(files[i]);
                }
            }
        }
    }
    return mDevices;
}

也是通过直接遍历 /dev 下的文件，只不过这里做了一些额外的过滤。

或者也可以通过读取 /proc/tty/drivers 配置文件后过滤：

Vector<Driver> getDrivers() throws IOException {
    if (mDrivers == null) {
        mDrivers = new Vector<Driver>();
        LineNumberReader r = new LineNumberReader(new FileReader("/proc/tty/drivers"));
        String l;
        while ((l = r.readLine()) != null) {
            // Issue 3:
            // Since driver name may contain spaces, we do not extract driver name with split()
            String drivername = l.substring(0, 0x15).trim();
            String[] w = l.split(" +");
            if ((w.length >= 5) && (w[w.length - 1].equals("serial"))) {
                Log.d(TAG, "Found new driver " + drivername + " on " + w[w.length - 4]);
                mDrivers.add(new Driver(drivername, w[w.length - 4]));
            }
        }
        r.close();
    }
    return mDrivers;
}

关于读取可用串口设备，其实从这里的路径也可以看出，都是系统路径，也就是说，如果没有权限，大概率也是读取不到东西的。

这就是使用与 Linux 一样的方式去读取串口数据的基本原理，那么问题来了，既然我说这个方法使用条件比较苛刻，那么更易用的替代方案是什么呢？

我们下面就会介绍，那就是使用安卓的 USB host （USB主机）的功能。

USB host

Android 3.1（API 级别 12）或更高版本的平台直接支持 USB 配件和主机模式。USB 配件模式还作为插件库向后移植到 Android 2.3.4（API 级别 10）中，以支持更广泛的设备。设备制造商可以选择是否在设备的系统映像中添加该插件库。

在安卓 3.1 版本开始，支持将USB作为主机模式（USB host）使用，而我们如果想要通过 USB 读取串口数据则需要依赖于这个主机模式。

在正式开始介绍USB主机模式前，我们先简要介绍一下安卓上支持的USB模式。

安卓上的USB支持三种模式：设备模式、主机模式、配件模式。

设备模式即我们常用的直接将安卓设备连接至电脑上，此时电脑上显示为 USB 外设，即可以当成 “U盘” 使用拷贝数据，不过现在安卓普遍还支持 MTP模式（作为摄像头）、文件传输模式（即当U盘用）、网卡模式等。

主机模式即将我们的安卓设备作为主机，连接其他外设，此时安卓设备就相当于上面设备模式中的电脑。此时安卓设备可以连接键盘、鼠标、U盘以及嵌入式应用USB转串口、转I2C等设备。但是如果想要将安卓设备作为主机模式可能需要一条支持 OTG 的数据线或转接头。（Micro-USB 或 USB type-c 转 USB-A 口）

而在 USB 配件模式下，外部 USB 硬件充当 USB 主机。配件示例可能包括机器人控制器、扩展坞、诊断和音乐设备、自助服务终端、读卡器等等。这样，不具备主机功能的 Android 设备就能够与 USB 硬件互动。Android USB 配件必须设计为与 Android 设备兼容，并且必须遵守 Android 配件通信协议。

设备模式与配件模式的区别在于在配件模式下，除了 adb 之外，主机还可以看到其他 USB 功能。

使用USB主机模式与外设交互数据

在介绍完安卓中的三种USB模式后，下面我们开始介绍如何使用USB主机模式。当然，这里只是大概介绍原生APi的使用方法，我们在实际使用中一般都都是直接使用大佬编写的第三方库。

准备工作

在开始正式使用USB主机模式时我们需要先做一些准备工作。

首先我们需要在清单文件(AndroidManifest.xml)中添加：

<!-- 声明需要USB主机模式支持，避免不支持的设备安装了该应用 -->
<uses-feature android:name="android.hardware.usb.host" />

<!-- …… -->

<!-- 声明需要接收USB连接事件 -->
<action android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED" />

一个完整的清单文件示例如下：

<manifest ...>
    <uses-feature android:name="android.hardware.usb.host" />
    <uses-sdk android:minSdkVersion="12" />
    ...
    <application>
        <activity ...>
            ...
            <intent-filter>
                <action android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED" />
            </intent-filter>
        </activity>
    </application>
</manifest>

声明好清单文件后，我们就可以查找当前可用的设备信息了：

private fun scanDevice(context: Context) {

    val manager = context.getSystemService(Context.USB_SERVICE) as UsbManager

    val deviceList: HashMap<String, UsbDevice> = manager.deviceList

    Log.i(TAG, "scanDevice: $deviceList")

}

将 ESP32 开发版插上手机，运行程序，输出如下：

可以看到，正确的查找到了我们的 ESP32 开发版。

这里提一下，因为我们的手机只有一个 USB 口，此时已经插上了 ESP32 开发版，所以无法再通过数据线直接连接电脑的 ADB 了，此时我们需要使用无线 ADB，具体怎么使用无线 ADB，请自行搜索。

另外，如果我们想要通过查找到设备后请求连接的方式连接到串口设备的话，还需要额外申请权限。（同理，如果我们直接在清单文件中提前声明需要连接的设备则不需要额外申请权限，具体可以看看参考资料5，这里不再赘述）

首先声明一个广播接收器，用于接收授权结果：

private lateinit var permissionIntent: PendingIntent



private const val ACTION_USB_PERMISSION = "com.android.example.USB_PERMISSION"



private val usbReceiver = object : BroadcastReceiver() {



    override fun onReceive(context: Context, intent: Intent) {

        if (ACTION_USB_PERMISSION == intent.action) {

            synchronized(this) {

                val device: UsbDevice? = intent.getParcelableExtra(UsbManager.EXTRA_DEVICE)



                if (intent.getBooleanExtra(UsbManager.EXTRA_PERMISSION_GRANTED, false)) {

                    device?.apply {

                    	// 已授权，可以在这里开始请求连接

                        connectDevice(context, device)

                    }

                } else {

                    Log.d(TAG, "permission denied for device $device")

                }

            }

        }

    }

}

声明好之后在 Acticity 的 OnCreate 中注册这个广播接收器：

permissionIntent = PendingIntent.getBroadcast(this, 0, Intent(ACTION_USB_PERMISSION), FLAG_MUTABLE)

val filter = IntentFilter(ACTION_USB_PERMISSION)

registerReceiver(usbReceiver, filter)

最后，在查找到设备后，调用 manager.requestPermission(deviceList.values.first(), permissionIntent) 弹出对话框申请权限。

连接到设备并收发数据

完成上述的准备工作后，我们终于可以连接搜索到的设备并进行数据交互了：

private fun connectDevice(context: Context, device: UsbDevice) {

    val usbManager = context.getSystemService(Context.USB_SERVICE) as UsbManager



    CoroutineScope(Dispatchers.IO).launch {

        device.getInterface(0).also { intf ->

            intf.getEndpoint(0).also { endpoint ->

                usbManager.openDevice(device)?.apply {

                    claimInterface(intf, forceClaim)

                    while (true) {

                        val validLength = bulkTransfer(endpoint, bytes, bytes.size, TIMEOUT)

                        if (validLength > 0) {

                            val result = bytes.copyOfRange(0, validLength)

                            Log.i(TAG, "connectDevice: length = $validLength")

                            Log.i(TAG, "connectDevice: byte = ${result.contentToString()}")

                        }

                        else {

                            Log.i(TAG, "connectDevice: Not recv data!")

                        }

                    }

                }

            }

        }

    }

}

在上面的代码中，我们使用 usbManager.openDevice 打开了指定的设备，即连接到设备。

然后通过 bulkTransfer 接收数据，它会将接收到的数据写入缓冲数组 bytes 中，并返回成功接收到的数据长度。

运行程序，连接设备，日志打印如下：

可以看到，输出的数据并不是我们预料中的数据。

这是因为这是非常原始的数据，如果我们想要读取数据，还需要针对不同的串口转USB芯片或协议编写驱动程序才能获取到正确的数据。

顺道一提，如果想要将数据写入串口数据的话可以使用 controlTransfer() 。

所以，我们在实际生产环境中使用的都是基于此封装好的第三方库。

这里推荐使用 usb-serial-for-android

usb-serial-for-android

使用这个库的第一步当然是导入依赖：

// 添加仓库

allprojects {

    repositories {

        ...

        maven { url 'https://jitpack.io' }

    }

}

// 添加依赖

dependencies {

    implementation 'com.github.mik3y:usb-serial-for-android:3.4.6'

}

添加完依赖同样需要在清单文件中添加相应字段以及处理权限，因为和上述使用原生API一致，所以这里不再赘述。

和原生 API 不同的是，因为我们此时已经知道了我们的 ESP32 主板的设备信息，以及使用的驱动（CDC），所以我们就不使用原生的查找可用设备的方法了，我们这里直接指定我们已知的这个设备（当然，你也可以继续使用原生API的查找和连接方法）：

private fun scanDevice(context: Context) {

    val manager = context.getSystemService(Context.USB_SERVICE) as UsbManager



    val customTable = ProbeTable()

    // 添加我们的设备信息，三个参数分别为 vendroId、productId、驱动程序

    customTable.addProduct(0x1a86, 0x55d3, CdcAcmSerialDriver::class.java)



    val prober = UsbSerialProber(customTable)

    // 查找指定的设备是否存在

    val drivers: List<UsbSerialDriver> = prober.findAllDrivers(manager)



    if (drivers.isNotEmpty()) {

        val driver = drivers[0]

        // 这个设备存在，连接到这个设备

        val connection = manager.openDevice(driver.device)

    }

    else {

        Log.i(TAG, "scanDevice: 无设备！")

    }

}

连接到设备后，下一步就是和数据交互，这里封装的十分方便，只需要获取到 UsbSerialPort 后，直接调用它的 read() 和 write() 即可读写数据：

port = driver.ports[0] // 大多数设备都只有一个 port，所以大多数情况下直接取第一个就行



port.open(connection)

// 设置连接参数，波特率9600，以及 “8N1”

port.setParameters(9600, 8, UsbSerialPort.STOPBITS_1, UsbSerialPort.PARITY_NONE)



// 读取数据

val responseBuffer = ByteArray(1024)

port.read(responseBuffer, 0)



// 写入数据

val sendData = byteArrayOf(0x6F)

port.write(sendData, 0)

此时，一个完整的，用于测试我们上述 ESP32 程序的代码如下：

@Composable

fun SerialScreen() {

    val context = LocalContext.current





    Column(

        Modifier.fillMaxSize(),

        verticalArrangement = Arrangement.Center,

        horizontalAlignment = Alignment.CenterHorizontally

    ) {

        Button(onClick = { scanDevice(context) }) {

            Text(text = "查找并连接设备")

        }



        Button(onClick = { switchLight(true) }) {

            Text(text = "开灯")

        }

        Button(onClick = { switchLight(false) }) {

            Text(text = "关灯")

        }



    }

}



private fun scanDevice(context: Context) {

    val manager = context.getSystemService(Context.USB_SERVICE) as UsbManager



    val customTable = ProbeTable()

    customTable.addProduct(0x1a86, 0x55d3, CdcAcmSerialDriver::class.java)



    val prober = UsbSerialProber(customTable)

    val drivers: List<UsbSerialDriver> = prober.findAllDrivers(manager)



    if (drivers.isNotEmpty()) {

        val driver = drivers[0]



        val connection = manager.openDevice(driver.device)

        if (connection == null) {

            Log.i(TAG, "scanDevice: 连接失败")

            return

        }



        port = driver.ports[0]



        port.open(connection)

        port.setParameters(9600, 8, UsbSerialPort.STOPBITS_1, UsbSerialPort.PARITY_NONE)



        Log.i(TAG, "scanDevice: Connect success!")



        CoroutineScope(Dispatchers.IO).launch {

            while (true) {

                val responseBuffer = ByteArray(1024)



                val len = port.read(responseBuffer, 0)



                Log.i(TAG, "scanDevice: recv data = ${responseBuffer.copyOfRange(0, len).contentToString()}")

            }

        }

    }

    else {

        Log.i(TAG, "scanDevice: 无设备！")

    }

}



private fun switchLight(isON: Boolean) {

    val sendData = if (isON) byteArrayOf(0x6F) else byteArrayOf(0x63)



    port.write(sendData, 0)

}

运行这个程序，并且连接设备，输出如下：

可以看到输出的是 byte 的 101，转换为 ASCII 即为 “e”。

然后我们点击 “开灯”、“关灯” 效果如下：

对了，这里发送的数据 “0x6F” 即 ASCII “o” 的十六进制，同理，“0x63” 即 “c”。

可以看到，可以完美的和我们的 ESP32 开发版进行通信。

实例

无论使用什么方式与串口通信，我们在安卓APP的代码层面能够拿到的数据已经是处理好了的数据。

即，在上一篇文章中我们说过串口通信的一帧数据包括起始位、数据位、校验位、停止位。但是我们在安卓中使用时一般拿到的都只有 数据位 的数据，其他数据已经在底层被解析好了，无需我们去关心怎么解析，或者使用。

我们可以直接拿到的就是可用数据。

这里举一个我之前用过的某型号驱动版的例子。

这块驱动版关于通信的信息如图：

可以看到，它采用了 RS485 的通信方式，波特率支持 9600 或 38400，8位数据位，无校验，1位停止位。

并且，它还规定了一个数据协议。

在它定义的协议中，第一位为地址；第二位为指令；第三位到第N位为数据内容；最后两位为CRC校验。

需要注意的是，这里定义的协议是基于串口通信的，不要把这个协议和串口通信搞混了，简单来说就是在串口通信协议的数据位中又定义了一个自己的协议。

而且可以看到，虽然定义串口参数时没有指定校验，但是在它自己的协议中指定了使用 CRC 校验。

另外，弱弱的吐槽一句，这个驱动版的协议真的不好使。

在实际使用过程中，主机与驱动版的通信数据无法保证一定会在同一个数据帧中发送完成，所以可能会造成“粘包”、“分包”现象，也就是说，数据可能会分几次发过来，而且你不好判断这数据是上次没发送完的数据还是新的数据。

我使用过的另外一款驱动版就方便的多，因为它会在帧头加上开始符号和数据长度，帧尾加上结束符号。

这样一来，即使出现“粘包”、“分包”我们也能很好的给它解析出来。

当然，它这样设计协议肯定是有它的道理的，无非就是减少通信代价之类的。

我还遇到过一款十分简洁的驱动版，直接发送一个整数过去表示执行对应的指令。

驱动版回传的数据同样非常简单，就是一个数字，然后事先约定各个数字表示什么意思……

说归说，我们还是继续来看这款驱动版的通信协议：

这是它的其中一个指令内容，我们发送指令 “1” 过去后，它会返回当前驱动版的型号和版本信息给我们。

因为我们的主板是定制工控主板，所以使用的通信方式是直接用 android-serialport-api。

最终发送与接收回复也很简单：

/**
 * 将十六进制字符串转成 ByteArray
 * */
private fun hexStrToBytes(hexString: String): ByteArray {
    check(hexString.length % 2 == 0) { return ByteArray(0) }

    return hexString.chunked(2)
        .map { it.toInt(16).toByte() }
        .toByteArray()
}

private fun isReceivedLegalData(receiveBuffer: ByteArray): Boolean {

    val rcvData = receiveBuffer.copyOf()  //重新拷贝一个使用，避免原数据被清零

    if (cmd.cmdId.checkDataFormat(rcvData)) {  //检查回复数据格式
        isPkgLost = false
        if (cmd.cmdId.isResponseBelong(rcvData)) {  //检查回复命令来源
            if (!AdhShareData.instance.getIsUsingCrc()) {  //如果不开启CRC检验则直接返回 true
                resolveRcvData(cmdRcvDataCallback, rcvData, cmd.cmdId)
                coroutineScope.launch(Dispatchers.Main) {
                    cmdResponseCallback?.onCmdResponse(ResponseStatus.Success, rcvData, 0, rcvData.size, cmd.cmdId)
                }
                return true
            }

            if (cmd.cmdId.checkCrc(rcvData)) {  //检验CRC
                 resolveRcvData(cmdRcvDataCallback, rcvData, cmd.cmdId)
                coroutineScope.launch(Dispatchers.Main) {
                    cmdResponseCallback?.onCmdResponse(ResponseStatus.Success, rcvData, 0, rcvData.size, cmd.cmdId)
                }

                return true
            }
            else {
                coroutineScope.launch(Dispatchers.Main) {
                    cmdResponseCallback?.onCmdResponse(ResponseStatus.FailCauseCrcError, ByteArray(0), -1, -1, cmd.cmdId)
                }

                return false
            }
        }
        else {
            coroutineScope.launch(Dispatchers.Main) {
                cmdResponseCallback?.onCmdResponse(ResponseStatus.FailCauseNotFromThisCmd, ByteArray(0), -1, -1, cmd.cmdId)
            }

            return false
        }
    }
    else {  //数据不符合，可能是遇到了分包，继续等待下一个数据，然后合并
        isPkgLost = true
        return isReceivedLegalData(cmd)
        /*coroutineScope.launch(Dispatchers.Main) {
            cmdResponseCallback?.onCmdResponse(ResponseStatus.FailCauseWrongFormat, ByteArray(0), -1, -1, cmd.cmdId)
        }

        return false  */
    }
}

// ……省略初始化和连接代码

// 发送数据
val bytes = hexStrToBytes("0201C110")
outputStream.write(bytes, 0, bytes.size)

// 解析数据
val recvBuffer = ByteArray(0)
inputStream.read(recvBuffer)

while (receiveBuffer.isEmpty()) {
   delay(10)
}

isReceivedLegalData()

本来打算直接发我封装好的这个驱动版的协议库的，想了想，好像不太合适，所以就大概抽出了这些不完整的代码，懂这个意思就行了，哈哈。

总结

从上面介绍的两种方式可以看出，两种方式使用各有优缺点。

使用 android-serialport-api 可以直接读取串口数据内容，不需要转USB接口，不需要驱动支持，但是需要 ROOT，适合于定制安卓主板上已经预留了 RS232 或 RS485 接口且设备已 ROOT 的情况下使用。

而使用 USB host ，可以直接读取USB接口转接的串口数据，不需要ROOT，但是只支持有驱动的串口转USB芯片，且只支持使用USB接口，不支持直接连接串口设备。

各位可以根据自己的实际情况灵活选择使用什么方式来实现串口通信。

当然，除了现在介绍的这些串口通信，其实还有一个通信协议在实际使用中用的非常多，那就是 MODBUS 协议。

下一篇文章，我们将介绍 MODBUS。

参考资料

1. android-serialport-api

2. What is tty?

3. Text-Terminal-HOWTO

4. Terminal Special Files

5. USB host

6. Android开启OTG功能/USB Host API功能

作者：equationl
来源：https://juejin.cn/post/7171347086032502792

为什么要少分几百块钱的工资，作为一个老板不诚信，谁还愿意跟你干。如果是因为效益不好，要跟员工说清楚，这个月欠发，下月一定要补上。即便是亏损，赊钱也应该是老板的，不能让员工替你亏损，你多赚钱的时候，也没发给员工。

作为员工要和老板沟通，到底什么原因少发的，如果是暂时的，以后补发，也可以理解。如果想赖账，劝你不要跟他干了。

几百块钱，对一个月薪3000—4000元的工资来讲，不是一个小数。一个农民工一个月的生活费，也就几百块钱。如果老板平时发的工资高，一个月万把，少发几百块钱也无所谓。发的工资少，又想克扣工资的老板，肯定不是好老板。

克扣员工工资，还说员工计较，拿着不是当理说。不是你留不留问题，是员工还愿意跟你干不干的问题。

从另一个角度看：

这不是员工有没有必要留下的问题，而是你自己懂不懂管理的问题。如果我是老板，肯定辞掉你，因为你根本就不配做管理者。

工资是员工的劳动所得，克扣工资就是不尊重员工的劳动成果。

劳动法明确规定，用人单位要按时足额发放工资。你现在明确承认将员工的工资少发了几百元，也就是说你的行为不仅仅严重损害了员工的合法权益，更是一种违法行为。

几百元确实不是大金额，但对于按件计酬的一线员工来说，也许要生产上千个配件；对于没有保障的保洁工来说，也许要打扫十天卫生；对于凭业绩拿奖金的销售来说，也许要成交上万元的订单…

员工付出了艰辛的劳动，劳动成果就被你无理由给克扣了，换作谁也会据理力争。凭什么啊，你为什么不会多给员工几百元的？

试想，如果你的工资是5k，老板无端克扣500，就发给你4.5k，难道你不会有情绪？如果老板不及时将工资补给你，你确信会继续干下去…

尊重员工不是一句空话，要从尊重员工的劳动成果做起！

员工闹情绪要离职，是给你的警钟。

作为管理者应该明白，员工遇事与你交流和争论，内心还是尊重你的，通过争论希望你能从公平公正的角度看问题，进而作出双赢的选择。

当争论后你仍固执己见，员工闹下小情绪是为了引起你的注意，再重新考虑。此时，管理者若不能把握解决问题的机会，员工就会对你完全失去信任，提出离职。

表面看，你好像赚到了几百元，其实你已经失去载舟之水，且终将被水颠覆。你让身边的人感到厌恶，公司形象严重受损，个人声誉一片狼藉，团队终将因你的无知而崩盘。

如果你不能及时改正错误，长此以往，你将因私自克扣员工的工资而走上不归路。少发的几百元哪去了？是终饱私囊，还是进入了小金库，这可都是违规违法的举动。

识时务者为俊杰，你应当将少发的几百元及时补发给员工，并且要深刻认识自己所犯错误的严重性。

此种情况下，即使员工离职，公司也要对员工进行经济补偿。

通常情况下，员工主动辞职，公司无需经济补偿；但是，由于你没有足额发放员工工资，且员工与你交涉后你拒绝改正。此时员工提出辞职，然后去申请仲裁，你肯定要作出经济补偿。

为了几百元，公司不仅损失了一名得力干将，还要对员工作出经济补偿，这是名副其实的得不偿失啊。

近者悦，远者来。这是管理者应该铭记的真理！

来源：maimai.cn/article/detail?fid=1741200421&efid=erVeYTis_A2HbjzYYIRU0A

宽表在BI业务中比比皆是，每次建设BI系统时首先要做的就是准备宽表。有时系统中的宽表可能会有上千个字段，经常因为“过宽”超过了数据库表字段数量限制还要再拆分。

为什么大家乐此不疲地造宽表呢？主要原因有两个。

一是为了提高查询性能。现代BI通常使用关系数据库作为后台，而SQL通常使用的HASH JOIN算法，在关联表数量和关联层级变多的时候，计算性能会急剧下降，有七八个表三四层级关联时就能观察到这个现象，而BI业务中的关联复杂度远远超过这个规模，直接使用SQL的JOIN就无法达到前端立等可取的查询需要了。为了避免关联带来的性能问题，就要先将关联消除，即将多表事先关联好采用单表存储（也就是宽表），再查询的时候就可以不用再关联，从而达到提升查询性能的目的。

二是为了降低业务难度。因为多表关联尤其是复杂关联在BI前端很难表达和使用。如果采用自动关联（根据字段类型等信息匹配）当遇到同维字段（如一个表有2个以上地区字段）时会“晕掉”不知道该关联哪个，表间循环关联或自关联的情况也无法处理；如果将众多表开放给用户来自行选择关联，由于业务用户无法理解表间关系而几乎没有可用性；分步关联可以描述复杂的关联需求，但一旦前一步出错就要推倒重来。所以，无论采用何种方式，工程实现和用户使用都很麻烦。但是基于单表来做就会简单很多，业务用户使用时没有什么障碍，因此将多表组织成宽表就成了“自然而然”的事情。

不过，凡事都有两面性，我们看到宽表好处而大量应用的同时，其缺点也不容忽视，有些缺点会对应用产生极大影响。下面来看一下。

宽表的缺点

数据冗余容量大

宽表不符合范式要求，将多个表合并成一个表会存在大量冗余数据，冗余程度跟原表数据量和表间关系有关，通常如果存在多层外键表，其冗余程度会呈指数级上升。大量数据冗余不仅会带来存储上的压力（多个表组合出来的宽表数量可能非常多）造成数据库容量问题，在查询计算时由于大量冗余数据参与运算还会影响计算性能，导致虽然用了宽表但仍然查询很慢。

数据错误

由于宽表不符合三范式要求，数据存储时可能出现一致性错误（脏写）。比如同一个销售员在不同记录中可能存储了不同的性别，同一个供应商在不同记录中的所在地可能出现矛盾。基于这样的数据做分析结果显然不对，而这种错误非常隐蔽很难被发现。

另外，如果构建的宽表不合理还会出现汇总错误。比如基于一对多的A表和B表构建宽表，如果A中有计算指标（如金额），在宽表中就会重复，基于重复的指标再汇总就会出现错误。

灵活性差

宽表本质上是一种按需建模的手段，根据业务需求来构建宽表（虽然理论上可以把所有表的组合都形成宽表，但这只存在于理论上，如果要实际操作会发现需要的存储空间大到完全无法接受的程度），这就出现了一个矛盾：BI系统建设的初衷主要是为了满足业务灵活查询的需要，即事先并不知道业务需求，有些查询是在业务开展过程中逐渐催生出来的，有些是业务用户临时起意的查询，这种灵活多变的需求采用宽表这种要事先加工的解决办法极为矛盾，想要获得宽表的好就得牺牲灵活性，可谓鱼与熊掌不可兼得。

可用性问题

除了以上问题，宽表由于字段过多还会引起可用性低的问题。一个事实表会对应多个维表，维表又有维表，而且表之间还可能存在自关联/循环关联的情况，这种结构在数据库系统中很常见，基于这些结构的表构建宽表，尤其要表达多个层级的时候，宽表字段数量会急剧增加，经常可能达到成百上千个（有的数据库表有字段数量限制，这时又要横向分表），试想一下，在用户接入界面如果出现上千个字段要怎么用？这就是宽表带来的可用性差的问题。

总体来看，宽表的坏处在很多场景中经常要大于好处，那为什么宽表还大量横行呢？

因为没办法。一直没有比宽表更好的方案来解决前面提到的查询性能和业务难度的问题。其实只要解决这两个问题，宽表就可以不用，由宽表产生的各类问题也就解决了。

SPL+DQL消灭宽表

借助开源集算器SPL可以完成这个目标。

SPL（Structured Process Language）是一个开源结构化数据计算引擎，本身提供了不依赖数据库的强大计算能力，SPL内置了很多高性能算法，尤其是对关联运算做了优化，对不同的关联场景采用不同的手段，可以大幅提升关联性能，从而不用宽表也能实时关联以满足多维分析时效性的需要。同时，SPL还提供了高性能存储，配合高效算法可以进一步发挥性能优势。

只有高性能还不够，SPL原生的计算语法不适合多维分析应用接入（生成SPL语句对BI系统改造较大）。目前大部分多维分析前端都是基于SQL开发的，但SQL体系（不用宽表时）在描述复杂关联计算上又很困难，基于这样的原因，SPL设计了专门的类SQL查询语法DQL（Dimensional Query Language）用于构建语义层。前端生成DQL语句，DQL Server将其转换成SPL语句，再基于SPL计算引擎和存储引擎完成查询返回给前端，实现全链路BI查询。需要注意的是，SPL只作为计算引擎存在，前端界面仍要由用户自行实现（或选用相应产品）。

SPL：关联实现技术

SPL如何不用宽表也能实现实时关联以满足性能要求的目标？

在BI业务中绝大部分的JOIN都是等值JOIN，也就是关联条件为等式的 JOIN。SPL把等值关联分为外键关联和主键关联。外键关联是指用一个表的非主键字段，去关联另一个表的主键，前者称为事实表，后者称为维表，两个表是多对一的关系，比如订单表和客户表。主键关联是指用一个表的主键关联另一个表的主键或部分主键，比如客户表和 VIP 客户表（一对一）、订单表和订单明细表（一对多）。

这两类 JOIN 都涉及到主键，如果充分利用这个特征采用不同的算法，就可以实现高性能的实时关联了。

不过很遗憾，SQL 对 JOIN 的定义并不涉及主键，只是两个表做笛卡尔积后再按某种条件过滤。这个定义很简单也很宽泛，几乎可以描述一切。但是，如果严格按这个定义去实现 JOIN，理论上没办法在计算时利用主键的特征来提高性能，只能是工程上做些有限的优化，在情况较复杂时（表多且层次多）经常无效。

SPL 改变了 JOIN 的定义，针对这两类 JOIN 分别处理，就可以利用主键的特征来减少运算量，从而提高计算性能。

外键关联

和SQL不同，SPL中明确地区分了维表和事实表。BI系统中的维表都通常不大，可以事先读入内存建立索引，这样在关联时可以少计算一半的HASH值。

对于多层维表（维表还有维表的情况）还可以用外键地址化的技术做好预关联。即将维表（本表）的外键字段值转换成对应维表（外键表）记录的地址。这样被关联的维表数据可以直接用地址取出而不必再进行HASH值计算和比对，多层维表仅仅是多个按地址取值的时间，和单层维表时的关联性能基本相当。

类似的，如果事实表也不大可以全部读入内存时，也可以通过预关联的方式解决事实表与维表的关联问题，提升关联效率。

预关联可以在系统启动时一次性读入并做好，以后直接使用即可。

当事实表较大无法全内存时，SPL 提供了外键序号化方法：将事实表中的外键字段值转换为维表对应记录的序号。关联计算时，用序号取出对应维表记录，这样可以获得和外键地址化类似的效果，同样能避免HASH值的计算和比对，大幅提升关联性能。

主键关联

有的事实表还有明细表，比如订单和订单明细，二者通过主键和部分主键进行关联，前者作为主表后者作为子表（还有通过全部主键关联的称为同维表，可以看做主子表的特例）。主子表都是事实表，涉及的数据量都比较大。

SPL为此采用了有序归并方法：预先将外存表按照主键有序存储，关联时顺序取出数据做归并，不需要产生临时缓存，只用很小的内存就可以完成计算。而SQL采用的HASH分堆算法复杂度较高，不仅要计算HASH值进行对比，还会产生临时缓存的读写动作，运算性能很差。

HASH 分堆技术实现并行困难，多线程要同时向某个分堆缓存数据，造成共享资源冲突；某个分堆关联时又会消费大量内存，无法实施较大的并行数量。而有序归则易于分段并行。数据有序时，子表就可以根据主表键值进行同步对齐分段以保证正确性，无需缓存，且因为占用内存很少可以采用较大的并行数，从而获得更高性能。

预先排序的成本虽高，但是一次性做好即可，以后就总能使用归并算法实现 JOIN，性能可以提高很多。同时，SPL 也提供了在有追加数据时仍然保持数据整体有序的方案。

对于主子表关联SPL还可以采用更有效的存储形式将主子表一体化存储，子表作为主表的集合字段，其取值是由与该主表数据相关的多条子表记录构成。这相当于预先实现了关联，再计算时直接取数计算即可，不需要比对，存储量也更少，性能更高。

存储机制

高性能离不开有效的存储。SPL也提供了列式存储，在BI计算中可以大幅降低数据读取量以提升读取效率。SPL列存采用了独有的倍增分段技术，相对传统列存分块并行方案要在很大数据量时（否则并行会受到限制）才会发挥优势不同，这个技术可以使SPL列存在数据量不很大时也能获得良好的并行分段效果，充分发挥并行优势。

SPL还提供了针对数据类型的优化机制，可以显著提升多维分析中的切片运算性能。比如将枚举型维度转换成整数，在查询时将切片条件转换成布尔值构成的对位序列，在比较时就可以直接从序列指定位置取出切片判断结果。还有将多个标签维度（取值是或否的维度，这种维度在多维分析中大量存在）存储在一个整数字段中的标签位维度技术（一个整数字段可以存储16个标签），不仅大幅减少存储量，在计算时还可以针对多个标签同时做按位计算从而大幅提升计算性能。

有了这些高效机制以后，我们就可以在BI分析中不再使用宽表，转而基于SPL存储和算法做实时关联，性能比宽表还更高（没有冗余数据读取量更小，更快）。

不过，只有这些还不够，SPL原生语法还不适合BI前端直接访问，这就需要适合的语义转换技术，通过适合的方式将用户操作转换成SPL语法进行查询。

这就需要DQL了。

DQL：关联描述技术

DQL是SPL之上的语义层构建工具，在这一层完成对于SPL数据关联关系的描述（建模）再为上层应用服务。即将SPL存储映射成DQL表，再基于表来描述数据关联关系。

通过对数据表关系描述以后形成了一种以维度为中心的总线式结构（不同于E-R图中的网状结构），中间是维度，表与表之间不直接相关都通过维度过渡。

基于这种结构下的关联查询（DQL语句）会很好表达。比如要根据订单表（orders）、客户表（customer）、销售员表（employee）以及城市表（city）查询：本年度华东的销售人员，在全国各销售区的销售额。

用SQL写起来是这样的：

SEL ECT
 ct1.area,o.emp_id,sum(o.amount) somt
FROM
 orders o
 JOIN customer c ON o.cus_id = c.cus_id
 JOIN city ct1 ON c.city_id = ct1.city_id
 JOIN employee e ON o.emp_id = e.emp_id
 JOIN city ct2 ON e.city_id = ct2.city_id
WHERE
 ct2.area = 'east' AND year(o.order_date)= 2022
GRO UP BY
 ct1.area,  o.emp_id

多个表关联要JOIN多次，同一个地区表要反复关联两次才能查到销售员和客户的所在区域，对于这种情况BI前端表达起来会很吃力，如果将关联开放出来，用户又很难理解。

那么DQL是怎么处理的呢？

DQL写法：

SEL ECT
 cus_id.city_id.area,emp_id,sum(amount) somt
FROM
 orders
WHERE
 emp_id.city_id.area == "east" AND year(order_date)== 2022
BY
 cus_id.city_id.area,emp_id

DQL不需要JOIN多个表，只基于orders单表查询就可以了，外键指向表的字段当成属性直接使用，有多少层都可以引用下去，很好表达。像查询客户所在地区通过cus_id.city_id.area一直写下去就可以了，这样就消除了关联，将多表关联查询转化成单表查询。

更进一步，我们再基于DQL开发BI前端界面就很容易，比如可以做成这样：

用树结构分多级表达多层维表关联，这样的多维分析页面不仅容易开发，普通业务用户使用时也很容易理解，这就是DQL的效力。

总结一下，宽表的目的是为了解决BI查询性能和前端工程实现问题，而宽表会带来数据冗余和灵活性差等问题。通过SPL的实时关联技术与高效存储可以解决性能问题，而且性能比宽表更高，同时不存在数据冗余，存储空间也更小（压缩）；DQL构建的语义层解决了多维分析前端工程的实现问题，让实时关联成为可能，，灵活性更高（不再局限于宽表的按需建模），界面也更容易实现，应用范围更广。

SPL+DQL继承（超越）宽表的优点同时改善其缺点，这才是BI该有的样子。

SPL资料

• SPL下载

• SPL源代码

作者：Java中文社群
来源：juejin.cn/post/7200033099752554553

koin 为 Android 提供了简单易用的 API 接口，让你简单轻松地接入 koin 框架。

[koin 在 Android 中的 gradle 配置]

mp.weixin.qq.com/s/bscC7mO4O…

1.Application 类中 startKoin

从您的类中，您可以使用该函数并注入 Android 上下文，如下所示：

Application startKoin androidContext
class MainApplication : Application() {

    override fun onCreate() {
        super.onCreate()

        startKoin {
            // Log Koin into Android logger
            androidLogger()
            // Reference Android context
            androidContext(this@MainApplication)
            // Load modules
            modules(myAppModules)
        }

    }
}

如果您需要从另一个 Android 类启动 Koin，您可以使用该函数为您的 Android 实例提供如下：startKoin Context

startKoin {
    //inject Android context
    androidContext(/* your android context */)
    // ...
}

2. 额外配置

从您的 Koin 配置（在块代码中），您还可以配置 Koin 的多个部分。startKoin { }

2.1 Koin Logging for Android

koin 提供了 log 的 Android 实现。

startKoin {
    // use Android logger - Level.INFO by default
    androidLogger()
    // ...
}

2.2 加载属性

您可以在文件中使用 Koin 属性来存储键/值：assets/koin.properties

startKoin {
    // ...
    // use properties from assets/koin.properties
    androidFileProperties()

}

3. Android 中注入对象实例

3.1 为 Android 类做准备

koin 提供了KoinComponents 扩展，Android 组件都具有这种扩展，这些组件包括 Activity Fragment Service ComponentCallbacks

您可以通过如下方式访问 Kotlin 扩展：

by inject()- 来自 Koin 容器的延迟计算实例

get() - 从 Koin 容器中获取实例

我们可以将一个属性声明为惰性注入：

module {
    // definition of Presenter
    factory { Presenter() }
}
class DetailActivity : AppCompatActivity() {

    // Lazy inject Presenter
    override val presenter : Presenter by inject()

    override fun onCreate(savedInstanceState: Bundle?) {
        //...
    }
}

或者我们可以直接得到一个实例：

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    // Retrieve a Presenter instance
    val presenter : Presenter = get()
}

注意：如果你的类没有扩展，只需添加 KoinComponent 接口，如果你需要或来自另一个类的实例。inject() get()

3.2 Android Context 使用

class MainApplication : Application() {

    override fun onCreate() {
        super.onCreate()

        startKoin {
            //inject Android context
            androidContext(this@MainApplication)
            // ...
        }

    }
}

在你的定义中，下面的函数允许你在 Koin 模块中获取实例，以帮助你简单地编写需要实例的表达式。androidContext() androidApplication() Context Application

val appModule = module {

    // create a Presenter instance with injection of R.string.mystring resources from Android
    factory {
        MyPresenter(androidContext().resources.getString(R.string.mystring))
    }
}

4. 用于 Android 的 DSL 构造函数

4.1 DSL 构造函数

Koin 现在提供了一种新的 DSL 关键字，允许您直接面向类构造函数，并避免在 lambda 表达式中键入您的定义。

对于 Android，这意味着以下新的构造函数 DSL 关键字：

viewModelOf()`- 相当于`viewModel { }

fragmentOf()`- 相当于`fragment { }

workerOf()`- 相当于`worker { }

注意：请务必在类名之前使用，以定位类构造函数::

4.2 Android DSL 函数示例

给定一个具有以下组件的 Android 应用程序：

// A simple service

class SimpleServiceImpl() : SimpleService



// a Presenter, using SimpleService and can receive "id" injected param

class FactoryPresenter(val id: String, val service: SimpleService)



// a ViewModel that can receive "id" injected param, use SimpleService and get SavedStateHandle

class SimpleViewModel(val id: String, val service: SimpleService, val handle: SavedStateHandle) : ViewModel()



// a scoped Session, that can received link to the MyActivity (from scope)

class Session(val activity: MyActivity)



// a Worker, using SimpleService and getting Context & WorkerParameters

class SimpleWorker(

    private val simpleService: SimpleService,

    appContext: Context,

    private val params: WorkerParameters

) : CoroutineWorker(appContext, params)

我们可以这样声明它们：

module {

    singleOf(::SimpleServiceImpl){ bind<SimpleService>() }



    factoryOf(::FactoryPresenter)



    viewModelOf(::SimpleViewModel)



    scope<MyActivity>(){

        scopedOf(::Session)

    }



    workerOf(::SimpleWorker)

}

5. Android 中的 koin 多模块使用

通过使用 Koin，您可以描述模块中的定义。在本节中，我们将了解如何声明，组织和链接模块。

5.1 koin 多模块

组件不必位于同一模块中。模块是帮助您组织定义的逻辑空间，并且可以依赖于其他定义 模块。定义是惰性的，然后仅在组件请求它时才解析。

让我们举个例子，链接的组件位于单独的模块中：

// ComponentB <- ComponentA

class ComponentA()

class ComponentB(val componentA : ComponentA)



val moduleA = module {

    // Singleton ComponentA

    single { ComponentA() }

}



val moduleB = module {

    // Singleton ComponentB with linked instance ComponentA

    single { ComponentB(get()) }

}

我们只需要在启动 Koin 容器时声明已使用模块的列表：

class MainApplication : Application() {



    override fun onCreate() {

        super.onCreate()



        startKoin {

            // ...



            // Load modules

            modules(moduleA, moduleB)

        }



    }

}

5.2 模块包含

类中提供了一个新函数，它允许您通过以有组织和结构化的方式包含其他模块来组合模块includes() Module

新模块有 2 个突出特点：

将大型模块拆分为更小、更集中的模块。

在模块化项目中，它允许您更精细地控制模块可见性（请参阅下面的示例）。

它是如何工作的？让我们采用一些模块，我们将模块包含在：parentModule

// `:feature` module

val childModule1 = module {

    /* Other definitions here. */

}

val childModule2 = module {

    /* Other definitions here. */

}

val parentModule = module {

    includes(childModule1, childModule2)

}



// `:app` module

startKoin { modules(parentModule) }

请注意，我们不需要显式设置所有模块：通过包含，声明的所有模块将自动加载。

parentModule includes childModule1 childModule2 parentModule childModule1 childModule2

信息：模块加载现在经过优化，可以展平所有模块图，并避免重复的模块定义。

最后，您可以包含多个嵌套或重复的模块，Koin 将扁平化所有包含的模块，删除重复项：

// :feature module

val dataModule = module {

    /* Other definitions here. */

}

val domainModule = module {

    /* Other definitions here. */

}

val featureModule1 = module {

    includes(domainModule, dataModule)

}

val featureModule2 = module {

    includes(domainModule, dataModule)

}

// :app module

class MainApplication : Application() {



    override fun onCreate() {

        super.onCreate()



        startKoin {

            // ...



            // Load modules

             modules(featureModule1, featureModule2)

        }



    }

}

请注意，所有模块将只包含一次：dataModule domainModule featureModule1 featureModule2

5.3 Android ViewModel 和 Navigation

Gradle 模块引入了一个新的 DSL 关键字，该关键字作为补充，以帮助声明 ViewModel 组件并将其绑定到 Android 组件生命周期。关键字也可用允许您使用其构造函数声明 ViewModel。koin-android viewModel singlefactory viewModelOf

val appModule = module {



    // ViewModel for Detail View

    viewModel { DetailViewModel(get(), get()) }



    // or directly with constructor

    viewModelOf(::DetailViewModel)

}

声明的组件必须至少扩展类。您可以指定如何注入类的构造函数 并使用该函数注入依赖项。android.arch.lifecycle.ViewModel get()

注意：关键字有助于声明 ViewModel 的工厂实例。此实例将由内部 ViewModelFactory 处理，并在需要时重新附加 ViewModel 实例。它还将允许注入参数。viewModel viewModelOf

5.4 注入 ViewModel

在 Android 组件中使用 viewModel ，Activity Fragment Service

by viewModel()- 惰性委托属性，用于将视图模型注入到属性中

getViewModel()- 直接获取视图模型实例

class DetailActivity : AppCompatActivity() {



    // Lazy inject ViewModel

    val detailViewModel: DetailViewModel by viewModel()

}

5.5 Activity 共享 ViewModel

一个 ViewModel 实例可以在 Fragment 及其主 Activity 之间共享。

要在使用中注入共享视图模型，请执行以下操作：Fragment

by activityViewModel()- 惰性委托属性，用于将共享 viewModel 实例注入到属性中

get ActivityViewModel()- 直接获取共享 viewModel 实例

只需声明一次视图模型：

val weatherAppModule = module {



    // WeatherViewModel declaration for Weather View components

    viewModel { WeatherViewModel(get(), get()) }

}

注意：viewModel 的限定符将作为 viewModel 的标记处理

并在 Activity 和 Fragment 中重复使用它：

class WeatherActivity : AppCompatActivity() {



    /*

     * Declare WeatherViewModel with Koin and allow constructor dependency injection

     */

    private val weatherViewModel by viewModel<WeatherViewModel>()

}



class WeatherHeaderFragment : Fragment() {



    /*

     * Declare shared WeatherViewModel with WeatherActivity

     */

    private val weatherViewModel by activityViewModel<WeatherViewModel>()

}



class WeatherListFragment : Fragment() {



    /*

     * Declare shared WeatherViewModel with WeatherActivity

     */

    private val weatherViewModel by activityViewModel<WeatherViewModel>()

}

5.6 将参数传递给构造函数

向 viewModel 传入参数，示例代码如下：

模块中

val appModule = module {



    // ViewModel for Detail View with id as parameter injection

    viewModel { parameters -> DetailViewModel(id = parameters.get(), get(), get()) }

    // ViewModel for Detail View with id as parameter injection, resolved from graph

    viewModel { DetailViewModel(get(), get(), get()) }

    // or Constructor DSL

    viewModelOf(::DetailViewModel)

}

依赖注入点传入参数

class DetailActivity : AppCompatActivity() {



    val id : String // id of the view



    // Lazy inject ViewModel with id parameter

    val detailViewModel: DetailViewModel by viewModel{ parametersOf(id)}

}

5.7 SavedStateHandle 注入

添加键入到构造函数的新属性以处理 ViewModel 状态：SavedStateHandle

class MyStateVM(val handle: SavedStateHandle, val myService : MyService) : ViewModel() 在 Koin 模块中，只需使用或参数解析它：get()

viewModel { MyStateVM(get(), get()) } 或使用构造函数 DSL：

viewModelOf(::MyStateVM) 在 Activity Fragment

by viewModel()- 惰性委托属性，用于将状态视图模型实例注入属性

getViewModel()- 直接获取状态视图模型实例

class DetailActivity : AppCompatActivity() {



    // MyStateVM viewModel injected with SavedStateHandle

    val myStateVM: MyStateVM by viewModel()

}

5.8 Navigation 导航图中的 viewModel

您可以将 ViewModel 实例的范围限定为导航图。只需要传入 ID 给by koinNavGraphViewModel()

class NavFragment : Fragment() {



    val mainViewModel: NavViewModel by koinNavGraphViewModel(R.id.my_graph)



}

5.9 viewModel 通用 API

Koin 提供了一些“底层”API 来直接调整您的 ViewModel 实例。viewModelForClass ComponentActivity Fragment

ComponentActivity.viewModelForClass(

    clazz: KClass<T>,

    qualifier: Qualifier? = null,

    owner: ViewModelStoreOwner = this,

    state: BundleDefinition? = null,

    key: String? = null,

    parameters: ParametersDefinition? = null,

): Lazy<T>

还提供了顶级函数：

fun <T : ViewModel> getLazyViewModelForClass(

    clazz: KClass<T>,

    owner: ViewModelStoreOwner,

    scope: Scope = GlobalContext.get().scopeRegistry.rootScope,

    qualifier: Qualifier? = null,

    state: BundleDefinition? = null,

    key: String? = null,

    parameters: ParametersDefinition? = null,

): Lazy<T>

5.10 ViewModel API - Java Compat

必须将 Java 兼容性添加到依赖项中：

// Java Compatibility

implementation "io.insert-koin:koin-android-compat:$koin_version"

您可以使用以下函数或静态函数将 ViewModel 实例注入到 Java 代码库中：viewModel() getViewModel() ViewModelCompat



@JvmOverloads

@JvmStatic

@MainThread

fun <T : ViewModel> getViewModel(

    owner: ViewModelStoreOwner,

    clazz: Class<T>,

    qualifier: Qualifier? = null,

    parameters: ParametersDefinition? = null

)

6. 在 Jetpack Compose 中注入

请先了解 Jetpack Compose 相关内容：

developer.android.com/jetpack/com…

6.1 注入@Composable

在编写可组合函数时，您可以访问以下 Koin API：

get()- 从 Koin 容器中获取实例

getKoin()- 获取当前 Koin 实例

对于声明“MyService”组件的模块：

val androidModule = module {



    single { MyService() }

}

我们可以像这样获取您的实例：

@Composable

fun App() {

    val myService = get<MyService>()

}

注意：为了在 Jetpack Compose 的功能方面保持一致，最好的编写方法是将实例直接注入到函数属性中。这种方式允许使用 Koin 进行默认实现，但保持开放状态以根据需要注入实例。

@Composable

fun App(myService: MyService = get()) {

}

6.2 viewModel @Composable

与访问经典单/工厂实例的方式相同，您可以访问以下 Koin ViewModel API：

getViewModel()`或 - 获取实例`koinViewModel()

对于声明“MyViewModel”组件的模块：

module {

    viewModel { MyViewModel() }

    // or constructor DSL

    viewModelOf(::MyViewModel)

}

我们可以像这样获取您的实例：

@Composable

fun App() {

    val vm = koinViewModel<MyViewModel>()

}

我们可以在函数参数中获取您的实例：

@Composable

fun App(vm : MyViewModel = koinViewModel()) {



}

7. 管理 Android 作用域

Android 组件，如Activity、Fragment、Service都有生命周期，这些组件都是由 System 实例化，组件中有相应的生命周期回调。

正因为 Android 组件具有生命周期属性，所以不能在 koin 中传入组件实例。按照生命周期长短，组件可分为三类：

• • 长周期组件(Service、database)——由多个屏幕使用，永不丢弃

• • 中等周期组件(User session)——由多个屏幕使用，必须在一段时间后删除

• • 短周期组件(ViewModel) ——仅由一个 Screen 使用，必须在 Screen 末尾删除

对于长周期组件，我们通常在应用全局使用 single 创建单实例

在 MVP 架构模式下，Presenter 是短周期组件

在 Activity 中创建方式如下

class DetailActivity : AppCompatActivity() {



    // injected Presenter

    override val presenter : Presenter by inject()

我们也可以在 module 中创建

我们使用 factory 作用域创建 Presenter 实例

val androidModule = module {



    // Factory instance of Presenter

    factory { Presenter() }

}

生成绑定到作用域的实例 scope

val androidModule = module {



    scope<DetailActivity> {

        scoped { Presenter() }

    }

}

大多数 Android 内存泄漏来自从非 Android 组件引用 UI/Android 组件。系统保留引用在它上面，不能通过垃圾收集完全回收它。

7.1 申明 Android 作用域

要限定 Android 组件上的依赖关系，您必须使用如下所示的块声明一个作用域：scope

class MyPresenter()

class MyAdapter(val presenter : MyPresenter)



module {

  // Declare scope for MyActivity

  scope<MyActivity> {

    // get MyPresenter instance from current scope

    scoped { MyAdapter(get()) }

    scoped { MyPresenter() }

  }

}

7.2 Android Scope 类

Koin 提供了 Android 生命周期组件相关的 Scope 类ScopeActivity Retained ScopeActivity ScopeFragment

class MyActivity : ScopeActivity() {



    // MyPresenter is resolved from MyActivity's scope

    val presenter : MyPresenter by inject()

}

Android Scope 需要与接口一起使用来实现这样的字段：AndroidScopeComponent scope

abstract class ScopeActivity(

    @LayoutRes contentLayoutId: Int = 0,

) : AppCompatActivity(contentLayoutId), AndroidScopeComponent {



    override val scope: Scope by activityScope()



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)



        checkNotNull(scope)

    }

}

我们需要使用接口并实现属性。这将设置类使用的默认 Scope。AndroidScopeComponent scope

7.3 Android Scope 接口

要创建绑定到 Android 组件的 Koin 作用域，只需使用以下函数：

createActivityScope()- 为当前 Activity 创建 Scope（必须声明 Scope 部分）

createActivityRetainedScope()- 为当前 Activity 创建 RetainedScope（由 ViewModel Lifecycle 支持）（必须声明 Scope 部分）

createFragmentScope()- 为当前 Fragment 创建 Scope 并链接到父 Activity Scope 这些函数可作为委托使用，以实现不同类型的作用域：

activityScope()- 为当前 Activity 创建 Scope（必须声明 Scope 部分）

activityRetainedScope()- 为当前 Activity 创建 RetainedScope（由 ViewModel Lifecycle 支持）（必须声明 Scope 部分）

fragmentScope()- 为当前 Fragment 创建 Scope 并链接到父 Activity Scope

class MyActivity() : AppCompatActivity(contentLayoutId), AndroidScopeComponent {



    override val scope: Scope by activityScope()



}

我们还可以使用以下内容设置保留范围（由 ViewModel 生命周期提供支持）：

class MyActivity() : AppCompatActivity(contentLayoutId), AndroidScopeComponent {



    override val scope: Scope by activityRetainedScope()

}

如果您不想使用 Android Scope 类，则可以使用自己的类并使用 Scope 创建 API AndroidScopeComponent

7.4 Scope 链接

Scope 链接允许在具有自定义作用域的组件之间共享实例。在更广泛的用法中，您可以跨组件使用实例。例如，如果我们需要共享一个实例。Scope UserSession

首先声明一个范围定义：

module {

    // Shared user session data

    scope(named("session")) {

        scoped { UserSession() }

    }

}

当需要开始使用实例时，请为其创建范围：UserSession

val ourSession = getKoin().createScope("ourSession",named("session"))



// link ourSession scope to current `scope`, from ScopeActivity or ScopeFragment

scope.linkTo(ourSession)

然后在您需要的任何地方使用它：

class MyActivity1 : ScopeActivity() {



    fun reuseSession(){

        val ourSession = getKoin().createScope("ourSession",named("session"))



        // link ourSession scope to current `scope`, from ScopeActivity or ScopeFragment

        scope.linkTo(ourSession)



        // will look at MyActivity1's Scope + ourSession scope to resolve

        val userSession = get<UserSession>()

    }

}

class MyActivity2 : ScopeActivity() {



    fun reuseSession(){

        val ourSession = getKoin().createScope("ourSession",named("session"))



        // link ourSession scope to current `scope`, from ScopeActivity or ScopeFragment

        scope.linkTo(ourSession)



        // will look at MyActivity2's Scope + ourSession scope to resolve

        val userSession = get<UserSession>()

    }

}

8.Fragment Factory

由于 AndroidX 已经发布了软件包系列以扩展 Android 的功能 androidx.fragment Fragment

developer.android.com/jetpack/and…

8.1 Fragment Factory

自版本以来，已经引入了 ，一个专门用于创建类实例的类：2.1.0-alpha-3 FragmentFactory Fragment

developer.android.com/reference/k…

Koin 也提供了创建 Fragment 的工厂类 KoinFragmentFactory Fragment

8.2 设置 Fragment Factory

首先，在 KoinApplication 声明中，使用关键字设置默认实例：fragmentFactory() KoinFragmentFactory

 startKoin {

    // setup a KoinFragmentFactory instance

    fragmentFactory()



    modules(...)

}

8.3 声明并注入 Fragment

声明一个 Fragment 并在 module 中注入

class MyFragment(val myService: MyService) : Fragment() {





}

val appModule = module {

    single { MyService() }

    fragment { MyFragment(get()) }

}

8.4 获取 Fragment

使用setupKoinFragmentFactory() 设置 FragmentFactory

查询您的 Fragment ，使用supportFragmentManager

supportFragmentManager.beginTransaction()

            .replace<MyFragment>(R.id.mvvm_frame)

            .commit()

加入可选参数

supportFragmentManager.beginTransaction()

            .replace<MyFragment>(

                containerViewId = R.id.mvvm_frame,

                args = MyBundle(),

                tag = MyString()

            )

8.5 Fragment Factory & Koin Scopes

如果你想使用 Koin Activity Scope，你必须在你的 Scope 声明你的 Fragment 作为一个定义：scoped

val appModule = module {

    scope<MyActivity> {

        fragment { MyFragment(get()) }

    }

}

并使用您的 Scope 设置您的 Koin Fragment Factory：setupKoinFragmentFactory(lifecycleScope)

class MyActivity : AppCompatActivity() {



    override fun onCreate(savedInstanceState: Bundle?) {

        // Koin Fragment Factory

        setupKoinFragmentFactory(lifecycleScope)



        super.onCreate(savedInstanceState)

        //...

    }

}

9. WorkManager 的 Koin 注入

koin 为 WorkManager 提供单独的组件包 koin-androidx-workmanager

首先，在 KoinApplication 声明中，使用关键字来设置自定义 WorkManager 实例：workManagerFactory()

class MainApplication : Application(), KoinComponent {



    override fun onCreate() {

        super.onCreate()

        startKoin {

            // setup a WorkManager instance

            workManagerFactory()

            modules(...)

        }

        setupWorkManagerFactory()

}

AndroidManifest.xml 修改，避免使用默认的

    <application . . .>

        . . .

        <provider

            android:name="androidx.work.impl.WorkManagerInitializer"

            android:authorities="${applicationId}.workmanager-init"

            tools:node="remove" />

  </application>

9.1 声明 ListenableWorker

val appModule = module {

single { MyService() }

worker { MyListenableWorker(get()) }

}

9.2 创建额外的 WorkManagerFactory

class MainApplication : Application(), KoinComponent {



    override fun onCreate() {

        super.onCreate()



        startKoin {

           workManagerFactory(workFactory1, workFactory2)

           . . .

        }



        setupWorkManagerFactory()

    }



}

如果 Koin 和 workFactory1 提供的 WorkManagerFactory 都可以实例化 ListenableWorker，则 Koin 提供的工厂将是使用的工厂。

9.3 更改 koin lib 本身的清单

如果 koin-androidx-workmanager 中的默认 Factory 被禁用，而应用程序开发人员不初始化 koin 的工作管理器基础架构，他最终将没有可用的工作管理器工厂。

针对上面的情况，我们做如下 DSL 改进：

val workerFactoryModule = module {

factory<WorkFactory> { WorkFactory1() }

factory<WorkFactory> { WorkFactory2() }

}

然后让 koin 内部做类似的事情

fun Application.setupWorkManagerFactory(

// no vararg for WorkerFactory

) {

. . .

getKoin().getAll<WorkerFactory>()

.forEach {

delegatingWorkerFactory.addFactory(it)

}

}

参考链接

insert-koin.io/

作者：Calvin873
来源：juejin.cn/post/7189917106580750395

前言

软件研发工程师俗称程序员经常对业界外的人自谦作码农，一来给自己不菲的收入找个不错的说辞（像农民伯伯那样辛勤耕耘挣来的血汗钱），二来也是自嘲这个行业确实辛苦，辛苦得没时间捯饬，甚至没有驼背、脱发加持都说不过去。不过时间久了，行外人还真就相信了程序员就是一帮没品味，木讷的low货，大部分的文艺作品中也都是这么表现程序员的。可是我今天要说一下我的感受，编程是个艺术活，程序员是最聪明的一群人，我们的品味也可以像艺术家一样。

言归正转，你是不是以为我今天要教你穿搭？不不不，这依然是一篇技术文章，想学穿搭女士学陈舒婷（《狂飙》中的大嫂），男士找陈舒婷那样的女朋友就好了。笔者今天教你怎样有“品味”的写代码。

以下几点可提升“品味”

说明：以下是笔者的经验之谈具有部分主观性，不赞同的欢迎拍砖，要想体系化提升编码功底建议读《XX公司Java编码规范》、《Effective Java》、《代码整洁之道》。以下几点部分具有通用性，部分仅限于java语言，其它语言的同学绕过即可。

优雅防重

关于成体系的防重讲解，笔者之后打算写一篇文章介绍，今天只讲一种优雅的方式：

如果你的业务场景满足以下两个条件：

1 业务接口重复调用的概率不是很高

2 入参有明确业务主键如：订单ID，商品ID，文章ID，运单ID等

在这种场景下，非常适合乐观防重，思路就是代码处理不主动做防重，只在监测到重复提交后做相应处理。

如何监测到重复提交呢？MySQL唯一索引 + org.springframework.dao.DuplicateKeyException

代码如下：

public int createContent(ContentOverviewEntity contentEntity) {
    try{
        return contentOverviewRepository.createContent(contentEntity);
    }catch (DuplicateKeyException dke){
        log.warn("repeat content:{}",contentEntity.toString());
    }
    return 0;
}

用好lambda表达式

lambda表达式已经是一个老生常谈的话题了，笔者认为，初级程序员向中级进阶的必经之路就是攻克lambda表达式，lambda表达式和面向对象编程是两个编程理念，《架构整洁之道》里曾提到有三种编程范式，结构化编程（面向过程编程）、面向对象编程、函数式编程。初次接触lambda表达式肯定特别不适应，但如果熟悉以后你将打开一个编程方式的新思路。本文不讲lambda，只讲如下例子：

比如你想把一个二维表数据进行分组，可采用以下一行代码实现

List<ActionAggregation> actAggs = ....
Map<String, List<ActionAggregation>> collect = 
    actAggs.stream()
    .collect(Collectors.groupingBy(ActionAggregation :: containWoNosStr,LinkedHashMap::new,Collectors.toList()));

用好卫语句

各个大场的JAVA编程规范里基本都有这条建议，但我见过的代码里，把它用好的不多，卫语句对提升代码的可维护性有着很大的作用，想像一下，在一个10层if 缩进的接口里找代码逻辑是一件多么痛苦的事情，有人说，哪有10层的缩进啊，别说，笔者还真的在一个微服务里的一个核心接口看到了这种代码，该接口被过多的人接手导致了这样的局面。系统接手人过多以后，代码腐化的速度超出你的想像。

下面举例说明：

没有用卫语句的代码，很多层缩进

if (title.equals(newTitle)){
    if (...) {
        if (...) {
            if (...) {

            }
        }else{
            
        }
    }else{
        
    }
}

使用了卫语句的代码，缩进很少

if (!title.equals(newTitle)) {
    return xxx;
}
if (...) {
    return xxx;
}else{
    return yyy;
}
if (...) {
    return zzz;
}

避免双重循环

简单说双重循环会将代码逻辑的时间复杂度扩大至O(n^2)

如果有按key匹配两个列表的场景建议使用以下方式：

1 将列表1 进行map化

2 循环列表2，从map中获取值

代码示例如下：

List<WorkOrderChain> allPre = ...
List<WorkOrderChain> chains = ...
Map<String, WorkOrderChain> preMap = allPre.stream().collect(Collectors.toMap(WorkOrderChain::getWoNext, item -> item,(v1, v2)->v1));
chains.forEach(item->{
    WorkOrderChain preWo = preMap.get(item.getWoNo());
    if (preWo!=null){
        item.setIsHead(1);
    }else{
        item.setIsHead(0);
    }
});

用@see @link来设计RPC的API

程序员们还经常自嘲的几个词有：API工程师，中间件装配工等，既然咱平时写API写的比较多，那种就把它写到极致@see @link的作用是让使用方可以方便的链接到枚举类型的对象上，方便阅读

示例如下：

@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class ContentProcessDto implements Serializable {
    /**
     * 内容ID
     */
    private String contentId;
    /**
     * @see com.jd.jr.community.common.enums.ContentTypeEnum
     */
    private Integer contentType;
    /**
     * @see com.jd.jr.community.common.enums.ContentQualityGradeEnum
     */
    private Integer qualityGrade;
}

日志打印避免只打整个参数

研发经常为了省事，直接将入参这样打印

log.info("operateRelationParam:{}", JSONObject.toJSONString(request));

该日志进了日志系统后，研发在搜索日志的时候，很难根据业务主键排查问题

如果改进成以下方式，便可方便的进行日志搜索

log.info("operateRelationParam，id:{},req:{}", request.getId(),JSONObject.toJSONString(request));

如上：只需要全词匹配“operateRelationParam，id:111”，即可找到业务主键111的业务日志。

用异常捕获替代方法参数传递

我们经常面对的一种情况是：从子方法中获取返回的值来标识程序接下来的走向，这种方式笔者认为不够优雅。

举例：以下代码paramCheck和deleteContent方法，返回了这两个方法的执行结果，调用方通过返回结果判断程序走向

public RpcResult<String> deleteContent(ContentOptDto contentOptDto) {

    log.info("deleteContentParam:{}", contentOptDto.toString());

    try{

        RpcResult<?> paramCheckRet = this.paramCheck(contentOptDto);

        if (paramCheckRet.isSgmFail()){

            return RpcResult.getSgmFail("非法参数："+paramCheckRet.getMsg());

        }

        ContentOverviewEntity contentEntity = DozerMapperUtil.map(contentOptDto,ContentOverviewEntity.class);

        RpcResult<?> delRet = contentEventHandleAbility.deleteContent(contentEntity);

        if (delRet.isSgmFail()){

            return RpcResult.getSgmFail("业务处理异常："+delRet.getMsg());

        }

    }catch (Exception e){

        log.error("deleteContent exception:",e);

        return RpcResult.getSgmFail("内部处理错误");

    }

    return RpcResult.getSgmSuccess();

}

我们可以通过自定义异常的方式解决：子方法抛出不同的异常，调用方catch不同异常以便进行不同逻辑的处理，这样调用方特别清爽，不必做返回结果判断

代码示例如下：

public RpcResult<String> deleteContent(ContentOptDto contentOptDto) {

	log.info("deleteContentParam:{}", contentOptDto.toString());

	try{

	    this.paramCheck(contentOptDto);

		ContentOverviewEntity contentEntity = DozerMapperUtil.map(contentOptDto,ContentOverviewEntity.class);

		contentEventHandleAbility.deleteContent(contentEntity);		

	}catch(IllegalStateException pe){

		log.error("deleteContentParam error:"+pe.getMessage(),pe);

		return RpcResult.getSgmFail("非法参数："+pe.getMessage());

	}catch(BusinessException be){

		log.error("deleteContentBusiness error:"+be.getMessage(),be);

		return RpcResult.getSgmFail("业务处理异常："+be.getMessage());

	}catch (Exception e){

		log.error("deleteContent exception:",e);

		return RpcResult.getSgmFail("内部处理错误");

	}

	return RpcResult.getSgmSuccess();

}

自定义SpringBoot的Banner

别再让你的Spring Boot启动banner千篇一律，spring 支持自定义banner，该技能对业务功能实现没任何卵用，但会给枯燥的编程生活添加一点乐趣。

以下是官方文档的说明： docs.spring.io/spring-boot…

另外你还需要ASCII艺术字生成工具： tools.kalvinbg.cn/txt/ascii

效果如下：

   _ _                   _                     _                 _       

  (_|_)_ __   __ _    __| | ___  _ __   __ _  | |__   ___   ___ | |_ ___ 

  | | | '_ \ / _` |  / _` |/ _ \| '_ \ / _` | | '_ \ / _ \ / _ \| __/ __|

  | | | | | | (_| | | (_| | (_) | | | | (_| | | |_) | (_) | (_) | |_\__ \

 _/ |_|_| |_|\__, |  \__,_|\___/|_| |_|\__, | |_.__/ \___/ \___/ \__|___/

|__/         |___/                     |___/                             

多用Java语法糖