效果图

思路

• 树形展开时，将该节点的childList添加到该节点下，并更新树结构
  
  

  mDataList.addAll(position, childList)
  
  notifyItemRangeInserted(position, childList.size)
  
  

  
  


• 树形关闭时，树的数据结构移除该节点的childList的数量，并更新树结构
  
  

  for (i in 0 until childList.size) {
  
      mDataList[position].isExpand=false
  
      mDataList.removeAt(position)
  
  }
  
  notifyItemRangeRemoved(position, childList.size)
  
  

  
  


• 对于含CheckBox的树形结构，每一个节点都需要监听他的状态，当状态和上一次的状态不一样时，则进行更新。更新不仅更新本节点，还需要递归的方式更新他的子节点；因为当前的选中状态还会牵连到他的父节点，他的父节点变更的话还会牵扯到再上一层，所以也需要递归的方式来更新。
  
  

  private fun updateNodeState(bean: T) {
  
      //更新子节点
  
      updateChildState(bean)
  
  ​
  
      //更新父节点状态
  
      updateParentState(bean)
  
  ​
  
      notifyDataSetChanged()
  
  }
  
  

  
  

  更新子节点

  
  

  private fun updateChildState(bean: T) {
  
      for (child in bean.getChildList()) {
  
          //更新子节点状态
  
          child.checkState = bean.checkState
  
          //递归更新子节点
  
          updateChildState(child)
  
      }
  
  }
  
  

  
  

  更新父节点

  
  

  private fun updateParentState(bean: T) {
  
      //找到父节点并更新
  
      mDataList.forEach { parent ->
  
          if (bean.getMyId() in parent.getChildList().map { it.getMyId() }) {
  
              //全部选中
  
              val allChecked =
  
                  parent.getChildList().all { it.checkState == TriStateCheckBox.State.CHECKED }
  
              val allUnChecked =
  
                  parent.getChildList().all { it.checkState == TriStateCheckBox.State.UNCHECKED }
  
  ​
  
              if (allChecked) {
  
                  parent.checkState = TriStateCheckBox.State.CHECKED
  
              } else if (allUnChecked) {
  
                  parent.checkState = TriStateCheckBox.State.UNCHECKED
  
              } else {
  
                  parent.checkState = TriStateCheckBox.State.PARTIALLY_CHECKED
  
              }
  
              //递归更新父节点
  
              updateParentState(parent)
  
          }
  
      }
  
  }
  
  

  
  


• 设置选中项时，可以先获取到selectList中的所有叶子节点，然后再更新整个树形结构的mDataList选项
  
  

  //获取所有的叶子节点
  
  private fun getLeafNodeList(selectedList: List<T>):List<T>{
  
      val result = mutableListOf<T>()
  
      for (bean in selectedList){
  
          if (bean.hasChild()){
  
              result.addAll(getLeafNodeList(bean.getChildList()))
  
          }else{
  
              result.add(bean)
  
          }
  
      }
  
      return result
  
  }
  
  

  
  

  fun setSelectedList(selectedList:List<T>){
  
      //选中的叶子节点列表
  
      val selectedChildNodeList = getLeafNodeList(selectedList).toMutableList()
  
      //通过递归的方式检查子列表  
  
      updateSelectedTree(mDataList, selectedChildNodeList)
  
      notifyDataSetChanged()
  
  }
  
  

  
  


• 因为想通过泛型的方式，适用于任何项目，所以我们搞一个抽象类，包含该节点的层级、是否展开、选中状态等属性
  
  

  abstract class TreeBaseBean<T>{
  
      
  
      //层级
  
      var level:Int=0
  
      //是否展开
  
      var isExpand = false
  
      //当前节点状态
  
      var checkState: TriStateCheckBox.State = TriStateCheckBox.State.UNCHECKED
  
  ​
  
      //判断是否有子节点
  
      fun hasChild():Boolean = !getChildList().isNullOrEmpty()
  
      
  
      //获取子节点列表
  
      abstract fun getChildList():List<T>
  
      //获取当前节点id
  
      abstract fun getMyId():Any
  
      //获取父节点id
  
      abstract fun getMyParentId():Any?
  
  ​
  
  }
  
  

  
  

步骤

处理数据

将项目中的树形数据结构继承自TreeBaseBean，重写该抽象类中的方法

data class MenuBean(

    var id: String = "",

    var parentId: Any? = null,

    var menuName: String = "",

    var menuType: String = "",

    var router: String = "",

    var sort: Int = 0,

    var icon: String = "",

    var sonList: List<MenuBean> = listOf(),

    var status: String = "",

    var userid: String=""

): TreeBaseBean<MenuBean>() {

​

    override fun getChildList(): List<MenuBean> {

        return sonList

    }

​

    override fun getMyId(): Any {

        return id

    }

​

    override fun getMyParentId(): Any? {

        return parentId

    }

}

2、建立自己的ItemView，确保里面包含有一个命名为ivArrow的箭头图片，一个命名为mCheckBox的CheckBox或自定义三种状态的TriStateCheckBox

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

<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"

    xmlns:app="http://schemas.android.com/apk/res-auto"

    android:layout_width="match_parent"

    android:layout_height="wrap_content"

    android:id="@+id/root">

​

    <ImageView

        android:id="@+id/ivArrow"

        android:layout_width="18dp"

        android:layout_height="18dp"

        android:src="@drawable/ic_keyboard_arrow_right_black_18dp"

        android:visibility="invisible"

        app:layout_constraintBottom_toBottomOf="@id/mCheckBox"

        app:layout_constraintLeft_toLeftOf="parent"

        app:layout_constraintTop_toTopOf="@id/mCheckBox" />

​

    <com.sxygsj.treefinalcase.TriStateCheckBox

        android:id="@+id/mCheckBox"

        android:layout_width="20dp"

        android:layout_height="20dp"

        app:layout_constraintLeft_toRightOf="@id/ivArrow"

        app:layout_constraintTop_toTopOf="@id/tvCheckName"

        app:layout_constraintBottom_toBottomOf="@id/tvCheckName"/>

​

    <TextView

        android:id="@+id/tvCheckName"

        android:layout_width="0dp"

        android:layout_height="wrap_content"

        android:text="内容"

        app:layout_constraintLeft_toRightOf="@id/mCheckBox"

        app:layout_constraintRight_toRightOf="parent"

        app:layout_constraintTop_toTopOf="parent"

        android:layout_marginLeft="5dp"

        android:paddingVertical="5dp"/>

    

</androidx.constraintlayout.widget.ConstraintLayout>

使用适配器

//数据项

private val dataList= mutableListOf<MenuBean>()

//设置的选中项

private val selectedList = mutableListOf<MenuBean>()

​

private lateinit var adapter: ChainCommonTreeCheckboxAdapter<MenuBean>

private fun initRcy() {

    adapter = ChainCommonTreeCheckboxAdapter.Builder<MenuBean>()

        .setData(dataList)

        .setLayoutId(R.layout.item_checkbox_tree)

        .addBindView { itemView, bean, level ->

            itemView.findViewById<TextView>(R.id.tvCheckName).setText("层级${level}："+bean.menuName)

        }

        .addItemClickListener {

            Toast.makeText(this,"点击了：${it.menuName}", Toast.LENGTH_SHORT).show()

        }

        .setPadding(16)

        .create()

​

​

    binding.apply {

        mRcy.layoutManager = LinearLayoutManager(this@ChainMultiActivity)

        mRcy.adapter=adapter

    }

​

}

//设置选中项

adapter.setSelectedList(selectedList)

//默认获取选中和部分选中节点

val list = adapter.getSelectedList()

//获取所有的叶子节点(具体想要获取怎么的选中项，可以通过lambda方式来自己设定规则)

val list = adapter.getSelectedList { bean ->

        bean.checkState == TriStateCheckBox.State.CHECKED&&!bean.hasChild()

}

总结

其实整体的关键操作是数据的处理，怎么通过递归的方式，联动更新各个节点的状态是最重要的，关键代码在思路里已整理，剩余的三种状态的CheckBox、链式调用的通用适配器有时间再更新。

1.概述

手机投屏是目前市场上常见的一个功能，在车机娱乐场景，辅助驾驶场景比如苹果的carplay,VR 场景都很常见，目前市场上的投屏分为三类：
第一类: 镜像模式，直接把手机上整个界面原封不动进行投射。这类投屏通常是对手机进行录屏，然后编码成视频流数据的方式给到接受端，接收端再解码播放，以此完成投屏功能。比如AirPlay的镜像模式、MiraCast、乐播投屏等；
第二类: 推送模式，播视频的场景比较常见。即A把一个视频链接传给B，B自己进行播放，后学A可以传输一些简单控制指令。比如DLNA协议等；
第三类： 基于特殊协议投射部分应用或部分功能，车载领域居多。比如苹果的CarPlay、华为HiCar、百度CarLife等。

这里还有一种投屏方式比较新颖，将手机上的画面投到车机上，然后手机上可以操作自己的功能，车机上也可以操作手机的功能，而且两者互不干涉，具体可以参考蔚来手机和车机的投屏：蔚来手机的投屏视频 今天的主要内容是介绍实现投屏的各种技术方式，主要介绍Miracast、scrcpy、以及Google cast的实现方式以及优缺点局限性。

2.术语解释

2.1 miracast

Miracast是一种以WiFi直连为基础的无线显示标准，它允许用户通过无线方式分享视频画面。这种技术支持用户将智能手机、平板电脑、笔记本电脑等设备上的内容投射到大屏幕电视或其他显示设备上，而无需使用线缆连接。

2.2 scrcpy

Scrcpy是一种开源的命令行工具，允许用户通过USB数据线或Android ADB（Android调试桥）来控制他们的Android设备，包括手机和平板电脑。使用Scrcpy，用户可以在电脑上实时查看和控制他们的Android设备，就像使用一个远程屏幕一样。
2.3 DLNA投屏
DLNA投屏是一种通过网络将多媒体内容从一台设备传输到另一台设备的技术。它允许用户将智能手机、平板电脑或电脑上的视频、音频和图片等内容投射到支持DLNA的电视、音响系统或其他显示设备上。DLNA投屏基于设备之间的WiFi连接，无需额外的物理连接或设置，使用户能够轻松地将手机上的媒体内容投屏到大屏幕上并实现双向控制。

2.4 Wifi Direct

WiFi Direct是一种允许设备通过WiFi直接相互连接的技术，无需通过路由器或中继点。这种技术使得设备之间的连接更加直接和便捷，常用于文件共享、打印服务和Miracast投屏等场景。

2.5 app_process

是Android原生的一个可执行程序，位于/system/bin目录下，zygote进程便是由这个执行文件启动的。

3.技术实现对比

3.1 Miracast

3.1.1 Miracast介绍

Miracast是一种无线技术，用于将屏幕无线连接到我们的计算机。它是由WiFi联盟制定，以WiFi-Direct、IEEE802.11为无线传输标准，允许手机向电视或其他接收设备进行无线投送视频、图片。和Miracast类似的投屏协议，还有Airplay、DLNA、chromecast等，Miracast是点对点网络，用于类似蓝牙的方式（比蓝牙更高效）无线发送由Wi-Fi Direct连接组成的截屏视频。大多数最新一代的设备（例如笔记本电脑、智能电视和智能手机）都可以支持该技术，Miracast还支持高达1080p（全高清）的分辨率和5.1环绕声。它还支持4k分辨率。通过无线连接，视频数据以H.264格式发送，这是当今最常见的高清视频编码标准。Miracast在诞生之初就以跨平台标准而设计，这意味着它能在多种平台间使用。

3.1.2 Miracast原理

Miracast基于WiFi P2P，或TDLS，或Infrastructure进行设备发现，位于OSI模型的数据链路层。而媒体传输控制使用RTSP协议，还有远程I2C数据读写、UIBC用户输入反向信道、HDCP高带宽内容保护等，位于OSI模型的TCP/IP传输控制层与网络层。其中，由音视频数据封装成PES包，经过HDCP内容保护，再封装成TS包，接着封装成RTP包，使用RTSP协议发送。如下图所示

3.1.3 Miracast优缺点分析

优点：投屏画质清晰，兼容性好。Android手机集成了Mircast投屏，如果想要二次开发可以从AOSP源码中找到对应的实现，网上的开发文档多
缺点： Miracast正常工作时，Wi-Fi工作在P2P模式，源端与接收端建立一对一的联接。也即当一个设备与一个接收端建立连接后，其它设备不可见该接收端，也就不能投屏。只有当该设备退出连接后，其它设备才能投屏。所以无法实现抢占功能。Miracast底层封装了UDP传输协议，没有严谨的问答机制。所以在实际使用过程中，当遇到干扰时，容易造成丢帧花屏现象。而传输过程中，一旦出现花屏，给客人的感觉就非常糟糕，现在市面上，哪些无线投屏设备之所以经常出现花屏、马赛克就是这个原因。另外，Miracast是操作系统供应商提供，一般都是在安卓系统上使用，但是安卓协议导致手机投屏没有声音，所以大多数用户在安卓手机无线投屏的时候，需要开启蓝牙，以便于把声音投屏过去。如果我们需要使用Mircast,需要对ROM进行二次开发。下面是一个投屏技术公司的关于Miracast的技术文档，描述了目前Mircast存在的问题。Mircast目前存在的问题 若要实现双向控制，需要加一个控制的通道和事件转换和注入

3.2 Scrcpy

3.2.1 scrcpy 介绍

scrcpy通过adb调试的方式来将手机屏幕投到电脑上，并可以通过电脑控制Android设备。它可以通过USB连接，也可以通过Wifi连接（类似于隔空投屏),使用adb的无线连接后投屏，而且不需要任何root权限，不需要在手机里安装任何程序。scrcpy同时适用于GNU / Linux，Windows和macOS。Scrcpy 显示的每帧画面的大小达到1920x1080或者更高，帧率在30～60fps,延迟很低（大约35~70ms),启动快，第一帧画面显示出来的时间大约为1秒，并且不需要安装任何apk。并且代码完全开源，源码地址：github.com/Genymobile/…

3.2.2 scrcpy的实现原理

Scrcpy的基本原理是通过ADB（Android Debug Bridge）将电脑和手机连接到一起后，推送一个jar文件到手机/data/local/tmp的目录下，然后通过adb shell 执行app_process 程序将jar文件运行起来，这个jar文件相当于是手机上运行的一个服务器，它的作用是处理来自电脑端的的数据请求。它的免root原理主要基于两个关键点：

3.2.3 scrcpy的优缺点分析

优点：Scrcpy的优点是显示的画质好，延迟低(大约3570ms)，帧率3060fps，非常流畅,而且代码完全开源并有很详细的文档，并且不需要安装任何apk和root权限。能自定义控制的行为，比如显示音频和视频，只播放音频，只显示视频，只投屏(不接受电脑端的控制，类似于投屏中的镜像)
缺点：需要用户打开开发者模式中的USB调试模式，否则很多的操作都无法进行了。这点会导致产品无法用于正式的生产环境中，因为用户一般都不会打开开发者选项中的USB调试模式。如果通过修改源码的方式，则无法实现事件注入的功能，因为事件注入需要依赖adb shell。

3.3 Google cast

3.3.1 Google cast 介绍

Google Cast类似于DLNA，AirPlayer，Miracast，就是一种投屏技术。Google Cast的作用在于把小屏幕（诸如手机、平板、笔记本）的内容通过无线（WIFI）方式发送到大屏设备（google TV、chromeCast）进行播放。Google Cast所做的便在于基于不同的平台提供提供为应用开支这种功能的SDK，这些平台即有发送端的也有接收端的，发送端的有IOS、android、chrome浏览器，接收端的有google TV, chromeCast等，可以说这一套解决方案是比较大而全的（就其涵盖的平台）。

3.3.2 Google cast 的实现原理

发送端 app（sender app）使用 SDK，将需要播放的媒体的信息发送到 Google 的服务器，服务器再通知接收端播放（所以发送端和接收端必须都可以访问 Google 的服务器才行）。接收端运行的是一个浏览器，它会根据发送端的app ID和媒体信息，去载入对应的一个网页，这个网页（receiver app）也是由发送端 app 的开发者提供的，的将会负责播放相应的媒体内容。即使接收端是 Chromecast Audio 之类只能播放音频的硬件，这个网页也是会载入并渲染的。Google Cast 和 DLNA 或者苹果的 AirPlay 不同之处，一是依赖 Google 的服务器，也就是说必须连接到 Internet 才可以用，如果只有一个局域网是不行的。二是前两个的接收端播放器接收端本身提供的，开发者只需要提供要播放的内容就可以，但是 Google Cast 则是需要提供自己的receiver app，这样的好处是开发者可以高度定制（比如可以定制UI，或者加入弹幕、歌词滚动、音乐可视化之类复杂功能），虽然接收端往往运行的并不是Android这样的开放操作系统，但是因为receiver app的本质是网页，所以开发难度并不高。

3.3.3 优缺点分析

优点：就是高度可定制，有官方成熟的SDK可接入，从宣传视频中看到手机可以投屏到大屏后，然后就可以随意操作其他应用而不会影响到大屏的显示内容了。
缺点：平台依赖性强，必须可以访问Google服务器，而由于国情的原因，必须可访问Google服务器这个缺点就可以宣告这个方案不合适了

总结

本文主要介绍了各种Android手机投屏的实现方式以及优缺点，手机投屏经常会涉及到投屏端和接收端端相互操作以及音频的播放。所以在建立了投屏需要建立好几个连接通道，分别传输音频、控制指令和录屏的视频流。scrcpy就是这样实现的，如果我们能获取到权限，目前决定scrcpy是最好的投屏实现方式。由于没有权限，现在的大多数控制都是通过Android手机的无障碍模式实现的。这就是我对手机投屏的一些调研总结，希望能帮到有需要的读者

开发 Android 应用时，是否有过这样的时刻？

"我只是想请求个网络数据，为什么我的主线程就卡住了！"

"多线程真香，但这锁和回调让我头都大了！"

别担心！

今天我们来认识 Android 开发中的超级英雄——协程（Coroutines） ，它能让你以最优雅的方式，化解多线程的痛点，轻松应对复杂的异步操作！

🦸‍♂️ 协程是个啥？

想象一下，你正在玩一款冒险游戏。游戏里的主角不仅可以“战斗”，还能“暂停”战斗，去完成一些重要任务（比如喝口水、回血），然后再无缝回归到战斗中继续打怪。

协程就像这个灵活的冒险主角：

• 轻量级线程：协程不是普通线程，但它可以暂停和恢复。


• 灵活暂停和恢复：随时挂起（suspend），随时回来。


• 并发管理高手：让你在多任务之间游刃有余，再也不用担心线程锁或回调地狱。

🎯 协程的核心武器

协程的核心技能就三个字：

挂起（Suspend）！

挂起函数是协程的魔法技能，虽然它暂停了自己，但不会阻塞线程。

比如这个最简单的例子：

suspend fun fetchData(): String {

    delay(1000) // 模拟网络请求，暂停1秒

    return "服务器返回的数据"

}

看到没有？协程就像在说：

"我歇一会儿，待会儿继续，不耽误别人干活！"

🤹‍♀️ 协程的奇幻队伍

协程离不开一支强大的“队友团队”，它们是：

1️⃣ GlobalScope

协程的孤狼模式，一旦启动就运行到世界尽头，但稍有不慎可能造成内存泄漏，慎用！

GlobalScope.launch {

    println("这是一个孤单的协程")

}

2️⃣ CoroutineScope

协程的队伍领袖，能保证所有子协程的生命周期跟它挂钩，避免资源泄漏。

class MyActivity : AppCompatActivity() {

    private val scope = CoroutineScope(Dispatchers.Main)



    override fun onDestroy() {

        super.onDestroy()

        scope.cancel() // 活动销毁时取消协程

    }

}

3️⃣ Dispatchers

调度器，决定协程的运行地点：

• Main：UI线程，适合更新界面。


• IO：专注网络请求、文件读写。


• Default：CPU密集型任务。


• Unconfined：自由漂流，不常用。

🛠️ 协程实战：网络请求案例

假设你是一位披风加身的 Android 开发英雄，任务是从服务器获取一段数据并显示在界面上：

fun fetchDataAndShow() {

    CoroutineScope(Dispatchers.Main).launch {

        try {

            val data = withContext(Dispatchers.IO) { 

                fetchData() // 网络请求在 IO 线程中执行

            }

            textView.text = data // 回到主线程更新 UI

        } catch (e: Exception) {

            textView.text = "出错啦！${e.message}"

        }

    }

}



suspend fun fetchData(): String {

    delay(2000) // 模拟网络请求

    return "这是来自服务器的数据"

}

你看，协程让异步操作简洁优雅，完全不需要复杂的回调！

以下是一篇轻松有趣、但同时技术性强的文章，主题是 "协程：解锁 Android 开发的超级英雄技能！" ：

协程：解锁 Android 开发的超级英雄技能！

开发 Android 应用时，是否有过这样的时刻？

"我只是想请求个网络数据，为什么我的主线程就卡住了！"

"多线程真香，但这锁和回调让我头都大了！"

别担心！

今天我们来认识 Android 开发中的超级英雄——协程（Coroutines） ，它能让你以最优雅的方式，化解多线程的痛点，轻松应对复杂的异步操作！

🦸‍♂️ 协程是个啥？

想象一下，你正在玩一款冒险游戏。游戏里的主角不仅可以“战斗”，还能“暂停”战斗，去完成一些重要任务（比如喝口水、回血），然后再无缝回归到战斗中继续打怪。

协程就像这个灵活的冒险主角：

• 轻量级线程：协程不是普通线程，但它可以暂停和恢复。


• 灵活暂停和恢复：随时挂起（suspend），随时回来。


• 并发管理高手：让你在多任务之间游刃有余，再也不用担心线程锁或回调地狱。

🎯 协程的核心武器

协程的核心技能就三个字：

挂起（Suspend）！

挂起函数是协程的魔法技能，虽然它暂停了自己，但不会阻塞线程。

比如这个最简单的例子：

suspend fun fetchData(): String {

    delay(1000) // 模拟网络请求，暂停1秒

    return "服务器返回的数据"

}

看到没有？协程就像在说：

"我歇一会儿，待会儿继续，不耽误别人干活！"

🤹‍♀️ 协程的奇幻队伍

协程离不开一支强大的“队友团队”，它们是：

1️⃣ GlobalScope

协程的孤狼模式，一旦启动就运行到世界尽头，但稍有不慎可能造成内存泄漏，慎用！

GlobalScope.launch {

    println("这是一个孤单的协程")

}

2️⃣ CoroutineScope

协程的队伍领袖，能保证所有子协程的生命周期跟它挂钩，避免资源泄漏。

class MyActivity : AppCompatActivity() {

    private val scope = CoroutineScope(Dispatchers.Main)



    override fun onDestroy() {

        super.onDestroy()

        scope.cancel() // 活动销毁时取消协程

    }

}

3️⃣ Dispatchers

调度器，决定协程的运行地点：

• Main：UI线程，适合更新界面。


• IO：专注网络请求、文件读写。


• Default：CPU密集型任务。


• Unconfined：自由漂流，不常用。

🛠️ 协程实战：网络请求案例

假设你是一位披风加身的 Android 开发英雄，任务是从服务器获取一段数据并显示在界面上：

fun fetchDataAndShow() {

    CoroutineScope(Dispatchers.Main).launch {

        try {

            val data = withContext(Dispatchers.IO) { 

                fetchData() // 网络请求在 IO 线程中执行

            }

            textView.text = data // 回到主线程更新 UI

        } catch (e: Exception) {

            textView.text = "出错啦！${e.message}"

        }

    }

}



suspend fun fetchData(): String {

    delay(2000) // 模拟网络请求

    return "这是来自服务器的数据"

}

你看，协程让异步操作简洁优雅，完全不需要复杂的回调！

🎮 协程的高阶玩法

1️⃣ 并发：一心多用

协程中的并发很简单，像玩双开游戏一样：

suspend fun loadData() = coroutineScope {

    val data1 = async { fetchData() }

    val data2 = async { fetchData() }

    println("数据1: ${data1.await()}, 数据2: ${data2.await()}")

}

只要用了 async，就能并发运行多个任务，效率提升 N 倍！

2️⃣ 结构化并发：协程的守护者

协程不像传统线程那么“放飞自我”。当它的宿主（比如 CoroutineScope）取消了，所有子协程也会跟着取消。这种“组队行动”叫做结构化并发。

coroutineScope {

    launch { delay(1000); println("任务1完成") }

    launch { delay(2000); println("任务2完成") }

    println("等待任务完成")

}

当 coroutineScope 结束时，所有子任务都会自动完成或取消。

💡 协程的隐藏技能：Flow

如果协程是单任务英雄，那 Flow 就是它的“数据流忍术”。用 Flow，你可以优雅地处理连续的数据流，比如加载分页数据、实时更新状态。

fun fetchDataFlow(): Flow<String> = flow {

    for (i in 1..5) {

        delay(500)

        emit("第 $i 条数据")

    }

}



CoroutineScope(Dispatchers.Main).launch {

    fetchDataFlow().collect { data ->

        println(data) // 每次收到数据时打印

    }

}

🧩 总结

协程就像一位超级英雄，它能：

• 解决主线程阻塞的问题。


• 简化复杂的异步操作。


• 提供更高效、更安全的并发管理。

而它的乐趣在于：

• 让开发者从回调地狱中解脱出来。


• 代码更简洁、更易读，就像写同步代码一样。

如果你还没使用协程，试试吧！它会让你感受到开发 Android 应用的魔法力量！

“用协程开发，就像给代码装上了飞行装置，既轻松又高效！”

愿你的 Android 开发之路充满乐趣与协程的超能力！ 😊

开发 Android 应用时，是否有过这样的时刻？

"我只是想请求个网络数据，为什么我的主线程就卡住了！"

"多线程真香，但这锁和回调让我头都大了！"

别担心！

今天我们来认识 Android 开发中的超级英雄——协程（Coroutines） ，它能让你以最优雅的方式，化解多线程的痛点，轻松应对复杂的异步操作！

🦸‍♂️ 协程是个啥？

想象一下，你正在玩一款冒险游戏。游戏里的主角不仅可以“战斗”，还能“暂停”战斗，去完成一些重要任务（比如喝口水、回血），然后再无缝回归到战斗中继续打怪。

协程就像这个灵活的冒险主角：

• 轻量级线程：协程不是普通线程，但它可以暂停和恢复。


• 灵活暂停和恢复：随时挂起（suspend），随时回来。


• 并发管理高手：让你在多任务之间游刃有余，再也不用担心线程锁或回调地狱。

🎯 协程的核心武器

协程的核心技能就三个字：

挂起（Suspend）！

挂起函数是协程的魔法技能，虽然它暂停了自己，但不会阻塞线程。

比如这个最简单的例子：

suspend fun fetchData(): String {

    delay(1000) // 模拟网络请求，暂停1秒

    return "服务器返回的数据"

}

看到没有？协程就像在说：

"我歇一会儿，待会儿继续，不耽误别人干活！"

🤹‍♀️ 协程的奇幻队伍

协程离不开一支强大的“队友团队”，它们是：

1️⃣ GlobalScope

协程的孤狼模式，一旦启动就运行到世界尽头，但稍有不慎可能造成内存泄漏，慎用！

GlobalScope.launch {

    println("这是一个孤单的协程")

}

2️⃣ CoroutineScope

协程的队伍领袖，能保证所有子协程的生命周期跟它挂钩，避免资源泄漏。

class MyActivity : AppCompatActivity() {

    private val scope = CoroutineScope(Dispatchers.Main)



    override fun onDestroy() {

        super.onDestroy()

        scope.cancel() // 活动销毁时取消协程

    }

}

3️⃣ Dispatchers

调度器，决定协程的运行地点：

• Main：UI线程，适合更新界面。


• IO：专注网络请求、文件读写。


• Default：CPU密集型任务。


• Unconfined：自由漂流，不常用。

🛠️ 协程实战：网络请求案例

假设你是一位披风加身的 Android 开发英雄，任务是从服务器获取一段数据并显示在界面上：

fun fetchDataAndShow() {

    CoroutineScope(Dispatchers.Main).launch {

        try {

            val data = withContext(Dispatchers.IO) { 

                fetchData() // 网络请求在 IO 线程中执行

            }

            textView.text = data // 回到主线程更新 UI

        } catch (e: Exception) {

            textView.text = "出错啦！${e.message}"

        }

    }

}



suspend fun fetchData(): String {

    delay(2000) // 模拟网络请求

    return "这是来自服务器的数据"

}

你看，协程让异步操作简洁优雅，完全不需要复杂的回调！

以下是一篇轻松有趣、但同时技术性强的文章，主题是 "协程：解锁 Android 开发的超级英雄技能！" ：

协程：解锁 Android 开发的超级英雄技能！

开发 Android 应用时，是否有过这样的时刻？

"我只是想请求个网络数据，为什么我的主线程就卡住了！"

"多线程真香，但这锁和回调让我头都大了！"

别担心！

今天我们来认识 Android 开发中的超级英雄——协程（Coroutines） ，它能让你以最优雅的方式，化解多线程的痛点，轻松应对复杂的异步操作！

🦸‍♂️ 协程是个啥？

想象一下，你正在玩一款冒险游戏。游戏里的主角不仅可以“战斗”，还能“暂停”战斗，去完成一些重要任务（比如喝口水、回血），然后再无缝回归到战斗中继续打怪。

协程就像这个灵活的冒险主角：

• 轻量级线程：协程不是普通线程，但它可以暂停和恢复。


• 灵活暂停和恢复：随时挂起（suspend），随时回来。


• 并发管理高手：让你在多任务之间游刃有余，再也不用担心线程锁或回调地狱。

🎯 协程的核心武器

协程的核心技能就三个字：

挂起（Suspend）！

挂起函数是协程的魔法技能，虽然它暂停了自己，但不会阻塞线程。

比如这个最简单的例子：

suspend fun fetchData(): String {

    delay(1000) // 模拟网络请求，暂停1秒

    return "服务器返回的数据"

}

看到没有？协程就像在说：

"我歇一会儿，待会儿继续，不耽误别人干活！"

🤹‍♀️ 协程的奇幻队伍

协程离不开一支强大的“队友团队”，它们是：

1️⃣ GlobalScope

协程的孤狼模式，一旦启动就运行到世界尽头，但稍有不慎可能造成内存泄漏，慎用！

GlobalScope.launch {

    println("这是一个孤单的协程")

}

2️⃣ CoroutineScope

协程的队伍领袖，能保证所有子协程的生命周期跟它挂钩，避免资源泄漏。

class MyActivity : AppCompatActivity() {

    private val scope = CoroutineScope(Dispatchers.Main)



    override fun onDestroy() {

        super.onDestroy()

        scope.cancel() // 活动销毁时取消协程

    }

}

3️⃣ Dispatchers

调度器，决定协程的运行地点：

• Main：UI线程，适合更新界面。


• IO：专注网络请求、文件读写。


• Default：CPU密集型任务。


• Unconfined：自由漂流，不常用。

🛠️ 协程实战：网络请求案例

假设你是一位披风加身的 Android 开发英雄，任务是从服务器获取一段数据并显示在界面上：

fun fetchDataAndShow() {

    CoroutineScope(Dispatchers.Main).launch {

        try {

            val data = withContext(Dispatchers.IO) { 

                fetchData() // 网络请求在 IO 线程中执行

            }

            textView.text = data // 回到主线程更新 UI

        } catch (e: Exception) {

            textView.text = "出错啦！${e.message}"

        }

    }

}



suspend fun fetchData(): String {

    delay(2000) // 模拟网络请求

    return "这是来自服务器的数据"

}

你看，协程让异步操作简洁优雅，完全不需要复杂的回调！

🎮 协程的高阶玩法

1️⃣ 并发：一心多用

协程中的并发很简单，像玩双开游戏一样：

suspend fun loadData() = coroutineScope {

    val data1 = async { fetchData() }

    val data2 = async { fetchData() }

    println("数据1: ${data1.await()}, 数据2: ${data2.await()}")

}

只要用了 async，就能并发运行多个任务，效率提升 N 倍！

2️⃣ 结构化并发：协程的守护者

协程不像传统线程那么“放飞自我”。当它的宿主（比如 CoroutineScope）取消了，所有子协程也会跟着取消。这种“组队行动”叫做结构化并发。

coroutineScope {

    launch { delay(1000); println("任务1完成") }

    launch { delay(2000); println("任务2完成") }

    println("等待任务完成")

}

当 coroutineScope 结束时，所有子任务都会自动完成或取消。

💡 协程的隐藏技能：Flow

如果协程是单任务英雄，那 Flow 就是它的“数据流忍术”。用 Flow，你可以优雅地处理连续的数据流，比如加载分页数据、实时更新状态。

fun fetchDataFlow(): Flow<String> = flow {

    for (i in 1..5) {

        delay(500)

        emit("第 $i 条数据")

    }

}



CoroutineScope(Dispatchers.Main).launch {

    fetchDataFlow().collect { data ->

        println(data) // 每次收到数据时打印

    }

}

🧩 总结

协程就像一位超级英雄，它能：

• 解决主线程阻塞的问题。


• 简化复杂的异步操作。


• 提供更高效、更安全的并发管理。

而它的乐趣在于：

• 让开发者从回调地狱中解脱出来。


• 代码更简洁、更易读，就像写同步代码一样。

如果你还没使用协程，试试吧！它会让你感受到开发 Android 应用的魔法力量！

“用协程开发，就像给代码装上了飞行装置，既轻松又高效！”

愿你的 Android 开发之路充满乐趣与协程的超能力！ 😊

看过我文章的小伙伴应该也都知道，去年我是坚持了每周更新一篇技术文章，去年文章总数算下来也有个50篇左右，然后今年立下的flag是：

• 再学一门语言，比如鸿蒙开发、游戏开发等等。这个flag是做到了，目前为止可以运用kotlin开发Android原生应用。


• 继续在掘金平台输出文章，至少做到每周一更。年初原本想着是每周2-3更，但是目前看来是完全没做到，因为这2个月的个人时间全都扑在了“副业”上。

所以接下来，我会将这3个月的心路历程讲给大家听，如果大家想做副业，可以参考一下我的经历。

过年这段时间的思考

时间回退到去年过年的时候，我没记错的话应该是今年2月份是去年过年的时间点。我司是放了2周的假，那个时候我的工作年限是2年半（可以出道了，哈哈哈）。从大学到目前为止，心里一直有个声音告诉我：

我不可能通过打工来实现理想中的生活状态。原因如下：

1、房贷、车贷、孩子教育、大病、未知的风险，这些因素会导致生活质量非常脆弱。当然这也要因人而异，毕竟过的是否开心只有自己知道。

2、疫情后时代，裁员潮一浪更比一浪强，毕业人数越来越多，岗位越来越少，谋得一份自己满意的工作也趋近于“99%的运气 + 1%的努力”。

3、原来我努力学习技术是为了更好的打工，有人的地方就有江湖，你不能独善其身，因为并不是所有的人都喜欢双赢。

所以，年后在回北京的路上，我决定今年要尝试一下，不要把所有的时间全扑在技术上，可以考虑做一下“副业”。

如何做副业？

我个人比较喜欢看电影、电视剧、动漫、NBA。影视解说这个赛道可能就比较适合我，定了赛道以后，视频发到哪个平台呢？今年短视频平台特别多，抖音、快手、视频号、B站、西瓜、甚至是支付宝里都可以刷视频等等。在综合考虑之后，我选择了微信视频号。原因如下：

• 微信不缺流量，也不缺广告商赞助。


• 视频号绝对是某讯今年发力的重点，因为官方不止一次在公共场合里说明了视频号的重要性，而且春节晚会上也出现了视频号的赞助。


• 视频号上目前竞争不激烈（这句话只在2024年6月前生效），因为用的人还不是很多，所以这个阶段对视频质量的管控还不是很严，毕竟它要吸引用户进来，前期肯定不会管控太严，而且流量也会给的很足。

于是2024年2月18日，我的第一条影视作品在视频号上发布了。

这是我第一次剪辑影视作品，花了3天时间。当时的播放量就是200多，你现在看到710播放量是2月18日 - 6月16日的播放量。那个时候粉丝数量是1，对，没错，就是你们想的那样，那个1就是我自己，哈哈哈。当时剪辑第一条视频的时候，说实话完全是一边学习一边剪辑，而且那个时候我进入了一个误区，就是必须要剪辑的完美，所以前2天一直没有产出，这个时候我慌了，2天一点产出都没有，所以第3天的时候我告诉我自己，先把视频发出去，你又不是只发一条视频，后面的视频慢慢优化，不要想着一口吃个胖子。

前2条视频都是有关三国的视频，那个时候播放量都是200多，但是从第3条视频开始，播放量直接破万，有的能达到10w。为啥会有大的播放差距？后来我复盘了一下，是因为我当时正好踩中热点了，并且竞争不激烈。第三条视频以后，我开始剪辑《南来北往》这部影视剧，当时这部电视剧可以说是非常火，没看过的小伙伴强烈建议你去爱奇艺上观看一遍，真的超级好看。

因为周一到周五上班嘛，所以周六周天我会把下周要发的视频全都剪出来，一天至少按时发一个作品，就这样，差不多2周左右的时间吧，我的有效粉丝突破了100个。

视频号是分等级的，等级跟粉丝有关系，等级越高，视频的基础播放量就越高，能解锁的权益也会越来越多。

有效粉丝数量突破100个，这个阶段是比较难的，原因如下：

• 你要审视自己的作品质量。自己剪出来的东西是否有待提高等等。


• 你要确定细分赛道，影视解说都算是一个大概念，它可以再细分为 “影视解说”、“影视混剪”、“影视情感”。


• 一天分很多个时间段，每个时间段流量不一样，所以你要测出自己的作品在哪个时间段里，播放量比较高。

我原以为影视解说这条道路会这么顺的走下去，结果因为没有版权+播放量太高，被投诉侵权了。不是我吹，如果那个时候你在视频号里搜索“南来北往”，你看到的视频大部分都是我剪出来的。

说实话，我也是第一次见到这种阵仗，吓的我把所有关于“南来北往”的20多部作品连夜下架删除了。

在对比了其他平台后，我得出了如下结论：

• 平台之间是有合作的，这部影视剧在这个平台算侵权，但是在其他平台里就不算侵权。


• 二次创作的质量要高，要不然很容易就会被判违规，所以我已经完全转为纯影视解说。


• 还是要看平台规则，要尊重平台的规则。

影视号在视频号里如何赚钱？

相信这个话题是你们比较喜欢看的，根据我的历程，影视号在视频号里的变现途径有以下几个方向：

• 当你的作品播放量能够稳定突破10w的时候，或者每周的播放总量能够稳定突破50w的时候，会有很多人主动找你合作。


• 视频号里有视频变现任务，你可以主动去接一些变现任务，然后等待任务结束后结算。当然，这个只有当你的有效粉丝数量突破100的时候，你才有资格去接任务。


• 如果你的有效粉丝数量突破1000的时候，你可以挂商品链接，用户从你的链接点进去后，如果发生了交易，你会在中间赚一些分成，这个跟抖音的规则差不多。


• 如果你的有效粉丝突破了5000的时候，你的账号就可以解锁商单功能。就是将自己的报价放出去，如果广告主找你合作，那么他就要遵循你的视频报价。一条1分钟以下的视频报价是多少，一分钟以上的视频报价是多少等等。

当然我说的这几个方向，都必须要遵循平台的规则。所以前2年，在抖音上，80%的探店账号都赚到了钱，就是因为前几年，探店视频在抖音上是趋势，如果前几年你在抖音上发探店视频，能够做到基础的每日一更，你的流量一定不会差，而且你也一定能够接到商单。

最后

又到了该和大家说再见的时候啦，这3个月确实是学到了很多东西，这3个月的奋斗史也绝对不仅仅是视频号，在其他方面上我也有很多很深入的尝试。

以上内容绝对没有任何的引导，只是自己上半年的一个分享，如果你还想看更多的，有关我在其他方面的尝试，欢迎评论区里发言，嘿嘿，我们下期再见，拜拜～～

大家好，我是猿java。

数据库的三大范式，它是数据库设计中最基本的三个规范，那么，三大范式是什么？在实际开发中，我们一定要严格遵守三大范式吗？这篇文章，我们一起来聊一聊。

1. 三大范式

1. 第一范式（1NF，确保每列保持原子性）

第一范式要求数据库中的每个表格的每个字段（列）都具有原子性，即字段中的值不可再分割。换句话说，每个字段只能存储一个单一的值，不能包含集合、数组或重复的组。

如下示例： 假设有一个学生表 Student，结构如下：

在这个表中，电话号码字段包含多个号码，违反了1NF的原子性要求。为了满足1NF，需要将电话号码拆分为单独的记录或创建一个新的表。

满足 1NF后的设计：

学生表 Student

电话表 Phone

1.2 第二范式（2NF，确保表中的每列都和主键相关）

第二范式要求满足第一范式，并且消除表中的部分依赖，即非主键字段必须完全依赖于主键，而不是仅依赖于主键的一部分。这主要适用于复合主键的情况。

如下示例：假设有一个订单详情表 OrderDetail，结构如下：

在上述表中，主键是复合主键 (订单ID, 商品ID)。商品名称和单价只依赖于复合主键中的商品ID，而不是整个主键，存在部分依赖，违反了2NF。

满足 2NF后的设计：

订单详情表 OrderDetail

商品表 Product

1.3 第三范式（3NF，确保每列都和主键列直接相关,而不是间接相关）

第三范式要求满足第二范式，并且消除表中的传递依赖，即非主键字段不应依赖于其他非主键字段。换句话说，所有非主键字段必须直接依赖于主键，而不是通过其他非主键字段间接依赖。

如下示例：假设有一个员工表 Employee，结构如下：

在这个表中，部门名称依赖于部门ID，而部门ID依赖于主键员工ID，形成了传递依赖，违反了3NF。

满足3NF后的设计：

员工表 Employee

部门表 Department

通过将部门信息移到单独的表中，消除了传递依赖，使得数据库结构符合第三范式。

最后，我们总结一下数据库设计的三大范式：

• 第一范式（1NF）： 确保每个字段的值都是原子性的，不可再分。


• 第二范式（2NF）： 在满足 1NF的基础上，消除部分依赖，确保非主键字段完全依赖于主键。


• 第三范式（3NF）： 在满足 2NF的基础上，消除传递依赖，确保非主键字段直接依赖于主键。

2. 破坏三范式

在实际工作中，尽管遵循数据库的三大范式（1NF、2NF、3NF）有助于提高数据的一致性和减少冗余，但在某些情况下，为了满足性能、简化设计或特定业务需求，我们可能需要违反这些范式。

下面列举了一些常见的破坏三范式的原因及对应的示例。

2.1 性能优化

在高并发、大数据量的应用场景中，严格遵循三范式可能导致频繁的联表查询，增加查询时间和系统负载。为了提高查询性能，设计者可能会通过冗余数据来减少联表操作。

假设有一个电商系统，包含订单表 Orders 和用户表 Users。在严格 3NF设计中，订单表只存储 用户ID，需要通过联表查询获取用户的详细信息。

但是，为了查询性能，我们通常会在订单表中冗余存储 用户姓名 和 用户地址等信息，因此，查询订单信息时无需联表查询 Users 表，从而提升查询速度。

破坏 3NF后的设计：

2.2 简化查询和开发

严格规范化可能导致数据库结构过于复杂，增加开发和维护的难度，为了简化查询逻辑和减少开发复杂度，我们也可能会选择适当的冗余。

比如，在内容管理系统（CMS）中，文章表 Articles 和分类表 Categories 通常是独立的，如果频繁需要显示文章所属的分类名称，联表查询可能增加复杂性。因此，通过在 Articles 表中直接存储 分类名称，可以简化前端展示逻辑，减少开发工作量。

破坏 3NF后的设计：

2.3 报表和数据仓库

在数据仓库和报表系统中，通常需要快速读取和聚合大量数据。为了优化查询性能和数据分析，可能会采用冗余的数据结构，甚至使用星型或雪花型模式，这些模式并不完全符合三范式。

在销售数据仓库中，为了快速生成销售报表，可能会创建一个包含维度信息的事实表。

破坏 3NF后的设计：

在事实表中直接存储 产品名称 和 类别，避免了需要联表查询维度表，提高了报表生成的效率。

2.4 特殊业务需求

在某些业务场景下，可能需要快速响应特定的查询或操作，这时通过适当的冗余设计可以满足业务需求。

比如，在实时交易系统中，为了快速计算用户的账户余额，可能会在用户表中直接存储当前余额，而不是每次交易时都计算。

破坏 3NF后的设计：

在交易记录表中存储每笔交易的增减，但直接在用户表中维护 当前余额，避免了每次查询时的复杂计算。

2.5 兼顾读写性能

在某些应用中，读操作远多于写操作。为了优化读性能，可能会通过数据冗余来提升查询速度，而接受在数据写入时需要额外的维护工作。

社交媒体平台中，用户的好友数常被展示在用户主页上。如果每次请求都计算好友数量，效率低下。可以在用户表中维护一个 好友数 字段。

破坏3NF后的设计：

通过在 Users 表中冗余存储 好友数，可以快速展示，无需实时计算。

2.6 快速迭代和灵活性

在快速发展的产品或初创企业中，数据库设计可能需要频繁调整。过度规范化可能导致设计不够灵活，影响迭代速度。适当的冗余设计可以提高开发的灵活性和速度。

一个初创电商平台在初期快速上线，数据库设计时为了简化开发，可能会将用户的收货地址直接存储在订单表中，而不是单独创建地址表。

破坏3NF后的设计：

这样设计可以快速上线，后续根据需求再进行规范化和优化。

2.7 降低复杂性和提高可理解性

有时，过度规范化可能使数据库结构变得复杂，难以理解和维护。适度的冗余可以降低设计的复杂性，提高团队对数据库结构的理解和沟通效率。

在一个学校管理系统中，如果将学生的班级信息独立为多个表，可能增加理解难度。为了简化设计，可以在学生表中直接存储班级名称。

破坏3NF后的设计：

通过在学生表中直接存储 班级名称 和 班主任，减少了表的数量，简化了设计。

3. 总结

本文，我们分析了数据库的三范式以及对应的示例，它是数据库设计的基本规范。但是，在实际工作中，为了满足性能、简化设计、快速迭代或特定业务需求，我们很多时候并不会严格地遵守三范式。

所以说，架构很多时候都是业务需求、数据一致性、系统性能、开发效率等各种因素权衡的结果，我们需要根据具体应用场景做出合理的设计选择。

4. 学习交流

如果你觉得文章有帮助，请帮忙转发给更多的好友，或关注公众号：猿java，持续输出硬核文章。

前言

今天是新公司入职后的三个多月了个人也是如愿的转正了，对于我个人而言此时的心情好像没有三个月前刚拿到offer那样的喜悦和兴奋了，更像一件很普通的事情在你身边发生了吧。从2023年底离职在到2024年初开始找工作中间休息了三个月，找工作到入职花了一个多月，在这个过程中也是第一次真真切切感受到了所谓大环境低迷下的“前端已死的言论”，也给大家分享一下自己入职三个月的个人感受吧。

从上一家公司离职时的个人感受

因为上一家公司的工作性质是人力外包驻场开发，年底客户公司（中国移动成都产业研究院）我所在的项目组不需要外包人员了，个人也是被迫拿了赔偿灰溜溜的走人了。

工作感受：对于这段工作经历我个人还是比较认可的，毕竟这里没有任何工作压力，也不加班，工作量少，有很多时间去学习新东西，做做自己的开源，认识了新的朋友等等。

学历的重要性：在这里面随便拎一个人出来可能就是研究生学历的国企单位,自己真实的意识到了学历的重要性（第一学历小专科的我瑟瑟发抖）。

和优秀的人共事：如果在一个长期压抑低沉消极的环境下工作无论你的性格在怎么积极乐观开朗，可能也很容易被影响到。相反如果是和在一群积极，乐观，开朗，充满自信的环境和人一起工作，相信你也会变得积极，乐观，自信这或许也是我这一段工作经历最大的收获吧。

2023年底找工作的市场就业环境

抱着试一试的心态在boss上更新了自己的简历状态，不出所料软件上面安静的奇怪ps:49入国军的感觉，已读未回可能是很失望的感觉吧，但年底找工作令人绝望的是大多数公司都是未读未回，这也就意味着年底基本上是没有正常公司招聘的了。

大概投了两周简历后终于在智联招聘上约到了一个短期三个月岗位的面试，现场两轮面试通过了，不过最终还是没有选择去。

原因有很多：

总结：年底招聘的公司基本上没啥好鸟，如果你的经济能力还行的话让自己放松休息一段时间也是不错的选择

2024年初找工作：真实的感受到了大环境的低迷下的市场行情

印象最深刻的是在疫情时期的2021年，那会儿出来找工作boos上会有很多HR主动给你打招呼，一周大概能五六个面试，大专学历也有机会去自研公司

解封之后本以为市场行情会变得回缓，结果大概就是今年可是未来十年行情最好的一年

简单总结一下2024年的成都就业环境大概这样的：

截至入职新公司前boss上面的投递状况：沟通了1384个岗位，投递了99份简历，一共约到了 8 家公司的面试

今年找工作的个人感受：不怕面试，就怕没有面试机会

首先说一下个人的一些情况吧，因为在创业小公司待过在技术栈方面个人认为算是比较全面的了

项目经验：做过管理系统(CRM,B2C,ERP，saas等管理系统)、商城和门户网站（响应式，自适应）、移动端（H5,小程序，app）、低代码和可视化（工作流，可视化大屏，3d编辑器）、第三方开发（腾讯IM,企业微信侧边栏）、微前端

项目经历:从0-1搭建过整个大项目的基建工作，封装过项目中很多功能性组件和UI组件二次封装（提高开发效率），接手过屎山代码并重构优化，约定项目的开发规范，处理很多比较棘手的疑难bug和提供相关的技术方案，没有需求概念下的敏捷开发，从0-1的技术调研等

代码方面：写过几个开源项目虽然star数量不多（目前最多一个项目是600+），但在代码规范和可读性方面个人认为还是比较OK的（至少不会写出屎山代码吧）

工作经验（4年）：2020毕业至今一直从事前端开发工作

学历：自考本科学历（貌似没啥卵用）

学历确实是我很硬伤的一个点但是没办法，人嘛总归要为年轻时的无知买单吧

在这样的背景下开启了24年的找工作，从2月26号开始投递简历到4月1号拿到offer差不多一个多月左右时间，一共约到了8加公司的面试，平均一周两家公司

大概统计了一下这些公司的面试情况：

公司A:

公司B

到现场写了一套笔试题，内容记不清楚了

公司C

公司D

笔试+面试

公司E

笔试+面试+和老板谈薪资

1.笔试:八股文

2.面试:主要聊的是项目内容比如项目的一些功能点的实现，和项目的技术点

3.老板谈薪资:首先就是非技术面的常规三件套（离职原因，期望薪资，职业规划），然后就是谈薪资（最终因为薪资给的太低了没有选择考虑这家）

公司F

也是最想去的一家公司，一个偏管理的前端岗位（和面试官聊的非常投缘，而且整个一面过程也非常愉快感受到了十分被尊重）

可惜的是复试的时候因为学历原因，以及一些职业规划和加班出差等方面上没有达到公司的预期也是很遗憾的错过了

一面：

二面：

1.我看写过一个Express+Mongoose服务端接口的开源项目，说说你在写后端项目时遇到过的难点

2.介绍一下你写的threejs 3d模型可视化编辑器 这个项目

3.以你的观点说一下你对three.js的了解，以及three.js在前端开发中发挥的作用

4.现在的AI工具都很流行，你有没有使用过AI工具来提高你对开发效率

5.说说你认为AI工具对你工作最有帮助的地方是哪些

6.以你的观点谈谈你对AI的看法，以及AI未来发展的趋势

7.你能接受出差时间是多久

8.你是从去年离职的到今天这这几个月时间，你是去了其他公司只是没有写在简历上吗?

9.说说你的职业规划，离职原因，你的优点和缺点，平时的学习方式

公司G

一共两轮面试，也是最终拿到正式offer入职的公司

一面：

二面：

hr电话：

因为后面没有别的面试了，再加上离职到在到找工作拿到offer已经有四个月时间没有上班了，最终选择了入职这家公司

入职第三天：我想跑路了！

入职后的第一天，先是装了一下本地电脑环境然后拉了一下项目代码熟悉一下，vue3,react，uniapp 项目都有

崩溃的开始：PC端是一个saas 系统由五个前端项目构成，用的是react umi 的微前端项目来搭建的，也是第一次去接触微前端这种技术栈，要命的是这些项目没有一个是写了readme文档的，项目如何启动以及node.js版本这些只能自己去package.json 文件去查看，在经过一番折腾后终于是把这几个项目给成功跑起来了，当天晚上回家也是专门了解了一下微前端

开始上强度： 入职的第二天被安排做了一个小需求，功能很简单就是改个小功能加一下字段，但是涉及的项目很多，pc端两个项目，小程序两个项目。在改完PC端之后，开始启动小程序项目不出所料又是一堆报错，最终在别的前端同事帮助下终于把小程序项目给启动成功了。

人和代码有一个能跑就行：入职的第三天也从别的同事那里了解到了，之前sass项目组被前端大规模裁员过，原因嘛懂得都懂? 能写出这样一堆屎山代码的人，能不被裁吗?

第一次知道 vue 还可以这样写

对于一个有代码强迫症的人来说，在以后的很长一段时间里要求优化和接触完全是一堆屎山一样代码，真的是很难接受的

入职一个月：赚钱嘛不寒掺

在有了想跑路的想法过后,也开始利用上班的空余时间又去投递简历了，不过现实就是在金三银四的招聘季，boss上面依旧是安静的可怕，在退一步想可能其他公司的情况也和这边差不多，于是最终还是选择接受了现实，毕竟赚钱嘛不寒掺

入职两个月：做完一个项目迭代过后，感觉好多了

在入职的前一个月里，基本上每天都要加班，原因也很简单：

1.全是屎山的项目想要做扩展新功能是非常困难的

2.整个项目的逻辑还是很多很复杂的只能边写项目边熟悉

3.因为裁了很多前端，新人还没招到，但是业务量没有减少只能加班消化

功能上线的晚上，加班到凌晨3点

在开发完一个项目迭代过后也对项目有了一些大概的了解，之后的一些开发工作也变得简单了许多

入职三个月：工作氛围还是很重要滴

在入职三个月后，前端组团队的成员也基本上是组建完成了，一共14人，saas项目组有四个前端，虽然业务量依然很多但是好在有更多的人一起分担了，每周的加班时间也渐渐变少了

在一次偶然间了解到我平时也喜欢打篮球后，我和公司后端组，产品组的同事之间也开始变得有话题了，因为大家也喜欢打球，后来还拉了一个篮球群周末有时间大家也会约出来一起打打球

当你有存在价值后一切的人情世故和人际关系都会变得简单起来

在这个世界上大多数时候除了你的父母等直系亲属和另一半，可能会对你无条件的付出

其余任何人对你尊重和示好，可能都会存在等价的利益交换吧

尤其是在技术研发的岗位，只有当你能够完全胜任这份工作时，并且能够体现出足够的价值时才能够有足够的话语权

入职三个月后的感受

大环境低迷下，随时做好被裁掉的准备

从2020年毕业工作以来，最长的一段工作经历是1年4个月，有过三家公司的经历

裁员原因也很简单:创业小公司和人力外包，要么就是小公司经营问题公司直接垮掉，或者就是人力外包公司卸磨杀驴

除非你是在国企单位上班，否则需要随时做好被裁掉的准备

什么都不怕，就怕太安逸了

这句话出自《我的团长我的团》电视剧里面龙文章故意对几十个过江的日本人围而不歼时和虞啸卿的对话，龙文章想通过这几十个日本人将禅达搅得鸡犬不宁，来唤醒还在沉睡在自己温柔乡的我们，因为就在我们放松警惕时日本人就已经将枪口和大炮对准了我们。

或许大家会很不认同这句话吧，如果你的父母给你攒下了足够的资本完全可以把我刚才的话当做放屁，毕竟没有哪一个男生毕业之前的梦想是车子和房子，从事自己喜欢的工作不好吗? 但现实却是你喜欢工作的收入很难让你在这座城市里体面的生活

于我而言前端行业的热爱更多是因为能够给我带来不错的收入所以我选择了热爱它吧，所以保持终身学习的状态也是我需要去做的吧

前端已死?

前端彻底死掉肯定是不会的，在前后端分离模式下的软件开发前端肯定是必不可少的一个岗位，只不过就业环境恶劣下的情况里肯定会淘汰掉很多人，不过35岁之后我还是否能够从事前端行业真的是一个未知数

结语

选择卷或者躺平，只是两种不同的生活态度没有对与错，偶尔躺累了起来卷一下也是可以的，偶尔卷累了躺起了休息一下也是不错的。

在这个网络上到处是人均年收入百万以及各种高质量生活的时代，保持独立思考，如何让自己不被负面情绪所影响才是最重要的吧

去年的：# 2023年总：裁员、买车、结婚、准备当爹🐲

笔者

• 96生农村，河南信阳


• 被裁2次，工作5年多，目前在杭州一家车企


• 摸鱼群 / 找工作群，加我wx：V798595965

一、布丁的出生

2024-9-19，我儿子布丁顺顺利利来到这个世界。

1.1 出生那一刻

一开始觉得没什么，但是当微信收到老婆发的信息，那一瞬间感动的热泪盈眶😭。生完还需要在产房观察2小时，我在外面等的这段时间，描述不清楚是什么感受。当时找了个角落，给自己录了几段视频，想说的话，巴巴拉拉啥都说说，不过现在也没看过😂

1.2 费用

全部费用没算过，就生娃住院那4天，自费部分差不多6500左右，包含1350的护工费（450*3），包含48天后产妇体检的费用。

因为是一胎，咱也没啥经验，害怕很多意外的出现，所以就选了杭州产科最强的医院：市一。 因为医院比较老，附近停车贼困难，而且还很贵，10块一小时。SUV停了几次机械车位，差点把后视镜干掉了。

实际生产还是挺顺利的，宝宝在妈妈肚子里多待了5天，出生之后做的各项目检查都正常。现在看，选着最近的医院才是比较好的选择。

1.3 为什么要生

和一部分人一样，家长催生占一部分，但不是决定性的。去年结婚，对我们而言就是生娃的信号。35岁以上会被定义为大龄产妇，大龄产妇又会面临着各种危险。同条件下，越年轻，生完恢复的也越好。

再加上我姐姐也还没生，我这个家庭相对来说缺一个娃来让整个大家庭更有目标感。所以现在布丁出生后，会有超级多的人来爱他，特别是妈妈和姑姑

偶然在xhs看到一句话：养娃能看到过去自己长大的过程，会把自己认为父母亏欠的部分加倍补偿给自己的孩子，或许是在治愈自己，也或许是在满足自己

1.4 养娃

太多攻略要做了，这里要非常感谢一位朋友的帮助，比我先生宝宝，然后经验都分享给我了，经常问他各种问题😭帮了巨多忙。

养娃不仅仅要研究育儿知识，每个月伺候宝宝的方法还是不同的，宝宝的变化非常非常快。针对宝宝的不同反应，要做出不同的应对。因为媳妇快要上班了，这些东西不能仅仅是我们自己会，还得教他奶奶。但是他奶奶也五十几了，很多东西学不会，记不住，就很困难，也没啥办法。

然后中间还要调解婆媳关系，我日常还要上班，中间有段时间，中午不吃饭，时间全部用来睡觉。。。

现在处于教学痛苦期，观察好宝宝的反应，其实很好哄。但是他奶奶学不会，导致现在给奶奶带，就往死里哭😭。但是我们又不得不依赖他奶奶，不然上班就没人管了。
但是，有时候他奶奶不觉得是自己的问题，就觉得是宝宝的问题，就是要闹人，也不知道找原因，所以我现在是非常痛苦的。有时候只能安慰媳妇，没办法，让宝宝自己适应。。。

1.5 拍拍拍

3个多月了，回头看过去的样子，感觉自己还拍少了😂

1.6 男宝女宝

就身边的现象来说

• 高中同学
  
  
  
  • 目前已知3个女宝
  
  
  
  


• 微信网友
  
  
  
  • 同一天出生的，1个女宝
  
  
  • 去年兔年生的，1个女宝
  
  
  
  


• 村里
  
  
  
  • 目前已知3个女宝
  
  
  
  


• 公司同事
  
  
  
  • 1男宝1女宝
  
  
  • 媳妇同事生1女宝
  
  
  
  


• 同产房
  
  
  
  • 1男宝3女宝
  
  
  
  

15个宝宝，只有2个男宝，13个女宝。 生男生女，概率不是差不多吗？
我倒是无所谓，生男生女，各有各的好处。你们身边男宝多还是女宝多？

二、工作

去年武汉被裁后，就来杭州这家了，当时还有点小插曲。因为武汉一家公司在我入职这家后又给了offer，我很纠结要不要去，当时处于这也想要，那也想要的状态，精神差点崩溃。

2.1 极越（集度）

关注新能源的应该都知道这个事吧，12月直接宣布原地解散了。去年在武汉可是大规模招聘，开的也算武汉Top几了。当时面了4轮，战线拉一个月，后面HC收紧被待定，然后一个月以后又联系给offer，蜜汁操作。要是早给，我肯定就去了。。。

去了的话，现在又是找工作的时间。我媳妇就认为是她的功劳，不是她在杭州，不是她对房子没有那么大执念了，我肯定又回武汉了。当初想去集度，就想赌一把百度智驾。我想着百度都干那么久了，对其他车企不得是降维打击，结果啊，百度还是那个百度。

间接躲过一劫，差点失业

2.2 晋升

虽然结果没出，但是我觉得是个伤心事

2.3 面试

帮忙面试

最近帮着公司招外包，收到一些十年以上经验的简历，很尴尬。简历潦草的，让人感觉他们自己也没抱什么希望，上次招聘给了几个大龄的面试机会，结果一个不如一个。第一次9月份，第二次就是最近。9月份也面了挺多的，过了几个，但是当时卡的严，最后一面基本都被毙了，卡着卡着，HC就变成了0

还有个现象就是异地简历贼多，很多都不是在本地工作的，可见大家都在海投，市场情况就是这样

今年又出1个外包HC，我有时候面1面，有时候面2面，给过了几个，不知道能不能来入职。

前端分类

简单分为，1-3年，3-8年，8年+，外包，自研

3年内的多是自研，简历写的都挺不错，但是一问就不会，一问就是别人做的

5年左右，最近一份干外包的居多，技术也还不错

8年+的，很大一部分就简历拉跨，技术也拉跨，各方面都不太行，当然厉害的也不会来投递外包了哈

今年面试感觉到的情况，并不具有代表性，各位简单看看

简单分析

结合我自己现在的状况，我也明白为什么，就是技术停滞，就是学习能力在逐步下降，不得不服。或许因为懒惰，或许因为家庭事情越来越多。。今年我没怎么学习过，就写了1篇掘金文章，很是惭愧。有更多的时间，不是在打游戏，就是在刷视频，看直播。我尝试着在改变，但是有点难。。。

自己也越来越老，通过面试官的身份反省自己，得好好学习，不仅仅是技术方面。

2025年，我还是需要在这块寻找突破口，不能再停滞不前了，不然迟早要被淘汰。

三、旅游

因为有了车，计划了挺多地方的自驾游，但是因为媳妇怀孕，所以就只能轻度转转，尽量避开人多的地方

3.1 南京

视频带奶奶看了下玄武湖，还不如杭州湘湖，哈哈哈

3.2 千篇一律

之前想着把国内这些一二线城市都逛逛，感受感受。但是吧，现在感觉都是千篇一律的商业街，风景区，真没啥意思。每次做攻略都做的好好的，去了以后就感觉和理想的落差太大，然后从这次南京后，就不太想玩这种很常规的旅游了。

看xhs说，这是要加入下一个level的迹象了，明年等小布丁1岁后，他奶奶能带的时候。计划计划去港澳台逛逛，然后日本韩国这些，怎么都得去看看吧。。。

四、主机

4.1 入手

6月初，终于入手了人生第一台主机，是的，没错。毕业5年了，第一次拥有自己的主机，之前都用MacBook 虚拟机打游戏，LOL fps，30~60😂

4.2 配置

2024-5-29价格：

• 板U： 微星B760 爆破弹 Wifi D5 + 12600kf 1694


• 显卡：微星RTX4060 VENTUS2 X WHITE8GOC白色 2180


• 电源：微星MAG A600DN额定600W 234


• 机箱：微星PAG PANO M100L 白色 188


• 散热：微星MAG 寒冰E240白色水冷 369


• 内存：威刚D300 16G 6400MHZ 387


• 硬盘：威刚S50 PRO NVME 1TB 465

合计：5517

pdd微星官方旗舰店整机4999，用卷到手4863

4.3 为什么卖

主要3个原因

• window和mac两种系统切换着用，还是不太舒服，更喜欢mac


• 空闲时间就爱玩LOL，玩几把就要红温


• 有两次下班没带娃玩LOL，媳妇生气了

想了想以后，主机对我也没太大吸引力了，就挂xhs了，就挂了一天，第二天晚上卖了。4863买的，用了半年，卖了4050。

黑神话开挂通关的、使命召唤系列玩了3部，总体也算是过瘾了。

卖完只有一个感慨：老了，花有重开日，人无再少年

4.4 JJ卖主机的奇幻经历

AB两个买家，A爽快最终成交，B一直砍价最后破防

A需送上门 B上门自提，时间线如下：

• B凌晨3点就给我发了个消息，要购买记录，我早上回复了下，人家看我买半年了，砍价说3800，我说不出


• A看到后直接问3900送上门行不行，我犹豫了，来回70km+可能现场验收有问题，就拒绝了。拿着3900，我问早上的B要不要，要的话就给B了。结果B还在还价，问3850行不行，我拒绝了。


• A看我犹豫，直接说不还价了3999送上门，他急着用。我就准备和他交易了，这个时候B又来了，问我怎么样，我说A直接3999了，B这个时候急了，说他也可以3999，现在就可以上门


• 同价格我肯定选择B上门自提的，但是这个时候A已经拍下了咸鱼链接，我和A说了这个事，他又给我加了50，意思给路费。 我和B说，他那边已经拍了，B就生气了，长篇大论说我人不行。。。

所以最后的结果：我怕B是个事逼，而且A已经拍了，所以还是选择送货上门和A交易，A比较痛快，貌似是个主播，上门简单验机后直接打钱，省了咸鱼0.6%的手续费

这俩人都是玩无畏契约的，玩过几把，这游戏现在这么火？🔥

4.5 老了

回来路上，一个人在高架上飙了一把，只能感慨：花有重开日，人无再少年

五、11月软考

5.1 系统规划与管理师

过去没有了解过杭州政策，最近朋友说了考这个东西的好处，可以认证E类人才。买房只需要30%，不买房每个月也有2500补贴，政策很香。所以准备来试试，但是因为很久没看过书了，+懒+生娃各方面的因素，几乎没看，考试前还一直在想要不要去考。后面一想，钱都交了，不得去试试，看看裸考能考多少。

结果就是：

还有俩朋友一起考的也没过，很多认真学的，一部分卡在了论文上。毕竟这个东西和利益相关，所以会卡通过率。

5.2 信息系统项目管理师

2025-5月来战斗，有一起考的没！！！

六、其他

零零碎碎的其他事，不想花费太多精力去写这个，年级大了，很多东西都要和利益挂钩。没得利益，就不太愿意付出了。

6.1 兼职

• 赚了几个w，非理财


• 辛苦钱且不稳定


• 得寻找比较稳定的睡后收入

今年国庆节那波股市，太猛了。本来准备拿10个入场的，媳妇都同意了，还是胆小没敢上。。。差点套进去

6.2 领证

感觉要给孩子出生做准备了，之前了解的准生证、建档什么的都得结婚证，反正去年也结婚了，赶紧找时间领了，方便后面办户口。

实际上现在很多都放开了，并不需要结婚证，领了证反而变成已婚了，租房个税都只能填一个人的了。领了证，现在这行情，浙江刚落地的13天婚假也不敢休，有些地方领结婚证还给钱。

所以，领证没得啥好处，建议大家能不领还是不要领

6.3 减肥

• 减了30斤，不过现在还是很胖


• 目前体重稳定了一个月，继续开始减

6.4 房子

• 和媳妇两个人都不再有买房的执念


• 租了个两室一厅，4200，住的挺舒服的


• 没有房贷、没有车贷、没有任何贷款


• 养着小布丁，满足了

6.5 计划

2025年，全面拥抱AI，用一句话说：所有行业都值得被AI重构

想要更多技术分享和摸鱼乐趣？

• 加入微信摸鱼群：一起交流学习，共享资源，偶尔摸鱼，趣味多多！


• 关注公众号 [前端技术圈儿] ：获取最新的前端技术干货、学习笔记和实用工具推荐！


• 加我wx：V798595965

快来和我一起探索前端世界吧！ 🚀

最后再放一波儿子

作者：三哥

个人网站：j3code.cn

本文已收录到语雀：http://www.yuque.com/j3code/me-p…

是的，真进电子厂了，但主人公不是我。

虽然我不是主人公，但是我经历的过程是和主人公一样的，真实而又无奈。真实是真真切切的经历了这一段过程，而无奈则是我进厂这段旅程所体会出来的。

如果你对我的这段经历感兴趣，可以耐心的往下看。

故事

这里我先定义一个主人公 A，然后他来我这边找工作，那么我作为在广州待了有些年头的靓仔（一坤年多点），肯定要出时间给他张罗张罗，所以就有了这一段难忘的经历（现在回想起来，我是不想再经历第二次了）。

在广州没有学历，能选择的工作其实并不多，无非就是进厂或者打零工当学徒。但奈何我也没有什么找工作的门道，所以只能帮着从某直聘软件上刷工作岗位了。只要是不要求经验，学历的统统都是我备选岗位中的一个。在这里就不得不说在某直聘软件上，刷这种普工、配/拣/打包等岗位一刷一大堆，而且还自动找上门来，不像我现在干的程序员行业，要么进人才库要么人才库都不配进，只能石沉大海。

在结合 A 自身的情况和交通出行方便的情况下，我们决定接受进厂工作。因为他们发的待遇信息确实很吸引人，如：小时工 30/小时，多劳多的；正式工底薪加提成综合薪资7-8k；还包吃包住。你看，这怎么能不吸引人，怎么能不吸引一个以前只能拿 2-3k 工资不包吃不包住的主人公 A 呢！当然，我当时也觉得非常可以，以至于不假思索的和主人公 A 达成了统一战线。

那么，这次的难忘之旅就由此展开了。

先是早上按照他们微信上聊的，带好行李，身-份-证去一个交通非常方便的地铁口面试。那么我在想去面个试带行李干啥，我放在住的地方也挺好的，等面试通过了，安排住宿的地方了，我在将行李搬过去，这不简单轻松嘛。所以我和主人公 A ，就一致决定没有带行李过去，直接人 + 身-份-证过去面试，然而奇怪的点就来了。当我们到达面试的地方时，见到好多外来务工的人，这一幕让我有点触动。都是大包小包，蛇皮袋+黑行李箱，然而我两却空空如也。这时候我还没意识到问题的严重性，就直接过去问怎么面试，而那个穿蓝色工作服的人只是抬头撇了我一眼，看我们没有行李，直接抬手挥了挥，说没行李的不收。我说，为什么，他也不搭理我，直接说别妨碍后面的人面试（其实后面也没人），不收就是不收。

在这里我已经忍不了了，先说一下此刻我的内心：diss 他上下 18 代无数遍了，后面细讲，咱们先看故事。

其实我当时是想直接怼他，但为了照顾主人公 A 的情况，我忍了，重新回家去拿了一次行李，然后再次去面试的地方找工作了，但这次不是上一个地点，而是我另一个备选面试（也是需要行李，还是行李）。

两个人拖着个行李，酿酿跄跄的来到了下一个面试点，还是和上一个面试点一样的流程，但这次不同的是我带了行李，ok，他接收了，说等会安排面试。其实我以为这就完了，但是并没有，这才是开始的第一步。

等了一会之后，这个面试点就陆陆续续的来了二三十个人，也还是和我上次看到的人群一样，大包小包，蛇皮袋+黑色行李箱。此时我内心就不仅感慨，为了个工作也是不容易。等了差不多十几分钟就有个嗓门大的人喊，要面试的人跟我来，带上行李，没行李的不要来。就这样，我和主人公 A 被带到了一个不是很大的大厅，里面差不多容纳了几百人，此时我又被触动了（是的，以我目前的认知，我这段经历会被触动很多次），感觉进了传销一样。

从进入那个大厅以后，我就觉得非常无力，这种无力感你只有亲自体会了才知道。全是人，但就是没有工作人员，只知道等着叫号，其余时间找个地方坐着。当时就想，走也不是来都来了，留也不是和印象中的面试太不一样了。所以就在这种内心纠结中，徘徊了几个小时，是的你没看错，就是几个小时（起码两小时）。

这期间其实还有套路，我怕文章会写的很长，就忽略了，如果你们想听，以后多关注我 B 站直播，我会时不时的讲出来。

中午的时候，终于有个人扯着嗓门喊话，让我们安静下来，听他介绍后续的招聘流程。他的话不是很精炼，但是足够洗脑，因为他会在合适的时机给这些找工作的人透露，在该公司上班工资比的过广州大多数CBD上班的白领。只要这话时不时的出现，人群就会时不时的骚动几下，其实我能明白这些务工人拼搏一年不就是为了多赚点吗？听到高薪，眼睛发光是在正常不过了。但是，我就是看不惯这些中介公司层层剥利，压榨忽悠这些信息闭塞的外来务工人员（我这是事后才知道，不是工厂直招，而是中介）。

反正一番讲话之后，我们被分成了两批人，一批工资高点，但是上班地点异常的偏僻，另一批就是工资地点，但好在是市里，交通方便。

但我个人觉得，工作高低也是骗人的，说的高工资，去的人就多，他们抽的利也就多。

而我选择工资低的这类工作也就是看中他交通方便，能时常照顾一下，帮点忙啥的。

但，你以为这就完了嘛，并没有。之后的这些时间，我被他们用大巴车从集合点、拉到电子厂、再由电子厂拉到体检中心、最后拉到安排宿舍大楼。每一个地点的具体事宜如下：

这期间，我们还没工作，杂七杂八的费用就被他们收去了 200 块（我们没有办卡，如果办卡了估计更多）。而且以上的时间线，每一个点都是非常熬人的，我一个正常男子都觉得非常累非常累，真不知道那些年纪小的、年纪大的、女生是如何坚持下来的。

熬人是因为，我们是一批人一批人的过，要等到这一批人的流程走完了才能走下一个流程，而且有些流程只有特定的时间点才开始，来早了，你就给我等着，到点才开始。

最后，当你分配到一张上下铺的床位后，你的这一趟流程就算是彻底走完了，时间也应该是来到了晚上六七点，所以就为了一个进厂工作的机会，从早上九点折腾到晚上六七点，真 TM 累。

以上就是我今天一天所经历的事情，现在想想，如果是你，你会为了进厂而这样折腾吗？

有感

不经历一遍，永远是不能感同身受。

上面的故事你们看了，也就是看了，可能内心都不会有一点波澜，但这个没关系，如果条件允许我希望看到这篇文章的人，永远都不要有这种经历。

首先，我来对这种中介第三方公司招人的方面，来说说我的看法：

你们要先分别什么是工厂直招还是第三方中介招聘，如果是从某直聘上看到的岗位应该是会写“派遣”或者“代招”。当然，也有不写的，那么这就需要后续的判断了“没有行李不接待”。是的，就是这个，我现在才反应过来，如果你去面试，不带行李，他们接待你，然后给你安排这一系列的流程，你中途觉得不靠谱，你是可以随时走人的，一点都不麻烦。但是如果你是大包小包 + 黑色行李箱的话，那么你就不可能那么方便的随时想走就走了，这个行李就是第三方中介拷住你的加锁。

你们也不要相信从某直聘上加的所谓人事的话，他们只有一句话是真的，那就是引你到面试的地点是真的，其余的都是假话，其余的都是假话。如果你们以后不幸碰到我上面的故事情节，千万不要对这种人抱有任何的感激，觉得他们真好，为了给我一个工作机会，解答我的各种问题。醒醒吧！你的真诚/感激之情真有可能是喂了狗（狗子对不起，不应该拿你做对比），你带着真诚的心态去问你所不了解的各种问题，他们只会用高薪，轻松等话术迷惑你。因为他们招到一个人，拿一个人的提成，你们只是他们的赚钱工具，才不会管你这个工作是否真高薪，真轻松，如果是为啥他们自己不上。

这种第三方公司做事效率是非常快，一天办理几百人的入职流程，为了就是让你们入职，他们有提成。如果等到第二天你们反应过来，后悔了，那么他们就没钱可赚了。效率快是好，但是整套流程下来，你们有没有发现，连午饭时间都不给人了（就怕你们溜走）。是的，我当时就是没吃午饭，硬撑着走完了一天。而且在后续我与同行的打工人交谈过程中了解到，有些人早饭都没吃，也就是一点都行没吃，来来回回折腾一整天，直到晚上才有时间去吃饭，而这个时候就不怕你走了，因为你的入职流程已经办完了，该交的钱也交了。

以上套路只是我经历过得一种，但肯定不止这一种，希望大家能提前辨别！

接着，我来说说这一天，我与同行人交谈过程中了解到的各种人生经历：

虽然我是程序员，但绝不是那种沉闷不爱社交的性格，相反我还是挺爱和人交谈的，爱听别人的故事也爱和别人分享我的故事。

我碰到的第一种人就是未满 18 岁的小孩，故事开始的时候我提过，前期我是被人带到一个大厅集合的，之后，未满 18 岁的小孩就被所谓的工作人员给筛选出来了。其实说是筛选出来，肯定也不是让他们走，只是安排他们去那种更偏僻、工资更低一点的、对年龄要求不严格的小厂工作。反正，只要有人头进入工厂，他们这种中介就有钱赚，只是从你身上赚多赚少而已。

看着这几个未满 18 岁就出来打工的小孩，内心多少都是有点不是滋味。毕竟这个时候他们应该是呆在校园，且正处于高中，正是读书改变命运的关键时刻。但，我想这种再次读书的机会，应该是不会在这几个小孩身上出现了。因为我没有机会和这几个小孩说话，所以不知道他们是什么原因走出校园，走出家庭，而选择步入社会。但是，希望他们几个往后能一帆风顺，改天换命。

第二种人，我也没有机会和他说话，我关注到他是因为一段对话：

招人的负责人说：看你年龄比较偏大，都 45 了？

务工大哥：是，确实大了点。

招人的负责人说：像你这种情况，年龄比较大，我可以招你进去，但是工厂要不要，就不能保证了，这个你要明白。

务工大哥：行，就过去试试吧！

招人的负责人说：好，等会跟着一起过去。

其实从这段对话中我们也能很快想到，工厂肯定是不想要那种年龄偏大的员工了，毕竟工作强度还是有的，万一出现什么身体情况，咋搞。而务工大哥，肯定也是不想失去这种工作机会嘛，毕竟对于他而言，能有高工资就行，其他的应该都是次要的。

看着这务工大哥珍惜工作机会的态度，我瞬间就醍醐灌顶。内心不禁在想，是什么样的生活压力或者其他原因，才能让这务工大哥情愿跟着一群小年轻这样奔波找工作。

因为没有机会和这位务工大哥搭上话，所以我也就内心想想罢了。

第三种人，我终于是和他们搭上话了，他们都很年轻。在和他们简单的交流过后，我了解到的情况大致如下：

年龄基本都是18、19岁左右，并且学历都不高，有初中、高中、中专等学历的。还有些是中途辍学，并没有完整的读完学历就出来工作的，而且我问他们不读书的原因，他们的回答基本都是自己不想读了，想出来找工作，有钱花。所以现在读书，倒不是家里穷读不起，而是很大一部分人，受不了社会上的一下诱惑，想要快点赚钱，好有能力买各种喜欢的东西，包括打游戏买装备（因为和他们聊天中，都是游戏不离手的状态）。

像他们这种，吃不了学习上的苦，就只能吃生活上的苦。以后或许他们还有选择的机会，毕竟还年轻，但是，我想他们应该在未来很长一段时间，都是游离在各种电子厂。因为感觉他们还是玩心重，而电子厂这种工作，多白了就是工作轻松，多劳多得，还包吃包住。等到某一时刻他们过腻了这种日子，应该能重新审视一下自己，未来的路，希望他们能早点醒悟。

第四种人，你可以理解他们是第三种人的升级版，就是他们一直没有醒悟，一直都是从事着电子厂这种工作。只是从厂 A，来到了他们认为工资，工作各方面还不错的厂 B 而已。你可以在他们身上看到全国各地奔波的痕迹：蛇皮袋、黑行李箱、竹席被褥、胡子拉碴、头发凌乱、烟味很重。我提到的这些，只是单纯的用文字写出来，而没有任何的其他意思。在和他们交谈的过程中，能很明显的看出一种无奈的心情出来，他们无非就是想要一个稳定，有点收入的工作。但是工厂就是这样，忙的时候招人，不忙的时候拼命的赶人。他们也不想走的，但工厂不忙，肯定是不发工资的，你这样呆在工厂没有任何的意义，所以只能又拿起行囊四处奔波。

所以，生活就是充满着未知的变化，我们能做的就是不断的提升自己，来面对这种变化。希望能看到这里的人，都不被生活所压迫，加油吧！

还有最后一种人，也是我最想不到的一种人。他们在没有进厂之前，手底下有十多号人，一个月光租金就可以花出去五六万。是的，我们暂且可以把他们定为老板被迫进厂的一类人。

说他们是老板，一点都没错。因为他们在没有进厂之前，确实是自己开店做老板的，只是因为 21 年疫情的时候，大家都闭门不出，实体经济很难再维持这种高房租的压力，所以才被迫关店，倒闭。我那时问他们，为什么不多坚持坚持，你看现在不就春暖花开了吗？他们只是面带苦涩的说，多坚持一个月，就是五六万的流水出去，而且那会不知道什么时候是个头。并且他们不是没坚持，而是已经没有钱再可以坚持下去了，所以只能现倒闭，让自己缓一缓，释放一下压力。

我也确实从他们身上感受到了他们所说的压力，只出不进，五六万的流水，这谁能受得了。并且疫情过去的时候，也想过重新再来，但是已经没有钱可以再来了，那会欠的钱还没还清，已经没有资金重头再来了。

这一天的交谈中，我见过两个这种人，以前都是老板，也都是因为疫情原因，赔钱了，只能进厂缓一缓，让自己好受一点。但是他们毕竟是见过一些世面的人，你可以很明显的感受到他们和前面这几种人不一样，如装扮、说话和回答问题方式，并且他们也都很乐观，还说，等我在工厂缓过来之后，还是会继续再拼搏一番。你看看，这不就非常好嘛！在人生的这条道路上，如果你跌倒，说明你选择的是一条坎坷的路，只要你能站起来，继续走下去，我相信你的收获绝对能对得起你这一路的坎坷。

好了，洋洋洒洒五千多字，算是我对那天经历的一个交代。如果你看到这里，内心也有一些感触，说明你是一个感性的人，欢迎你在评论区留下你的足迹。

题外话：主人公 A 最后还是没去成！🤣🤣🤣

支付宝

支付宝昨天（2024-01-16）的无差别"送钱"的事儿，大家都知道了吧。

具体的，就是在昨天 14:40~14:45 期间，所有支付宝的支付订单都被减免了 20%，减免原因在界面上显示为"政府补贴"。

这里指的订单，是指所有通过支付宝产生的交易，包括「购物、信用卡、生活缴费、个人转账」等等，而且和此前（消费类的）有减免上限的政府补贴不同，本次减免无上限，统统 20%。

好家伙，个人转账 5W 减免 1W，那些刚好在那段时间有大额支付的幸运儿，你能想象他们多开心吗 🤣🤣🤣🤣

如此重大的 P0 事故（互联网公司对线上事故的评级，代表事故最高等级），虽然只有短短的 5 分钟，但如果被反应快又别有用心的不法分子利用上（同一笔钱，两个账号来回转），那就可不是一点羊毛的事儿，可能几十上万上百万，整条羊村都被薅走了。

正当所有人都觉得支付宝一定会或多或少有"追回"行动时，凌晨一则来自「支付宝官方微博」的公告说明来了：

简单总结的话：错误在支付宝一方，给出的优惠不会再追回。

好家伙，这属于是给这小部分的幸运儿发"过年费"了 🍋🍋🍋

虽然犯的是如此低级的错误，不像大公司所为，但处理方案又是实打实的"有格局"。搞得我都不好意思笑支付宝"草台班子、降本增笑"了 🤣🤣🤣

从本次的处理方案来看，我们可以做一些合理的猜测：

从这个发布声明的时间点来看，不难猜测，对于这次事故，支付宝经过了「修正模板 -> 统计事故损失金额 -> 事件逐级上报到高层 -> 高层决议最后处理方案 -> 将处理方案下发对应部门 -> 公关拟对外声明 -> 走声明审批流程 -> 正式发出」等多步环节，导致了声明发出的时间已经接近凌晨一点。

由于声明中涉及「提醒大家不要点击诈骗短信/链接」，因此必然不存在支付宝故意推迟声明时间的可能性，他们从事故到发声明，确实就是花了 10+ 小时。

另外，关于支付宝损失金额的猜测。

如果简单结合数据来看，这个数字会很大。

根据易观分析报告的公开数据，支付宝 2024 年第一季度的交易量为 118.19 万亿元，即每个月 39.4 万亿，折合每天约 1.31 万亿，每小时约 0.0546 万亿，每分钟约 9.1 亿。

事故维持 5 分钟，减免力度为 20%，就当全部订单都是不符合"政府补贴"要求的支付订单，那么损失金额约 $9.1 \times 5 \times 0.2 = 9.1$ 亿。

但实际情况并不会如此直接了当，支付订单的流量也不可能是均摊每天，甚至是每分钟。

从日期来说，1-16 是一个没有节日加成的普通周四；从时间点来说，14:40~14:45 虽然属于"白天"范畴，但也不是什么支付高峰期。

我问了在支付宝工作的朋友，他跟我分享道：一整周里的交易，会有接近一半的交易流水，会在周末假期产生；而如果是周内的工作日的话，会有 8 成的流水会在上班时间（09:00~18:00）以外的时间段产生。

基于此，虽然没有具体数字，同时事故维持时间段（5 分钟），不考虑传播效应导致的交易激增。可以合理推算 2025-01-16 14:40~14:45 产生的交易最多不会超过 20 亿，即亏损最多不会超过 4 亿。相比于简单线性均摊的 9.1 亿，还是要小不少的。

支付宝（蚂蚁金服）是一家全年净利润 238.2 亿的公司，4 个亿的事故，还是支付得起的，只不过导致事故发生的员工和部门，估计要面临大处罚了。

对此，你怎么看？昨天有薅到支付宝的羊毛吗？欢迎评论区交流。

...

回归主题。

来一道和「阿里（校招）」相关的算法题。

题目描述

平台：LeetCode

题号：406

假设有打乱顺序的一群人站成一个队列，数组 people 表示队列中一些人的属性（不一定按顺序）。每个 $people[i] = [h_i, k_i]$ 表示第 $i$ 个人的身高为 $h_i$ ，前面 正好 有 $k_i$ 个身高大于或等于 $h_i$ 的人。

请你重新构造并返回输入数组 people 所表示的队列。返回的队列应该格式化为数组 queue ，其中 $queue[j] = [h_j, k_j]$ 是队列中第 $j$ 个人的属性（$queue[0]$ 是排在队列前面的人）。

示例 1：

输入：people = [[7,0],[4,4],[7,1],[5,0],[6,1],[5,2]]



输出：[[5,0],[7,0],[5,2],[6,1],[4,4],[7,1]]



解释：

编号为 0 的人身高为 5 ，没有身高更高或者相同的人排在他前面。

编号为 1 的人身高为 7 ，没有身高更高或者相同的人排在他前面。

编号为 2 的人身高为 5 ，有 2 个身高更高或者相同的人排在他前面，即编号为 0 和 1 的人。

编号为 3 的人身高为 6 ，有 1 个身高更高或者相同的人排在他前面，即编号为 1 的人。

编号为 4 的人身高为 4 ，有 4 个身高更高或者相同的人排在他前面，即编号为 0、1、2、3 的人。

编号为 5 的人身高为 7 ，有 1 个身高更高或者相同的人排在他前面，即编号为 1 的人。

因此 [[5,0],[7,0],[5,2],[6,1],[4,4],[7,1]] 是重新构造后的队列。

示例 2：

输入：people = [[6,0],[5,0],[4,0],[3,2],[2,2],[1,4]]



输出：[[4,0],[5,0],[2,2],[3,2],[1,4],[6,0]]

提示：

• $1 <= people.length <= 2000$


• $0 <= h_i <= 10^6$


• $0 <= k_i < people.length$


• 题目数据确保队列可以被重建

构造 + 二分 + 树状数组

这是一道非常综合的题目。

首先根据双关键字排序：当「高度（第一维）」不同，根据高度排升序，对于高度相同的情况，则根据「编号（第二维）」排降序。

采取这样的排序规则的好处在于：在从前往后处理某个 $people[i]$ 时，我们可以直接将其放置在「当前空位序列（从左往后统计的，不算已被放置的位置）」中的 $people[i][1] + 1$ 位（预留了前面的 $people[i][1]$ 个位置给后面的数）。

关于「空位序列」如图所示（黄色代表已被占用，白色代表尚未占用）：

具体的，我们按照构造的合理性来解释双关键字排序的合理性，假设当前处理的是 $people[i]$：

根据「高度」排升序，根据「编号」排降序：由于首先是根据「高度」排升序，因此当 $people[i]$ 被放置在「当前空位序列」的第 $people[i][1] + 1$ 之后，无论后面的 $people[j]$ 如何放置，都不会影响 $people[i]$ 的合法性：后面的数的高度都不低于 $people[i][0]$，无论放在 $people[i][1] + 1$ 前面还是后面都不会影响 $people[i]$ 的合法性。

同时对于高度（第一维）相同，编号（第二维）不同的情况，我们进行了「降序」处理，因此「每次将 $people[i]$ 放置在空白序列的 $people[i][1] + 1$ 位置的」的逻辑能够沿用：

对于「高度」相同「编号」不同的情况，会被按照「从右到左」依次放置，导致了每个 $people[i]$ 被放置时，都不会受到「高度」相同的其他 $people[j]$ 所影响。换句话说，当 $people[i]$ 放置时，其左边必然不存在其他高度为 $people[i][0]$ 的成员。

剩下的在于，如何快速找到「空白序列中的第 $k$ 个位置」，这可以通过「二分 + 树状数组」来做：

对于已被使用的位置标记为 $1$，未使用的位置为 $0$，那么第一个满足「$0$ 的个数大于等于 $k + 1$」的位置即是目标位置，在长度明确的情况下，求 $0$ 的个数和求 $1$ 的个数等同，对于位置 $x$ 而言（下标从 $1$ 开始，总个数为 $x$），如果在 $[1, x]$ 范围内有 $k + 1$ 个 $0$，等价于有 $x - (k + 1)$ 个 $1$。

求解 $[1, x]$ 范围内 $1$ 的个数等价于求前缀和，即「区间查询」，同时我们每次使用一个新的位置后 ，需要对其进行标记，涉及「单点修改」，因此使用「树状数组」进行求解。

Java 代码：

class Solution {

    int n;

    int[] tr;

    int lowbit(int x) {

        return x & -x;

    }

    void add(int x, int v) {

        for (int i = x; i <= n; i += lowbit(i)) tr[i] += v;

    }

    int query(int x) {

        int ans = 0;

        for (int i = x; i > 0; i -= lowbit(i)) ans += tr[i];

        return ans;

    }

    public int[][] reconstructQueue(int[][] ps) {

        Arrays.sort(ps, (a, b)->{

            return a[0] != b[0] ? a[0] - b[0] : b[1] - a[1];

        });

        n = ps.length;

        tr = new int[n + 1];

        int[][] ans = new int[n][2];

        for (int[] p : ps) {

            int h = p[0], k = p[1];

            int l = 1, r = n;

            while (l < r) {

                int mid = l + r >> 1;

                if (mid - query(mid) >= k + 1) r = mid;

                else l = mid + 1;

            }

            ans[r - 1] = p;

            add(r, 1);

        }

        return ans;

    }

}

C++ 代码：

class Solution {

public:

    int n;

    vector<int> tr;

    int lowbit(int x) {

        return x & -x;

    }

    void add(int x, int v) {

        for (int i = x; i <= n; i += lowbit(i)) tr[i] += v;

    }

    int query(int x) {

        int ans = 0;

        for (int i = x; i > 0; i -= lowbit(i)) ans += tr[i];

        return ans;

    }

    vector<vector<int>> reconstructQueue(vector<vector<int>>& ps) {

        sort(ps.begin(), ps.end(), [](const vector<int>& a, const vector<int>& b) {

            return a[0] != b[0] ? a[0] < b[0] : b[1] < a[1];

        });

        n = ps.size();

        tr.resize(n + 1, 0);

        vector<vector<int>> ans(n, vector<int>(2));

        for (auto& p : ps) {

            int h = p[0], k = p[1];

            int l = 1, r = n;

            while (l < r) {

                int mid = l + r >> 1;

                if (mid - query(mid) >= k + 1) r = mid;

                else l = mid + 1;

            }

            ans[r - 1] = p;

            add(r, 1);

        }

        return ans;

    }  

};