注册
环信即时通讯云

环信即时通讯云

单聊、群聊、聊天室...
环信开发文档

环信开发文档

环信FAQ

环信FAQ

集成常见问题及答案
RTE开发者社区

RTE开发者社区

汇聚音视频领域技术干货,分享行业资讯
技术讨论区

技术讨论区

技术交流、答疑
资源下载

资源下载

收集了海量宝藏开发资源
iOS Library

iOS Library

不需要辛辛苦苦的去找轮子, 这里都有
Android Library

Android Library

不需要辛辛苦苦的去找轮子, 这里都有

拯救强迫症!前端统一代码规范

web
1. 代码格式化 1.1 工具介绍 ESLint 是一款用于查找并报告代码中问题的工具 Stylelint 是一个强大的现代 CSS 检测器 Prettier 是一款强大的代码格式化工具,支持多种语言 lint-staged 是一个在 git 暂存文件上运...
继续阅读 »

1. 代码格式化


1.1 工具介绍


Untitled 1.png



  • ESLint 是一款用于查找并报告代码中问题的工具

  • Stylelint 是一个强大的现代 CSS 检测器

  • Prettier 是一款强大的代码格式化工具,支持多种语言

  • lint-staged 是一个在 git 暂存文件上运行 linters 的工具

  • husky 是 Git Hook 工具,可以设置在 git 各个阶段触发设定的命令


1.2 配置说明


1.2.1 ESLint 配置


在项目根目录下增加 .eslintrc.js 文件进行配置,配置项详见官方文档,以下为参考配置:


npm i -D eslint eslint-plugin-vue eslint-plugin-import eslint-import-resolver-typescript @typescript-eslint/parser @typescript-eslint/eslint-plugin prettier eslint-plugin-prettier eslint-config-prettier

module.exports = {
// 此项是用来告诉 eslint 找当前配置文件不能往父级查找
root: true,
// 全局环境
env: {
browser: true,
node: true,
},
// 指定如何解析语法,eslint-plugin-vue 插件依赖vue-eslint-parser解析器
parser: "vue-eslint-parser",
// 优先级低于parse的语法解析配置
parserOptions: {
// 指定ESlint的解析器
parser: "@typescript-eslint/parser",
// 允许使用ES语法
ecmaVersion: 2020,
// 允许使用import
sourceType: "module",
// 允许解析JSX
ecmaFeatures: {
jsx: true,
},
},
extends: [
"eslint:recommended", // 引入 ESLint的核心功能并且报告一些常见的共同错误
"plugin:import/recommended", // import/export语法的校验
"plugin:import/typescript", // import/export 语法的校验(支持 TS)
// 'plugin:vue/essential' // vue2 版本使用
// 'plugin:vue/recommended', // vue2 版本使用
"plugin:vue/vue3-essential", // vue3 版本使用
"plugin:vue/vue3-recommended", // vue3 版本使用
"plugin:@typescript-eslint/recommended",
"prettier", // prettier 要放在最后!
],
plugins: ["prettier"],
rules: {
"prettier/prettier": "error",
"@typescript-eslint/explicit-module-boundary-types": "off",
"no-undef": "off",
// 更多规则详见:http://eslint.cn/docs/rules/
},
settings: {
"import/parsers": {
"@typescript-eslint/parser": [".ts", ".tsx"],
},
"import/resolver": {
typescript: {
alwaysTryTypes: true,
},
},
},
};

💡当 ESLint 同时使用 prettier 的时候,prettier 和 ESLint 可能存在一些规则冲突,我们需要借助 eslint-plugin-prettiereslint-config-prettier 进行解决,在安装完依赖包后在 .eslintrc.js 配置文件中进行添加如下内容:


module.exports = {
"extends": [
// 其他扩展内容...
"prettier" // prettier 要放在最后!
],
"plugins": ["prettier"],
"rules": {
"prettier/prettier": "error"
},
}

1.2.2 StyleLint 配置


在项目根目录下增加 .stylelintrc.js 文件进行配置,配置项详见官方文档,以下为参考配置:


npm i -D stylelint stylelint-config-standard stylelint-order stylelint-config-rational-order prettier stylelint-prettier stylelint-config-prettier postcss-html postcss-less stylelint-config-recommended-vue

module.exports = {
extends: [
'stylelint-config-standard', // 官方 stylelint 规则
'stylelint-config-rational-order', // 属性排列顺序规则
/*
* 通过安装 stylelint-prettier,设置 'stylelint-prettier/recommended',其包含了三个操作
plugins: ['.'],
extends: ['stylelint-config-prettier'], // 需要安装 stylelint-config-prettier
rules: {'prettier/prettier': true},
*/

'stylelint-prettier/recommended',
],
plugins: [
'stylelint-order', // CSS 属性排序
],
rules: {
// 更多规则详见:https://stylelint.io/user-guide/rules/list
},
};

💡当 StyleLint 同时使用 prettier 的时候,prettier 和 StyleLint 可能存在一些规则冲突,我们需要借助 stylelint-prettierstylelint-config-prettier 进行解决,在安装完依赖包后在 .stylelintrc.js 配置文件中进行添加如下内容:


module.exports = {
extends: [
/*
* 通过安装 stylelint-prettier,设置 'stylelint-prettier/recommended',其包含了三个操作
plugins: ['.'],
extends: ['stylelint-config-prettier'], // 需要安装 stylelint-config-prettier
rules: {'prettier/prettier': true},
*/

'stylelint-prettier/recommended',
],
};

1.2.3 Prettier 配置


在项目根目录下增加 .prettierrc.js 文件进行配置,配置项详见官方文档,以下为参考配置:


npm i -D prettier

module.exports = {
// 更多规则详见:https://prettier.io/docs/en/options.html
printWidth: 120, // 单行长度
tabWidth: 2, // 缩进长度
useTabs: false, // 使用空格代替tab缩进
semi: true, // 句末使用分号
singleQuote: true, // 使用单引号
bracketSpacing: true, // 在对象前后添加空格-eg: { foo: bar }
quoteProps: 'consistent', // 对象的key添加引号方式
trailingComma: 'all', // 多行时尽可能打印尾随逗号
jsxBracketSameLine: true, // 多属性html标签的‘>’折行放置
arrowParens: 'always', // 单参数箭头函数参数周围使用圆括号-eg: (x) => x
jsxSingleQuote: true, // jsx中使用单引号
proseWrap: 'preserve',
htmlWhitespaceSensitivity: 'ignore', // 对HTML全局空白不敏感
};

1.2.4 husky 和 lint-staged 配置


step1. 初始化 husky


npx husky-init && npm install

step2. 在 .husky/pre-commit 文件中进行修改(注意区别 husky@7 与 husky@4 的设置方式)


#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

step3. 安装 lint-statged 并在 package.json 中进行设置


npm i -D lint-staged

{
"lint-staged": {
"*.{js,ts,vue}": [
"eslint --fix",
"prettier --write",
"git add"
],
"*.{css,less,vue}": [
"stylelint --fix",
"prettier --write",
"git add"
]
}
}

1.3 使用参考



  1. 代码提交:根据上述工具配置,代码在提交仓库时进行检查和格式化,实现代码风格统一;

  2. 本地保存:在 VSCode 中进行配置,使得代码在保存的时候即按照相应的规则进行格式化;



如何在 VSCode 中进行配置使得能够自动按照相应的规则进行格式化呢?接下来进入第二章《编辑器配置》。



2. 编辑器配置


2.1 VSCode 配置


2.1.1 配置内容


Untitled.png


所有 VSCode 配置自定义的内容(包括插件部分)都在 setting.json 文件中,以下为参考配置:


{
"editor.tabSize": 2,
"window.zoomLevel": 0,
"editor.fontSize": 14,
"editor.formatOnPaste": true,
"editor.formatOnSave": true,
"editor.multiCursorModifier": "ctrlCmd",
"editor.snippetSuggestions": "top",
"eslint.codeAction.showDocumentation": {
"enable": true
},
"eslint.run": "onSave",
"eslint.format.enable": true,
"eslint.options": {
"extensions": [
".js",
".vue",
".ts",
".tsx"
]
},
"eslint.validate": [
"javascript",
"typescript",
"vue"
],
"stylelint.validate": [
"css",
"less",
"postcss",
"scss",
"sass",
"vue",
],
// 保存时按照哪个规则进行格式化
"editor.codeActionsOnSave": {
"source.fixAll": true,
"source.fixAll.eslint": true
},
"files.autoSave": "afterDelay", // 文件自动保存
"files.autoSaveDelay": 2000, // 2s 后文件自动保存
}

参考资料: VS Code 使用指南VS Code 中 Vetur 与 prettier、ESLint 联合使用


2.1.1 插件推荐



  1. Eslint: Integrates ESLint JavaScript int0 VS Code

  2. stylelint: Official Stylelint extension for Visual Studio Code

  3. Prettier: Code formatter using prettier

  4. EditorConfig: EditorConfig Support for Visual Studio Code

  5. Npm Intellisense: VS Code plugin that autocompletes npm modules in import statements

  6. Path Intellisense: VS Code plugin that autocompletes filenames

  7. Auto Rename Tag: Auto rename paired HTML/XML tag

  8. Auto Close Tag: Automatically add HTML/XML close tag

  9. Code Spelling Checker: Spelling checker for source code

  10. Volar / Vetur: Language support for Vue 3 / Vue tooling for VS Code


2.2 EditorConfig 配置


EditorConfig 的优先级高于编辑器自身的配置,因此可用于维护不同开发人员、不同编辑器的编码风格。在项目根目录下增加 .editorconfig 文件进行配置即可,以下为参考配置:


# Editor configuration, see http://editorconfig.org

# 表示是最顶层的 EditorConfig 配置文件
root = true

[*] # 表示所有文件适用
charset = utf-8 # 设置文件字符集为 utf-8
indent_style = space # 缩进风格(tab | space)
indent_size = 2 # 缩进大小
end_of_line = lf # 控制换行类型(lf | cr | crlf)
insert_final_newline = true # 始终在文件末尾插入一个新行
trim_trailing_whitespace = true # 去除行尾的任意空白字符

3. Commit Message 格式化


3.1 工具介绍


Conventional Commits 约定式提交规范是一种用于给提交信息增加人机可读含义的规范,可以通过以下工具来进行检查、统一和格式化:



  • commitlint:检查您的提交消息是否符合 conventional commit format

  • commitizen:帮助撰写规范 commit message 的工具

  • cz-customizable:自定义配置 commitizen 工具的终端操作

  • commitlint-config-cz:合并 cz-customizable 的配置和 commitlint 的配置


3.2 配置说明


3.2.1 格式化配置


step1. 安装 commitizen 和 cz-customizable


npm install -D commitizen cz-customizable

step2. 在 package.json 添加以下内容:


{
"config": {
"commitizen": {
"path": "node_modules/cz-customizable"
}
}
}

step3. 在项目根目录下增加 .cz-config.js 文件进行配置即可,以下为参考配置:


module.exports = {
// type 类型
types: [
{ value: 'feat', name: 'feat: 新增功能' },
{ value: 'fix', name: 'fix: 修复 bug' },
{ value: 'docs', name: 'docs: 文档变更' },
{ value: 'style', name: 'style: 代码格式改变(不影响功能)' },
{ value: 'refactor', name: 'refactor: 代码重构(不包括 bug 修复、功能新增)' },
{ value: 'perf', name: 'perf: 性能优化' },
{ value: 'test', name: 'test: 添加或修改测试用例' },
{ value: 'build', name: 'build: 构建流程或外部依赖变更' },
{ value: 'ci', name: 'ci: 修改 CI 配置或脚本' },
{ value: 'chore', name: 'chore: 对构建过程或辅助工具和库的更改(不影响源文件、测试用例)' },
{ value: 'revert', name: 'revert: 回滚 commit' },
],
// scope 类型
scopes: [
['components', '组件相关'],
['hooks', 'hook 相关'],
['utils', 'utils 相关'],
['styles', '样式相关'],
['deps', '项目依赖'],
// 如果选择 custom,后面会让你再输入一个自定义的 scope。也可以不设置此项,把后面的 allowCustomScopes 设置为 true
['custom', '以上都不是,我要自定义'],
].map(([value, description]) => {
return {
value,
name: `${value.padEnd(30)} (${description})`,
};
}),
// 交互提示信息
messages: {
type: '确保本次提交遵循 Angular 规范!\n选择你要提交的类型:',
scope: '选择一个 scope(可选):\n',
customScope: '请输入自定义的 scope:\n', // 选择 scope: custom 时会出现的提示
subject: '填写简短精炼的变更描述:\n',
body: '填写更加详细的变更描述(可选)。使用 "|" 换行:\n',
breaking: '列举非兼容性重大的变更(可选):\n',
footer: '列举出所有变更的 ISSUES CLOSED(可选):\n',
confirmCommit: '是否确认提交?',
},
// 设置只有 type 选择了 feat 或 fix,才询问 breaking message
allowBreakingChanges: ['feat', 'fix'],
// subject 限制长度
subjectLimit: 100,
};

step4. 新增 husky 配置,使得提交 commit message 时触发 commitizen,快捷命令如下:


npx husky add .husky/prepare-commit-msg "exec < /dev/tty && node_modules/.bin/cz --hook || true"

注意,commitizen 如果是全局安装,则使用下面的快捷命令:


npx husky add .husky/prepare-commit-msg "exec < /dev/tty && git cz --hook || true"

3.2.2 格式检查配置


step1. 安装 commitlint 和 commitlint-config-cz ****依赖:


npm install --save-dev @commitlint/{config-conventional,cli} commitlint-config-cz

step2. 在项目根目录下增加 commitlint.config.js 文件进行配置即可,以下为配置内容:


module.exports = {
extends: ['@commitlint/config-conventional', 'cz'],
rules: {},
};

step3. 新增 husky 配置,使得提交 commit message 时触发 commitlint 检验,配置内容如下:


npx husky add .husky/commit-msg 'npx --no -- commitlint --edit "$1"'

3.3 使用参考


在命令行输入 git commit,然后根据命令行提示输入相应的内容,完成之后则会自动生成符合规范的 commit message,从而实现提交信息的统一。


4. 代码规范参考


4.1 JS/TS 规范


社区类代码风格:



工具类代码风格:



4.2 CSS 规范


社区类代码风格:



工具类代码风格



4.3 VUE 规范


推荐阅读 Vue 官方风格指南:Vue2 版本Vue3 版本,其他可参考 eslint-plugin-vue


作者:植物系青年
来源:juejin.cn/post/7278575483909799947
收起阅读 »

APP端上通用安全体系建设

背景:APP端上安全在谈什么 APP的每个业务场景都有其既定的运行模式,若被人为破坏就可认为是不安全的。举个栗子,比如秒杀场景:大量用户在特定时间点,通过点击抢购来秒杀优惠商品,从而营造一种紧迫而有噱头的营销场景,但如果能通过非法手段自动抢购、甚至提前开始刷接...
继续阅读 »

背景:APP端上安全在谈什么


APP的每个业务场景都有其既定的运行模式,若被人为破坏就可认为是不安全的。举个栗子,比如秒杀场景:大量用户在特定时间点,通过点击抢购来秒杀优惠商品,从而营造一种紧迫而有噱头的营销场景,但如果能通过非法手段自动抢购、甚至提前开始刷接口抢购,那就彻底破坏了业务的玩法,这就是一种不安全的运行模式。再比如常用的用户拉新场景:新客获取成本高达200左右,所有产品的拉新投入都蛮高,如何获得真正的新用户而不是羊毛党也是拉新必须处理的事,一般而言,新设备+新账户是新用户的基本条件,但新账户的成本其实不高,大部分是要靠新设备来识别的,但如果能通过非法手段不断模拟新设备,那拉新投入获取的可能大部分都是无效的羊毛党,这也可看做是一种不安全的运行场景,甚至还有二次篡改,构建马甲APP等各种场景。而APP端上安全要做的就是甄别并防范这种异常场景的发生,简而言之它就是:一种确保官方APP既定业务模型中运行的能力。


APP端上安全体系应该具备哪些能力


一个安全体系要具备哪些能力呢,简单说可分两块:甄别与防御。即一:甄别运行环境是否安全的能力,二:针对不同的场景作出不同的防御的能力,场景千变万化,所以防御手段也没有一剑破万法的能力,基本都要根据具体的风险场景,产出不同的应对方案,但是整体涉及的流程基本一致,如下:


image.png


要做的事情就是围绕四个阶段构建不同的能力。先看第一阶段:风险场景的假设,预判有哪些风险场景,从AppStore或者官方应用市场下载,安装、正常使用,这是理想中的运行模式,但不安分的用户千千万,异常场景也多变,不存在一剑破万法的说法,这里人为做了一些场景归类:


image.png


从实践来看,安全模型必须覆盖的场景包含上述四类,即



一: 运行的APP非官方应用



这种情况一般是非法用户为了谋求特定的权益,对原装APP进行魔改二次打包后发布,这对于一些广告类、离线付费类APP是一种毁灭性的打击,最常见的就是一些APP会在闪屏页面投放广告,从而获取收益,但一旦这个业务逻辑被篡改绕过,那么广告收益直接归零;还有些情况APP被碰瓷,魔改一些功能,跳转到非官方设定的网站,比如在比较火的APP添加劫持逻辑,跳转到一些黄赌网站,这给官方APP带来的负面影响是难易估量的,如果不能自证清白,甚至还会面临法律上的追责。



二:业务的运转模型被篡改



简单的讲就是没有按照产品的既定玩法进行,就像文章开头的秒杀场景【电商平台的茅台抢购】,如果能通过API直接组单,那APP里点击的那批用户无论如何也抢不过插件;再比如有些签到的场景是为了促活,如果通过自动签到工具自动打卡,那促活的目的也无法达到,这也是要重点防控的一个场景。



三:运行的设备非目标设备



这种场景主要影响一些拉新、优惠权益等,甚至直接影响整体运营策略,简单举个例子,拉新场景中会投放大量的新人免单、直减券,基本等于免费领取权益,比如我们都经历过的打车软件、外卖软件、新电商产品上线等。全国有无数的专业羊毛党专注于这一场景,他们掌握大量手机号,可以注册大量新账号,同时能通过虚拟机、应用多开、复刻设备等手段无限冒充新设备,如果不加反制,优惠策略一上线,各种券基本全被这批人掠夺,被这种手段折磨致死的产品数不胜数,也几乎是每个电商平台的噩梦。



四:一些核心逻辑的泄漏



这不是端上特有的风险,比如代码泄漏这种,各方都有这种风险,只不过端上风险更高,因为APP是要上架发出去的,虽然经历过各种混淆与保护,但是用户最终还是能拿到可执行的APP包的,里面各种的核心的逻辑、秘钥都有潜在泄漏的风险,一旦泄漏,也是一种毁灭性的打击,比如某些音视频软件特有滤镜、转场、特效,这些算法是一个产品的核心,一旦破解,产品优势不再,如果防止逻辑代码的泄漏与破解也是安全必须关注的点。


覆盖上述场景的意思是要提供甄别的能力,针对不同的场景,抽象特征值并搜集上报,建立特定的模型,推导C端操作环境是否安全,之后上线不同的应对策略:比如直接退出应用、标记为风险用户等。


建设方案


甄别与防御是体系的核心,建设方案主要是围绕这两个主题展开,虽说名称是“端上安全体系”,但只依靠端自己是无法解决所有问题的,也无法将价值发挥到最大,仍需多端系统配合来完成整个体系的搭建,分工的基本原则是:端上侧重特征信息的搜集,云端负责整体策略的执行,根据上述场景,搭建示意如下:


image.png


按层次跟功能大致分四块,端、网关、业务后台、数据风控中心:



  • 端是信息的来源,负责信息采集上报,是安全体系建设的基石,所以端上采集信息的真实性、为完整性至关重要,同时端上也可以执行部分风险低,但收益高的拦截略,比如对于一些已经侦测到的马甲包,在上报用户信息之后,可以选择Crash,对于一些机器点击类的签到、秒杀场景,可以主动拦截请求,降低带宽压力。

  • 网关是第二层,一般处理一些具体规则类的拦截与信息采集,比如有些简单的规则检验,Header里是否携带必备的校验字段,如多开标识、模拟器标志等,如果携带则可以在这一层直接拦截,并沉淀到数据中心,既保证了信息的采集,又能减轻业务后台的压力,尤其对于一些秒杀类的场景非常有效。

  • 业务后台跟数据平台可以一起看做第三层,负责更复杂的模型建设跟业务落地,比如在什么样的节点,才有什么样的策略,比如在组单的时候,业务后台可根据风控侧的判断决定用户的优惠力度等


针对各个具体的场景会有具体的建设方案,



如何应对非官方APP:APP包识别



非法人员总是出于自己的权益来破解官方APP,定制一些逻辑再二次打包发布,比如对一些付费类APP,含广告类工具APP等,通过破解代码,并二次打包后就可以官方造成冲击,甚至是毁灭性的打击,对于这种场景如何甄别,又如何处理呢?拿Android为例,检测手段有签名校验、文件校验、包完整性校验等,一旦检测到风险就可以做出响应处理,在处理方式上也需要根据不同产品不同场景随机变动,比如工具类APP就Crash阻断,而对于一些有用户体系类的APP则可以先回传用户信息,用作用户画像,再做响应的处理,而处理的手段也可以根据风险等级的不同再做定制,甄别的技术手段可能是死的,但获取的收益一定要灵活。



如何应对非理想设备:设备识别与设备指纹



非理想设备最经典的就是文章开头的场景,拉新拉来一堆老羊毛党,说到底其实就是对于用户设备的定位追踪能力不足,对于这种场景的如何应对?这里单独说说设备指纹,设备指纹主要解决的如何定位一台设备的问题,在理想情况下,一台设备只有一个身份信息,它不因APP卸载、升级、HOOK伪装所改变,这在现在的互联产品生态中是非常困难的,困难主要来源于两个方面:一技术上的、一是法规上的,从技术上来讲,以Android端为例,它是一个开源的系统,每一行代码都不可信,任何通过官方API拿到的信息都可以被HOOK篡改,而指纹很大程度依赖API获得的设备特征信息,如果这些信息都不可信,那指纹的可信程度也会降低。另一方面,从法规上来讲,现在注重保护个人隐私,不可以随意获取用户信息,这一点有利于用户【包括羊毛党】,但是对于运营方却是不利的,信息越少越难定位到,因此,在隐私合规的前提下,仍需要多维度的获取更多的用户信息,从更多的维度定位到该用户。


具体如何执行?以Android为例,定位一台设备的信息有MAC、IMEI、IMSI、序列号、AndroidID、IP+UA、OAID、各种设备型号等,虽然信息很多,但单独任何一条的可信度都不高,比如之前的某盾、某盟都曾用MAC地址作为指纹,甚至有些产品直接用IMEI作为指纹,但网上利用XPOSED来篡改的插件比比皆是,通过官方API获取的分分钟被破解,但是可以对多种信息进行整合生成一个唯一可信的ID,这种方式获取的ID的稳定性要比单一的稳定性要高,原理示意如下:


image.png


简单来说:只有篡改了全部的设备特征信息,才会导致设备指纹更新,这会大幅提高设备逃逸的难度。设备指纹的另一个难题是如何识别虚拟设备,这里特指模拟器,每个新开的模拟器都可以看做是新设备,如果不能识别,同样无法解决设备跟踪的问题,尤其对于国内的Android生态来讲,问题更加严重,各种游戏厂商都有对应的手游模拟器,不仅支持多开,还原生支持篡改各种设备特征信息,可以算得上助纣为虐,在模拟器甄别与防控的层面能做的有如下几种:



  • 通过特征信息甄别【容易绕过】

  • 通过CPU架构甄别【ARM与SimpleX86】

  • 限定APP的运行平台


这里简单介绍下通过CPU架构甄别方式,就目前的硬件市场,几乎99.9%以上的手机设备都是基于ARM处理,而模拟器大部分是面向x86平台设计的,采用的是simplex86架构,两者采用的不一样缓存机制,ARM采用的哈弗架构将指令存储跟数据存储分开,分为I-Cache(指令缓存)与D-Cahce(数据缓存),CPU无法直接修改I-Cache【同步延迟导致不一致】,但Simpled X86架构的模拟器只有一块缓存,这一点导致两者在运行Self-Modifying Code【自修改代码】时会有不同的表现,可以借助这个特性进行甄别,示意如下


image.png


至此,设备的定位与跟踪能力基本已经具备,在用户在领券的节点,就可以从更多维度判断他当前的设备是否有资格享受这个权益,保障业务按既定模型运转。


image.png


当然还有更多的场景,比如应用多开、应用分身等,都要具体问题具体分析,但思路一致:特征搜集、甄别、防控,因为所有的不轨行为一定有迹可循,



如何应对非设定业务场景:场景识别与校验



每种业务都有其既定的运行模式,只有照章办事,运营才能获取最大的收益,这里特指一些可以通过自己的参与获得收益的场景,比如秒杀、签到、预约摇号等。一般而言,在这类场景下,破坏者可钻的空子有两个方向,一个是便利:通过插件自动预约,免得用户自己操作,适合摇号、签到类【签到领积分】;一个是速度,通过插件直接API请求,抢跑下单,获得收益,适合限时秒杀类的场景【各大平台强茅台】。以秒杀为例,通过营造紧迫而又刺激的氛围可以让活动更有意思,但如果能直接刷接口/或者通过插件抢跑,那就会破坏其公平性,影响用户的参与感,造成资产及口碑受损,这类场景如何应对?其实要做的事情分两块:一 识别请求是从APP发出来 , 二 识别是真实用户操作的,这两快一般会整体考虑,非APP端的请求往往伴随着非用户触发,多归结于脚本,所以识别“人”与识别“场景”殊途同归,具体有哪些手段可以用呢?



  • 扩展核心API接口的能力,承载更多逻辑

  • 通过埋点、用户操作轨迹分析识别用户

  • 启用端上特有能力校验,如短信验证码、行程码分析


如何拓展API接口的能力?比如预约接口其基础能力就是预约,如不特殊处理,PC上就完全可以复制APP端发出的请求,进而通过脚本预约,如要加以限制就必须拓展端上API能力,让其携带更多端上独有特征,同时服务端可以完成校验,形成一个闭环,比较容易理解的就是让APP端与服务端协商一套加解密通信协议,并假定协议无法破解,避免接口直刷,从而确保请求是从APP发出的,即使不是从APP发出的,也能被甄别出来,进而提高APP与服务端通信阶段的安全性。当然,无法破解只是理论上,实际上只要舍得投入成本,暴力破解并不是问题,这种就需要通过更多元的手段,不断更新迭代,持续做攻防,例如,为了保证加密算法的保密性,可以将其用c实现,并通混淆、加固、防探测等手段保证这个策略的正确执行;暴力堆积加密的类型、节点,提升秘钥的更新频率也是一种应对手段,而且,惩罚手段上也可以多元,同直接拦截相比,隐秘的搜捕,诱捕也是一种灵活收益的手段。


其次,基于埋点、用户操作行为的大数据分析是另一种更高级的防御手段,对于识别用户操作场景更加科学,正常的用户轨迹与插件类的访问轨迹会有很大的差异,直刷的目标明确,主攻几个关键接口,但正常用户访问会有一系列的曝光、点击等行为,并且每次的点击也会有各种零零散散的活体特征可以采集,比如点击的点位置、数量、力度、频率等,这些维度为用户识别提供了更广的操作空间。基于以上几点的模型示意如下:


image.png


最后一点,启用端上特有的校验能力,这个已经是最终的防御手段,在实在没有办法的情况才会采用的,因为这种手段很影响用户体验,由于采用的是端上特有的能力,比如短信验证码,必须真机才能收到,这就从根本上避免了插件类的直刷,所以可靠性确实所有手段中最高的,但体验差,成本高,所以算是最后一道防线。



如何应对核心逻辑的泄漏



这一块主要关注的是APP端的一些核心逻辑的破解或泄密,可以分两个方向,对外与对内,对外主要是APP包的逆向与破解,不法人员从发布上架的APP包中获取核心业务实现或其他敏感信息;而对内主要指工程安全,核心源码或秘钥的泄漏、误改等。


相应的防范策略也是分两块,对外的线上防破解可以从以下几点入手:



  • 利用代码混淆防APP逆向,一般而言官方会提供相应的能力,也可借助三方加固来提高混淆的力度

  • 核心源码、秘钥下沉,采用更难破解的方式实现,同时增加防外部调用的防范策略,比如Android采用C+混淆来处理

  • 为线上APP添加防调试与HOOK的能力,防止动态调试探测,

  • 添加防止代理与中间人劫持的能力,例如SSLPING等技术,避免被抓包探测

  • 从二次打包入手,添加签名、完整性检测的能力,防止被探测、篡改


而对内主要从工程安全角度推进,主要是做好代码的权责管理



  • 采用组件化开发模式,不同等级的基础能力、业务、核心逻辑做好隔离

  • 仓库单独部署,同时做好权责划分,代码、文档做好权限隔离

  • 加强秘钥、KEY的管控,开发与生产环境严格隔离


上述手段基本涵盖大部可预见的风险场景,即使未覆盖,也大概有类似的手段作为参考,无非就是抽象、搜集、判断、处理。


线上执行方案


最后一步是上线执行,上述的手段多种多样,但相互之间并非孤立运行,彼此可以相互穿插,灵活配合,不存在特定的章法,全看使用方的意图,如何探测,探测之后如何处理,是全杀还是放一部分,都看操刀者自己的运作,以应用多开场景为例,除了利用多开基础的多开检测手段,还可以配合设备指纹做更多的事情,有时虽然没有检测到多开,但是基于设备指纹的补刀,也能定位到问题设备,而在最后一步惩治处理中,不同处理手段也会获得不一样的收益:


类型处理方式最终收益优缺点
被动拦截端上部署检测规则,检测到风险,100%在端上拦截处理【如Crash】效果明显,但易被发现,徒增防御成本
被动捕获检测到风险,在端上不处理,只上报,后端隐形标记或拦截不易被发现,但长期运行收益比较局限
主动诱捕人为制造有迹可循的漏洞,捕获后在端上不拦截或部分拦截,并上报,后端隐形标记不易被发现,虚虚实实,操作空间更大,收益更大

理论上讲,APP技术层面不存在100%有效的安防策略,虚虚实实才是王道,敬畏,才是最有效的防御手段


总结与展望


目前国内APP的生态环境并不健康,甚至可以说野蛮,随着隐私策略收紧,APP所能获取的信息越来越少,安防也越来越难做,反之,刷子却越活越滋润,技术所面临的的挑战也更加棘手,安防注定是一个长期攻防的领域。最后,技术不能解决所有问题,最终还是要依赖法律的健全与全民意识提升。


作者:看书的小蜗牛
来源:juejin.cn/post/7350354672861052980
收起阅读 »

反转反转再反转,揭秘人心深处的“恶意”

“……真是过分,我每天可是难过得要死。有个爱管闲事的邻居,每天都来找我,我没办法,只好去上学,都快给他烦死了。” “老师和学生的关系建立在一种错觉上。老师错以为自己可以教学生什么,而学生错以为能从老师那里学到什么。重要的是,维持这种错觉对双方而言都是件幸福的...
继续阅读 »

“……真是过分,我每天可是难过得要死。有个爱管闲事的邻居,每天都来找我,我没办法,只好去上学,都快给他烦死了。”


“老师和学生的关系建立在一种错觉上。老师错以为自己可以教学生什么,而学生错以为能从老师那里学到什么。重要的是,维持这种错觉对双方而言都是件幸福的事。因为若看清了真相,反而一点好处都没有。我们在做的事,不过是教育的扮家家酒而已。”


是什么样的经历让他说出这样的话呢?我不明白。


大家好,我是杰哥


昨天晚上凌晨三点,我终于第三次翻完了《恶意》。这本书,真的让我欲罢不能!每次阅读都像是一次心灵的冒险,让我惊叹不已。


作者东野圭吾巧妙地运用手记的方式,将故事的发展娓娓道来。那些看似简单平实的文字,却隐藏着令人震撼的真相。他对复杂人性抽丝剥茧的深刻描画,简直让我眼花缭乱,哑口无言。


故事围绕着一起谋杀案展开:畅销书作家在出国的前一晚于家中被杀,凶手很快便落网了。但别以为这只是个简单的“谁是凶手”的故事,其实更多的是”我为什么要杀他“的故事。


凶手对作案动机语焉不详,倒是引起了著名侦探”加贺“的兴趣,他凭借自己一贯对于人性觉察比较敏锐的”直觉“,以及自己曾经作为老师所亲身经历过的“校园暴力”事件,对”作案动机“展开了缜密的分析与调查。经过层层曲折的调查,终于将真实的动机呈现在我们的面前(此处故意不剧透,以免影响了大家的阅读体验)。我只能说,得知真相的你,一定会被震撼到,从而陷入深思。


我是一个悬疑推理类书籍的书迷,看过很多悬疑推理类的书籍,而这本则是一本题材与故事都很新颖且富有创造力,结局也会很让人意外的其中之一。


读这本书的过程中,我就像是坐过山车一样,情绪起伏不定。每当我以为抓到了真相的尾巴,作者就会巧妙地用一个新的情节把我甩回去。反转再反转,直到最后,我才恍然大悟:哦,原来真相是这样的!大概真正优秀的悬疑推理类小说的作家的仅有的几部作品中,才可以与读者的互动达到这样的效果吧。


这本书不仅仅是悬疑,它更深刻地探讨了人性。恶意,这个看似抽象的概念,在书中被具象化,变得触手可及。它让我不禁深思,人心的黑暗面到底能有多深,我们又该如何面对和控制自己内心的恶意。


东野圭吾的笔下,每个人物都有自己的秘密,每个线索都可能是个陷阱。他的作品,让人读起来往往感觉惊险又刺激,恨不得一口气读完,甚至连旁边的手机也被冷落了。


总之,如果你喜欢心理悬疑,喜欢深度剖析人性的作品,那《恶意》绝对不容错过。它会让你在紧张刺激的阅读中,体验到心灵的震撼!


作者:舒米勒
来源:mdnice.com/writing/924e74e14de748d3b72493d7224aba0d
收起阅读 »

跳舞的人

跳舞的人 从我们大学的老校区南院门口进入,迎面便能看到庄严的主楼。 河北大学主楼 主楼后面是一段有花草树木的路,旁边是多功能馆。在主楼和多功能馆中间,有一块空旷的场地,人们清晨、傍晚常常在那里嬉戏玩耍。 大学一年级下半年、...
继续阅读 »

跳舞的人


从我们大学的老校区南院门口进入,迎面便能看到庄严的主楼。



河北大学主楼

河北大学主楼


主楼后面是一段有花草树木的路,旁边是多功能馆。在主楼和多功能馆中间,有一块空旷的场地,人们清晨、傍晚常常在那里嬉戏玩耍。


大学一年级下半年、大学二年纪一整学年我都是在主楼内的我们学院的机房里值班的。所谓值班就是,我晚上需要在机房对面的小屋里睡觉,白天需要管理好机房的日常使用工作。


因为早晨经常需要帮在机房上课的老师学生开门,所以在主楼住的时候,我会醒的比较早。


醒来后,我会先去食堂吃饭,然后在主楼后面散散步,转一圈。


有天在散步的过程中,听到了主楼前的方向有音乐的声音,我对这音乐比较好奇,便循着声音来到了主楼和多功能馆旁的空旷场地。这里放着一个看起来又大又重的音响,音乐便是从这个音箱里传出来的。在大音箱旁边,一个男生在跟随着音乐跳着舞。


早晨的时间是比较充分的,我便在这站了一会,发现跳舞的男生,每个舞蹈都会重复很多遍。我并不懂跳舞,只是能够感觉出来每一遍舞蹈,都是那么认真、那么投入,我猜他很热爱跳舞吧。


后面每每有时间,我都会走到那块空旷的地方,也经常能够看到他在这里跳舞。我想,这块空旷的场地就是他的舞台吧。


有天早晨,雨下得很大,我很早便被雨声吵醒了,我突然想看看「那个跳舞的人,下雨天会不会来练习跳舞呢?」


我便穿好衣服、鞋子,来到主楼不会被雨淋到的台子上。不一会,我便看到一个打着大伞的男生,拉着音箱走了过来。随着男生越来越近,我看清了,就是他——那个跳舞的人


他把音箱拉离地面,一步一步地走上台阶。我心里想,这么大的音箱,拉到台子上,不重吗?


他慢慢近了,来到了我旁边,我和他互相说了声你好,他便打开了音箱,放起了音乐,跳起了舞来,依旧那么认真、那么投入。


外面很冷,看到他来了,心里的疑问算是解开了,我便向主楼里面走去,回到了机房。


在回机房的路上,我便想,因为热爱,音箱便不会重了吧。


作者:随机的未知
来源:mdnice.com/writing/6882be2b53a04567a77d7be826eef49c
收起阅读 »

工作思考|研发环境好好的,怎么上线就出问题了?

场景再现 那是一个夜黑风高的晚上,某个版本迭代经过了完备的测试,正准备上线。研发同事A开完了上线评审后,信心满满地对运维同事B说:“开冲!” 几分钟后,同事B发了条消息过来,看着抖动的头像,同事A心想:小B效率真高啊,这么快!点开消息一看【启动报错了,你看一下...
继续阅读 »

场景再现


那是一个夜黑风高的晚上,某个版本迭代经过了完备的测试,正准备上线。研发同事A开完了上线评审后,信心满满地对运维同事B说:“开冲!”


几分钟后,同事B发了条消息过来,看着抖动的头像,同事A心想:小B效率真高啊,这么快!点开消息一看【启动报错了,你看一下】。


什么?启动还能报错,不可能啊,我研测环境都好好的。


小A火急火忙地连上堡垒机,看了下日志,报错信息大致为 【表tb_xxx没有找到】。


“怎么可能,我用了伟大的flyway,怎么可能会没有表呢?”小A如是说道。



提到flyway,这里简单介绍一下。Flyway是一款开源的数据库版本管理工具,可以实现管理并跟踪数据库变更,支持数据库版本自动升级,而且不需要复杂的配置,能够帮助团队更加方便、合理的管理数据库变更。只需要引入相应依赖,添加配置,再在resource目录下创建db/migration/xxxx.sql文件,在sql文件中写入用到的建表语句,插入语句即可。



不管怎么说,代码是不会骗人的。先找下是哪里出了问题!


小A很快就定位到了代码位置,是一个用于缓存的HashMap,这操作也没什么问题,相信大家都这么用过,对于一些一次查找,到处使用,还亘古不变的表信息,可以先查一次,把它用Map缓存起来,以便后续使用。


但是研发同事C把这段代码放在了afterPropertiesSet()​方法内部,没错,就是那个InitializingBean​接口的方法。看到这里,相信各位熟练背诵Bean生命周期的Java Boy已经明白了!查询数据库的操作在Bean还没有创建完成的时候就进行了!而此时,flyway脚本还没有执行,自然就找不到对应的表信息了。


那怎么办呢?


解决方法


解决方法很简单,sql执行的时候找不到表,那就让它在表创建完之后再执行!


1.CommandLineRunner接口


一个方法就是我们常用的CommandLineRunner​接口,重写run()​方法,把缓存逻辑移到run()​方法中。原因是run()方法的执行时机是在SpringBoot应用程序启动之后,此时flyway已经执行完毕,表结构已经存在,就没问题了!


2.@DependsOn注解


通过代码分析,flyway的加载是由flywayInitializer​这个Bean负责的。所以只需要我们的Bean在它之后加载就行了,这就用上了@DependsOn​注解。



@DependsOn注解可以定义在类和方法上,意思是我这个Bean要依赖于另一个Bean,也就是说被依赖的组件会比该组件先加载注册到IOC容器中。



也就是在我们的Bean上加上这么个注解@DependsOn("flywayInitializer")


总结


此次线上问题复习了Bean的生命周期,复习了InitializingBeanCommandLineRunner​两个接口,复习了@DependsOn​注解。


作者:钱思惘
来源:juejin.cn/post/7349750846898913332
收起阅读 »

时间格式化,显示昨天、今天

web
时间格式化的需求: 今天的数据显示“时分”,HH:mm 10:00 昨天的数据显示“昨天 时分”, 昨天 10:00 今年的数据,显示 “月日 时分”, 05-01 10:00 不是今年的数据,显示“年月日 时分”, 2022-05-01 10:00 代...
继续阅读 »

时间格式化的需求:



  • 今天的数据显示“时分”,HH:mm 10:00

  • 昨天的数据显示“昨天 时分”, 昨天 10:00

  • 今年的数据,显示 “月日 时分”, 05-01 10:00

  • 不是今年的数据,显示“年月日 时分”, 2022-05-01 10:00


代码展示



在 ios中 用new Date("2022-05-01 10:00").getTime()会有兼容性问题,跟日期格式的连字符有关系,这里使用moment插件



const moment = require("moment");

// 判断日期是不是今天、昨天, 0:今天 -1:昨天 1-明天
// str: 2023-02-07 14:09:27.0
export function isWhichDay(str) {
const date = new Date();
const that = moment(moment(str).format("YYYY-MM-DD")).valueOf();
const today = moment(moment(date).format("YYYY-MM-DD")).valueOf();
const timeStampDiff = that - today;
const obj = {
"-86400000": "-1",
0: "0",
86400000: "1",
};
return obj[timeStampDiff] || null;
}

// 判断是不是当年
export function isCurYear(str) {
return moment().format("YYYY") === moment(str).format("YYYY");
}

/**
* 格式化时间 YYYY-MM-DD HH:mm:ss
* 1、当天时间显示如 10:00
* 2、昨天显示如 昨天10:00
* 3、昨天之前且当年的,显示如,05-01 10:00
* 4、昨天之前且跨年的,显示如, 2022-05-01 10:00
*
@param {string} time "2022-05-01 10:00:01.0"
*
@returns {string}
*/

export function formatTime(time) {
const t = isWhichDay(time);
if (t === "0") {
return moment(time).format("HH:mm");
} else if (t === "-1") {
return `昨天 ${moment(time).format("HH:mm")}`;
} else if (
isCurYear(time) &&
moment(time).valueOf() < moment(new Date()).valueOf()
) {
return moment(time).format("MM-DD HH:mm");
} else {
return moment(time).format("YYYY-MM-DD HH:mm");
}
}



作者:甜点cc
来源:juejin.cn/post/7226300253921558583
收起阅读 »

环信WEB端单群聊 UIKit 快速集成与消息发送指南

写在前面:千呼万唤始出来,环信web端终于出uikit了,环信单群聊 UIKit 是基于环信即时通讯云 IM SDK 开发的一款即时通讯 React UI 组件库。该组件库提供了聊天相关的组件,包括会话列表、聊天界面、联系人列表和群组设置等组件,组件内部集成了...
继续阅读 »

写在前面:

千呼万唤始出来,环信web端终于出uikit了,环信单群聊 UIKit 是基于环信即时通讯云 IM SDK 开发的一款即时通讯 React UI 组件库。该组件库提供了聊天相关的组件,包括会话列表、聊天界面、联系人列表和群组设置等组件,组件内部集成了 IM SDK,可以帮助开发者不关心内部实现和数据管理就能根据实际业务需求快速搭建包含 UI 界面的即时通讯应用。现在就让我们一起探索如何集成吧!本文介绍如何快速实现在单聊会话中发送消息


准备工作:

  1. React 环境:需要 React 16.8.0 或以上版本;React DOM 16.8.0 或以上版本。

  2. 即时通讯 IM 项目:已在环信即时通讯云控制台创建了有效的环信即时通讯 IM 开发者账号,并获取了 App Key

  3. 环信用户:在环信控制台创建 IM 用户,并获取用户 ID 和密码或 token。


  4. 好友关系:双方需要先添加好友才可以聊天







集成uikit:

准备工作完成就开始集成!在此先奉上uikit源码

第一步:创建一个uikit项目

# 安装 CLI 工具。
npm install create-react-app
# 构建一个 my-app 的项目。
npx create-react-app my-app
cd my-app

第二步:安装 easemob-chat-uikit

cd my-app
  • 使用 npm 安装 easemob-chat-uikit 包
npm install easemob-chat-uikit --save
  • 使用 yarn 安装 easemob-chat-uikit 包
yarn add easemob-chat-uikit

第三步:引入uikit组件

在你的 React 项目中,引入 UIKit 提供的组件和样式:

// 导入组件
import {
UIKitProvider,
Chat,
ConversationList,
// ...
} from "easemob-chat-uikit";

// 导入样式
import "easemob-chat-uikit/style.css";

第四步:初始化配置

easemob-chat-uikit 提供 UIKitProvider 组件管理数据。UIKitProvider 不渲染任何 UI, 只用于为其他组件提供全局的 context,自动监听 SDK 事件, 在组件树中向下传递数据来驱动组件更新。单群聊 UIKit 中其他组件必须用 UIKitProvider 包裹。

import "./App.css";
import { UIKitProvider} from "easemob-chat-uikit";
import "easemob-chat-uikit/style.css";
function App() {
return (
<div>
<UIKitProvider
initConfig={{
appKey: "your app key", // 你的 app key
userId: "userId", // 用户 ID
password: "password", // 如果使用密码登录,传入密码。
translationTargetLanguage: "zh-Hans", // 翻译功能的目标语言
useUserInfo: true, // 是否使用用户属性功能展示头像昵称(UIKit 内部会获取用户属性,需要用户自己设置)
}}
local={{
fallbackLng: "zh",
lng: "zh",
resources: {
zh: {
translation: {
hello: "欢迎使用",
conversationTitle: "会话列表",
deleteCvs: "删除会话",
//...
},
},
},
}}
>
</UIKitProvider>
</div>
);
}

export default App;


第五步:引入组件

根据自己的项目引入所需组件,组件文档,本文只介绍如何快速实现在单聊会话中发送消息,为了方便快速体验,一定要确保准备工作的第四条双方已经互为好友

import "./App.css";
import { UIKitProvider} from "easemob-chat-uikit";
import "easemob-chat-uikit/style.css";
function App() {
return (
<div>
<UIKitProvider
initConfig={{
appKey: "your app key", // 你的 app key
userId: "userId", // 用户 ID
password: "password", // 如果使用密码登录,传入密码。
translationTargetLanguage: "zh-Hans", // 翻译功能的目标语言
useUserInfo: true, // 是否使用用户属性功能展示头像昵称(UIKit 内部会获取用户属性,需要用户自己设置)
}}
local={{
fallbackLng: "zh",
lng: "zh",
resources: {
zh: {
translation: {
hello: "欢迎使用",
conversationTitle: "会话列表",
deleteCvs: "删除会话",
//...
},
},
},
}}
>
<div style={{ display: "flex" }}>
<div style={{ width: "40%", height: "100%" }}>
<ContactList
onItemClick={(data) => {
rootStore.conversationStore.addConversation({
chatType: "singleChat",
conversationId: data.id,
lastMessage: {},
unreadCount: "",
});
}}
/>
</div>//联系人组件,点击某个好友通过‘rootStore.conversationStore.addConversation’创建会话
<div style={{ width: "30%", height: "100%" }}>
<ConversationList />//会话列表组件
</div>
<div style={{ width: "30%", height: "100%" }}>
<Chat />//聊天消息组件
</div>
</div>
</UIKitProvider>
</div>
);
}

export default App;


第六步:运行并测试

1、运行项目

npm run start

2、点击好友并发送一条消息


总结:

通过以上步骤,你已经成功集成了环信单聊 UIKit 并实现了基本的即时通讯功能,接下来继续根据 UIKit 提供的组件和 API 文档进行进一步开发吧


收起阅读 »

【CSS浮动属性】别再纠结布局了!一文带你玩转CSS Float属性

在网页设计的世界里,CSS浮动属性(float)就像一把双刃剑。它能够让元素脱离文档流,实现灵活的布局,但如果处理不当,也可能引发一系列布局问题。今天,我们就来深入探讨这把“剑”的正确使用方法,让你的页面布局既美观又稳定。一、什么是CSS浮动属性浮动属性是CS...
继续阅读 »

在网页设计的世界里,CSS浮动属性(float)就像一把双刃剑。它能够让元素脱离文档流,实现灵活的布局,但如果处理不当,也可能引发一系列布局问题。

今天,我们就来深入探讨这把“剑”的正确使用方法,让你的页面布局既美观又稳定。

一、什么是CSS浮动属性

浮动属性是CSS中的一个定位属性,它允许元素脱离文档流,并向左或向右移动,直到它的外边缘碰到包含框或者另一个浮动元素的边缘。简单来说,它就像是让元素“漂浮”在页面上,不受常规排列规则的限制。

在网站开发中需要一行排列多个元素,使用浮动可以方便实现。下面是使用浮动排列多个元素。

Description

下面我们来了解一下浮动属性的基本使用语法和常用的应用场景都有哪些。

1.1 浮动属性的语法

selector {
float: 值;
}

其中,选择器是你想要应用浮动属性的元素的选择器,值可以是以下之一:

  • none:这是默认值,元素不会浮动,即保持在标准文档流中的位置。

  • left:元素将向左浮动,它会尽量向左移动,直到它的外边缘碰到包含框或另一个浮动框的边框为止。

  • right:元素将向右浮动,它会尽量向右移动,直到它的外边缘碰到包含框或另一个浮动框的边框为止。

1.2 浮动的应用场景

CSS浮动属性的应用场景主要包括以下几点:

布局定位:
浮动可以用于创建复杂的页面布局,例如将块级元素放置在一行内,或者创建多列布局。

文本环绕图片:
这是浮动最常见的应用之一,通过将图片设置为浮动,可以使文本自动环绕在图片周围,从而实现类似印刷布局中的文本环绕效果。

清除元素间缝隙:
浮动元素会紧挨着排列,没有间隙,这可以用来清除列表或图片间的空格,使得元素紧密排列。

创建下拉菜单
浮动还常用于创建下拉菜单或弹出式菜单,通过将菜单项设置为浮动,可以实现菜单的显示和隐藏。

实现侧边栏:
在网页设计中,浮动可以用来创建固定在一侧的侧边栏,而主要内容则围绕侧边栏流动。

创建瀑布流布局:
在响应式设计中,浮动可以用来实现瀑布流布局,这种布局可以根据浏览器窗口的大小自动调整列数和列宽。

1.3 盒子的排列规则

在使用浮动属性后盒子是如何排列的呢?

Description

  • 左浮动的盒子向上向左排列
  • 右浮动的盒子向上向右排列
  • 浮动盒子的顶边不得高于上一个盒子的顶边
  • 若剩余空间无法放下浮动的盒子,则该盒子向下移动,直到具备足够的空间能容纳盒子,然后再向左或向右移动

二、浮动的核心特点

下面将通过这个示例来给大家讲解浮动的特点:

<div>
<div>正常元素</div>
<div>
浮动元素
</div>
<div>我是浮动元素后面的第一个同级正常元素</div>
<div>我是浮动元素后面的第二个同级正常元素</div>
</div>
.container{
width: 200px;
height: 200px;
background-color: red;
}
.box1{
background-color: green;
}
.box2{
background-color: brown;
}
.box3{
background-color: pink;
}


.float{
float:left;


background-color: yellow;
}

Description

2.1 包裹性

具有“包裹性”的元素当其未主动设置宽度时,其宽度右内部元素决定。且其宽度最大不会超过其包含块的宽度。

设置了float属性(不为none)的元素都会具有包裹性。

在上面的例子中float元素不设置宽度,其宽度也不会超过container元素的宽度。

2.2 块状化并格式化上下文

设置了float属性(不为none)的元素,无论该元素原本是什么元素类型,其display属性的计算值都会自动变成"block"或’table(针对inline-table元素)'。并且浮动元素会生成一个BFC(块级格式化上下文)。

所以永远不需要对设置了float属性(不为none)的元素再设置"display:block"属性或者vertical-align属性!这都是多余和无效的。

2.3 脱离标准流

设置了float属性(不为none)的元素,都会脱离标准流。标准流一般是针对块级或行级元素(不包括行内块)。

通俗一点解释是,浮动元素A会“漂浮”在标准流上面,此时其原始占用的标准流空间由同级的后续第一个标准流兄弟元素B顶替(但是元素B中的文本内容会记住浮动元素A的位置,并在排布时避开它,由此形成文本环绕效果)。所以会出现B的部分内容会被飘起来的A所遮挡的现象。

有人可能会问,上面的例子中好像没发现类似"A遮挡B"的现象啊?

其实并不是,具体解释如下:
我们将box2元素(即浮动元素后续的第一个同级元素)的文本内容减少一些,使其不换行并不占满一行方便解释效果。

Description

图片这时候发现box2是和container元素宽度200是一致的,而不是自身文本的宽度。由于浮动元素的脱离文档流,.box2会忽略浮动元素的原空间(即当其不存在),由因为普通div不设置宽度默认会是父元素宽度。

所以这里box2和其父元素container宽度一致。但又因为浮动元素会使box2的文本环绕,导致box2的文本重新布局排版,“移动”到了紧跟浮动元素的右边界的地方。所以此时可以看作box2被浮动元素遮挡的那一部分实际是空背景。

2.4 高度坍塌

当你给浮动元素设置了具体宽高度,并增加box2元素的文本内容,也许这种脱离文档流现象更明显,如下示例:

Description

浮动元素脱离标准流的特性很容易带来的一大问题就是——父元素的高度塌陷

我们将html内容精简,只保留浮动元素和box2元素:

<div>
<div>
浮动元素
</div>
<div>我是浮动元素后面的第一个同级元素</div>


</div>

然后设置浮动元素宽高度,并去掉父元素设置的宽高度(核心点)

.container{
/* width: 200px;*/
/*height: 200px;*/
background-color: red;
}
.float{
float:left;
width: 40px;
height: 40px;
background-color: yellow;
}

Description

此时我们发现:没有设置高度的container元素,其实际高度只由标准文档流的box2元素撑起来了21px,而设置了30px高度的浮动元素由于脱离文档流其高度被忽略了。

这就是浮动经典的“高度塌陷”问题了。

2.4 无margin重叠问题

普通的块级元素之间的margin-top和margin-bottom有时会出现margin合并的现象,而浮动元素由于其自身会变成一个BFC(块级格式化上下文),不会影响外部元素,所以不会出现margin重叠问题。

三、清除浮动

清除浮动并不是去掉浮动,而是解决因为浮动带来的副作用的消极影响,也就是我们上面说的父元素高度塌陷问题。

3.1 clear属性

在此之前,我们需要了解另一个CSS属性,就是float的克星——clear

官方对于clear属性的解释是:元素盒子的边不能和前面的浮动元素相邻。其本质在于让当前元素不和前面的float元素在一行显示。

对此我们可以对于clear的属性值形象地理解为:

  • left:元素左边抗浮动

  • right:元素右边抗浮动

  • both:元素两侧抗浮动

注意:由于clear属性只关注当前元素前面的浮动元素,所以使用clear:left/right都是和clear:both等效的。实际上我们只需要用到clear:both即可。

想要快速入门前端开发吗?推荐一个前端开发基础课程,这个老师讲的特别好,零基础学习无压力,知识点结合代码,边学边练,可以免费试看试学,还有各种辅助工具和资料,非常适合新手!

点这里前往学习哦!


3.2 清除方法

当今流行的浮动布局已不再是最初的文字环绕了,而是通过给每个子元素添加浮动来实现元素横向排列(一行占不下就换行继续)的布局。

注意:这种横向排列布局建议最好让每个子元素的高度一致,否则可能会出现以下图这种高度不齐引起的布局问题:

Description

即使如此,依然需要解决父元素高度塌陷问题,以下分别对几种常见解决方案简单说明下:

  • 让父元素也浮动

没有从根本解决问题,反而生成了新的浮动问题。

  • 给父元素设置高度

此法太过死板,让父元素高度固定死了,无法自适应高度。

  • 给父元素设置overflow:hidden

此法原理在于让父元素成为一个BFC,唯一缺点容易导致溢出内容被隐藏掉,不过这种场景较少,还是可以用此方法的。

  • 伪元素与clear属性配合(推荐)
/*对浮动元素的父元素设置*/
.clear::after{
clear: both;
content:'';
/*clear属性只对块元素有效,而伪元素::afer默认是行级*/
display: block;
}

CSS浮动属性是网页设计师的重要工具,但也需要谨慎使用。通过今天的介绍,希望你能够更加自信地在你的设计中运用这一属性,创造出既美观又稳定的网页布局。

在CSS的世界里,每一个属性都有其独特的魅力和规则。浮动属性作为布局的强大工具,虽然有时会带来挑战,但只要我们理解它的本质,就能将它变为实现创意设计的利器。

收起阅读 »

Redis不再 “开源”

Redis 官方今日宣布修改开源协议 —— 未来所有版本都将使用 “源代码可用” 的许可证 (source-available licenses)。具体来说,Redis 将不再遵循 BSD 3-Clause 开源协议进行分发。从 Redis 7.4 版本开始,...
继续阅读 »

Redis 官方今日宣布修改开源协议 —— 未来所有版本都将使用 “源代码可用” 的许可证 (source-available licenses)。


具体来说,Redis 将不再遵循 BSD 3-Clause 开源协议进行分发。从 Redis 7.4 版本开始,Redis 采用 SSPLv1 和 RSALv2 双重许可证。Redis 源代码将通过 Redis 社区版免费提供给开发者、客户和合作伙伴。

SSPL:Server Side Public License

RSAL:Redis Source Available License Redis 产品家族的具体许可证如下:


根据新许可证的条款,托管 Redis 产品的云服务提供商将不再允许免费使用 Redis 的源代码。例如,云服务提供商只有在与 Redis(Redis 代码的维护者)达成许可条款后,才能向用户交付 Redis 7.4。

Redis 官方表示:

实际上,Redis 开发者社区不会发生任何变化,他们将继续拥有双重许可证下的宽松许可。同时,Redis 负责的所有 Redis 客户端库将保持采用开源许可证。 Redis 将继续支持其庞大的合作伙伴生态系统(包括托管服务提供商和系统集成商),并独家访问 Redis 通过其合作伙伴计划开发和提供的所有未来版本、更新和功能。 现有 Redis Enterprise 客户没有变化。 总的来说,对于使用 Redis 开源版本和新版本的 Redis 的最终用户(使用双重许可证进行内部或个人使用),没有任何变化。

对于使用 Redis 构建客户端库或其他集成的集成合作伙伴,同样没有任何变化。 Redis 对这次修改开源协议的举措十分坦诚,他们承认 Redis 不再是 OSI 定义下的“开源”项目。但他们仍是开源理念的支持者,并会继续维护开源项目。


原文:https://mp.weixin.qq.com/s/9_-w6lF7ffiu49WbEORPtQ

收起阅读 »

正则表达式太难写?试试这个可视化工具

在工作中有没有觉得写正则表达式很难,我就一直很头疼。今天我们就介绍一个开源项目,它可以用可视化的方式查看、编辑和测试正则表达式,大大的提升效率,它就是:regex-vis regex-vis是什么 regex-vis是一个辅助学习、编写和验证正则的工具,你输入...
继续阅读 »

在工作中有没有觉得写正则表达式很难,我就一直很头疼。今天我们就介绍一个开源项目,它可以用可视化的方式查看、编辑和测试正则表达式,大大的提升效率,它就是:regex-vis


regex-vis是什么


regex-vis是一个辅助学习、编写和验证正则的工具,你输入一个正则表达式后,会生成它的可视化图形。然后可以点选或框选图形中的单个或多个节点,再在右侧操作面板对其进行操作,具体操作取决于节点的类型,比如在其右侧插入空节点、为节点编组、为节点增加量词等。



安装regex-vis


首先regex-vis提供了一个在线环境,可以直接到regex-vis.com/ 去试用,这是最简单的方式。



当然,作为一个开源项目,另外一种方式就是自己运行啦。按以下步骤:



  • 首先下载代码到本地。

  • 安装依赖:pnpm install

  • 安装完成后运行服务:pnpm start



启动完成后到3000端口访问即可。


这里可能会遇到一些小问题,比如SSL的问题,稍微修改一些运行命令的配置即可解决。


使用 regex-vis


首先我准备一个例子的正则表达式,验证身-份-证的正则:


^[1-9]\d{5}(18|19|([23]\d))\d{2}((0[1-9])|(10|11|12))(([0-2][1-9])|10|20|30|31)\d{3}[0-9Xx]$

可视化


直接把正则表达式贴进去就能看到可视化的效果了。



编辑


在右侧是正则表达式的编辑区,可以在这里修改、编辑正则的内容。



首先是一些图例,点击图形中想要编辑的部分,然后点击中间的编辑就可以进入到编辑页面了。



测试


修改完了正则的内容,想要验证一下写的对不对,那就到测试里去试一试吧。通过的会显示绿色,失败的则显示为红色。



示例


项目还自带了几个示例,如果你 刚一进来,不知道用什么来试用,可以直接打开示例来看看。



设置


本身是个小工具,这里有2个可用的设置,一个是切换语言,可以切成中文显示,另一个就是明/暗显示模式的转换。



总结


作为一个小工具还是挺不错的,对于像我这样不熟练正则的人有所帮助,一步步的编辑可以渐进式的编辑。


当然现在写正则最好的方式是让AI帮忙写,所以我建议可以AI帮忙写,然后通过这个工具来检查一下,通过可是的方式检查和AI的沟通有没有错误。


另外测试正则的功能里,不能显示出事那部分 正则出错略有可惜,如果能增强就更好用了。


项目信息



作者:IT咖啡馆
来源:juejin.cn/post/7350683679297290294
收起阅读 »

趣解适配器模式之《买了苹果笔记本的尴尬》

〇、小故事 小王考上了理想的大学,为了更好的迎接大学生活,他决定买一台苹果的笔记本电脑犒赏自己。 电脑很快买好了,用起来也非常的流畅,但是,当他想要插U盘传资料的时候,尴尬的事情来了,这台电脑两侧的插口非常少,只有1个耳机插孔和2个雷电插孔,根本没有USB插...
继续阅读 »

〇、小故事


小王考上了理想的大学,为了更好的迎接大学生活,他决定买一台苹果的笔记本电脑犒赏自己。



电脑很快买好了,用起来也非常的流畅,但是,当他想要插U盘传资料的时候,尴尬的事情来了,这台电脑两侧的插口非常少,只有1个耳机插孔2个雷电插孔根本没有USB插口!这咋办呀?



他赶快咨询了他的哥哥,他哥哥告诉他,去买一个扩展坞就可以了,然后他上网一看,原来买一个扩展坞之后,无论是U盘还是连接显示器的HDMI都可以连接啦!!他开心极了,本来要遗憾退掉这台心爱的苹果笔记本电脑,这回也不用退啦!



以上这个小故事,相信很多使用过苹果笔记本的同学们都会遇到,大多也都会购买这种扩展坞,那么,这种扩展坞其实就是适配器模式的一个具体实现例子了。那么,言归正传,我们来正式了解一下这个设计模式——适配器模式


一、模式定义


适配器模式定义:



该模式将一个类的接口,转换成客户期望的另一个接口。适配器模式让原本接口不兼容的类可以合作无间。



为了进一步加深该模式的理解,我们再举一个研发过程中会遇到的例子:



此时我们维护了一个员工管理系统,然后接入我们系统的第三方系统,我们都要求对方遵守我们的接口规范去开发,比如:提供方法名为queryAllUser()的方法等等。但是,这次接入的系统已经有类似功能了,他们不希望因为两个系统的接入而重新开发新的接口,那么这对这种情况,我们就可以采用适配器模式,将接口做中间层的适配转换。



如图下图所示:



二、模式类图


通过上面的介绍,相信大家对适配器模式也有了一定的了解了。那么,下面我们就来看一下如果要实现适配器模式,我们的类图应该是怎么样的。


首先,我们要说明两个重要的概念:AdapterAdaptee,其含义分别是适配器待适配的类。我们就是通过实现Target接口创建Adapter类,然后在具体的方法内部来通过调用Adaptee方法来实现具体的业务逻辑。具体类图如下所示:



三、代码实现


首先创建目标类接口——Target


public interface Target {
void prepare();
void execute();
}

实现Target接口,创建具体实现类——NormalTarget


public class NormalTarget implements Target {
public void prepare() {
System.out.println("NormalTarget prepare()");
}
public void execute() {
System.out.println("NormalTarget execute()");
}
}

创建待适配的类Adaptee,用于后续适配器对其进行适配工作:


public class Adaptee {
public void prepare1() {
System.out.println("Adaptee prepare1()");
}
public void prepare2() {
System.out.println("Adaptee prepare2()");
}
public void prepare3() {
System.out.println("Adaptee prepare3()");
}
public void doingSomething() {
System.out.println("Adaptee doingSomething()");
}
}

创建适配器Adapter,由于要适配目标对象Target,所以需要实现Target接口:


public class Adapter implements Target {
// 待适配的类
private Adaptee adaptee;

public Adapter(Adaptee adaptee) {
this.adaptee = adaptee;
}

public void prepare() {
adaptee.prepare1();
adaptee.prepare2();
adaptee.prepare3();
}

public void execute() {
adaptee.doingSomething();
}
}

创建客户端Client,用于操作Target目标对象执行某些业务逻辑:


public class Client {
Target target;
public void work() {
target.prepare();
target.execute();
}
public void setTarget(Target target) {
this.target = target;
}
}

创建测试类AdapterTest,使得Client操作NormalTarget和Adaptee:


public class AdapterTest {
public static void main(String[] args) {
Client client = new Client();

System.out.println("------------NormalTarget------------");
client.setTarget(new NormalTarget());
client.work();

System.out.println("------------Adaptee------------");
client.setTarget(new Adapter(new Adaptee())); // 适配器转换
client.work();
}
}

通过输出结果我们可以看到,适配器运行正常:


------------NormalTarget------------
NormalTarget prepare()
NormalTarget execute()
------------Adaptee------------
Adaptee prepare1()
Adaptee prepare2()
Adaptee prepare3()
Adaptee doingSomething()

今天的文章内容就这些了:



写作不易,笔者几个小时甚至数天完成的一篇文章,只愿换来您几秒钟的 点赞 & 分享



更多技术干货,欢迎大家关注公众号“爪哇缪斯” ~ \(^o^)/ ~ 「干货分享,每天更新」


作者:爪哇缪斯
来源:juejin.cn/post/7273125596951298060
收起阅读 »

我不敢把水烧的太开

我不敢把水烧开,那样家里会有两个沸物。我也不敢把房间打扫的很干净,我怕太干净,垃圾只剩下我。我常坐在窗口看着窗外发呆,这悲伤来的没有油头。床上有两个枕头,一个是我的,另一个也是我的,因为我裂开了。我也经常熬夜,因为天冷了,时间就不说了。白天面对的是生活,夜晚面...
继续阅读 »

我不敢把水烧开,那样家里会有两个沸物。我也不敢把房间打扫的很干净,我怕太干净,垃圾只剩下我。我常坐在窗口看着窗外发呆,这悲伤来的没有油头。床上有两个枕头,一个是我的,另一个也是我的,因为我裂开了。我也经常熬夜,因为天冷了,时间就不说了。白天面对的是生活,夜晚面对的是灵魂,一半的时间来生存,剩下的时间拿来滋养灵魂!我熬的不是夜,是我短暂的自由。青春献给了梦想,梦想败给了现实。小时候无忧无虑,倒头就睡,长大后忙于生计,失眠怎么常态。背井离乡的颠沛流离,不过是为了碎银几两。习惯了一个人的独处,也慢慢接受了自己的平庸。我们不是故事里的主角,也没有主角光环!我们只是茫茫人海中的渺小一个。不曾坐过飞机,也没喝过星巴克,更没有用过奢侈品。小时候的自由人,长大后的笼中鸟。以前叫醒你的是父母,现在叫醒你的是生活。我们变得好像是机器人,每天起床的意义就是重复的工作。 我似乎感受到那袭来的风划过,渴望度图欣赏,但更吹醒了我的意识,要继续生存下去,夜深人静是自由醒来清晨是生活,朋友人间自由身,却非人间自由人,看似自由自在,实则身不由己。


我不敢轻易点燃热情,以免世界再添两个燃烧的灵魂。我也不敢让心扉过于透彻明亮,只怕纯净得只剩下自我孤独。我常常倚在窗前凝望星空,那份寂寥悄无声息地蔓延。床榻上有两个梦乡,一个属于清醒时的我,另一个属于深夜里破碎的我。我时常与黑夜为伴,仿佛只有此刻,才握住了片刻的宁静。白昼应对的是繁杂尘世,夜晚则是对内心世界的对话,一半的生命为了生存而奋斗,另一半则用来沉淀和丰盈心灵。我熬的不只是夜,更是那一份难能可贵的自我空间。青春曾向理想倾注所有,而理想最终却在现实中折戟沉沙。儿时懵懂无知,酣然入梦,成人后疲于奔命,反倒是失眠成了常态。远离故土、四海为家,无非是为了那些散落各处的铜板。渐渐习惯独自行走,也逐渐接纳了自己的平凡无奇。我们并非小说里的主人公,身上也没有主角光环庇佑,我们只是芸芸众生中的一员。未曾体验云端飞翔,亦未尝品鉴星巴克的香醇,更谈不上拥有奢侈品牌的光环。曾经那个随性率真的孩子,如今已变成囚禁在生活牢笼中的飞鸟。过去的黎明由父母唤醒,现在的黎明却是生活的催促。我们如同被设定程序的机器,日复一日只是为了重复的工作奔波。


我恍若感受到那阵疾风吹过,虽有心去追逐欣赏,但它更像是一记警钟,提醒我要坚韧地活下去,深夜的清醒是对自由的领悟,破晓的苏醒则是对生活的担当,身边的朋友皆似世间自由行者,却非人人能真正活得洒脱。表面看似悠然自得,实则都身陷无形的生活枷锁之中。


作者:Young_
来源:mdnice.com/writing/ac9b73a2a7f84f1eb843a6c404a82701
收起阅读 »

深入研究Kotlin运行时的泛型

深入研究Kotlin运行时的泛型 通过前面的学习,对Kotlin的泛型已经有了比较全面的了解了,泛型的目的是让通用的代码更加的类型安全。现在我们离写出类型安全的泛型代码还差最后一块拼图,那就是泛型的类型擦除,今天就来深入地学习一下运行时的泛型,彻底的弄懂类型...
继续阅读 »

深入研究Kotlin运行时的泛型


通过前面的学习,对Kotlin的泛型已经有了比较全面的了解了,泛型的目的是让通用的代码更加的类型安全。现在我们离写出类型安全的泛型代码还差最后一块拼图,那就是泛型的类型擦除,今天就来深入地学习一下运行时的泛型,彻底的弄懂类型擦除的前因后果,并学会如何在运行时做类型检查和类型转换,以期完成拼图掌握泛型,写出类型安全的通用代码。





关于泛型话题的一系列文章:



泛型类型擦除(Type erasure)


泛型的类型安全性(包括类型检查type check,和类型转换type casting)都是由编译器在编译时做的,为了保持在JVM上的兼容性,编译器在保障完类型安全性后会对泛型类型进行擦除(Type erasure)。在运行时泛型类型的实例并不包含其类型信息,也就是说它不知道具体的类型参数,比如Foo和Foo都被擦除成了Foo<*>,在虚拟机(JVM)来看,它们的类型是一样的。


因为泛型Foo的类型参数T会被擦除(erased),所以与类型参数相关的类型操作(类型检查is T和类型转换as T)都是不允许的。


可行的类型检查和转换


虽然类型参数会被擦除,但并不是说对泛型完全不能进行类型操作。


星号类型操作


因为所有泛型会被擦除成为星号无界通配Foo<*>,它相当于Foo,是所有Foo泛型的基类,类型参数Any?是根基类,所以可以进行类型检查和类型转换:


if (something is List<*>) {
 something.forEach { println(it) } // 元素被视为Any?类型
}

针对星号通配做类型操作,类型参数会被视为Any?。但其实这种类型操作没有任何意义,毕竟Any是根基类,任何类当成Any都是没有问题的。


完全已知具体的类型参数时


另外一种情况就是,整个方法的上下文中已经完全知道了具体的类型参数时,不涉及泛型类型时,也是可以进行类型操作的,说的比较绕,我们来看一个🌰:


fun handleStrings(list: MutableList<String) {
 if (list is ArrayList) {
  // list is smart-cast to ArrayList
 }
}

这个方法并不涉及泛型类型,已经知道了具体的类型参数是String,所以类型操作也是可行的,因为编译器知道具体的类型,能对类型进行检查 保证是类型安全的。并且因为具体类型参数String可以推断出来,所以是可以省略的。


未检查的转换


当编译器能推断出具体的类型时,进行类型转换就是安全的,这就是被检查的转型(checked cast),如上面的🌰。


如果无法推断出类型时,比如涉及泛型类型T时,因为类型会被擦除,编译器不知道具体的类型,这时as T或者as List都是不安全的,编译器会报错,这就是未检查转型(unchecked cast)。


但如果能确信是类型转换是安全的,可以用注解@Suppress("UNCHECKED_CAST")来忽略。


用关键reified修饰inline泛型函数


要想能够对泛型类型参数T做类型操作,只能是在用关键字reified修饰了的inline泛型函数,在这种函数体内可以对泛型类型参数T做类型操作,🌰如:


inline fun <reified A, reified B> Pair<*, *>.asPairOf(): Pair? {
    if (first !is A || second !is B) return null
    return first as A to second as B
}

val somePair: Pair = "items" to listOf(123)


val stringToSomething = somePair.asPairOf()
val stringToInt = somePair.asPairOfInt>()

需要注意的是关键字reified能够让针对类型参数T的操作得到编译器的检查,保证安全,是允许的。但是对于泛型仍是不允许的,🌰如:


inline fun <reified T> List<*>.asListOfType(): List? =
    if (all { it is T })
        @Suppress("UNCHECKED_CAST")
        this as List else
        null

这个inline泛型函数用关键字reified修饰了,因此针对类型参数T是允许类型检查类型转换,如第2行是允许的。但泛型仍是不合法,如第4行,这时可以用上一小节提到的注解@Suppress("UNCHECKED_CAST")来忽略未检查类型转换。


inline和reified的原理


对于一些泛型工厂方法,就非常适合使用inline和reified,以保证转换为类型参数(因为工厂方法最终肯定要as T)是允许的且是安全的:


inline fun <reified T> logger(): Logger = LoggerFactory.getLogger(T::class.java)

class User {
    private val log = logger()
    // ...
}

关键字reified其实也没有什么神秘的,因为这是inline函数,这种函数是会把函数体嵌入到任何调用它的地方(call site),而每个调用泛型函数的地方必然会有明确的具体类型参数,那么编译器就知道了具体的类型能保证类型安全(checked cast)。上面的工厂方法在调用时就会大概变成酱紫:


class User {
 private val log = LoggerFactory.getLogger(User.class.java)
}

这时其实在函数体内已经知道了具体的类型参数User,编译器能够进行类型检查,所以是安全的。


总结


本文深入的讨论一下运行时泛型的一些特性,泛型类型在运行时会被擦除,无法做泛型相关的类型操作,因为编译器无法保证其类型安全。例外就是在用reified修饰的inline函数中可以对类型参数T做类型操作,但泛型类型(带尖括号的)仍是会被擦除,可以用注解@Suppress("UNCHECKED_CAST")来忽略unchecked cast。


参考资料



作者:稀有猿诉
来源:toughcoder.net/blog/2024/03/16/deep-dive-int0-kotlin-generics-runtime
收起阅读 »

《健听女孩》——一部感人的电影

故事 《健听女孩》的主人公是一个听力正常爱唱歌的女孩鲁比。这里为什么强调听力正常呢?因为她的父母和哥哥都是聋哑人,家里只有她自己一个人具有听力。这个家庭以捕鱼为生,渔船通知响应,渔获交易,与人沟通等事情都是由她进行翻译来进行的。这个家庭很需要她。 她有去伯...
继续阅读 »

故事


《健听女孩》的主人公是一个听力正常爱唱歌的女孩鲁比。这里为什么强调听力正常呢?因为她的父母和哥哥都是聋哑人,家里只有她自己一个人具有听力。这个家庭以捕鱼为生,渔船通知响应,渔获交易,与人沟通等事情都是由她进行翻译来进行的。这个家庭很需要她。


她有去伯克利音乐学院面试的机会,这是她的梦想,本片就是主要讲述了她在梦想与家庭进行抉择的过程和家庭成员的看法、处理方式等。


被“嘲笑”


鲁比出生在聋哑家庭,可想而知,她的家人没有办法教她讲话,她的发声很难听,这遭到了她的同学们的嘲笑、欺凌。她每天凌晨三点便起床与家人一起捕鱼,有时会来不及换衣服,同学也会嫌弃她身上的鱼腥味,进行讥讽。


种种这些,让她幼小的心灵受到了很大打击,所以她害怕面对她们,同时也造成了她的自卑、敏感。


师生情


在报课程的时候,她选择了合唱课,因为她热爱唱歌。但是第一节课,老师让大家开唱的时候,她却逃避得跑出去了。后来和老师讲明因为自己得经历,不敢在同学面前唱歌,害怕被嘲笑。老师给了她鼓励,让她有了自信。


老师发现她的天赋,推荐她去伯克利面试,同时教她唱歌。


在家庭不同意她去伯克利学院时,对她进行惋惜。


友情和爱情


鲁比得闺蜜是她参加合唱团前唯一的好友,闺蜜帮她分担心事,支持她唱歌。


参加合唱团后,她又有了一个男性朋友,是她的二重唱的搭档,当然也发生了一些小插曲。这位朋友家庭也存在一些问题,他的爸妈关系不和,他选择唱歌也并不是自己本意。后来她俩互相了解,互谈心事。 成为了男女朋友。


亲情


这部电影主要还是讲解亲情的。


在得知鲁比想去读大学时,她的妈妈特别反对,她说,“她不能离开我,她是我的宝宝”,爸爸说,“可是她从来没有当过宝宝”。是啊,她从小就帮家里进行翻译,是这个家与外界沟通的桥梁。她这么小就承担了这么多。她的爸爸希望她去,但是这个家庭没有她是没办法运作的。她的哥哥在看到父母把鲁比当成最重要的沟通媒介时,他心事重重,他认为他是哥哥,这些事情他也是能做好的。


虽说她的妈妈开始不支持唱歌,但是在她要进行表演的时候还是送了她一条红色裙子。她俩谈心过程中,妈妈在生孩子时希望鲁比是聋哑人,因为妈妈怕如果是正常儿童的话,自己的聋哑会成为一个“坏妈妈”。 在闺蜜和鲁比哥哥讲述了鲁比唱歌方面的天赋后,他很希望她去参加面试。


她还是没有选择去面试。这是她想成全家庭,因为她知道家庭对她的需要。


一家人一起去看了她的表演,看着台下人的感动,鼓掌,落泪等行为,爸爸心事重重,回到家后爸爸让她为她又唱了一遍,在星空下,他摸着她的振动,感受歌曲。


后来一家人一起去参加了伯克利的面试。这是家庭成员对鲁比的成全。


总结


这是一部很感人的电影,故事的讲述行云流水,每一个转折恰到好处。能够让我们聆听到悦耳的声音。


作者:随机的未知
来源:mdnice.com/writing/4a81248164b4409f8be55c27575fbf3b
收起阅读 »

Android:优雅的处理首页弹框逻辑:责任链模式

背景 随着业务的发展,首页的弹窗越来越多,隐私政策弹窗,广告弹窗,好评弹窗,应用内更新弹窗等等。 并且弹框显示还有要求,比如: 用户本次使用app,只能显示一个弹框,毕竟谁都不愿意打开app就看到一堆弹框 这些弹框有优先级:如隐私政策弹窗优先级肯定比好评弹窗...
继续阅读 »

背景


随着业务的发展,首页的弹窗越来越多,隐私政策弹窗,广告弹窗,好评弹窗,应用内更新弹窗等等。
并且弹框显示还有要求,比如:



  • 用户本次使用app,只能显示一个弹框,毕竟谁都不愿意打开app就看到一堆弹框

  • 这些弹框有优先级:如隐私政策弹窗优先级肯定比好评弹窗高,所以希望优先级高的优先显示

  • 广告弹框只展示一次

  • 等等


如何优雅的处理这个逻辑呢?请出我们的主角:责任链模式。


责任链模式


举个栗子🌰


一位男性在结婚之前有事要和父母请示,结婚之后要请示妻子,老了之后就要和孩子们商量。作为决策者的父母、妻子或孩子,只有两种选择:要不承担起责任来,允许或不允许相应的请求; 要不就让他请示下一个人,下面来看如何通过程序来实现整个流程。


先看一下类图:
未命名文件.png
类图非常简单,IHandler上三个决策对象的接口。


//决策对象的接口
public interface IHandler {
//处理请求
void HandleMessage(IMan man);
}

//决策对象:父母
public class Parent implements IHandler {
@Override
public void HandleMessage(IMan man) {
System.out.println("孩子向父母的请求是:" + man.getRequest());
System.out.println("父母的回答是:同意");
}
}

//决策对象:妻子
public class Wife implements IHandler {
@Override
public void HandleMessage(IMan man) {
System.out.println("丈夫向妻子的请求是:" + man.getRequest());
System.out.println("妻子的回答是:同意");
}
}

//决策对象:孩子
public class Children implements IHandler{
@Override
public void HandleMessage(IMan man) {
System.out.println("父亲向孩子的请求是:" + man.getRequest());
System.out.println("孩子的回答是:同意");
}
}

IMan上男性的接口:


public interface IMan {
int getType(); //获取个人状况
String getRequest(); //获取个人请示(这里就简单的用String)
}

//具体男性对象
public class Man implements IMan {
/**
* 通过一个int类型去描述男性的个人状况
* 0--幼年
* 1--成年
* 2--年迈
*/

private int mType = 0;
//请求
private String mRequest = "";

public Man(int type, String request) {
this.mType = type;
this.mRequest = request;
}

@Override
public int getType() {
return mType;
}

@Override
public String getRequest() {
return mRequest;
}
}

最后我们看下一下场景类:


public class Client {
public static void main(String[] args) {
//随机生成几个man
Random random = new Random();
ArrayList<IMan> manList = new ArrayList<>();
for (int i = 0; i < 5; i++) {
manList.add(new Man(random.nextInt(3), "5块零花钱"));
}
//定义三个请示对象
IHandler parent = new Parent();
IHandler wife = new Wife();
IHandler children = new Children();
//处理请求
for (IMan man: manList) {
switch (man.getType()) {
case 0:
System.out.println("--------孩子向父母发起请求-------");
parent.HandleMessage(man);
break;
case 1:
System.out.println("--------丈夫向妻子发起请求-------");
wife.HandleMessage(man);
break;
case 2:
System.out.println("--------父亲向孩子发起请求-------");
children.HandleMessage(man);
break;
default:
break;
}
}
}
}

首先是通过随机方法产生了5个男性的对象,然后看他们是如何就要5块零花钱这件事去请示的,运行结果如下所示:


--------丈夫向妻子发起请求-------
丈夫向妻子的请求是:5块零花钱
妻子的回答是:同意
--------丈夫向妻子发起请求-------
丈夫向妻子的请求是:5块零花钱
妻子的回答是:同意
--------父亲向孩子发起请求-------
父亲向孩子的请求是:5块零花钱
孩子的回答是:同意
--------孩子向父母发起请求-------
孩子向父母的请求是:5块零花钱
父母的回答是:同意
--------丈夫向妻子发起请求-------
丈夫向妻子的请求是:5块零花钱
妻子的回答是:同意


发没发现上述的代码是不是有点不舒服,有点别扭,有点想重构它的感觉?那就对了!这段代码有以下几个问题:



  • 职责界定不清晰



对孩子提出的请示,应该在父母类中做出决定,父母有责任、有义务处理孩子的请示,



因此Parent类应该是知道孩子的请求自己处理,而不是在Client类中进行组装出来,
也就是说 原本应该是父亲这个类做的事情抛给了其他类进行处理,不应该是这样的。



  • 代码臃肿



我们在Client类中写了if...else的判断条件,而且能随着能处理该类型的请示人员越多,
if...else的判断就越多,想想看,臃肿的条件判断还怎么有可读性?!




  • 耦合过重



这是什么意思呢,我们要根据Man的type来决定使用IHandler的那个实现类来处理请



求。有一个问题是:如果IHandler的实现类继续扩展怎么办?修改Client类?
与开闭原则违背了!【开闭原则:软件实体如类,模块和函数应该对扩展开放,对修改关闭】
http://www.jianshu.com/p/05196fac1…



  • 异常情况欠考虑



丈夫只能向妻子请示吗?丈夫向自己的父母请示了,父母应该做何处理?
我们的程序上可没有体现出来,逻辑失败了!


既然有这么多的问题,那我们要想办法来解决这些问题,我们先来分析一下需求,男性提出一个请示,必然要获得一个答复,甭管是同意还是不同意,总之是要一个答复的,而且这个答复是唯一的,不能说是父母作出一个决断,而妻子也作出了一个决断,也即是请示传递出去,必然有一个唯一的处理人给出唯一的答复,OK,分析完毕,收工,重新设计,我们可以抽象成这样一个结构,男性的请求先发送到父亲,父母一看是自己要处理的,就作出回应处理,如果男性已经结婚了,那就要把这个请求转发到妻子来处理,如果男性已经年迈,那就由孩子来处理这个请求,类似于如图所示的顺序处理图。
未命名文件 (1).png
父母、妻子、孩子每个节点有两个选择:要么承担责任,做出回应;要么把请求转发到后序环节。结构分析得已经很清楚了,那我们看怎么来实现这个功能,类图重新修正,如图 :
未命名文件 (2).png
从类图上看,三个实现类Parent、Wife、Children只要实现构造函数和父类中的抽象方法 response就可以了,具体由谁处理男性提出的请求,都已经转移到了Handler抽象类中,我们 来看Handler怎么实现,


public abstract class Handler {
//处理级别
public static final int PARENT_LEVEL_REQUEST = 0; //父母级别
public static final int WIFE_LEVEL_REQUEST = 1; //妻子级别
public static final int CHILDREN_LEVEL_REQUEST = 2;//孩子级别

private Handler mNextHandler;//下一个责任人

protected abstract int getHandleLevel();//具体责任人的处理级别

protected abstract void response(IMan man);//具体责任人给出的回应

public final void HandleMessage(IMan man) {
if (man.getType() == getHandleLevel()) {
response(man);//当前责任人可以处理
} else {
//当前责任人不能处理,如果有后续处理人,将请求往后传递
if (mNextHandler != null) {
mNextHandler.HandleMessage(man);
} else {
System.out.println("-----没有人可以请示了,不同意该请求-----");
}
}
}

public void setNext(Handler next) {
this.mNextHandler = next;
}
}

再看一下具体责任人的实现:Parent、Wife、Children


public class Parent extends Handler{

@Override
protected int getHandleLevel() {
return Handler.PARENT_LEVEL_REQUEST;
}

@Override
protected void response(IMan man) {
System.out.println("----------孩子向父母提出请示----------");
System.out.println(man.getRequest());
System.out.println("父母的回答是:同意");
}
}

public class Wife extends Handler{
@Override
protected int getHandleLevel() {
return Handler.WIFE_LEVEL_REQUEST;
}

@Override
protected void response(IMan man) {
System.out.println("----------丈夫向妻子提出请示----------");
System.out.println(man.getRequest());
System.out.println("妻子的回答是:同意");
}
}

public class Children extends Handler{
@Override
protected int getHandleLevel() {
return Handler.CHILDREN_LEVEL_REQUEST;
}

@Override
protected void response(IMan man) {
System.out.println("----------父亲向孩子提出请示----------");
System.out.println(man.getRequest());
System.out.println("孩子的回答是:同意");
}
}

那么再看一下场景复现:
在Client中设置请求的传递顺序,先向父母请示,不是父母应该解决的问题,则由父母传递到妻子类解决,若不是妻子类解决的问题则传递到孩子类解决,最终的结果必然有一个返回,其运行结果如下所示。


----------孩子向父母提出请示----------
15块零花钱
父母的回答是:同意
----------丈夫向妻子提出请示----------
15块零花钱
妻子的回答是:同意
----------父亲向孩子提出请示----------
15块零花钱
孩子的回答是:同意
----------丈夫向妻子提出请示----------
15块零花钱
妻子的回答是:同意
----------父亲向孩子提出请示----------
15块零花钱
孩子的回答是:同意

结果也正确,业务调用类Client也不用去做判断到底是需要谁去处理,而且Handler抽象类的子类可以继续增加下去,只需要扩展传递链而已,调用类可以不用了解变化过程,甚至是谁在处理这个请求都不用知道。在这种模式就是责任链模式


定义


Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.Chain the receiving objects and pass the request along the chain until an object handles it.
(使多个对象都有机会处理请求,从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有对象处理它为止。) 责任链模式的重点是在“链”上,由一条链去处理相似的请求在链中决定谁来处理这个请 求,并返回相应的结果,其通用类图如图所示
未命名文件 (3).png
最后总结一下,责任链的模版:
包含四个对象,Handler,Request,Level,Response:


public class Request {
//请求的等级
public Level getRequestLevel(){
return null;
}
}

public class Level {
//请求级别
}


public class Response {
//处理者返回的数据
}

//抽象处理者
public abstract class Handler {
private Handler mNextHandler;

//每个处理者都必须对请求做出处理
public final Response handleMessage(Request request) {
Response response = null;
if (getHandlerLevel().equals(request.getRequestLevel())) {
//是自己处理的级别,自己处理
response = echo(request);
} else {
//不是自己处理的级别,交给下一个处理者
if (mNextHandler != null) {
response = mNextHandler.echo(request);
} else {
//没有处理者能处理,业务自行处理
}
}
return response;
}

public void setNext(Handler next) {
this.mNextHandler = next;
}

@NotNull
protected abstract Level getHandlerLevel();

protected abstract Response echo(Request request);
}

实际应用


我们回到开篇的问题:如何设计弹框的责任链?


//抽象处理者
abstract class AbsDialog(private val context: Context) {
private var nextDialog: AbsDialog? = null

//优先级
abstract fun getPriority(): Int

//是否需要展示
abstract fun needShownDialog(): Boolean

fun setNextDialog(dialog: AbsDialog?) {
nextDialog = dialog
}

open fun showDialog() {
//这里的逻辑,我们就简单点,具体逻辑根据业务而定
if (needShownDialog()) {
show()
} else {
nextDialog?.showDialog()
}
}

protected abstract fun show()

// Sp存储, 记录是否已经展示过
open fun needShow(key: String): Boolean {
val sp: SharedPreferences = context.getSharedPreferences(SP_NAME, Context.MODE_PRIVATE)
return sp.getBoolean(key, true)
}

open fun setShown(key: String, show: Boolean) {
val sp: SharedPreferences = context.getSharedPreferences(SP_NAME, Context.MODE_PRIVATE)
sp.edit().putBoolean(key, !show).apply()
}

companion object {
const val LOG_TAG = "Dialog"
const val SP_NAME = "dialog"
const val POLICY_DIALOG_KEY = "policy_dialog"
const val AD_DIALOG_KEY = "ad_dialog"
const val PRAISE_DIALOG_KEY = "praise_dialog"
}
}

/**
* 模拟 隐私政策弹窗
* */

class PolicyDialog(context: Context) : AbsDialog(context) {
override fun getPriority(): Int = 0

override fun needShownDialog(): Boolean {
// 这里可以根据业务逻辑判断是否需要显示弹窗,如接口控制等等
// 这里通过Sp存储来模拟
return needShow(POLICY_DIALOG_KEY)
}

override fun show() {
Log.d(LOG_TAG, "显示隐私政策弹窗")
setShown(POLICY_DIALOG_KEY, true) //记录已经显示过
}
}

/**
* 模拟 广告弹窗
* */

class AdDialog(private val context: Context) : AbsDialog(context) {
private val ad = DialogData(1, "XX广告弹窗") // 模拟广告数据

override fun getPriority(): Int = 1

override fun needShownDialog(): Boolean {
// 广告数据通过接口获取,广告id应该是唯一的,所以根据id保持sp
return needShow(AD_DIALOG_KEY + ad.id)
}

override fun show() {
Log.d(LOG_TAG, "显示广告弹窗:${ad.name}")
setShown(AD_DIALOG_KEY + ad.id, true)
}
}

/**
* 模拟 好评弹窗
* */

class PraiseDialog(context: Context) : AbsDialog(context) {
override fun getPriority(): Int = 2

override fun needShownDialog(): Boolean {
// 这里可以根据业务逻辑判断是否需要显示弹窗,如用户使用7天等
// 这里通过Sp存储来模拟
return needShow(PRAISE_DIALOG_KEY)
}

override fun show() {
Log.d(LOG_TAG, "显示好评弹窗")
setShown(PRAISE_DIALOG_KEY, true)
}
}

//模拟打开app
val dialogs = mutableListOf<AbsDialog>()
dialogs.add(PolicyDialog(this))
dialogs.add(PraiseDialog(this))
dialogs.add(AdDialog(this))
//根据优先级排序
dialogs.sortBy { it.getPriority() }
//创建链条
for (i in 0 until dialogs.size - 1) {
dialogs[i].setNextDialog(dialogs[i + 1])
}
dialogs[0].showDialog()

第一次打开
image.png


第二次打开
image.png


第三次打开
image.png


总结:



  • 优点


责任链模式非常显著的优点是将请求和处理分开。请求者可以不用知道是谁处理的,处理者可以不用知道请求的全貌,两者解耦,提高系统的灵活性。



  • 缺点


责任链有两个非常显著的缺点:一是性能问题,每个请求都是从链头遍历到链尾,特别是在链比较长的时候,性能是一个非常大的问题。二是调试不很方便,特别是链条比较长, 环节比较多的时候,由于采用了类似递归的方式,调试的时候逻辑可能比较复杂。



  • 注意事项


链中节点数量需要控制,避免出现超长链的情况,一般的做法是在Handler中设置一个最大节点数量,在setNext方法中判断是否已经是超过其阈值,超过则不允许该链建立,避免无意识地破坏系统性能。


作者:蹦蹦蹦
来源:juejin.cn/post/7278239421706633252
收起阅读 »

腾讯女后端设计了一套短链系统,当场就想给她offer!

你好,我是猿java 如上图,对于这种客评短信,相信大家并不陌生,通过点击短信里“蓝色字体”,就能跳转到一个网页。其实,背后的秘密就是一套完整的短链系统,今天我们就来看看字节的后端女生是如何设计的? 上图中那串蓝色字符,有个专业的术语叫做“短链”,它可以是一...
继续阅读 »

你好,我是猿java


image.png


如上图,对于这种客评短信,相信大家并不陌生,通过点击短信里“蓝色字体”,就能跳转到一个网页。其实,背后的秘密就是一套完整的短链系统,今天我们就来看看字节的后端女生是如何设计的?


上图中那串蓝色字符,有个专业的术语叫做“短链”,它可以是一个链接地址,也可以设计成二维码。


为什么要用短链?


存在既合理,这里列举 3个主要原因。


1.相对安全


短链不容易暴露访问参数,生成方式可以完全迎合短信平台的规则,能够有效地规避关键词、域名屏蔽等风险,而原始 URL地址,很可能因为包含特殊字符被短信系统误判,导致链接无法跳转。


2.美观


对于精简的文字,似乎更符合美学观念,不太让人产生反感。


3.平台限制


短信发送平台有字数限制,在整条短信字数不变的前提下,把链接缩短,其他部分的文字描述就能增加,这样似乎更能达到该短信的实际目的(比如,营销)。


短链的组成


如下图,短链的组成通常包含两个部分:域名 + 随机码


image.png


短链的域名最好和其他业务域名分开,而且要尽量简短,可以不具备业务含义(比如:xyz.com),因为短链大部分是用于营销,可能会被三方平台屏蔽。


短链的随机码需要全局唯一,建议 10位以下。


短链跳转的原理


首先,我们先看一个短链跳转的简单例子,如下代码,定义了一个 302重定向的代码示例:


import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.servlet.view.RedirectView;

@Controller
public class RedirectController {

@GetMapping("/{shortCode}")
public RedirectView redirect(@PathVariable String shortCode) {
String destUrl = "https://yuanjava.com";
// destUrl = getDestUrlByShortCode(shortCode); //真实的业务逻辑
return new RedirectView(destUrl);
}
}

接着,在浏览器访问短链”http://127.0.0.1:8080/s2TYdWd” 后,请求会被重定向到 yuanjava.com ,下图为浏览器控制台信息:


image.png


从上图,我们看到了 302状态码并且请求被 Location到另外一个 URL,整个交互流程图如下:


image.png


是不是有一种偷梁换柱的感觉???


最后,总结下短链跳转的核心思想:


生成随机码,将随机码和目标 URL(长链)的映射关系存入数据库;


用域名+随机码生成短链,并推送给目标用户;


当用户点击短链后,请求会先到达短链系统,短链系统根据随机码查找出对应的目标 URL,接着将请求 302重定向到目标 URL(长链);


关于重定向有 301 和 302两种,如何选择?



  • 302,代表临时重定向:每次请求短链,请求都会先到达短链系统,然后重定向到目标 URL(长链),这样,方便短链系统做一些统计点击数等操作;通常采用 302

  • 301,代表永久重定向:第一次请求拿到目标长链接后,下次再次请求短链,请求不会到达短链系统,而是直接跳转到浏览器缓存的目标 URL(长链),短链系统只能统计到第一次访问的数据;一般不采用 301。


如何生成短链?


从短链组成章节可以知道短链=域名+随机码,随意如何生成短链的问题转换成了如何生成一个随机码,而且这个随机码需要全局唯一。通常会有 3种做法:


Base62


Base62 表示法是一种基数为62的数制系统,包含26个英文大写字母(A-Z),26个英文小写字母(a-z)和10个数字(0-9)。这样,共有62个字符可以用来表示数值。 如下代码:


import java.security.SecureRandom;

public class RandomCodeGenerator {
private static final String CHAR_62 = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
private static final SecureRandom random = new SecureRandom();

public static String generateRandomCode(int length) {
StringBuilder sb = new StringBuilder(length);
for (int i = 0; i < length; i++) {
int rndCharAt = random.nextInt(CHAR_62.length());
char rndChar = CHAR_62.charAt(rndCharAt);
sb.append(rndChar);
}
return sb.toString();
}
}

对于 Base62算法,如果是生成 6位随机数有 62^6 - 1 = 56800235583, 568亿多,如果是生成 7位随机数有 62^7 - 1 = 3521614606208,合计3.5万亿多,足够使用。


Hash算法


Hash算法算法是我们最容易想到的办法,比如 MD5, SHA-1, SHA-256, MurmurHash, 但是这种算法生成的 Hash算法值还是比较长,常用的做法是把这个 Hash算法值进行 62/64进行压缩。


如下代码,通过 Google的 MurmurHash算法把长链 Hash成一个 32位的 10进制正数,然后再转换成62进制(压缩),这样就可以得到一个 6位随机数,


import com.google.common.hash.HashFunction;
import com.google.common.hash.Hashing;
import java.nio.charset.StandardCharsets;

public class MurmurHashToBase62 {

private static final String BASE62 = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
public static String toBase62(int value) {
StringBuilder sb = new StringBuilder();
while (value > 0) {
sb.insert(0, BASE62.charAt(value % 62));
value /= 62;
}
return sb.toString();
}
public static void main(String[] args) {
// 长链
String input = "https://yuanjava.cnposts/short-link-system/design?code=xsd&page=1";
// 长链利用 MurmurHash算法生成 32位 10进制数
HashFunction hashFunction = Hashing.murmur3_32();
int hash = hashFunction.hashString(input, StandardCharsets.UTF_8).asInt();
if (hash < 0) {
hash = hash & 0x7fffffff; // Convert to positive by dropping the sign bit
}
// 将 32位 10进制数 转换成 62进制
String base62Hash = toBase62(hash);
System.out.println("base62Hash:" + base62Hash);
}
}

全局唯一 ID


比如,很多大中型公司都会有自己全局唯一 ID 的生成服务器,可以使用这些服务器生成的 ID来保证全局唯一,也可以使用雪花算法生成全局唯一的ID,再经过 62/64进制压缩。


如何解决冲突


对于上述3种方法的前 2种:base62 或者 hash,因为都是哈希函数,所以,不可避免地会产生哈希冲突(尽管概率很低),该怎么解决呢?


要解决冲突,首先要检测冲突,通常来说有 3种检测方法。


数据库索


如下,这里以 MySQL数据库为例(也可以保存在 Redis中),表结构如下:


CREATE TABLE `short_url_map` (   
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`long_url` varchar(160) DEFAULT NULL COMMENT '长链',
`short_url` varchar(10) DEFAULT NULL COMMENT '短链',
`gmt_create` int(11) DEFAULT NULL COMMENT '创建时间',
PRIMARY KEY (`id`),
UNIQUE INDEX 'short_url' ('short_url')
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

首先创建一张长链和短链的关系映射表,然后通过给 short_url字段添加唯一锁,这样,当数据插入时,如果存在 Hash冲突(short_url值相等),数据库就会抛错,插入失败,因此,可以在业务代码里捕获对应的错误,这样就能检测出冲突。


也可以先用 short_url去查询,如果能查到数据,说明 short_url存在 Hash冲突了。


对于这种通过查询数据库或者依赖于数据库唯一锁的机制,因为都涉及DB操作,所以对数据库是一个开销,如果流量比较大的话,需要保证数据库的性能。


布隆过滤器过滤器


在 DB操作的上游增加一个布隆过滤器,在长链生成短链后, 先用短链在布隆过滤器中进行查找,如果存在就代表冲突了,如果不存在,说明 DB里不存在此短链,可以插入。 对于布隆过滤器的选择,单机可以采用 Google的布隆过滤器,分布式可以使用 RedisBloom。


整体流程可以抽象成下图:


image.png


检测出了冲突,需要如何解决冲突?


再 Hash,可以在长链后面拼接一个 UUID之类的随机字符串,然后再次进行 Hash,用得出的新值再进行上述检测,这样 Hash冲突的概率又大大大的降低了。


高并发场景


在流量不大的情况,上述方法怎么折腾似乎都没有问题,但是,为了架构的健壮性,很多时候需要考虑高并发,大流量的场景,因此架构需要支持水平扩展,比如:



  • 采用微服务

  • 功能模块分离,比如,短链生成服务和长链查询服务分离

  • 功能模块需要支持水平扩容,比如:短链生成服务和长链查询服务能支持动态扩容

  • 缓解数据库压力,比如,分区,分库分表,主从,读写分离等机制

  • 服务的限流,自保机制

  • 完善的监控和预警机制


这里给出一套比较完整的设计思路图:


image.png


总结


本文通过一个客服评价的短信开始,分析了短链的构成,短链跳转的原理,同时也给出了业内的一些实现算法,以及一些架构上的建议。


对于业务体量小的公司,可以根据成本来搭建服务(单机或者少量服务器做负载),对于业务体量比较大的公司,更多需要考虑到高并发的场景,如何保证服务的稳定性,如何支持水平扩展,当服务出现问题时如何具备一套完善的监控和预警服务器。


其实,很多系统都是在一次又一次的业务流量挑战下成长起来的,我们需要不断打磨自己宏观看架构,微观看代码的能力,这样自己也就跟着业务,系统一起成长起来了。


作者:猿java
来源:juejin.cn/post/7350585600858898484
收起阅读 »

手把手教集成环信新版UIKit组件,快速构建Android应用

前言环信新版UIKit已重磅发布!目前包含单群聊UIKit、聊天室ChatroomUIKit,本文详细讲解Android端单群聊UIKit的集成教程。环信单群聊 UIKit 是基于环信即时通讯云 IM SDK 开发的一款即时通讯 UI 组件库,提供各种组件实现...
继续阅读 »

前言

环信新版UIKit已重磅发布!目前包含单群聊UIKit、聊天室ChatroomUIKit,本文详细讲解Android端单群聊UIKit的集成教程。

环信单群聊 UIKit 是基于环信即时通讯云 IM SDK 开发的一款即时通讯 UI 组件库,提供各种组件实现会话列表、聊天界面、联系人列表及后续界面等功能,帮助开发者根据实际业务需求快速搭建包含 UI 界面的即时通讯应用。



在环信旧版UIkit 中,很多开发者比较头疼的是头像昵称问题,新版UIkit 将解决这一烦恼。新的UIkit从消息扩展中获取昵称和头像,把用户基本的昵称和头像的URL放到消息的扩展中,通过消息传递给接收方,当收到一条消息时,则通过消息的扩展得到发送者的昵称和头像URL,然后保存到本地数据库和缓存,需要显示昵称和头像时进行获取。

此外,新版UIkit 使用的是Kotlin语言进行开发,目前支持本地module 形式的导入,远程依赖可以关注官网后续更新。

官方文档链接

1、本地module 导入

集成条件以及环境配置需要参考文档 :

https://doc.easemob.com/uikit/chatuikit/android/chatuikit_quickstart.html
hatuikit/android/chatuikit_quickstart.html

本地module 导入:选择File - new - import module 进行导入。


部分项目按照上面可能会导入失败。可以选择把 ease-im-kit 放到跟app 一个级别下面,手动进行配置。
在settings.gradle.kts 下进行添加

include(":ease-im-kit")


在app module 下进行添加本地依赖

implementation(project(mapOf("path" to ":ease-im-kit")))

导入以后编译项目即可

2、设置聊天界面的头像昵称

用户调用 EaseIM.login 方法登录时需要传入一个 EaseProfile 对象,包含 idname 和 avatar 三个属性。id 为必填参数,name和 avatar 用于展示当前用户昵称和头像。发送消息时,将 name 和 avatar 属性设置到消息的 ext 中,方便其他用户展示。

EaseIM.login(
user = EaseProfile(
id = "",
name = "",
avatar = ""
),
token = "",
onSuccess = {

},
onError = {code,error ->

}
)

这里登录时进行了设置。发消息时把头像昵称携带在扩展字段里面,扩展字段key 如下

exts: [{key: ease_chat_uikit_user_info,type: 8,value: {"nickname": "小刚","avatarURL": "https:\/\/img0.baidu.com\/it\/u=4105778329,1297102594&fm=253&app=120&size=w931&n=0&f=JPEG&fmt=auto?sec=1710954000&t=d0bfcba4c95d2e7b9bc8aaaf870f0582"}}]

接收到消息以后UIKit 会进行处理,聊天页面就可以展示头像跟昵称了




这里接收到的消息获取到扩展字段解析如下

val jsonObject = JSONObject(message.ext().get("ease_chat_uikit_user_info").toString())
jsonObject.get("nickname").toString()//获取昵称
jsonObject.get("avatarURL").toString()// 获取头像

3、设置会话列表的头像和昵称

EaseIM.setConversationInfoProvider(object : EaseConversationInfoProvider {
// 同步获取会话信息
override fun getProfile(id: String?, type: ChatConversationType): EaseProfile? {
return when(type) {
ChatConversationType.Chat ->{
// 可以从本地数据库或者缓存中获取用户信息,并返回,不可进行异步操作。
loadUserInfoFromLocal(id)
}

ChatConversationType.GroupChat -> {
// 可以从本地数据库或者缓存中获取群组信息,并返回,不可进行异步操作。
loadGroupInfoFromLocal(id)
}

else -> null
}
return null
}

override fun fetchProfiles(
idsMap:
Map
>,
onValueSuccess:
OnValueSuccess
>
)
{
fetchProfilesFromServer(idsMap, onValueSuccess)
}

})

这里可以在接收到消息以后更新会话列表的头像昵称,也可以通过从服务端获取,获取到以后调用上面方法进行设置。
在上面代码中 loadUserInfoFromLocal(id) 是需要自己从本地获取,然后设置到会话列表中,这里也可以在接收消息时从消息扩展字段获取对方的信息时进行设置。

4、会话列表的使用

通过继承 EaseConversationListFragment 进行自定义设置


EaseConversationListFragment 里面实现了页面跳转逻辑,如果继承EaseConversationListFragment 的情况下需要实现对应的方法,也可以直接使用EaseConversationListFragment 。

至此,集成与头像昵称使用介绍完,要比历史版本头像昵称实现简单很多,欢迎大家体验使用环信新版UIkit,有更多丰富功能助您快速实现单群聊完整功能!

参考文档

收起阅读 »

前端如何用密文跟后端互通?原来那么简单!

web
后端:密码得走密文哇! 我:base64?md5? 后端:这次不行哇,新来的测试不好糊弄呢!必须要国密sm2加密捏 我: 好吧,看我的。 我这边使用的是sm-crypto,当然也有很多优秀的库如:forge,我在业务上搭配jszip做过上传zip文件内藏加密后...
继续阅读 »

后端:密码得走密文哇!

我:base64?md5?

后端:这次不行哇,新来的测试不好糊弄呢!必须要国密sm2加密捏

我: 好吧,看我的。


我这边使用的是sm-crypto,当然也有很多优秀的库如:forge,我在业务上搭配jszip做过上传zip文件内藏加密后的私钥进行证书登录,还是不错的支持,但是文档社区不是很友好,所以推荐sm-crypto,接下来让我们一起使用它吧。


sm-crypto是一个基于Node.js的密码学库,专为与国密算法(中国密码算法标准)兼容而设计。它提供了各种加密、解密、签名和验证功能。


sm-crypto包含多种密码算法的实现,例如:



  • SM1:对称加密算法,其加密强度与AES相当,但该算法不公开,调用时需要通过加密芯片的接口进行调用。

  • SM2:非对称加密算法,基于ECC(椭圆曲线密码学)。该算法已公开,且由于基于ECC,其签名速度与秘钥生成速度都快于RSA。此外,ECC 256位(SM2采用的就是ECC 256位的一种)的安全强度比RSA 2048位高,但运算速度快于RSA。

  • SM3:消息摘要算法,可以用MD5作为对比理解,其校验结果为256位。

  • SM4:无线局域网标准的分组数据算法,属于对称加密,密钥长度和分组长度均为128位。


sm-crypto内部方法介绍


1.SM2加密与解密


SM2是一种基于椭圆曲线密码学的非对称加密算法。sm-crypto提供了SM2的密钥生成、加密、解密等功能。通过调用相关方法,开发者可以轻松地生成SM2密钥对,并使用公钥进行加密、私钥进行解密。


const { sm2 } = require('sm-crypto');  
const keyPair = sm2.generateKeyPairHex(); // 生成密钥对
const publicKey = keyPair.publicKey; // 公钥
const privateKey = keyPair.privateKey; // 私钥

const message = 'Hello, SM2!'; // 待加密的消息
const encrypted = sm2.doEncrypt(message, publicKey, { hash: true }); // 使用公钥加密
const decrypted = sm2.doDecrypt(encrypted, privateKey, { hash: true, raw: true }); // 使用私钥解密

console.log('加密结果:', encrypted);
console.log('解密结果:', decrypted.toString()); // 输出原始消息

image.png


2.SM3摘要算法


SM3是一种密码杂凑算法,用于生成消息的摘要值。sm-crypto提供了SM3的摘要计算功能,开发者可以通过调用相关方法计算任意消息的SM3摘要值。


const { sm3 } = require('sm-crypto');  
const message = 'Hello, SM3!'; // 待计算摘要的消息
const digest = sm3(message); // 计算SM3摘要值

console.log('SM3摘要值:', digest);

image.png


3.SM4分组加密算法


SM4是一种分组密码算法,适用于无线局域网等场景。sm-crypto提供了SM4的加密与解密功能,开发者可以使用SM4密钥对数据进行加密和解密操作。


const sm4 = require('sm-crypto').sm4;                                               |
const sm4 = require('sm-crypto').sm4;
const key = '0123456789abcdeffedcba9876543210'; // 16字节的SM4密钥
const message = 'Hello, SM4!'; // 待加密的消息
const encrypted = sm4.encrypt(Buffer.from(message), Buffer.from(key, 'hex')); // 加密
const decrypted = sm4.decrypt(encrypted, Buffer.from(key, 'hex')); // 解密

console.log('加密结果:', encrypted.toString('hex'));
console.log('解密结果:', decrypted.toString()); // 输出原始消息

image.png


4、签名/验签


签名(Sign)


const { sm2 } = require('sm-crypto'); 
const keyPair = sm2.generateKeyPairHex(); // 生成密钥对
const publicKey = keyPair.publicKey; // 公钥
const privateKey = keyPair.privateKey; // 私钥

const message = '这是要签名的消息'; // 替换为实际要签名的消息
// 使用私钥对消息进行签名
let sigValueHex = sm2.doSignature(message, privateKey);
console.log('签名结果:', sigValueHex);

image.png
验签(Verify Signature)


const message = '这是要验证签名的消息'; // 应与签名时使用的消息相同  
const sigValueHex = '签名值'; // 替换为实际的签名值字符串,即签名步骤中生成的sigValueHex

// 使用公钥验证签名是否有效
let verifyResult = sm2.doVerifySignature(message, sigValueHex, publicKey);

console.log('验签结果:', verifyResult); // 如果验证成功,应输出true;否则输出false


image.png


实战例子


登录注册,对用户密码进行加密



注意:前端是不储存任何涉及安全的密钥(公钥是直接拿后端生成的)。



新建个工具文件,专门存放加密逻辑,我这用的是SM2


// smCrypto.js
import { sm2 } from 'sm-crypto' // 引入加密库

export const doEncrypt = ( // 加密
data,
pKey = publicKey,
cipherMode = 0
) =>
sm2.doEncrypt(
typeof data === 'object'
? JSON.stringify(data) : data,
pKey,
cipherMode
)
export const encryptionPwd = async data => { // 加密密码高阶
let servePublicKey = ''
await user.getSm2Pkeys()
.then(res => {
servePublicKey = res.data.content
})
return doEncrypt(
data,
servePublicKey
)
}

sm-crypto作为一款基于Node.js的国密算法库,为开发者提供了丰富的密码学功能。通过调用sm-crypto的内部方法,开发者可以轻松地实现SM2加密与解密、SM3摘要计算以及SM4分组加密等操作。这些功能在保障数据安全、构建安全应用等方面发挥着重要作用。同时,开发者在使用sm-crypto时,也需要注意遵循最佳的安全实践,确保密钥的安全存储和管理,以防止潜在的安全风险。


作者:大码猴
来源:juejin.cn/post/7350168797637558272
收起阅读 »

浏览器无痕模式就真的无痕了吗?不一定哦!

web
概述 无痕模式,有些浏览器也叫隐身模式,隐私模式。该模式下所有cookie、缓存是失效的,也就是所有原来的登录信息都会消失,那么是否你打开一个网站,网站平台就真的不确定你是谁了吗? 不一定哦。这个世界上有一种技术叫浏览器指纹技术,不需要你登录,它就可以根据你的...
继续阅读 »

概述


无痕模式,有些浏览器也叫隐身模式,隐私模式。该模式下所有cookie、缓存是失效的,也就是所有原来的登录信息都会消失,那么是否你打开一个网站,网站平台就真的不确定你是谁了吗? 不一定哦。这个世界上有一种技术叫浏览器指纹技术,不需要你登录,它就可以根据你的特定标志来区分,从而跟踪你的所有操作记录。今天我们就来看看这种技术的原理,还有用途。


一、原理


浏览器指纹可以在用户没有任何登录的情况下仍然知道你谁,比如你在登录了一下网站A,现在开启无痕模式,再次打开网站A, 那么网站A大概率还是能区分现在操作网站的人是谁。 因为在这个世界上,用户的浏览器环境极小概率才能相同,考虑的因素包括浏览器版本、浏览器型号、屏幕分辨率、系统语言、本地时间、CPU架构、电池状态、网络信息、已安装的浏览器插件等等各种各样。浏览器指纹技术就是用这些因素来综合计算一个哈希值,这个哈希值大概率是唯一的


二、展示


今天我们就展示一下单单利用Canvas画布这个功能来确定用户的唯一标识,因为Canvas API专为通过JavaScript和HTML绘制图形而设计,而图形在画布上的呈现方式可能因Web浏览器、操作系统、显卡和其他因素而不一样,从而产生可用于创建指纹的唯一图像,我们利用下方代码展示一个图像。


// 输入一个带有小写、大写、标点符号的文本
var txt = "BrowserLeaks,com <canvas> 1.0";
ctx.textBaseline = "top";
ctx.font = "14px 'Arial'";
ctx.textBaseline = "alphabetic";
ctx.fillStyle = "#f60";
ctx.fillRect(125,1,62,20);
ctx.fillStyle = "#069";
ctx.fillText(txt, 2, 15);
ctx.fillStyle = "rgba(102, 204, 0, 0.7)";
ctx.fillText(txt, 4, 17);

下面动画GIF图展示了虽然JavaScript代码相同,但是由于图像在不同系统上的呈现方式不同,因此每一个用户所显示的图像都有细微的差别。这种差别大多数时候人眼通常无法识别,但通过对生成图像的数据进行分析就能发现不一样。



我们直接看成品,利用普通模式和无痕模式打开这个测试网站,就能发现2个哈希值是完全一样的,并且是每15万个用户中有2个人可能是相同的哈希值,唯一性达到了99.99%。


三、用途


1、广告


广告联盟通过浏览器指纹技术,不需要你登录,就可以知道你看过哪些记录,然后在其他站点给你推送你感兴趣的广告。所以有时候我们经常会碰到在淘宝或者百度搜索了一个商品,然后去到其他网站,马上给你推送你搜索过的商品的广告。


2、防刷


针对一些商品的浏览量、内容的阅读量、投票等等各种类似平台,往往会针对用户做一个限制,比如只能浏览一次。这种时候往往也都是用浏览器指纹技术,虽然你可能注册了很多用户账号,但是你的浏览器指纹都是相同的,可以判断你就是同一个人。不过上有政策,下有对策,有个东西叫做指纹浏览器,这类浏览器里面可以随意的切换用户的指纹。 所以这个技术针对广大的普通用户防刷还是有效的,对专业的刷量工作室就没什么效果了。


作者:明同学
来源:juejin.cn/post/7347958786050637875
收起阅读 »

勇闯天涯-程序员小哥哥,来婚介所试一下嘛(七千字长文预警!)

前言 今天技术博主不聊技术,聊聊生活聊聊情感。先叠个甲,我纯纯乐子人,对婚介所无任何恶意,可能后面还得用上,本次纯纯试探下婚介所是个什么路数!事件源于上周五的一通红娘电话,我一听要给我介绍有钱有颜的小姐姐,直接挂断,这天底下哪有这样的好事。当天下午的时候,又给...
继续阅读 »

前言


今天技术博主不聊技术,聊聊生活聊聊情感。先叠个甲,我纯纯乐子人,对婚介所无任何恶意,可能后面还得用上,本次纯纯试探下婚介所是个什么路数!事件源于上周五的一通红娘电话,我一听要给我介绍有钱有颜的小姐姐,直接挂断,这天底下哪有这样的好事。当天下午的时候,又给我来了一通电话,仿佛不知道我给她挂断了一样,基于一些奇妙的想法,我想尝试以及找找素材,我决定让她微信跟我聊。然后因为博主工作比较忙,打了招呼后,就没理她,最关键是到晚上下班后,我也忘了这档子事。周六的下午四点左右,一通电话开启了本次的故事,即使315曝光了相关产业,但是博主依然要冲,就是头铁。


阳光下午的微醺时光


接到电话的时候,我挺疑惑的,这次上来就问我现在是不是有空,出于礼貌,并且我也听出了她是昨天那个红娘,我就没有挂断电话。上来就说,弟弟,我是XX老师,今天来电话主要是聊一下,看能不能进一步推荐小姐姐。说她那里看资料我是97年的程序员,年收入XX,对吗?然后我说是,她就跟我说这里有个小姐姐挺合适的,北京XX工作的,身高165身高,本地的,收入XX。哥们一听就懵了,本地的,心里OS是,那咋遭得住,咱也不是高富帅,纯纯普男。红娘一听就问我有没有考虑常驻北京,然后就问我老家哪里的,我说四川的,她就在资料库里找了找,说真有个四川在北京的,快速给我念了一遍女生的资料。


接着就离谱了,问我怎么称呼?我说姓王,哪里工作,海淀XX公司?红娘直接薄纱,诶,没听过耶( •̀ ω •́ )y,咱们一般服务百度、阿里和字节的比较多。好好好,北京人中龙凤就是多,哥们就是菜中菜,脸都绿了。接着问我加班如何,公司福利啥的,然后说我这个181cm的身高在四川挺高的,她知道的四川男生都不太高来着。然后聊到了哥们的毕业学校,说前两天有个大连理工的女孩,真绝了,大家都这么爱走婚介所吗?我感觉聊到啥,都有女孩能配上,后面说到工作,又聊到一个大二的姑娘还没工作就来找对象了,好好好,走上了人生快车道。


然后聊到了我父母的职业,就说哥们的条件在当地不错,怎么没找上对象?我当时就说到了我的前对象,网恋的,就在掘金找的,一说到这个,好兄弟们,掘金真的能找对象的,不骗人。我的失败不是网恋的问题,纯属我自己的问题,第一次谈吧,不知道咋谈,自己也是摸不准进度,达不到对象的期待,慢慢地就淡了。我也是无脑纯爱战士,这是红娘听了之后的评价,哈哈,不过我觉得前对象确实挺不错的,当时要是硬扛着也能继续,但是我感觉可能是热情燃尽了,她也算是太忙了太累了,无论是生活还是工作,我都挺佩服,主动退出,我感觉应该是我被甩了。不后悔,男人就该当断即断,她也不小了,继续耗着,对她不公平。说远了啊,核心意思就是,网恋也有靠谱的,掘金这质量高的离谱,大家多去相亲角看看。


说着说着,突然红娘聊到了星座,说我应该了解了解星座,也说到了一些星座的小知识。然后顺嘴提到了应该门当户对,不只是能力,还有三观,阶层之类的。接着说道,我条件还行,为啥这么晚谈恋爱,是不是打游戏了?我说姐,没毛病,游戏真好玩!又接着问我单身多久了,身边还有没有介绍的呀,同事父母啥的资源。接着就进入正题了,就说小弟弟你呀,身边没有资源,姐姐这里有呀,你又有点慢热,男人花期这么短,这不得抓紧时间。你没谈就是没有遇到合适的人,圈子太小,北京这边初婚太晚了,25岁才准备开始,你想想四川重庆那边20左右就开始准备结婚了,你回去那就是大龄青年了,不是市场上最合适的那一批了。姐姐之前认识一个大哥,一年给女生花了七八万,环球影城去哈尔滨各种礼物砸下去结果手都没牵上。我???这不是大冤种嘛,移动ATM。红娘就跟我说,弟弟你啊,现在这恋爱能力,跟女生比划比划半年结果嘴都亲不上,咱们也不要浪费时间,选对人比胡乱去试强多了。姐姐我这啊,适合你的资源还蛮多的呀,你是B站来的资源,这种比较少,一般只占15%,我们婚介所大部分都是线下和国企政府合作的,所以需要你提供一定的身份和征信资料,因为我们这的姑娘都是认证过的,要对大家负责。接着又说觉得我性格比较好,很坦诚,就问我对女生有没有什么要求,我说年龄上不超过我三岁吧,不抽烟不去酒吧夜店,然后红娘跟我说,你这就没别的要求啦,那还挺低的,然后就问我三观、家庭情况之类的要求,问的很细。然后谈笑间,红娘给我猛推三个女生,嘎嘎读资料,听得哥们心里发慌,动不动就是大厂,家里有矿,问女生条件是否符合我的要求.......我真蚌埠住了,哥们真的配嘛,这条件谷歌,父母地方小领导或者开公司,问我符不符合,好好好,我能傍富婆不?


有一说一,专业红娘就是能聊,我俩聊了得有一小时,最后说让我去线下谈,给我预约了她明早10点半的时间。她想要了解下我这个人的衣着品位、谈吐举止、再做下深度的了解,以及一些信息的认证,同时也给我一些情感上的建议,让我少走些弯路。哥们听到情感上的建议,真的心动了,教练,俺就缺这个,确认了下这次聊天不收钱,就是个单纯的信息认证,我就决定去了。


小雨霖霖的春日午前


因为约好的时间是10点半,我住在石景山,婚介所在朝外SOHO那里,差不多一小时十几分钟的路程,我就九点出发了。到了地方之后,周围有好几个SOHO,没有明显指示牌,而且感觉周日早上那里人也少,当时就觉得奇怪了。因为事前的时候,跟亲友和群里的小伙伴下过军令状,不掏一分钱,实时播报进度,没消息就赶紧救我,所以我倒也没有特别慌。我的想法就很纯粹,想通过红娘的眼睛来认识我在相亲市场中是什么样的,因为我接触的人相对少嘛,所以也算是练练胆,特别是这种情感上的,多积累积累经验总没错。没找到地方,我就拍了个附件的标识给红娘老师,她就指挥我上了楼,上楼之后还蛮吓人的,左边黑的,右边就她家灯亮的。


进门之后有个助理来接待,给了我一张表单去填,相对详细哈,但是身-份-证这敏感信息可以选择不填,其实这会儿我觉得还挺不错,放下了防备,但是打开了录音,哈哈。把我领到一个逼仄的会议室,大概两平米吧,首先给我拍了一张坐着的照片,然后在我填表的时候,说要看下我的征信,简单点的就看芝麻信用就行,看了我的八百多分吧,就说你这还蛮高的。又试探性的问了能不能看下花呗借呗之类的,我寻思着也没多少额度,那就看呗,他一看就挺奇怪的,就说按你这个分数应该有好几万才对呀,你是自己调了吗?我说是呀,没事搞那么多干啥,又问我有没有信用卡,我说就拿花呗当信用卡。又说想看我支付宝里的资产,我寻思着没几个钱,那就看呗。他一看就说,你没炒基金股票啥的嘛,我说没,他就顺着话说,昨天有个姑娘和你一样,也是这样的,她就喜欢这种稳赚不赔的。浅聊了一下就说,去给我叫红娘老师,说红娘老师特别看重我,昨天周六来了好多姑娘,很多都不错的,让我跟红娘老师好好学学。哥们一听这个就来劲了,好啊,就是要这个,我不就缺这套恋爱情商嘛。


热情似火的夏日狂欢


红娘老师进来首先点评了我的头发,有点长还有点凌乱,说怎么还没理发呀。这一点说的挺对,我快一个月没理了,因为头发烫过,又有点长,显得乱。然后又说我好白呀,南方人皮肤就是好,因为我有痘痘嘛,就聊了聊油性皮肤。然后就跟我说想看看我短发的照片,说比较难想象我短发的照片,又说我这个是不是渣男锡纸烫,认出来了我这是前刺发型,感谢我的四川托尼,摩根前刺音容犹在。然后又说我字写的还不错,我说着就没必要硬夸了吧,她说跟其他人对比算是工整了。因为看到我手机壳了,就问我是个什么图案,我给她看了是二次元,她就问我是不是老爱玩B站,是不是博主,我说我哪是啊,只是喜欢看。她就说你声音还蛮好听的有点像肖战,可以整点视频啥的,说不定还能火。我说没那颜值,哈哈,谈笑间我就给她发了几张我的生活照,还有全身照片。她就说没有很胖呀,看着还好,而且家里还蛮干净的,弟弟习惯不错。


我也比较能说嘛,我就说红娘老师怎么不开个号啥的,吐吐槽啥的,比如B站上的XX说媒啥的。她跟我说她们上班很忙的,周一周二休息,平时都是快九点才下班,哪有时间开视频吐槽,都是朋友之间聊聊。然后她就很好奇我之前电话里说的前对象嘛,就聊了聊我前对象的事。因为我是抱着想要咨询的目的来的,所以我也说的相对比较详细,红娘比较在意的点是各阶段时间点、怎么认识的、告白怎么做的、准备了什么样的礼物和GG的理由。大致说了一遍,我觉得我前女友挺好的,无奈博主高攀不上,也没有达到人家的期望,就选择了默默退出。前女友说实话很不错的,情侣头像是我先换她才换的,我说话她也会回我,是我感觉被甩了,也是她有点冷吧,就放弃了。说这些呢,也是跟前面一样,说一下兄弟们要勇敢冲,掘金相亲角也靠谱,哪有那么多渣女,大部分还是好女孩,希望大家都把握得住,找到合适的另一半!


红娘老师跟我说了几个之前来聊的哥们,就说谈恋爱不能太晚,有一些大哥因为圈子比较小,导致来婚介所就想找个合适的姑娘一步到位。但是哪有这么合适的呀,一点攻略和目标都没有,怎么可能一口吃个胖子!我也附和老师说,对啊,心急吃不了热豆腐。然后就跟我说,昨天来了两哥们,一个京东一个百度的,还有00年来找对象的,我一听都懵了,这不都是人中龙凤嘛,这还愁对象,有没有大厂哥们来现身说法的,让小弟我长长见识。聊着聊着,就跟我看了个小姐姐,大四左右吧,想找个大五岁左右工作稳定的哥们,本身条件很优秀的,北交大硕士进国企,所以想要个稳定的生活。反正红娘老师意识就是说,现在女生吧,恋商普遍比男生多个三五年,现在这么卷,考虑得都比较现实。然后就说现在女生都是要求有钱有颜,小弟弟你也没钱,正在发展期嘛,颜的话还算周正,需要打理打理。然后就说想看看我之前的照片,要看我手机,emmm,这时候我没发现这是个套路,应该之前有哥们也做过这事儿。我有开录音嘛,左上角有小标,很烦,红娘应该是特意盯了这个地方,一开始问我怎么不给她看手机,而是直接发给她。我也没在意,她就老找理由看我手机,然后我也不小心被她看见了,她就问我是不是忘了关导航,哈哈,我打了个马虎眼就过了,然后后面过了一阵又看到了,就直接问我是不是录音。我非常坦诚的告诉她就是在录音,有顾虑,然后我也当着她面关了,我俩嘻嘻哈哈也就把这事过了。


想要摸一下秋天的老虎


聊了聊我的家庭,跟我聊了聊她最近咨询过的男生,有成功也有失败案例,反正都是会员。比较隐晦地指出了我这个水平在北京不够看,在成都也不算特别优秀地类型,但是结合家庭和年龄来讲,也算是还不错,至少还有操作空间。我一开始就想知道我在婚恋市场是个什么档次,以及从红娘视角来看我是什么样的,所以我就直球问她了。或许是基于职业素养,或者我问的有点子收费味道了,她顿了一下,从两方面给了我建议,一是从我初恋这段历程总结出来的,说我就是没有技巧的纯爱战士,需要提高情商,反正套话居多。二是不要乱撒网,要精准定位,选择自己合适的人,基于星座啥的跟我聊了半天,我这金牛座适合什么样的人。然后就说我这个改是来不及了,27也不小了,没救了,就从选对人开始,然后就开始围绕她们的服务开始聊。


总共聊了得有三小时左右吧,前一个半小时唠家常,根据你的资料聊细节,时不时说说女生的资料。后面就开始猛攻,围绕中介所的两项核心服务,一是心动女生匹配筛选,二是全程跟踪指导,结合真实案例开始跟我介绍。比如女生这个,真的是拿了五六份女生的资料,就跟简历似的,问我有没有眼缘,又跟我说这几天来了什么什么姑娘,有还没毕业的,有点子真实案例掺点焦虑的感觉。比如全程指导,给我看了她手下成功的案例,放了点截图和视频啥的,让我看效果。


中间插一下哈,聊聊我对红娘的看法,真的很强。能干这行的都是社牛,还有很强的气场,我确实能感觉出来她是很快乐地在撮合,觉得是在做正确的事,收的钱理所应当。说真的,要不是我去之前就抱着分文不出的想法,她一顿吹我真给了,业务能力太强了。她聊天的话,目的性很强,总是往婚介服务,这个筛选方向去带,会弱化你的劣势,不会很明显地贬低你,但也不会特别夸耀你的长处,就把你当作一个朋友一样,所有都是围绕我们能给你找一个天造地设的对象这一核心点展开。说实在的,动不动认个亲弟弟这操作也太骚了,见面第一次,这社交强度直接拉满,很热情。


聊聊收费啥的,好像每个人都不一样,给我的标准是1年49990,半年29990,3个月19990,后面我说不用了,拉扯半小时,认我做亲弟弟,然后给我亲属价对赌协议,先交10100等成功了再补9890或者给她介绍2个就不用给尾款了。最后博主一是领导在催干活,嘎嘎电话,朋友在催吃饭,也微信电话不停,就想润了,红娘就说要不先交500定金,不行再退,我确实没这想法,就发了50红包给姐买奶茶。反正这吃相一出来就有点尬住了,我这确实是很好说话,没有一甩脸子直接走了,就这么耗着。说实在的,我确实觉得人家说了3小时,这总得有点收益,50块钱在北京不是什么大钱,但是我本来也是抱着聊聊的想法,没想到上来就这么狠,直接2W起步,真恐怖,润了润了。


又到了白色相簿的季节


最后聊聊博主的收获,有用信息不多哈,大部分是一些套话,这大概就是免费内容吧。她给我看了客户的跟踪记录,红娘会全程指导男生的行为,会推一些书或者情感内容啥的,当然,这都是收费内容。怎么说呢,这一次三小时的激烈battle,我也能感觉出来,我还是该在情商上做一些提升,红娘有提到男女之间的情商和朋友之间的情商是两码事,说我上一次挂了就是技巧不足,竟然半年连嘴都没亲,这还是人???跟我说她们那里的都是一个月速通,我这样的已经没救了,好好好,这年头纯爱战士就是鲨BEE。


我其实对这家婚介所没啥意见,我也是想着既然聊上了那就去看看呗,没想到第一次这强度就这么大,哈哈,离谱。我看了下女生资源都很不错,男生也很厉害,都是人中龙凤,不知真假。XX爱恋,她跟我说主要还是线下,我的资料是从B站过去的,就离谱,不知道我填啥了,一开始就知道我的性别年龄和手机号,其他一概不知,可能是我资料被卖了吧,根据年龄给我推送的。喔,对了,说是每周给政府或者国企办公益相亲会,我之前倒是没怎么了解,不知道她家是不是在北京属于厉害的了,还是纯诈骗,摸不清楚,这也是我没交钱的理由之一。因为我在B站上看过XX说媒嘛,我就问她,怎么不开个自媒体号吐吐槽,还能挣点外快。哈哈,这姐非常真实,说剪辑、化妆、文案太累了,线下就够赚了,没必要混线上。


写着写着,突然想起来这姐还说过我一个坏毛病,说我没有底线,有点舔狗,女生一般不喜欢姿态放低的男生,希望我有点神秘感,或者说装一点。哈哈,下一个更好,咱们有的是资源,看得出姐是相当洒脱,成年人不改变只选择这话倒是诠释的清清楚楚。还说我应该有个底,不要一上来就跟人托底,比如她一看我就是个逗比的人,结果跟我一聊还真是个嘻嘻哈哈的乐天派,这样就没有神秘感,她说女生一般不太喜欢这种。


最后的最后,她把经理叫来了,做个回访,我是很欣赏红娘老师的,因为我这次没谈成业绩我也是相当抱歉,所以当着经理面说了很多红娘的好话,没有谈成也确实是我的问题。哈哈,经理直接问我,免费给我介绍同意不,我都懵了,这太狠了,我也没答应,这种形式还是太超前了。相亲说实话还是摆条件,看见女生资料搁面前一遍遍刷,人中龙凤太多啦,哈哈,不由得想起了我初恋也就是我前对象,我也得好好努力呀!


锵锵!我闪亮登场!


今天突然想到,好像真是在B站一个UP那里填过资料的,是我错怪人家了。红娘这姐姐挺有意思的,我是真的觉得她干这行很快乐,她还问我对这行有没有兴趣,哈哈。这种撮合有情人就能收钱的事可太行了,我也蛮喜欢这种做好事的感觉。不过骗人的也不少,315曝光过了,大家也长个心眼吧,学会识人。


最后做个总结吧,博主从昨年开始琢磨男女大事,经历了人生第一次相亲会、初恋、婚介所,虽然都只有一次,但都是挺有意思的。哎,母胎SOLO真的太难了,不会谈啊,盲目冲锋的纯爱战士真的不是版本答案了,红娘老师也跟我说,女生感情上比男生早熟三四年以上,难难难,但是博主依旧对生活抱有期望,哈哈,毕竟我是个乐子人。


我的人生信条是,我要让这痛苦压抑的世界绽放幸福快乐之花,向美好的世界献上祝福!!!


作者:云雨雪
来源:juejin.cn/post/7350123500936986674
收起阅读 »

祖传屎山代码平时不优化,一重构就翻天覆地

写作背景 写背景之前先放一张网图,侵删。 有一个活跃应用包含了2个相似业务场景,所以共用了底层模型。 前期在开发过程中,强行将两波研发组正在研发的产品底层模型和能力统一。底层能力统一遇到了挺多问题,比如数据库字段适配、转换、冗余;repo 层 SQL...
继续阅读 »



写作背景



写背景之前先放一张网图,侵删。



image.png


有一个活跃应用包含了2个相似业务场景,所以共用了底层模型。




  1. 前期在开发过程中,强行将两波研发组正在研发的产品底层模型和能力统一。底层能力统一遇到了挺多问题,比如数据库字段适配、转换、冗余;repo 层 SQL 条件拼接用了大量 if else,导致建索引困难…等等。

  2. 一些历史原因,该应用经手了十多个研发,代码是垒了又垒,出现一个很有规律的现象,大家都是只增代码不减代码。

  3. 代码性能随着数据规模增加不断降低,靠着优化补丁缝缝补补支撑着,业务高峰期经常被运维同学拿着 SQL 光顾。



重构该项目想法不止10次,想逮着机会拉着各方大佬商讨重构事项,因为重构对业务是没有收益的,并且重构难度相当大,所以迟迟没有下定决心。


最近刚好产品需要打磨下一个版本,需要挺长时间,几个后端研发商讨要不重构吧。嗯,我想可以,于是我找上前端负责人沟通拉他入伙,找上前端之前测试已经同意了。


于是一场重构拉开序幕了。




  1. A 同学负责梳理和收敛模型、数据订正、向上提供能力。

  2. B 同学负责梳理前端接口,编排底层能力,提供原子接口给前端(最复杂,直接面向Web端业务,接口有很多特殊逻辑)。

  3. C 同学负责引擎层,和一些计算类逻辑,另外就是打打杂。



重构


大型重构耗时不说还费人力,搞不好重构完你拿不到业务结果,所以重构前你要明确收益是啥?无非就是下面几种




  1. 性能提升产品体验更好;

  2. 简化架构并提升架构扩展性(后面迭代基于重构后架构能快速开发上线);

  3. 历史债清理,历史代码可读性差维护费劲(大部分程序员看别人代码都是这样吧)。



我们是三种情况都中,下面简单总结重构的思路吧。


模型梳理和能力收敛


底层模型我认为最重要,要可靠、稳定且变动少,如果在迭代中你的模型变来变去,上层业务根本开发不了或者边开发边改,到项目收尾就是另一坨屎山。


上层业务是根据底层模型长出来的,所以一定要跟产品讨论确定最终模型,若有好的竞品参考更好了,你的设计可能会看的更远,以防过度设计,架构设计满足未来1-2年迭代即可。


模型设计需要预估数据规模,数据规模决定是否采用分库分表/分区表。如果不好预估采用简单原则先上线看看业务效果,但基础框架这些能力一定要预留好,上量后能快速开发上线。


底层模型和能力收敛了,上层业务编排对能力的复用性更高。ps:这次模型梳理我们干掉了 2 张千万级表。


数据订正


模型梳理和收敛一般会涉及数据订正,特指线上模型对应的数据割接在新模型。一般会有下面几种方式




  1. 写脚本从数据库捞数据订正数据,一般会先 select 查询到内存中,重新组装数据再 insert 新模型。数据量小场景完全可行,但数据量大是跑不动(已踩过坑,线上数据几天没跑完最后发布失败)。

  2. 写 SQL 直接操作数据表,简单的数据处理场景、数据量小场景可行,数据量大场景不可靠,容易超时并且会有数据库稳定性风险,另外订正逻辑复杂是搞不定的(已踩过坑,线上跑数据失败导致发布失败)。

  3. oplog、binlog.... 日志采集同步到消息队列(kafka、pulsar 等),启消费组消费订正数据(我最常用也是最可靠的),数据量大的场景特别爽,处理存量数据的同时还能保证增量数据同步处理。



数据订正是清理过期数据最佳时期。假若平台过期数据体量大,这部分数据不迁移新表,留在历史表中当备份就行,亦可快速恢复。ps:本次重构过期数据预估是千万级别。


API 接口


接口是你对外的门面,应该提前规划明确,不能新增需求就干一个接口,需求迭代到后期,大大小小接口加起来几十上百个维护成本是很高的。


我们一般会按照下面几个原则:




  1. 按操作分类比如:增、删、改、查是一类,只会定义4个接口上游业务方调用需传入 source 区分调用源。

  2. 接口保持简洁,不耦合非当前业务的复杂数据。比如业务上需要回显组织架构数据(员工名称、部门、员工上级等),这类数据需要业务方自行编排组织架构 byids 接口。

  3. 接口具备降级能力,不能因为接口内部编排的非重要接口、逻辑报错导致整个接口不可用。
    降级指将某些业务或者接口的功能降低,可以是只提供部分功能,也可以是完全停掉所有功能。



这次重构 B 同学和前端面临了巨大压力,接口多、混乱、逻辑不清晰,决定梳理业务逻辑按照上面 3 个原则重写接口。


代码重构技巧


代码重构也是本次重构重点,经过长时间迭代已经闻到了坏代码味道。怎么重构早就心中有数,很早就盘点和推演了,下面是我常用的一些重构技巧,这些技巧都是非常经典的,如果看过「重构改善既有代码设计」应该都不陌生。


内联临时变量

项目里有一些临时变量,只被简单赋值了一次。将这些临时变量的赋值语句直接嵌入到使用它们的地方,而不是创建一个新的变量来存储这个临时值。


func Publish() error {
// ... 省略一部分代码
err = Producer(context.TODO()).ProducerOne(&obj)
if err != nil {
return err
}
return nil
}

临时变量内联改造后👇👇👇


func Publish() error {
// ... 省略一部分代码
return Producer(context.TODO()).ProducerOne(&obj)
}

魔幻数字"(Magic Number)

指代码中使用未经解释或定义的常数值,这些值通常没有命名并且没有给出其含义或用途。这样的数字使代码难理解和维护,项目里面很多魔幻数字使用。


func Update(ids []string, nodeID string) {
// ... 省略一部分代码
Report(context.TODO(), nodeID, "6", ids)
}

要解决魔幻数字比较简单,只需你把业务逻辑理解定义成枚举就可以了,这个数字6表示朋友圈类型,魔幻数字改造后👇👇👇


type TargetType int

const (
QWMoment TargetType = 6
)

func Update(ids []string, nodeID string) {
// ... 省略一部分代码
Report(context.TODO(), nodeID, QWMoment, ids)
}

删除注释、未引用代码「俗称死代码」

根据我 review 代码的经验,不少研发同学会把已注释、未引用代码保留,这部分代码是非常影响后面维护者思路的,我们在重构过程中遇到不少这类代码,来来回回找测试和研发确认为什么会保留,哪些业务常用在用?带来了不小负担。(尤其是越上层的死代码引用了一堆下层代码,比如controller 引用 service,service 再引用 repo ,若重写 repo 非常上头)


所以我强烈建议,一旦代码不用了,应该立刻删除。若删除这部分代码后面迭代可能会使用,我建议重新开发。我列一些删除代码后的收益。




  1. 清晰度和简洁性;

  2. 减少维护成本;

  3. 减少冗余和混乱;

  4. 避免误导。



卫语句取代条件表达式

卫语是用来提前结束方法执行的结构。通常情况下,卫语句用来检查某些前置条件是否满足,如果条件不满足,则立即退出方法执行,以避免进入后续的代码块。有助于减少代码嵌套深度,增加代码的可读性和可维护性。


按照我的经验,卫语句应该有下面 2 种情况:




  1. 两个条件分支都属于正常行为;

  2. 有一个条件分支是正常行为,另一个分支则是异常的情况。



我们review过的代码一般是第二种情况比较严重。


func Recall(exclusion constant.ExclusionType)error  {
if exclusion == constant.OnlyOneExec {
if detail.TargetID == "" {
return nil
}
_, err := repo.Update(ctx,....)
if err != nil {
return xerrors.Wrapf(err, "Update")
}
}
return nil
}

调整后代码👇👇👇


func Recall(exclusion constant.ExclusionType)error  {
if exclusion != constant.OnlyOneExec {
return nil
}

if detail.TargetID == "" {
return nil
}
_, err := repo.Update(ctx,....)
return err
}

变量改名

好的命名能让读者一目了然,变量名可以很好的解释一段代码干了什么。我发现项目里面很多字段名、类名、包名很模糊,很难理解具体的业务(包括我自己也经常命名错)。


下段代码是我整理的坏的命名


TaskCommand 是 Kafka 消费者依赖的实体,收到消息后根据 Type 和 Status 撤回数据。但你看 struct 名 跟撤回没有任何关系。


// TaskCommand 任务相关命令
type TaskCommand struct {
Type   int8 `json:"type"`   // 执行类型
Status int8 `json:"status"` 
}

所以我选择把 TaskCommand 替换成跟业务更贴切的名称👇👇👇


type RecallDataParam struct {
Type   int8 `json:"type"` // 执行类型
Status int8 `json:"status"`
}

引入参数对象

以一个对象取代一些参数,可以改善代码的可读性和维护性,尤其是在函数参数列表较长或者参数之间存在复杂关系的情况下。将一组相关的参数封装到一个对象中,将该对象作为函数的参数传递,简化函数签名并提高代码的清晰度。


在一些历史比较久的代码里过长参数真的很常见,从 controller 透传到 service 再透传到 repo 层,代码复用性也非常低。


type AppImpl struct {
}

func (app *AppImpl) List(tp []int, status, page, pageSize int, keyword string, domain string) ([]interface{}, error) {
// .... 省略业务逻辑
return nil, nil
}

上段代码我一般会在 controller 和 service 中间抽一个 dto 实体。👇👇👇


type AppImpl struct {
}

func (app *AppImpl) List(listDTO *ListDTO) ([]interface{}, error) {
// .... 省略业务逻辑
return nil, nil
}

type ListDTO struct {
tp []int
status, page, pageSize int
keyword, domain string
}

提炼类

一个类应该是一个明确的抽象,它的职责是单一的,只处理一些明确的职责。


提炼类一般是下面两种情况




  1. 需求是在不停变化和累加,你会这儿加一个函数,那儿加一个方法。导致某些文件或者类非常臃肿。

  2. 相似的能力,散落在不同的业务板块,涉及的开发都在重复建设,有一个需求建一个烟囱。



典型案例是项目中事件上报能力,本应该是一个通用能力集中收敛上报代码,据我梳理代码散落在多处,上报触点有 10 来个,每个触点都在写同样的上报代码,假设某一天上报逻辑变化必须在这 10 多处做出许多小修改。


所以我决定把上报能力收敛在一个类,将复杂逻辑封装到该类,定义有限参数露出给使用方。


上报通用能力封装在 EventTracking。👇👇👇


// Tracker 埋点上报接口
type Tracker[T any] interface {
EventTracking(in T) error
}

type CMSReachDTO struct {
}

type CMSReachTracking[T any] struct {
ctx context.Context
}

func NewCMSReachTracking[T any](ctx context.Context) Tracker[*CMSReachDTO] {
return &CMSReachTracking[T]{ctx: ctx}
}

func (t *CMSReachTracking[T]) EventTracking(in *CMSReachDTO) error {
// ....逻辑省略

return nil
}

提炼超类

如果两个类在做相似的事,可以利用基本的继承/组合(GO 只有组合)机制把它们的相似之处提炼到超类。一般会把字段、方法都搬移过去。


我遇到的 case 在 entity 上会多一些,比如下面这两个 struct。


type Task struct {
ID string `gorm:"column:id"`
Tenant string `gorm:"column:tenant"`
SubDomain string `gorm:"column:sub_domain"`
IsDel int8   `gorm:"column:is_del;default:1" `
CreateAt int64  `gorm:"column:create_at;autoCreateTime:milli"`
UpdateAt int64  `gorm:"column:update_at;autoUpdateTime:milli"`
CreateUserID string `gorm:"column:create_uid"`
UpdateUserID string `gorm:"column:update_uid"`
// ... 省略其他字段
}

type TaskDetail struct {
ID string `gorm:"column:id"`
TargetID string `gorm:"column:target_id"`
Tenant string `gorm:"column:tenant"`
SubDomain string `gorm:"column:sub_domain"`
IsDel int8   `gorm:"column:is_del;default:1" `
CreateAt int64  `gorm:"column:create_at;autoCreateTime:milli"`
UpdateAt int64  `gorm:"column:update_at;autoUpdateTime:milli"`
CreateUserID string `gorm:"column:create_uid"`
UpdateUserID string `gorm:"column:update_uid"`
// ... 省略其他字段
}

上面这段代码他们都有共性的代码,并且我非常熟悉业务是不可能更改的,所以我会提炼一个超类。👇👇👇


type SuperParty struct {
Tenant string `gorm:"column:tenant"`
SubDomain string `gorm:"column:sub_domain"`
IsDel int8   `gorm:"column:is_del;default:1" `
CreateAt int64  `gorm:"column:create_at;autoCreateTime:milli"`
UpdateAt int64  `gorm:"column:update_at;autoUpdateTime:milli"`
CreateUserID string `gorm:"column:create_uid"`
UpdateUserID string `gorm:"column:update_uid"`
}

type Task struct {
ID string `gorm:"column:id"`
SuperParty
// ... 省略其他字段
}

type TaskDetail struct {
ID string `gorm:"column:id"`
TargetID string `gorm:"column:target_id"`
SuperParty
// ... 省略其他字段
}

当然某些场景还有一些配套的方法,也可以一并搬迁到 SuperParty 里面。


提炼方法/函数

提炼函数/方法是我常用的一种手段,我不喜欢长函数/方法。我看过一个说法,一个函数/方法应该能在一屏中显示,我一直奉为经典语录(我写的代码函数/方法基本不会超过一百行);另外只要有一段代码不止被用一次,我就会把他们单独放进一个函数。


有这样一个场景,调用外部 byids 查询员工信息获取 externalId 执行业务逻辑,封装外部接口调用。


type Client struct {
ctx context.Context
}

func (c *Client) GetByIDs(id []string) ([]*User, error) {
// ....省略业务逻辑
return []*User{}, nil
}

type User struct {
ID         string `json:"id"`
ExternalID string `json:"externalId"`
}

下面是业务方使用 GetByIDs() 方法


func TestGetUserByIDs(t *testing.T) {
ids := []string{"1""2"}

client := &Client{}
users, err := client.GetByIDs(ids)
if err != nil {
panic(err)
}

l := make([]string0len(users))
for _, v := range users {
l = append(l, v.ExternalID)
}

// ...执行业务逻辑
}

 业务方调用 GetByIDs() 方法,遍历 users 获取 ExternalID 执行业务逻辑。在业务上这种操作还真不少,所以决定优化复用一部分代码。👇👇👇




  1. 定义 Users 切片。

  2. GetByIDs() 方法返回 Users。

  3. Users 提供 GetExternalIDs 方法。



type Client struct {
ctx context.Context
}

func (c *Client) GetByIDs(id []string) (Users, error) {
// .... 省略业务逻辑
return Users{}, nil
}

type Users []*User

func (u Users) GetExternalIDs() []string {
out := make([]string0len(u))
for _, v := range u {
out = append(out, v.ExternalID)
}

return out
}

type User struct {
ID         string `json:"id"`
ExternalID string `json:"externalId"`
}

下面是业务方使用 GetByIDs() 方法


func TestGetUserByIDs(t *testing.T) {
ids := []string{"1""2"}

client := &Client{}
users, err := client.GetByIDs(ids)
if err != nil {
panic(err)
}

l := users.GetExternalIDs()
// 执行业务逻辑
   // ....
}

代码空行

我非常非常不喜欢代码从头到尾写下来没有任何空行,难以阅读让读者很难提起兴趣。空行在我看来是必不可少的,在代码中使用空行来分隔不同功能或逻辑块之间的代码,空行使得代码更易读。


下面段代码是没有任何空行的,代码比较短阅读起来可能并不费劲。
image.png


适当进行空行优化后👇👇👇
企业微信截图_25861264-b69d-48eb-bd5c-eb2e4e9f87aa.png


上段代码先不关注逻辑,优化后可读性更强了,代码分为3段逻辑,每段逻辑都有各自的职责。


空行是用来区分不同逻辑块的,过度空行也会影响代码阅读,如下:
image.png


引入设计模式

设计模式是被大佬们验证过的、开发经验的总结,可以帮助我们更好地组织和管理代码,并提高代码的可维护性、可读性、可扩展性和可重用性。下面链接是我最常用的设计模式,也在这次重构过程中全部用上了,有兴趣可以看看。


最后总结




  1. 如果你的项目不是外包项目(交付了就完事儿),一定要多回头看看自己写的代码,跟着版本迭代持续优化和改进,你才能进步。另外对代码一定要有洁癖。

  2. 重构是持续的过程,如果是重要项目,每个版本我们都会推进代码优化,保证代码可维护性、可扩展性、另外就是高性能。千万别堆积最后,那可是大工程到后面很多人是没有决心干这个事儿的,所以大家应该平时迭代中不断优化和完善,才可持续性。

  3. 大型重构时,一定要明确收益并且是可量化的,比如重构后 qps 提升了10%,应用消耗资源降低了…等等,你才有跟老板谈判的筹码。



作者:彭亚川Allen
来源:juejin.cn/post/7344290391989485578
收起阅读 »

2024年的安卓现代开发

大家好 👋🏻, 新的一年即将开始, 我不想错过这个机会, 与大家分享一篇题为《2024年的安卓现代开发》的文章. 🚀 如果你错过了我的上一篇文章, 可以看看2023年的安卓现代开发并回顾一下今年的变化. 免责声明 📝 本文反映了我的个人观点和专业见解, 并参考...
继续阅读 »


大家好 👋🏻, 新的一年即将开始, 我不想错过这个机会, 与大家分享一篇题为《2024年的安卓现代开发》的文章. 🚀


如果你错过了我的上一篇文章, 可以看看2023年的安卓现代开发并回顾一下今年的变化.


免责声明


📝 本文反映了我的个人观点和专业见解, 并参考了 Android 开发者社区中的不同观点. 此外, 我还定期查看 Google 为 Android 提供的指南.


🚨 需要强调的是, 虽然我可能没有明确提及某些引人注目的工具, 模式和体系结构, 但这并不影响它们作为开发 Android 应用的宝贵替代方案的潜力.


Kotlin 无处不在 ❤️



Kotlin是由JetBrains开发的一种编程语言. 由谷歌推荐, 谷歌于 2017 年 5 月正式发布(查看这里). 它是一种与 Java 兼容的现代编程语言, 可以在 JVM 上运行, 这使得它在 Android 应用开发中的采用非常迅速.


无论你是不是安卓新手, 都应该把 Kotlin 作为首选, 不要逆流而上 🏊🏻 😎, 谷歌在 2019 年谷歌 I/O 大会上宣布了这一做法. 有了 Kotlin, 你就能使用现代语言的所有功能, 包括协程的强大功能和使用为 Android 生态系统开发的现代库.


请查看Kotlin 官方文档


Kotlin 是一门多用途语言, 我们不仅可以用它来开发 Android 应用, 尽管它的流行很大程度上是由于 Android 应用, 我们可以从下图中看到这一点.




KotlinConf ‘23


Kotlin 2.0 要来了


另一个需要强调的重要事件是Kotlin 2.0的发布, 它近在眼前. 截至本文发稿之日, 其版本为 2.0.0-beta4



新的 K2 编译器 也是 Kotlin 2.0 的另一个新增功能, 它将带来显著的性能提升, 加速新语言特性的开发, 统一 Kotlin 支持的所有平台, 并为多平台项目提供更好的架构.


请查看 KotlinConf '23 的回顾, 你可以找到更多信息.


Compose 🚀




Jetpack Compose 是 Android 推荐的用于构建本地 UI 的现代工具包. 它简化并加速了 Android 上的 UI 开发. 通过更少的代码, 强大的工具和直观的 Kotlin API, 快速实现你的应用.




Jetpack Compose 是 Android Jetpack 库的一部分, 使用 Kotlin 编程语言轻松创建本地UI. 此外, 它还与 LiveData 和 ViewModel 等其他 Android Jetpack 库集成, 使得构建具有强反应性和可维护性的 Android 应用变得更加容易.


Jetpack Compose 的一些主要功能包括



  1. 声明式UI

  2. 可定制的小部件

  3. 与现有代码(旧视图系统)轻松集成

  4. 实时预览

  5. 改进的性能.


资源:



Android Jetpack ⚙️




Jetpack是一套帮助开发者遵循最佳实践, 减少模板代码, 编写在不同Android版本和设备上一致运行的代码的库, 这样开发者就可以专注于他们的业务代码.


_ Android Jetpack 文档



其中最常用的工具有:



Material You / Material Design 🥰



Material You 是在 Android 12 中引入并在 Material Design 3 中实现的一项新的定制功能, 它使用户能够根据个人喜好定制操作系统的视觉外观. Material Design 是一个由指南, 组件和工具组成的可调整系统, 旨在坚持UI设计的最高标准. 在开源代码的支持下, Material Design 促进了设计师和开发人员之间的无缝协作, 使团队能够高效地创造出令人惊叹的产品.



目前, Material Design 的最新版本是 3, 你可以在这里查看更多信息. 此外, 你还可以利用Material Theme Builder来帮助你定义应用的主题.


代码仓库


使用 Material 3 创建主题


SplashScreen API



Android 中的SplashScreen API对于确保应用在 Android 12 及更高版本上正确显示至关重要. 不更新会影响应用的启动体验. 为了在最新版本的操作系统上获得一致的用户体验, 快速采用该 API 至关重要.


Clean架构



Clean架构的概念是由Robert C. Martin提出的. 它的基础是通过将软件划分为不同层次来实现责任分离.


特点



  1. 独立于框架.

  2. 可测试.

  3. 独立于UI

  4. 独立于数据库

  5. 独立于任何外部机构.


依赖规则


作者在他的博文Clean代码中很好地描述了依赖规则.



依赖规则是使这一架构得以运行的首要规则. 这条规则规定, 源代码的依赖关系只能指向内部. 内圈中的任何东西都不能知道外圈中的任何东西. 特别是, 外圈中声明的东西的名称不能被内圈中的代码提及. 这包括函数, 类, 变量或任何其他命名的软件实体.




安卓中的Clean架构:


Presentation 层: Activitiy, Composable, Fragment, ViewModel和其他视图组件.
Domain层: 用例, 实体, 仓库接口和其他Domain组件.
Data层: 仓库的实现类, Mapper, DTO 等.


Presentation层的架构模式


架构模式是一种更高层次的策略, 旨在帮助设计软件架构, 其特点是在一个可重复使用的框架内为常见的架构问题提供解决方案. 架构模式与设计模式类似, 但它们的规模更大, 解决的问题也更全面, 如系统的整体结构, 组件之间的关系以及数据管理的方式等.


在Presentation层中, 我们有一些架构模式, 我想重点介绍以下几种:



  • MVVM

  • MVI


我不想逐一解释, 因为在互联网上你可以找到太多相关信息. 😅


此外, 你还可以查看应用架构指南.



依赖注入


依赖注入是一种软件设计模式, 它允许客户端从外部获取依赖关系, 而不是自己创建依赖关系. 它是一种在对象及其依赖关系之间实现控制反转(IoC)的技术.



模块化


模块化是一种软件设计技术, 可将应用划分为独立的模块, 每个模块都有自己的功能和职责.



模块化的优势


可重用性: 拥有独立的模块, 就可以在应用的不同部分甚至其他应用中重复使用.


严格的可见性控制: 模块可以让你轻松控制向代码库其他部分公开的内容.


自定义交付: Play特性交付 使用应用Bundle的高级功能, 允许你有条件或按需交付应用的某些功能.


可扩展性: 通过独立模块, 可以添加或删除功能, 而不会影响应用的其他部分.


易于维护: 将应用划分为独立的模块, 每个模块都有自己的功能和责任, 这样就更容易理解和维护代码.


易于测试: 有了独立的模块, 就可以对它们进行隔离测试, 从而便于发现和修复错误.


改进架构: 模块化有助于改进应用的架构, 从而更好地组织和结构代码.


改善协作: 通过独立的模块, 开发人员可以不受干扰地同时开发应用的不同部分.


构建时间: 一些 Gradle 功能, 如增量构建, 构建缓存或并行构建, 可以利用模块化提高构建性能.


更多信息请参阅官方文档.


网络



序列化


在本节中, 我想提及两个我认为非常重要的工具: 与 Retrofit 广泛结合使用的Moshi, 以及 JetBrains 的 Kotlin 团队押宝的Kotlin Serialization.



MoshiKotlin Serialization 是用于 Kotlin/Java 的两个序列化/反序列化库, 可将对象转换为 JSON 或其他序列化格式, 反之亦然. 这两个库都提供了友好的接口, 并针对移动和桌面应用进行了优化. Moshi 主要侧重于 JSON 序列化, 而 Kotlin Serialization 则支持包括 JSON 在内的多种序列化格式.


图像加载



要从互联网上加载图片, 有几个第三方库可以帮助你处理这一过程. 图片加载库为你做了很多繁重的工作; 它们既处理缓存(这样你就不用多次下载图片), 也处理下载图片并将其显示在屏幕上的网络逻辑.


_ 官方安卓文档




响应/线程管理




说到响应式编程和异步进程, Kotlin协程凭借其suspend函数和Flow脱颖而出. 然而, 在 Android 应用开发中, 承认 RxJava 的价值也是至关重要的. 尽管协程和 Flow 的采用率越来越高, 但 RxJava 仍然是多个项目中稳健而受欢迎的选择.


对于新项目, 请始终选择Kotlin协程❤️. 可以在这里探索一些Kotlin协程相关的概念.


本地存储


在构建移动应用时, 重要的一点是能够在本地持久化数据, 例如一些会话数据或缓存数据等. 根据应用的需求选择合适的存储选项非常重要. 我们可以存储键值等非结构化数据, 也可以存储数据库等结构化数据. 请记住, 这一点并没有提到我们可用的所有本地存储类型(如文件存储), 只是提到了允许我们保存数据的工具.



建议:



测试 🕵🏼



软件开发中的测试对于确保产品质量至关重要. 它能检测错误, 验证需求并确保客户满意. 下面是一些最常用的测试工具::



工具文档的测试部分


截屏测试 📸



Android 中的截屏测试涉及自动捕获应用中各种 UI 元素的屏幕截图, 并将其与基线图像进行比较, 以检测任何意外的视觉变化. 它有助于确保不同版本和配置的应用具有一致的UI外观, 并在开发过程的早期捕捉视觉回归.



R8 优化


R8 是默认的编译器, 可将项目的 Java 字节码转换为可在 Android 平台上运行的 DEX 格式. 通过缩短类名及其属性, 它可以帮助我们混淆和减少应用的代码, 从而消除项目中未使用的代码和资源. 要了解更多信息, 请查看有关 缩减, 混淆和优化应用 的 Android 文档. 此外, 你还可以通过ProGuard规则文件禁用某些任务或自定义 R8 的行为.




  • 代码缩减

  • 缩减资源

  • 混淆

  • 优化


第三方工具



  • DexGuard


Play 特性交付





Google Play 的应用服务模式称为动态交付, 它使用 Android 应用Bundle为每个用户的设备配置生成并提供优化的 APK, 因此用户只需下载运行应用所需的代码和资源.




自适应布局



随着具有不同外形尺寸的移动设备使用量的增长, 我们需要一些工具, 使我们的 Android 应用能够适应不同类型的屏幕. 因此, Android 为我们提供了Window Size Class, 简单地说, 就是三大类屏幕格式, 它们是我们开发设计的关键点. 这样, 我们就可以避免考虑许多屏幕设计的复杂性, 从而将可能性减少到三组, 它们是 Compat, MediumExpanded.


Window Size Class




支持不同的屏幕尺寸


我们拥有的另一个重要资源是Canonical Layout, 它是预定义的屏幕设计, 可用于 Android 应用中的大多数场景, 还为我们提供了如何将其适用于大屏幕的指南.



其他相关资源



Form-Factor培训


本地化 🌎



本地化包括调整产品以满足不同地区不同受众的需求. 这包括翻译文本, 调整格式和考虑文化因素. 其优势包括进入全球市场, 增强用户体验, 提高客户满意度, 增强在全球市场的竞争力以及遵守当地法规.


注: BCP 47 是安卓系统使用的国际化标准.


参考资料



性能 🔋⚙️



在开发 Android 应用时, 我们必须确保用户体验更好, 这不仅体现在应用的开始阶段, 还体现在整个执行过程中. 因此, 我们必须使用一些工具, 对可能影响应用性能的情况进行预防性分析和持续监控:



应用内更新



当你的用户在他们的设备上不断更新你的应用时, 他们可以尝试新功能, 并从性能改进和错误修复中获益. 虽然有些用户会在设备连接到未计量的连接时启用后台更新, 但其他用户可能需要提醒才能安装更新. 应用内更新是 Google Play 核心库的一项功能, 可提示活跃用户更新你的应用*.


运行 Android 5.0(API 等级 21)或更高版本的设备支持应用内更新功能. 此外, 应用内更新仅支持 Android 移动设备, Android 平板电脑和 Chrome OS 设备.


- 应用内更新文档




应用内评论



Google Play 应用内评论 API 可让你提示用户提交 Play Store 评级和评论, 而无需离开你的应用或游戏.


一般来说, 应用内评论流程可在用户使用应用的整个过程中随时触发. 在流程中, 用户可以使用 1-5 星系统对你的应用进行评分, 并添加可选评论. 一旦提交, 评论将被发送到 Play Store 并最终显示出来.


*为保护用户隐私并避免 API 被滥用, 你的应用应严格遵守有关何时请求应用内评论评论提示的设计的规定.


- 应用内评论文档




可观察性 👀



在竞争日益激烈的应用生态系统中, 要获得良好的用户体验, 首先要确保应用没有错误. 确保应用无错误的最佳方法之一是在问题出现时立即发现并知道如何着手解决. 使用 Android Vitals 来确定应用中崩溃和响应速度问题最多的区域. 然后, 利用 Firebase Crashlytics 中的自定义崩溃报告获取更多有关根本原因的详细信息, 以便有效地排除故障.


工具



辅助功能



辅助功能是软件设计和构建中的一项重要功能, 除了改善用户体验外, 还能让有辅助功能需求的人使用应用. 这一概念旨在改善的不能包括: 有视力问题, 色盲, 听力问题, 灵敏性问题和认知障碍等.


考虑因素:



  • 增加文字的可视性(颜色对比度, 可调整文字大小)

  • 使用大而简单的控件

  • 描述每个UI元素


更多详情请查看辅助功能 - Android 文档


安全性 🔐



在开发保护设备完整性, 数据安全性和用户信任的应用时, 安全性是我们必须考虑的一个方面, 甚至是最重要的方面.



  • 使用凭证管理器登录用户: 凭据管理器 是一个 Jetpack API, 在一个单一的 API 中支持多种登录方法, 如用户名和密码, 密码匙和联合登录解决方案(如谷歌登录), 从而简化了开发人员的集成.

  • 加密敏感数据和文件: 使用EncryptedSharedPreferencesEncryptedFile.

  • 应用基于签名的权限: 在你可控制的应用之间共享数据时, 使用基于签名的权限.


android="http://schemas.android.com/apk/res/android"
package="com.example.myapp">
name="my_custom_permission_name"
android:protectionLevel="signature" />


  • 不要将密钥, 令牌或应用配置所需的敏感数据直接放在项目库中的文件或类中. 请使用local.properties.

  • 实施 SSL Pinning: 使用 SSL Pinning 进一步确保应用与远程服务器之间的通信安全. 这有助于防止中间人攻击, 并确保只与拥有特定 SSL 证书的受信任服务器进行通信.


res/xml/network_security_config.xml


"1.0" encoding="utf-8"?>
<network-security-config>
<domain-config>
<domain includeSubdomains="true">example.comdomain>
<pin-set expiration="2018-01-01">
<pin digest="SHA-256">ReplaceWithYourPinpin>

<pin digest="SHA-256">ReplaceWithYourPinpin>
pin-set>
domain-config>
network-security-config>


  • 实施运行时应用自我保护(RASP): 这是一种在运行时保护应用免受攻击和漏洞的安全技术. RASP 的工作原理是监控应用的行为, 并检测可能预示攻击的可疑活动:



    • 代码混淆.

    • 根检测.

    • 篡改/应用钩子检测.

    • 防止逆向工程攻击.

    • 反调试技术.

    • 虚拟环境检测

    • 应用行为的运行时分析.




想了解更多信息, 请查看安卓应用中的运行时应用自我保护技术(RASP). 还有一些 Android 安全指南.


版本目录


Gradle 提供了一种集中管理项目依赖关系的标准方式, 叫做版本目录; 它在 7.0 版中被试验性地引入, 并在 7.4 版中正式发布.


优点:



  • 对于每个目录, Gradle 都会生成类型安全的访问器, 这样你就可以在 IDE 中通过自动补全轻松添加依赖关系.

  • 每个目录对构建过程中的所有项目都是可见的. 它是声明依赖项版本的中心位置, 并确保该版本的变更适用于每个子项目.

  • 目录可以声明 dependency bundles, 即通常一起使用的 "依赖关系组".

  • 目录可以将依赖项的组和名称与其实际版本分开, 而使用版本引用, 这样就可以在多个依赖项之间共享一个版本声明.


请查看更多信息


Secret Gradle 插件


Google 强烈建议不要将 API key 输入版本控制系统. 相反, 你应该将其存储在本地的 secrets.properties 文件中, 该文件位于项目的根目录下, 但不在版本控制范围内, 然后使用 Secrets Gradle Plugin for Android 来读取 API 密钥.


日志


日志是一种软件工具, 用于记录程序的执行信息, 重要事件, 错误调试信息以及其他有助于诊断问题或了解程序运行情况的信息. 日志可配置为将信息写入不同位置, 如日志文件, 控制台, 数据库, 或将信息发送到日志记录服务器.



Linter / 静态代码分析器



Linter 是一种编程工具, 用于分析程序源代码, 查找代码中的潜在问题或错误. 这些问题可能是语法问题, 代码风格不当, 缺乏文档, 安全问题等, 它们会对代码的质量和可维护性产生影响.



Google Play Instant



Google Play Instant 使本地应用和游戏无需安装即可在运行 Android 5.0(API 等级 21)或更高版本的设备上启动. 你可以使用 Android Studio 构建这类体验, 称为即时应用即时游戏. 通过允许用户运行即时应用或即时游戏(即提供即时体验), 你可以提高应用或游戏的发现率, 从而有助于吸引更多活跃用户或安装.



新设计中心



安卓团队提供了一个新的设计中心, 帮助创建美观, 现代的安卓应用, 这是一个集中的地方, 可以了解安卓在多种形态因素方面的设计.


点击查看新的设计中心


人工智能



GeminiPalM 2是谷歌开发的两个最先进的人工智能(AI)模型, 它们将改变安卓应用开发的格局. 这些模型具有一系列优势, 将推动应用的效率, 用户体验和创新.



人工智能编码助手工具


Studio Bot



Studio Bot 是你的 Android 开发编码助手. 它是 Android Studio 中的一种对话体验, 通过回答 Android 开发问题帮助你提高工作效率. 它采用人工智能技术, 能够理解自然语言, 因此你可以用简单的英语提出开发问题. Studio Bot 可以帮助 Android 开发人员生成代码, 查找相关资源, 学习最佳实践并节省时间.


Studio Bot



Github Copilot


GitHub Copilot 是一个人工智能配对程序员. 你可以使用 GitHub Copilot 直接在编辑器中获取整行或整个函数的建议.


Amazon CodeWhisperer


这是亚马逊的一项服务, 可根据你当前代码的上下文生成代码建议. 它能帮助你编写更高效, 更安全的代码, 并发现新的 API 和工具.


Kotlin Multiplatform 🖥 📱⌚️ 🥰 🚀



最后, 同样重要的是, Kotlin Multiplatform 🎉 是本年度最引人注目的新产品. 它是跨平台应用开发领域的有力竞争者. 虽然我们的主要重点可能是 Android 应用开发, 但 Kotlin Multiplatform 为我们提供了利用 KMP 框架制作完全本地 Android 应用的灵活性. 这一战略举措不仅为我们的项目提供了未来保障, 还为我们提供了必要的基础架构, 以便在我们选择多平台环境时实现无缝过渡. 🚀


如果你想深入了解 Kotlin Multiplatform, 我想与你分享这几篇文章. 在这些文章中, 探讨了这项技术的现状及其对现代软件开发的影响:



作者:bytebeats
来源:juejin.cn/post/7342861726000791603
收起阅读 »

H5唤起APP路子

web
前一段时间在做一些H5页面,需求中落地页占比较大,落地页承担的职责就是引流。引流有两种形式,同时也是我们对唤端的定义:引导已下载用户打开APP,引导未下载用户下载APP。 引导已下载用户打开APP,从数据上说用户停留在APP中的时间更多了,是在提高用户粘性;从...
继续阅读 »

前一段时间在做一些H5页面,需求中落地页占比较大,落地页承担的职责就是引流。引流有两种形式,同时也是我们对唤端的定义:引导已下载用户打开APP,引导未下载用户下载APP。


引导已下载用户打开APP,从数据上说用户停留在APP中的时间更多了,是在提高用户粘性;从体验上说,APP体验是要比H5好的。引导未下载用户下载APP,可以增加我们的用户量。


上面其实分别解释了 什么是唤端 以及 为什么要唤端,也就是 3W法则 中的 What 和 Why,那么接下来我们就要聊一聊 How 了,也就是 如何唤端


我们先来看看常见的唤端方式以及他们适用的场景:


唤端媒介


URL Scheme


来源


我们的手机上有许多私密信息,联系方式、照片、银彳亍卡信息...我们不希望这些信息可以被手机应用随意获取到,信息泄露的危害甚大。所以,如何保证个人信息在设备所有者知情并允许的情况下被使用,是智能设备的核心安全问题。


对此,苹果使用了名为 沙盒 的机制:应用只能访问它声明可能访问的资源。但沙盒也阻碍了应用间合理的信息共享,某种程度上限制了应用的能力。


因此,我们急需要一个辅助工具来帮助我们实现应用通信, URL Scheme 就是这个工具。


URL Scheme 是什么


我们来看一下 URL 的组成:

[scheme:][//authority][path][?query][#fragment]

我们拿 https://www.baidu.com 来举例,scheme 自然就是 https 了。


就像给服务器资源分配一个 URL,以便我们去访问它一样,我们同样也可以给手机APP分配一个特殊格式的 URL,用来访问这个APP或者这个APP中的某个功能(来实现通信)。APP得有一个标识,好让我们可以定位到它,它就是 URL 的 Scheme 部分。


常用APP的 URL Scheme


APP微信支付宝淘宝微博QQ知乎短信
URL Schemeweixin://alipay://taobao://sinaweibo://mqq://zhihu://sms://

URL Scheme 语法


上面表格中都是最简单的用于打开 APP 的 URL Scheme,下面才是我们常用的 URL Scheme 格式:

     行为(应用的某个功能)    
|
scheme://[path][?query]
| |
应用标识 功能需要的参数

Intent


安卓的原生谷歌浏览器自从 chrome25 版本开始对于唤端功能做了一些变化,URL Scheme 无法再启动Android应用。 例如,通过 iframe 指向 weixin://,即使用户安装了微信也无法打开。所以,APP需要实现谷歌官方提供的 intent: 语法,或者实现让用户通过自定义手势来打开APP,当然这就是题外话了。


Intent 语法

intent:
HOST/URI-path // Optional host
#Intent;
package=[string];
action=[string];
category=[string];
component=[string];
scheme=[string];
end;

如果用户未安装 APP,则会跳转到系统默认商店。当然,如果你想要指定一个唤起失败的跳转地址,添加下面的字符串在 end; 前就可以了:

S.browser_fallback_url=[encoded_full_url]

示例


下面是打开 Zxing 二维码扫描 APP 的 intent。

intent:
//scan/
#Intent;
package=com.google.zxing.client.android;
scheme=zxing;
end;

打开这个 APP ,可以通过如下的方式:

 <a href="intent://scan/#Intent;scheme=zxing;package=com.google.zxing.client.android;S.browser_fallback_url=http%3A%2F%2Fzxing.org;end"> Take a QR code a>

Universal Link


Universal Link 是什么


Universal Link 是苹果在 WWDC2015 上为 iOS9 引入的新功能,通过传统的 HTTP 链接即可打开 APP。如果用户未安装 APP,则会跳转到该链接所对应的页面。


为什么要使用 Universal Link


传统的 Scheme 链接有以下几个痛点:



  • 在 ios 上会有确认弹窗提示用户是否打开,对于用户来说唤端,多出了一步操作。若用户未安装 APP ,也会有一个提示窗,告知我们 “打不开该网页,因为网址无效”

  • 传统 Scheme 跳转无法得知唤端是否成功,Universal Link 唤端失败可以直接打开此链接对应的页面

  • Scheme 在微信、微博、QQ浏览器、手百中都已经被禁止使用,使用 Universal Link 可以避开它们的屏蔽( 截止到 18年8月21日,微信和QQ浏览器已经禁止了 Universal Link,其他主流APP未发现有禁止 )


如何让 APP 支持 Universal Link


有大量的文章会详细的告诉我们如何配置,你也可以去看官方文档,我这里简单的写一个12345。



  1. 拥有一个支持 https 的域名

  2. 开发者中心 ,Identifiers 下 AppIDs 找到自己的 App ID,编辑打开 Associated Domains 服务。

  3. 打开工程配置中的 Associated Domains ,在其中的 Domains 中填入你想支持的域名,必须以 applinks: 为前缀

  4. 配置 apple-app-site-association 文件,文件名必须为 apple-app-site-association不带任何后缀

  5. 上传该文件到你的 HTTPS 服务器的 根目录 或者 .well-known 目录下


Universal Link 配置中的坑


这里放一下我们在配置过程中遇到的坑,当然首先你在配置过程中必须得严格按照上面的要求去做,尤其是加粗的地方。



  1. 跨域问题


    IOS 9.2 以后,必须要触发跨域才能支持 Universal Link 唤端。


    IOS 那边有这样一个判断,如果你要打开的 Universal Link 和 当前页面是同一域名,ios 尊重用户最可能的意图,直接打开链接所对应的页面。如果不在同一域名下,则在你的 APP 中打开链接,也就是执行具体的唤端操作。


  2. Universal Link 是空页面


    Universal Link 本质上是个空页面,如果未安装 APP,Universal Link 被当做普通的页面链接,自然会跳到 404 页面,所以我们需要将它绑定到我们的中转页或者下载页。



如何调用三种唤端媒介


通过前面的介绍,我们可以发现,无论是 URL Scheme 还是 Intent 或者 Universal Link ,他们都算是 URL ,只是 URL Scheme 和 Intent 算是特殊的 URL。所以我们可以拿使用 URL 的方法来使用它们。


iframe

<iframe src="sinaweibo://qrcode">

在只有 URL Scheme 的日子里,iframe 是使用最多的了。因为在未安装 app 的情况下,不会去跳转错误页面。但是 iframe 在各个系统以及各个应用中的兼容问题还是挺多的,不能全部使用 URL Scheme。


a 标签

<a href="intent://scan/#Intent;scheme=zxing;package=com.google.zxing.client.android;end"">扫一扫</a>

前面我们提到 Intent 协议,官方给出的用例使用的就是使用的 a 标签,所以我们跟着一起用就可以了


使用过程中,对于动态生成的 a 标签,使用 dispatch 来模拟触发点击事件,发现很多种 event 传递过去都无效;使用 click() 来模拟触发,部分场景下存在这样的情况,第一次点击过后,回到原先页面,再次点击,点击位置和页面所识别位置有不小的偏移,所以 Intent 协议从 a 标签换成了 window.location。


window.location


URL Scheme 在 ios 9+ 上诸如 safari、UC、QQ浏览器中, iframe 均无法成功唤起 APP,只能通过 window.location 才能成功唤端。


当然,如果我们的 app 支持 Universal Link,ios 9+ 就用不到 URL Scheme 了。而 Universal Link 在使用过程中,我发现在 qq 中,无论是 iframe 导航 还是 a 标签打开 又或者 window.location 都无法成功唤端,一开始我以为是 qq 和微信一样禁止了 Universal Link 唤端的功能,其实不然,百般试验下,通过 top.location 唤端成功了。


判断唤端是否成功


如果唤端失败(APP 未安装),我们总是要做一些处理的,可以是跳转下载页,可以是 ios 下跳转 App Store... 但是Js 并不能提供给我们获取 APP 唤起状态的能力,Android Intent 以及 Universal Link 倒是不用担心,它们俩的自身机制允许它们唤端失败后直接导航至相应的页面,但是 URL Scheme 并不具备这样的能力,所以我们只能通过一些很 hack 的方式来实现 APP 唤起检测功能。

// 一般情况下是 visibilitychange 
const visibilityChangeProperty = getVisibilityChangeProperty();
const timer = setTimeout(() => {
const hidden = isPageHidden();
if (!hidden) {
cb();
}
}, timeout);

if (visibilityChangeProperty) {
document.addEventListener(visibilityChangeProperty, () => {
clearTimeout(timer);
});

return;
}

window.addEventListener('pagehide', () => {
clearTimeout(timer);
});

APP 如果被唤起的话,页面就会进入后台运行,会触发页面的 visibilitychange 事件。如果触发了,则表明页面被成功唤起,及时调用 clearTimeout ,清除页面未隐藏时的失败函数(callback)回调。


当然这个事件是有兼容性的,具体的代码实现时做了事件是否需要添加前缀(比如 -webkit- )的校验。如果都不兼容,我们将使用 pagehide 事件来做兜底处理。


没有完美的方案


透过上面的几个点,我们可以发现,无论是 唤端媒介调用唤端媒介 还是 判断唤端结果 都没有一个十全十美的方法,我们在代码层上能做的只是在确保最常用的场景(比如 微信、微博、手百 等)唤端无误的情况下,最大化的兼容剩余的场景。


好的,我们接下来扯一些代码以外的,让我们的 APP 能够在更多的平台唤起。




  • 微信、微博、手百、QQ浏览器等。


    这些应用能阻止唤端是因为它们直接屏蔽掉了 URL Scheme 。接下来可能就有看官疑惑了,微信中是可以打开大众点评的呀,微博里面可以打开优酷呀,那是如何实现的呢?


    它们都各自维护着一个白名单,如果你的域名在白名单内,那这个域名下所有的页面发起的 URL Scheme 就都会被允许。就像微信,如果你是腾讯的“家属”,你就可以加入白名单了,微信的白名单一般只包含着“家属”,除此外很难申请到白名单资质。但是微博之类的都是可以联系他们的渠道童鞋进行申请的,只是条件各不相同,比如微博的就是在你的 APP 中添加打开微博的入口,三个月内唤起超过 100w 次,就可以加入白名单了。




  • 腾讯应用宝直接打开 APP 的某个功能


    刚刚我们说到,如果你不是微信的家属,那你是很难进入白名单的,所以在安卓中我们一般都是直接打开腾讯应用宝,ios 中 直接打开 App Store。点击腾讯应用宝中的“打开”按钮,可以直接唤起我们的 APP,但是无法打开 APP 中的某个功能(就是无法打开指定页面)。


    腾讯应用宝对外开放了一个叫做 APP Link 的申请,只要你申请了 APP Link,就可以通过在打开应用宝的时候在应用宝地址后面添加上 &android_schema={your_scheme} ,来打开指定的页面了。




开箱即用的callapp-lib


信息量很大!各种问题得自己趟坑验证!内心很崩溃!


不用愁,已经为你准备好了药方,只需照方抓药即可😏 —— npm 包 callapp-lib


你也可以通过 script 直接加载 cdn 文件:

<script src="https://unpkg.com/callapp-lib"></script>

它能在大部分的环境中成功唤端,而且炒鸡简单啊,拿过去就可以用啊,还支持很多扩展功能啊,快来瞅瞅它的 文档 啊~~~


作者:阳光多一些
链接:juejin.cn/post/7348249728939130907
收起阅读 »

Mysql中Varchar(50)和varchar(500)区别是什么?

Mysql中Varchar(50)和varchar(500)区别是什么? 一. 问题描述 我们在设计表结构的时候,设计规范里面有一条如下规则: 对于可变长度的字段,在满足条件的前提下,尽可能使用较短的变长字段长度。 为什么这么规定,我在网上查了一下,主要基...
继续阅读 »

Mysql中Varchar(50)和varchar(500)区别是什么?


一. 问题描述


我们在设计表结构的时候,设计规范里面有一条如下规则:



  • 对于可变长度的字段,在满足条件的前提下,尽可能使用较短的变长字段长度。


为什么这么规定,我在网上查了一下,主要基于两个方面



  • 基于存储空间的考虑

  • 基于性能的考虑


网上说Varchar(50)和varchar(500)存储空间上是一样的,真的是这样吗?


基于性能考虑,是因为过长的字段会影响到查询性能?


本文我将带着这两个问题探讨验证一下


二.验证存储空间区别


1.准备两张表


CREATE TABLE `category_info_varchar_50` (
`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',
`name` varchar(50) NOT NULL COMMENT '分类名称',
`is_show` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否展示:0 禁用,1启用',
`sort` int(11) NOT NULL DEFAULT '0' COMMENT '序号',
`deleted` tinyint(1) DEFAULT '0' COMMENT '是否删除',
`create_time` datetime NOT NULL COMMENT '创建时间',
`update_time` datetime NOT NULL COMMENT '更新时间',
PRIMARY KEY (`id`) USING BTREE,
KEY `idx_name` (`name`) USING BTREE COMMENT '名称索引'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='分类';

CREATE TABLE `category_info_varchar_500` (
`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',
`name` varchar(500) NOT NULL COMMENT '分类名称',
`is_show` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否展示:0 禁用,1启用',
`sort` int(11) NOT NULL DEFAULT '0' COMMENT '序号',
`deleted` tinyint(1) DEFAULT '0' COMMENT '是否删除',
`create_time` datetime NOT NULL COMMENT '创建时间',
`update_time` datetime NOT NULL COMMENT '更新时间',
PRIMARY KEY (`id`) USING BTREE,
KEY `idx_name` (`name`) USING BTREE COMMENT '名称索引'
) ENGINE=InnoDB AUTO_INCREMENT=288135 DEFAULT CHARSET=utf8mb4 COMMENT='分类';

2.准备数据


给每张表插入相同的数据,为了凸显不同,插入100万条数据


DELIMITER $$
CREATE PROCEDURE batchInsertData(IN total INT)
BEGIN
DECLARE start_idx INT DEFAULT 1;
DECLARE end_idx INT;
DECLARE batch_size INT DEFAULT 500;
DECLARE insert_values TEXT;

SET end_idx = LEAST(total, start_idx + batch_size - 1);

WHILE start_idx <= total DO
SET insert_values = '';
WHILE start_idx <= end_idx DO
SET insert_values = CONCAT(insert_values, CONCAT('(\'name', start_idx, '\', 0, 0, 0, NOW(), NOW()),'));
SET start_idx = start_idx + 1;
END WHILE;
SET insert_values = LEFT(insert_values, LENGTH(insert_values) - 1); -- Remove the trailing comma
SET @sql = CONCAT('INSERT INTO category_info_varchar_50 (name, is_show, sort, deleted, create_time, update_time) VALUES ', insert_values, ';');

PREPARE stmt FROM @sql;
EXECUTE stmt;
SET @sql = CONCAT('INSERT INTO category_info_varchar_500 (name, is_show, sort, deleted, create_time, update_time) VALUES ', insert_values, ';');
PREPARE stmt FROM @sql;
EXECUTE stmt;

SET end_idx = LEAST(total, start_idx + batch_size - 1);
END WHILE;
END$$
DELIMITER ;

CALL batchInsertData(1000000);

3.验证存储空间


查询第一张表SQL


SELECT
table_schema AS "数据库",
table_name AS "表名",
table_rows AS "记录数",
TRUNCATE ( data_length / 1024 / 1024, 2 ) AS "数据容量(MB)",
TRUNCATE ( index_length / 1024 / 1024, 2 ) AS "索引容量(MB)"
FROM
informati0n—schema.TABLES
WHERE
table_schema = 'test_mysql_field'
and TABLE_NAME = 'category_info_varchar_50'
ORDER BY
data_length DESC,
index_length DESC;

查询结果


image.png


查询第二张表SQL


SELECT
table_schema AS "数据库",
table_name AS "表名",
table_rows AS "记录数",
TRUNCATE ( data_length / 1024 / 1024, 2 ) AS "数据容量(MB)",
TRUNCATE ( index_length / 1024 / 1024, 2 ) AS "索引容量(MB)"
FROM
informati0n—schema.TABLES
WHERE
table_schema = 'test_mysql_field'
and TABLE_NAME = 'category_info_varchar_500'
ORDER BY
data_length DESC,
index_length DESC;

查询结果


image.png


4.结论


两张表在占用空间上确实是一样的,并无差别


三.验证性能区别


1.验证索引覆盖查询


select name from category_info_varchar_50 where name = 'name100000'
-- 耗时0.012s
select name from category_info_varchar_500 where name = 'name100000'
-- 耗时0.012s
select name from category_info_varchar_50 order by name;
-- 耗时0.370s
select name from category_info_varchar_500 order by name;
-- 耗时0.379s

通过索引覆盖查询性能差别不大


1.验证索引查询


select * from category_info_varchar_50 where name = 'name100000'
--耗时 0.012s
select * from category_info_varchar_500 where name = 'name100000'
--耗时 0.012s
select * from category_info_varchar_50 where name in('name100','name1000','name100000','name10000','name1100000',
'name200','name2000','name200000','name20000','name2200000','name300','name3000','name300000','name30000','name3300000',
'name400','name4000','name400000','name40000','name4400000','name500','name5000','name500000','name50000','name5500000',
'name600','name6000','name600000','name60000','name6600000','name700','name7000','name700000','name70000','name7700000','name800',
'name8000','name800000','name80000','name6600000','name900','name9000','name900000','name90000','name9900000')
-- 耗时 0.011s -0.014s
-- 增加 order by name 耗时 0.012s - 0.015s

select * from category_info_varchar_50 where name in('name100','name1000','name100000','name10000','name1100000',
'name200','name2000','name200000','name20000','name2200000','name300','name3000','name300000','name30000','name3300000',
'name400','name4000','name400000','name40000','name4400000','name500','name5000','name500000','name50000','name5500000',
'name600','name6000','name600000','name60000','name6600000','name700','name7000','name700000','name70000','name7700000','name800',
'name8000','name800000','name80000','name6600000','name900','name9000','name900000','name90000','name9900000')
-- 耗时 0.012s -0.014s
-- 增加 order by name 耗时 0.014s - 0.017s

索引范围查询性能基本相同, 增加了order By后开始有一定性能差别;


3.验证全表查询和排序


全表无排序


image.png


image.png


全表有排序


select * from category_info_varchar_50 order by  name ;
--耗时 1.498s
select * from category_info_varchar_500 order by name ;
--耗时 4.875s

image.png
image.png


结论:


全表扫描无排序情况下,两者性能无差异,在全表有排序的情况下, 两种性能差异巨大;


分析原因


varchar50 全表执行sql分析

1711426760869.jpg
我发现86%的时花在数据传输上,接下来我们看状态部分,关注Created_tmp_files和sort_merge_passes
1711426760865.jpg


image.png
Created_tmp_files为3

sort_merge_passes为95


varchar500 全表执行sql分析

image.png


增加了临时表排序


image.png
image.png
Created_tmp_files 为 4

sort_merge_passes为645


关于sort_merge_passes, Mysql给出了如下描述:



Number of merge passes that the sort algorithm has had to do. If this value is large, you may want to increase the value of the sort_buffer_size.



其实sort_merge_passes对应的就是MySQL做归并排序的次数,也就是说,如果sort_merge_passes值比较大,说明sort_buffer和要排序的数据差距越大,我们可以通过增大sort_buffer_size或者让填入sort_buffer_size的键值对更小来缓解sort_merge_passes归并排序的次数。


四.最终结论


至此,我们不难发现,当我们最该字段进行排序或者其他聚合操作的时候,Mysql会根据该字段的设计的长度进行内存预估, 如果设计过大的可变长度, 会导致内存预估的值超出sort_buffer_size的大小, 导致mysql采用磁盘临时文件排序,最终影响查询性能;


作者:向显
来源:juejin.cn/post/7350228838151847976
收起阅读 »

华为自研的前端框架是什么样的?

web
大家好,我卡颂。 最近,华为开源了一款前端框架 —— openInula。根据官网提供的信息,这款框架有3大核心能力: 响应式API 兼容ReactAPI 官方提供6大核心组件 并且,在官方宣传视频里提到 —— 这是款大模型驱动的智能框架。 ...
继续阅读 »

大家好,我卡颂。


最近,华为开源了一款前端框架 —— openInula。根据官网提供的信息,这款框架有3大核心能力:



  1. 响应式API




  1. 兼容ReactAPI




  1. 官方提供6大核心组件



并且,在官方宣传视频里提到 —— 这是款大模型驱动智能框架


那么,这究竟是款什么样的前端框架呢?我在第一时间体验了Demo,阅读了框架源码,并采访了框架核心开发者。本文将包括两部分内容:



  1. 对框架核心开发者陈超涛的采访

  2. 卡颂作为一个老前端,阅读框架源码后的一些分析

采访核心开发者


开发Inula的初衷是?


回答:


华为内部对于业务中强依赖的软件,考虑到竞争力,通常会开发一个内部使用的版本。


Inula在华为内部,从立项到现在两年多,基本替换了公司内绝大部分React项目。



卡颂补充背景知识:Inula兼容React 95% API,最初开发的目的就是为了替换华为内部使用的React。为了方便理解,你可以将Inula类比于华为内部的React



为什么开源?


回答:


华为对于自研软件的公司策略,只要是公司内部做的,觉得还ok的自研都会开源。



接下来的提问涉及到官网宣传的内容



宣传片提到的大模型赋能、智能框架是什么意思?


回答:


这主要是Inula团队与其他外部团队在AI低代码方向的一些探索。比如:



  1. 团队与上海交大的一个团队在探索大模型赋能chrome调试业务代码方面有些合作,目的是为了自动定位问题

  2. 团队与华为内部的大模型编辑器团队合作,探索框架与编辑器定制可能性


以上还都属于探索阶段。


Inula未来有明确的发展方向么?


回答:


团队正在探索引入响应式API,相比于React的虚拟DOM方案,响应式API能够提高运行时性能。24年可能会从Vue composition API中寻求些借鉴。


新的发展方向会在项目仓库以RFC的形式展开。



补充:RFCRequest for Comments的缩写。这是一种协作模式,通常用于提出新的特性、规范或者改变现有的一些规则。RFC的目的是收集不同的意见和反馈,以便在最终确定一个决策前,考虑尽可能多的观点和影响。



为什么要自研核心组件而不用社区成熟方案?



卡颂补充:所谓核心组件,是指状态管理、路由、国际化、请求库、脚手架这样的框架生态相关的库。既然Inula兼容React,为什么不直接用React生态的成熟产品,而要自研呢?毕竟,这些库是没有软件风险的。




回答:


主要还是丰富Inula生态,根据社区优秀的库总结一套Inula官方推荐的最佳实践。至于开发者怎么选择,我们并不强求。


卡颂的分析


以上是我对Inula核心开发者陈超涛的采访。下面是我看了Inula源码后的一些分析。


要分析一款前端框架,最重要的是明白他是如何更新视图的?这里我选择了两种触发时机来分析:



  1. 首次渲染


触发的方式类似如下:


Inula.render(<App />, document.getElementById("root"));


  1. 执行useState的更新方法触发更新


触发的方式类似如下:


function App() {
const [num, update] = useState(0);
// 触发更新
update(xxx);
// ...
}

顺着调用栈往下看,他们都会执行两步操作:



  1. 创建名为update的数据结构

  2. 执行launchUpdateFromVNode方法


比如这是首屏渲染时:



这是useState更新方法执行时:



launchUpdateFromVNode方法会向上遍历到根结点(源码中遍历的节点叫VNode),再从根节点开始遍历树。由此可以判断,Inula的更新机制与React类似。


所有主流框架在触发更新后,都不会立刻执行更新,中间还有个调度流程。这个流程的存在是为了解决:



  1. 哪些更新应该被优先执行?

  2. 是否有些更新是冗余的,需要合并在一块执行?


Vue中,更新会在微任务中被调度并统一执行,在React中,同时存在微任务(promise)与宏任务(MessageChannel)的调度模式。


Inula中,存在宏任务的调度模式 —— 当宿主环境支持MessageChannel时会使用它,不支持则使用setTimeout调度:



同时,与这套调度机制配套的还有个简单的优先级算法 —— 存在两种优先级,其中:



  • ImmediatePriority:对应正常情况触发的更新

  • NormalPriority:对应useEffect回调


每个更新会根据更新的ID(一个自增的数字)+ 优先级对应的数字 作为优先级队列中的排序依据,按顺序执行。


假设先后触发2次更新,优先级分别是ImmediatePriorityNormalPriority,那么他们的排序依据分别是:



  1. 100(假设当前ID到100了)- 1(ImmediatePriority对应-1) = 99

  2. 101(100自增到101)+ 10000(NormalPriority对应10000)= 10101


99 < 10101,所以前者会先执行。


需要注意的是,Inula中对更新优先级的控制粒度没有React并发更新细,比如对于如下代码:


useEffect(function cb() {
update(xxx);
update(yyy);
})

React中,控制的是每个update对应优先级。在Inula中,控制的是cb回调函数与其他更新所在回调函数之间的执行顺序。


这意味着本质来说,Inula中触发的所有更新都是同步更新,不存在React并发更新中高优先级更新打断低优先级更新的情况。


这也解释了为什么Inula兼容 95% 的React API,剩下 5% 就是并发更新相关API(比如useTransitionuseDeferredvalue)。


现在我们已经知道Inula的更新方式类似React,那么官网提到的响应式API该如何实现呢?这里存在三条路径:



  1. 一套外挂的响应式系统,类似ReactMobx的关系

  2. 内部同时存在两套更新系统(当前一套,响应式一套),调用不同的API使用不同的系统

  3. 重构内部系统为响应式系统,通过编译手段,使所有API(包括当前的React API与未来的类 Vue Composition API)都走这套系统



其中第一条路径比较简单,第二条路径应该还没框架使用,第三条路径想象空间最大。不知道Inula未来会如何发展。


总结


当前,Inula是一款类React的框架,功能上可以类比为React并发更新之前的版本


下一步,Inula会引入响应式API,目的是提高渲染效率。


对于未来的发展,主要围绕在:



  • 探索类 Vue Composition API的可能性

  • 迭代官方核心生态库


对于华为出的这款前端框架,你怎么看?


现在开放原子开源基金会搞了个开源大赛,奖金有35w,有两个选题:



  1. 基于openInula实现社区生态库,比如组件库、图表库、Rust基建、SSR、跨平台、高性能响应式更新方案...

  2. 基于openInula实现的AI应用


由于 openInulaReact API基本一致,说白了只要你把自己的 React 项目改下依赖适配下就能报名,有奖金拿,还有华为背书,这波属于稳赚不赔。感兴趣的朋友可以搜openInula前端框架生态与AI创新挑战赛报名。


作者:魔术师卡颂
来源:juejin.cn/post/7307451255432249354
收起阅读 »

告别混乱布局:用CSS盒子模型为你的网页穿上完美外衣!

在网络设计的世界里,盒子模型是构建网页布局的基石,只有理解了盒子模型,我们才能更好的进行网页布局。HTML中的每一个元素都可以看成是一个盒子,拥有盒子一样的外形和平面空间,它不可见、不直观,但无处不在,所以初学者很容易在这上面出问题。今天就让我们来深入了解一下...
继续阅读 »

在网络设计的世界里,盒子模型是构建网页布局的基石,只有理解了盒子模型,我们才能更好的进行网页布局。

HTML中的每一个元素都可以看成是一个盒子,拥有盒子一样的外形和平面空间,它不可见、不直观,但无处不在,所以初学者很容易在这上面出问题。今天就让我们来深入了解一下盒子模型。

一、盒子模型是什么?

首先,我们来理解一下什么是CSS盒子模型。

简单来说,CSS盒子模型是CSS用来管理和布局页面上每一个元素的一种机制。每个HTML元素都可以被想象成一个矩形的盒子,这个盒子由内容(content)、内边距(padding)、边框(border)和外边距(margin)四个部分组成。

Description

这四个部分共同作用,决定了元素在页面上的最终显示效果。

二、盒子模型的组成部分

一个盒子由外到内可以分成四个部分:margin(外边距)、border(边框)、padding(内边距)、content(内容)。

Description

其中margin、border、padding是CSS属性,因此可以通过这三个属性来控制盒子的这三个部分。而content则是HTML元素的内容。

下面来一一介绍盒子模型的各个组成部分:

2.1 内容(Content)

内容是盒子模型的中心,它包含了实际的文本、图片等元素。内容区域是盒子模型中唯一不可或缺的部分,其他三部分都是可选的。

内容区的尺寸由元素的宽度和高度决定,但可以通过设置box-sizing属性来改变这一行为。

下面通过代码例子来了解一下内容区:

<!DOCTYPE html>
<html>
<head>
<style>
.box {
width: 200px;
height: 100px;
background-color: lightblue;
border: 2px solid black;
padding: 10px;
margin: 20px;
box-sizing: content-box; /* 默认值 */
}
</style>
</head>
<body>


<div>这是一个盒子模型的例子。</div>


</body>
</html>

Description

在这个例子中,.box类定义了一个具有特定样式的<div>元素。这个元素的宽度为200px,高度为100px,背景颜色为浅蓝色。边框为2像素宽的黑色实线,内边距为10像素,外边距为20像素。

由于我们设置了box-sizing: content-box;(这是默认值),所以元素的宽度和高度仅包括内容区的尺寸。换句话说,元素的宽度是200px,高度是100px,不包括内边距、边框和外边距。

如果我们将box-sizing属性设置为border-box,则元素的宽度和高度将包括内容区、内边距和边框,但不包括外边距。这意味着元素的总宽度将是234px(200px + 2 * 10px + 2 * 2px),高度将是124px(100px + 2 * 10px + 2 * 2px)。

总之,内容区是CSS盒子模型中的一个核心概念,它表示元素的实际内容所在的区域。通过调整box-sizing属性,您可以控制元素尺寸是否包括内容区、内边距和边框。

2.2 内边距(Padding)

内边距是内容的缓冲区,它位于内容和边框之间。通过设置内边距,我们可以在内容和边框之间创建空间,让页面看起来不会太过拥挤。

内边距是内容区和边框之间的距离,会影响到整个盒子的大小。

  • padding-top: ; 上内边距
  • padding-left:; 左内边距
  • padding-right:; 右内边距
  • padding-bottom:; 下内边距

代码示例:

<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8" />
<title></title>
<style type="text/css">
/*
1、 padding-top: ; 上内边距
padding-left:; 左内边距
padding-right:; 右内边距
padding-bottom:; 下内边距
2、padding简写 可以跟多个值
四个值 上 右 下 左
三个值 上 左右 下
二个值 上下 左右
一个值 上下左右


*/

.box1 {
width: 200px;
height: 200px;
background-color: #bfa;
/* padding-top:30px ;
padding-left: 30px;
padding-right: 30px;
padding-bottom: 30px; */

padding: 40px;
border: 10px transparent solid;
}
.box1:hover {
border: 10px red solid;
}

/*
* 创建一个子元素box2占满box1,box2把内容区撑满了
*/

.box2 {
width: 100%;
height: 100%;
background-color: yellow;
}
</style>
</head>
<body>
<div>
<div></div>
</div>
</body>
</html>

Description

2.3 边框(Border)

边框围绕在内边距的外围,它可以是实线、虚线或者其他样式。边框用于定义内边距和外边距之间的界限,同时也起到了美化元素的作用。

边框属于盒子边缘,边框里面属于盒子内部,出了边框都是盒子的外部,设置边框必须指定三个样式 边框大小、边框的样式、边框的颜色

  • 边框大小:border-width
  • 边框样式:border-style
  • 边框颜色:border-color

代码示例:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title></title>
<style type="text/css">


.box {
width: 0px;
height: 0px;
/* background-color: rgb(222, 255, 170); */
/* 边框的大小 如果省略,有默认值,大概1-3px ,不同的浏览器默认大小不一样
border-width 后可跟多个值
四个值 上 右 下 左
三个值 上 左右 下
二个值 上下 左右
一个值 上下左右

单独设置某一边的边框宽度
border-bottom-width
border-top-width
border-left-width
border-right-width
*/

border-width: 20px;
/* border-left-width:40px ; */
/*
边框的样式
border-style 可选值
默认值:none
实线 solid
虚线 dashed
双线 double
点状虚线 dotted
*/

border-style: solid;
/* 设置边框的颜色 默认值是黑色
border-color 也可以跟多个值
四个值 上 右 下 左
三个值 上 左右 下
二个值 上下 左右
一个值 上下左右
对应的方式跟border-width是一样
单独设置某一边的边框颜色
border-XXX-color: ;
*/

border-color: transparent transparent red transparent ;
}
.box1{
width: 200px;
height: 200px;
background-color: turquoise;
/* 简写border
1、 同时设置边框的大小,颜色,样式,没有顺序要求
2、可以单独设置一个边框
border-top:; 设置上边框
border-right 设置右边框
border-bottom 设置下边框
border-left 设置左边框
3、去除某个边框
border:none;
*/

border: blue solid 10px;
border-bottom: none;
/* border-top:10px double green ; */

}
</style>
</head>
<body>
<div></div>
<div></div>
</body>
</html>

Description

2.4 外边距(Margin)

外边距是元素与外界的间隔,它决定了元素与其他元素之间的距离。通过调整外边距,我们可以控制元素之间的相互位置关系,从而影响整体布局。

  • margin-top:; 正值 元素向下移动 负值 元素向上移动
  • margin-left:; 正值 元素向右移动 负值 元素向左移动
  • margin-bottom:; 正值 元素自己不动,其靠下的元素向下移动,负值 元素自己不动,其靠下的元素向上移动
  • margin-right: ; 正值负值都不动

代码示例:

<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8" />
<title></title>
<style type="text/css">
/* 外边距 不会影响到盒子的大小
可以控制盒子的位置
margin-top:; 正值 元素向下移动 负值 元素向上移动
margin-left:; 正值 元素向右移动 负值 元素向左移动
margin-bottom:; 正值 元素自己不动,其靠下的元素向下移动,负值 元素自己不动,其靠下的元素向上移动
margin-right: ; 正值负值都不动
简写 margin 可以跟多个值
规则跟padding一样
*/

.box1 {
width: 200px;
height: 200px;
background-color: #bfa;
border: 10px solid red;
/* margin-top: -100px;
margin-left: -100px;
margin-bottom: -100px;
margin-right: -100px; */

margin: 40px;
}


.box2 {
width: 200px;
height: 200px;
background-color: yellow;
}
</style>
</head>
<body>
<div></div>
<div></div>
</body>
</html>

Description

三、盒子的大小

盒子的大小指的是盒子的宽度和高度。大多数初学者容易将宽度和高度误解为width和height属性,然而默认情况下width和height属性只是设置content(内容)部分的宽和高。

盒子真正的宽和高按下面公式计算

  • 盒子的宽度 = 内容宽度 + 左填充 + 右填充 + 左边框 + 右边框 + 左边距 + 右边距
  • 盒子的高度 = 内容高度 + 上填充 + 下填充 + 上边框 + 下边框 + 上边距 + 下边距

我们还可以用带属性的公式表示:

  • 盒子的宽度 = width + padding-left + padding-right + border-left + border-right + margin-left + margin-right
  • 盒子的高度 = height + padding-top + padding-bottom + border-top + border-bottom + margin-top + margin-bottom

上面说到的是默认情况下的计算方法,另外一种情况下,width和height属性设置的就是盒子的宽度和高度。盒子的宽度和高度的计算方式由box-sizing属性控制。

Description

box-sizing属性值

content-box:默认值,width和height属性分别应用到元素的内容框。在宽度和高度之外绘制元素的内边距、边框、外边距。

想要快速入门前端开发吗?推荐一个前端开发基础课程,这个老师讲的特别好,零基础学习无压力,知识点结合代码,边学边练,可以免费试看试学,还有各种辅助工具和资料,非常适合新手!

点这里前往学习哦!

border-box:为元素设定的width和height属性决定了元素的边框盒。就是说,为元素指定的任何内边距和边框都将在已设定的宽度和高度内进行绘制。通过从已设定的宽度和高度分别减去 边框 和 内边距 才能得到内容的宽度和高度。

  • 当box-sizing:content-box时,这种盒子模型成为标准盒子模型;
  • 当box-sizing: border-box时,这种盒子模型称为IE盒子模型。

四、盒子模型应用技巧

掌握了盒子模型的基本概念后,我们就可以开始创造性地应用它来设计网页。以下是一些技巧:

  • 使用内边距来创建呼吸空间,不要让内容紧贴边框,这样可以让页面看起来更加舒适。

  • 巧妙运用边框来分隔内容区域,或者为特定的元素添加视觉焦点。

  • 利用外边距实现元素间的对齐和分组,保持页面的整洁和组织性。

  • 考虑使用负边距来实现重叠效果,创造出独特的层次感和视觉冲击力。

CSS盒子模型是前端开发的精髓之一,它不仅帮助我们理解和控制页面布局,还为我们提供了无限的创意空间。现在,你已经掌握了盒子模型的奥秘,是时候在你的项目中运用这些知识,创造出令人惊叹的网页设计了。

记住,每一个细节都可能是打造卓越用户体验的关键。开启你的CSS盒子模型之旅,让我们一起构建更加精彩、更加互动的网页世界!

收起阅读 »

爱猫程序员给自家小猪咪做了一个上门喂养小程序

web
🐱前言 每次一到节假日,都好想和好朋友们一起出去玩,但是心里总放不下家里的小猪咪,于是心想能不能找一个喂养师上门喂养呢。于是找了几个上门喂养的平台,并最终下单了服务。 真的不得不说,上门喂养的小姐姐真的非常用心和专业。她们来到我家期间,全情投入地照顾着我的毛孩...
继续阅读 »

🐱前言


每次一到节假日,都好想和好朋友们一起出去玩,但是心里总放不下家里的小猪咪,于是心想能不能找一个喂养师上门喂养呢。于是找了几个上门喂养的平台,并最终下单了服务。


真的不得不说,上门喂养的小姐姐真的非常用心和专业。她们来到我家期间,全情投入地照顾着我的毛孩子,让它吃得饱饱的,看起来胖乎乎的。更令我感动的是,她们还全程录像了照料过程,并将视频发送给我,让我能够时刻了解小猪咪的情况。


分享下小猪咪美照👇



🤔️思考


我也是程序员,为什么我不能自己也做一个上门喂养的小程序呢,于是经过调研,发现了其他的几个平台各有各的弊端和优点,然后诞生出了最初的想法如何做一个把其他平台的弊端去除掉,做一个最好的上门喂养平台。


🎨开始设计


于是开始琢磨figma~~~


因为任何c端都是通过首页再去衍生出其他页面整体样式的,所以先着手制作首页,只要首页定好了其他页面都好说。
image.png


一周后....开始着手设计🤔️...思考...参考....初版定稿


由于刚入门设计一开始丑丑的,不忍直视~~~



再经过几天的琢磨思考...改版...最终确定首页


经过不断的练习琢磨参考最后定稿,给大家推荐下我经常参考我素材网站花瓣



N天之后......其他页面陆续出炉


由于页面太多了就不一一展示啦~~~


image.png


最满意的设计页面


给各大掘友分享一下我最满意的设计页面


签到


结合了猫咪的元素统一使用了同一只猫咪素材~整体效果偏向手绘风格。


image.png


抽奖扭蛋


这个扭蛋机真是一笔一画画了一天才出来的,真的哭😭啦~,由于AE动画太过麻烦所以每一个扭蛋球球的滚动都用代码去实现~~


image.png



💻编程


技术选型


uniapp + nestjs + mysql


NestJS是一个基于Node.js的开发框架,它提供了一种构建可扩展且模块化的服务端应用程序的方式,所以对于前端而言是最好上手的一门语法。


Nestjs学习推荐


给各大掘友推荐一下本人从0到1上手nestjs的教程,就是一下小册就是以下这本,初级直接上手跟着写一遍基本就会啦


image.png


建议学习到 61章左右就可以开始写后端项目啦



小程序端基本使用逻辑



  • 用户下单-服务人员上门服务完成-用户检查完成后确认订单完成-订单款项打款到服务人员钱包

  • 用户注册成为服务人员-设置服务范围-上线开始服务-等待用户给服务人员下单


下单流程


选择服务地点-选择服务人员-点击预约-添加服务宠物-付款


image.png


服务人员认证流程


根据申请流程逐步填写,由于服务人员是平台与用户产生信任的标准,所以我们加大了通过审核的门槛,把一些只追求利益,而不是真正热爱宠物的人员拒之门外,保护双方利益。


image.png


后端Nestjs部署


后端代码写完之后我们需要把服务部署到腾讯云,以下是具体步骤


1.腾讯云创建镜像仓库


前往腾讯云创建容器镜像服务,这样我们就可以把本地docker镜像推送到腾讯云中了,这个容器镜像服务个人版是免费的


image.png


2.打包Nestjs


通过执行docker命令部署到本地的docker


image.png


👇以下是具体docker代码


FROM --platform=linux/amd64 node:18-alpine3.14 as build-stage

WORKDIR /app

COPY package.json .
COPY cert .
COPY catdogship.com_nginx .
COPY ecosystem.config.js .

RUN npm config set registry https://registry.npmmirror.com/

RUN npm install

COPY . .

# 第一个镜像执行 build
RUN npm run build

# FROM 继承 node 镜像创建一个新镜像
FROM --platform=linux/amd64 node:18-alpine3.14 as production-stage

# 通过 COPY --from-build-stage 从那个镜像内复制 /app/dist 的文件到当前镜像的 /app 下
COPY --from=build-stage /app/package.json /app/package.json
COPY --from=build-stage /app/ecosystem.config.js /app/ecosystem.config.js

COPY --from=build-stage /app/dist /app/src/
COPY --from=build-stage /app/cert /app/cert/
COPY --from=build-stage /app/public /app/public/
COPY --from=build-stage /app/static /app/static/
COPY --from=build-stage /app/catdogship.com_nginx /app/catdogship.com_nginx/

WORKDIR /app

# 切到 /app 目录执行 npm install --production 只安装 dependencies 依赖
RUN npm install --production

RUN npm install pm2 -g

EXPOSE 443

CMD ["pm2-runtime", "/app/ecosystem.config.js"]

3.推送到腾讯云


本地打包完成之后我们需要把本地的docker推送到腾讯云中,所以我们本地写一个sh脚本执行推送


#!/bin/bash

# 生成当前时间
timestamp=$(date +%Y-%m-%d-%H-%M)

# Step 1: 构建镜像
docker build -t hello:$timestamp .

# Step 2: 查找镜像的标签
image_id=$(docker images -q hello:$timestamp)

# Step 3: 为镜像添加新的标签
docker tag $image_id 你的腾讯云镜像地址:$timestamp

docker push 你的腾讯云镜像地址:$timestamp

4.部署到服务器


由于我使用的是轻量级应用服务器,所以直接使用自动化助手去进行部署(PS:可能有一些小伙伴会问为什么用轻量级应用服务器呢,因为目前用户量不是很多,轻量级应用服务器足够支撑,后面用户量起来会考虑转为k8s集群


image.png


然后我们去创建一个自动化执行命令,去执行服务器的docker部署


image.png


创建命令


image.png


执行命令


image.png


👇以下是命令代码


# 停止服务
docker stop hello

# 删除容器
docker rm hello

# 拉取镜像
docker pull 你的腾讯云镜像地:{{key}}

#读取image名称
image_id=$(docker images -q 你的腾讯云镜像地:{{key}})

# 运行容器
docker run -d -p 443:443 -e TZ=Asia/Shanghai --name hello $image_id

5.部署完成


命令返回执行结果显示执行完成,说明已经部署成功了


image.png


6.Nestjs服务器端的管理


由于node是一个单线程,所以我们使用的是pm2去进行管理node,它可以把node变成一个多线程并进行管理


由于nestjs中使用到了定时任务,而定时任务只需要开一条线程去做就好了,所以我增加了一个环境变量NODE_ENV来对定时任务进行管理


module.exports = {
apps: [
{
name: 'wx-applets',
// 指定要运行的应用程序的入口文件路径
script: '/app/src/main.js',
exec_mode: 'cluster',
// 集群模式下的实例数-启动了2个服务进程
instances: 4,
// 如果设置为 true,则避免使用进程 ID 为日志文件添加后缀
combine_logs: true,
// 如果服务占用的内存超过300M,会自动进行重启。
// max_memory_restart: '1000M',
env: {
NODE_ENV: 'production',
},
},
{
name: 'wx-applets-scheduled-tasks',
script: '/app/src/main.js',
instances: 1,
// 采用分叉模式,创建一个单独的进程
exec_mode: 'fork',
env: {
NODE_ENV: 'tasks',
},
},
],
};

后端总结


到目前为止前台的业务接口都写完了做了个统计一共有179个接口


image.png


后期版本更新


预计这个月上线毛孩子用品盲盒抽奖,有兴趣的友友们也可关注下哦


Frame 2608921.png


后期展望,帮助更多的流浪动物有一个温暖的家


image.png

小程序上线


目前小程序已经上线啦~,友友们可以前往小程序搜索 喵汪舰 前往体验,
或者扫描一下二维码前往


开业海报.jpg

我的学习路线


因为我是一个前端开发,所以对于设计感觉还是挺好的,所以上手比较快。
一条学习建议路线:前端-后端-设计-产品,最终形成了一个完整的产品产出。


以下的链接是这个项目中我经常用到的素材网站:


freepik国外素材网站-可以找到大部份的插画素材


figma自带社区-获取参考的产品素材


花瓣国内素材参考网站-涵盖了国内基本的产品素材


pinterest国外大型素材网-你想到的基本都有


总结


一个产品的产出不仅仅依靠代码,还要好的用户体验,还需要不断的优化迭代,


最后给一起并肩前行的创业者们的一段话:


在创业的道路上,我们正在追逐梦想,挑战极限,为自己和世界创造新的可能性。这个旅程充满了风险和不确定性,但也蕴藏着无限的机遇和成就,不要害怕失败,勇于面对失败,将其视为成功的必经之路。


作者:热爱vue的小菜鸟
来源:juejin.cn/post/7348363812948033575
收起阅读 »

业务开发做到零 bug 有多难?

大家好,我是树哥,好久不见啦。 作为一个工作了 10 多年的开发,写业务代码总是写了不少的。但你想过做到零 bug 吗?我可是想过的,毕竟我还是有点追求的。不然每天都是浑浑噩噩地过,多没意思啊。 大概在一年多前,我给自己立下一个目标 —— 尽量将自己经手的业务...
继续阅读 »

大家好,我是树哥,好久不见啦。


作为一个工作了 10 多年的开发,写业务代码总是写了不少的。但你想过做到零 bug 吗?我可是想过的,毕竟我还是有点追求的。不然每天都是浑浑噩噩地过,多没意思啊。


大概在一年多前,我给自己立下一个目标 —— 尽量将自己经手的业务需求做到零 bug。不试不知道,一试吓一跳,原来零 bug 还真的还不容易。今天,树哥就跟大家分享关于「业务开发零 bug」的一些思考。


要做到业务开发零 bug,其实挺难的。这涉及到非常多方面,有些方面可能还不只是你能控制的,例如:产品 PRD 详尽程度,产研组织的稳定性等等。经过一段时间的思考与摸索,我自己总结出一些影响因素,分别是:



  1. 产品需求文档的清晰程度

  2. 需求的复杂程度

  3. 开发人员的细心程度

  4. 开发人员是否详细自测过

  5. 开发人员对项目的熟悉程度

  6. 开发人员开发时间是否充足


针对上面说到的影响因素,我们一个个详细聊聊。


需求文档清晰程度


对于研发、测试人员来说,他们获取信息的源头就是产品的 PRD 文档。因此,需求文档是否写得清晰、明确,就显得非常重要。


如果产品自己对功能都不了解,那么输出的需求文档肯定「缺斤少两」,到时候就是边开发边补充需求,甚至是在测试过程中补充需求。遇到这种情况,想要做到零 bug 真的非常难。


因此,清晰明确的需求文档,是我们实现业务开发零 bug 的重要前提。如果这个前提保证不了,那要做到零 bug 真的很难。毕竟想做成啥样都不知道,程序员又不是神仙,咋能猜出你想要什么。但这块内容,更多是对于产品人员专业能力的要求,开发人员无法控制。


在一些公司,会再需求评审之前先对需求文档进行一次初审,筛除那些有明显重大问题的需求,这样可以减少一部分劣质需求。


但初审的作用还是有限的,它没办法对功能的细节做较多的判断。很多时候恰恰就是一些功能细节的缺失,导致了一些 bug 的诞生。


需求的复杂程度


需求的复杂程度,对于实现业务开发零 bug 也有很大的影响。举个简单地例子:一个改文案的需求,和一个完全重新做的功能。


这样的两个需求,其复杂程度差别很大,肯定是改文案的需求实现业务开发零 bug 的难度低很多。对于一个完全重新做的功能,要做到完全零 bug,对于开发人员的要求非常高。


对于越复杂的项目,零 bug 的可能性就越低。因此,很多项目为了追求产出功能的高质量,会采用将功能点拆得非常细的方式,来减少单个需求的复杂度。


笔者公司在去年做过这个尝试,确实是可以较大地提高产出功能的质量。


细心程度


前面说到需求文档的清晰程度很重要,这取决于产品人员对于业务的理解程度,以及对于对于功能的熟悉程度。开发人员的细心,就像是一个质检关卡一样,在开发之前就对产品的需求内容进行详尽的思考与提问。


对于粗心的开发人员来说,其可能不看需求文档就直接参加需求评审,等到开发的时候边写代码边看需求文档,其写得代码也是一边熟悉需求一边改。这样写出来的系统功能是比较差的,没有一个统一、全局的设计与思考,很容易在细节处发生问题。


一个细心的开发人员,其会在评审之前就详细阅读需求文档,甚至会前前后后翻阅好几次。他甚至会逐字逐句地阅读,弄懂每个文字、句子的意思,甚至有时候会让你觉得他是在玩文字游戏(但不得不说,确实有必要细致一些)。


最后会联系上下文思考功能的合理性。如果发现一些不合理的地方,他会积极与产品沟通反馈,以确保其对于需求的理解,与产品经理对于需求的理解是一致的。


通过对比,我们知道细心的开发人员对于产品经理来说,是一个莫大的帮助,可以帮助他查漏补缺,让其对于功能的考虑更加细致、严谨。


这里的开发人员不仅仅指的是后端开发人员,也包括前端开发、移动端开发,他们都会从不同角度提出问题。


对于后端开发人员来说,他们可能会提出性能问题。对于前端开发以及移动端开发同学,他们可能会提出交互问题、样式统一等问题。


简单地说,细心的开发人员可以弥补需求文档的缺陷,从而让大家对于需求的理解更趋于一致,从而减少 bug 的发生。因此,开发人员的细心程度也是决定业务开发能否实现零 bug 的关键因素!


是否详细自测过


即使写过 10 多年代码的开发人员,刷 Leetcode 也不敢说 bug free 一把过,对于更加复杂的业务代码更是如此。因此,要做到业务开发零 bug,其中一个很重要的操作便是 —— 自测。


自测可以帮你再次检查可能出现的问题,从而提高零 bug 的概率。对于我而言,我习惯性在自测的时候再次对照一遍需求文档,从而避免自己遗漏一些功能的细节点。


对于自测而言,业界有很多种自测方法,包括:单测、集成测试、功能测试。一般情况,建议自己选择适合自己的自测方法。


很多时候,功能测试是相对来说性价比较高的方式。除此之外,自测的详细程度也根据实际情况有所不同,例如有些人只会测试正常情况,但有些老手会测试一些边界情况、异常情况。


毫无疑问,你越能像测试人员一样测试,你的提测质量肯定就越高,bug 当然也就越少。


对项目的熟悉程度


这里说的项目熟悉程度,既指技术层面的熟悉程度,也指业务功能层面的熟悉程度。


技术层面的熟悉程度,指的是项目之间是用什么技术栈搭建的,你对这些技术是否都熟悉。举个很简单的例子,项目中采用了微服务的方式进行调用,那么你是否清楚是什么微服务调用?


如果采用了 ElasticSearch 进行搜索,那么你是否对 ElasticSearch 有一些了解,知道一些基本使用及最佳实践?等等。


这些算是技术层面的熟悉程度,你对这些越熟悉,你在技术层面发生问题的可能性就越小。


业务功能层面的熟悉程度,指的是你对项目其他模块的业务是否熟悉。例如你经常负责 A 模块的功能,你对 A 模块肯定很熟悉。


但下个迭代你就要去做 B 迭代的需求了,这时候你肯定不是很熟,相对来说出错的可能性就更大一些。


无论是技术层面,还是业务层面的熟悉程度,都会随着你做了更多的需求,变得更加熟悉。到了后面某个阶段,你基本上就不存在踩坑的问题了,也为你业务开发零 bug 奠定了基础。如果你是一个刚刚进入公司的新手,那么做到零 bug 还是很难的。


开发时间是否充足


开发时间是否充足,决定了你是否有充足的时间去熟悉需求,去和产品经理确定细节。有了充足的时间,你也才能有一定时间去进行更详细的自测。更为关键的一点,有充足的时间,你写代码才能写得更好。因此,开发时间是否充足是很重要的。


在实际的开发过程中,会因为各种各样的原因,其实并没有办法给你留出特别理想的开发时间。这时候该怎么办?有些人选择接受,去压缩自己的时间。


有些人则会选择去沟通,或者协调资源,保证自己有充足的时间。其实,正确的做法还是第二种,这样会更好一些。


这需要开发人员有更强的综合能力(沟通、协调能力),但并不是每个开发人员都具备的。关于这点,又是可以聊的一个话题 —— 当你的需求被压缩工时的时候,你应该怎么做?这里暂不展开,后续有时间可以聊聊。


简单来说,开发时间是基础,没有合理、充足的时间保障的话,要做到业务开发零 bug 是不可能的事情。


总结


要做到业务开发零 bug,其实就是要消除功能开发过程中的所有不确定性,包括:需求功能的不确定性、自己写错代码的不确定性等等。而发生这些不确定性的地方,可能就有:



  1. 产品需求文档的清晰程度

  2. 需求的复杂程度

  3. 开发人员的细心程度

  4. 开发人员是否详细自测过

  5. 开发人员对项目的熟悉程度

  6. 开发人员开发时间是否充足


除了上面说到的 6 个影响业务开发零 bug 的因素之外,肯定还有其他影响因素。


你能想到什么影响业务开发零 bug 的因素吗?欢迎在评论区留言与大家分享。


好了,今天的分享就到此为止,希望大家都能做到业务开发零 bug,业务开发代码一把过!


如果你觉得今天的文章对你有帮助,欢迎点赞转发评论,你的转发对于我很重要,感谢大家!


作者:树哥聊编程
来源:juejin.cn/post/7347668702029971475
收起阅读 »

聊一聊定时任务重复执行以及解决方案

大家好,我是小趴菜,关于定时任务大家都有接触过,项目中肯定也使用过,只需要在项目中的启动类上加上 @EnableScheduling 注解就可以实现了 现在是单个节点部署,倒是没什么问题。如果是多节点部署呢? 假设现在我们系统要每天给用户新增10积分,那么更新...
继续阅读 »

大家好,我是小趴菜,关于定时任务大家都有接触过,项目中肯定也使用过,只需要在项目中的启动类上加上 @EnableScheduling 注解就可以实现了


现在是单个节点部署,倒是没什么问题。如果是多节点部署呢?


假设现在我们系统要每天给用户新增10积分,那么更新的SQL如下


  update user set point = point + 10 where id = 1;

这时候你的服务部署了两台,那么每一台都会来执行这条更新语句,那么用户的积分就不是+10了。而是+20。


当然这里我们只是举了个例子来引出 @EnableScheduling 的定时任务会存在定时任务重复执行的问题。而且有可能会因为重复执行导致数据不一致的问题


使用数据库乐观锁


在使用乐观锁的时候,首先我们会新增一个字段,也就是更新日期,但是这个更新日期不是指我们修改数据的那个更新时间,比如说今天是2024-03-25,那么到了明天,第一台机器更新成功了,这个值就更新成2024-03-26,其它机器的线程来更新判断这个值是否是2024-03-25,如果不是,说明已经有线程更新了,那么就不需要再次更新了


  update user set point = point + 10,modifyTime = 2023-03-26 where id = 1 and modifyTime = 2024-03-25

基于乐观锁的方式有什么缺点呢??


现在我们只有两台服务器,那如果有1千台,1万台呢,对于同一条数据的,那么这1万台服务器都会去执行更新操作,但是其实在这1万次更新操作中,只有一次操作是成功的,其余的操作都是不需要执行的


所以使用这种方式当机器数量很多的时候,对数据库的压力是非常大的


分布式锁


我们还可以使用分布式锁的方式来实现,比如要执行这个定时任务之前要先获取一把锁,这个锁是对每一条记录都分别有对应的一把锁


当线程来更新某一条数据的时候,首先要获取这条记录的一个分布式锁,拿到锁了就可以去更新了,没有拿到锁的也不要去等待获取锁了,就直接更新下一条数据即可,同样的步骤,只有拿到某条数据的锁,才可以更新


image.png


但是这里有一个注意的点,就是比如服务-1先获取到id=100的这条记录的锁,然后执行更新,但是此时因为某些原因,导致某台服务器过了一会才来执行id=100的这条数据,因为服务-1已经执行完了,所以会释放掉这把锁,所以这台服务器来就能获取到锁,那么也会执行更新操作


所以在更新的时候,还是做一下判断,判断这条记录是否已经被更新了,如果已经更新了,那么就不要再次更新了


分布式锁相对于乐观锁来说,减少了大量的无用的更新操作,但还是会存在极少量的重复更新操作,但是相对来说,对数据库的压力就减少了很多


但是与此同时,这就依赖于Redis,要保证Redis的服务可用


消息队列


我们可以将要更新的数据提前加载到消息队列中去,然后每台服务就是一个消费者,保证一条记录只能让一个消费者消费,这样也就可以避免重复更新的问题了


但是消费失败的记录不要重回队列,可以在数据库记录,让人工进行处理


使用消息队列会有什么问题呢?


如果你的消息数据特别多,比如有上亿条,那么消息队列就会被堆满,,而且每天都要把数据库的数据都加载到消息队列中去


或许有人说,数据量大我可以多弄几个消息队列,这样确实可以解决一个消息队列堆积消息过多的问题,但是你要如何控制某些服务器只访问某个队列呢?不能每台服务都循环获取每一个队列中的消息吧


而且如果你的消息队列是单点的,那么服务宕机那么所有数据都没法更新了,这时候你还要去弄一个集群
,这成本就有点大了


所以不推荐使用这种方式


分布式任务调度-xxl-job


最后就是使用分布式定时任务调度框架 xxl-job了,关于xxl-job的使用大家可以网上自己搜一下资料。


XXL-JOB是一个开源的分布式任务调度框架,它主要用于解决大规模分布式任务的调度和执行问题。该框架提供了任务调度中心执行器任务日志等组件,支持任务的定时调度、动态添加和删除、执行情况监控和日志记录等功能。


总结


以上就是为大家提供的定时任务重复执行的解决方案,大家可以根据自己的实际情况来选择不同的方案来实现


作者:我是小趴菜
来源:juejin.cn/post/7350167062364979226
收起阅读 »

职场上的人情世故 - 初入公司的第一个项目

说下背景 来公司的第二周,上面下发了新需求,也是我参与公司的第一个项目。 我先说下公司一个项目的大体配置 产品经理 1~2人 一般中小版本就1人 UI 1~2人 研发前端 1~3人 研发后端 1~5人(包含协同团队) ps:其中后端中1...
继续阅读 »

说下背景


来公司的第二周,上面下发了新需求,也是我参与公司的第一个项目。


我先说下公司一个项目的大体配置


产品经理 1~2人  一般中小版本就1人
UI 1~2人
研发前端 1~3人
研发后端 1~5人(包含协同团队)
ps:其中后端中1人为项目负责人,负责整体项目进度和协调资源
测试 1~2人

好的,故事由此开始。先铺垫下,该项目是我从业以来最无力最绝望最想扯呼的一个。


需求评审


周一刚来公司,就被公司给我安排的导师L 叫到身边


导师L:「一会儿有个需求评审,我文档先发你,你先抓紧时间看看」


懵懂的我:「好的,我先熟悉下任务」


说实话文档看起来真的有点头疼,主要是上面的一行字我真的无语至极【与线上保持一致】。公司的项目还是比较大的,我上哪儿去了解保持一致是个啥意思......问下导师吧,他也在排查线上问题;问下其他同事吧,也刚来没多久不了解这块业务....


好吧时间应该够,我先打开系统,看看这功能到底在哪里。


「走,A2评审会」 导师L给了我一个眼神


大哥,我才看了不到20分钟,功能我都没看完......


我的情况稍微有点特殊,一般来说,大家跟随导师的节奏,问题都不大
看不懂的需求,一定要整懂了在动手,否则返工风险很大
时间不允许?那要再考虑下该公司是不是适合你了哦!!!总不能说能跑起来就行吧

过程我全程梦游,大家都在提问题:各种数据的兼容方案、功能冲突怎么兼容、有类似功能是否能套用、数据权限是否考虑、特殊逻辑的兜底方案.......


开始还能记一下笔记,后面发现 跟不上,根本跟不上 直接 弃笔,从容 面对现实了


从会议室走出来,嗯~~ 怎么形容心情呢。我高考语文作文那一页名字忘了写出考场都没这么忧虑过(当然作文最后还是有得分)。


分配任务


直接上对话详情,后端加上我一共3人


导师L:「任务我这边大概分配了下,你们先选吧」


我内心很慌,我一个都看不明白要怎么做


不知所措的我:「要不我拿剩下的」


同事P:「那把这个、这个、这个给我吧,剩下的你们分?」


导师L看着我:「那就这样分,你做那个、那个、那个,有问题随时找我」


不知所措的我:「好的,我主要是不熟悉这块业务,有问题我先整理出来再一起问下你呗」


这里有个关键点,整理完问题再一起咨询,切记遇到一个问一个
态度摆正,表现得自信点,第一次在同事面前“刷脸”,印象要留好一些

研发阶段


我的任务主要是客户群统计模块


导师给我开了两个服务的权限,让我先看看代码


懵逼的我:「L哥,要不大概说下在那部分写的统计数据?我应该从哪些表出结果?」


导师L:「你先看代码,里面都有逻辑,你看得懂」


无语的我:「好的」 内心(这么玩儿是吧)


知道那代码有多难懂吗?全都是A队列推到B队列,判断后再推C队列,并且还有了很多观察者模式。可能有兄弟姐妹问:「看不懂注释?」。注释少得可怜,也就一些字段含义,不过看单词也能看出来。


队列和队列之间很难看懂,并且很多跨服务的队列,给我开的两个服务根本不够,前后一共加上4个服务才把统计的逻辑串起来,我还专门画了个流程图出来


不管代码设计和质量如何,作为新人别公开喷前辈的代码
前期不要加入太多个性化的代码和设计,每个公司的要求不一致,最好的方式还是模仿
逻辑复杂的话,建议画一个流程图or时序图,架构图的话还是问下老同事,自己画可能不准确
不要轻易下手编码,确保自己很明确整体逻辑了再跟熟悉的同事复述一遍先

好吧,我终于找到逻辑线了(花了1天半时间,留给我开发的时间很近很近),但我发现,结果表很多很多,有AAA_statistics、BBB_statistics、CCC_statistics...... 我拿不定主意,刚好我也对这几个服务熟悉得差不多了,于是我拿着这些成果去问导师L


诚恳的我:「L哥,帮忙看看这几张表,我感觉有一些数据是重复的,还对不上数,帮忙看看呢?」


导师L:「逻辑都捋清楚了吗?」


我直接掏出了我的流程图


导师L:「这是JW(我们组的TL)给你的吗?」


求知的我:「我自己画的,不晓得准确性怎么样,帮忙check下呢」


导师L:「主要是我这还有点事,你再看看吧,晚点我们过一下」


前期难免会有很多问题,但自己也要有点准备,否则被问成麻瓜,印象分直接拉低
不知道的不要说"不知道",可以说"我还不太熟悉,我先去看看逻辑,X哥要不跟我说下大概位置或则有啥文档?"

到了晚上7:00左右,我发现L哥不见了,后来才晓得那天他溜得挺早的。只剩我原地爆炸,明天要联调了,我关键的数据组装service还只有一行//TODO。没招了,我按照我的想法和数据指标,找了几张最合适的表,把数据产出了。


第二天


我早早地来公司,重新check了下代码并又调试了几次,除了数据对不上没啥其他问题。导师L带着早饭来到公司,我还等到吃完早饭再去问了下。


疲惫的我:「L哥,你看我用这张统计表去输出功能有问题没?」


导师L:「就那么几张表,你造几条数据不就看出来了」


疲惫的我:「我造了几条数据,但是昨天的数据我看今天才过来,昨天忘了记录过程」


导师L:「怎么可能,你怎么造的数据,算了等会儿我看一下」


......


过程就不细讲了,总之,不好受...... 最后问题也定位到了,是导师L当初做测试,把定时任务往后延了1天。好吧,这还有定时任务的事儿?我只能看代码看到一堆数据同步的接口,真的是应征了那句话:【最怕的是:我不知道我'不知道'】。


时间允许的话,着手开工前还是留一份概要设计的存档,别把坑都留给后面的人了
流程图、时序图、架构图等,前期多花时间,少走弯路
心态摆好,我们是来打工挣钱的,交不交朋友是其次而已,关系不恶化怎么着都行

而后,比较顺利地进行到提测阶段,bug真的是多得要命,主要是以下几点:


1、数据权限没加(就是prd文档上写的跟xxx模块保持一致逻辑)


2、数据同步时好时坏,排查后发现是定时任务不稳定,大家都在一个环境提测版本,都在修改功能


3、未做改造的功能点测出历史bug(功能类似,故测试同学也纳入了测试范围)


4、服务被其他版本覆盖


导致最终版本交付时,我个人产生了大概20+个bug。周五下午TL专门找我谈话,约谈此事,大概意思是版本复杂度不高,但bug数过多,对我的版本质量不满意。对此,我也阐述了我的解释,这里我就不细说解释的话,大概从以下几点去阐述


不要丢锅,先把由自己粗心产生的bug讲一下,记得提一下数据,因自身代码质量产生了X个bug,后续会加强编码质量,多自测
也不要背锅,说下由于环境问题导致了X个bug的产生,并给出自己的建议,是否能做环境隔离,一个环境只能容纳服务不冲突的1~2个版本
注意下,TL直接对话的机会并不是很多,可以结合自身入职以来的经历,提一些建议(不用管是否重要)
总之,事事多总结,否则像这种情况下TL突然找咱们约谈,说不出个123,印象分会很差

项目总结


在项目研发中,不一定能得到公司前辈们的"关照",这时候就需要先自己憋一下(注意合理安排时间),怎么着也能憋出点内容,那这这些内容再去咨询,效果会好很多。像我这种被孤立的情况,我也不好说是不是常态,我个人还是认为好同事还是居多的。总之还是与同事搞好关系,或者关系一般遇事能帮忙也行,不要跟任何同事把关系闹僵(哪怕脾气差、技术菜、背后勾心斗角)。


还是那句话,遇事不要慌,先调整好心态(道理都看得懂,但希望大家都能做得到),尽力吃透项目再开始施工,否则返工或者低质量产出不好避免。


多做总结,不甩锅不背锅,不管是项目总结还是转正答辩还是晋升答辩,都能有个有条理有依据的总结出来。这点在职场中至关重要。


作者:snowlover
来源:juejin.cn/post/7347542133610364980
收起阅读 »

低谷期可能是在救你

怎么来定义低谷期? 我觉得真正的低谷期是迷茫,挫败,痛苦,自我怀疑等等,反正一定是比肉体上的痛苦更煎熬! 可能你会觉得暂时性找不到工作,面试受挫,分手等是你的低谷期,实则不然,这大概是一个不敢面对自己的借口。 因为多数人找到工作后,只要能在温饱线上,那么90%...
继续阅读 »

怎么来定义低谷期?


我觉得真正的低谷期是迷茫,挫败,痛苦,自我怀疑等等,反正一定是比肉体上的痛苦更煎熬!


可能你会觉得暂时性找不到工作,面试受挫,分手等是你的低谷期,实则不然,这大概是一个不敢面对自己的借口。


因为多数人找到工作后,只要能在温饱线上,那么90%的人就会心安理得摆烂,和男女朋友复合后,依然是维持原样,不会被爱情去刺激自己成长。


如果用工作和分手这两件事情来描述真正的低谷期,那么我觉得应该是这样描述的:


自己付出了很多,每天都像一条疯狗干,工作和学习的时长维持在18个小时左右,坚持了很久,但是没有收获自己想要的东西,希望还是如此渺茫,于是产生严重的自我怀疑,挫败,深圳绝望!


自己一直在努力,在慢慢成长,目标越来越近,但是自己爱得死去活来的女朋友实在等不了自己成长,自己变强,所以无情的选择离开。


经过上面的描述,成为了毋庸置疑的低谷期。


因为没经过描述之前其实你是没有任何斗志的,目的就是能安心混日子,可以用摆烂来形容,和女朋友在一起,自己也不需要啥成本,她也没有啥诉求,所以算得上是互相将就。


但是经过描述后,实际上你的努力近乎疯狂,对于成功是无比的渴望,但是迟迟没降临到你的身上,而女朋友是在你身上压了筹码的,而你又非常爱她,但是迟迟不能让她压的筹码赚个翻倍,所以离开成了定局。


这下就一目了然了吧。


所以这时候你再去回想一下自己所谓的低谷期,是否真的是低谷期?还是自己矫情?


从上面的场景我们能看到深刻二字,第一个是根本谈不上深刻,而第二个是无比的深刻,如果你经历过,那么你自然能理解!


只有让自己刻骨铭心和痛苦的事情才能让自己成长,其他的基本不能。


就像你比较肥胖,三高找上你,家里人叫你不要再吃垃圾食品,不要喝饮料,但是这时候你还没真正躺在病床上,你基本上不会去听。


但是如果此刻你躺在病床上,插着呼吸管,医生给你说,如果你再不注意饮食,那么你很快就会死掉。你看你还会不会再去吃垃圾食品,喝饮料。


所以说,只有让自己脱一层皮,自己才会意识到问题的所在。


那么低谷期里,也自然会脱一层皮,甚至还会换骨头,那么你觉得这难道不是最佳的成长期吗?


所以一个人能遇上真正的低谷期,其实是一种幸运,应该要感谢这个遭遇。


就像一个朋友,因为一些原因导致自己不能再继续读书,家里为了自己的事情而负债累累,自己承受巨大的压力,想死的心都有了。


但是在这段堪称被恶魔惩罚的时期,他没有一蹶不振,反而置之死地而后生,最后无论是财富还是个人能力,阅历都有很大的提升!


后面和他聊天的时候,他说那是自己最痛苦,最无助的时候,但是自己庆幸没有放弃,才造就了一身钢筋铁骨?


所以你说这个低谷期是不幸的吗?


不是,这算的上是恩赐,因为并不是谁都有这种机会。


所以我们在低谷期的时候,如果能有把它作为翻盘的机会的思想,那么它一定是很难得的机会!


但是如果把它作为上天对自己的惩罚,从而一蹶不振,那么其实是错失一次很好的机会,并且也学让自己越陷越深!


作者:苏格拉的底牌
来源:juejin.cn/post/7349750846900125748
收起阅读 »

探索个人IP&副业第三个月的思考:未经审视的人生不值得过

前言 Hi 你好,我是东东拿铁,一个正在探索个人IP&副业的后端程序员。 个人IP探索的第三个月,不再是一往无前的埋头苦干,一腔热血之余,对自己的能力探索与兴趣挖掘,成为了日常生活的主线。 为了更好的坚持下去,希望自己能够找到自己最擅长、做起来最愉悦、...
继续阅读 »

前言


Hi 你好,我是东东拿铁,一个正在探索个人IP&副业的后端程序员。


个人IP探索的第三个月,不再是一往无前的埋头苦干,一腔热血之余,对自己的能力探索与兴趣挖掘,成为了日常生活的主线。


为了更好的坚持下去,希望自己能够找到自己最擅长、做起来最愉悦、自身价值观又认可的事情。但最近一段时间,我意识到,我其实并不了解我自己。想认识自己,也不是一件简单的事情。



古希腊哲学家苏格拉底曾说:“未经审视的人生不值得过。“



话不多说,看看最近一段时间,我身边发生的事情与思考吧。


经历AI的诱惑,坚定内心的方向


其实在23年年底刚开始写作的时候,自己就对自己列了几个方向


其中,AI一直是我自己认为一个很重要的方向,时代大趋势下,所有行业只要加上AI,似乎都变得有些不一样。


image.png


24年年初,我第一次试着去了解AI的工具,是因为那时看到一个圈友,做了一个AI艺术二维码。于是我也下载下了stable-diffusion,准备大展身手一把。


本来是这样想的,发个朋友圈,如果有想要做艺术二维码的,我5块钱给他生成一个,怎么着也算开启了副业收入对吧。


结果人家做出来的是这样的,蛮好看。


image.png


我生成出来的,丑就不说了,问题是扫都扫不出来,就很搞笑。


苦于周边暂时没有大佬支持,也有着别的事情需要做,就暂时被我搁置了。


我的内心其实对AI感兴趣,但实际上,还是以一个程序员思维来考虑的。举一个例子,就想现在.NET的就业环境已经逐渐减少,如果我毕业时选择了一份.NET的工作,那么市场需求一定是很小的。


所以我才会对AI感兴趣,我的思路还是,或许5年后,Java已经不行了,但是算法开发、模型开发可能成为市场需求主流,为了找到工作,不得不去学习AI相关。


这件事情埋在我心里,虽没干成,但毕竟没有搞出来,心里还是有点不甘心的。


从过年伊始,就通过各种渠道,了解到了AI破局社群,即将迎来拉新。那时候我了解到,原来搞AI类应用,其实是有一个专门的社群的,里面也有各种各样的项目让你去落地,还有专业的人给你指导,我之前没跑出来的AI二维码,只要加入,遇到的问题肯定就能解决。


面对着铺天盖地的宣传,自己内心也逐渐有些动摇,一边是追求热点,迅速满足。一边是继续学习写作,延迟满足,看着许多圈友入局,内心还是挺焦虑的。


最终还是克服了自己短期尝试AI的想法,两个原因:



  1. 自己在尝试副业的伊始,就决定2024上半年,我不会思考变现问题,主业还能养活自己。

  2. 既然决定先好好锻炼写作能力,那就应该持续内化基本功,不追求短期目标。


人的精力有限,需要放在有用的地方。


关于写作


上了热榜,占据首页


经过一周时间的打磨,之前经历的一篇文章,竟然上了热榜第一,6000多字的碎碎念能被大家看到,不少朋友给我说能够感同深受,一切的努力都值得了。


image.png


被更多的人看到,固然是好事,但在写这篇文章的过程中,也发现了不少问题,其中低效、内耗的问题,最为严重。


首先,6000多字的文章,完全是个人经历与思考,纯手写的话,如何组织语言,安排好顺序,就是一个最大的问题。


其次,如何把结构梳理好,能够更有连贯性,才能让大家在看的过程中,不枯燥乏味,我花费了非常多的时间。


最后,因为事情涉及到不少真实经历,受限于篇幅,不能完全的呈现给大家,如何选择最能让大家共鸣,最能给大家带来价值的地方,也蛮头疼的。


与现在利用AI工具,一天能够四五篇文章的作者比起来,效率简直低的可怕,虽然带来的价值不一样,但是流量就是这么多,想让更多人看到,效率如何提高,是我接下来要重点思考的事情。


关于输出的“困扰”


经过3个月的输出,我不出意外的遇到了“缺少话题”的情况,这也是最近更新频率变低的最主要的原因。


在这段时间,虽然输出频率降低,但话题的收集没有落下,每当有一些小点子,我就会先记录下来,每天翻一翻,去看看哪些是最想写的。


但实际上,即使收集了很多素材,如果你没有太多想说的话,无疑也只是罗列旧知识,没有新观点,我只想说点新颖的,所以迟迟没有动笔。


为了解决这个问题,两个方法和大家分享下


先立后破


先立后破,虽然话题素材减少,但强制要求自己,每周都要有所输出。


为了达成这个任务,我被迫搜集很多素材,先丰富自己的素材库,然后选择自己最有表达欲的主题,详细去写。


为什么要先立后破


任何事情都有一个逻辑,就是先别管技巧或者合理性,也别管效果如何,先给它规定一个数量,把数量做到了,慢慢的,你就会因为数量而倒逼自己去琢磨如何研究质量。


写作这件事也一样,即使我不知道写什么,也要强迫自己动笔去写,自己在输出这件事上,依然坚信着一句话。



数量不一定能决定质量,但一定能决定重量。



定扩联思维


先确定


能输出的点有很多,技术、副业、写作、复盘,先把内容方向定下来,比如我今天选择的方向就是复盘。


后扩展


扩展的话就好说了,既然是复盘,每一件事情都可以展开来讲,AI的一些经历。关于输出的困扰,输出一些方法论。


再联想


根据自己阅读、学习过的内容,进行发散。比如我深入思考的个人定位问题,最近的所学所想,都可以随着复盘输出出来。


个人定位


这个月花费最多的时间,就是在思考如何有一个清晰的定位。思考过程中问自己的几个问题,也在此罗列出来,如果你也想找到个人定位,也不妨对着这几个问题问一下自己。


职业与专业知识


7年后端研发工程师,北漂回二线城市的大厂程序员。毕业半年裸辞北漂,但经过几年北漂后,为了追求内心、照顾家庭,6年后回到二线城市发展。


北漂阶段,从30人小公司,最终进入大厂。大厂期间面试人数50+,对于求职面试、职业规划有着不少宝贵经验。


完成北漂回归二线城市,完成了城市选择,公司判断,薪资谈判,心里建设等一系列流程,各种有些许挫折,但都一一完成拆解。


善于在复杂项目中抽丝剥茧,但缺乏创造力。经手的项目无论难度多大,都可以极快的完成梳理与上手。但每当新业务开展,思路总会比较局限。


喜欢的博主


个人非常喜欢的博主是,半佛仙人,18年从公众号关注至今,文章几乎一篇不落。


image.png


为什么喜欢?我简单的想了下,有一下几个原因。



  1. 有一定的专业性,瑞幸等一些文章,业内出名,如果大家听说过半佛,大概也看过那些非常出名的文章。

  2. 够肝。热点时事跟踪及时,比较重要的热点新闻,时事动向,他一定参与进来。虽然从作者的角度来说,肯定是要跟着热点和流量走,但对于我这种几乎不看微博和新闻的人来说,能让我省下很多无效时间,还能了解到很多最新的新闻。

  3. 够骚,从他的ID就看出来了:banfoSB,他的文风是我关注的所有博主里,最有特点的。


以上,羡慕。在我眼中,能毫无顾及的表达出自己的看法,让这么多人看到,对于一个爱写东西的人来讲,无疑是一件幸福的事情了。如果这件事情还能赚到钱,那更是锦上添花。


业余爱好


大学业余时间除了打游戏,就是谈恋爱,一上高数就睡觉,下课铃响就起床,


直到看了一本书《皮囊》之后,开始热爱上了阅读。虽然自己生在城市,完全没有农村经历,但对《皮囊》《活着》《兄弟》等很多农村作品,阅读的时候却有着特别大的感触,文中主人工经历越苦难,我的感受越心酸。


后来发现,老读这种文章,人都快看emo了(许多穷苦的事情,自己又没有能力改变什么)。


后来大学期间看了《嫌疑人x的现身》(短篇小说,非常精彩),了解了东野圭吾,对悬疑类作品有了极大兴趣,花了半年的时间就把他大多数重要的作品都看了一遍。印象最深的是《白夜行》,从第一次打开《白夜行》到最终看完,几乎过去了半年的时间,但是《嫌疑人x的现身》只需花了2天时间我就看完了。


但最终读完《白夜行》后,其中的精彩程度让我认为这是东野圭吾小说系列在我心中的No.1。这本书也让我意识到长篇小说的精彩之处,前面之前认为的枯燥的铺垫,到最后都是拍手称绝的伏笔。让我对延时满足这四个字,有个更深的体会。


image.png


后来又听说了村上春树,《挪威的森林》目前为止读了四遍,闲下来仍然会打开翻一翻。里面一些句子,一直在潜移默化的影响着我



不要同情自己,同情自己是卑劣懦夫干的勾当。


所谓绅士,就是做自己该做之事,而不是想做之事。



擅长的事情


我的盖洛普第二名和第五名,是和谐和体谅,遇见冲突解决冲突,并能够设身处地的体会他人的感受。所以之前有很多朋友和我说过,和我聊天,即使问题解决不了,心理上也能舒服很多。


image.png


或许你想找对象,我能帮你发现一些你潜在的问题,帮你去想应该怎么做,才能得到妹妹。


或许你面临裁员、换工作,我能根据你现有的能力与过往的经验,帮你规划提升方向。


或许你面临职场困惑,我也可以根据过往经验给出一些意见。


如果你有类似的问题,也欢迎你来找我聊聊。


说在最后


这次的复盘就先聊到这里了,有小的高光时刻,也有阻碍和自己的思考,感谢你能看到这里。




作者:东东拿铁
来源:juejin.cn/post/7349856694996074550
收起阅读 »

歌词滚动效果

web
需求 实现歌词滚动效果,类似网易云音乐播放界面。 实现 1.准备数据 后台一般会返回这样一个歌词数据,每个时间都对应当前这个歌词。 因为是字符串不方便直接使用,我们把他转化为对象格式。封装一个utils工具传入歌词把lyric转化为对象。 // 处理后端返...
继续阅读 »

需求


实现歌词滚动效果,类似网易云音乐播放界面。



实现


1.准备数据

后台一般会返回这样一个歌词数据,每个时间都对应当前这个歌词。



因为是字符串不方便直接使用,我们把他转化为对象格式。封装一个utils工具传入歌词把lyric转化为对象。


// 处理后端返回歌词
export const HandleLyric = (lyric) => {
    function convertToSeconds(timeArray) {
        // 获取分钟和秒(包括毫秒)  
        const minutes = parseFloat(timeArray[0]); // 使用parseFloat来确保即使分钟有小数部分也能正确处理  
        const secondsWithMilliseconds = parseFloat(timeArray[1]);
        // 计算总秒数  
        const totalSeconds = minutes * 60 + secondsWithMilliseconds;
        return totalSeconds;
    }
    let line = lyric.split('\n')
    let value1 = []
    for (let i = 0; i < line.length; i++) {
        let str = line[i]
        // 把字符串分割为数组
        let part = str.split(']')
        let timestr = part[0].substring(1)
        let parts = timestr.split(':')
        let obj = {
            time: convertToSeconds(parts),
            word: part[1]
        }
        value1.push(obj)
    }
    return value1
}


2.计算偏移量

准备audio标签


  <div class="audio">
      <el-button>立即播放/暂停</el-button>
      <audio :src="audio_info['url']" ref="audio" class="audio-sty">11</audio>
  </div>

调用audio标签的currentTime可以获取当前歌曲播放到第几秒,遍历歌词的时间和当前时间(currentTime)比较,返回的i就是当前歌词的在第几行。


const changeplay = () => {
    let audio = document.querySelector('.audio-sty')
     // 找到当前这一句歌词的索引
        function FindIndex() {
            let currentTime = audio.currentTime
            for (var i = 0; i < store.lyicWords.length; i++) {
                if (currentTime < store.lyicWords[i].time) {
                    return i - 1
                }
            }
            return store.lyicWords.length - 1
        } 
}

计算偏移量


        // 计算偏移量 
        /**
         * 偏移量
         * @containerHeight //容器高度
         * @PHeight   //单个歌词高度
         */
        function Setoffset() {
            var index = FindIndex()
            var offset = index * store.PHeight + store.PHeight / 2 - store.containerHeight / 2
            if (offset < 0) {
                offset = 0
            }
            store.index = index
            store.Offset = offset
        }


用当前歌词所偏移的大小加上单个歌词Height1/2的大小,就可以实现歌词偏移,如果想让每次高亮的歌词在中间,需要再减去container盒子自身Height的一半。




调用audio的timeupadte时间触发计算偏移函数


  // audio 时间变化事件
audio.addEventListener('timeupdate', Setoffset)

3.添加样式

<div class="center" ref="center">
            <h1>歌词</h1>
<el-card class="box-center">
      <div class="center-ci" style="overflow: auto;" ref="lyricHeight">
      <p v-for="(item, index) in  songList['txt']" v-if="songList['txt'].length != 0"
                        :class="[index == store.index ? 'active' : '']">
{{item }}</p>
       <p v-else>纯音乐,无歌词</p>
       </div>
</el-card>
</div>

使用transform: translateY(-50px);控制偏移

使用transform: scale(1.2);控制文字大小


     .center-ci {
                transformtranslateY(-50px);
                display: block;
                height100%;
                width100%;

                p {
                    transition0.2s;
                    font-size20px;
                    text-align: center;
                }

                .active {
                    transformscale(1.2);
                    color: goldenrod;
                }
            }

给歌词容器设置transform就可以实现歌词偏移了



// 根据偏移量滚动歌词 
lyricHeight.value.style.transform = `translateY(-${store.Offset}px)`

4.效果


~谢谢观看


作者:remember_me
来源:juejin.cn/post/7336538738749849600
收起阅读 »

微信小程序:优雅处理分页功能

web
背景 在公司的项目中,分页功能十分常见,以前就是简单的复制粘贴,每次来回切换切面,还经常复制错位置或复制到其他页面去了,半天找不到原因(内心:#*! $%^&@ 1)。 核心思路 分页原理: 属性 page来控制分页数,初始值为1;moreFlag有更多数...
继续阅读 »

背景



在公司的项目中,分页功能十分常见,以前就是简单的复制粘贴,每次来回切换切面,还经常复制错位置或复制到其他页面去了,半天找不到原因(内心:#*! $%^&@ 1)。



核心思路


分页原理:


属性 page来控制分页数,初始值为1;moreFlag有更多数据的标志,初始值为true;pageSize页面自行定义,可以默认设置为10


组件 原生scroll-viewrecycle-view,但内容页面定制化(循环detailList)


方法 bindscrolltolowerbindscrolltoUpper 调取接口获取更多数据,若结果集中的数据量小于pageSize时,moreFlag更新为false,界面激活“暂无更多”标识;bindrefresherrefresh时刷新重置变量为初始值。


后端接口对接 一般接口都会用Promise异步封装,但一般页面中的请求和处理都各不相同,所以不能作为共同点


graph TD
getListChangeStatus初始化 --> getList加载数据 --> getRemoteList调接口输出处理好的结果集 --> getList合并结果集 --> 下拉刷新重置pulldownRefresh

混入


根据上面的分页原理,大都为逻辑处理,所以考虑使用类似Vue里的混入,而在小程序中有一个类似的语法:Behavior

Behavior


image.png


behaviors 是用于组件间代码共享的特性,类似于一些编程语言中的 “mixins” 或 “traits”。


每个 behavior 可以包含一组属性、数据、生命周期函数和方法。组件引用它时,它的属性、数据和方法会被合并到组件中,生命周期函数也会在对应时机被调用。  每个组件可以引用多个 behavior ,behavior 也可以引用其它 behavior


定义Behavior


和组件的配置参数差不多,点击查看详情


注意 即使运用在Page里,方法也需放在methods里;同时注意一下同名字段和生命周期的规则,如下图所示:


image.png
以 scroll-view 按照分页原理来定义分页的Behavior


module.exports = Behavior({
data: {
page: 1,
moreFlag: true,
detailList: [],
refreshFlag: false
},
methods: {
// 初始化
async getListChangeStatus() {
this.setData({
page: 1,
detailList: [],
moreFlag: true
})
await this.getList()
},
// 获取列表
async getList() {
if (!this.data.moreFlag) {
... // 可以增加处理,例如吐司等
return
}
let { detailList,fun } = await this.getRemoteList()
if (detailList) {
let detailListTem = this.data.detailList
if (this.data.page == 1) {
detailListTem = []
}
if (detailList.length < this.data.pageSize) {
//表示没有更多数据了
this.setData({
detailList: detailListTem.concat(detailList),
moreFlag: false
})
} else {
this.setData({
detailList: detailListTem.concat(detailList),
moreFlag: true,
page: this.data.page + 1
})
}
// 可能需要一些处理,例如获取容器的高度之类的,又或者scroll-int0-view对应id
if(fun && fun instanceof Function) fun()
}
},
// 到达底部
reachBottom() {
console.log('--reachBottom--')
this.getList()
},
// 下拉刷新重置
pullDownRefresh() {
this.setData({
page: 1,
hasMoreData: true,
detailList: []
})
this.getList()
setTimeout(() => {
this.setData({
refreshFlag: false
})
}, 500)
}
}
})

引入方法


在页面或组件中(如果页面多个需要分页的地方建议用组件)使用behaviors: [myBehavior]


import pagination from '../../behaviors/pagination.js'
Page({
data: {
pageSize: 10
},
behaviors: [pagination],
onShow() {
this.getListChangeStatus()
},
async getRemoteList() {
let { page, pageSize } = this.data
const returnObj = {}
const res = await XXX // 请求接口
... // 处理数据
returnObj.detailList = data
return returnObj
}
})


<scroll-view scroll-y refresher-enabled refresher-triggered="{{refreshFlag}}" bindrefresherrefresh="pullDownRefresh" bindscrolltolower="reachBottom" style="height:100%;">

scroll-view>



作者:HuaHua的世界
来源:juejin.cn/post/7267417634478719036
收起阅读 »

宏观经济的一些判断

估计谁都没想到2023年,疫情恢复的第一年竟然如此:大厂裁员、楼市继续下跌、年底股市暴跌等。 这篇文章说下笔者对宏观经济的一些理解和判断,以试图解释过去一年发生的一些事情。 宏观经济周期 笔者看来,由于美元具备全球货币属性,美元加息是全球的麻烦。所以总体而言,...
继续阅读 »

估计谁都没想到2023年,疫情恢复的第一年竟然如此:大厂裁员、楼市继续下跌、年底股市暴跌等。


这篇文章说下笔者对宏观经济的一些理解和判断,以试图解释过去一年发生的一些事情。


宏观经济周期


笔者看来,由于美元具备全球货币属性,美元加息是全球的麻烦。所以总体而言,全球经济处于美元加息影响下的结果中,也就是处于美元回流,全球货币紧缩,全球经济处于下行周期中


但每个主要经济体又有其自身的宏观经济周期,比如说我们国家,疫情三年为了人民的生命健康,我们国家没有像西方打开方便之门,大肆放水,而是选择严守死防。


三年疫情,我们国家保护了人民的生命健康,但我们也封闭了三年,紧缩了三年。我们国家处于疫情恢复周期中,处于上行周期中。但始作俑者的美国因为超发货币,自身经济过热,所以需要降低过热经济,所以宏观经济也处于下行周期中。


这里说一个题外话,宏观经济是通缩好还是通货膨胀好呢?实际上,过分的通缩和过分的通货膨胀都不好,适度的通胀最好,一般来说维持在2%左右是比较好的,这也就是美国一直想通过加息实现的通胀水平。


不管是通缩还是通胀代表的都是一种趋势,通缩经济逐渐下行,规模逐渐减小,反之通胀经济处于上行,规模逐渐扩大,这样才能实现GDP的增长,实现经济的发展。


回来继续说宏观经济周期,当下国家要做的就是让经济处于扩张区间,或者说实现经济的适度通胀。


2023年CPI和PPI一直不温不火,其实有一点通缩的迹象,所以国家在出台各种手段改善这种迹象:



  1. 对楼市逐渐降低首付比例,逐渐放开楼市,逐渐降息,逐渐降低存款准备金等

  2. 对股市降低印花税,转融通暂停,加大逆回购力度,证监会新管理层上任等


但改变趋势谈何容易,同时还要考虑美国的加息节奏。所以出台的手段并不是那么尽如人意,也因为受到美国加息节奏的影响,为了维持外汇的稳定性,出台的时机也并未尽如人意。


笔者觉得正因为上述原因:美元加息周期、国内降息周期导致2023大厂裁员、楼市继续下跌、年底股市暴跌。


2024年宏观经济


目前美国已经暂停加息半年,加息周期已经到顶,预期5、6月份后降息。也正因为暂停加息,加息到顶我国央行今天进一步降低5年期贷款利率。


2024年的国内的宏观经济依然是将经济恢复为适度通胀的水平。笔者的判断是在汇率稳定的前提下,稳定楼市,因为楼市涉及的面太大。稳定了楼市才能稳定经济稳定预期,才能稳定股市。


完全有可能的是央行在美国降息后选择再一次降息贷款利息的方式,加强人们的信心,加强人们对国家进一步搞活经济的决心,给人们信心。


稳定楼市而不是大力发展楼市。笔者认为未来国家的发展会逐渐向高科技产业倾斜,从依靠楼市带动GDP增长改为依靠科技带动。


综上,一些配套的改革一定也会有:比如真正支持优秀公司发展的证券市场,比如政府职能转变为服务好企业,比如更加开放的区域市场(现在的浦东新区)等等。


而笔者比较关心的股票市场,隶属于证券市场,笔者觉得未来中国的股市一定会越来越好,尤其优秀的科技公司。


(本文完)


作者:通往自由之路
来源:juejin.cn/post/7337227407365963803
收起阅读 »

打工人应避免被过度体制化

《肖申克的救赎》是一部令人震撼的电影。其给我留下深刻印象的不止男主的筹谋,还有终获假释,却选择上吊自杀的老布。老布是一个悲剧人物。 老布被关押监狱五十年。半个多世纪,老布从青年变为白发苍苍的老头,他最终熟悉了监狱的一切,适应了监狱的一切,也和监狱捆绑在了一起。...
继续阅读 »

《肖申克的救赎》是一部令人震撼的电影。其给我留下深刻印象的不止男主的筹谋,还有终获假释,却选择上吊自杀的老布。老布是一个悲剧人物。


老布被关押监狱五十年。半个多世纪,老布从青年变为白发苍苍的老头,他最终熟悉了监狱的一切,适应了监狱的一切,也和监狱捆绑在了一起。用电影中的话来说,老布被监狱“体制化”了,包括他的自我认同,自我习惯。他依赖这个监狱。


也正因为此,出狱后的老布因为无法适应、融入发生巨变的社会环境,选择结束自己的一生。


体制化是指是个人或群体在某种环境中逐渐适应并接受其中的规则、习惯、意识和氛围,以至于这些成为其思考和行为的一部分。比如说销售人员更会自我激励,司机师傅更容易记下位置路线,财务人员更细致……


现代社会高度发展,每个人都不可避免的依赖某个组织或企业。为了融入组织或企业,被体制化是必然。但过度被体制化,比如长期生活在农村的老人,长期在高速口收费的收费员,长期无法晋升的公司老白兔……不利于人的发展,应该主动避免。


分工


现代企业建立的基础之一是大规模生产下的分工,分工可以提高生产效率,但分工也让人失去独立性。就拿上面长期在高速口收费的收费员举例,几年前河北高速一个收费员被辞退,就闹了起来,原因是他别的什么都不会了。


长期单一职责一旦被离职很容易陷入困境,轻者生活质量下降;重者长期失业;更重者,如老布一般选择终结自己的生命,事实上前几年就发生了这种事……


企业机会狼多肉少


几年前读过一句话:我们的社会实际是一个精英筛选系统,大多数人存在的意义是辅助筛选。这句话套用在企业也适用,企业是一个小型的精英筛选系统。


这些年互联网行业流行的所谓35岁职场危机,背后实际是部分企业认定35岁没能成为精英,也就不具人力性价比,选择不再对其招聘。


35岁大部分都有了家庭,要是35岁没有成为精英,相关企业招聘的意愿又不强,只能等着被辞退。要是在被过度体制化,被拴在一家企业,那无疑是雪上加霜。


体制化是放弃整个森林


我对企业有很多定义,其中之一企业是社会当中满足一系列特定需求的组织。一系列特定需求实际是局部市场。在局部市场里,企业注定机会有限。而市场本身比企业拥有更多机会,被过度体制化会被动放弃拥有更多机会的可能。


积极培养第二曲线甚至第三曲线


随着技术的提高,经济的发展,现代职业的生命周期在缩短。我认为每个人应该积极培养第二甚至第三职业。第二职业可以是自媒体,比如写作、比如up主、再比如小红书博主……可以是其他擅长的,可以利用下班时间去做的事业。


第三职业可以是投资人,投资是坐顺风车的学问,重要的是识别顺风车。做投资可以先从二级市场,也就是股票市场开始(投资需谨慎)。要能够借国家发展的大势,享受国家发展带来的红利。


我之前写过一篇关于宏观经济的文章《宏观经济的一些判断》。目前,我国经济处于上行周期中,受房地产拖累,经济爬坡有些缓慢。上个月CPI同比上涨0.7%,消费意愿在加强;上个月社融处于增长态势,经济活动相对活跃,上个月规模以上企业工业增加值显著增长……


种种迹象表明经济在好转,我也相信经济一定会好起来,经济好起来叠加国家对证券市场的进一步规范,不久以后股市完全有可能成为新的国民财富蓄水池。


结尾


总之,在工作过程中要识别哪些规则、习惯、意识和氛围,长期来讲是真正的机会,哪些不是。到了一定年龄,看不到成为公司精英的希望,应发展更多社会生存技能,在社会这个更大市场中生根发芽,创造财富,获取财富。


也希望能够直接借到国家发展大势,直接享受国家发展红利。


作者:通往自由之路pro
来源:juejin.cn/post/7348013957732941876
收起阅读 »

微信小程序商城分类滚动列表锚点

web
一、需求背景最近接了个商城小程序的项目,在做商品分类页面的时候,一开始是普通分类列表,但是客户觉得效果不理想,想要滚动列表的效果,需要实现以下功能:列表滑动效果;滑动切换分类;点击分类跳转到相应的分类位置。思路是用使用官方组件scroll-view,给每个分类...
继续阅读 »

一、需求背景

最近接了个商城小程序的项目,在做商品分类页面的时候,一开始是普通分类列表,但是客户觉得效果不理想,想要滚动列表的效果,需要实现以下功能:

  1. 列表滑动效果;
  2. 滑动切换分类;
  3. 点击分类跳转到相应的分类位置。

思路是用使用官方组件scroll-view,给每个分类(子元素)添加锚点,然后记录每个分类项的高度,监听scroll-view组件滚动事件,计算分类的跳转

二、效果演示

录制_2023_04_18_11_25_56_701.gif

三、核心代码实现

下面要使用到的方法都来自于查阅微信小程序官方文档

  1. 创建一个scoll-view 并配置需要用到的属性scroll-int0-view 根据文档描述此属性是子元素的id,值为哪个就跳到那个子元素。为了使跳转不显得生硬,再添加scroll-with-animation属性,然后创建动态生成分类的dom元素并为每个子元素添加相应的id

image.png

        <view class="content">

<scroll-view scroll-y scroll-with-animation class="left" style="height:{{height}}rpx;" scroll-int0-view='{{leftId}}'>
<view id='left{{index}}' class="left-item {{activeKey===index?'active':''}}" wx:for="{{navData}}" data-index='{{index}}' wx:key='id' bindtap="onChange">
<text class='name'>{{item.name}}text>
view>
scroll-view>

<scroll-view class="right" scroll-y scroll-with-animation scroll-int0-view="{{selectedId}}" bindscroll="changeScroll" style='height:{{height}}rpx;'>

<view class="item" wx:for="{{goodslist}}" wx:key="id" id='type{{index}}'>

<view class="type">【{{item.name}}】view>

<view class="item-list">
<navigator class="list-item" wx:for="{{item.list}}" wx:for-item='key' wx:key="id" url='/pages/goods/goods?id={{key.id}}'>
<image style="width: 100%; height: 180rpx;" src="{{key.imgurl}}" />
<view class="item-name">{{key.goods_name}}view>
navigator>
view>
<view wx:if="{{item.list.length===0}}" class="nodata">
暂无商品
view>
view>
scroll-view>
view>

css部分

这里用到了吸顶效果position: sticky;

        .content {
width: 100%;
height: calc(100% - 108rpx);
overflow-y: hidden;
display: flex;

.left {
height: 100%;
overflow-y: scroll;
.left-item {
width: 100%;
padding: 20rpx;
box-sizing: border-box;

.name {
word-wrap: break-word;
font-size: 28rpx;
color: #323233;
}
}

.active {
border-left: 6rpx #ee0a24 solid;
background-color: #fff;
}
}

.right {
flex: 1;

.item {
position: relative;
padding: 20rpx;

.type {
margin-bottom: 10rpx;
padding: 5rpx;
position: sticky;
top: 0;
background-color: #fff;
}

.item-list {
width: 100%;
display: grid;
grid-template-columns: 1fr 1fr 1fr;
grid-gap: 20rpx;
text-align: center;

.item-name {
color: #3a3a3a;
font-size: 26rpx;
margin-top: 10rpx;
}
}

.nodata{
padding: 20rpx;
color: #ccc;
}
}
}
}

2. 在列表渲染完成之后计算出每个分类的高度并且保存成一个数组

// 用到的data
data:{
// 分类列表
navData:[],
// 商品列表
goodslist:[],
// 左侧分类选中项 分类列表数组的下标
activeKey:0,
// 计算出的锚点的位置
heightList:[],
// 右侧子元素的锚点
selectedId: 'type0',
// 左侧分类的锚点
leftId:'left0',
// scroll-view 的高度
height:0
},
onShow() {
let Height = 0;
wx.getSystemInfo({
success: (res) => {
Height = res.windowHeight
}
})
const query = wx.createSelectorQuery();
query.selectAll('.search').boundingClientRect()
query.exec((res) => {
// 计算滚动列表的高度 视口高度减去顶部高度 *2是因为拿到的是px 虽然也可以 但是我们通常使用的是rpx
this.setData({
height: (Height - res[0][0].height) * 2
})
})
},

//计算右侧每个锚点的高距离顶部的高
selectHeight() {
let h = 0;
const query = wx.createSelectorQuery();
query.exec((res) => {
console.log('res', res)
let arr=res[0].map((item,index)=>{
h+ = item.height
return h
})
this.setData({
heightList: arr,
})
console.log('height', this.data.heightList)
})
},

使用到的相关API image.png

  1. 监听scroll-view的滚动事件,通过滚动位置计算当前是哪个分类。
changeScroll(e) {
// 获取距离顶部的距离
let scrollTop = e.detail.scrollTop;
// 当前分类选中项,分类列表下标
let {activeKey,heightList} = this.data;
// 防止超出分类 判断滚动距离是否超过当前分类距离顶部高度
if (activeKey + 1 < heightList.length && scrollTop >= heightList[activeKey]) {
this.setData({
// 左侧分类选中项改变
activeKey: activeKey + 1,
// 左侧锚点对应位置
leftId: `left${activeKey + 1}`
})
}
if (activeKey - 1 >= 0 && scrollTop < heightList\[activeKey - 1]) {
this.setData({
activeKey: activeKey - 1,
leftId: `left${activeKey - 1}`
})
}
},

4. 监听分类列表点击事件,点击分类跳转相应的分类商品列表

onChange(event) {
let index = event.currentTarget.dataset.index
this.setData({
activeKey: index,
selectId: "item" + index
});
},

四、总结

左侧分类一开始是用的vantUI的滚动列表,但是分类过多就不会随着滑动分类滚动到可视位置,所以改成自定义组件,反正也很简单。

最初是想根据右侧滚动位置给左侧的scroll-view添加scroll-top,虽然实现,但是有时会有一点小问题目前没有想好怎么解决,改用右侧相同方法实现可以解决。

css部分使用scss编写,使用的是vscode的easy scss插件,具体方法百度一下,很简单。


作者:丝网如风
来源:juejin.cn/post/7223211123960660028

收起阅读 »

如何防止网站信息泄露(复制/水印/控制台)

web
一、前言 中午休息的时候,闲逛公司内网,看到一个url,就想复制一下url,看看url对应的内容是啥,习惯性使用ctrl+c,然后ctrl+v,最后得到是 禁止复制,哦,原来是禁用了复制。这能难倒一个前端开发吗?当然不能。于是打开了控制台,这时,发现页面自动执...
继续阅读 »

一、前言


中午休息的时候,闲逛公司内网,看到一个url,就想复制一下url,看看url对应的内容是啥,习惯性使用ctrl+c,然后ctrl+v,最后得到是 禁止复制,哦,原来是禁用了复制。这能难倒一个前端开发吗?当然不能。于是打开了控制台,这时,发现页面自动执行了一段立即执行函数,函数体里面是debugger代码,然后手动跳过debugger后,页面已经变成一个空白页面了。


本文将简单讲解禁止复制、水印和禁止打开控制台三个功能点的实现。


前面几节是分功能讲解,最后一节将会写出完整的代码,如何防止网站信息泄露。


二、禁止复制


现在有的复制网页(常规网页用户,不开控制台的情况)的内容方式有:



  1. 选择 -> ctrl+c(command + c)

  2. 选择 -> 鼠标右键 -> 复制


js拦截


相比user-select无法做到某一些内容可以被选中


document.addEventListener('contextmenu', function(e) {  
e.preventDefault();
}, false);

document.addEventListener('selectstart', function(e) {
e.preventDefault();
}, false);


user-select


不难发现,当我们复制内容的时候,首选是选择目标内容,那我们可以禁用用户的选择目标内容。


css属性user-select用于控制用户是否能够选择(即复制)文本和其他页面元素。它的作用是指定用户在浏览网页时是否能够选择和复制页面上的文本和其他元素。


<h3>user-select: none;</h3>
<div style="user-select: none;">我是捌玖,欢迎关注我哟,这儿是利用css样式,测试能否禁用复制</div>
<div style="user-select: none;">哈哈哈,当然,这种方式是无效的,我只是玩下</div>

那user-select和pointer-event的区别是啥?
pointer-events  指定在什么情况下 (如果有) 某个特定的图形元素可以成为鼠标事件的 target (en-US)。通俗一点讲,例如我们给某个元素设置了pointer-events: none,当我们点击这个元素的时候,是不会触发click事件,包括我们即使通过鼠标也无法选中该元素。

user-select 用于控制用户是否可以选择文本。这不会对作为浏览器用户界面(即 chrome)的一部分的内容加载产生任何影响,除非是在文本框中。



注意:user-select是无法拦截input中的选中(鼠标/ctrl+a)



拦截ctrl + a


每个人(系统)使用使用组合键进行复制,可能键是存在差异的,就拿我电脑是mac,默认是command + a为复制,当然是可以修改的,看个人使用习惯,所以我们要同时拦截掉ctrl + a 和 command + a。


document.keyDown = function(event) {
const {ctrlKey, metaKey, keyCode} = event;
if((ctrlKey || metaKey) && keyCode === 65) {
return false;
}
}

拦截ctrl+c(command + c)


每个人(系统)使用使用组合键进行复制,可能键是存在差异的,就拿我电脑是mac,默认是command + c为复制,当然是可以修改的,看个人使用习惯,所以我们要同时拦截掉ctrl + c 和 command + c的。不可以直接拦截c键的输入,会影响到input框的输入


document.keyDown = function(event) {
const {ctrlKey, metaKey, keyCode} = event;
if((ctrlKey || metaKey) && keyCode === 67) {
return false;
}
}

直接拦截鼠标右键


该方法直接拦截了右键菜单的打开,主要用于拦截图片的复制,菜单中的复制图片的方法有多种(复制图片、复制图片地址等),暂时没找到合适的方法拦截菜单中具体的某一项。
image.png


document.oncontextmenu = function(event){
if(event.srcElement.tagName=="IMG"){
alert('图片直接右键');
return false;
}
};

三、水印


网站水印的主要作用是版权保护和网站标识展示。具体来说,它可以在图片上加上作者的信息或标识,防止他人未经授权使用,有助于保护图片的版权安全。同时,它也可以在网页中展示特定的标识或信息,如网站的名称、网址、版权信息等,有助于提高网站的知名度和品牌形象。


此外,网站水印还可以用于追踪网站的非法使用和侵权行为。当发现某个网站上出现了未经授权的水印,就可以通过水印的信息追踪到该网站的使用者,从而采取相应的法律措施。


// 创建Canvas元素  
const canvas = document.createElement('canvas');
const context = canvas.getContext('2d');

// 设置Canvas尺寸和字体样式
canvas.width = 100;
canvas.height = 100;
context.font = '30px Arial';
context.fillStyle = 'rgba(0,0,0,0.1)';

// 绘制文字到Canvas上
context.fillText('捌玖', 10, 50);

// 生成水印图像的URL
const watermarkUrl = canvas.toDataURL();

// 在页面上显示水印图像(或进行其他操作)
const divDom = document.createElement('div');
divDom.style.position = 'fixed';
divDom.style.zIndex = '99999';
divDom.style.top = '-10000px';
divDom.style.bottom = '-10000px';
divDom.style.left = '-10000px';
divDom.style.right = '-10000px';
divDom.style.transform = 'rotate(-45deg)';
// 避免对用户的交互产生影响
divDom.style.pointerEvents = 'none';
divDom.style.backgroundImage = `url(${watermarkUrl})`;
document.body.appendChild(divDom);

四、禁止打开控制台


禁止用户打开控制台



  1. 防止代码被窃取:在控制台中,用户可以查看和修改网页的源代码,这可能会导致恶意用户窃取您的代码或敏感信息。通过禁止打开控制台,可以保护您的代码和数据不被未经授权的用户访问或篡改。

  2. 提高安全性:控制台是网页与用户之间进行交互的主要渠道之一,但也是潜在的安全风险之一。恶意用户可以利用控制台执行恶意代码、进行钓鱼攻击等。禁止用户打开控制台可以减少这些潜在的安全风险。

  3. 保护系统资源:在控制台中,用户可以执行各种操作,例如创建新文件、删除文件等,这可能会对系统资源造成不必要的占用和破坏。禁止打开控制台可以限制用户的操作范围,保护系统资源不被滥用。

  4. 防止误操作:控制台允许用户进行各种操作,但这也增加了误操作的风险。禁止打开控制台可以减少用户误操作的可能性,避免不必要的损失和风险。


let firstTime;
let lastTime;
setInterval(() => {
firstTime = Date.now()
debugger
lastTime = Date.now()
if (lastTime - firstTime > 10) {
window.location.href = "about:blank";
}
}, 100)

五、总结


    // 防止用户选中
function disableSelect() {
// 方式一,js拦截
// 缺点: 无法做到某一些内容可以选中
document.onselectstart = function(event){
e.preventDefault();
};


// 方式:给body设置样式
document.body.style.userSelect = 'none';


// 禁用input的ctrl + a
document.keyDown = function(event) {
const {ctrlKey, metaKey, keyCode} = event;
if((ctrlKey || metaKey) && keyCode === 65) {
return false;
}
}
};

// 禁用键盘的复制
function disableCopy() {
const {ctrlKey, metaKey, keyCode} = event;
if((ctrlKey || metaKey) && keyCode === 67) {
return false;
}
}

// 禁止复制图片
function disableCopyImg() {
document.oncontextmenu = function(event){
if(event.srcElement.tagName=="IMG"){
alert('图片直接右键');
return false;
}
};
};

// 生成水印
function generateWatermark(keyword = '捌玖') {
// 创建Canvas元素
const canvas = document.createElement('canvas');
const context = canvas.getContext('2d');

// 设置Canvas尺寸和字体样式
canvas.width = 100;
canvas.height = 100;
context.font = '30px Arial';
context.fillStyle = 'rgba(0,0,0,0.1)';

// 绘制文字到Canvas上
context.fillText(keyword, 10, 50);

// 生成水印图像的URL
const watermarkUrl = canvas.toDataURL();

// 在页面上显示水印图像(或进行其他操作)
const divDom = document.createElement('div');
divDom.style.position = 'fixed';
divDom.style.zIndex = '99999';

// 因为div旋转了45度,所以div需要足够的大
divDom.style.top = '-10000px';
divDom.style.bottom = '-10000px';
divDom.style.left = '-10000px';
divDom.style.right = '-10000px';
divDom.style.transform = 'rotate(-45deg)';

// 防止对用户的交互产生影响
divDom.style.pointerEvents = 'none';
divDom.style.backgroundImage = `url(${watermarkUrl})`;
document.body.appendChild(divDom);
}

// 禁止打开控制台
function disbaleConsole() {
let firstTime
let lastTime
setInterval(() => {
firstTime = Date.now()
debugger
lastTime = Date.now()
if (lastTime - firstTime > 10) {
window.location.href = "about:blank";
}
}, 100);
}

disableSelect();
disableCopy();
disableCopyImg();
generateWatermark();
disbaleConsole();

作者:捌玖ki
来源:juejin.cn/post/7292416512333332534
收起阅读 »

瘫痪8年后,马斯克的首个脑机接口人类植入者,正在用念力玩文明6

一名因潜水事故导致肩部以下瘫痪八年的 29 岁男子,正在借助脑机接口设备重温在线国际象棋和杀时间大作游戏《文明 6》。 这是脑机接口公司 Neuralink 最新一场直播的内容,迅速吸引了五百万多人围观。 在九分钟的简短直播中,Neuralink 首位人体...
继续阅读 »

一名因潜水事故导致肩部以下瘫痪八年的 29 岁男子,正在借助脑机接口设备重温在线国际象棋和杀时间大作游戏《文明 6》。


图片


这是脑机接口公司 Neuralink 最新一场直播的内容,迅速吸引了五百万多人围观。


图片


在九分钟的简短直播中,Neuralink 首位人体受试者 Noland Arbaugh 先是进行了自我介绍,并表示自己可以使用 Neuralink 设备玩在线国际象棋和视频游戏《文明》。


Arbaugh 使用一把特制的椅子坐在笔记本电脑前。当他试图控制一盘棋时,双手仍然放在椅子的扶手上:


图片


「这并不完美。我想说我们遇到了一些问题。我不想让人们认为这是旅程的终点,还有很多工作要做,」Arbaugh 在 Neuralink 工程师 Bliss Chapman 旁边说道。但脑机接口已经为他的生活带来了许多改善,比如终于不用依赖家人就能玩几个小时的视频游戏了。


原本的身体情况限制了他参与最喜欢的电子游戏《文明 6》的能力,因为每次只能玩几个小时,然后需要家人的帮助来重新调整坐姿。


「我基本上已经放弃玩那个游戏了,」他补充说这是一个「大型游戏」,需要很多时间坐着不动。


有了脑机芯片之后,躺在床上玩几小时的视频游戏不成问题。如果说仍有限制,那就是在连续玩 8 个小时的视频游戏后,必须再次为设备充电。这对于经常「一局到天亮」的《文明 6》来说,确实还不太够。


在直播中,Arbaugh 描述了学习如何使用脑机接口的过程:「我会尝试移动,比如说,我的右手向左、向右、向前、向后移动,从那时起,我觉得开始想象光标移动变得很直观。」


他说:「如果你们能看到光标在屏幕上移动,那或许就是我。」


虽然直播中包含的细节相对较少,但 Neuralink 工程师在视频中表示,未来几天公司会发布更多信息。


脑机接口研究的重要一步


Neuralink 由马斯克在 2016 年创立,目前正在开发一种被称为脑机接口的系统,它可以从大脑信号中解码运动意图。该公司的初步目标是让瘫痪者只用意念就能控制光标或键盘。


此次直播,使 Neuralink 成为了真正发布人脑植入证据的公司之一。另外发布过证据的两家公司 Blackrock Neurotech 和 Synchron 领先多年,三家公司各有不同的做法,同时这一赛道也涌入了不少初创公司。 


比如,Neuralink 的一位联合创始人于 2021 年离开公司,创办了竞争对手 Precision Neuroscience,去年 6 月开始了一项人体临床研究。 


而 Neuralink 遭遇了严格的审查,部分原因是其创始人马斯克也是特斯拉和 SpaceX 的首席执行官,且是世界上最富有的人之一。 


Neuralink 去年获得了美国食品和药物管理局(US Food and Drug Administration)的绿灯,可以继续进行初步人体试验,并在秋季开始招募瘫痪者来测试该设备。


但到目前为止,Neuralink 公司几乎没有透露这项研究进展的细节。


马斯克在 1 月份的一篇 X 帖子中宣布,第一个人体试验对象已经接受了 Neuralink 的植入物,并且「恢复良好」。


图片


2 月 19 日,马斯克在 X 上的 Spaces 音频对话中回答了有关参与者情况的问题:「进展良好,患者似乎已完全康复,没有出现我们所知的不良影响。患者只需通过思考就能在屏幕上移动鼠标。」


Neuralink 的设备通过该公司开发的手术机器人植入大脑;一旦植入成功,它在外观上是不可见的。为了分析大脑信号并将其转化为输出命令来控制外部设备,Neuralink 还设计了专门的软件。


Arbaugh 的此次直播似乎打消了人们对设备安全的顾虑:「我想,没什么好害怕的。手术非常简单,一天后我就真的出院了。」他还表示手术后没有认知障碍。


争议中前行的脑机接口


一些神经科学家和伦理学家批评 Neuralink 之前的试验缺乏透明度。2021 年,Neuralink 发布了一段视频,展示一只植入其设备的猴子通过心灵感应玩电子游戏,引起巨大轰动。美国动物保护组织 PCRM 曾对 Neuralink 提起诉讼,指控其「虐待」试验中使用的猴子。


图片


Neuralink 回应称:「多只猴子在参加试验之前健康状况就已经不佳,即将被实施安乐死。所有新的医疗设备都必须先在动物身上进行测试,然后再在人体上进行测试。这是 Neuralink 无法逃避的规则。但我们绝对致力于以尽可能人道和道德的方式与动物合作。」


相比于动物,人类受试者参与试验在伦理方面会带来更大的挑战。Neuralink 尚未透露将参加此次初步人体试验的受试者数量、试验地点或将进行的评估。


值得注意的是,Neuralink 尚未在 ClinicalTrials.gov (一个包含涉及人类受试者的医学研究信息的政府存储库)上注册。


据专家称,即使脑机接口设备被证明可安全用于人体,Neuralink 仍可能需要十多年的时间才能获得商业使用许可。


除了 Neuralink,其他几家公司也在竞相将脑机接口商业化。例如,Synchron 正在开发一种类似支架的装置,试图将其插入颈静脉并向上移动,使其紧贴大脑。相比之下,Synchron 的血管介入方式有着比 Neuralink 更高的安全性,Neuralink 需要切入人体颅骨进行设备植入。


Synchron 曾为 ALS 患者植入其脑机接口设备 ——Stentrode。接受 Stentrode 植入物后,参与者可以使用计算机通过文本进行交流并完成日常任务,比如在线购物和办理银行业务。


图片


Synchron 的临床参与者通过使用他的思想以数字方式控制他的计算机来进行交流。


然而,FDA 尚未批准任何脑机接口设备,它们都还处于实验阶段。


参考链接:http://www.wired.com/story/neura…


http://www.sohu.com/a/535904499…


作者:机器之心
来源:juejin.cn/post/7348640468005273615
收起阅读 »

ES2024即将发布!5个可能大火的JS新方法

web
Hello,大家好,我是 Sunday。 ECMAScript 2024(ES15) 即将发布(2024年6月),新的版本带来了非常多全新的特性。其中有 5 个全新的 JS 方法,可以大幅度提升我们的工作效率,从而让我们得到更多的摸鱼时间。咱们一起来看看吧! ...
继续阅读 »

Hello,大家好,我是 Sunday。


ECMAScript 2024(ES15) 即将发布(2024年6月),新的版本带来了非常多全新的特性。其中有 5 个全新的 JS 方法,可以大幅度提升我们的工作效率,从而让我们得到更多的摸鱼时间。咱们一起来看看吧!


01:Promise.withResolvers


这个功能引入了一个新方法来创建一个 promise,直接返回 resolve 和 reject 的回调。使用 Promise.withResolvers ,我们可以创建直接在其执行函数之外 resolve 和 reject


const [promise, resolve, reject] = Promise.withResolvers();

setTimeout(() => resolve('Resolved after 2 seconds'), 2000);

promise.then(value => console.log(value));

02:Object.groupBy()


Object.groupBy() 方法是一项新添加的功能,允许我们按照特定属性将数组中的 对象分组,从而使数据处理变得更加容易。


const pets = [
{ gender: '男', name: '张三' },
{ gender: '女', name: '李四' },
{ gender: '男', name: '王五' }
];

const res = Object.groupBy(pets, pet => pet.gender);
console.log(res);
// 输出:
// {
// 女: [{ gender: '女', name: '李四' }]
// 男: [{ gender: '男', name: '张三' }, { gender: '男', name: '王五' }],
// }

03:Temporal


Temporal提案引入了一个新的API,以更直观和高效的方式 处理日期和时间。例如,Temporal API提供了新的日期、时间和持续时间的数据类型,以及用于创建、操作和格式化这些值的函数。


const today = Temporal.PlainDate.from({ year: 2023, month: 11, day: 19 });
console.log(today.toString()); // 输出: 2023-11-19

const duration = Temporal.Duration.from({ hours: 3, minutes: 30 });
const tomorrow = today.add(duration);
console.log(tomorrow.toString()); // 输出: 2023-11-20

04:Records 和 Tuples


Records 和 Tuples 是全新的数据结构,提供了一种更简洁和类型安全的方式来创建对象和数组。



  • Records 类似于对象,但具有具体类型的固定属性集。

  • Tuples 类似于数组,但具有固定长度,每个元素可以具有不同类型。


let record = #{
id: 1,
name: "JavaScript",
year: 2024
};
console.log(record.name); // 输出: JavaScript

05:装饰器(Decorators)


装饰器(Decorators)是一种提议的语法,用于添加元数据或修改类、函数或属性的行为。装饰器可用于实现各种功能,如日志记录、缓存和依赖注入。


function logged(target, key, descriptor) {
const original = descriptor.value;
descriptor.value = function(...args) {
console.log(`Calling ${key} with`, args);
return original.apply(this, args);
};
return descriptor;
}

class Example {
@logged
sum(a, b) {
return a + b;
}
}

const e = new Example();
e.sum(1, 2); // 输出:[1, 2]

其他


ES15 还提供了很多其他的新提案,比如:新的正则v、管道符|>String.prototype.isWellFormed()ArrayBuffer.prototype.resize 等等。大家有兴趣的同学可以额外到 mdn 网站上进行了解~~



前端训练营:1v1私教,终身辅导计划,帮你拿到满意的 offer 已帮助数百位同学拿到了中大厂 offer。欢迎来撩~~~~~~~~



作者:程序员Sunday
来源:juejin.cn/post/7349410765525483555
收起阅读 »

💀填好个税,一年多给几千块 ~ 聊聊个人所得税,你该退税还是补税?写一个个税的计算器(退税、补税、个税)

前言 一年一度个税年度综合汇算清缴的时间又到了,作为开发者的你,肯定过了起征点了吧。🫤 去年退税退了 5676 ,今年看这个估计得补好几千,但是个税年度汇算清缴还没有预约到,抓紧提前算算金额,做做心理建设。\同时,了解个税都扣在哪了,才可以让我们合理避税~ 下...
继续阅读 »

前言


一年一度个税年度综合汇算清缴的时间又到了,作为开发者的你,肯定过了起征点了吧。🫤


去年退税退了 5676 ,今年看这个估计得补好几千,但是个税年度汇算清缴还没有预约到,抓紧提前算算金额,做做心理建设。\同时,了解个税都扣在哪了,才可以让我们合理避税~


下面我们简单聊聊 补税预缴 ,顺便讲讲专项附加扣除应该怎么填。


以及带大家写一个个税计算器。你可以通过码上掘金查看 在线 svelte(无UI) 版 ,后续也会推出其他框架版。


为什么你需要补税?


大多数情况下,公司发工资会替你把税交了,这个行为叫预缴。


为什么预缴呢?因为国家规定:



《个人所得税扣缴申报管理办法(试行)》(国家税务总局公告2018年第61号发布)

第六条:扣缴义务人向居民个人支付工资、薪金所得时,应当按照累计预扣法计算预扣税款,并按月办理扣缴申报。



这也就是我们每个月发工资都会扣税的原因。


那为什么需要补税呢?因为预缴是根据你在当前公司的收入进行缴税,公司会计算你的累进税率,你会发现每到年底税交的越来越高了,这是累进预缴导致的。


有些人在年中换了工作了,新公司不知道你之前已经交到哪个阶段的个税了,因此预缴时计税金额会重新累计。


因此补税的原因不外乎:



  • 工作变更

  • 公司主体变更(如:公司拆分)


为什么说预缴是天才发明?


预缴制简直是个天才发明,不但会大大减少逃税人数,而且能减轻税务工作量(转移至各公司),且可以让缴税的人对税率的感知没有那么强烈。


达成这种效果主要原因有两点,分别是 损失厌恶心理账户


损失厌恶


人们对损失的敏感程度通常远远大于对同等价值的收益的敏感程度

人们对损失的敏感程度通常远远大于对同等价值的收益的敏感程度

人们对损失的敏感程度通常远远大于对同等价值的收益的敏感程度


牢记这句话。


一个最简单的例子,短视频中经常会出现的 最有效的 6 条学习方式,最后一条最重要 。这种放大损失的语言,常常能诱发更高的完播率。



虽然我很讨厌以这种方式留住用户,但常常在刷到这类视频时,也忍不住多看一样,虽然知道它最终可能也没什么实质内容。



还有一种就是我们常常刷掉一个视频,又返回去看一眼,又刷掉又返回去。我常常会有这种心理,这个视频我是不是应该看一看的纠结。


个税也是同理,个税预缴是减少我们的收益,而个税年终汇算则是直接让我们从口袋中掏钱。


就算汇算综合到月度计算,同样也是,一种是公司扣完发给你,另一种是发给你之后你再掏出来一部分。大家感受一下这其中的区别。


心理账户


人们可能会将个税缴纳视作开销,而且是意外开销,意外开销总是让人痛苦的。


比如我每个月 1w 块,其中 3k 拿来租房,3k 拿来吃饭, 2k 拿来娱乐,2k 拿来缴五险一金。


这时候到年终汇算时,人们则容易苦不堪言。


且这种带来的直接后果是,我想把税留到最后一天交,同时最后一天也很容易忘记交,因为大脑也不想要这种意外支出。


最终则导致 漏交、拒交 个税的人数大大增加。


专项附加扣除严谨度



  • 子女教育(未婚,无接触)

  • 赡养老人(容易被查)

  • 继续教育 - 学历提升(基本不查)

    • 学历提升可以选择一个对应学历,每个学历 4 年,共 16 年左右抵税



  • 继续教育 - 证书获取(基本不查)

    • 证书获取有人一个证书可以一直抵税,建议: 营养师证、焊工证等



  • 租房买房(基本不查)

  • 大病医疗(未填过,未知)


开发


首先咱们先写个个税计算器的 class ,个人所得税英文简称 IIT (Individual Income Tas)


class IITCalulator {}

添加需要计算的内容


众所周知,

个税计算法:应缴税款 * 对应税率 - 速算扣除

应缴税款计算法:工资 - 五险一金缴纳额 - 专项附加扣除


因此我们先添加 工资 、 五险一金 、 专项附加扣除 的属性。


工资


我们工资有两个组成部分,分别是 固定工资 和 年终奖(如果有的话)。


class IITCalulator {
private salary: {
monthlySalary: number;
yearEnd: number;
} = {
monthlySalary: 0,
yearEnd: 0,
};

/**
* @description 添加工资(通过工资计算年薪)
*/

addSalary(
monthlySalary,
yearEnd?: { value: number; type: "month" | "amount" }
) {
this.salary.monthlySalary = monthlySalary;
if (yearEnd) {
this.salary.yearEnd =
yearEnd.type === "amount"
? yearEnd.value
: monthlySalary * yearEnd.value;
}
}
}

五险一金


这里直接给了固定金额,可以通过查看每月扣除得知。



考虑到有人不太清楚自己的五险一金缴纳基数,这里直接用了固定金额,后续可以扩展出通过缴纳比例自动计算



class IITCalulator {
private socialInsuranceMonthlyAmount = 0;

/**
* @description 添加五险一金,计算年五险一金缴纳额
* @param {number} monthlyAmount 月度缴纳金额
*/

addSocialInsurance(monthlyAmount) {
this.socialInsuranceMonthlyAmount = monthlyAmount;
}
}

专项附加扣除


专项附加扣除通过数组的方式存储扣除项。



  1. 子女教育

  2. 赡养老人

  3. 继续教育(学校)

  4. 继续教育(证书)

  5. 住房贷款

  6. 大病医疗


// 专项附加扣除类型
type SpecialDeductionType =
| "children"
| "elder"
| "education-school"
| "education-certificate"
| "housing"
| "medical";

class IITCalulator {
private specialDeductionTypes: Array<SpecialDeductionType> = [];
private medicalAmount = 0;

/**
* @description 添加专项附加扣除
* @param {string} type 专项附加扣除类型
*/

addSpecialDeduction(
SpecialDeductionType: SpecialDeductionType,
medicalAmount?: number
) {
this.specialDeductionTypes.some((t) => t !== SpecialDeductionType) &&
this.specialDeductionTypes.push(SpecialDeductionType);

if (medicalAmount) {
this.medicalAmount = medicalAmount;
}
}
}

计算 工资 、 五险一金 、 专项附加扣除


我们添加了基础属性,可以根据基础属性计算出对应金额。


工资


工资 = 月薪 * 12 + 年终奖


getYearSalary() {
return this.salary.monthlySalary * 12 + this.salary.yearEnd;
}

五险一金


五险一金 = 月缴纳额 * 12


getYearSocialInsurance() {
return this.socialInsuranceMonthlyAmount * 12;
}

专项附加扣除


专项附加扣除 = 扣除项的扣除金额合集



需要注意的是:大病扣除项是固定金额的



这里直接采用 reduce 进行累加。


/**
* @description 计算专项附加扣除
*/

private getSpecialDeduction() {
return this.specialDeductionTypes.reduce((r, v) => {
switch (v) {
case "children":
return r + 2000 * 12;
case "elder":
return r + 3000 * 12;
case "education-school":
return r + 400 * 12;
case "education-certificate":
return r + 3600;
case "housing":
return r + 1500 * 12;
case "medical":
return r + this.medicalAmount;
default:
return r;
}
}, 0);
}

计算纳税金额


我们基础数据都有了,就只差计算了。先通过基础数据计算应纳税所得额,再通过应纳税所得额计算个税。


计算应纳税所得额


calcIIT() {
// 计算年薪
const yearSalary = this.getYearSalary();
// 五险一金缴纳金额
const yearSocialInsurance = this.getYearSocialInsurance();
// 专项附加扣除金额
const specialDeduction = this.getSpecialDeduction();
// 计算需要缴纳个税的金额
let taxableAmount =
yearSalary - yearSocialInsurance - specialDeduction - 60000;
// 计算个税
return this.calcTaxableAmount(taxableAmount);
}

计算应缴个税


个税计算参考:


image.png


// 计算个税(金额 * 税率 - 速算扣除)
private calcTaxableAmount(taxableAmount: number) {
if (taxableAmount <= 36000) {
return taxableAmount * 0.03;
} else if (taxableAmount <= 144000) {
return taxableAmount * 0.1 - 2520;
} else if (taxableAmount <= 300000) {
return taxableAmount * 0.2 - 16920;
} else if (taxableAmount <= 420000) {
return taxableAmount * 0.25 - 31920;
} else if (taxableAmount <= 660000) {
return taxableAmount * 0.3 - 52920;
} else if (taxableAmount <= 960000) {
return taxableAmount * 0.35 - 85920;
} else {
return taxableAmount * 0.45 - 181920;
}
}

完整代码:


// 专项附加扣除类型
// 1. 子女教育
// 2. 赡养老人
// 3. 继续教育(学校)
// 4. 继续教育(证书)
// 5. 住房贷款
// 6. 大病医疗
type SpecialDeductionType =
| "children"
| "elder"
| "education-school"
| "education-certificate"
| "housing"
| "medical";

class IITCalculator {
private salary: {
monthlySalary: number;
yearEnd: number;
} = {
monthlySalary: 0,
yearEnd: 0,
};
private socialInsuranceMonthlyAmount = 0;

private specialDeductionTypes: Array<SpecialDeductionType> = [];
private medicalAmount = 0;

constructor() {}

/**
* @description 添加工资(通过工资计算年薪)
*/

addSalary(
monthlySalary,
yearEnd?: { value: number; type: "month" | "amount" }
) {
this.salary.monthlySalary = monthlySalary;
if (yearEnd) {
this.salary.yearEnd =
yearEnd.type === "amount"
? yearEnd.value
: monthlySalary * yearEnd.value;
}
}

getYearSalary() {
return this.salary.monthlySalary * 12 + this.salary.yearEnd;
}

/**
* @description 添加五险一金,计算年五险一金缴纳额
* @param {number} monthlyAmount 月度缴纳金额
*/

addSocialInsurance(monthlyAmount) {
this.socialInsuranceMonthlyAmount = monthlyAmount;
}

getYearSocialInsurance() {
return this.socialInsuranceMonthlyAmount * 12;
}

/**
* @description 添加专项附加扣除
* @param {string} type 专项附加扣除类型
*/

addSpecialDeduction(
SpecialDeductionType: SpecialDeductionType,
medicalAmount?: number
) {
this.specialDeductionTypes.some((t) => t !== SpecialDeductionType) &&
this.specialDeductionTypes.push(SpecialDeductionType);

if (medicalAmount) {
this.medicalAmount = medicalAmount;
}
}

/**
* @description 计算专项附加扣除
*/

private getSpecialDeduction() {
return this.specialDeductionTypes.reduce((r, v) => {
switch (v) {
case "children":
return r + 2000 * 12;
case "elder":
return r + 3000 * 12;
case "education-school":
return r + 400 * 12;
case "education-certificate":
return r + 3600;
case "housing":
return r + 1500 * 12;
case "medical":
return r + this.medicalAmount;
default:
return r;
}
}, 0);
}

calcIIT() {
// 计算年薪
const yearSalary = this.getYearSalary();
// 年终奖是否单独计税

// 五险一金缴纳金额
const yearSocialInsurance = this.getYearSocialInsurance();
// 专项附加扣除金额
const specialDeduction = this.getSpecialDeduction();
// 计算需要缴纳个税的金额
let taxableAmount =
yearSalary - yearSocialInsurance - specialDeduction - 60000;
// 计算个税
return this.calcTaxableAmount(taxableAmount);
}

// 计算个税(金额 * 税率 - 速算扣除)
private calcTaxableAmount(taxableAmount: number) {
if (taxableAmount <= 36000) {
return taxableAmount * 0.03;
} else if (taxableAmount <= 144000) {
return taxableAmount * 0.1 - 2520;
} else if (taxableAmount <= 300000) {
return taxableAmount * 0.2 - 16920;
} else if (taxableAmount <= 420000) {
return taxableAmount * 0.25 - 31920;
} else if (taxableAmount <= 660000) {
return taxableAmount * 0.3 - 52920;
} else if (taxableAmount <= 960000) {
return taxableAmount * 0.35 - 85920;
} else {
return taxableAmount * 0.45 - 181920;
}
}
}

最后


我最开始尝试写一个 UI 版。但后续感觉,UI 版对于不同语言的用户,会看起来很痛苦。

因此我通过纯 JS 实现,大家可以通过不同的 UI 调用该类,可以在各个框架中使用。

同时也通过 svelte 做了一个简略 UI 版,大家可以直接尝试。


最后,点赞、关注、收藏 ,祝大家多多退税~~


作者:sincenir
来源:juejin.cn/post/7342511044290789430
收起阅读 »

如果我贷款买一套 400W 的房子,我要给银行多送几辆迈巴赫?

买房攻略 2023 年至今,上海房价一跌再跌。俺已经蠢蠢欲动了,磨刀霍霍向"买房"。但是奈何手里钞票不够,只能向天再借 500 年打工赚钱。但是作为倔强的互联网打工人,想知道自己会被银行割多少韭菜。于是就写了个程序,用于计算我贷款买房需要多给银行还多少钱。这样...
继续阅读 »

买房攻略


2023 年至今,上海房价一跌再跌。俺已经蠢蠢欲动了,磨刀霍霍向"买房"。但是奈何手里钞票不够,只能向天再借 500 年打工赚钱。但是作为倔强的互联网打工人,想知道自己会被银行割多少韭菜。于是就写了个程序,用于计算我贷款买房需要多给银行还多少钱。这样我就能知道银行割我的韭菜,能省下几辆迈巴赫的钱了。


贷款利率



  • 公积金的贷款利率



    • 首房:贷款时间 <=5 年,利率为 2.6% ;贷款时间 >= 5 年,利率为 3.1%

    • 非首房:贷款时间 <=5 年,利率为 3.025% ;贷款时间 >= 5 年,利率为 3.575%




image.png



  • 商业险贷款利率



    • 贷款时间 <=5 年,利率为 3.45% ;贷款时间 >= 5 年,利率为 3.95%




image.png


代码实现



  • 以下代码,实现了:我贷款买房需要多给银行还多少钱


public class LoanAmountCalculation {

   //首套住房5年以内公积金贷款利率
   private static final double FIRST_HOUSE_ACCUMULATION_FUND_LOAN_RATE_WITHIN_FIVE_YEARS = 2.6;
   //首套住房5年以上公积金款利率
   private static final double FIRST_HOUSE_ACCUMULATION_FUND_LOAN_RATE_MORE_FIVE_YEARS = 3.1;
   //二房5年以内公积金贷款利率
   private static final double NOT_FIRST_HOUSE_ACCUMULATION_FUND_LOAN_RATE_WITHIN_FIVE_YEARS = 3.025;
   //二房5年以上公积金款利率
   private static final double NOT_FIRST_HOUSE_ACCUMULATION_FUND_LOAN_RATE_MORE_FIVE_YEARS = 3.575;
   //5年以内商业贷款利率
   private static final double COMMERCIAL_LOAN_RATE_WITHIN_FIVE_YEARS = 3.45;
   //5年以上商业贷款利率
   private static final double COMMERCIAL_LOAN_RATE_MORE_FIVE_YEARS = 3.95;

   public static void main(String[] args) {
       Scanner scanner = new Scanner(System.in);

       double houseAmount = getInputValue(scanner, "请输入预计买房金额(单位:W):", "请输出正确的买房金额(>0)!");
       double principal = getInputValue(scanner, "请输入您的本金(单位:W):", "请输出正确的买房金额(>0)!");
       if (principal >= houseAmount) {
           System.out.println("全款买房,崇拜大佬!");
           return;
      }

       double accumulationFundLoanAmount = getInputValue(scanner, "请输入公积金贷款金额(单位:W):", "请输出正确的公积金贷款金额(>0)!");

       double commercialLoanAmount = houseAmount - principal - accumulationFundLoanAmount;
       if(commercialLoanAmount <= 0){
           System.out.println("您的本金+公积金贷款已经够买房啦,恭喜大佬!");
           return;
      }else{
           System.out.println("您的本金+公积金贷款还不够买房哦,需要商业贷款金额为(单位:W):" + commercialLoanAmount + "\n");
      }

       int accumulationFundLoanYears = getInputIntValue(scanner, "请输入公积金贷款年份(单位:年):");
       int commercialLoanAmountYears = getInputIntValue(scanner, "请输入商业贷款年份(单位:年):");

       int isFirstHouse = getInputIntValue(scanner, "请输入是否首房(0:否,1:是):");

       LoanAmount loanAmount = calculateLoanAmount(
               accumulationFundLoanAmount, accumulationFundLoanYears,
               commercialLoanAmount, commercialLoanAmountYears, isFirstHouse);
       System.out.println("详细贷款信息如下:" + "\n" + loanAmount);
  }

   /**
    * 获取double类型的输入
    * @param scanner:Java输入类
    * @param prompt:提示信息
    * @param errorMessage:输入错误的提示信息
    * @return 一个double类型的输入
    */

   private static double getInputValue(Scanner scanner, String prompt, String errorMessage) {
       double value;
       while (true) {
           System.out.println(prompt);
           if (scanner.hasNextDouble()) {
               value = scanner.nextDouble();
               if (value > 0) {
                   break;
              } else {
                   System.out.println(errorMessage);
              }
          } else {
               scanner.next();
               System.out.println(errorMessage);
          }
      }
       return value;
  }

   /**
    * 获取int类型的输入
    * @param scanner:Java输入类
    * @param prompt:提示信息
    * @return 一个int类型的输入
    */

   private static int getInputIntValue(Scanner scanner, String prompt) {
       int value;
       while (true) {
           System.out.println(prompt);
           if (scanner.hasNextInt()) {
               value = scanner.nextInt();
               if (value > 0) {
                   break;
              } else {
                   System.out.println("请输入正确的年份(>0)!");
              }
          } else {
               scanner.next();
               System.out.println("请输入正确的年份(>0)!");
          }
      }
       return value;
  }

   /**
    * 功能:贷款金额计算
    * 入参:
    * 1.accumulationFundLoanAmount:公积金贷款金额 2.accumulationFundLoanYears:公积金贷款年份;
    * 3.commercialLoanAmount:商业贷款金额;       4.commercialLoanAmountYears:商业贷款年份
    * 5.isFirstHouse:是否首房
    */

   private static LoanAmount calculateLoanAmount(double accumulationFundLoanAmount, int accumulationFundLoanYears,
                                                          double commercialLoanAmount, int commercialLoanAmountYears, int isFirstHouse)
{
       LoanAmount loanAmount = new LoanAmount();
       //公积金贷款还款金额
       double accumulationFundRepaymentAmount;
       if(isFirstHouse == 1){
           accumulationFundRepaymentAmount = accumulationFundLoanYears <= 5 ?
                   accumulationFundLoanAmount * Math.pow((100 + FIRST_HOUSE_ACCUMULATION_FUND_LOAN_RATE_WITHIN_FIVE_YEARS) / 100, accumulationFundLoanYears)
                  : accumulationFundLoanAmount * Math.pow((100 + FIRST_HOUSE_ACCUMULATION_FUND_LOAN_RATE_MORE_FIVE_YEARS) / 100, accumulationFundLoanYears);
      }else{
           accumulationFundRepaymentAmount = accumulationFundLoanYears <= 5 ?
                   accumulationFundLoanAmount * Math.pow((100 + NOT_FIRST_HOUSE_ACCUMULATION_FUND_LOAN_RATE_WITHIN_FIVE_YEARS) / 100, accumulationFundLoanYears)
                  : accumulationFundLoanAmount * Math.pow((100 + NOT_FIRST_HOUSE_ACCUMULATION_FUND_LOAN_RATE_MORE_FIVE_YEARS) / 100, accumulationFundLoanYears);
      }
       loanAmount.setAccumulationFundRepaymentAmount(String.format("%.2f", accumulationFundRepaymentAmount));

       //公积金贷款每年还款金额
       loanAmount.setAccumulationFundAnnualRepaymentAmount(String.format("%.2f", accumulationFundRepaymentAmount / accumulationFundLoanYears));

       //商业贷款还款金额
       double commercialRepaymentAmount = commercialLoanAmountYears <= 5 ?
               commercialLoanAmount * Math.pow((100 + COMMERCIAL_LOAN_RATE_WITHIN_FIVE_YEARS) / 100, commercialLoanAmountYears)
              : commercialLoanAmount * Math.pow((100 + COMMERCIAL_LOAN_RATE_MORE_FIVE_YEARS) / 100, commercialLoanAmountYears);
       loanAmount.setCommercialRepaymentAmount(String.format("%.2f", commercialRepaymentAmount));

       //商业贷款每年还款金额
       loanAmount.setCommercialAnnualRepaymentAmount(String.format("%.2f", commercialRepaymentAmount / commercialLoanAmountYears));

       //公积金贷款超出金额
       loanAmount.setAccumulationFundLoanExceedAmount(String.format("%.2f", accumulationFundRepaymentAmount - accumulationFundLoanAmount));

       //商业贷款超出金额
       loanAmount.setCommercialLoanExceedAmount(String.format("%.2f", commercialRepaymentAmount - commercialLoanAmount));

       loanAmount.setTotalExceedLoanAmount(String.format("%.2f", accumulationFundRepaymentAmount - accumulationFundLoanAmount + commercialRepaymentAmount - commercialLoanAmount));
       return loanAmount;
  }
   @Data
   static class LoanAmount{
       /**
        * 公积金贷款还款金额
        */

       private String accumulationFundRepaymentAmount;
       /**
        * 公积金贷款每年还款金额
        */

       private String accumulationFundAnnualRepaymentAmount;
       /**
        * 商业贷款还款金额
        */

       private String commercialRepaymentAmount;
       /**
        * 商业贷款每年还款金额
        */

       private String commercialAnnualRepaymentAmount;
       /**
        * 公积金贷款超出金额 = 公积金贷款还款金额 - 公积金贷款金额
        */

       private String accumulationFundLoanExceedAmount;
       /**
        * 商业贷款超出金额 = 商业贷款还款金额 - 商业贷款金额
        */

       private String commercialLoanExceedAmount;

       /**
        * 总共贷款超出金额
        */

       private String totalExceedLoanAmount;

       @Override
       public String toString() {
           return "1.公积金贷款还款金额=" + accumulationFundRepaymentAmount + "万元\n" +
                   "2.商业贷款还款金额=" + commercialRepaymentAmount + "万元\n" +
                   "3.公积金贷款每年还款金额=" + accumulationFundAnnualRepaymentAmount + "万元\n" +
                   "4.商业贷款每年还款金额=" + commercialAnnualRepaymentAmount + "万元\n" +
                   "5.公积金贷款超出金额=" + accumulationFundLoanExceedAmount + "万元\n" +
                   "6.商业贷款超出金额=" + commercialLoanExceedAmount + "万元\n" +
                   "7.总共贷款超出金额=" + totalExceedLoanAmount + "万元\n";
      }
  }
}

代码输入,输出示例


6f9e90ab10c92d0a673777569a64f75.png


由上图可知,我要贷款买一套 400w 的房子,本金只有 120w,使用组合贷:公积金贷款 120w(10年),商业贷款 160w(20年)。最终我需要多还银行 230.07w,相当于买两辆迈巴赫的钱了,巨亏!


以上就是全部内容了,如果涉及到真实场景,还是需要根据具体的情况计算的!


作者:一只野生的八哥
来源:juejin.cn/post/7346385551366684722
收起阅读 »

用马斯克五步工作法重构支付宝商家账单

本文作者是蚂蚁集团数据研发工程师惠勒,将马斯克五步工作法应用在了实际项目中,实现了支付宝商家账单的重构,希望本文对想要降低系统复杂度的同学或者项目有所帮助。0. 概述支付宝中国数据团队在过去的一年里应用马斯克的五步工作法重构了有 10 年历史之久的支付宝商家账...
继续阅读 »

本文作者是蚂蚁集团数据研发工程师惠勒,将马斯克五步工作法应用在了实际项目中,实现了支付宝商家账单的重构,希望本文对想要降低系统复杂度的同学或者项目有所帮助。

0. 概述

支付宝中国数据团队在过去的一年里应用马斯克的五步工作法重构了有 10 年历史之久的支付宝商家账单,整体复杂度减少 60%,时效性提升 1 小时,计存成本降低 30%,理解和运维成本大幅下降。复杂度是很多问题的根源,既会增加运维的成本,又降低了支撑业务的效率。 账单重构的经验表明,相当大比例的复杂度是没有必要的,我们应该致力于把复杂的事情变简单,而不是倒过来做“防御性编程”。希望本文对想要降低系统复杂度的同学或者项目有所帮助。

1. 重构背景

1.1 什么是商家账单

商家通过支付宝发生业务,我们对他们提供相应的流水单或者凭证,这就是商家账单。商户可以到B站下载账单和他们自己的业务记录及资金变动期望逐一比对,确认所有业务和资金都按正确的期望的方式完成了处置,这个过程称为商家对账

支付宝目前提供了丰富账单类型,包括资金流水,交易订单,资产凭证,营销动账,费用账单以及一些列个性化定制账单。实现方式上则有在线实时账单以及基于 odps 的离线的日/月账单,其中在线账单主要用于业务查询,而离线账单则主要用于商家对账,本文所指商家账单主要指离线账单

图1:B站里的商家账单

1.2 为什么要重构

一句话概括:历时 10 年,积重难返

商家账单作为支付宝收单业务配套的基础产品,主要的服务对象是商家。和所有 To B 产品一样,其面临着“千人千面的个性化诉求和成本可控的快速支撑”的核心矛盾。在实现过程中,要么在原有逻辑上打个补丁,更多的时候是出于稳定性等因素考虑,不敢动原有的逻辑,于是就新起炉灶搞个新的字段。历时 10 年,资金流水账单搞出了上百个字段,很多字段的加工链路极其复杂。目前整个账单大概有几千个任务,近万的依赖关系,平均加工深度 20 多层,各种横向域之间的耦合,纵向层之间的调用层出不强,用一团乱麻来形容也不为过!

图 2:真实的账单血缘图

image.png

图 3:账单架构混乱的示意图

1.3 为什么是现在

主要是因为逻辑过于复杂,当前用于保障账单准确出账时效的成本已经过于高昂。

离线账单是拿去对账的,这就像有上百万商家拿着放大镜在找问题一样,不仅像金额,时间等字段不能有问题,各种订单号,门店 ID 等字段也偏差不得。而当前账单过于复杂,经常出现变更了这里漏了那里,或者是改了上游影响了好几层以外的下游。目前每年流转到二线研发同学的咨询就有几百例,一线外包和马力等同学接到的账单类问题更是以万计。

时效性方面的压力则有过之而无不及。由于需要对标竞对 T+1 10 点的出账时效,支付宝目前对客承诺 T+1 9 点出账,扣减掉在线账单文件生成和预留的异常处理时间,基本上要求离线账单需要 T+1 5 点 30 产出。作为蚂蚁唯二的两条最高级基线之一,运维同学承担了极大的压力,从 2023 年 9 月-12 月,运维同学在夜间共计响应 150+ 起电话告警,涉及天数 67 天,值班起夜比例为 67/122=54.9%。虽然引发起夜的因素有集群计算资源以及 odps 软件等外部因素,但根子上还是因为加工链路太长,给基线预留的余量不够。

为了彻底解决上述问题,我们决心重构支付宝商家账单,通过降低复杂度的方式,既提升用户体验又降低运维成本。

2. 重构目标

通过降低 50% 的复杂度,达到以下 5 点业务效果

  • 准确的

每个字段的含义是明确的,账单数据内部是一致的

  • 高时效的

    账单产出提前 1 小时
  • 好运维的

    重大问题能够快速一键重跑的(72h 降低到 12h 以内),日常的异常情况能够快速处理(1h以内),代码结构是好理解的(模块化的分层架构)
  • 易扩展的

    可扩展性强,对于各种业务需求的响应速度较快,不需要对代码逻辑大幅改动。有灰度环境的全链路回归链路,减少变更风险
  • 低成本的

    在保证回刷要求的前提下尽可能降低存储成本(降低 1/3 的存储成本),减少任务数量,降低计算成本(降低 1/3 的计算成本)

3. 应用五步工作法重构账单

马斯克在特斯拉和 spaceX 的成功经验告诉我们,应用五步工作法可以把复杂的事情变得简单,把高昂的成本打下来。所谓五步工作法,主要是

  1. 质疑,推敲需求,不要有愚蠢的需求;
  2. 删减,简化流程,精简部件或工艺流程;
  3. 优化,在前面两步的基础上做优化;
  4. 加速,在前三步的基础上加快迭代时间;
  5. 替换,在完成前四步之后做自动化替换。 商家账单的重构工作也或多或少借鉴了五步工作法。

3.1 质疑

第一步是质疑:为什么有那么多字段,为什么每个字段有那么多逻辑,为什么加工链路需要那么长。 带着这几个为什么,我们开始做字段梳理工作,核心工作是两项

  1. 梳理这些字段哪些是有人用的,哪些是没人用的。有人用的话有多少人在用,都是哪些商户
  2. 从末端表的字段出发,自下而上的梳理加工链路,穿透到最上游,看字段最终来源于哪些领域。

以最多商户使用的资金流水账单为例,上百个字段中仅有不到三分之一是核心字段,一半左右是个性化字段(使用商户数 100 以下),剩余大几十个都是无人使用字段;字段来源方面则集中在账务,交易,支付,计收费,结算,充转提等几个领域。从这些数字中我们得出以下两个观点

  1. 不需要那么多字段,可以先集中攻克核心字段
  2. 我们可以分域处理信息,再拼起来集中加工使用

3.2 删减

带着第一步质疑的观点,我们开始做删减,以核心字段为目标,落地如下架构设计 image.png

图4:重构的账单架构图

核心的工作有那么几项

  1. 把最终的一个对客账单字段,拆解为几个不同领域的字段加工。 如账单字段商户订单号,可以简化为如下规则:如果有交易号的话,则取交易号,否则使用账务域的外部流水号兜底。这样一来,一个账单字段就拆解为了一个交易域的字段和一个账务域的字段。对其余核心账单字段如法炮制,最终可以归到账务,交易,支付,计收费,结算,充转提等6-7个领域中去。
  2. 每个领域按照面向领域建模的方式进行中间层的构建,把需要的领域内的字段提前加工处理好
  3. 把(2)的结果拼接起来变成账单因子层宽表,再根据每个出账字段的加工规则,清洗出最后的账单字段
  4. 清洗出账规则,过滤(3)的结果,产出最终的日明细账单。日汇总,月账单等都基于日明细账单加工。

    特别需要注意的是,在这个阶段并不需要特别拘泥于细节,因为后面还会把删多的逻辑补回来,按照五步工作法的说法,如果最后没有补回来 10% 的逻辑,说明这个阶段删减的不够。

3.3 优化

在整个账单重构过程中,有几个难点我们专门提出来成立了专项进行优化

  1. 出账范围
  2. 商家账单中最基本的一个问题是给谁出账。老账单里起了好几十个任务在处理这个问题,经常会出现商户来问为什么没有出账,往往需要查半天才解释的清楚。重构时优化了该问题,明确了必须是签约了指定产品才能出账单,任务数相应减少到 10 个以下。
  3. 关联 jar 包

    商家账单中经常出现一笔昨日的流水需要关联多日之前的商品信息或者交易信息的诉求。这种跨天关联在离线odps的批处理框架下是比较麻烦且性价比很低的,在需要关联多日数据时面临着需要申请大量资源导致任务无法调起的问题。商家账单当前是使用一种jar包的方案来实现的,它的本质还是离线跨天关联,只是优化了并发逻辑,把一个大任务拆分成多个子任务发到 odps 跑。

    这次重构,我们提出离在线融合方案,利用在线可以笔笔查,性能好速度快的优势,使用 udf 调用在线http接口进行查询。考虑到在线查询可能会有失败的可能,对于失败的少数数据再用离线跨天关联的方式进行查漏补缺。

    目前这个方案还在研发中,预计可以大幅降低相关任务的计算成本,进一步提高出账的时效性。

  4. 离线灰度方案

    作为一个面客类产品,如何在离线实现像在线一样的变更三板斧从而减少对客影响,是一直困扰着所有离线同学的一个难题。本次重构中,我们做了一点尝试。我们的核心思想是:离线任务只跑一次但算两套值,并通过一个控制模块来控制哪些账号取原始值,哪些账号取灰度值。

    如下图所示,我们跑一次任务,把线上值记录在因子宽表的强字段收入金额和指出金额中,把灰度值记录在灰度扩展字段中,不同的值经过相同或者不同的加工规则,产出两个账单对客值净收入金额和灰度扩展字段中的净收入金额,最后通过一个控制模块来决定哪些账号要用灰度值。

    image.png

图5:离线灰度方案

  1. 稳定性自愈方案

    商家账单有几千个任务,但我们依赖的这套离线批处理的模式里又有很多不确定的因素:odps 的软件问题,底层计算集群的机器抖动,槽位占用,在线压制等,所以每个月总有那么几十个报错或者变慢的任务需要人工处理。在本次重构过程中,我们联合蚂蚁大数据部相关团队上线了报错自动重跑和变慢自愈恢复等两个稳定性自愈方案。

    报错自动重跑方案的核心是系统自动识别运行日志中的关键词,除非是明确不可重跑的报错(如数据质量问题,权限问题等),都会由调度系统拉起来重跑,实际运行过程中还需要综合考虑基线余量等要素。目前报错自动重跑方案每个月可以减少商家账单几十次的报错处理,减少 4-5 天的起夜值班。

    变慢自愈方案的核心思想是识别相关变慢任务并自动 copy 到双跑链路执行。若双跑任务执行期间原链路恢复,则不做处理;若双跑链路执行完成,原链路仍未完成,则杀死原链路任务,将双跑结果注入原表,将任务置成功。

图 6:变慢自愈方案

3.4 加速

在第二步删减模块我们只关注于核心字段的核心逻辑,一方面存在核心字段逻辑删多了的问题,另外一方面需要把其余个性化字段也补上。在第四步加速中,我们需要通过一定的方式开始回补,并且这种回补相比第二步而言要高效的多。

我们的办法是找一个牵引指标,小步快跑,快速迭代。当主逻辑搭建的差不多了以后尽快把脚本发布上线,并起一个新老账单对比任务,通过对比来发现新账单逻辑上存在的问题,对于缺失的部分快速补上。这里面的核心是要有一个牵引指标,在账单重构过程中,我们引入了商户可切流比例这样一个指标,计算公式如下

商户可切流比例=所有流水的所有字段都比对通过的商户数/总商户数*100%

以资金账单为例,商户可切流比例从第一版的 41% 经过大概 10 次迭代上升到了 85%,后又经过一段时间的精细化调整,目前为 99.3%。在这个过程中,我们一方面修复了代码中的 bug,另外也基本上把删多了的有用逻辑进行了回补。这种目标驱动的针对性查漏补缺的做法相比第二步的正向推进要高效的多。

图 7:资金账单的迭代次数和商户可切流比例

3.5 替换

五步工作法的最后一步是自动化替换人工,在账单场景中我们姑且取替换之意。在商户可切流比例高于 95%,且新账单的时效性等问题基本优化完全之后,我们就开启了新老账单的替换工作。优先切换核对通过且经常有下载使用的商户,这样做一方面可以得到商户的反馈,另一方面不因为长尾的逻辑优化影响切流。

4. 重构效果

重构的效果总的来说是满足预期的。以下为几个方面的效果

  • 复杂度

我们用任务数来衡量复杂度,资金流水账单的复杂度下降了 60% 以上,交易订单的复杂度也下降了47%

  • 时效性

资金流水账单时效性较老账单提升 1.5 小时,交易订单提升 1 小时

  • 成本

    存储和计算成本较老账单下降 1/3 左右,每年节省上百万的计存成本

  • 准确性

汇总,月,历史等账单均从日明细加工而得,不再会有内部不统一的问题

  • 运维/理解成本

代码耦合度大幅降低,账单整体的理解成本从半年到1年下降到 1 个月左右

5. 总结反思

站在现在这个时间点,我们认为有那么几点是值得总结的

1) 复杂度是各种问题的源泉

商家账单的各种准确性,时效性以及高可用问题,归根到底是因为业务逻辑过多,架构腐化,导致整体复杂度急剧飙升,造成今日想改也改不动,想维持也维持不了的尴尬局面。我们必须在日常迭代中高度重视复杂度控制问题,不图一时之快,尽量不给后人留坑。

2) 很多复杂度是没有必要的

账单重构的经验表明,对于一个发展了多年的系统,很多复杂度是没有必要的。今日之所以可以降低复杂度,一方面是因为过去很多逻辑现在已经失效了,另一方面是因为后人对于业务的理解有了新的认知,可以用新的方法来复现来重做相关功能。

复杂度的降低带来的好处是方方面面的,就商家账单而言,最直观的就是时效性的提升,从而带来基线稳定性的提升,降低起夜压力。其次复杂度的减少降低了运维和编码成本,可以进一步减少准确性问题。当然,用现在流行的话讲,这不是一种“防御性编程”,不再需要半年到1年的时间才能熟悉账单的工作,一个略有经验的同学,可能1个月左右就能上手账单业务。那是否要担心因此工作就会被替代呢?我们想是没有必要杞人忧天的,如果一个工作要通过刻意把事情变复杂才能形成壁垒和核心竞争力,那么这样的工作是不值得为之奉献的。

3) 拆解事情很重要,节奏感更重要

重构商家账单是一件有些复杂的事情,面对这样一团乱麻般的代码,从何处下手,要拆解出哪几件事情来,每件事件的交付物应该是什么,这样的拆解固然很重要。但更重要的是节奏感的把握,同样是做这些事情,哪个阶段先重点做什么工作,是细致做还是粗略做,这种节奏感的把握更为重要。因为如果节奏不对,就会在某个阶段发现事情无法快速推进下去,时间一久就会受到一线同学以及主管等质疑。要是节奏对了,每个阶段都能看到一些希望,那么一件复杂的事情便会推行的比较顺利。

4) 需要进一步降低重构这件事的成本

尽管如此,我们还是耗费了几百人日来做账单的重构。我们有那么多的场景值得重构,整个社会上也有非常多的公司有这种重构降本增效的诉求。是否有可能把重构的过程流程化,甚至是产品化,从而大幅降低重构这件事的成本?这是重构这件事给我们的遗留命题。

5) 数仓同学未来的两个发展方向

在转岗到支付宝数据部门的时候,有一位高年级的同学曾经问我如何看待数仓同学的上升空间/发展路径问题。经过这一年多在商家账单的一线工作,尤其是这大半年来专职投入重构工作的经历,我想可能有如下两个方向

a) 专业的数据技术专家

数据技术专家主要专注于通过代码优化,架构优化等方法,降低一套数仓任务的复杂度,获取时效,准确,计存成本等方面的收益。商家账单重构就是典型这类场景,这个发展方向的价值收益比较好衡量。未来的核心竞争力在于是否可以借助AI的力量把重构优化这件事的成本降低,提升效率。

b) 全局的数据架构师

全局的数据架构师更关注的是信息架构的问题,要解决的是数据生产者和数据消费者之间的信息差问题。我们常常可以听到业务同学抱怨数据不准,不好用,听到算法同学说没有优质的数据供给。殊不知其实要做一份好的数据资产其实是有比较高的门槛,需要对业务,架构,信息流转的方式等都有比较深入的理解,才有可能做出一份好的数据。但在实践中我们发现,造成这种门槛的一个重要原因是因为作为数据生产者的系统研发同学并不了解作为数据消费者的数仓同学的痛点,有些问题其实在数据生产者略作改动就可以给数据消费者减少极大的成本。数据架构师就需要致力于解决这样的问题。我们很难具象的衡量这样的改动带来的收益,但可以肯定的是这些细小的改动会润物细无声的降低做一份好的数据资产的门槛,进而真正的发挥数据要素乘数效应,助力业务发展。


作者:支付宝体验科技
来源:juejin.cn/post/7347912334700789779
收起阅读 »

答应我,在vue中不要滥用watch好吗?

web
前言 上周五晚上8点,开开心心的等着产品验收完毕后就可以顺利上线。结果产品突然找到我说要加需求,并且维护这一块业务的同事已经下班走了,所以只有我来做。虽然内心一万头草泥马在狂奔,但是嘴里还是一口答应没问题。由于这一块业务很复杂并且我也不熟悉,加上还饿着肚子,在...
继续阅读 »

前言


上周五晚上8点,开开心心的等着产品验收完毕后就可以顺利上线。结果产品突然找到我说要加需求,并且维护这一块业务的同事已经下班走了,所以只有我来做。虽然内心一万头草泥马在狂奔,但是嘴里还是一口答应没问题。由于这一块业务很复杂并且我也不熟悉,加上还饿着肚子,在梳理代码逻辑的时候我差点崩溃了。需要修改的那个vue文件有几千行代码,迭代业务对应的ref变量有10多个watch。我光是梳理这些watch的逻辑就搞了很久,然后小心翼翼的在原有代码上面加上新的业务逻辑,不敢去修改原有逻辑(担心搞出线上bug背锅)。


滥用watch带来的问题


首先我们来看一个例子:


<template>
{{ dataList }}
</template>

<script setup lang="ts">
import { ref, watch } from "vue";

const dataList = ref([]);
const props = defineProps(["disableList", "type", "id"]);
watch(
() => props.disableList,
() => {
// 根据disableList逻辑很复杂同步计算出新list
const newList = getListFromDisabledList(dataList.value);
dataList.value = newList;
},
{ deep: true }
);
watch(
() => props.type,
() => {
// 根据type逻辑很复杂同步计算出新list
const newList = getListFromType(dataList.value);
dataList.value = newList;
}
);
watch(
() => props.id,
() => {
// 从服务端获取dataList
fetchDataList();
},
{ immediate: true }
);
</script>

上面这个例子在template中渲染了dataList,当props.id更新时和初始化时从服务端异步获取dataList。当props.disableListprops.type更新时,同步的计算出新的dataList。


代码逻辑流程图是这样的:


bad-code.png


乍一看上面的代码没什么问题,但是当一个不熟悉这一块业务的新同学接手这一块代码时问题就出来了。


我们平时接手一个不熟悉的业务首先要找一个切入点,对于前端业务,切入点肯定是浏览器渲染的页面。在 Vue 中,页面由模板渲染而来,找到模板中使用的响应式变量和他的来源,就能理解业务逻辑。以 dataList 变量为例,梳理dataList的来源基本就可以理清业务逻辑。


在我们上面的这个例子dataList的来源就是发散的,有很多个来源。首先是watchprops.id从服务端异步获取。然后是watchprops.disableListprops.type,同步更新了dataList。这个时候一个不熟悉业务的同学接到产品需求要更新dataList的取值逻辑,他需要先熟悉dataList多个来源的取值逻辑,熟悉完逻辑后再分析我到底应该是在哪个watch上面去修改业务逻辑完成产品需求。


但是实际上我们维护别人的代码时(特别是很复杂的代码)一般都不愿意去改代码,而是在原有代码的基础上再去加上我们的代码。因为去改别人的复杂代码很容易搞出线上bug,然后背锅。所以在这里我们的做法一般都是再加一个watch,然后在这个watch中去实现产品最新的dataList业务逻辑。


watch(
() => props.xxx,
() => {
// 加上产品最新的业务逻辑
const newList = getListFromXxx(dataList.value);
dataList.value = newList;
}
);

迭代几次业务后这个vue文件里面就变成了一堆watch,屎山代码就是这样形成的。当然不排除有的情况是故意这样写的,为的就是稳定自己在团队里面的地位,因为离开了你这坨代码没人敢动。


关注公众号:前端欧阳,解锁我更多vue干货文章,并且可以免费向我咨询vue相关问题。


使用computed解决问题


我们看了上面的反例,那么一个易维护的代码是怎么样的呢?我认为应该是下面这样的:


line.png


dataListtemplate中渲染,然后同步更新dataList,最后异步从服务端异步获取dataList,整个过程能够被穿成一条线。此时新来一位同学要去迭代dataList相关的业务,那么他只需要搞清楚产品的最新需求是应该在同步阶段去修改代码还是异步阶段去修改代码,然后在对应的阶段去加上对应的最新代码即可。


我们来看看上面的例子应该怎么优化成易维护的代码,上面的代码中dataList来源主要分为同步来源和异步来源。异步来源这一块我们没法改,因为从业务上来看props.id更新后必须要从服务端获取最新的dataList。我们可以将同步来源的代码全部摞到computed中。优化后的代码如下:


<template>
{{ renderDataList }}
</template>

<script setup lang="ts">
import { ref, computed, watch } from "vue";

const props = defineProps(["disableList", "type", "id"]);
const dataList = ref([]);

const renderDataList = computed(() => {
// 根据disableList计算出list
const newDataList = getListFromDisabledList(dataList.value);
// 根据type计算出list
return getListFromType(newDataList);
});

watch(
() => props.id,
() => {
// 从服务端获取dataList
fetchDataList();
},
{
immediate: true,
}
);
</script>

我们在template中渲染的不再是dataList变量,而是renderDataListrenderDataList是一个computed,在这个computed中包含了所有dataList同步相关的逻辑。代码逻辑流程图是这样的:


good-code.png


此时一位新同学接到产品需求要迭代dataList相关的业务,因为我们的整个业务逻辑已经变成了一条线,新同学就可以很快的梳理清楚业务逻辑。再根据产品的需求看到底应该是修改同步相关的逻辑还是异步相关的逻辑。下面这个是修改同步逻辑的demo:


const renderDataList = computed(() => {
// 加上产品最新的业务逻辑
const xxxList = getListFromXxx(dataList.value);
// 根据disableList计算出list
const newDataList = getListFromDisabledList(xxxList);
// 根据type计算出list
return getListFromType(newDataList);
});

总结


这篇文章介绍了watch主要分为两种使用场景,一种是当watch的值改变后需要同步更新渲染的dataList,另外一种是当watch的值改变后需要异步从服务端获取要渲染的dataList。如果不管同步还是异步都一股脑的将所有代码都写在watch中,那么后续接手的维护者要梳理dataList相关的逻辑就会非常痛苦。因为到处都是watch在更新dataList的值,完全不知道应该在哪个watch中去加上最新的业务逻辑,这种时候我们一般就会再新加一个watch然后在新的watch中去实现最新的业务逻辑,时间久了代码中就变成了一堆watch,维护性就变得越来越差。我们给出的优化方案是将那些同步更新dataListwatch代码全部摞到一个名为renderDataListcomputed,后续维护者只需要判断新的业务如果是同步更新dataList,那么就将新的业务逻辑写在computed中。如果是要异步更新dataList,那么就将新的业务逻辑写在watch中。


作者:前端欧阳
来源:juejin.cn/post/7340573783744102435
收起阅读 »

H5、小程序商品加入购物车的抛物线动画如何实现

web
H5、小程序商品加入购物车的抛物线动画如何实现 电商类 H5、小程序把商品加入到购物车时,常常有一个抛物线动画。比如麦当劳小程序,当你点击加购按钮时,会看到有一个小汉堡从卡片汉堡上抛出,然后掉落到购物袋里。 这种动画该怎么做呢?如果你也想实现它,看完这篇文章...
继续阅读 »

H5、小程序商品加入购物车的抛物线动画如何实现


电商类 H5、小程序把商品加入到购物车时,常常有一个抛物线动画。比如麦当劳小程序,当你点击加购按钮时,会看到有一个小汉堡从卡片汉堡上抛出,然后掉落到购物袋里。


mcdonald's.gif


这种动画该怎么做呢?如果你也想实现它,看完这篇文章,你一定有所收获。我会先说明抛物线动画的原理,再解释实现它的关键代码,最后给出完整的代码示例。代码效果如下:


parabola.gif


拳打 H5,脚踢小程序。我是「小霖家的混江龙」,关注我,带你了解更多实用的前端武学。


抛物线动画的原理


高中物理告诉我们,平抛运动、斜抛运动可以分解为水平方向的匀速直线运动、竖直方向自由落体运动(匀加速直线运动)。


principle.png


同理,我们可以把抛物线动画分解为水平的匀速动画、竖直的匀加速动画。


水平匀速动画很容易实现,直接 animation-timing-function 取值 linear 就行。


竖直的匀加速直线运动,严格实现非常困难,我们可以近似实现。因为匀加速直线运动,速度是越来越快的,所以我们可以用一个先慢后快的动画替代,你可能立刻就想到给 animation-timing-function 设置 ease-in。不过 ease-in 先慢后快的效果不是很明显。针对这个问题,张鑫旭大佬提供了一个贝塞尔曲线 cubic-bezier(0.55, 0, 0.85, 0.36);1。当然,你也可以用 cubic-bezier 自己调一个先慢后快的贝塞尔曲线。


关键代码实现


我们把代码分为两部分,第一部分是布局代码、第二部分是动画代码。


布局代码


首先是 HTML 代码,代码非常简单。下图中小球代表商品、长方形代表购物车。


ball-and-cart.png


<div class="ball-box">
<div class="ball"></div>
</div>
<div class="cart"></div>

你可能比较好奇,小球用一个 ball 元素就可以实现,为什么我要用 ball 和 ball-box 两个元素呢?因为 animation 只能给一个元素定义一个动画效果,而我们需要给小球添加两个动画效果。于是我们将动画分解,给 ball-box 添加水平运动的动画,给 ball 添加竖直运动的动画。


动画代码


再看动画代码,moveX 是水平运动动画,moveY 是竖直动画,动画时间均为 1s。为了让效果更加明显,我还特意将动画设置成无限循环的动画。


.ball-box {
/* ... */
animation: moveX 1s linear infinite;
}

.ball {
/* ... */
animation: moveY 1s cubic-bezier(0.55, 0, 0.85, 0.36) infinite;
}

@keyframes moveX {
to {
transform: translateX(-250px);
}
}

@keyframes moveY {
to {
transform: translateY(250px);
}
}

代码示例



总结


本文我们介绍了抛物线动画的实现方法,我们可以将抛物线动画拆分为水平匀速直线动画和竖直从慢变快的动画,水平动画我们可以使用 linear 来实现,竖直动画我们可以使用一个先慢后快的贝塞尔曲线替代。设置动画时,我们还需要注意,一个元素只能设置一个动画。


拳打 H5,脚踢小程序。我是「小霖家的混江龙」,关注我,带你了解更多实用的前端武学。


Footnotes




作者:小霖家的混江龙
来源:juejin.cn/post/7331607384933220390
收起阅读 »

面试官:在连续请求过程中,如何取消上次的请求?

web
前言 这个问题想必很多朋友都遇到过,我再详细说一下场景! 如 Boss 搜索框所示: 先输入1 再输入2 再输入3 再输入123  请求参数依次为:1 12 123 123123 请求参数通过右侧的 query 参数也可以看到,一共请求了...
继续阅读 »

前言


这个问题想必很多朋友都遇到过,我再详细说一下场景!


如 Boss 搜索框所示:




先输入1




再输入2




再输入3




再输入123 




请求参数依次为:1 12 123 123123



请求参数通过右侧的 query 参数也可以看到,一共请求了四次。


不难发现,这里已经做了基本的防抖,因为我们连续输入123的时候,只发了一次请求。


好了,现在看完基本场景,我们回到正题!


从上面的演示中不难发现我们一共发送了4次请求,顺序依次为1、12、123、123123。


问题


面试官现在问题如下:



我先输入的 1,已经发送请求了,紧接着输入了 2,3,123,如果在我输入最后一次 123 的时候,我第一次输入的 1 还没有请求成功,那请求 query 为 1 的这个接口将会覆盖 query 为 123123 的搜索结果,因为当 1 成功的时候会将最后一次请求的结果覆盖掉,当然这个概率很小很小,现在就这个bug,说一下你的解决思路吧!



解决


看到这个问题我们首先应该思考的是如何保证后面的请求不被前面的请求覆盖掉,首先说一下防抖是不行的,防抖只是对连续输入做了处理,并不能解决这个问题,上面的演示当中应该不难发现。


如何保证后面的请求不被前面的请求覆盖掉?


我们思路是否可以转化为:只需要保证后面的每次接口请求都是最新的即可?


简单粗暴一点就是,我们后续请求接口时直接把前面的请求干掉即可!


那如何在后续请求时,直接干掉之前的请求?


关键:使用 AbortController


MDN 解释如下:



AbortController 接口表示一个控制器对象,允许你根据需要中止一个或多个 Web 请求。


AbortController.abort(),中止一个 尚未完成 的 Web(网络)请求。



MDN 文档如下:



AbortController - Web API 接口参考 | MDN (mozilla.org)



我们可以借助 AbortController 直接终止还 未完成 的接口请求,注意这里说的是还未完成的接口,如果接口已经请求成功就没必要终止了。


代码实现


参考代码如下:


    let currentAbortController = null;
function fetchData(query) {
// 取消上一次未完成的请求
if (currentAbortController) {
currentAbortController.abort();
}

// 创建新的 AbortController
currentAbortController = new AbortController();

return fetch(`/api/search?q=${query}`, {
signal: currentAbortController.signal
})
.then(response => response.json())
.then(data => {
// 处理请求成功的数据
updateDropdownList(data);
})
.catch(error => {
// 只有在请求未被取消的情况下处理错误
if (!error.name === 'AbortError') {
handleError(error);
}
});
}

借用官方的解释:



当 fetch 请求初始化时,我们将 AbortSignal 作为一个选项传递进入请求的选项对象中(下面的 {signal: currentAbortController.signal})。这将 signal 和 controller 与 fetch 请求相关联,并且允许我们通过调用 AbortController.abort() 去中止它!



这就意味着我们将 signal 作为参数进行传递,当我们调用 currentRequest.abort() 时就可以终止还未完成的接口请求,从而达到我们的需要。


我们在每次重新调用这个接口时,判断是否存在 AbortController 实例,如果存在直接中止掉该实例即可,这样就可以保证我们每次的请求都可以拿到最新的数据。


    if (currentAbortController) {
currentAbortController.abort();
}

总结


我们再来理一下这个逻辑:


首先是第一次调用时为接口请求添加 AbortSignal 参数


之后在每次进入都判断是否存在 AbortController 实例,有的话直接取消掉


取消只会针对还未完成的请求,已经完成的不会取消


通过这样就可以达到我们每次都会使用最新的请求接口作为数据来源,因为后面的接口会将前面的干掉


如果这道面试题这样回答,是不是还不错?


作者:JacksonChen
来源:juejin.cn/post/7347395265836924938
收起阅读 »

10 天的开发量,老板让我 1 天完成,怎么办?

大家好,我是树哥! 昨天,我在文章《业务开发做到零 bug 有多难?》和大家聊了下影响零 bug 的一些因素。其中,我提到了开发时被压缩工时,应该怎么做。今天,我们就来聊聊这个话题。 只要工作过几年的小伙伴,必然会遇到过背压工时的情况。面对这种情况,不同的工作...
继续阅读 »

大家好,我是树哥!


昨天,我在文章《业务开发做到零 bug 有多难?》和大家聊了下影响零 bug 的一些因素。其中,我提到了开发时被压缩工时,应该怎么做。今天,我们就来聊聊这个话题。


只要工作过几年的小伙伴,必然会遇到过背压工时的情况。面对这种情况,不同的工作年限、在不同的公司、不同的团队氛围下,都会有不同的反应。如果你是一个刚刚毕业的萌新开发,很大情况下你会选择自己加班服从。甚至加班都完不成的情况下,你还吭哧吭哧不出声。


最后等待你的结果就是 —— 成为被复盘的对象,被批评。那么如果遇到了开发时间被压缩,或者被质疑的情况下,我们除了默默加班接受之外,还能做些什么来让自己没那么苦逼吗?


在我看来,自己一个人傻傻加班是下下签,是最后实在没办法才做的无奈之举。一旦有其他选择,你都不应该提出自己加班加点做完。那么,到底有什么办法可以解决工时被压缩这一问题呢?


解释工时构成


如果你的开发时间被压缩,那么较大可能是 leader 质疑你评估出的工时。假设你的工时评估并没有问题,那么就是你考虑到了一些风险点,而你的 leader 并没有考虑到。毕竟这也很正常,对于一个很久没有写代码的管理者来说,其会习惯性地忽略一些细节性的东西。


这个时候,你要做的不是胆怯地接受。而是要主动去找 leader ,跟他解释工时是怎么评估出来的。你考虑到了某些风险点,为什么是这么多工时。如果你的 leader 不是傻子,那么相信他会接受你的解释。但这里要注意的是,解释的时候记得要语气好些,不要怒气冲冲地找别人,不然话没说然就吵起来了。


减少需求内容


假设你和 leader 已经进行了友好地沟通, leader 也认可了你的评估时间。但是他说:没办法,老板就要求那个时间点做完,没办法给你更多时间了!


这时候,萌新小白就会老老实实回去座位上加班,最后还是干不完被批斗。但对于职场老油条来说,他就学会与 leader 以及产品沟通 —— 能不能少点需求内容。例如:我们要做一个员工列表,那是不是只做列表就可以,不用做筛选和搜索了?员工详情是不是也可以先不走了?


老板可以指定最终完成的时间,但是他基本不会干涉到具体的细节上面。这时候就给我们留下了沟通的空间,这也就是作为开发的你可以争取的东西。对于一个有经验的产品经理来说,如果研发给他提出了减少非核心功能的诉求,他一般也会答应的。


申请更多资源


如果产品说:不行,我们每个功能点都得做,一点需求都少不了!


这时候你可以再向你的老板提出诉求 —— 申请更多资源。


前面你也解释过工时的构成,做这么多功能确实需要这么多时间。如果最终上线时间不能推迟,那么就只能投入更多的资源了。


在这种情况下,如果公司还有富裕的研发资源,那自然会优先考虑你这边的诉求。对于你来说,你的研发压力也自然变小了。


分摊开发压力


如果实在又申请不到更多资源,这个项目又只能由你们团队 5 个人来完成,怎么办?


很多时候,不同开发人员的开发压力不一样。可能你开发压力比较大,其他人开发压力比较小,这时候你可以提出 —— 是否可以让其他小伙伴帮忙做点工作,这样可以减少一些压力?


我想,如果你的 leader 也应该会考虑你的诉求。千万不要自己明明完成不了,还要硬抗。到最后加班干了几个星期,需求还是完成不了,不仅辛苦的付出得不到理解,还被批斗。那可就真的是赔了夫人又折兵啊!


千万不要觉得这种情况不会发生,在我去年工作的时候,就发生了这样一个事情,我也是很同情那位同学的。如果那位同学能看到这篇文章,那么或许他后面就不会踩坑了吧。


推迟上线时间


上面说得是最终上线时间无法变更的情况,但很多时候并没有这种倒排需求。很多需求的上线时间并不是一成不变的,你只要给出足够合理的解释,也都是可以沟通的。


因此,如果在上面的沟通方法都行不通的情况下,你也可以沟通看看是否可以推迟上线时间。毕竟相对于研发速度来说,研发质量肯定更加重要。


终极绝招


大多数情况下,如果你能合理应用上面提到的几种沟通方式,被压缩工时的问题一般都能解决。但有些小伙伴会问:那如果真的所有办法都失效了呢?那怎么办?


其实,大多数情况下,不太可能到了需要使用绝招的地步。但如果真的到了这一步,那你就做好「殊死一搏」的准备,用上这个绝招吧 —— 调预期、表态度。


调预期,就是给你的 leader 打预防针,提前告诉他这样做的后果就是 —— 质量差、很难做得完。如果他还是这么坚定地推进,那么如果真的做不完,相信他也理解,不会太过于责怪你。


表态度,就是得加加班。如果你之前已经说了压力很大,甚至加班都做不完。那么你至少还是得表表态度,不能像往常一样早早下班,这样即使最后搞砸了。由于你态度还算端正,还不至于被责怪得太狠。但如果你要是又说做不完,又每天早早下班,那别人就觉得是你态度问题了。


走到这一步,实属是无奈,但这也是最后的保命之举了,除非你不想在这干了。


总结


今天分享了几种沟通解决「被压缩工时」的方法,包括:



  • 解释工时构成

  • 减少需求内容

  • 申请更多资源

  • 分摊开发压力

  • 推迟上线时间


本质上来说,就是不要自己一个人傻傻地抗压力,不要让自己背负着太大压力。我们要明白自己能做到什么程度,而且不要早早把「自己加班」这一最后的保命、卖惨利器祭出。他应该是自己的保命技能,而不是为别人锦上添花的技能。


特别是,不要因为赶进度、赶工时,而去牺牲开发质量。因为如果你这么做了,后果就是你付出了很多时间和精力,最后你会在项目复盘会上检讨 —— 为什么你的功能代码质量这么差。这是另一个话题了,后续有时间我们继续聊。


希望大家都能够活学活用,下次在和 leader 以及产品沟通的时候,用上这些沟通技巧吧!希望大家都不要加班,准时下班!


如果你觉得今天的文章对你有帮助,欢迎点赞转发评论支持树哥,你的支持对于我很重要,感谢大家!


作者:树哥聊编程
来源:juejin.cn/post/7348289379055140903
收起阅读 »

业务开发做到零 bug 有多难?

大家好,我是树哥,好久不见啦。作为一个工作了 10 多年的开发,写业务代码总是写了不少的。但你想过做到零 bug 吗?我可是想过的,毕竟我还是有点追求的。不然每天都是浑浑噩噩地过,多没意思啊。大概在一年多前,我给自己立下一个目标 —— 尽量将自己经手的业务需求...
继续阅读 »

大家好,我是树哥,好久不见啦。

作为一个工作了 10 多年的开发,写业务代码总是写了不少的。但你想过做到零 bug 吗?我可是想过的,毕竟我还是有点追求的。不然每天都是浑浑噩噩地过,多没意思啊。

大概在一年多前,我给自己立下一个目标 —— 尽量将自己经手的业务需求做到零 bug。不试不知道,一试吓一跳,原来零 bug 还真的还不容易。今天,树哥就跟大家分享关于「业务开发零 bug」的一些思考。

要做到业务开发零 bug,其实挺难的。这涉及到非常多方面,有些方面可能还不只是你能控制的,例如:产品 PRD 详尽程度,产研组织的稳定性等等。经过一段时间的思考与摸索,我自己总结出一些影响因素,分别是:

  1. 产品需求文档的清晰程度
  2. 需求的复杂程度
  3. 开发人员的细心程度
  4. 开发人员是否详细自测过
  5. 开发人员对项目的熟悉程度
  6. 开发人员开发时间是否充足

针对上面说到的影响因素,我们一个个详细聊聊。

需求文档清晰程度

对于研发、测试人员来说,他们获取信息的源头就是产品的 PRD 文档。因此,需求文档是否写得清晰、明确,就显得非常重要。

如果产品自己对功能都不了解,那么输出的需求文档肯定「缺斤少两」,到时候就是边开发边补充需求,甚至是在测试过程中补充需求。遇到这种情况,想要做到零 bug 真的非常难。

因此,清晰明确的需求文档,是我们实现业务开发零 bug 的重要前提。如果这个前提保证不了,那要做到零 bug 真的很难。毕竟想做成啥样都不知道,程序员又不是神仙,咋能猜出你想要什么。但这块内容,更多是对于产品人员专业能力的要求,开发人员无法控制。

在一些公司,会再需求评审之前先对需求文档进行一次初审,筛除那些有明显重大问题的需求,这样可以减少一部分劣质需求。

但初审的作用还是有限的,它没办法对功能的细节做较多的判断。很多时候恰恰就是一些功能细节的缺失,导致了一些 bug 的诞生。

需求的复杂程度

需求的复杂程度,对于实现业务开发零 bug 也有很大的影响。举个简单地例子:一个改文案的需求,和一个完全重新做的功能。

这样的两个需求,其复杂程度差别很大,肯定是改文案的需求实现业务开发零 bug 的难度低很多。对于一个完全重新做的功能,要做到完全零 bug,对于开发人员的要求非常高。

对于越复杂的项目,零 bug 的可能性就越低。因此,很多项目为了追求产出功能的高质量,会采用将功能点拆得非常细的方式,来减少单个需求的复杂度。

笔者公司在去年做过这个尝试,确实是可以较大地提高产出功能的质量。

细心程度

前面说到需求文档的清晰程度很重要,这取决于产品人员对于业务的理解程度,以及对于对于功能的熟悉程度。开发人员的细心,就像是一个质检关卡一样,在开发之前就对产品的需求内容进行详尽的思考与提问。

对于粗心的开发人员来说,其可能不看需求文档就直接参加需求评审,等到开发的时候边写代码边看需求文档,其写得代码也是一边熟悉需求一边改。这样写出来的系统功能是比较差的,没有一个统一、全局的设计与思考,很容易在细节处发生问题。

一个细心的开发人员,其会在评审之前就详细阅读需求文档,甚至会前前后后翻阅好几次。他甚至会逐字逐句地阅读,弄懂每个文字、句子的意思,甚至有时候会让你觉得他是在玩文字游戏(但不得不说,确实有必要细致一些)。

最后会联系上下文思考功能的合理性。如果发现一些不合理的地方,他会积极与产品沟通反馈,以确保其对于需求的理解,与产品经理对于需求的理解是一致的。

通过对比,我们知道细心的开发人员对于产品经理来说,是一个莫大的帮助,可以帮助他查漏补缺,让其对于功能的考虑更加细致、严谨。

这里的开发人员不仅仅指的是后端开发人员,也包括前端开发、移动端开发,他们都会从不同角度提出问题。

对于后端开发人员来说,他们可能会提出性能问题。对于前端开发以及移动端开发同学,他们可能会提出交互问题、样式统一等问题。

简单地说,细心的开发人员可以弥补需求文档的缺陷,从而让大家对于需求的理解更趋于一致,从而减少 bug 的发生。因此,开发人员的细心程度也是决定业务开发能否实现零 bug 的关键因素!

是否详细自测过

即使写过 10 多年代码的开发人员,刷 Leetcode 也不敢说 bug free 一把过,对于更加复杂的业务代码更是如此。因此,要做到业务开发零 bug,其中一个很重要的操作便是 —— 自测。

自测可以帮你再次检查可能出现的问题,从而提高零 bug 的概率。对于我而言,我习惯性在自测的时候再次对照一遍需求文档,从而避免自己遗漏一些功能的细节点。

对于自测而言,业界有很多种自测方法,包括:单测、集成测试、功能测试。一般情况,建议自己选择适合自己的自测方法。

很多时候,功能测试是相对来说性价比较高的方式。除此之外,自测的详细程度也根据实际情况有所不同,例如有些人只会测试正常情况,但有些老手会测试一些边界情况、异常情况。

毫无疑问,你越能像测试人员一样测试,你的提测质量肯定就越高,bug 当然也就越少。

对项目的熟悉程度

这里说的项目熟悉程度,既指技术层面的熟悉程度,也指业务功能层面的熟悉程度。

技术层面的熟悉程度,指的是项目之间是用什么技术栈搭建的,你对这些技术是否都熟悉。举个很简单的例子,项目中采用了微服务的方式进行调用,那么你是否清楚是什么微服务调用?

如果采用了 ElasticSearch 进行搜索,那么你是否对 ElasticSearch 有一些了解,知道一些基本使用及最佳实践?等等。

这些算是技术层面的熟悉程度,你对这些越熟悉,你在技术层面发生问题的可能性就越小。

业务功能层面的熟悉程度,指的是你对项目其他模块的业务是否熟悉。例如你经常负责 A 模块的功能,你对 A 模块肯定很熟悉。

但下个迭代你就要去做 B 迭代的需求了,这时候你肯定不是很熟,相对来说出错的可能性就更大一些。

无论是技术层面,还是业务层面的熟悉程度,都会随着你做了更多的需求,变得更加熟悉。到了后面某个阶段,你基本上就不存在踩坑的问题了,也为你业务开发零 bug 奠定了基础。如果你是一个刚刚进入公司的新手,那么做到零 bug 还是很难的。

开发时间是否充足

开发时间是否充足,决定了你是否有充足的时间去熟悉需求,去和产品经理确定细节。有了充足的时间,你也才能有一定时间去进行更详细的自测。更为关键的一点,有充足的时间,你写代码才能写得更好。因此,开发时间是否充足是很重要的。

在实际的开发过程中,会因为各种各样的原因,其实并没有办法给你留出特别理想的开发时间。这时候该怎么办?有些人选择接受,去压缩自己的时间。

有些人则会选择去沟通,或者协调资源,保证自己有充足的时间。其实,正确的做法还是第二种,这样会更好一些。

这需要开发人员有更强的综合能力(沟通、协调能力),但并不是每个开发人员都具备的。关于这点,又是可以聊的一个话题 —— 当你的需求被压缩工时的时候,你应该怎么做?这里暂不展开,后续有时间可以聊聊。

简单来说,开发时间是基础,没有合理、充足的时间保障的话,要做到业务开发零 bug 是不可能的事情。

总结

要做到业务开发零 bug,其实就是要消除功能开发过程中的所有不确定性,包括:需求功能的不确定性、自己写错代码的不确定性等等。而发生这些不确定性的地方,可能就有:

  1. 产品需求文档的清晰程度
  2. 需求的复杂程度
  3. 开发人员的细心程度
  4. 开发人员是否详细自测过
  5. 开发人员对项目的熟悉程度
  6. 开发人员开发时间是否充足

除了上面说到的 6 个影响业务开发零 bug 的因素之外,肯定还有其他影响因素。

你能想到什么影响业务开发零 bug 的因素吗?

欢迎在评论区留言与大家分享。

好了,今天的分享就到此为止。如果你觉得今天的文章对你有帮助,欢迎点赞转发评论,你的转发对于我很重要,感谢大家!


作者:树哥聊编程
来源:mp.weixin.qq.com/s/XqCD9-epYHstWD3CS7hLEg
收起阅读 »

APP与H5通信-JsBridge

背景 在移动开发领域,原生应用嵌入网页(H5)可以实现一套代码多端使用,那么原生应用(APP)和网页(H5)之间的通信就非常重要。 JsBridge作为一种实现此类通信的工具,用于实现原生应用和嵌入其中的网页之间的通信。 H5与native交互,本质上来说就两...
继续阅读 »

背景


在移动开发领域,原生应用嵌入网页(H5)可以实现一套代码多端使用,那么原生应用(APP)和网页(H5)之间的通信就非常重要。


JsBridge作为一种实现此类通信的工具,用于实现原生应用和嵌入其中的网页之间的通信。


H5与native交互,本质上来说就两种调用:



  1. JavaScript 调用 native 方法

  2. native 调用 JavaScript 方法


JavaScript调用native方法有两种方式:



  1. 注入,native 往 webview 的 window 对象中添加一些原生方法,h5可以通过注入的方法来调用 app 的原生能力

  2. 拦截,H5通过与 native 之间的协议发送请求,native拦截请求再去调用 app 原生能力


本文主要介绍H5端与App(android和ios)之间通信使用方式。


代码实现


实现步骤:


这段代码实现的是 APP(Android 和 iOS) 和 H5 之间的通信。这个通信过程主要依赖于 WebViewJavascriptBridge 这个桥接库。这里是具体的流程:



  1. 初始化 WebViewJavascriptBridge 对象:



    • 对于 Android,如果 WebViewJavascriptBridge 对象已经存在,则直接使用;如果不存在,则在 'WebViewJavascriptBridgeReady' 事件触发时获取 WebViewJavascriptBridge 对象。

    • 对于 iOS,如果 WebViewJavascriptBridge 对象已经存在,直接使用;如果不存在,则创建一个隐藏的 iframe 来触发 WebViewJavascriptBridge 的初始化,并在初始化完成后通过 WVJBCallbacks 回调数组来获取 WebViewJavascriptBridge 对象。



  2. 注册事件:


    提供了 callHandlerregisterHandler 两个方法,分别用于在 JS 中调用 APP 端的方法和注册供 APP 端调用的 JS 方法。


  3. 调用方法:


    当 APP 或 JS 需要调用对方的方法时,只需调用 callHandlerregisterHandler 方法即可。



const { userAgent } = navigator;
const isAndroid = userAgent.indexOf('android') > -1; // android终端

/**
* Android 与安卓交互时:
* 1、不调用这个函数安卓无法调用 H5 注册的事件函数;
* 2、但是 H5 可以正常调用安卓注册的事件函数;
* 3、还必须在 setupWebViewJavascriptBridge 中执行 bridge.init 方法,否则:
* ①、安卓依然无法调用 H5 注册的事件函数
* ①、H5 正常调用安卓事件函数后的回调函数无法正常执行
*
* @param {*} callback
*/

function androidFn(callback) {
if (window.WebViewJavascriptBridge) {
callback(window.WebViewJavascriptBridge);
} else {
document.addEventListener(
'WebViewJavascriptBridgeReady',
() => {
callback(window.WebViewJavascriptBridge);
},
false,
);
}
}

/**
* IOS 与 IOS 交互时,使用这个函数即可,别的操作都不需要执行
*/

function iosFn(callback) {
if (window.WebViewJavascriptBridge) { return callback(window.WebViewJavascriptBridge); }
if (window.WVJBCallbacks) { return window.WVJBCallbacks.push(callback); }
window.WVJBCallbacks = [callback];
const WVJBIframe = document.createElement('iframe');
WVJBIframe.style.display = 'none';
WVJBIframe.src = 'https://__BRIDGE_LOADED__';
document.documentElement.appendChild(WVJBIframe);
setTimeout(() => { document.documentElement.removeChild(WVJBIframe); }, 0);
}

/**
* 注册 setupWebViewJavascriptBridge 方法
* 之所以不将上面两个方法融合成一个方法,是因为放在一起,那么就只有 iosFuntion 中相关的方法体生效
*/

const setupWebViewJavascriptBridge = isAndroid ? androidFn : iosFn;

/**
* 这里如果不做判断是不是安卓,而是直接就执行下面的方法,就会导致
* 1、IOS 无法调用 H5 这边注册的事件函数
* 2、H5 可以正常调用 IOS 这边的事件函数,并且 H5 的回调函数可以正常执行
*/

if (isAndroid) {
/**
* 与安卓交互时,不调用这个函数会导致:
* 1、H5 可以正常调用 安卓这边的事件函数,但是无法再调用到 H5 的回调函数
*
* 前提 setupWebViewJavascriptBridge 这个函数使用的是 andoirFunction 这个,否则还是会导致上面 1 的现象出现
*/

setupWebViewJavascriptBridge((bridge) => {
console.log('打印***bridge', bridge);
// 注册 H5 界面的默认接收函数(与安卓交互时,不注册这个事件无法接收回调函数)
bridge.init((message, responseCallback) => {
responseCallback('JS 初始化');
});
});
}

export default {
// js调APP方法 (参数分别为:app提供的方法名 传给app的数据 回调)
callHandler(name, params, callback) {
setupWebViewJavascriptBridge((bridge) => {
bridge.callHandler(name, params, callback);
});
},

// APP调js方法 (参数分别为:js提供的方法名 回调)
registerHandler(name, callback) {
setupWebViewJavascriptBridge((bridge) => {
bridge.registerHandler(name, (data, responseCallback) => {
callback(data, responseCallback);
});
});
},
};

使用 JSBridge 总结:


1、跟 IOS 交互的时候,只需要且必须注册 iosFuntion 方法即可,不能在 setupWebViewJavascriptBridge 中执行 bridge.init 方法,否则 IOS 无法调用到 H5 的注册函数;


2、与安卓进行交互的时候



  • 使用 iosFuntion,就可以实现 H5 调用 安卓的注册函数,但是安卓无法调用 H5 的注册函数,
    并且 H5 调用安卓成功后的回调函数也无法执行

  • 使用 andoirFunction 并且要在 setupWebViewJavascriptBridge 中执行 bridge.init 方法,
    安卓才可以正常调用 H5 的回调函数,并且 H5 调用安卓成功后的回调函数也可以正常执行了


H5使用


h5获取app返回的数据:


jsBridge.callHandler('getAppUserInfo', { title: '首页' }, (data) => {
console.log('获取app返回的数据', data);
});

app获取h5返回的数据:


 jsBridge.registerHandler('getInfo', (data, responseCallback) => {
console.log('打印***get app data', data);
responseCallback('我是返回的数据');
});


两者都可通信,只要一方使用registerHandler注册了事件,另一方通过callHandler接受数据


总结


主要介绍了原生应用嵌入网页(H5)与APP(android和ios)之间的通信实现方法。


这个通信过程主要依赖于 WebViewJavascriptBridge 这个桥接库。通过在JavaScript中调用native方法和native调用JavaScript方法,实现APP和H5的互通。


主要通过提供了 callHandlerregisterHandler 两个方法,分别用于在 JS 中调用 APP 端的方法和注册供 APP 端调用的 JS 方法。


更简单方式: APP与H5通信-postMessage


参考资料:


ios-webview


android-webview


参考案例


作者:一诺滚雪球
来源:juejin.cn/post/7293728293768855587
收起阅读 »

面试官:为什么不用 index 做 key?

web
Holle 大家好,我是阳阳羊,在前两天的面试中,面试官问了这样一个问题:“在 Vue 中,我们在使用 v-for 渲染列表的时候,为什么要绑定一个 key?能不能用 index 做 key?” 在聊这个问题之前我们还得需要知道 Vue 是如何操作 DOM 结...
继续阅读 »

Holle 大家好,我是阳阳羊,在前两天的面试中,面试官问了这样一个问题:“在 Vue 中,我们在使用 v-for 渲染列表的时候,为什么要绑定一个 key?能不能用 indexkey?”


在聊这个问题之前我们还得需要知道 Vue 是如何操作 DOM 结构的。


虚拟DOM


我们知道,Vue 不可以直接操作 DOM 结构,而是通过数据驱动、指令等机制来间接操作 DOM 结构。当我们修改模版中的数据时,Vue 会触发重新渲染过程,调用render函数,它会返回一个 虚拟 DOM 树,它描述了整个组件模版的结构。


举个栗子🌰:


<template>
<ul class="list">
<li v-for="item in list" :key="item.index" class="item">{{ item }}</li>
</ul>
</template>

<script setup>
import { ref } from 'vue';
const list = ref(['html', 'css', 'js'])
</script>

Vue 在渲染这个列表时,就会调用render函数,它会返回一个类似下面这个虚拟 DOM 树。


let VDom = {
tagName: 'ul',
props: {
class: 'list'
},
chilren: [
{
tagName: 'li',
props: {
class: 'item'
},
chilren: ['html']
},
{
tagName: 'li',
props: {
class: 'item'
},
chilren: ['css']
},
{
tagName: 'li',
props: {
class: 'item'
},
chilren: ['js']
}
]
}

虚拟 DOM 的每个节点对应于真实 DOM 树中的一个节点。


当我们修改数据时,Vue 又会触发重新渲染的过程。


const list = ref(['html', 'css', 'vue']) //修改列表第三项'js'->'vue'

Vue 又会生成一个新的虚拟DOM树:


let VDom = {
tagName: 'ul',
props: {
class: 'list'
},
chilren: [
{
tagName: 'li',
props: {
class: 'item'
},
chilren: ['html']
},
{
tagName: 'li',
props: {
class: 'item'
},
chilren: ['css']
},
{
tagName: 'li',
props: {
class: 'item'
},
chilren: ['vue']
}
]
}

注意观察,这里最后一个节点的子节点为'vue',发生了数据变化,Vue内部又会返回一个新的虚拟 DOM。那么 Vue 是如何将这个变化响应给页面的呢?


摆在面前的有两条路


要么重新渲染这个新的虚拟 DOM ,要么只新旧虚拟 DOM 之间改变的地方。


显而易见,只渲染修改了的地方是不是会更节省性能。


巧了,尤雨溪也是这样想的,于是便有了“ Diff 算法 ”。


Diff 算法


Vue 将新生成的新虚拟 DOM 与上一次渲染时生成的旧虚拟 DOM 进行比较,对比出是哪个虚拟节点更改了,找出这个虚拟节点,并只更新这个虚拟节点所对应的真实节点,而不用更新其他数据没发生改变的节点。


我自己总结了一下Diff算法的过程,由于代码过多,就不在此展示了:




  1. 新旧虚拟DOM对比的时候,Diff 算法比较只会在同层级进行,不会跨层级比较。

  2. 首先比较两个节点的类型,如果类型不同,则废弃旧节点并用新节点替代。

  3. 对于相同类型的节点,进一步比较它们的属性。记录属性差异,以便生成相应的补丁。

  4. 如果两个节点相同,继续递归比较它们的子节点,直到遍历完整个树。

  5. 如果节点有唯一标识,可以通过这些标识来快速定位相同标识的节点。

  6. 如果节点的相同,只是顺序变化,不会执行不必要的操作。



面试官:为什么不用 index 做 key?


平常v-for循环渲染的时候,为什么不建议用 index 作为循环项的 key 呢?


举个栗子🌰:


<div id="app">
<ul>
<li v-for="item in list" :key="item.index">{{item}}</li>
</ul>
<button @click="add">添加</button>
</div>
<script>
const { createApp, ref } = Vue
createApp({
setup() {
const list = ref(['html', 'css', 'js']);
const add=()=> {
list.value.unshift('阳阳羊');
}
return {
list,
add
}
}
}).mount('#app')
</script>

这里用 indexkey渲染这个列表,我们通过 add 方法在列表的前面添加一项。


GIF 2024-3-5 23-57-41.gif


我们发现添加操作导致的整个列表的重新渲染,按道理来说,Diff 算法会复用后面的三项,因为它们只是位置发生了变化,内容并没有改变。但是我们回过头来发现,我们在前面添加了一项,导致后面三项的 index 变化,从而导致 key 值发生变化。Diff 算法失效了?


那我们可以怎么解决呢?其实我们只要使用一个独一无二的值来当做key就行了


<div id="app">
<ul>
<li v-for="item in list" :key="item.id">{{item.name}}</li>
</ul>
<button @click="add">添加</button>
</div>
<script>
const { createApp, ref } = Vue
createApp({
setup() {
const list = ref(
[
{ name: "html", id: 1 },
{ name: "css", id: 2 },
{ name: "js", id: 3 },
]);
const add=()=> {
list.value.unshift({ name: '阳阳羊', id: 4 });
}
return {
list,
add
}
}
}).mount('#app')
</script>

GIF 2024-3-6 0-09-39.gif


这样,key就是永远不变的,更新前后都是一样的,并且又由于节点的内容本来就没变,所以 Diff 算法完美生效,只需将新节点添加到真实 DOM 就行了。


最后


看到这里,希望你已经对Diff 算法有了初步的了解,想要深入了解,可以自行查看Diff 源码。总的来说,Diff 算法是一项关键的技术,为构建响应式和高效的用户界面提供了基础。最后,祝你面试顺利,学习进步!



如果你正在面临春招,或者对面试有所疑惑,欢迎评论 / 私信,我们报团取暖!




技术小白记录学习过程,有错误或不解的地方还请评论区留言,如果这篇文章对你有所帮助请 “点赞 收藏+关注” ,感谢支持!!



作者:阳阳羊
来源:juejin.cn/post/7342793254096109583
收起阅读 »