注册
环信即时通讯云

环信即时通讯云

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

环信开发文档

Demo体验

Demo体验

场景Demo,开箱即用
RTE开发者社区

RTE开发者社区

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

技术讨论区

技术交流、答疑
资源下载

资源下载

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

iOS Library

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

Android Library

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

面试官问,如何在十亿级别用户中检查用户名是否存在?

前言 不知道大家有没有留意过,在使用一些app注册的时候,提示你用户名已经被占用了,需要更换一个,这是如何实现的呢?你可能想这不是很简单吗,去数据库里查一下有没有不就行了吗,那么假如用户数量很多,达到数亿级别呢,这又该如何是好? 数据库方案 第一种方案就是查...
继续阅读 »

前言


不知道大家有没有留意过,在使用一些app注册的时候,提示你用户名已经被占用了,需要更换一个,这是如何实现的呢?你可能想这不是很简单吗,去数据库里查一下有没有不就行了吗,那么假如用户数量很多,达到数亿级别呢,这又该如何是好?


数据库方案



第一种方案就是查数据库的方案,大家都能够想到,代码如下:


public class UsernameUniquenessChecker {
private static final String DB_URL = "jdbc:mysql://localhost:3306/your_database";
private static final String DB_USER = "your_username";
private static final String DB_PASSWORD = "your_password";

public static boolean isUsernameUnique(String username) {
try (Connection conn = DriverManager.getConnection(DB_URL, DB_USER, DB_PASSWORD)) {
String sql = "SELECT COUNT(*) FROM users WHERE username = ?";
try (PreparedStatement stmt = conn.prepareStatement(sql)) {
stmt.setString(1, username);
try (ResultSet rs = stmt.executeQuery()) {
if (rs.next()) {
int count = rs.getInt(1);
return count == 0; // If count is 0, username is unique
}
}
}
} catch (SQLException e) {
e.printStackTrace();
}
return false; // In case of an error, consider the username as non-unique
}

public static void main(String[] args) {
String desiredUsername = "new_user";
boolean isUnique = isUsernameUnique(desiredUsername);
if (isUnique) {
System.out.println("Username '" + desiredUsername + "' is unique. Proceed with registration.");
} else {
System.out.println("Username '" + desiredUsername + "' is already in use. Choose a different one.");
}
}
}

这种方法会带来如下问题:



  1. 性能问题,延迟高 如果数据量很大,查询速度慢。另外,数据库查询涉及应用程序服务器和数据库服务器之间的网络通信。建立连接、发送查询和接收响应所需的时间也会导致延迟。

  2. 数据库负载过高。频繁执行 SELECT 查询来检查用户名唯一性,每个查询需要数据库资源,包括CPU和I/O。



  1. 可扩展性差。数据库对并发连接和资源有限制。如果注册率继续增长,数据库服务器可能难以处理数量增加的传入请求。垂直扩展数据库(向单个服务器添加更多资源)可能成本高昂并且可能有限制。


缓存方案


为了解决数据库调用用户名唯一性检查的性能问题,引入了高效的Redis缓存。



public class UsernameCache {

private static final String REDIS_HOST = "localhost";
private static final int REDIS_PORT = 6379;
private static final int CACHE_EXPIRATION_SECONDS = 3600;

private static JedisPool jedisPool;

// Initialize the Redis connection pool
static {
JedisPoolConfig poolConfig = new JedisPoolConfig();
jedisPool = new JedisPool(poolConfig, REDIS_HOST, REDIS_PORT);
}

// Method to check if a username is unique using the Redis cache
public static boolean isUsernameUnique(String username) {
try (Jedis jedis = jedisPool.getResource()) {
// Check if the username exists in the Redis cache
if (jedis.sismember("usernames", username)) {
return false; // Username is not unique
}
} catch (Exception e) {
e.printStackTrace();
// Handle exceptions or fallback to database query if Redis is unavailable
}
return true; // Username is unique (not found in cache)
}

// Method to add a username to the Redis cache
public static void addToCache(String username) {
try (Jedis jedis = jedisPool.getResource()) {
jedis.sadd("usernames", username); // Add the username to the cache set
jedis.expire("usernames", CACHE_EXPIRATION_SECONDS); // Set expiration time for the cache
} catch (Exception e) {
e.printStackTrace();
// Handle exceptions if Redis cache update fails
}
}

// Cleanup and close the Redis connection pool
public static void close() {
jedisPool.close();
}
}

这个方案最大的问题就是内存占用过大,假如每个用户名需要大约 20 字节的内存。你想要存储10亿个用户名的话,就需要20G的内存。


总内存 = 每条记录的内存使用量 * 记录数 = 20 字节/记录 * 1,000,000,000 条记录 = 20,000,000,000 字节 = 20,000,000 KB = 20,000 MB = 20 GB


布隆过滤器方案


直接缓存判断内存占用过大,有没有什么更好的办法呢?布隆过滤器就是很好的一个选择。


那究竟什么布隆过滤器呢?


布隆过滤器Bloom Filter)是一种数据结构,用于快速检查一个元素是否存在于一个大型数据集中,通常用于在某些情况下快速过滤掉不可能存在的元素,以减少后续更昂贵的查询操作。布隆过滤器的主要优点是它可以提供快速的查找和插入操作,并且在内存占用方面非常高效。


具体的实现原理和数据结构如下图所示:



布隆过滤器的核心思想是使用一个位数组(bit array)和一组哈希函数。



  • 位数组(Bit Array) :布隆过滤器使用一个包含大量位的数组,通常初始化为全0。每个位可以存储两个值,通常是0或1。这些位被用来表示元素的存在或可能的存在。

  • 哈希函数(Hash Functions) :布隆过滤器使用多个哈希函数,每个哈希函数可以将输入元素映射到位数组的一个或多个位置。这些哈希函数必须是独立且具有均匀分布特性。


那么具体是怎么做的呢?



  • 添加元素:如上图所示,当将字符串“xuyang”,“alvin”插入布隆过滤器时,通过多个哈希函数将元素映射到位数组的多个位置,然后将这些位置的位设置为1。

  • 查询元素:当要检查一个元素是否存在于布隆过滤器中时,通过相同的哈希函数将元素映射到位数组的相应位置,然后检查这些位置的位是否都为1。如果有任何一个位为0,那么可以确定元素不存在于数据集中。但如果所有位都是1,元素可能存在于数据集中,但也可能是误判。


本身redis支持布隆过滤器的数据结构,我们用代码简单实现了解一下:


import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;

public class BloomFilterExample {
public static void main(String[] args) {
JedisPoolConfig poolConfig = new JedisPoolConfig();
JedisPool jedisPool = new JedisPool(poolConfig, "localhost", 6379);

try (Jedis jedis = jedisPool.getResource()) {
// 创建一个名为 "usernameFilter" 的布隆过滤器,需要指定预计的元素数量和期望的误差率
jedis.bfCreate("usernameFilter", 10000000, 0.01);

// 将用户名添加到布隆过滤器
jedis.bfAdd("usernameFilter", "alvin");

// 检查用户名是否已经存在
boolean exists = jedis.bfExists("usernameFilter", "alvin");
System.out.println("Username exists: " + exists);
}
}
}

在上述示例中,我们首先创建一个名为 "usernameFilter" 的布隆过滤器,然后使用 bfAdd 将用户名添加到布隆过滤器中。最后,使用 bfExists 检查用户名是否已经存在。


优点:



  • 节约内存空间,相比使用哈希表等数据结构,布隆过滤器通常需要更少的内存空间,因为它不存储实际元素,而只存储元素的哈希值。如果以 0.001 误差率存储 10 亿条记录,只需要 1.67 GB 内存,对比原来的20G,大大的减少了。

  • 高效的查找, 布隆过滤器可以在常数时间内(O(1))快速查找一个元素是否存在于集合中,无需遍历整个集合。


缺点:



  • 误判率存在:布隆过滤器在判断元素是否存在时,有一定的误判率。这意味着在某些情况下,它可能会错误地报告元素存在,但不会错误地报告元素不存在。

  • 不能删除元素:布隆过滤器通常不支持从集合中删除元素,因为删除一个元素会影响其他元素的哈希值,增加了误判率。


总结


Redis 布隆过滤器的方案为大数据量下唯一性验证提供了一种基于内存的高效解决方案,它需要在内存消耗和错误率之间取得一个平衡点。当然布隆过滤器还有更多应用场景,比如防止缓存穿透、防止恶意访问等。


作者:JAVA旭阳
来源:juejin.cn/post/7293786247655129129
收起阅读 »

初学后端,如何做好表结构设计?

前言 最近有不少前端和测试转Go的朋友在私信我:如何做好表结构设计? 大家关心的问题阳哥必须整理出来,希望对大家有帮助。 先说结论 这篇文章介绍了设计数据库表结构应该考虑的4个方面,还有优雅设计的6个原则,举了一个例子分享了我的设计思路,为了提高性能我们也要从...
继续阅读 »

前言


最近有不少前端和测试转Go的朋友在私信我:如何做好表结构设计?


大家关心的问题阳哥必须整理出来,希望对大家有帮助。


先说结论


这篇文章介绍了设计数据库表结构应该考虑的4个方面,还有优雅设计的6个原则,举了一个例子分享了我的设计思路,为了提高性能我们也要从多方面考虑缓存问题。


收获最大的还是和大家的交流讨论,总结一下:



  1. 首先,一定要先搞清楚业务需求。比如我的例子中,如果不需要灵活设置,完全可以写到配置文件中,并不需要单独设计外键。主表中直接保存各种筛选标签名称(注意维护的问题,要考虑到数据一致性)

  2. 数据库表结构设计一定考虑数据量和并发量,我的例子中如果数据量小,可以适当做冗余设计,降低业务复杂度。


4个方面


设计数据库表结构需要考虑到以下4个方面:




  1. 数据库范式:通常情况下,我们希望表的数据符合某种范式,这可以保证数据的完整性和一致性。例如,第一范式要求表的每个属性都是原子性的,第二范式要求每个非主键属性完全依赖于主键,第三范式要求每个非主键属性不依赖于其他非主键属性。




  2. 实体关系模型(ER模型):我们需要先根据实际情况画出实体关系模型,然后再将其转化为数据库表结构。实体关系模型通常包括实体、属性、关系等要素,我们需要将它们转化为表的形式。




  3. 数据库性能:我们需要考虑到数据库的性能问题,包括表的大小、索引的使用、查询语句的优化等。




  4. 数据库安全:我们需要考虑到数据库的安全问题,包括表的权限、用户角色的设置等。




设计原则


在设计数据库表结构时,可以参考以下几个优雅的设计原则:




  1. 简单明了:表结构应该简单明了,避免过度复杂化。




  2. 一致性:表结构应该保持一致性,例如命名规范、数据类型等。




  3. 规范化:尽可能将表规范化,避免数据冗余和不一致性。




  4. 性能:表结构应该考虑到性能问题,例如使用适当的索引、避免全表扫描等。




  5. 安全:表结构应该考虑到安全问题,例如合理设置权限、避免SQL注入等。




  6. 扩展性:表结构应该具有一定的扩展性,例如预留字段、可扩展的关系等。




最后,需要提醒的是,优雅的数据库表结构需要在实践中不断迭代和优化,不断满足实际需求和新的挑战。



下面举个示例让大家更好的理解如何设计表结构,如何引入内存,有哪些优化思路:



问题描述



如上图所示,红框中的视频筛选标签,应该怎么设计数据库表结构?除了前台筛选,还想支持在管理后台灵活配置这些筛选标签。


这是一个很好的应用场景,大家可以先自己想一下。不要着急看我的方案。


需求分析



  1. 可以根据红框的标签筛选视频

  2. 其中综合标签比较特殊,和类型、地区、年份、演员等不一样



  • 综合是根据业务逻辑取值,并不需要入库

  • 类型、地区、年份、演员等需要入库



  1. 设计表结构时要考虑到:



  • 方便获取标签信息,方便把标签信息缓存处理

  • 方便根据标签筛选视频,方便我们写后续的业务逻辑


设计思路



  1. 综合标签可以写到配置文件中(或者写在前端),这些信息不需要灵活配置,所以不需要保存到数据库中

  2. 类型、地区、年份、演员都设计单独的表

  3. 视频表中设计标签表的外键,方便视频列表筛选取值

  4. 标签信息写入缓存,提高接口响应速度

  5. 类型、地区、年份、演员表也要支持对数据排序,方便后期管理维护


表结构设计


视频表


字段注释
id视频主键id
type_id类型表外键id
area_id地区表外键id
year_id年份外键id
actor_id演员外键id

其他和视频直接相关的字段(比如名称)我就省略不写了


类型表


字段注释
id类型主键id
name类型名称
sort排序字段

地区表


字段注释
id类型主键id
name类型名称
sort排序字段

年份表


字段注释
id类型主键id
name类型名称
sort排序字段

原以为年份字段不需要排序,要么是年份正序排列,要么是年份倒序排列,所以不需要sort字段。


仔细看了看需求,还有“10年代”还是需要灵活配置的呀~


演员表


字段注释
id类型主键id
name类型名称
sort排序字段

表结构设计完了,别忘了缓存


缓存策略


首先这些不会频繁更新的筛选条件建议使用缓存:




  1. 比较常用的就是redis缓存

  2. 再进阶一点,如果你使用docker,可以把这些配置信息写入docker容器所在物理机的内存中,而不用请求其他节点的redis,进一步降低网络传输带来的耗时损耗

  3. 筛选条件这类配置信息,客户端和服务端可以约定一个更新缓存的机制,客户端直接缓存配置信息,进一步提高性能


列表数据自动缓存


目前很多框架都是支持自动缓存处理的,比如goframe和go-zero


goframe


可以使用ORM链式操作-查询缓存


示例代码:


package main

import (
"time"

"github.com/gogf/gf/v2/database/gdb"
"github.com/gogf/gf/v2/frame/g"
"github.com/gogf/gf/v2/os/gctx"
)

func main() {
var (
db = g.DB()
ctx = gctx.New()
)

// 开启调试模式,以便于记录所有执行的SQL
db.SetDebug(true)

// 写入测试数据
_, err := g.Model("user").Ctx(ctx).Data(g.Map{
"name": "xxx",
"site": "https://xxx.org",
}).Insert()

// 执行2次查询并将查询结果缓存1小时,并可执行缓存名称(可选)
for i := 0; i < 2; i++ {
r, _ := g.Model("user").Ctx(ctx).Cache(gdb.CacheOption{
Duration: time.Hour,
Name: "vip-user",
Force: false,
}).Where("uid", 1).One()
g.Log().Debug(ctx, r.Map())
}

// 执行更新操作,并清理指定名称的查询缓存
_, err = g.Model("user").Ctx(ctx).Cache(gdb.CacheOption{
Duration: -1,
Name: "vip-user",
Force: false,
}).Data(gdb.Map{"name": "smith"}).Where("uid", 1).Update()
if err != nil {
g.Log().Fatal(ctx, err)
}

// 再次执行查询,启用查询缓存特性
r, _ := g.Model("user").Ctx(ctx).Cache(gdb.CacheOption{
Duration: time.Hour,
Name: "vip-user",
Force: false,
}).Where("uid", 1).One()
g.Log().Debug(ctx, r.Map())
}

go-zero


DB缓存机制


go-zero缓存设计之持久层缓存


官方都做了详细的介绍,不作为本文的重点。


讨论


我的方案也在我的技术交流群里引起了大家的讨论,也和大家分享一下:


Q1 冗余设计和一致性问题



提问: 一个表里做了这么多外键,如果我要查各自的名称,势必要关联4张表,对于这种存在多外键关联的这种表,要不要做冗余呢(直接在主表里冗余各自的名称字段)?要是保证一致性的话,就势必会影响性能,如果做冗余的话,又无法保证一致性



回答:


你看文章的上下文应该知道,文章想解决的是视频列表筛选问题。


你提到的这个场景是在视频详情信息中,如果要展示这些外键的名称怎么设计更好。


我的建议是这样的:



  1. 根据需求可以做适当冗余,比如你的主表信息量不大,配置信息修改后同步修改冗余字段的成本并不高。

  2. 或者像我文章中写的不做冗余设计,但是会把外键信息缓存,业务查询从缓存中取值。

  3. 或者将视频详情的查询结果整体进行缓存


还是看具体需求,如果这些筛选信息不变化或者不需要手工管理,甚至不需要设计表,直接写死在代码的配置文件中也可以。进一步降低DB压力,提高性能。


Q2 why设计外键?



提问:为什么要设计外键关联?直接写到视频表中不就行了?这么设计的意义在哪里?



回答:



  1. 关键问题是想解决管理后台灵活配置

  2. 如果没有这个需求,我们可以直接把筛选条件以配置文件的方式写死在程序中,降低复杂度。

  3. 站在我的角度:这个功能的筛选条件变化并不会很大,所以很懂你的意思。也建议像我2.中的方案去做,去和产品经理拉扯喽~


总结


这篇文章介绍了设计数据库表结构应该考虑的4个方面,还有优雅设计的6个原则,举了一个例子分享了我的设计思路,为了提高性能我们也要从多方面考虑缓存问题。


收获最大的还是和大家的交流讨论,总结一下:



  1. 首先,一定要先搞清楚业务需求。比如我的例子中,如果不需要灵活设置,完全可以写到配置文件中,并不需要单独设计外键。主表中直接保存各种筛选标签名称(注意维护的问题,要考虑到数据一致性)

  2. 数据库表结构设计一定考虑数据量和并发量,我的例子中如果数据量小,可以适当做冗余设计,降低业务复杂度



本文抛砖引玉,欢迎大家留言交流。



一起学习


欢迎和我一起讨论交流:可以在掘金私信我


也欢迎关注我的公众号: 程序员升职加薪之旅


也欢迎大家关注我的掘金,点赞、留言、转发。你的支持,是我更文的最大动力!



作者:王中阳Go
来源:juejin.cn/post/7212828749128876092
收起阅读 »

React框架部署实战:打造高效现代化的Web应用

web
React框架部署实战 在前端开发领域,React框架因其高效的组件化架构和出色的性能而备受开发者喜爱。然而,要让React应用真正展现其魅力,一个关键的环节就是部署。 本文将带领你深入了解React框架的部署过程,为你的Web应用提供一个高效、稳定的运行...
继续阅读 »

React框架部署实战



在前端开发领域,React框架因其高效的组件化架构和出色的性能而备受开发者喜爱。然而,要让React应用真正展现其魅力,一个关键的环节就是部署。



本文将带领你深入了解React框架的部署过程,为你的Web应用提供一个高效、稳定的运行环境。


📍 准备工作:配置环境


在开始部署React应用之前,确保你的开发环境已经配置完善。首先,安装Node.js和npm,这是React应用的基础依赖。随后,使用以下命令安装Create React App,这是一个官方推荐的React应用脚手架,简化了项目的初始化和配置过程。


npx create-react-app my-react-app

📍 生产环境构建:优化性能


React应用在开发过程中使用的是开发环境配置,而在部署到生产环境时,我们需要进行一些优化以提升性能。使用以下命令进行生产环境构建:


npm run build

这将生成一个build文件夹,包含了优化后的、用于生产环境的代码。这一步骤将帮助你减小应用的体积,提高加载速度,使其更适合在生产环境中运行。


📍 选择合适的服务器:保障稳定性


选择一个合适的服务器对于React应用的部署至关重要。你可以选择使用传统的Web服务器,比如Nginx或Apache,也可以考虑使用专门为React应用设计的服务器,如Express或Firebase Hosting。确保服务器能够正确配置,以支持React路由和处理单页面应用的特殊需求。


📍 域名与SSL:提升安全性


为你的React应用配置域名,并考虑启用SSL证书以提高安全性。在大多数情况下,你可以通过云服务提供商或第三方SSL证书颁发机构获取免费的SSL证书。使用HTTPS协议不仅有助于提升安全性,还有可能对搜索引擎排名产生积极影响。


📍 自动化部署:提高效率


自动化部署是一个高效的实践,可以减少人为错误并提高开发团队的工作效率。你可以考虑使用持续集成/持续部署(CI/CD)工具,如Jenkins、Travis CI或GitHub Actions,将代码的自动构建和部署流程整合到你的开发工作流中。


📍 监控与日志:保障可维护性


部署完成后,监控和日志记录是必不可少的环节。使用工具如Sentry、New Relic等,实时监测应用的性能和错误,及时发现并解决潜在的问题。同时,记录应用的日志可以帮助你追踪和分析用户行为,为后续的优化提供有力支持。


📍 版本管理:确保灵活性


在生产环境中,灵活地管理React应用的版本是至关重要的。使用工具如Docker,可以打包你的应用及其依赖,确保在不同环境中的一致性。结合版本控制工具如Git,能够轻松地进行回滚和发布新版本。


📍 总结


通过本文的步骤,你可以更好地了解如何部署React应用,确保其在生产环境中高效、稳定地运行。部署不仅仅是一个技术问题,更是一个关乎用户体验和团队效率的重要环节。通过合理的部署流程,你的React应用将能够展现出其设计之美和高效性能,为用户提供卓越的使用体验。


作者:知识浅谈
来源:juejin.cn/post/7301976895913689125
收起阅读 »

历时一个月,6年前端降薪上岸了

web
6年前端,11.15号,拿到了这一个月以来的第一份offer,降薪,教育行业,正如之前在文章中所说的,我就是头铁。 这篇文章就水一下我这差不多一个月的面试旅程吧。 我是在7.14号左右从一家培训公司毕业,然后拿了N+1,我就回家了,一直待到国庆之后才回的北京。...
继续阅读 »

6年前端,11.15号,拿到了这一个月以来的第一份offer,降薪,教育行业,正如之前在文章中所说的,我就是头铁。
这篇文章就水一下我这差不多一个月的面试旅程吧。
我是在7.14号左右从一家培训公司毕业,然后拿了N+1,我就回家了,一直待到国庆之后才回的北京。


第一次面试


第一个面试是我的朋友给我内推的公司,智联招聘,时间大概是在10.08,当时我啥也没有准备,裸面,最后还是被pass了。面试官当时问了我这么几个问题:




  1. 说说你自己想做的技术方向(主要是针对招聘岗位看看你是否合适,他们想找一个做监控平台和业务的)

  2. 你认为什么是好的代码

  3. 对程序设计原则有了解吗

  4. 对于质量保障,前端职能该做什么(前端质检工作)

  5. 小程序从聊天记录选择文件,上传失败,你觉得应该如何去解决和排查这个问题

  6. node是如何处理高并发的



从整个面试来看,涉及到前端技术相关的问题其实也没几个,第1个问题,面试官就已经给我挖坑了,我当时巴拉巴拉说了一堆关于前端基建和自己想做前端底层相关的事情,很明显,他需要的不是这样的人,因为他们现在做的还是以业务为主,还有监控相关的事情正在推进,需要有人着手去做。然后就是第4个问题,这个问题就可以考察出我对于前端整个开发生命周期的质量保证了解多少,从而判断出我是不是适合这个岗位,很明显的,我的回答并不满意。第2个和第3个问题,我确实以前没有考虑过,后来我查了一下,如果对理论知识比较关注的话,这些东西应该都需要了解的。由此考察出我对这方面知识的欠缺。第5个问题,是之前他们在开发遇到的一个问题,然后问我如何解决这个问题,我当时脑子短路了,一直在寻思这个问题到底出在哪里,而他想知道的是,当遇到问题的时候如何排查解决的一个思路,很明显,我走错路了。整个面试过程也很清晰,考察三个点,第一点是不是匹配他们的招聘岗位,第二点是不是理论基础比较扎实,第三点解决问题的能力。


如何复习


经过这次面试,我把上面几个问题总结了,在后面的面试中2、3、4经常被问到,我也是对答如流。由此开始了我的面试旅程。那么接下来就讲讲我是如何来复习和做总结的。


首先,复习基础知识(八股文),一般就是css、js、ts、vue、react、webpack浏览器相关面试题,如何去找面试题呢?我最常用的方式是掘金去看优质的文章,这是最浪费时间也是最能能掌握的一种方式,可能很多面试题手册写的就是针对面试题的那么几句话,并没有讲的很清楚,知其然,不知其所以然,问的详细一点就会懵了。如果需要面试题手册的可以加我WX:xiumubai01。然后就是就是总结,我选择的是xmind写个思维导图,罗列大纲。这样看起来就非常清晰,哪些知识点我复习过了,对应的每个知识点有哪些细节,我都会做出标记,这样,在我的脑海中就形成了一套面试的话术,我面试的时候也会根据这样一个结构去讲,一来我心中有思路,二来面试官听的不迷糊。
大概差不多像下面的这样的:
image.png


以某个知识点为例:
image.png
我把整个浏览器相关的知识点都总结到了一起,这样既可以方便复习,也能让我系统的掌握相关浏览器的知识点。
想要获取思维导图的道友们可以可以加我WX:xiumubai01


关于项目问题,我也提以下。非常重要。一般面试官会根据你写的简历上面的项目问你,让你讲讲做的最拿手的一个项目,做了哪些事?遇到过什么问题?怎么解决的?当你讲项目的时候,面试官就能直观的感受到你平时工作中到底几斤几两。我的项目中写了一个业务(剧本直播),微前端平台,低代码平台。比如我微前端平台面试官会问到的问题:你如何选型?为什么选这个框架(qiankun)?那qiankun当中你使用的时候遇到过什么问题?你觉得这个框架有哪些不足的地方?它是如何实现js沙箱隔离的?(变态一点的直接让你实现一个)。所以项目你一定要吃透。当你讲的过程中,人家会提问各种场景,问你如何解决的,如果你提前没有想到,那只能当场退役。


除了自己复习相关的知识点以外,面试总结特别重要。我养成的习惯是每次面试完了立马总结问到的问题,然后进行复盘,这次面试哪里回答的不好,面试官想要考察的能力是什么?这次回答不好的问题下次我能不能应对?按照我的经验,每次总结完之后大概率后面的面试都会问到同样的问题。以下是我总结的:
image.png


如果你面试完了记不住面试官问的问题,我的做法是掏出纸和笔,在面试官提问的时候,记下问题关键词,这样方便面试完了以后回忆。


如何coding


加下来就是关于coding题,很多人都会恐惧,我也是,没有思路,前一天刚刷的代码第二天就忘了。没有他法,脑子笨,只能靠理解加强记忆,那最好的办法就是你要把这道题目吃透,研究明白,思路清晰,其实不管任何代码,你先得知道这道题怎么解啊,然后才能用代码实现。我这里总结了我面试以来手写的一些coding题,放在github了。大家可以打开链接自取。



github: github.com/xiumubai/co…


gitee: gitee.com/xiumubai/co…



如何消除焦虑


在面试的过程中,难免会有学不进去,面试遭受打击,长时间没有offer心中气垒等等情况的发生。尤其是当你面试3-4轮以后,眼见要拿到offer了,最后杳无音信,或者人事直接通知你pass了,这时候是最打击人的。整个人就像被掏空了一样。


面对以上这种情况,我后来想了一种排解的方式,拉了个微信群,把最近找工作的道友们一起拉进去,大家互相鼓励,讨论遇到的面试题,最近的市场行情,这样可以分解一下压力,转移注意力,有可能有的人比你更惨。有想进群的朋友可以关注一下我的公众号「白哥学前端」,进群,群里有我最新的一些面试题和xmind文件分享。


当然保持积极的心情也很重要,不要做一些沉迷动作(比如打游戏,晚上不睡,早上不起),把自己的时间调整成上班的时间,这个时间点你就做跟学习有关的事情。


这个过程是很痛苦和煎熬的,相信大家都能坚持住,最后,祝大家都能顺利找到满意的工作。


作者:白哥学前端
来源:juejin.cn/post/7301909438540267531
收起阅读 »

企业应该如何选择合适的api解决方案

当下有不少企业需要通过外部的api服务来进行公司内部的战略规划,那么在进行选择时,如何才能在满足公司需求的同时还能选择好合适自己的api解决方案呢?可以根据以下这几个标准来评估,以确保api方案能够实现企业利益最大化。服务性能为了满足企业对页面速度的期望,AP...
继续阅读 »


当下有不少企业需要通过外部的api服务来进行公司内部的战略规划,那么在进行选择时,如何才能在满足公司需求的同时还能选择好合适自己的api解决方案呢?可以根据以下这几个标准评估,以确保api方案能够实现企业利益最大化。

服务性能

为了满足企业对页面速度的期望,API响应时间不应超过 90 毫秒。保证API 快速运转其中一种方法是采用客户端将数据传送到 CDN 网络的边缘节点,而不是存储在数据中心某处的服务器上。

但是并非每个功能都需要相同级别的速度。例如,某电商产品描述内容大多是静态的,而商品库存则不是。因此,由企业 CMS API 提供的内容可能不需要与来自其他渠道的数据相同的速度。

虽然高性能对于企业使用的每个 API 都很重要,但每个 API 需要满足的实际性能基准却因功能和企业要解决的最终用户问题而异。

文档

对于企业采用的任何 API 解决方案来说,完整的文档是必不可少的。强大的文档让开发人员可以更有效地使用 API,并最终更快地将产品推向市场。

但即使在提供详尽文档的API提供商中,开发人员也无法直接有效上手使用。例如,我已经阅读了大量文档,这些文档是在已经了解 API 的工作原理的情况下编写的这使得新开发人员更难学习和理解 API 的功能。因此文档不仅需要完整还需要被人理解清楚。

安全

任何 API 提供商都应提供强大的安全性,以确保 API 不会被不良行为者恶意使用或被黑客入侵以暴露敏感信息。所以需要看API服务商是如何描述其安全性的,这关系到企业的信息安全问题。

灵活性和可扩展性

企业可以自由地使用 API 创建任何他们想要的东西,这种创建包括在客户体验方面、或者对组织有意义的方式去管理后端信息。

换句话说,API 解决方案应该定义明确

定价模式

最后要考虑的是 API 的定价模型,包括实际成本,还包括提供商使用其服务的收费方式。

例如,是否按订单收费?按带宽?按记录数?这种定价模式需要适用于企业的业务

API 解决方案应该使其易于增长和发展

如果企业 API 作为平台重构项目的一部分进行探索那么有可能会存在API无法满足不断变化的客户期望或者会限制团队创造力。因此企业选择的 API 应该满足内部需求,并且可以随着需求的发展而轻松做出更改例如将一个 API 提供者换成另一个。

数聚变基于以上几个标准打造了专门为企业提供标准化数据服务的API平台,通过API接口轻松接入精细化数据,帮助企业完成数字化转型,提高工作效率,更多信息点击了解:数聚变 | 数智技术加速数据要素安全流通,融合聚变 (goldwind.com)

收起阅读 »

用Kotlin通杀“一切”进率换算

用Kotlin通杀“一切”进率换算之存储容量 前言 在之前的文章《用Kotlin Duration来优化时间运算》 中,用Duration可以很方便的进行时间的单位换算和运算。我忽然想到平时的工作中经常用到的换算和运算。(人民币汇率;长度单位m,cm;质量单位...
继续阅读 »

用Kotlin通杀“一切”进率换算之存储容量


前言


在之前的文章《用Kotlin Duration来优化时间运算》
中,用Duration可以很方便的进行时间的单位换算和运算。我忽然想到平时的工作中经常用到的换算和运算。(人民币汇率;长度单位m,cm;质量单位 kg,g,lb;存储容量单位 mb,gb,tb 等等)


//进率为1024
val tenMegabytes = 10 * 1024 * 1024 //10mb
val tenGigabytes = 10 * 1024 * 1024 * 1024 //10gb

这样的业务代码加入了单位换算后阅读性就变差了,能否有像Duration一样的api实现下面这样的代码呢?


fun main() {
1.kg = 2.20462262.lb; 1.m = 100.cm

val fiftyMegabytes = 50.mb
val divValue = fiftyMegabytes - 30.mb
// 20mb
val timesValue = fiftyMegabytes * 2.4
// 120mb

// 1G文件 再增加2个50mb的数据空间
val fileSpace = fiftyMegabytes * 2 + 1.gb
RandomAccessFile("fileName","rw").use {
it.setLength(fileSpace.inWholeBytes)
it.write(...)
}
}

下面我们通过分析Duration源码了解原理,并且实现存储容量单位DataSize的换算和运算。


简单拆解Duration


kotlin没有提供,要做到上面的api那么我不会啊,但是我看到Duration可以做到,那我们来看看它的原理,进行仿写就行了。



  1. 枚举DurationUnit是用来定义时间不同单位,方便换算和转换的(详情看源码或上篇文)。

  2. Duration是如何做到不同单位的数据换算的,先看看Duration的创建函数和构造函数。toDuration把当前的值通过convertDurationUnit把时间换算成nanos或millis的值,再通过shl运算用来记录单位。
    //Long创建 Duration
    public fun Long.toDuration(unit: DurationUnit): Duration {
    //最大支持的 nanos值
    val maxNsInUnit = convertDurationUnitOverflow(MAX_NANOS, DurationUnit.NANOSECONDS, unit)
    //当前值如果在最大和最小值中间 表示不会溢出
    if (this in -maxNsInUnit..maxNsInUnit) {
    //创建 rawValue 是Nanos的 Duration
    return durationOfNanos(convertDurationUnitOverflow(this, unit, DurationUnit.NANOSECONDS))
    } else {
    //创建 rawValue 是millis的 Duration
    val millis = convertDurationUnit(this, unit, DurationUnit.MILLISECONDS)
    return durationOfMillis(millis.coerceIn(-MAX_MILLIS, MAX_MILLIS))
    }
    }
    // 用 nanos
    private fun durationOfNanos(normalNanos: Long) = Duration(normalNanos shl 1)
    // 用 millis
    private fun durationOfMillis(normalMillis: Long) = Duration((normalMillis shl 1) + 1)
    //不同os平台实现,肯定是 1小时60分 1分60秒那套算法
    internal expect fun convertDurationUnit(value: Long, sourceUnit: DurationUnit, targetUnit: DurationUnit): Long


  3. Duration是一个value class用来提升性能的,通过rawValue还原当前时间换算后的nanos或millis的数据value。为何不全部都用Nanos省去了这些计算呢,根据代码看应该是考虑了Nanos的计算会溢出。用一个long值可以还原构造对象前的所有参数,这代码设计真牛逼。
    @JvmInline
    public value class Duration internal constructor(private val rawValue: Long) : Comparable<Duration> {
    //原始最小单位数据
    private val value: Long get() = rawValue shr 1
    //单位鉴别器
    private inline val unitDiscriminator: Int get() = rawValue.toInt() and 1
    private fun isInNanos() = unitDiscriminator == 0
    private fun isInMillis() = unitDiscriminator == 1
    //还原的最小单位 DurationUnit对象
    private val storageUnit get() = if (isInNanos()) DurationUnit.NANOSECONDS else DurationUnit.MILLISECONDS


  4. Duration是如何做到算术运算的,是通过操作符重载实现的。不同单位Duration,持有的数据是同一个单位的那么是可以互相运算的,我们后面会着重介绍和仿写。

  5. Duration是如何做到逻辑运算的(>,<,>=,<=),构造函数实现了接口Comparable<Duration>重写了operator fun compareTo(other: Duration): Int,返回1,-1,0



Duration主要依靠对象内部持有的rawValue: Long,由于value的单位是“相同”的,就可以实现不同单位的换算和运算。



存储容量单位换算设计




  1. 存储容量的单位一般有比特(b),字节(B),千字节(KB),兆字节(MB),千兆字节(GB),太字节(TB),拍字节(PB),艾字节(EB),泽字节(ZB),尧字节(YB)
    ,考虑到实际应用和Long的取值范围我们最大支持PB即可。


    enum class DataUnit(val shortName: String) {
    BYTES("B"),
    KILOBYTES("KB"),
    MEGABYTES("MB"),
    GIGABYTES("GB"),
    TERABYTES("TB"),
    PETABYTES("PB")
    }



  2. 对于存储容量来说最小单位我们就定为Bytes,最大支持到PB,然后可以省去对数据过大的溢出的"单位鉴别器"设计。(注意使用pb时候,>= 8192.pb就会溢出)


    @JvmInline
    value class DataSize internal constructor(private val rawBytes: Long)



  3. 参照Duration在创建和最后单位换算时候都用到了convertDurationUnit函数,接受原始单位和目标单位。另外考虑到可能出现换算溢出使用Math.multiplyExact来抛出异常,防止数据计算异常无法追溯的问题。


    /** Bytes per Kilobyte.*/
    private const val BYTES_PER_KB: Long = 1024
    /** Bytes per Megabyte.*/
    private const val BYTES_PER_MB = BYTES_PER_KB * 1024
    /** Bytes per Gigabyte.*/
    private const val BYTES_PER_GB = BYTES_PER_MB * 1024
    /** Bytes per Terabyte.*/
    private const val BYTES_PER_TB = BYTES_PER_GB * 1024
    /** Bytes per PetaByte.*/
    private const val BYTES_PER_PB = BYTES_PER_TB * 1024

    internal fun convertDataUnit(value: Long, sourceUnit: DataUnit, targetUnit: DataUnit): Long {
    val valueInBytes = when (sourceUnit) {
    DataUnit.BYTES -> value
    DataUnit.KILOBYTES -> Math.multiplyExact(value, BYTES_PER_KB)
    DataUnit.MEGABYTES -> Math.multiplyExact(value, BYTES_PER_MB)
    DataUnit.GIGABYTES -> Math.multiplyExact(value, BYTES_PER_GB)
    DataUnit.TERABYTES -> Math.multiplyExact(value, BYTES_PER_TB)
    DataUnit.PETABYTES -> Math.multiplyExact(value, BYTES_PER_PB)
    }
    return when (targetUnit) {
    DataUnit.BYTES -> valueInBytes
    DataUnit.KILOBYTES -> valueInBytes / BYTES_PER_KB
    DataUnit.MEGABYTES -> valueInBytes / BYTES_PER_MB
    DataUnit.GIGABYTES -> valueInBytes / BYTES_PER_GB
    DataUnit.TERABYTES -> valueInBytes / BYTES_PER_TB
    DataUnit.PETABYTES -> valueInBytes / BYTES_PER_PB
    }
    }

    internal fun convertDataUnit(value: Double, sourceUnit: DataUnit, targetUnit: DataUnit): Double {
    val valueInBytes = when (sourceUnit) {
    DataUnit.BYTES -> value
    DataUnit.KILOBYTES -> value * BYTES_PER_KB
    DataUnit.MEGABYTES -> value * BYTES_PER_MB
    DataUnit.GIGABYTES -> value * BYTES_PER_GB
    DataUnit.TERABYTES -> value * BYTES_PER_TB
    DataUnit.PETABYTES -> value * BYTES_PER_PB
    }
    require(!valueInBytes.isNaN()) { "DataUnit value cannot be NaN." }
    return when (targetUnit) {
    DataUnit.BYTES -> valueInBytes
    DataUnit.KILOBYTES -> valueInBytes / BYTES_PER_KB
    DataUnit.MEGABYTES -> valueInBytes / BYTES_PER_MB
    DataUnit.GIGABYTES -> valueInBytes / BYTES_PER_GB
    DataUnit.TERABYTES -> valueInBytes / BYTES_PER_TB
    DataUnit.PETABYTES -> valueInBytes / BYTES_PER_PB
    }
    }



  4. 扩展属性和构造DataSize,rawBytes是Bytes因此所有的目标单位设置为DataUnit.BYTES,而原始单位就通过调用者告诉convertDataUnit


    fun Long.toDataSize(unit: DataUnit): DataSize {
    return DataSize(convertDataUnit(this, unit, DataUnit.BYTES))
    }
    fun Double.toDataSize(unit: DataUnit): DataSize {
    return DataSize(convertDataUnit(this, unit, DataUnit.BYTES).roundToLong())
    }
    inline val Long.bytes get() = this.toDataSize(DataUnit.BYTES)
    inline val Long.kb get() = this.toDataSize(DataUnit.KILOBYTES)
    inline val Long.mb get() = this.toDataSize(DataUnit.MEGABYTES)
    inline val Long.gb get() = this.toDataSize(DataUnit.GIGABYTES)
    inline val Long.tb get() = this.toDataSize(DataUnit.TERABYTES)
    inline val Long.pb get() = this.toDataSize(DataUnit.PETABYTES)

    inline val Int.bytes get() = this.toLong().toDataSize(DataUnit.BYTES)
    inline val Int.kb get() = this.toLong().toDataSize(DataUnit.KILOBYTES)
    inline val Int.mb get() = this.toLong().toDataSize(DataUnit.MEGABYTES)
    inline val Int.gb get() = this.toLong().toDataSize(DataUnit.GIGABYTES)
    inline val Int.tb get() = this.toLong().toDataSize(DataUnit.TERABYTES)
    inline val Int.pb get() = this.toLong().toDataSize(DataUnit.PETABYTES)

    inline val Double.bytes get() = this.toDataSize(DataUnit.BYTES)
    inline val Double.kb get() = this.toDataSize(DataUnit.KILOBYTES)
    inline val Double.mb get() = this.toDataSize(DataUnit.MEGABYTES)
    inline val Double.gb get() = this.toDataSize(DataUnit.GIGABYTES)
    inline val Double.tb get() = this.toDataSize(DataUnit.TERABYTES)
    inline val Double.pb get() = this.toDataSize(DataUnit.PETABYTES)



  5. 换算函数设计
    Duration用toLong(DurationUnit)或者toDouble(DurationUnit)来输出指定单位的数据,inWhole系列函数是对toLong(DurationUnit) 的封装。toLong和toDouble实现就比较简单了,把convertDataUnit传入输出单位,而原始单位就是rawValue的单位DataUnit.BYTES
    toDouble需要输出更加精细的数据,例如: 512mb = 0.5gb。


    val inWholeBytes: Long
    get() = toLong(DataUnit.BYTES)
    val inWholeKilobytes: Long
    get() = toLong(DataUnit.KILOBYTES)
    val inWholeMegabytes: Long
    get() = toLong(DataUnit.MEGABYTES)
    val inWholeGigabytes: Long
    get() = toLong(DataUnit.GIGABYTES)
    val inWholeTerabytes: Long
    get() = toLong(DataUnit.TERABYTES)
    val inWholePetabytes: Long
    get() = toLong(DataUnit.PETABYTES)

    fun toDouble(unit: DataUnit): Double = convertDataUnit(bytes.toDouble(), DataUnit.BYTES, unit)
    fun toLong(unit: DataUnit): Long = convertDataUnit(bytes, DataUnit.BYTES, unit)



操作符设计


在Kotlin 中可以为类型提供预定义的一组操作符的自定义实现,被称为操作符重载。这些操作符具有预定义的符号表示(如 + 或
*)与优先级。为了实现这样的操作符,需要为相应的类型提供一个指定名称的成员函数或扩展函数。这个类型会成为二元操作符左侧的类型及一元操作符的参数类型。


如果函数不存在或不明确,则导致编译错误(编译器会提示报错)。下面为常见操作符对照表:


操作符函数名说明
+aa.unaryPlus()一元操作 取正
-aa.unaryMinus()一元操作 取负
!aa.not()一元操作 取反
a + ba.plus(b)二元操作 加
a - ba.minus(b)二元操作 减
a * ba.times(b)二元操作 乘
a / ba.div(b)二元操作 除

算术运算支持



  1. 这里用算术运算符+实现来举例:假如DataSize对象需要重载操作符+
    val a = DataSize(); val c: DataSize = a + b


  2. 需要定义扩展函数1或者添加成员函数2
    1. operator fun DataSize.plus(other: T): DataSize {...}
    2. class DataSize { operator fun plus(other: T): DataSize {...} }


  3. 函数中的参数other: T表示b的对象类型,例如
    // val a: DataSize; val b: DataSize; a + DataSize()
    operator fun DataSize.plus(other: DataSize): DataSize {...}
    // val a: DataSize; val b: Int; a + 1
    operator fun DataSize.plus(other: Int): DataSize {...}


  4. 为了阅读性,Duration不会和同类型的对象乘除法运算,而使用了Int或Double,因此重载运算符用了operator fun times(scale: Int): Duration

  5. 那么在DataSize中我们也重载(+,-,*,/),并且(*,/)重载的参数只支持Int和Double即可
    operator fun unaryMinus(): DataSize {
    return DataSize(-this.bytes)
    }
    operator fun plus(other: DataSize): DataSize {
    return DataSize(Math.addExact(this.bytes, other.bytes))
    }

    operator fun minus(other: DataSize): DataSize {
    return this + (-other) // a - b = a + (-b)
    }

    operator fun times(scale: Int): DataSize {
    return DataSize(Math.multiplyExact(this.bytes, scale.toLong()))
    }

    operator fun div(scale: Int): DataSize {
    return DataSize(this.bytes / scale)
    }

    operator fun times(scale: Double): DataSize {
    return DataSize((this.bytes * scale).roundToLong())
    }

    operator fun div(scale: Double): DataSize {
    return DataSize((this.bytes / scale).roundToLong())
    }

    上面的操作符重载中minus(),我们使用了 plus()unaryMinus()重载组合a-b = a+(-b),这样我们可以多一个-DataSize的操作符


逻辑运算支持




  • (>,<,>=,<=)让DataSize构造函数实现了接口Comparable<DataSize>重写了operator fun compareTo(other: DataSize): Int,返回rawBytes对比值即可。




  • (==,!=)通过equals(other)函数实现的,value class默认为rawBytes的对比,可以通过java字节码看到。kotlin 1.9之前不支持重写value classs的equals和hashCode


    value class DataSize internal constructor(private val bytes: Long) : Comparable<DataSize> {
    override fun compareTo(other: DataSize): Int {
    return this.bytes.compareTo(other.bytes)
    }
    //示例
    600.mb > 0.5.gb //true
    512.mb == 0.5.gb




操作符重载的目的是为了提升阅读性,并不是所有对象为了炫酷都可以用操作符重载,滥用反而会增加代码的阅读难度。例如给DataSize添加*操作符,5mb * 2mb 就让人头大。



获取字符串形式


为了方便打印和UI展示,一般我们需要重写toSting。Duration的toSting不需要指定输出单位,可以详细的输出当前对象的字符串格式(1h 0m 45.677s)算法比较复杂。我不太会,就简单实现指定输出单位的toString(DataUnit)


 override fun toString(): String = String.format("%dB", rawBytes)

fun toString(unit: DataUnit, decimals: Int = 2): String {
require(decimals >= 0) { "decimals must be not negative, but was $decimals" }
val number = toDouble(unit)
if (number.isInfinite()) return number.toString()
val newDecimals = decimals.coerceAtMost(12)
return DecimalFormat("0").run {
if (newDecimals > 0) minimumFractionDigits = newDecimals
roundingMode = RoundingMode.HALF_UP
format(number) + unit.shortName
}
}

单元测试


功能都写好了需要验证期望的结果和实现的功能是否一直,那么这个时候就用单元测试最好来个100%覆盖。


class ExampleUnitTest {
@Test
fun data_size() {
val dataSize = 512.mb

println("format bytes:$dataSize")
// format bytes:536870912B
println("format kb:${dataSize.toString(DataUnit.KILOBYTES)}")
// format kb:524288.00KB
println("format gb:${dataSize.toString(DataUnit.GIGABYTES)}")
// format gb:0.50GB
// 单位换算
assertEquals(536870912, dataSize.inWholeBytes)
assertEquals(524288, dataSize.inWholeKilobytes)
assertEquals(512, dataSize.inWholeMegabytes)
assertEquals(0, dataSize.inWholeGigabytes)
assertEquals(0, dataSize.inWholeTerabytes)
assertEquals(0, dataSize.inWholePetabytes)
}

@Test
fun data_size_operator() {
val dataSize1 = 512.mb
val dataSize2 = 3.gb

val unaryMinusValue = -dataSize1 //取负数
println("unaryMinusValue :${unaryMinusValue.toString(DataUnit.MEGABYTES)}")
// unaryMinusValue :-512.00MB

val plusValue = dataSize1 + dataSize2 //+
println("plus :${plusValue.toString(DataUnit.GIGABYTES)}")
// plus :3.50GB

val minusValue = dataSize1 - dataSize2 // -
println("minus :${minusValue.toString(DataUnit.GIGABYTES)}")
// minus :-2.50GB

val timesValue = dataSize1 * 2 //乘法
println("times :${timesValue.toString(DataUnit.GIGABYTES)}")
// times :1.00GB

val divValue = dataSize2 / 2 //除法
println("div :${divValue.toString(DataUnit.GIGABYTES)}")
// div :1.50GB
}

@Test(expected = ArithmeticException::class)
fun data_size_overflow() {
8191.pb
8192.pb //溢出了不支持,如果要支持参考"单位鉴别器"设计
}

@Test
fun data_size_compare() {
assertTrue(600.mb > 0.5.gb)
assertTrue(512.mb == 0.5.gb)
}
}

总结


通过学习Kotlin Duration的源码,举一反三应用到储存容量单位转换和运算中。Duration中的拆解计算api,还有toSting算法实现就留给大家学习吧。当然了你也可以实现和Duration一样更加精细的"单位鉴别器"设计,支持bit、ZB、BB等大单位。


另外类似的进率场景也可以实现,用Kotlin通杀“一切进率换算”。比如Degrees角度计算 -90.0.degrees == 270.0.degrees;质量计算kg和磅,两等等1.kg == 2.20462262.lb;人民币汇率 (动态实现算法)8.dollar == 1.rmb 🐶


github 代码: github.com/forJrking/K…


操作符重载文档: book.kotlincn.net/text/operat…


作者:forJrking
来源:juejin.cn/post/7301145359852765218
收起阅读 »

MQTT客户端学习路线总结

本篇仅仅是记录一下MQTT学习的过程和感想,文字偏多 前言 总结一下MQTT协议的学习过程, 大概分为9步。 在IoT最热门时,有过一些了解,仅限名词解释。这次在为工厂装修设计时,涉及到了一些智能设备,也因此近距离接触到了MQTT协议相关的系统。虽然直接采...
继续阅读 »

本篇仅仅是记录一下MQTT学习的过程和感想,文字偏多



前言


总结一下MQTT协议的学习过程, 大概分为9步。


MQTT学习过程.jpg


在IoT最热门时,有过一些了解,仅限名词解释。这次在为工厂装修设计时,涉及到了一些智能设备,也因此近距离接触到了MQTT协议相关的系统。虽然直接采购的是成品(包含施工方案),但出于好奇和喜欢动手的本能,我想学习一下MQTT通信应用协议


使用


直接体验采购的智能设备,也算是使用,但总感觉少了点什么-感觉没有真正体验到MQTT协议通信。基于此种想法,翻阅MQTT环境搭建的指导文章,开始在自己的电脑上捣鼓安装MQTT客户端软件和MQTT服务器软件,一番折腾后,成功安装了MQTTXmosquitto


在MQTTX客户端上,看到可以成功的接收消息和发送消息,瞬间有种傻瓜式的成就感(我会用MQTT协议啦)。


体验完MQTTX,按照mosquitto官方指导,竟然发现它既可用作服务器同时还可用做客户端,在mac终端中急切的敲着发送主题的命令,在MQTTX上看到收到的消息,就一个感觉:呗爽。


对于一个新手,MQTTX和mosquitto的成就感促使我想继续阅读MQTT相关的文章,也因此从MQTT官网找到了Steve's Internet Guide博客


体验了MQTT软件和阅读了Steve's Internet Guide后,对运行一个客户端源码工程十分渴望,如此优秀的博客,配上程序运行时的日志,简直是学习MQTT的“下饭菜”。决定了就开干,从MQTT官网选型合适的MQTT协议实现库,最终我选定了Elipse paho


实践


Elipse paho共包含了17种版本,涉及多种语言(C语言,python, javascript, C++, golang, ruby, rust), 我实践学习用的是paho.mqtt.java版本。


用IntelliJ IDEA(社区版)创建一个属于自己的命令式应用MQTTHarvey, 将“org.eclipse.paho.mqttv5.client” 源码引入自己的应用。然后创建自己实践用入口代码(包括场景模拟和日志打印)。


最佳体验的方式:上手直接敲代码,调用核心功能API,看效果。如果API不熟,记住功能名称,疯狂的在掘金中搜索相关的介绍文章,比如:MQTT如何发送主题, MQTT如何订阅等等。


在首次成功运行已集成好源码的工程后,针对PUBLISH,SUBCRIBE需要先实践一遍(当然,最初我对实践这两个消息的称呼为:发送消息,接收消息).


消息的发送和接收源码在哪里?带着这个疑问,“胡乱一通”断点,终于找到了地方,接收消息的文件是MqttInputStream.java, 发送消息的文件是MqttOutputStream.java。


协议流到底是什么样子?能不能输出这些字节流,以观其全貌,知其结构。


协议初探


既然是协议,那必然有数据格式规范,编码后的数据按照字节流的方式进行传输,那么将字节流按照字节一个一个打印日志输出出来,就是协议的样子。我应该最先了解哪个协议样子呢?依据基础常识,MQTT客户端开始运行时,与服务端建立连接肯定是第一次联网操作,既然是这个样子,MQTT有没有关于联机的协议呢?经过一顿搜索,CONNECT 是关于客户端连接服务器的协议。那如何将其打印出来呢?因为都是字节流,又不了解协议规范,想要打印出来真的比较难。


正向研究协议在刚开始阶段,硬杠还是比较浪费时间的,甚至会打击继续学习的信心。后来我才用了一个比较讨巧的方式, 写一段只包含连接服务器的代码,就可以解决难以仅仅打印CONNECT协议的问题。


在二进制流打印完成后,在IDE控制台看到的日志,其实都是一个字节一个字节的字符串信息,很难以看懂。这个时候就需要拿出MQTT规范文档找到CONNECT协议的定义,然后手动尝试去解析每个字节,直到可以把字节都能和规范对上号,才可以证明对这个协议稍微搞懂了。


在手动完成CONNECT协议后,我就迫不及待的想看看消息发送协议,后来想了一下,没必要那么急,毕竟发送消息协议是如此的重要,肯定是比较复杂的。调整一下探究方向,一个新手,想要学习协议分析,从简单的协议入手,比如:断开连接,心跳。因此,我第二个分析的协议就是DISCONNECT,带着好奇的激情,最终完成了这个协议分析,那一天晚上睡觉时,感觉都是无比的开心。


解码


其实软件的职责就是能自动解决规范化的一些流程问题,数据格式问题。在协议初探时,还停留在手动分析字节流阶段,毕竟MQTT客户端如果应用在真实场景,自动解码字节流这样的功能,肯定是必备的。


既然在研究MQTT协议,那就需要拿出点诚意,自己写程序来解码字节流,然后将其拆解为规范中可描述的文字。


依然从简单的协议分析,然后再去分析复杂的。通过MQTT规范文档了解到,CONNECT,PING,DISCONNECT都是相对比较简单的,也容易写测试代码来完成解码实验场景。


在真正通过代码来解码CONNECT协议时,才发现固定头,可变头真的在用代码一步一步解码时,非常容易出错,因为是新手,再加上急于求成(毕竟已经会手动分析了),程序要么执行到一半就发生异常,要么在测试代码中稍微调整一下参数,程序就会崩溃。冷静下来后,发现还是要按照规范文档,一个属性一个属性往下研究,不能急躁。并且在这个过程中,发现自己对待MQTT规范不够重视,连数据类型都直接给忽略了,比如规范中的 “1.5 Data representation” 内容。因为没有重视它,导致在按照规范实现解码时,时常囫囵吞枣,自己认为是代表的是什么意思,就赶紧敲代码实现。


在刚开始对协议解码时,因为懒,所以只针对数据包的头部做了解码,完成了控制包类型1到14(控制包类型:“2.1.2 MQTT Control Packet type”)。完成之后,回看代码发现重复代码很多,分析完重复部分后,才发现像Reason Code,UTF-8 Encoded, Variable Byte Integer这些都是具有全局性的,即:可以把他们的解码分别做成公共部分。为了证实自己的这一点理解,赶紧翻看客户端源码是不是这样的,果不其然,理解正确。


工程分析


因为已经完成了一部分的解码工作,并且对MQTT规范阅读也已经上道,所以就想歇一歇,安静的学习一下客户端源码,它到底是如何实现发送接收消息的,它的代码是如何实现了每一条MQTT规范的。带着这些疑问,先确定程序执行每个控制包的方法调用流程,然后确定运行时的线程数,最终再分析代码之间的依赖关系。


代码跟踪是枯燥的,看别人将协议实现的如此漂亮,深深的受了打击。


每天偶尔看看源码,想象是自己在维护它,熟练的记住每个API,让自己的信心慢慢恢复。


术语理解


有了阅读MQTT规范的技能,自己解码的能力和分析源码之后,有种放空茫然的感觉。MQTT到底是什么,我如何描述它,它在布道时,是如何宣传的,等等?


可能要解决上述疑惑,需要找MQTT官方资料认真学习一下,然后再看看中文是如何教授的。


因此,我从MQTT官网找到HIVEMQ发布的MQTT基础文章,整个系列有十部分内容,然后再逐字逐句翻译,通过翻译,让自己产生疑问,然后再带着疑问去阅读MQTT规范,如果还是无法理解,再通过代码做实验。总之,硬着头皮也要将MQTT规范中的术语或者别人对MQTT的描述理解清楚。


场景模拟


在完成HIVEMQ基础文章的翻译之后,算得上对MQTT有点感觉了,也因此想要将自己的实践测试代码,能不能按照使用场景,分别实现一遍。



场景



  • 连接 -> 断开 -> 重连

  • 连接 -> 订阅 -> 解除订阅

  • 连接 -> 心跳

  • 连接 -> 恢复会话

  • 等等



为什么做这样的事情,我是基于2个原因:1. 我对代码库API及参数使用不熟 2. 提前模拟这些场景,对实战中发生的故障分析,肯定有指导作用


MQTT协议实现


通过一系列的学习和实践,如果真的已经搞懂了MQTT,那么我应该自己可以实现一个简化版的MQTT客户端


比如:实现最简化的功能,连接broker服务器


graph TD
建立Socket --> 发送CONNECT协议 --> 解析CONNACK

当然,自研一个MQTT客户端,从个人来讲,确实对技术能力提升有很大帮助,从公司来讲,那就是Money(比如:杭州映云科技有限公司)。


扩展


短时间内是否真的可以搞懂MQTT?难。协议规范纯理论学习是可以慢慢搞的十分清楚的,但MQTT最终是为了解决生活中实际的通信问题的,那就意味网络原因,数据安全也好,都可能让一个开发人员耗费大量的时间去排查定位问题。基于此种考虑,想要提高技能,增加增经验,可能需要建立问题库,及查看其他人或者公司在使用MQTT过程中的问题列表,并且尝试思考是否能给出解决方案。


作者:harvey_fly
来源:juejin.cn/post/7278953365224734774
收起阅读 »

Android 属性系统入门

这是一个介绍 Android 属性系统的系列文章: Android 属性系统入门(本文) 属性文件生成过程分析 如何添加系统属性 属性与 Selinux 属性系统整体框架与启动过程分析 属性读写过程源码分析 本文基于 AOSP android-10.0.0...
继续阅读 »

这是一个介绍 Android 属性系统的系列文章:



  • Android 属性系统入门(本文)

  • 属性文件生成过程分析

  • 如何添加系统属性

  • 属性与 Selinux

  • 属性系统整体框架与启动过程分析

  • 属性读写过程源码分析


本文基于 AOSP android-10.0.0_r41 版本讲解


在 Android 系统中,为统一管理系统的属性,设计了一个统一的属性系统,每个属性都是一个 key-value 对。
我们可以通过 shell 命令,Native 函数接口,Java 函数接口的方式来读写这些 key-vaule 对。


属性在哪里?


init 进程在启动会去加载后缀为 .prop 的属性文件, 将属性文件中的属性加载到共享内存中, 这样系统就有了默认的一些属性。


属性文件都在哪里呢?


属性文件的后缀绝大部分都是 prop,我们可以在 Android 模拟器的 shell 环境下搜索:


find . -name "*.prop"

/default.prop
/data/local.prop
/system/build.prop
/system/product/build.prop
/vendor/build.prop
/vendor/odm/etc/build.prop
/vendor/default.prop

我们看看 /default.prop 属性文件的内容:


cat /default.prop

#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.actionable_compatible_property.enabled=true
ro.postinstall.fstab.prefix=/system
ro.secure=0
ro.allow.mock.location=1
ro.debuggable=1
debug.atrace.tags.enableflags=0
dalvik.vm.image-dex2oat-Xms=64m
dalvik.vm.image-dex2oat-Xmx=64m
dalvik.vm.dex2oat-Xms=64m
dalvik.vm.dex2oat-Xmx=512m
dalvik.vm.usejit=true
dalvik.vm.usejitprofiles=true
dalvik.vm.dexopt.secondary=true
dalvik.vm.appimageformat=lz4
ro.dalvik.vm.native.bridge=0
pm.dexopt.first-boot=extract
pm.dexopt.boot=extract
pm.dexopt.install=speed-profile
pm.dexopt.bg-dexopt=speed-profile
pm.dexopt.ab-ota=speed-profile
pm.dexopt.inactive=verify
pm.dexopt.shared=speed
dalvik.vm.dex2oat-resolve-startup-strings=true
dalvik.vm.dex2oat-max-image-block-size=524288
dalvik.vm.minidebuginfo=true
dalvik.vm.dex2oat-minidebuginfo=true
ro.iorapd.enable=false
tombstoned.max_tombstone_count=50
persist.traced.enable=1
ro.com.google.locationfeatures=1
ro.setupwizard.mode=DISABLED
persist.sys.usb.config=adb

可以看出属性确实是一些 key-value 对。


init 进程会调用 property_load_boot_defaults 函数来加载属性文件:


void property_load_boot_defaults(bool load_debug_prop) {
// TODO(b/117892318): merge prop.default and build.prop files int0 one
// We read the properties and their values int0 a map, in order to always allow properties
// loaded in the later property files to override the properties in loaded in the earlier
// property files, regardless of if they are "ro." properties or not.
std::map<std::string, std::string> properties;
if (!load_properties_from_file("/system/etc/prop.default", nullptr, &properties)) {
// Try recovery path
if (!load_properties_from_file("/prop.default", nullptr, &properties)) {
// Try legacy path
load_properties_from_file("/default.prop", nullptr, &properties);
}
}
load_properties_from_file("/system/build.prop", nullptr, &properties);
load_properties_from_file("/vendor/default.prop", nullptr, &properties);
load_properties_from_file("/vendor/build.prop", nullptr, &properties);
if (SelinuxGetVendorAndroidVersion() >= __ANDROID_API_Q__) {
load_properties_from_file("/odm/etc/build.prop", nullptr, &properties);
} else {
load_properties_from_file("/odm/default.prop", nullptr, &properties);
load_properties_from_file("/odm/build.prop", nullptr, &properties);
}
load_properties_from_file("/product/build.prop", nullptr, &properties);
load_properties_from_file("/product_services/build.prop", nullptr, &properties);
load_properties_from_file("/factory/factory.prop", "ro.*", &properties);

if (load_debug_prop) {
LOG(INFO) << "Loading " << kDebugRamdiskProp;
load_properties_from_file(kDebugRamdiskProp, nullptr, &properties);
}

for (const auto& [name, value] : properties) {
std::string error;
if (PropertySet(name, value, &error) != PROP_SUCCESS) {
LOG(ERROR) << "Could not set '" << name << "' to '" << value
<< "' while loading .prop files" << error;
}
}

property_initialize_ro_product_props();
property_derive_build_fingerprint();

update_sys_usb_config();
}

从源码中我们也可以看到 init 进程加载了哪些属性文件以及加载的顺序。


属性长什么样?


每一个属性是一个 key-value 对:


ro.actionable_compatible_property.enabled=true
ro.postinstall.fstab.prefix=/system
ro.secure=0
ro.allow.mock.location=1
ro.debuggable=1
debug.atrace.tags.enableflags=0
dalvik.vm.image-dex2oat-Xms=64m
dalvik.vm.image-dex2oat-Xmx=64m

等号左边是属性的名字,等号右边是属性的值


属性的分类:



  • 一般属性:普通的 key-value 对,没有其他功能,系统启动后,如果修改了某个属性值(仅修改了内存中的值,未写入到文件),再重启系统,修改的值不会被保存下来,读取到的仍是修改前的值

  • 特殊属性

    • 属性名称以 ro 开头,那么这个属性被视为只读属性。一旦设置,属性值不能改变。

    • net 开头的属性,顾名思义,就是与网络相关的属性,net 属性中有一个特殊的属性:net.change,它记录了每一次最新设置和更新的 net 属性,也就是每次设置和更新 net,属性时则会自动的更新 net.change 属性,net.change 属性的 value 就是这个被设置或者更新的 net 属性的 name。例如我们更新了属性 net.bt.name 的值,由于 net 有属性发生了变化,那么属性服务就会自动更新 net.change,将其值设置为 net.bt.name

    • persist 为开头的属性值,当在系统中通过 setprop 命令设置这个属性时,就会在 /data/property/ 目录下会保存一个副本。这样在系统重启后,按照加载流程这些 persist 属性的值就不会消失了。

    • 属性 ctrl.startctrl.stop 是用来启动和停止服务。这里的服务是指定义在 rc 后缀文件中的服务。当我们向 ctrl.start 属性写入一个值时,属性服务将使用该属性值作为服务名找到该服务,启动该服务。这项服务的启动结果将会放入 init.svc.<服务名> 属性中,可以通过查询这个属性值,以确定服务是否已经启动。




如何读写属性:


命令行:


getprop "wlan.driver.status"
setprop "wlan.driver.status" "timeout"

Native 代码:


char buf[20]="qqqqqq";
char tempbuf[PROPERTY_VALUE_MAX];
property_set("type_value",buf);
property_get("type_value",tempbuf,"0");

Java 代码:


String navBarOverride = SystemProperties.get("qemu.hw.mainkeys");
SystemProperties.set("service.bootanim.exit", "0");

属性的作用


常见的属性文件的作用如下:



参考资料



作者:阿豪讲Framework
来源:juejin.cn/post/7298645450555326464
收起阅读 »

底部弹出菜单原来这么简单

底部弹出菜单是什么 底部弹出菜单,即从app界面底部弹出的一个菜单列表,这种UI形式被众多app所采用,是一种主流的布局方式。 思路分析 我们先分析一下,这样一种UI应该由哪些布局组成?首先在原界面上以一小块区域显示界面的这种形式,很明显就是对话框Dial...
继续阅读 »

底部弹出菜单是什么


底部弹出菜单,即从app界面底部弹出的一个菜单列表,这种UI形式被众多app所采用,是一种主流的布局方式。


截屏2023-09-28 14.36.51.png


截屏2023-09-28 14.37.29.png


思路分析


我们先分析一下,这样一种UI应该由哪些布局组成?首先在原界面上以一小块区域显示界面的这种形式,很明显就是对话框Dialog做的事情吧!最底部是一个取消菜单,上面的功能菜单可以是一个,也可以是两个、三个甚至更多。所以,我们可以使用RecyclerView实现。需要注意一点的是,最上面那个菜单的样式稍微有点不一样,因为它上面是圆滑的,有圆角,这样的界面显示更加和谐。我们主要考虑的就是弹出对话框的动画样式,另外注意一点就是可以多支持几个语种,让框架更加专业,这里只需要翻译“取消”文字。


开始看代码


package dora.widget

import android.app.Activity
import android.app.Dialog
import android.view.Gravity
import android.view.LayoutInflater
import android.view.View
import android.view.WindowManager
import android.widget.TextView
import androidx.recyclerview.widget.DividerItemDecoration
import androidx.recyclerview.widget.RecyclerView
import com.chad.library.adapter.base.BaseQuickAdapter
import com.chad.library.adapter.base.listener.OnItemChildClickListener
import dora.widget.bean.BottomMenu
import dora.widget.bottomdialog.R

class DoraBottomMenuDialog : View.OnClickListener, OnItemChildClickListener {

private var bottomDialog: Dialog? = null
private var listener: OnMenuClickListener? = null

interface OnMenuClickListener {
fun onMenuClick(position: Int, menu: String)
}

fun setOnMenuClickListener(listener: OnMenuClickListener) : DoraBottomMenuDialog {
this.listener = listener
return this
}

fun show(activity: Activity, menus: Array<String>): DoraBottomMenuDialog {
if (bottomDialog == null && !activity.isFinishing) {
bottomDialog = Dialog(activity, R.style.DoraView_AlertDialog)
val contentView =
LayoutInflater.from(activity).inflate(R.layout.dview_dialog_content, null)
initView(contentView, menus)
bottomDialog!!.setContentView(contentView)
bottomDialog!!.setCanceledOnTouchOutside(true)
bottomDialog!!.setCancelable(true)
bottomDialog!!.window!!.setGravity(Gravity.BOTTOM)
bottomDialog!!.window!!.setWindowAnimations(R.style.DoraView_BottomDialog_Animation)
bottomDialog!!.show()
val window = bottomDialog!!.window
window!!.decorView.setPadding(0, 0, 0, 0)
val lp = window.attributes
lp.width = WindowManager.LayoutParams.MATCH_PARENT
lp.height = WindowManager.LayoutParams.WRAP_CONTENT
window.attributes = lp
} else {
bottomDialog!!.show()
}
return this
}

private fun initView(contentView: View, menus: Array<String>) {
val recyclerView = contentView.findViewById<RecyclerView>(R.id.dview_recycler_view)
val adapter = MenuAdapter()
val list = mutableListOf<BottomMenu>()
menus.forEachIndexed { index, s ->
when (index) {
0 -> {
list.add(BottomMenu(s, BottomMenu.TOP_MENU))
}
else -> {
list.add(BottomMenu(s, BottomMenu.NORMAL_MENU))
}
}
}
adapter.setList(list)
recyclerView.adapter = adapter
val decoration = DividerItemDecoration(contentView.context, DividerItemDecoration.VERTICAL)
recyclerView.addItemDecoration(decoration)
adapter.addChildClickViewIds(R.id.tv_menu)
adapter.setOnItemChildClickListener(this)
val tvCancel = contentView.findViewById<TextView>(R.id.tv_cancel)
tvCancel.setOnClickListener(this)
}

private fun dismiss() {
bottomDialog?.dismiss()
bottomDialog = null
}

override fun onClick(v: View) {
when (v.id) {
R.id.tv_cancel -> dismiss()
}
}

override fun onItemChildClick(adapter: BaseQuickAdapter<*, *>, view: View, position: Int) {
listener?.onMenuClick(position, adapter.getItem(position) as String)
dismiss()
}
}

类的结构不仅可以继承,还可以使用聚合和组合的方式,我们这里就不直接继承Dialog了,使用一种更接近代理的一种方式。条条大路通罗马,能抓到老鼠的就是好猫。这里的设计是通过调用show方法,传入一个菜单列表的数组来显示菜单,调用dismiss方法来关闭菜单。最后添加一个菜单点击的事件,把点击item的内容和位置暴露给调用方。


package dora.widget

import com.chad.library.adapter.base.BaseMultiItemQuickAdapter
import com.chad.library.adapter.base.viewholder.BaseViewHolder
import dora.widget.bean.BottomMenu
import dora.widget.bottomdialog.R

class MenuAdapter : BaseMultiItemQuickAdapter<BottomMenu, BaseViewHolder>() {

init {
addItemType(BottomMenu.NORMAL_MENU, R.layout.dview_item_menu)
addItemType(BottomMenu.TOP_MENU, R.layout.dview_item_menu_top)
}

override fun convert(holder: BaseViewHolder, item: BottomMenu) {
holder.setText(R.id.tv_menu, item.menu)
}
}

多类型的列表布局我们采用BRVAH,


implementation("io.github.cymchad:BaseRecyclerViewAdapterHelper:3.0.10")

来区分有圆角和没圆角的item条目。


<?xml version="1.0" encoding="utf-8"?>

<resources>
<style name="DoraView.AlertDialog" parent="@android:style/Theme.Dialog">
<!-- 是否启用标题栏 -->
<item name="android:windowIsFloating">true</item>
<item name="android:windowIsTranslucent">true</item>
<item name="android:windowNoTitle">true</item>

<!-- 是否使用背景半透明 -->
<item name="android:windowBackground">@android:color/transparent</item>
<item name="android:background">@android:color/transparent</item>
<item name="android:backgroundDimEnabled">true</item>
</style>

<style name="DoraView.BottomDialog.Animation" parent="Animation.AppCompat.Dialog">
<item name="android:windowEnterAnimation">@anim/translate_dialog_in</item>
<item name="android:windowExitAnimation">@anim/translate_dialog_out</item>
</style>
</resources>

以上是对话框的样式。我们再来看一下进入和退出对话框的动画。


translate_dialog_in.xml


<?xml version="1.0" encoding="utf-8"?>
<translate xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:duration="300"
android:fromXDelta="0"
android:fromYDelta="100%"
android:toXDelta="0"
android:toYDelta="0">

</translate>

translate_dialog_out.xml


<?xml version="1.0" encoding="utf-8"?>
<translate xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:duration="300"
android:fromXDelta="0"
android:fromYDelta="0"
android:toXDelta="0"
android:toYDelta="100%">

</translate>

最后给你们证明一下我是做了语言国际化的。
截屏2023-09-28 15.08.20.png


使用方式


// 打开底部弹窗
val dialog = DoraBottomMenuDialog()
dialog.setOnMenuClickListener(object : DoraBottomMenuDialog.OnMenuClickListener {
override fun onMenuClick(position: Int, menu: String) {
val intent = Intent(Intent.ACTION_VIEW)
intent.data = Uri.parse(url)
startActivity(intent)
}
})
dialog.show(this, arrayOf("外部浏览器打开"))

开源项目


github.com/dora4/dview…


作者:dora
来源:juejin.cn/post/7283516197487214611
收起阅读 »

从Kotlin中return@forEach了个寂寞

今天在Review(copy)同事代码的时候,发现了一个问题,想到很久之前,自己也遇到过这个问题,那么就来看下吧。首先,我们抽取最小复现代码。 (1..7).forEach { if (it == 3) { return@forEach...
继续阅读 »

今天在Review(copy)同事代码的时候,发现了一个问题,想到很久之前,自己也遇到过这个问题,那么就来看下吧。首先,我们抽取最小复现代码。


(1..7).forEach {
if (it == 3) {
return@forEach
}
Log.d("xys", "Num: $it")
}

�很简单的代码,我相信很多人都这样写过,实际上就是遍历的过程中,满足条件后就退出遍历,那么上面的代码,能实现这样的需求吗?我们来看下执行结果。


Num: 1
Num: 2
Num: 4
Num: 5
Num: 6
Num: 7

很遗憾,即使等于3之后就return了,但是然并卵,遍历依然继续执行了。相信很多写Kotlin的开发者都遇到过这个问题,其原因,还是在于语法的思维定势,我们在Kotlin的文档上,可以找到非常明确的解释。
kotlinlang.org/docs/return…


我们先来看下Kotlin中forEach的源码。


/**
* Performs the given [action] on each element.
*/

@kotlin.internal.HidesMembers
public inline fun Iterable.forEach(action: (T) -> Unit): Unit {
for (element in this) action(element)
}

�我们来提取下关键信息:



  • 内联函数

  • 高阶函数


发现了吗,由于高阶函数的存在,当你在高阶函数的闭包内「return」时,是结束的整个函数,当你使用「return@forEach�」时,是结束当前的闭包,所以,如果你像这样写:


(1..7).forEach {
if (it == 3) {
return
}
Log.d("xys", "Num: $it")
}

那么等于3之后,整个函数就被return了,那么如果你像文章开头这样写,那么等效于continue,因为你结束了当前的闭包,而这个闭包只是其中的一次遍历过程。那么我们要如何实现我们最初的需求呢?看到这样,答案其实已经呼之欲出了,那就是要return整个遍历的闭包。所以,官方也给出了解决方案,那就是外面套一层闭包:


run loop@{
(1..7).forEach {
if (it == 3) {
return@loop
}
Log.d("xys", "Num: $it")
}
}

写起来确实是麻烦一点,但这却是必不可少的过程,是引入闭包所带来的一点副作用。



当然这里不仅限于run,任何闭包都是可以的。


作者:xuyisheng
来源:juejin.cn/post/7243819009866235964
收起阅读 »

鸿蒙 AkrUI 零基础教程第一集

前言 各位同学有段时间没有见面 因为一直很忙所以就你没有去更新博客。最近有在学习这个鸿蒙的ark ui开发 因为鸿蒙不是发布了一个鸿蒙next的测试版本 明年会启动纯血鸿蒙应用 所以我就想提前给大家写一些博客文章 线性布局(Row/Column) 线性布局(L...
继续阅读 »

前言


各位同学有段时间没有见面 因为一直很忙所以就你没有去更新博客。最近有在学习这个鸿蒙的ark ui开发 因为鸿蒙不是发布了一个鸿蒙next的测试版本 明年会启动纯血鸿蒙应用 所以我就想提前给大家写一些博客文章


线性布局(Row/Column)


线性布局(LinearLayout)是开发中最常用的布局,通过线性容器RowColumn构建。线性布局是其他布局的基础,其子元素在线性方向上(水平方向和垂直方向)依次排列。线性布局的排列方向由所选容器组件决定,Column容器内子元素按照垂直方向排列,Row容器内子元素按照水平方向排列。根据不同的排列方向,开发者可选择使用Row或Column容器创建线性布局。这个比较像flutter里面线性布局 学过flutter的就比较容易理解


横向线性布局


image.png


纵向线性布局


image.png


基本概念



  • 布局容器:具有布局能力的容器组件,可以承载其他元素作为其子元素,布局容器会对其子元素进行尺寸计算和布局排列。

  • 布局子元素:布局容器内部的元素。

  • 主轴:线性布局容器在布局方向上的轴线,子元素默认沿主轴排列。Row容器主轴为横向,Column容器主轴为纵向。

  • 交叉轴:垂直于主轴方向的轴线。Row容器交叉轴为纵向,Column容器交叉轴为横向。

  • 间距:布局子元素的间距。


具体代码实现


横向线性布局


@Entry
@Component
struct Index {
build() {
Row() {
Column({ space: 20 }) {
Row().width('90%').height(50).backgroundColor(0xFF0000)
Row().width('90%').height(50).backgroundColor(0xFF0000)
Row().width('90%').height(50).backgroundColor(0xFF0000)
}.width('100%')
}
.height('100%')
}
}



image.png


纵向线性布局


@Entry
@Component
struct Index {
build() {
Row({ space: 35 }) {
Text('space: 35').fontSize(15).fontColor(Color.Gray)
Row().width('10%').height(150).backgroundColor(0xFF0000)
Row().width('10%').height(150).backgroundColor(0xFF0000)
Row().width('10%').height(150).backgroundColor(0xFF0000)
}.width('90%')
}
.height('100%')
}
}

image.png


布局子元素在交叉轴上的对齐方式


在布局容器内,可以通过alignItems属性设置子元素在交叉轴(排列方向的垂直方向)上的对齐方式。且在各类尺寸屏幕中,表现一致。其中,交叉轴为垂直方向时,取值为VerticalAlign类型,水平方向取值为HorizontalAlign
alignSelf属性用于控制单个子元素在容器交叉轴上的对齐方式,其优先级高于alignItems属性,如果设置了alignSelf属性,则在单个子元素上会覆盖alignItems属性。



  • HorizontalAlign.Start:子元素在水平方向左对齐


@Entry
@Component
struct Index {
build() {
Column({}) {
Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)

Column() {
}.width('80%').height(50).backgroundColor(0xD2B48C)

Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)
}.width('100%').alignItems(HorizontalAlign.Start).backgroundColor('rgb(242,242,242)')
}
}

image.png
HorizontalAlign.Center:子元素在水平方向居中对齐



@Entry
@Component
struct Index {
build() {
Column({}) {
Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)

Column() {
}.width('80%').height(50).backgroundColor(0xD2B48C)

Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)
}.width('100%').alignItems(HorizontalAlign.Center).backgroundColor('rgb(242,242,242)')
}
}

image.png



  • HorizontalAlign.End:子元素在水平方向右对齐



@Entry
@Component
struct Index {
build() {
Column({}) {
Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)

Column() {
}.width('80%').height(50).backgroundColor(0xD2B48C)

Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)
}.width('100%').alignItems(HorizontalAlign.End).backgroundColor('rgb(242,242,242)')
}
}

image.png


Row容器内子元素在垂直方向上的排列



  • VerticalAlign.Top:子元素在垂直方向顶部对齐。


@Entry
@Component
struct Index {
build() {
// VerticalAlign.Center:子元素在垂直方向居中对齐
Row({}) {
Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)

Column() {
}.width('20%').height(30).backgroundColor(0xD2B48C)

Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)
}.width('100%').height(200).alignItems(VerticalAlign.Top).backgroundColor('rgb(242,242,242)')

}
}

image.png



  • VerticalAlign.Center:子元素在垂直方向居中对齐



@Entry
@Component
struct Index {
build() {
// VerticalAlign.Bottom:子元素在垂直方向底部对齐。

Row({}) {
Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)

Column() {
}.width('20%').height(30).backgroundColor(0xD2B48C)

Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)
}.width('100%').height(200).alignItems(VerticalAlign.Center).backgroundColor('rgb(242,242,242)')


}
}

image.png



  • VerticalAlign.Bottom:子元素在垂直方向底部对齐


@Entry
@Component
struct Index {
build() {
// VerticalAlign.Bottom:子元素在垂直方向底部对齐
Row({}) {
Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)

Column() {
}.width('20%').height(30).backgroundColor(0xD2B48C)

Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)
}.width('100%').height(200).alignItems(VerticalAlign.Bottom).backgroundColor('rgb(242,242,242)')
}
}

image.png


布局子元素在主轴上的排列方式


在布局容器内,可以通过justifyContent属性设置子元素在容器主轴上的排列方式。可以从主轴起始位置开始排布,也可以从主轴结束位置开始排布,或者均匀分割主轴的空间


Column容器内子元素在主轴上的排列


justifyContent(FlexAlign.Start):元素在主轴方向首端对齐,第一个元素与行首对齐,同时后续的元素与前一个对齐



@Entry
@Component
struct Index {
build() {
//justifyContent(FlexAlign.Start):元素在主轴方向首端对齐,第一个元素与行首对齐,同时后续的元素与前一个对齐
Column({}) {
Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)

Column() {
}.width('80%').height(50).backgroundColor(0xD2B48C)

Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)
}.width('100%').height(300).backgroundColor('rgb(242,242,242)').justifyContent(FlexAlign.Start)
}
}

image.png


justifyContent(FlexAlign.Center):元素在主轴方向中心对齐,第一个元素与行首的距离与最后一个元素与行尾距离相同。



@Entry
@Component
struct Index {
build() {

//justifyContent(FlexAlign.Center):元素在主轴方向中心对齐,第一个元素与行首的距离与最后一个元素与行尾距离相同
Column({}) {
Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)

Column() {
}.width('80%').height(50).backgroundColor(0xD2B48C)

Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)
}.width('100%').height(300).backgroundColor('rgb(242,242,242)').justifyContent(FlexAlign.Center)
}
}

image.png



  • justifyContent(FlexAlign.End):元素在主轴方向尾部对齐,最后一个元素与行尾对齐,其他元素与后一个对齐


@Entry
@Component
struct Index {
build() {
//justifyContent(FlexAlign.Spacebetween):主轴方向均匀分配元素,相邻元素之间距离相同。第一个元素与行首对齐,最后一个元素与行尾对齐
Column({}) {
Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)

Column() {
}.width('80%').height(50).backgroundColor(0xD2B48C)

Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)
}.width('100%').height(300).backgroundColor('rgb(242,242,242)').justifyContent(FlexAlign.End)

}
}

image.png
justifyContent(FlexAlign.Spacebetween):主轴方向均匀分配元素,相邻元素之间距离相同。第一个元素与行首对齐,最后一个元素与行尾对齐。



@Entry
@Component
struct Index {
build() {
//justifyContent(FlexAlign.Spacebetween):主轴方向均匀分配元素,相邻元素之间距离相同。第一个元素与行首对齐,最后一个元素与行尾对齐

Column({}) {
Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)

Column() {
}.width('80%').height(50).backgroundColor(0xD2B48C)

Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)
}.width('100%').height(300).backgroundColor('rgb(242,242,242)').justifyContent(FlexAlign.SpaceBetween)
}
}

image.png


justifyContent(FlexAlign.SpaceAround):主轴方向均匀分配元素,相邻元素之间距离相同。第一个元素到行首的距离和最后一个元素到行尾的距离是相邻元素之间距离的一半。


@Entry
@Component
struct Index {
build() {
//justifyContent(FlexAlign.SpaceAround):主轴方向均匀分配元素,相邻元素之间距离相同。
// 第一个元素到行首的距离和最后一个元素到行尾的距离是相邻元素之间距离的一半。


Column({}) {
Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)

Column() {
}.width('80%').height(50).backgroundColor(0xD2B48C)

Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)
}.width('100%').height(300).backgroundColor('rgb(242,242,242)').justifyContent(FlexAlign.SpaceAround)


}
}

image.png


justifyContent(FlexAlign.SpaceEvenly):主轴方向均匀分配元素,相邻元素之间的距离、第一个元素与行首的间距、最后一个元素到行尾的间距都完全一样。


@Entry
@Component
struct Index {
build() {
//justifyContent(FlexAlign.SpaceEvenly):主轴方向均匀分配元素,
// 相邻元素之间的距离、第一个元素与行首的间距、最后一个元素到行尾的间距都完全一样
Column({}) {
Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)

Column() {
}.width('80%').height(50).backgroundColor(0xD2B48C)

Column() {
}.width('80%').height(50).backgroundColor(0xF5DEB3)
}.width('100%').height(300).backgroundColor('rgb(242,242,242)').justifyContent(FlexAlign.SpaceEvenly)


}
}

image.png


Row容器内子元素在主轴上的排列


justifyContent(FlexAlign.Start):元素在主轴方向首端对齐,第一个元素与行首对齐,同时后续的元素与前一个对齐



@Entry
@Component
struct Index {
build() {
//justifyContent(FlexAlign.Start):元素在主轴方向首端对齐,第一个元素与行首对齐,同时后续的元素与前一个对齐。
Row({}) {
Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)

Column() {
}.width('20%').height(30).backgroundColor(0xD2B48C)

Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)
}.width('100%').height(200).backgroundColor('rgb(242,242,242)').justifyContent(FlexAlign.Start)



}
}

image.png


justifyContent(FlexAlign.Center):元素在主轴方向中心对齐,第一个元素与行首的距离与最后一个元素与行尾距离相同



@Entry
@Component
struct Index {
build() {
// justifyContent(FlexAlign.Center):元素在主轴方向中心对齐,第一个元素与行首的距离与最后一个元素与行尾距离相同

Row({}) {
Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)

Column() {
}.width('20%').height(30).backgroundColor(0xD2B48C)

Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)
}.width('100%').height(200).backgroundColor('rgb(242,242,242)').justifyContent(FlexAlign.Center)

}
}

image.png


justifyContent(FlexAlign.Spacebetween):主轴方向均匀分配元素,相邻元素之间距离相同。第一个元素与行首对齐,最后一个元素与行尾对齐。



@Entry
@Component
struct Index {
build() {
// justifyContent(FlexAlign.End):元素在主轴方向尾部对齐,最后一个元素与行尾对齐,其他元素与后一个对齐。

Row({}) {
Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)

Column() {
}.width('20%').height(30).backgroundColor(0xD2B48C)

Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)
}.width('100%').height(200).backgroundColor('rgb(242,242,242)').justifyContent(FlexAlign.End)

}
}

image.png


justifyContent(FlexAlign.Spacebetween):主轴方向均匀分配元素,相邻元素之间距离相同。第一个元素与行首对齐,最后一个元素与行尾对齐


@Entry
@Component
struct Index {
build() {

//justifyContent(FlexAlign.Spacebetween):主轴方向均匀分配元素,相邻元素之间距离相同。第一个元素与行首对齐,最后一个元素与行尾对齐


Row({}) {
Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)

Column() {
}.width('20%').height(30).backgroundColor(0xD2B48C)

Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)
}.width('100%').height(200).backgroundColor('rgb(242,242,242)').justifyContent(FlexAlign.SpaceBetween)
}
}

image.png


justifyContent(FlexAlign.SpaceAround):主轴方向均匀分配元素,相邻元素之间距离相同。第一个元素到行首的距离和最后一个元素到行尾的距离是相邻元素之间距离的一半。



@Entry
@Component
struct Index {
build() {
//justifyContent(FlexAlign.SpaceAround):主轴方向均匀分配元素,相邻元素之间距离相同。第一个元素到行首的距离和最后一个元素到行尾的距离是相邻元素之间距离的一半

Row({}) {
Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)

Column() {
}.width('20%').height(30).backgroundColor(0xD2B48C)

Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)
}.width('100%').height(200).backgroundColor('rgb(242,242,242)').justifyContent(FlexAlign.SpaceAround)


}

}

image.png


justifyContent(FlexAlign.SpaceEvenly):主轴方向均匀分配元素,相邻元素之间的距离、第一个元素与行首的间距、最后一个元素到行尾的间距都完全一样


@Entry
@Component
struct Index {
build() {
//justifyContent(FlexAlign.SpaceEvenly):主轴方向均匀分配元素,相邻元素之间的距离、第一个元素与行首的间距、最后一个元素到行尾的间距都完全一样。

Row({}) {
Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)

Column() {
}.width('20%').height(30).backgroundColor(0xD2B48C)

Column() {
}.width('20%').height(30).backgroundColor(0xF5DEB3)
}.width('100%').height(200).backgroundColor('rgb(242,242,242)').justifyContent(FlexAlign.SpaceEvenly)
}

}

image.png


最后总结


arkui 写法和flutter非常的像 有兴趣的同学可以多尝试哈 今天的文章就讲到这里
。最后呢 希望我都文章能帮助到各位同学工作和学习 如果你觉得文章还不错麻烦给我三连 关注点赞和转发 谢谢


作者:xq9527
来源:juejin.cn/post/7301242165279047707
收起阅读 »

Android设置IPV4优先、httpdns使用

Android设置IPV4优先、httpdns使用 前言 最近接了个比较奇怪的BUG,就是服务器开了IPV6之后,部分安卓手机会访问不了,或者访问时间特别久,查了下是DNS会返回多个IP,但是IPV6地址会放在前面,比如: [ms.bdstatic.com/2...
继续阅读 »

Android设置IPV4优先、httpdns使用


前言


最近接了个比较奇怪的BUG,就是服务器开了IPV6之后,部分安卓手机会访问不了,或者访问时间特别久,查了下是DNS会返回多个IP,但是IPV6地址会放在前面,比如:


[ms.bdstatic.com/240e:95d:801:2::6fb1:624, ms.bdstatic.com/119.96.52.36]

然后取域名的时候默认会取第一个IP,然后就蛋疼了,有的机型、系统、运行商、路由器都可能不支持IPV6,然后访问不了。 由于iOS是没问题的,剩下来的肯定是Android的问题了。


于是我花了些时间看了看,做了个IPV4优先方案(还没用到生产环境),测试了下可行性,顺便又学了下httpdns的使用,这里记录下。


核心思路


网上找了资料,解决办法都是通过okhttp的自定义DNS去处理的(可以用Interceptor,不推荐),这个也是解决办法的核心:


class MyDns : Dns {
@Throws(UnknownHostException::class)
override fun lookup(hostname: String): List<InetAddress> {
return try {
val inetAddressList: MutableList<InetAddress> = ArrayList()
val inetAddresses = InetAddress.getAllByName(hostname)
Log.d("TAG", "lookup before: ${Arrays.toString(inetAddresses)}")
for (inetAddress in inetAddresses) {

// 将IPV4地址放到最前面
if (inetAddress is Inet4Address) {
inetAddressList.add(0, inetAddress)
} else {
inetAddressList.add(inetAddress)
}
}
Log.d("TAG", "lookup after: $inetAddressList")
inetAddressList
} catch (var4: NullPointerException) {
val unknownHostException = UnknownHostException("Broken system behavior")
unknownHostException.initCause(var4)
throw unknownHostException
}
}
}

上面自定义了一个DNS,里面的lookup就是okhttp查找DNS的逻辑,前面我okhttp源码的文章也有说到,默认会取第一个inetAddress,下面看下如何使用:


val client = OkHttpClient.Builder()
.dns(DnsInterceptor.MyDns())
.build()

// 异步请求下百度
client.newCall(Request.Builder().url(originalUrl).build()).enqueue(
object : Callback {
override fun onFailure(call: Call, e: IOException) {
Log.d("TAG", "onFailure: ")
}

override fun onResponse(call: Call, response: Response) {
Log.d("TAG", "onResponse: $response")
}
}
)

看下log,第一个是我WiFi访问的,不支持IPV6,第二个是我用iPhone开热点访问的,支持IPV6:
dd.png


cc.png


ps. Android手机可以设置使用IPV6:



华为手机: 设置->移动网络->移动数据->接入点名称(APN)->新建一个APN,配置中的APN协议及APN漫游协议设置为仅ipv4或ipv6.



WebView内使用


okhttp好办,可是我们APP是套壳webView的,Android请求不多,大部分还是HttpURLConnection的,HttpURLConnection找了资料也不太好改,还不如改逻辑换成okhttp,但是webView就没得办法了。


好在API-21后,WebViewClient提供了新的shouldInterceptRequest方法,可以让我们代理它的请求操作,不过有很多限制操作。


shouldInterceptRequest方法


先来看下shouldInterceptRequest方法,它要求API大于等于21:


binding.webView.webViewClient = object : WebViewClient() {
override fun shouldInterceptRequest(
view: WebView?,
request: WebResourceRequest
)
: WebResourceResponse? {
// ...
}
}

方法会提供一个request携带一些请求信息,要求我们返回一个WebResourceResponse,将代理的请求结果封装进去。鸡肋的就是这两个类东西都不多,会限制我们的代理功能:
dd.png


image.png


功能封装


这里我把代理功能封装了一下,可能还有问题,请谨慎参考:


import android.os.Build
import android.text.TextUtils
import android.util.Log
import android.webkit.WebResourceRequest
import android.webkit.WebResourceResponse
import android.webkit.WebView
import okhttp3.Dns
import okhttp3.Headers
import okhttp3.OkHttpClient
import okhttp3.Request
import java.net.Inet4Address
import java.net.InetAddress
import java.net.UnknownHostException
import java.nio.charset.Charset
import java.util.Arrays

object DnsInterceptor {

/**
* 设置okhttpClient
*/

lateinit var client: OkHttpClient

/**
* 拦截webView请求
*/

fun shouldInterceptRequest(
view: WebView?,
request: WebResourceRequest
)
: WebResourceResponse? {
// WebResourceRequest Android6.0以上才支持header,不支持body所以只能拦截GET方法
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP
&& request.method.lowercase() == "get"
&& (request.url.scheme?.lowercase() == "http"
|| request.url.scheme?.lowercase() == "https")) {

// 获取头部
val headersBuilder = Headers.Builder()
request.requestHeaders.entries.forEach {
headersBuilder.add(it.key, it.value)
}
val headers = headersBuilder.build()

// 生成okhttp请求
val newRequest = Request.Builder()
.url(request.url.toString())
.headers(headers)
.build()

// 同步请求
val response = client.newCall(newRequest).execute()

// 对于无mime类型的请求不拦截
val contentType = response.body()?.contentType()
if (TextUtils.isEmpty(contentType.toString())) {
return null
}

// 获取响应头
val responseHeaders: MutableMap<String, String> = HashMap()
val length = response.headers().size()
for (i in 0 until length) {
val name = response.headers().name(i)
val value = response.headers().get(name)
if (null != value) {
responseHeaders[name] = value
}
}

// 创建新的response
return WebResourceResponse(
"${contentType!!.type()}/${contentType.subtype()}",
contentType.charset(Charset.defaultCharset())?.name(),
response.code(),
"OK",
responseHeaders,
response.body()?.byteStream()
)
} else {
return null
}
}

/**
* 优先使用ipv4
*/

class MyDns : Dns {
@Throws(UnknownHostException::class)
override fun lookup(hostname: String): List<InetAddress> {
return try {
val inetAddressList: MutableList<InetAddress> = ArrayList()
val inetAddresses = InetAddress.getAllByName(hostname)
Log.d("TAG", "lookup before: ${Arrays.toString(inetAddresses)}")
for (inetAddress in inetAddresses) {
if (inetAddress is Inet4Address) {
inetAddressList.add(0, inetAddress)
} else {
inetAddressList.add(inetAddress)
}
}
Log.d("TAG", "lookup after: $inetAddressList")
inetAddressList
} catch (var4: NullPointerException) {
val unknownHostException = UnknownHostException("Broken system behavior")
unknownHostException.initCause(var4)
throw unknownHostException
}
}
}
}

把大部分操作封装到一个单例类去了,然后在webView使用的时候就可以这样写:


// 创建okhttp
val client = OkHttpClient.Builder().dns(DnsInterceptor.MyDns()).build()
DnsInterceptor.client = client

// 配置webView
val webSettings = binding.webView.settings
webSettings.javaScriptEnabled = true //启用js,不然空白
webSettings.domStorageEnabled = true //getItem报错解决
binding.webView.webViewClient = object : WebViewClient() {
override fun shouldInterceptRequest(
view: WebView?,
request: WebResourceRequest
)
: WebResourceResponse? {
try {
// 通过okhttp拦截请求
val response = DnsInterceptor.shouldInterceptRequest(view, request)
if (response != null) {
return response
}
}catch (e: Exception) {
// 可能有异常,发生异常就不拦截: UnknownHostException(MyDns)
e.printStackTrace()
}
return super.shouldInterceptRequest(view, request)
}
}

binding.button.setOnClickListener {
binding.webView.loadUrl(binding.ip.text.toString())
}

试了下,访问百度没啥问题


存在问题


上面方法虽然代理webView去发请求了,不过这里有好多限制:



  1. 需要API21以上,大部分机型应该满足

  2. 只能让GET请求优先使用IPV4,其他请求方法改不了

  3. 不支持MIME类型为空的响应

  4. 不支持contentType中,无法获取到编码的非二进制文件请求

  5. 不支持重定向


网上文章比较少,有几篇我看还都差不多,最后一对比,竟然是阿里云httpdns里面的说明,这里我也不太详叙了,看下文章吧:


Android端HTTPDNS+Webview最佳实践


HTTPDNS使用


上面修改DNS顺序的操作,实际和HTTPDNS的思路是一样的,看到相关内容后,触发了我知识的盲区,觉得还是有必要去学一学的。


HTTPDNS的作用就是代替本地的DNS解析,通过http请求访问httpdns的服务商,先拿到IP,再发起请求,可以防劫持,并且更快,当然这都是我简单的理解,可以看下阿里对它产品的介绍:



help.aliyun.com/document_de…



阿里HTTPDNS


这里我是选的阿里的httpdns服务,开通方式还是看他们自己的说明吧,不是很复杂: 服务开通


下面就来看如何使用,首先是添加依赖:


// setting.gradle.kts中
dependencyResolutionManagement {
repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
repositories {
maven{ url = uri("./catalog_repo") }
maven {
url = uri("http://maven.aliyun.com/nexus/content/repositories/releases/")
name = "aliyun"
//一定要添加这个配置
isAllowInsecureProtocol = true
}
}
}

// 要使用的module中
implementation 'com.aliyun.ams:alicloud-android-httpdns:2.3.2'

这里是kts的依赖,groovy语法类似,gradle7.0以下甚至加个url就行。


再来看下具体使用,我在阿里云的后台配置了百度的域名(”http://www.baidu.com“),这里就来请求百度的IP:


val httpdns = HttpDns.getService(getContext(), "xxx")
// 预加载
httpdns.setPreResolveHosts(ArrayList(listOf("www.baidu.com")))

val originalUrl = "http://www.baidu.com"
val url = URL(originalUrl)
val ip = httpdns.getIpByHostAsync(url.host)
Log.d("TAG", "httpdns get init: ip = $ip")

这样使用我这直接就失败了,拿到的ip为null,所以初始化的操作应该要提前一点做:


// 点击事件
binding.button.setOnClickListener {
val ipClick = httpdns.getIpByHostAsync(url.host)
val ipv6 = httpdns.getIPv6sByHostAsync(url.host).let {
if (it.isNotEmpty()) return@let it[0]
else return@let "not get"
}
Log.d("TAG", "httpdns get: ip = $ipClick, ipv6 = $ipv6")
}

后面我把获取操作放到点击事件里面,就没问题了,也能拿到IPV6地址:
dd.png


这里要注意下,如果切换网络,IPV6的地址会有缓存,谨慎使用吧(网络可能不支持了):
dd.png


httpdns的使用应该算网络优化了吧,看别人文章说dns查找域名有的要几百毫秒,用httpdns可能只要一百毫秒,有机会来研究研究源码^_^


小结


稍微总结下吧,这篇文章分析了一下IPV6在Android上出错的原因,实践了下IPV4优先的思路,并且对webView做了支持,还研究了下httpdns的使用。


作者:方大可
来源:juejin.cn/post/7301573790342414351
收起阅读 »

IT界惊现文豪!华为领导及阿里P10遭吐槽!

来源:网络一篇奇文出现在某匿名社交软件,引起了大家对文豪的赞口不绝。先发原图:一遍好文一定少不了精彩评论写这么好,应该不是偶然,原来这位文豪之前也有关于P10的大作,分享给各位小伙伴以上只是工作之余的一点乐趣,仅供娱乐。真正的P10,还确实是挺厉害的,只不过他...
继续阅读 »

来源:网络

一篇奇文出现在某匿名社交软件,引起了大家对文豪的赞口不绝。

先发原图:

一遍好文一定少不了精彩评论

写这么好,应该不是偶然,

原来这位文豪之前也有关于P10的大作,分享给各位小伙伴

以上只是工作之余的一点乐趣,仅供娱乐。

真正的P10,还确实是挺厉害的,只不过

他的厉害,懂得人并不多,

因为懂得人至少也得P9!

作者:程序员直聘
来源:mp.weixin.qq.com/s/Fw0s7uE76a2h2opHRGVUfg

收起阅读 »

技术人该如何准备晋升答辩?

前言 大家好,我是路由器没有路。今天跟大家聊下关于技术人该如何准备晋升答辩的话题。 每到年中或者年底,都会有一波晋升答辩潮。所以在这个时间点,想跟大家聊聊我的个人经验,以及一些对技术人该如何准备晋升的一些启发。 在公司里,我曾参与过各个职级的晋升答辩,也见到过...
继续阅读 »

前言


大家好,我是路由器没有路。今天跟大家聊下关于技术人该如何准备晋升答辩的话题。


每到年中或者年底,都会有一波晋升答辩潮。所以在这个时间点,想跟大家聊聊我的个人经验,以及一些对技术人该如何准备晋升的一些启发。


在公司里,我曾参与过各个职级的晋升答辩,也见到过各种各样的答辩现场。就在前阵子,公司部门刚结束了年中职级晋升答辩,我也花了不少时间在团队成员的答辩辅导上。今天我就把一些晋升答辩的技巧和常见的坑跟大家说说,希望能够在晋升之路上对你有所启发。


争取获得答辩机会


现在很多公司都有完善的员工职级晋升管理制度。职级晋升的答辩当然是少不了的了。既然是答辩,就会涉及答辩内容及现场答辩发挥,每一个环节都不容忽视。


也有一些公司的年中或年度晋升是需要在时间范围内先自主提报的,也就是说每个人都有机会,但有些公司是按提名制的,需要你自己去争取答辩机会。下面我们就来说说怎样才能获得提名资格:



  • 自身能力能够达到了下一个职级的要求。但有些人可能会认为,要晋升了之后才需要具备下一个职级的能力,这观点是不正确的。

  • 公司对人才的要求具备高度的确定性。通常不会冒太大风险去晋升能力不确定的人。因此,你可以提前参考目标职级的要求或同事,关注他们的技术深度和业务能力。

  • 主动找领导沟通,确定努力发展方向。对发展方向制定可落地的措施。其实上级对于希望得到成长的员工都是非常欢迎的。



接下来,在争取获得答辩晋升机会后,就可以着手为答辩做准备了。


准备答辩素材


说到述职晋升答辩,当然少不了一份晋升汇报的 PPT。那么该如何准备晋升答辩素材呢?内容当然是包含近一年来的工作成果。


在答辩时,晋升答辩评委通常是跨团队或跨部门的领导。他们往往是不了解你工作成果的业务背景和技术实现细节,因此你需要在短时间内将业务背景、工作成果介绍清楚,这对不善演讲的技术人来说确实有比较大的挑战。


有人可能会说,平时是不是需要记录项目素材呀,我只能说,关系不太大。答辩素材是需要你去实践并产生的,而并非是靠记录。所以我建议,如果有机会,要尽可能多的去参与比较有挑战的项目建设,当然这可能开发难度较大、工作量大、比较累,但相比简单的项目则更容易创造价值、得到收获。


当然如果你没有参与过这种项目,那么你也可以对项目或者线上问题的点作技术深挖


比如线上有这么个问题:经常性的发生 CPU 占用突然飙高,停顿一两秒后又恢复正常。或者内存间歇性的发生 OOM 了。虽然这对业务影响不算大,很多人可能也不会在意和处理这种问题,最多重启下服务,恢复正常就好,但是如果你去深挖问题背后产生的原因,找到问题的根源和涉及的底层技术点,并在团队内部给大家分享。


这就是很有价值的内容,因为你不仅主动的解决了看似不起眼问题,而且还通过分享的方式让其他同事也明白其中的原因,帮助了其他同学的成长。


根据素材,编写答辩 PPT


在上面准备了答辩素材案例之后,接下来需要根据准备好的素材,编写答辩素材 PPT。这里有几个需要遵循的原则:



  1. 在讲述结果的同时,需要把问题点和解决方式也讲清楚。比如在这一年里,你负责了一个大型项目,并成功完成了上线。切记在 PPT 里花大篇幅介绍项目是什么,以及项目成功上线这一结果。因为评委无法通过结果评估你的能力和价值。所以,在介绍素材时,首先要介绍背景,然后介绍这个项目案例中存在哪些问题,你是如何解决的?

  2. 结果要有价值和数据体现。说到结果时,很多人习惯讲解项目如期上线等内容,但在评委看来,这是基本的要求,并不是加分项。正确的做法是通过一些上线后的数据说话。比如介绍上线后的系统性能、数据质量等相关内容。这里强调一点,很多研发同学习惯写上线后的一些业务数据。如新增用户数带来的金额、收入等,这类数据其实与产品、业务同学联系更紧密一些。研发应该更多的把关注点应放在技术层面上。

  3. 素材要匹配晋升的职级定位。像只有苦劳的内容,比如在赶工期的项目里,加班加点的保证他如期上线,且获得了领导认可等,建议不要写,原因很简单,就是不能体现你的技术价值,这些活,说不好听点,刚毕业的同学都可以完成。



晋升答辩素材 PPT 的一些建议


这里和大家分享下编写晋升答辩 PPT 的一些建议,可以参考一下:



  1. PPT 的基本格式要统一。答辩的 PPT 的内容不要太过绚丽。除了要保证基本的工整,细节也很重要,一定要注意审查错字。有些评委会认为错字多,可能写代码 bug 也多。还要注意统一字号,不要一页字大一页字小。此外,还要避免过多动画。注意控制字数,重要的内容标红、加粗。答辩一般都是集中评审,评委一天要评审,很多人没有耐心看太多字。把你想要表达的重点内容标红加粗,这样评委才能快速吸收。

  2. 不要放一张大而全的架构图。很多同学都习惯在 PPT 里放一张大家全的架构图。但在答辩时,你只讲解了其中的一小部分。你可能会认为大而全的架构图可以彰显自己系统的完善性。但如果你只讲解了其中一二,其实是很难讲出价值内容,毕竟时间有限,反而容易给评委留下浮于表面的形象。你可以对自己负责实现的那个模块单独拿出来讲,可以采用更优雅的方式进行展现,就具体问题的架构,加上细节问题描述,代替大而全的架构图,才能让评委快速了解问题的背景和解决方法,进而更好的评判你到底做的好还是不好。

  3. PPT 上不要露马脚。我曾经遇到过答辩人在 PPT 中写了幂等两个字,我想他写出来的目的是想表示如何实现它,但评委一直对这个点穷追不舍,导致答辩人最终答辩挂了。你写在 PPT 上的每一个字都需要十分熟悉,每一个内容都可能是地雷。


要写答辩稿并加以练习


写完 PPT 后,在正式答辩前的这段时间里,可以不断的加强练习。在练习时也有以下几个建议:



  1. 写出答辩稿。很多人没有写答辩稿的习惯,撰写文字稿能够帮助你发现答辩的逻辑是否通畅,还能够框定你的表达内容。咱们前面提到过,答辩是有时间限制的,如果没有固定的稿子,每次发挥的时长都不一样,最后很容易因为超时影响答辩效果。

  2. 你要准确按照答辩的时间完整练习至少十遍以上,注意是完整练习。非完整的零碎练习和完整的练习节奏差别非常大。

  3. 做预答辩。不同公司的晋升评委组成不同,有的是管理者,有的是技术专家,还有的是管理者加技术专家。因此,在做预答辩练习时,最好邀请相对应的人员辅导你答辩,比如选择你的 leader,相信部门 leader 还是比较乐意的。


调整答辩心态


在答辩将至时,大家都会跟你说,答辩时不要紧张,会影响发挥。但过来人都知道,不紧张好像太难了。下面就说说具体有什么方式可以抑制紧张。



  • 首先还是上一节的内容,答辩稿必须写出来,跟着稿子来。人在紧张时,智力和反应能力会呈指数级下滑。没有预先练习,顺溜的稿子你是临场发挥不出来的,只能满嘴跑火车或者照着 PPT 念,效果会大打折扣。

  • 一个能够避免紧张的好办法是做最坏假设。紧张是因为想通过晋升,你可以想象一下此次晋升没有通过的场景,你会怎样对待这个答辩结果,如果最坏的结果你都接纳了,还有什么是不能面对的呢?这也能反过来激励你好好准备。

  • 回答问题要言简意赅。一般答辩时都会设提问环节,很多时候答辩演讲的很好,但回答差,也会被一票否决,这种情况就比较可惜。作为过来人,我在这里给你提个醒,评委比较喜欢回答问题,言简意赅,直达重点的人印象分都比较高,你可以换位思考一下,评委提了一天的答辩,理解能力也下降的厉害,如果你半天收不到点子上,评委可能会认为你知识储备和逻辑能力薄弱。

  • 不会的问题不要直接回答不知道。如果评委临场抛出了一个较难的问题,你可以短暂思考,尝试从几个角度简单回答一下,一定不要直接回答不知道。


总结


最后用一句话总结下:有些人工作五年,但只有一年的经验,但有些人工作一年却拥有了五年经验,那是因为一直在学习、思考和总结


希望这篇文章能够对你在晋升道路上有所帮助。


作者:路由器没有路
来源:juejin.cn/post/7243248407535468600
收起阅读 »

如何做大促压测

一.背景&目标 1.1 常见的压测场景 电商大促:一众各大厂的促销活动场景,如:淘宝率先推出的天猫双11,而后京东拉出的京东 618 .还是后续陆陆续续的一些年货节, 3.8 女神节等等.都属于一些常规的电商大促 票务抢购:常见的如承载咱们 8...
继续阅读 »

一.背景&目标


1.1 常见的压测场景




  • 电商大促:一众各大厂的促销活动场景,如:淘宝率先推出的天猫双11,而后京东拉出的京东 618 .还是后续陆陆续续的一些年货节, 3.8 女神节等等.都属于一些常规的电商大促




  • 票务抢购:常见的如承载咱们 80,90 青春回忆的 Jay 的演唱会,还有普罗大众都参与的 12306 全民狂欢抢票.




  • 单品秒杀:往年被小米抢购秒杀带起来的红米抢购,还有最近这几年各大电商准点的茅台抢购;过去这三年中抢过的口罩,酒精等.这都属于秒杀的范畴.




  • toB 私有化服务:这个场景相对特殊.但是随着咱们 toC 的业务饱和,很多软件服务商也开始做 toB 的业务. toB 的业务特点其中有一个相对比较特别的就是存在私有化部署的诉求.主要的一些目的也是基于一些数据安全,成本这些因素来考虑的.




如上是在工作过程接触到的一些场景,书不尽言.下面就针对这些场景做一个压测的的梳理.


1.2 目标


  稳是第一位的,不久前某猫厂云事故,以及刚出现的某雀文档事故,历历在目.从大了说,整个产品的公信力被质疑将是后续用户是否持续购买的最大障碍;往小了说咱们这些小兵严重就是直接被离职,直接决定房贷,车贷下个月能不能交上的事情.所以除了稳,我们没别的.


WX20231115-101734@2x.png


  那其实从实际场景来说,除了稳定性是我们要求的第一位.还有一个整体的成本也是常用来被考虑的.所以压测的目标就是在稳定性和成本中间尽可能做一个权衡.


  如上在这些场景中前三的这种场景优先都是以稳定性是第一位,特别是电商大促,涉及的流程和各模块繁杂.在具体实施的过程中尽可能的去保证稳定性,资源优先度可以先往后放一放.


  其中稳定性的部分.我理解有两个部分.首先是面对峰值流量的时候的稳定性,一个是整个系统全链路的系统业务流程的稳定性.如:整体的交易的黄金流程.保证从用户的商详,购物车,结算,订单,支付都能够完整的走下来,这是业务流程的稳定性.


  最后一个私有化的场景相对比较特殊,更多的是一个私域的流量场景,流量相比公域要少的多.这时候尽可能要去压榨机器的性能,在尽可能少的资源成本下去提供更多的流量支持.因为成本就直接面临了产品的竞争力.


二.流程


    将流程划分为三个阶段压测前的一些前置准备;压测进行过程中的主要是测试和研发的具体的配合操作,以及监控观测;压测后的一些结果沉淀以及复盘,优化,复压.


2.1 压测前


2.1.1 流量预估


    这个是压测前第一项工作也是非常重要的一项工作,直接决定了本次压测的一个目标,而目标的准确制定就决定了本次的压测的最终目的---保证大促的稳定的直接成功与否.所以这里的流量预估显得非常重要.一般来说的话常用的有这两种形式.




  • 流量同比规则粗估


    如: 2012年6月1日 42w(qps) , 2013年6月1日 24w(qps) .同比下滑 42% .在得到 2012年11月1日 49w(qps) .以此推算 2013年11月1日 49w*0.57=28w .这是一个大概的量,如果压测的话按照这个量上浮 20% .压测按照 28*1.2= 34(w).




  • GMV 原则预估




从业务侧拿到2013年11月1日 11.11dau 的预估的量. 比如: dau 相比 618 的增长 1.2 倍.从监控里得到 618 的查车的量 20w ,占比 40% .得到整体流量为 50w. 得到 11.11 整体的量 50w*1.2 得到整体双 11 的量为 60w . 如果压测的话按照这个量上浮 ** 20%** .压测按照 60*1.2=72(w)
.


2.1.2 限流对齐以及配置


  限流毋庸置疑都是需要配置的,防止系统在承载能力之外的流量冲击下直接崩溃,造成xue'peng


2.1.2.1 限流配置原则


在整个流量预估完成之后,各模块基本上可以基于所域系统服务在流量预估的数值来进行设置.来保证峰值以上的一些突发情况也能够在系统承受范围.


2.1.2.2 限流的配置



  • 单机维度


一般单机房维度设置限流有两个方面. cpu 维度和 qps 维度.



  • 机房维度


每个机房的压测流量不一样,如张北,中云信.需要根据机房来进行限流配置,因为一般场景下优先保障同机房调用.


2.1.2.3 机器配置



  • 单机核心配置


机器配置.16c32g 50G SAS硬盘. SAS [既有的机械硬盘升级]


export maxParameterCount="10000"
export acceptCount="1000"
export maxSpareThreads="750"
export maxThreads="1000"
export minSpareThreads="50"
export URIEncoding="UTF-8"
export JAVA_OPTS=" -Xms16384m -Xmx16384m -XX:MaxMetaspaceSize=512m -XX:MetaspaceSize=512m -XX:ConcGCThreads=4 -XX:ParallelGCThreads=16 -Djava.library.path=/usr/local/lib -server -Xmn4096m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses -XX:+CMSClassUnloadingEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75 -XX:+CMSScavengeBeforeRemark "


  • 集群机房资源配比及配置


2.1.2.4 监控配置


监控配置主要分两个方面.
本身系统的机器的物理监控.
主要的指标[ CPU 使用率, load 负载.内存使用率,磁盘使用率, TCP 重传,连通性.].示例如下:
在这里插入图片描述



  • 接口服务监控.主要指标.



调用次数(秒级,分钟级),平均响应时长,TP99,TP999,可用率.示例如下:
在这里插入图片描述


核心的监控面板:


1.自身系统依赖的服务接口监控面板.
2.常见上游/自身/下游error状态码监控面板.
3.自身系统核心接口监控面板


2.1.3 流量切割



  • 入口流量切割


  从域名到压测机器的流量,保证生产环境和压测环境进行流量切分



  • *DB *流量切割


  一般通过识别压测上下文指标的路由标,来判定是否需要重新切换数据源.这个技术很常见.常见的做法就是通过 AbstractRoutingDataSource 的重写来实现 determineCurrentLookupKey 方法来切换数据源.动态数据源切割.压测的数据源一般会重新 copy 一遍现有的数据库 schema 建立一个影子库,保证线上数据不受影响,有时候为了压测还需要进行一些线上数据的一些冲入,保证测试场景的完整进行.



  • MQ 流量切割


  主要是消费和发送都需要增加识别压测标来进行消息的发送和消息的消费.如:原有 topic .rd_product_add ,通过识别 isForceBot

标来增加 rd_product_add_shadow .



  • cache 流量切割


  方案基本同上.通过识别标来具体使用具体的 cacheClient 不同.



  • 其他的中间件具体改造


如: es,ck,blink 等.


   如上的流量切割后要进行小流量的试跑来保证改造的方案是可行的.防止出现压测过程的流量逃逸.影响线上真实的环境,污染生产数据等.


2.1.4 压测前的机器状态检查


   这一步主要是 check 机器指标异常的,主要指标有 CPU, 硬盘, 内存, 连通性.防止一些特别的机器造成压测一直压不上去.出现指标异常的机器进行流量摘除的处理或者重启能消除隐患也可以继续使用.


2.1.5 测试的数据&脚本准备



  • 数据准备


  这里的数据准备要充分的模拟生产的环境数据,例如:加车的数据多样性每个维度都要充分的添加到.常见的加车数量6-10.
常见的重要的生产数据模拟.用户数据,订单数据,产品数据,购物车数据.



  • 脚本
      要保证基本的用例case能通


2.2 压测中


2.2.1 单场景压测


特定的场景压测,比如商详.这种场景下的压测因为是单场景的,所以在压测过程中不能够按照打满的场景去操作.比如说:整体商详压测的目标机器 cpu 目标是 60% .单场景的时候可能要留一些 buffer 去给全链路的场景做一些预留.


2.2.2 全链路压测


2.2.3 故障演练


通过演练做到面对故障时的响应机制.目标:完成3分钟内发现,5分钟内应急处理.10分钟定位原因.
大致分为这几个方面.


2.2.3.1 系统及硬件


系统方面涉及: CPU ,硬盘, TCP 重传,内存,磁盘可用率.
JVM :频繁 GC ,高频 YGC .
应对预案:快速通过监控平台完成具体IP机器定位,通过IP摘除流量完成,机器流量下线.通知运维定位原因. JVM 相关 DUMP 响应日志进行分析.


2.2.3.1 中间件相关演练


  在服务中间件出现异常时系统能够正常提供服务,对应接口的指标能够满足目标要求.常见的中间件故障.
存储类: ES,DB,cache.
中间件: MQ
应对预案:中间件能够做到手动预案热备数据源切换,缓存中间件降级. MQ 停止消费等.


2.2.3.2 上下游服务异常演练


  通过观察上下游服务监控面板快速定位上下游接口超时.
应对预案:非核心链路接口,主动通过开关进行降级.核心链路接口快速联系上下游进行相关原因排查.


2.6 限流演练



  • 单机限流演练
      在日常qps 平均值的前提上浮一些,保证生产的正常流量能够进行正常访问而不会触发限流.

  • 集群演练


2.3 压测后



  • 压测后机器挂载流量回切

  • 压测复盘


2.3.1 压测优化



  • 代码优化

  • 资源扩缩容

  • 针对场景复压测


2.3.2 压测其他收官



  • 完成压测报告

  • 沉淀操作手册

  • 沉淀压测记录

  • 动态扩缩容规则确认,资源确认

  • 流量回切


   如果在整个压测过程中是使用的同样的生产环境,保证压测后机器及时归还线上.避免影响线上集群性能和用户体验.


三.压测中遇到的问题


3.1 硬件相关


   首先定位具体硬件 IP 地址,优先进行流量摘取.出现大面积故障时同时保留现场同时立即联系运维同学协助排查定位.


3.2 接口相关


   首先通过接口监控得到相关接口的tp99avg,观测到实际的接口耗时已经影响主接口的调用时,进行主动的开关降级做到不影响主接口和核心逻辑.


3.3 其他



  • tomcat 6 定期主动回收问题
    tomcat6.0.33为防止内存泄露周期性每 1 小时触发 1 次System.gc(),导致tp周期性波动。tomcat源码JreMemoryLeakPreventionListener fullgc触发位置:
    在这里插入图片描述
    修复方案:从fullgc平均耗时200ms左右来看,fullgc耗时引发接口超时导致图文详情h5超时风险较小。计划618后升级tomcat版本解决。


作者:柏修
来源:juejin.cn/post/7300845951865290767
收起阅读 »

如何在 SwiftUI 中实现音频图表

iOS
前言 在可访问性方面,图表是复杂的事物之一。iOS 15 引入了一项名为“音频图表”的新功能。 下面我们将学习如何通过使用 accessibilityChartDescriptor 视图修饰符为任何 SwiftUI 视图构建音频表示,呈现类似自定义条形图视图或...
继续阅读 »

前言


在可访问性方面,图表是复杂的事物之一。iOS 15 引入了一项名为“音频图表”的新功能。


下面我们将学习如何通过使用 accessibilityChartDescriptor 视图修饰符为任何 SwiftUI 视图构建音频表示,呈现类似自定义条形图视图或图像的图表。


DataPoint 结构体


让我们从在 SwiftUI 中构建一个简单的条形图视图开始,该视图使用垂直条形显示一组数据点。


struct DataPoint: Identifiable {
let id = UUID()
let label: String
let value: Double
let color: Color
}

在这里,我们有一个 DataPoint 结构,用于描述条形图视图中的条形。它具有 id、标签、数值和填充颜色。


BarChartView 结构体


接下来,我们可以定义一个条形图视图,它接受一组 DataPoint 结构体实例并将它们显示出来。


struct BarChartView: View {
let dataPoints: [DataPoint]

var body: some View {
HStack(alignment: .bottom) {
ForEach(dataPoints) { point in
VStack {
RoundedRectangle(cornerRadius: 8, style: .continuous)
.fill(point.color)
.frame(height: point.value * 50)
Text(point.label)
}
}
}
}
}

如上例所示,我们有一个 BarChartView,它接收一组 DataPoint 实例并将它们显示为水平堆栈中不同高度的圆角矩形。


ContentView 结构体


我们能够在 SwiftUI 中轻松构建条形图视图。接下来让我们尝试使用带有示例数据的新 BarChartView


struct ContentView: View {
@State private var dataPoints = [
DataPoint(label: "1", value: 3, color: .red),
DataPoint(label: "2", value: 5, color: .blue),
DataPoint(label: "3", value: 2, color: .red),
DataPoint(label: "4", value: 4, color: .blue),
]

var body: some View {
BarChartView(dataPoints: dataPoints)
.accessibilityElement()
.accessibilityLabel("Chart representing some data")
}
}

在这里,我们创建了一组 DataPoint 实例的示例数组,并将其传递给 BarChartView。我们还为图表创建了一个可访问元素,并禁用了其子元素的可访问性信息。为了改进图表视图的可访问性体验,我们还添加了可访问性标签。


最后,我们可以开始为我们的条形图视图实现音频图表功能。音频图表可以通过旋钮菜单获得。要使用旋钮,请在 iOS 设备的屏幕上旋转两个手指,就像您在拨盘。VoiceOver 会说出第一个旋钮选项。继续旋转手指以听到更多选项。松开手指选择音频图表。然后在屏幕上上下滑动手指以导航。


音频图表允许用户使用音频组件理解和解释图表数据。VoiceOver 在移动到图表视图中的条形时播放具有不同音调的声音。VoiceOver 对于更大的值使用高音调,对于较小的值使用低音调。这些音调代表数组中的数据。


实现协议


现在,我们可以讨论在 BarChartView 中实现此功能的方法。首先,我们必须创建一个符合 AXChartDescriptorRepresentable 协议的类型。AXChartDescriptorRepresentable 协议只有一个要求,即创建 AXChartDescriptor 类型的实例。AXChartDescriptor 类型的实例表示我们图表中的数据,以 VoiceOver 可以理解和交互的格式呈现。


extension ContentView: AXChartDescriptorRepresentable {
func makeChartDescriptor() -> AXChartDescriptor {
let xAxis = AXCategoricalDataAxisDescriptor(
title: "Labels",
categoryOrder: dataPoints.map(\.label)
)

let min = dataPoints.map(\.value).min() ?? 0.0
let max = dataPoints.map(\.value).max() ?? 0.0

let yAxis = AXNumericDataAxisDescriptor(
title: "Values",
range: min...max,
gridlinePositions: []
) { value in "\(value) points" }

let series = AXDataSeriesDescriptor(
name: "",
isContinuous: false,
dataPoints: dataPoints.map {
.init(x: $0.label, y: $0.value)
}
)

return AXChartDescriptor(
title: "Chart representing some data",
summary: nil,
xAxis: xAxis,
yAxis: yAxis,
additionalAxes: [],
series: [series]
)
}
}

我们所需做的就是符合 AXChartDescriptorRepresentable 协议,并添加 makeChartDescriptor 函数,该函数返回 AXChartDescriptor 的实例。


首先,我们通过使用 AXCategoricalDataAxisDescriptorAXNumericDataAxisDescriptor 类型定义 X 轴和 Y 轴。我们希望在 X 轴上使用字符串标签,这就是为什么我们使用 AXCategoricalDataAxisDescriptor 类型的原因。在线图的情况下,我们将在两个轴上都使用 AXNumericDataAxisDescriptor 类型。


实现线图


接下来,我们使用 AXDataSeriesDescriptor 类型定义图表中的点。有一个 isContinuous 参数,允许我们定义不同的图表样式。例如,对于条形图,它应该是 false,而对于线图,它应该是 true。


struct ContentView: View {
@State private var dataPoints = [
DataPoint(label: "1", value: 3, color: .red),
DataPoint(label: "2", value: 5, color: .blue),
DataPoint(label: "3", value: 2, color: .red),
DataPoint(label: "4", value: 4, color: .blue),
]

var body: some View {
BarChartView(dataPoints: dataPoints)
.accessibilityElement()
.accessibilityLabel("Chart representing some data")
.accessibilityChartDescriptor(self)
}
}

作为最后一步,我们使用 accessibilityChartDescriptor 视图修饰符将符合 AXChartDescriptorRepresentable 协议的实例设置为描述我们图表的实例。


示例截图:



总结


音频图表功能对于视力受损的用户来说是一项重大改进。音频图表功能的好处是,可以将其用于任何您想要的视图,甚至包括图像视图。只需创建 AXChartDescriptor 类型的实例。


作者:Swift社区
来源:juejin.cn/post/7301496834232401959
收起阅读 »

如何优雅地创建对象?

1. 写在前头 大家好,我是方圆,最近读完了《Effective Java 第三版》,准备把其中可供大家一起学习的点来分享出来。 这篇博客儿主要是关于建造者模式在创建对象时的应用,这已经成了我现在写代码的习惯,它在灵活性和代码整洁程度上,都让我十分满意。以下的...
继续阅读 »

1. 写在前头


大家好,我是方圆,最近读完了《Effective Java 第三版》,准备把其中可供大家一起学习的点来分享出来。


这篇博客儿主要是关于建造者模式在创建对象时的应用,这已经成了我现在写代码的习惯,它在灵活性和代码整洁程度上,都让我十分满意。以下的内容非常的长,也是我费尽心力去完成的一篇博客儿,从初次应用建造者模式,到发现Lombok方便的注解,最后深挖Lombok的源码,大家既可以简单的学会它的应用,也可以从源码的角度来弄清楚它为什么是这样儿,就看你有什么需求了!


那,我们开始吧!


2. Java Beans创建对象


先创建一个Student类做准备,包含如下五个字段,姓名,年龄,爱好,性别和介绍


public class Student {

private String name;

private Integer age;

private String hobby;

/**
* 性别 0-女 1-男
*/

private Integer sex;

/**
* 介绍
*/

private String describe;

}

2.1 最常见的创建对象方式



  • 直接new一个对象,之后逐个set它的值,比如我们现在需要一个芳龄23岁的男生叫小明


Student xm = new Student();
xm.setName("小明");
xm.setAge(23);
xm.setSex(1);


  • 四行代码看着好多,我现在想让代码好看一些,一行就把这个对象创建出来,那就,添加个构造函数呗


// Student中添加构造函数
public Student(String name, Integer age, Integer sex) {
this.name = name;
this.age = age;
this.sex = sex;
}

// 一行一个小明
Student xm2 = new Student("小明", 23, 1);

这下看着是舒心多了,一行代替了之前的四行代码



  • 又来新需求了,创建一个对象,只要年龄和姓名,不要性别了,如果还要使用一行代码的话,我们又需要维护一个构造方法


// Student中添加构造函数
public Student(String name, Integer age) {
this.name = name;
this.age = age;
}

// 一行一个小明
Student xm3 = new Student("小明", 23);

两个构造方法,维护起来感觉还好...



  • 但是,需求接连不断,“再给我来一个只有名字的小明!”,“我还要一个有名字,有爱好的小明”,“我还要...”


有没有发现点儿什么,也就是说,只要创建包含不同字段的对象,都需要维护一个构造方法,五个字段最多维护“5 x 4 x 3 x 2 x 1...” 个构造方法,这才仅仅是五个字段,现在想想如果每打开一个实体类文件映入眼帘的是无数个构造方法,我就...


image.png


所以这个弊端很明显,Java Beans创建对象会让代码行数很多,一行set一个属性,不美观,而采用了构造方法创建对象之后,又要对构造方法进行维护,代码量大增,难道代码美观和少代码量不能兼得吗?


3. effective Java说:用建造者模式创建对象


我先直接把代码写好,再一点点给大家讲


public class Student {

private String name;

private Integer age;

private String hobby;

/**
* 性别 0-女 1-男
*/

private Integer sex;

/**
* 介绍
*/

private String describe;

// 注意这里添加了一个private的构造函数,建造者字段和实体字段一一对应赋值
private Student(Builder builder) {
this.name = builder.name;
this.age = builder.age;
this.hobby = builder.hobby;
this.sex = builder.sex;
this.describe = builder.describe;
}

// 静态方法创建建造者对象
public static Builder builder() {
return new Builder();
}

/**
* 采用建造者模式,每个字段都有一个设置字段的方法
* 且返回值为Builder,能进行链式编程
*/

public static class Builder {
private String name;
private Integer age;
private String hobby;
private Integer sex;
private String describe;

// 私有构造方法
private Builder() {
}

public Builder name(String val) {
this.name = val;
return this;
}

public Builder age(Integer val) {
this.age = val;
return this;
}

public Builder hobby(String val) {
this.hobby = val;
return this;
}

public Builder sex(Integer val) {
this.sex = val;
return this;
}

public Builder describe(String val) {
this.describe = val;
return this;
}

public Student build() {
return new Student(this);
}
}

}


  • 需要注意的点:




  1. 为Student添加了一个private的构造函数,参数值为Builder,建造者字段和实体字段在构造函数中一一对应赋值




  2. 建造者中对每个字段都添加一个方法,且返回值为建造者本身,这样才能进行链式编程




3.1 这下能自如应对对象创建


// 创建一个23岁的小明
Student xm4 = Student.builder().name("小明").age(23).build();
// 创建一个男23岁小明
Student xm5 = Student.builder().name("小明").age(23).sex(1).build();
// 创建一个喜欢写代码的小明
Student xm6 = Student.builder().name("小明").hobby("代码").build();
// ...

3.2 新添加字段怎么办?



  • 如果要新增一个国籍的字段,不光要在实体类中添加,还需要在建造者中添加对应的字段方法,而且还要更新实体类的构造方法


// 实体类和建造者中均新增字段
private String country;

// 建造者中添加对应方法
public Builder country(String val) {
this.country = val;
return this;
}

// 更新实体类的构造方法
private Student(Builder builder) {
this.name = builder.name;
this.age = builder.age;
this.hobby = builder.hobby;
this.sex = builder.sex;
this.describe = builder.describe;
// 新增赋值代码
this.country = builder.country;
}

完成如上工作就可以创建对象为country赋值了


Student xm7 = Student.builder().name("小明").country("中国").build();



  • 那,建造者模式的好处又有什么? 难道不是既有了JavaBeans创建对象的可读性避免了繁重的代码量吗?




  • 题外话: 在我刚使用如上建造者模式创建对象的时候,觉得分分钟能吊打Java Beans创建对象的代码,也乐此不疲的为我要使用的实体类进行维护,但是也正所谓“凡事都很难经得住时间的磨砺”,当发现了更好的方法后,我变懒了!




4. Lombok的@Builder注解


4.1 注解带来的代码整洁



  • 在类上注解标注@Builder注解,会自动生成建造者的代码,且和上述用法一致,而且不需要再为新增字段特意维护代码,也太香了吧...


@Data
@Builder
public class Student {
...
}


  • 所以可以直接标注@Builder注解使用建造者模式创建对象(使用方法和上文中3.1节一致)


4.2 你可能听说过@Accessors要比@Builder灵活



  • @Builder在创建对象时具有链式赋值的特点,但是在创建对象后,就不能链式赋值了,虽然toBuilder注解属性可以返回一个新的建造者,并复用对象的成员变量值,但是这并不是在原对象上进行修改,调用完build方法后,会返回一个新的对象


// 在@Builder注解中,指定属性toBuilder = true
@Builder(toBuilder = true)

// 在创建完成对象后使用toBuilder方法获取建造者,指定新的属性值创建对象
Student xm7 = Student.builder().name("小明").country("中国").build();

Student xm8 = xm7.toBuilder().age(23).build();


  • @Accessors注解可以在原对象上进行赋值,这里先解读一下@Accessors的源码,方便对下面的用法理解


/**
* @Accessors注解是不能单独使用的,单独标记不会产生任何作用
* 需要搭配@Data或者@Getter@Setter使用才能生效
*/

@Target({ElementType.TYPE, ElementType.FIELD})
@Retention(RetentionPolicy.SOURCE)
public @interface Accessors {
/**
* 这个属性默认是false,为false时,getter和setter方法会有get和set前缀
* 什么意思呢,比如字段name,在该属性为false生成的get和set方法为getName和setName
* 而当属性为true时,就没有没有get和set前缀,get方法和set方法都名为name,只不过set方法要有参数,是对name方法的重载
*/

boolean fluent() default false;

/**
* chain属性,显然从字面意思它能实现链式编程,默认属性false
* 为true时,setter方法的返回值是该对象,那么我们就能进行链式编程了
* 为false时,setter的返回值为void,就不能进行链式编程了
*
* 注意:特殊的一点是,当fluent属性为true时,该值在不指定的情况下也会为true
*/

boolean chain() default false;

/**
* 这个属性值当我们指定的时候,会将字段中已经匹配到的前缀进行'删除'后生成getter和setter方法
* 但是它也有生效条件:字段必须是驼峰式命名,且前几个小写字母与我们指定的前缀一致
*
* 举个例子:
* 我们有一个字段如下
* private String lastName
* 在我们不指定prefix时,生成的getter和setter方法为 getLastName 和 setLastName
* 当我们指定prefix为last时,那么生成的getter和setter方法 为 getName 和 setName
*/

String[] prefix() default {};
}


  • 下面我们来看看用法,它实在是很灵活


// 我们为Student类标记一个如下注解,方法不含get和set前缀,同时又支持链式编程
@Accessors(fluent = true, chain = true)

// 这里我们创建一个25岁的小明
Student xm9 = new Student().age(25).name("小明");
// do something

// 使用完之后,假设这里需要对25岁的小明的属性进行修改,可采用如下方法,之后重新复用这个对象即可
xm9.country("中国");


  • 这也实在太好用了吧!


4.3 既然把@Accessors的源码读了,@Builder的源码我也讲给你听吧


@Target({ElementType.TYPE, ElementType.METHOD, ElementType.CONSTRUCTOR})
@Retention(RetentionPolicy.SOURCE)
public @interface Builder {
// 指定创建建造者的方法名,默认为builder
String builderMethodName() default "builder";

// 指定创建对象的方法名,默认为build
String buildMethodName() default "build";

// 指定静态内部建造者类的名字,默认为 类名 + Builder,如StudentBuilder
String builderClassName() default "";

// 是否能重新从对象生成建造者,默认为false,上文中有使用样例
boolean toBuilder() default false;

// 建造者能够使用的范围,默认是PUBLIC
AccessLevel access() default AccessLevel.PUBLIC;

// 标注了该注解的字段必须指定默认初始化值
@Target({ElementType.FIELD})
@Retention(RetentionPolicy.SOURCE)
public @interface Default {
}

// 这个注解的使用是要和 @Builder(toBuilder = true) 一同使用才可生效
// 在调用toBuilder方法时,会根据被标注该注解的字段或方法对字段进行赋值
@Target({ElementType.FIELD, ElementType.PARAMETER})
@Retention(RetentionPolicy.SOURCE)
public @interface ObtainVia {
// 指定要获取值的字段
String field() default "";

// 指定要获取值的方法
String method() default "";

// 这个值在指定method才有效,为true时获取值的方法必须为静态的,且方法参数值为本类(参考下文代码)
boolean isStatic() default false;
}
}


  • 全网很少有人讲@ObtainVia注解,那我们就来说说,它到底有什么用,该怎么用



  1. 指定field赋值


// 在类中注解标记和新增字段如下
@Builder.ObtainVia(field = "hobbies")
private String hobby;

// 供hobby获取值使用
private String hobbies = "唱跳RAP";

// 测试调用toBuilder方法,检查hobby值,若为‘唱跳RAP’证明注解生效
System.out.println(new Student().toBuilder().build().getHobby());
结果:唱跳RAP

查看编译后的源码,可以发现赋值语句hobby(this.hobbies),原来它是如此生效的


public Student.StudentBuilder toBuilder() {
return (new Student.StudentBuilder()).name(this.name).lastNames(this.lastNames).age(this.age)
.hobby(this.hobbies).hobbies(this.hobbies)
.sex(this.sex).describe(this.describe).country(this.country);
}


  1. 指定非静态method赋值


// 在类中标注如下注解和创建如下方法
@Builder.ObtainVia(method = "describe")
private String describe;

// 非静态方法赋值
private String describe() {
return "小明的自我介绍";
}

// 测试调用toBuilder方法,检查describe值,若为‘小明的自我介绍’证明注解生效
System.out.println(new Student().toBuilder().build().getDescribe());
结果:小明的自我介绍

查看编译后的源码,发现会调用该方法


public Student.StudentBuilder toBuilder() {
// 这里会调用该方法进行赋值,在下面生成Builder时使用
String describe = this.describe();
return (new Student.StudentBuilder()).name(this.name).lastNames(this.lastNames).age(this.age).hobby(this.hobby).sex(this.sex)
.describe(describe)
.country(this.country);
}


  1. 指定静态method赋值


// 在类中标注如下注解和创建如下静态方法
@Builder.ObtainVia(method = "describe", isStatic = true)
private String describe;

// 静态方法赋值,需要指定本类类型参数
private static String describe(Student student) {
return "小明的自我介绍";
}

// 测试调用toBuilder方法,检查describe值,若为‘小明的自我介绍’证明注解生效
System.out.println(new Student().toBuilder().build().getDescribe());
结果:小明的自我介绍

查看编译后的源码


public Student.StudentBuilder toBuilder() {
// 这里调用静态方法赋值
String describe = describe(this);
return (new Student.StudentBuilder()).name(this.name).lastNames(this.lastNames).age(this.age).hobby(this.hobby).sex(this.sex).describe(describe).country(this.country);
}

5. 番外:@Builder,@Singular 夫妻双双把家还


5.1 @Singular简介


@Singular必须搭配@Builder使用,相辅相成,@Singular标记在集合容器字段上,在建造者中自动生成针对集合容器的添加单个值添加多个值清除其中值的方法,可进行标记的集合容器类型如下(参考官方文档) java.util.Iterable, Collection, List, Set, SortedSet, NavigableSet, Map, SortedMap, NavigableMap com.google.common.collect.ImmutableCollection, ImmutableList, ImmutableSet, ImmutableSortedSet, ImmutableMap, ImmutableBiMap, ImmutableSortedMap, ImmutableTable



  • 使用演示


// 在类中添加如下字段,并标注@Singular注解
@Singular
private List<String> subjects;

// 测试代码,调用单个添加和多个值添加的方法
Student xm11 = Student.builder()
.subject("Math").subject("Chinese")
.subjects(Arrays.asList("English", "History")).build();

// 查看添加结果
System.out.println(xm11.getSubjects().toString());
结果:[Math, Chinese, English, History]

// 调用clearSubjects清空方法,并查看结果
System.out.prinln(xm11.toBuilder().clearSubjects().build().getSubjects().toString());
结果:[]

5.2 @Singular源码解析


@Target({FIELD, PARAMETER})
@Retention(SOURCE)
public @interface Singular {
// 指定添加单个值的方法的方法名,不指定时会自动生成方法名,比例中为'subject'
String value() default "";

// 添加多个值是否忽略null,默认不忽略,添加null的列表时会抛出异常
// 为ture时,添加为null的列表不进行任何操作
boolean ignoreNullCollections() default false;
}


  • @Singular(ignoreNullCollections = false)编译后的代码


public Student.StudentBuilder subjects(Collection<? extends String> subjects) {
// 添加的列表为null,抛出异常
if (subjects == null) {
throw new NullPointerException("subjects cannot be null");
} else {
if (this.subjects == null) {
this.subjects = new ArrayList();
}

this.subjects.addAll(subjects);
return this;
}
}


  • @Singular(ignoreNullCollections = true)编译后的代码


public Student.StudentBuilder subjects(Collection<? extends String> subjects) {
// 为null时不进行任何操作
if (subjects != null) {
if (this.subjects == null) {
this.subjects = new ArrayList();
}

this.subjects.addAll(subjects);
}

return this;
}

5.3 @Singular在build方法中的细节



  • 创建完对象后,被标记为@Singular的列表能修改吗?我们试试


Student xm11 = Student.builder()
.subject("Math").subject("Chinese")
.subjects(Arrays.asList("English", "History")).build();

// 再添加一门Java课程
xm11.getSubjects().add("Java");

结果:抛出不支持操作的异常
Exception in thread "main" java.lang.UnsupportedOperationException
at java.util.AbstractList.add(AbstractList.java:148)
at java.util.AbstractList.add(AbstractList.java:108)
at builder.TestBuilder.main(Student.java:177)


  • 为什么这样?我们看看源码中的build方法就知道了,build方法根据不同的列表大小走不同的初始化列表方法,返回的列表都是不能进行修改的


public Student build() {
List subjects;
switch(this.subjects == null ? 0 : this.subjects.size()) {
case 0:
// 列表大小为0时,创建一个空列表
subjects = Collections.emptyList();
break;
case 1:
// 列表大小为1时,创建一个不可修改的单元素列表
subjects = Collections.singletonList(this.subjects.get(0));
break;
default:
// 其他情况,创建一个不可修改的列表
subjects = Collections.unmodifiableList(new ArrayList(this.subjects));
}

// 下面进行忽略只看上边就好
String name$value = this.name$value;
if (!this.name$set) {
name$value = Student.$default$name();
}

return new Student(name$value, this.lastNames, this.age, this.hobby, this.sex, this.describe, this.country, subjects);
}

6. 写在最后


呼!终于写完了,做个总结吧(文末有博客对应的代码仓库)




  • @Accessors注解非常的轻便,我觉得它现在已经能cover我在业务开发中创建对象的需求了,代码可读性高,代码量又很少




  • @Builder注解它的功能相对来说更多一些,通过方法和字段来初始化建造者的值,搭配@Singular操作列表等,但是这些功能真正的在业务开发中的应用效果,还有待考量




巨人的肩膀



作者:方圆想当图灵
来源:juejin.cn/post/7246025362969722936
收起阅读 »

前端版本过低引导弹窗方案分享

web
作者:费昀锋 背景 作为 TOB 的业务方,我们偶尔会收到一些如下图所示的反馈。 作为 PC 页面为主的业务方,大多数用户在一天的工作中,可能都不太会刷新或者重新打开我们的页面,导致我们在下午或者白天发布的前端版本,往往需要到几个小时甚至第二天,才能覆盖到...
继续阅读 »

作者:费昀锋



背景


作为 TOB 的业务方,我们偶尔会收到一些如下图所示的反馈。



作为 PC 页面为主的业务方,大多数用户在一天的工作中,可能都不太会刷新或者重新打开我们的页面,导致我们在下午或者白天发布的前端版本,往往需要到几个小时甚至第二天,才能覆盖到 98% 以上的用户。



我们统计了 bscm 平台 5 次下午 2-3 点左右发布的版本,在发布后每个时间段内老版本用户的占比情况。选择这个时间点发布的原因是这个时间点基本是平台用户的上班时间,是最有可能出现用户已经打开了页面同时我们在发布新代码的场景的,比较具有代表性。按平台用户六七点下班来看,我们可以看到还有将近 6% 的用户在当天是会一直访问老版本的前端代码的,按照 bscm 平台 1w+的 uv 来看,约有 600 多人会可能遇到前端版本过低导致的使用问题。


方案


弹窗内容



弹窗的触发条件


首先介绍两个概念,本地版本号和云端版本号。本地版本号是用户请求到的前端页面的代码版本号,是用户访问页面时决定;云端版本号可以理解为最新前端版本号,它是每次开发者发布前端代码时决定的。



判断触发条件的时机


有了弹窗的触发条件,我们还需要去决定什么时候判断弹窗是否满足触发的条件,上面也提到了,出现这类问题的场景多见于用户在使用过程中,开发者进行了前端代码发布,那我们主要可以有两个类型的时机去进行触发条件的判断。




  1. 前端代码去感知什么时候有新版本的代码发布了,去进行条件判断(消息推送)




  2. 前端在一定的条件下主动去判断触发条件(轮询,请求后端接口时,一些中频前端事件的监听)




我们对这些时机在更新是否及时,判断次数多少、实现成本高低等维度进行一个对比。



⭐️ 越多表示这个维度得分越高




根据表格可以看到 websocket 消息推送和前端事件监听这两种方案综合来看是更合适一些的,但是前端事件监听其实它的劣势在实际运用场景中会被弱化(一天的上线数量有限,请求次数一天不会多太多次),但是实现成本远低于 websocket,所以无疑是实际落地场景中比较理想的选择。



根据 can i use 的结果我们也可以发现 visibilitychange 事件也基本符合我们目前 B 端页面对于 PC 浏览器的要求。


版本号的生成


本地版本号


本地版本号是用户访问时决定的,那无疑页面的 html 文件就是这个版本号存在的最佳载体,我们可以在打包时通过 plugin 给 html 文件注入一个版本号。


云端版本号


云端版本号的选择则有很多方式了,数据库、cdn 等等都可以满足需求。不过考虑到实现成本和泳道的情况,想了一下两个思路一个是打包的同时生成一个 version.json 文件,配一个路由去访问;另一个是直接访问对应的 html 代码,解析出注入的版本号,二者各自有适合的场景。


微前端的适配


我们现在的大多数项目都包含了主应用和子应用,那其实不管是子应用的更新还是主应用的更新都应该有相关的提示,而且相互独立,但同时又需要保证弹窗不同时出现。


想要沿用之前的方案其实只需要解决三个问题。



  1. 主子应用的本地版本号标识需要有区分,因为 html 文件只有一个,需要能在 html 文件中区分出哪个应用的版本是什么,这个我们只需在 plugin 中注入标识即可解决。

  2. 云端版本号请求时也要请求对应的云端版本号,这个目前采用的方案是主应用去请求唯一的 version.json 文件,因为主应用路由是唯一的,子应用则去请求最新的 html 资源文件,解析出云端版本号。

  3. 不重复弹窗我们只需要在展示弹窗前,多加一个是否已经有弹窗展示的判断即可了。


具体实现


版本号的写入和读取



监听时机和频控逻辑


正如前文提到的,本身版本发布不是一个高频事件,但是监听事件的频次有时候可能过高了,不希望频繁的去进行触发条件判断。同时如果出现一天内多次发布的场景,也不希望这个弹窗对于用户有过多的打扰,所以需要去添加一个频控逻辑。



具体代码


plugin


/* eslint-disable */
import { CoraWebpackPlugin, WebpackCompiler } from '@ies/eden-web-build';
const fs = require('fs');
const path = require('path');
const cheerio = require('cheerio');

interface IVersion {
name?: string; // 编译完的文件夹名称
subName?: string; // 子应用的名称,主应用可以不传
}

export class VersionPlugin implements CoraWebpackPlugin {
readonly name = 'versionPlugin'; // 插件必须要有一个名字,这个名字不能和已有插件冲突
private _version: number;
private _name: string;
private _subName: string;
constructor(params: IVersion) {
this._version = new Date().getTime();
this._name = params?.name || 'build';
this._subName = params?.subName || ''
}
apply(compiler: WebpackCompiler): void {
compiler.hooks.afterCompile.tap('versionPlugin', () => {
try {
const filePath = path.resolve(`./${this._name}/template/version.json`);
fs.writeFile(filePath, JSON.stringify({ version: this._version }), (err: any) => {
if (err) {
console.log('@@@err', err);
}
});
const htmlPath = path.resolve(`./${this._name}/template/index.html`);
const data = fs.readFileSync(htmlPath);
const $ = cheerio.load(data);
$('body').append(`
${this._subName}versionTag" style="display: none">${this._version}
`
);
fs.writeFile(htmlPath, $.html(), (err: any) => {
if (err) {
console.log('@@@htmlerr', err);
}
});
} catch (err) {
console.log(err);
}
});
}
}

弹窗组件


import React, { useEffect } from 'react';

import { Modal } from '@ecom/auxo';
import axios from 'axios';
import moment from 'moment';

export interface IProps {
isSub?: boolean; // 是否为子应用
subName?: string; // 子应用名称
resourceUrl?: string; // 子应用的资源url
}

export type IType = 'visibilitychange' | 'popstate' | 'init';

export default React.memo<IProps>(props => {
const { isSub = false, subName = '', resourceUrl = '' } = props || {};

const cb = (latestVersion: number | undefined, currentVersion: number | undefined, type: IType) => {
try {
// 版本落后,提示可以刷新页面
if (latestVersion && currentVersion && latestVersion > currentVersion) {
// 提醒过了就设置一个更新提示过期时间,一天内不需要再提示了,弹窗过期时间暂时全局只需要一个!!
localStorage.setItem(`versionUpdateExpireTime`, moment().endOf('day').format('x'));
if (!document.getElementById('versionModalTitle')) {
Modal.confirm({
title: <div id="versionModalTitle">版本更新提示div>,
content:
'您已经长时间未使用此页面,在此期间平台有过更新,如您此时在页面中没有填写相关信息等操作,请点击刷新页面使用最新版本!',
okText: <div data-text={`前端版本升级引导-立即更新 ${type}`}>刷新页面div>,
cancelText: <div data-text={`前端版本升级引导-我知道了 ${type}`}>我知道了div>,
onCancel: () => {
console.log('fe-version-watcher INFO: 未更新~');
},
onOk: () => {
location.reload();
},
});
}
}
// 不管版本是否落后,半小时内都不需要去重新请求判断
localStorage.setItem(`versionInfoExpireTime`, String(new Date().getTime() + 1000 * 60 * 30));
} catch {}
};

const formatVersion = (text?: string) => (text ? Number(text) : undefined);

useEffect(() => {
try {
const fn = function (type: IType) {
if (document.visibilityState === 'visible') {
/**
*
@desc 为了防止打扰,版本更新每个应用一天只提示一次 所以过期时间设为当天23:59:59,没过期则直接return
*/

if (Number(localStorage.getItem(`versionUpdateExpireTime`) || 0) >= new Date().getTime()) {
return;
}
/**
*
@desc 不需要每次切换页面都去判断资源,每次从服务器获取到的版本信息,给半个小时的缓存时间,需要区分子应用
*/

if (Number(localStorage.getItem(`versionInfoExpireTime`) || 0) > new Date().getTime()) {
return;
}

if (!isSub) {
/**
*
@desc 主应用使用version.json文件来获取最新的版本号
*/

const dom = document.getElementById('versionTag');
const currentVersion = formatVersion(dom?.innerText);
axios.get(`/version?timestamp=${new Date().getTime()}`).then(res => {
const latestVersion = res?.data?.version;
cb(latestVersion, currentVersion, type);
});
} else {
/**
*
@desc 子应用使用最新html中的innerText来获取最新版本号
*/

if (resourceUrl) {
const dom = document.getElementById(`${subName}versionTag`);
const currentVersion = dom?.innerText ? Number(dom?.innerText) : undefined;
axios.get(resourceUrl).then(res => {
/** ignore_security_alert */
try {
const html = res.data;
const doc = new DOMParser().parseFromString(html, 'text/html');
const latestVersion = formatVersion(doc.getElementById(`${subName}versionTag`)?.innerText);
cb(latestVersion, currentVersion, type);
} catch {}
});
}
}
}
};
const visibleFn = () => {
fn('visibilitychange');
};
const routerFn = () => {
fn('popstate');
};
if (isSub) {
// 子应用可能会有缓存,初始化的时候先判断一次
fn('init');
}
document.addEventListener('visibilitychange', visibleFn);
window.addEventListener('popstate', routerFn);
return () => {
document.removeEventListener('visibilitychange', visibleFn);
window.removeEventListener('popstate', routerFn);
};
} catch {}
}, []);

return <div />;
});

如何接入


主应用版本



  1. 安装依赖


npm i @ecom/fe-version-watcher-plugin # 安装plugin 
npm i @ecom/logistics-supply-chain-fe-version-watcher # 安装引导弹窗


  1. 引入 versionPlugin,自动生成 version.json + html 文件中自动注入


import { VersionPlugin } from '@ecom/fe-version-watcher-plugin';

// 有些项目打包后template文件夹下的名字不是build而是build_cn
// 可以根据自己项目的实际情况传入{name: build_cn}

{
...,
plugins: [
...,
[VersionPlugin, {}],
]
}


  1. 引入版本引导弹窗


import { FeVersionWatcher } from '@ecom/logistics-supply-chain-fe-version-watcher';

<FeVersionWatcher />


  1. goofy 新增路由配置,/version 指向 version.json 文件 (或者其它方式可以使得/version 的路由指向该 version.json 文件)



预告


采用 version.json 的方案,引入 FersionWatcher 组件就不再需要任何参数,目前主应用只支持这种模式。未来也将参考子应用,主应用支持读取 html 中版本标识的能力,将配置路由的工作改成组件 props 传入资源 url,开发者可以根据实际情况自行选择。


子应用版本



  1. 安装依赖


npm i @ecom/fe-version-watcher-plugin # 安装plugin
npm i @ecom/logistics-supply-chain-fe-version-watcher # 安装引导弹窗


  1. 引入 versionPlugin, html 文件中自动注入版本号,需要子应用标识参数(必填)


import { VersionPlugin } from '@ecom/fe-version-watcher-plugin';

// 有些项目打包后template文件夹下的名字不是build而是build_cn
// 可以根据自己项目的实际情况传入{name: build_cn}

{
...,
plugins: [
...,
[VersionPlugin, {subName: 'general-supplier', name: 'build_cn'}],
]
}


  1. 引入版本引导弹窗(subName 和 plugin 中保持一致,resourceUrl 为配置的子应用路由)


import { FeVersionWatcher } from '@ecom/logistics-supply-chain-fe-version-watcher';

// subName需要和plugin的参数保持一致,resourceUrl为子应用资源的路径(子引用goofy上配置的路由)
<FeVersionWatcher isSub subName="general-supplier" resourceUrl="/webApp/general-supplier" />

resourceUrl一般就是goofy上配置的路由设置,,如果不同平台有区分,可以动态传入。



如何调试/效果展示


发布成功后,可以根据如下步骤测试:




  1. 删除 localstorage 中相关的 value





  2. 修改 html 中的 version,改成一个比较小的数值即可





  3. 切换路由,或者隐藏/打开页面,出现弹窗




收益统计



同样我们截取了 4 次该平台 2-3 点发布的版本情况,可以看到老版本用户的 uv 占比有着明显的下降。



上线至今共计提示 10 万+用户,帮助约 5 万人次及时更新了前端代码。


作者:字节前端
来源:juejin.cn/post/7301530293377843235
收起阅读 »

索引数据结构千千万 , 为什么B+Tree独领风骚

索引的由来 大数据时代谁掌握了数据就是掌握了流量,就是掌握的号召力。面对浩瀚的数据如何存储并非难事, 难点在于如何在大数据面前查询依旧快如闪电! 这时候索引就产生了,索引的产生主要还是借鉴于图书管理员书签的功能。在大数据面前 es 产生了,而我们今天要...
继续阅读 »

索引的由来




  • 大数据时代谁掌握了数据就是掌握了流量,就是掌握的号召力。面对浩瀚的数据如何存储并非难事, 难点在于如何在大数据面前查询依旧快如闪电!




  • 这时候索引就产生了,索引的产生主要还是借鉴于图书管理员书签的功能。在大数据面前 es 产生了,而我们今天要说的索引却不是它 而是目前中小项目中广泛使用的 mysql 数据库中的索引。




  • 本文主题着重介绍索引是什么?索引如何存储?为什么这么设计索引?常见的索引有哪些?最后我们在通过案列来分析如何命中索引以及索引失效的部分场景。




什么是索引



索引是创建在表上的,对数据库表中一列或多列的值进行排序的一种结构,可以提高查询的速度。




  • 索引是一种数据结构,以协助快速查询,更新数据库中的数据 。 mysql 的索引主要由 B+Tree 进行存储。在存储主题上又分为聚簇索引和非聚簇索引。


聚簇索引




  • 聚簇索引从字面上理解就是聚集在一起。所以凡事索引和数据存放在一起的我们就叫做聚簇索引。在mysqlINNODB 的主键索引就是采用的聚簇索引,因为在叶子节点负责存放数据,而非叶子节点负责存放索引。而除了主键索引外其他索引则是非聚簇索引,因为其他索引的叶子节点存储的是主键索引的地址指向。




非聚簇索引



  • MyISAM 引擎中就是非聚簇索引,我们通过它的文件结构也能够看出索引和数据是分开存放的。 非聚簇索引也会带来一些问题。诸如回表

  • INNODB 中非主键索引就是非聚簇索引,同时这种非主键索引也会带来一个问题就是二次索引也称回表。因为我们通过非主键索引是无法定位到最终数据的。大部分情况下我们是需要在根据主键索引进行第二次查找的。加入你有一个索引idx_name

    • select name from t where name=13 发生一次索引,不会回表查询

    • select * from t where name=13 发生两次索引,会发生回表



  • 上面第一个sql 不会发生回表是因为我门的sql 发生了索引覆盖,意思是idx_name 这颗树已经覆盖了我们查询的范围。


索引存储结构



  • 先说结论 mysql 中索引是通过 B+ Tree 进行存储的。但是在 mysql 中一开始是采取的 二叉树存储的。关于树形存储结构都是二叉树。那么我们是mysql 中不采用二叉树、红黑树呢?下面我们来分析下采用二叉树、红叉树分别会带来哪些问题。


二叉树



  • 二叉树是根据顺序在根据大小判断其存储的左右节点的。这就导致如果我们是按递增ID作为索引的话,最终就导致二叉树变成一颗偏向一边的树,换个角度看其实就是链表。


image-20221116191402773.png




  • 而针对一张表我们往往就是ID作为索引的居多。而ID采用自增策略的居多,所以如果索引采用的是二叉树的,毋庸置疑销量基本无提升,这也是为什么官方放弃 二叉树 作为索引存储的数据结构。




  • 而二叉树一共有如下几种极端情况




image-20221116203557935.png


平衡二叉树



  • 在开始红黑树之前,我们需要先了解下有种临界状态叫平衡二叉树。

  • 平衡二叉树又叫做Self-balancing binary search tree 。 平衡二叉树是二叉树的一种特例

  • 在二叉树中有一个定义平衡度(平衡因子)的概念。他的公式是左右高度的绝对值。

  • 当这个平衡度<=1的时候我们就称之为平衡二叉树

  • 在平衡二叉树中他的高度是最稳定的,换句话说平衡二叉树和其他二叉树相比能够在相同的节点情况下保证树的高度最低;这也是为什么mysql中索引的结构是一种平衡二叉树的升级版


image-20221116203517550.png


红黑树



红黑树实际上是一颗平衡二叉树;所以在构建的过程中他会发生自平衡



image-20221116194807714.png



  • 因为二叉树在极端的情况会变成一个链表,针对链表的问题红黑树的自平衡特性就完美的规避了二叉树的缺点。那么为什么最终索引也不是选择红黑树呢?

  • 仔细观察能够发现红黑树是一颗标准的二叉树。他所能容纳的最大节点数和他的高度正好成二的次方这个关系。也就是说假设红黑树的高度是h ,那么他能容纳最多的节点为 2^h。

  • 这样看来在数据量过大时,通过红黑树去构建貌似这颗二叉树高度就过去庞大了。高度也高给我们查询就带来更多次交互。要知道每个节点都是存储在硬盘中的,那么每一次的访问都会带来一次IO消耗。所以为了能够提高查询效率 mysql 最终还是没有选择红黑树。


①、每个节点要么红色要么黑色


②、根节点是黑色的


③、叶子节点是黑色的


④、红色节点的子节点一定是黑色的


⑤、从一个节点出发,到达任意一个叶子结点(NULL)路径上一定具有相同的黑色节点(保证了平衡度<=2)


image-20221116203407778.png


BTree



BTree的设计主要是针对磁盘获取其他存储的一种平衡树(不一定是二叉这里往往指的是多叉)



image-20221116203109328.png



  • B树非常适合读取和写入相对较大的数据块(如光盘)的存储系统。它通常用于数据库和文件系统。

  • 总结下BTree 具有如下特点:


①、至少是2阶,即至少有两个子节点
②、对于m阶BTree来说,非根节点所包含的关键词个数j需要满足 (m/2)-1<=j<=m-1
③、除叶子结点外,节点内关键词个数+1总是等于指针个数
④、所有叶子结点都在同一层
⑤、每个关键字保存实际磁盘数据


B+Tree



B+Tree 是BTree的一种变体。BTree节点里出了索引还会存储指针数据,而B+Tree仅存储索引值,这样同样空间节点能够存储更多的索引




  • B+Tree 因为压缩了数据存储空间,这样就能够在相同高度的BTree上存储更多的索引,这样更加提高索引定位销率。


image-20221116203306106.png


Hash表


①、hash索引无法进行范围查询,因为上述的hash结构是没有顺序的,hash索引只能实现等于、In等查询
②、hash值是针对元数据的一种散列运算。hash值得大小并不能反应元数据的大小。元数据a 、b对应的hash值有可能是3333、2222,而实际上上a<b . 所以我们无法通过hash值进行排序,从而hash索引无法进行排序
③、对于组合索引来说,在B+Tree中我们有最左匹配原则,但是在hash索引中是不支持的。因为组合索引整个映射成hash值,我们通过联合索引中部分值进行hash运算得带的值与hash索引中是没有关系的
④、hash索引在查询时是需要遍历整个hash表的。这点我们Java中的HashMap一样
⑤、hash索引在数据量少的情况下比BTree快。但是当hash冲突比较多的时候定位就会比B+Tree慢很多了。


image-20221116203746016.png


总结



  • 现在看来数据库运行的很牛逼,而且索引也很快,但这并不是一口吃成胖子的,了解了索引的底层数据结构后我们也能够了解 mysql 也是一步一步尝试过来的, 索引也是不断的优化而成的。说不定以后还会有其他结构产生,只能说每种数据结构都是最好的,前提是在特定的场景下。

  • 本专栏最后一篇我们将介绍下 mysql 的索引如何命中,以及那些场景导致索引失效。然后再着重介绍下高频面试题--回表&&索引下推



作者:zxhtom
来源:juejin.cn/post/7168268214713974798
收起阅读 »

说一个大家都知道的 Spring Boot 小细节!

小伙伴们知道,我们在创建 Spring Boot 项目的时候,默认都会有一个 parent,这个 parent 中帮我们定了项目的 JDK 版本、编码格式、依赖版本、插件版本等各种常见内容,有的小伙伴可能看过 parent 的源码,这个源码里边有这么一个配置:...
继续阅读 »

小伙伴们知道,我们在创建 Spring Boot 项目的时候,默认都会有一个 parent,这个 parent 中帮我们定了项目的 JDK 版本、编码格式、依赖版本、插件版本等各种常见内容,有的小伙伴可能看过 parent 的源码,这个源码里边有这么一个配置:


<resources>
<resource>
<directory>${basedir}/src/main/resources</directory>
<filtering>true</filtering>
<includes>
<include>**/application*.yml</include>
<include>**/application*.yaml</include>
<include>**/application*.properties</include>
</includes>
</resource>
<resource>
<directory>${basedir}/src/main/resources</directory>
<excludes>
<exclude>**/application*.yml</exclude>
<exclude>**/application*.yaml</exclude>
<exclude>**/application*.properties</exclude>
</excludes>
</resource>
</resources>

首先小伙伴们知道,这个配置文件的目的主要是为了描述在 maven 打包的时候要不要带上这几个配置文件,但是咋一看,又感觉上面这段配置似乎有点矛盾,松哥来和大家捋一捋就不觉得矛盾了:



  1. 先来看第一个 resource,directory 就是项目的 resources 目录,includes 中就是我们三种格式的配置文件,另外还有一个 filtering 属性为 true,这是啥意思呢?这其实是说我们在 maven 的 pom.xml 文件中定义的一些变量,可以在 includes 所列出的配置文件中进行引用,也就是说 includes 中列出来的文件,可以参与到项目的编译中。

  2. 第二个 resource,没有 filter,并且将这三个文件排除了,意思是项目在打包的过程中,除了这三类文件之外,其余文件直接拷贝到项目中,不会参与项目编译。


总结一下就是 resources 下的所有文件都会被打包到项目中,但是列出来的那三类,不仅会被打包进来,还会参与编译。


这下就清晰了,上面这段配置实际上并不矛盾。


那么在 properties 或者 yaml 中,该如何引用 maven 中的变量呢?


这块原本的写法是使用 $ 符号来引用,但是,我们在 properties 配置文件中,往往用 $ 符号来引用当前配置文件的另外一个 key,所以,我们在 Spring Boot 的 parent 中,还会看到下面这行配置:


<properties>
<java.version>17</java.version>
<resource.delimiter>@</resource.delimiter>
<maven.compiler.source>${java.version}</maven.compiler.source>
<maven.compiler.target>${java.version}</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
</properties>

这里的 <resource.delimiter>@</resource.delimiter> 就表示将资源引用的符号改为 @ 符号。也就是在 yaml 或者 properties 文件中,如果我们想引用 pom.xml 中定义的变量,就可以通过 @ 符号来引用。


松哥举一个简单的例子,假设我想在项目的 yaml 文件中配置当前项目的 Java 版本,那么我就可以像下面这样写:


app:
java:
version: @java.version@

这里的 @java.version@ 就表示引用了 pom.xml 中定义的 java.version 变量。


现在我们对项目进行编译,编译之后再打开 application.yaml,内容如下:



可以看到,引用的变量已经被替换了。


按照 Spring Boot parent 中默认的配置,application*.yaml、application*.yml 以及 application*.properties 文件中可以引用 pom.xml 中定义的变量,其他文件则不可以。如果其他文件也想引用,就要额外配置一下。


例如,想让 txt 文件引用 pom.xml 中的变量,我们可以在 pom.xml 中做如下配置:


<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<includes>
<include>**/*.txt</include>
</includes>
<filtering>true</filtering>
</resource>
</resources>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>

include 所有的 txt 文件,并且设置 filtering 为 true(不设置默认为 false),然后我们就可以在 resources 目录下的 txt 文件中引用 pom.xml 中的变量了,像下面这样:



编译之后,这个变量引用就会被替换成真正的值:



在 yaml 中引用 pom.xml 的配置,有一个非常经典的用法,就是多环境切换。


假设我们现在项目中有开发环境、测试环境以及生产环境,对应的配置文件分别是:



  • application-dev.yaml

  • application-test.yaml

  • application-prod.yaml


我们可以在 application.yaml 中指定具体使用哪个配置文件,像下面这样:


spring:
profiles:
active: dev

这个表示使用开发环境的配置文件。


但是有时候我们的环境信息是配置在 pom.xml 中的,例如 pom.xml 中包含如下内容:


<profiles>
<profile>
<id>dev</id>
<properties>
<package.environment>dev</package.environment>
</properties>
<!-- 是否默认 true表示默认-->
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<profile>
<id>prod</id>
<properties>
<package.environment>prod</package.environment>
</properties>
</profile>
<profile>
<id>test</id>
<properties>
<package.environment>test</package.environment>
</properties>
</profile>
</profiles>

这里配置了三个环境,其中默认是 dev(activeByDefault)。那么我们在 application.yaml 中就可以使用 package.environment 来引用当前环境的名称,而不用硬编码。如下:


spring:
profiles:
active: @package.environment@

此时,我们通过 maven 命令对项目打包时,就可以指定当前环境的版本了,例如使用 test 环境,打包命令如下:


mvn package -Ptest

打包之后我们去看 application.yaml,就会发现里边的环境已经是 test 了。


如果你使用的是 IDEA,则也可以手动勾选环境之后点击打包按钮,如下:



可以先勾选上面的环境信息,再点击下面的打包。


好啦,一个小小知识点,因为有小伙伴在微信上问这个问题,就拿出来和大家分享下。


作者:江南一点雨
来源:juejin.cn/post/7226916546931949626
收起阅读 »

程序员黑话集

为什么 10.24 是程序员节计算机采用的是 2 进制,2 的 10 次方是 1024,而数据存储的单位从 B, KiB, MiB, GiB, TiB ..... 以 1024 作为一个跨度,比如 1 KiB = 1024 B。程序员在日常工作中接触到 102...
继续阅读 »

为什么 10.24 是程序员节

计算机采用的是 2 进制,2 的 10 次方是 1024,而数据存储的单位从 B, KiB, MiB, GiB, TiB ..... 以 1024 作为一个跨度,比如 1 KiB = 1024 B。程序员在日常工作中接触到 1024 的机会太多了,看到 1024 就会产生条件反射。
除了 1024 外,程序员届还有许多的术语/黑话,借着 10.24 这个日子,也和大家分享一下吧。学会了这些术语,基本就能和程序员们谈笑风生,而把非程序员们唬得一愣一愣。

通用术语

404

当请求的网络资源不存在时,返回的错误编号。扩展为某样东西不存在/找不到。

403

当没有权限访问网络资源时,返回的错误编号。扩展为没有权限/资格接触某项信息。

500

当在请求某个网络资源时,服务器内部发生错误时,返回的错误编号。扩展为系统发生内部故障。

API

Application Programming Interface。程序间对接的接口,两边程序只要遵循这个接口,就能互相交互。扩展为两个对象之间交互应该遵循的规范,对象没有限定,可以为人,机器,系统等概念。

Bug

软件错误。扩展到因为人为疏漏导致的问题。

Cookie

网站记录你个人访问行为的载体。你能被广告主精准命中的关键情报仓库,各种 “Allow Cookie" 骚扰弹窗的根源。

Cache

一层缓冲,商家每年搞剁手节,能不被海量用户冲垮的核心堤坝。当然偶尔流量实在太大,也会决堤,比如被屡次冲垮的微博。

RFC

Request for Comments。起初用于起草互联网标准,比如 HTTP 1.0 协议是 RFC 1945。后来不少公司的设计文档也沿用了 RFC 这个名字。

Interesting

有趣🧐。起初是个褒义词,但现在在许多场合下,因为无法给出积极评价的时候,会用该词来化解尴尬。有时甚至会传达嘲讽,所以请慎用。

UI vs UX

UI - User Interface。用户的视觉感受。UX - User Experience。用户的真实使用感受。

Frontend and Backend

前端和后端,一个应用的两个组成部分。前端是用户能感知的部分,后端则是用户感知不到,隐藏起来的部分。既有左图里美如画的前端,脏乱差的后端,也有右图里风雨飘摇的前端,高精尖的后端。

研发流程相关

DevOps

把研发(Dev) 和运维(Ops) 两种职能融合在一起的运动。也有人认为这是让一个人打两份工的阴谋。

生产环境 (Production / Prod)

也叫线上环境,实际在生产当中使用的。与之对应的是内部的研发环境 (Dev),测试环境 (Test),预发环境(Staging)。

Test in Prod

一种以快速迭代作为借口,不做全面的测试,就直接把代码发布到生产环境的行为。虽然许多产品都是这么做的。

Canary (金丝雀)

过去矿工下井时会带上金丝雀,因为金丝雀对有害气体敏感,如果有害气体超标,金丝雀会率先死亡,矿工便知道需要撤离。在软件发布中,也通常会采用金丝雀模式,把新的版本先发布到一小部分用户中。有些地方把前面提到的预发环境也直接叫做金丝雀环境。

删库跑路

最严重的事故莫过于误删了应用数据库,所有的数据都没了,那整个公司的业务也就完蛋了。就像当年的扁鹊一样,无法挽回,唯有跑路了。扩展为强调后果的严重性。

Fat Finger

胖胖的手指。因为手指粗,所以误敲到了回车键,引发了诸如删库这样的事故。扩展为人为的操作不小心。

Repository / Repo

仓库,托管代码的地方。

Branch

分支。多人在同一个仓库上工作时,为了避免互相影响到对方,会在不同的分支上进行开发。

Trunk

主干或者叫主干分支。通常主干的分支名字叫 main 或者 master。主干也是一个仓库的代码主线,大家在不同的分支上开发,但某一个时刻,还是要把开发的代码合并进入主干。另外要开启新的分支时,通常也会基于主干进行分叉。当然也可以基于其他分支进行进一步分叉,但最终在某一个时间点,代码还是要合并回主干的。

主干开发 (Trunk-based development)

一种强调迭代速度的开发模式。要求大家尽可能频繁地把开发完的功能合并进主干,但同时也要尽量保证主干的健康。如果主干经常有问题的话,团队就无法基于主干开启新的分支,进行新的研发任务。所以主干开发会强调小步快跑,高频提交小规模变更。

Cherrypick

有时候你只想从一个分支里挑选一部分的内容合并到另一个分支,这个动作就像是捡樱桃一样。落水三千,只取一瓢。

Release Train

发布列车。每隔一段时间,软件就会进行发布,发布负责人往往会规定一个时间点,如果希望让自己的功能赶上这次的发布,就需要在这个时间点前把代码提交,不然发布列车就开走了。不过现实中,发布列车往往要等某一个 VIP 功能,会推迟发车时间。

TODO

在代码里记录一个将来再解决的问题,但至于什么时候去解决,谁知道呢。

Postmortem

原义是验尸报告。在软件研发领域,在发生事故后,详细的故障分析报告,报告最后通常会留好几个 TODO。

On-call (Carry the pager)

值班,以前带着的传呼机叫做 Pager。现在传呼机被手机/软件取代了,但 Pager 这个名字沿用了下来。

Spaghetti code

形容代码乱成一团,像通心粉一样交织在一起。

PR

不是指公关 (Public Relations),而是 Pull Request。GitHub 里要像某一个分支合并代码时,提交的合并请求。而在 GitLab 里,对应的概念叫 Merge Request (MR)。你看出来了,这两家老对着干,倒霉的是我们这帮程序员。

虚构概念

ACME

一家虚构的公司,一般文档例子里要用到一家子虚乌有的公司时,会用这个名字。

Alice and Bob

一组虚构人物,起源于网络安全,交换信息的双方。

example.com

访问这个网站就知道是用来干嘛的了。

Foo, Bar, Baz

一组没有意义的占位符(Placeholder)来指代某种概念。失去自我,成就大我。

缩略语

LGTM

Looks Good To Me。通常用于审核(Review)流程中,比如代码审核,文档审核。审核人(Reviewer)用来表示认同,批准👍。

PTAL

Please Take Another Look。通常用于审核(Review)流程中,比如代码审核,文档审核。发起人(Author)告知审核人(Reviewer)再次审核。

Nit

Nitpicking。吹毛求疵,通常用于审核(Review)流程中,比如代码审核,文档审核。审核人(Reviewer)提出的一些不影响核心内容,或者带有主观判断的建议。

WDYT

What Do You Think。在双方问题讨论中,在提出自己观点后, 一种启发式的希望获得对方反馈的表达方式。

YMMV

Your Mileage May Vary。在分享完自己的经验和观点后,也提醒他人要思辨地吸收。

EOF

End Of File。标识一个文件结尾的符号。扩展为表示一件事情的终结。

IMO / IMHO

In My Opinion / In My Humble Opinion。在表达自己观点前,为了降低对方抵触情绪,附加的谦逊语气。但也不要指望加了这个,就能避免引起对方的不适。

WYSIWYG

What You See Is What You Get。所见即所得,一种提供更好用户体验的交互方式。

TGIF

Thank God It's Friday 🪩!

TIL

Today I Learned.

Happy 1024! 早点下班!🎉


作者:Bytebase
来源:mp.weixin.qq.com/s/WRANBcZ69_COkZfnZY0pCQ

收起阅读 »

工作了5年你居然不知道版本号有这些规范?

前言 所谓语义化版本控制,就是要求你的版本号能按照特定规则及条件来进行约束,以期达到见到版本号即能了解其修改内容的信息或相邻版本间的更新迭代关系。通过阅读本文,你将能够对语义化版本控制规范能够有一个全面的了解,同时也对各平台上依赖版本时的语法有个大体的了解。 ...
继续阅读 »



前言


所谓语义化版本控制,就是要求你的版本号能按照特定规则及条件来进行约束,以期达到见到版本号即能了解其修改内容的信息或相邻版本间的更新迭代关系。通过阅读本文,你将能够对语义化版本控制规范能够有一个全面的了解,同时也对各平台上依赖版本时的语法有个大体的了解。


背景


在正式开始之前,先问大家几个问题:


我们经常在类似 Github、npm、或者 pub.dev 上看到一些软件或者库的版本号包含如下信息,你是否会疑惑他们之间的区别是什么?分别适用什么场景?



  • alpha

  • beta

  • rc

  • release


再看看下面几组版本号,你是否能弄清楚各个版本号之间谁更新更大?



  • 1.0.0 1.0.1 1.1.0

  • 1.0.0-beta 1.0.0

  • 1.0.0-release 1.0.0

  • 1.0.0-alpha 1.0.0-alpha.1

  • 1.0.0-alpha 1.0.0-rc.1


这次将借着我们在做组件管理平台的机会,像大家介绍一下日常软件开发中的语义化版本控制规范。相信通过下面的学习,上述的问题也能够迎刃而解。


常见先行版本号标识


上面说到 alpha、beta、rc、release 等版本号中常见的一些标识,有一个正式的名称叫做:先行版本号标识。我们可以通过一个生活中的例子来通俗易懂的说明它们之间的差异和联系。


现在假设你是一个蛋糕店的老板,你打算给你的蛋糕店推出一个新品,那么上述所谓的先行版本号就是如下几个阶段的蛋糕:


Alpha 版就是你对于你蛋糕的最终形式还在脑海当中,只有一个蛋糕的基本样子,口味应该是什么味道你心里还没谱,对于装饰如奶油、水果还有蜡烛这些甚至都还没有放在一起(你的软件各功能甚至都没有打通)。由于过于简陋,并且口味还没固定,你还不能将其给你的顾客品尝。你只能自己反复摸索尝试,或者让自己店里的员工对口味、外观以及一些缺陷进行点评。


Alpha版蛋糕


Beta 版就是你的蛋糕已经开始尝试将部分奶油涂抹在蛋糕上,你已经尝试将所有的元素组装起来,这时候的蛋糕还处于不能拿出去卖的阶段,但口味和后续方向已经基本固定。你甚至可以邀请你店里的熟客来参加小规模的试吃活动,并让他们针对你的这款蛋糕进行全方面的点评。


Beta版蛋糕


RC 版就是你的蛋糕已经基本做完了,其最核心的口味和外观已经确定下来,你可以再检查一下蛋糕是否有裂缝、哪些地方需要针对性的进行一些美化或修补。


RC版蛋糕


release 版就是你已经把蛋糕装饰好了,插上蜡烛,撒上曲奇,进行裱花。这时候蛋糕已经完成了,你可以正式的将这块蛋糕摆上橱窗,向大家兜售你的艺术品了。


release版蛋糕


通过上述的蛋糕制作过程,你应该对这些先行版本号标识有了自己的认知。接下来我们再总结下这些先行版本号标识的常见含义:


标识常见含义
alpha(α)内部测试版(有些也叫 A 测版)。α 是希腊字母的第一个,表示最早的版本,一般此类版本包含很多 BUG ,功能也不全,主要面向的是开发人员和测试人员。
beta(β)公开测试版(有些也叫 B 测版)。 β 是希腊字母的第二个,因此这个版本比alpha版发布较晚一些,主要是给参与内部体验的用户测试用,该版本仍然存在很多 BUG ,但是相对 alpha 版要稳定一些。此时,基本功能已经固定,但仍然可能增加新功能。
rc(Release Candidate)rc (候选版本),该版本又较 beta 版更进一步了,该版本功能不再增加,和最终发布版功能一样。
这个版本的作用是提前预览即将发行版本的内容,并且在该版本后,最终发行版的发布也迫在眉睫了。
release稳定版(有些也叫做 stable、GA 版)。在开源软件中,都有正式版,这个就是开源软件的最终发行版,用户可以放心大胆的用了。

相信阅读到这里,上面的第一个问题你已经有了答案。那么明白这些标识的具体含义之后,它到底应该怎么用呢?具体要放在版本号里的哪个位置上呢?接下来我们将通过对语义化版本控制规范的详细介绍,来帮助你解答这些疑惑。


何为语义化版本控制规范


在介绍什么是语义化版本控制规范之前,我们先需要了解为什么需要语义化版本控制规范。


大家先设身处地的设想这样一个开发场景:


你现在的项目现在分别依赖了 foo : 1.0.0bar : 2.0.0baz : 3.0.0


项目example_app的依赖项


同时 foo 组件也依赖了 bar : 2.0.0baz : 3.0.0


组件foo的依赖项


同时 bar 组件也依赖了 baz : 3.0.0


组件bar的依赖项


现在你很幸运,项目可以跑起来。


突然有一天因为要修改一个问题,需要升级你项目中 baz 组件的版本号,需要将它从 3.0.0 升级到 3.0.1。但很不幸的是,baz 组件这个小小的版本升级却发生了破坏性的 API 改动。然后你发现你不仅需要修改主工程 example_app 的版本号,还需要升级 foo 组件的版本号以及 bar 组件的版本号。而在你做完这些之后,发现 foo 依赖的其他组件的版本又和你主工程 example_app 项目中依赖的组件的版本冲突了,于是你崩溃了。


这就是软件管理领域中被称作“依赖地狱”的死亡之谷。即当你的系统规模越大,引入的包越多,你就越可能遇到由于依赖导致的问题:



  • 如果依赖关系过高,可能面临版本控制被锁死的风险(必须对每一个依赖包改版才能完成某次升级)

  • 而如果依赖关系过于松散,又将无法避免版本的混乱(假设兼容于未来的多个版本已超出了合理数量) 当你项目的进展因为版本依赖被锁死或版本混乱变得不够简便和可靠,就意味着你正处于依赖地狱之中。


通过上述的场景我们可以看到,版本号的管理(包括依赖关系的控制以及版本号的命名)并不是一个随心所欲的事情:管理好了,能给你带来极大便利,反之则会给你的开发带来很多没必要的麻烦。那么我们应该如何解决这些事情呢?


基于上述的一些问题,Gravatars 及 Github 的创始人之一的 Tom Preston-Werner 提出了一个名为语义化版本控制规范(Semantic Versioning)的解决方案,它期望用一组简单的规则及条件来约束版本号的配置和增长。这套规则是根据现在各种封闭、开源软件所广泛使用的版本号命名规则所设计。为了让这套理论运作,必须要定义好你的公共 API。一旦定义了公共 API,你就可以透过修改相应的版本号来向大家说明你的修改。考虑使用这样的版本号格式:



版本格式:主版本号.次版本号.修订号,版本号递增规则如下:



  1. 主版本号:当你做了不兼容的 API 修改

  2. 次版本号:当你做了向下兼容的功能性新增

  3. 修订号:当你做了向下兼容的问题修正


先行版本号版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。



以上这套规则或者说系统,就是所谓的”语义化版本控制”,在这套规则之下,版本号以及版本号的更新都潜在包含了代码的修改信息,而这套规则被简称为 semver (Semantic Versioning 简写)。


接下来我将基于 semver 2.01 向大家介绍 这套规则的一些细则。


语义化版本控制规范细则


语义化版本控制规范的细则有很多,有兴趣的同学可以直接到semver 2.01 的官方文档 查看即可,我们这里将其主要内容总结给大家。


X.Y.Z(主版本号.次版本号.修订号)修复问题但不影响 API 时,递增修订号;API 保持向下兼容的新增及修改时,递增次版本号;进行不向下兼容的修改时,递增主版本号。


一个标准的语义化版本号各部分的含义


其实所谓语义化版本控制规范,本来也只是一种约定,它并不能完美适合每一个团队,我们也没必要完全生搬硬套,这里以 Google 官方推出的 mockito2 的版本号为例,可以看到其也没有严格按照细则进行遵守。


组件mockito的一些非正式版本号


所以如果你团队内已经统一认知,了解版本号中每个地方代表的含义,做到“见号知意”:看到 1.0.0-npeFixed.8 就知道这个组件是从 1.0.0 拉出来 为了修复 NPE 的;看到 2.3.0-addFaceIdSupport.1 就知道这个组件是基于 2.3.0 来做 FaceId 支持的;见到 5.0.0-nullSafety.6 就知道这个版本是为了空安全的。那么我们的语义化版本控制规范的目的也就达到了,不是吗?


版本语法


就像人类的烹饪方式从最开始的单纯用火烤到发明陶器之后的烹煮,再到现代社会中基于烤、煮、蒸而演化出来的各类五花八门的烹饪方式一样,语义化版本控制规范在各个平台上也衍生出不同的版本规范和版本语法(Version Syntax),但万变不离其宗。接下来我将大致介绍下常见平台版本语法的异同,期望能对你有所帮助。



由于 PyPI上的版本规范及版本说明符比较特殊且繁琐,这里就不进行比对,有兴趣的同学可以查看PEP 440 – Version Identification and Dependency Specification3 了解更多细节。



和烹饪方式的的演化过程一样, 语义化版本控制规范在不同平台、不同时期也有不同的表现


定义平台格式示例描述
完全匹配目标版本gradleversion

version!!
com.example:foo:5.0.2

com.example:foo:5.0.2!!
这里用5.0.2 和 5.0.2!! 是有区别的。
5.0.2 这种写法是对此版本最低要求,但是可以被引擎升级,这里的5.0.2是被称作必须版本(Required version4), 也就是说它最小版本是5.0.2,并且相信未来的任何升级都是可以正常工作的。

而5.0.2!! 则是严格版本(Strict version5), 即只能使用5.0.2的版本,传递依赖项过来的版本如果没有更高约束或者别的严格版本,会被覆写为此版本,否则会失败。
mavenversion

[version]
5.0.2

[5.0.2]
和gradle类似,这里用5.0.2 和 [5.0.2] 是有区别的。
5.0.2 这种写法是对此版本的软要求(Soft requirement6),如果依赖关系树中较早没有出现其他版本,则使用 5.0.2。

而 [5.0.2] 这种写法是对此版本的硬性要求(Hard requirement6)。使用 5.0.2并且仅使用 5.0.2。
pubversionfoo: 5.0.2
npmversionfoo: 5.0.2
podversion

= version
pod 'foo', '5.0.2'

pod 'foo', '=5.0.2'
兼容版本gradleversion.+com.example:foo:1.+>= 1.0.0 < 2.0.0
maven[version, version+1)[1.0.0, 2.0.0)同上
pub^version

~version
foo: ^1.0.0

foo: ~1.0.0
>= 1.0.0 < 2.0.0

>=1.0.0 < 1.1.0

^version 和 ~version 分别被称作 插入符语法(Caret Syntax7) 和 波形语法(Tilde Syntax8),他们的主要区别在于前者兼容当前版本后及后续所有的 次版本号及修订号,即 ^X.Y.Z 等价于 >=X.Y.Z
<(X+1).0.0;

而后着只兼容当前版本号及后续所有的修订号,即
~X.Y.Z 等价于 >=X.Y.Z
npm^versionfoo: ^1.0.0同上
pod~> versionpod 'foo', '~> 1'同上
匹配任意版本gradlecom.example:foo任意一个版本,具体约束可能由其他组件依赖了此组件并且存在具体约束,否则默认取最新的
maven[firstVersion,)[0.0.1,)>=0.0.1
pubanyfoo: any任意一个版本,具体约束可能由其他组件依赖了此组件并且存在具体约束,否则默认取最新的
npm*foo: *同上
podpod 'foo'同上
已发布的最新版本gradle+com.example:foo:+任意一个版本,具体约束可能由其他组件依赖了此组件并且存在具体约束,否则默认取最新的
mavenLATEST

LATESTLATEST 在maven 3.x版本被废弃
pubanyfoo: any任意一个版本,具体约束可能由其他组件依赖了此组件并且存在具体约束,否则默认取最新的
npm*foo: *同上
pod> 0.0.1pod 'foo', '>0.0.1'同上
大于当前版本gradle(version, )com.example:foo: (0.0.1, )
maven(version, )(0.0.1, )
pub>versionfoo: >0.0.1
npm> versionfoo: > 0.0.1
pod> versionpod 'foo', '> 0.0.1'
大于等于当前版本gradle[version, )com.example:foo: [0.0.1, )
maven[version, )[0.0.1, )
pub>=versionfoo: >=0.0.1
npm>= versionfoo: >= 0.0.1
pod>= versionpod 'foo', '>= 0.0.1'
小于当前版本gradle(, version)com.example:foo: (, 2.0.0)
maven(, version)(, 2.0.0)
pubfoo: <2.0.0
npm< versionfoo: < 2.0.0
pod< versionpod 'foo', '< 2.0.0'
小于等于当前版本gradle(, version]com.example:foo: (, 2.0.0]
maven(, version](, 2.0.0]
pub<=versionfoo: <=2.0.0
npm<= versionfoo: <= 2.0.0
pod<= versionpod 'foo', '<= 2.0.0'
范围区间gradle[version1, version2]com.example:foo: [1.0.0, 2.0.0]
maven[version1, version2][1.0.0, 2.0.0]
pub'>=version1 <=version2 'foo: '>=1.0.0 <=3.0.0'当存在区间约束的时候,版本号需要通过单引号进行包裹
npmversion1-version2

>=version1 <=version2
foo: 1.0.0-3.0.0


foo: >=1.0.0 <=3.0.0
version1 到 version的任意版本号,包含自身
pod>=version1, <=version2pod 'foo', '>= 1.0.0' , '<= 3.0.0'
范围集合gradle(,version1), [version2,)com.example:foo:
(,1.0.0),[3.0.0,)
< 1.0.0 或者 >= 3.0.0
maven(,version1), [version2,)(,1.0.0),[3.0.0,)同上
pub不支持不支持不支持
npmversion1version2foo: <1.0.0>= 3.0.0< 1.0.0 或者 >= 3.0.0
pod=version2pod 'foo', '< 1.0.0' , '>= 3.0.0'同上
排除制定版本gradle(,version), (version,)com.example:foo:
(,1.0.5),(1.0.5,)
不等于 1.0.5
maven(,version), (version,)(,1.0.5),(1.0.5,)同上
pub不支持不支持不支持
npm>versionfoo: <1.0.5>1.0.5不等于 1.0.5
pod!= versionpod 'foo', '!= 1.0.5'不等于 1.0.5
特有gradlemaven特殊版本标识: -SNAPSHOTcom.example:foo: 1.0.0-SNAPSHOT这个其实是maven的特殊版本标识,当你发布此带-SNAPSHOT标识版本后,maven自己会根据你的发布时间将版本展开为类似于1.0-yyyyMMdd-HHmmss-1 的格式,所以如果你带了此标识,你可以重复发布此版本,当前前提是你的maven开启了对应的配置。
其他特殊标识
dev

rc\snapshot\final\ga\release\sp
1. dev会被判定低于任何其他非数字部分,如:
1.0.0-dev < 1.0.0-ALPHA < 1.0.0-alpha < 1.0-rc
2. 字符串rc,snapshot,final,ga,release和 sp 被认为高于其他字符串部分(按此顺序排序),如:
1.0-zeta < 1.0-rc < 1.0-snapshot < 1.0-final < 1.0-ga < 1.0-release < 1.0-sp < 1.0


有些平台中还有一些特定的其他语法和规则,如果感兴趣,可以点击平台名称的超链接进入对应平台的官方文档自行查看。



相信你读到了这里,对语义化版本控制规范已经了然于胸。那么开篇的两个问题你是否也有了答案,欢迎在评论区留言。


Q&A 环节


经过上面的分享,相信大家对语义化版本已经有了一个整体的了解,那么我们来检验一下你的学习效果,请尝试回答下面几个问题:


Q:“v1.2.3” 是一个语义化版本号吗?


首先,“v1.2.3” 并不是的一个语义化的版本号。但是,在语义化版本号之前增加前缀 “v” 是用来表示版本号的常用做法。在版本控制系统中,将 “version” 缩写为 “v” 是很常见的。但是我们可以通过 npm-semver 来进行处理并转化成语义化的版本。


npm-semver可以帮你处理和转化语义化版本


Q:这么多规则及要求,我该如何验证我的语义化版本是否符合规范或者比较他们之间的大小关系呢?


这里就推荐 npm 的 github.com/npm/node-se…


node-semver 也可以帮你做到


对于脚本上对版本是否符合要求进行验证,可以使用 semver 2.0 文档中推荐的如下两个正则表达式。


第一个用于支持按组名称提取的语言,PCRE(Perl 兼容正则表达式,比如 Perl、PHP 和 R)、Python 和 Go。参见: regex101.com/r/Ly7O1x/3/



/^(?P0|[1-9]\d*).(?P0|[1-9]\d*).(?P0|[1-9]\d*)(?:-(?P(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:+(?P[0-9a-zA-Z-]+(?:.[0-9a-zA-Z-]+)*))?$/gm



第二个用于支持按编号提取的语言(与第一个对应的提取项按顺序分别为:major、minor、patch、prerelease、buildmetadata)。主要包括 ECMA Script(JavaScript)、PCRE(Perl 兼容正则表达式,比如 Perl、PHP 和 R)、Python 和 Go。 参见: regex101.com/r/vkijKf/1/



/^(0|[1-9]\d ).(0|[1-9]\d).(0|[1-9]\d )(?:-((?:0|[1-9]\d|\d*a-zA-Z-)(?:.(?:0|[1-9]\d |\da-zA-Z- )) ))?(?:+([0-9a-zA-Z-]+(?:.[0-9a-zA-Z-]+)))?$/gm



Q:万一不小心把一个不兼容的改版当成了次版本号发行了,或者在修订等级的发布中,误将重大且不兼容的改变加到代码之中,我能通过重复发布当前版本来解决问题吗?


首先必须强调一点,不管如何都不能去修改已发行的版本(这点在部分平台已经帮你处理掉了,例如 pub 本身已经做了这种限制)。然后最好根据场景升级一个对应级别的版本来回滚逻辑,最后再将你的重大且不兼容的改版升一个主版本号进行发布。记住,语义化的版本控制就是透过版本号的改变来传达意义。


尾声


至此,我们已经了解了语义化版本控制规范的具体细则,常用的先行版本号标识的含义及应用场景,希望能在大家日后的工作生活当中所有帮助。你还见过哪些常见的先行版本号,你们团队又是如何避免包依赖地狱的,欢迎在评论区补充。感谢大家的观看,再见。


作者:政采云技术
来源:juejin.cn/post/7278238875456684090
收起阅读 »

某研究生不写论文竟研究起了算命?

起因 大约一个月前,在学校大病一场(不知道是不是🐑了,反正在学校每天核酸没检测出来)在宿舍休息了整整一周。当时因为发烧全身疼所以基本一直躺着刷刷视频。看了一周倪海厦老师讲的天纪,人纪感悟颇多,中华传统中一些优秀的东西竟然在现代教育下被丢失了而现在的人也只有在身...
继续阅读 »

起因


大约一个月前,在学校大病一场(不知道是不是🐑了,反正在学校每天核酸没检测出来)在宿舍休息了整整一周。当时因为发烧全身疼所以基本一直躺着刷刷视频。看了一周倪海厦老师讲的天纪,人纪感悟颇多,中华传统中一些优秀的东西竟然在现代教育下被丢失了而现在的人也只有在身体不得不休息的情况下才会停止内卷慢下来好好思考。


当然有人会说算命啥的都是封建迷信,作为接受了科学思想洗礼的新时代人慢慢也不再去接受那一套,在这里呢我不对这些想法做任何评价。信则有不信则无,存在即合理嘛。


因为疫情原因呢学校早早就给我们放了假,有了更多的空闲时间可以思考在学校没时间想的事情,做一些除开看论文、做项目之外的事


开始


前几天买的服务器刚好到家了,花了几天配置好环境(最重要的是花了大半天解决todesk、向日葵远程黑屏的问题)。今天下午写好代码丢到阳台让它自己慢慢训练去,剩下的时间就开始写今天关于算命的小程序。


六壬法


六壬法


留连速喜赤口
大安空亡小吉

根据倪师讲的,计算现在的农历日期加上时辰就可以推算当前某个想法适不适合去做。以大安开始每次从当宫开始顺时针数,下面是例子。



  • 假如今天是农历十二月十号 子时




  1. 首先从大安开始数1到12,结果是空亡




  2. 再从空亡开始数1到10,结果是速喜




  3. 然后从速喜开始子丑寅卯这样数,子是1




  4. 所以上面例子最后的结果就是速喜




计算过程都理解了怎么写成代码呢。这里需要知道三个条件,农历的月日以及当前的时辰,农历的月日这个地方我借鉴了这篇博客【C/C++】:用C实现输出日期的阴历日子直接复制了主要内容,打表直接计算农历日期,只需要输入当前阳历的年月日。


然后当前时间转为十二时辰也很简单,首先得到当前的小时时间hour,那么十二时辰就是(hour+1)/2<12?(hour+1)/2:0;这里子时记为0。


整个程序如下:


#include<iostream>
#include<string>
#include<ctime>
#include<vector>

std::vector<std::string> MAP{"大安","留连","速喜","赤口","小吉","空亡"};

unsigned int LunarCalendarDay;
unsigned int LunarCalendarTable[199] =
{
0x04AE53,0x0A5748,0x5526BD,0x0D2650,0x0D9544,0x46AAB9,0x056A4D,0x09AD42,0x24AEB6,0x04AE4A

,/*1901-1910*/


0x6A4DBE,0x0A4D52,0x0D2546,0x5D52BA,0x0B544E,0x0D6A43,0x296D37,0x095B4B,0x749BC1,0x049754

,/*1911-1920*/


0x0A4B48,0x5B25BC,0x06A550,0x06D445,0x4ADAB8,0x02B64D,0x095742,0x2497B7,0x04974A,0x664B3E

,/*1921-1930*/


0x0D4A51,0x0EA546,0x56D4BA,0x05AD4E,0x02B644,0x393738,0x092E4B,0x7C96BF,0x0C9553,0x0D4A48

,/*1931-1940*/


0x6DA53B,0x0B554F,0x056A45,0x4AADB9,0x025D4D,0x092D42,0x2C95B6,0x0A954A,0x7B4ABD,0x06CA51

,/*1941-1950*/


0x0B5546,0x555ABB,0x04DA4E,0x0A5B43,0x352BB8,0x052B4C,0x8A953F,0x0E9552,0x06AA48,0x6AD53C

,/*1951-1960*/


0x0AB54F,0x04B645,0x4A5739,0x0A574D,0x052642,0x3E9335,0x0D9549,0x75AABE,0x056A51,0x096D46

,/*1961-1970*/


0x54AEBB,0x04AD4F,0x0A4D43,0x4D26B7,0x0D254B,0x8D52BF,0x0B5452,0x0B6A47,0x696D3C,0x095B50

,/*1971-1980*/


0x049B45,0x4A4BB9,0x0A4B4D,0xAB25C2,0x06A554,0x06D449,0x6ADA3D,0x0AB651,0x093746,0x5497BB

,/*1981-1990*/


0x04974F,0x064B44,0x36A537,0x0EA54A,0x86B2BF,0x05AC53,0x0AB647,0x5936BC,0x092E50,0x0C9645

,/*1991-2000*/


0x4D4AB8,0x0D4A4C,0x0DA541,0x25AAB6,0x056A49,0x7AADBD,0x025D52,0x092D47,0x5C95BA,0x0A954E

,/*2001-2010*/


0x0B4A43,0x4B5537,0x0AD54A,0x955ABF,0x04BA53,0x0A5B48,0x652BBC,0x052B50,0x0A9345,0x474AB9

,/*2011-2020*/


0x06AA4C,0x0AD541,0x24DAB6,0x04B64A,0x69573D,0x0A4E51,0x0D2646,0x5E933A,0x0D534D,0x05AA43

,/*2021-2030*/


0x36B537,0x096D4B,0xB4AEBF,0x04AD53,0x0A4D48,0x6D25BC,0x0D254F,0x0D5244,0x5DAA38,0x0B5A4C

,/*2031-2040*/


0x056D41,0x24ADB6,0x049B4A,0x7A4BBE,0x0A4B51,0x0AA546,0x5B52BA,0x06D24E,0x0ADA42,0x355B37

,/*2041-2050*/


0x09374B,0x8497C1,0x049753,0x064B48,0x66A53C,0x0EA54F,0x06B244,0x4AB638,0x0AAE4C,0x092E42

,/*2051-2060*/


0x3C9735,0x0C9649,0x7D4ABD,0x0D4A51,0x0DA545,0x55AABA,0x056A4E,0x0A6D43,0x452EB7,0x052D4B

,/*2061-2070*/


0x8A95BF,0x0A9553,0x0B4A47,0x6B553B,0x0AD54F,0x055A45,0x4A5D38,0x0A5B4C,0x052B42,0x3A93B6

,/*2071-2080*/


0x069349,0x7729BD,0x06AA51,0x0AD546,0x54DABA,0x04B64E,0x0A5743,0x452738,0x0D264A,0x8E933E

,/*2081-2090*/
0x0D5252,0x0DAA47,0x66B53B,0x056D4F,0x04AE45,0x4A4EB9,0x0A4D4C,0x0D1541,0x2D92B5

/*2091-2099*/
};

int MonthAdd[12] = {0,31,59,90,120,151,181,212,243,273,304,334};
int LunarCalendar(int year,int month,int day)
{
int Spring_NY,Sun_NY,StaticDayCount;
int index,flag;
//Spring_NY 记录春节离当年元旦的天数。
//Sun_NY 记录阳历日离当年元旦的天数。
if ( ((LunarCalendarTable[year-1901] & 0x0060) >> 5) == 1)
Spring_NY = (LunarCalendarTable[year-1901] & 0x001F) - 1;
else
Spring_NY = (LunarCalendarTable[year-1901] & 0x001F) - 1 + 31;
Sun_NY = MonthAdd[month-1] + day - 1;
if ( (!(year % 4)) && (month > 2))
Sun_NY++;
//StaticDayCount记录大小月的天数 29 或30
//index 记录从哪个月开始来计算。
//flag 是用来对闰月的特殊处理。
//判断阳历日在春节前还是春节后
if (Sun_NY >= Spring_NY)//阳历日在春节后(含春节那天)
{
Sun_NY -= Spring_NY;
month = 1;
index = 1;
flag = 0;
if ( ( LunarCalendarTable[year - 1901] & (0x80000 >> (index-1)) ) ==0)
StaticDayCount = 29;
else
StaticDayCount = 30;
while (Sun_NY >= StaticDayCount)
{
Sun_NY -= StaticDayCount;
index++;
if (month == ((LunarCalendarTable[year - 1901] & 0xF00000) >> 20) )
{
flag = ~flag;
if (flag == 0)
month++;
}
else
month++;
if ( ( LunarCalendarTable[year - 1901] & (0x80000 >> (index-1)) ) ==0)
StaticDayCount=29;
else
StaticDayCount=30;
}
day = Sun_NY + 1;
}
else //阳历日在春节前
{
Spring_NY -= Sun_NY;
year--;
month = 12;
if ( ((LunarCalendarTable[year - 1901] & 0xF00000) >> 20) == 0)
index = 12;
else
index = 13;
flag = 0;
if ( ( LunarCalendarTable[year - 1901] & (0x80000 >> (index-1)) ) ==0)
StaticDayCount = 29;
else
StaticDayCount = 30;
while (Spring_NY > StaticDayCount)
{
Spring_NY -= StaticDayCount;
index--;
if (flag == 0)
month--;
if (month == ((LunarCalendarTable[year - 1901] & 0xF00000) >> 20))
flag = ~flag;
if ( ( LunarCalendarTable[year - 1901] & (0x80000 >> (index-1)) ) ==0)
StaticDayCount = 29;
else
StaticDayCount = 30;
}
day = StaticDayCount - Spring_NY + 1;
}
LunarCalendarDay |= day;
LunarCalendarDay |= (month << 6);
if (month == ((LunarCalendarTable[year - 1901] & 0xF00000) >> 20))
return 1;
else
return 0;
}

void output(int year,int month,int day,int &d_month,int &d_day)
{
const char *ChDay[] = {"*","初一","初二","初三","初四","初五",
"初六","初七","初八","初九","初十",
"十一","十二","十三","十四","十五",
"十六","十七","十八","十九","二十",
"廿一","廿二","廿三","廿四","廿五",
"廿六","廿七","廿八","廿九","三十"
};
const char *ChMonth[] = {"*","正","二","三","四","五","六","七","八","九","十","十一","腊"};
char str[13] = "";
strcat(str,"农历");
if (LunarCalendar(year,month,day)){
strcat(str,"闰");
d_month=(LunarCalendarDay & 0x3C0) >> 6;
strcat(str,ChMonth[(LunarCalendarDay & 0x3C0) >> 6]);
}
else{
d_month=(LunarCalendarDay & 0x3C0) >> 6;
strcat(str,ChMonth[(LunarCalendarDay & 0x3C0) >> 6]);
}
strcat(str,"月");
d_day=LunarCalendarDay & 0x3F;
strcat(str,ChDay[LunarCalendarDay & 0x3F]);
puts(str);
}


int ChangeHourToPeriods(){
time_t now=time(0);
int hour;
std::tm* t=std::localtime(&now);
hour=(int)t->tm_hour;
hour=(hour+1)/2<12?(hour+1)/2:0;
return hour;
}


int main(){
int year,month,day;
std::cout<<"Please input the number of year,month,day:"<<std::endl;
std::cin>>year>>month>>day;
int d_month=0,d_day=0;
output(year,month,day,d_month,d_day);
int hour=ChangeHourToPeriods();
int SumAll=d_month+d_day+hour-2;
std::cout<<"The result is : "<<MAP[(SumAll%6)]<<std::endl;
return 0;
}

因为每次从当宫开始数也就每次都少数了1,但是由于最后子时以0开始所以只减2。


测试结果(测试的时间是21点亥时)
在这里插入图片描述


占卦法


占卦法


还有傅佩荣教授的三组三位数占卦法,这个更多就是易经中的内容太过于深奥,所以直接说计算方法。


三组三位数分别代表下卦,上卦和爻,卦象的三位数对8取余爻对6取余,如果整除就记为除数本身。


然后再去六十四卦中复制打表,最后得到卦象以及爻


整体实现如下


#include<iostream>
#include<string>
#include<vector>


std::vector<std::string> TRIGRAM=std::vector<std::string> {"乾","兑","离","震","巽","坎","艮","坤"};
std::vector<std::string> TRIGRAMMAP {
"乾为天","泽天夬","火天大有","雷天大壮","风天小畜","水天需","山天大畜","地天泰",
"天泽履","兑为泽","火泽睽","雷泽归妹","风泽中孚","水泽节","山泽损","地泽临",
"天火同人","泽火革","离为火","雷火丰","风火家人","水火既济","山火贲","地火明夷",
"天雷无妄","泽雷随","火雷噬嗑","震为雷","风雷益","水雷屯","山雷颐","地雷复",
"天风姤","泽风大过","火风鼎","雷风恒","巽为风","水风井","山风蛊","地风升",
"天水讼","泽水困","火水未济","雷水解","风水涣","坎为水","山水蒙","地水师",
"天山遁","泽山咸","火山旅","雷山小过","风山渐","水山蹇","艮为山","地山谦",
"天地否","泽地萃","火地晋","雷地豫","风地观","水地比","山地剥","坤为地"

};

int main(){
std::vector<int> LowToHigh(3);
std::vector<std::string> results(3);
std::cout<<"Input 3*xxx like(111,222,333),means from up to high"<<std::endl;

for(int i=0;i<3;++i){
std::cin>>LowToHigh[i];
}

LowToHigh[0]=LowToHigh[0]%8==0?8:LowToHigh[0]%8;
LowToHigh[1]=LowToHigh[1]%8==0?8:LowToHigh[1]%8;
LowToHigh[2]=LowToHigh[2]%6==0?6:LowToHigh[2]%6;



for(int i=0;i<2;++i){
results[i]=TRIGRAM[LowToHigh[i]-1];
}
results[2]=std::to_string(LowToHigh[2]);

std::cout<<"下卦:"<<results[0]<<" 上卦:"<<results[1]<<" "<<results[2]<<std::endl;
std::cout<<"卦象: "<<TRIGRAMMAP[(LowToHigh[0]-1)*8+LowToHigh[1]-1]<<std::endl;
}

这里测试的例子是视频中的数字
在这里插入图片描述


结尾


有的时候真的需要一些自己的沉淀时间,不能忘了最初的目标。写这篇Blog也并不是为了宣传封建迷信,而是希望让更多程序圈的人想想当初我们喜欢敲代码到底是为了什么?我们喜欢的是将代码作为工具实现一些有趣的功能,并不是为了水论文或者工作被迫的去东拼西凑弄出一些用处不大的东西。


好多想吐槽的话最终还是打了又删,无法改变现状的时候只能屈服于现状,我相信不止我一人如此。但是请不要忘了 潜龙勿用见龙在田,终日乾乾飞龙在天


作者:shelgi
来源:juejin.cn/post/7176629565559685178
收起阅读 »

使用后端代码生成器,提高开发效率

如果你是一名后端开发者,那么大多数的工作一定是重复编写各种 CRUD(增删改查)代码。时间长了你会发现,这些工作不仅无趣,还会浪费你的很多时间,没有机会去做更有创造力和挑战的工作。 作为一名程序员,一定要学会偷懒!学会利用工具来解放人力。 其实现在有很多现成的...
继续阅读 »

如果你是一名后端开发者,那么大多数的工作一定是重复编写各种 CRUD(增删改查)代码。时间长了你会发现,这些工作不仅无趣,还会浪费你的很多时间,没有机会去做更有创造力和挑战的工作。


作为一名程序员,一定要学会偷懒!学会利用工具来解放人力。


其实现在有很多现成的代码生成器,可以帮助我们自动生成常用的增删改查代码,而不用自己重复编写,从而大幅提高开发效率,所以大家一定要掌握。


对应到 Java 后端开发,主流技术是 Spring Boot + Spring MVC + MyBatis 框架,使用这些技术来开发项目时,通常需要编写数据访问层 (DAO / Mapper) 和数据库表的 XML 映射代码、实体类、Service 业务逻辑代码、以及 Controller 接口代码。


本文就以使用 IDEA 开发工具中我认为非常好用的免费代码生成插件 MyBatisX 为例,带大家学习如何使用工具自动生成后端代码,节省时间和精力。


MyBatisX 自动生成代码教程


1、安装 MyBatisX 插件


首先,确保你已经安装了 IntelliJ IDEA 开发工具。


打开你的项目工程,然后进入 Settings 设置页搜索 MyBatisX 插件并安装,步骤如图:



2、配置数据库连接


MyBatisX 插件的核心功能是根据数据库表的结构来生成对应的实体类、数据访问层 Mapper、Service 等代码,所以在使用前,我们需要在 IDEA 中配置一个数据库连接。


先在 IDEA 右侧的 Database 中创建一个 MySQL 数据源配置:



然后根据自己的数据库信息填写配置,并测试能否连接成功:



连接成功后,就可以在 IDEA 中管理数据库了,不需要 Navicat 之类的第三方工具:



3、使用 MyBatisX 生成代码


右键要生成代码的数据表,进入 MyBatisX 生成器:



然后进入生成配置页面,可以根据你的需求来自定义代码生成规则:



上述配置中,我个人建议 base package (生成代码的包名和位置)尽量不要和已有的项目包名重叠,先把代码生成到一个完全不影响业务的位置,确认生成的代码没问题后,再移动代码会更保险一些。


进入下一步,填写更多的配置,可以选择生成代码的模板(一般是 MyBatis-Plus 模板),以及自定义实体类的生成规则(一般建议用 Lombok)。


以下是我常用的推荐配置:



改完配置后,直接点击生成即可,然后可以在包目录中看到生成的代码:



4、定制修改


通过以上方法,就已经能够完成基础增删改查代码的生成了,但一般情况下,我们得到生成的代码后,还要再根据自己的需求进行微调。


比如把主键 ID 的生成规则从自动递增改为雪花算法生成,防止数据 id 连续被别人轻松爬走:



最后你就可以使用现成的代码来操作数据库啦~


其他


如开头所说,现在的代码生成器非常多,比如 MyBatis Plus 框架也提供了灵活的代码生成器:



指路:baomidou.com/pages/98140…




再比如可以直接在浏览器使用的代码生成器,鱼皮自己也开发过并且开源了:



指路:sqlfather.yupi.icu/


开源:github.com/liyupi/sql-…




感兴趣的话,大家也可以尝试使用 FreeMarker 技术做一个属于自己的代码生成器。


实践


编程导航星球的用户中心项目使用了 MyBatisX 插件来生成代码,非常简单,大家一定要学会运用!


作者:程序员鱼皮
来源:juejin.cn/post/7300949817378308123
收起阅读 »

中介思想背后的三大技术意识,你具备了哪些?

不论在天上,在自然界,在精神中,不论在哪个地方,没有什么东西不是同时包含着直接性和间接性的。——黑格尔 代码既是一种艺术创作,也是一种工艺制造,其中也包含诸多中介。 以下是一个简单认识中介的例子: 中介活动:中介活动系指中介人居间帮助 委托方、委托方合作者(...
继续阅读 »

不论在天上,在自然界,在精神中,不论在哪个地方,没有什么东西不是同时包含着直接性和间接性的。——黑格尔



代码既是一种艺术创作,也是一种工艺制造,其中也包含诸多中介。


以下是一个简单认识中介的例子:


中介活动:中介活动系指中介人居间帮助

委托方、委托方合作者(下简称合作者)双方达成某项协议/契约/合同的活动。


嗯,读到这儿好像还能理解,以买房为例,大概就如下图所示:


中介活动图.jpg


但还得再加上这么一句话,但在中介过程中,牵涉到中介人与委托方(甲、乙方或双方)

签约、发布、寻找委托方合作者、协调甲、乙方签约、帮助完成签约和追索并获得报酬等活动。


中介活动图2.jpg


相比上一张图,这张图更能体现出中介具体做了哪些工作



  • 积极收集符合委托方条件的合作者;

  • 和合作者讨价还价;

  • ······


当然,中介并不是白干这些活,他最终也是需要中介费的,这也就是委托方的成本。


看完只想说,啊啊啊啊可恶要长脑子了,不过没有关系,在代码意识中,成本的耗费相比模块和架构意识少。




代码意识


言归正传,我们直入主题,看以下两个案例:




  • 有代码块 A、B、C... 想使用变量 “str”,我们往往会通过静态常数描述它,

    如:static String CONSTANT = "str"




  • 委托方:代码块 A、B、C...




  • 中介人:CONSTANT




  • 合作者:"str"




  • 有类 A、B、C... 想使用类 X,在 Spring 框架中,我们常常会通过注入的方式让 X 被其他类依赖.




  • 委托方:类 A、B、C...




  • 中介人:Spring 容器




  • 合作者:类 X




上述只是两个简单的中介行为案例,现实生活中委托方和合作者往往都会向中介人提供自己的需求,

而中介人则需要根据需求推荐委托方或合作者。


衍生出下一个案例:



  • 在一个方法中,入参为 code,而这个方法动作则需要根据不同的 code 执行不同的逻辑。

    如:


void performLogic(String code) {  

}

如果 code 的变化是固定的,例如像英文字母,无论如何都是 26 个,那我们穷举出来,其实也不耽误代码的扩张性,

只是过于冗长有点丑陋,但这种情况在实际中偏少。


void performLogic(String code) {  
if (code == "A") {

} else if(code == "B") {

} ... {

} else if (code == "Y") {

} else {

}
}

实际开发过程中,code 的变化往往是动态的,考虑维护成本和扩张性的功能,所以在方法performLogic()

显然不能因为 code 的动态变化而变化。


那可不可以找一个中介,让其提前知晓 code 对应的逻辑,每当 code 投来,我们让它把对应的逻辑给到委托者,

这样,委托者只需要关心自己在什么场景下传递什么 code,而不需要关心具体的逻辑怎么做。


这种情景 Map 结构再合适不过,因此可以这么写:


  
@Value // get
private final Map<String, Logic> knownLogics;

void performLogic(String code) {
Logic logic = knownLogics.getOrDefault(code, defaultLogic);
logic.performed();
}

那以上的身份可以确定如下:



  • 委托者:执行 performLogic() 的业务

  • 中介者:knownLogics

  • 合作者:对应的逻辑


中介活动也显然易见:



  1. 中介提前知晓委托者(上层业务)的需求(code)对应哪些合作者(逻辑)

  2. 委托者将需求给中介(knownLogics)

  3. 中介将对应的合作者告知委托者

  4. 委托者与合作者完成合作


中介者的身份有效地将委托者与合作者进行了解藕,彼此各尽其职。


相反,如果在此处采取 “字母”的做法,那么每当出现新的 code ,那么都需要在方法 performLogic() 中修改。


综上,使用中介思想可以让委托者和合作者在遵循单一职责和开闭原则的同时,还能保证委托者与合作者合作的代码不变,

是符合面向对象设计原则的。因此,使用中介思想可以促进开发人员理解面向对象设计原则和灵活使用设计模式,进而提高代码质量。




模块意识


以规则引擎在众安无界山理赔中心的应用为例:


在理赔业务中,主要有报案、立案、定损、理算和核赔五大流程,每一个流程进行至下一步时都需要进行规则校验,

例如有黑名单客户校验、反洗钱校验等校验规则。


如果将这些规则嵌套在每一步流程的代码中,那么一旦面对规则逻辑需要修改时,就不得不在原有代码上进行修改,

这导致规则与代码逻辑强耦合,并且每一次修改规则时,都需要重新编译代码。


我们可以通过中介意识将这个问题解决,我们将每个被校验的对象当作变量 x

在经过一个函数:


Fn(x1x2...,xn){0,1}F_n(x_1,x_2,..., x_n) \in
\begin{Bmatrix}
0, 1
\end{Bmatrix}

后得到通过或不通过。


理赔传参至函数.png


到这一步,我们也只是知道了委托方(业务代码)、委托方的需求(变量 X)及合作者(函数)


那中介是谁呢?没错,这个中介就是要新增的模块


言归正传,我们回到规则引擎在无界山理赔中心的应用中,那么我们可以确定以下身份:



  • 委托方:业务代码

  • 中介:规则引擎

  • 合作者:规则组(一簇规则;函数)


中介活动如下:



  1. 委托方(业务代码)提供需求(被校验的对象)给中介(规则引擎)

  2. 中介寻找合作者(规则组)

  3. 合作者按照委托方的需求签订协议(校验结果)


有了如上意识后,我们可以将规则引擎单独做一个模块去开发,然后使业务模块依赖,最后通过“创造(配置)”合作者(规则)。


这样,所有要使用到规则校验的业务代码都只需要通过规则引擎的入口,传递指定的需求和规则组 code 即可完成校验,如下图:


理赔传参至函数2.png


事实上,从模块意识开始,成本的问题就略有呈现了,例如:



  • 创建出中介;

  • 编写中介找到合作者逻辑;

  • 合作者创造出来,应该存储在何处?又如何管理?


通常来讲,都是存储到数据库,又通过接口调用进行增删改查,虽然与业务代码进行了解耦,但需要另取资源存储和管理,

那这样是否是拆东墙补西墙呢?


回答这个问题之前,反过来问一个问题,如果保持原来的做法,没有中介,那又会怎么样呢?因此这就成了对比,需要在权衡之下做选择。


显然,有了中介能够拆更少的东墙补更多的西墙。




架构意识



以前车马很慢,书信很远,一生只够爱一个人。



为了能让信封能够抵达心上人的手上,往往会将信封塞到信箱中,或是托信使帮忙托送,尔后忙于其他。


架构亦是如此,服务与服务之间难免存在沟通的情况,例如:



  1. 如果服务 A 需要且满足某接口,那么通常会让服务 A 寻找实现了该接口的服务;

  2. 如果服务 A 只是需要某服务的处理,并不关心处理的细节,那么通常会让 A 传递给信使,信使再告诉能帮助 A 的服务 X。


从中介思想的角度看上述两个案例,需要解决两个问题:



  1. 案例 1 中 A 是如何找到实现了该接口的服务?

  2. 案例 2 中的信使是谁?又如何找到他?


问题显而易见:



  1. 案例 1 中 A 肯定是通过中介才找到实现了该接口的服务;

  2. 案例 2 中 A 肯定也是通过中介才找到信使;

  3. 案例 2 中 信使自己本身也是一个中介人,负责存储 A 的需求和寻找帮助 A 的服务 X。


事实上,上述的案例就是现在的远程过程调用(Remote Procedure Call, 下简称 RPC)

和消息队列(Message Queue, 下简称 MQ)。


案例 1 (以 Dubbo 框架作为 RPC 框架为例)的身份确定如下:



  • 委托方:服务 A

  • 中介:注册中心

  • 合作者:实现了该接口的服务





案例 1 的中介活动如下:



  1. 委托方(服务 A)已知合作者(实现了该接口的服务)的要求(接口信息)

  2. 委托方按要求提供信息给中介

  3. 中介根据委托方提供的信息寻找合适(时间、天气等外部因素)的合作者

  4. 委托方得到合作者的答复(响应结果)


案例 2 的身份确定如下:



  • 委托方:服务 A

  • 中介 C:配置中心

  • 合作者 M 兼中介 M:消息队列

  • 合作者 X:帮助服务 A 的服务 X


生产者-消费者.jpg


案例 2 的中介活动如下:



  • 委托方(服务 A)从中介 C (配置中心)得知有中介 M (消息队列)可以帮助他

  • 委托方找到中介 M 拖信(消息体)

  • 中介 M 将信传给委托方指定的合作者 X (帮助服务 A 的服务)


中介意识在当前分布式架构中非常常用,除了 RPC 和 MQ 用于服务之间的交流之外,

还诞生了许多中介人用于不同的场景,例如:



  • 充当中介的事务协调者,用于分布式事务场景;

  • 充当中介的分布式锁,用于多服务对共享资源的访问;

  • 充当中介的负载均衡器,用于多服务时的负载均衡;

  • 充当中介的服务监控,用于监视多服务沟通链路;

  • ······


到这儿,作为造物主的你此时会发现,除了在完成功能的服务之外,令你头疼的不仅仅是功能逻辑,

还涉及到了如何让功能在各种场景下运行,因此你做了不少非原有功能的事情。


这就是成本,它不再是“多写几行代码”这种简单的成本,此时的它显然变得不可忽视。


那是不是就可以随意妄为呢?什么中介,这些成本才不想考虑。


那更有趣,如果我们的生活中没有像招标、房屋、拍卖和招聘这种中介,似乎好像也没啥影响,无疑是变得不方便。

但中介有没有可能是物,是思想呢?

比如一个人想让另一个人消失,是什么在约束他呢......


总结


艺术来源于生活,代码也如此,程序员也是一种艺术家,如今在现实生活中已有很多中介案例,只需要模仿或照搬。

特别地是,程序员有着与生俱来的逻辑感,他们热衷于为什么,于是在代码世界中将那些曾经的工匠精神复燃,

在那里,重现了将动力和转矩传递到所需处的齿轮、解决远距离沟通的电话乃至能量转换的发动机的发明。


参考文献


[1] Dubbo 官方文档


[2] 黑格尔. 逻辑学[M]. 北京: 商务印书馆, 1976.


作者:Masker
来源:juejin.cn/post/7300758264328683529
收起阅读 »

防抖是回城,节流是攻击

web
前言 防抖和节流是前端开发中常用的函数优化手段,它们可以限制函数的执行频率,提升性能和用户体验。在我们的日常开发中,经常会遇到一些需要对函数进行优化的场景,比如防止表单的重复提交。 一 防抖与节流的区别 我们简单描述下它们的作用 防抖:它限制函数在一段连续的时...
继续阅读 »

前言


防抖节流是前端开发中常用的函数优化手段,它们可以限制函数的执行频率,提升性能和用户体验。在我们的日常开发中,经常会遇到一些需要对函数进行优化的场景,比如防止表单的重复提交。


一 防抖与节流的区别


我们简单描述下它们的作用


防抖:它限制函数在一段连续的时间内只执行一次。当连续触发某个事件时,只有在事件停止触发一段时间后,才会执行函数。


节流:它按照固定的时间间隔执行函数。当连续触发某个事件时,每隔一段时间执行一次函数。


简而言之,防抖是在事件停止触发后延迟执行函数,而节流是按照固定的时间间隔执行函数。


因为防抖节流的作用和应用场景基本相同,也就导致它们容易被人混淆,不好记忆。


之前在网上看到了一个例子非常的有趣形象,和大家分享下。


王者荣耀大家都玩过吧,里面的英雄都有一个攻击间隔,当我们连续的点击普通攻击的时候,英雄的攻速并不会随着我们点击的越快而更快的攻击。这个其实就是节流,英雄会按照自身攻速的系数执行攻击,我们点的再快也没用。


而防抖在王者荣耀中就是回城,在游戏中经常会遇到连续回城嘲讽对手的玩家,它们每点击一次回城,后一次的回城都会打断前一次的回城,只有最后一次点击的回城会被触发,从而保证回城只执行一次,这就是防抖的概念。


自从我看到这个例子后,节流和防抖就再也没记混过了。作为一个8年王者老玩家。


下面是防抖和节流的实现


防抖的实现与使用


防抖的应用场景:



  1. 输入框搜索:当用户在搜索框中输入关键字时,使用防抖可以避免频繁发送搜索请求,而是在用户停止输入一段时间后才发送请求,减轻服务器压力。

  2. 窗口调整:当窗口大小调整时,使用防抖可以避免频繁地触发重排和重绘操作,提高页面性能。

  3. 按钮点击:当用户点击按钮时,使用防抖可以避免用户多次点击造成的多次提交或重复操作。


immediate参数用于控制防抖函数是否立即触发,true立即触发,false过delay时间后触发。


<!DOCTYPE html>
<html lang="en">

<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>

<body>
<button id="btn">按钮</button>
<script>
function debounce(func, delay, immediate) {
let timer;
return function () {
let context = this;
let args = arguments;

if (timer) {
clearTimeout(timer)
}

if (immediate && !timer) {
func.apply(context, args)
}

timer = setTimeout(() => {
timer = null
if (!immediate) {
func.apply(context, args)
}
}, delay);
}
}

// 创建一个被防抖的函数
const debouncedFunction = debounce(() => {
console.log("Debounced function executed.");
}, 1000, false);

document.getElementById('btn').addEventListener('click', debouncedFunction)

</script>
</body>

</html>

节流的实现与使用


节流的应用场景:



  1. 页面滚动:当页面滚动时,使用节流可以限制滚动事件的触发频率,减少事件处理的次数,提高页面的响应性能。

  2. 鼠标移动:当鼠标在某个元素上移动时,使用节流可以减少事件处理的次数,避免过于频繁的操作。


<!DOCTYPE html>
<html lang="en">

<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>

<body>
<button id="btn">按钮</button>
<script>

function throttle(func, delay, immediate) {
let timer;
return function () {
const context = this
const args = arguments

if (timer) {
return
}

if (!timer && immediate) {
func.apply(context, args)
}

timer = setTimeout(() => {
timer = null

if (!immediate) {
func.apply(context, args)
}
}, delay);
}
}

// 创建一个被节流的函数
const throttledFunction = throttle(() => {
console.log("throttled function executed.");
}, 1000, false);

document.getElementById('btn').addEventListener('click',throttledFunction)
</script>
</body>

</html>

结尾


看完本文章后,希望能够加深大家对防抖和节流的印象,分清二者的区别。


作者:欲买炸鸡同载可乐
来源:juejin.cn/post/7301244391153467431
收起阅读 »

买房后,害怕失业,更不敢裸辞,心情不好就提前还房贷,缓解焦虑

自从买房后,心态有很大变化。虽然住自己的房子,心情和体验都很好,但是一把掏空钱包,很焦虑。买房后现金流一直吃紧,再加上每年16万的房贷,我很焦虑会失业。之前我喜欢裸辞,现在不敢想裸辞这个话题。尤其是在行业下行期,找工作很艰难,背着房贷裸辞,简直是头孢就酒,嫌命...
继续阅读 »

自从买房后,心态有很大变化。虽然住自己的房子,心情和体验都很好,但是一把掏空钱包,很焦虑。买房后现金流一直吃紧,再加上每年16万的房贷,我很焦虑会失业。之前我喜欢裸辞,现在不敢想裸辞这个话题。尤其是在行业下行期,找工作很艰难,背着房贷裸辞,简直是头孢就酒,嫌命太久。


焦虑的根源是背负房贷,金额巨大,而且担心40岁以后失业,还不上房贷。


一次偶然的沟通


"你的贷款利率调整了吗",同事问我。


同事比我早两年在北京买房,他在顺义买的,我在昌平买的,我俩一直有沟通房贷的问题。但我没听说利率有调整,银行好像也没通知我,于是我问道:”我不知道啊,你调整了?调到多少了?“。


”调的挺多的,已经降到了 4.3%“。同事兴高采烈的回复我。


”这么牛逼,之前我记得一直是4.85%,我去看看我的利率“,我听说房贷利率下降那么多,很是兴奋。


然而我的房贷利率没有调整,我尝试给银行打电话,沟通的过程很坎坷。工商银行客服说了很多,大概意思是:利率会自动调整,无需申请,但是要等到利率调整日才会调整”。我开始很不理解,很生气,利率都调整了,别人也都调整了,凭什么不给我调整呢?


我想到同事有尝试提前还贷,生气的时候,我就萌发了提前还贷的想法。


开始尝试提前还贷,真香


我在22年初贷款买房,其中商业贷款 174 万,贷款25年,等额本息,每个月要还 1 万的房贷。公积金贷款每个月大概需要还 2500。每个月一万二的房贷还是很有压力的,尤其是刚买房的这一两年,兜里比脸都干净,没存款,不敢失业,更不敢裸辞。


即便兜里存款不多,也要提前还贷,因为实在太香了。


我在工行App上,申请 提前还贷,选择缩短 18个月的房贷,只需要 6万2,而我每个月房贷才1万,相当于是用 6 万 顶 18 万的房贷。还有比这更划算的事情吗?


image.png
预约提前还款后,银行会安排一个时间,在这个时间前,把钱存进去。到时候银行就会扣除,如果扣除金额不足,那么提前还款计划则自动终止,需要重新预约!


工行的预约还款时间大概是1个月以后,我是10-15号申请提前还款,银行给的预约日期是 11-14号,大概是1个月。


提前还款,比理财强多了


这次还贷以后,我又申请了提前还款, 提前还 24 期,只需要 9 万,也就是 9 万顶 24 万;提前还 60 期,只需要 24 万,相当于 24 万顶 60 万。


image.png


image.png


还有比提前还贷收益更高,风险更低的理财方式吗?没有! 除了存款外,任何理财都是有风险的。债券和基金收益和风险挂钩,想找到收益5%的债券基金,要承担亏本风险。你惦记人家的利息,人家惦记你的本金!


股票的风险更不必说,我买白酒股票已经被套的死死,只能躺平装死。(劝大家不要入 A 股)


提前还贷划算吗?


我目前的贷款利息是 4.85%,而存到银行的利息不会超过 3% ,很多货币基金只有 2%了。两者利息差高达 3%,肯定是提前还贷款更加合适。


要明白,一年两年短期的利息差还好,但是房贷可是高达 25 年。25年 170 万贷款 3% 的利息差,这个金额太大了。提前还了,省下来的钱还是很多的。例如刚才截图里展示的 提前还 24 万顶了 60 万的房贷。


网上很多砖家说,“要考虑通货膨胀因素,4.85% 的贷款利率和实际通货膨胀比起来不高,提前还款不划算。”


砖家说话都是昧良心的。提前还贷款是否划算,只需要和存款利率比就行了,不需要和通货膨胀比。因为把钱存在银行也会因为通货膨胀贬值。只有把钱 全都消费,全部花光才不会受通货膨胀的困扰,建议砖家,多消费,把家底败光,这样最划算!


砖家们一定是害怕太多人提前还贷,影响了银行的放贷生意。今年上半年,提前还贷已经成潮流,有些银行坐不住,甚至关闭了提前还贷的入口…… 所以要抓紧,没准哪天就提高了还贷门槛,或者直接禁止。


程序员群体收入高,手里闲钱多,可以考虑提前还贷款,比存银行划算多了,别再给银行打工了!


作者:五阳神功
来源:juejin.cn/post/7301530293378727971
收起阅读 »

刚入职因为粗心大意,把事情办砸了,十分后悔

刚入职,就踩大坑,相信有很多朋友有我类似的经历。 5年前,我入职一家在线教育公司,新的公司福利非常好,各种零食随便吃,据说还能正点下班,一切都超出我的期望,“可算让我找着神仙公司了”,我的心里一阵窃喜。 在熟悉环境之后,我趁着上厕所的时候,顺便去旁边的零食摊挑...
继续阅读 »

刚入职,就踩大坑,相信有很多朋友有我类似的经历。


5年前,我入职一家在线教育公司,新的公司福利非常好,各种零食随便吃,据说还能正点下班,一切都超出我的期望,“可算让我找着神仙公司了”,我的心里一阵窃喜。


在熟悉环境之后,我趁着上厕所的时候,顺便去旁边的零食摊挑了点零食。接下来的一天里,我专注地配置开发环境、阅读新人文档,当然我也不忘兼顾手边的零食。


初出茅庐,功败垂成


"好景不长",第三天上午,刚到公司,屁股还没坐热。新组长立刻给我安排了任务。他决定让我将配置端的课程搜索,从使用现有的Lucene搜索切换到ElasticSearch搜索。这个任务并不算复杂,然而我却办砸了。


先说为什么不复杂?



  1. ElasticSearch的搜索功能 基于Lucene工具库实现的,两者在搜索请求构造方式上几乎一致,在客户端使用上差异很小。


image.png



  1. 切换方案无需顾虑太多稳定性问题。由于是配置端课程搜索,并非是用户端搜索,所以平稳切换的压力较小、性能压力也比较小。


总的来说,领导认为这个事情并不紧急,重要性也不算高,而且业务逻辑相对简单,难度能够把握,因此安排我去探索一下。可是,我却犯了两个错误,把入职的第一件事办砸了。现在回过头来看,十分遗憾!


image.png


难以解决的bug让我陷入困境


将搜索方式从Lucene切换为ElasticSearch后,如何评估切换后搜索结果的准确度呢?


除了通过不断地回归测试,还有一个更好的方案。


我的方案是,在调用搜索时同时并发调用Lucene搜索和ElasticSearch搜索。在汇总搜索结果时,比对两者的搜索结果是否完全一致。如果在切换搜索引擎的过程中,两个方案的搜索结果不一致,就打印异常搜索条件和搜索结果,并进行人工排查原因。


image.png


在实际切换过程中,我经常遇到搜索数据不一致的情况,这让我感到十分苦恼。我花了一周的时间编写代码,然后又用了两周多的时间来排查问题,这超出了预估的时间。在这个过程中,我感到非常焦虑和沮丧。作为一个新来的员工,我希望能够表现出色,给领导留下好印象。然而事与愿违,难以解决的bug让我陷入困境。


经过无数次的怀疑和尝试,我终于找到了问题的根源。原来,我忘记了添加排序方式。


因为存在很多课程数据,所以配置端搜索需要分页搜索。在之前的Lucene搜索方式中,我们使用课程Id来进行排序。然而在切换到新的ElasticSearch方案中时,我忘记了添加排序方式。这个错误的后果是,虽然整体上结果是一致的,但由于新方案没有排序方式,每一页的搜索结果是随机的,无法预测,所以与原方案的结果不一致。


image.png
新方案加上课程Id排序方式以后,搜索结果和原方案一致。


为此,我总结了分页查询的设计要点!希望大家不要重复踩坑!# 四选一,如何选择适合你的分页方案?


千万不要粗心大意


实际上,在解决以上分页搜索没有添加排序方式的问题之后,还存在着许多小问题。而这些小问题都反映了我的另一个不足:粗心大意。


正是这些小问题,导致线上环境总会出现个别搜索结果不一致的情况,导致这项工作被拖延很久。


课程模型是在线教育公司非常核心的数据模型,业务逻辑非常复杂,当然字段也非常多。在我入职时,该模型已经有120 个字段,并且有近 50 个字段可以进行检索。


在切换搜索方式时,我需要重新定义各种DO、DTO、Request等类型,还需新增多个类,并重新定义这些字段。在这个过程中,我必须确保不遗漏任何字段,也不能多加字段。当字段数量在20个以内时,这项工作出错的可能性非常低。然而,班课模型却有多达120个字段,因此出错的风险极大。当时我需要大量搬运这些字段,然而我只把这项工作看作是枯燥乏味的任务,未能深刻意识到出错的可能性极大,所以工作起来散漫随意,没有特别仔细校验重构前后代码的准确性。


image.png
墨菲定律:一件事可能出错时就一定会出错



墨菲定律是一种普遍被接受的观念,指出如果某件事情可能出错,那么它将以最不利的方式出错。这个定律起源于美国航天局的项目工程师爱德华·墨菲,在1950年代发现了这一规律。


墨菲定律还强调了人类的倾向,即将事情弄糟或让事情朝着最坏的方向发展。它提醒人们在计划和决策时要考虑可能出错的因素,并准备应对不利的情况。



墨菲定律实在是太准了,当你感觉某个事情可能会出错的时候,那它真的就会出错。而且我犯错不止一次,因为有120个字段,很多字段的命名非常相似,最终我遗漏了2个字段,拼写错误了一个字段,总共有三个字段出了问题。


不巧的是,这三个字段也参与检索。当用户在课程搜索页面选择这三个字段来进行检索时,因为字段的拼写错误和遗漏,这三个字段没有被包含在检索条件中,导致搜索结果出错……


导致这个问题的原因有很多,其中包括字段数量太多,我的工作不够细致,做事粗心大意,而且没有进行充分的测试……


为什么没有测试


小公司的测试人员相对较少,尤其是在面对课程管理后台的技术重构需求时,更加无法获取所需的测试资源!


组长对我说:“ 要人没有,要测试更没有!”


image.png


事情办砸了,十分遗憾


首先,从各个方面来看,切换搜索引擎这件事的复杂度和难度是可控的,而且目标也非常明确。作为入职后第一项任务,我应该准确快速地完成它,以留下一个良好印象。当然,领导也期望我能够做到这一点,然而事实与期望相去甚远。


虽然在线上环境没有出现问题,但在上线后,问题排查的时间却远远超出了预期,让领导对结果不太满意。


总的来说,从这件事中,我获得的最重要教训就是:对于可能出错的事情,要保持警惕。时刻用墨菲定律提醒自己,要仔细关注那些可能发生小概率错误的细节问题。


对于一些具有挑战性的工作,我们通常都非常重视,且在工作中也非常认真谨慎,往往不会出错。


然而,像大量搬运代码、搬运大量字段等这类乏味又枯燥的工作确实容易使人麻痹大意,因此我们必须提高警惕。要么我们远离这些乏味的工作,要么就要认真仔细地对待它们。


否则,如果对这些乏味工作粗心大意,墨菲定律一定会找上你,让你在线上翻车!


作者:他是程序员
来源:juejin.cn/post/7295576148364787751
收起阅读 »

35岁遭遇父亲肺癌、失业、失恋. . . . . .

写在前面 目前已经上班快两个月了,对现在的工作很满意,甚至说更喜欢这的氛围吧。 如题所示,从今年5月开始,发生的所有事,都完全超出了我自己可以承受的范围,好在这一切都过去了,真的感谢上天安排,让我能更加确信自己要的是什么,以后该怎么生活。 爸爸被诊断为肺癌 我...
继续阅读 »

写在前面


目前已经上班快两个月了,对现在的工作很满意,甚至说更喜欢这的氛围吧。


如题所示,从今年5月开始,发生的所有事,都完全超出了我自己可以承受的范围,好在这一切都过去了,真的感谢上天安排,让我能更加确信自己要的是什么,以后该怎么生活。


爸爸被诊断为肺癌


我每年都会带父母去做体检,因为去年疫情全面放开后,担心被传染。寻思稳定稳定再去。


后爸爸因为走路崴脚在家养了三个月,就一直没去上体检。


有一天下班爸爸跟我说,心脏不得劲,心总疼,而且还上不来气,我说那明天去医院看看吧。


由于我工作项目忙还总加班,就让姐姐陪爸爸一起去检查了。


由于比较有名的医院,都没号了,姐姐就去了某国际医院(私立医院),做了全面检查,通过各种CT的检查结果汇总,医院给出的答案是小细胞癌晚期,建议转院。


当我姐哭着给我打电话告诉我这个消息时,我整个人都楞了几秒。


我跟姐姐说,你先别慌,我们再去其他医院看看,小医院技术不行,也许查错了呢!


你就跟我爸说,可能是上火引起的,CT上查出来有个黑点具体什么没看出来,建议我们去大医院看,那设备好一些,能看出来


接下来,我和姐姐去约各大医院的专家号,某军区总院、某四院、某二院、某市中医院、某省总医院、某肿瘤医院等等。


最后,以上所有医院的结果,给出的答案都是小细胞癌晚期


据我同学给介绍的医生说,我爸这样的情况,最多可能半年或1年,即使是化疗也意义不大,当我和姐姐知道这个消息的时候,一时我也接受不了这个消息,看到姐姐伤心痛哭的样子,我心里也难受极了.....


我强忍着跟姐姐说,咱们再看看,肯定可以治疗。


爸爸得知自己肺癌


对我们而言,怕爸爸知道自己肺癌,会因为舍不得钱而轻生的想法,不配合治疗,所以刚开始在没完全确诊之前,就一直瞒着他。


后来,随着去的医院越来越多,爸爸也逐渐开始起了疑心!


直到我们去某四院,做完肺活检,等结果。并告诉爸爸一周后才能出来(那时候我都佩服我自己撒谎的本事!),其实结果早就出了,只是 我和姐姐不死心,想拿着结果去其他医院再看看,总觉得是医院给看错了。


爸爸也是一直在关注着检查的结果,每天都会问结果到底什么时候能出来!


本来和妈妈、姐姐一直打算瞒着爸爸,让他开心的过完后面的时间。


当然,肯定这肯定是瞒不住的,只是能瞒着一天算一天。


后来,经商量后决定,还是跟爸爸说,觉得他也有知道的权利,而且我们相信爸爸可以接受,并且会积极配合治疗。


当爸爸知道自己得了肺癌后,刚开始那几天,每天都在那发呆,一句话也不说。


于是,我们就决定每天家里必须有个人在家,怕爸爸有轻生的想法,但怕他待在家比较闷,我们决定就带爸爸去旅游。


当然这期间,我们一直没有放弃,又通过关系找到某肿瘤医院主任医生,抱着试试看的态度就去了,听他说完,我们觉得还算靠谱,于是,我们决定就在这家医院治疗了。


随着时间的流逝,爸爸也开始慢慢接受了自己肺癌的事实,而且也选择积极配合治疗,最后也去了医院,这真的让我很开心。


千万不要去化疗


刚开始化疗的时候,我们都是早上7点多就到医院,晚上挂完点滴,到晚上9点-10点才能到家,第一次化疗大约5天左右。


和每个化疗患者一样,刚开始,爸爸也是开始掉头发、厌食。


爸爸最爱吃猪蹄,我每天都会买猪蹄,都后来干脆都不吃,说是没胃口,再到后面脸上也逐渐出现一些症状,有点发黑。


那一刻,我真的感觉化疗就和慢性自杀一样,看着一天天日渐消瘦的爸爸,我的心里真的很不是滋味。


就这样顺利的完成第一阶段,22天后,我们又开始进行了第二次化疗。


化疗的第一天开始,爸爸就开始感觉不舒服,说心脏不得劲,后来医生说有个药不给用了,再看看。


然后,到了第二天,爸爸又开始血压不稳定、心慌,开始不怎么吃饭了,也不怎么说话了,把我吓坏了,脸色也不好。


我一也没睡,就这样守着看到了第三天,抢矿更不好,爸爸开始吐,恶心。


后来和医生说我们要强制出院,不打了,化疗的反应真的太大了,医生也同意我们出院了。


回家后,过了两天稍微好些,第三天,爸爸开始高烧不退、拉肚子不止,脸色苍白,后来我就带爸爸去急诊,输液后好了一些,到急诊那医生,听医生说爸爸是化疗后引起的,没有血小板和白细胞了,建议我们回原医院好些。


然后,我们又去商量主治医师,跟她说了下我爸爸现在的状况,只想恢复正常,表示先不化疗了,并询问能再次接收我们住院治疗,医生最后同意了。


住院后,开始做各种检查,住院当天下午稍微稳定了一些,然后连续两天又开始连续高烧、血压不稳,查完指标说还是是血小板太低,白细胞是0,几乎没有免疫力,需要补


这时,通过食补根本来不及,主要因为爸爸基本不怎么吃东西了,而且高烧起来,抽起来吓人,筷子都咬折了,真太吓人了,我当时真的希望我要是能替爸爸受这个罪该多好,当时真的强忍着眼泪,心里老难受了 !


最后,在我们的一再坚持下,请到了某二院的专家来帮忙会诊,老专家先让爸爸做了几项检查,并给换了药输液,大约也就一周左右,爸爸就好了,出院前,也去查了CT,发现肺部的肿瘤竟然没了!


医生说建议,过一阵再来接着化疗,后面再放疗会更好。其实我们也明白,因为小细胞癌的扩散速度很快,所以建议多观察治疗。


但是我们都坚持不会再去化疗了!


求医之路


爸爸出院回家后,开始进行食补,大约一周后,爸爸能正常走了,而且起色也好了许多。


我们开始四处求医,开启寻医之路,也是去了好多地方吧!


这期间遇到的,有一些老中医有个习惯,说是凡是化疗过的都不给看, 这让我表示很苦恼而且不理解。


再后来,爸爸的一位病友给推荐了一个老中医,我们还是照常打个电话过去,说明了情况,查看是否能治疗,结果开心的是能治疗。


刚开始,我们也是不相信的,抱着试试看的态度,我们去看了下,医生给开了半个月的药,结果爸爸喝中药俩礼拜后,就感觉明显走路有劲了,比以前强很多。


直到现在还在喝中药,之前化疗的副作用慢慢都好了,比如厌食、牙齿松动,吃甜的东西牙疼,头发也长出来了,而且每天还和之前一样,早晚去散步,连之前楼下的老太太,都说完全看不出来像生病一样,真的是好开心,也算是好事多磨吧,也可以说是遇到贵人了。


我失业了


2022年开始年底就开始裁员,公司也是组织架构调整,人员变动也比较频繁。


我当时也是负责性能测试、自动化测试这两块,并行着三个项目,也是真的加班加点的干。


因为爸爸生病,跑医院检查,我总请假,赶上公司组织架构调整。检查、陪护一个人根本忙不过来,妈妈年龄大了不太方便,所以我辞职了,当然也失业了,"成功"地走进2023失业大军中。


好处就是,我终于可以全身心的去忙家里的事了。


找工作


出院后的一个月,爸爸这边病情算是稳定了,我便开始了积极找工作。


因为好久没找工作了,首先,我用了大约5天的时间去搞简历,搞完简历便开始找工作。


通过找工作才发现,真TM卷呀,都是统招本科起步,更过分的是有的公司还要求必须是计算机专业!


我一看我自己,大专自考本科,完全没竞争力,BOSS上、智联、脉脉上、拉钩、内推,基本都是被学历卡掉了!


而且,那会特别焦虑,除了这行还能干嘛,我还会做啥,离了这行,是不是完了?


那会女友找到了工作,而且收入也不错,我待业,顶着巨大压力,我还是继续努力的寻找的工作。


还好感谢上天眷顾图片,还有几个面试,让我有的选择,最终我选择了一家成功上岸工作了。


分享两个面试题:


StringBuilderStringBuffer的区别?(我只用过他们拼接字符,结果凉了)


你性能测试中最大的QPS是多少?(这题我跟面试官,开始了杠精模式,我真没法回答)


我失恋了


每次写到这块,就感觉我像个怨妇一样呢,哈哈,真的不爱写。


我和女友是相亲认识的,3月相识直到今年10月长假彻底分手,分手是在吃完定亲饭开始黄的,听起来是不是很奇怪。


那会我已经上班一周,也是临近十一的一周,爸爸那会身体恢复的已经很好了,开始正常上班了。


因为在这之前她总跟我说,我们结婚把之类的话,我刚开始没往心里去,但是也就在那周,我接了话拆,并也耐心的跟他说了个初步沟通,寻问过彩礼和三金等等,当时,我看她也很开心的。


然后,回家我就跟家长说了这事,我爸说,那也行我这边身体现在也恢复的挺好,那就吃个定亲饭,把你俩的事定下来。


之后,爸爸给介绍人打了电话给介绍人,介绍人询问她家什么时候有时间,然后他妈妈给了个时间,当天晚上下班,女孩就跟我生气说,没正式通知她(也许差个求婚仪式吗?我可能直男了吧),完事我俩吵了一架。


然后呢,她告诉他妈说不行,然后又跟他妈妈吵架了,那意思说没告诉她 怎么就定了呢!


后来,我妥协了,我说那这样吧,时间你来定什么时候都行,不行怎么就先处着,你感觉行再订婚,你别有压力呢。


结果,也不到怎么她妈妈又给介绍人打电话定了个时间,完事又不行,来回会改了三次,我爸妈当时也说,要是人家不愿意就算了,再等等吧。


完事我还是跟女孩说,等你们定好,提前一天告诉我就行,你先和家长商量好就行的。


就因为吃定亲饭时间,他们家来回变定不下来,搞的我父母心情很复杂,但也是为了自己的儿子幸福,就等等了。 好在最后,定下来最后的时间了。


在吃定亲饭那天,给了定金,我感觉啥也没谈,介绍人问了女孩家有没有陪嫁,男方这边有房子,可以出装修等等,其他的我忘记了,当时他父母不吱声也不表态,我就感觉很奇怪吧。


当然,我作为晚辈在桌上没法发表意见。


于是,第二天,我们去自驾游回来的时候,我就说吃完定亲饭,介绍人问你父母你家有没有陪嫁,你爸妈没表态,我爸爸得了肺癌手头可能也不宽裕,我寻思问下你家有没有陪嫁,可以出点家电或者装修?因为都我家的话,可能会负债。


女孩问我是我的意思,还是我爸妈的意思,我说昨晚我们到家都很晚了,我晚上到家父母都睡觉了,一早我俩5点多出门去旅游,基本没说上话,我俩就是商量下。


女孩没说话,直接下车,并说 我现在就去找我爸妈,我去问问(当时生气的哭了,或许我不该问?


之后,我回家和我爸妈说,我又把对象惹生气了,并说了事情的缘由,父母本着保全大局的原则,让我先去道歉。


我先去找女孩的妈妈,结果,到那后,他妈妈基本都不让我说话,大概那意思,就是她们不是卖女儿,娶媳妇还想让她们拿钱,能娶得起就娶,娶不起就不娶,要是有饥荒,女儿肯定不嫁。


我看这样,我就又去找女孩各种道歉努力,女孩最后说不处了,直接退定金,走介绍人流程


之后,我回家跟父母学了一下,父母还是为了我,为了他们儿子,直接去找到女孩的父母,带着我去赔礼道歉。


到了后,我虽然离的很远都能听到,他妈妈跟我说的那些话,又跟我妈妈说了几遍,好在他爸爸是明事理的人,说也会帮着劝劝,但是他爸爸说了不算,尴尬。


随后,妈妈和我又去找到女孩去赔礼道歉,妈妈说了很多话,大概意思是,给阿姨个面子,我们家小孩不太会说话,别忘心里去


那种乞求被原谅的感觉,我那一刻,眼泪唰就出来了,心里很不是滋味,完事我偷偷的快速擦掉眼泪。妈妈临出门时说,大概意思是,你俩好好聊聊,好好相处,我家小孩嘴笨,你多担待点!结果我说啥,她也不说话,我说,那你先忙。


那一刻的冷漠,让我感觉到这份感情真的太脆弱、卑微了。


接着到了第二天,我早上买完早点给他送去,从8点多一直说到11点多,她的态度依旧是那么坚决,说不想处了,我当时回家后,我就在那想,处了半年多,一点感情也没有吗?说分就分,真的就能放下?


虽然每次吵架她都说分手,我都去哄,去赔礼道歉,也习惯了,但是这次不一样,我感觉好像是真的无法挽回。


但是我真的觉得,我和女孩都相处了快7个月了,有啥不能谈呢,至于上升到家长层面吗?


回家后,我跟父母说了下,后来大家讨论后,得出的结论:


可能是因为得知我爸爸是肺癌,每个月都要喝中药治病,觉得可能会是个累赘,再一个就是为了给爸爸治病花了不少钱,可能我家没多少钱了,可能怕以后的日子不好过,受拖累!


接着又过了一天,介绍人把我叫去,聊了一下,问我还有多少钱,还有一些别的,然后,又说跟她妈妈约定了好了,具体啥我忘记了,和我聊完,又给女孩妈妈打了个电话。


又过了一个多小时,我接到女孩的电话,她没说话,说打错了,我寻思给了台阶我就下了,我说你在哪,等你到家,你告诉我我去找你吧。


当天晚上,我收到女孩微信,说让我一起去介绍人那再聊一下,他们聊了啥,我也不到,我被支开了,他们聊了很久吧,聊的啥我也不知道,完事我送她回家。


第二天,早上我去找他,我打算跟她好好聊一下,我知道她肯定是想和好,我就问了他几个问题:



  1. 我不能保证一直都有工作,或者说我以后可能会有待业期,或者赚的不多,或者说不能给你更好的物质生活,但是我肯定会努力赚钱,不会摆烂(大概意思),你愿意跟我结婚吗?(没想过,而且现在不想结婚,想两年后吧,或者明年?)

  2. 比如我上班要早起你上班比较晚,偶尔愿意帮我早起做个早饭吗?(不想起来)

  3. 以后相处模式,能跟我先沟通下,再到父母层面吗?(不说话)

  4. 我爸爸要喝中药,我不能不管我爸爸(她的意思是我把父母看的比她重)


其他我忘记了,总之基本不说话,虽然来抱我,表示和好,但是那一刻我发现,感觉真的变了!


然后跟我说,她会跟她妈妈说,我们和好了,但是不让我和我爸妈说,让我很吃惊!


难道我家长是因为好说话?就该不被重视?


“和好后”的两天,和之前一样,每天正常见面,都是我在找话题,她还是不说话,去她家,她基本不说话,在那工作,不说话,我就在那刷手机看视频。


然后又过去两天,我们出去散步,她还是不说话,甚至不牵我手。


想到带我去道歉的妈妈她的冷漠态度, 突然,我好像想明白了。


又过了一天,晚上下班到家,我提出了分手,删除了她的微信,彻底分手了


我知道,如果我在跟她谈结婚,还是会遇到这样的问题,而且她也说过,



不想结婚,想再玩两年!



而我真玩不起了,从始至终,每次吵架,我都去道歉挽留,因为害怕失去,感觉在感情里,我被养成了讨好型的人格。


跳出来看,换位思考,如果我是女孩家长,可能也会让她嫁的更好,或者未来会有更好的物质生活,感情里,没有谁对谁错,只有愿不愿意吧,所以真的就是和平分手了!


但无论怎样,我也不会动父母养老的钱,没钱我就不娶!


可能有同学会说了,那你是娶不起吧。


没错,要是结个婚,要贷款梭哈的话,还是算了吧。


你有没有想过把父母老本都拿来,完事还让他们去借钱,他们都那么大岁数了,没有劳动力了,怎么还?


值得一说的是,她家并不是家境不好,只能说和我家差不多吧,后面我了解到,真的不是他们家没钱,只是他姐姐陪嫁还有个房子,到我这就一个人,让我们自己白手起家?还是瞧不起我?亦或许就不想跟我结婚?


写在最后


刚失恋那一个月,真的我天天失眠睡不着,而且担心光棍一辈子,去求助很多朋友帮忙介绍对象。


而现在呢,失眠是因为搞不到钱。真的才发现搞钱,才是这个世界上最有意义的事了吧。


图片


作者:软件测试君
来源:juejin.cn/post/7300099522202009637
收起阅读 »

老黄深夜炸场,世界最强AI芯片H200震撼发布!性能飙升90%,Llama 2推理速度翻倍,大批超算中心来袭

【新智元导读】 刚刚,英伟达发布了目前世界最强的AI芯片H200,性能较H100提升了60%到90%,还能和H100兼容。算力荒下,大科技公司们又要开始疯狂囤货了。 英伟达的节奏,越来越可怕了。 就在刚刚,老黄又一次在深夜炸场——发布目前世界最强的AI芯片H2...
继续阅读 »
【新智元导读】 刚刚,英伟达发布了目前世界最强的AI芯片H200,性能较H100提升了60%到90%,还能和H100兼容。算力荒下,大科技公司们又要开始疯狂囤货了。

英伟达的节奏,越来越可怕了。


就在刚刚,老黄又一次在深夜炸场——发布目前世界最强的AI芯片H200!


较前任霸主H100,H200的性能直接提升了60%到90%。


不仅如此,这两款芯片还是互相兼容的。这意味着,使用H100训练/推理模型的企业,可以无缝更换成最新的H200。


图片


全世界的AI公司都陷入算力荒,英伟达的GPU已经千金难求。英伟达此前也表示,两年一发布的架构节奏将转变为一年一发布。


就在英伟达宣布这一消息之际,AI公司们正为寻找更多H100而焦头烂额。


英伟达的高端芯片价值连城,已经成为贷款的抵押品。


图片


谁拥有H100,是硅谷最引人注目的顶级八卦


至于H200系统,英伟达表示预计将于明年二季度上市。


同在明年,英伟达还会发布基于Blackwell架构的B100,并计划在2024年将H100的产量增加两倍,目标是生产200多万块H100。


而在发布会上,英伟达甚至全程没有提任何竞争对手,只是不断强调「英伟达的AI超级计算平台,能够更快地解决世界上一些最重要的挑战。」


随着生成式AI的大爆炸,需求只会更大,而且,这还没算上H200呢。赢麻了,老黄真的赢麻了!


图片


141GB超大显存,性能直接翻倍!


H200,将为全球领先的AI计算平台增添动力。


它基于Hopper架构,配备英伟达H200 Tensor Core GPU和先进的显存,因此可以为生成式AI和高性能计算工作负载处理海量数据。


英伟达H200是首款采用HBM3e的GPU,拥有高达141GB的显存。


图片


与A100相比,H200的容量几乎翻了一番,带宽也增加了2.4倍。与H100相比,H200的带宽则从3.35TB/s增加到了4.8TB/s。


英伟达大规模与高性能计算副总裁Ian Buck表示——



要利用生成式人工智能和高性能计算应用创造智能,必须使用大型、快速的GPU显存,来高速高效地处理海量数据。借助H200,业界领先的端到端人工智能超算平台的速度会变得更快,一些世界上最重要的挑战,都可以被解决。



图片


Llama 2推理速度提升近100%


跟前代架构相比,Hopper架构已经实现了前所未有的性能飞跃,而H100持续的升级,和TensorRT-LLM强大的开源库,都在不断提高性能标准。


H200的发布,让性能飞跃又升了一级,直接让Llama2 70B模型的推理速度比H100提高近一倍!


H200基于与H100相同的Hopper架构。这就意味着,除了新的显存功能外,H200还具有与H100相同的功能,例如Transformer Engine,它可以加速基于Transformer架构的LLM和其他深度学习模型。


图片


HGX H200采用英伟达NVLink和NVSwitch高速互连技术,8路HGX H200可提供超过32 Petaflops的FP8深度学习计算能力和1.1TB的超高显存带宽。


当用H200代替H100,与英伟达Grace CPU搭配使用时,就组成了性能更加强劲的GH200 Grace Hopper超级芯片——专为大型HPC和AI应用而设计的计算模块。


图片


下面我们就来具体看看,相较于H100,H200的性能提升到底体现在哪些地方。


首先,H200的性能提升最主要体现在大模型的推理性能表现上。


如上所说,在处理Llama 2等大语言模型时,H200的推理速度比H100提高了接近1倍。


图片


因为计算核心更新幅度不大,如果以训练175B大小的GPT-3为例,性能提升大概在10%左右。


图片


显存带宽对于高性能计算(HPC)应用程序至关重要,因为它可以实现更快的数据传输,减少复杂任务的处理瓶颈。


对于模拟、科学研究和人工智能等显存密集型HPC应用,H200更高的显存带宽可确保高效地访问和操作数据,与CPU相比,获得结果的时间最多可加快110倍。


相较于H100,H200在处理高性能计算的应用程序上也有20%以上的提升。


图片


而对于用户来说非常重要的推理能耗,H200相比H100直接腰斩。这样,H200能大幅降低用户的使用成本,继续让用户「买的越多,省的越多」!


图片


上个月,外媒SemiAnalysis曾曝出一份英伟达未来几年的硬件路线图,包括万众瞩目的H200、B100和「X100」GPU。


图片


而英伟达官方,也公布了官方的产品路线图,将使用同一构架设计三款芯片,在明年和后年会继续推出B100和X100。


图片


B100,性能已经望不到头了


这次,英伟达更是在官方公告中宣布了全新的H200和B100,将过去数据中心芯片两年一更新的速率直接翻倍。


以推理1750亿参数的GPT-3为例,今年刚发布的H100是前代A100性能的11倍,明年即将上市的H200相对于H100则有超过60%的提升,而再之后的B100,性能更是望不到头。


图片


至此,H100也成为了目前在位最短的「旗舰级」GPU。如果说H100现在就是科技行业的「黄金」,那么英伟达又成功制造了「铂金」和「钻石」。


图片


H200加持,新一代AI超算中心大批来袭


云服务方面,除了英伟达自己投资的CoreWeave、Lambda和Vultr之外,亚马逊云科技、谷歌云、微软Azure和甲骨文云基础设施,都将成为首批部署基于H200实例的供应商。


图片


此外,在新的H200加持之下,GH200超级芯片也将为全球各地的超级计算中心提供总计约200 Exaflops的AI算力,用以推动科学创新。


图片


在SC23大会上,多家顶级超算中心纷纷宣布,即将使用GH200系统构建自己的超级计算机。


德国尤里希超级计算中心将在超算JUPITER中使用GH200超级芯片。


这台超级计算机将成为欧洲第一台超大规模超级计算机,是欧洲高性能计算联合项目(EuroHPC Joint Undertaking)的一部分。


图片


Jupiter超级计算机基于Eviden的BullSequana XH3000,采用全液冷架构。


它总共拥有24000个英伟达GH200 Grace Hopper超级芯片,通过Quantum-2 Infiniband互联。


每个Grace CPU包含288个Neoverse内核, Jupiter的CPU就有近700万个ARM核心。


它能提供93 Exaflops的低精度AI算力和1 Exaflop的高精度(FP64)算力。这台超级计算机预计将于2024年安装完毕。


图片


由筑波大学和东京大学共同成立的日本先进高性能计算联合中心,将在下一代超级计算机中采用英伟达GH200 Grace Hopper超级芯片构建。


作为世界最大超算中心之一的德克萨斯高级计算中心,也将采用英伟达的GH200构建超级计算机Vista。


图片


伊利诺伊大学香槟分校的美国国家超级计算应用中心,将利用英伟达GH200超级芯片来构建他们的超算DeltaAI,把AI计算能力提高两倍。


此外,布里斯托大学将在英国政府的资助下,负责建造英国最强大的超级计算机Isambard-AI——将配备5000多颗英伟达GH200超级芯片,提供21 Exaflops的AI计算能力。


图片


英伟达、AMD、英特尔:三巨头决战AI芯片


GPU竞赛,也进入了白热化。


图片


面对H200,而老对手AMD的计划是,利用即将推出的大杀器——Instinct MI300X来提升显存性能。


MI300X将配备192GB的HBM3和5.2TB/s的显存带宽,这将使其在容量和带宽上远超H200。


而英特尔也摩拳擦掌,计划提升Gaudi AI芯片的HBM容量,并表示明年推出的第三代Gaudi AI芯片将从上一代的 96GB HBM2e增加到144GB。


图片


英特尔Max系列目前的HBM2容量最高为128GB,英特尔计划在未来几代产品中,还要增加Max系列芯片的容量。


H200价格未知


所以,H200卖多少钱?英伟达暂时还未公布。要知道,一块H100的售价,在25000美元到40000美元之间。训练AI模型,至少需要数千块。此前,AI社区曾广为流传这张图片《我们需要多少个GPU》。


图片


GPT-4大约是在10000-25000块A100上训练的;Meta需要大约21000块A100;Stability AI用了大概5000块A100;Falcon-40B的训练,用了384块A100。


根据马斯克的说法,GPT-5可能需要30000-50000块H100。摩根士丹利的说法是25000个GPU。


Sam Altman否认了在训练GPT-5,但却提过「OpenAI的GPU严重短缺,使用我们产品的人越少越好」。


图片


我们能知道的是,等到明年第二季度H200上市,届时必将引发新的风暴。


参考资料:nvidianews.nvidia.com/news/nvidia…


作者:新智元
来源:juejin.cn/post/7300860696685363219
收起阅读 »

iOS 判断系统版本

iOS
方案一 double systemVersion = [UIDevice currentDevice].systemVersion.boolValue; if (systemVersion >= 7.0) { // >= iOS 7.0 ...
继续阅读 »

方案一


double systemVersion = [UIDevice currentDevice].systemVersion.boolValue;

if (systemVersion >= 7.0) {
// >= iOS 7.0
} else {
// < iOS 7.0
}

if (systemVersion >= 10.0) {
// >= iOS 10.0
} else {
// < iOS 10.0
}

如果只是大致判断是哪个系统版本,上面的方法是可行的,如果具体到某个版本,如 10.0.1,那就会有偏差。我们知道 systemVersion 依旧是10.0。


方案二


NSString *systemVersion = [UIDevice currentDevice].systemVersion;
NSComparisonResult comparisonResult = [systemVersion compare:@"10.0.1" options:NSNumericSearch];

if (comparisonResult == NSOrderedAscending) {
// < iOS 10.0.1
} else if (comparisonResult == NSOrderedSame) {
// = iOS 10.0.1
} else if (comparisonResult == NSOrderedDescending) {
// > iOS 10.0.1
}

// 或者

if (comparisonResult != NSOrderedAscending) {
// >= iOS 10.0.1
} else {
// < iOS 10.0.1
}

有篇博客提到这种方法不靠谱。比如系统版本是 10.1.1,而我们提供的版本是 8.2,会返回NSOrderedAscending,即认为 10.1.1 < 8.2 。


其实,用这样的比较方式 NSComparisonResult comparisonResult = [systemVersion compare:@"10.0.1"],的确会出现这种情况,因为默认是每个字符逐个比较,即 1(0.1.1) < 8(.2),结果可想而知。但我是用 NSNumericSearch 方式比较的,即数值的比较,不是字符比较,也不需要转化成NSValue(NSNumber) 再去比较。


方案三


if (NSFoundationVersionNumber >= NSFoundationVersionNumber_iOS_7_0) {
// >= iOS 7.0
} else {
// < iOS 7.0
}

// 或者

if (kCFCoreFoundationVersionNumber >= kCFCoreFoundationVersionNumber_iOS_7_0) {
// >= iOS 7.0
} else {
// < iOS 7.0
}

这些宏定义是 Apple 预先定义好的,如下:


#if TARGET_OS_IPHONE
...
#define NSFoundationVersionNumber_iOS_9_4 1280.25
#define NSFoundationVersionNumber_iOS_9_x_Max 1299
#endif


细心的童靴可能已经发现问题了。Apple 没有提供 iOS 10 以后的宏?,我们要判断iOS10.0以后的版本该怎么做呢?
有篇博客中提到,iOS10.0以后版本号提供了,并且逐次降低了,并提供了依据。


#if TARGET_OS_MAC
#define NSFoundationVersionNumber10_1_1 425.00
#define NSFoundationVersionNumber10_1_2 425.00
#define NSFoundationVersionNumber10_1_3 425.00
#define NSFoundationVersionNumber10_1_4 425.00
...
#endif


我想这位童鞋可能没仔细看, 这两组宏是分别针对iPhone和macOS的,不能混为一谈的。


所以也只能像下面的方式来大致判断iOS 10.0, 但之前的iOS版本是可以准确判断的。


if (NSFoundationVersionNumber > floor(NSFoundationVersionNumber_iOS_9_x_Max)) {
// > iOS 10.0
} else {
// <= iOS 10.0
}

方案四


在iOS8.0中,Apple也提供了NSProcessInfo 这个类来检测版本问题。


@property (readonly) NSOperatingSystemVersion operatingSystemVersion NS_AVAILABLE(10_10, 8_0);
- (BOOL) isOperatingSystemAtLeastVersion:(NSOperatingSystemVersion)version NS_AVAILABLE(10_10, 8_0);

所以这样检测:


if ([[NSProcessInfo processInfo] isOperatingSystemAtLeastVersion:(NSOperatingSystemVersion){.majorVersion = 8, .minorVersion = 3, .patchVersion = 0}]) {
// >= iOS 8.3
} else {
// < iOS 8.3
}

用来判断iOS 10.0以上的各个版本也是没有问题的,唯一的缺点就是不能准确版本是哪个版本,当然这种情况很少。如果是这种情况,可以通过字符串的比较判断。


方案五


通过判断某种特定的类有没有被定义,或者类能不能响应哪个特定版本才有的方法。
比如,UIAlertController 是在iOS 8.0才被引进来的一个类,我们这个依据来判断版本


if (NSClassFromString(@"UIAlertController")) {
// >= iOS 8.0
} else {
// < iOS 8.0
}

说到这里,就顺便提一下在编译期间如何进行版本控制,依然用UIAlertController 来说明。


NS_CLASS_AVAILABLE_IOS(8_0) @interface UIAlertController : UIViewController

NS_CLASS_AVAILABLE_IOS(8_0) 这个宏说明,UIAlertController 是在iOS8.0才被引进来的API,那如果我们在iOS7.0上使用,应用程序就会挂掉,那么如何在iOS8.0及以后的版本使用UIAlertController ,而在iOS8.0以前的版本中仍然使用UIAlertView 呢?


这里我们会介绍一下在#import <AvailabilityInternal.h> 中的两个宏定义:


*__IPHONE_OS_VERSION_MIN_REQUIRED


*__IPHONE_OS_VERSION_MAX_ALLOWED


从字面意思就可以直到,__IPHONE_OS_VERSION_MIN_REQUIRED 表示iPhone支持最低的版本系统,__IPHONE_OS_VERSION_MAX_ALLOWED 表示iPhone允许最高的系统版本。


__IPHONE_OS_VERSION_MAX_ALLOWED 的取值来自iOS SDK的版本,比如我现在使用的是Xcode Version 8.2.1(8C1002),SDK版本是iOS 10.2,怎么看Xcode里SDK的iOS版本呢?



进入PROJECT,选择Build Setting,在Architectures中的Base SDK中可以查看当前的iOS SDK版本。



打印这个宏,可以看到它一直输出100200。


__IPHONE_OS_VERSION_MIN_REQUIRED 的取值来自项目TARGETS的Deployment Target,即APP愿意支持的最低版本。如果我们修改它为8.2,打印这个宏,会发现输出80200,默认为10.2。


通常,__IPHONE_OS_VERSION_MAX_ALLOWED 可以代表当前的SDK的版本,用来判断当前版本是否开始支持或具有某些功能。而__IPHONE_OS_VERSION_MIN_REQUIRED 则是当前SDK支持的最低版本,用来判断当前版本是否仍然支持或具有某些功能。


回到UIAlertController 使用的问题,我们就可以使用这些宏,添加版本检测判断,从而使我们的代码更健壮。


 - (void)showAlertView {
#if defined(__IPHONE_OS_VERSION_MIN_REQUIRED) && __IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_9_0
UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"Title" message:@"message" delegate:nil cancelButtonTitle:@"Cancel" otherButtonTitles:@"OK", nil];
[alertView show];
#else
if (NSFoundationVersionNumber >= NSFoundationVersionNumber_iOS_8_0) {
UIAlertController *alertViewController = [UIAlertController alertControllerWithTitle:@"Title" message:@"message" preferredStyle:UIAlertControllerStyleAlert];

UIAlertAction *cancelAction = [UIAlertAction actionWithTitle:@"Cancel" style:UIAlertActionStyleCancel handler:nil];
UIAlertAction *otherAction = [UIAlertAction actionWithTitle:@"OK" style:UIAlertActionStyleDefault handler:nil];

[alertViewController addAction:cancelAction];
[alertViewController addAction:otherAction];

[self presentViewController:alertViewController animated:YES completion:NULL];
}
#endif
}

方案六


iOS 11.0 以后,Apple加入了新的API,以后我们就可以像在Swift中的那样,很方便的判断系统版本了。


if (@available(iOS 11.0, *)) {
// iOS 11.0 及以后的版本
} else {
// iOS 11.0 之前
}

参考链接



作者:蒙哥卡恩就是我
来源:juejin.cn/post/7277111344003399734
收起阅读 »

货拉拉用户 iOS 端灵动岛实践总结

iOS
1. 前言 实时活动是iOS 16.1及以上版本中新增的功能,它允许应用在锁屏界面显示实时数据,能够帮助用户实时查看当前订单的进展,而无需解锁手机。用户在货拉拉APP上下单后,可以将手机放置一旁,开始其他工作。当用户想要查询订单状态时,只需从锁定屏幕或灵动岛...
继续阅读 »

1. 前言


实时活动是iOS 16.1及以上版本中新增的功能,它允许应用在锁屏界面显示实时数据,能够帮助用户实时查看当前订单的进展,而无需解锁手机。用户在货拉拉APP上下单后,可以将手机放置一旁,开始其他工作。当用户想要查询订单状态时,只需从锁定屏幕或灵动岛上轻松操作即可。实时活动的出现不仅省去了用户解锁手机的步骤,更为用户节省了时间和精力。目前货拉拉APP适配“灵动岛”的最新6.7.68版本已正式上线,欢迎大家升级体验。在适配过程中,货拉拉App也踩过很多“坑”,在此汇总为实战经验分享给大家。


2. Live Activity&灵动岛的介绍


Live Activity的实现需要使用Apple的ActivityKit框架。通过使用ActivityKit,开发者可以轻松地创建一个Live Activity,这是一个动态的、实时更新的活动,可以在用户的设备上显示各种信息。此外,ActivityKit还提供了推送通知的功能,开发者可以通过服务器向用户的设备发送更新;这样,即使应用程序没有运行,用户也可以接收到最新的信息。


灵动岛是Live Activity的一种展示形式,灵动岛有三种展示形式:Compact紧凑、Minimal最小化,Expanded扩展。开发时必须实现这三种形式,以确保灵动岛在不同的场景下都能正常展示。



同时还需要实现锁屏下的实时活动UI,设备处于锁屏状态下,也能查看实时更新的内容。以上功能的实现,都是使用WidgetKit和SwiftUI完成开发。


2.1 技术难点及策略


实时活动,主要是APP在后台时,主动更新通知栏和灵动岛的数据,为用户展示最新实时订单状态。如何及时刷新实时活动的数据,是一个重点、难点。


更新方式有3种:



  1. 通过APP内订单状态的变化刷新实时活动和灵动岛。此方法开发量小,但是APP退到后台30s后或者进程杀掉,会停止数据的更新。

  2. 让APP配置支持后台运行模式,通过本地现有的订单状态变化逻辑,在后台发起网络请求,获取订单的数据后刷新实时活动。此方法开发量小,但求主App进程必须存在,进程一旦杀掉就无法更新。

  3. 通过接受远程推送通知来更新实时活动。此方法需要后端配合,此方式比较灵活,无需App进程存在,数据更新及时。也是业界常见的方案。


通过对数据刷新的三种方案进行评估后,选择了用户体验最佳的第三种方式。通过后端发生push,端上接受push数据来更新实时活动。


3. Live Activity&灵动岛的实践


3.1 实现方案流程图


实现流程图:


image.png


3.2 实现代码


创建Live Activities的准备:



  • Xcode需要14.1以上版本

  • 在主工程的 Info.plist 文件中添加一个键值对,key 为 NSSupportsLiveActivities,value 为 YES

  • 使用ActivityKit在Widget Extension 中创建一个Live Activity


需要实现锁屏状态下UI、灵动岛长按展开的UI、灵动岛单个UI、多个实时活动时的minimalUI


import SwiftUI
import WidgetKit

@main
struct TestWidget: Widget {
var body: some WidgetConfiguration {
ActivityConfiguration(for: TestAttributes.self) { context in
// 锁屏状态下的UI
} dynamicIsland: { context in
DynamicIsland {
//灵动岛展开后的UI
} compactLeading: {
// 未被展开左边UI
} compactTrailing: {
// 未被展开右边UI
} minimal: {
// 多任务时,右边的一个圆圈区域
}
.keylineTint(.cyan)
}
}
}

灵动岛主要分为StartUpdateEnd三种状态,可由ActivityKit远程推送控制其状态。


开启Live Activity


        let state = TestAttributes.ContentState()
let attri = TestAttributes(value: 100)
do {
let current = try Activity.request(attributes: attri, contentState: state, pushType: .token)
Task {
for await state in current.contentStateUpdates {
//监听state状态
}
}
Task {
for await state in current.activityStateUpdates {
//监听activity状态
}
}
} catch(let error) {
}

更新Live Activity


   Task {
guard let current = Activity<TestAttributes>.activities.first else {
return
}
let state = TestAttributes.ContentState(value: 88)
await current.update(using: state)
}

结束Live Activity


    Task {
for activity in Activity<TestAttributes>.activities {
await activity.end(dismissalPolicy: .immediate)
}
}

4. 使用ActivityKit推送通知


ActivityKit提供了接收推送令牌的功能,我们可以使用这个令牌来通过ActivityKit推送通知从我们的服务器向Apple Push Notification service (APNs)发送更新。


推送更新Live Activity的准备:




  • 在开发者后台配置生成p8证书,替换原来的p12证书




  • 通过pushTokenUpdates获取推送令牌PushToken




  • 向后端注册PushToken




代码展示:


//取得PushToken
for await tokenData in current.pushTokenUpdates {
let mytoken = tokenData.map { String(format: "x", $0) }.joined()
//向后端注册
registerActivityToken(mytoken)
}

4.1 模拟器push验证测试


环境要求:


Xcode >= 14.1 MacOS >= 13.0


准备工作:



  1. 通过pushTokenUpdates获取推送需要的token

  2. 根据开发者TeamID、p8证书本地路径、BuidleID等进行脚本配置


脚本示例:


export TEAM_ID=YOUR_TEAM_ID
export TOKEN_KEY_FILE_NAME=YOUR_AUTHKEY_FILE.p8
export AUTH_KEY_ID=YOUR_AUTHKEY_ID
export DEVICE_TOKEN=YOUR_PUSH_TOKEN
export APNS_HOST_NAME=api.sandbox.push.apple.com

export JWT_ISSUE_TIME=$(date +%s)
export JWT_HEADER=$(printf '{ "alg": "ES256", "kid": "%s" }' "${AUTH_KEY_ID}" | openssl base64 -e -A | tr -- '+/' '-_' | tr -d =)
export JWT_CLAIMS=$(printf '{ "iss": "%s", "iat": %d }' "${TEAM_ID}" "${JWT_ISSUE_TIME}" | openssl base64 -e -A | tr -- '+/' '-_' | tr -d =)
export JWT_HEADER_CLAIMS="${JWT_HEADER}.${JWT_CLAIMS}"
export JWT_SIGNED_HEADER_CLAIMS=$(printf "${JWT_HEADER_CLAIMS}" | openssl dgst -binary -sha256 -sign "${TOKEN_KEY_FILE_NAME}" | openssl base64 -e -A | tr -- '+/' '-_' | tr -d =)
export AUTHENTICATION_TOKEN="${JWT_HEADER}.${JWT_CLAIMS}.${JWT_SIGNED_HEADER_CLAIMS}"

curl -v \
--header "apns-topic:YOUR_BUNDLE_ID.push-type.liveactivity" \
--header "apns-push-type:liveactivity" \
--header "authorization: bearer $AUTHENTICATION_TOKEN" \
--data \
'{"Simulator Target Bundle": "YOUR_BUNDLE_ID",
"aps": {
"timestamp":1689648272,
"dismissal-date":0,
"event": "update",
"sound":"default",
"content-state": {
"title": "等待付款",
"content": "请尽快完成下单"
}
}}'
\
--http2 \
https://${APNS_HOST_NAME}/3/device/$DEVICE_TOKEN

其中:


apns-topic:固定为{BundleId}.push-type.liveactivity


apns-push-type:固定为liveactivity


Simulator Target Bundle:模拟器推送,设置为对应APP的BundleId


timestamp:表示推送通知的发送时间,如果timestamp字段的值与当前时间相差太大,可能会收不到推送。


event:可填入update、end,对应Live Activity的更新与结束。


dismissal-date:当event为end时有效,表示结束后从锁屏上移除Live Activity的时间。如果推送内容不包含"dismissal-date",默认结束后4小时后消失,但内容不会再发生更新。如果期望Live Activity结束后立即从锁屏上移除它,可为"dismissal-date"提供一个过去的日期。


content-state:对应灵动岛的Activity.ContentState;如果push中content-state的字段和Attributes比较:




  • 字段过多,多余的字段可能会被忽略,不会导致解析失败




  • 字段缺少,会在解析push通知时出现问题错误。错误表现为:实时活动会有蒙层,并展示loading菊花UI。




示范:


image.png


image.png


5. 踩坑记录




  • 在模拟器上无法获取到pushToken,无法进行推送模拟?


    检查电脑的系统版本号,需要13.0以上




  • 更新实时活动时,页面显示加载loadingUI,为什么?


    核对push字段和Activity.ContentState的字段是否完全一致,字段少了会解析失败




  • 在16.1系统上,无法展示实时活动,其他更高系统能展示?


    检查Widget里面iOS系统版本号的配置,设置为想要支持的最低版本




  • dismissal-date设置为10分钟后才消失,为什么Dynamic Island灵动岛立即消失了?


    Dynamic Island的显示逻辑可能会更加复杂,如果push的event=end,Dynamic Island灵动岛会立即消失。期望同时消失,可以在指定时间再发end,dismissal-date设置为过去时间,锁屏UI和Dynamic Island灵动岛会同时消失。




  • 推送不希望打扰用户,静默推送,不需要震动和主动弹出,如何设置?


    将"content-available"设置为1,"sound" 设置为: ""




"aps" = {
"content-available" : 1,
"sound" : ""
}



  • 用户系统是深色模式时,如何适配?


    可以使用@Environment(.colorScheme)属性包装器来获取当前设备的颜色模式。会返回一个ColorScheme枚举,它可以是.light.dark。在根据具体的场景进行UI适配




struct ContentView: View {
@Environment(.colorScheme) var colorScheme

var body: some View {
VStack {
if colorScheme == .dark {
Text("深夜模式")
.foregroundColor(.white)
.background(Color.black)
} else {
Text("日间模式")
.foregroundColor(.(.black)
.background(Color.white)
}
}
}
}

5.1 场景限制及建议



  1. 官方文档提示实时活动最多持续8小时,8小时后数据无法刷新,12小时后会强制消失。因此8小时后的数据不准确

  2. 实时活动的卡片上禁止定位以及网络请求,数据需要小于4KB,不能展示特别负责庞大的数据

  3. 同场景多卡片由于样式趋同且折叠,不建议同时创建多卡片。用户多次下单时,建议只处理第一个订单


6. 用户APP上线效果


用户端iOS APP灵动岛上线后的部分场景截图:







7. 总结


灵动岛功能自上线以来,经过我们的数据统计,用户实时活动使用率高达75%以上。这一数据的背后,是灵动岛强大的功能和优秀的用户体验。用户可以在锁屏页直接查看订单状态,无需繁琐的操作步骤,大大提升了用户体验。这种便捷性,使得灵动岛在用户中的接受度较高。


我们的方案不仅可以应用于当前的业务场景,后续还计划扩展到营销活动,定制化通知消息等多种业务场景。这种扩展性,使得灵动岛可以更好地满足不同用户的需求,丰富产品运营策略。


我们希望通过分享开发过程中遇到的问题和解决方案,可以帮助到更多的人。如果你有任何问题或者想法,欢迎在评论区留言。期待我们在技术的道路上再次相遇。


总的来说,灵动岛以其高效、便捷、灵活的特性,赢得了用户的广泛好评。我们将继续努力,为用户提供更优质的服务,为产品的发展注入更多的活力。


作者:货拉拉技术
来源:juejin.cn/post/7300779071390335030
收起阅读 »

iOS如何通过在线状态来监听其他设备登录的状态

前提条件1、完成 3.9.1 或以上版本 SDK 初始化2、了解环信即时通讯 IM API 的 使用限制。3、已联系商务开通在线状态订阅功能实现方法你可以通过调用 subscribe 方法订阅自己的在线状态,从而可以监听到其他设备在登录和离线时的回调,示例代码...
继续阅读 »

前提条件

1、完成 3.9.1 或以上版本 SDK 初始化
2、了解环信即时通讯 IM API 的 使用限制。
3、已联系商务开通在线状态订阅功能

实现方法

你可以通过调用 subscribe 方法订阅自己的在线状态,从而可以监听到其他设备在登录和离线时的回调,示例代码如下:

先在EMConversationsViewController.m文件上加代理

EMPresenceManagerDelegate
[[[EMClient sharedClient] presenceManager] addDelegate:self delegateQueue:nil];

别的设备在发送状态变化的时候代理方法会接收到响应

- (void) presenceStatusDidChanged:(NSArray<EMPresence*>*)presences
{

NSLog(@"presenceStatusDidChanged:%@",presences);
}


红框中的device是发布者的当前在线设备使用的平台,包括iOSAndroidLinuxwindowswebim

status 是当前在线状态,0为离线,1为在线。

通过上述的方式可以在监听到变化时可以让自己的设备做些业务。

相关文档:

收起阅读 »

【Java集合】想成为Java编程高手?先来了解一下List集合的特性和常用方法!

嗨~ 今天的你过得还好吗?生命如同寓言其价值不在于长短而在于内容通过前面文章的介绍,相信大家对Java集合框架有了简单的理解,接下来说说集合中最常使用的一个集合类的父类,List 集合。那么,List到底是什么?它有哪些特性?又该如何使用呢?让我们一...
继续阅读 »


嗨~ 今天的你过得还好吗?

生命如同寓言

其价值不在于长短

而在于内容


通过前面文章的介绍,相信大家对Java集合框架有了简单的理解,接下来说说集合中最常使用的一个集合类的父类,List 集合。那么,List到底是什么?它有哪些特性?又该如何使用呢?让我们一起来揭开List的神秘面纱。

List,顾名思义,就是列表的意思。在Java中,List是一个接口,它继承了Collection接口,表示一个有序的、可重复的元素集合。下面我们从List 接口的概念、特点和常用方法等方面来介绍List。


一、接口介绍


java.util.List 接口,继承自 Collection 接口(可以回看咱们第二篇中的框架体系),List 接口是单列集合的一个重要分支,习惯性地将实现了List 接口的对象称为List集合。


在list 集合中允许出现重复的元素,所有的元素对应一个整数型的序号记载其在容器中的位置进行存储,在程序中可以通过索引来访问集合中的指定元素。另外,List集合还是 有序的,即元素的存入和取出顺序一致。

List 接口的特点:

  • 它是一个元素存取有序的集合。例如,存元素的顺序是3,45,6。那么集合中,元素的存储就是按照3,45,6的顺序完成的)。

  • 它是一个带有索引的集合,通过索引就可以精确的操作集合中的元素(与数组的索引是一个道理)。

  • 可以有重复的元素,通过元素的equals方法,来比较是否为重复的元素。


List接口中常用方法:

List作为Collection集合的子接口,不但继承了Collection接口中的全部方法,而且还增加了一些根据元素索引来操作集合的特有方法,如下:

  • public void add(int index, E element):将指定的元素,添加到该集合中的指定位置上。

  • public E get(int index):返回集合中指定位置的元素。

  • public E remove(int index):移除列表中指定位置的元素, 返回的是被移除的元素。

  • public E set(int index, E element):用指定元素替换集合中指定位置的元素,返回值的更新前的元素。


通过代码来体验一下:


二、List集合子类

List接口有很多实现类,如ArrayListLinkedList等,它们各自有着不同的特点和应用场景。下面分别来介绍一下常用的ArrayList 集合和LinkedList集合。


ArrayList 集合

通过 javaApi 帮助文档 ,可以看到 List的实现类其实挺多,在此选择比较常见的 ArrayList 和 LinkedList 简单介绍。


ArrayList 有以下两个特点:

  • 底层的数据结构是一个数组;

  • 这个数组会自动扩容,看起来像一个长度可变的数组。

通过阅读源码的方式,简单分析下这两个特点的实现:



在实例化ArrayList时,调用了对象的无参构造器,在无参构造器中,首先看到变量 elementData 的定义就是一个数组类型,它存储的就是集合中的元素,其次在初始化对象时,把一个长度为0的Object[] 数组,赋值给了 elementData 。这就是刚刚所说的 ArrayList 底层是一个数组


下面再来看自动扩容这个特点又是怎么实现的。


在向集合中添加一个元素之前,会计算集合中数组的长度是否满足,可以通过代码追踪,通过一系列方法的调用,会使用 arrays 工具类的复制方法 (根据文档,介绍复制方法)创建一个新的长度的数组,将添加的元素保存进去,这就是说的数组可变,自动扩容


ArrayList的两个特点就介绍到这里了,大家有兴趣的可以去读读源码,挺有意思。


重点说明:

之前讲过,数组结构的特点是元素增删慢,查找快。由于java.util.ArrayList 集合数据存储的结构是数组结构,所以它的特点也是元素增删慢,但是查询快


由于日常开发中使用最多的功能为查询数据、遍历数据,所以ArrayList 也是最常使用的集合。

而因着这些特点呢,在日常开发中,有些开发人员就非常随意地使用ArrayList完成任何需求,这是不严谨,这种编码方式也是不提倡的。

LinkedList是一个双向链表,那么双向链表是什么样子的呢,我上篇文章说过的结构图:


LinkedList 集合

接着来看看下面这个实现类:java.util.LinkedList 集合数据存储的结构是链表结构。方便元素添加、删除的集合。

你还在苦恼找不到真正免费的编程学习平台吗?可以试试云端源想!课程视频、在线书籍、在线编程、实验场景模拟、一对一咨询……你想要的全部学习资源这里都有,重点是统统免费!点这里即可查看


inkedList 是由链表来说实现的,并且它实现了List接口的所有方法,还增加了一些自己特有的方法。


api 文档上提到 LinkedList 所有的操作都是按照双重链接列表来执行,那就说明 LinkedList 的底层数据结构的实现是 一个双向链表。


那么之前介绍过双向链表的特点,所以LinkedList的特点就是:元素添加,删除速度快,而查询速度慢。


常用方法

LinkedList 作为 List的实现类,List中的方法LinkedList都是可以使用,所以这些方法就不做详细介绍;而特别练习一下 linkedList 提供的特有方法,因为在实际开发中对一个集合元素的添加与删除也经常涉及到首尾操作。



下面看下演示代码:



三、总结


虽然List功能强大,但我们也不能滥用。在使用时,我们需要注意以下几点:

  • 尽量避免频繁的插入和删除操作,因为这会影响List的性能。在这种情况下,我们可以考虑使用LinkedList。

  • List的大小是有限的,当元素超过List的最大容量时,会抛出OutOfMemoryError异常。因此,我们需要合理地设置List的初始容量和最大容量。


总的来说,Java单列集合List是一个非常强大的工具,它可以帮助我们解决很多编程问题。只要我们能够正确地使用它,就能够在编程的世界中找到无尽的乐趣。



收起阅读 »

一文带你如何优雅地封装小程序蓝牙模块

web
一. 前言。 蓝牙功能在我们日常软件中的使用率还是蛮高的----譬如各类共享单车/电单车。正因此,我们开发中接触蓝牙功能也是日渐增长。对于很多从未开发过蓝牙功能的童鞋来说,当PM小姐姐扔过来一个蓝牙协议要你接入时,简直一头雾水(我是谁?我在哪?)。只能一翻度娘...
继续阅读 »

一. 前言。


蓝牙功能在我们日常软件中的使用率还是蛮高的----譬如各类共享单车/电单车。正因此,我们开发中接触蓝牙功能也是日渐增长。对于很多从未开发过蓝牙功能的童鞋来说,当PM小姐姐扔过来一个蓝牙协议要你接入时,简直一头雾水(我是谁?我在哪?)。只能一翻度娘和AI,可是网上文章大多水准参差不齐,技术五花八门,没法真正地让你从无到有掌握蓝牙功能/协议对接。


二. 说明。


本文就基于uni-app框架结合微信和支付宝小程序为例,来讲述蓝牙功能在各类型小程序中的整体开发流程和如何“优雅”高效的封装蓝牙功能模块。本文使用到的主要技术栈和环境有:



  • uni-app

  • JavaScript

  • AES加解密

  • 微信小程序

  • 支付宝小程序


三. 蓝牙流程图。


正所谓“知己知彼,百战不殆”,所以在讲述蓝牙模块如何在小程序中开发和封装之前,我们先要了解蓝牙功能模块是如何在小程序中“走向”的,各API是如何交互通讯的。为了让大家看得清楚,学的明白----这里简明扼要地梳理了一份蓝牙核心API流程图(去除了非必要的逻辑走向,只展示了实际开发中最重要的步骤和交互)。



  • uni-app: 蓝牙API

  • 微信小程序:蓝牙API

  • 支付宝小程序:蓝牙API

  • 核心API流程图(注:每家厂商的小程序API大同小异,uni-app的基本通用,具体明细详见各厂商开发文档):


小程序蓝牙流程.png


四. 蓝牙协议。


了解完开发所需的API后,就需要根据实际开发场景中所对接的硬件和其厂家提供的蓝牙对接协议来结合上述的API来编写代码了。每家厂商的蓝牙协议是不一样的,不过“万变不离其宗”。只要知道其中的规则,真正看懂一家,那换其他家的也是可以看懂的。本文以下述协议(蓝牙寻车+蓝牙开锁)为例解释下。


1. 寻车:



  • 协议内容:


image.png



  • 解读:


根据上述图文的描述,我们可以知道想要开启蓝牙锁,那么必须先通过寻车蓝牙指令(7B5B01610060 或 7B5B01610160)写入,然后根据蓝牙响应的信息功能体和错误码判断响应是否正确,如正确,那么就拿到此时的随机数,后根据协议规定对该随机数做相应的处理,最后将处理后得到的结果用于组装开锁的蓝牙写入指令。



  • 案例代码:


image.png
image.png


2. 开锁:



  • 协议内容:


image.png



  • 解读:


根据上述图文的描述,我们可以知道开锁的写入指令是需要自己组装的,组装规则为:7B5B(数据头) 1B(信息体长度) 62(信息功能) 00(秘钥索引)018106053735(补1位0的电话号码)4B大端的时间戳 寻车拿到的随机码补8位0后经AES加密组合得到的16B数据 00(校验码);所以开锁写入的数据就是这种(案例:7B5B1B6200018106053735XXXXXXXXXXXXXXXXXXXX)。响应的话,也是根据信息功能体和错误码来判断开锁失败(9201)还是成功(9200)。



  • 案例代码:


image.png


五.代码编写。


这里为了提高蓝牙模块的代码耦合度,我们会把业务层和蓝牙模块层分离出来----也就是会把蓝牙整体流程交互封装成一个蓝牙模块js,然后根据业务形态,在各个业务层面上通过传参的形式来区分每个组件的蓝牙功能。


1. 业务层:



  • 核心代码:


//引入封装好的蓝牙功能JS模块核心方法函数
import { operateBluetoothYws } from '@/utils/bluetoothYws.js';

//调用蓝牙功能
blueTooth() {
//初始化蓝牙模块,所有的蓝牙API都需要在此步成功后才能调用
uni.openBluetoothAdapter({
success(res) {
console.log('初始化蓝牙成功res', res);
let mac = 'FF8956DEDA29';
let key = 'oYQMt8LFavXZR6sB';
operateBluetoothYws('open', mac, key, flag => {
if (flag) {
console.log('flag存在回调函数--蓝牙成功,可以执行后续步骤了', flag);
} else {
console.log('flag不存在回调函数--蓝牙成功,可以执行后续步骤了', flag);
}
})
},
fail(err) {
console.log('初始化蓝牙失败err', err);
}
})
},


  • 解读:


这里是我们具体业务层需要的写法,一开始就是引入我们封装好的蓝牙JS模块核心方法函数(operateBluetoothYws),然后启用uni.openBluetoothAdapter这个蓝牙功能启动前提,成功后在其success内执行operateBluetoothYws方法,此时的参数根据实际开发业务和相对应的蓝牙协议而定(这里以指令参数、设备编号和AES加密秘钥为例),实际中每个mac和key是数据库一一匹配的,我们按后端童鞋提供的接口获取即可(这里为了直观直接写死)。


2. 蓝牙模块层:



  • 核心代码:


let CryptoJS = require('./crypto-js.min.js'); //引入AES加密
let callBack = null; //回调函数,用于与业务层交互
let curOrder; //指令(开锁还是关锁后取锁的状态)
let curMac; //当前扫码的车辆编码对应的设备mac
let curKey; //当前扫码的车辆编码对应的秘钥secret(用于AES加密)
let curDeviceId; //当前扫码的车辆编码对应的设备的 id
let curServiceId; //蓝牙服务 uuid,需要使用 getBLEDeviceServices 获取
let curCharacteristicRead; //当前设备读的uuid值
let curCharacteristicWrite; //当前设备写的uuid值


//蓝牙调用核心方法(order: 指令;mac:车辆编码;key:秘钥secret;cb:回调)
function operateBluetoothYws(order,mac, key, cb) {
curOrder = order;
curMac = mac;
curKey = key;
callBack = cb
searchBluetooth();
}

//第一步(uni.startBluetoothDevicesDiscovery(OBJECT),开始搜寻附近的蓝牙外围设备。)
function searchBluetooth() {
uni.startBluetoothDevicesDiscovery({
services: ['00000001-0000-1000-8000-00805F9B34FB', '00000002-0000-1000-8000-00805F9B34FB'],
success(res) {
console.log('第一步蓝牙startBluetoothDevicesDiscovery搜索成功res', res)
watchBluetoothFound();
},
fail(err) {
console.log('第一步蓝牙startBluetoothDevicesDiscovery搜索失败err', err)
callBack && callBack(false)
}
})
}

//第二步(uni.onBluetoothDeviceFound(CALLBACK),监听寻找到新设备的事件。)
function watchBluetoothFound() {
uni.onBluetoothDeviceFound(function(res) {
curDeviceId = res.devices.filter(i => i.localName.includes(curMac))[0].deviceId;
stopSearchBluetooth()
connectBluetooth()
})
}

//第三步(uni.createBLEConnection(OBJECT),连接低功耗蓝牙设备。)
function connectBluetooth() {
if (curDeviceId.length > 0) {
// #ifdef MP-WEIXIN
uni.createBLEConnection({
deviceId: curDeviceId,
timeout: 5000,
success: (res) => {
console.log('第三步通过deviceId连接蓝牙设备成功res', res);
getBluetoothServers()
},
fail: (err) => {
console.log('第三步通过deviceId连接蓝牙设备失败err', err);
callBack && callBack(false)
}
});
// #endif
// #ifdef MP-ALIPAY
my.connectBLEDevice({
deviceId: curDeviceId,
timeout: 5000,
success: (res) => {
console.log('第三步通过deviceId连接蓝牙设备成功res', res);
getBluetoothServers()
},
fail: (err) => {
console.log('第三步通过deviceId连接蓝牙设备失败err', err);
callBack && callBack(false)
}
});
// #endif
}
}

//第四步(uni.stopBluetoothDevicesDiscovery(OBJECT),停止搜寻附近的蓝牙外围设备。)
function stopSearchBluetooth() {
uni.stopBluetoothDevicesDiscovery({
success: (res) => {
console.log('第四步停止搜寻附近的蓝牙外围设备成功res', res);
},
fail: (err) => {
console.log('第四步停止搜寻附近的蓝牙外围设备失败err', err);
}
})
}

//第五步(uni.getBLEDeviceServices(OBJECT),获取蓝牙设备所有服务(service)。)
function getBluetoothServers() {
uni.getBLEDeviceServices({
deviceId: curDeviceId,
success(res) {
console.log('第五步获取蓝牙设备所有服务成功res', res);
//这里取res.services中的哪个,这是硬件产商配置好的,不同产商不同,具体看对接协议
if (res.services && res.services.length > 1) {
curServiceId = res.services[1].uuid
getBluetoothCharacteristics()
}
},
fail(err) {
console.log('第五步获取蓝牙设备所有服务失败err', err);
callBack && callBack(false)
}
})
}

//第六步(uni.getBLEDeviceCharacteristics(OBJECT),获取蓝牙设备某个服务中所有特征值(characteristic)。)
function getBluetoothCharacteristics() {
// #ifdef MP-WEIXIN
uni.getBLEDeviceCharacteristics({
deviceId: curDeviceId,
serviceId: curServiceId,
success: (res) => {
console.log('第六步获取蓝牙设备某个服务中所有特征值成功res', res);
curCharacteristicWrite = res.characteristics.filter(item => item && item.uuid.includes('0002'))[
0].uuid
curCharacteristicRead = res.characteristics.filter(item => item && item.uuid.includes('0003'))[
0].uuid
notifyBluetoothCharacteristicValueChange()
},
fail: (err) => {
console.log('第六步获取蓝牙设备某个服务中所有特征值失败err', err);
callBack && callBack(false)
}
});
// #endif
// #ifdef MP-ALIPAY
my.getBLEDeviceCharacteristics({
deviceId: curDeviceId,
serviceId: curServiceId,
success: (res) => {
console.log('第六步获取蓝牙设备某个服务中所有特征值成功res', res);
curCharacteristicWrite = res.characteristics.filter(item => item && item.characteristicId.includes('0002'))[
0].characteristicId
curCharacteristicRead = res.characteristics.filter(item => item && item.characteristicId.includes('0003'))[
0].characteristicId
notifyBluetoothCharacteristicValueChange()
},
fail: (err) => {
console.log('第六步获取蓝牙设备某个服务中所有特征值失败err', err);
callBack && callBack(false)
}
});
// #endif
}

//第七步(uni.notifyBLECharacteristicValueChange(OBJECT),启用低功耗蓝牙设备特征值变化时的 notify 功能,订阅特征值。)
function notifyBluetoothCharacteristicValueChange() {
uni.notifyBLECharacteristicValueChange({
deviceId: curDeviceId,
serviceId: curServiceId,
characteristicId: curCharacteristicRead,
state: true,
success(res) {
console.log('第七步启用低功耗蓝牙设备特征值变化时的 notify 功能,订阅特征值成功res', res);
if(curOrder == 'open'){
//寻车指令
getRandomCode();
}else if(curOrder == 'close'){
//查看锁状态指令
getLockStatus();
}else{

}
//第八步(监听)(uni.onBLECharacteristicValueChange(CALLBACK),监听低功耗蓝牙设备的特征值变化事件。),含下发指令后的上行回应接受
//这里会一直监听设备上行,所以日志等需清除
uni.onBLECharacteristicValueChange((characteristic) => {
// #ifdef MP-WEIXIN
//完整的蓝牙回应数据
let ciphertext = ab2hex(characteristic.value);
//蓝牙回应数据的信息功能体和错误码
let curFeature = ab2hex(characteristic.value).slice(6, 10);
//蓝牙回应数据的错误码
let errCode = ab2hex(characteristic.value).slice(8, 10);
// #endif

// #ifdef MP-ALIPAY
//完整的蓝牙回应数据
let ciphertext = characteristic.value;
//蓝牙回应数据的信息功能体和错误码
let curFeature = characteristic.value.slice(6, 10);
//蓝牙回应数据的错误码
let errCode = characteristic.value.slice(8, 10);
// #endif
if (curFeature.startsWith('91')) { //寻车响应,拿到随机码
//用于给开锁的随机码
getUnlockData(ciphertext)
} else if (curFeature.startsWith('9200')) { //开锁响应(成功)
callBack && callBack(true)
} else if (curFeature.startsWith('98')) { //关锁后APP主动读取后的响应,查看是否已关锁
if (curFeature == '9801') { //关锁成功
callBack && callBack(true)
} else { //关锁失败
callBack && callBack(false)
}
} else {

}
})
},
fail(err) {
console.log('第七步启用低功耗蓝牙设备特征值变化时的 notify 功能,订阅特征值失败err', err);
callBack && callBack(false)
}
})
}

// ArrayBuffer转16进度字符串示例
function ab2hex(buffer) {
const hexArr = Array.prototype.map.call(
new Uint8Array(buffer),
function (bit) {
return ('00' + bit.toString(16)).slice(-2)
}
)
return hexArr.join('')
}

//寻车指令,用于拿到开锁所需的随机码
function getRandomCode() {
let str = '7B5B01610060';
writeBLE(str)
}

//开锁指令,获取到开锁所需的数据
function getUnlockData(ciphertext) {
if (ciphertext.length > 16) { //确保寻车后蓝牙响应内容有用于开锁的随机码
//开锁头(固定值)
let headData = '7B5B1B6200';
//用户手机号
let userPhone = '018106053735';
//4B大端秒级时间戳
let timestamp = convertLettersToUpperCase(decimalToHex(getSecondsTimestamp()));
//随机码 + 8个‘0’
let randomVal = convertToLower(ciphertext.slice(16, 24)) + '00000000';
//AES加密后的前32位密文
let aesResult = aesEncrypt(randomVal,curKey).slice(0,32)
//校验码
let checkCode = '00';
//最后用于发指令的内容
let result = headData + userPhone + timestamp + aesResult + checkCode;
writeBLE(result)
} else {
getRandomCode();
}
}

//查看锁状态指令,用于验证用户手工关锁后查询是否真的已关锁
function getLockStatus() {
let str = '7B5B006868';
writeBLE(str)
}

//AES的ECB方式加密,以hex格式(转大写)输出;参数一:明文数据,参数二:秘钥
function aesEncrypt(encryptString, key) {
let aeskey = CryptoJS.enc.Utf8.parse(key);
let aesData = CryptoJS.enc.Utf8.parse(encryptString);
let encrypted = CryptoJS.AES.encrypt(aesData, aeskey, {
mode: CryptoJS.mode.ECB,
padding: CryptoJS.pad.Pkcs7
});
//将base64格式转为hex格式并转换成大写
let password = encrypted.ciphertext.toString().toUpperCase()
return password;
}

//处理写入数据
function writeBLE(str) {
//如果大于20个字节则分包发送
if (str.length > 20) {
let curArr = splitString(str,20);
// #ifdef MP-WEIXIN
curArr.map(i => writeBLECharacter(hexStringToArrayBuffer(i)))
// #endif

// #ifdef MP-ALIPAY
curArr.map(i => writeBLECharacter(i))
// #endif
} else {
// #ifdef MP-WEIXIN
writeBLECharacter(hexStringToArrayBuffer(str));
// #endif

// #ifdef MP-ALIPAY
writeBLECharacter(str);
// #endif
}
}

//第八步(写入)(uni.writeBLECharacteristicValue(OBJECT),向低功耗蓝牙设备特征值中写入二进制数据。)
function writeBLECharacter(bufferValue){
uni.writeBLECharacteristicValue({
deviceId: curDeviceId,
serviceId: curServiceId,
characteristicId: curCharacteristicWrite,
value: bufferValue,
success(res) {
console.log('第八步(写入)向低功耗蓝牙设备特征值中写入二进制数据成功res', res);
},
fail(err) {
console.log('第八步(写入)向低功耗蓝牙设备特征值中写入二进制数据失败err', err);
callBack && callBack(false)
}
})
}

//将字符串以每length位分割为数组
function splitString(str, length) {
var result = [];
var index = 0;
while (index < str.length) {
result.push(str.substring(index, index + length));
index += length;
}
return result;
}

//字符转ArrayBuffer
function hexStringToArrayBuffer(str) {
// 将16进制转化为ArrayBuffer
return new Uint8Array(str.match(/[\da-f]{2}/gi).map(function(h) {
return parseInt(h, 16)
})).buffer
}

//对字符串中的英文大写转小写
function convertToLower(str) {
var result = '';
for (var i = 0; i < str.length; i++) {
if (/[a-zA-Z]/.test(str[i])) {
result += str[i].toLowerCase();
} else {
result += str[i];
}
}
return result;
}

//对字符串中的英文小写转大写
function convertLettersToUpperCase(str) {
var result = str.toUpperCase(); // 将字符串中的字母转换为大写
return result;
}

//获取秒级时间戳(十进制)
function getSecondsTimestamp() {
var timestamp = Math.floor(Date.now() / 1000); // 获取当前时间戳(单位为秒)
return timestamp;
}

//将十进制时间戳转成十六进制
function decimalToHex(timestamp) {
var hex = timestamp.toString(16); // 将十进制时间戳转换为十六进制字符串
return hex;
}


//抛出蓝牙核心方法
module.exports = {
operateBluetoothYws
};


  • 解读:


这里的步骤和上面流程图中的步骤走向是一样的,不过里面的详情,笔者还是想每一步都拆开来对着实际案例讲述为好,详见下文(这里主要是为了照顾小白,大佬勿怪)。


六. 蓝牙模块层各步骤详解。



  1. 蓝牙功能调用核心方法的定义和导出(operateBluetoothYws)


operateBluetoothYws 这里没啥好特别的,就是将业务层传进来的参数做个中转处理,为后续步骤的api所调用,详见上文代码及其注释。



  1. 第一步(uni.startBluetoothDevicesDiscovery(OBJECT))


uni.startBluetoothDevicesDiscovery 这里主要注意的是services这个参数,这个参数会由硬件厂家提供,一般在其提供的蓝牙协议文档中会标注,作用是要搜索的蓝牙设备主 service 的 uuid 列表。某些蓝牙设备会广播自己的主 service 的 uuid。如果设置此参数,则只搜索广播包有对应 uuid 的主服务的蓝牙设备。建议主要通过该参数过滤掉周边不需要处理的其他蓝牙设备。


image.png



  1. 第二步(uni.onBluetoothDeviceFound(CALLBACK))


uni.onBluetoothDeviceFound 这一步用来确定目标设备id,即后续步骤所需的参数deviceId。 这里主要注意的是其回调函数的devices结果,我们要根据厂家或其提供的蓝牙对接协议规定和我们业务层传进来的mac来匹配筛选目标设备(因为这里会监听到第一步同样的uuid的每一台设备)(这里我就一台设备测试,所以回调函数的devices结果数组中内容就一个;然后之所以用localName.includes(curMac) 来匹配目标设备,这是根据厂商协议文档来做的,每家厂商和每种设备不一样,这里要按实际情况处理,不过万变不离其宗)。


image.png



  1. 第三步(uni.createBLEConnection(OBJECT))


uni.createBLEConnection 这里没啥特别的,主要就是用到第二步中得到的deviceId去连接低功耗蓝牙目标设备。需要注意的是这里支付宝小程序的API不一致,为my.connectBLEDevice


image.png



  1. 第四步(uni.stopBluetoothDevicesDiscovery(OBJECT))


uni.stopBluetoothDevicesDiscovery 这一步主要是为了节省电量和资源,在第三步连接目标设备成功后给停止搜寻附近的蓝牙外围设备。


image.png



  1. 第五步(uni.getBLEDeviceServices(OBJECT))


uni.getBLEDeviceServices 这里通过第二步中得到的deviceId用来获取蓝牙目标设备的所有服务并确定后续步骤所需用的蓝牙服务uuid(serviceId)。这里取res.services中的哪个,这是硬件厂商定好的,不同厂商不同,具体看对接协议(案例中的是固定放在第2个,所以是通过curServiceId = res.services[1].uuid得到)。


image.png



  1. 第六步(uni.getBLEDeviceCharacteristics(OBJECT))


uni.getBLEDeviceCharacteristics 这里通过第二步获取的目标设备IddeviceId和第五步获取的蓝牙服务IdserviceId来得到目标设备的写的uuid读的uuid。这里取characteristics的哪一个也是要根据厂商和其提供的蓝牙协议文档来决定的(案例以笔者这的协议文档为主,所以是这样获取的:curCharacteristicWrite = res.characteristics.filter(item => item && item.uuid.includes('0002'))[0].uuid 和 curCharacteristicRead = res.characteristics.filter(item => item && item.uuid.includes('0003'))[0].uuid)。需要注意的是这里支付宝小程序的API不一致,为my.getBLEDeviceCharacteristics,其res返回值也不一样,curCharacteristicWrite = res.characteristics.filter(item => item && item.characteristicId.includes('0002'))[0].characteristicId 和 curCharacteristicRead = res.characteristics.filter(item => item && item.characteristicId.includes('0003'))[0].characteristicId。


image.png



  1. 第七步(uni.notifyBLECharacteristicValueChange(OBJECT))


uni.notifyBLECharacteristicValueChange 这里就是开启低功耗蓝牙设备特征值变化时的 notify 功能,订阅特征值。可以在其的success内执行一些写入操作执行uni.onBLECharacteristicValueChange(CALLBACK)来监听低功耗蓝牙设备的特征值变化事件了。


image.png



  1. 第八步(写入)(uni.writeBLECharacteristicValue(OBJECT))


uni.writeBLECharacteristicValue 这里特别要注意的是参数value必须为二进制值(这里需用注意的是支付宝小程序的参数value可以不为二进制值,可直接传入,详见支付宝小程序开发文档);并且单次写入不得超过20字节,超过了需分段写入


image.png


image.png



  1. 第八步(监听)(uni.onBLECharacteristicValueChange(CALLBACK))


uni.onBLECharacteristicValueChange 这里需根据实际开发的业务场景对CALLBACK 返回参数转16进度字符串后自行处理(支付宝小程序如果写入时未转换,那么这里读取时也不需要转换)(本文以寻车--开锁--检测锁状态为例)。


image.png


七. 总结。


以上就是本文的所有内容,主要分为2部分----业务层蓝牙模块层(封装)。业务层只需要关注目标设备和其对应的密钥(不同厂家和设备不同);蓝牙模块层主要是按蓝牙各API拿到以下四要素并按流程图一步步执行即可。



  1. 蓝牙设备Id:deviceId

  2. 蓝牙服务uuid:serviceId

  3. 蓝牙写操作的uuid

  4. 蓝牙读操作的uuid


至此,如何在小程序中优雅地封装蓝牙模块并高效使用就已经完结了,当然本文只是以最简而易学的案例来讲述蓝牙模块开发,大多只处理了success的后续,至于fail后续可以根据大家实际业务处理。相信看到这,你已经对小程序开发蓝牙功能,对接各种蓝牙协议已经有一定的认识了,再也不虚PM小姐姐的蓝牙需求了。完结撒花~ 码文不易,还请各位大佬三连鼓励(如发现错别之处,还请联系笔者修正)。


作者:三月暖阳
来源:juejin.cn/post/7300929241948422179
收起阅读 »

流量思维的觉醒,互联网原来是这么玩的

流量就是钱,这是一个很原始的认知。但最开始我并不清楚流量和钱之间是如何相互转化的。 微创业,认知很低 大学时期,不管是出于积累项目经验、还是折腾新技术的需要,我有做过一个相对完整的项目。 没记错的话,应该是在20年10月份启动的。当时在宿舍里买了一台激光打印机...
继续阅读 »

流量就是钱,这是一个很原始的认知。但最开始我并不清楚流量和钱之间是如何相互转化的。


微创业,认知很低


大学时期,不管是出于积累项目经验、还是折腾新技术的需要,我有做过一个相对完整的项目。


没记错的话,应该是在20年10月份启动的。当时在宿舍里买了一台激光打印机,做起了点小买卖。所以就发现如果我手动给同学处理订单会非常麻烦。他们把文件通过qq发给我,我这边打开,排版,确认格式没有问题之后算一个价格,然后打印。


所以根据痛点,我打算开发一个线上自助下单,商户自动打印的一整套系统。


百折不挠,项目终于上线


21年年中克服各种困难终于实现整套系统,提供了小程序端,商户客户端,web端。


用户在手机或网页上上传文件后会自动转换为pdf,还提供了在线预览,避免因为格式与用户本地不同的纠纷。可以自由调节单双面、打印范围、打印分数、色彩等参数。实时算出价格,自助下单。下单后服务器会通知商户客户端拉取新任务,拉取成功后将文件丢入打印队列中。打印完成后商户客户端发送信息,并由服务器转发,告知用户取件。


image.png


image.png


大三下学期,宿舍里通过线上平台,在期末考试最忙那段期间经过了“订单高峰”的考验,成交金额上千块钱。看着我商户端里面一个个跳动的文件,就像流入口袋里的💰,开心。


商业化的很失败


没想到,我自己就是我最大的客户。


期末考完,其实想拉上我的同学大干一场,让校里校外的所有的商户,都用上我们的软件,多好的东西啊。对于盈利模式的概念非常模糊,同时也有很强的竞品。我的同学并不看好我。


我对商业化的理解也源自美团模式,美团是外卖的流量入口,所以对商户抽佣很高。滴滴是打车的流量入口,对司机的抽佣也很高。所以我认为,假设我未来成为了自助打印的流量入口,那应该也可以试试抽佣模式。


而且就算我不能为商户引流,也能解放他们的双手。


当时的我,一个人做技术,做UI,还要做商业计划,去地推,真的搞得我精疲力尽。反正后面觉得短期内变现无望,就去腾讯实习了。


其实也推广了2个商户,但是他们因为各种原因不愿意用。一个是出于隐私合规风险的考虑,一个是订单量少,不需要。


所以基本这个自助打印只能框死在高校。大学生打印的文件私密性很低,但是单价低,量多,有自助打印的需求。还有一部分自助打印的场景是在行政办事大厅,这种估计没点门门道道是开不进去的。


看不懂的竞品玩法


商户通过我的平台走,我这边并不无本万利。


因为开通了微信支付、支付宝支付,做过的小伙伴应该都知道办这些手续也会花一些钱,公司还要每年花钱养。还有需要给用户的文档成转换成pdf,提供在线预览,这很消耗算力和带宽,如果用户的成交单价非常低,哪怕抽佣5%都是亏的。比如用户打印了100份1页的内容,和打印了1份100页的内容,对我来说成本差别很大,前者很低,后者很高。


当时学校里已经有一部分商户用上自助打印了。一共有3个竞品。


竞品A:不抽佣,但是每笔订单对用户收取固定的服务费,界面简陋,有广告。


竞品B:不抽佣,不收用户的服务费,界面清爽无广告。


竞品C:彻彻底底走无人模式,店铺内基本没有老板,店铺是自营或加盟的。


前期缺乏市场调研,后期缺乏商业认知


当时我在没有摸清自己商业模式,市场调研也没怎么做好的情况下。一心想的就是先把东西做出来再说,卖不成自己还能学到技术。毕竟技术这个玩意不在项目里历练,永远都是纸上谈兵。所以对于商业化的设想就是搞不成就不搞了。


我当时的想法就是要“轻”运营,就是最好我的利润是稳定的,不会亏损的。商户如果要用就得每笔订单都给我一笔钱。


后面为了补齐和竞品的功能差距,也耗费了大量心力。让我把项目从一个大学课程设计,变成了一个有商业化潜力的产品。


竞品玩法的底层逻辑


商业化的时候,就发现这个市场还是蛮卷的,不可能直接和商户收钱。竞品B不仅免费,还想着帮商户创造额外收入,做“增益”。那我确实是没有精力去对抗的。


我当时也没搞懂自己的定位,我究竟是tob还是toc。当时想着我精心设计的界面,怎么可以被广告侵蚀?那可是我的心血。所以一心想把产品体验做的比竞品好,就会有人用。但这个定位也很模糊,因为如果商户不用你的,用户怎么可能用你的下单呢。


其实应该to rmb。面向利润开发。美,是奢侈品,那是属于我内心的一种追求,但他很难具有说服力让商户使用。在国内的各种互联网产品,不盈利的产品最后都是越来越粗糙,越来越丑的,都要降本增效。而rmb是必需品,如果不能为各方创造价值,那就没有竞争力。


所以后续分析了一下各家的玩法:


竞品A:传统商业模式,依靠用户强制付费和广告,市占率一般,和第一差了10倍数量级。


竞品B:烧钱模式,免费给商户用,免费给用户用,自己想办法别的渠道做增益,还要补贴商户。市占率第一。先圈地,再养鱼,变现的事之后再说。


竞品C:不单单做打印软件,卖的是项目。一整套自助打印店的解决方案,不知道店铺能不能赚钱,但是可以先赚加盟商的钱。这个对商业运作的要求会很高,我一时半会做不了。


大佬指点了一下我


他说,你看现在什么自助贩卖机,其实就是一个流量入口。至于别的盈利不盈利再说,但是流量是值钱的。


我最近去查阿拉丁指数,了解到了买量和卖量的观念,重新认识了流量,因为知道价格了。


买量和卖量是什么?


买量说的就是你做了一个app,花钱让别人给你引流。


卖量就是你有一个日活很高的平台,可以为别人引流。


买量和卖量如何结算?


一般分为cpc和cpa两种计价方式。前者是只要用户点击了我的引流广告,广告主就得掏钱。后者是用户可能还需要注册并激活账号,完成一系列操作才掏钱。


一般价格在0.1-0.3元,每次引流。


后面我查了一下竞品B在卖量,每天可以提供10-30w的uv,单次引流报价0.1元。也就是理想情况下,每天可以有1-3w的广告费收入。


侧面说明了竞品B的市占率啊,在这个细分市场做到这个DAU……


关于流量,逆向思维的建立


流量是实现商业利益的工具。


工具类应用通过为别人引流将流量变现,内容类应用通过电商将流量变现的更贵。


依靠流量赚钱有两种姿势,主动迎合需求,和培养需求。前者就是你可以做一些大家必须要用的东西,来获得流量。比如自助打印小程序,只要商户接入了,那么他的所有顾客都会为这个小程序贡献流量。比如地铁乘车码,所有坐地铁的人都会用到,比如广州地铁就在卖量,每天有几百万的日活。


培养需求就是做自己看好的东西,但是当下不明朗,尝试发掘用户潜在的需求。


流量,如果不能利用好,那就是无效流量。所以正确的姿势是,发掘目标人群 -> 设计变现方案 -> 针对性的开发他们喜欢的内容或工具 -> 完成变现。而不是 自己发现有个东西不错 -> 开发出来 -> 测试一下市场反应 -> 期盼突然爆红,躺着收钱。


研究报告也蛮有意思,主打的就是一个研究如何将用户口袋里的钱转移到自己口袋里。做什么产品和个人喜好无关,和有没有市场前景相关。


互联网是基于实体的


互联网并不和实体脱钩,大部分平台依赖广告收入,但广告基本都是实体企业来掏钱。还有电商也是,消费不好,企业赚不到钱,就不愿意投更多推广费。


作者:程序员Alvin
来源:juejin.cn/post/7248118049583906872
收起阅读 »

真正的成长没有速成剂,都是风吹雨打过来的

一个人真正的成长一定是极其不容易的,如果想通过一两本书,一两个鸡汤文案,一两场培训就能够获得成长,那简直是痴人说梦,真正的成长一定不会是轻松的,一定是经过一次又一次的跌倒,然后爬起,对所做过的事,所经历的事进行一次又一次的复盘,总结,思考,最终才能慢慢认识到事...
继续阅读 »

一个人真正的成长一定是极其不容易的,如果想通过一两本书,一两个鸡汤文案,一两场培训就能够获得成长,那简直是痴人说梦,真正的成长一定不会是轻松的,一定是经过一次又一次的跌倒,然后爬起,对所做过的事,所经历的事进行一次又一次的复盘,总结,思考,最终才能慢慢认识到事物的本质,成长不是时间的堆积,也不会因为年龄递增而获得。


思考的难关


毫不夸张的说,思考是这个世界上最难的事,因为思考是要动脑的,而在现在这个信息爆炸的时代,我们想要任何资讯,任何知识,都可以找到现成的答案,所以懒惰就此滋生出来,“都有现成的答案了,我干嘛还要去动脑,我动脑得到的东西也未必有现成的好,而且动脑肚子还消耗能量,这种消耗不亚于体力劳动”,所以思考是最难的,而思考也是获取知识最快的途径。


我们在读书的时候,有些同学看似十分努力,一天感觉都是泡在书本里面的,但是成绩往往都不理想,初高中时,班上有些同学十分努力,对于我这种混子来说,我一定是扛不住的,就比如背英语单词,我发现有一些同学采用“原始人”的方式去背诵,因为我们整个初中换了三四个英语老师,而每个老师的教学方式不一样,其中一个老师就是教死记硬背,英语单词就比如“good”,她的方式是,“g o o d , g o o d”,也就是一个字母一个字母的背诵,后来因为一些原因,又换了老师,老师又教了音标,但是最后我还是发现,很多同学依旧还是“g o o d”,后来我才发现,因为学音标还需要花时间,还要动点脑子,对于一个单词,还有不同的情况,所以还是司机硬背好,这种方式就是“蛮力”,其实只要稍微花点时间去研究一下音标,然后再好好学学,背单词就会轻松很多,所以初高中英语成绩一直比较好,当然,现在很差,词汇量很少,完全是后面吃了懒惰的大亏。


所以,思考虽然是痛苦的,但是熬过痛苦期,就能够飞速成长,如果沉浸在自我感动的蛮力式努力中,那么只会离成长越来越远。


懒惰的魔咒


说到懒惰,我们可能会想到睡懒觉,不努力学习,不努力工作,但这其实并不是懒惰,每天起得很早去搬砖,日复一日地干着重复的事,却没有半点成长,这才是真正的懒惰。


没有思考的勤快是一文不值的,在现在这个社会,各种工具十分普遍,如果我们依旧保持原始人的工作方式,那么最终只会把自己累死,就像很多统计工作,如果认为自己加班到十二点,人工统计出数据来,老板就会很欣赏你,觉得你很吃苦耐劳,那么这是愚蠢的,因为有很多工具可能五分钟就能够搞出来,可偏偏固执去搞一些没用的东西,这有用吗,还有现在是人工智能时代,各种GPT工具那么爽,直接让效率翻倍,但是我就是不用,我就喜欢自己从头搞,那也没办法。


很多时候,所谓的勤快不过是为了掩饰自己的懒惰而已,懒惰得不愿意去接受新的事物,不愿意去学习新东西,总觉得“老一套“万能。


成长过程中,要不断打破自己的认知,冲破自己的心灵上的懒惰,拥抱新鲜事物,这样才不至于和主流脱节。


环境的影响



在南瓜里度日,就成圆形;在竹子里生活,就成长形。



一个人的环境同样是塑造成长的重要因素。环境不仅指物理环境,也包括人际环境和心理环境。在环境中,我们需要学会适应和改变环境,让环境成为我们成长的动力。


人以类聚,物以群分,如果我们身边的人都是不思上进,终日惶惶,那么长时间下来,我们也会受影响,读书时,如果身边的同学都好学,那么自己也绝对不会变得很烂,相反,如果同学都整天无所事事,那么自己自然也不会好到哪里去,当身边的人都是勤于思考,有想法,那么大家就会有一个良好的氛围,这样成长得就比较快,工作中,如果大家都很有热情,分享很多,学习很多,那么自己也不好意思,自然也会去学习。


但是我们每个人的能力都不一样,所以遇到的环境也不一样,所以很多时候,这并不是我们能选择的,所以说在自己没能力选择的时候,那么就要克制自己,别人混,自己不能混,要时刻提醒自己不能松懈,也不要因为别人的闲言碎语而去”同流合污“,始终记住,一切都是为了自己变得更好,不要太在意别人的看法。


保持良好的心态


在这个浮躁的社会,我们的思想和意志总是被这个社会所影响,特别现在短视频如此火爆,”脉脉上面低于百万年薪不好意思发言,抖音上面人均劳斯莱斯,自己同学朋友又买了几套房“,我们的心态时不时会受到打击,原本平稳的步伐一下变得不稳了,想一步升天了,但是当步子迈大了,可能就受伤了。


我们要时刻提醒自己自己是为自己而活,无论别人是真还是假,和自己关系不大,不要被外界过于影响,这个世界上没有一个人的成功是轻易的,都是在黑暗中努力发光的,如果相信了速成,相信快速致富,那么镰刀造已经嫁到脖子上了,而且还割坏了很多把,一茬接着一茬!


即使此刻多么的不堪,也不要放弃,积累自己,也许有一天,我们再相逢,睁开眼睛看,我才是英雄,他日若遂凌云志,敢笑黄巢不丈夫!



今天的分享就到这里,感谢你的观看,我们下期见!



作者:刘牌
来源:juejin.cn/post/7233052510554423333
收起阅读 »

【一点点税务知识】我的工资原来是这样少的

起因是这样的,我发现我的工资代扣个税,相较以前翻了三、四倍,工资也没给我涨呀,怎么交税还多了。怀疑给我算错了,于是我翻了翻资料找到一张税务总局的个人所得税税率表。 它是这样计算的: 1. 一年分成12个月,交纳税也分为12期 2. 本期应预扣预缴税额 = ...
继续阅读 »

起因是这样的,我发现我的工资代扣个税,相较以前翻了三、四倍,工资也没给我涨呀,怎么交税还多了。怀疑给我算错了,于是我翻了翻资料找到一张税务总局的个人所得税税率表



它是这样计算的:


1. 一年分成12个月,交纳税也分为12期

2.
本期应预扣预缴税额 = (累计预扣预缴应纳税所得额 * 税率 - 速算扣除数)- 累计已预扣预缴税额

3.
累计预扣预缴应纳税所得额 = 累计收入 - 累计免税收入 - 累计减除费用 - 累计专项扣除 - 累计专项附加扣除 - 累计依法确定的其他扣除

4.
其中,累计减除费用,按照5000元/月乘以纳税人当年截至本月在本单位的任职受雇月份数计算


举个例子,假设张三每月工资收入20000,各项社会保险金(五险一金)扣除为1000。


在八月份:



  • 张三累计减除费用是5000*8=40000

  • 累计专项扣除是1000*8=8000

  • 排除张三有免税收入等情况,他的累计预扣预缴应纳税所得额为20000*8-40000-8000=112000

  • 累计预扣预缴应纳税所得额112000对应税率表的2级数,所以第八期应预扣预缴税额为(112000*0.1-2520)-累计已预扣预缴税额

  • 累计已预扣预缴税额是前7个月的纳税总和。这样计算,20000*7-5000*7-1000*7=98000 对应税率表的2级数,前7期累计已预扣预缴税额为98000*0.1-2520 = 7280

  • 最后,张三在八月份,他要纳税为(112000*0.1-2520)-7280=1400


等等,文章还没完呢,不然又有人怼我纯水了。



我发现网络上像这类纳税计算器参差不齐,计算公式差得离谱,所以决定自己动手撸一个。



个税计算器


由于html、css、js代码内容长,所以我把这部分内容拼接成一张大图,也方便读源码。css布局大量使用Flex弹性布局,不了解的同学先学习一波《和我女神王冰冰一起学display: flex布局》



描述下js逻辑层:



  • 本月工资、社保(五险一金)、专项附加扣除都要乘以纳税期数,分别计算出各自的累计数

  • 本月工资、社保(五险一金)、专项附加扣除、累计减除费用累计数相减计算后,就是累计预扣预缴应纳税所得额(累计应缴税款)

  • 个人所得税税率表转化成taxRates数据结构,累计预扣预缴应纳税所得额作为参数调用getTaxRate方法返回税率、速算扣除数

  • 累计已预扣预缴税额(已缴税款)计算为纳税期数减1,然后以减后的纳税期数再重复一遍上述计算过程

  • 本期应预扣预缴税额(应交税额)= 累计预扣预缴应纳税*税率-速算扣除数-累计已预扣预缴税额(已缴税款)


布局兼容到了PC端、移动端,它们分别是这样的:



想要源码的同学,可以访问下面👇链接保存页面即可。


个税计算器在线链接:http://www.linglan01.cn/c/salary/


最后的话


文章中一类的个税计算器,一般计算出来的结果是有偏差的,原因如下:



  • 每月工资不是固定的,受KPI影响工资会有一定起浮

  • 奖金类的收入也要计算进去,如果有奖金没有计算进累计预扣预缴应纳税所得额,那计算的结果就是会偏差


所以说,个税计算器只能计算出大概的税。


想要准确的计算自己纳税情况,建议下载个人所得税APP。



当工资收入越高,应纳税所得额比重也会增大,比重在到一定程度后,我想我们应该要考虑如何合法避税。


每年年未都会有一次在个人所得税APP提交专项附加扣除,它能一定程度上补返回税额给我们。



另外,开通个人养老金帐户也可以进行一定额度的避税,将来养老滋不滋润重点看这个帐户。我收入还不足以供个人养老帐户,有条件、有需要的同学可以去了解一下。


如果我的文章对你有帮助,您的👍就是对我的最大支持^_^。


作者:凌览
来源:juejin.cn/post/7270395503821160506
收起阅读 »

浏览器的秘密

web
 浏览器架构 1 浏览器的历史 单进程与多进程浏览器 在2007年之前,市面上浏览器都是单进程的,所有功能模块都是运行在同一个进程里,这些模块包含了网络、插件、JavaScript运行环境、渲染引擎和页面等。 最新的Chrome浏览器包括:1个浏览器(B...
继续阅读 »

 

浏览器架构


1 浏览器的历史


单进程与多进程浏览器



在2007年之前,市面上浏览器都是单进程的,所有功能模块都是运行在同一个进程里,这些模块包含了网络、插件、JavaScript运行环境、渲染引擎和页面等。20210415092040.png




最新的Chrome浏览器包括:1个浏览器(Browser)主进程1个 GPU 进程1个网络(NetWork)进程多个渲染进程多个插件进程
20210415092356.png




  • 浏览器进程。主要负责界面显示、用户交互、子进程管理,同时提供存储等功能。

  • 渲染进程。核心任务是将 HTML、CSS 和 JavaScript 转换为用户可以与之交互的网页,排版引擎Blink和JavaScript引擎V8都是运行在该进程中,默认情况下,Chrome会为每个Tab标签创建一个渲染进程。出于安全考虑,渲染进程都是运行在沙箱模式下。

  • GPU进程。其实,Chrome刚开始发布的时候是没有GPU进程的。而GPU的使用初衷是为了实现3D CSS的效果,只是随后网页、Chrome的UI界面都选择采用GPU来绘制,这使得GPU成为浏览器普遍的需求。最后,Chrome在其多进程架构上也引入了GPU进程。

  • 网络进程。主要负责页面的网络资源加载,之前是作为一个模块运行在浏览器进程里面的,直至最近才独立出来,成为一个单独的进程。

  • 插件进程。主要是负责插件的运行,因插件易崩溃,所以需要通过插件进程来隔离,以保证插件进程崩溃不会对浏览器和页面造成影响


2 JavaScript的单线程模型



  • 因为JS是与用户互动,以及操作DOM。如果JavaScript是多线程的,会带来很多复杂的问题,假如 JavaScript有A和B两个线程,A线程在DOM节点上添加了内容,B线程删除了这个节点,应该是哪个为准呢? 所以,为了避免复杂性,所以设计成了单线程。

  • H5提供了多线程的方案:Web Worker, 他允许主线程创建worker线程,分配任务给worker进程处理,但是worker线程完全受到主线程控制,也不能操作DOM,没有改变JS的单线程本质。


3 Chrome 打开一个页面需要启动多少进程?分别有哪些进程?


打开 1 个页面至少需要 1 个网络进程、1 个浏览器进程、1 个 GPU 进程以及 1 个渲染进程,共 4 个;最新的 Chrome 浏览器包括:1 个浏览器(Browser)主进程、1 个 GPU 进程、1 个网络(NetWork)进程、多个渲染进程和多个插件进程。



  • 浏览器进程:主要负责界面显示、用户交互、子进程管理,同时提供存储等功能。

  • 渲染进程:核心任务是将 HTML、CSS 和 JavaScript 转换为用户可以与之交互的网页,排版引擎 Blink 和 JavaScript 引擎 V8 都是运行在该进程中,默认情况下,Chrome 会为每个 Tab 标签创建一个渲染进程。出于安全考虑,渲染进程都是运行在沙箱模式下。

  • GPU 进程:其实,Chrome 刚开始发布的时候是没有 GPU 进程的。而 GPU 的使用初衷是为了实现 3D CSS 的效果,只是随后网页、Chrome 的 UI 界面都选择采用 GPU 来绘制,这使得 GPU 成为浏览器普遍的需求。最后,Chrome 在其多进程架构上也引入了 GPU 进程。

  • 网络进程:主要负责页面的网络资源加载,之前是作为一个模块运行在浏览器进程里面的,直至最近才独立出来,成为一个单独的进程。

  • 插件进程:主要是负责插件的运行,因插件易崩溃,所以需要通过插件进程来隔离,以保证插件进程崩溃不会对浏览器和页面造成影响。


4 渲染机制


1. 浏览器如何渲染网页


概述:浏览器渲染一共有五步



  1. 处理 HTML 并构建 DOM 树。

  2. 处理 CSS构建 CSSOM 树。

  3. 将 DOM 与 CSSOM 合并成一个渲染树。

  4. 根据渲染树来布局,计算每个节点的位置。

  5. 调用 GPU 绘制,合成图层,显示在屏幕上



第四步和第五步是最耗时的部分,这两步合起来,就是我们通常所说的渲染



具体如下图过程如下图所示


img


img


渲染



  • 网页生成的时候,至少会渲染一次

  • 在用户访问的过程中,还会不断重新渲染



重新渲染需要重复之前的第四步(重新生成布局)+第五步(重新绘制)或者只有第五个步(重新绘制)




  • 在构建 CSSOM 树时,会阻塞渲染,直至 CSSOM树构建完成。并且构建 CSSOM 树是一个十分消耗性能的过程,所以应该尽量保证层级扁平,减少过度层叠,越是具体的 CSS 选择器,执行速度越慢

  • 当 HTML 解析到 script 标签时,会暂停构建 DOM,完成后才会从暂停的地方重新开始。也就是说,如果你想首屏渲染的越快,就越不应该在首屏就加载 JS 文件。并且CSS也会影响 JS 的执行,只有当解析完样式表才会执行 JS,所以也可以认为这种情况下,CSS 也会暂停构建 DOM


知识点1



  • 由于<script>标签是阻塞解析的,将脚本放在网页尾部会加速代码渲染。

  • deferasync属性也能有助于加载外部脚本。

  • defer使得脚本会在dom完整构建之后执行;

  • async标签使得脚本只有在完全available才执行,并且是以非阻塞的方式进行的


知识点2: 重绘(Repaint)和回流(Reflow)



重绘和回流是渲染步骤中的一小节,但是这两个步骤对于性能影响很大




  • 重绘是当节点需要更改外观而不会影响布局的,比如改变 color 就叫称为重绘

  • 回流是布局或者几何属性需要改变就称为回流。



回流必定会发生重绘,重绘不一定会引发回流。回流所需的成本比重绘高的多,改变深层次的节点很可能导致父节点的一系列回流



以下几个动作可能会导致性能问题



  • 改变 window 大小

  • 改变字体

  • 添加或删除样式

  • 文字改变

  • 定位或者浮动

  • 盒模型


很多人不知道的是,重绘和回流其实和 Event loop 有关



  • 当 Event loop 执行完Microtasks 后,会判断 document 是否需要更新。因为浏览器是 60Hz 的刷新率,每 16ms 才会更新一次。

  • 然后判断是否有 resize 或者 scroll ,有的话会去触发事件,所以 resize 和 scroll 事件也是至少 16ms才会触发一次,并且自带节流功能。

  • 判断是否触发了 media query

  • 更新动画并且发送事件

  • 判断是否有全屏操作事件

  • 执行 requestAnimationFrame 回调

  • 执行 IntersectionObserver 回调,该方法用于判断元素是否可见,可以用于懒加载上,但是兼容性不好

  • 更新界面

  • 以上就是一帧中可能会做的事情。如果在一帧中有空闲时间,就会去执行 requestIdleCallback 回调


常见的引起重绘的属性



  • color

  • border-style

  • visibility

  • background

  • text-decoration

  • background-image

  • background-position

  • background-repeat

  • outline-color

  • outline

  • outline-style

  • border-radius

  • outline-width

  • box-shadow

  • background-size


3.4 常见引起回流属性和方法



任何会改变元素几何信息(元素的位置和尺寸大小)的操作,都会触发重排,下面列一些栗子




  • 添加或者删除可见的DOM元素;

  • 元素尺寸改变——边距、填充、边框、宽度和高度

  • 内容变化,比如用户在input框中输入文字

  • 浏览器窗口尺寸改变——resize事件发生时

  • 计算 offsetWidth 和 offsetHeight 属性

  • 设置 style 属性的值


回流影响的范围



由于浏览器渲染界面是基于流失布局模型的,所以触发重排时会对周围DOM重新排列,影响的范围有两种




  • 全局范围:从根节点html开始对整个渲染树进行重新布局。

  • 局部范围:对渲染树的某部分或某一个渲染对象进行重新布局


全局范围回流


<body>
<div class="hello">
<h4>hello</h4>
<p><strong>Name:</strong>BDing</p>
<h5>male</h5>
<ol>
<li>coding</li>
<li>loving</li>
</ol>
</div>
</body>


p节点上发生reflow时,hellobody也会重新渲染,甚至h5ol都会收到影响



局部范围回流



用局部布局来解释这种现象:把一个dom的宽高之类的几何信息定死,然后在dom内部触发重排,就只会重新渲染该dom内部的元素,而不会影响到外界



3.5 减少重绘和回流



使用 translate 替代 top



<div class="test"></div>
<style>
.test {
position: absolute;
top: 10px;
width: 100px;
height: 100px;
background: red;
}
</style>
<script>
setTimeout(() => {
// 引起回流
document.querySelector('.test').style.top = '100px'
}, 1000)
</script>


@程序员poetry: 代码已经复制到剪贴板



  • 使用 visibility 替换 display: none ,因为前者只会引起重绘,后者会引发回流(改变了布局)

  • 把 DOM 离线后修改,比如:先把 DOM 给 display:none (有一次 Reflow),然后你修改100次,然后再把它显示出来

  • 不要把 DOM 结点的属性值放在一个循环里当成循环里的变量


for(let i = 0; i < 1000; i++) {
// 获取 offsetTop 会导致回流,因为需要去获取正确的值
console.log(document.querySelector('.test').style.offsetTop)
}


@程序员poetry: 代码已经复制到剪贴板



  • 不要使用 table 布局,可能很小的一个小改动会造成整个 table 的重新布局

  • 动画实现的速度的选择,动画速度越快,回流次数越多,也可以选择使用 requestAnimationFrame

  • CSS选择符从右往左匹配查找,避免 DOM深度过深

  • 将频繁运行的动画变为图层,图层能够阻止该节点回流影响别的元素。比如对于 video标签,浏览器会自动将该节点变为图层。


img


img


作者:vast11
来源:juejin.cn/post/7298893187065659430
收起阅读 »

谈谈SSO单点登录的设计实现

谈谈SSO单点登录的设计实现 本篇将会讲讲单点登录的具体实现。 实现思路 其实单点登录在我们生活中很常见,比如学校的网站,有很多个系统,迎新系统,教务系统,网课系统。我们往往只需要登录一次就能在各个系统中被认定为登录状态。 这是怎么实现的?我们需要一个认证中心...
继续阅读 »

谈谈SSO单点登录的设计实现


本篇将会讲讲单点登录的具体实现。


实现思路


其实单点登录在我们生活中很常见,比如学校的网站,有很多个系统,迎新系统,教务系统,网课系统。我们往往只需要登录一次就能在各个系统中被认定为登录状态。


这是怎么实现的?我们需要一个认证中心,一如学校网站也有一个统一认证中心,也就是我们的SSO的Server端。在每个系统也就是Client端,我们只要判断已经在这个认证中心中登录,那我们就会被设置为登录状态。


再来就是最后一个问题了,我们判断在认证中心登录后,怎么在其他系统中也登录?


这个问题其实就是单点登录中最麻烦的问题了,也就是如何传播我们的登录状态。


我们可以分为两个情况Cookie共享传播状态,url参数传播状态。


Cookie共享传播状态


第一种情况:我们的认证中心和其他系统是在一个域名下的,认证中心为父域名(jwxt.com),其他系统是子域名(yx.jwxt.com),或者是同一IP不同端口的情况,我们的服务端通过cookie去判断是否登录。


在这种情况下我们只要在认证中心登录成功的时候设置Cookie,当然设置Cookie的时候也要注意设置好你的Cookie参数。


要注意设置的参数是dominpath。这两个参数值决定了Cookie的作用域。domin要设置为父域名(.jwxt.com)。当然还要注意一个SameSite参数,不能设置为。(如果为,你在baidu.com登录,在example.com网站如果你点击了 baidu.com/delete 链接,会带着你在baidu.com的Cookie访问。)


设置完Cookie,子域名的系统也有了Cookie,自然就会被服务端判断为登录状态。


简而言之,就是利用Cookie共享来实现登录状态的传播。


url参数传播状态


第二种我们的认证中心和其他系统不在一个域名下的,或者是不同IP的情况。


为了安全浏览器限制cookie跨域,也就是说第一种方法就不管用了。


这种情况可以通过传播参数来实现,也就是在认证中心登录后带着 登录凭证(token) 重定向到对应的Client页面,然后我们的前端就可以用js获取到url中的token进行存储(设置到Cookie或者localstorage等方式),之后我们的服务端只需要通过这个token就可以判断为登录状态了。


当然,为了安全我们往往不会直接传递凭证,而是传递一个校验码ticket,然后前端发送ticket到服务端校验ticket,校验成功,就进行登录,设置Cookie或者存储token。


流程


接下来我们梳理一下流程,一下Client为需要单点登录的系统,Server为统一认证中心。


Cookie共享传播状态



  1. 用户在Client1,如果没有登录,跳转到Server,判断在Server是否登录,如果判断没有登录,要求登录,登录成功后设置Cookie,跳转Client

  2. Client1登录成功


如果之后在Client2页面,由于共享Cookie,当然也是登录状态。


url参数传播状态



  1. 用户在Client1,判断没有登录,跳转到Server,判断在Server是否登录,如果没有登录,要求登录,登录成功后设置Cookie,带着ticket跳转Client。

  2. 到了Client1,前端通过参数获取到ticket,发送到服务端,服务端校验ticket获取登录id,设置Cookie进行登录。


之后在Client2页面



  1. 用户在Client2,判断没有登录,跳转到Server,判断在Server是否登录,这时候判断为登录,带着ticket(或者token)跳转Client。

  2. 到了Client2,前端通过参数获取到ticket,发送到服务端,服务端校验ticket获取登录id,设置Cookie进行登录。


如果不使用ticket校验就直接存储传播过来的登录凭证即可,当然如果你不存储到Cookie,记得在请求后端服务的时候带上token。


ticket校验


再说说ticket校验


ticket校验根据情况也可以分为两种,一种情况是Server和Client的后端共用的同一个Redis或者Redis集群,可以直接向Redis请求校验。如果后端用的Redis不同,可以发送http请求到Server端在Server端校验。


到此,单点登录就完成了。


当然在以上描述中的Cookie你也可以不使用,使用Cookie主要是方便,在请求后端时会自动发送。你只需要存储到localstorage/sessionstorage等地方,请求后端的时候记得get然后带上即可。


作者:秋玻
来源:juejin.cn/post/7297782151046266890
收起阅读 »

前端基建有哪些?大小公司的偏重啥?🤨

web
前言 兄弟们可能有的感受 感受一:入职 初创公司 或者成立 新的团队 而只有你一个前端,不知道从何做起。 感受一:天天写业务代码,感觉没啥技术含量,没沉淀,成长太慢,架构那边挺有趣的。 感受二:天天写内部工具,觉得没啥提升,感觉要废。 感受三:对一些框架的...
继续阅读 »

前言




兄弟们可能有的感受



  • 感受一:入职 初创公司 或者成立 新的团队 而只有你一个前端,不知道从何做起。

  • 感受一:天天写业务代码,感觉没啥技术含量,没沉淀,成长太慢,架构那边挺有趣的。

  • 感受二:天天写内部工具,觉得没啥提升,感觉要废。

  • 感受三:对一些框架的原理、源码、工具 研究较少,无法突破评级,成为leader。


上面的感受都是一些兄弟们的典型感受(也包括我自己)。这时候不妨可以考虑一下,了解了解前端的基础建设,进而 搭建起一个坚实的底座和让自己得到一个提升




正文开始——关于“基建”




1.什么是基建?



  • “技术基建”,就是研发团队的技术基础设施建设,一个团队通用技术能力的沉淀。

  • 小到文档规范,脚手架工具,大到工程化、各个领域工具链,凡是能促进业务效率、沟通成本都可以称作基建。

  • 网上看到的一句话,说的很好, “业务支撑是活在当下,技术基建是活好未来”




2.基建的意义


主要是为了以下几点:



  • 业务复用,提高效率: 基建可以提高单个人的工作产出和工作效率,可以从代码层面解决一些普遍性和常用性的业务问题

  • 规范、优化流程制度: 优异的流程制度必将带来正面的、积极的、有实效的业务支撑。

  • 更好面对未来业务发展: ,像建房子一样,好的地基可以建出万丈高楼。

  • 影响力建设、开源建设:建设结果对于业务的促进,更容易获得内部合作方的认可;沉淀下来的好的经验,可以对外输出分享,也是对影响力的有力帮助。




基建搞什么




1.核心:


下手之前首先得记住总结出的核心概念:



  • 三个落地要素: 公司的团队规模、公司的业务、团队水平。

  • 四大基础特性: 技术的健全性、基建的稳定性、研发的效率性、业务的体验性


根据结合落地和基础特性,来搭建不同"重量"和"复杂度"的基建系统。(毕竟每个公司的情况都不同)




2.方向


基建开始之前,首先得确定建设的策略及步骤,主要是从 拆解研发流程 入手的:


一个基本的研发流程闭环一般是:需求导入 => 需求拆解 => 技术方案制定 => 本地编码 => 联调 => 自测优化 => 提测修复 Bug => 打包 => 部署 => 数据收集&分析复盘 => 迭代优化 。


在研发流程闭环中每一个环节的阻塞点越少,研发效率就越高。基建,就是从这些耽误研发时间的阻塞点入手,按照普遍性 + 高频的优先级标准,挨个突破。




3.搞什么


通用的公式是: 标准化 + 规范化 + 工具化 + 自动化 ,能力完备后可以进一步提升到平台化 + 产品化。在方向上,主要是从下面的 8 个主要方向进行归类和建设,供大家参考:



  • 开发规范:这一部分沉淀的是团队的标准化共识,标准化是团队有效协作的必备前提。

  • 研发流程: 标准化流程直接影响上下游的协作分工和效率,优秀的流程能带来更专业的协作。

  • 工程管理: 面向应用全生命周期的低成本管控,从应用的创建到本地环境配置到低代码搭建到打包部署。

  • 性能体验: 自动化工具化的方式发现页面性能瓶颈,提供优化建议。

  • 安全防控: 三方包依赖安全、代码合规性检查、安全风险检测等防控机制。

  • 统计监控: 埋点方案、数据采集、数据分析、线上异常监控等。

  • 质量保障: 自测 CheckList、单测、UI 自动化测试、链路自动化测试等。


如上是一般性前端基建的主要方向和分区,不论是 PC 端还是移动端,这些都是基础的建设点。业务阶段、团队能力的差异,体现在基建上,在于产出的完整性颗粒度深入度自动化的覆盖范围。




4.大小公司基建重点


小团队的现实问题:考虑到现实,毕竟大多数前端团队不像大厂那样有丰富的团队人员配置,大多数还是很小的团队,小团队在实施基建时就不可避免的遇到很现实的阻力:



  • 最大的阻力应该就是 受限于团队规模小 ,无法投入较多精力处理作用于直接业务以外的事情

  • 其次应该是团队内部 对于基建的必要性和积极性认识不够 (够用就行的思想)


大小公司基建重点:




  • 小公司: 针对一些小团队或者说偏初创期的团队,其建设,往往越偏向于基础的技术收益,如脚手架组件库打包部署工具等;优先级应该排好,推荐初创公司和小团队成立优先搭建好:规范文档、统一开发环境技术栈/方法/工具、项目模板、CI/CD流程 ,把基础的闭环优先搭建起来。




  • 大公司: 越是成熟的业务和成熟沉淀的团队,其建设会越偏向于获取更多的业务收益,如直接服务于业务的系统,技术提效的同时更能直接带来业务收益。搭建起一套坚实的项目底座,能够更好的支持上层建筑的发展,同时也能够提升团队的成长,打开在业界的知名度,获取更好的信任支持。大公司在基础建设上,会更加考虑数据一些监控以及数据的埋点分析和统计,更加的偏重于数据的安全防范,做到质量保证。对于这点,很多前端需要写许多的测试case,有些人感觉很折磨,哈哈哈哈哈哈。






基建怎么搞




下面,会针对一些大家都感兴趣的方向,结合我们团队过去部分的建设产出,为大家列举一些前端基建类的沉淀,以供参考。


1. 规范&文档


规范和文档是最应该先行的,规范意味着标准,是团队的共识,是沟通协作的基础。


文档:



  • 新人文档(公司、业务、团队、流程等)

  • 技术文档、

  • 业务文档、

  • 项目文档(旧的、新的)

  • 计划文档(月度、季度、年度)

  • 技术分享交流会文档


规范:



  • 项目目录规范:比如api,组件,页面,路由,hooks,store等



  • 代码书写规范:组件结构、接口(定义好参数类型和响应数据类型)、事件、工具约束代码规范、代码规范、git提交规范




2. 脚手架


开发和维护一个通用的脚手架工具,可以帮助团队快速初始化项目结构、配置构建工具、集成常用的开发依赖等。


省事的可能直接拥抱框架选型对应的全家桶,如 Vue 全家桶,或者用 Webpack 撸一个脚手架。能力多一些的会再为脚手架提供一些插件服务,如 Lint 或者 Mock。从简单的一个本地脚手架,到复杂的一个工程化套件系统。




3. 组件


公司项目多了会有很多公共的组件,可以抽离出来,方便自身和其他项目复用,一般可以分为以下几种组件:



  • UI组件:antd、element、vant、uview...

  • 业务组件:表单、表格、搜索...

  • 功能组件:上拉刷新,滚动到底部加载更多,虚拟滚动,拖拽排序,图片懒加载..




4. 工具 / 函数库


前端工具库,如 axios、loadsh、Day.js、moment.js、big.js 等等(太多太多,记不得了)


常见的 方法 / API封装:query参数解析、device设备解析、环境区分、localStorage封装、Day日期格式封装、Thousands千分位格式化、防抖、节流、数组去重、数组扁平化、排序、判断类型等常用的方法hooks抽离出来组成函数库,方便在各个项目中使用




5. 模板


可以提前根据公司的业务需求,封装出各个端对应通用开发模版,封装好项目目录结构,接口请求,状态管理,代码规范,git规范钩子,页面适配,权限,本地存储管理等等,来减少开发新项目时前期准备工作时间,也能更好的统一公司整体的代码规范。



  1. 通用后台管理系统基础模版封装

  2. 通用小程序基础模版封装

  3. 通用h5端基础模版封装

  4. 通用node端基础模版封装

  5. 其他类型的项目默认模版封装,减少重复工作。




6. API管理 / BFF


推荐直接使用axios封装或fetch,项目中基于次做二次封装,只关注和项目有关的逻辑,不关注请求的实现逻辑。在请求异常的时候不返回 Promise.reject() ,而是返回一个对象,只是code改为异常状态的 code,这样在页面中使用时,不用用 try/catch 包裹,只用 if 判断 code 是否正确就可以。再在规定的目录结构、固定的格式导出和导入。


BFF(Backends For Frontends)主要将后端复杂的微服务,聚合成对各种不同用户端(无线/Web/H5/第三方等)友好和统一的API;




7. CI/CD 构建部署


前端具备自己的构建部署系统,便于专业化方面更好的流程控制。很多公司目前,都实现了云打包、云检测和自动化部署,每次 git commit 代码后,都会自动的为你部署项目至 测试环境、预生产环境、生产环境,不用你每次手动的去打包后 cv 到多个服务器和环境。开发新的独立系统之初,也会希望能实现一种 Flow 的流式机制,以便实现代码的合规性静态检测能力。如果可以的话,可以去实现了一套插件化机制,可以按需配置不同的检测项,如某检测项检测不通过,最终会阻塞发布流程。




8. 数据埋点与分析


前端团队可以做的是 Web 数据埋点收集和数据分析、可视化相关的全系统建设。可实现埋点规范、埋点 SDK、数据收集及分析、PV/UV、链路分析、转化分析、用户画像、可视化热图、坑位粒度数据透出等数据化能力,下面给大家细分一些这些数据:



  • 行为数据:时间、地点、人物、交互、交互的内容;

  • 质量数据:浏览器加载情况、错误异常等;

  • 环境数据:浏览器相关的元数据以及地理、运营商等;

  • 运营数据:PV、UV、转化率、留存率(很直观的数据);




9.微前端


将您的大型前端应用拆分为多个小型前端应用,这样每个小型前端应用都有自己的仓库,可以专注于单一的某个功能;也可再聚合成有各个应用组成的一个平台,而各个应用使用的技术栈可以不同,也就是可以将不同技术栈的项目给整合到一块。这点就很不错,在如今电子办公化如此细致的时代,可能许多公司工作中都不止一个平台,平台之间的切换十分的繁琐,这时候平台之间聚合的趋势想来是必然的。(个人浅显的理解)


目前成熟一点的框架有蛮多的,使用的底层思想也各有不同,目前我也在学习qiankun等框架中,期待后面能够给大家分享一篇文章,加油💪




基建之外思考




1. 从当下业务场景出发开始


很多时候我们的建设推不下去,往往不是因为人力的问题,而是 没想清楚/没有方向 。对于研发同学,我们更应该着重于当下,从方案出发找实际场景的问题,也就是从我们项目和团队目前的业务问题、人员问题,一步步出发。还有就是,我们得开这个头。没有一个作家是看小说看成的,同理技术专家也不会是通过看技术书籍养成的。在实践中也就是实际场景中学习,从来都是最快的方式。许多有价值的事从来都是从业务本身的问题出发。到头来你会发现:问题就是机会,问题就是长萝卜的坑




2.基建讲究循序渐进


业界大部分的研发团队,都不是阿里、腾讯、头条这样基础完备沉淀丰富的情况,起步期和快速爬坡期居多,建设滞后。体现在基建上,可能往往只有一个基于 Webpack 搞搞的脚手架,和一个第三方开源的 UI 组件库上封装下自己的业务组件库,除此之外无他。如果兄弟们现在恰好是我说的这种情况,不用焦虑,很多前端也是一样的情况。只要我们一步步建设,慢慢落地基础设施,就一定会取得好的反馈




3. 技术的价值,在于解决业务问题,并且匹配


技术的价值,在于解决业务问题;人的身价,在于解决问题的能力


基建的内容我认为首先是 和业务阶段相匹配 的。不同团队服务的业务阶段不同,基建的内容和广深度也会不同。高下之分不在于多寡,而在于对业务的理解和支持程度。


“业务支撑” 和 “基础建设” 都是同一件事的两个面,这个 “同一件事”,就是帮助业务解决问题。任何脱离解决实际场景而发起的基建,都需要重新审视甚至不应被鼓励。如果时间成本没有那么多的话,建议先搭建好基本的建设底座,想要更好的闭环的想法还是先搁置一下。




4.个人不足


总结了这么多,结果发现自己对于一些知识点还是了解的太浅显了,自身在那些方面能分享的还是不多,也看了一些文章,只能描出个大概,实在是有点不好意思。但回头想想,这何尝也不算个勉励自己的方法,能够鞭策自己。后续,在我学习深入一些基建方面的知识后,会再出一些文章分享给大家,希望能够帮助到大家,共勉!!!☺(发现问题会及时补充)




落尾




大家好,我是 KAIHUA ,一个来自阿卡林省目前在深圳前端区Frank + ikun


从这周开始,我想试试每一两周复盘一次,总结出至少一个知识点,目的是尽快给自己的反馈,将自己产品一样快速迭代上升,希望可以坚持✊。


如果有什么相关错误,望大家指正,感谢感谢!!!(还在学习中,嘿嘿🤭)


下一篇文章应该会是关于 前端思考 方面的,希望早一点归纳出,和大家沟通交流...


各位 彦祖 / 祖贤,fan yin (欢迎) 关注点赞收藏,将泼天的富贵带点给我😭


一起加油!!! giao~~~🐵🙈🙉


作者:KAIHUA
来源:juejin.cn/post/7301150860825133110
收起阅读 »

有些程序员表面老实,背地里不知道玩得有多花

作者:CODING来源:juejin.cn/post/7259258539164205115

img


img


img


img


img


img


img


img


img


img


img


img


img


img


img


img


img


img


作者:CODING
来源:juejin.cn/post/7259258539164205115

关于我坚持 2 年的学习打卡心得

学习的心得 记住两个概念,终值和峰值。这是一个心理学专家提出来的。 峰值是指这段体验中的最高峰。终值是指这段体验结束后的感觉。它们都分为两个方向,正向和负向。 在学习的过程中,想体验到正向的终值和峰值,是比较困难的。我如何让学习变得相对愉悦一点呢?穿插自己比较...
继续阅读 »

学习的心得


记住两个概念,终值和峰值。这是一个心理学专家提出来的。


峰值是指这段体验中的最高峰。终值是指这段体验结束后的感觉。它们都分为两个方向,正向和负向。


在学习的过程中,想体验到正向的终值和峰值,是比较困难的。我如何让学习变得相对愉悦一点呢?穿插自己比较喜欢的,即自己比较擅长的。例如,我每次学习时,都会划分时间片,因为目标越小,压力越小。学习计算机网络,我每次强制自己学 25 分钟,时间一到就立刻停止,即使我还没学完整,此时去做一点自己喜欢的输入,例如去吃点水果零食,看会儿朋友圈。之后就是两种任务来回切换。如果让我连续学习几个小时的计算机网络,我可能很难坚持到最后。


为了避免终值是负向的,我们制定计划的时候,要考虑量力而行,以天为最小单位,不要给自己一天安排太多任务,根据自己的情况灵活决定,每天我们都能总结自己的收获,一目了然。人的大脑,都喜欢看到眼前的利益,我们的远大理想和目标,很难满足大脑。让自己能从每天的学习上得到正反馈。学东西,制定计划,不是为了用某种标准框架自己,我们是为了成长,而不是为了满足框架,专注做事本身。



  • 戒掉手机。物理隔绝。

  • 收集素材,整理输出。

  • 不搞形式主义,直接开始。

  • 带着问题去探索,做到记少忆多。

  • 要允许自己写出来垃圾,否则连垃圾都写不出来。

  • 检测自己获得了什么,也就是做题,实践应用。这样才能实现闭环。

  • 加工自己的知识,即仔细的思考、精细化的提问,多问自己“为什么”。


坚持的秘诀



  • 要么此时做,要么不再做。

  • 不要花大量的时间做容易的环节。

    • 例如学习数据结构与算法,长时间都去学习最基础的数组、链表、队列,这就是伪勤奋。相对的真勤奋,是真的那些让你需要感到思考、克服困难的任务。



  • 番茄模式。轮换式工作,投资式休息。

  • 如果不去做完成这个任务,就要去做更难得任务。

    • 例如学习计算机网络,我不想学习的时候,就告诉自己要去看 CSAPP。



  • 领先自己的计划。如有偷懒,也可接受,不至于一日崩盘。

  • 完成每天的目标后,其余时间,自由安排,一切感兴趣之事。

  • 要么自律,要么他律。

    • 什么是他律?大声的告诉你在意的人,你在学什么。



  • 不想学的时候,也先打开看看。根据惯性定律,改变状态往往是最难的,但维持状态却是相对简单的。


做笔记


笔记有两个方向,四个作用。
关于方向,一个方向记录别人说的话,另一个方向是记录看过的书、视频。关于作用,请看下图。


WechatIMG160.jpeg


总结


没有完美的方法论,只有完美的行动,祝愿看完的同学们,都能有完美的人生。


有修养的程序员才可能成长为真正的工程师和架构师,而没有修养的程序员只能沦为码农,这是码农和工程师的关键区分点。


修养指的是:英文能力、提问的能力、写代码的修养、安全防范意识、软件工程和上线规范、编程规范等。这些能力的训练和培养将为后续的学习和发展夯实基础。



作者:龚国玮
来源:juejin.cn/post/7204349756620750908
收起阅读 »

既当产品又当研发,字节大哥手把手带我追求极致

在学校的时候,计算机相关专业的同学应该都或多或少都被“大作业”折磨过,没有为“大作业”熬过夜通过宵的大学生活可以说是不完整的。步入公司后才发现,校园里的“大作业”就像玩具一样,需求明确、解决方案明确、最终产品效果明确、甚至还有前人的作品可以参考,而在公司里要做...
继续阅读 »

在学校的时候,计算机相关专业的同学应该都或多或少都被“大作业”折磨过,没有为“大作业”熬过夜通过宵的大学生活可以说是不完整的。步入公司后才发现,校园里的“大作业”就像玩具一样,需求明确、解决方案明确、最终产品效果明确、甚至还有前人的作品可以参考,而在公司里要做的东西,上面说的特点至少有一个不具备,甚至通通不具备。


而我在字节实习的过程中,所经手的恰恰就是这么一个需求不明确、解决方案不明确、最终产品效果不明确的项目。整个过程中有过焦头烂额毫无进展的时刻也有过欲哭无泪的时刻,还好有我的mentor带着我一路披荆斩棘、过关斩将。


首先和大家讲一下项目背景,当时我在的组是视频会议移动端,经历了近三年大流感的洗礼,相信大家对于视频会议中可能遇到的各种问题如数家珍,包括但不限于没声了、没音了、没画面了、画面卡顿、画面不清晰、画面和语音不同步、同步屏幕时闪退等等等等。作为一个服务企业级的B端产品,出现以上问题时就可能会投诉,然后经过客户成功部门转手到运营再转手到研发这里,研发就需要判断分析一下究竟是我们产品的原因、还是客户本身设备的问题、或者是第三方环境的因素,当用户的量级上来后,这样的客诉就会很多,会严重占用oncall的研发人员的时间以及精力。


我的mentor,一个专注于解决问题、避免重复劳动的人,一个字节范我觉得有E+的人,一个虽然身处移动端但是前后端甚至网络也都会的人,觉得这样很不OK,应该有个工具,能够自动的分析出来客户究竟遇到了什么问题,分析不出来的再找研发进行排查。没有这个工具也不影响业务开发的进展,所以整个项目并不存在时间上的紧迫性,但是呢,有这个工具做出来后肯定会大大降低研发的开发时间,所以项目的必要性还是有的。于是,我作为刚入职的实习新人,这个项目就交给我来做了。


而我,一个还没有从校园中完全出来的新兵蛋子,说实话面对这样的场面是一脸懵逼的,对于要做啥、要怎么做可以说是一无所知,我的mentor在我入职后,让我先了解了解背景,第一周就带着我oncall了,让我知道都可能有样的客诉,手把手给我演示他们正常的排查问题的方式。先了解客户反馈的情况,然后捞出来客户对应时间的设备信息以及设备日志。


说实话,作为一个新人,或者说我本身对于项目有一种畏难心理,碰到一点难题就总是想着往后拖,或者摆烂先不管然后就搁置在一边不想再问津了,但是我的mentor是一个有着坚定信念的人,差不多就是见山开山,见水架桥这种,遇到问题会主动找到相关人员一起解决,可以说就是有那种主人翁,项目owner的意识。于是,我就跟在他的后面,和整个团队的不同角色沟通他们遇到问题时排查的思路,试图总结出来一种通用的流程。在过程中,难免有许多困难,我的第一反应是退缩,但是导师的第一反应是拉会拉上相关人员一起讨论,看看用什么方式可以解决。比如在如何确定设备日志和故障表现的映射关系时,先后调研了多种方式看看相关团队有没有类似的做法以及他们最后实现的效果,包括大数据机器学习、代码状态流转图、自定义规则引擎等多种方式,最后调研后决定采用自定义规则引擎的方式。在实现需求的时候,需要其他团队协作时,他总是直接向前提出自己的需求,而我向一个陌生人发消息之前总要做一些心理建设,总是在担心些什么、害怕些什么,而事实上大家都是打工人,谁也不比谁厉害多少,对方不配合那就拉+1进群一起看看,解决不了就向上暴露问题。


于是,导师披荆斩棘在前,我在后面跟着实现他的设想。我们很快就做出来了第一个版本。通过Python自动化下载设备日志,然后正则匹配筛选出含有特定标记的日志,并对他们的出现频率次数做出判断。因为Python是解释型的语言,所以可以把规则直接写成python语言,用eval或者exec函数进行执行。第一个版本做出来后,导师又积极的带着我去给其他人宣传我们的这个工具。然后根据他们的反馈继续进行相关改进,最后我离职前实现的效果就是@ 一个群里的机器人,告诉他出现问题的ID,他就能自动化的拉下来日志进行排查,然后告诉你他分析的结果,整个交互非常的方便。


一个成功的项目必须要有一个负责的owner,我的导师就向我展示了一个优秀的owner是如何一步步解决问题、排除项目中的难关,如今我也正式成为一名打工人,希望我也能早日如他一般自如的面对工作。


我是日暮与星辰之间,出道两年半的Java选手,相信时间的力量,一起成为更好的自己!


作者:日暮与星辰之间
来源:juejin.cn/post/7211801284709138493
收起阅读 »

面试多起来了

就在昨天 10.17 号,同时收到了三个同学面试的消息。他们的基本情况都是双非院校本科、没有实习经历、不会消息中间件和 Spring Cloud 微服务,做的都是单体项目。但他们投递简历还算积极,从今年 9 月初就开始投递简历了,到现在也有一个多月了。 来看看...
继续阅读 »

就在昨天 10.17 号,同时收到了三个同学面试的消息。他们的基本情况都是双非院校本科、没有实习经历、不会消息中间件和 Spring Cloud 微服务,做的都是单体项目。但他们投递简历还算积极,从今年 9 月初就开始投递简历了,到现在也有一个多月了。


来看看,这些消息。
73cef56826e05f5c6076d35e6bcf442.jpg
7ceca957a2af480d4ae4fe345698b35.jpg
674493f3926c19f65f16c529e1c231b.jpg


为什么会这样?


9 月中旬就开始正式批校招了,而且从往年的数据来看,每年参加秋招的公司大概有 1700 多家,为什么大多数双非本科,到了 10 月中旬才有面试机会呢?


主要原因是软件行业这两年的情况是“供大于求”,一方面是软件公司的业务趋向平稳,招聘需求量不大;而另一方面是应届生逐年增多,而且涌向软件行业的人也越来越多。


a.毕业生增多


image.png
从图片可以看出,每年本硕毕业生都在增多,而 2022 年本硕毕业生已经达到了惊人的 1076 万人了,请问咱们国家的就业缺口有这么大吗?


b.业务平稳期


软件的生命周期中有两个大的阶段:



  1. 程序开发期:需要大量的人力协同开发一款程序,这时候需要大量的研发人员。

  2. 程序维护期:程序开发完了,只有一些小的需求和功能维护等工作,这个时候只需要少量的开发人员就可以搞定了。


而目前大部分互联网公司都已经进入了第二个阶段“程序维护期”,如果程序开发期需要 1000 人的话,那么维护期 50 个人就够了,因为没有很多的功能要做,只是少量修修补补的工作。


c.越来越多人的涌入


2018 年之后,计算机成为中国薪资最高的行业,一举超过了多年霸榜的金融行业,所以大家慢慢全部都明白了“计算机行业赚钱啊”。


所以,综合上述情况大家可以看出,目前的供需关系是:供给方(毕业的学生)远远大于需求方(用人单位),所以目前计算机行业就业严峻是一个必然事件。


如何获得Offer?


既然想拿高薪、既然没有其他的出路、既然已经上了贼船,那么怎么才能在竞争激烈的校招中找到满意的 Offer 呢?


你需要做以下四件事:



  1. 海投简历

  2. 面试前充分准备

  3. 准备好自我介绍

  4. 调整好心态&积极面试


1.海投简历


海投简历是指,你要把你能找到的、你能看到的所有和你岗位相关的职位都投递一遍(简历)。


举个例子,例如你在 Boss 上投递 Java 研发工程师的工作,那么就搜索“Java”,然后把你能找到的(看到的)所有公司,且没投递的公司(投递的公司用 Excel 记录下来),全部(打招呼)投递一遍简历。


注意:不用去看 HR 发布的职位要求,很多公司发布的职位要求是比较高的,但大部分情况下,她们都会减低标准,给更多应聘者笔试和面试的机会。所以说,不要看到很高的职位要求就退缩了,任何机会都不要放过,海投就是投递所有和你职位相关的所有公司,一家都不放过,因为他的失败影响不大,但万一成功了就有工作了。



海投简历什么时候结束?
答:海投简历通常是到 11 月中下旬,或拿到第一个保底 Offer 之后,才会逐渐停止,所以做好打持久战的准备,没有任何事是一蹴而就的。



2.面试前充分准备


面试之前,一定要把该公司的岗位技能要求,以及该公司的往年历史真题全部过一遍。


对于自己不会的技能一定要提前学习,还有往年的历史真题也要仔细过一遍,把不会的问题在面试前一定要搞定,防止面试时再次被面试官问到。


3.准备好自我介绍


细节决定成败,面试本质上是“自我推销”的过程。如何在短短的几十分钟内打动面试官,从来都不是一个简单的问题。


所以怎么开场?怎么让面试官对我产生兴趣?非常关键。


好的自我介绍,一定要讲明白以下 4 点:



  1. 你是谁?

  2. 你会啥?

  3. 你有什么成就?

  4. 为什么是你?


a.你是谁?


自我介绍的第一步一定是自报家门,例如,我是张三,2015 年毕业于西安电子科技大学,毕业之后一直从事 Java 开发的工作,做过 XXX 公司的高级研发工程师,也很高兴参加贵公司的面试。



校招版本:我是李四,24 届学生,目前就读于西安电子科技大学,硕士学历,就读的专业是软件工程(非软件相关专业就不要介绍你的专业了),很荣幸参加贵公司的面试。



b.你会啥?


技术岗位,最看重的就是你的技术能力,所以这一步一定要好好准备,并详细的介绍你会的技能。


要做好这一步,在面试前一定要查阅应聘公司的岗位要求和使用的技术栈,这样你就能针对性的进行技能介绍了。而当面试官看到一个应聘者的技术栈,和自己公司的技术栈完全匹配的时候,你的面试成功率就大幅提升了。


例如,你可以这样介绍。
我会的技能是并发编程、MySQL、Redis、Spring、Spring MVC、Spring Boot、Spring Cloud Alibaba Nacos、Sentinel、Seata、Spring Cloud Gateway、Skywalking、RabbitMQ 等技术栈。


c.你有什么成就?


学以致用很重要,尤其是校招,你上面说你会,那么怎么证明你真的会你说的哪些技术呢?你使用上述技能获得过什么成就?或做过什么项目呢?


如果你参加过 ACM、蓝桥杯等编程竞技大赛,可以在自我介绍的时候详细的说一下,参赛情况和获奖经历。


如果你没有参赛经历和获奖经历,那么你可以介绍你用上面的技能做过什么项目?


例如,我使用 Spring Cloud Alibaba 全家桶 + Spring Cloud Gateway + MySQL + Redis + RabbitMQ 总共做过 3 个项目,其中有两个项目我已经写在简历上了,等会您有任何关于项目或技能点的问题都可以问我。


d.为什么是你?


前面三点是陈述,而最后这点就要升华了,这也是你进行“自我吹嘘”最后的机会,也是打动面试官最关键的时刻,“峰终定律”就是讲这个事。


为什么要你?就是你要介绍自己的优点了,例如(但不限)以下这些:



  1. 我的技术栈和公司非常匹配:因为我的技术栈和公司的技术栈非常匹配,所以来了之后就能直接干活,大大节省了新人培养成本。

  2. 我对公司的业务比较熟悉:我之前从事过,或者详细的了解过公司的相关业务,所以来了之后直接能干活,大大节省了业务培训成本。

  3. 我做事比较专注:例如,去图书馆看书,经常忘记吃中午饭,等到肚子饿的不行了,抬头一看表已经下午 3 点了。

  4. 我自学能力比较强:例如,整个微服务,像 Spring Cloud Alibaba 整个技术栈,我只用了 2 周的时间就全部学会了,并且能用它开发一个 Java 项目,期间遇到的所有问题,我都能自行解决。

  5. 我喜欢编程:例如,您可以看我的 GitHub 我每天都有练习和提交代码。


4.调整心态&积极面试


a.避免过度紧张


学的好也要面的好,尤其是第一次面试,紧张是不可避免的事情,所以你要告诉自己“允许自己适当紧张”这是正常的表现。


你越在意什么就越容易失去什么,所以不要过度的在意“自己比较紧张”这件事,它是正常的情况,我工作 13 年了,现在出去面试依然会紧张,所以“紧张”这些事,本身就是人类正常的情绪。


如何缓解紧张?


答:把注意力和精力放在面试官问的问题上,而不是过度的关照自我,面试前深呼吸,面试时把注意力放在自身以外的其他事情上,这样就能大大的减少紧张的情绪。


b.不要害怕失败


越害怕什么就越容易失去什么,所以不要害怕失败,失败乃成功之母,任何事情都是有意义的,即使失败也不例外,它能让你变成更好的自己。


你把每次面试都当成是自我检验和自我提升的机会,无论结果如何,你都能收获成长,越不在意结果,可能结果越理想。


c.不要太在意薪资


万事开头难,尤其是校招第一份工作,不要太在意薪资,你真正赚钱是 3-5 年工作经验之后,所以事情不可能一蹴而就,也不可能一口气吃成一个大胖子。所以先入行比什么都重要,熟练之后才能真正的赚到钱。每个人都是一样,所以不要太在意入行薪资。


小结


软件行业业务趋于平稳,涌入的人越来越多,所以也会越来越卷,每年都是当下最好的一年,所以你只有做到最好,才有可能拿到满意的 Offer。多投简历、面试前做好充足准备、准备好自我介绍、调整好心态、积极去面试,相信做好这些,结果就不会太差。加油,少年。


作者:Java中文社群
来源:juejin.cn/post/7291134345920643107
收起阅读 »

用剥蒜的方式去学习闭包,原来这么简单!!!

web
对于很多学习js的码友们来说,闭包无疑是最难啃的模块之一,今天我们就用剥蒜的方式一层一层的剥开它。 我们先用一个案例来引入它 大多数肯定会觉得它输出的结果是0到9,那么大多数人都错了,它输出的结果是十个10 那么要怎么让它输出0到9呢?这里我们要先引入一个新...
继续阅读 »

对于很多学习js的码友们来说,闭包无疑是最难啃的模块之一,今天我们就用剥蒜的方式一层一层的剥开它。


我们先用一个案例来引入它



大多数肯定会觉得它输出的结果是0到9,那么大多数人都错了,它输出的结果是十个10
那么要怎么让它输出0到9呢?这里我们要先引入一个新的东西,叫调用栈


调用栈


调用栈是用来管理函数调用关系的一种数据结构


在代码预编译的时候就会产生一个生成一个调用栈,它会先去找到代码中的全局变量、函数声明,形成一个变量环境,这个变量环境和词法环境(这里我们不去探讨)一起放在全局执行上下文中。然后再从上到下去执行代码,每调用一个函数,就会生成一个该函数的执行上下文,然后入栈,函数执行的时候先去它的词法环境去找对应的变量名,找不到再去变量环境中找,再找不到就去它的下一级去寻找直到找到为止,然后函数执行完成后再将其执行上下文销毁,避免栈溢出,我们用一个代码来举例:


iwEcAqNwbmcDAQTRB4AF0QQ4BrAXVDtt0dImQAU9UGjZw-8AB9IZAt15CAAJomltCgAL0gAC84A.png_720x720q90.jpg


执行函数add时,先去add的执行上下文中寻找b,b在add的变量环境中,但是并没有a,于是再去全局执行上下文中按照词法环境和变量环境的顺序去找,找到了a,最终返回a+b=12。


作用域链


调用栈在生成执行上下文时会默认在变量环境中产生一个outer,它指向该函数的外层作用域,函数声明在哪里,哪里就是函数的外层作用域,然后形成一个作用域链。


我们再来看下一个案例



调用foo的时候生成了foo的执行上下文,foo的函数体中有bar的调用,所以又生成了一个bar的执行上下文,bar声明在最外面,所以它的outer指向全局执行上下文,因此当bar在寻找myName这个变量的时候直接跳过foo去了全局执行上下文,所以最终输出的结果是万总


iwEcAqNwbmcDAQTRB4AF0QQ4BrDMeEmBKzv5FAU9V3BEkJoAB9IZAt15CAAJomltCgAL0gADbJY.png_720x720q90.jpg


闭包


了解完调用栈和作用域链之后,就可以进入我们今天的主题闭包了,还是用一个案例来说明



函数a的函数体中声明了一个函数b,并且函数a的结果是返回了函数b


var c = a() 先调用a,并且把a的返回值赋给c,因此c就是一个函数,然后再调用c,这就是整个的执行过程。在调用完a后,a的函数体已经全部执行完毕,应该被销毁,但是在调用c的时候(c就是函数b),需要用到a中的变量,因此在销毁掉a的执行上下文的同时会分出一个区域用来存储b中所需要用到a的变量,这个存储了count的地方就叫做闭包。


iwEcAqNwbmcDAQTRB4AF0QQ4BrCKgRsdcT9JIgU9Y1plkyAAB9IZAt15CAAJomltCgAL0gACzhQ.png_720x720q90.jpg


因此闭包的概念就是:


即使外部函数已经执行完毕,但是内部函数引用了外部函数中的变量依然会保存在内存中,我们把这些变量的集合,叫做闭包


现在我们再回到第一个问题,如何让它输出0到9,很显然,就是在for的内部形成一个闭包,让i每次可以叠加存在内存中,因此代码如下:



这样一层一层把从外到内的去了解闭包,是不是就更容易了呢,你学会了吗?


作者:欣之所向
来源:juejin.cn/post/7300063572074201125
收起阅读 »

自定义注解实现服务动态开关

🧑‍💻🧑‍💻🧑‍💻Make things different and more efficient 接近凌晨了,今天的稿子还没来得及写,甚是焦虑,于是熬了一个夜也的给它写完。正如我的题目所说:《自定义注解实现服务动态开关》,接下来和shigen一起来揭秘吧。 ...
继续阅读 »

🧑‍💻🧑‍💻🧑‍💻Make things different and more efficient


接近凌晨了,今天的稿子还没来得及写,甚是焦虑,于是熬了一个夜也的给它写完。正如我的题目所说:《自定义注解实现服务动态开关》,接下来和shigen一起来揭秘吧。




前言


shigen实习的时候,遇到了业务场景:实现服务的动态开关,避免redis的内存被打爆了。 当时的第一感受就是这个用nacos配置一下不就可以了,nacos不就是有一个注解refreshScope,配置中心的配置文件更新了,服务动态的更新。当时实现是这样的:


在我的nacos上这样配置的:


 service:
  enable: true

那对应的java部分的代码就是这样的:


 class Service {
   @Value("service.enable")
   private boolean serviceEnable;
   
   public void method() {
     if (!serviceEnable) {
       return;
    }
     // 业务逻辑
  }
 }

貌似这样是可以的,因为我们只需要动态的观察数据的各项指标,遇到了快要打挂的情况,直接把布尔值换成false即可。




但是不优雅,我们来看看有什么不优雅的:



  1. 配置的动态刷新是有延迟的。nacos的延迟是依赖于网络的;

  2. 不亲民。万一哪个开发改坏了配置,服务就是彻底的玩坏了;而且,如果业务想做一个动态的配置,任何人都可以在系统上点击开关,类似于下边的操作:


服务开关操作


element-UI的动态开关


nacos配置的方式直接不可行了!


那给予以上的问题,相信部分的伙伴已经思考到了:那我把配置放在redis中呗,内存数据库,直接用外部接口控制数据。


很好,这种想法打开了今天的设计思路。我们先协一点伪代码:


 @getMapping(value="switch") 
 public Integer switch() {
     Integer status = redisTemplate.get("key");
     if (status == 1) {
       status = 0;
    } else {
       status = 1;
    }
     redisTemplate.set("key", status);
     return status;
 }
 
 
 @getMapping(value= "pay")
 public Result pay() {
   Integer status = redisTemplate.get("key");
   if (status ==0) {
     throw new Bizexception("服务不可用");
  } else {
     doSometing();
  }
 }

貌似超级完美了,但是想过没有,业务的侵入很大呢。而且,万一我的业务拓展了,别的地方也需要这样的配置,岂不是直接复制粘贴?那就到此为止吧。




我觉得任何业务的设计都是需要去思考的,一味的写代码,做着CRUD的各种操作,简直是等着被AI取代吧。


那接下来分享shigen的设计,带着大家从我的视角分析我的思考和设计点、关注点。


代码设计


注解设计


 @Target(ElementType.METHOD)
 @Retention(RetentionPolicy.RUNTIME)
 public @interface ServiceSwitch {
 
     String switchKey();
 
     String message() default "当前业务已关闭,请稍后再试!";
 
 }

我在设计的时候,考虑到了不同的业务模块和失败的信息,这些都可以抽取出来,在使用的时候,直接加上注解即可。具体的方法和拦截,我们采用spring的AOP来做。


常量类


 public class Constants {
 
     public static final String ON = "1";
     public static final String OFF = "0";
 
     public static class Service {
 
         public static final String ORDER = "service-order";
         public static final String PAY = "service-pay";
    }
 
 }

既然涉及到了业务模块和状态值,那配置一个常量类是再合适不过了。


业务代码


   @ServiceSwitch(switchKey = Constants.Service.PAY)
   public Result pay() {
       log.info("paying now");
       return Result.success();
  }

业务代码上,我们肯定喜欢这样的设计,直接加上一个注解标注我们想要控制的模块。


请注意,核心点来了,我们注解的AOP怎么设计?


AOP设计


老方式,我们先看一下代码:


 @Aspect
 @Component
 @Slf4j
 public class ServiceSwitchAOP {
 
     @Resource
     private RedisTemplate redisTemplate;
 
     /**
      * 定义切点,使用了@ServiceSwitch注解的类或方法都拦截 需要用注解的全路径
      */

     @Pointcut("@annotation(main.java.com.shigen.redis.annotation.ServiceSwitch)")
     public void pointcut() {
    }
 
     @Around("pointcut()")
     public Object around(ProceedingJoinPoint point) {
 
         // 获取被代理的方法的参数
         Object[] args = point.getArgs();
         // 获取被代理的对象
         Object target = point.getTarget();
         // 获取通知签名
         MethodSignature signature = (MethodSignature) point.getSignature();
 
         try {
 
             // 获取被代理的方法
             Method method = target.getClass().getMethod(signature.getName(), signature.getParameterTypes());
             // 获取方法上的注解
             ServiceSwitch annotation = method.getAnnotation(ServiceSwitch.class);
 
             // 核心业务逻辑
             if (annotation != null) {
 
                 String switchKey = annotation.switchKey();
                 String message = annotation.message();
                 /**
                  * 配置项: 可以存储在mysql、redis 数据字典
                  */

                 String configVal = redisTemplate.opsForValue().get(switchKey);
                 if (Constants.OFF.equals(configVal)) {
                     // 开关关闭,则返回提示。
                     return new Result(HttpStatus.FORBIDDEN.value(), message);
                }
            }
 
             // 放行
             return point.proceed(args);
        } catch (Throwable e) {
             throw new RuntimeException(e.getMessage(), e);
        }
    }
 }

拦截我的注解,实现一个切点,之后通知切面进行操作。在切面的操作上,我们读取注解的配置,然后从redis中拿取对应的服务状态。如果服务的状态是关闭的,直接返回我们自定义的异常类型;服务正常的话,继续进行操作。


接口测试


最后,我写了两个接口实现了服务的调用和服务模块状态值的切换。


 @RestController
 @RequestMapping(value = "serviceSwitch")
 public class ServiceSwitchTestController {
 
     @Resource
     private ServiceSwitchService serviceSwitchService;
 
     @GetMapping(value = "pay")
     public Result pay() {
         return serviceSwitchService.pay();
    }
 
     @GetMapping(value = "switch")
     public Result serviceSwitch(@RequestParam(value = "status", required = false) String status) {
         serviceSwitchService.switchService(status);
         return Result.success();
    }
 }

代码测试


测试服务正常


服务状态正常情况下的测试


此时,redis中服务的状态值是1,服务也可以正常的调用。


测试服务不正常


我们先调用接口,改变服务的状态:


调用接口,切换服务的状态


再次调用服务:


服务模块关闭


发现服务403错误,已经不能调用了。我们改变一下状态,服务又可以用了,这里就不做展示了。


作者:shigen01
来源:juejin.cn/post/7301193497247055908
收起阅读 »

程序员什么时候感觉到编程能力突飞猛进?

我是一个41岁老程序员,从 2007年硕士毕业参加工作以来,已经在编程一线工作16年了。平时一直有逛技术社区的习惯。最近在社区看到一个讨论,题目是《你什么时候感觉到编程能力突飞猛进》。我觉得这个题目挺有意思,于是借这篇文章,也来聊聊自己的程序人生。 我觉得自己...
继续阅读 »

我是一个41岁老程序员,从 2007年硕士毕业参加工作以来,已经在编程一线工作16年了。平时一直有逛技术社区的习惯。最近在社区看到一个讨论,题目是《你什么时候感觉到编程能力突飞猛进》。我觉得这个题目挺有意思,于是借这篇文章,也来聊聊自己的程序人生。


我觉得自己编程能力突飞猛进,应该是分了几个阶段吧。


第一阶段:研究生时期封闭式的项目开发阶段


我 2004 年电子科技大学计算机科学与技术本科毕业,同年留在母校,继续攻读计算机系统结构的硕士学位。研一时上了很多专业必修课,比如《Unix 系统设计》,《Unix 环境下的高级编程》,《Unix 网络编程》等等。但是这些书本上的知识,我也只是课堂上跟着老师过了一遍,缺乏动手实战。研一在校园里,也只是完成这些教材的课后作业而已。我当时具体有多菜?连 GDB 调试器都不熟,代码执行出错,我只会用 printf 大法来定位问题。


研二时我们教研室的同学们,在当时段翰聪段博的带领下,到北京声学所高性能网络实验室做项目。白天在实验室,晚上九点之后才返回海淀区知春路的学生宿舍休息,算是一年的封闭式开发吧。当时教研室承接的项目是国家发改委 CNGI 专项基金子课题——基于 IPv6 的 P2P 弹性重叠网络智能节点的研制。段博当时还在攻读他的博士学位,他现在已经是电子科技大学计算机科学与工程学院的教授和博士生导师了。


这一年的封闭式开发,我最先的任务是负责实现一款基于 P2SP 协议的负载发生器,作为测试工具,来验证项目研制的网络智能节点的各项性能指标和参数。刚开始动手编写项目代码时,我就立即感受到这种大型项目和校园里编写的那些课后作业代码的具体差异。我的程序代码量稍稍一上去,一运行就 Segmentation Fault,然后我就不知所措了。还好项目组里有段博这种大神,还有教研室其他优秀的同学帮助我。这一年我们可以说是心无旁骛,每天除了项目编码,技术讨论,然后就是找一些项目相关的论文来阅读,再有就是网上逛技术社区。慢慢的我也熟练掌握了 GDB 的用法,遇到问题也知道如何通过单步调试去定位问题,根据程序运行出错消息用搜索引擎去寻找解决方案,向身边伙伴求助的次数也明显减少了。



第二阶段:工作时大量研读其他高手同事的代码


2007 年研究生毕业后,我进入了 SAP 成都研究院工作。我本科和研究生生涯,使用的都是 C/C++, 工作中换成了 SAP 独树一帜的 ABAP. 面对技术栈的切换,编程经验尚浅的我可谓是苦不堪言,ABAP 在我手中用起来觉得各种别扭。有一次,ABAP 一个浅拷贝和深拷贝的问题困扰了我几天,我居然还写邮件,给 SAP 成都研究院我熟识的几位 ABAP 高手同事吐槽,说某某需求如果用 C/C++ 实现那是分分钟的事,可现在换成 ABAP,得绕来绕去。



现在回忆起来,我当时的行为挺可笑。那几位高手同事收到邮件后没有回复,只有一位当时外号薛老板的同事,不仅认真给我指出我邮件里关于 ABAP 实现深拷贝的错误,邮件末尾还点评到:“从 ABAP 转 C++/Java 很难,但是从 C++/Java 转 ABAP 开发很简单。”


虽然当时 SAP 开发社区尚不如现在完善,2007 年的时候,网络上 ABAP 开发资源也没有现在丰富。不过 ABAP 的开发编程环境在服务器端,这使得我能轻松阅读到服务器上其他 ABAP 高手的代码。


抱着熟读唐诗三百首,不会作诗也会吟的心态,我把我认识的很多 ABAP 高手的工作代码看了一个遍。不光看,还把他们的代码拷贝出来,自己修改,然后单步调试,边调试边学习。遇到不懂的知识点,直接按 F1 召唤出帮助文档学习。



通过大量的阅读,我发现程序员与程序员之间还是存在细微的编码风格差异。比如 William 是当时在 SAP 成都研究院工作过的一位天才程序员,他的很多非生产代码,都是用面向过程的编程方式编写,并且变量命名风格颇有谭浩强 C 语言程序设计那本书里配套源代码的风采。Willian 程序里数量众多的 include 和神秘的变量命名规则,庞大的代码量,但是最后程序仍然能够极其精巧地运行,成功实现极其繁复的需求,这一切让我佩服不已。


Annie 是另一个让我极其佩服的 ABAP 程序媛。她的代码生产速度让我惊叹,而且代码规范工整,犹如教科书一般。当时 SAP 成都研究院 On Demand 交付项目使用的 CPMS(Content Production Management System) ,前身是 CR(Content Repository) 系统,这个系统的主要开发人员就是 Annie. 她对 CR 系统的贡献,给我提供了大量可供学习和模仿的素材。当时在佩服之余,我心中也有一个疑问:Annie 是如何做到短时间内写出海量高质量代码的?要知道那可是在 2007 年,那时既没有 ABAP 代码生成向导,也没有 ChatGPT. 我当时性格腼腆,也没好意思去问她,这个遗憾就一直留到现在了。


就这样一头扎进 ABAP 代码海洋之后,慢慢的我工作中对 ABAP 的运用也得心应手起来,和自己刚进 SAP 成都研究院时相比,ABAP 编程能力可以说是突飞猛进,这可能就是量变到质变吧。



第三阶段:2014 年接触 JavaScript/HTML/CSS


2007~2014年,我做了七八年的 ABAP 开发,2014 年底,我觉得自己算是这个领域的专家了,此时工作岗位变动,需要接收 SAP UI5 应用开发,使用的技术栈从 ABAP 转成了 JavaScript 和 HTML/CSS. 此前我从未在工作中接触过基于 JavaScript 的 Web 前端开发。和之前刚毕业工作时从 C++ 转 ABAP 一样,我在刚接触 SAP UI5 开发时,又失去了对 ABAP 得心应手那种感觉。


我当时的做法是,从源代码实现的层面研究 SAP UI5 这个前端框架,研究它的工作原理,顺便把 JavaScript 也学习了。我也在技术社区上发布了《深入学习 SAP UI5 框架代码系列》,从 SAP UI5 Module 的懒加载机制,控件渲染机制,事件处理机制,元数据实现机制,实例数据的读写实现原理,数据绑定的实现原理等方面,通过分析 SAP UI5 框架的 JavaScript 源代码实现,介绍了我对这个前端开发框架的理解。



从框架一行行代码的研读,我也领略了从事应用开发和框架开发的不同侧重点和编程技巧,我这个系列总共写了 14 篇文章。漫长的框架源代码研读和文章写作完成之后,我感到自己 Web 应用的编程能力再次突飞猛进。


展望未来


以 ChatGPT 为代码的 AIGC 工具的流行,为程序员再次提供了编程能力突飞猛进的机会。善用 AIGC 工具,我们可以提高自己对陌生编程领域的学习速度,在学习遇到障碍时,善用这些工具,能够帮助我们克服学习过程中遇到的各种困难。


愿每一位程序员同行都能在编程中找到快乐。



作者:JerryWang_sap
来源:juejin.cn/post/7300118821532450831
收起阅读 »

我被这奇葩的答辩评价给惊呆了

最近组里有个小伙伴晋升,我司职级跟腾讯的不一样,可以理解为大概是要晋升高工(T9)吧。 据我了解,我司的晋升答辩还不成熟,没有统一规范和套路,那我就以腾讯的经验来辅导我的小伙伴吧。我想,万变不离其宗,只要能论证能力达标就可以了吧,结果,我着着实实地被这个奇葩的...
继续阅读 »

最近组里有个小伙伴晋升,我司职级跟腾讯的不一样,可以理解为大概是要晋升高工(T9)吧。


据我了解,我司的晋升答辩还不成熟,没有统一规范和套路,那我就以腾讯的经验来辅导我的小伙伴吧。我想,万变不离其宗,只要能论证能力达标就可以了吧,结果,我着着实实地被这个奇葩的答辩评价给雷到了。


插图1.jpeg


上周答辩,我跟我领导全程旁听。先不管我的小伙伴的答辩内容、评委提问对答表现、临场发挥怎么样,直接快进,跳到最后评委合议之后的答辩总结环节。



原话我肯定不记得了,就按照大概意思来描述



“先说说 XX 的优点。XX 的答辩有两个很突出的优点,”


“第一个是体现出来很好的产品化思维,整体的架构设计把握得比较好,能够解释地比较清楚;”


“第二个是问题解决能力比较好,能够结合业务的情况去思考方案的优缺点,进行合理的决策。”


“但 XX 的答辩有个很明显的问题。”


“这个项目没有很好地体现前端的技术(深度)。”【我当时的反应:what?评委,麻烦你再说一次?】


“这么说吧,这是前端的通道答辩,这个项目放在前端的通道答辩是不太合适的这个项目对前端岗位的挑战是不太够的。”【我当时的反应:!?我不是很懂你在说什么,我进错会议室了?】


换种说法,这个项目拿去给 QA 也是能做出来的。”【这一句是原话,因为这句话是印象最深刻的。】


这句话真得把我给整无语了。


首先,3 个评委都是前端,之前还会有后台的评委,今年终于“规范”了,全部前端了。照我说,还不如来后台评委呢,不至于说这种话,真给整破防了。


其次,这些评委全部是比我高 1、2 级的,这职级居然能说出这种话。


所以,我挺想知道,什么是前端技术?什么是前端专属的技术?


按照评委们的说法,


那不要拿后台全栈项目去答辩了,后台也是能做出来的。


那不要拿 app 跨端项目去答辩了,app 客户端也是能做出来的。


那不要拿 pc 跨端项目去答辩了,pc 客户端也是能做出来的。


那不要拿 devops 项目去答辩了,谁都能做出来的。


那不要拿基建项目去答辩了,infra 也是能做出来的。


所以,前端技术就只剩切图仔了呗????搞搞组件库?搞搞页面性能优化?


问题是这玩意儿能搞出花儿来?真想搞出花儿来不得再造一个 React?真要搞出个 React 出来能呆在这儿?


哎,真要被憋出内伤来了,还是得写出来释放一下。


我司答辩还没到卷部门影响力的地步,那全凭答辩评委个人喜好我也忍了,但这样的认知我实在是接不住呀。


哎,止血止血,打住打住,给我一周时间缓一缓,缓一缓......


作者:潜龙在渊灬
来源:juejin.cn/post/7300918873904824331
收起阅读 »

那个年薪 201万 的华为 “天才少年” 真面目被曝光,醒醒吧,他根本就不是天才!

综合自网络有的人为了买房掏空家里6个钱袋,此后几十年被捆绑在房贷上,有的人自己奋斗几年,甚至是一两年就可以全款入手。今天介绍一个高考落榜,复读一年才进一所三本院校,最后成功逆袭成为年薪201万的华为“天才少年”的故事。你以为201万已经是他的极限了,其实更牛的...
继续阅读 »
综合自网络
有的人为了买房掏空家里6个钱袋,此后几十年被捆绑在房贷上,有的人自己奋斗几年,甚至是一两年就可以全款入手。
今天介绍一个高考落榜,复读一年才进一所三本院校,最后成功逆袭成为年薪201万的华为“天才少年”的故事。
你以为201万已经是他的极限了,其实更牛的还在后面。
他曾拒绝腾讯和阿里,甚至是世界巨头IBM的offer,有的大厂甚至开出了360万年薪。
看到的这样的消息,网友的态度很统一:
这位“天才少年”叫张霁,彼时的他刚博士毕业,不过如今他的过往经历被曝光,人们震惊地发现他的真面目:根本不是什么天才!
复读才考上三本,最后成功逆袭的原因
张霁最高学历是985高校华中科技大学计算机专业博士学位,但退回几年前,他还是别人眼中的“失败者”。

他的父母职业都是教师,对他的学习成绩没有作过多要求,重点培养他独立思考的能力,比如儿时他看上一个价值50块钱的玩具,父母只会给他45块钱,剩下的5块要他自己想办法,小张霁会通过卖废品的方式攒到钱去购买心爱的玩具。

通过这样的教育,培养了他善于思考和动手解决问题的能力,但是张霁并没有重视成绩,因此平时成绩不温不火,直到高考那年,连大学都没考上。

在之后伴随的“这个孩子完了”、“当个技工”评价声中,痛定思痛,决定复读。努力追赶了一年,奇迹并没有发生,他考上了一所当地人都很少知道的三本民办院校——武昌理工学院。

谁能想到,三本只是他的起点,他选择了并不热门的专业——计算机,在往后的几年里,他会继续完成他的人生逆袭,
当时学校氛围不必多说,大家基本每天都在吃喝玩乐,努力学习不仅是异类,甚至会被取笑。
张霁就在这样的环境中定下了考研考博的目标,并坚持不懈的在图书馆啃难嚼的书本,最终功夫不负有心人的考上了武汉邮电科学研究院的研究生。
3年后又考上了自己的理想大学华中科技大学博士——这里是武汉光电国家研究中心,更是整个湖北省唯一的国家级实验室。
读博期间他取得了许多突破,并在众多国际一流刊物发表相关学术论文,包括ATC, DAC,ICPP等行业顶级会议和期刊。
每篇都是国际top级别,刊登难如登天,是无数科研人毕生的追求,重点是许多成果可以直接落地。
此外,他还在腾讯实习期间拿到了腾讯2016、2017年度杰出贡献奖,2019年度最佳卓越运营奖。
最后选择了华为,是因为华为正在受到“制裁”,他知道可以在华为找到志同道合的人,一起努力渡过难关。
他有一句座右铭:“很多人比你还要努力,你有什么理由不上进”。
所有的成功都有努力后的水到渠成
入选华为“天才少年”并不容易。
“众所周知,华为有资源池。”知乎上一名匿名的华为员工介绍称,例如,某产品线申报人力缺口200人,那么一般会从简历投递者中按学校、专业等筛选出大约2000份简历。
笔试、面试通过大概500人,放进资源池。
然后再按笔试、面试综合成绩发放200份offer,最终有100人签约,然后再按顺序发放100份offer……直到offer签完。
哪有什么天才少年,不过是一群怀揣梦想、坚韧不拔的人在苦苦地熬。
吃够了苦,熬到了头,生活才有可能对你网开一面。
张霁的逆袭故事并不是“天才少年”里的个例。
沈树忠,家境贫寒,世代都是农民出身。第一次高考成绩化学只有5分,物理0分。第二次高考仅仅读了中专,毕业后当了个“挖煤工人”,20岁自学考研,历时6年拿到硕士博士学位,如今是中国科学院院士,并拿下了地层学国际最高金奖,成为中国获此奖项第一人。
还有物理5分、化学5分,数学15分,却要挑战物理系,让爱因斯坦赞叹过的世界火箭、宇航工程的开拓者,“中国力学之父”,他叫钱伟长。
同样有201万年薪的左鹏飞,也不是大家眼中的“天选之子”。
他说:“我只是把别人打游戏的时间,花在了实验室里。”
......
说实话,我觉得“天才少年”这个项目名字虽然吸引人,但它给很多日以继夜的努力才得到的结果加上了一层光芒四射的滤镜,让普通人可望而不可即。
它容易让人们忽略那些努力的重要性。
但其实,哪有那么玄乎。这世界上99.9%的人远没有到拼智商的时候,有的不过是找到自己为之努力的方向、去坚持然后得到。
于是,年龄大的叫大器晚成,年龄小的叫天才,我更愿意称其为逆袭。
薛兆丰:“我们每个人,都在为自己的简历打工。”
知乎上有这样一个提问:
“为什么大多数人宁愿吃生活的苦,也不愿吃学习的苦?”
点赞最高的答主@特雷西亚是这样说的:
“生活的苦难可以被疲劳麻痹,被娱乐转移,无论如何只要还生存着,行尸走肉也可以得过且过,最终习以为常,可以称之为钝化。 
学习的痛苦在于,你始终要保持敏锐的触感,保持清醒的认知和丰沛的感情,这不妨叫锐化。”
生活的苦,会让人麻木,习以为常;学习的苦,让人保持尖锐的疼痛感。
人生是一条漫长的旅程,但关键的就那么几年。
生活其实并不算太苦,苦的是在该努力的年纪,你却选择了放纵和逃避。
真正的苦,是被命运扼住了咽喉,无法动弹,没有出路。
《奇葩说》里辩手肖骁有一句辩词我特别喜欢:
往往最诱惑的选择,不是上帝给你的机会,而是恶魔给你的考题。
在向上攀登的路上,我们会遇到无数选择题:
安逸还是改变?主动出击还是随波逐流?
我只有一个建议:在人生的十字路口,永远选择正确但困难模式。
因为好走的路,都是下坡路。
所以现在开始学习起来吧,定好目标,规划好人生的每一步,低级的快乐靠放纵,顶级的快乐靠自律。
---END---

作者:程序员直聘
来源:mp.weixin.qq.com/s/0TKWfX7-HvrgFs8xowr5sw
e>

收起阅读 »