一位程序员最近非常生气，因为他喜欢上一位美团的妹子，却被妹子骗去写代码做苦力，成了妥妥的工具人。

该程序员一怒之下，把妹子和自己的聊天记录曝光了出来:

另外，搜索公众号后端架构师后台回复“架构整洁”，获取一份惊喜礼包。

楼主说，自己已经在美团官网举报了，该女生就等待阳光职场通报吧。其实这几个月早就发现她有很多不对劲的地方，但希望她能良心发现，跟自己坦诚一下，然而并没有。

有人评价，这就是传说中的职场妲己？

有人嘲笑楼主被女生当成了工具人。

有人说，这种人不是一个，只是有的靠外面的备胎养，有的压榨下面的人。美团管理层很狂妄傲慢，一直坚持pua。

有人说，这种数据表严禁外露，这个女生可能有阳光职场的风险，估计要被开除了。

也有人说，这是私德问题，公司不管。看开点，愿意帮就帮，不愿意就算了。

有人说，工作是工作，感情是感情，楼主可以帮一部分，但不能帮全部。

还有人说，这就是一个舔狗舔而不得的故事，楼主追不到女生就恼羞成怒了，明显表白不成想报复，还用掐头去尾的聊天记录。其实帮她之前就该知道，帮不帮都不能影响她和自己的关系。

站在楼主的角度，我们完全能理解他为什么这么生气。在他的复杂情绪里，既有没追上妹子的失望沮丧，也有被妹子欺骗利用的愤怒。无论是谁，被别人当成工具人都会火冒三丈吧？

在现实生活中，的确有一些心术不正的人喜欢利用别人的感情，让别人成为自己职业生涯的跳板和垫脚石，无论男女，坏人不分性别。

所以，即使你对某人动了心，也一定要警惕别有用心的感情陷阱。一旦发现自己有成为工具人的苗头，赶紧保持冷静，好好看清目前的局势。不要变成恋爱脑，像王宝钏一样，为了等待一个不值得的人，挖着野菜苦守寒窑十八年，成了一个笑话。

来自：行者

提到大文件上传，在脑海里最先想到的应该就是将图片保存在自己的服务器（如七牛云服务器），保存在数据库，不仅可以当做地址使用，还可以当做资源使用；或者将图片转换成base64，转换成buffer流，但是在javascript这门语言中不存在，但是这些只适用于一些小图片，对于大文件还是束手无策。

一、问题分析

如果将大文件一次性上传，会发生什么？想必都遇到过在一个大文件上传、转发等操作时，由于要上传大量的数据，导致整个上传过程耗时漫长，更有甚者，上传失败，让你重新上传！这个时候，我已经咬牙切齿了。先不说上传时间长久，毕竟上传大文件也没那么容易，要传输更多的报文，丢包也是常有的事，而且在这个时间段万不可以做什么其他会中断上传的操作；其次，前后端交互肯定是有时间限制的，肯定不允许无限制时间上传，大文件又更容易超时而失败....

一、解决方案

既然大文件上传不适合一次性上传，那么将文件分片散上传是不是就能减少性能消耗了。

没错，就是分片上传。分片上传就是将大文件分成一个个小文件（切片），将切片进行上传，等到后端接收到所有切片，再将切片合并成大文件。通过将大文件拆分成多个小文件进行上传，确实就是解决了大文件上传的问题。因为请求时可以并发执行的，这样的话每个请求时间就会缩短，如果某个请求发送失败，也不需要全部重新发送。

二、具体实现

1、前端

（1）读取文件

准备HTML结构，包括：读取本地文件（input类型为file）、上传文件按钮、上传进度。

<input type="file" id="input">
<button id="upload">上传</button>
<!-- 上传进度 -->
<div style="width: 300px" id="progress"></div>

JS实现文件读取：

监听input的change事件，当选取了本地文件后，打印事件源可得到文件的一些信息：

let input = document.getElementById('input')
let upload = document.getElementById('upload')
let files = {}//创建一个文件对象
let chunkList = []//存放切片的数组

// 读取文件
input.addEventListener('change', (e) => {
    files = e.target.files[0]
    console.log(files);
    
    //创建切片
    //上传切片
})

观察控制台，打印读取的文件信息如下：

（2）创建切片

文件的信息包括文件的名字，文件的大小，文件的类型等信息，接下来可以根据文件的大小来进行切片，例如将文件按照1MB或者2MB等大小进行切片操作：

// 创建切片
function createChunk(file, size = 2 * 1024 * 1024) {//两个形参：file是大文件，size是切片的大小
    const chunkList = []
    let cur = 0
    while (cur < file.size) {
        chunkList.push({
                file: file.slice(cur, cur + size)//使用slice()进行切片
        })
        cur += size
    }
    return chunkList
}

切片的核心思想是：创建一个空的切片列表数组chunkList，将大文件按照每个切片2MB进行切片操作，这里使用的是数组的Array.prototype.slice()方法，那么每个切片都应该在2MB大小左右，如上文件的大小是8359021，那么可得到4个切片，分别是[0，2MB]、[2MB，4MB]、[4MB,6MB]、[6MB,8MB]。调用createChunk函数，会返回一个切片列表数组，实际上，有几个切片就相当于有几个请求。

调用创建切片函数：

//注意调用位置，不是在全局，而是在读取文件的回调里调用
chunkList = createChunk(files)
console.log(chunkList);

观察控制台打印的结果：

（3）上传切片

上传切片的个关键的操作：

第一、数据处理。需要将切片的数据进行维护成一个包括该文件，文件名，切片名的对象，所以采用FormData对象来进行整理数据。FormData 对象用以将数据编译成键值对,可用于发送带键数据，通过调用它的append()方法来添加字段，FormData.append()方法会将字段类型为数字类型的转换成字符串（字段类型可以是 Blob、File或者字符串：如果它的字段类型不是 Blob 也不是 File，则会被转换成字符串类。

第二、并发请求。每一个切片都分别作为一个请求，只有当这4个切片都传输给后端了，即四个请求都成功发起，才上传成功，使用Promise.all()保证所有的切片都已经传输给后端。

//数据处理
async function uploadFile(list) {
    const requestList = list.map(({file,fileName,index,chunkName}) => {
        const formData = new FormData() // 创建表单类型数据
        formData.append('file', file)//该文件
        formData.append('fileName', fileName)//文件名
        formData.append('chunkName', chunkName)//切片名
        return {formData,index}
    })
        .map(({formData,index}) =>axiosRequest({
            method: 'post',
            url: 'http://localhost:3000/upload',//请求接口，要与后端一一一对应
            data: formData
        })
            .then(res => {
                console.log(res);
                //显示每个切片上传进度
                let p = document.createElement('p')
                p.innerHTML = `${list[index].chunkName}--${res.data.message}`
                document.getElementById('progress').appendChild(p)
            })
        )
        await Promise.all(requestList)//保证所有的切片都已经传输完毕
}

//请求函数
function axiosRequest({method = "post",url,data}) {
    return new Promise((resolve, reject) => {
        const config = {//设置请求头
            headers: 'Content-Type:application/x-www-form-urlencoded',
        }
        //默认是post请求，可更改
        axios[method](url,data,config).then((res) => {
            resolve(res)
        })
    })
}

// 文件上传
upload.addEventListener('click', () => {
    const uploadList = chunkList.map(({file}, index) => ({
        file,
        size: file.size,
        percent: 0,
        chunkName: `${files.name}-${index}`,
        fileName: files.name,
        index
    }))
    //发请求，调用函数
    uploadFile(uploadList)

})

2、后端

（1）接收切片

主要工作：

第一：需要引入multiparty中间件，来解析前端传来的FormData对象数据；

第二：通过path.resolve()在根目录创建一个文件夹--qiepian，该文件夹将存放另一个文件夹（存放所有的切片）和合并后的文件；

第三：处理跨域问题。通过setHeader()方法设置所有的请求头和所有的请求源都允许；

第四：解析数据成功后，拿到文件相关信息，并且在qiepian文件夹创建一个新的文件夹${fileName}-chunks，用来存放接收到的所有切片；

第五：通过fse.move(filePath,fileName)将切片移入${fileName}-chunks文件夹，最后向前端返回上传成功的信息。

//app.js
const http = require('http')
const multiparty = require('multiparty')// 中间件，处理FormData对象的中间件
const path = require('path')
const fse = require('fs-extra')//文件处理模块

const server = http.createServer()
const UPLOAD_DIR = path.resolve(__dirname, '.', 'qiepian')// 读取根目录，创建一个文件夹qiepian存放切片

server.on('request', async (req, res) => {
    // 处理跨域问题，允许所有的请求头和请求源
    res.setHeader('Access-Control-Allow-Origin', '*')
    res.setHeader('Access-Control-Allow-Headers', '*')

    if (req.url === '/upload') { //前端访问的地址正确
        const multipart = new multiparty.Form() // 解析FormData对象
        multipart.parse(req, async (err, fields, files) => {
            if (err) { //解析失败
                return
            }
            console.log('fields=', fields);
            console.log('files=', files);
            
            const [file] = files.file
            const [fileName] = fields.fileName
            const [chunkName] = fields.chunkName
            
            const chunkDir = path.resolve(UPLOAD_DIR, `${fileName}-chunks`)//在qiepian文件夹创建一个新的文件夹，存放接收到的所有切片
            if (!fse.existsSync(chunkDir)) { //文件夹不存在，新建该文件夹
                await fse.mkdirs(chunkDir)
            }

            // 把切片移动进chunkDir
            await fse.move(file.path, `${chunkDir}/${chunkName}`)
            res.end(JSON.stringify({ //向前端输出
                code: 0,
                message: '切片上传成功'
            }))
        })
    }
})

server.listen(3000, () => {
    console.log('服务已启动');
})

通过node app.js启动后端服务，可在控制台打印fields和files：

（2）合并切片

第一：前端得到后端返回的上传成功信息后，通知后端合并切片：

// 通知后端去做切片合并
function merge(size, fileName) {
    axiosRequest({
        method: 'post',
        url: 'http://localhost:3000/merge',//后端合并请求
        data: JSON.stringify({
            size,
            fileName
        }),
    })
}

//调用函数，当所有切片上传成功之后，通知后端合并
await Promise.all(requestList)
merge(files.size, files.name)

第二：后端接收到合并的数据，创建新的路由进行合并，合并的关键在于：前端通过POST请求向后端传递的合并数据是通过JSON.stringify()将数据转换成字符串，所以后端合并之前，需要进行以下操作：

• 解析POST请求传递的参数，自定义函数resolvePost，目的是将每个切片请求传递的数据进行拼接，拼接后的数据仍然是字符串，然后通过JSON.parse()将字符串格式的数据转换为JSON对象；

• 接下来该去合并了，拿到上个步骤解析成功后的数据进行解构，通过path.resolve获取每个切片所在的路径；

• 自定义合并函数mergeFileChunk，只要传入切片路径，切片名字和切片大小，就真的将所有的切片进行合并。在此之前需要将每个切片转换成流stream对象的形式进行合并，自定义函数pipeStream，目的是将切片转换成流对象，在这个函数里面创建可读流，读取所有的切片，监听end事件，所有的切片读取完毕后，销毁其对应的路径，保证每个切片只被读取一次，不重复读取，最后将汇聚所有切片的可读流汇入可写流；

• 最后，切片被读取成流对象，可读流被汇入可写流，那么在指定的位置通过createWriteStream创建可写流，同样使用Promise.all()的方法，保证所有切片都被读取，最后调用合并函数进行合并。

if (req.url === '/merge') { // 该去合并切片了
        const data = await resolvePost(req)
        const {
            fileName,
            size
        } = data
        const filePath = path.resolve(UPLOAD_DIR, fileName)//获取切片路径
        await mergeFileChunk(filePath, fileName, size)
        res.end(JSON.stringify({
            code: 0,
            message: '文件合并成功'
        }))
}

// 合并
async function mergeFileChunk(filePath, fileName, size) {
    const chunkDir = path.resolve(UPLOAD_DIR, `${fileName}-chunks`)

    let chunkPaths = await fse.readdir(chunkDir)
    chunkPaths.sort((a, b) => a.split('-')[1] - b.split('-')[1])

    const arr = chunkPaths.map((chunkPath, index) => {
        return pipeStream(
            path.resolve(chunkDir, chunkPath),
            // 在指定的位置创建可写流
            fse.createWriteStream(filePath, {
                start: index * size,
                end: (index + 1) * size
            })
        )
    })
    await Promise.all(arr)//保证所有的切片都被读取
}

// 将切片转换成流进行合并
function pipeStream(path, writeStream) {
    return new Promise(resolve => {
        // 创建可读流，读取所有切片
        const readStream = fse.createReadStream(path)
        readStream.on('end', () => {
            fse.unlinkSync(path)// 读取完毕后，删除已经读取过的切片路径
            resolve()
        })
        readStream.pipe(writeStream)//将可读流流入可写流
    })
}

// 解析POST请求传递的参数
function resolvePost(req) {
    // 解析参数
    return new Promise(resolve => {
        let chunk = ''
        req.on('data', data => { //req接收到了前端的数据
            chunk += data //将接收到的所有参数进行拼接
        })
        req.on('end', () => {
            resolve(JSON.parse(chunk))//将字符串转为JSON对象
        })
    })
}

还未合并前，文件夹如下图所示：

合并后，文件夹新增了合并后的文件：

作者：来碗盐焗星球
来源：juejin.cn/post/7177045936298786872

Z近几个月，在年轻群体中，出现一个新鲜的热词—精神离职，从前的躺平、摆烂流行词已经过时，新的流行词不知不觉间已经取代了旧的。

什么是精神离职？从哪里来？褒的贬的？

员工为什么要精神离职？

精神离职通常在哪个群体？

精神离职的表现有哪些？

应不应该精神离职？

是做低级的精神离职，还是高级的精神离职？

员工精神离职，老板怎么应对？

还有人精神离职，Z后当了CEO，甚至当了老板，这是真的吗？

精神离职一词延伸出许多疑惑，我将分几期来谈论这个话题。

一、什么是精神离职？

Quiet Quitting翻译为安静地放弃，即精神离职，顾名思义，通俗易懂地讲，就是精神离了职，身体还在职。这个词是从欧美年轻群体传过来，在国外TK短视频火起来，Z近慢慢在中国开始受人关注。

精神离职是一种出勤不出力、人在心不在、有力不愿使、事不关己高高挂起的状态。也是一种拿多少钱办多少事、不内卷、不加班、不承担额外责任的工作心态。

精神离职的人只是把工作当成以出卖劳动和时间换取生存的手段，只是把工作当成一个需要扮演的角色。是一种自我保护，一种对现状的妥协。他们不屑于996和狼性文化，内卷也卷不动他们。

精神离职人的表现有哪些？到底什么造成这一现象？

二、精神离职人的表现

1、不违规违纪，相当隐蔽。是平静海底的暗流。

2、上下班特别规律。

3、公司不论怎么变，都岿然不动。

4、不管遇到什么事，不生气，特别平静。不抱怨，觉得一切都很正常，不正常的也是正常的。

5、一切照章办事，如机器人一般。

三、员工为什么要精神离职？

1、外部就业环境、经济环境、工作环境。

2、工作不能自由选择。

3、工作痛苦、无聊、无力、孤立。

4、感觉工作没有意义，没有价值。没有认同感和成就感。

5、企业不考虑员工感受，不听取员工意见与建议。

6、工作中受到打击，没有信心。

7、怀才不遇，没有伯乐。

8、员工心态不好，没有责任感、没有目标追求。

你精神离职了吗？又是哪一种原因的精神离职？

工作痛苦的时候，是选择精神离职，还是身体离职？应不应该精神离职？怎么样才是对自己好的精神离职？怎么样才是高级的精神离职？员工精神离职老板怎么应对？下一期继续。

工作痛苦怎么办？精神离职还是身体离职？

是不是有很多人都觉得工作很痛苦，很无聊，没有意义，没有价值感，没有成就感？甚至让人压抑崩溃？据统计，大部分人每天都有离职的念头。但因为各种原因，一直纠结该不该离职。

那我们工作痛苦时，到底应不应该离职？是选择精神离职还是身体离职？

选择精神离职

1、如果你喜欢你的行业和工作，但因为其它原因而痛苦，可以选择精神离职。

2、如果你的工作你所在公司很有前途，你也很有前途，工资很高，很有希望，可以选择精神离职。

3、如果你非常需要这份工作来养家糊口，经济压力很大，又暂时找不到其他合适的工作，你可以选择精神离职。

4、如果你能从这份工作中学到知识，得到成长，为未来铺路，你可以选择精神离职。

选择身体离职

1、活太多，工资太低，养不活自己。

2、学不到任何东西，未来没有希望。

3、被老板PUA，被人欺负，没有丝毫的受尊重感，每天都活得很憋屈。

4、整个环境让人压抑抑郁。同事素质普遍低下。

5、加班太多，身体被搞垮。

6、加班很多，还没加班费。

7、行业、公司没有前景。

8、特别讨厌这份工作，觉得像活在地Y。

9、每天上班都很疲惫，工作让你觉得活着没意义。

10、有其它好的工作机会。

如果你的工作痛苦，你会选择精神离职还是身体离职？

精神离职＝躺平摆烂？

你是低级的精神离职，还是高级的精神离职？

精神离职就是躺平摆烂吗？他们有区别吗？其实精神离职大于摆烂，小于内卷。

精神离职又分为高级的精神离职和低级的精神离职。看看你是哪一种？

低级的精神离职

1、上班时不开心，无聊，麻木，让干啥干啥，就一个机器人。

2、不在乎一切，不受尊重，被骂也无所谓，不想生气不想吵架。

3、没有梦想，没有目标，没有追求，混一天是一天，就是混工资求生存的。

4、不想沟通，不想交际，没有想法，没有建议。

5、没有责任感，事不关己高高挂起，我只做我该做的事，其它事情和我无关。

6、下班刷视频追剧玩网络游戏，继续躺平，娱乐至上。

7、每天浑浑噩噩，虚度人生。

高级的精神离职

1、上班虽然佛系，让干什么干什么，但心里有目标和想法。

2、暗地里为自己努力，让自己渐渐变强大。不加班是觉得加班没用，不如回家提升自己。

3、下班搞副业，或者学习，提升各种能力，给自己更多的机会。哪天副业上来了，就变成主业了。

4、反抗方式放在创造力上，文学、艺术、音乐、运动、写作等是工作痛苦的解Y。

5、把更多的时间放在提升自己，或者维持健康，陪伴家人身上。

你是低级的精神离职还是高级的精神离职？都是精神离职，不如让自己成为高级的。

员工精神离职，老板怎么应对？怎么防止员工精神离职？

精神离职这个词近期突然火了起来，很多人都选择了精神离职，让自己身心舒坦一些。

那么员工精神离职，对企业有什么影响，老板应该怎么应对？

其实大部分精神离职，都是一种负面的，影响企业发展的因素，不能不重视。如果不及时纠正、引导、化解，一定如离岸流一般，拖累企业，让企业走向艰难的境地。

我们先来了解一下精神离职的人，以便对症下药。

精神离职人的特征：

1、精神离职的人不在意尊严荣誉，不在意自己的感受，没有目的追求，没有责任感，看不到努力的意义。不愿和公司沟通，选择一种被动攻击。

2、精神离职的人不再反思、选择，不再有目标、梦想等。

3、精神离职的人在工作中没有获得知识和成长，没有价值感、归属感、认同感、成就感，找不到自己在社会中的位置。

4、精神离职的人经常感觉无力，无意义，孤立，痛苦、无聊等。

5、精神离职的人觉得工作不能自由选择。

6、精神离职的人工作中受到打击，没有信心。企业不考虑员工感受，不听取员工意见与建议。

7、精神离职的人怀才不遇，感觉没有伯乐。

总结为两大点，一是对公司不满，二是对自己不满。

一般对公司不满时，有三种表现，一是直接身体离职，二是抱怨或提建议，三是沉默冷战，即精神离职。

精神离职其实是比较可怕的。因为它是一股暗流，你不知道的时候，它已经发展壮大，你可能没有机会挽救。

所以作为老板，要防止精神离职，或者在有苗头时掐灭。如果已经成形，便采取应对方法。

老板应对员工精神离职的方法：

1、管理者要从自负的控制者转变为谦逊的学习者。不要抑制员工的反馈与建议，不要不听负面的声音。

2、管理者要以互助学习模式来面对和解决工作问题。

3、公司要有公正的企业文化氛围， 有原则和规则的文化，能让员工获得信息沟通的安全感。缺少员工认同和员工互动的文化，不能称为企业文化。

4、征求员工意见，关注员工合理的需求。

5、多听合理的建议，解决企业的一些实际问题。

6、多采取激励方法，激励员工工作热情。

7、关心员工工作、生活和休息，注意假期安排，比如主动积极安排年休假等。

8、多肯定认可鼓励员工，肯定员工个人价值。

9、多增强团体信任感。

精神离职是一种安静社交，安静工作，因为感觉没有希望，所以沉默，愿我们都能在工作中找到真正的自己，快乐的自己。

来源：baijiahao.baidu.com/s?id=1749641382911734394

前言

读者诸君，今日我们适当放松一下，不钻研枯燥的知识和源码，分享一套高效的摸鱼绝活。

我有一位程序员朋友，当时在一个团队中开发Android应用，历经多次考核后发现：

在组内以及与iOS团队的对比中:

• 他的任务量略多

• 但他的bug数量和严重度均低

• 但他加班的时间又少于其他人

不禁令人产生好奇，他是如何做到代码别的又快，质量又高的

经过多次研究我终于发现了奥秘。

为了行文方便我用"老L"来代指这位朋友。

最常见的客户端bug

"老L，听说昨晚上线，你又坐那摸鱼看测试薅别人，有什么秘诀吗？"

老L："秘诀？倒也谈不上，你这么说，我倒是有个问题，你觉得平日里最常见的bug有哪些？"

"emm，编码上不健壮的地方，例如NPE，IndexOutOfBoundsException，UI上的可就海了去了，文本长度不一导致显示不下，间距问题，乱七八糟的一大堆"

老L："哈哈，都是些看起来很幼稚、愚蠢的问题吧？是不是测试挂嘴边的那句：' 你就不能跑一跑吗，你又不瞎，跑两下不就看到了，这么明显！！！' "

我突然来了兴致，"你是说我们有必要上 TDD（test-driven-develop），按照DevOps思想，在CI（Continuous Integration）的时候，顺带跑自动化测试用例发现问题？"

老L突然打断了我："不要拽你那些词了，记住了，事情是要人干的，机器只能替代可重复劳动，现在还不能替代人的主观能动性，拽词并不能解决问题。我们已经找到了第一个问题的答案，现在换个角度"

平日里最常见的bug有哪些？

• 编码不健壮, 例如NPE，IndexOutOfBoundsException

• UI细节问题, 例如文本长度不一导致显示不下，间距，等

为什么很浅显的问题没有被发现

老L："那么问题来了，为什么这些浅显的问题，在交测前没有被发现呢？"

我陷入了思考...

是开发们都很懒吗？也不至于啊！

是时间很紧来不及吗？确实节奏紧张，但也不至于不给调试就拿去测了！

"emm, 可能是迭代的节奏的太频繁，压力较大，并没有整块的时间用来自测联调"

老L接过话茬，"假定你说的是正确的，那么就有两种可能。"

"第一种，自测与联调要比开发还要耗费心思的一件事情。但实际上，你我都知道，这一点并站不住脚！"

"而第二种，就是在开发阶段无法及时测试，拖到开发完，简单测测甚至被催促着就交差了"

仔细的思考后

• 业务逐步展开，无法在任意时间自由地进行有效的集成测试

• 后端节奏并不比前端快多少，在前端的开发阶段，难以借助后端接口测试，也许接口也有问题

"确实，这是一个挺麻烦的问题，听你一说，我感觉除了多给几天，开发完集中自测一波才行" 我如是说到。

"NO NO NO"，老L又打断了我："你想的过多了，你想借助一个可靠的、已经完备的后端系统来进行自测。对于你的需求来说，这个要求过高了，你这是准备干QA的活"

"我帮你列举一下情况"

1. 一些数据处理的算法，这种没有办法，老老实实写单元测试，在开发阶段就可以做好，保障可靠性

2. UI呢，我们现在写的代码，基本都做到了UI与逻辑分层，只要能模拟数据，就能跑起来看页面

3. 业务层，后端逻辑我们无法控制，但 Web-API 调用的情况可以分析下并做一下测试，而对于返回数据的JSON结构校验、约束性校验也可以考虑做一下测试

总而言之，我们只需要先排除掉浅显的错误。而这些浅显的错误，属于情况2、3

老L接着说道："你先歇歇吧，我来说，你再插嘴这文章就太长了！"

接下来就可以实现矛盾转移："如何模拟数据进行测试"，准确的说，问题分成两个子问题：

• 如何生成模拟数据

• 如何从接缝中塞入数据，让系统得以使用

可能存在的接缝

先看问题2："如何从接缝中塞入数据，让系统得以使用"

脑暴一下，可以得出结论：

• 应用内部

  • 替换调用web-api的业务模块，使用假数据调用业务链，一般替换Presenter、Controller实例

  • 替换Model层，不调用web-api，返回假数据或用假数据调用回调链

  • 侵入网络层实现，不进行实际网络层交互，直接使用假数据

  • 遵循切面，向缓存等机制模块中植入假数据

• 应用外部

  • 使用代理，返回假数据

  • 假数据服务器

简单分析：

• "假数据服务器" ，并且使用逻辑编造假数据的代价太大，过。

• "使用代理，返回假数据"，可以用于特定问题的调试，不适用广泛情况，过。

• "替换调用web-api的业务模块"，成本过大，过。

• "替换Model层"，对项目的依赖注入管理具有较大挑战，备选，可能带来很多冗余代码。

• "侵入网络层实现"，优选。

• "向缓存等机制模块中植入假数据"，操作真实的缓存较复杂，但可以考虑增加一个 Mock缓存实现模块，基于SPI等机制，可以解决冗余代码问题，备选。

得出结论：

• 方案1："侵入网络层实现"，优选

• 方案2："替换Model层"，（项目的依赖注入做得很好时）作为备选，可能带来冗余代码

• 方案3："向缓存等机制模块中植入假数据"，增加一个 Mock缓存实现模块，备选。（基于SPI等机制，可以解决冗余代码问题）

再仔细分析： 方案1和方案3可以合并，形成一个完整的方案，但未必需要限定在缓存机制中

OK 我们先搁置一下这个问题，看前一个问题。

创造假数据

简单脑暴一下，无非三种：

• 人工介入，手动编写 -- 成本过大

  • 可能在前期准备好，基本是纯文本

  • 可能使用一个交互工具，在需要数据时介入，通过图形化操作和输入产生数据

• 人工介入，逻辑编码

• 基于反射等自省机制，并完全随机或者基于限制生成数据

"第一种代价过大，暂且抛弃"

"第二种可以采用，但是人力成本不容忽视! 一个可以说服我使用它的理由是："可以精心设计单测数据，针对性的发现问题"

"第三种很轻松，例如使用Mockito，但生成合适的数据需要花费一定的精力"

我们来扒一扒第三种方式，其核心思想为：

1. 获取类信息，得到属性集

2. 遍历属性填充 >

1. 基础类型、箱体类型，枚举，确定取值范围，使用Random取值，赋值

2. 普通类、泛型类，创建实例，回归步骤1
3. 集合、数组等，创建实例，回归步骤1，收集填充

不难得出结论，这一方法虽然很强大，但 创建高度定制化的数据 是一件有挑战的事情。

举个例子，模拟字符串时，一般会使用语料集作为枚举，进行取值。要得到“地址”、“邮箱”等特定风格的数据，需要结合框架做配置，客观上存在较高地学习、使用门槛。

你也知道，前几年我图好玩，写了个 mock库 。

必须强调的一点：“我并不认为我写的库比Mockito等库强大，仅仅是在我们开发人员够用的基础上，做到尽可能简单！”

你也知道，Google 在Androidx（前身为support）中提供了一套注解包： annotations。但Google并未提供bean validation 实现 ，我之前也基于此做过一套JSR303实现，有一次突发灵感，这套注解的含义同样适用于 声明假数据取值范围 ！！！

所以，我能使用它便捷的生成合适的假数据，在开发阶段及时的进行 “伪集成”

此刻，我再也忍不住要发言了：“且慢，老L，你这个做法有一定的侵入性吧。而且，如果数据类在不同业务下复用的话，是否存在问题呢？”

老L顿了顿，“确实，google的annotations是源码级注解，并不是运行时，我为了保持简单，使用了运行时反射而非代码生成。所以确实存在一定的代码侵入性”。

但是，我们可以基于此建立一套简单的MOCK-API，这样就不存在代码侵入了。

另外，也可以增加一套Annotation-Processor 实现方案，这样就可以适当沿用项目中的注解约束了，但我个人认为华而不实。

---

看你的第二个问题，Mocker一开始确实存在这个问题，有一次从Spring的JSR380中得到灵感，我优化了注解规则，这个问题已经被解决了。得空你可以顺着这个图看看：

或者去看看代码和使用说明：github.com/leobert-lan…

再次审视如何处理接缝

此时我已经有点云里雾里，虽然听起来很牛，如何用起来呢？我还是很茫然，简直人麻了！不得不再次请教。

老L笑着说：“你问的是一个实践方案的问题，而这类问题没有银弹.不同的项目、不同的习惯都有最适宜的方法，我只能分享一下我的想法和做法，仅做参考”

在之前的项目中，我自己建了一个Mock-API，利用我的Mocker库，写一个假数据接口就是分分钟的事情。

测试机挂上charles代理，有需要的接口直接进行mapping，所以在客户端代码中，你看不到我做了啥。

当然，这个做法是在软件外部。

如果要在软件内部做，我个人认为这也是一个华而不实的事情。不过不得不承认是一件好玩的事情，那就提一些思路。

基于Retrofit的CallAdapter

public interface CallAdapter<R, T> {
    Type responseType();

    T adapt(Call<R> call);

    abstract class Factory {
        public abstract @Nullable
        CallAdapter<?, ?> get(Type returnType, Annotation[] annotations,
                              Retrofit retrofit);

        protected static Type getParameterUpperBound(int index, 
                                                     ParameterizedType type) {
            return Utils.getParameterUpperBound(index, type);
        }

        protected static Class<?> getRawType(Type type) {
            return Utils.getRawType(type);
        }
    }
}

很明显，我们可以追加注解，用以区分是否需要考虑mock；

可选：对于有可能需要mock的接口，可以继续追加切面，实现在软件外部控制使用 mock数据 或 真实数据

而Retrofit已经使用反射确定了方法的 return Type ，在Mocker中也有适应的API直接生成假数据

基于Retrofit的Interceptor

相比于上一种，拦截器已经在Retrofit处理流程中靠后，此时在 Chain 中能够得到的内容已经属于Okhttp库的范畴。

所以需要一定的前置措施用于确定 "return Type"、"是否需要Mock" 等信息。可以借助Tag机制：

@Documented
@Target(PARAMETER)
@Retention(RUNTIME)
public @interface Tag {
}

@GET("/")
Call<ResponseBody> foo(@Tag String tag);

最终从 Request#tag(type: Class<out T>): T? 方式获取，并接入mock，并生成 Response

其他针对Okhttp的封装

思路基本类似，不再展开。

写在最后

听完老L的思路，我若有所思，若有所悟。他的方案似乎很有效，而且直觉告诉我，这些方案中还有很多留白空间，例如：

• 借用SPI等技术思路，可以轻易的解决 "Mock 模块集成与移除" 的问题

• 提前外部控制是否Mock的接缝，可以在加一个工具APP、或者Socket+网页端工具 用以实现控制

但我似乎遗漏了问题的开始

是否原意做 用于约束假数据生成规则的基础建设工作呢？？？ 例如维护注解

事情终究是人干的，人原意做，办法总比困难多。

最后一个小问题：

作者：leobert-lan
来源：juejin.cn/post/7175772997582585917

这篇文章适用于你和得病的朋友、熟人、同学和同事的沟通场景。

如果你本人发烧了，不妨把这篇转出去。

他们看了就算不能对你好一点儿，也能少说一点气人的话来激怒你。

图片来自：作者提供

1. 别人报阳千万别点赞

遇到朋友报发烧、报抗原两杠、红码截图。

普通熟人、朋友，可以用“辛苦了”“保重啊”来评论，也可以用“拥抱”“咖啡”等表情。

如果是对你比较重要的人，建议你小窗发消息问候。

不建议只点一个赞，什么都不说。

即使是日常的损友也不要这么做。

2. 问候的三种方式

对方是病人，病人情绪不会太好，病痛会让他们比较易怒，问候宜简短、不要长篇大论。

我的同事欧小宅老师（今天刚退烧）总结说，问候有三种方式：

“你还好吗？”

“祝早日康复！”

“能帮你做点什么？”

你可能会觉得这些问候太书面、太客套，但是请明白一点，大多数别出心裁、自来熟的问候都会砸锅，我们探望病人问候病人的时候形成了这三种问候，是有原因的，因为它们不会出错。

3. 想帮忙该怎么说

如果对方是你比较亲近、比较重要的朋友，你可以把“能帮你做点什么”具体化。

“你的药够吗？如果缺药，我匀点给你。”

“我买了一箱黄桃罐头，可以分你四个，要不要？”

注意，后半句一定要有。

如果你只是简单地问：“你囤药了吗？”对方会摸不准你要做什么。

这句话是看不出“我要你给我药”还是“我有药可以分享给你的”。

明确地表达自己的意图，是跟病人高效沟通的关键。

4. 如何请病人坚持工作

如果你因为工作的缘故仍然要跟一个病人对接，请务必先行问候对方，再谈工作。

工作谈完之后，一定要说“好好休息”之类安慰和勉励的话。

尽快结束工作，比什么安慰都好。

图片来自：作者提供

5. 刨根问底很无聊

“你阳了吗？”

“阳了吗？阳了吗？阳了吗？”

“怎么不理我，我好心问候你，你到底阳了没有啊？”

图片来自：作者提供

“烧起来之后反正都要吃感冒药，不去测还更不容易感染别人。”

这种追问，是没有把对方当病人，而是把对方当风险源和管理对象。

小区门口的大白们都撤了，但有些人心中的防护服还没有脱下来——这种盘根问底，就是他代入了某种角色的表现。

6. 发烧的人没法特么关心世界

有的人其实是想问候病人的，但是一开口就是极其宏大的命题，比如：

“发烧是不是很疼啊？”（废话，你烧到39.5试试看。）

“你身边病倒的人多吗？”（朋友圈有两百多人，你要每个人的电话号码是吗？）

“北京那边形势怎么样？”（我两眼冒金星，你觉得我关心吗？）

图片来自：作者提供

你是出考研政治大题的吗？

开放式问题是问候病人的大忌。

7. 过来人如何给支持

昨天我的一位朋友张老师作为过来人给我分享了一个要诀。

“退热贴已经不好买了，如果买不到，可以把面膜放在冰箱里，烧厉害的时候替代退热贴。”

这种就是非常宝贵的信息，病人只能接受这样明确的信息。

如果你给一个已经病倒的人分享医生嘚嘚嘚讲如何防护的短视频，或者用药大名单之类的PDF，完全没意义了。

此外，每个人的体质不同，疼痛是一种主观感受，作为过来人，不要说“不疼”“没事儿”之类的话，只要告诉病人“我理解你的感受”就够了。

8. 遇到含糊的问题怎么办

刚才说的是如何问候病人。

如果你的领导含含糊糊地问你“你囤药了吗？”应该怎么回答？

建议你实话实说。

“布洛芬还有一盒，不多了。”

如果他是要给你药，你可以决定要不要，如果他是跟你要药，这会儿就会去找别人了。

9. 讨药的注意事项

中国不缺布洛芬或者对乙酰氨基酚，如果开足马力，一年能够30亿人轮番发烧吃的。

退烧药不会吃很多，大多数拍照发朋友圈的囤药者，未来都会剩很多药放在家里过期。

如果你断了药，就直接请那些发囤药照的朋友帮忙就好了。

鉴于发烧的人很多，可能跑腿快递也很难叫到，所以如果缺药，优先在邻居群里求。

如果要发朋友圈求助某类药品，最好是写上自己所在的位置，这样能得到最快的支援。

记得说谢谢，等一切都过去了，一定要坐下来吃个饭。

图片来自：作者提供

有些关系，是给出来的，有些关系，是要出来的。

10. 为什么要这样强调礼貌

这三年的经验就是，全靠自己做自了汉是不行的。

人需要互相扶持。

你今天安慰一个正在发烧的朋友，向他提供帮助，明天你病倒，而且危险的时候，他作为一个刚刚康复有抗体的人，可能就能送打不上车的你去医院（你不会相信等那三个数派车能轮到你吧）。

有一批错峰发病、互相关心的朋友，是我们健康平安的保险阀。

p.s

普通家庭肯定是一阳全阳的，没有双卫怎么保证不传染？

双卫了也照样……

专家都会告诉你说，把病人单独搁一个屋里，没病的在外面。我跟说，你真这样会没朋友的。

媳妇在屋里疼得哞哞哭，自己爬起来吃药倒水，你在外面看世界杯？转阴之日也就是你离异之时了。自己权衡一下，这就是个烧三天的病。

有时候就要冒着风险做该做的事。

活学活用，是生活的奥义。

作者：能老师
来源：mp.weixin.qq.com/s/PMj6gLj32AUNOXPvptYscA

作家采铜说过一个很有意思的比喻，他说，我们真的生活在一个肤浅的时代……希望今天的文章能够给你们带来收获，欢迎分享和点亮在看。

......................................................

......................................................

......................................................

外国的神父呆了不久

留下几个 P 就走了，

一个 P 叫 BPR，

一个 P 叫 ERP。

......................................................

监院也没闲着，

他认为问题的关键在于

人才没有充分利用、

寺庙文化没有建设好,

于是就成立了

人力资源部和寺庙工会等等

......................................................

......................................................

......................................................

......................................................

最后决定，

成立专门的挑水部负责后勤

和专门的烧香部负责市场前台。

同时，为了更好地开展工作，

寺庙提拔了十几名和尚

分别担任副主持、主持助理，

并在每个部门任命了

部门小主持、副小主持、小主持助理。

......................................................

老问题终于得到缓解了，

可新的问题跟着又来了。

后台挑水的和尚也抱怨人手不足、

水的需求量太大而且没个准儿，

不好伺候。

为了便于沟通、协调，

每个部门都设立了对口的联系和尚。

协调虽然有了，但效果却不理想，

仔细一研究，

原来是由于水的需求量不准、

水井数量不足等原因造成的。

于是各部门又召开了几次会，

决定加强前台念经和尚对饮用水的预测

和念经和尚对挑水和尚满意度测评等，

让前后台签署协议、相互打分，

健全考核机制。

同时成立香火钱管理部、

香火钱出账部、

打井策略研究部、

打井建设部、

打井维护部等等。

由于各个系统出来的数总

不准确、都不一致，

于是又成立了技术开发中心，

负责各个系统的维护、

二次开发。

......................................................

由于部门太多、办公场地不足，

寺院专门成立了综合部

来解决这一问题

......................................................

同时，

为了精简机构、提高效率，

寺院还成立了精简机构办公室、

机构改革研究部等部门。

......................................................

一切似乎都合情合理，

但香火钱和喝水的问题

还是迟迟不能解决。

问题在哪呢？

有的和尚提出来每月应该开一次分析会，

于是经营分析部就应运而生了。

寺院空前地热闹起来，

有的和尚在拼命挑水、

有的和尚在拼命念经、

有的和尚在拼命协调、

有的和尚在拼命分析……

忙来忙去，水还是不够喝，

香火钱还是不够用。

什么原因呢？

这个和尚说流程不顺、

那个和尚说任务分解不合理，

这个和尚说部门职责不清、

那个和尚说考核力度不够。

只有三个人最清楚问题之关键所在，

那三个人就是最早的那三个和尚。

......................................................

......................................................

三个人忍无可忍，斗胆向上汇报，

要求增加挑水的人手，

越过数个层级之后，

主持和监院总算收到了这个请求。

经过各个部门季度会议的总结和分析，

经过了数次激烈的探讨，

总算可以从其他部门抽调过来

一些和尚进行支援，

但这些跨部门过来的和尚

根本挑不动水，

还对挑水的这几个和尚指手画脚，

挑水的和尚再次请求，

自己担任挑水的和尚团队负责人。

......................................................

又过了一年，寺院黄了，

大部分和尚都死了

......................................................

大企业管理特色：

总部愈来愈庞大，基层愈来愈忙碌，

成本愈来愈高，客户愈来愈不满。

来源：芝麻观点

一.求学之路

首先说一下自己的背景：由于家庭原因高中辍学，后面报了一个成人专科，浑浑噩噩在学校呆了3年，没有学到什么有用的东西(浪了3年)。我在17年的时候通过自学前端的知识找到了人生的第一份前端开发的工作，当时真的是培训班盛行，那些培训班打着面试的旗号让你进去培训班，出来打工还债。我也是差点就被带进去了。后来还是抵住了诱惑，通过自己学习前端找到了工作。

第一家公司没有明确的分开前后端，项目也是没有前后端分离的，当时他们主要使用的语言是C# + .net 开发。我当时没有接触过C#(只会一些基本的语法)。那时候我也是心非常的慌，害怕好不容易找到的工作就这样丢了，于是每天晚上回去都会去自学C#的基础。幸运的是遇到一个非常好的同事与领导带着我去做项目，我也是顺利的转正了。公司的主要业务是做客户端系统，业务很复杂，通过在公司一年多的磨练，我从一个什么都不会的小白，变成了一个什么都会一点（前端，后端，sql，运维）的萌新了。

当时公司的前端主要框架是JQuery，当时我还不知道Vue，React这种数据驱动的框架，公司也没有其他真正的前端来教我（没错，我是那个公司的唯一一个前端）。后面通过自学，学习了Vue的框架，想在公司中推广这种架构。对于我这个人微言轻的小萌新来说，显然是失败的，大概就是公司不想冒风险，毕竟公司需要求稳。

没办法，当时的我觉得在这里已经没有办法能提高了，毕竟是没有人带，但是那边的老板非常看重我，也是希望我留下，在经过一系列的思想斗争后，还是离开了在这里的呆了一年半的公司，从广州跑去了深圳。

在深圳，再一次被社会毒打。由于是专科的学历，而且不是全日制，找工作处处碰壁，经过一个月的艰苦找工作之路，拿到了两个offer，一个是主要是做邮箱后台的，使用的技术栈是Vue，薪资8K；另外是一个新成立的部门，主要的业务是小程序与后台，但是所有东西都是从零开始搭，薪资6K。当时我希望学习的更多的东西，所以我选择了后者。现在看来，我的选择是正确的，在这个公司，我自学的node，帮助公司搭起架构，学会了服务器运维，同时也学会了Vue。

在那时，我是深刻地意识到，没有学历真的寸步难行。别人轻易拿到的东西，我们需要拼尽全力才能拿到。同时我见识到了成人本科的摆烂行为。我不想混一个本科，既然要拿本科，那自己也要学习到对得起学历的知识。所以我选择了自考。我没有报班，坚持自己的学习计划：每天6点起来学习，下班回去复习，周末没事就去图书馆学习。

这是部分自考的书籍

或许我不是一个特别聪明的人，书上的很多概念有很多很多，因为我是自学的，没有人给我总结重点，所以我认为整本书都是重点，自己去手抄每一个知识点加深记忆，通过三年时间的学习，我写满了二十几个笔记簿（下面只是部分）。没有人教我，那我就去网上自学，刷题。（不得不说通信原理自学是真的很难（傅里叶变换，傅里叶级数...），网上教学也很笼统，只能自己硬啃，我挂了两次！！）

在自考路上的同时，我也不忘深入地学习前端的知识。所以想起当时的自己总是很忙，工作，自考，提升技术，没有时间去做其他的事情。

通过三年（2019-2022）的自学。我终于拿到了学位证。或许这就是给自己努力的回报吧~!

（最差的英语一遍过了！！）
(仅仅过关的学位考试)

（校园随拍）

（校园随拍）

（毕业设计）

（毕业设计）

（毕业设计）

（学历信息）

（学位证）

要说最高兴的不是我拿到了学位证，是我在自考的过程中真正地学习到了知识。我报的是网络工程专业，在自考之前，除了数据结构和程序设计，其他专业课与基础课基本我都没有学习过。通过自考这个渠道，我学习了高数，线代，网络原理，通信原理，多路复用，信号传输原理，如何搭建网络，如何设计一个属于自己的网络协议等很多很多的知识，这种学习到自己喜欢的专业知识是非常让人兴奋的。

还有就是，这是我第一次通过学习得到了老师的肯定——毕业论文的导师愿意帮我写推荐信，可把我高兴得泪目了。

很显然，经过社会毒打四年多的我拿到这一个本科学历绝对不是终点，我希望再次进入学校学习（其实就是我不想去做公司的那些重复无聊的表单设计前端工作）。于是在我面前有3条路可走：1.躺平，2.考研，3.留学。

18岁时我没得选，现在我再一次站在了人生的十字路口中。这次我选择的是后者，考研和留学（希望这次我不会选错吧）。
经过几年的工作，也有一些积蓄去支撑我到国外留学，那就先试试留学吧，不行就去考研。于是我就一步一步按着学校的流程准备资料。

留学最大的难度就是英语，我自认为自己最差的就是英语了，总是学不会。但我不会向困难屈服的，觉得自己英语不好，那就从背单词开始，每天背一点，一直坚持了几年（期间换了一个APP），也总算把初中高中的词汇量补回来了。可以开始下一步的学习了

于是现在我除了工作，就是学英语。我是这样想的，即使我留学申请都没过，但雅思过了，多少也能提升一点竞争力，让社会资源多倾向自己多一点（这就是我几个月没更文的原因😢）。

（凌乱的书桌）

（雅思开始迫在眉睫，压力山大）

二.是什么驱动着我去学习

我觉得，当我们有一个目标，而且这个目标的吸引力足够大的时候，人们就会将逼迫着自己去努力，去拿到自己想要的东西。就比如高考，有的人希望自己能考一个好的学校，于是他很努力地想要达到自己想要的结果，有人却无所谓，没有了驱动力，通常情况是不会得到好的结果。

对我而言，我的目标就是，我不希望被其他人歧视自己是非全日制的学生，还有一点小小的梦想——能稍微改变一下这个社会对于非全日制但是却有足够能力的人的看法。人就是这么与无力，这样一个目标就足以让我们奋斗一生。

对我而言，遇到社会的不公已经是习以为常，甚至已经麻木了。没办法，一步错步步错，没有得到社会资源的倾斜也是自己不够努力的结果。前面我也说了，我是一个要强的人，这种社会的毒打对我而言就是一种动力，只会让我更加努力，让那些看不起我们的人后悔或是另眼相看。

说一个我亲身经历的例子，19年的时候我入职了一个node开发的岗位，入职的时候HR看到我的bi业证是业余大专的时候，他给我发了信息说：你这个大专不是全日制的啊？我说对，后面她也没说什么，只是说好吧。

估计那时候HR已经有不想要的意思了，我甚至都可能撑不过试用期。但是经过三个月的工作，我完美地完成了公司的工作，还优化了公司的后端基础工程，在转正答辩的时候得到所有领导的同意转正。那个HR从此路转粉甚至还加了我的私人微信。

可能是我运气比较好的原因吧，如果我遇到的是一些规定严格的公司，我估计一点机会都不会有。毕竟全日制的学历的学生出现差错的概率比非全日制学历的学生小得多，没有哪一个人愿意冒着风险去请一个人有可能踩雷的员工。对吧？

三.2022的成长

毫无意外，2022也是忙碌的一年，除了准备学位考试，同时还对外输出了文章，参加了两次掘金更文活动。

自学了go基础，用go语言将自己的博客后端服务重构了

做了一个读书笔记的网站

做了一个自用的cli工具，源码

为了了解非关系型数据库，自己手写了一个类似非关系型的数据存储项目，源码

除此之外，在公司中，我给公司创建了公共UI库，通用请求队列库，异常捕捉系统，低代码项目等前端基础工程~

四.保持自己的危机感

第一次听到危机意识这个词，是我在第一个公司的时候，带我的一个同事跟我说的。

其实无论是否躺平，我们都需要保持自己的危机意识，不能说在一个公司里面很闲，工作很轻松，就觉得可以放松下去了。万一遇到一些突发情况（例如：被毕业之类的），自己的处境就会很被动了。

当然过度的紧张也会适得其反。如果有🐟可摸，我一般都会抽出一半的时间去学习，让自己保持学习的状态。

我在这个公司已经工作一年半了。怎么说呢，一开始这个公司说是弄SCRM的，结果入职后天天搞小程序和管理系统，而且都是一些基础的表单UI，对我而言，我在没有什么可以学习的。

其实我也不是第一次遇到这种情况了，毕竟除了第一个公司，后面的公司我都是靠自学一个人走过来的。遇到这种情况，首先我做的是在空闲的时间输出一些便于开发公共库，在公司的期间，我也开了一个关于微前端的内部分享会，同时我也写了一遍关于微前端框架的文章从0到1实现一个微前端框架。

（分享会的PPT）

为了应对长期的活动页面需求（基本上一周需要上线一个小程序活动页），于是我在摸鱼的时候给小程序做了一个低代码生成活动页的模块，很愉快地将需求甩给了其他人😄，给自己挣到了摸鱼的时间!!

（低代码后台）

我是什么时候萌生跑路的意思的，其实也都是一些人际关系的问题，还有就是工作对于我而言了，我希望向难度挑战。

先说一下人际关系吧，就是在一次需求评审过程中，我第一次听到资源这个词。没错，他们那些项目经理把我们当成是资源供他们调度，后面听说他们之间还有一个资源群，这让我更加反感了。

怎么说呢，对我来说就是不把人当人，我们只是他们的一个棋子的意思吧，所以我很反感这种，所以我受不了，决定到过年前就跑路了。这几年也没怎么真正休息过，正好趁着这次机会休息一下吧～

(聊天记录)

五.明年目标

前面我也说过，做人还是得有目标，才会有动力去做事情，每年给自己定一些小目标。

• 首先持续输出技术文章这个肯定是要做的，希望明年能到LV5

• 如果有哪个学校肯收留我了，那我就去读书了（这回我肯定拼尽全力地学习了）！！如果没有收留，那就开始着手准备考研的事情。

• 第三个就是英语，希望雅思6.5。这个是属于挑战自己最不擅长的事情了，希望能做到~!

• 如果进去学校了，我会开始研究物联网相关的知识。

作者：Ichmag
来源：juejin.cn/post/7174340400151265294

一、在中国你千万不要以为学习技术就可以换来稳定的生活和高的薪水待遇，你更不要认为那些从事市场开发，跑腿的人，没有前途。

不清楚你是不是知道，咱们中国有相当大的一部分软件公司，他们的软件开发团队都小的可怜，甚至只有1-3个人，连一个项目小组都算不上，而这样的团队却要承担一个软件公司所有的软件开发任务，在软件上线和开发的关键阶段需要团队的成员没日没夜的加班，还需要为测试出的BUG和不能按时提交的软件模块功能而心怀忐忑，有的时候如果你不幸加入现场开发的团队你则需要背井离乡告别你的女友，进行封闭开发，你平时除了编码之外就是吃饭和睡觉(有钱的公司甚至请个保姆为你做饭，以让你节省出更多的时间来投入到工作中，让你一直在那种累了就休息，不累就立即工作的状态)

更可怕的是，会让你接触的人际关系非常单一，除了有限的技术人员之外你几乎见不到做其他行业工作和职位的人，你的朋友圈子小且单一，甚至破坏你原有的爱情(想象一下，你在外地做现场开发2个月以上，却从没跟女友见过一面的话，你的女友是不是会对你呲牙裂嘴)。

也许你拿到了所谓的白领的工资，但你却从此失去享受生活的自由，如果你想做技术人员尤其是开发人员，我想你很快就会理解，你多么想在一个地方长期待一段时间，认识一些朋友，多一些生活时间的愿望。

比之于我们的生活和人际关系及工作，那些从事售前和市场开发的朋友，却有比我们多的多的工作之外的时间，甚至他们工作的时间有的时候是和生活的时间是可以兼顾的，他们可以通过市场开发，认识各个行业的人士，可以认识各种各样的朋友，他们比我们坦率说更有发财和发展的机会，只要他们跟我们一样勤奋。(有一种勤奋的普通人，如果给他换个地方，他马上会成为一个勤奋且出众的人。)

二、在学习技术的时候千万不要认为如果做到技术最强，就可以成为100%受尊重的人。

有一次一个人在面试项目经理的时候说了这么一段话：我只用最听话的人，按照我的要求做只要是听话就要，如果不听话不管他技术再好也不要。随后这个人得到了试用机会，如果没意外的话，他一定会是下一个项目经理的继任者。

朋友们你知道吗?不管你技术有多强，你也不可能自由的腾出时间象别人那样研究一下LINUX源码，甚至写一个LINUX样的杰作来表现你的才能。需要做的就是按照要求写代码，写代码的含义就是都规定好，你按照规定写，你很快就会发现你昨天写的代码，跟今天写的代码有很多类似，等你写过一段时间的代码，你将领略：复制，拷贝，粘贴那样的技术对你来说是何等重要。(如果你没有做过1年以上的真正意义上的开发不要反驳我)。

如果你幸运的能够听到市场人员的谈话，或是领导们的谈话，你会隐约觉得他们都在把技术人员当作编码的机器来看，你的价值并没有你想象的那么重要。而在你所在的团队内部，你可能正在为一个技术问题的讨论再跟同事搞内耗，因为他不服你，你也不服他，你们都认为自己的对，其实你们两个都对，而争论的目的就是为了在关键场合证明一下自己比对方技术好，比对方强。(在一个项目开发中，没有人愿意长期听别人的，总想换个位置领导别人。)

三、你更不要认为，如果我技术够好，我就自己创业，自己有创业的资本，因为自己是搞技术的。

如果你那样认为，真的是大错特错了，你可以做个调查在非技术人群中，没有几个人知道C#与JAVA的，更谈不上来欣赏你的技术是好还是不好。一句话，技术仅仅是一个工具，善于运用这个工具为别人干活的人，却往往不太擅长用这个工具来为自己创业，因为这是两个概念，训练的技能也是完全不同的。

创业最开始的时候，你的人际关系，你处理人际关系的能力，你对社会潜规则的认识，还有你明白不明白别人的心，你会不会说让人喜欢的话，还有你对自己所提供的服务的策划和推销等等，也许有一万，一百万个值得我们重视的问题，但你会发现技术却很少有可能包含在这一万或一百万之内，如果你创业到了一个快成功的阶段，你会这样告诉自己：我干吗要亲自做技术，我聘一个人不就行了，这时候你才真正会理解技术的作用，和你以前做技术人员的作用。

小结

基于上面的讨论，我奉劝那些学习技术的朋友，千万不要拿科举考试样的心态去学习技术,对技术的学习几近的痴迷，想掌握所有所有的技术，以让自己成为技术领域的权威和专家，以在必要的时候或是心里不畅快的时候到网上对着菜鸟说自己是前辈。

技术仅仅是一个工具，是你在人生一个阶段生存的工具，你可以一辈子喜欢他，但最好不要一辈子靠它生存。

掌握技术的唯一目的就是拿它找工作(如果你不想把技术当作你第二生命的话)，就是干活。所以你在学习的时候千万不要去做那些所谓的技术习题或是研究那些帽泡算法，最大数算法了，什么叫干活?

就是做一个东西让别人用，别人用了，可以提高他们的工作效率，想象吧，你做1万道技术习题有什么用?只会让人觉得酸腐，还是在学习的时候，多培养些自己务实的态度吧，比如研究一下当地市场目前有哪些软件公司用人，自己离他们的要求到底有多远，自己具体应该怎么做才可以达到他们的要求。等你分析完这些，你就会发现，找工作成功，技术的贡献率其实并没有你原来想象的那么高。

不管你是学习技术为了找工作还是创业，你都要对技术本身有个清醒的认识，在中国不会出现Bill Gates，因为，中国目前还不是十分的尊重技术人才，还仅仅的停留在把软件技术人才当作人才机器来用的尴尬境地。(如果你不理解，一种可能是你目前仅仅从事过技术工作，你的朋友圈子里技术类的朋友占了大多数，一种可能是你还没有工作，但喜欢读比尔·盖茨的传记)。

总结

“千万不要一辈子靠技术生存”，这是一句比较现实的话。很多人觉得自己现在20多岁，月入2~3W或者更多了，很OK呀。

理解这句话的前提是，你不满足于现在的收入（如果是工作年限比较短的，你可以看看这个行业做的比较好的人的收入，你能否满足），对自己的未来或者行业有感到担忧，那么你才能很好的理解这句话。

这也是为什么能理解这句话的人，大多是到了35岁左右的。诚然，对于一个工作7、8年或者不到的程序员，这个阶段技术是必须的，要深、要有一个今天被开，我可以保证明天找到工作的技术能力； 如果你足够幸运，能有在某一个领域做到专家级的、后面的小辈无法替代你，那"千万不要一辈子靠技术生存"这句话当然也就不适合你了，大牛，请受吾一拜。 但是，对于大多数人，都无法做到在一个领域无可替代（机遇与天赋），那么就要想办法保证在上了年纪、上有老下有下的时候不被公司裁掉、收入不减、生活质量不降。

如果在这个阶段你还在研究这个功能怎么实现、这个算法是多么的精妙，我觉得你不是太单纯，就是在借技术之名在逃避现实。 说一句庸俗的话，我满脑子想得都是怎么搞钱，怎么让家人生活的更好，做技术的在35岁之前没达到这一点（且不论财务自由），你觉得35岁以后还有机会吗？或者说扪心自问一下，你所做的事情有多少是你能做，别人不能做的，有多少技术含量自己心里应该也有点数。 所以，技术只是现阶段谋生的一项技能。

每个人的技术都是有天花板的，你的技术到了天花板的时候，你的收入能否满足你，这个是需要考虑的。当然，你家里有矿或者北京二环内有几套房，那你完全可以把技术当爱好。

作者：小伙子有前途
来源：juejin.cn/post/7175009448854257725

先说结论：

• 看经典书

• 看官方文档

为什么是经典书籍

我买过很多本计算机、前端、JavaScript方面的书，在这方面也踩过一些坑，分享下我的经验。

在最早我也买过亚马逊的kindle，kindle的使用体验还不错，能达到和纸书差不多的阅读体验，而且很便携，但由于上面想看的书很多都没有，又懒得去折腾，所以后来就卖了。

之后就转到了纸书上，京东经常搞100减50的活动，买了很多的书，这些书有的只翻了几页，有的翻来覆去看了几遍。

翻了几页的也有两种情况，一种是内容质量太差，完全照抄文档，而且还是过时的文档，你们都知道，前端的技术更新是比较快的，框架等更新也很快，所以等书出版了，技术可能就已经翻篇了。

另一种就是过于专业的，比较复杂难懂，比如编译原理，深入了解计算机系统 算法(第4版)等这种计算机传世经典之作。

纸书其实也有缺点，它真的是太沉了，如果要是出差的话想要带几本书的话，都得去考虑考虑，带多了是真的重。

还有就是在搬家的时候，真的就是噩梦，我家里有将近100本的纸书，每次搬家真的就是累死了。

所以最近一两年我都很少买纸书了，如果有需要我都会尽量选择电子版。

电子版书走到哪里都能看，不会有纸书那么多限制，唯一缺点可能就是没有纸书那股味道。

还有就是电子书平台的问题，一个平台的书可能不全，比如我就有微信图书和京东这两个，这也和听歌看剧一样，想看个东西，还得去多个平台，如果要是能够统一的话就好了。

还有就是盗版的pdf，这个我也看过，有一些已经买不到的书，没办法只能去网上寻找资源了。建议大家如果能支持正版，还是支持正版，如果作者赚不到钱，慢慢就没有人愿意创作优质内容，久而久之形成了恶性循环。

看经典书学习前端，是非常好的方式之一，因为书是一整套系统的内容，它不同于网上的碎片化文章。同时好书也是经过成千上万人验证后的，我们只需选择对的就可以了。

我推荐几本我读过的比较好的前端方面的书

1. javascript高级程序设计

2. 你不知道的javascript 上 中 下卷

3. 狼书 卷1 卷2

关于计算机原理方面的书

1. 编码：隐匿在计算机软硬件背后的语言

2. 算法图解

3. 图解http

4. 大话数据结构

上面的书都是我买过，看过的，可能还有我不知道的，欢迎在评论中留言

这些书都有一些共同的特征，就是能经过时间的检验，不会过时，可以重复的去阅读，学习。

为什么是官方API文档

除了经典书之外，就是各种语言、框架的官方文档，这里一定注意是“官方文档”，因为百度里面搜索的结果里，有很多镜像的文档网站，官方第一时间发布的更新，他们有时并不能及时同步，所以接受信息就比人慢一步。所以一定要看“官方文档”。

比如要查询javascript、css的内容，就去mdn上查看。要去看nodejs就去nodejs的官网，要去看react、vue框架就去官网。尽量别去那些第三方网站。

作者：小帅的编程笔记
来源：juejin.cn/post/7060102025232515086

续 做一个具有高可用性的网络库（上）

网速检测

如果可以获取到当前手机的网速，就可以做很多额外的操作。 比如在图片场景中，可以基于当前的实时网速进行图片的质量的变换，在网速快的场景下，加载高质量的图片，在网速慢的场景下，加载低质量的图片。 我们如何去计算一个比较准确的网速呢，比如下面列举的几个场景

• 当前app没有发起网络请求，但是存在其他进程在使用网络，占用网速

• 当前app发起了一个网络请求，计算当前网络请求的速度

• 当前app并发多个网络请求，导致每个网络请求的速度都比较慢

可能还会存在一些其他的场景，那么在这么复杂的场景，我们通过两种不同的计算方式进行合并计算

1. 基于当前网络接口的response读取的速度，进行网速的动态计算

2. 基于流量和时间计算出网速

通过计算出来的两者，取最大值的网速作为当前的网速值。

基于当前接口动态计算

基于前面网络请求的全流程监控，我们可以在全局添加所有网络接口的监听，在ResponseBody这个周期内，基于response的byte数和时间，可以计算每一个网络body读取速度。之所以要选取body读取的时间来计算网速，主要是为了防止把网络建连的耗时影响了最终的网速计算。 不过接口网速的动态计算需要针对不同场景去做不同的计算。

• 当前只有一个网络请求 在当前只有一个网络请求的场景下， 当前body计算出来请求速度就是当前的网速。

• 当前同时存在多个网络请求发起时 每一个请求都会瓜分网速，所以在这个场景下，每个网络请求的网速都有其对应的网速占比。比如当前有6个网络请求，每个网络请求的网速近似为1/6。

当然，为了防止网速的短时间的波动，每个网络请求对于当前的网速的影响是有固定的占比的, 比如我们可以设置的占比为5%。

currentSpeed = (requestSpeed * concurrentRequestCount - preSpeed) * ratePercent + preSpeed

其中

• requestSpeed：表示为当前网络请求计算出来的网速。

• concurrentRequestCount：表示当前网络请求的总数

• preSpeed：表示先前计算出来的网速

• ratePercent：表示当前计算出来网速对于真正的网速影响占比

为了防止body过小导致的计算出来网速不对的场景，我们选取当前body大小超过20K的请求参与进行计算。

基于流量动态计算

基于流量的计算，可以参照TrafficState进行计算。可以参照facebook的network-connection-class 。可以通过每秒获取系统当前进程的流量变化，网速 = 流量总量 / 计算时间。 它内部也有一个计算公式：

public void addMeasurement(double measurement) {
  double keepConstant = 1 - mDecayConstant;
  if (mCount > mCutover) {
    mValue = Math.exp(keepConstant * Math.log(mValue) + mDecayConstant * Math.log(measurement));
  } else if (mCount > 0) {
    double retained = keepConstant * mCount / (mCount + 1.0);
    double newcomer = 1.0 - retained;
    mValue = Math.exp(retained * Math.log(mValue) + newcomer * Math.log(measurement));
  } else {
    mValue = measurement;
  }
  mCount++;
}

自定义注解处理

假如我们现在有一个需求，在我们的网络库中有一套内置的接口加密算法，现在我们期望针对某几个网络请求做单独的配置，我们有什么样的解决方案呢？ 比较容易能够想到的方案是添加给网络添加一个全局拦截器，在拦截器中进行接口加密，然后在拦截器中对符合要求的请求URL的进行加密。但是这个拦截器可能是一个网络库内部的拦截器，在这里面去过滤不同的url可能不太合适。 那么，有什么方式可以让这个配置通用并且简洁呢？ 其中一种方式是通过接口配置的地方，添加一个Header，然后在网络库内部拦截器中获取Header中有没有这个key，但是这个这个使用起来并且没有那么方便。首先业务方并不知道header里面key的值是什么，其次在添加到header之后，内部还需要在拦截器中把这个header的key给移除掉。

最后我们决定对于网络库给单接口提供的能力都通过注解来提供。 就拿接口加密为例子，我们期望加密的配置方式如下所示

@Encryption
@POST("xxUrl)
fun testRequest(@Field("xxUrl") nickname: String)

这个注解是如何能够透传到网络库中的内部拦截器呢。首先需要把在Interface中配置的注解获取出来。CallAdapter.Factory可以拿到网络请求中配置的注解。

override fun get(returnType: Type, annotations: Array<Annotation>, retrofit: Retrofit): CallAdapter<*, *>？ {}

我们可以在这里讲注解和同一个url的request的关联起来。 然后在拦截器中获取是否有对应的注解。

override fun intercept(chain: Interceptor.Chain): Response {
       val request = chain.request()
       if (!NetAnnotationUtil.isAnntationExsit(request, Encryption::class)) {
           return chain.proceed(request)
      }
       //do encrypt we want
      ...
}

调试工具

对于网络能力，我们经常会去针对网络接口进行调试。最简单的方式是通过charles抓包。 通过charles抓包我们可以做到哪些调试呢？

1. 查看请求参数、查看网络返回值

2. mock网络数据 看着上面2个能力似乎已经满足我们了日常调试了，但是它还是有一些缺陷的：

3. 必须要借助PC

4. 在App关闭了可抓包能力之后，就不能再抓包了

5. 无法针对于post请求参数区分

所以，我们需要有一个强大的网络调试能力，既满足了charles的能力， 也可以不借助PC，并且不论apk是否开启了抓包能力也能够允许抓包。 可以添加一个专门Debug网络拦截器，在拦截器中实现这个能力。

1. 把网络的debug文件配置在本地Sdcard下（也可以配置在远端统一的地址中）

2. 通过拦截器，进行url、参数匹配，如果命中，将本地json返回。否则，正常走网络请求。

data class GlobalDebugConfig(
    @SeerializedName("printToConsole") var printData: Boolean = false,
   @SeerializedName("printToPage") var printData: Boolean = false
)
data class NetDebugInfo(
       @SerializedName("filter") var debugFilterInfo: NetDebugFilterInfo?,
       @SerializedName("response") var responseString: Any?,
       @SerializedName("code") var httpCode: Int,
       @SerializedName("message") var httpMessage: String? = null,
       @SeerializedName("printToConsole") var printData: Boolean = true,
       @SeerializedName("printToPage") var printData: Boolean = true)

data class NetDebugFilterInfo(
       @SerializedName("host") var host: String? = null,
       @SerializedName("path") var path: String? = null,
       @SerializedName("parameter") var paramMap: Map<String, String>? = null)

首先日志输出有个全局配置和单个接口的配置，单接口配置优于全局配置。

• printToConsole表示输出到控制台

• printToPage表示将接口记录到本地中，可以在本地页面查看请求数据

其次filterInfo就是我们针对接口请求的匹配规则。

• host表示域名

• path表示接口请求地址

• parameter表示请求参数的值，如果是post请求，会自动匹配post请求的body参数。如果是get请求，会自动匹配get请求的query参数。

       val host = netDebugInfo.debugFilterInfo?.host
       if (!TextUtils.isEmpty(host) && UriUtils.getHost(request.url().toString()) != host) {
           return chain.proceed(request)
      }
       val filterPath = netDebugInfo.debugFilterInfo?.path
       if (!TextUtils.isEmpty(filterPath) && path != filterPath) {
           return chain.proceed(request)
      }
       val filterRequestFilterInfo = netDebugInfo.debugFilterInfo?.paramMap
       if (!filterRequestFilterInfo.isNullOrEmpty() && !checkParam(filterRequestFilterInfo, request)) {
           return chain.proceed(request)
      }
       val resultResponseJsonObj = netDebugInfo.responseString
       if (resultResponseJsonObj == null) {
           return chain.proceed(request)
      }
       return Response.Builder()
               .code(200)
               .message("ok")
               .protocol(Protocol.HTTP_2)
               .request(request)
               .body(NetResponseHelper.createResponseBody(GsonUtil.toJson(resultResponseJsonObj)))
               .build()

对于配置文件，最好能够共同维护mock数据。 本地可以提供mock数据展示列表。

组件化上网络库的能力支持

在组件化中，各个组件都需要使用网络请求。 但是在一个App内，都会有一套统一的网络请求的Header，例如AppInfo，UA，Cookie等参数。。在组件化中，针对这几个参数的配置有下面几个比较容易想到的解决方案：

1. 在各个组件单独配置这几个Header

• 每个组件都需要但单独配置Header，会存在很多重复代码

• 通用信息很大概率在各个组件中获取不到

1. 由主工程实现代理发起网络请求 这种实现方式也有下面几个缺陷

• 主工程需要关注所有组件，随着集成的组件越来越多，主工程需要初始化网络代理接口会越来越多

• 由于主工程并不知道组件什么时候会启动，只能App启动就初始化网络代理，导致组件初始化提前

• 所有直接和间接依赖的模块都需要由主工程来实现代理，很容易遗漏

通用信息拦截器自动注入

正因为上面两个实现方式或多或少都有问题，所以需要从网络库这一层来解决这个问题。 我们可以在网络层通过服务发现的能力，给外部提供一个通用网络信息拦截器注解, 一般由主工程实现, 完成默认信息的Header修改。创建网络Client实例时，自动查找app中被通用网络信息拦截器注解标注的拦截器。

线程池、连接池复用

各个组件都会有自己的网络Client实例，导致在同一个进程中，创建出来网络Client实例过多，同时线程池、连接池并没有复用。所以在网络库中，各个组件创建的网络Client默认会共享网络连接池和线程池，有特殊需要的模块，可以强制使用独立线程池和连接池。

作者：谢谢谢_xie
来源：juejin.cn/post/7074493841956405278

在android中，网络模块是一个不可或缺的模块，相信很多公司都会有自建的网络库。目前市面上主流的网络请求框架都是基于okHttp做的延伸和扩展，并且android底层的网络库实现也使用OkHttp了，可见okHttp应用的广泛性。

Retrofit本身就是对于OkHttp库的封装，它的优点很很多，比如注解来实现的，配置简单，使用方便等。那为什么我们要做二次封装呢？最根本的原因还是我们现有的业务过于复杂，我们期望有更多的自定义的能力，有更好用的使用方式等。就好比下面这些自定义的能力

1. 屏蔽底层的网络库实现

2. 网络层统一处理code码和线程回调问题

3. 网络请求绑定生命周期

4. 网络层的全局监控

5. 网络的调试能力

6. 网络层对于组件化的通用能力支持

这些目前能力目前如果直接使用Retrofit，基本都是满足不了的。 本文是基于Retrofit + OkHttp提供的基础能力上，做的网络库的二次封装。主要介绍下如何在retrofit和Okhhtp的基础上，提供上述几个通用的能力。 本文需要有部分okHttp和retrofit源码的了解。 有兴趣的可以先查看官方文档，传送门：

• OkHttp

• Retrofit

屏蔽底层的网络库实现

虽然Retrofit是一个非常强大的封装框架，但是它并没有完全把网路库底层的实现的屏蔽掉。 默认的内部网络请求使用的okHttp，在我们创建Retrofit实例的时候，如果需要配置拦截器，就会直接依赖到底层的OkHttp，导致上层业务直接访问到了网络库的底层实现。这个对于后续的网络库底层的替换会是一个不小的成本。 因此，我们希望能够封装一层网络层，让业务的使用仅仅依赖到网络库的封装层，而不会使用到网络库的底层实现。 首先，我们需要先知道业务层当前使用到了哪些网络库底层的API， 其实最主要的还是拦截器这一层的封装。 拦截器这一层，主要涉及到几个类：

1. Request

2. Response

3. Chain和Intercept 我们可以针对这几个类进行封装，定义对象接口，IRequest、IResponse、IChain和INetIntercept，这套接口不带任何具体实现。 然后在真正需要访问到具体的实例的时候，转化成具体的Request和Response等。我们可以看看在自己定义了一套拦截器之后，如何添加到之前OkHttp的流程中。 先看看IChain和INetIntercept的定义。

interface IChain {

    fun getRequestInfo(): IRequest

    @Throws(IOException::class)
    fun proceed(request: IRequest): IResponse?

}

interface INetInterceptor {
    @Throws(IOException::class)
    fun intercept(chain: IChain): IResponse?
}

在构造Retrofit的实例时，内部会尝试创建OkHttpClient，在此时把外部传入的INetInterceptor合并组装成一个OkHttp的拦截器,添加到OkHttpClient中。

 fun swicherToIntercept(list: MutableList<INetInterceptor>): Interceptor {
            return object: Interceptor  {
                override fun intercept(chain: Interceptor.Chain): Response? {
                    val netRequest = IRequest(chain.request())
                    val realChain = IRealChain(0, netRequest, list as MutableList<IInterceptor>, chain, this)
                    val response: Response?
                    return (realChain.proceed(netRequest) as? IResponse)?.response
                }
            }
        }

整体修改后的拦截器的调用链如下所示：

上面举的只是在构建拦截器中的隔离，如果你们项目还有访问到其他内部的OkHttp的能力，也可以参照上面的封装流程，定义接口，在需要使用的地方转换为具体实现。

Retrofit的Call自定义

对于Retrofit，我们在接口中定义的方法就是每一个请求的配置，每一个请求都会被包装成Call。我们想要的请求做一些通用的逻辑处理和自定义，就比如在请求前做一些逻辑处理，请求后做一些逻辑处理，最后才返回给上层，就需要hook这个请求流程，可以做Retrofit的二次动态代理。 如果希望做一些更精细化的处理，hook能力就满足不了了。这种时候，可以选择使用自定义Call对象。如果整个Call对象都是我们提供的，我们当然可以在里面实现任何我们期望的逻辑。接下来简单介绍下如何自定义Retrofit的Call对象。

定义Call类型

class TestCall<T>(internal var call: Call<T>) {}

自定义CallAdapter

自定义CallAdapter时，需要使用我们前面自定义的返回值类型，并将call对象转化为我们我们自定义的返回值类型。

 class NetCallAdapter<R>(repsoneType: Type): CallAdapter<R, TestCall<R>> {
      override fun adapt(call: Call<R>): TestCall<R> {
        return TestCall(call)
    }
      override fun responseType(): Type {
        return responseType
    }
 }

1. 首先需要在class的继承关系上，显式的标明CallAdapter的第二个泛型参数是我们自定义的Call类型。

2. 在adapt适配方法中，通过原始的call，转化为我们期望的TestCall。

自定义Factory

class NetCallAdapterFactory: CallAdapter.Factory() {
        override fun get(returnType: Type, annotations: Array<Annotation>, retrofit: Retrofit): CallAdapter<*, *>? {
        val rawType = getRawType(returnType)
        if (rawType == TestCall::class.java && returnType is ParameterizedType) {
            val callReturnType = getParameterUpperBound(0, returnType)
            return NetCallAdapter<ParameterizedType>(callReturnType)
        }
        return null
    }
}

在自定义的Factory中，根据从接口定义中获取到的网络返回值，匹配TestCall类型，如果匹配上，就返回我们定义的CallAdapter。

注册Factory

val builder = Retrofit.Builder()
    .baseUrl(retrofitBuilder.baseUrl!!)
    .client(client)
    .addCallAdapterFactory(NetCallAdapterFactory())

网络层统一处理code码和线程回调问题

code码统一处理

相信每一个产品都会定义业务错误码，每一个业务都可能有自己的一套错误码，有一些错误码可能是全局的，比如说登录过期、被封禁等，这种错误码可能跟特定的接口无关，而是一个全局的业务错误码，在收到这些错误码时，会有统一的逻辑处理。 我们可以先定义code码解析的接口

interface ICodehandler {
    fun handle(context: Context?, code: Int, message: String?, isBackGround: Boolean): Boolean
}

code码处理器的注册。

code码处理器的注册方式有两种，一种是全局的code码处理器。 在创建Retrofit实例的传入。

NetWorkClientBuilder()
        .addNetCodeHandler(SocialCodeHandler())
        .build()

另一种是在具体的网络请求时，传入错误码处理器，

TestInterface.inst.testCall().backGround(true)
        .withInterceptor(new CodeRespHandler() {
            @Override
            public boolean handle(int code, @Nullable String message) {
                  ....
            }
        })
        .enqueue(null)

code码处理的调用

因为Call是我们自定义的，我们可以在网络成功的返回时，优先执行错误码处理器，如果命中业务错误码，那么对外返回失败。否则正常返回成功。

线程回调

OkHttp的callback线程回调默认是在子线程，retrofit的回调线程取决于创建实例时的配置，可以配置callbackExecutor，这个是对整个实例生效的，在这个实例内，所有的网络返回都会通过callbackExecutor。我们希望能够针对每一个接口单独配置回调的线程，所以同样基于自定义call的前提下，我们自定义Callback和UiCallback。

• Callback: 表示当前回调线程无需主线程

• UICallback： 表示当前回调线程需要在主线程

通用业务传入的接口类型就标识了当前回调的线程.

网络请求绑定生命周期

大部分网络请求都是异步发起的。所以可能会导致下面两个问题：

• 内存泄漏问题

• 空指针问题

先看一个比较常见的内存泄漏的场景

class XXXFragment {

    var unBinder: Unbinder? = null
    
    @BindView(R.id.xxxx)
    val view: AView;
    
     @Override
    public void onDestroyView() {
        unBinder?.unbind();
    }
    
    override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {
      val view= super.onCreateView(inflater, container, savedInstanceState)
      unBinder = ButterKnife.bind(this, view)
      loadDataOfPay(1, 20)
      return view
    }
    
    private void testFun() {
        TestInterface.getInst().getTestFun()
                .enqueue(new UICallback<TestResponse>() {
                    @Override
                    public void onSuccessful(TestResponse test) {
                        view.xxxx = test.xxx
                    }

                    @Override
                    public void onFailure(@NotNull NetException e) {
                       ....
                    }
                }); 
    }
}

在上面的例子中，在testFun方法中编译后会创建匿名内部类，并且显式的调用了外部Fragment的View，一旦这个网络请求阻塞了，或者晚于这个Fragment的销毁时机回调，就会导致这个Fragment出现内存泄漏，直至这个请求正常结束返回。

更严重的是，这个被操作的view是通过ButterKnife绑定的，在Fragment走到onDestory之后就进行了解绑，会将这个View的值设置为null，导致在这个callback的回调时候，可能出现view为null的情况，导致空指针。 对于空指针的问题，我们可以看到有很多网络请求的回调都可能会出现类似下面的代码段。

 TestInterface.getInst().getTestFun()
                .enqueue(new UICallback<TestResponse>() {
                    @Override
                    public void onSuccessful(TestResponse test) {
                      if(!isFinishing() && view != null) {
                          view.xxxx = test.xxx
                      }  
                    }}); 

在匿名内部类回调时，通过判断页面是否已经销毁，以及view是否为空，再进行对应的UI操作。 我们通过动态代理来解决了这个空指针和内存泄漏的问题。 详细的方案可以阅读下这个文章匿名内部类导致内存泄漏的解决方案 因为我们把Activity、Fragment抽象为UIContext。在网络接口调用时，传入对应的UIContext，会将网络请求的Callabck通过动态代理，将Callback和UIContext进行关联，在页面销毁时，不进行回调。

自动Cancel无用请求

很多的业务场景中，在页面一进去就会触发很多网络请求，这个请求可能有一部分处于网络库的请求等待队列中，一部分处于进行中。当我们退出了这个页面之后，这些网络请求其实都已经没有了存在的意义。 所以我们可以在页面销毁时，取消还未发起和进行中的网络请求。 我们可以通过上面提过的UIContext，将网络请求跟页面进行关联。监听页面的生命周期，在页面关闭时，cancel掉对应的网络请求。

页面关联

在网络请求发起前，把当前的网络请求关联上对应的页面。

class TestCall {
    fun  enqueue(uiCallBack: Callback, uiContext: UIContext?) {
          LifeCycleRequestManager.registerCall(this, uiContext)
     ....
    }
    
}

internal object LifeCycleRequestManager {

    init {
        registerApplicationLifecycle()
    }
    private val registerCallMap = ConcurrentHashMap<Int, MutableList<BaseNetCall>>()

    }

ConcurrentHashMap的key为页面的HashCode，value的请求list。每一个页面都会关联一个请求List。

cancel请求

通过Application监听Activity、Fragment的生命周期。在页面销毁时，调用cancel取消对应的网络请求。

  private fun registerActivityLifecycle(app: Application) {
        app.registerActivityLifecycleCallbacks(object : Application.ActivityLifecycleCallbacks {
            override fun onActivityDestroyed(activity: Activity?) {
                registerCallMap.remove(activity.hashCode())
            }})
    }

这个是针对Activity的生命周期的监听。对于Fragment的生命周期的监听其实和Activity类似。

    private fun registerActivityLifecycle(app: Application) {
        app.registerActivityLifecycleCallbacks(object : Application.ActivityLifecycleCallbacks {
            override fun onActivityCreated(activity: Activity?, savedInstanceState: Bundle?) {
                (activity as? FragmentActivity)?.supportFragmentManager
                        ?.registerFragmentLifecycleCallbacks(fragmentLifecycleCallbacks, true)
            }})
    }

网络监听

网络模使用的场景非常多，当前出现问题的概率也更好，网络相关的问题非常多，比如网络异常、DNS解析失败、连接超时等。所以一套完善网络流程监控是非常有必要的，可以帮助我们在很多问题中快速分析出问题，提高我们的排查问题的效率

网络流程监控

根据OkHttp官方的EventListener提供的回调：OkHttpEvent事件，我们定义了以下几个一个网络请求中可能 触发的Action事件。

enum class NetEventType {
    EN_QUEUE, //入队
    NET_START, //网络请求真正开始执行
    DNS_START, //开始DNS解析
    DNS_END, //DNS解析结束
    CONNECT_START, //开始建立连接
    TLS_START, // TLS握手开始
    TLS_END, //TLS握手结束
    CONNECT_END, //建立连接结束
    RETRY, //尝试重新连接
    REUSE, //连接重用，从连接池中获取到连接
    CONNECTION_ACQUIRE, //获取到链接（可能不走连接建立，直接从连接池中获取）
    CONNECT_FAILED, // 连接失败
    REQUEST_HEADER_START, // request写Header开始
    REQUEST_HEADER_END, // request写Header结束
    REQUEST_BODY_START, // request写Body开始
    REQUEST_BODY_END, // request写Body结束
    RESPONSE_HEADER_START, // response写Header开始
    RESPONSE_HEADER_END, // response写Header结束
    RESPONSE_BODY_START, // response写Body开始
    RESPONSE_BODY_END, // response写Body结束
    FOLLOW_UP, // 是否发生重定向
    CALL_END, //请求正常结束
    CONNECTION_RELEASE, // 连接释放
    CALL_FAILED, // 请求失败
    NET_END, // 网络请求结束（包括正常结束和失败）

}

可以看到，除了okHttp原有的几个Event，还额外多了一个ENQUEUE事件。这个时机最主要的作用是计算出请求从调用到真正发起接口请求的等待时间。 当我们调用了RealCall.enqueue方法时，实际上这个接口请求并不是都会立即执行，OkHttp对于同一个时刻的请求数有限制。

• 同一个Dispatcher，同一时刻并发数不能超过64

• 同一个Host，同一时刻并发数不能超过5

 private final Deque<AsyncCall> readyAsyncCalls = new ArrayDeque<>();
 private final Deque<AsyncCall> runningAsyncCalls = new ArrayDeque<>();
 
   synchronized void enqueue(AsyncCall call) {
    if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) {
      runningAsyncCalls.add(call);
      executorService().execute(call);
    } else {
      readyAsyncCalls.add(call);
    }
  }

所以一旦超过对应的阈值，当次请求就会被添加到readyAsyncCalls中，等待被执行。

根据这几个Action，我们可以将统计的时间分为下面几个阶段

enum class NetRecordItemType {
    WAIT, // 等待时间，入队到真正开始执行耗时
    DNS, // DNS耗时
    TLS, // TLS耗时
    RequestHeader, // request写入Header耗时
    RequestBody, // request写入Body耗时
    Request, // request写入header和body总耗时
    NetworkLatency, // 网络请求延时
    ResponseHeader, // response写入Header耗时
    ResponseBody, // response写入Body耗时
    Response, // response写入header和body总耗时
    Connect, // 连接建立总耗时
    RequestAndResponse, // 数据传输耗时
    CallTime, // 单次网络请求总耗时(包含排队时间)
    UNKNOWN
}

唯一ID

我们不仅仅想对整个网络的大盘进行监控，我们还希望能够精细化到每一个独立的网络请求进行监控。针对单个网络请求进行的监控的难点是我们如何去标志出来每一个网络请求,因为EventListener回调只会返回对应的call。

public abstract class EventListener {
    public void callStart(Call call) {}
    
    public void callEnd(Call call) {}
}

而这个Call没有办法与单个监控的请求进行关联。 并且在网络请求发起的阶段就需要标识出来，所以需要在Request创建的最前头就生成这个唯一ID。通过阅读源码，我们发现可以生成唯一id最早时机是在OkHttp的RealCall创建的最前头。

  RealCall(OkHttpClient client, Request originalRequest, boolean forWebSocket) {
    final EventListener.Factory eventListenerFactory = client.eventListenerFactory();

    this.client = client;
    this.originalRequest = originalRequest;
    this.forWebSocket = forWebSocket;
    this.retryAndFollowUpInterceptor = new RetryAndFollowUpInterceptor(client, forWebSocket);

    this.eventListener = eventListenerFactory.create(this);
  }

其中，eventListenerFactory是由外部传递到Okhttp中的。

 public Builder eventListenerFactory(EventListener.Factory eventListenerFactory) {
      if (eventListenerFactory == null) {
        throw new NullPointerException("eventListenerFactory == null");
      }
      this.eventListenerFactory = eventListenerFactory;
      return this;
    }

因此，我们可以在EventListener.Factory中生成标记request的唯一Id。

internal class CallEventFactory(var configuration: CallEventConfiguration?) : EventListener.Factory {
    companion object {
        private val nextCallId = AtomicLong(1L)
    }

    override fun create(call: Call): EventListener {
         val callId = nextCallId.getAndIncrement()
    }
}

那生成的callId如何与request进行关联呢？最直接的是给Request添加一个Header的key。Request本身没有提供Api去修改Header。 所以这个时候就需要通过反射来设置, 先获取当前的Header，然后给header新增这个CallId，最后通过反射设置到request的header字段上。

fun appendToHeader(request: Request?, key: String?, value: String?) {
    key ?: return
    request ?: return
    value ?: return
    val headerBuilder = request.headers().newBuilder().add(key, value)
    ReflectUtils.setFieldValue(Request::class.java, request, NetCallAdapter.HEADER_NAME, headerBuilder.build())
    }

需要注意的是，因为使用了反射，所以需要在proguard文件中keep住request。 当然这个key最好能够不带到服务端，所以需要新增一个拦截器，添加到所有拦截器最后，这个这个唯一id的key就不会被添加到真正的请求上了。

class NetLastInterceptor: Interceptor {
    companion object {
        const val TAG = "NetLastInterceptor"

    }
    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain.request()
        val requestBuilder = request
                .newBuilder()
                .removeHeader(NetConstants.CALL_ID)
      
        return chain.proceed(requestBuilder.build())
    }
}

监控

在生成完唯一Id之后，我们再来看看如何外部是如何添加期望的网络监控的。

基于Client的监控

networkClient = NetWorkClientBuilder()
    .addLifecycleListener("*", object : INetLifecycleListener {
        override fun onLifecycle(info: INetLifecycleInfo) {  }})
    .registerEventListener("xxxUrl", NetEventType.CALL_END, object : INetEventListener {
        override fun onEvent(event: NetEventType, request: NetRequest) { }})
        .build()

基于单个请求的监控