算法是问题的解决步骤，同一个问题可以有多种解决思路，也就会有多种算法，但是算法之间是有好坏之分的，区分标志就是复杂度。

通过复杂度可以估算出耗时/内存占用等性能的好坏，所以我们用复杂度来评价算法。

（不了解复杂度可以看这篇：性能分析不一定得用 Profiler，复杂度分析也行）

开发的时候，大多数场景下我们用最朴素的思路，也就是复杂度比较高的算法也没啥问题，好像也用不到各种高大上的算法，算法这个东西似乎可学可不学。

其实不是的，那是因为你没有遇到一些数据量大的场景。

下面我给你举一个我之前公司的具体场景的例子：

体现算法威力的例子

这是我前公司高德真实的例子。

我们会做全源码的依赖分析，会有几万个模块，一个模块依赖另一个模块叫做正向依赖，一个模块被另一个模块依赖叫做反向依赖。我们会先分析一遍正向依赖，然后再分析一遍反向依赖。

分析反向依赖的时候，之前的思路是这样的，对于每一个依赖，都遍历一边所有的模块，找到依赖它的模块，这就是它的反向依赖。

这个思路是很朴素的，容易想到的思路，但是这个思路有没有问题呢？

这个算法的复杂度是 O(n^2)，如果 n 达到了十几万，那性能会很差的，从复杂度我们就可以估算出来。

事实上也确实是这样，后来我们跑一遍全源码依赖需要用 10 几个小时，甚至一晚上都跑不出来。

如果让你去优化，你会怎么优化性能呢？

有的同学可能会说，能不能拆成多进程/多个工作线程，把依赖分析的任务拆成几部分来做，这样能得到几倍的性能提升。

是，几倍的提升很大了。

但是如果说我们后来做了一个改动，性能直接提升了几万倍你信么？

我们的改动方式是这样的：

之前是在分析反向依赖的时候每一个依赖都要遍历一遍所有的正向依赖。但其实正向依赖反过来不就是反向依赖么？

所以我们直接改成了分析正向依赖的时候同时记录反向依赖。

这样根本就不需要单独分析反向依赖了，算法复杂度从 O（n^2）降到了 O(n)。

O(n^2) 到 O(n) 的变化在有几万个模块的时候，就相当于几万倍的性能提升。

这体现在时间上就是我们之前要跑一个晚上的代码，现在十几分钟就跑完了。这优化力度，你觉得光靠多线程/进程来跑能做到么？

这就是算法的威力，当你想到了一个复杂度更低的算法，那就意味着性能有了大幅的提升。

为什么我们整天说 diff 算法，因为它把 O(n^2) 的朴素算法复杂度降低到了 O(n)，这就意味着 dom 节点有几千个的时候，就会有几千倍的性能提升。

所以，感受到算法的威力了么？

总结

多线程、缓存等手段最多提升几倍的性能，而算法的优化是直接提升数量级的性能，当数据量大了以后，就是几千几万倍的性能提升。

那为什么我们平时觉得算法没用呢？那是因为你处理的数据量太小了，处理几百个数据，你用 O(n^2) O(n^3) 和 O(n) 的算法，都差不了多少。

你处理的场景数据量越大，那算法的重要性越高，因为好的算法和差的算法的差别不是几倍几十倍那么简单，可能是几万倍的差别。

所以，你会见到各大公司都在考算法，没用么？不是的，是太过重要了，直接决定着写出的代码的性能。

原文：https://juejin.cn/post/7023024399376711694

阅读本文📖

你将：

1. 明白通过JSON 来配置el-table的列可能并不是那么美。（作者主观意见）
2. 学会一点关于VNode操作的实例。（一点点）
3. 辩证地思考一下当我们在团队内对组件进行二次封装时，哪些东西是我们需要取舍的。

前言

大家好，我是春哥。
我热爱 vue.js , ElementUI , Element Plus 相关技术栈，我的目标是给大家分享最实用、最有用的知识点，希望大家都可以早早下班，并可以飞速完成工作，淡定摸鱼🐟。

相信使用 vue 的同学大部分都用过 Element 系列框架，并且绝大部分都用过其中的 el-table 组件。并且几乎所有人都会把表格和分页进行一层封装。

不过，很多人在封装时，总是习惯性地把 el-table 官方推荐的 "插槽写法" 改成 "JSON 数组" 写法。

就像这样：

<template>

  <my-el-table :columns="columns" :data="tableData">

  </my-el-table>

</template>

<script setup>

const columns = [

  {

    prop: 'date',

    label: 'Date',

    width: '180'

  },

  {

    prop: 'name',

    label: 'Name'

  }

]

// ...其他略

</script>

但经过我多年踩坑的惨痛经历，我必须要大声说出那句话：
快住手！有更好的封装技巧！

JSON 式封装哪些缺点？

缺点一：学习成本增高

以下两种场景，如果是你今天刚刚入职，你更愿意在业务代码里看到哪种组件呢？

我反正是更偏向于 1 和 4！
第 1 种意味着它有丰富的社区支持，有准确而清晰的文档和 demo 可以借鉴。
第 4 种意味着你依然可以靠官方文档横行，并且可以使用一些同事根据业务进行的"增强能力"。

那么 2 和 3 呢？
也许我的同事真的可以做出很好的封装，但如果你在小厂、在初创公司、甚至在外包公司，更大的可能是你的同事并不靠谱。
他的某些封装只是为了满足单一的业务场景, 但你为了了解他的功能，却不得不去面对全新的 api，甚至是通过看他的源码才能了解具体有什么 api 和能力。

在这种场景下，我选择面对熟悉的，官方的 api。 

缺点二：自定义内容需要写 h 函数

不会真的有人喜欢在业务里写 h 函数吧？

当简单的 JSON 配置无法满足产品经理那天马行空的想象力时，你可能需要对 el-table-column 里的内容进行更多的自定义。
此时，也许你就会怀念"插槽式"的便捷了。
假设你的产品经理要求你写一个 带色彩的状态列 。 

以上两种写法你会选择哪种呢？
而且，当业务变得更加复杂的时候，h 函数写法的可读性是指数式下跌的，你怕不怕？

当然，用JSX写法来简化 h 函数写法是个不错的思路。

JSON 式封装有哪些优点？

优点一：能简化写法？（并不）

有人说：“ JSON 式封装，能够简化代码写法。”
听到这样的话，我的内心其实是充满困惑的：它究竟能简化什么？

看出来了吗？
这种常见的所谓 封装，只不过是做了做简单形式化的转换：你并没有少写哪怕一个属性，只不过把它们从这里挪到了那里。

甚至于极端场景，你还需要多写代码：

// 从：

<el-table-column show-overflow-tooltip />

// 变成：

{

  'show-overflow-tooltip': true

}

优点二：只有 JSON 化才能实现动态列？（并不）

我在《我对 Element 的 Table 做了封装》 里讨论时， JackLiR8 同学提出了一个疑问： 
简化一下就是：

怎样封装才能在保持插槽写法的情况下，实现 动态列呢 ？

其实这个问题并不难，前提是需要你理解 vNode 是什么以及怎么操作它们。

我做了一个简单的例子，核心代码如下：

// vue3 函数式组件写法

const FunctionalTable = (props, context) => {

  // 获得插槽里的 vNodes

  const vNodes = context.slots.default()

  // 过滤 vNodes

  const filteredVNodes = props.visibleKeys == null ? vNodes : vNodes.filter(node => props.visibleKeys.includes(node?.props?.prop))

  // 把属性透传给el-table

  return <el-table {...context.attrs}>

    { filteredVNodes }

  </el-table>

}

// vue3 函数式组件定义 props

FunctionalTable.props = {

  visibleKeys: {

    type: Array,

    default: () => null

  } 

}

这就能实现 动态列 了？
是的。
下面正是使用时的代码：

<template>

  <el-button @click="onClick">给我变！</el-button>

  <FunctionalTable :data="tableData" :visibleKeys="visibleKeys">

    <el-table-column prop="date" label="Date" width="180" />

    <el-table-column prop="name" label="Name" />

    <el-table-column prop="address" label="Address" />       

  </FunctionalTable>

</template>

<script setup>

// 其他略

const visibleKeys = ref(['date', 'name'])

const onClick = () => {

  visibleKeys.value = ['date', 'name', 'address']

}

// 其他略

// ...

效果如下： 

毫无疑问，当遇到复杂场景，以及列里需要渲染各种奇形怪状的东西如 tag、popover 或者你需要进行更加复杂的定义的时候，插槽写法是更为优秀的。
这是上述demo的源代码 => github源码

优点三：JSON 配置能存数据库？（我劝你慎重）

"如果我把列的 JSON 配置存到数据库里，那我就不用写代码了！"

好家伙，我直呼好家伙！

除非你已经封装了非常成熟的可视化配置方案，否则！ 当业务上需要新增一列时，不还是你写？服务端和运维可不会帮你写代码。

只不过你存储代码的地点，从 git 变成了 数据库。

碰上懒一点的服务端，你还需要安装数据库链接软件，增加一项写 sql update 语句的活儿。

更让人感到害怕的是，你丢失了对代码版本跟踪的能力。

"为啥生产库/测试库/开发库存的数据不一样，到底应该用谁，我也不知道这字段是哪个版本、因为什么被谁合入的呀...."

那一刻，你可能会无比怀念 git commit-msg 那。

我期望的封装是什么样的？

如果你想设计一款基于"element UI"或"element Plus"，能解决一些迫在眉睫的问题，能优化一些写法，能规范一些格式，能让团队小伙伴们乐于使用到组件库。
我想，你可能得充分考虑以下内容：

• 它的API是否简单易学（甚至大部分就和 element 一模一样 ）？
• 它是否确确实实简化了业务上的写法？
  比如把 表格 和 分页器 合并，比如提供 请求方法 作为 prop 等都是能极大降低业务复杂性的封装。
• 它是否扩展性强，易维护？api 设计是否和项目保持风格上的一致？
  在同一个项目里，render/jsx/template 混用很可能会让一些新人感到吃力。
• 它是否是增强和渐进的？
  我可不希望当我试图使用 elementUI 某个特性时，我猛然发现我同事封装的组件居然不支持！

免喷声明

以上所有配图和文本都是我的个人观点。

如果你认为它们是错的，那它们就是错的吧。

关于我反对把 Element 表格列 JSON化 最初的初心，我确实厌倦了在不同团队不同公司总是要一遍又一遍去看前同事们蹩脚的封装，去理解他们做了哪些东西，拼写有没有改编，有没有丢失特性，去再学习一遍完全没有学习价值的API。

希望大家写代码时，都能获得良好的体验。

封装组件时，都能封装出"能用"，"好用"， "大家愿意用"的组件！

原文：https://juejin.cn/post/7043578962026430471

开发多语言版本的 APP，估计是大家希望的，尤其对于 iOS/Mac APP 的开发，上线 App Store 多希望在其它地区也能使用，所以今天主要想学习怎么基于 SwiftUI 做一些文本和字符串文字多语言化。

相信市面上不少这样的文章可供参考

Project 配置

首先，在 Project Info 选项中，选择 Localization 增加一个「中文」本地化配置，如果你需要其他语言，可以相对应的添加：

接下来，新建对应的 Group 文件夹，如本文的两个 Group：en.lproj、zh-Hans.lproj：

在这两个 Group 里，同时创建同名的 Strings 文件：Localizable：

代码编写

创建完成之后，我们分别创建一个 Preferences demo：

在我们的主 View 上引入变量 locale：

popOver.contentViewController?.view = NSHostingView(rootView: MainView().environment(\.locale, .init(identifier: "en")))

然后创建一个 Text：

Text("Preferences")

    .font(.customf(22))

    .padding(.bottom, 10.0)

刚开始我们定义的是 en，执行看看效果：

如果我们改为 zh-Hans：

MainView().environment(\.locale, .init(identifier: "zh-Hans"))

结果也就不一样了：

Locale 变化功能

基本功能实现了，接下来就是设置一个开关来变化 Locale 了。

首先，创建一个 Picker：

Section(header: Text("localization")) {

    Picker("", selection: $localeViewModel.localeString) {

        ForEach(LocaleStrings.allCases) { localeString in

            Text(localeString.rawValue)

                .tag(localeString.suggestedLocalication)

        }

    }

    .pickerStyle(SegmentedPickerStyle())

}

其中，我定义两个 enum 来做选择的类型：

enum Localication: String, CaseIterable, Identifiable {

    case zh_Hans = "zh-Hans"

    case en = "en"

    var id: String { self.rawValue }

}



enum LocaleStrings: String, CaseIterable, Identifiable {

    case zh_Hans = "中文"

    case en = "English"

    var id: String { self.rawValue }

}



extension LocaleStrings {

    var suggestedLocalication: Localication {

        switch self {

            case .zh_Hans: return .zh_Hans

            case .en: return .en

        }

    }

}

这个好理解，因为显示的 String 和提供给 locale 的字符串不一致，如显示的是「中文」，提供给 locale 的是 zh-Hans，这里我借助 suggestedLocalication 做桥梁转换。

最后，我们创建一个 Combine ViewModel 变量 localeString，以供实时变化改变本地化字符串内容。

class LocaleViewModel: ObservableObject {

    @Published var localeString: Localication

}

最后，只需要在具体的 View 里加入 ViewModel 订阅变量 localeString 的更新：

// ContentView.swift



import SwiftUI



struct ContentView: View {

    @ObservedObject private var timerViewModel: TimerViewModel

    @ObservedObject private var localeViewModel: LocaleViewModel

    init(timerViewModel: TimerViewModel, localeViewModel: LocaleViewModel) {

        self.timerViewModel = timerViewModel

        self.localeViewModel = localeViewModel

    }

    

    var body: some View {

        Text("localization")

            .font(.customf(14))

            .padding()

            .environment(\.locale, .init(identifier: localeViewModel.localeString.rawValue))

    }

}

好了，代码编写完毕，我们运行看效果：

小结

基本跑通本地化多语言适配流程，接下来就是不断增加新的语言和翻译工作。

未完待续

• 原文地址：The Ultimate Guide to the SwiftUI 2 Application Life Cycle
• 原文作者：Peter Friese
• 译文出自：掘金翻译计划
• 本文永久链接：github.com/xitu/gold-m…
• 译者：zhuzilin
• 校对者：PassionPenguin、zenblo

在很长一段时间里，iOS 开发者们都是使用 AppDelegate 作为应用的主要入口。随着 SwiftUI 2 在 WWDC 2020 上发布，苹果公司引入了一个新的应用生命周期。新的生命周期几乎（几乎）完全与 AppDelegate 无关，为类 DSL 方法铺平了道路。

在本文中，我会讨论引入新的生命周期的原因，以及你该如何在已有的应用或新的应用中使用它。

指定应用入口

我们的第一个问题是，该如何告诉编译器哪里是应用的入口呢？SE-0281 详述了**基于类型的程序入口（Type-Based Program Entry Points）**的工作方式：

Swift 编译器将识别标注了 @main 属性的类型为程序的入口。标有 @main 的类型有一个隐式要求：类型内部需要声明一个静态 main() 方法。

创建新的 SwiftUI 应用时，应用的主类（main class）如下所示：

import SwiftUI



@main

struct SwiftUIAppLifeCycleApp: App {

  var body: some Scene {

    WindowGroup {

      ContentView()

    }

  }

}

那么 SE-0281 提到的静态 main() 函数在哪儿呢？

实际上，框架可以（并且应该）为用户提供方便的默认实现。你会从上面的代码片段注意到 SwiftUIAppLifeCycleApp 遵循 App 协议。对于 App 协议，苹果提供了如下协议扩展：

@available(iOS 14.0, macOS 11.0, tvOS 14.0, watchOS 7.0, *)

extension App {



    /// 初始化并运行应用。

    ///

    /// 如果你在你的 ``SwiftUI/App`` 的实现类（conformer）的声明前加上了

    /// [@main](https://docs.swift.org/swift-book/ReferenceManual/Attributes.html#ID626)

    /// 属性，系统会调用这个实现类的 `main()` 方法来启动应用。

    /// SwiftUI 提供了该方法的默认实现，从而能以适合平台的方式处理应用启动流程。

    public static func main()

}

这下你就懂了吧 —— 这个协议扩展提供了处理应用启动的默认的实现。

由于 SwiftUI 框架不是开源的，所以我们看不到苹果是如何实现此功能的，但是 Swift Argument Parser 是开源的，并且也用了这个办法。查看 ParsableCommand 的源码，就能了解它是如何用协议扩展来提供静态 main 函数的默认实现，并将其用作程序入口的：

extension ParsableCommand {

...

  public static func main(_ arguments: [String]?) {

    do {

      var command = try parseAsRoot(arguments)

      try command.run()

    } catch {

      exit(withError: error)

    }

  }



  public static func main() {

    self.main(nil)

  }

}

如果上述这些听起来有点复杂，好消息是实际上在创建新的 SwiftUI 应用程序时你不必关心它：只需确保在 Life Cycle 下拉菜单中选择 SwiftUI App 来创建你的应用程序就行了：

让我们来看一些常见的情况。

初始化资源 / 你最喜欢的 SDK 或框架

大多数应用程序需要在启动时执行这些步骤：获取一些配置值，连接数据库或者初始化框架或第三方 SDK。

通常，您可以在 ApplicationDelegate 的 application(_:didFinishLaunchingWithOptions:) 方法中进行这些操作。由于已经没有应用委托了，我们需要找到其他方法来初始化我们的应用程序。根据您的特定需求，有以下策略：

• 为你的主类实现一个构造函数（initializer）（详见文档）
• 为存储属性设置初始值（详见文档）
• 用闭包设置属性的默认值（详见文档）

@main

struct ColorsApp: App {

  init() {

    print("Colors application is starting up. App initialiser.")

  }

  

  var body: some Scene {

    WindowGroup {

      ContentView()

    }

}

如果上述几种策略都无法满足你的需求，你可能还是需要一个 AppDelegate。后文会介绍如果能在应用中加入一个 AppDelegate。

处理你的应用的生命周期

了解你的应用程序处于哪种状态有时很有用。例如，你可能希望应用处于活动状态时立即获取新数据，或者在应用程序变为非活动状态并转换到后台后清除所有缓存。

通常，您可以在你的 ApplicationDelegate 上实现 applicationDidBecomeActive，applicationWillResignActive 或 applicationDidEnterBackground。

从 iOS 14.0 起，苹果提供了新的 API，该 API 允许以更优雅，更易维护的方式跟踪应用程序状态：[ScenePhase](https://developer.apple.com/documentation/swiftui/scenephase)。你的项目可以有多个场景（scene），不过有时只有一个场景。这些场景将由 [WindowGroup](https://developer.apple.com/documentation/swiftui/windowgroup) 展示。

SwiftUI 追踪环境中场景的状态，你可以使用 @Environment 属性包装器来获取 scenePhase 的值，然后使用 onChange(of:) modifier 来监听该值的变化：

@main

struct SwiftUIAppLifeCycleApp: App {

  @Environment(\.scenePhase) var scenePhase

  

  var body: some Scene {

    WindowGroup {

      ContentView()

    }

    .onChange(of: scenePhase) { newScenePhase in

      switch newScenePhase {

      case .active:

        print("App is active")

      case .inactive:

        print("App is inactive")

      case .background:

        print("App is in background")

      @unknown default:

        print("Oh - interesting: I received an unexpected new value.")

      }

    }

  }

}

值得注意的是，你可以从应用中的其他位置读取该值。当在应用的顶层读取该值时（如上面的代码片段所示），你将获得应用程序中所有阶段（phase）的汇总。.inactive 表示你应用中的所有场景均未激活。当在视图中读取 scenePhase 时，你将收到包含该视图的阶段值。请记住，你的应用程序在在同一时刻可能包含在不同阶段的多个场景。想了解有关场景阶段的更多详细信息，请阅读苹果的[文档]（developer.apple.com/documentati…

处理深层链接（Deeplink）

之前，在处理深层链接时，你需要实现 application(_:open:options:)，并将传入的 URL 转给最合适的处理程序。

新的应用生命周期模型可以更容易地处理深层链接。在最顶层的场景上添加 onOpenURL 就可以处理传入的 URL 了：

@main

struct SwiftUIAppLifeCycleApp: App {

  var body: some Scene {

    WindowGroup {

      ContentView()

        .onOpenURL { url in

          print("Received URL: \(url)")

        }

    }

  }

}

真正酷的是：你可以在整个应用程序中装上多个 URL 处理程序 —— 让进行深层链接变得很轻松，因为你可以在最合适的位置处理传入的链接。

可能的话，你应该使用 universal links（或者 Firebase Dynamic Links，它使用了 universal links for iOS apps），因为它们使用了关联域（associated domain）来创建网站和你的应用之间的链接 —— 这会让你可以安全地共享数据。

不过，你仍可以使用自定义 URL scheme 来链接应用内部的内容。

无论哪种方式，触发应用中的深层链接的一种简单方法是在开发计算机上使用以下命令：

xcrun simctl openurl booted <your url>

继续用户 activity

如果你的应用使用 NSUserActivity 来集成 Siri、Handoff 或 Spotlight，你需要处理用户继续进行的 activity。

同样，新的应用生命周期模型通过提供两个 modifier 使你更容易实现这一点。这些 modifier 使你可以声明 activity 并让用户可以继续进行它们。

下面是一个展现如何声明 activity 的代码片段。在一个具体的视图里：

struct ColorDetailsView: View {

  var color: String

  

  var body: some View {

    Image(color)

      // ...

      .userActivity("showColor") { activity in

        activity.title = color

        activity.isEligibleForSearch = true

        activity.isEligibleForPrediction = true

        // ...

      }

  }

}

为了允许继续进行这个 activity，你可以在最顶层的导航视图中注册 onContinueUserActivity 闭包，如下所示：

import SwiftUI



struct ContentView: View {

  var colors = ["Red", "Green", "Yellow", "Blue", "Pink", "Purple"]

  

  @State var selectedColor: String? = nil

  

  var body: some View {

    NavigationView {

      ScrollView {

        LazyVGrid(columns: columns) {

          ForEach(colors, id: \.self) { color in

            NavigationLink(destination: ColorDetailsView(color: color),

                           tag: color,

                           selection: $selectedColor) {

              Image(color)

            }

          }

        }

        .onContinueUserActivity("showColor") { userActivity in

          if let color = userActivity.userInfo?["colorName"] as? String {

            selectedColor = color

          }

        }

      }

    }

  }

}

请帮帮我 —— 上述的那些对我都不管用！

新的应用声明周期（截止当前）并非支持 AppDelegate 的所有回调函数。如果上述这些都不满足你的需求，你可能还是需要一个 AppDelegate。

另一个需要 AppDelegate 的原因是你使用的第三方 SDK 会使用 method swizzling 来把它们注入应用生命周期。Firebase 就是一个典型的例子。

为了帮助上述情况中的你摆脱困境，Swift 提供了一种将 AppDelegate 的一个实现类与你的 App 实现相连接的方法：@UIApplicationDelegateAdaptor。使用方法如下：

class AppDelegate: NSObject, UIApplicationDelegate {

  func application(_ application: UIApplication,

                   didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool {

    print("Colors application is starting up. ApplicationDelegate didFinishLaunchingWithOptions.")

    return true

  }

}



@main

struct ColorsApp: App {

  @UIApplicationDelegateAdaptor(AppDelegate.self) var delegate

  

  var body: some Scene {

    WindowGroup {

      ContentView()

    }

  }

}

如果你是在复制现有的 AppDelegate 实现，不要忘记删除 @main 属性 —— 不然，编译器该向你抱怨存在多个应用入口了。

总结

至此，让我们讨论一下苹果为什么要进行这些改变。我觉得有以下的几个原因：

SE-0281 explicitly states that one of the design goals was “to offer a more general purpose and lightweight mechanism for delegating a program’s entry point to a designated type.”

苹果选择的基于 DSL 来处理应用生命周期的方法和 SwiftUI 的声明式 UI 搭建方法相契合。两者采用相同的概念可以更方便新加入的开发者们理解。

声明式方法的主要好处是：框架/平台将替代开发者承受实现特定功能的负担。如果需要进行任何更改，这种模式可以在不破坏许多开发人员的应用的情况下进行发布，这也使发布更改变得更容易 —— 理想情况下，开发人员无需更改其实现，因为框架将把一切都搞定。

总体而言，新的应用生命周期模型使实现应用程序的启动更加简单。你的代码将变得更加简洁，更易于维护 —— 要我说，这总是一件好事。

我希望本文能帮你了解新的应用生命周期的来龙去脉。如果你有关于本文的任何疑问或评论，欢迎在 Twitter 上关注并私信我，或者在 GitHub 上的样例项目中提 issue。

感谢你的阅读！

扩展阅读

想了解更多，请查看下面的这些资料：

• Swift Evolution SE-0281 - @main: Type-Based Program Entry Points
• The App Protocol
• Allowing Apps and Websites to Link to Your Content

如果发现译文存在错误或其他需要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可获得相应奖励积分。文章开头的 本文永久链接 即为本文在 GitHub 上的 MarkDown 链接。

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。

在 Xcode 13.2 中，苹果完成了 async/await 的向前部署（Back-deploying）工作，将最低的系统要求降低到了 iOS 13（macOS Catalina），这一举动鼓舞了越来越多的人开始尝试使用 async/await 进行开发。当大家在接触了异步序列（AsyncSequence）后，会发现它同 Combine 的表现有些接近，尤其结合近两年 Combine 框架几乎没有什么变化，不少人都提出了疑问：苹果是否打算使用 AsyncSequence 和 AsyncStream 替代 Combine。

恰巧我在最近的开发中碰到了一个可能需要结合 Combine 和 async/await 的使用场景，通过本文来聊聊 Combine 和 async/await 它们之间各自的优势、是否可以合作以及如何合作等问题。

原文发表在我的博客 wwww.fatbobman.com

欢迎订阅我的公共号：【肘子的Swift记事本】

需要解决的问题

在最近的开发中，我碰到了这样一个需求：

• 在 app 的生命周期中，会不定期的产生一系列事件，事件的发生频率不定、产生的途径不定
• 对每个事件的处理都需要消耗不小的系统资源，且需要调用系统提供的 async/await 版本的 API
• app 对事件的处理结果时效性要求不高
• 需要限制事件处理的系统消耗，避免同时处理多个事件
• 不考虑使用 GCD 或 OperationQueue

对上述的需求稍加分析，很快就可以确立解决问题的方向：

• Combine 在观察和接收事件方面表现的非常出色，应该是解决需求第一点的不二人选
• 在解决方案中必然会使用到 async/await 的编程模式

需要解决的问题就只剩下两个：

• 如何将事件处理串行化（必须处理完一个事件后才能处理下一个事件）
• 如何将 Combine 和 async/await 结合使用

Combine 和 AsyncSequence 之间的比较

由于 Combine 同 AsyncSequence 之间存在不少相似之处，有不少开发者会认为 AsyncSequence 可能取代 Combine，例如：

• 两者都允许通过异步的方式处理未来的值
• 两者都允许开发者使用例如 map、flatMap 等函数对值进行操作
• 当发生错误时，两者都会结束数据流

但事实上，它们之间还是有相当的区别。

事件的观察与接收

Combine 是为响应式编程而生的工具，从名称上就可以看出，它非常擅长将不同的事件流进行变形和合并，生成新的事件流。Combine 关注于对变化的响应。当一个属性发生变化，一个用户点击了按钮，或者通过 NotificationCenter 发送了一个通知，开发者都可以通过 Combine 提供了的内置工具做出及时处理。

通过 Combine 提供的 Subject（PassthroughSubject、CurrentValueSubject），开发者可以非常方便的向数据流中注入值，当你的代码是以命令式风格编写的时候，Subject 就尤为显得有价值。

在 async/await 中，通过 AsyncSequence，我们可以观察并接收网络流、文件、Notification 等方面的数据，但相较于 Combine，仍缺乏数据绑定以及类似 Subject 的数据注入能力。

在对事件的观察与接收方面，Combine 占有较大优势。

关于数据处理、变形的能力

仅从用于数据处理、变形的方法数量上来看，AsyncSequence 相较 Combine 还是有不小的差距。但 AsyncSequence 也提供了一些 Combine 尚未提供，且非常实用的方法和变量，例如：characters、lines 等。

由于侧重点不同，即使随着时间的推移两者增加了更多的内置方法，在数据处理和变形方面也不会趋于一致，更大的可能性是不断地在各自擅长的领域进行扩展。

错误处理方式

在 Combine 中，明确地规定了错误值 Failure 的类型，在数据处理链条中，除了要求 Output 数据值类型一致外，还要求错误值的类型也要相互匹配。为了实现这一目标，Combine 提供了大量的用于处理错误类型的操作方法，例如：mapError、setFailureType、retry 等。

使用上述方法处理错误，可以获得编译器级别的保证优势，但在另一方面，对于一个逻辑复杂的数据处理链，上述的错误处理方式也将导致代码的可读性显著下降，对开发者在错误处理方面的掌握要求也比较高。

async/await 则采用了开发者最为熟悉的 throw-catch 方式来进行错误处理。基本没有学习难度，代码也更符合大多数人的阅读习惯。

两者在错误处理上功能没有太大区别，主要体现在处理风格不同。

生命周期的管理

在 Combine 中，从订阅开始，到取消订阅，开发者通过代码可以对数据链的生命周期做清晰的定义。当使用 AsyncSequence 时，异步序列生命周期的表述则没有那么的明确。

调度与组织

在 Combine 中，开发者不仅可以通过指定调度器（scheduler），显式地组织异步事件的行为和地点，而且 Combine 还提供了控制管道数量、调整处理频率等多维度的处理手段。

AsyncSequence 则缺乏对于数据流的处理地点、频率、并发数量等控制能力。

下文中，我们将尝试解决前文中提出的需求，每个解决方案均采用了 Combine + async/await 融合的方式。

方案一

在 Combine 中，可以使用两种手段来限制数据的并发处理能力，一种是通过设定 flatMap 的 maxPublishers，另一种则是通过自定义 Subscriber。本方案中，我们将采用 flatMap 的方式来将事件的处理串行化。

在 Combine 中调用异步 API，目前官方提供的方法是将上游数据包装成 Future Publisher，并通过 flatMap 进行切换。

在方案一中，通过将 flatMap、Deferred（确保只有在订阅后 Future 才执行）、Future 结合到一起，创建一个新的 Operator，以实现我们的需求。

public extension Publisher {

    func task<T>(maxPublishers: Subscribers.Demand = .unlimited,

                     _ transform: @escaping (Output) async -> T) -> Publishers.FlatMap<Deferred<Future<T, Never>>, Self> {

        flatMap(maxPublishers: maxPublishers) { value in

            Deferred {

                Future { promise in

                    Task {

                        let output = await transform(value)

                        promise(.success(output))

                    }

                }

            }

        }

    }

}



public extension Publisher where Self.Failure == Never {

    func emptySink() -> AnyCancellable {

        sink(receiveValue: { _ in })

    }

}

鉴于篇幅，完整的代码（支持 Error、SetFailureType）版本，请访问 Gist，本方案的代码参考了 Sundell 的 文章。

使用方法如下：

var cancellables = Set<AnyCancellable>()



func asyncPrint(value: String) async {

    print("hello \(value)")

    try? await Task.sleep(nanoseconds: 1000000000)

}



["abc","sdg","353"].publisher

    .task(maxPublishers:.max(1)){ value in

        await asyncPrint(value:value)

    }

    .emptySink()

    .store(in: &cancellables)

// Output

// hello abc

// 等待 1 秒

// hello sdg

// 等待 1 秒

// hello 353

假如将将上述代码中的["abc","sdg","353"].publisher更换成 PassthoughSubject 或 Notification ，会出现数据遗漏的情况。这个状况是因为我们限制了数据的并行处理数量，从而导致数据的消耗时间超过了数据的生成时间。需要在 Publisher 的后面添加 buffer，对数据进行缓冲。

let publisher = PassthroughSubject<String, Never>()

publisher

    .buffer(size: 10, prefetch: .keepFull, whenFull: .dropOldest) // 缓存数量和策略根据业务的具体情况确定

    .task(maxPublishers: .max(1)) { value in

        await asyncPrint(value:value)

    }

    .emptySink()

    .store(in: &cancellables)



publisher.send("fat")

publisher.send("bob")

publisher.send("man")

方案二

在方案二中，我们将采用的自定义 Subscriber 的方式来限制并行处理的数量，并尝试在 Subscriber 中调用 async/await 方法。

创建自定义 Subscriber：

extension Subscribers {

    public class OneByOneSink<Input, Failure: Error>: Subscriber, Cancellable {

        let receiveValue: (Input) -> Void

        let receiveCompletion: (Subscribers.Completion<Failure>) -> Void



        var subscription: Subscription?



        public init(receiveCompletion: @escaping (Subscribers.Completion<Failure>) -> Void,

             receiveValue: @escaping (Input) -> Void) {

            self.receiveCompletion = receiveCompletion

            self.receiveValue = receiveValue

        }



        public func receive(subscription: Subscription) {

            self.subscription = subscription

            subscription.request(.max(1)) // 订阅时申请数据量

        }



        public func receive(_ input: Input) -> Subscribers.Demand {

            receiveValue(input)

            return .max(1) // 数据处理结束后，再此申请的数据量

        }



        public func receive(completion: Subscribers.Completion<Failure>) {

            receiveCompletion(completion)

        }



        public func cancel() {

            subscription?.cancel()

            subscription = nil

        }

    }

}

在receive(subscription: Subscription)中，使用subscription.request(.max(1))设定了订阅者订阅时请求的数据量，在receive(_ input: Input)中，使用return .max(1)设定了每次执行完receiveValue方法后请求的数据量。通过上述方式，我们创建了一个每次申请一个值，逐个处理的订阅者。

但当我们在receiveValue方法中使用 Task 调用 async/await 代码时会发现，由于没有提供回调机制，订阅者将无视异步代码执行完成与否，调用后直接会申请下一个值，这与我们的需求不符。

在 Subscriber 中可以通过多种方式来实现回调机制，例如回调方法、Notification、@Published 等。下面的代码中我们使用 Notification 进行回调通知。

public extension Subscribers {

    class OneByOneSink<Input, Failure: Error>: Subscriber, Cancellable {

        let receiveValue: (Input) -> Void

        let receiveCompletion: (Subscribers.Completion<Failure>) -> Void



        var subscription: Subscription?

        var cancellable: AnyCancellable?



        public init(notificationName: Notification.Name,

                    receiveCompletion: @escaping (Subscribers.Completion<Failure>) -> Void,

                    receiveValue: @escaping (Input) -> Void) {

            self.receiveCompletion = receiveCompletion

            self.receiveValue = receiveValue

            cancellable = NotificationCenter.default.publisher(for: notificationName, object: nil)

                .sink(receiveValue: { [weak self] _ in self?.resume() })

                // 在收到回调通知后，继续向 Publisher 申请新值

        }



        public func receive(subscription: Subscription) {

            self.subscription = subscription

            subscription.request(.max(1))

        }



        public func receive(_ input: Input) -> Subscribers.Demand {

            receiveValue(input)

            return .none // 调用函数后不继续申请新值

        }



        public func receive(completion: Subscribers.Completion<Failure>) {

            receiveCompletion(completion)

        }



        public func cancel() {

            subscription?.cancel()

            subscription = nil

        }



        private func resume() {

            subscription?.request(.max(1))

        }

    }

}



public extension Publisher {

    func oneByOneSink(

        _ notificationName: Notification.Name,

        receiveCompletion: @escaping (Subscribers.Completion<Failure>) -> Void,

        receiveValue: @escaping (Output) -> Void

    ) -> Cancellable {

        let sink = Subscribers.OneByOneSink<Output, Failure>(

            notificationName: notificationName,

            receiveCompletion: receiveCompletion,

            receiveValue: receiveValue

        )

        self.subscribe(sink)

        return sink

    }

}



public extension Publisher where Failure == Never {

    func oneByOneSink(

        _ notificationName: Notification.Name,

        receiveValue: @escaping (Output) -> Void

    ) -> Cancellable where Failure == Never {

        let sink = Subscribers.OneByOneSink<Output, Failure>(

            notificationName: notificationName,

            receiveCompletion: { _ in },

            receiveValue: receiveValue

        )

        self.subscribe(sink)

        return sink

    }

}

调用：

let resumeNotification = Notification.Name("resume")



publisher

    .buffer(size: 10, prefetch: .keepFull, whenFull: .dropOldest)

    .oneByOneSink(

        resumeNotification,

        receiveValue: { value in

            Task {

                await asyncPrint(value: value)

                NotificationCenter.default.post(name: resumeNotification, object: nil)

            }

        }

    )

    .store(in: &cancellables)

由于需要回调才能完成整个处理逻辑，针对本文需求，方案一相较方案二明显更优雅。

方案二中，数据处理链是可暂停的，很适合用于需要触发某种条件才可继续执行的场景。

方案三

在前文中提到过，苹果已经为 Notification 提供了 AsyncSequence 的支持。如果我们只通过 NotificationCenter 来发送事件，下面的代码就直接可以满足我们的需求：

let n = Notification.Name("event")

Task {

    for await value in NotificationCenter.default.notifications(named: n, object: nil) {

        if let str = value.object as? String {

            await asyncPrint(value: str)

        }

    }

}



NotificationCenter.default.post(name: n, object: "event1")

NotificationCenter.default.post(name: n, object: "event2")

NotificationCenter.default.post(name: n, object: "event3")

简单的难以想象是吗？

遗憾的是，Combine 的 Subject 和其他的 Publishe 并没有直接遵循 AsyncSequence 协议。

但今年的 Combine 为 Publisher 增加了一个非常小但非常重要的功能——values。

values 的类型为 AsyncPublisher，其符合 AsyncSequence 协议。设计的目的就是将 Publisher 转换成 AsyncSequence。使用下面的代码便可以满足各种 Publisher 类型的需求：

let publisher = PassthroughSubject<String, Never>()

let p = publisher

        .buffer(size: 10, prefetch: .keepFull, whenFull: .dropOldest)

Task {

    for await value in p.values {

        await asyncPrint(value: value)

    }

}

因为 AsyncSequence 只能对数据逐个处理，因此我们无需再考虑数据的串行问题。

将 Publisher 转换成 AsyncSequence 的原理并不复杂，创建一个符合 AsyncSequence 的结构，将从 Publihser 中获取的数据通过 AsyncStream 转送出去，并将迭代器指向 AsyncStream 的迭代器即可。

我们可以用代码自己实现上面的 values 功能。下面我们创建了一个 sequence，功能表现同 values 类似。

public struct CombineAsyncPublsiher<P>: AsyncSequence, AsyncIteratorProtocol where P: Publisher, P.Failure == Never {

    public typealias Element = P.Output

    public typealias AsyncIterator = CombineAsyncPublsiher<P>



    public func makeAsyncIterator() -> Self {

        return self

    }



    private let stream: AsyncStream<P.Output>

    private var iterator: AsyncStream<P.Output>.Iterator

    private var cancellable: AnyCancellable?



    public init(_ upstream: P, bufferingPolicy limit: AsyncStream<Element>.Continuation.BufferingPolicy = .unbounded) {

        var subscription: AnyCancellable?

        stream = AsyncStream<P.Output>(P.Output.self, bufferingPolicy: limit) { continuation in

            subscription = upstream

                .sink(receiveValue: { value in

                    continuation.yield(value)

                })

        }

        cancellable = subscription

        iterator = stream.makeAsyncIterator()

    }



    public mutating func next() async -> P.Output? {

        await iterator.next()

    }

}



public extension Publisher where Self.Failure == Never {

    var sequence: CombineAsyncPublsiher<Self> {

        CombineAsyncPublsiher(self)

    }

}

完整代码，请参阅 Gist，本例的代码参考了 Marin Todorov 的 文章

sequence 在实现上和 values 还是有微小的不同的，如果感兴趣的朋友可以使用下面的代码，分析一下它们的不同点。

let p = publisher

    .print()  // 观察订阅器的请求情况。 values 的实现同方案二一样。

    // sequence 使用了 AsyncStream 的 buffer，因此无需再设定 buffer



for await value in p.sequence {

    await asyncPrint(value: value)

}

总结

在可以预见的未来，苹果一定会为 Combine 和 async/await 提供更多的预置融合手段。或许明后年，前两种方案就可以直接使用官方提供的 API 了。

希望本文能够对你有所帮助。

原文发表在我的博客 wwww.fatbobman.com

欢迎订阅我的公共号：【肘子的Swift记事本】

简介

Java的反射是指程序在运行期可以拿到一个对象的所有信息

使用

反射主要分为以下几个步骤

1. 获取Class对象

JVM在加载类的时候，会为每个类生成一个独一无二的Class对象

获取方式有以下几种 

//name = Test.class.getDeclaredField("name");

//name = test.getClass().getDeclaredField("name");

name = Class.forName("com.example.app.MainActivity$Test").getDeclaredField("name");

 

2. 操作fileds

Test test = new Test("xxx");

Field name;

try {

  //name = Test.class.getDeclaredField("name");

  //name = test.getClass().getDeclaredField("name");

  name = Class.forName("com.example.app.MainActivity$Test").getDeclaredField("name");

  name.setAccessible(true);

  Log.d("test", (String)name.get(test));

} catch (NoSuchFieldException | IllegalAccessException | ClassNotFoundException e) {

  e.printStackTrace();

}



class Test {

  private String name;



  public Test(String name) {

    this.name = name;

  }

  public String getName() {

    return name;

  }



  public void setName(String name) {

    this.name = name;

  }

}

 

• 
  

  getDeclaredField ：获取本类的任何field

  
  


• 
  

  getField：获取本类和基类的public field

  
  


• 
  

  获取基类非public值，只能通过基类class的getDeclaredField

  
  

3. 调用method

// 无参数的方法

Method getName = Class.forName("com.example.app.MainActivity$Test").getMethod("getName");

Log.d("test", (String)getName.invoke(test));



// 有参数的方法

Method setName = Class.forName("com.example.app.MainActivity$Test").getMethod("setName", String.class);

setName.invoke(test, "sdaasda");

Log.d("test", test.getName());

 

动态代理

在程序运行期动态创建某个interface的实例，通过动态代理可以实现一个方法/类的hook

比如hook点击事件

public class HookOnClickListenerHelper {

    public static View.OnClickListener hook(Context context, final View v) {//

        return (OnClickListener)Proxy.newProxyInstance(v.getClass().getClassLoader(),

            new Class[] {OnClickListener.class},

            new ProxyHandler(new ProxyOnClickListener()));

    }



    static class ProxyHandler implements InvocationHandler {



        private View.OnClickListener listener;



        public ProxyHandler(OnClickListener listener) {

            this.listener = listener;

        }



        @Override

        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

            return method.invoke(listener, args);

        }

    }



    static class ProxyOnClickListener implements View.OnClickListener {

        @Override

        public void onClick(View v) {

            Log.d("HookSetOnClickListener", "点击事件被hook到了");

        }

    }

}



findViewById(R.id.service).setOnClickListener(HookOnClickListenerHelper.hook(this, findViewById(R.id.service)))

 

实践

目标：动态代理应用版本号的返回

分析：

动态代理的实现相对来说是简单的，困难的部分在于通过读源码了解到功能是如何实现的，通过代理哪个类可以修改目标代码的返回

1. Android是如何获取应用版本号的？

通过getPackageManager()的getPackageInfo()

PackageManager pm = getPackageManager();

PackageInfo pi = pm.getPackageInfo(getPackageName(), 0);

versionName = pi.versionName;

versioncode = pi.versionCode;

 

1. getPackageManager()如何获取 ？

getPackageManager在Context中实现，Context是一个abstract Class，所有的实现都在 ContextImpl中，通过ContextImpl我们发现getPackageManager()是从 ActivityThread.getPackageManager()拿到的

// ContextImp.java

@Override

public PackageManager getPackageManager() {

    if (mPackageManager != null) {

        return mPackageManager;

    }



    final IPackageManager pm = ActivityThread.getPackageManager();

    if (pm != null) {

        // Doesn't matter if we make more than one instance.

        return (mPackageManager = new ApplicationPackageManager(this, pm));

    }



    return null;

}

 

1. ActivityThread如何获取？

ActivityThread内部有静态方法currentActivityThread()来获取

// ActivityThread.java

public static ActivityThread currentActivityThread() {

     return sCurrentActivityThread;

 }

 

1. ActivityThread中的packageManager怎么获取？

在ActivityThread中定义了sPackageManager，通过它我们就能拿到sPackageManager

 public static IPackageManager getPackageManager() {

     if (sPackageManager != null) {

         //Slog.v("PackageManager", "returning cur default = " + sPackageManager);

         return sPackageManager;

     }

     IBinder b = ServiceManager.getService("package");

     //Slog.v("PackageManager", "default service binder = " + b);

     sPackageManager = IPackageManager.Stub.asInterface(b);

     //Slog.v("PackageManager", "default service = " + sPackageManager);

     return sPackageManager;

 }

 

代理：

1. 
   

   获取ActivityThread

   
   

   // 获取ActivityThread
   activityThreadClz = Class.forName("android.app.ActivityThread");
   Method currentActivityThread = activityThreadClz.getDeclaredMethod("currentActivityThread");
   currentActivityThread.setAccessible(true);
   Object activityThread = currentActivityThread.invoke(null);

   
   


2. 
   

   获取packageManager

   
   

   // 获取packageManager
   Field packageManagerField = activityThreadClz.getDeclaredField("sPackageManager");
   packageManagerField.setAccessible(true);
   final Object packageManager = packageManagerField.get(activityThread);

   
   


3. 
   

   动态代理，处理getPackageInfo方法

   
   

   // 动态代理处理数据
   Class<?> packageManagerClazz = Class.forName("android.content.pm.IPackageManager", false, getClassLoader());
   Object proxy = Proxy.newProxyInstance(getClassLoader(), new Class[] {packageManagerClazz},
   new InvocationHandler() {
   @Override
   public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
   Object result = method.invoke(packageManager, args);
   if ("getPackageInfo".equals(method.getName())) {
   PackageInfo packageInfo = (PackageInfo)result;
   packageInfo.versionName = "sdsds";
   }
   return result;
   }
   });

   
   


4. 
   

   给packManger设置hook的对象

   
   

   //hook sPackageManager
   packageManagerField.set(activityThread, proxy);

   
   

测试:

//越早 hook 越好，推荐在 attachBaseContext 调用

PackageManager pm = getPackageManager();

try {

    PackageInfo pi = pm.getPackageInfo(getPackageName(), 0);

    Log.d(TAG, pi.versionName);

} catch (NameNotFoundException e) {

    e.printStackTrace();

}

 

“

这篇文章是我一次活动分享的讲稿

”

最近项目上机缘巧合用微前端解决了一些团队问题，借此机会跟大家分享一下。

微前端作为近两年兴起的一种解决方案，也不是什么新东西了，既然是解决方案，那么微前端帮我们解决了什么问题呢？这里我以我们项目组为例子讲讲：

我们为什么需要微前端？

我们的项目整体来看算得上一个比较大型的项目，整个项目规划完成后有 17 条业务线。但是在刚起项目的时候由于种种原因并没有考虑周全，将项目当成一个普通的前端项目来解决，在第一期项目结束，第一条业务上线后，我们紧接着开始了第二和第三条业务线的开发，紧接着我们就遇到了一些问题：

代码冲突

一期项目上线后交由维护团队维护，交付团队继续后面项目的开发。由于所有代码在同一个 repo 中作为一个大型单体被共同维护，两个团队的代码修改常常有冲突，需要小心 merge。同时还需要理解对方的业务，看自己的业务会不会破坏对方的业务。

部署冲突

由于所有的基础设施包括 CI/CD 等都是公用的，任何一个团队想要部署自己的代码，势必会对另外一个团队造成影响，不管是 feature toggle 还是 chunk base 的开发方式都将增大开发人员的心智负担。

技术栈冲突

由于项目比较大，未来团队的数量不确定，我们不能将技术栈限制死，否则就有可能有的团队要使用自己完全不熟练的技术栈，更别说未来还有第三方团队加入的可能性，我们不希望将整个项目绑定在某一个技术栈上。

基于这样的背景，我们发现微前端这套解决方案很好地解决了我们的问题。说白了在我们的项目背景下，我们最希望得到的东西是 -- 团队自治。

我们希望各个业务线的团队能够自由修改自己的代码，不用担心与别的团队产生冲突。她们可以自由选择自己熟悉的技术栈，不必有过多限制。同时任何团队的部署都不会影响其他团队，这也就意味着某一个团队负责的部分如果挂掉了，网站上其他团队维护的部分也是可用的。

最重要的，这样的架构可以让各个团队聚焦在自己的技术和业务上，减少各个团队不必要的无效沟通，提升各个团队的开发效率。

拆分时机

对于微前端的拆分来说，这是一项工作量较大的技术改进，而且它不同于别的技术改进，它没有模版，没有办法按部就班的从网上找个东西过来照抄，必须要结合自己的项目来进行。

另一方面，我们需要达成共识的是，在我们的日常开发中，大多数情况下项目上不可能给开发人员足够的时间来做技术改进，这就意味着大多数技术改进需要同业务开发一同进行。那么找准一个改进的时机就很重要了。

那么这样的时机通常是什么时候呢？

业务有较大的改变或演进

这种情况我想大多数同学都经历过，在开发最初说的好好的需求，由于种种原因需要做一次大的改变。面对这种大的需求变更，通常我们的代码也需要做对应的改变，而这种改变也需要重写一些代码，这个重写的过程就是一个很好的进行拆分的好时机。

在这个期间我们有足够的理由说服项目干系人给我们时间去重新组织项目代码去更好地支持业务的发展。

业务稳定不再有大的改进

此时业务的发展趋于稳定，但目前的架构如果也的确给开发造成了阻碍。那么就可以在这个稳定架构上进行改进。当然此时的业务还在发展，我们可以采取两种策略：

• 一种是以拆分任务为高优先级，新的业务开发基于新的架构
• 一种是先在旧的架构上持续开发，在拆分的过程中由负责拆分的同学将业务和技术一起迁移过去

拆分原则

我们在拆分微前端的时候一定是带有某种目的的，有可能是想对技术栈进行渐进式升级，也有可能像我们一样想提升各个独立团队的自治力，在不同的目的下我们可能会秉持不同的原则，这也是另一个为什么微前端的拆分没办法简单抄作业的原因。

就我们项目来说，我们追求各个团队的最高自治力，那么我们就希望各个独立app尽量减少彼此的通信和依赖，每个app能够尽量独立处理自己的业务。

在这样的大前提下，我们可以按照业务为主模块为辅的方式指导拆分，基于此，我们定义了一些拆分时候的原则：

• 保证业务独立，一条业务线应该由一个独立的app来支撑，使得该业务团队拥有这个app的完全控制权
• 跨业务的页面不应该各个业务各自持有，也应该拆分为一个独立的app
• 通用方法库和通用组件库由大家共同维护以支撑各自的业务

拆分前的准备

前置概念

single-spa

Single-spa 是一个微前端框架，它不限制每一个 app 具体使用怎样的技术栈，主要通过控制 route 的方式在页面上渲染不同的 app。

在开始微前端的拆分前我们进行了一些调研后选择了它作为我们微前端的框架，说是调研其实当时我们并没有过多的了解每一个框架，比如国内比较有名的 qiankun。

这里其实有一个小插曲，我们第一个了解的框架就是 single-spa，当时有一个小需求 single-spa 实现不了，于是我按照官网的文档去 slack 询问，第二天一大早我就收到了回复，算上时差他们一看到我的问题就给了我答复，这个反馈速度加上对国内开源社区的不乐观，我们直接就选择了 single-spa。

In-broswer module vs build time module

在开始实践前，我可能需要给大家介绍两个概念以帮助大家更好地理解接下来的架构设计，第一个概念是 in-broswer module，或者叫做es6 modules，与之对应的是现在用途最广的 build time module，这两个module有什么区别呢？我们先来看一个图：

module-build-result

这个图里两个 js 文件互相引用后最后打包的结果就是 build time module。在写代码的时候虽然你觉得这两个文件是分离的，但是其实在最终打包的时候这两个文件里的内容会被合并，最终变成一个 js 文件，然后这个 js 文件被 html 文件引用。

in-broswer module 则不同，这种模块是浏览器根据你提供的 url 从网络中请求回来的，你的每一个 import 都代表了一次网络请求，各个文件真的变成了独立的模块，通过网络请求相互依赖。

但是这样的模块有一个缺点，就是它没有办法像我们日常开发一样直接给一个名字就能直接引用到对应的模块：

import singleSpa from "single-spa";

由于需要在网络中定位到这个模块在哪里病发送对应的请求，它需要一个完整的url：

import singleSpa from "https://cdn.jsdelivr.net/npm/single-spa/esm/single-spa.min.js";

Import-map

这个特性使得大多数程序员都不喜欢它，毕竟大多数人都不想写一串长长的 url 来引用一个模块。为了解决这个问题，WICG 起草了一个新的浏览器规范，这个规范叫做 import map：

<script type="importmap">

 {

  "imports": {

   "single-spa": "https://cdn.jsdelivr.net/npm/single-spa/esm/single-spa.min.js"

  }

 }

</script>

import map 是一段特殊的 js，它的 type 为 importmap，在这个 script 标签里面的是一个 json object。这个 json object 的 key 就是某一个模块的名字，而它对应的 value 就是这个模块的 url 地址。

当然，既然 import-map 是一个 script 标签，那么理所应当它也可以加上 src 属性，成为一段外部 script：

<script type="importmap" src="https://some.url.to.your.importmap"></script>

在一些情况下，可能你的项目中引用了某一个包的不同版本，这时候可以用 import-map 的 scopes 功能来限制某一个文件的引用：

<script type="importmap">

 {

  "imports": {

   "lodash": "https://unpkg.com/lodash@3"

  },

  "scopes": {

   "/module-a/": {

    "lodash": "https://unpkg.com/lodash@4"

   }

  }

 }

</script>

这里的 scopes 代表了如果某一个 module 以 module-a 开头那么里面如果有引用 lodash 的 import，这个 import 将会引用 v4 版本，其他的 import 则都是引用的 v3 版本。

于是根据这个 import-map，我们就能够在代码里像使用正常模块那样使用 in-broswer module 了：

import singleSpa from "single-spa";

Systemjs

然后接下来就是前端传统节目，很显然，这么新的规范大部分浏览器目前都是不支持的，更别提永远也不可能支持的 IE 了，所以我们需要 polyfill - systemjs，它怎么工作的这里为了不扯远就不再赘述了，感兴趣的同学可以通过链接去 github 里面看文档，总的来说这是一个专门为了 es-module 而生的 polyfill。

我们从一个简单的 demo 来看它是怎么让 import-map 工作的：

es6-module-syntax

这是一个很简单的 demo，HTML 页面中留有一段 template，然后导入一份 es-module，这份 module 也很简单，只做了一件事就是导入 vue 然后把 template 里面的 name 换成我们想要的东西。

但是这里有一个细节，我们在导入 vue 的时候必须用一段 url 来导入，如果我们把这段 url 换成我们平时开发时的字符串会发生什么呢？

import-without-url

这里会发生这样的错误是因为我们在 script 标签上标记了这个 script 是一个 es-module，于是里面的 import 关键字是浏览器在运行时执行的，但是因为后面的字符串没办法告诉浏览器 Vue 这个资源到底在哪，浏览器当然也就找不到对应的资源，于是就报错了。

如果我们想要将 url 替换为我们平时开发时候的字符串，就得依赖于 import-map，但是大部分浏览器现在都还不支持这一特性，于是我们需要引入 systemjs：

how-to-use-systemjs

由于我们使用了 systemjs，为了按照它的规矩来行事，我们需要在原本的规范上修改一些代码：

• 首先是我们需要在开始引入 systemjs
• 然后将 import-map 的 type 从 importmap 改为 systemjs-importmap
• 接着把 es-module 的 type 从 module 改为 systemjs-module
• 最后是改动最大的地方，在 es-module 中我们不再使用 import 和 export 来导入导出模块，转而使用 systemjs 的语法，不过不用担心， webpack 和 rollup 等打包工具现在都支持将代码打包成 systemjs 风格，所以我们在写代码的时候还是可以按照正常规范来写

架构设计

到这里我们的前置概念就介绍完了，可以准备开始正式的拆分工作了，不过在拆分开始前，我们需要提前设计好我们的基础设施架构和代码组织方式。

基础设施架构

基于 single-spa 加上 import-map，我们最后计划好的基础设施架构大概长这个样子：

arch-of-micro-fe

1. 首先我们前端的所有静态资源都会分别部署在 AWS 的 S3 服务中，其中唯一的一份 HTML 文件存放在 root 容器的 S3 中。
2. 当用户访问我们的网站时，流量会从 client 端到达 root 容器的 AWS S3，这个时候用户的浏览器会先加载根路径下的 HTML 页面，而 HTML 页面的 head 标签中有一份 import-map 的 script。
3. 这时候 client 会再发送一次请求到我们的 import-map 所在的 S3 拿到 import-map。
4. 然后我们在 body 标签中用 systemjs 引入 root 容器，整个 APP 开始运转，之后根据不同的路径去不同的 S3 拿对应的静态文件

部署策略

为了能够达到各个团队独立自治的目的，部署是必不可缺的一环，我们的最终目的是不同的团队部署不会影响其他团队的业务。一个团队的线上代码出了问题，其他团队的业务仍可正常运行，对于一个 to B 的项目来说，这样的规划是有意义的。

delpoy-plan

基于这个目的，每一个团队自己维护自己的 app 的 CI/CD pipeline。需要特别注意的是，在每一次部署后需要更新 import-map 自己团队对应的 app 地址，这样还可以达到版本管理的目的。只要 S3 中一直存放着某一个版本的静态资源，仅仅更新 import-map 的对应地址即可达到快速部署和回滚的目的。

pipeline-stage

本地开发策略

在本地开发时有两种策略，一种是直接在本地启动一个 root 容器，然后将本地的 APP 注册到 root 容器中。

但是这样的开发方式需要解决依赖问题，比如 APP 依赖的通用方法库、通用组件库。解决这些依赖问题也有两个办法，一个是直接将对应的依赖打包，在本地进行配置，本地开发时直接引用打包好的依赖；第二个方式是将这些依赖作为一个共享 APP 直接在本地作为一个类似于 server 一样运行，然后通过 import-map 来共享，在开发时直接引用导出的方法和组件，而 single-spa 也提供了这样的方式，感兴趣的读者可以通过这个链接详细了解。

第二种方式则要简单许多，并且开发体验也会好很多。通常我们都有开发环境。我们可以直接在线上开发环境的 import-map 开一个口，利用 import-map-overrides 这个工具把线上的 import-map 对应的那个 APP 地址覆盖成本地地址。这时线上通过 import-map 去寻找这个 APP 的时候就会直接请求你的本地某个地址，然后线上运行的代码其实就已经是你本地的代码了，可以无缝与各种依赖开发。

你可能会觉得有安全问题，但其实这个工具可以做一些配置，比如只在本地和某一个域名下才打开这个口子，在别的地方都不开放这个后门。

实际拆分

problem

讲了这么多，终于开始上手了，但是这个世界上有一句名话叫做理想很丰满，现实很骨感。当你兴致勃勃准备好了一切计划，现实一般都不会让你如愿。我们这些看起来都还不错的计划有一部分被金主爸爸暂时搁置了，有一部分由于设计不妥开发体验不佳也被改造了。

太贵了

成本永远是和金主爸爸谈判绕不开的话题，我们新的架构设计在单体前端的基础上增加了许多东西：

• 多 repo（当然这个不算钱，也就没啥阻碍，但是最终也没有用多 repo 的方案，这个后面再聊
• 多 pipeline
• 多部署资源（每一个 APP 使用单独的 S3
• 多出来的 import map service

“

以前 10 块钱就能干完的活，你这么一搞我得出 100 块了吧，你这么玩我的钱包很难办啊

”

金主爸爸如是说。这种情况下我们就需要和金主爸爸谈判，为什么这些东西是必要的，为什么我们需要加这么多资源。但项目的问题在于，我们没时间谈判了，所以决定采取“架构降级”：

• 先暂时用一条 pipeline 来 build 我们的 app，在下一期项目有足够证据的时候切分 pipeline

  • 这一决定在后来验证是完全错误的，设想一下一个内存只有 1G 的 agent，需要 build 一个有 5 个 APP 的前端项目
  • 同时由于金主爸爸的钱包问题，我们项目只有一个 agent，请想象一下我们的日常开发hhhhh

• 先暂时将所有 app 部署到同一个地方，以文件夹分隔，如果一段时间后发现能满足需求，就先保持原状

• 每次 build 生成一份 import map，不单独维护 import map 资源，当团队相互影响时再寻求拆分时机

repo 拆分问题

我们一开始的设想是一个单独的 APP 拆分为一个单独的 repo，真正上手的时候仔细一想，有必要吗？

这让我回想起了一期项目时后端的微服务 repo，由于是一期项目，不同微服务之间的调用需要 setup，所以大多数时候本地都打开了三个以上的 Intellij，加上乱七八糟的其他应用，不得不说对 16G 内存的 Macbook 是一个考验。

回到前端这边，极有可能我们在日常的开发过程中会频繁抽取/更改公用代码库，也就意味着我们需要频繁提交更改，更新版本，然后才能使用，想想都不想做了。

再者，目前两个团队的体量其实还不必如此细致的拆分

有必要吗 - 繁琐的开发流程 - 多个本地 idea

公用代码难以维护 - 不同repo 不同更改 - ts类型引用问题

跨业务页面拆分问题

最初的设想是一条业务线是一个单独的 APP，一些跨业务的页面（也就是每一个业务都会有的页面，比如 User Account Management）也会被单独抽取一个 APP。

我们也真的这么做了，然后小伙伴们就戴上了痛苦面具：

• “BA 说这个页面是统一的，这个业务的改动，那个业务也要改。” “抽！”
• “BA 说这个新的页面要独立，所有新功能要在所有业务中生效。” “抽！”
• ......

“这个公共页面的逻辑跟那边的逻辑是一样的，我们是 copy 一份？” “......”

这样的策略导致我们的项目中存在大量 APP，而这些 APP 仔细一想好像没必要啊。增加 build 成本的同时也增加了我们自己的开发和维护成本，这拆的本末倒置了，于是我们做了一个改进 - 将所有公共页面塞进了一个 APP 中。

这个方案咋一听怪怪的，但是真的这么做了以后发现真香。所有的改动都会在所有的业务生效，不同的业务用不同的权限限制，大家维护同意份代码。等一下，你刚刚不是说不想大家维护同一份代码怕冲突吗？

这里的情况恰恰相反，所有的改动和需求都需要在所有地方生效，这样的方式我们就不用维护多份代码，而且也不会造成冲突 - 因为需求方的需求是单向的，如果有冲突，那就是需求冲突了，需要金主爸爸自己内部去掰头了。

可能有的小伙伴会说，怎么不试试后端拆分方式，使用 DDD 来指导拆分呢？巧了么不是，一开始我们就是按照后端 DDD 的方式来指导拆分的，然后就发生了这些问题，至少在我们的实践过程中，微服务的拆分方式不能照搬到前端来。

CSS 冲突问题

这是我们遇到的另一个比较严重的问题。我们在项目中使用了 Material UI，其中的 CSS 使用的是 CSS-in-JS 的方式，又因为有一套自己的 class name 生成规则，在没有控制好 scope 的情况下，多个 APP 的样式名冲突了，导致了严重的互相影响。

这虽然不是 single-spa 的问题，但是 single-spa 也提供了一些解决方案，包括 JS lib 和 CSS 的隔离问题，这些方案可以轻易地在官网或者 github issue 里面搜索到，这里就不过多解释了。解决的关键在于使用不同的 JS 或者 CSS 方案要做好相应的隔离。

写在最后

以上大概就是我们在拆分微前端过程中遇到的还记得住的事情了，从这次拆分中给我最大的益处其实不是技术上的提升，而是让我明白了做项目的两个关键点：

• 所有事情不会原封不动按照你的计划执行，越大的事情越是这样，及时考虑突发事件，灵活应变，不要拘泥于设计，基于现实改变计划才是可行之策。
• 架构的演进应该逐步推进，稳步前行，没有必要在一次架构演进中考虑好未来的所有情况，先不说你能不能考虑周全，谁又能说未来的情况不会发生改变呢，不要以现在的情况去揣度未来的情景，过好当下，灵活设计，提前预防未来可能发生的状况，准备好plan B即可。

工作学习生活中不免要经常用到 PowerShell ，但是那深蓝色的背景实在让人想吐槽几句。

今天我们就来美化一下它，几十种花里胡哨的主题任你选择~

准备

1. 首先我们要下载 Windows Terminal，打开微软商店搜索或者在Github搜索下载即可：

   

2. Win11后，WSL又迎来了质的飞跃，你甚至可以直接在文件管理中看到它：

   

3. 想修改 Windows Terminal 透明亚克力背景以及字体样式颜色也可以看我的上篇文章。

插一句，可以尝试一下新的 PowerShell 是跨平台的，挺好用

安装及修改

先贴出Oh My Posh官方文档：

1. 首先在命令行分别输入以下命令，中途询问输入Y确认即可：

   Install-Module oh-my-posh -Scope CurrentUser -SkipPublisherCheck
   
   Install-Module posh-git -Scope CurrentUser
   
   
   

2. 直接来修改配置文件：

   notepad $PROFILE
   
   
   

3. 会提示你新建一个文件，直接复制粘贴，然后保存退出重新启动即可。

   Import-Module posh-git
   
   Import-Module oh-my-posh
   
   Set-PoshPrompt -Theme agnosterplus
   
   
   

4. 你可以通过 Get-PoshThemes 来查看所有可用主题，再次修改配置文件中第三行内容即可：

   

一些提示

1. 你打开后可能会有些图标显示不出来，那是因为你的字体不支持，你可以下载Nerd Fonts ，或者下载官方推荐的Meslo LGM NF，使用字体需要修改Windows Terminal的设置文件，具体可以看我的上篇文章，我这里使用的是"MesloLGS NF"。

2. 选择主题也可以直接输入 Set-PoshPrompt -Theme 主题名。

3. 这个主题在VScode中也可以适配显示，在设置中搜索 Integrated:font，修改字体即可：

   

4. 显示出来是这样的：

   

5. 暂时想不出来更多了，有问题可以评论然后我再补充~