有时候会跟着家人去逛菜市场，有次我岳母说北京的菜真贵，原本在农村老家2、3块的黄瓜到了北京要5、6块一斤，感觉真是土气。

出于好奇，我就开始琢磨这个问题。

我问了财务专业的老婆大人，老婆大人的答案很直接，大概意思是北京的供应链比老家贵的多，比如运输成本、用于卖菜的房租成本、还有销售蔬菜的人力成本……然后这些成本都加到蔬菜价格上，自然就高了。

我哈哈一笑，老婆大人的回答自然是不敢出声反驳的，但我可以在心里揣测。我觉得老婆大人说的没问题，但并不深刻，于是我开始浮想联翩……

一 自产自销

在北京生活久了，我发现就蔬菜来说并非不可以自产的。我之前生活的小区，就有销售自产蔬菜的大爷大妈。老婆说是因为供应链比老家的贵，可大爷大妈自产自销不需要供应链啊，老婆的回答就没法解释了。

在我的印象里面，大爷大妈自产的蔬菜也是要比老家的贵的，为什么会如此？

我思考的结果是，大爷大妈是询价定价的。简单来说大爷大妈一开始是不知道定价多少合适的，定的太低心里不得劲，定的太高没人买，所以大爷大妈会去附近菜市场询价，然后定一个比菜市场低的价格，这样既解决了心里不得劲问题，也解决了卖不出去问题。

但这本质上还是因为北京市场上的蔬菜价格比老家的贵。

二 供应链

如果不是自产自销，那就是依靠供应链了。在老家市场销售的黄瓜和北京市场销售的黄瓜，假设有着相同的货源，但背后供应链体系肯定是不同的。

在我们老家有那种大集，就是固定一个时间周期在一个固定地点开展买卖。

大集上的菜农销售蔬菜基本可以忽略掉租房成本，然后因为菜农本身就是销售人员，也省下销售成本，这样整体的供应链成本就下来了，就能够低价销售蔬菜了。

这也就是老婆说的供应链成本不同。

三 边际

边际是经济学核心概念之一，是一种思维方式，就是永远看市场中最后一个人的行为或者最后一个产品的情况。

比如在劳动力市场上，工资不是市场中的平均水平的劳动者决定的，而是最后一个参加劳动的人决定的，要看给他多高的工资他才愿意去做这份工作，同时也要看他有多大的贡献工厂才雇用他，两者相等的时候才是市场里的均衡工资。

拉长时间看蔬菜市场中的黄瓜价格会受边际影响。简单来说，蔬菜超市会因为追求最大经济利益调整蔬菜价格，直到找到均衡价格。

结果因为北京的购买者更能容忍价格的波动，导致北京的黄瓜比农村的贵。

四 可替代性

北京的购买者之所以更能容忍价格波动，原因之一是北京生活的人相对老家农村生活的人，在蔬菜这件事上，可替代性弱。

北京生活的人，少有自产自销者；而农村老家的人，多可以自产自销。这虽然不是价格上涨的直接原因，但无形当中推高了均衡价格。

五 购买力

北京的购买者之所以更能容忍价格波动，原因之二是北京的购买力强。

我之前在小区周边的永辉超市看到有机蔬菜，标记35.98/kg，我当时想什么人会买这种蔬菜呢？

从结果来说，北京购买者购买力强是老家的黄瓜比北京便宜的直接原因。

尾声

黄瓜的价格只是一个小的不能再小的缩影，老家的黄瓜之所以比北京便宜，根本原因是老家农村和北京有着根本不同的经济结构。

北京这种大城市有更高效的资源利用率，更强的生产能力和更高效的生产效率，结果就是北京创造了更多财富，即使普通人在这里也会有较高收入，高收入下基于边际思维演化的黄瓜价格，形成高的均衡价格。

多年前我曾极力劝我一个朋友来北京，他在四线城市很努力，但始终没能赚大钱。当初我说不出更具说服力的让他来北京的理由，但我认为我现在找到了：他赚钱少可能不是因为他不够努力，而是因为他本来就不在一个发达的经济体里，也就难以享受到比较高的红利。

所以我给普通奋斗者的建议是去经济发达地区谋生吧！

1. 引言

平时Android开发中，启动Activity是非常常见的操作，而打开一个新Activity可以直接使用Intent，也可以每个Activity提供一个静态的启动方法。但是有些时候使用这些方法并不那么方便，比如：一个应用内的网页需要打开一个原生Activity页面时。这种情况下，网页的调用代码可能是app.openPage("/testPage")这样，或者是用app.openPage("local://myapp.com/loginPage")这样的方式，我们需要用一种方式把路径和页面关联起来。Android可以允许我们在Manifest文件中配置<data>标签来达到类似效果，也可以使用ARouter框架来实现这样的功能。本文就用200行左右的代码实现一个类似ARouter的简易界面路由。

2. 示例

2.1 初始化

这个操作建议放在Application的onCreate方法中，在第一次调用Router来打开页面之前。

public class AppContext extends Application {

    @Override

    public void onCreate() {

        super.onCreate();

        Router.init(this);

    }

}

2.2 启动无参数Activity

这是最简单的情况，只需要提供一个路径，适合“关于我们”、“隐私协议”这种简单无参数页面。

Activity配置：

@Router.Path("/testPage")

public class TestActivity extends Activity {

    //......

}

启动代码：

Router.from(mActivity).toPath("/testPage").start();

//或

Router.from(mActivity).to("local://my.app/testPage").start();

2.3 启动带参数Activity

这是比较常见的情况，需要在注解中声明需要的参数名称，这些参数都是必要参数，如果启动的时候没有提供对应参数，则发出异常。

Activity配置：

@Router.Path(value = "/testPage",args = {"id", "type"})

public class TestActivity extends Activity {

        @Override

    protected void onCreate(@Nullable Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        //加载布局...



        String id = getIntent().getStringExtra("id"); //获取参数

        int type = getIntent().getIntExtra("type", 0);//获取参数

    }

}

启动代码：

Router.from(mActivity).toPath("/testPage").with("id", "t_123").with("type", 1).start();

2.4 启动带有静态启动方法的Activity

有一些Activity需要通过它提供的静态方法启动，就可以使用Path中的method属性和Entry注解来声明入口，可以提供参数。在提供了method属性时，需要用Entry的args来声明参数。

Activity配置：

@Router.Path(value = "/testPage", method = "open")

public class TestActivity extends Activity {



    @Router.Entry(args = {"id", "type"})

    public static void open(Activity activity, Bundle args) {

        Intent intent = new Intent(activity, NestWebActivity.class);

        intent.putExtras(args);

        activity.startActivity(intent);

    }



    @Override

    protected void onCreate(@Nullable Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        //加载布局...



        String id = getIntent().getStringExtra("id"); //获取参数

        int type = getIntent().getIntExtra("type", 0);//获取参数

    }

}

启动代码：

Router.from(mActivity).toPath("/testPage").with("id", "t_123").with("type", 1).start();

3. API介绍

3.1 Path注解

这个注解只能用于Activity的子类，表示这个Activity需要页面路由的功能。这个类有三个属性：

• value：表示这个Activity的相对路径。


• args：表示这个Activity需要的参数，都是必要参数，如果打开页面时缺少指定参数，就会发出异常。


• method：如果这个Activity需要静态方法做为入口，就将这个属性指定为方法名，并给对应方法添加Entry注解。（注意：这个属性值不为空时，忽略这个注解中的args属性内容）

3.1 Entry注解

这个注解只能用于Activity的静态方法，表示这个方法作为打开Activity的入口。仅包含一个属性：

• args：表示这个方法需要的参数。

3.2 Router.init方法

• 方法签名：public static void init(Context context)


• 方法说明：这个方法用于初始化页面路由表，必须在第一次用Router打开页面之前完成初始化。建议在Application的onCreate方法中完成初始化。

3.3 Rouater.from方法

• 方法签名：public static Router from(Activity activity)


• 方法说明：这个方法用于创建Router实例，传入的参数通常为当前Activity。例如，要从AActivity打开BActivity，那么传入参数为AActivity的实例。

3.4 Rouater.to和Rouater.toPath方法

• 方法签名：

1. public RouterBuilder to(String urlString)


2. public RouterBuilder toPath(String path)

• 方法说明：这个方法用于指定目标的路径，to需要执行绝对路径，而toPath需要指定相对路径。返回的RouterBuilder用于接收打开页面需要的参数。

3.4 RouterBuilder.with方法

• 方法签名：

1. public RouterBuilder with(String key, String value)


2. public RouterBuilder with(String key, int value)

• 方法说明：这个方法用于添加参数，对应Bundle的各个put方法。目前只有常用的String和int两个类型。如有需要可自行在RouterBuilder中添加对应的方法。

3.4 RouterBuilder.start方法

• 方法签名：public void start()


• 方法说明：这个方法用于打开页面。如果存在路径错误、参数错误等异常情况，会发出对应运行时异常。

4. 实现

import android.app.Activity;

import android.content.Context;

import android.content.Intent;

import android.content.pm.ActivityInfo;

import android.content.pm.PackageInfo;

import android.content.pm.PackageManager;

import android.net.Uri;

import android.os.Bundle;

import android.text.TextUtils;



import androidx.annotation.Keep;



import java.lang.annotation.ElementType;

import java.lang.annotation.Retention;

import java.lang.annotation.RetentionPolicy;

import java.lang.annotation.Target;

import java.lang.reflect.Method;

import java.util.Map;

import java.util.Objects;

import java.util.concurrent.ConcurrentHashMap;



@Keep

public class Router {



    public static final String SCHEME = "local";

    public static final String HOST = "my.app";

    public static final String URL_PREFIX = SCHEME + "://" + HOST;



    private static final Map<String, ActivityStarter> activityPathMap = new ConcurrentHashMap<>();



    public static void init(Context context) {

        try {

            PackageManager packageManager = context.getPackageManager();

            PackageInfo packageInfo = packageManager.getPackageInfo(

                    context.getPackageName(), PackageManager.GET_ACTIVITIES);



            for (ActivityInfo activityInfo : packageInfo.activities) {

                Class<?> aClass = Class.forName(activityInfo.name);

                Path annotation = aClass.getAnnotation(Path.class);

                if (annotation != null && !TextUtils.isEmpty(annotation.value())) {

                    activityPathMap.put(annotation.value(), (Activity activity, Bundle bundle) -> {

                        if (TextUtils.isEmpty(annotation.method())) {

                            for (String arg : annotation.args()) {

                                if (!bundle.containsKey(arg)) {

                                    throw new IllegalArgumentException(String.format("Bundle does not contains argument[%s]", arg));

                                }

                            }

                            Intent intent = new Intent(activity, aClass);

                            intent.putExtras(bundle);

                            activity.startActivity(intent);

                        } else {

                            try {

                                Method method = aClass.getMethod(annotation.method(), Activity.class, Bundle.class);

                                Entry entry = method.getAnnotation(Entry.class);

                                if (entry != null) {

                                    for (String arg : entry.args()) {

                                        if (!bundle.containsKey(arg)) {

                                            throw new IllegalArgumentException(String.format("Bundle does not contains argument[%s]", arg));

                                        }

                                    }

                                    method.invoke(null, activity, bundle);

                                } else {

                                    throw new IllegalStateException("can not find a method with [Entry] annotation!");

                                }

                            } catch (Exception e) {

                                throw new RuntimeException(e);

                            }

                        }

                    });

                }

            }

        } catch (Exception e) {

            throw new RuntimeException(e);

        }

    }



    public static Router from(Activity activity) {

        return new Router(activity);

    }



    private final Activity activity;



    private Router(Activity activity) {

        this.activity = activity;

    }



    public RouterBuilder to(String urlString) {

        if (TextUtils.isEmpty(urlString)) {

            return new ErrorRouter(new IllegalArgumentException("argument [urlString] must not be null"));

        } else {

            return to(Uri.parse(urlString));

        }

    }



    public RouterBuilder toPath(String path) {

        return to(Uri.parse(URL_PREFIX + path));

    }



    public RouterBuilder to(Uri uri) {

        try {

            if (SCHEME.equals(uri.getScheme())) {

                if (HOST.equals(uri.getHost())) {

                    String path = uri.getPath();//note: 二级路径暂不考虑

                    ActivityStarter starter = activityPathMap.get(path);

                    if (starter == null) {

                        throw new IllegalStateException(String.format("path [%s] is not support", path));

                    } else {

                        NormalRouter router = new NormalRouter(activity, starter);

                        for (String key : uri.getQueryParameterNames()) {

                            if (!TextUtils.isEmpty(key)) {

                                router.with(key, uri.getQueryParameter(key));

                            }

                        }

                        return router;

                    }

                } else {

                    throw new IllegalArgumentException(String.format("invalid host : %s", uri.getHost()));

                }

            } else {

                throw new IllegalArgumentException(String.format("invalid scheme : %s", uri.getScheme()));

            }

        } catch (RuntimeException e) {

            return new ErrorRouter(e);

        }

    }



    public static abstract class RouterBuilder {

        public abstract RouterBuilder with(String key, String value);



        public abstract RouterBuilder with(String key, int value);



        public abstract void start();

    }





    private static class ErrorRouter extends RouterBuilder {

        private final RuntimeException exception;



        private ErrorRouter(RuntimeException exception) {

            this.exception = exception;

        }



        @Override

        public RouterBuilder with(String key, String value) {

            return this;

        }



        @Override

        public RouterBuilder with(String key, int value) {

            return this;

        }



        @Override

        public void start() {

            throw exception;

        }

    }



    private static class NormalRouter extends RouterBuilder {

        final Activity activity;

        final Bundle bundle = new Bundle();

        final ActivityStarter starter;



        private NormalRouter(Activity activity, ActivityStarter starter) {

            this.activity = Objects.requireNonNull(activity);

            this.starter = Objects.requireNonNull(starter);

        }



        @Override

        public RouterBuilder with(String key, String value) {

            bundle.putString(key, value);

            return this;

        }



        @Override

        public RouterBuilder with(String key, int value) {

            bundle.putInt(key, value);

            return this;

        }



        @Override

        public void start() {

            starter.start(activity, bundle);

        }

    }



    @FunctionalInterface

    private interface ActivityStarter {

        void start(Activity activity, Bundle bundle);

    }



    @Retention(RetentionPolicy.RUNTIME)

    @Target(ElementType.TYPE)

    public @interface Path {

        String value();



        String method() default "";



        String[] args() default {};

    }



    @Retention(RetentionPolicy.RUNTIME)

    @Target(ElementType.METHOD)

    public @interface Entry {

        String[] args() default {};

    }

}

5. 注意

背景

小盟 AI 助手项目中需要服务端把 AI 模型回调回来内容，实时推送到客户端，展示给用户；整个流程需要一个能够快速支持上线的服务端推送方案。经过对现有的一些服务端推送方案进行调研，并结合项目的周期、实现成本、用户体验等多方综合考量，最终选择了 Server-Sent Events（SSE）方案进行实践。

首先服务端推送，是一种允许应用服务器主动将信息发送到客户端的能力，为客户端提供了实时的信息更新和通知，增强了用户体验。

服务端推送主要基于以下几个诉求：

（1）实时通知：在很多情况下，用户期望实时接收到应用的通知，如新消息提醒、活动提醒等。

（2）节省资源：如果没有服务端推送，客户端需要通过轮询的方式来获取新信息，会造成客户端、服务端的资源损耗。通过服务端推送，客户端只需要在收到通知时做出响应，大大减少了资源的消耗。

（3）增强用户体验：通过服务端推送，应用可以针对特定用户或用户群发送有针对性的内容，如优惠活动、个性化推荐等。这有助于提高用户对应用的满意度和黏性。

方案对比

轮询： 是一种较为传统的方式，客户端定时地向服务端发送请求，询问是否有新数据。服务端只需要检查数据状态，然后将结果返回给客户端。轮询的优点是实现简单，兼容性好；缺点是可能产生较大的延迟，且对服务端资源消耗较高。

长轮询（Long Polling）： 轮询的改进版。客户端向服务器发送请求，服务器收到请求后，如果有新的数据，立即返回给客户端；如果没有新数据，服务器会等待一定时间（比如30秒超时时间），在这段时间内，如果有新数据，就返回给客户端，否则返回空数据。客户端处理完服务器返回的响应后，再次发起新的请求，如此反复。长轮询相较于传统的轮询方式减少了请求次数，但仍然存在一定的延迟。   

WebSocket： 一种双向通信协议，同时支持服务端和客户端之间的实时交互。WebSocket 是基于 TCP 的长连接，和HTTP 协议相比，它能实现轻量级的、低延迟的数据传输，非常适合实时通信场景，主要用于交互性强的双向通信。

SSE： 是一种基于 HTTP 协议的推送技术。服务端可以使用 SSE 来向客户端推送数据，但客户端不能通过 SSE 向服务端发送数据。相较于 WebSocket，SSE 更简单、更轻量级，但只能实现单向通信。

小盟 AI 助手项目需要快速上线且保证要用户较好的使用体验。鉴于 SSE 技术的轻量、实现简单、不增加额外的资源成本；当前业务场景也只需要服务端到用户端的单向的字符推送。非常适合项目需要。所以决定使用 SSE 来实现内容推送。****

深入 SSE

SSE 服务端推送，它基于 HTTP 协议，易于实现和部署，特别适合那些需要服务器主动推送信息、客户端只需接收数据的场景。有以下特点：

1、简单：基于 HTTP，无须额外的协议或者类库支持。主流浏览器都支持。

2、事件流：使用"事件流"（Event Stream）将数据从服务器发送到客户端。每个事件都可以包含一个事件标识符、事件类型和数据字段。客户端可以根据这些信息来解析和处理接收到的数据。

3、自动重连：意外断开时会自动尝试重新连接。可以确保了在网络故障或连接中断后能够及时恢复通信，为用户提供连续的数据流。重连时会在 HTTP 头中的Last_Event_ID 带上上一次的数据 ID，便于服务端返回后续数据。

4、单向推送：只能从服务端推送数据到客户端。

SSE 消息体介绍：

SSE消息体示例：

服务端主要使用 Spring，其对 SSE 主要提供了两种支持：

• Spring WebMVC：传统的基于 Servlet 的同步阻塞编程模型，即 同步模型 Web 框架。


• Spring WebFlux：异步非阻塞的响应式编程模型，即 异步模型 Web 框架。          

项目基于springboot，所以选择使用前者实现。SseEmitter emitter = new SseEmitter(); 一句代码就可以建立一个 SSE 连接。

实践

后端实现

建立一个SseEmitterManger，统一管理当前服务 SSE 连接的创建、释放以及数据推送。结合 Redis 缓存可实现集群环境 SSE 连接的管理。

核心逻辑如下：

• 连接池维护，设定一个上限，避免过大，导致内存问题。

static final Map<String, SseEmitter> sseCache =     new ConcurrentHashMap<>(300)          

• 建立SSE连接，为每个连接建立一个唯一的MsgId，用来维护SSE连接与客户端的关系了；在 Redis 缓存中存入MsgId和当前机器节点的IP和Port，这样可以找到SSE 连接所在的服务结点，然后通过 HTTP 请求转发需要发送的数据到对应的服务节点上进行处理。

sse = new SseEmitter()sseId = "sse_xxx";redisKey= "aisse:" + bosId + "_" + wid ipPort = "10.10.10.10:8080"redis.hset(redisKey, msgId, ipPort)sseCache.put(msgId, sseEmitter);

• 获取持有连接的 pod ipPort；根据 IP 发起请求。

ipPort = redisUtil.hashGet(redisKey, msgId)

• 获取当前服务结点的SSE连接，发送数据。

sseEmitter = sseCache.get(msgId)sseEmitter.send(msgJson)          

• 释放SSE连接

SseEmitter sseEmitter = sseCache.get(msgId);sseEmitter.complete();sseCache.remove(msgId);redisUtil.hashDel(redisKey, msgId);

**核心流程图如下： **  

需要注意的是开启 SSE 连接接口的整个链路都要支持长连接。例如使用 Nginx 则要开启长连接的配置：

• keepalive 用于控制可连接整个 upstream servers 的 HTTP 长连接的个数，即控制总数。


• proxy_http_verion 用于控制代理后端链接时使用的 HTTP 版本，默认为 1.0。要想使用长连接，必须配置为 1.1。


• proxy_set_header 需要设置为 Connection ""，否则则发往 upstream servers 的请求中，Connection header 的值将为close，导致无法建立长连接。   

http {        upstream keepAliveService {            server 10.10.131.149:8080;            keepalive 20;        }            server {            listen 80;            server_name keepAliveService;            location /keep-alive/hello {                proxy_http_version 1.1;                proxy_set_header Connection "";                proxy_pass http://keepAliveService;            }        }}

**前端实现 **  

前端可以使用组件 @microsoft/fetch-event-source 来实现。

npm i @microsoft/fetch-event-source

import { fetchEventSource } from '@microsoft/fetch-event-source';let controller = new AbortController();  let eventSource = fetchEventSource('apiUrl', {  method: 'POST',  headers: {    'Content-Type': 'application/json',    'token': '....'  },  signal: controller.signal,  body: JSON.stringify({    ... // 传参  }),  onopen() {    // 建立连接  },  onmessage(event) {    // 接收信息    // 成功之后满足某些条件可以使用AbortController关闭连接        controller.abort()        eventSource?.close && eventSource.close();  },  onerror() {    // 服务异常        controller.abort()        eventSource?.close && eventSource.close();  },  onclose() {    // 服务关闭  },})

总结

SSE 轻量级的服务端单向推送技术；具有支持跨域、使用简单、支持自动重连等特点。相对于 WebSocket 更加轻量级，如果需求场景客户端和服务端单向通信，那么 SSE 是一个不错的选择。

00后整顿职场，也算是我之前的关键词吧。

我硬怼老板要加班费和提成，和他们辩论什么是我的财产，什么是公司的财产。

甚至还能在即将被开除的时候，反将一军把老板开除。

而正是因为这一次把老板开除，让我得到了机会。可以站在了相对于之前更高的位置，来俯瞰整个职场。

也真正意义上让我感受到了，00后整顿职场，就是一个互联网笑话罢了。

1、职场宫斗，成功上位

我之前在苏州工作，堪称工作中的宫斗，并且在这场宫斗大戏中胜出，将原有的项目负责人开除，成功上位。

而这个项目存在的问题非常多，我就在六月被派遣去项目的总部合肥进行学习，等到打通项目的全部链路后，再回到苏州。

届时我将以这个项目的负责人，重新搭建团队，开展这个项目。所以我在合肥那边，以员工的身份深入各个工作组进行学习。

在市场部，运营部的办公大厅工作过，也在各部门的独立办公室工作过。

我感觉自己像个间谍，一边在以平级的打工人身份和我的同事们相处，一边又以苏州负责人的身份，参与那些领导才能参与的内部会议。

2、内心变化的开端

我在合肥总部工作中，接触了很多躺平摆烂的同事，但这个“躺平摆烂“要加上双引号。

他们是00后，90后，甚至有85后。如果放在三个月前，我可以不假思索地说，他们全都是我最讨厌的人。他们如同牛羊一般任人宰割，上级让加班，他们就加班，有时候加班甚至超过四五个小时也没有怨言。

我甚至从来没听他们感慨过为什么没有加班费。亲眼看着他们被自己的上级用一些与工作无关的鸡毛蒜皮之事骂得狗血淋头，但他们也只会在被骂完之后，背地里吐槽那个领导估计是在家被老婆骂了，才来拿他们泄愤。

我打听了他们的工资，只能说中规中矩，起码不是能让人当牛做马的数字。偶尔我见到一两个有骨气的人，觉得拿这么点钱就应该干这么点事。干不爽就马上离职，但马上就会有下一个人替补他的位置，形成闭环。

我惊讶于怎么有人能惹到这个地步，但后来和他们日渐熟落，我们一起吃饭，一起打游戏，一起下班顺路回家，还参加了他们的生日聚会。我发现他们活得其实真的很洒脱。一切都是随遇而安，下班时间一到，他们就真的可以无忧无虑。

因为他们有一份工资还行的工作，养活自己。他们没有啃老，也没有用卑鄙的手段，去抢想要努力的人应该分到的蛋糕，也压根不去想要赚很多钱，因为没有什么需要太高消费的需求。

加上现在的环境，找到一份可观收入的工作确实很难。所以公司偶尔的加班，领导偶尔的泄愤，这些毕竟还是少数时候的偶尔，也都没有超过他们的心理承受阈值，那也就得过且过了。

所以我们其实都一样，只是个普通人罢了。而像我们这样的普通人，取之不尽，用之不竭。这到底是好事还是坏事呢？

3、复杂的职场生态环境

建立在这个基础上，视觉转换到高层领导们这里。他们当着我的面说，这样的人就是个底层打工仔，缺人就招，加班照旧，心情不好还要扣他们的全勤绩效。

压根就不怕这些底层打工仔闹事，纵使有一两个所谓的决心者辞职，也能在很快时间找到下一位。

两者形成互补，共同铸就了这样恶劣的职场生态环境。但我说职场无法改变，远不止这么一点原因。

在这个项目中，我说好听一些只能算是项目负责人，在此之上还有着项目股东，这还要细分成大股东和小股东。而我所在的项目属于互联网赛道，也就是说需要一些新鲜事物的眼光和思维来对待。

但这些股东们经常提出一些奇怪的意见，就如同用微商时代的卖货思维，来指点直播带货，并且他们是出钱的股东，他们提出的战略方针不容我驳回，因为在他们的光辉历史中，有大量的成功案例，来佐证他们的思路是对的。

我刚开始觉得也有道理。他们能有钱投资，肯定是有什么过人的本领能让他们赚到钱，但是随着相处下来，我发现不过是他们本身家里条件就优越，在九几年就能拿出一百万给他们创业。

他们把这一百万分散到二十个领域，每个投资五万总能撞上那么一两个风口，让他们实现钱生钱。

九几年的五万也算是一笔不少的投资。他们这样的发财经历，让我很难不产生质疑，这不是给我我也行吗？

毕竟他们如果真的有什么过人的本领和远见，也不至于在每次内部开会之前，都要组织喊这样的口号：“好，很好，非常好，越来越好“

甚至试图把这样的口号，带到每一次迎接客户的项目介绍会上。我以自曝式要挟制止他们这个行为，我说如果你们这么干，那我当天就辞职，内部都是自己人，我可以陪你们这样弄，但如果对外这么搞，被录下来说我们是传销，我都不知道怎么辩解。

4、职场中的背锅人

他们就是这样坚信着自己能成功，是因为自己有过人的才华。所以自我洗脑着自己提出的方向没有错。如果出错了，亏损了，那一定是负责人的问题。

但好巧不巧，我就是那个负责人。我已经无数次告诉他们，我们这个项目压根就不需要穿黑丝短裙跳舞的小姐姐。

我甚至写了一篇报告给他们，分析我们的项目为什么不能用擦边这种手段引流。但他们执意要，说这样来流量快，我都有点分不清到底是他们自己想看，还是深信这样做确实是可行。

但如果最后这样还是没成功，导致项目亏损，大概率还是在我身上找原因吧。

面对他们这样的大佬，我心里很清楚，这已经远远不是宫斗了，这也绝对不是靠几个心计，或者有实力撑腰就能取胜上位了。这场权力的游戏，不是我等草民玩得起的。

5、换个思路，创造属于自己的职场

一边是被提供资金，但是瞎指挥的股东们摧残，一边是在有限的预算下，我作为负责人，确实很难做到尊重打工人的内心挣扎，回到苏州我虽然能身居高位，但我终将成为我曾经最鄙视的人。

我不要当这个背锅侠，我也不想在这个环境中，去逐渐接受这样的价值观。

这样看来确实如此，00后整顿职场不过是一场互联网的狂欢罢了。

这个题材的故事，也永远只能发生在职场的最底层。由一群家境优越，体验生活的公子哥和我这种不知好歹的普通人共同出演。

大部分人只是在手机屏幕前把我们当个乐子，成了扣个666，然后一起吃胜利的果实。没成，那就确实是看了个乐子。

或许是因为他们心里也清楚，凭我们压根就做不到。

00后现在确实整顿不了职场，因为社会的资源和命脉还不掌握在00后手上。

但就止步于此了吗？我曾说过我想有一个自己的小工作室，遵守劳动法，双休，按时发工资，交纳五险一金。

是的，换个思路，也许00后不需要整顿职场，而是直接创造属于自己的职场，那么接下来我就要向着这个目标去努力了，毕竟二十年后我也还是00后，不如到时候再来说00后整顿职场吧。

背景原因

今天写需求，需要使用background简写属性，心想这还不简单吗，真男人写样式只需要两秒:

background:  url('./bg.png') no-repeat center contain ;

搞定！

上面设置的依次是 背景图片 背景平铺模式 背景位置 背景图片是保有其原有的尺寸还是拉伸到新的尺寸。

so easy~

看我ctrl + s 保存代码，编译。

嗯？ 怎么不生效？ 俺的背景呢？
打开控制台一看，好家伙，压根没生效:

问题排查

第一反应是这些属性有固定顺序，但是凭我练习两年半的经验，不应该啊，之前也是这样用的啊，遂打开MDN，仔细翻阅....

发现了下面这段话:

这让我更加确信 写的没毛病啊！！

background-attachment、background-color、background-image、background-position、background-repeat、background-size
这些属性可以以任意顺序书写。

见了鬼了,待我排查两小时(摸鱼...)

原因浮现

在仔细阅读文档后发现，其实在文档的上面，还有另外一段话：

我恍然大悟，索嘎，以后看文档不能马虎了，得仔细查阅，过于经验主义了，这都是细节啊！

background使用注意事项和总结

其实，使用background时，大部分时候 属性的顺序是可以任意位置书写的，
但是有两个属性有点特殊，那就是background-size和background-position，

当background简写同时有这两个属性时，那么必须background-position在前，background-size在后，且两者只能紧挨着书写并且以 "/"分隔。
例如:

错误: background: url('./bg.png') no-repeat center  contain ; // 没有以 "/"分隔

错误: background: url('./bg.png') center  no-repeat contain ; // 没有紧挨着书写

错误: background: url('./bg.png') no-repeat contain / center; //background-size写在了 background-position的前面



正确: background: url('./bg.png') no-repeat center / contain ; 

写在最后

其实MDN在关于background的文档最开头的例子中就有写：

只不过没有用语言描述出来，一般没有认真看很难发现，所以有时候能够静下心来认真查阅文档，真的会发现很多细节(甩锅:这tm是谁写的文档，出来挨打).

背景

前两天分享了一篇自己的个人经历，没想到引来了那么多人共鸣，很多人留下了评论，大部分评论我都认真看了，并且也回复了，有的评论建议真的很棒，对我的帮助很大，很感谢。

今天给评论给整理了一下，再加上自己有一些新的感悟，给大家分享分享，给迷茫的朋友一点建议。有很多东西想说，但是表达能力有限，只能写出一点。

一个30岁老前端的人生经历（学习+工作+婚姻+孩子），给迷茫的朋友一点激励。前端是不是真的不行了

有些没有毕业或者刚毕业的兄弟们，很关心这个问题，因为关乎他们是否要学前端开发。还有一些想转前端开发的兄弟，也很关心这个问题。

关于这个问题，上篇文章有评论开玩笑的说现在入前端，相当于49年入guojun，下面就这个问题我发表一下我的个人看法。

先说一下我的观点，前端确实比以前难很多，工作岗位变少，薪资变低，技术要求也变高了，还没入或准备入前端的，建议真的不要入了，有经验的都不好找工作，更别说没工作经验的了，当然天才除外。

我同学和我朋友两个前端（都是好几年工作经验的）找了几个月都没有合适的工作，面试机会还是有的，但是外包偏多，并且还要降薪，最后都拒了。

他们还发现了一个现象，有时候面试的过程中整体都非常好，hr有要发offer的意思，但是就一直拖着，然后后面突然有一天说不合适了。这种应该是有更好的选择了，以前都是求职者手握多个offer，去挑选公司，现在公司占据主动了，从多个候选人中挑员工了。

后端情况我不清楚，但是前端真的没有以前好就业了，这个时候想入前端的，我真的不太建议，除非你真的特别牛，就算你很牛，但是没有面试机会，也没办法证明啊。

有些已经入前端的新人私信我，让我给他一些提升建议。

小结

没入前端的同学，建议别入了。刚入前端的同学想快速提升自己，多学多练，多总结和复盘，不要怕被别人说卷，给自己定目标。

30岁前端的路

我在flag里写了打算2024年认真看一下react源码，很多大佬建议说现在别搞这些没意义的东西了，搞前端死路一条。

关于大龄前端发展，从评论建议中，我总结了以下几条常用出路，欢迎大家补充。

深入技术

都说前端的天花板就是组长，结合我自身的经历和评论区的留言来看好像确实是这样，我几年前就开始做前端负责人了，其实就是组长，只是管的人多少的问题，cto永远是后端。主要工作就是需求来了，把任务给下面人分一分，就没了，最有挑战的也就是框架基建了吧。

评论里有人说，如果想要继续搞技术的话，可以往全栈方向发展，因为前端很难涉及到公司业务，所以可替代性很高，后端和公司业务结合的比较深一点，而业务才是公司的根本，换一个人很难立马上手，可替代性比前端低很多。

关于全栈我的观点是，大龄前端还是往全栈发展比较好，除了上面的原因外，全栈可以自己做个产品，还可以接私活、做自由职业者，甚至转管理都需要懂点后端技术。

想转全栈，但是又不想学别人语言，node也是可以做后端开发的，现在比较成熟的框架有midway和nest，甚至koa都可以做后端开发。关注我的人应该知道我正在做的fluxy-admin就是一个全栈项目，前端使用的是react，后端使用的是midway，前端上手midway还是很简单的，我一个星期就上手写项目了。

转管理

有一些评论提到了转管理，说实话这个是需要机会的，不是所有人想转就转的，因为公司很少愿意给员工尝试的机会，除非你开发的时候已经表现出了管理方面的天赋，让老板认可你，不然都很难转成功，一是一个萝卜一个坑，老的领导没走你就上不去，而上面领导走了，很多公司可能会从外面招一个新的人空降过来，而不是从下面提拨一个上去。

还有管理也不是什么人都可以做的，有的人搞技术可以，管理真的不太行，比如我，在某家公司，当时管着10几个前端，团队被我带的一团糟，后来我找个副组长帮我管理，我专心搞技术搞框架，团队才慢慢走上正规。

个人觉得想转管理，需要机会和自身有管理才能，这两个条件都很重要。

转产品

有些评论还提到了转产品，我感觉这个还是比较靠谱的，玉伯大佬就是一个成功转型的案例。

个人感觉前端转产品还是有一些优势的，下面是我从网上搜的：

前端转产品，可以将技术理解和用户体验融入产品管理中，提高产品的竞争力。感觉门槛也不高，只需要有想法，并且现在软件行业那么发达，实在想不到好的点子，还可以借鉴别人产品设计。

甚至以后AI发展的很成熟了，可能就不需要开发了，只需要产品经理把需求描述好，产品就自动生成出来了。

我现在也在往这方面发展，最近一年在公司主导研发低代码平台，从最开始的设计到基本构架实现都是我一个人，框架成熟后，经常和交付直接交流，渐渐往产品的角色发展了。现在工作中不只是只有代码了，经常也会站在产品的角度去思考，做的东西怎么才能更有价值，怎么提高用户体验等。

平时有一些想法在公司产品里用不上，所以打算自己做一个产品，现在有了一些idea，明年应该会去做。这里说明一下，如果有想法想做个产品但找不到合适的后端合伙人，全栈做小应用或独立产品还是很有优势的，呼应了前面说的全栈优势。

搞副业

评论里也有很多人建议搞副业，这个确实也是一条出路，但是我感觉搞副业得有可靠的路子，不能盲目的去搞，不然最后可能血本无归。

我知道前几年有个程序员可以干的并且很好的副业，录视频卖课程，现在随着互联网新人越来越少，这个副业已经不行了。

现在我知道的有个副业还不错，在线帮别人修改简历，因为现在很多人找不到工作，甚至没有面试机会，他们会很焦虑，认为可能是自己简历的问题，会找一些大佬帮忙优化简历，搞这个的提前你得是个大佬，并且有一定的知名度，对于普通人不适用。

现在也有一些人趁着AI的热度，独立开发AI应用，靠这个赚了一些钱，我对这个不太了解，不做评价。

下面是一位大佬的评论，可能比较适合普通人，不过他说的那些我都没有认证，大家请谨慎对待：

转行

有很多评论认为搞技术没有前途，还是要考公，确实对于刚入行或准备入行的兄弟考公是一个比较好的选择，因为年轻还有很多机会，像我们这种年龄大的，还拖家带口的已经不适合改行了，成本太高了，真经不起折腾。

也有评论说想回老家，说实话我也想老家，但是以我的能力，回老家估计都养不活一家人，只会写代码，回老家能干啥呢。

最后

上面的内容是根据评论内容简单的整理了一下，还加了一些个人看法，大家可以结合自己的情况食用。可能还有更多好的建议因为我文笔有限，没写出来，欢迎大家评论，一起交流。

最后说一下自己吧，没写文章之前，我一直认为作为一个程序员技术最重要的，就像我的简介里说的那样，我唯一会的就是写代码，我不一定会成功，但是我会努力做的更好。看完大家的评论后，内心有过动摇，是不是不应该继续卷技术了，在写这篇文章的时候，我又坚定了，因为搞技术不只是我的工作，这也是我热爱的东西，即使有一天被迫失业不做程序员了，我可能偶尔还会写写代码。不过鸡蛋不能放在一个篮子里的道理我还是知道的，我现在已经在慢慢往产品转，用以保证未来不失业，因为还有一大家子需要我来养啊。共勉。

是的, 你没听错! 网络开发中无处不在的数据交换格式JSON, 可能会拖慢你的应用程序. 在这个速度和响应速度至上的世界里, 检查 JSON 的性能影响至关重要, 而我们对此却常常忽略. 在本博客中, 我们将深入探讨 JSON 成为应用程序瓶颈的原因, 并探索更快的替代方案和优化技术, 以确保你的应用程序以最佳状态运行.

JSON 是什么? 为何我要关注这个问题?

JSON 教程 | w3resource

JSON是JavaScript Object Notation的缩写, 是一种轻量级数据交换格式, 已成为Web应用中传输和存储数据的首选. 它的简洁性和人类可读格式使人类和机器都能轻松使用. 但是, 为什么要在Web开发项目中关注 JSON 呢?

JSON 是应用中数据的粘合剂. 它是服务器和客户端之间进行数据通信的语言, 也是数据库和配置文件中存储数据的格式.

JSON 的流行以及人们使用它的原因…

JSON 在Web开发领域的受欢迎程度怎么强调都不为过. 它已成为数据交换的事实标准, 这其中有几个令人信服的原因:

它易于使用!

鉴于这些优势, 难怪全球的开发人员都依赖 JSON 来满足他们的数据交换需求. 然而, 随着我们在本博客的深入探讨, 我们将发现与 JSON 相关的潜在性能挑战, 以及如何有效解决这些挑战.

速度需求

🚀🚀🚀

应用的速度和响应的重要性

在当今快节奏的数字环境中, 应用的速度和响应能力是不可或缺的. 用户希望在Web和移动应用中即时获取信息, 快速交互和无缝体验. 对速度的这种要求是由以下几个因素驱动的:

JSON 会拖慢我们的应用吗?

现在, 让我们来讨论核心问题: JSON 是否会拖慢我们的应用?

如前所述, JSON 是一种非常流行的数据交换格式. 它灵活, 易用, 并得到广泛支持. 然而, 这种广泛的应用并不意味着它不会面临性能挑战.

在某些情况下, JSON 可能是导致应用慢的罪魁祸首. 解析 JSON 数据的过程, 尤其是在处理大型或复杂结构时, 可能会耗费宝贵的毫秒时间. 此外, 低效的序列化和反序列化也会影响应用的整体性能.

在接下来的内容中, 我们将探讨 JSON 成为应用瓶颈的具体原因, 更重要的是, 探讨如何缓解这些问题. 在深入探讨的过程中, 请记住我们的目标不是诋毁 JSON, 而是了解其局限性并发现优化其性能的策略, 以追求更快, 反应更灵敏的应用.

LinkedIn将Protocal Buffers与Rest.li集成以提高微服务性能| LinkedIn工程

JSON 为什么会变慢

尽管 JSON 被广泛使用, 但它也难逃性能挑战. 让我们来探究 JSON 可能会变慢的原因, 并理解为什么 JSON 并不总是数据交换的最佳选择.

1. 解析带来的开销

当 JSON 数据到达应用时, 它必须经过解析过程才能转换成可用的数据结构. 解析过程可能相对较慢, 尤其是在处理大量或深度嵌套的 JSON 数据时.

2. 序列化和反序列化

JSON 要求在从客户端向服务器发送数据时进行序列化(将对象编码为字符串), 并在接收数据时进行反序列化(将字符串转换回可用对象). 这些步骤会带来开销, 影响应用的整体速度.

在微服务架构的世界里, JSON 通常用于在服务之间传递消息. 但是, 很关键的是, 我们必须认识到, JSON 消息需要序列化和反序列化, 这两个过程会带来巨大的开销.

在有大量微服务不断通信的场景中, 这种开销可能会增加, 并有可能使应用变慢, 以至于影响用户体验.

我们面临的第二个挑战是, 由于 JSON 的文本性质, 序列化和反序列化的延迟和吞吐量都不理想.
— LinkedIn

序列化和反序列化

3. 字符串操作

JSON 基于文本, 在连接和解析等操作中严重依赖字符串操作. 与处理二进制数据相比, 处理字符串的速度会慢一些.

4. 缺乏数据类型

JSON 的数据类型(如字符串, 数字, 布尔值)非常有限. 复杂的数据结构可能需要效率较低的表示法, 从而导致内存使用量增加和处理速度减慢.

5. 冗余

JSON 的人类可读性设计可能会导致冗余. 不需要的键和重复的结构增加了有效载荷的大小, 导致数据传输时间延长.

第一个挑战是 JSON 是一种文本格式, 往往比较冗余. 这导致网络带宽使用量增加, 更高的延迟, 效果并不理想.
— LinkedIn

6. 不支持二进制

JSON 缺乏对二进制数据的本地支持. 在处理二进制数据时, 开发人员通常需要将其编解码为文本, 而这可能会降低效率.

7. 深度嵌套

在某些情况下, JSON 数据可能是深嵌套的, 需要递归解析和遍历. 这种计算复杂性会降低应用的运行速度, 尤其是在没有优化的情况下.

JSON的替代方案

虽然 JSON 是一种通用的数据交换格式, 但由于其在某些情况下的性能限制, 人们开始探索更快的替代格式. 让我们深入探讨其中的一些替代方案, 了解何时以及为何选择它们:

1. Protocol Buffers(protobuf)

Protocal Buffers通常被称为protobuf, 是由谷歌开发的一种二进制序列化格式. 它的设计宗旨是高效, 紧凑和快速. Protobuf 的二进制性质使其在序列化和反序列化方面的速度明显快于 JSON.

• 何时选择: 当你需要高性能的数据交换时, 尤其是在微服务架构, 物联网应用或网络带宽有限的情况下, 请考虑使用Protobuf.

GitHub - vaishnav-mk/protobuf-example

2. MessagePack

MessagePack 是另一种二进制序列化格式, 以速度快, 结构紧凑而著称. 它比 JSON 更有效率, 同时与各种编程语言保持兼容.

• 何时选择: 当你需要在速度和跨语言兼容性之间取得平衡时, MessagePack 是一个不错的选择. 它适用于实时应用和对减少数据大小至关重要的情况.

3. BSON (二进制 JSON)

BSON 或二进制 JSON 是一种从 JSON 衍生出来的二进制编码格式. 它保留了 JSON 的灵活性, 同时通过二进制编码提高了性能. BSON 常用于 MongoDB 等数据库.

• 何时选择: 如果你正在使用 MongoDB, 或者需要一种格式来弥补 JSON 和二进制效率之间的差距, 那么 BSON 是一个很有价值的选择.

4. Apache Avro

Apache Avro 是一个数据序列化框架, 专注于提供一种紧凑的二进制格式. 它基于schema, 可实现高效的数据编解码.

• 何时选择: Avro 适用于schema演进非常重要的情况, 如数据存储, 以及需要在速度和数据结构灵活性之间取得平衡的情况.

与 JSON 相比, 这些替代方案提供了不同程度的性能改进, 具体选择取决于你的具体使用情况. 通过考虑这些替代方案, 你可以优化应用的数据交换流程, 确保将速度和效率放在开发工作的首位.

JSON, Protobufs, MessagePack, BSON 和 Avro 之间的差异

每个字节都很重要: 优化数据格式

在效率和速度至上的数据交换世界中, 数据格式的选择会产生天壤之别. 本节将探讨从简单的 JSON 数据表示到更高效的二进制格式(如 Protocol Buffers, MessagePack, BSON 和 Avro)的过程. 我们将深入探讨每种格式的细微差别, 并展示为什么每个字节都很重要.

开始: JSON 数据

我们从简单明了的 JSON 数据结构开始. 下面是我们的 JSON 数据示例片段:

{

  "id": 1,                                 // 14 bytes

  "name": "John Doe",                      // 20 bytes

  "email": "johndoe@example.com",          // 31 bytes

  "age": 30,                               // 9 bytes

  "isSubscribed": true,                    // 13 bytes

  "orders": [                              // 11 bytes

    {                                      // 2 bytes

      "orderId": "A123",                   // 18 bytes

      "totalAmount": 100.50                // 20 bytes

    },                                     // 1 byte

    {                                      // 2 bytes

      "orderId": "B456",                   // 18 bytes

      "totalAmount": 75.25                 // 19 bytes

    }                                      // 1 byte

  ]                                        // 1 byte

}                                          // 1 byte

JSON 总大小: ~ 139 字节

虽然 JSON 用途广泛且易于使用, 但它也有一个缺点, 那就是它的文本性质. 每个字符, 每个空格和每个引号都很重要. 在数据大小和传输速度至关重要的情况下, 这些看似微不足道的字符可能会产生重大影响.

效率挑战: 使用二进制格式减小尺寸

现在, 让我们提供其他格式的数据表示并比较它们的大小:

Protocol Buffers (protobuf):

syntax = "proto3";



message User {

  int32 id = 1;

  string name = 2;

  string email = 3;

  int32 age = 4;

  bool is_subscribed = 5;

  repeated Order orders = 6;



  message Order {

    string order_id = 1;

    float total_amount = 2;

  }

}

0A 0E 4A 6F 68 6E 20 44 6F 65 0C 4A 6F 68 6E 20 44 6F 65 65 78 61 6D 70 6C 65 2E 63 6F 6D 04 21 00 00 00 05 01 12 41 31 32 33 03 42 DC CC CC 3F 05 30 31 31 32 34 34 35 36 25 02 9A 99 99 3F 0D 31 02 42 34 35 36 25 02 9A 99 99 3F

Protocol Buffers 总大小: ~ 38 bytes

MessagePack:

(注意:MessagePack 是一种二进制格式, 此处的表示法非人工可读.)

二进制表示(十六进制):

a36a6964000000000a4a6f686e20446f650c6a6f686e646f65406578616d706c652e636f6d042100000005011241313302bdcccc3f0530112434353625029a99993f

MessagePack 总大小: ~34 字节

BSON (二进制 JSON):

(注意:BSON 是一种二进制格式, 此处的表示法非人工可读.)

二进制表示法 (十六进制):

3e0000001069640031000a4a6f686e20446f6502656d61696c006a6f686e646f65406578616d706c652e636f6d1000000022616765001f04370e4940

BSON 总大小: ~ 43 字节

Avro:

(注: Avro使用schema, 因此数据与schema信息一起编码.)

二进制表示法 (十六进制):

0e120a4a6f686e20446f650c6a6f686e646f65406578616d706c652e636f6d049a999940040a020b4108312e3525312e323538323539

Avro 总大小: ~ 32 字节

(这些替代方案的实际字节数可能会有所不同, 提供这些数字只是为了让大家有个大致的了解.)

现在你可能会感到奇怪, 为什么我们的程序会有这么多的字节数?

现在你可能想知道为什么有些格式输出的是二进制, 但它们的大小却各不相同. Avro, MessagePack 和 BSON 等二进制格式具有不同的内部结构和编码机制, 这可能导致二进制表示法的差异, 即使它们最终表示的是相同的数据. 下面简要介绍一下这些差异是如何产生的:

1. Avro:

• Avro 使用schema对数据进行编码, 二进制表示法中通常包含该schema.


• Avro 基于schema的编码可提前指定数据结构, 从而实现高效的数据序列化和反序列化.


• Avro 的二进制格式设计为自描述格式, 这意味着schema信息包含在编码数据中. 这种自描述性使 Avro 能够保持不同版本数据模式之间的兼容性.

2. MessagePack:

• MessagePack 是一种二进制序列化格式, 直接对数据进行编码, 不包含schema信息.


• 它使用长度可变的整数和长度可变的字符串的紧凑二进制表示法, 以尽量减少空间使用.


• MessagePack 不包含schema信息, 因此更适用于schema已预先知道并在发送方和接收方之间共享的情况.

3. BSON:

• BSON 是 JSON 数据的二进制编码, 包括每个值的类型信息.


• BSON 的设计与 JSON 紧密相连, 但它增加了二进制数据类型, 如 JSON 缺乏的日期和二进制数据.


• 与 MessagePack 一样, BSON 不包含schema信息.

这些设计和编码上的差异导致了二进制表示法的不同:

• Avro 包含模式信息并具有自描述性, 这导致二进制大小稍大, 但提供了schema兼容性.


• MessagePack 因其可变长度编码而高度紧凑, 但缺乏模式信息, 因此适用于已知模式的情况.


• BSON 与 JSON 关系密切, 包含类型信息, 与 MessagePack 等纯二进制格式相比, 会增加大小.

总之, 这些差异源于每种格式的设计目标和功能. Avro 优先考虑schema兼容性, MessagePack 注重紧凑性, 而 BSON 则在保持类似 JSON 结构的同时增加了二进制类型. 格式的选择取决于具体的使用情况和要求, 如schema兼容性, 数据大小和易用性.

优化 JSON 性能

JSON 虽然用途广泛, 在Web开发中被广泛采用, 但在速度方面也存在挑战. 这种格式的人类可读性会导致数据负载较大, 处理时间较慢. 因此, 问题出现了: 我们能够怎样优化JSON以使得它更快更高效? 在本文中, 我们将探讨可用于提高 JSON 性能的实用策略和优化方法, 以确保 JSON 在提供应用所需的速度和效率的同时, 仍然是现代 Web 开发中的重要工具.

以下是一些优化 JSON 性能的实用技巧以及代码示例和最佳实践:

1. 最小化数据大小:

• 使用简短, 描述性的键名: 选择简洁但有意义的键名, 以减小 JSON 对象的大小.

// Inefficient

{

  "customer_name_with_spaces": "John Doe"

}



// Efficient

{

  "customerName": "John Doe"

}

• 尽可能缩写:  在不影响清晰度的情况下, 考虑对键或值使用缩写.

// Inefficient

{

  "transaction_type": "purchase"

}

 

// Efficient

{

  "txnType": "purchase"

}

2. 明智地使用数组:

• 最小化嵌套: 避免深度嵌套数组, 因为它们会增加解析和遍历 JSON 的复杂性.

// Inefficient

{

  "order": {

    "items": {

      "item1": "Product A",

      "item2": "Product B"

    }

  }

}



// Efficient

{

  "orderItems": ["Product A", "Product B"]

}

3. 优化数字表示:

• 尽可能使用整数:  如果数值可以用整数表示, 请使用整数而不是浮点数.

// Inefficient

{

  "quantity": 1.0

}



// Efficient

{

  "quantity": 1

}

4. 消除冗余:

• 避免重复数据: 通过引用共享值来消除冗余数据.

// Inefficient

{

  "product1": {

    "name": "Product A",

    "price": 10

  },

  "product2": {

    "name": "Product A",

    "price": 10

  }

}



// Efficient

{

  "products": [

    {

      "name": "Product A",

      "price": 10

    },

    {

      "name": "Product B",

      "price": 15

    }

  ]

}

5. 使用压缩:

• 使用压缩算法:  如何可行的话, 使用压缩算法, 比如Gzip 或者Brotli, 以在传输过程中减少JSON负载大小.

// Node.js example using zlib for Gzip compression

const zlib = require('zlib');



const jsonData = {

  // Your JSON data here

};



zlib.gzip(JSON.stringify(jsonData), (err, compressedData) => {

  if (!err) {

    // Send compressedData over the network

  }

});

6. 采用服务器端缓存:

• 缓存 JSON 响应:  实施服务器端缓存, 以便高效地存储和提供 JSON 响应, 减少重复数据处理的需要.

7. 剖析与优化:

• 剖析性能:  使用剖析工具找出 JSON 处理代码中的瓶颈, 然后优化这些部分.

请记住, 你实施的具体优化措施应符合应用的要求和限制.

真实世界的优化: 在实践中加速

在这一部分, 我们将深入探讨现实世界中遇到 JSON 性能瓶颈并成功解决的应用和项目. 我们将探讨企业如何解决 JSON 的局限性, 以及这些优化为其应用带来的切实好处. 从 LinkedIn 和 Auth0 这样的知名平台到 Uber 这样的颠覆性科技巨头*, 这些示例为我们提供了宝贵的见解, 让我们了解在尽可能利用 JSON 的多功能性的同时提高速度和响应能力的策略.

1. LinkedIn集成Protocol Buffers:

挑战: LinkedIn 面临的挑战是 JSON 的冗长以及由此导致的网络带宽使用量增加, 从而导致延迟增加.
解决方案: 他们在微服务通信中采用了二进制序列化格式 Protocol Buffers 来取代 JSON.
影响: 这一优化将延迟降低了60%, 提高了 LinkedIn 服务的速度和响应能力.

2. Uber的H3地理索引:

• 挑战: Uber 使用 JSON 表示各种地理空间数据, 但解析大型数据集的 JSON 会降低其算法的速度.


• 解决方法 他们引入了H3地理索引, 这是一种用于地理空间数据的高效六边形网格系统, 可减少 JSON 解析开销.


• 影响: 这一优化大大加快了地理空间操作, 增强了 Uber 的叫车和地图服务.

3. Slack的消息格式优化:

• 挑战: Slack 需要在实时聊天中传输和呈现大量 JSON 格式的消息, 这导致了性能瓶颈.


• 解决方法 他们优化了 JSON 结构, 减少了不必要的数据, 只在每条信息中包含必要的信息.


• 影响: 这一优化提高了消息渲染速度, 改善了 Slack 用户的整体聊天性能.

4. Auth0的Protocal Buffers实现:

• 挑战: Auth0 是一个流行的身份和访问管理平台, 在处理身份验证和授权数据时面临着 JSON 的性能挑战.


• 解决方案: 他们采用Protocal Buffers来替代 JSON, 以编解码与身份验证相关的数据.


• 影响: 这一优化大大提高了数据序列化和反序列化的速度, 从而加快了身份验证流程, 并增强了 Auth0 服务的整体性能.

这些真实案例表明, 通过优化策略解决 JSON 的性能难题, 可对应用的速度, 响应和用户体验产生重大积极影响. 它们强调了在各种应用场景中考虑使用替代数据格式和高效数据结构来克服 JSON 相关缓慢的问题的重要性.

总结一下

在开发领域, JSON 是数据交换不可或缺的通用工具. 其人类可读格式和跨语言兼容性使其成为现代应用的基石. 然而, 正如我们在本文中所探讨的, JSON 的广泛应用并不能使其免于性能挑战.

我们在优化 JSON 性能的过程中获得的主要启示是显而易见的:

• 性能至关重要: 在当今的数字环境中, 速度和响应速度至关重要. 用户希望应用能够快如闪电, 即使是微小的延迟也会导致不满和机会的丧失.


• 尺寸至关重要: 数据有效载荷的大小会直接影响网络带宽的使用和响应时间. 减少数据大小通常是优化 JSON 性能的第一步.


• 替代格式: 当效率和速度至关重要时, 探索其他数据序列化格式, 如Protocal Buffers, MessagePack, BSON 或 Avro.


• 真实世界案例: 从企业成功解决 JSON 速度变慢问题的实际案例中学习. 这些案例表明, 优化工作可以大幅提高应用的性能.

在继续构建和增强Web应用时, 请记住要考虑 JSON 对性能的影响. 仔细设计数据结构, 选择有意义的键名, 并在必要时探索其他序列化格式. 这样, 你就能确保你的应用在速度和效率方面不仅能满足用户的期望, 而且还能超越用户的期望.

在不断变化的Web开发环境中, 优化 JSON 性能是一项宝贵的技能, 它能让你的项目与众不同, 并确保你的应用在即时数字体验时代茁壮成长.

我和你一样都经历过 家里蹲 狗都嫌 的尴尬时期，每天早上起来拿着手机不断刷着招聘软件，

海投几百份还是杳无音讯，在BOSS直拒、前程堪忧、失联招聘、猎空之间反复横跳...

还经历了十分灰暗的阶段，焦虑导致出现躯体化反应（头痛、严重失眠、吃不下东西等）

整夜整夜睡不着，躺下脑子都是工作、面试、人生选择带来的压力

不想出门社交，害怕面试。

其实，我想跟你说：裸辞并不是终点。

1.裸辞/辞职并不是终点

当我扛着我的键盘收拾东西离开工位，第一次对辞职的 “人走茶凉” 有了实感，

下午六点跟对我很好的前辈们告了别，公司离地铁有点远，和往常不一样，天还没黑，有黄昏相伴

三号线还是这么挤 还有点闷。

算起来这是第二次辞职，但第一次辞职找了一个礼拜就顺利入职了
，这次好像有点久，今年大家都在说被裁员、大环境差，同学领证成家的也不少。

我意识到人与人的节奏不同，而我好像又一次走到了岔路口，上一次这么慌张还是在高考前

即便我从来没后悔过离职这个决定，但还是会因为面试带来的压力感到局促不安

每次离职就像是一场查漏补缺的大考，对勇气，对储蓄，对知识点的大考

唯有拆迁和认亲能打破这场突如其来的考验。。。啊不是。。。我想说：

唯有行动能打破僵局！！

行动！！！去吃个冰淇淋！！。。。果然有灵感了

短暂的欢愉后，是与台灯的昼夜相守，与简历的交织缠绵

（简历编。。不是。。写不出来呀！！！）

反复改了几版之后确实多了一些“打招呼”的机会，但是实际面试机会还是屈指可数呀，

切！又不是第一次没人要🤡，拒绝我的多的去了，得从巴黎排到广州...

继续努力，等待运气，厚积薄发

2.当知识脱离了考试，真理和美丽才慢慢浮现

2.1 心态调整（分享一下最近对我有帮助的书）

• 《见识》 - 吴军

这是第一年出来工作，遇上了很好的领导送我的书，每当迷茫的时候再拿出来翻翻有了不一样的感悟，很多我们看上去非做不可的事情，其实想通了并没有那么重要，无论在职场上还是在生活中，提高效率都需要从拒绝伪工作开始，有些苦是可以不用吃的，苦难并非造就人类。

幸福是目的，成功是手段

• 《意志力》 - 罗伊·鲍迈斯特

技术行业的人都知道学习是个漫长/终身的事情，跟考公考研短期爆发式集中不同，我们更需要坚持、长期一点点做下去，我认识到所有人的意志力都是有限的，使用就会消耗，压力也并非与动力画等号，人也跟机器一样需要“充电”和合理分配，每个人的节奏和身体承受能力也不同。

• 《被讨厌的勇气》 - 岸见一郎、古贺史健编著

在心情动荡的时期，这本书就像开了一盏加热灯一样在一旁无声陪伴，那会我就像婴儿一样无意识地紧紧抓着自己的头发，直到我睁开眼看见了、意识到了，放下禁锢着工作、生活、交友的课题的手，更能轻松地赶路了。

生活的方式千千万，人生的意义，由我自己决定

• 《法律常识全知道》 - 李桥

读书的时候没有一门跟社会接轨的课程，毕业了也一直专研技术，导致一毕业不知道劳动合同/租房有什么坑，把仲裁和维权看得过于艰难，法律条例密密麻麻 一时间不知从何下手，这本书就很适合我这种来一线城市打工没什么社会经验的小白，用简单的案例植入“NPC游戏”攻略，和《影响力》这本书加一起简直就是进城防骗指南哈哈哈

免费法律援助电话：12348

2.2 前端学习路线图：

各位摸鱼的小伙伴下次见，这篇便是我的2023年终总结：

裸辞不是终点，唯有行动才能打破僵局，当知识脱离了考试，真理和美丽才慢慢浮现。

参考资料：

前端学习路线

我是一个普普通通的前端开发工程师，

除了我的同事，在这个圈子内没人认识我。

“前端开发工程师”，老实讲，我很喜欢这个称呼，我对一些圈外朋友总是这么称呼我自己，当然我的内心和认识我的人都知道，我就是一个“写代码的”。

初见

在2019年，我大专毕业，那时候的学长学姐总和我开玩笑说，以后毕业的我们都会去卖保险，跑销售，那时候的我不以为意，以为只是自我调侃，后来发现人家说的是真的，根本不是开玩笑。我在某大厂做了近3个月的电销，那时候我还是我们班工资最高的人，但不得不说这份职业我根本不喜欢。后来，我大学的班花邓某（真的很漂亮）有一次和我聊天，那阵子她在某大厂做审核。她说她打算去培训前端，问我有没有兴趣。那时候的我觉得计算机啊，编程啊都是精英人群，我这等人也能从事吗？我还打趣的问她，参与前端和高考上清华哪个难？（可见那时候的我对这个想都不敢想）

学习

在19年6月毕业后，我就失业了。我根本想不到大专毕业生能从事什么好的工作，也不清楚我能做些什么。后来我一想，那不妨去培训吧，这样就能和班花做同学，有一起接触的空间和机会了！然后我就开始联系她，但是不得不说，她有强烈的拖延症，她根本对这件事没放在心上。那就自学吧！如果我先学会了，然后等她入门的时候，我就可以教她了！她一定对我刮目相看！嘿嘿！我当时是这样想的没错。我首先找到了培训机构，找他们要到了课程大纲，然后自己逐一的根据大纲上的内容，在网上找视频。不得不说，bilibili大学真的很好用。我的html,css,js都是师承的pink老师，他讲的真的很棒，后来vue就跟着180的科比老师学习，不得不说，这两位的视频对我来说有着举足轻重的作用。那时候第一次学习编程，很多东西都是死记硬背的（切记不要这么做），你很难想象到一个人会去背各种元素的作用以及api。那时候学习的过程还是很快乐的，每天都能接触到新知识，在这就是看着那些视频的进度，想象着看完后自己就能毕业的样子，还是很期待的。甚至说，根据视频模仿了一个很小的功能，然后和自己父母分享的时候，他们都在夸我，现在回想起来，那是我从事前端这么多年来最快乐的时光。

毕业

20年9月的时候，大概经历了近10个月的自学，我决定出山找工作了，我来到了广东。当时我具备的技能有html,css,js,vue2,ts。后来就进入了刷面试题的阶段，有很多面试题完全都是死记硬背的，印象最深刻的就是vue2的响应式原理和nextTick原理，完全是根据百度来的台词去阐述。虽然说现在的我让我自己手写这些都不成问题。不得不说，准备的面试题可以准备，但是项目经验，一些细节可真是苦恼了我。一些对项目，业务比较感兴趣的面试官，我通常都会挂在这里，因为没有任何的工作经验。

我还记得，我面试的第一家公司，是在一个星期天，他们需要找开发小程序的人，最后聊完了技术之后;

面试官：“我看你的简历上写着你上一份工作在武汉有着6k/月，是吗？”

我：“是的”（在这里，我和大多数人一样，包装了，美化了自己的简历）

面试官：“据我所知，不到1年工作经验的专科生，是不可能在武汉有6k/月的，当然这只是我个人的片面的看法，江东自古多才俊嘛”（这就是他的原话，我此生都忘不了）

我内心：“尴尬，脸红，我要逃！快让我走！”

我也还记得，我第一次收获的offer的时候，是一家在CBD，25层高楼的公司，在我毕业以前，我一直都以为能在那里工作的人都是精英，商业大佬。这家公司他让我试岗三天，试岗第一天有个题目是让人手写轮播图和使用element做一个分页功能。我还是通过网友，帮我远程控制我的电脑才完成的这个任务，不过很遗憾，我自己选择了离开这家公司，原因嘛，因为我每天挤不上地铁，再者就是，那家公司气氛感觉很压抑。21年的我还很年轻，有这样的果敢和勇气，如果说24年的我，肯定会忍耐这两点。

第一份工作

2021年3月，在经历过长达3个月的求职经历后，我已经被磨练成了面试机器人。终于找到了一家公司，给我的薪水也很不错，至今我都觉得那家公司是宝藏公司，人数500+，我在那里上班1年没有任何加班经历，需求也非常简单，用vue改改东西，写下静态，一周5天能摸鱼3天。就姑且叫那家公司为X公司吧，还有一个特别搞笑的经历，在X面试的时候，老大问我，“你的项目上有分页查询，这个功能是怎么做的？”，我的回答是：“这个功能是前端做的”。真的很难崩有木有！！！他居然要我了！后来在X的日子，开始过起了神仙般的日子，温饱问题总算是解决了，开始每天接触前端这个圈子，和群友聊天，早上刷各种社交软件。 那时候下班了自己也会回家学习，心里也有一个大牛梦，想着自己能不能做出一些很棒的产品开源出去，就像那些社区圈子的名人一样。还记得那时候跟着视频学习写mini-vue框架，也买了很多课程，觉得投资自己是一笔超值的买卖，然而时至今日那些视频都没有看完。在X公司混到了要转正的那一天，还是蛮忐忑的，结果老大把我单独喊出去谈话，到这里已经开始觉得事情不对了。老大说我的表现还不能满足转正，要继续观察一个月，如果说看到这里，可能很多人会说垃圾公司快跑，但我始终为我当时没有赌气离职感到自豪和开心。

ps：有趣的事，在22年的时候我和带我的女同事都离职了，我们聊天的时候说谈起来这件事，她告诉我，关于我是否能转正的问题，是老大先去问她的意见，问我技术怎么样，她把我夸了一顿。当我知道这个事情的时候，泪目了。

第二份工作

在X公司混了1年左右后，说实在的，我的任务实在是太简单了，上班大多数时间都在摸鱼和自学，没有接触到真正的业务。后来就跑路来到了第二家公司，且叫Y公司吧。在这里我接手的一个项目是从0到1实现的，这正是我想要的，能够完整的学习到项目经验，太妙了。那阵子加班的时间就开始多起来，不过也还挺满意的，能学习到真正的业务。不过这种情况持续了大概半年，新鲜感就退去了，我发现我所做的事情，就是“搬砖”。业务上需要用到什么东西，直接搜一个开源的，然后自己管理一下状态，和后端交互一下，结束了，基本上所有的我参与的业务都是这样的模式，我开始懈怠了，早上每天来了先吃半个小时早饭，然后刷新闻，甚至直到下午才开始做活，因为这些事情实在是太无聊了。在下班后，我开始探索代码的世界，开始着手实现自己刚出道的时候的梦想----实现一个开源产品。那时候的我仿佛就是为了写而去写，我根本不知道要写什么，解决什么样的问题，完全就是照着vue，react这种前端框架去抄，而且实现的非常玩具，没坚持多久就放弃了这个天真的想法。

再见

突然有一天，班花邓某突然联系我了，她告诉我她已经辞职去培训了，问我要不要一起。我得承认，收到她消息的时候小鹿乱撞了，我告诉了她我已经从事前端的工作了，她大为开心，说要我帮帮她，有什么不会的就来问我，我很开心，第一次明白被人需要是什么感受。后来她在培训班毕业了，她让我来面试她，不得不说教她的都是什么妖魔鬼怪，我问她对Vue的理解，她居然背文档说，“vue是一款渐进式框架...”。我问她什么是“渐进式”，她就不知道了。那阵子和她交流了很多，虽然不在一个城市，但还是很开心。另外确实漂亮的女生真的在我们这个行业很有优势，她不到1个月就找到工作，而且她提出期望9k，人家面试官给她10k。

JS为我做的三件事

1. 工作，

这第一件事就是让我有了生存的技能，找到了一份工作，首先是能生存下来了。说真的，在我参加工作之后，程序员人数膨胀之前，我一直都认为程序员是普通家庭的专科生一项比较好的出路，但现在的话的来说，我可能也会偏向于劝退专科生的萌新吧，这张图是我专科，4年工作经验，计算机专业的求职经历，如果你能承担像这样的挫折感的话，并且你比较自律，热爱编程，我也鼓励你坚持梦想！

其实我目前的状态也很难讲，因为这是一个离奇的经历。我们公司最近的效益不太好，可能是我们部门的产品没能带来什么收益，已经开始裁员了，而且很过分的一件事情是，我和我的部门同事，已经3个月没有发薪水了！这件事超级严重，根据过往的经验和数据的话，大概是要凉凉的节奏。

我们部门一个资历比较老的同事，就带头跑路，然后搞的其他人也就跟风，然后吧，好巧不巧，他们问我跑不跑，我深知专科生找工作无比艰难（请参考上面我的BOOS图），我只能相信公司，会好起来的。

这件事无论说到哪里，大家给我的建议都会是立马跑路，然后去仲裁，可能现在看文章的你也是这么想的，但是我很怕，我怕失去工作，我已经适应了现在的环境，我没办法面对接下来的未知挑战，这和我的个人性格有关系，我决定留下来，在赌一下自己的前程，或者等公司裁掉我，没准还有补偿不是吗？

好巧不巧，我们部门资历老的全跑了，老大让我来当老二了，我听到这个消息的时候是懵逼的，老大给我布置了一系列的任务，包括架构一下前端，招人等事宜，我提道工资呢？老大说会给你发的，公司在等机会。也就是典型的加量不加价，其实今天为什么能来更新这篇文章，也是因为我来架构前端，打算在掘金调研一套eslint规则，因为这里的大佬比较多，技术文章质量也还是很高的。

我想到这里，其实觉得我的平台，舞台也是蛮大的，发挥的机会很多，（虽然没发工资）。于是乎我提出了一系列计划上报了老大，包括技术从Vue2转到react18,前端组件库改用storybook等。除了使用react18这套方案被否决了，其余的也都通过了。

说真的，对这份工作的未来也是有极高的不确定性，如果你不敢承受10%的暴跌，那就会错过1%的大涨，不是吗？

2. 爱情，

我在2023年的时候，在某书上认识了一个江西的女生，我们聊的很投缘，我们甚至是一个大学毕业的，她在武汉上的大学。我们有着共同的爱好，经常聊天就是半天的时间就过去了。而且，我们经常分享自己的一些身边事给对方，一些实事的热点新闻的看法，我们也出奇的一致，她在朋友圈发的照片也很好看，有一次，我给她发消息，她过了一段时间没有回复我，我就开始想着，她在干嘛，为什么还没有回，开始焦急，情绪被左右了，我明白了，我确实喜欢他了。

当从朋友，也可能是网友的关系，变成了爱慕的时候，我对她的态度就变了，我开始变得很有占有欲，开始看她某书下的评论有没有其他男孩子，那阵子的我，真的很丑陋。

我开始着急了，我决定更近一步试探一下，我邀请她一起玩某某荣耀，她也答应的很爽快，那时候我还以为我成功了，有戏！没想到，当天，我上号后，她邀请我，我发现！她居然带了她闺蜜和一个男生，我纯纯无语。。。而且游戏过程中，他们三个互动比较多，基本上我就是路人甲，那晚挺失望的反正。

到了她的生日，我说我送你一个生日礼物吧！她也婉拒了，从那时候开始，我们的距离就变得远了。到今天，2024，3，27号，我们大概40多天没说过话了。

到这里，和js有什么关系呢？

我即将告诉你我人生中，做的最小丑的决定

我想的是，女生都比较幕强，我要给她展现一个技术大佬的人设！没错，在某个夜晚我是这么想的，晚上下班后，我上某里云租了一个最便宜的服务器，然后用express + react.js（没错，我个人更喜欢react，这也是我为什么尝试说服领导转react的原因，hhh）花了一晚上时间，写了一个聊天室功能，还内置了许多她喜欢的东西作为背景，icon，logo，然后我部署在了服务器上。

第二天，我立马把域名分享给她，期待她的回复！还俏皮的说，能打败微信吗？我以为这样，她会对我五体投地的佩服，结果她只回了一个 “6”，然后补充“哈哈哈哈哈哈”

那时候我觉得，她是对这种技术不感冒，她只对迪士尼和追星有兴趣，她每周都会去迪士尼和一只小狐狸合影，请注意是每周。而且她会追每一个在她城市开演唱会的人，某杰，某谦，某棋。我以为她是喜欢这些，后来我才发现，她其实是对我没兴趣而已，意识到我越界了，有意疏远我。

3. 开源，

我用js尝试写过很多开源，也想成为一个为社区有过贡献的人，但后来发现根本没什么用，自己无论写什么，都已经有了前人的库，比我好，比我成熟，比我火。我最近一直在思考，如果我把学习这些，折腾这些的时间用来学习一门其他的事情，比如吉他，或者打游戏，我会不会更快乐？都说1-3年的前端交流群里都在聊技术，4-5年都在聊业务，5年以上的都在聊家庭和钓鱼，看得出，这就是现实，极少有人能从技术中脱颖而出，我也认清了自己。

一、背景

转转集团旗下有多款APP产品，随着业务发展，各APP发版频率变高。在持续交付的背景下，渠道包更新存在以下几个效率问题：

（1）Android渠道包提交应用市场审核，工作重复&人工成本高  

（2）公司目前存在多个APP、需更多人支持，有培训成本

（3）每次发版需要人工通知项目成员渠道包审核进度 

  针对以上问题，我们设计开发了渠道包自动更新后台，用来解决渠道更新的效率问题。

二、方案调研

1、基于业务现状，做了技术调研和逻辑抽象

  不同APP支持的渠道不同，不同渠道更包api不同，如下图：

针对以上调研结果，我们将通用的逻辑统一封装开发，将差异点进行配置，做到灵活配置可扩展。

2、整体的实现方案演变

初期方案，每个应用市场单独提审（需要先选择物料，选好物料后上传包文件，文件上传成功后再点击提交审核），多个应用市场需要重复该操作。

上线运行了一段时间后，发现存在一些问题：单个市场提交步骤繁琐、多个应用市场需要分开多次提交。这些步骤是重复且可简化的，因此我们又对提审的过程做了封装，提供批量上传的入口，简化交互过程，做到一键提审。以下是当前运行的第二版方案：

第二版方案上线后，提审同学只需要在入口处选择要更新的应用市场，然后一键上传全部物料，再点击提审按钮即可提审成功。代码内部会处理具体的逻辑，比如：根据配置规则将物料匹配到对应市场、自动匹配包文件进行提审。

三、方案设计

自动上传包含以下核心模块：

• APP管理：支持配置多个APP信息，包括转转、找靓机、采货侠等


• 包管理：支持下载不同渠道，不同版本的包


• 物料管理：包括历史物料的选择，和新增物料的存储（icon、市场截图）


• 提交审核：包括包下载、物料下载，支持按照APP配置账号密码提交审核


• 消息提醒：对提交的结果和审核的结果进行消息通知

实现效果：

提审前信息确认，选择APP，可选择单个或者多个渠道，系统自动选择包地址，用户选择物料后可一键提审多应用市场。操作简单便捷，使用成本低

提审后发送消息通知，便于各方了解渠道的审核结果，对审核异常信息进行及时干预。同时自动存储不同版本的审核记录，方便后续分析。

四、总结

渠道包自动更新功能，节省了大量的提交审核人力成本，打通了Android整体的持续交付过程，降低了人工学习成本。之后我们也会针对各种体验问题进行不断的改进和更新～

大家好，本篇文章仍然聊聊kotlin官方做的一些优化工作，主要包括以下三个方面：

接下来就带大家介绍下上面三个特性。

一. 数据对象data object的支持

该特性由kotlin1.7.20插件版本提供，并处于实验阶段。

这个特性主要是和原来的object声明的单例类的toString()方法输出有关，在了解这个特性之前，我们先看下下面一个例子：

object Single1



fun main() {

    println(Single1)

}

输出：

这个输出本质上就是一个类名、@、地址的拼接，有时候你想要打印输出的仅仅是类名，就得需要重写下toString()方法：

object Single1 {



    override fun toString(): String {

        return "Single1"

    }

}

然后再看一个密封类的例子：

sealed interface Response {

    

    data class Success(val response: String): Response

    

    data class Fail(val error: String): Response

    

    object Loading : Response

    

}



fun main() {

    println(Response.Success("{code: 200}"))

    println(Response.Fail("no net"))

    println(Response.Loading)

}

输出：

可以看到，大家都是密封子类，但就这个Loading类的输出比较"丑陋"，没有上面两个兄弟类的输出简洁清爽。

接下来我们就要介绍下主人公数据对象data object了，这个东西其实使用起来和object一模一样，核心的区别就是前者的toString() 更加简洁。

接下来从一个例子一探究竟：

data object Single2



fun main() {

    println(Single2)

}

看下输出：

输出是不是比上面的object Single1更加简单明了。最重要的是在密封类中使用效果更加，我们把上面密封类Loading声明为data object：

    data object Loading : Response

看下最终的输出结果：

这下子输出结果是不是清爽更多！！

讲完了应用，我们再java的角度看下其背后的实现机制，相比较于object，data object会多了下面这三个重写方法：

public final class Single2 {

    

   @NotNull

   public String toString() {

      return "Single2";

   }



   public int hashCode() {

      return -535782198;

   }



   public boolean equals(@Nullable Object var1) {

      if (this != var1) {

         if (!(var1 instanceof Single2)) {

            return false;

         }



         Single2 var2 = (Single2)var1;

      }



      return true;

   }

}

我们需要关心的toString()方法就是直接重写返回了当前的类名。

如果想要使用这个特性，我们只需要增加如下配置即可：

compileKotlin.kotlinOptions {

    languageVersion = "1.9"

}

二. @Repeatable注解优化

该特性由kotlin1.6.0插件版本提供优化。

在了解这个特性之前，我们先回忆下@Repeatable这个注解在java中的使用：

如果一个注解在某个方法、类等等上面需要重复使用，那就需要@Repeatable帮助。

• 首先定义需要重复使用的注解

@Retention(RetentionPolicy.RUNTIME)

@Target(ElementType.TYPE)

@Repeatable(Fruits.class)

public @interface Fruit {

    String name();

    String color();

}

• 然后定义注解容器，用来指定可重复使用的注解类型

@Retention(RetentionPolicy.RUNTIME)

@Target(ElementType.TYPE)

public @interface Fruits {

    Fruit[] value();

}

然后就可以在代码中这样使用：

@Fruits({

        @Fruit(name = "apple", color = "red"),

        @Fruit(name = "origin", color = "yellow"),

})

public class Detail {

}

大家有没有发现，可重复注解定义起来还是由一丢丢的麻烦，接下来轮到我们kotlin重磅出击了。先看下面一个例子：

@Repeatable 

annotation class Animal(val name: String)

在kotlin中我们只要声明一个需要重复使用的注解即可，kotlin编译器会自动帮助我们生成注解容器@Animal.Container，然后我们就能在代码中这样使用：

@Animal(name = "dog")

@Animal(name = "horse")

public class Detail {

}

是不是非常简单便捷了。

如果你偏要显示指明一个包含注解，也可以，通过以下方式即可实现：

@JvmRepeatable(Animals::class)

annotation class Animal(val name: String)



annotation class Animals(val value: Array)

然后除了上面的使用方式，你在kotlin中还可以这样使用：

@Animals([Animal(name = "dog"), Animal(name = "dog")])

class Detail {

}

请注意：

另外，其实这个特性kotlin早就支持了，只不过kotlin1.6.0插件版本之前，kotlin这个特性只只支持RetentionPolicy.SOURCE生命周期的注解，并且还和java的可重复注解不兼容。

总结

这两个小技巧相信在大家日常开发中还是比较实用的，希望本篇能对你有所帮助。

参考文章：

Improved string representations for singletons and sealed class hierarchies with data objects

Repeatable annotations with runtime retention for 1.8 JVM target

1.Android Room 数据库的坑

在用Room数据库的时候 发现有需要一个字段的条件合到一起去写这个SQL

 @Query("SELECT * FROM 表名 WHERE 字段A = '1' and 字段B <= :Time " +

            "and 字段B >= :Time and 字段C <= :BTime and 字段C >= :BTime " +

            "and '(' || 字段D is null or 字段D = '' || ')'")

    List selectList(String Time, String BTime);

这里面的 “ ||” 是Room里面独特的表达方式 是替代了java里面的“+”号

正常在android中 使用 是这样的

String sql = "SELECT * FROM 表名 WHERE 字段A = '1' and 字段B <= "+传入的参数+" " +

            "and 字段B >= "+传入的参数+" and 字段C <= "+传入的参数+" and 字段c >= "+传入的参数+" " +

            "and '(' "+" 字段D is null or 字段D = '' "+" ')'"





cursor = db.rawQuery(sql, null);

而在Room 中 用 “||” 代替了 “+”

2.Android Room 查询语句的坑

@Query("SELECT * FROM 表名 WHERE 字段A = '0' order by id desc")

List selectList();

假如你正在查询一张表的面的内容,然后忽然跑出来一个异常

# [Android RoomDatabase Cruash "Cursor window allocation of 4194304 bytes failed"](https://stackoverflow.com/questions/75456123/android-roomdatabase-cruash-cursor-window-allocation-of-4194304-bytes-failed)

奔溃日志:

android.database.CursorWindowAllocationException: Could not allocate CursorWindow '/data/user/0/cn.xxx.xxx/databases/xxx.db' of size 2097152 due to error -13.

	at android.database.CursorWindow.nativeCreate(Native Method)

	at android.database.CursorWindow.(CursorWindow.java:139)

	at android.database.CursorWindow.(CursorWindow.java:120)

	at android.database.AbstractWindowedCursor.clearOrCreateWindow(AbstractWindowedCursor.java:202)

	at android.database.sqlite.SQLiteCursor.fillWindow(SQLiteCursor.java:147)

	at android.database.sqlite.SQLiteCursor.getCount(SQLiteCursor.java:140)

	at yd.d.m(SourceFile:21)

	at cn.xxx.control.y.y0(SourceFile:1)

	at e5.y.p(SourceFile:230)

	at e5.y.l(SourceFile:1)

	at e5.y.E(SourceFile:1)

	at cn.xxx.cluster.classin.viewmodel.SessionViewModel$d.invokeSuspend(SourceFile:42)

触发原因

• Room 对应的 Sqlite 数据库，其对 CursorWindows 分配的大小是有限制的，最大为 2M，超过之后会发生上述崩溃闪退现象（偶现且难以复现的 bug）

解决方法

需要业务方梳理这块的业务，优化数据库的调用，如果明确知道在一个方法里面会调用多个数据库的方法，需要让 controller 提供新的方法，且这个 controller 层的方法需要添加 @Transaction 进行注解，从而保证在同一个事物内进行数据库操作，以此避免 CursorWindows 大小超过 2M

那么问题来了 @Transaction 这个注解是干嘛的呢

翻译 事务的意思

@Transaction

@Query("SELECT * FROM 表名 WHERE 字段A = '0' order by id desc")

List selectList();

接着 问题完美解决

今天想和大家分享的一个技术是 SSE 流式传输 。如标题所言，通过 SSE 流式传输的方式可以让我们不再通过轮询的方式获取服务端返回的结果，进而提升前端页面的性能。

对于需要轮询的业务场景来说，采用 SSE 确实是一个更好的技术方案。

接下来，我将从 SSE 的概念、与 Websocket 对比、SSE 应用场景多个方面介绍 SSE 流式传输，感兴趣的同学一起来了解下吧！

什么是 SSE 流式传输

SSE 全称为 Server-sent events , 是一种基于 HTTP 协议的通信技术，允许服务器主动向客户端（通常是Web浏览器）发送更新。

它是 HTML5 标准的一部分，设计初衷是用来建立一个单向的服务器到客户端连接，使得服务器可以实时地向客户端发送数据。

这种服务端实时向客户端发送数据的传输方式，其实就是流式传输。

我们在与 ChatGPT 交互时，可以发现 ChatGPT 的响应总是间断完成。细扒 ChatGPT 的网络传输模式，可以发现，用的也是流式传输。

SSE 流式传输的好处

在 SSE 技术出现之前，我们习惯把需要等待服务端返回的过程称为长轮询。

长轮询的实现其实也是借助 http 请求来完成，一个完整的长轮询过程如下图所示：

从图中可以发现，长轮询最大的弊端是当服务端响应请求之前，客户端发送的所有请求都不会被受理。并且服务端发送响应的前提是客户端发起请求。

前后端通信过程中，我们常采用 ajax 、axios 来异步获取结果，这个过程，其实也是长轮询的过程。

而同为采用 http 协议通信方式的 SSE 流式传输，相比于长轮询模式来说，优势在于可以在不需要客户端介入的情况下，多次向客户端发送响应，直至客户端关闭连接。

这对于需要服务端实时推送内容至客户端的场景可方便太多了！

SSE 技术原理

1. 参数设置

前文说到，SSE 本质是一个基于 http 协议的通信技术。

因此想要使用 SSE 技术构建需要服务器实时推送信息到客户端的连接，只需要将传统的 http 响应头的 contentType 设置为 text/event-stream 。

并且为了保证客户端展示的是最新数据，需要将 Cache-Control 设置为 no-cache 。

在此基础上，SSE 本质是一个 TCP 连接，因此为了保证 SSE 的持续开启，需要将 Connection 设置为 keep-alive 。

Content-Type: text/event-stream

Cache-Control: no-cache

Connection: keep-alive

完成了上述响应头的设置后，我们可以编写一个基于 SSE 流式传输的简单 Demo 。

2. SSE Demo

服务端代码：

const express = require('express');

const app = express();

const PORT = 3000;



app.use(express.static('public'));



app.get('/events', function(req, res) {

    res.setHeader('Content-Type', 'text/event-stream');

    res.setHeader('Cache-Control', 'no-cache');

    res.setHeader('Connection', 'keep-alive');



    let startTime = Date.now();



    const sendEvent = () => {

        // 检查是否已经发送了10秒

        if (Date.now() - startTime >= 10000) {

            res.write('event: close\ndata: {}\n\n'); // 发送一个特殊事件通知客户端关闭

            res.end(); // 关闭连接

            return;

        }



        const data = { message: 'Hello World', timestamp: new Date() };

        res.write(`data: ${JSON.stringify(data)}\n\n`);



        // 每隔2秒发送一次消息

        setTimeout(sendEvent, 2000);

    };



    sendEvent();

});



app.listen(PORT, () => {

    console.log(`Server running on http://localhost:${PORT}`);

});

客户端代码：

<!DOCTYPE html>

<html lang="en">



<head>

    <meta charset="UTF-8">

    <title>SSE Example</title>

</head>



<body>

    <h1>Server-Sent Events Example</h1>

    <div id="messages"></div>



    <script>

        const evtSource = new EventSource('/events');

        const messages = document.getElementById('messages');



        evtSource.onmessage = function(event) {

            const newElement = document.createElement("p");

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

            newElement.textContent = "Message: " + eventObject.message + " at " + eventObject.timestamp;

            messages.appendChild(newElement);

        };

    </script>

</body>

</html>

当我们在浏览器中访问运行在 localhost: 3000 端口的客户端页面时，页面将会以 流式模式 逐步渲染服务端返回的结果：

需要注意的是，为了保证使用 SSE 通信协议传输的数据能被客户端正确的接收，服务端和客户端在发送数据和接收数据应该遵循以下规范：

服务端基本响应格式

SSE 响应主要由一系列以两个换行符分隔的事件组成。每个事件可以包含以下字段：

data：事件的数据。如果数据跨越多行，每行都应该以data:开始。

id：事件的唯一标识符。客户端可以使用这个ID来恢复事件流。

event：自定义事件类型。客户端可以根据不同的事件类型来执行不同的操作。

retry：建议的重新连接时间（毫秒）。如果连接中断，客户端将等待这段时间后尝试重新连接。

字段之间用单个换行符分隔，而事件之间用两个换行符分隔。

客户端处理格式

客户端使用 EventSource 接口监听 SSE 消息：

const evtSource = new EventSource('path/to/sse');

evtSource.onmessage = function(event) {

    console.log(event.data); // 处理收到的数据

};

SSE 应用场景

SSE 作为基于 http 协议由服务端向客户端单向推送消息的通信技术，对于需要服务端主动推送消息的场景来说，是非常适合的：

SSE 兼容性

可以发现，除了 IE 和低版本的主流浏览器，目前市面上绝大多数浏览器都支持 SSE 通信。

SSE 与 WebSocket 对比

看完 SSE 的使用方式后，细心的同学应该发现了：

SSE 的通信方式和 WebSocket 很像啊，而且 WebSocket 还支持双向通信，为什么不直接使用 WebSocket ？

下表展示了两者之间的对比：

可以发现，SSE 与 WebSocket 各有优缺点，对于需要客户端与服务端高频交互的场景，WebSocket 确实更适合；但对于只需要服务端单向数据传输的场景，SSE 确实能耗更低，且不需要客户端感知。

参考文档

developer.mozilla.org/zh-CN/docs/…

需求场景

我们在开发应用的时候经常会遇到先登录，登录成功后再跳转到目标页面。比如商品详情页面我们点击购买必须要先登录，登录完成才能去下单支付。针对这种场景，我们一般有两种做法：

第一种我们就不谈了产品经理不同意🐶。第二种我们一般是在 onActivityResult 里面获取到登录成功，然后根据 code 跳转到目标页面。这种方式缺点就是我们要在每个页面都处理相同的逻辑还有定义各种 code，如果应用里面很多这种场景也太繁琐了。那有没有统一的方式去处理这种场景就是我们今天的主题了。

封装方式

我们的应用是组件化的，APP 的页面跳转使用了 Arouter。所以我们统一处理使用 Arouter 封装。直接上代码

fun checkLoginToTarget(postcard: Postcard) {//Postcard 是 Arouter 的类

    if (User.isLogin()) {

        postcard.navigation()

    } else {

        //不能使用 postcard 切换 path 直接跳转，因为 group 可能不同，所以重新 build

        ARouter.getInstance().build(Constant.LOGIN)

            .with(postcard.extras)//获取携带的参数重新转入

            .withString(Constant.TAGACTIVIFY, postcard.path)//添加目标路由

            .navigation()

    }

}

//登录成功后在登录页面执行这个方法

fun loginSuccess() {

    val intent= intent

    val target = intent.getStringExtra(Constant.TAGACTIVIFY)//获取目标路由

    target?.apply { 

        if (isNotEmpty()){

            val build = ARouter.getInstance().build(this)

            val extras = intent.extras//获取携带的参数

            if (extras != null) {

                build.with(extras)

            }

            build.navigation()

        }

    }

    finish()

}

代码加了注释，使用 Kotlin 封装了顶层函数，登录页面在登录成功后跳转到目标页面，针对上面的场景直接调用 checkLoginToTarget 方法。

checkLoginToTarget(ARouter.getInstance().build(Constant.PAY_PAGE).withInt(Constant.GOOD_ID,id))

通过 Arouter 传入下单支付的路由地址，并且携带了商品的 ID，生成了 Postcard 参数。登录成功后能带着商品 ID
直接下单支付了。

最后

如果项目里没有使用路由库可以使用 Intent 封装实现，或者别的路由库也可以用上面的方式去做统一处理。

哈喽,大家好 我是 xy👨🏻‍💻。今天我们来聊聊一个面试时超级敏感但又不得不面对的问题——离职原因💢

找工作面试被问离职原因，千万不要直接说出你为什么从上家公司离职的真实原因！！！

当老实人要吃亏的！！！

其实，大部分真实的离职原因都是每家公司或多或少会遇到的，但如果直接说出来，很可能会让面试官担心你入职后也会因为同样的原因离职哦！💢

😉 所以，作为一个聪明的求职者，我们应该如何回答这个问题呢？

6 个常见的离职原因

首先，让我们来看看这 6 个常见的离职原因❌，以及它们的“禁忌”回答方式吧！🚫

🎯 工资太低

🚫 禁忌回答：因为前公司给的工资太低了，我实在是受不了了。

🎯 加班严重

🚫 禁忌回答：前公司加班太严重了，我身体都垮了。

🎯 领导傻 X

🚫 禁忌回答：前领导简直就是个傻 X，根本不懂管理。

🎯 被裁员

🚫 禁忌回答：我之前的公司裁员，我被无辜波及了。

🎯 无法升职

🚫 禁忌回答：我在前公司干了几年，但一直升不上去。

🎯 同事相处不和谐

🚫 禁忌回答：前公司的同事们都太奇葩了，我实在受不了。

👀 看到了吗？这些回答都是大忌，因为它们会让 HR 觉得你不稳定、有负面情绪、甚至可能是个问题员工。那么，正确的回答方式是什么呢？别急，我们接着往下看！✅

🎯 工资太低

✅ 回答模板：HR 您好!我过去 2 年，在公司和领导的帮助下，我在技术和能力方面有了很大提升，为公司开发的各种工具和库，极大地提高了项目开发效率，领导对我很认可，但公司的薪资结构有一些硬指标，无法满足我的涨薪需求，所以想看看市场上的新机会，寻找一个可以长期稳走发展的平台。

🎯 加班严重

✅ 回答模板：HR 您好!在上家公司，我的工作效率较高，能按时保质保量地完成工作，但前司会定期统计加班时长，并以此进行考核，导致大部分人为了加班而加班，效率非常低，我个人并不反对加班，但这种低效的常态化 996，我并不认可，我希望能在更人性化管理的公司里发挥优势。

🎯 领导傻 X（这个有点难，但我们可以尽量委婉）

✅ 回答模板：HR 您好!因为前公司的工作职贵划分比较固定，每个人负责的业务比较少，对于所负责的开发工作，我已经没有什么新知识可以学的了，我希望职业生涯是一个持续的学习和提升的过程，并且在自己具备了相关业务技能经验后，也想迎接一些新的挑战。

🎯 被裁员

✅ 回答模板：HR 您好!前公司当时在进行业务调整，公司想让我调到其他业务线上，岗位职责也发生了变化，我觉得自己还是很擅长做前端工具链方向的开发，并且也在这块积累了几年经验，还是想继续在这个方向上深耕，因此出来看看机会。

🎯 无法升职

✅ 回答模板：HR 您好!前公司管理比较扁平，虽然一直被领导重用，也负责过多个核心业务，但是职级几年来来一直没有变化。领导也争取过，但由于工作年限等原因，没能通过。我不想安于现状，想找一个更能发挥自己才能的平台。

🎯 同事相处不和谐

✅ 回答模板：HR 您好!我之前在前司能力不错，取得了不错的成绩，但由于分工不太合理，出现了很多扯皮现象和低效沟通，影响到了工作效率，有时甚至会影响整个项目的进度，内耗较大，所以决定离开，希望找一个氛国好团队长期发展。

💡 记住了吗？面试时回答离职原因的关键在于：不要贬低前司和前同事、不要让 HR 觉得是你的问题、也不要吐槽前司的任何不足。掌握这些要领，相信你在面试中一定能够游刃有余地应对这个问题啦！

需求背景

前几天，甲方提了个需求，想让下面的数据循环展示，准备放在他们集团首页给他们领导演示用。

我们领导很重视这个事儿，拍了拍我，语重心长的说，小伙子，好好做。

我啪的一下就兴奋了，老板居然如此器重我，我必当鞠躬尽瘁，减少摸鱼，我要让老板拜倒在精湛的技术下！

于是，我搬出自己的库存代码，仅2min就实现了数据的滚动：

没错，我直接照搬了自己以前写过的文章：JS实现可滚动区域自动滚动展示 - 掘金

就在我准备告诉老板我做完了的时候，我突然想了想，这么快做完，老板一定觉得我没好好做，我以后还怎么升职加薪，赢取白富美？

于是，我连夜研究，终于改进了数据滚动方式，赢得了老板的大饼（以后涨500）。最终效果：

技术方案

技术选型

观察最终效果图，可以发现这其实就是一个数据循环滚动的效果，每条内容之间间隔1000ms，每条出现动的时间为500ms。用术语来说，这就是一个单步停顿滚动效果。

我百度了一下，社区还是有这个实现的现成方案的：vue-seamless-scroll，周下载也还行。

于是，我果断试了试，结果不知道什么原因，并不生效...

既然如此，直接手写一个吧！

实现思路

要实现上述效果其实很简单，如图

我们创造一个含有六个值的数组，每隔一段时间循环更改黄色区域的数据，当黄色区域数据变成最新的时候，红色区域整体向下移动，当有数值超出滚动区域后，在删除这个数据即可。

数据更新

如果不考虑动画，我们的代码应该这么写

<template>

    <div class="item-wrap" v-for="(item, index) in animationData">

          <!-- 模块内容 -->     

     </div>

</template>

<script setup lang="ts">

// #假设这是接口请求的10条最新数据

const allCarouseData = ref([1, 2, 3, 4, 5, 6, 7, 8, 9, 10])

// #需要轮播的数据

const animationData = ref<any>([])

// *定时器

const animationTimerMeta: any = {

    timer: null,

    // 这个函数负责设置轮播数据的更新逻辑。

    timeFuc() {

        let setTimeoutId: any = null

        if (this.timer) return

        this.timer = setInterval(() => {

            // 取轮播数据的第一条id

            let firstId = animationData.value[0].id

            // 为轮播数据添加最新的第一项数据 

            let index = allCarouseData.value.findIndex((res: any) => res.id === firstId)

            let addIndex = index - 1 < 0 ? allCarouseData.value.length - 1 : index - 1

            animationData.value.unshift(allCarouseData.value[addIndex])

            setTimeout(() => {

                // 删除数组的最后一项

                animationData.value.pop()

            }, 1000)

            

        }, 1500)

    }

}

animationData.value = allCarouseData.value.slice(-5)

animationTimerMeta.timeFuc()

</script>