什么是密封接口？

密封接口（sealed interface）是kotlin 1.5引入的一个新特性，它可以让我们定义一个限制性的类层次结构，也就是说，我们可以在编译时就知道一个密封接口有哪些可能的子类型。这样，我们就可以更好地控制继承关系，避免出现意外的子类型。

密封接口与密封类（sealed class）类似，都可以用来表示一组有限的可能性。但是，密封类只能有一个实例，而密封接口的子类型可以有多个实例。此外，密封类只能被类继承，而密封接口可以被类和枚举类（enum class）实现。

要声明一个密封接口，我们需要在interface关键字前加上sealed修饰符：

sealed interface Error // 密封接口

一个密封接口可以有抽象或默认实现的方法，也可以有属性：

sealed interface Shape { // 密封接口

    val area: Double // 属性

    fun draw() // 抽象方法

    fun printArea() { // 默认实现方法

        println("The area is $area")

    }

}

密封接口的优点

使用密封接口有以下几个优点：

• 类型安全：由于密封接口的子类型是固定的，我们可以在编译时就检查是否覆盖了所有可能的情况。这样，我们就不会遗漏某些分支或者处理错误的类型。
• 可读性：使用密封接口可以让我们清楚地看到一个类型有哪些变种。这样，我们就可以更容易地理解和维护代码。
• 灵活性：使用密封接口可以让我们定义更多样化的子类型。我们可以使用数据类（data class），对象（object），普通类（class），或者另一个密封类（sealed class）作为子类型。我们还可以在不同的文件或模块中定义子类型。
• 表达力：使用密封接口可以让我们利用多态（polymorphism）和继承（inheritance）来实现更复杂和优雅的设计模式。

密封接口在设计模式中的应用

设计模式是一些经过验证和总结的解决特定问题的代码结构和技巧。使用设计模式可以让我们编写出更高效，更可复用，更易扩展的代码。

下面，我们将介绍几种常见的设计模式，并展示如何使用密封接口来实现它们。

策略模式

策略模式（Strategy Pattern）是一种行为型设计模式，它可以让我们在运行时根据不同的情况选择不同的算法或策略。这样，我们就可以将算法的定义和使用分离，提高代码的灵活性和可维护性。

要实现策略模式，我们可以使用密封接口来定义一个策略的抽象，然后使用不同的子类型来实现具体的策略。例如，我们可以定义一个排序策略的密封接口，然后使用不同的排序算法作为子类型：

sealed interface SortStrategy { // 密封接口

    fun sort(list: List<Int>): List<Int> // 抽象方法

}



object BubbleSort : SortStrategy { // 对象

    override fun sort(list: List<Int>): List<Int> {

        // 实现冒泡排序

    }

}



object QuickSort : SortStrategy { // 对象

    override fun sort(list: List<Int>): List<Int> {

        // 实现快速排序

    }

}



object MergeSort : SortStrategy { // 对象

    override fun sort(list: List<Int>): List<Int> {

        // 实现归并排序

    }

}

然后，我们可以定义一个上下文类（Context Class），它可以持有一个策略的引用，并根据需要切换不同的策略：

class Sorter(var strategy: SortStrategy) { // 上下文类

    fun sort(list: List<Int>): List<Int> {

        return strategy.sort(list) // 调用策略的方法

    }

}

最后，我们可以在客户端代码中使用上下文类来执行不同的策略：

fun main() {

    val list = listOf(5, 3, 7, 1, 9)

    val sorter = Sorter(BubbleSort) // 创建上下文类，并指定初始策略

    println(sorter.sort(list)) // 使用冒泡排序

    sorter.strategy = QuickSort // 切换策略

    println(sorter.sort(list)) // 使用快速排序

    sorter.strategy = MergeSort // 切换策略

    println(sorter.sort(list)) // 使用归并排序

}

使用密封接口实现策略模式的优点是：

• 我们可以在编译时就知道有哪些可用的策略，避免出现无效或未知的策略。
• 我们可以使用数据类，对象，普通类或密封类作为子类型，根据不同的策略需要定义不同的属性和方法。
• 我们可以在不同的文件或模块中定义子类型，提高代码的模块化和可读性。

如果使用java实现策略模式，我们可能需要定义一个接口来表示策略，然后使用不同的类来实现接口：

interface SortStrategy { // 接口

    List<Integer> sort(List<Integer> list); // 抽象方法

}



class BubbleSort implements SortStrategy { // 类

    @Override

    public List<Integer> sort(List<Integer> list) {

        // 实现冒泡排序

    }

}



class QuickSort implements SortStrategy { // 类

    @Override

    public List<Integer> sort(List<Integer> list) {

        // 实现快速排序

    }

}



class MergeSort implements SortStrategy { // 类

    @Override

    public List<Integer> sort(List<Integer> list) {

        // 实现归并排序

    }

}

然后，我们也需要定义一个上下文类来持有和切换策略：

class Sorter { // 上下文类

    private SortStrategy strategy; // 策略引用



    public Sorter(SortStrategy strategy) { // 构造函数

        this.strategy = strategy;

    }



    public void setStrategy(SortStrategy strategy) { // 设置策略方法

        this.strategy = strategy;

    }



    public List<Integer> sort(List<Integer> list) {

        return strategy.sort(list); // 调用策略的方法

    }

}

最后，我们也可以在客户端代码中使用上下文类来执行不同的策略：

public static void main(String[] args) {

    List<Integer> list = Arrays.asList(5, 3, 7, 1, 9);

    Sorter sorter = new Sorter(new BubbleSort()); // 创建上下文类，并指定初始策略

    System.out.println(sorter.sort(list)); // 使用冒泡排序

    sorter.setStrategy(new QuickSort()); // 切换策略

    System.out.println(sorter.sort(list)); // 使用快速排序

    sorter.setStrategy(new MergeSort()); // 切换策略

    System.out.println(sorter.sort(list)); // 使用归并排序

}

使用java实现策略模式的缺点是：

• 我们不能在编译时就知道有哪些可用的策略，因为任何类都可以实现接口。
• 我们只能使用类作为子类型，不能使用数据类或对象。
• 我们必须在同一个包中定义子类型，不能在不同的文件或模块中。

访问者模式

访问者模式（Visitor Pattern）是一种行为型设计模式，它可以让我们在不修改原有类结构的情况下，为类添加新的操作或功能。这样，我们就可以将数据结构和操作分离，提高代码的扩展性和复用性。

要实现访问者模式，我们可以使用密封接口来定义一个元素（Element）的抽象，然后使用不同的子类型来实现具体的元素。例如，我们可以定义一个表达式（Expression）的密封接口，然后使用不同的子类型来表示不同的表达式：

sealed interface Expression { // 密封接口

    fun accept(visitor: Visitor): Any // 抽象方法，接受访问者

}



data class Number(val value: Int) : Expression { // 数据类

    override fun accept(visitor: Visitor): Any {

        return visitor.visitNumber(this) // 调用访问者的方法

    }

}



data class Sum(val left: Expression, val right: Expression) : Expression { // 数据类

    override fun accept(visitor: Visitor): Any {

        return visitor.visitSum(this) // 调用访问者的方法

    }

}



data class Product(val left: Expression, val right: Expression) : Expression { // 数据类

    override fun accept(visitor: Visitor): Any {

        return visitor.visitProduct(this) // 调用访问者的方法

    }

}

然后，我们可以定义一个访问者（Visitor）的接口，它可以为每种元素提供一个访问方法：

interface Visitor { // 访问者接口

    fun visitNumber(number: Number): Any // 访问数字表达式

    fun visitSum(sum: Sum): Any // 访问加法表达式

    fun visitProduct(product: Product): Any // 访问乘法表达式

}

最后，我们可以定义不同的访问者实现类，它们可以为元素提供不同的操作或功能。例如，我们可以定义一个求值（Evaluate）访问者，它可以计算表达式的值：

class Evaluate : Visitor { // 求值访问者

    override fun visitNumber(number: Number): Any {

        return number.value // 返回数字本身

    }



    override fun visitSum(sum: Sum): Any {

        return (sum.left.accept(this) as Int) + (sum.right.accept(this) as Int) // 返回左右子表达式之和

    }



    override fun visitProduct(product: Product): Any {

        return (product.left.accept(this) as Int) * (product.right.accept(this) as Int) // 返回左右子表达式之积

    }

}

我们还可以定义一个打印（Print）访问者，它可以打印表达式的字符串表示：

class Print : Visitor { // 打印访问者

    override fun visitNumber(number: Number): Any {

        return number.value.toString() // 返回数字的字符串

    }



    override fun visitSum(sum: Sum): Any {

        return "(${sum.left.accept(this)}) + (${sum.right.accept(this)})" // 返回加法的字符串

    }



    override fun visitProduct(product: Product): Any {

        return "(${product.left.accept(this)}) * (${product.right.accept(this)})" // 返回乘法的字符串

    }

}

使用密封接口实现访问者模式的优点是：

• 我们可以在编译时就知道有哪些可用的元素，避免出现无效或未知的元素。
• 我们可以使用数据类，对象，普通类或密封类作为子类型，根据不同的元素需要定义不同的属性和方法。
• 我们可以在不同的文件或模块中定义子类型，提高代码的模块化和可读性。
• 我们可以在不修改元素类的情况下，为它们添加新的访问者和操作。

如果使用java实现访问者模式，我们可能需要定义一个抽象类来表示元素，然后使用不同的子类来继承元素：

abstract class Expression { // 抽象类

    public abstract Object accept(Visitor visitor); // 抽象方法，接受访问者

}



class Number extends Expression { // 子类

    private int value; // 属性



    public Number(int value) { // 构造函数

        this.value = value;

    }



    public int getValue() { // 获取属性值方法

        return value;

    }



    @Override

    public Object accept(Visitor visitor) {

        return visitor.visitNumber(this); // 调用访问者的方法

    }

}



class Sum extends Expression { // 子类

    private Expression left; // 属性

    private Expression right; // 属性



    public Sum(Expression left, Expression right) { // 构造函数

        this.left = left;

        this.right = right;

    }



    public Expression getLeft() { // 获取属性值方法

        return left;

    }



    public Expression getRight() { // 获取属性值方法

        return right;

    }



    @Override

    public Object accept(Visitor visitor) {

        return visitor.visitSum(this); // 调用访问者的方法

    }

}



class Product extends Expression { // 子类

    private Expression left; // 属性

    private Expression right; // 属性



    public Product(Expression left, Expression right) { // 构造函数

        this.left = left;

        this.right = right;

    }



    public Expression getLeft() { // 获取属性值方法

        return left;

    }



    public Expression getRight() { // 获取属性值方法

        return right;

    }



    @Override

    public Object accept(Visitor visitor) {

        return visitor.visitProduct(this); // 调用访问者的方法

    }

}

可以使用 Java 8 中的 Map.replaceAll() 方法将所有的值转为 String 类型：

Map<String, Object> map = new HashMap<>();

// 添加一些键值对

map.put("key1", 123);

map.put("key2", true);

map.put("key3", new Date());



// 将所有的值转为 String 类型

map.replaceAll((k, v) -> String.valueOf(v));

上面的代码会将 map 中所有的值都转为 String 类型。

HashMap 是 Java 中使用最广泛的集合类之一，它是一种非常快速的键值对存储方式，可以用于存储和访问大量的数据。下面介绍一些 HashMap 的常用方法：

1. put(key, value) ：向 HashMap 中添加一个键值对。

HashMap<String, Integer> map = new HashMap<>();

   map.put("apple", 1);

   map.put("banana", 2);

2. get(key) ：根据键取出对应的值。

Integer value = map.get("apple");

3. containsKey(key) ：判断 HashMap 中是否包含指定键。

if (map.containsKey("apple")) {

       // ...

   }

4. containsValue(value) ：判断 HashMap 中是否包含指定值。

if (map.containsValue(1)) {

       // ...

   }

5. remove(key) ：根据键删除 HashMap 中的一个键值对。

map.remove("apple");

6. keySet() ：返回 HashMap 中所有键的集合。

Set<String> keys = map.keySet();

7. values() ：返回 HashMap 中所有值的集合。

Collection<Integer> values = map.values();

8. entrySet() ：返回 HashMap 中所有键值对的集合。

Set<Map.Entry<String, Integer>> entries = map.entrySet();

以上是常用的 HashMap 方法，还有其他一些方法可以查阅相关文档获得更多信息。

HashMap 的存储原理主要是基于 Hash 算法和数组实现的。 在 HashMap 中，每个键值对对应一个数组中的一个元素，这个元素叫做“桶(bucket)”或“槽(slot)”。

数组的索引值就是通过 Hash 算法计算出来的，每个桶中存放的是一个链表，存储了 key-value 对。如果不同的键值对计算出来的索引值相同，则这些键值对会被放到同一个桶中，以链表的形式存储在该桶中，这就是 HashMap 的解决冲突的方法。

HashMap 的存储过程如下：

1. 当使用 put 方法将一个键值对添加到 HashMap 中时，首先会根据键的 hashCode 值计算出数组索引位置。具体方法是，将 hashCode 值进行一些运算，得到一个数组索引值。这个索引值是键值对在数组中的位置。
2. 如果数组中该位置为空，那么就可以直接将键值对存储在该位置，完成添加操作。
3. 如果该位置已经有了键值对，那么就需要通过比较键的 equals 方法，来判断是更新该键值对的值，还是添加一个新的键值对。
4. 如果表示键值对的链表长度较长，就会影响到 HashMap 的性能，因为在查找时可能需要遍历整个链表。

为此，Java 8 引入了“红黑树”(Red-Black Tree) 的数据结构，可以将链表转换为树，以提高性能。 需要注意的是，HashMap 是非线程安全的，如果在多线程环境下使用，可能会发生一些异常情况。如果需要在多线程环境中使用 HashMap，可以使用 ConcurrentHashMap 或 Collections.synchronizedMap 方法来实现线程安全。

前言

在之前的文章【你的登录接口真的安全吗？】中，我们在用户登录安全方面做了很多设计，就是保护用户的账号安全，但是！！我相信做过用户体系的开发或产品都知道，用户的密码泄漏是一个不可避免的事件，总会有用户因为各种奇奇怪怪的原因而导致账号被盗，进而导致用户信息泄漏、虚拟数据丢失、经济损失等各种后果。那针对这种场景，我们可以通过什么手段来尽量预防呢？

几种实现方式来判断用户登录环境

一般这种情况，业界最简单的处理方式就是识别用户登录环境是是否正常：比如是否是常登录IP、或者是常登录设备等，如果不是，那么则进行限制、二次验证、用户告警等操作。

异地登录

首先是用户异地登录，一般场景下，用户的使用环境大部分时间都是不怎么变化的，比如公司、家里、宿舍或学校等。那么我们可以基于用户的使用IP，来做风险管理。

伪代码实现

   def login(username, password, ip):

      # 登录失败，简化其它流程

      if not do_login(username, password):

         return Result(100, '登录失败')



      # 检查用户登录环境异常

      if !check_login_env(username, ip):

         # 发送短信或邮件给用户，告知用户账号在非常用地登录

         send_notice(username, ip)

         # 前端收到这个状态码后跳转到二次验证页面

         return Result(101, '非常登录地登录')



      # 登录成功，异步记录当前ip

      async_log_ip(username, ip)

      return Result(0, '登录成功')

流程很简单，用户登录成功后，进行一次环境校验，判断用户当前登录ip是否为常登录地，如果不是，那么先给用户发送邮件或短信通知，然后返回对应状态码给前端，跳转到二次校验的页面。

二次校验可以通过APP扫码、手机验证码等方式登录。

*上面的代码中还缺少很重要的一步操作，怎么判断用户的IP是否是常登录IP？我们可以基于IP来实现，但是我们现在家用网络的IP基本上都不是固定IP，所以实际场景下可能更多的是使用地区来判断，比如城市。

伪代码实现

   def check_login_env(username, ip):

      cur_city = get_city_from_ip(ip)

      # 此城市是否在近半年的常登录城市中

      city = get_last_half_year_cities(username)

      return cur_city == city





   def log_env(username, ip):

      city = get_city_from_ip(ip)

      # 记录当前登录城市 

      insert_login_ip(username, city, ip, datetime.now())

      # 统计常登录城市

      # 查询的近半年登录次数最多的城市

      city = select_max_login_city_last_half_year()

      # 设置常登录城市

      set_last_half_year_cities(username, city)

上面只是简单的实现，整个判断过程比较粗糙，准确性也不够高。实际产生中，我们可以根据ip位置，结合算法来计算常登录地；或者结合下面的其它方式共同判断。

非常用设备登录

除了通过ip来判断用户使用环境外，我们一般还会结合用户设备来判断，特别是移动端应用，用户设备大部分时候是固定不变的。
设备信息一般可以使用设备指纹的方式，通过采集设备的各种信息，生成一个唯一标识，用于标识此设备。如果设备指纹不存在，那么证明用户在新设备上登录，则进行二次验证。

伪代码实现

   def login(username, password, ip, device_info):

      # 登录失败，简化其它流程

      if not do_login(username, password):

         return Result(100, '登录失败')



      # 检查用户登录环境异常

      if !check_login_env(username, ip):

         # 发送短信或邮件给用户，告知用户账号在非常用地登录

         send_notice(username, ip)

         # 前端收到这个状态码后跳转到二次验证页面

         return Result(101, '非常登录地登录')



      if !check_device_env(username, device_info):

         send_notice(username, device_info)

         # 前端收到这个状态码后跳转到二次验证页面

         return Result(102, '正在使用新设备登录')



      # 登录成功，异步记录当前ip

      async_log_ip(username, ip)

      # 记录设备信息

      async_log_device(username, device_info)

      return Result(0, '登录成功')

用户设备信息采集需要征得用户同意，那万一无法采集信息怎么办？ 我们也可以想办法在用户第一次登录时，在用户设备中生成记录一个唯一ID并存储在设备中，用于标记这个设备。

异常IP登录

这个和异地登录不同的是，我们可以维护一个IP黑名单，只要是用户登录的IP在黑名单内，则一定要求用户做二次验证。

黑名单的来源主要是通过购买、自行采集的方式获取到的黑产IP

用户风控

上面的各种方式，都不是孤立的，更多的是结合起来，包括其它更多的判断逻辑，来最终决定用户的登录环境是否存在风险，而这部分功能，我们一般会把它抽离出来，单独做为一个风控服务实现。 我们输入用户登录相关的数据，比如用户ID、登录IP、设备信息等，风控服务结合历史数据、用户行为数据等，通过大数据分析以及我们配置的风控规则，最终输出给我们一个风险级别，然后再根据风险级别决定是否需要做后续的措施。

总结

今天主要讲了几种预防用户账号被盗的手段以及简单的实现，相信大家在使用各种产品的时候也有碰到过对应的功能，我们在做用户体系设计的时候，前期可能用户量比较少，但是也可以尽量的考虑安全相关的设计，体量小有小的做法，大有大的做法，但是做了总比没做好。希望读完这篇文章大家有所收获~

在有预算的情况可以采购第三方服务防火墙，没钱就使用开源的WAF进行防护。

WAF防火墙的基本防护原理

WAF（Web 应用防火墙）可以使用多种技术来防止恶意爬虫攻击，例如：

1. 黑名单：WAF 可以使用黑名单技术来过滤恶意爬虫的请求。黑名单中包含一些已知的爬虫用户代理（User-Agent），WAF 可以检查每个请求的用户代理，并拒绝那些与黑名单匹配的请求。

2. 限制访问频率：WAF 可以使用限制访问频率的技术来防止恶意爬虫攻击。例如，可以设置每个 IP 地址在一定时间内只能访问网站的某个页面一定次数。如果超过了访问次数限制，则 WAF 会拒绝该 IP 地址的请求。

3. JavaScript 检测：WAF 可以使用 JavaScript 检测技术来检测爬虫。例如，可以在页面中嵌入一些 JavaScript 代码，这些代码会检测浏览器的一些属性（如是否支持 JavaScript、是否支持 Cookie 等），如果检测到浏览器属性与正常用户不同，则 WAF 可以认为该请求来自恶意爬虫，从而拒绝该请求。

4. 隐藏字段：WAF 可以在页面中添加一些隐藏的字段，这些字段只有正常用户才会填写，而恶意爬虫往往无法正确填写这些字段。例如，可以在登录表单中添加一个隐藏字段（如 CSRF Token），如果该字段的值不正确，则 WAF 可以认为该请求来自恶意爬虫，从而拒绝该请求。

5. 图片验证码：WAF 可以使用图片验证码技术来防止恶意爬虫攻击。例如，可以在某些敏感操作（如注册、登录、发表评论等）前，要求用户输入验证码。如果 WAF 发现多次输入错误验证码的请求，则可以认为该请求来自恶意爬虫，从而拒绝该请求。

使用注意事项

关于 WAF 的具体使用方法，常见的开源 WAF 包括 ModSecurity、Naxsi、WebKnight 等。这些 WAF 都可以通过配置文件来设置规则，过滤恶意请求。一般来说，使用 WAF 的步骤如下：

1. 安装 WAF：根据 WAF 的安装说明，安装 WAF 并将其集成到 Web 服务器中。

2. 配置规则：编辑 WAF 的配置文件，设置需要过滤的请求规则，例如黑名单、访问频率限制等。

3. 测试 WAF：启动 Web 服务器，并针对一些已知的恶意请求进行测试，验证 WAF 是否能够正确过滤这些请求。

4. 持续维护：WAF 的规则需要根据实际情况不断更新和维护，以保证其能够有效地防止恶意攻击。

开源WAF的优缺点

ModSecurity、Naxsi、WebKnight 都是常见的开源 WAF，它们各有优缺点。

1. ModSecurity

优点：

• 可以通过自定义规则来检测和防止各种攻击，包括 SQL 注入、XSS 攻击、命令注入、文件包含等。
• 支持正则表达式，可以灵活地匹配和过滤请求。
• 支持 HTTP/2 和 WebSocket 协议。
• 有一个活跃的社区，提供了丰富的文档和示例代码。
• 可以与 Apache、Nginx、IIS 等常见的 Web 服务器集成。

缺点：

• 学习曲线较陡峭，需要一定的安全知识和经验。
• 配置复杂，需要仔细调整规则以避免误报和漏报。
• 对于高并发的 Web 应用，可能会对性能产生一定的影响。

2. Naxsi

优点：

• 专门针对 Web 应用安全的防火墙，易于使用和配置。
• 通过学习模式（Learning Mode）和白名单模式（Whitelist Mode）来防止误报。
• 支持自定义规则，可以根据实际需求进行扩展。
• 对于高并发的 Web 应用，性能表现较好。

缺点：

• 仅支持 Nginx Web 服务器。
• 防护能力相对较弱，只能检测和防止一些常见的攻击，如 SQL 注入、XSS 攻击等。
• 社区活跃度不高，文档相对较少。

3. WebKnight

优点：

• 支持多种 Web 服务器，包括 IIS、Apache、Tomcat 等。
• 可以通过自定义规则来检测和防止各种攻击，包括 SQL 注入、XSS 攻击、命令注入等。
• 支持正则表达式，可以灵活地匹配和过滤请求。
• 有一个活跃的社区，提供了较为详细的文档和示例代码。

缺点：

• 学习曲线较陡峭，需要一定的安全知识和经验。
• 配置较为复杂，需要仔细调整规则以避免误报和漏报。
• 对于高并发的 Web 应用，可能会对性能产生一定的影响。

总的来说，选择哪种 WAF 主要取决于实际需求和应用场景。如果需要防范多种攻击，并且具备一定的安全知识和经验，可以选择 ModSecurity；如果需要一个易于使用和配置的 WAF，并且仅需要防范一些常见的攻击，可以选择 Naxsi；如果需要一个支持多种 Web 服务器的 WAF，并且对性能要求较高，可以选择 WebKnight。

需要注意的是，WAF 并不能完全防止恶意爬虫攻击，因为恶意攻击者可以使用各种技术来规避 WAF 的过滤。因此，在使用 WAF 的同时，还需要采取其他措施来增强网站的安全性，例如使用 SSL/TLS 加密技术、限制敏感操作的访问、使用验证码等。

阅读时长约10分钟，共计2268个字

如果要问自己这样一个问题：“我们工作的意义到底是什么？”会得到怎样的答案？

是为了安身立命？是为了满足别人的期待？是为了得到社会的认同？抑或是索性认为工作是无意义的？

如果我说：工作的意义在于自我实现，你会同意吗？你会觉得这样的观点很片面吗？你会觉得这很理想化吗？

其实，依我的工作经验来看，上面列举出的常见答案其实都有道理。人在不同的阶段，不同状态，工作的意义便会发生变化。

坦率地讲，我从开始工作之后，就下定决心不再啃老。简单地说，就是不再向父母伸手要钱。于是，如何保障自己的温饱就是我工作的最首要和最基本目的。也就是说，我刚开始的时候，工作就是为了挣钱。

刚起步的时候我一个月有多少工资呢？很少，2500块。即便是毕业后转正，拿到手也只有三四千块。

但是，这些钱已经可以很好地满足我的温饱需要。即使我出去租房，不在家吃饭，这些钱其实也是够的，只不过很可能剩不下分文。很感谢我的父母，在我事业刚刚开始的时候，照顾了我的起居生活。

一开始，我眼中工作的意义就是为了能养活我自己，就是为了那三两碎银。所以，为了养活自己而选择工作，挣钱，然后达到目的，我至今也不觉得有什么丢人的。

后来呢？因为我一直在家吃饭，午饭的话公司也有食堂，所以基本没什么开销。唯一生活上的花销就是衣服和鞋，可偏偏我穿衣穿鞋算是比较省的，一件衣服基本上少说穿个四五年，鞋的话就更久了，我现在还经常穿七八年前买回来的经典款。我认为穿衣方面，买经典款总是不会错，而且很难因为流行趋势而过时。

话说回来，随着我的小金库慢慢积累变多，我就不愁“安身立命”的目标了。因为我是家族后代中唯一的男性，所以心中总会有一种使命感，虽然没有人给我这方面的压力。我感受到的最大的责任感其实是想让家人生活得更美好的目标，虽然我父母在这方面依然没有表现出很大的期待。

于是凭着这个我自认为的“责任感”，一直努力工作了很多年。其实我的想法很简单，就是想让爱自己和自己爱的人过得好一点。我觉得凭本事挣更多的钱，然后达到这个目标，更是无可厚非的事情，也没什么错。

后来呢？我其实很早就有写博客的习惯，随着读者对我的文章产生认同，更重要的是有出版社编辑的认同，我就产生了要获得社会认同感的目标。虽说是“社会认同感”，其实它所包括的内容很广泛。比如读者的、家人的、老同学的、（前）同事的等等。这种“社会认同感”还会顺便带来他人的尊重甚至是敬重。至少我这次的工作和上次的工作，在面试的时候基本上技术方面是被认可的，免去了“八股文”的考验。不过老实讲，如果考验我面试“八股文”，大概率我还真得吃败仗。

再到现在，金钱对我的诱惑依然存在，但已经大幅降低了。更多的是考虑如何实现自己的价值，真正地释放自己的潜力，对这个社会，对这个世界发挥光和热。也就是我在一开始说的“工作的意义在于自我实现”。

好了，这就是我的故事。一开始为了满足温饱，我去工作，去挣钱；后来，为了得到别人的认可，获得社会认同感而努力工作，顺便把钱给挣了，引一句读者的评论：“挣钱是重要的事情中最不重要的”；再到现在，自我实现对我是最重要的。

所以，在不同阶段，不同状态，对工作意义产生不同的观点，我觉得都是正常的，也都是正确的。

但是，你知道吗？在我刚刚工作的时候，我就立下目标，要在这个世界上留下点什么，留下自己活过的印记，不想虚度此生。但当时无论如何也想不到，自己会成为作者，通过文字和图片把枯燥的编程知识教授给需要的人。

不知道你有没有听说过“马斯洛需求层次”，莫名其妙地，从一开始我就攀登这个需求金字塔，直到现在，已过去十余年。

有读者说我是“长期主义者”，以现在的认知，我愿意做一个“长期主义者”。但当初的我，哪懂什么“长期主义”。我更偏向于用“轴”、“固执”或是“不见棺材不落泪，不撞南墙不死心”这类的修饰词来形容自己。所幸的是，在我“固执”的一路上，受到了很多人的帮助与支持，还有上天的眷顾。“运气”、“机遇”占了很大的比重。

回到最初的问题：“我们工作的意义到底是什么”？如果我们对一个疲于奔命的人说：“你要实现自我”。很遗憾，“实现自我”在这个人眼中，也许就只是保障温饱，他甚至会转过头来和别人说我们是神经病。因为阶段不同，状态不同，追求的东西自然也会不同。也许这很无情，很冷血。但它很真实，也很正常。

但即便我们处在最开始的温饱阶段，着眼于生计，但目光一定要看到那个“未来”，坚定不移地坚持走“长期主义”的道路。

另一方面，在学校里，往往努力就会有结果，这是具有极大的确定性的。踏入社会之后，这种确定性消失了，我们往往努力了，却并没有得到想要的结果。很多人在鼓吹“选择大于努力”，选择固然重要。选错了，越努力，走得越偏。但这种话听多了，就要当心它是否成为了不努力的借口。努力是为了在机会到来的时候，我们有能力抓住他。这就好像不慎跌落坑里的人，有人扔绳子救他，他得努力抓住绳子，才有被救的可能。如果一味求救，却不选一种力所能及的方法去做，无论有多少次生还的机会，也会错过。

所以，任何时候也不要轻视努力与坚持的重要性。这看上去很笨很傻，但它却是每一个平凡人实现“自我价值”的可行之路。就像歌中唱的那样：“老天爱笨小孩”。在这个充满不确定性的时代，更应如此。不确定性就像基因突变，可能会变糟，也可能会变好。当有好事到来时，便是好运来临之际。和“选择大于努力”相比，我更倾向于相信“机会总是留给有准备的人”。这句话出自法国著名的微生物学家、化学家路易斯·巴斯德，告诫人们：机遇往往不易察觉，可遇不可求，容易稍纵即逝。作为普通人，若要抓住机遇，就要把功夫用在平时，甚至是有点傻的、偏执的努力。

背景

关于招聘，在最近一段时间有幸又参与到了面试工作。这次面试也包含一些相对高级一点的岗位，如何招到合适的人成为了最近一段时间一直在思考的一个点。

整体上感觉自己还是没有章法，没有清晰的思路（做不到因人而异），这种情况对自己对他人都是不负责任的。

因此，简单做一些总结思考，边面边想边改进吧。

招聘者的目标

首先，作为招聘者，都希望能找到一些厉害的人，成本不应该是他要考虑的问题。但现实总是相反。

面试官：这是我这次招聘的需求，要这个...... 那个...... 总之，能力越强越好。

公司：这次招聘成本范围已发给你了，注意查收。

面试官：......

所以，在成本有限的情况下，面试官要做的就是找到那些会发光的人。对面试官来说，招到一个即战力（不亏），招到一个高潜力（赚翻了）。

因此，招聘者的目标都是希望能够招到 能力 > 成本 的人。

梳理招聘需求

招聘的需求是需要面试官提前梳理好的，面试官作为团队的组建者，一定要提前规划好招聘需求。比如：

1. 我要找技术强的。（我不懂的他来）
2. 我要找态度好的。（我说啥都听）
3. 我要找有责任心的。（不用我说就把活干得很漂亮）
4. 我要找学习能力强的。（自我提升，啥需求都能接的住）
5. 最好还能带团队。（这样我就轻松了）
6. 最后一定要稳定。（这样我就一直轻松了）

哈哈，先开个玩笑。虽然我真的想......

现实就像上边提到的，招聘者希望的求职者模样。虽然知道不可能，但还是忍不住想要（我控制不住我几己呀！），所以在有限的面试时间内，问了很多方方面面的问题......

面试结束后：我问了那么多才答上来那么几个问题，不行，下一个......

面了几天后：人怎么这么难招呢？

所以真正的招聘需求应该是下边这样的：

1. 我要招一个领导者还是执行者：这个一定要想清楚，两者考察维度完全不一样。
2. 我要技术强的：想好哪方面技术强，不要妄图面面俱到。
3. 我要找有责任心的，学习能力强的，稳定的：想好怎么提问，如何判断。

如果能够做到上边的三点，相信招进来的人应该都是OK得。PS：先做到不亏。

领导者Or执行者

为什么把这个作为第一点，上边也提到过，两者考察维度完全不一样。一场面试，时间就那么点，所以要有针对性。

先说领导者

如果招聘领导者。试想一下领导者有哪些特点，什么样的人你愿意让他成为领导者。

1. 业务理解程度深，不仅限于产品规划的业务需求，还要有自己的理解和看法。
2. 技术能力强，通常一个技术方案便能提现出来，方案好不好，考虑全面不全面。
3. 抗压能力强，能够承担工作压力，这里不是指加班（当然加班也算），更多的是来自于技术，业务的困难和挑战。

以上三点并不代表全部，仅做参考。那么如何在面试中确认呢？

1. 业务理解程度主要通过追问细节的方式来确认。在你不了解的情况下，依然能够给你讲明白，这个业务是做什么的，关键核心点是什么，核心点有什么难度和挑战，最后是怎么解决的，解决的是否完美，不完美的原因。如果能够回答的不错那就基本合格了。最后可以再多问一下: 有没有哪些产品提出的需求，你认为不合理或者不适合当前产品现状的？这个问题只要回答的有一定高度，那就完美了。

   ps: 如果面试者认为没有什么难度和挑战，只能证明他自己没有深度参与或主导该业务。再简单的系统，也不可能一点问题都没有，如果真的没有，那么完全没有必要安排团队去专门负责。没有简单的系统，只有简单的思考。

   举个栗子，用户管理（用户CRUD）系统我们一听可能都觉得很简单，早期，用户注册要填一堆的东西，现在都是各种登录渠道，非常的方便。站在现在的角度，对于早期的用户管理来说，如何提升用户注册效率，增加用户量就是一个有难度有挑战的事情。

2. 技术能力，我简单分为有效技术能力和无效技术能力。无效技术能力代指无用且无聊的八股，当然也不是所有的八股都无用。有效技术能力我理解就是解决问题的能力，而解决问题不在于使用的技术手段与否高明，是否先进，只要贴合业务场景，我都会认为有技术能力。反而那些八股回答的头头是道，解决实际项目问题无一用到的会严重减分。

3. 抗压能力，项目经验是能反应出来一些信息的：有难度，有挑战的事情你不会交给一个不合适的人来做的，所以如果简历的项目经验中有类似的经验那么就证明别人已经帮你筛选过了。PS：别忘了鉴别一下。

再说执行者

还是试想一下，好的执行者有哪些特质：

1. 注重细节，考虑问题全面。
2. 责任心强，不会随便应付了事。
3. 技术OK，至少基础没有问题。

同样，上述三点仅做参考。

1. 注重细节，直接体现其实跟方案的完善程度有关，所以问问技术方案的异常情况是如何考虑的。另外，直接体现其实就是BUG比较少，当然这个一般人肯定不会说自己BUG多，所以可以问问，对于如何减少BUG量，有没有心得。（这个问题目前来看基本没啥用，哈哈）

2. 责任心强。责任心如何体现的我也说不太清楚，思考以后认为加班算一方面，有加薪、晋升算一方面，面试中很难直接体现，只能凭感觉。和第一条注重细节一样，我面试全凭聊完之后的直觉，这种大家都会有，而且一般来说准确率也不错。

   PS： 其实在面试沟通过程中，一问一答，很多事情靠直觉、面向也能猜个七七八八，玄学的东西这里不多说。说一点有科学依据的，人的性格简单分为外向、内向，两者都有其各自的特质，通常来说，内向者的特质更多时候适合于执行者。感兴趣的可以去了解一下两种性格特质，有益于团队管理。

3. 技术OK。这个不做多说了，一定要多问实际使用的，不用的就不要问了，可能用的适当问一下，实际使用的也可以拔高一下往深了问问。比如：mysql都在用，mysql的八股可以多问几个。JVM这种开发基本不用的，简单问一下得了（我一般是不问的）。

这一篇先到这里把，关于技术强、责任心其实也简单提了一下。关于这两点，后续结合实际情况再更新吧。

前言

一个运行了多年的ToB的项目，由于数据量越来越大，业务越来越复杂，也一直在迭代，今年的阶段性交付那几天，公司 最大的客户 现场那边人员提出，某某某单据页面速度太慢了，点击会出现没反应的情况，然后就多点了几次，结果后面发现有的数据重复提交了，由于数据错误个别单据流程给弄不正常了，一些报表的数据统计也不对了，客户相关人员很不满意，马上该交付了，出这问题可还了得，项目款不按时给了，这责任谁都担不起🤣

领导紧急组织相关技术人员开会分析原因

初步分析原因

发生这个情况前端选手应该会很清楚这是怎么回事，明显是项目里的按钮没加防抖导致的，按钮点击触发接口，接口响应慢，用户多点了几次，可能查询接口还没什么问题，如果业务复杂的地方，部分按钮的操作涉及到一些数据计算和后端多次交互更新数据的情况，就会出现错误。

看下项目情况

用到的框架和技术

项目使用 angular8 ts devextreme 组合。对！这就是之前文章提到的那个屎山项目（试用期改祖传屎山是一种怎么样的体验）

项目规模

业务单据页面大约几百个，项目里面的按钮几千个，项目里面的按钮由于场景复杂，分别用了如下几种写法：

• dx-button
• div
• dx-icon
• input type=button
• svg

由于面临交付，领导希望越快越好，最好一两天之内解决问题

还好我们领导没有说这问题当天就要解决 😁

解决方案

1. 添加防抖函数

按钮点击添加防抖函数，设置合理的时间

function debounce(func, wait) {

  let timeout;

  return function () {

    if(timeout) clearTimeout(timeout);

    timeout = setTimeout(func, wait)

  }

}

优点

封装一个公共函数，往每个按钮的点击事件里加就行了

缺点

这种情况有个问题就是在业务复杂的场景下，时间设置会比较棘手，如果时间设置短了，接口请求慢，用户多次点击还会出现问题，如果时间设置长了，体验变差了

2. 设置按钮禁用

设置按钮的 disabled 相关属性，按钮点击后设置禁用效果，业务代码执行结束后取消禁用

this.disabled = true

this.disabled = false

优点

原生按钮和使用的UI库的按钮设置简单

缺点

div, icon, svg 这种自定义的按钮的需要单独处理效果，比较麻烦

3. 请求拦截器中添加loading

在请求拦截器中根据请求类型显示 loading，请求结束后隐藏

优点

直接在一个地方设置就行了，不用去业务代码里一个个加

缺点

由于我们的技术栈使用的 angular8 内置的请求，无法实现类似 axios 拦截器那种效果，还有就是项目中的接口涉及多个部门的接口，不同部门的规范命名不一样，没有统一的标准，在实际的业务场景中，一个按钮的行为可能触发了多个请求，因此这个方案不适合当前的项目

4. 添加 loading 组件（项目中使用此方案）

新增一个 loading 组件，绑定到全局变量中，按钮点击触发显示 loading，业务执行结束后隐藏。

loading 组件核心代码

import { Injectable } from '@angular/core';

import { BehaviorSubject } from 'rxjs';

@Injectable({

  providedIn: 'root'

})

export class LoadingService {

  private isLoading$ = new BehaviorSubject<boolean>(false);

  private message$ = new BehaviorSubject<string>('正在加载中...');

  constructor() {}

  show(): void {

    this.isLoading$.next(true);

  }

  hide(): void {

    this.isLoading$.next(false);

  }

}

主要是 show() 和 hide() 函数，将 loading 组件绑定到 app.components.ts 中，绑定组件到window 对象上，

window['loading'] = this.loadingService

在按钮点击时触发 show() 函数，业务代码执行结束后触发 hide() 函数

window['loading'].show();

window['loading'].hide();

优点

这种方式很好的解决了问题，由于 loading 有遮罩层还避免了用户点击某提交按钮后，接口响应慢，这时候去点击了别的操作按钮的情况。

缺点

需要在业务单据的按钮提交的地方一个个加

问题来了，一两天解决所有问题了吗？

这么大的项目一两天不管哪种方案，把所有按钮都处理好是不现实的，经过分析讨论，最终选择了折中处理，先把客户提出来的几个业务单据页面，以及相关的业务单据页面添加上提交 loading 处理，然后再一边改 bug 一边完善剩余的地方，优先保证客户正常使用

这一篇文章我们继续分析另外一个重要的类RenderNode， 这个在前面绘制流程里有也有提到，这里我将更加深入的介绍这个类

1 简介

RenderNode是一个绘制节点，一个大的界面是由很多小的绘制单元组成，这个正如View的层级结构，整个界面由很多控件组成，这样带来的好处就是需要整体绘制界面的时候，只有那些变化的单元重新绘制，然后在重新组装界面即可。这让我联想到了活字印刷术，当我们要印刷一页内容的时候，如果将所有的字都刻在一块板上，当要修改的时候，就需要整体重新来刻，效率很低成本很高，但是如果是将每一个字作为一个组件，页面只是这些字拼接出来的，修改或者重用的话就相对容易很多，RenderNode就相当于是一个个的字。

尽管在应用层我们很少使用这个类，但是实际上的每个View都持有 一个RenderNode,我们可以这样去理解，View作为一个组件，会由很多业务，比如事件，布局，测量和绘制等，而绘制业务正是委托给RenderNode去完成，绘制需要Canvas也是由这个RenderNode提供的。RenderNode除了为View提供绘制能力外，还为其他可绘制的API提供绘制能力，最常见的就是Drawable，我们也可以封装自己的绘制组件，基于RenderNode的绘制是利用了硬件加速的绘制。

在应用层，View会形成树型的层级结构，因此RenderNode也会相应的构造一个出绘制节点的树形结构。但是RenderNode的树形结构和View的树形结构可能是不一样的，因为一个View可能会对应着几个RenderNode，比如View的背景也会转换成一个RenderNode，因此一个View节点可能会产生多个RenderNode对象，通常一个View的背景和View的的Children是平级的。

2 属性

2.1 Java层

RenderNode 的功能主要是在C层实现的。在java层，它持有一个mCurrentRecordingCanvas，表示当前正在使用的那个Canvas
frameworks/base/graphics/java/android/graphics/RenderNode.java

private RecordingCanvas mCurrentRecordingCanvas;

这个Canvas的类型是RecordingCanvas， 它由RenderNode的beginRecording方法创建的

public @NonNull RecordingCanvas beginRecording(int width, int height) {

        if (mCurrentRecordingCanvas != null) {

            throw new IllegalStateException(

                    "Recording currently in progress - missing #endRecording() call?");

        }

        mCurrentRecordingCanvas = RecordingCanvas.obtain(this, width, height);

        return mCurrentRecordingCanvas;

    }

这里可以看到beginRecording方法不能连续调用，需要在调用endRecording之后才能再次调用。这个canvas是通过RecordingCanvas获得的一个canvas，obtain方法往往代表是从缓存池中获取的，这里我们不深入介绍，我们知道这个Canvas 是再从这里获得的，它的类型是RecordingCanvas. 它是Canvas的子类。

RenderNode 也由很多其他的属性，但是在C层定义的，所以我们继续分析一下在C层的RenderNode

2.2 C层

在JNI 和C层这里，主要有这个几个文件
frameworks/base/libs/hwui/jni/android_graphics_RenderNode.cpp

frameworks/base/libs/hwui/RenderNode.h
frameworks/base/libs/hwui/RenderNode.cpp

以及专门用于存储属性的RenderProperties类

frameworks/base/libs/hwui/RenderProperties.h
frameworks/base/libs/hwui/RenderProperties.cpp

2.2.1 mStagingProperties

mStagingProperties记录的是修改过的属性，在没有提交前，所有的修改都临时存在mStagingProperties。

RenderProperties mStagingProperties;

对属性的修改，是通过一个宏定义来实现的，来分析一个简单属性的top的修改流程

frameworks/base/graphics/java/android/graphics/RenderNode.java

public boolean setTop(int top) {

        return nSetTop(mNativeRenderNode, top);

    }

frameworks/base/libs/hwui/jni/android_graphics_RenderNode.cpp

static jboolean android_view_RenderNode_setTop(CRITICAL_JNI_PARAMS_COMMA jlong renderNodePtr, int top) {

    return SET_AND_DIRTY(setTop, top, RenderNode::Y);

}

通过SET_AND_DIRTY这个宏定义来调用mutateStagingProperties上的方法

#define SET_AND_DIRTY(prop, val, dirtyFlag) \

    (reinterpret_cast<RenderNode*>(renderNodePtr)->mutateStagingProperties().prop(val) \

        ? (reinterpret_cast<RenderNode*>(renderNodePtr)->setPropertyFieldsDirty(dirtyFlag), true) \

        : false)

扩展开就相当于是

reinterpret_cast<RenderNode*>(renderNodePtr)->mutateStagingProperties().setTop(top) 

        ? (reinterpret_cast<RenderNode*>(renderNodePtr)->setPropertyFieldsDirty(dirtyFlag), true) 

        : false

renderNode->mutateStagingProperties() 返回的就是 mStagingProperties
frameworks/base/libs/hwui/RenderNode.h

RenderProperties& mutateStagingProperties() { return mStagingProperties; }

因此，会执行RenderProperties的setTop方法。如果setTop返回true，则会调用setPropertyFieldsDirty，记录发生变化的属性，这里传入的是RenderNode::Y这个枚举值，定义如下：

 enum DirtyPropertyMask {

        GENERIC = 1 << 1,

        TRANSLATION_X = 1 << 2,

        TRANSLATION_Y = 1 << 3,

        TRANSLATION_Z = 1 << 4,

        SCALE_X = 1 << 5,

        SCALE_Y = 1 << 6,

        ROTATION = 1 << 7,

        ROTATION_X = 1 << 8,

        ROTATION_Y = 1 << 9,

        X = 1 << 10,

        Y = 1 << 11,

        Z = 1 << 12,

        ALPHA = 1 << 13,

        DISPLAY_LIST = 1 << 14,

    };

frameworks/base/libs/hwui/RenderProperties.h

bool setTop(int top) {

        if (RP_SET(mPrimitiveFields.mTop, top)) {

            mPrimitiveFields.mHeight = mPrimitiveFields.mBottom - mPrimitiveFields.mTop;

            if (!mPrimitiveFields.mPivotExplicitlySet) {

                mPrimitiveFields.mMatrixOrPivotDirty = true;

            }

            return true;

        }

        return false;

    }

RP_SET是一个宏定义

#define RP_SET(a, b, ...) ((a) != (b) ? ((a) = (b), ##__VA_ARGS__, true) : false)

也就是如果mPrimitiveFields.mTop与top不相同，则将top赋值给mPrimitiveFields.mTop， 并且返回true，否则直接返回false。
如果top变化了，同步修改高度。
这就是一个简单属性的修改流程。 那么RenderNode有那些属性呢？来看一看RenderProperties的定义

 struct PrimitiveFields {

        int mLeft = 0, mTop = 0, mRight = 0, mBottom = 0;

        int mWidth = 0, mHeight = 0;

        int mClippingFlags = CLIP_TO_BOUNDS;

        SkColor mSpotShadowColor = SK_ColorBLACK;

        SkColor mAmbientShadowColor = SK_ColorBLACK;

        float mAlpha = 1;

        float mTranslationX = 0, mTranslationY = 0, mTranslationZ = 0;

        float mElevation = 0;

        float mRotation = 0, mRotationX = 0, mRotationY = 0;

        float mScaleX = 1, mScaleY = 1;

        float mPivotX = 0, mPivotY = 0;

        bool mHasOverlappingRendering = false;

        bool mPivotExplicitlySet = false;

        bool mMatrixOrPivotDirty = false;

        bool mProjectBackwards = false;

        bool mProjectionReceiver = false;

        bool mAllowForceDark = true;

        bool mClipMayBeComplex = false;

        Rect mClipBounds;

        Outline mOutline;

        RevealClip mRevealClip;

    } mPrimitiveFields;

我们可以看到这里的属性和我们在JAVA层View的几何属性是非常相似的，基本上View的几何属性都会类似setTop的方式反映到RenderProperties。大部分的简单属性比如top，bottom，translate，rotate，elevation，scale，pivot这些就不介绍了，我们分析一下两个比较特殊的属性mProjectBackwards 和 mProjectionReceiver。这两个属性会更改RenderNode绘制顺序。设置成mProjectionReceiver的RenderNode会成为一个锚点，被标记成mProjectBackwards的RenderNode不会被绘制在它的父节点，而是绘制到它最近的父节点中的标记成mProjectionReceiver的子节点中。例如P节点包含一个子节点C，以及P的背景PB，C包含一个背景CB. 一般的顺序应该是CB绘制到C中，然后C和PB绘制到P中。 但是如果PB被设置成mProjectionReceiver ，且CB被标记成mProjectBackwards，绘制的顺序将变成，C绘制到P中，CB绘制到PB 中，然后PB绘制到P中。也就是说将CB投影到PB中去。这种做法将使得CB的变化不会导致C重新绘制，从而提升效率，比如作为背景动画的RenderNode，它不会导致View自身的RenderNode的重新绘制。

2.2.1 mProperties

mStagingProperties暂存的修改将会与mProperties同步，从而正式成为影响绘制的参数。同步的方法很简单，直接赋值，在绘制帧之前会完成这些参数的同步。

void RenderNode::syncProperties() {

    mProperties = mStagingProperties;

}

个人感觉好像第一同步之后，mProperties就和mStagingProperties指向同一个对象，只有似乎以后没有同步的必要了。

3 总结

RenderNode主要保存了一系列的属性，大部分的View属性都会反映到RenderNode，RenderNode使用RenderProperties来保存这些属性，在绘制帧的时候，这些属性会影响最终的绘制。RenderNode也会形成一颗树形的层级结构，但是它与View的层级结构并不是一一对应的，在同一级中的RenderNode不仅包含View的兄弟节点的RenderNode，也包含父View的背景等可绘制内容。除了属性之外，RenderNode的另外一个重要属性是DisplayList，它存放的是这个RenderNode的绘制指令，这个将在下一篇中继续分析。

以上内容是对RenderNode的分析，基于个人的理解，如有疏漏和错误， 👀关注公众号：Android老皮！！！欢迎大家来找我探讨交流👀

前端跨域的几种方式

一、 什么是跨域

跨域（Cross-Origin）是指在浏览器你执行脚本时，通过XMLHttpRequest、Fetch等方式请求不同源（协议、域名、端口）的资源。同源策略是浏览器的一种安全机制，它限制了网页中的脚本只能与同源（相同协议、域名、端口）的资源进行交互，防止恶意网站获取用户的敏感信息或进行攻击。

在同源策略下。浏览器允许脚本访问同源的资源，但不允许访问不同域的资源。跨域请求会触发浏览器的安全机制，导致请求被拒绝。例如，如果网页在域名A下加载了一个脚本，而在这个脚本尝试访问域名B下的资源，浏览器阻止这个跨域请求。

对于前端开发来说，跨域请求是一个常见的问题，因为现代应用通常需要不同的服务器或域名上获取数据。为了实现跨域访问，开发者可以采用常用的一些常见的方式，如 JSONP、CORS、代理服务器或 WebSocket等。这些允许前端页面与其他源的服务器进行安全的通信。

二、 前端跨域的几种方式

1、JSONP

JSONP(JSON with Padding)是一种利用<script>标签跨域获取数据的方法，可以绕过浏览器的同源策略限制。

JSONP的原理如下：

• 通过请求参数作为回调函数的参数传递给服务器，服务器在响应中返回这个回调函数的调用，前端页面通过动态插入<script>标签来加载数据。
• 由于<script>标签不受同源策略的限制，因此可以跨域加载并执行返回的脚本。

以下是JSONP的使用示例：

<script>

    function callback(data) { 

        // 处理数据

    }

</script>



<script src="http://example.com/api?callback=callback"></script>

上面的示例中，我们定义了一个名为callback的函数，在之后的脚本中使用这个函数来处理返回的数据。通过将callback函数的名称作为请求参数传递给服务器（例如： example.com/api?callbac… ），服务器在返回的响应中将调用该函数并传递数据。前端页面通过动态插入<script>标签来加载这个跨域的脚本，并在脚本执行时用callback函数来处理数据。

JSONP的应用场景是在需要获取跨域数据时，由于同源策略的限制我们无法直接使用XMLHttpRequest 或 Fetch方法时。比如说：我们需要从另一个域名的API获取数据，而该API支持JSONP，我们可以使用JSONP来实现跨域获取数据并在前端页面中进行处理。

JSONP需要服务器直接返回可执行的脚本代码。此外，JSONP只支持GET请求，不支持POST请求等其他类型的脚本。

2、CORS

CORS（跨域资源共享）是一种通过在服务器配置响应头来实现跨域请求的机制。它允许在浏览器中进行安全的跨域通信，突破同源策略的限制。

CORS的原理如下：

• 前端页面发送跨域请求给服务器。
• 服务器在响应头中添加Access-Control-Allow-Origin字段，指定允许跨域的源。例如，可以将其设置为Access-Control-Allow-Origin: http://example.com。
• 浏览器收到带有这个响应头的请求后，会判断该请求是否在允许的跨域列表中，如果是则将响应返回给前端页面，否则会被浏览器拦截。
• 前端页面收到响应后，跨域像处理同源请求一样处理响应数据。

以下是CORS的使用示例：

//服务器端响应头配置

Access-Control-Allow-Origin: http://example.com

Access-Control-Allow-Methods: GET, POST

Access-Control-Allow-Headers: Content-Type





//前端页面请求

fetch('http://example.com/api',{

    method: 'GET',

    mode: 'cors'

})

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

    .then(data => {

        //处理数据

    });

在上面的示例中，服务器在响应头中添加了Access-Control-Allow-Origin字段，指定允许跨域请求源为http://example.com。前端页面在发送具有mode: 'cors'的跨域请求时，浏览器会允许请求通过，并将响应返回给前端页面，使得前端跨域像处理同源请求一样处理跨域请求的响应数据。

CORS的运用非常广泛，特别是在现代的Web应用中。通过使用CORS，前端跨域与其他域的服务器进行安全的跨域通信，实现数据的获取与交互。开发者跨域在服务器端配置CORS响应头，来实现不同应用之间的跨域请求，提供更好的用户体验以及功能拓展。

3、前端代理服务器

前端代理服务器作为中间层。通过其中转，跨域绕过浏览器的同源限制，实现跨域请求。这种方法的优点是简单、灵活、适用于各种场景。

前端代理服务器的原理如下：

• 前端代理服务器位于浏览器和后端服务器之间，充当转发请求和响应的角色。
• 当浏览器发起跨域请求时，请求会先发送到前端代理服务器。
• 前端代理服务器收到请求后，根据根据配置的规则判断是否属于跨域请求。
• 如果属于跨域请求，前端代理服务器将发送新的请求到后端服务器，获取数据。
• 前端代理服务器收到后端服务器的响应后，将响应内容返回给浏览器。

以下是如何使用Node.js创建一个前端代理服务器：

const http = require('http');

const request = require('request');



const proxy = http.createServer((req,res) => {

    //处理跨域请求

    res.setHeader('Access-Control-Allow-Origin','*');

    res.setHeader('Access-Control-Allow-Methods','GET,POST,PUT,DELETE');

    

    //转发请求到后端服务器

    const url = 'http://example.com' + req.url;

    req.pipe(request(url)).pipe(res);

});



const port = 8080;

proxy.listen(port, () => {

    console.log('Proxy server is running on port ${port}');

});

使用前端代理服务器的好处是可以方便地在开发环境中进行前后端分离，同时避免一些跨域请求带来地麻烦。但在生产环境中，建议采用更成熟地反向代理服务器，如Nginx来处理跨域请求。

4、WebSocket

前端WebSocket实现跨域的原理是基于浏览器的同源策略的限制，通过WebSocket协议进行通信。由于WebSocket是基于TCP协议的全双工通信协议，WebSocket对象不受同源策略的约束，因此跨域实现跨域通信。

WebSocket通信的实现原理：

• 在服务器端配置允许跨域请求：服务器端需要设置响应头，允许特定的域名访问该服务器资源。可以通过Access-Control-Allow-Origin进行跨域资源共享。
• 在前端使用WebSocket对象与服务器建立连接：在前端代码中，可以使用WebSocket对象建立与目标服务器的连接。使用WebSocket构造函数提供服务器的URL，例如：let socket = new WebSocket('ws://example.com/socket').
• 进行WebSocket通信：一旦与服务器建立了WebSocket连接，前端就可以通过WebSocket对象发送和接收数据。可以使用WebSocket对象的send()方法发送数据，使用onmessage时间监听接收到的信息，使用onopen事件监听连接建立成功，使用onclose事件建立连接关闭。

WebSocket是HTML5的新技术，不是所有的浏览器都支持。在使用WebSocket实现跨域通信时，需要检查浏览器的兼容性并提供备选方案，确保在不支持WebSocket的情况下仍能正常工作。

引言

在快速发展的互联网时代，前端开发一直处于高速增长的趋势中。作为构建用户界面和实现交互功能的关键角色，前端开发人员需要不断提升自己的技能和能力，以适应变化的行业需求。本文将为前端开发人员提供一个能力定位指南，帮助他们了解自己在前端领域的定位，内容参考阿里前端面试指南，P6/P6+/P7的能力标准。

目录

0.掌握图形学，webgl或熟练使用threejs框架，熟练canvas相关渲染及动画操作的优先。
1.熟练掌握JavaScript。
2.熟悉常用工程化工具，掌握模块化思想和技术实现方案。
3.熟练掌握React前端框架，了解技术底层。同时了解vue以及angular等其他框架者优先。
4.熟练掌握react生态常用工具，redux/react-router等。
5.熟悉各种Web前端技术，包括HTML/XML/CSS等，有基于Ajax的前端应用开发经验。
6.有良好的编码习惯，对前端技术有持续的热情，个性乐观开朗,逻辑性强，善于和各种背景的人合作。
7.具有TS/移动设备上前端开发/NodeJS/服务端开发等经验者优先。

0.掌握图形学，webgl或熟练使用threejs框架，熟练canvas相关渲染及动画操作的优先。

初级：

• 学习过图形学相关知识，知道矩阵等数学原理在动画中的作用，知道三维场景需要的最基础的构成，能用threejs搭3d场景，知道webgl和threejs的关系。
• 知道canvas是干嘛的，聊到旋转能说出canvas的api。
• 知道css动画，css动画属性知道关键字和用法(换句话说，电话面试会当场出题要求口喷css动画，至少能说对大概，而不是回答百度一下就会用)。
• 知道js动画，能说出1~2个社区js动画库，知道js动画和css动画优缺点以及适用场景。
• 知道raf和其他达到60fps的方法。

中级：

• 如果没有threejs，你也能基于webgl自己封装一个简单的threejs出来。
• 聊到原理能说出四元数，聊到鼠标操作能提到节流，聊到性能能提到restore，聊到帧说出raf和timeout的区别，以及各自在优化时候的作用。
• 知道怎样在移动端处理加载问题，渲染性能问题。
• 知道如何结合native能力优化性能。
• 知道如何排查性能问题。对chrome动画、3d、传感器调试十分了解。

高级：

• 搭建过整套资源加载优化方案，能说明白整体方案的各个细节，包括前端、客户端、服务端分别需要实现哪些功能点、依赖哪些基础能力，以及如何配合。
• 设计并实现过前端动画引擎，能说明白一个复杂互动项目的技术架构，知道需要哪些核心模块，以及这些模块间如何配合。
• 有自己实现的动画相关技术方案产出，这套技术方案必须是解决明确的业务或技术难点问题的。为了业务快速落地而封装一个库，不算这里的技术方案。如果有类似社区方案，必须能从原理上说明白和竞品的差异，各自优劣，以及技术选型的原因。

1.熟练掌握JavaScript。

初级：

• JavaScript各种概念都得了解，《JavaScript语言精粹》这本书的目录都得有概念，并且这些核心点都能脱口而出是什么。这里列举一些做参考：
• 知道组合寄生继承，知道class继承。
• 知道怎么创建类function + class。
• 知道闭包在实际场景中怎么用，常见的坑。
• 知道模块是什么，怎么用。
• 知道event loop是什么，能举例说明event loop怎么影响平时的编码。
• 掌握基础数据结构，比如堆、栈、树，并了解这些数据结构计算机基础中的作用。
• 知道ES6数组相关方法，比如forEach，map，reduce。

中级：

• 知道class继承与组合寄生继承的差别，并能举例说明。
• 知道event loop原理，知道宏微任务，并且能从个人理解层面说出为什么要区分。知道node和浏览器在实现loop时候的差别。
• 能将继承、作用域、闭包、模块这些概念融汇贯通，并且结合实际例子说明这几个概念怎样结合在一起。
• 能脱口而出2种以上设计模式的核心思想，并结合js语言特性举例或口喷基础实现。
• 掌握一些基础算法核心思想或简单算法问题，比如排序，大数相加。

2.熟悉常用工程化工具，掌握模块化思想和技术实现方案。

初级：

• 知道webpack，rollup以及他们适用的场景。
• 知道webpack v4和v3的区别。
• 脱口而出webpack基础配置。
• 知道webpack打包结果的代码结构和执行流程，知道index.js，runtime.js是干嘛的。
• 知道amd，cmd，commonjs，es module分别是什么。
• 知道所有模块化标准定义一个模块怎么写。给出2个文件，能口喷一段代码完成模块打包和执行的核心逻辑。

中级：

• 知道webpack打包链路，知道plugin生命周期，知道怎么写一个plugin和loader。
• 知道常见loader做了什么事情，能几句话说明白，比如babel-loader，vue-loader。
• 能结合性能优化聊webpack配置怎么做，能清楚说明白核心要点有哪些，并说明解决什么问题，需要哪些外部依赖，比如cdn，接入层等。
• 了解异步模块加载的实现原理，能口喷代码实现核心逻辑。

高级：

• 能设计出或具体说明白团队研发基础设施。具体包括但不限于：
• 项目脚手架搭建，及如何以工具形态共享。
• 团队eslint规范如何设计，及如何统一更新。
• 工具化打包发布流程，包括本地调试、云构建、线上发布体系、一键部署能力。同时，方案不仅限于前端工程部分，包含相关服务端基础设施，比如cdn服务搭建，接入层缓存方案设计，域名管控等。
• 客户端缓存及预加载方案。

3.熟练掌握React前端框架，了解技术底层。同时了解vue以及angular等其他框架者优先。

初级：

• 知道react常见优化方案，脱口而出常用生命周期，知道他们是干什么的。
• 知道react大致实现思路，能对比react和js控制原生dom的差异，能口喷一个简化版的react。
• 知道diff算法大致实现思路。
• 对state和props有自己的使用心得，结合受控组件、hoc等特性描述，需要说明各种方案的适用场景。
• 以上几点react替换为vue或angular同样适用。

中级：

• 能说明白为什么要实现fiber，以及可能带来的坑。
• 能说明白为什么要实现hook。
• 能说明白为什么要用immutable，以及用或者不用的考虑。
• 知道react不常用的特性，比如context，portal。
• 能用自己的理解说明白react like框架的本质，能说明白如何让这些框架共存。

高级：

• 能设计出框架无关的技术架构。包括但不限于：
• 说明如何解决可能存在的冲突问题，需要结合实际案例。
• 能说明架构分层逻辑、各层的核心模块，以及核心模块要解决的问题。能结合实际场景例举一些坑或者优雅的处理方案则更佳。

4.熟练掌握react生态常用工具，redux/react-router等。

初级：

• 知道react-router，redux，redux-thunk，react-redux，immutable，antd或同级别社区组件库。
• 知道vue和angular对应全家桶分别有哪些。
• 知道浏览器react相关插件有什么，怎么用。
• 知道react-router v3/v4的差异。
• 知道antd组件化设计思路。
• 知道thunk干嘛用的，怎么实现的。

中级：

• 看过全家桶源码，不要求每行都看，但是知道核心实现原理和底层依赖。能口喷几行关键代码把对应类库实现即达标。
• 能从数据驱动角度透彻的说明白redux，能够口喷原生js和redux结合要怎么做。
• 能结合redux，vuex，mobx等数据流谈谈自己对vue和react的异同。

高级：

• 有基于全家桶构建复杂应用的经验，比如最近很火的微前端和这些类库结合的时候要注意什么，会有什么坑，怎么解决

5.熟悉各种Web前端技术，包括HTML/XML/CSS等，有基于Ajax的前端应用开发经验。

初级：

• HTML方面包括但不限于：语义化标签，history api，storage，ajax2.0等。
• CSS方面包括但不限于：文档流，重绘重排，flex，BFC，IFC，before/after，动画，keyframe，画三角，优先级矩阵等。
• 知道axios或同级别网络请求库，知道axios的核心功能。
• 能口喷xhr用法，知道网络请求相关技术和技术底层，包括但不限于：content-type，不同type的作用；restful设计理念；cors处理方案，以及浏览器和服务端执行流程；口喷文件上传实现；
• 知道如何完成登陆模块，包括但不限于：登陆表单如何实现；cookie登录态维护方案；token base登录态方案；session概念；

中级：

• HTML方面能够结合各个浏览器api描述常用类库的实现。
• css方面能够结合各个概念，说明白网上那些hack方案或优化方案的原理。
• 能说明白接口请求的前后端整体架构和流程，包括：业务代码，浏览器原理，http协议，服务端接入层，rpc服务调用，负载均衡。
• 知道websocket用法，包括但不限于：鉴权，房间分配，心跳机制，重连方案等。
• 知道pc端与移动端登录态维护方案，知道token base登录态实现细节，知道服务端session控制实现，关键字：refresh token。
• 知道oauth2.0轻量与完整实现原理。
• 知道移动端api请求与socket如何通过native发送，知道如何与native进行数据交互，知道ios与安卓jsbridge实现原理。

高级：

• 知道移动端webview和基础能力，包括但不限于：iOS端uiwebview与wkwebview差异；webview资源加载优化方案；webview池管理方案；native路由等。
• 登陆抽象层，能够给出完整的前后端对用户体系的整体技术架构设计，满足多业务形态用户体系统一。考虑跨域名、多组织架构、跨端、用户态开放等场景。
• mock方案，能够设计出满足各种场景需要的mock数据方案，同时能说出对前后端分离的理解。考虑mock方案的通用性、场景覆盖度，以及代码或工程侵入程度。
• 埋点方案，能够说明白前端埋点方案技术底层实现，以及技术选型原理。能够设计出基于埋点的数据采集和分析方案，关键字包括：分桶策略，采样率，时序性，数据仓库，数据清洗等。

6.有良好的编码习惯，对前端技术有持续的热情，个性乐观开朗，逻辑性强，善于和各种背景的人合作。

初级：

• 知道eslint，以及如何与工程配合使用。
• 了解近3年前端较重要的更新事件。
• 面试过程中遇到答不出来的问题，能从逻辑分析上给出大致的思考路径。
• 知道几个热门的国内外前端技术网站，同时能例举几个面试过程中的核心点是从哪里看到的。

高级：

• 在团队内推行eslint，并给出工程化解决方案。
• 面试过程思路清晰，面试官给出关键字，能够快速反应出相关的技术要点，但是也要避免滔滔不绝，说一堆无关紧要的东西。举例来说，当时勾股老师面试我的时候，问了我一个左图右文的布局做法，我的回答是：我自己总结过7种方案，其中比较好用的是基于BFC的，float的以及flex的三种。之后把关键css口喷了一下，然后css就面完了。

7.具有TS/移动设备上前端开发/NodeJS/服务端开发等经验者优先。

• 根据了解的深度分初/中/高级。
• 知道TS是什么，为什么要用TS，有TS工程化实践经验。
• 知道移动端前端常见问题，包括但不限于：rem + 1px方案；预加载；jsbridge原理等。
• 能说出大概的服务端技术，包括但不限于：docker；k8s；rpc原理；中后台架构分层；缓存处理；分布式；响应式编程等。

5. 结论与进一步学习

本文为前端开发人员提供了一个能力定位指南，帮助他们了解自己在前端领域的定位，并提供了具体的代码示例来巩固学习成果。通过不断学习和实践，前端开发人员可以逐步提升自己的能力，从初级到中级再到高级。但请注意，在实际工作中，不同公司和项目对于各个级别的要求可能会有所不同。

为了进一步提高自己的水平，前端开发人员可以考虑以下学习路径和资源：

• 阅读官方文档和教程，如MDN、React官方文档等；
• 参与开源项目，并与其他开发人员进行交流和合作；
• 关注前端开发的博客和社区，如Medium、Stack Overflow等；
• 参加在线或线下的前端开发培训课程；
• 阅读经典的前端开发书籍，如《JavaScript高级程序设计》、《CSS权威指南》等。

通过持续学习和实践，相信每个前端开发人员都可以不断成长，并在前端领域中取得更好的成就。祝愿大家在前端开发的道路上越走越远！