前言

hi，大家好，我是大鱼七成饱。

前几天同事review我的代码，发现mapstruct有这么多好用的技巧，遇到POJO转换的问题经常过来沟通。考虑到不可能每次都一对一，所以我来梳理五个场景，谁在过来问，直接甩出总结。

环境准备

由于日常使用都是spring，所以后面的示例都是在springboot框架中运行的。关键pom依赖如下：

<properties>

        <java.version>1.8</java.version>

        <org.mapstruct.version>1.5.5.Final</org.mapstruct.version>

        <org.projectlombok.version>1.18.30</org.projectlombok.version>

    </properties>

    <dependencies>



        <dependency>

            <groupId>org.mapstruct</groupId>

            <artifactId>mapstruct</artifactId>

            <version>${org.mapstruct.version}</version>

        </dependency>

        <dependency>

            <groupId>org.mapstruct</groupId>

            <artifactId>mapstruct-processor</artifactId>

            <version>${org.mapstruct.version}</version>

        </dependency>



        <dependency>

            <groupId>org.projectlombok</groupId>

            <artifactId>lombok</artifactId>

            <optional>true</optional>

            <scope>provided</scope>

        </dependency>



        <dependency>

            <groupId>org.projectlombok</groupId>

            <artifactId>lombok-mapstruct-binding</artifactId>

            <version>0.2.0</version>

        </dependency>



        <dependency>

            <groupId>org.springframework.boot</groupId>

            <artifactId>spring-boot-starter</artifactId>

        </dependency>



        <dependency>

            <groupId>org.springframework.boot</groupId>

            <artifactId>spring-boot-starter-test</artifactId>

            <scope>test</scope>

        </dependency>

    </dependencies>



    <build>

        <plugins>

            <plugin>

                <groupId>org.springframework.boot</groupId>

                <artifactId>spring-boot-maven-plugin</artifactId>

            </plugin>

        </plugins>

    </build>

场景一：常量转换

这是最简单的一个场景，比如需要设置字符串、整形和长整型的常量，有的又需要日期，或者新建类型。下面举个例子，演示如何转换

//实体类

@Data

public class Source {

    private String stringProp;

    private Long longProp;

}

@Data

public class Target {

    private String stringProperty;

    private long longProperty;

    private String stringConstant;

    private Integer integerConstant;

    private Long  longWrapperConstant;

    private Date dateConstant;

}

• 设置字符串常量


• 设置long常量


• 设置java内置类型默认值，比如date

那么mapper这么设置就可以

@Mapper(componentModel = MappingConstants.ComponentModel.SPRING)

public interface SourceTargetMapper {



    @Mapping(target = "stringProperty", source = "stringProp", defaultValue = "undefined")

    @Mapping(target = "longProperty", source = "longProp", defaultValue = "-1l")

    @Mapping(target = "stringConstant", constant = "Constant Value")

    @Mapping(target = "integerConstant", constant = "14")

    @Mapping(target = "longWrapperConstant", constant = "3001L")

    @Mapping(target = "dateConstant", dateFormat = "yyyy-MM-dd", constant = "2023-09-")

    Target sourceToTarget(Source s);

}

解释下，constant用来设置常量值，source的值如果没有设置，则会使用defaultValue的值，日期可以按dateFormat解析。

Talk is cheap, show me the code !废话不多说，自动生成的转换类如下：

@Component

public class SourceTargetMapperImpl implements SourceTargetMapper {

    public SourceTargetMapperImpl() {

    }



    public Target sourceToTarget(Source s) {

        if (s == null) {

            return null;

        } else {

            Target target = new Target();

            if (s.getStringProp() != null) {

                target.setStringProperty(s.getStringProp());

            } else {

                target.setStringProperty("undefined");

            }



            if (s.getLongProp() != null) {

                target.setLongProperty(s.getLongProp());

            } else {

                target.setLongProperty(-1L);

            }



            target.setStringConstant("Constant Value");

            target.setIntegerConstant(14);

            target.setLongWrapperConstant(3001L);



            try {

                target.setDateConstant((new SimpleDateFormat("dd-MM-yyyy")).parse("09-01-2014"));

                return target;

            } catch (ParseException var4) {

                throw new RuntimeException(var4);

            }

        }

    }

}

是不是一目了然

场景二：转换中调用表达式

比如id不存在使用UUID生成一个，或者使用已有参数新建一个对象作为属性。当然可以用after mapping，qualifiedByName等实现，感觉还是不够优雅，这里介绍个雅的（代码少点的）。

实体类如下：

@Data

public class CustomerDto {

    public Long id;

    public String customerName;



    private String format;

    private Date time;

}

@Data

public class Customer {

    private String id;

    private String name;

    private TimeAndFormat timeAndFormat;

}

@Data

public class TimeAndFormat {

    private Date time;

    private String format;



    public TimeAndFormat(Date time, String format) {

        this.time = time;

        this.format = format;

    }

}

Dto转customer，加创建TimeAndFormat作为属性，mapper实现如下：

@Mapper(componentModel = MappingConstants.ComponentModel.SPRING, imports = UUID.class)

public interface CustomerMapper {



    @Mapping(target = "timeAndFormat",

            expression = "java( new TimeAndFormat( s.getTime(), s.getFormat() ) )")

    @Mapping(target = "id", source = "id", defaultExpression = "java( UUID.randomUUID().toString() )")

    Customer toCustomer(CustomerDto s);



}

解释下，id为空则走默认的defaultExpression，通过imports引入，java括起来调用。新建对象直接new TimeAndFormat。有的小伙伴喜欢用qualifiedByName自定义方法，可以对比下，哪个合适用哪个，都能调用转换方法。

生成代码如下：

@Component

public class CustomerMapperImpl implements CustomerMapper {

    public CustomerMapperImpl() {

    }



    public Customer toCustomer(CustomerDto s) {

        if (s == null) {

            return null;

        } else {

            Customer customer = new Customer();

            if (s.getId() != null) {

                customer.setId(String.valueOf(s.getId()));

            } else {

                customer.setId(UUID.randomUUID().toString());

            }



            customer.setTimeAndFormat(new TimeAndFormat(s.getTime(), s.getFormat()));

            return customer;

        }

    }

}

场景三：类共用属性，如何复用

比如下面的Bike和车辆类，都有id和creationDate属性，我又不想重复写mapper属性注解

public class Bike {

    /**

     * 唯一id

     */

    private String id;



    private Date creationDate;



    /**

     * 品牌

     */

    private String brandName;

}



public class Car {

    /**

     * 唯一id

     */

    private String id;



    private Date creationDate;

    /**

     * 车牌号

     */

    private String chepaihao;

 }

解决起来很简单，写个共用的注解，使用的时候引入就可以，示例如下：

//通用注解

@Retention(RetentionPolicy.CLASS)

//自动生成当前日期

@Mapping(target = "creationDate", expression = "java(new java.util.Date())")

//忽略id

@Mapping(target = "id", ignore = true)

public @interface ToEntity { }



//使用

@Mapper(componentModel = MappingConstants.ComponentModel.SPRING)

public interface TransportationMapper {

    @ToEntity

    @Mapping( target = "brandName", source = "brand")

    Bike map(BikeDto source);



    @ToEntity

    @Mapping( target = "chepaihao", source = "plateNo")

    Car map(CarDto source);

}

这里Retention修饰ToEntity注解，表示ToEntity注解被保留到class文件，但jvm加载class文件时候被遗弃，这是默认的生命周期，辅助生成mapper实现类。上面定义了creationDate和id的转换规则,新建日期，忽略id。

生成的mapper实现类如下：

@Component

public class TransportationMapperImpl implements TransportationMapper {

    public TransportationMapperImpl() {

    }



    public Bike map(BikeDto source) {

        if (source == null) {

            return null;

        } else {

            Bike bike = new Bike();

            bike.setBrandName(source.getBrand());

            bike.setCreationDate(new Date());

            return bike;

        }

    }



    public Car map(CarDto source) {

        if (source == null) {

            return null;

        } else {

            Car car = new Car();

            car.setChepaihao(source.getPlateNo());

            car.setCreationDate(new Date());

            return car;

        }

    }

}

坚持一下，还剩俩场景，剩下的俩更有意思

场景四：lombok和mapstruct冲突了

啥冲突？用了builder注解后，mapstuct转换不出来了。哎，这个问题困扰了我那同事两天时间。

解决方案如下：

 <dependency>

            <groupId>org.projectlombok</groupId>

            <artifactId>lombok-mapstruct-binding</artifactId>

            <version>0.2.0</version>

 </dependency>

加上lombok-mapstruct-binding就可以了，看下生成的效果：

@Builder

@Data

public class Person {

    private String name;

}

@Data

public class PersonDto {

    private String name;

}

@Mapper(componentModel = MappingConstants.ComponentModel.SPRING)

public interface PersonMapper {



    Person map(PersonDto dto);

}

@Component

public class PersonMapperImpl implements PersonMapper {

    public PersonMapperImpl() {

    }



    public Person map(PersonDto dto) {

        if (dto == null) {

            return null;

        } else {

            Person.PersonBuilder person = Person.builder();

            person.name(dto.getName());

            return person.build();

        }

    }

}

从上面可以看到，mapstruct匹配到了lombok的builder方法。

场景五：说个难点的，转换的时候，如何注入springBean

有时候转换方法比不是静态的，他可能依赖spring bean，这个如何导入？

这个使用需要使用抽象方法了，上代码：

@Component

public class SimpleService {

    public String formatName(String name) {

        return  "您的名字是：" + name;

    }

}

@Data

public class Student {

    private String name;

}

@Data

public class StudentDto {

    private String name;

}

@Mapper(componentModel = MappingConstants.ComponentModel.SPRING)

public abstract class StudentMapper {



    @Autowired

    protected SimpleService simpleService;



    @Mapping(target = "name", expression = "java(simpleService.formatName(source.getName()))")

    public abstract StudentDto map(StudentDto source);

}

接口是不支持注入的，但是抽象类可以，所以采用抽象类解决，后面expression直接用皆可以了，生成mapperimpl如下：

@Component

public class StudentMapperImpl extends StudentMapper {

    public StudentMapperImpl() {

    }



    public StudentDto map(StudentDto source) {

        if (source == null) {

            return null;

        } else {

            StudentDto studentDto = new StudentDto();

            studentDto.setName(this.simpleService.formatName(source.getName()));

            return studentDto;

        }

    }

}

思考

以上场景肯定还有其他解决方案，遵循合适的原则就可以。驾驭不了的代码，可能带来更多问题，先简单实现，后续在迭代优化可能适合更多的业务场景。

本文示例代码放在了github，需要的朋友请关注公众号大鱼七成饱,回复关键词MapStruct使用即可获得。

背景

最近在使用拼多多购物，除了价格比较香之外，每次冷启打开的体验非常好，作为一个Android开发不免好奇 简单分析记录一下

冷启数据

体验好，让我想到了郭德纲的那句话"全靠同行的衬托",那找几个同行过来对比下，这里使用淘宝、京东、闲鱼，从点击开始图标开始录个屏直接数秒，

测试手机是 华为 Mate 60

我这个样本比较少，机器性能也比较好，仅仅是个人对比，不代表大众使用的真实情况

可以粗略的看几个常见app的冷启对比下，这里录屏使用的剪映来分析
帧率为 每秒30帧，后面会涉及一些时间换算

拼多多

无广告冷启动 从点击图标到到首页完整展示 大概花了 29帧，
1000ms * 29/30 约为 0.96s
，太惊人了，基本冷启秒开

拼多多可能真的没有开屏广告，我印象中没有见过拼多多的开屏广告

淘宝

无广告冷启东 从点击图标到到首页完整展示


大概花了 1s+21帧，
1000ms+ 21/30*1000ms = 1.7s
还可以

淘宝可能没有开屏广告，或者非常克制，我刷了十几次都没有见到开屏广告

京东

无广告冷启京东
从点击图标到到首页完整展示

大概花了 1s+28帧，
1000ms + 28/30*1000ms 约为 1.93s
也是不错的

不过京东的开屏有开屏广告，但是做了用户频控，刷了几次就没了，这里仅对比无广告冷启开屏

闲鱼

毕竟是国内最大的二手平台（虽然现在小商家也特别多），而且是flutter深度使用者，看看它的表现


大概花了** 2s+10帧**
2000ms+ 10/30*1000ms 约为 2.3s

从上面数据来看，怪不得 我使用拼多多之后，打开app 确实比较舒服，因为我就是奔着买东西去的，越快到购物页面越舒服的。或许这就是极致的用户体验吧

首屏细节

拼多多的首页数据咋这么快就准备好了，网络耗时应该也有呢，应该是它提前准备好了数据

我们来实操验证下

• 切后台的截图

我们记住 手枪、去虾线、行李箱、停电 这几个卡片

冷启打开之后首先展示的是 还是切后台之前的数据

紧接着网络数据到了做了一次屏幕刷新

到这里大概就明白了，冷启使用上次feeds流的数据，先让用户看到数据，然后等新数据请求到之后再刷新页面就好

为了严谨点，把缓存数据清除的话，那么肯定首次冷启白屏，ok最后再验证一下

此时冷启白茫茫的一片，看来拼多多的策略还是让用户尽快进应用优先，或者这里并没有刻意设计🤔，都是先进首页有缓存就使用 没有的话就等网络数据，毕竟这种情况也只是新用户或者缓存数据过期才会这样

因此这里我可以得出把这种缓存优先的技术方案也可以学习学习，看看我们自己的app是不是可以复用一下，绩效这不就来了吗🤔
首页 = 数据 + UI
数据是使用缓存，UI也能吧一些UI组件提前预加载，不过这里也无法判断 是否预加载了首页UI🤔

开屏无广告

我目前在字节就是搞广告的，所以对广告稍微敏感些，开屏广告是一个很棒收入来源，特别是合约广告这种，之前应用冷启时间长，有时候其实是故意抽出一些时间来等待冷启的开屏广告，
但是我试了很多次，确实没看过拼多多的开屏广告，不过从这个结果来看 肯定是 经过严密的ab实验，不过拼多多在开屏广告上确实比较克制，

关于现在互联网的计算广告业务还是蛮有意思的比如 广告类型有 开屏、原生、激励、插屏、横幅，sdk类型有单个adn或者聚合广告sdk，有时间再单独分享几篇。

冷启优化一些常见手段

冷启动往往是大型应用的必争之地

拼多多技术是应该是有些东西的，但是非常低调，属于人狠话不多那种，也没找到他们的方案。这里结合自身经验聊聊这块，主要是以下4个阶段结合技术手段做优化

Application attachBaseContext

这个阶段由于 Applicaiton Context 赋值等问题，一般不会有太多的业务代码，可能的耗时会在低版本机器4.x机器比较多，首次由于MultiDex.install耗时

dex 的指令格式设计并不完善，单个 dex 文件中引用的 Java 方法总数不能超过 65536 个，在方法数超过 65536 的情况下，将拆分成多个 dex。一般情况下 Dalvik 虚拟机只能执行经过优化后的 odex 文件，在 4.x 设备上为了提升应用安装速度，其在安装阶段仅会对应用的首个 dex 进行优化。对于非首个 dex 其会在首次运行调用 MultiDex.install 时进行优化，而这个优化是非常耗时的，这就造成了 4.x 设备上首次启动慢的问题。

可以使用一些开源方案，比如 github.com/bytedance/B…
不过 这里优化难度比较大，roi的话 看看app低版本的机型占比再做决定

ContentProvider

这里要注意检查 ContentProvider，特别是一些sdk在 AndroidManifest 里面注册了自己的 xxSDkProvider，然后在 xxSDkProvider 的 onCreate 方面里面进行初始化，确实调用者不需要自己初始化了，可却增加了启动耗时，
我们可以打开 Apk，看一下最终merge的 AndroidManiest 里面有多少 provider，看一下是否有这样的骚操作，往往这里容易忽视，这种情况可以使用谷歌App Startup来收敛ContentProvider

Application 优化

西瓜视频 在冷启优化就将 push、小程序、sandboxed这几个进程做了优化拿到一些不错的收益mp.weixin.qq.com/s/v23jEhF9k…

搞进程难度大风险高

3. 启动链路任务编排

在 Spring Boot 框架中，内置了许多实用的功能，这些功能可以帮助开发者高效地开发和维护应用程序。

松哥来和大家列举几个。

一 请求数据记录

Spring Boot提供了一个内置的日志记录解决方案，通过 AbstractRequestLoggingFilter 可以记录请求的详细信息。

AbstractRequestLoggingFilter 有两个不同的实现类，我们常用的是 CommonsRequestLoggingFilter。

通过 CommonsRequestLoggingFilter 开发者可以自定义记录请求的参数、请求体、请求头和客户端信息。

启用方式很简单，加个配置就行了：

@Configuration

public class RequestLoggingConfig {

    @Bean

    public CommonsRequestLoggingFilter logFilter() {

        CommonsRequestLoggingFilter filter = new CommonsRequestLoggingFilter();

        filter.setIncludeQueryString(true);

        filter.setIncludePayload(true);

        filter.setIncludeHeaders(true);

        filter.setIncludeClientInfo(true);

        filter.setAfterMessagePrefix("REQUEST ");

        return filter;

    }

}

接下来需要配置日志级别为 DEBUG，就可以详细记录请求信息：

logging.level.org.springframework.web.filter.CommonsRequestLoggingFilter=DEBUG

二 请求/响应包装器

2.1 什么是请求和响应包装器

在 Spring Boot 中，请求和响应包装器是用于增强原生 HttpServletRequest 和 HttpServletResponse 对象的功能。这些包装器允许开发者在请求处理过程中拦截和修改请求和响应数据，从而实现一些特定的功能，如请求内容的缓存、修改、日志记录，以及响应内容的修改和增强。

请求包装器

• ContentCachingRequestWrapper：这是 Spring 提供的一个请求包装器，用于缓存请求的输入流。它允许多次读取请求体，这在需要多次处理请求数据（如日志记录和业务处理）时非常有用。

响应包装器

• ContentCachingResponseWrapper：这是 Spring 提供的一个响应包装器，用于缓存响应的输出流。它允许开发者在响应提交给客户端之前修改响应体，这在需要对响应内容进行后处理（如添加额外的头部信息、修改响应体）时非常有用。

2.2 使用场景

2.3 具体用法

请求包装器的使用

import org.springframework.web.filter.OncePerRequestFilter;

import javax.servlet.FilterChain;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import java.io.IOException;



@Component

public class RequestWrapperFilter extends OncePerRequestFilter {

    @Override

    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)

            throws ServletException, IOException {

        ContentCachingRequestWrapper requestWrapper = new ContentCachingRequestWrapper(request);

        // 可以在这里处理请求数据

        byte[] body = requestWrapper.getContentAsByteArray();

        // 处理body，例如记录日志

        //。。。

        filterChain.doFilter(requestWrapper, response);

    }

}

响应包装器的使用

import org.springframework.web.filter.OncePerRequestFilter;

import javax.servlet.FilterChain;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import java.io.IOException;



@Component

public class ResponseWrapperFilter extends OncePerRequestFilter {

    @Override

    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)

            throws ServletException, IOException {

        ContentCachingResponseWrapper responseWrapper = new ContentCachingResponseWrapper(response);

        filterChain.doFilter(request, responseWrapper);



        // 可以在这里处理响应数据

        byte[] body = responseWrapper.getContentAsByteArray();

        // 处理body，例如添加签名

        responseWrapper.setHeader("X-Signature", "some-signature");



        // 必须调用此方法以将响应数据发送到客户端

        responseWrapper.copyBodyToResponse();

    }

}

在上面的案例中，OncePerRequestFilter 确保过滤器在一次请求的生命周期中只被调用一次，这对于处理请求和响应数据尤为重要，因为它避免了在请求转发或包含时重复处理数据。

通过使用请求和响应包装器，开发者可以在不改变原有业务逻辑的情况下，灵活地添加或修改请求和响应的处理逻辑。

三 单次过滤器

3.1 OncePerRequestFilter

OncePerRequestFilter 是 Spring 框架提供的一个过滤器基类，它继承自 Filter 接口。这个过滤器具有以下特点：

3.2 OncePerRequestFilter 使用场景

通过使用 OncePerRequestFilter，开发者可以确保过滤器逻辑在一次请求的生命周期内只执行一次，从而避免重复处理和潜在的性能问题。这使得 OncePerRequestFilter 成为处理复杂请求和响应逻辑时的一个非常有用的工具。

OncePerRequestFilter 的具体用法松哥就不举例了，第二小节已经介绍过了。

四 AOP 三件套

在 Spring 框架中，AOP（面向切面编程）是一个强大的功能，它允许开发者在不修改源代码的情况下，对程序的特定部分进行横向切入。AopContext、AopUtils 和 ReflectionUtils 是 Spring AOP 中提供的几个实用类。

我们一起来看下。

4.1 AopContext

AopContext 是 Spring 框架中的一个类，它提供了对当前 AOP 代理对象的访问，以及对目标对象的引用。

AopContext 主要用于获取当前代理对象的相关信息，以及在 AOP 代理中进行一些特定的操作。

常见方法有两个：

• getTargetObject(): 获取当前代理的目标对象。


• currentProxy(): 获取当前的代理对象。

其中第二个方法，在防止同一个类中注解失效的时候，可以通过该方法获取当前类的代理对象。

举个栗子：

public void noTransactionTask(String keyword){    // 注意这里 调用了代理类的方法

    ((YourClass) AopContext.currentProxy()).transactionTask(keyword);

}



@Transactional

void transactionTask(String keyword) {

    try {

        Thread.sleep(5000);

    } catch (InterruptedException e) {        //logger

        //error tracking

    }

    System.out.println(keyword);

}

同一个类中两个方法，noTransactionTask 方法调用 transactionTask 方法，为了使事务注解不失效，就可以使用 AopContext.currentProxy() 去获取当前代理对象。

4.2 AopUtils

AopUtils 提供了一些静态方法来处理与 AOP 相关的操作，如获取代理对象、获取目标对象、判断代理类型等。

常见方法有三个：

• getTargetObject(): 从代理对象中获取目标对象。


• isJdkDynamicProxy(Object obj): 判断是否是 JDK 动态代理。


• isCglibProxy(Object obj): 判断是否是 CGLIB 代理。

举个栗子：

import org.springframework.aop.framework.AopProxyUtils;

import org.springframework.aop.support.AopUtils;



public class AopUtilsExample {

    public static void main(String[] args) {

        MyService myService = ...

        // 假设 myService 已经被代理

        if (AopUtils.isCglibProxy(myService)) {

            System.out.println("这是一个 CGLIB 代理对象");

        }

    }

}

4.3 ReflectionUtils

ReflectionUtils 提供了一系列反射操作的便捷方法，如设置字段值、获取字段值、调用方法等。这些方法封装了 Java 反射 API 的复杂性，使得反射操作更加简单和安全。

常见方法：

• makeAccessible(Field field): 使私有字段可访问。


• getField(Field field, Object target): 获取对象的字段值。


• invokeMethod(Method method, Object target, Object... args): 调用对象的方法。

举个栗子：

import org.springframework.util.ReflectionUtils;



import java.lang.reflect.Field;

import java.util.Map;



public class ReflectionUtilsExample {

    public static void main(String[] args) throws Exception {

        ExampleBean bean = new ExampleBean();

        bean.setMapAttribute(new HashMap<>());



        Field field = ReflectionUtils.findField(ExampleBean.class, "mapAttribute");

        ReflectionUtils.makeAccessible(field);



        Object value = ReflectionUtils.getField(field, bean);

        System.out.println(value);

    }



    static class ExampleBean {

        private Map<String, String> mapAttribute;



        public void setMapAttribute(Map<String, String> mapAttribute) {

            this.mapAttribute = mapAttribute;

        }

    }

}

还有哪些实用内置类呢？欢迎小伙伴们留言～

首先感谢
Vue3 封装不定高虚拟列表 hooks，复用性更好！这篇文章提供的一些思路，在此基础作者进一步对相关代码进行了一些性能上的优化（解决了通过鼠标操作滚动条时的卡顿）。因为项目没有用到ts，就先去掉了。

hooks

import { ref, onMounted, onBeforeUnmount, watch, nextTick } from "vue";



export default function useVirtualList(config) {

  // 获取元素

  let actualHeightContainerEl = null,

    translateContainerEl = null,

    scrollContainerEl = null;

  // 数据源，便于后续直接访问

  let dataSource = [];



  onMounted(() => {

    actualHeightContainerEl = document.querySelector(

      config.actualHeightContainer

    );

    scrollContainerEl = document.querySelector(config.scrollContainer);

    translateContainerEl = document.querySelector(config.translateContainer);

  });



  // 数据源发生变动

  watch(

    () => config.data.value,

    (newValue) => {

      // 更新数据源

      dataSource = newValue;

      // 计算需要渲染的数据

      updateRenderData();

    }

  );



  /* 

  

  

  

    更新相关逻辑

  

  

  

  */

  // 更新实际高度

  let flag = false;

  const updateActualHeight = (oldValue, value) => {

    let actualHeight = 0;

    if (flag) {

      // 修复偏差

      actualHeight =

        actualHeightContainerEl.offsetHeight -

        (oldValue || config.itemHeight) +

        value;

    } else {

      // 首次渲染

      flag = true;

      for (let i = 0; i < dataSource.length; i++) {

        actualHeight += getItemHeightFromCache(i);

      }

    }

    actualHeightContainerEl.style.height = `${actualHeight}px`;

  };



  // 缓存已渲染元素的高度

  const RenderedItemsCache = {};

  const RenderedItemsCacheProxy = new Proxy(RenderedItemsCache, {

    get(target, key, receiver) {

      return Reflect.get(target, key, receiver);

    },

    set(target, key, value, receiver) {

      const oldValue = target[key];

      const result = Reflect.set(target, key, value, receiver);

      // 更新实际高度

      updateActualHeight(oldValue, value);

      return result;

    },

  });



  // 更新已渲染列表项的缓存高度

  const updateRenderedItemCache = (index) => {

    // 当所有元素的实际高度更新完毕，就不需要重新计算高度

    const shouldUpdate =

      Reflect.ownKeys(RenderedItemsCacheProxy).length < dataSource.length;

    if (!shouldUpdate) return;



    nextTick(() => {

      // 获取所有列表项元素(size条数)

      const Items = Array.from(document.querySelectorAll(config.itemContainer));

      // 进行缓存（通过下标作为key)

      for (let i = 0; i < Items.length; i++) {

        const el = Reflect.get(Items, i);

        const itemIndex = index + i;

        if (!Reflect.get(RenderedItemsCacheProxy, itemIndex)) {

          Reflect.set(RenderedItemsCacheProxy, itemIndex, el.offsetHeight);

        }

      }

    });

  };



  // 获取缓存高度，无缓存，取配置项的 itemHeight

  const getItemHeightFromCache = (index) => {

    const val = Reflect.get(RenderedItemsCacheProxy, index);

    return val === void 0 ? config.itemHeight : val;

  };



  // 实际渲染的数据

  const actualRenderData = ref([]);



  // 更新实际渲染数据

  const updateRenderData = (scrollTop = 0) => {

    let startIndex = 0;

    let offsetHeight = 0;



    for (let i = 0; i < dataSource.length; i++) {

      offsetHeight += getItemHeightFromCache(i);



      // 第几个以上进行隐藏

      if (offsetHeight >= scrollTop - (config.offset || 0)) {

        startIndex = i;

        break;

      }

    }

    // 计算得出的渲染数据

    actualRenderData.value = dataSource

      .slice(startIndex, startIndex + config.size)

      .map((data, idx) => {

        return {

          key: startIndex + idx + 1, // 为了在vue的for循环中绑定唯一key值

          data,

        };

      });



    // 缓存最新的列表项高度

    updateRenderedItemCache(startIndex);



    updateOffset(offsetHeight - getItemHeightFromCache(startIndex));

  };



  // 更新偏移值

  const updateOffset = (offset) => {

    translateContainerEl.style.transform = `translateY(${offset}px)`;

  };



  /* 

  

  

  

    注册事件、销毁事件

  

  

  

  */

  // 滚动事件

  const handleScroll = (e) =>

    // 渲染正确的数据

    updateRenderData(e.target.scrollTop);



  // 注册滚动事件

  onMounted(() => {

    scrollContainerEl?.addEventListener("scroll", handleScroll);

  });



  // 移除滚动事件

  onBeforeUnmount(() => {

    scrollContainerEl?.removeEventListener("scroll", handleScroll);

  });



  return { actualRenderData };

}

vue

<script setup>

import { ref } from "vue";

import useVirtualList from "../utils/useVirtualList.js"; // 上面封装的hooks文件

import list from "../json/index.js"; // 造的数据模拟

const tableData = ref([]);

// 模拟异步请求

setTimeout(() => {

  tableData.value = list;

}, 0);

const { actualRenderData } = useVirtualList({

  data: tableData, // 列表项数据

  scrollContainer: ".scroll-container", // 滚动容器

  actualHeightContainer: ".actual-height-container", // 渲染实际高度的容器

  translateContainer: ".translate-container", // 需要偏移的目标元素,

  itemContainer: ".item", // 列表项

  itemHeight: 400, // 列表项的大致高度

  size: 10, // 单次渲染数量

  offset: 200, // 偏移量

});

</script>



<template>

  <div>

    <h2>virtualList 不固定高度虚拟列表</h2>

    <ul class="scroll-container">

      <div class="actual-height-container">

        <div class="translate-container">

          <li

            v-for="item in actualRenderData"

            :key="item.key"

            class="item"

            :class="[{ 'is-odd': item.key % 2 }]"

          >

            <div class="item-title">第{{ item.key }}条：</div>

            <div>{{ item.data }}</div>

          </li>

        </div>

      </div>

    </ul>

  </div>

</template>



<style scoped>

* {

  list-style: none;

  padding: 0;

  margin: 0;

}

.scroll-container {

  border: 1px solid #000;

  width: 1000px;

  height: 200px;

  overflow: auto;

}

.item {

  border: 1px solid #ccc;

  padding: 20px;

  display: flex;

  flex-wrap: wrap;

  word-break: break-all;

}

.item.is-odd {

  background-color: rgba(0, 0, 0, 0.1);

}

</style>

大家好，我是徐徐。今天和大家谈谈我做 Electron 桌面端应用的这一两年，把一些经验和想法分享给大家。

前言

入职现在这家公司三年了，刚进公司的时候是 21 年年初，那时候会做一些稍微复杂的后台管理系统以及一些简单的 C 端 SDK。准备开始做 Electron 项目是因为我所在的是安全部门，急需一款桌面管控软件来管理（监控）员工的电脑安全以及入网准入，可以理解为一款零信任的桌面软件。其实之前公司也有一款安全管控的软件，但是Windows 和 Mac是分端构建的，而且维护成本极高，Windows 是使用的 C#, Mac 是用的 Objective-C，开发和发版效率低下，最后在研发老大的同意下，我和另外一个同事开始研究如何用 Electron 这个框架来做一款桌面端软件。

我们发起这个项目大概是在 21 年年底，Windows 版本上线是在上海疫情封城期间，2022年4月份的时候，疫情结束后由于事业部业务方向的调整，又被抽调到了另外一个组去做一个 C 端的创业项目，后面项目结束了，又回来做 Electron 相关的工作直到现在，之所以是一两年，其实就是这个时间线。

对桌面端开发的一些看法

如果你是前端的话，多一门桌面端开发的技能也不是坏事，相当是你的一个亮点，进可攻，退可守。因为桌面端开发到后期的架构可以非常的复杂，不亚于服务端（chromium 就是一个例子），当然也取决于你所应对的场景的挑战，如果所做的产品跟普通前端无异，那也不能说是一个亮点，但是如果你的工作已经触及到一些操作系统的底层，那肯定是一个亮点。

当然也有人说，做桌面端可能就路越走越窄了，但是我想说的是深度和广度其实也可以理解为一个维度，对于技术人来说，知道得越多就行，因为到后期你要成为某个方面的专家，就是可能会非常深入某一块，换一种思路其实也是叫知道得越多。所以，我觉得前端能有做桌面端的机会也是非常好的，即拓展了自己的技能，还能深入底层，因为现阶段由于业务方向的需要，我已经开始看 chromium 源码了，前端的老祖宗。当然，以上这些只代表自己的观点，大家自行斟酌。

谈谈 Electron

其实刚刚工作前两年我就知道这个框架了，当时也做过小 demo，而且还在当时的团队里面分享过这个技术，但是当时对这门技术的认知是非常浅薄的，就知道前端可以做桌面端了，好厉害，大概就停留在这个层面。后面在真正需要用到这门技术去做一个企业级的桌面应用的时候才去真正调研了一下这个框架，然后才发现它真的非常强大，强大到几乎可以实现你桌面端的任何需求。网上关于 Electron 与其他框架的对比实在是太多了，Google 或者 Baidu 都能找到你想要的答案，好与不好完全看自己的业务场景以及自己所在团队的情况。

谈谈自己的感受，什么情况下可以用这门框架

• 追求效率，节省人力财力


• 团队前端居多


• UI交互多

什么情况下不适合这门框架呢？

• 包体积限制


• 性能消耗较高的应用


• 多窗口应用

我们当时的情况就是要追求效率，双端齐头并进，所以最后经过综合对比，选择了 Electron。毕竟 Vscode 就是用它做的，给了我们十足的信心和勇气，一点都不虚。

一图抵千字，我拿出这张图你自己就有所判断了，还是那句话，仁者见仁，智者见智，完全看自己情况。

图片来源：http://www.electronjs.org/apps

技术整体架构

这里我画了一张我所从事 Electron 产品的整体技术架构图。

整个项目基于 Vite 开发构建的，基础设施就是常见的安全策略，然后加上一些本地存储方案，外加一个外部插件，这个插件是用 Tauri 做的 Webview，至于为什么要做这个插件我会在后面的段落说明。应用层面的框架主要是分三个大块，下面主要是为了构建一些基础底座，然后将架构进行分层设计，添加一些原生扩展，上面就是基础的应用管理和 GUI 相关的东西，有了这个整体的框架在后面实现一些业务场景的时候就会变得易如反掌（夸张了一点，因为有的技术细节真的很磨人😐）。

当然这里只是一个整体的架构图，其实还有很多技术细节的流程图以及业务场景图并没有在这里体现出来，不过我也会挑选一些方案在后面的篇幅里面做出相应的讲解。

挑战和方案

桌面端开发会遇到一些挑战，这些挑战大部分来源于特殊的业务场景，框架只能解决一些比较常见的应用场景，当然不仅仅是桌面端，其实移动端或者是 Web 端我相信大家都会遇到或多或少的挑战，我这里遇到的一些挑战和响应的方案不一定适合你，只是做单纯的记录分享，如果有帮助到你，我很开心。下面我挑选软件升级更新，任务队列设计，性能检测优化以及一些特殊的需求这几个方面来聊聊相应的挑战和方案。

软件升级更新

桌面端的软件更新升级是桌面端开发中非常重要的一环，一个好的商业产品必须有稳定好用的解决方案。桌面端的升级跟 C 端 App 的升级其实也是差不多的思路，虽然我所做的产品是公司内部人使用，但是用户也是你面向公司所有用户的，所以跟 C 端产品的解决思路其实是无异的。

升级更新主要是需要做到定向灰度。这个功能是非常重要的，应该大部分的应用都有定向灰度的功能，所以我们为了让软件能够平滑升级，第一步就是实现定向灰度，达到效果可回收，性能可监控，错误可告警的目的。定向更新的功能实现了之后，后面有再多的功能需要实现都有基础保障了，下面是更新相关的能力图。

整个更新模块的设计是分为两大块，一块是后台管理系统，一块是客户端。后台管理系统主要是维护相应的策略配置，比如哪些设备需要定向更新，哪些需要自动更新，不需要更新的白名单以及更新后是需要提醒用户相应的更新功能还是就静默更新。客户端主要就是拉取相应的策略，然后执行相应的更新动作。

由于我们的软件是比较特殊的一个产品，他是需要长期保活的，Mac 端上了文件锁是无法删除的。所以我们在执行更新的时候和常规的软件更新是不一样的，软件的更新下载是利用了 electron-update 相应的钩子，但是安装的时候并没有使用相应的钩子函数，而是自己研究了 electron 的更新源码后做了自己的更新脚本。 因为electron 的更新它自己也会注册一个保活的更新任务的服务，但是这个和我们的文件锁和保活是冲突的，所以是需要禁用掉它的保活服务，完成自己的更新。

整体来说，这一块是花了很多时间去研究的，windows 还好，没有破坏其整个生命周期，傻瓜式的配置一下electron-update 相关的函数钩子就可以了。Mac 的更新花了很多时间，因为破坏了文件的生命周期，再加上保活任务，所以会对 electron-update 的更新钩子进行毁灭性的破坏，最后也只能研究其源码然后自己去实现特殊场景下的更新了。

任务队列设计

任务模块的实现在我们这个软件里面也是非常重要的一环，因为客户端会跑非常多的定时任务。刚开始研发这个产品的时候其实还好，定时任务屈指可数，但是随着长时间的迭代，端上要执行的任务越来越多，每个任务的触发时间，触发条件都不一样，以及还要考虑任务的并发情况和对性能的影响，所以在中后期我们对整个任务模块都做了相应的改造。

下面是整个任务模块的核心能力图。

业界也有一些任务相关的开源工具包，比如 node-schedule、node-cron、cron，这些都是很优秀的库，但是我在使用过程中发现他们好像不具备并发限制的场景，比如有很多任务我们在开始设置的时候都会有个时间间隔，这些任务的时间间隔都是可以在后台随意配置的，如果端上不做并发限制会导致一个问题，就是用户某一瞬间会觉得电脑非常卡。

比如你有 4 个 10 分钟间隔的任务 和 2 个五分钟间隔的任务，那么到某一个时间段，他最大并发可能就是 6，如果刚好这 6 个任务都是非常耗费 CPU 的任务，那他们一起执行的时候就会导致整个终端CPU 飙升，导致用户感觉卡顿，这样就会收到相应的 Diss。

安全类的软件产品其实有的时候不需要太过醒目，后台默默运行就行，所以我们的宗旨就是稳定运行，不超载。为此我们就自己实现了相应的任务队列模式，然后去控制任务并发。其实底层逻辑也不难，就是一个 setInterval 的函数，然后不断的创建销毁，读取队列的函数，执行相应的函数。

性能优化

Electron相关的性能优化其实网上也有非常多的文章，我这里说说我的实践和感受。

首先，性能优化你需要优化什么？这个就是你的出发点了，我们要解决一个问题，首先得知道问题的现状，如果你都不知道现在的性能是什么样子，如何去优化呢？所以发现问题是性能优化的最重要的一步。

这里就推荐两个工具，一个是chrome dev-tool，一个是electron 的 inspector，第一个可以观测渲染进程相关的性能情况，第二个可以观测主进程相关的性能情况。

具体可参考以下网址：

• developer.chrome.com/docs/devtoo…


• http://www.electronjs.org/zh/docs/lat…

有了工具之后我们就需要用工具去分析一些数据和问题，这里面最重要的就是内存相关的分析，你通过内存相关的分析可以看到 CPU 占用高的动作，以及提前检测出内存泄漏的风险。只要把这两个关键的东西抓住了，应用的稳定性就可以得到保障了，我的经验就是每次发布之前都会跑一遍内存快照，内存没有异常才进行发布动作，内存泄漏是最后的底线。

我说说我大概的操作步骤。

• 通过Performance确认大体的溢出位置


• 使用Memory进行细粒度的问题分析


• 根据heap snapshot，判断内存溢出的代码位置


• 调试相应的代码块


• 循环往复上面的步骤

上面的步骤在主进程和渲染进程都适用，每一步实际操作在这里就不详细展开了，主要是提供一个思路和方法，因为 dev-tool 的面板东西非常多，扩展开来都可以当一个专题了。

然后我再说说桌面端什么地方可能会内存泄漏或者溢出，下面这些都是我血和泪的教训。

• 创建的子进程没有及时销毁：

如果子进程在完成任务后未被正确终止，这些进程会继续运行并占用系统资源，导致内存泄漏和资源浪费。

假设你的 Electron 应用启动了一个子进程来执行某些计算任务，但在计算完成后未调用
childProcess.kill() 或者未确保子进程已正常退出，那么这些子进程会一直存在，占用系统内存。

const { spawn } = require('child_process');

const child = spawn('someCommand');



child.on('exit', () => {

    console.log('Child process exited');

});



// 未正确终止子进程可能导致内存泄漏

• HTTP 请求时间过长没有正确处理：

长时间未响应的 HTTP 请求如果没有设定超时机制，会使得这些请求占用内存资源，导致内存泄漏。

在使用 fetch 或 axios 进行 HTTP 请求时，如果服务器长时间不响应且没有设置超时处理，内存会被这些未完成的请求占用。

const fetch = require('node-fetch');



fetch('https://example.com/long-request')

    .then(response => response.json())

    .catch(error => console.error('Error:', error));



// 应该设置请求超时

const controller = new AbortController();

const timeout = setTimeout(() => {

    controller.abort();

}, 5000); // 5秒超时



fetch('https://example.com/long-request', { signal: controller.signal })

    .then(response => response.json())

    .catch(error => console.error('Error:', error));

• 事件处理器没有移除

未正确移除不再需要的事件处理器会导致内存一直被占用，因为这些处理器仍然存在并监听事件。

在添加事件监听器后，未在适当时机移除它们会导致内存泄漏。

const handleEvent = () => {

    console.log('Event triggered');

};



window.addEventListener('resize', handleEvent);



// 在不再需要时移除事件监听器

window.removeEventListener('resize', handleEvent);

• 定时任务未被正确销毁

未在适当时候清除不再需要的定时任务（如 setInterval）会导致内存持续占用。

使用 setInterval 创建的定时任务，如果未在不需要时清除，会导致内存泄漏。

const intervalId = setInterval(() => {

    console.log('Interval task running');

}, 1000);



// 在适当时机清除定时任务

clearInterval(intervalId);

• JavaScript 对象未正确释放

长时间保留不再使用的 JavaScript 对象会导致内存占用无法释放，特别是当这些对象被全局变量或闭包引用时。

创建了大量对象但未在适当时机将它们置为 null 或解除引用。

let bigArray = new Array(1000000).fill('data');



// 当不再需要时，应释放内存

bigArray = null;

• 窗口实例未被正确销毁

未关闭或销毁不再使用的窗口实例会继续占用内存资源，即使用户已经关闭了窗口界面。

创建了一个新的 BrowserWindow 实例，但在窗口关闭后未销毁它。

const { BrowserWindow } = require('electron');

let win = new BrowserWindow({ width: 800, height: 600 });



win.on('closed', () => {

    win = null;

});



// 应确保在窗口关闭时正确释放资源

• 大文件或大数据量的处理

处理大文件或大量数据时，如果没有进行内存优化和分批处理，会导致内存溢出和性能问题。

在读取一个大文件时，未采用流式处理，而是一次性加载整个文件到内存中。

const fs = require('fs');



// 不推荐的方式：一次性读取大文件

fs.readFile('largeFile.txt', (err, data) => {

    if (err) throw err;

    console.log(data);

});



// 推荐的方式：流式读取大文件

const readStream = fs.createReadStream('largeFile.txt');

readStream.on('data', (chunk) => {

    console.log(chunk);

});

一些特殊的需求

做这个产品也遇到一些特殊的需求，有的需求还挺磨人的，这里也和大家分享一下。

• 保活和文件锁

作为一个前端，桌面端的保活和文件锁这种需求基本是之前不可能接触到的，为了做这个需求也去了解了一下业界的实现，其实实现都还好，主要是它会带来一些问题，诸如打包构建需要自定义前置脚本和后置脚本，root 用户环境下 mac 端无法输入中文，上面提到的用 Tauri 构建一个 webview 组件就是为了解决 root 用户无法输入中文的场景。

• 静默安装应用

这个需求也是很绝的一个需求。我想如果是做常规的前端开发，估计一般都不会遇到这种需求，你需要从头到尾实现一个下载器，一个软件安装器，而且还要双端适配，不仅如此，还需要实现 exe、zip、dmg、pkg 等各种软件格式的安装，里面包含重试机制，断点下载，队列下载等各种技术细节。当时接到这个需求头也特别大，不过技术方案做出来后感觉也还好，再复杂的需求只要能理清思路，其实都可以慢慢解决。

• VPN 和 访问记录监控

这种需求对一个前端来说更是无从入手，但是好在之前有老版本的 VPN 做参考，就是根据相应的代码翻译一遍也能实现，大部分可以用命令行解决。至于访问记录监控这个玩意咋说呢，客户端做其实也挺费神的，如果不借助第三方的开源框架，自己是非常难实现的，所以这种就是需要疯狂的翻国外的网站，就GitHub，Stackoverflow啰，总有一款适合你，这里就不具体说明了。

• 进程禁用

违规进程禁用其实在安全软件的应用场景是非常常见的，它需要实时性，而且对性能要求很高，一个是不能影响用户正常使用，还要精准杀掉后台配置的违规进程，这个地方其实也是做了很多版优化，但是最后的感觉还是觉得任务队列有性能瓶颈，无法达到要求，现阶段我们也在想用另外的方式去改造，要么就是上全局钩子，要么就是直接把相应的进程文件上锁或者改文件权限。

上面所提到的需求只是一小部例子，还好很多奇奇怪怪的需求没有举例，这些奇怪的需求就像小怪物，不断挑战我的边界，让我也了解和学习和很多奇奇怪怪的知识，有的时候我就会发出这样的感叹：我去，还能这样？

结语

洋洋洒洒，不知不觉已经写了 5000 字了，其实做 Electron 桌面端应用的这一两年自我感觉还是成长了不少，不管是技术方面还是产品设计方面，自己的能力都有所提升。但是同样会遇到瓶颈，就是一个东西一直做一直做，到后面创新会比较难，取得的成就也会慢慢变少。

另外就是安全类的桌面端产品在整个软件开发的里其实是非常冷门的一个领域，他有他的独特性，也有相应的价值，他需要默默的运行，稳定的运行，出问题可以监控到，该提醒的时候提醒用户。你说他低调吧，有时候也挺高调的，真的不好定论，你说没影响力吧，有的时候没他还真不行。让用户不反感这种软件，拥抱这种软件其实挺难的。从一个前端开发的视角来看，桌面端的体验的确很重要，不管是流畅度还是美观度，都不能太差，这也是我们现阶段追求的一个点，就是不断提升用户体验。

路漫漫其修远兮，吾将上下而求索。前端开发这条路的确很长，如果你想朝某个方面深度发展，你会发现边界是非常难触达的，当然也看所处的环境和对应的机遇，就从技术来说的话，前端的天花板也可以很高，不管是桌面端，服务端，移动端，Web端，每个方向前端的天花板都非常难触摸到。

最后，祝大家在自己的领域越来越深，早日触摸到天花板。

原文链接

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

互联网时代，程序员承担着数字世界构建和技术发展的大任，如此重要，为什么存在感不高，社会地位不高呢？

知乎上针对这个问题也有过讨论，分享给大家。

http://www.zhihu.com/question/58…

回答1

什么是社会地位？

社会地位可以简化成，一个人可支配社会资源的数量，例如：

医生 医疗资源

教师 教育资源

...

而程序员可支配的社会资源只有他自己。从这一点上说，程序员和工人没有本质上的区别。

时代的红利成就了这个职业，抛弃它的时候，一样不会留情。

回答2

程序员作为一种社会职业，既没有政府职能部门的公权力，又没有有钱人的一掷千金，挣得也都是辛苦钱，何来社会地位高不高一说，无非就是资本的韭菜罢了。

回答3

这个问题我曾经思考过很久。按知乎的习惯，先问是不是，再问为什么。

首先说“是不是”。

按大家的直觉也好，或者现有的各个社区讨论来看，程序员的社会地位肯定不是高的。

最多有人说程序员的社会地位和其他职业一样高，但没见过谁说程序员的社会地位能高过GWY，医生，老师的。这么说来，“是不是”这个问题已经基本没有大的争议——在公众认知内，程序员的社会地位的确不高。

再来就是“为什么”。

这个为什么是我想了很久了，如果单独拿程序员和某个职业/行业比较，可以有很多个维度的对比，但如果想把大部分的职业/行业进行对比，需要找一个更有共性的比较方式，或者说是能归纳出比较重要的影响因素。对此，我归纳出来的最主要因素是“自由裁量权”。

这里的“自由裁量权”，又分为两个维度：

第一个是权力本身影响后果的大小，比如影响10块钱和影响10亿元的大小肯定不一样；

第二个是权力影响的范围，比如影响一个区和影响全国肯定不一样。

这里举电视剧《人民的名义》里面的人物来说明这一点。

第一个剧中是京州市副市长兼光明区区委书记丁义珍。丁义珍是“负责土地划批，矿产资源整合，还有老城改造”，这里无论是土地划批给某开发商，或者矿产资源交给哪个煤老板开挖，对于这些开发商和煤老板，都一笔稳赚不赔的买卖。而剧中的丁义珍在具体能把这块地或者这片矿批给谁上面，有很大的自由裁量权，也就是说，他能在规则范围之内，把地给批了。于是各个房地产开发商老板，煤矿老板都要找丁义珍去批地批矿，自然丁义珍社会地位就高了。

第二个是京州市城市银行副行长欧阳菁。作为银行副行长，很多带款她拥有最终决定权。是放贷或者不放贷，放贷放给哪个企业，她拥有决定权力，甚至还能影响汉东农信社的决定。比如在蔡成功申请六千万的带款的事情上，欧阳菁一直阻挠，甚至打电话让汉东农信社不给蔡成功带款。为什么以前能贷给蔡成功，而这次不行了呢，那是因为之前每次过桥贷蔡成功都给欧阳菁50万好处费，而这次没有。

从以上两个例子可以出，无论是在ZF，还是银行这种企业里，当官至一定地位时，就拥有了影响社会面的一定量的自由裁量权。无论是丁义珍还是欧阳菁，他们的自由裁量权总体上还是在规则之内运行的，没有明显超出规则之外。要不是赵德汉被查，丁义珍还没那么快会被抓以至于后面要逃亡国外。而欧阳菁如果不是因为侯亮平下来查山水集团等案子，也不会露出马脚。

在最开始说了，自由裁量权除了影响的后果大小，还有涉及面的大小，比如丁义珍和欧阳菁的影响力，主要还是在京州市之内，出了京州市，尤其是出了汉东省，他们也影响不到啥。而剧中的第一个出场的贪官赵德汉，就有影响全国资源项目的审核权，这就是影响面的区别了。所以才有那个全国各地都有人找赵德汉，在他办公室门口排队的事情了。

通过《人民的名义》这三个例子，自由裁量权的影响力和影响面应该都有一定的了解了。

那么我们回过头来看现实中的程序员，这个职业带来的对于社会影响的自由裁量权，可以看出是非常小的，影响面也非常不适合操作。

首先，程序员可以决定程序的技术架构和代码，但很难影响其功能。真正决定功能是怎么样的，是产品经理（网站、APP类）、策划（游戏类）、甲方（to B和to G类），程序员本身几乎没有话语权，即没有自由裁量权，更多地是执行权。即使程序员做到了manager，或者技术VP，甚至CTO，对于这些功能特性的影响都是有限的。

比如说你是某游戏的技术leader，过年了你侄子在玩这款游戏，他希望你帮他的角色属性全部乘以10，你也是做不到的，甚至在内部评审阶段都被砍了。从影响面的角度来看，如果程序员是做某个APP的，他没法影响同公司另一款APP怎么做，更别说影响别的公司的APP怎么做。用通俗点的话来说，无论是社会上的陌生人，还是亲戚朋友，希望找程序员去做一些其职业内能自由裁量的内容从而获益，是很难的。这也就是程序员社会不高的主要原因。

同理，按照这个框架，我们能分析其他的一些职业的社会地位，同时也能看到一些职业除了稳定之外，还有自由裁量权这一微妙的东西，让不少人甘愿去追逐。

全文完

或许，这些讨论，并不能改变现实。

我觉得我们要思考的是：

社会地位的标准到底是什么？

技术人如今的社会地位，合理不合理？

技术人做什么，能够改变自己的社会地位？

处理错误的两种方式：try...catch 与 then、catch

在前端编程中，错误和异常处理是保证代码健壮性和用户体验的重要环节。JavaScript 提供了多种方式来处理错误，其中最常见的两种是 try...catch 和 Promise 的 then、catch，但是什么时候该用try...catch，什么时候该用then、catch呢，下面将详细探讨这两种机制的区别及其适用场景。

一、try...catch

try...catch 是一种用于捕获和处理同步代码中异常的机制。其基本结构如下：

try {

    // 可能会抛出异常的代码

} catch (error) {

    // 处理异常

}

使用场景：

• 主要用于同步代码，尤其是在需要处理可能抛出的异常时。


• 适用于函数调用、操作对象、数组等传统代码中。

示例：

function divide(a, b) {

    try {

        if (b === 0) {

            throw new Error("Cannot divide by zero");

        }

        return a / b;

    } catch (error) {

        console.error(error.message);

    }

}



divide(4, 0); // 输出: Cannot divide by zero

在这个例子中，如果 b 为零，则会抛出一个错误，并被 catch 块捕获。

二、then 和 catch

在处理异步操作时，使用 Promise 的 then 和 catch 方法是更加常见的做法。其结构如下：

someAsyncFunction()

    .then(result => {

        // 处理成功的结果

    })

    .catch(error => {

        // 处理错误

    });

使用场景：

• 主要用于处理异步操作，例如网络请求、文件读取等。


• 可以串联多个 Promise 操作，清晰地处理成功和错误。

示例：

function fetchData() {

    return new Promise((resolve, reject) => {

        // 模拟异步操作

        setTimeout(() => {

            const success = Math.random() > 0.5; // 随机决定成功或失败

            if (success) {

                resolve("Data fetched successfully");

            } else {

                reject("Failed to fetch data");

            }

        }, 1000);

    });

}



fetchData()

    .then(result => {

        console.log(result);

    })

    .catch(error => {

        console.error(error);

    });

在这个示例中，fetchData 函数模拟了一个异步操作，通过 Promise 来处理结果和错误。

三、async/await 与 try...catch

为了使异步代码更具可读性，JavaScript 引入了 async/await 语法。结合 try...catch，可以让异步错误处理更加简洁：

async function fetchDataWithAwait() {

    try {

        const result = await fetchData();

        console.log(result);

    } catch (error) {

        console.error(error);

    }

}



fetchDataWithAwait();

总结

• try...catch：适合于同步代码，能够捕获代码块中抛出的异常。


• then 和 catch：用于处理 Promise 的结果和错误，适合异步操作。


• async/await 结合 try...catch：提供了清晰的异步错误处理方式，增强了代码的可读性。

在实际开发中，选择哪种方式取决于代码的性质（同步或异步）以及个人或团队的编码风格。

往期推荐

前端如何实现图片伪防盗链，保护页面图片🔥

适当使用$forceUpdate()🔥

怎么进行跨组件通信，教你如何使用provide 和 inject🔥

使用reactive导致数据失去响应式？🔥

前言

前端基于文件上传需要有生成临时可访问链接的能力，我们可以通过URL.createObjectURL和FileReader.readAsDataURAPI来实现。

URL.createObjectURL()

URL.createObjectURL() 静态方法会创建一个 DOMString，其中包含一个表示参数中给出的对象的URL。这个 URL 的生命周期和创建它的窗口中的 document 绑定。这个新的URL 对象表示指定的 File 对象或 Blob 对象。

1. 语法

let objectURL = URL.createObjectURL(object);

2. 参数

用于创建 URL 的 File 对象、Blob 对象或者 MediaSource 对象。

3. 返回值

一个DOMString包含了一个对象URL，该URL可用于指定源 object的内容。

4. 示例

"file" id="file">



document.querySelector('#file').onchange = function (e) {

  console.log(e.target.files[0])

  console.log(URL.createObjectURL(e.target.files[0]))

}

将上方console控制台打印的blob文件资源地址粘贴到浏览器中

blob:http://localhost:8080/1ece2bb1-b426-4261-89e8-c3bec43a4020

URL.revokeObjectURL()

在每次调用 createObjectURL() 方法时，都会创建一个新的 URL 对象，即使你已经用相同的对象作为参数创建过。当不再需要这些 URL 对象时，每个对象必须通过调用 URL.revokeObjectURL() 方法来释放。

浏览器在 document 卸载的时候，会自动释放它们，但是为了获得最佳性能和内存使用状况，你应该在安全的时机主动释放掉它们。

1. 语法

window.URL.revokeObjectURL(objectURL);

2. 参数 objectURL

一个 DOMString，表示通过调用 URL.createObjectURL() 方法返回的 URL 对象。

3. 返回值

undefined

4. 示例

"file" id="file">

<img id="img1" style="width: 200px;height: auto" />

<img id="img2" style="width: 200px;height: auto" />



document.querySelector('#file').onchange = function (e) {

	const file = e.target.files[0]

	

	const URL1 = URL.createObjectURL(file)

	console.log(URL1)

	document.querySelector('#img1').src = URL1

	URL.revokeObjectURL(URL1)

	

	const URL2 = URL.createObjectURL(file)

	console.log(URL2)

	document.querySelector('#img2').src = URL2

}

与FileReader.readAsDataURL(file)区别

1. 主要区别

• 通过FileReader.readAsDataURL(file)可以获取一段data:base64的字符串


• 通过URL.createObjectURL(blob)可以获取当前文件的一个内存URL

2. 执行时机

• createObjectURL是同步执行（立即的）


• FileReader.readAsDataURL是异步执行（过一段时间）

3. 内存使用

• createObjectURL返回一段带hash的url，并且一直存储在内存中，直到document触发了unload事件（例如：document close）或者执行revokeObjectURL来释放。


• FileReader.readAsDataURL则返回包含很多字符的base64，并会比blob url消耗更多内存，但是在不用的时候会自动从内存中清除（通过垃圾回收机制）

4. 优劣对比

• 使用createObjectURL可以节省性能并更快速，只不过需要在不使用的情况下手动释放内存


• 如果不在意设备性能问题，并想获取图片的base64，则推荐使用FileReader.readAsDataURL

常见的大屏数据请求方式

1、http请求轮询：使用定时器每隔多少时间去请求一次数据。优点：简单，传参方便。缺点：数据更新不实时，浪费服务器资源（一直请求，但是数据并不更新）

2、websocket：使用websocket实现和服务器长连接，服务器向客户端推送大屏数据。优点：长连接，客户端不用主动去请求数据，节约服务器资源（不会一直去请求数据，也不会一直去查数据库），数据更新及时，浏览器兼容较好（web、h5、小程序一般都支持）。缺点：有点大材小用，一般大屏数据只需要查询数据不需要向服务端发送消息，还要处理心跳、重连等问题。

3、sse：基于http协议，将一次性返回数据包改为流式返回数据。优点：sse使用http协议，兼容较好、sse轻量，使用简单、sse默认支持断线重连、支持自定义响应事件。缺点：浏览器原生的EventSource不支持设置请求头，需要使用第三方包去实现（event-source-polyfill）、需要后端设置接口的响应头Content-Type: text/event-stream

sse和websocket的区别

Websocket和SSE分别适用于什么业务场景？

根据sse的特点（轻量、简单、单向通信）更适用于大屏的数据查询，业务应用上查询全局的一些数据，比如消息通知、未读消息等。

根据websocket的特点（双向通信）更适用于聊天功能的开发

前端代码实现

sse的前端的代码非常简单

 const initSse = () => {

        const source = new EventSource(`/api/wisdom/terminal/stats/change/notify/test`);



        // 这里的stats_change要和后端返回的数据结构里的event要一致

        source.addEventListener('stats_change', function (event: any) {

            const types = JSON.parse(event.data).types;

        });

        // 如果event返回的是message 数据监听也可以这样监听

        // source.onmessage =function (event) {

        //  var data = event.data;

        // };



        // 下面这两个监听也可以写成addEventListener的形式

        source.onopen = function () {

            console.log('SSE 连接已打开');

        };



        // 处理连接错误

        source.onerror = function (error: any) {

            console.error('SSE 连接错误:', error);

        };

        setSseSource(source);

    };

    

// 关闭连接

sseSource.close();