前言：搞懂 Android 系统和汽车到底有什么关系。

一、基本概念

1、Android Auto

1）是什么

• Android Atuo 是一个 Android 端的 app，专门为驾驶环境设计的；


• 运行环境：需要在 Android 5.0 或者更高版本的系统，并且需要 Google 地图和 Google Play 音乐应用；

2）功能

• Android Atuo 可以用来将 Android 设备上的部分功能映射到汽车屏幕上；


• 满足了很多人在开车时会使用手机的需求；

2、Google Assistant

• Google 将 GoofleAssistant 集成到 AndroidAuto 中；


• 交互方式有键盘、触摸、语音等；


• 对于汽车来说，语音无疑是比触摸更好的交互方式；


• 在驾驶环境中，语音交换存在的优势
  
  
  
  • 用户不改变自身的物理姿势，这种交互方式不影响驾驶员对驾驶的操作；
  
  
  • 有需要多次触摸的交互时，可能只需要一条语音就可以完成；
  
  
  • 语音交互不存在入口的层次嵌套，数据更加扁平；
  
  
  • 优秀的语音系统可以利用对话的上下文完成任务，避免用户重复输入；
  
  
  
  

3、Android Automotive

1、Android Auto 和 Android Automotive 的区别

• Android Auto 是以手机为中心的
  
  
  
  • 好处：数据和应用始终是一致的，不存在需要数据同步的问题，手机上装的软件和已有数据，接到汽车上就直接有了；
  
  
  • 坏处：每次都需要拿出手机，汽车只是作为手机的一个外设；这种模式不便于对于汽车本身的控制和相关数据的获取；
  
  
  
  


• Android Automotive
  
  
  
  • 如果将系统直接内置于汽车中，会大大提升用户体验；
  
  
  • Android Automotive 就是面向这个方向进行设计的；
  
  
  • 一旦将系统内置于汽车，可以完成的功能就会大大增加；例如，直接在中控触摸屏上调整座椅和空调；同时，系统也能获取更多关于汽车的信息，例如：油耗水平、刹车使用等；
  
  
  
  

加两张中控和仪表的图片

4、App

1）App 的开发

• Android Auto 目前仅支持两类第三方应用
  
  
  
  • 音频应用：允许用户浏览和播放汽车中的音乐和语音内容；
  
  
  • 消息应用：通过 text-to-speech 朗读消息并通过语音输入回复消息；
  
  
  
  

2）App 的设计

• Google 专门为 Android Auto 上的 UI 设计做了一个指导网站：Auto UI guidelines；


• 基本指导原则（车机交互系统的借鉴）
  
  
  
  • Android Auto 上的互动步调必须由驾驶员控制；
  
  
  • 汽车界面上的触摸目标必须足够大，以便可以轻松地浏览和点击；
  
  
  • 适当的私彩对比可以帮助驾驶员快速解读信息并做出决定；
  
  
  • 应用必须支持夜间模式，因为过高的强度可能会干扰注意力；
  
  
  • Roboto 字体在整个系统中用于保持一致性并帮助提高可读性；
  
  
  • 通过触摸来进行分页应用用来作为滑动翻页的补充；
  
  
  • 有节制地使用动画来描述两个状态间的变化；
  
  
  
  

二、源码和架构

1、Android Automative的整体架构

• Android Automative 的源码包含在 AOSP 中；


• Android Automative 是在原先 Android的 系统架构上增加了一些与车相关的（图中虚线框中绿色背景的）模块；
  
  
  
  • Car App：包括 OEM 和第三方开发的 App；
    
    
    
    • OEM：就是汽车厂商利用自身掌握的核心技术负责设计和开发新产品，而具体的生产制造任务则通过合同订购的方式委托给同类产品的其他厂家进行，最终产品会贴上汽车厂商自己的品牌商标。这种生产方式被称为定牌生产合作，俗称“贴牌”。承接这种加工任务的制造商就被称为OEM厂商，其生产的产品就是OEM产品；
    
    
    
    
  
  
  • Car API：提供给汽车 App 特有的接口；
  
  
  • Car Service：系统中与车相关的服务；
  
  
  • Vehicle Network Service：汽车的网络服务；
  
  
  • Vehicle HAL：汽车的硬件抽象层描述；
  
  
  
  

1）Car App

• /car_product/build/car.mk 这个文件中列出了汽车系统中专有的模块；


• 列表中，首字母大写的模块基本上都是汽车系统中专有的 App；


• App的源码都位于 /platform/packages/services/Car/ 目录下
  
  

  # Automotive specific packages
  
  PRODUCT_PACKAGES += \
  
      vehicle_monitor_service \
  
      CarService \
  
      CarTrustAgentService \
  
      CarDialerApp \
  
      CarRadioApp \
  
      OverviewApp \
  
      CarLensPickerApp \
  
      LocalMediaPlayer \
  
      CarMediaApp \
  
      CarMessengerApp \
  
      CarHvacApp \
  
      CarMapsPlaceholder \
  
      CarLatinIME \
  
      CarUsbHandler \
  
      android.car \
  
      libvehiclemonitor-native \
  
  

  
  

2）Car API

• 开发汽车专有的App自然需要专有的API；


• 这些API对于其他平台（例如手机和平板）通常是没有意义的；


• 所以这些API没有包含在Android Framework SDK中；


• 下图列出了所有的 Car API；

• android.car：包含了与车相关的基本API。例如：车辆后视镜，门，座位，窗口等。
  
  
  
  • cabin：座舱相关API。
  
  
  • hvac：通风空调相关API。（hvac是Heating, ventilation and air conditioning的缩写）
  
  
  • property：属性相关API。
  
  
  • radio：收音机相关API。
  
  
  • pm：应用包相关API。
  
  
  • render：渲染相关API。
  
  
  • menu：车辆应用菜单相关API。
  
  
  • annotation：包含了两个注解。
  
  
  • app
  
  
  • cluster：仪表盘相关API。
  
  
  • content
  
  
  • diagnostic：包含与汽车诊断相关的API。
  
  
  • hardware：车辆硬件相关API。
  
  
  • input：输入相关API。
  
  
  • media：多媒体相关API。
  
  
  • navigation：导航相关API。
  
  
  • settings：设置相关API。
  
  
  • vms：汽车监测相关API。
  
  
  
  

3）Car Service

• Car Service并非一个服务，而是一系列的服务。这些服务都在ICarImpl.java构造函数中列了出来；

public ICarImpl(Context serviceContext, IVehicle vehicle, SystemInterface systemInterface,

        CanBusErrorNotifier errorNotifier) {

    mContext = serviceContext;

    mHal = new VehicleHal(vehicle);

    mSystemActivityMonitoringService = new SystemActivityMonitoringService(serviceContext);

    mCarPowerManagementService = new CarPowerManagementService(

            mHal.getPowerHal(), systemInterface);

    mCarSensorService = new CarSensorService(serviceContext, mHal.getSensorHal());

    mCarPackageManagerService = new CarPackageManagerService(serviceContext, mCarSensorService,

            mSystemActivityMonitoringService);

    mCarInputService = new CarInputService(serviceContext, mHal.getInputHal());

    mCarProjectionService = new CarProjectionService(serviceContext, mCarInputService);

    mGarageModeService = new GarageModeService(mContext, mCarPowerManagementService);

    mCarInfoService = new CarInfoService(serviceContext, mHal.getInfoHal());

    mAppFocusService = new AppFocusService(serviceContext, mSystemActivityMonitoringService);

    mCarAudioService = new CarAudioService(serviceContext, mHal.getAudioHal(),

            mCarInputService, errorNotifier);

    mCarCabinService = new CarCabinService(serviceContext, mHal.getCabinHal());

    mCarHvacService = new CarHvacService(serviceContext, mHal.getHvacHal());

    mCarRadioService = new CarRadioService(serviceContext, mHal.getRadioHal());

    mCarNightService = new CarNightService(serviceContext, mCarSensorService);

    mInstrumentClusterService = new InstrumentClusterService(serviceContext,

            mAppFocusService, mCarInputService);

    mSystemStateControllerService = new SystemStateControllerService(serviceContext,

            mCarPowerManagementService, mCarAudioService, this);

    mCarVendorExtensionService = new CarVendorExtensionService(serviceContext,

            mHal.getVendorExtensionHal());

    mPerUserCarServiceHelper = new PerUserCarServiceHelper(serviceContext);

    mCarBluetoothService = new CarBluetoothService(serviceContext, mCarCabinService,

            mCarSensorService, mPerUserCarServiceHelper);

    if (FeatureConfiguration.ENABLE_VEHICLE_MAP_SERVICE) {

        mVmsSubscriberService = new VmsSubscriberService(serviceContext, mHal.getVmsHal());

        mVmsPublisherService = new VmsPublisherService(serviceContext, mHal.getVmsHal());

    }

    mCarDiagnosticService = new CarDiagnosticService(serviceContext, mHal.getDiagnosticHal());

4）Car Tool

a、VMS

• VMS全称是Vehicle Monitor Service。正如其名称所示，这个服务用来监测其他进程；


• 在运行时，这个服务是一个独立的进程，在init.car.rc中有关于它的配置

service vms /system/bin/vehicle_monitor_service

   class core

   user root

   group root

   critical



on boot

    start vms

• 这是一个Binder服务，并提供了C++和Java的Binder接口用来供其他模块使用；

前言

刚入门 Flutter 编程时，差点被 Flutter 的嵌套地狱吓走，不过当我看到 Flutter 支持 Windows 稳定后，于是下定决心尝试接受 Flutter，因为 Flutter 真的给的太多了：跨平台、静态编译、热加载界面。

Flutter 代码是写到文件夹中的，通过文件夹来管理代码，像是 c++ 语言那样，一个文件，即可以写类，也可以直接写方法😠。

不像 java 那样，全部都是类，整齐划一，通过包名来管理，但也支持类似的“导包”😆。

那么怎样才能像 Java 那样，有个框架优化代码，让项目看起来更整洁好维护呢？

我目前的答案是 MVC 🐷，合适自己的架构才是最好的架构，用这个架构，我感觉找到了家，大家先看看我的代码，然后再做评价。

使用部分

结合GetX, 使用方式如下：

import 'package:flutter/material.dart';

import 'package:get/get.dart';

import 'package:wenznote/commons/mvc/controller.dart';

import 'package:wenznote/commons/mvc/view.dart';



class CustomController extends MvcController {

  var count = 0.obs;



  void addCount() {

    count.value++;

  }

}



class CustomView extends MvcView<CustomController> {

  const CustomView({super.key, required super.controller});



  @override

  Widget build(BuildContext context) {

    return Center(

      child: Column(

        children: [

          Obx(() => Text("点击次数：${controller.count.value}")),

          TextButton(

            onPressed: () {

              controller.addCount();

            },

            child: Text("点我"),

          ),

        ],

      ),

    );

  }

}

简单粗暴，直接在 CustomView 中设计 UI, 在 CustomController 中编写业务逻辑代码，比如登录注册之类的操作。

至于 MVC 中的 Model 去哪里了？你猜猜😘。

代码封装部分

代码封装也很简洁，封装的 controller 代码如下

import 'package:flutter/material.dart';



class MvcController with ChangeNotifier {

  late BuildContext context;



  @mustCallSuper

  void onInitState(BuildContext context) {

    this.context = context;

  }



  @mustCallSuper

  void onDidUpdateWidget(BuildContext context, MvcController oldController) {

    this.context = context;

  }



  void onDispose() {}

}

封装的 view 代码如下

import 'package:flutter/material.dart';

import 'controller.dart';



typedef MvcBuilder<T> = Widget Function(T controller);



class MvcView<T extends MvcController> extends StatefulWidget {

  final T controller;

  final MvcBuilder<T>? builder;



  const MvcView({

    super.key,

    required this.controller,

    this.builder,

  });



  Widget build(BuildContext context) {

    return builder?.call(controller) ?? Container();

  }



  @override

  State<MvcView> createState() => _MvcViewState();

}



class _MvcViewState extends State<MvcView> with AutomaticKeepAliveClientMixin{

  @override

  bool get wantKeepAlive => true;



  @override

  void initState() {

    super.initState();

    widget.controller.onInitState(context);

    widget.controller.addListener(onChanged);

  }



  void onChanged() {

    if (context.mounted) {

      setState(() {});

    }

  }



  @override

  Widget build(BuildContext context) {

    super.build(context);

    widget.controller.context = context;

    return widget.build(context);

  }



  @override

  void didUpdateWidget(covariant MvcView<MvcController> oldWidget) {

    super.didUpdateWidget(oldWidget);

    widget.controller.onDidUpdateWidget(context, oldWidget.controller);

  }





  @override

  void dispose() {

    widget.controller.removeListener(onChanged);

    widget.controller.onDispose();

    super.dispose();

  }

}

结语

MVC 可以很简单快速的将业务代码和 UI 代码隔离开，改逻辑的时候就去找 Controller 就行，改 UI 的话就去找 View 就行，和后端开发一样的思路，完成作品就行。

附上的作品文件结构截图，亲喷哈~

感谢大家的关注与支持，后续继续更新更多 flutter 跨平台开发知识，例如：MVC 架构中的 Controller 应该在哪里创建？Controller 中的 Service 应该在哪里创建？

作品地址：github.com/lyming99/we…

哈喽，大家好 我是 xy👨🏻‍💻。今天和大家来聊一聊大屏可视化适配过程中的痛点以及怎么去解决这些痛点！！！

前言

开发过大屏可视化应用的前端工程师们通常会有这样的共识：

在可视化开发过程中，最具有挑战性的并非各种图表的配置与效果展示，而是如何确保大屏在不同尺寸的屏幕上都能实现良好的适配。

原始解决方案

起初比较流行的三大解决方式：

rem 方案

• 动态设置 HTML 根字体大小和 body 字体大小，配合百分比或者 vw/vh 实现容器宽高、字体大小、位移的动态调整

vw/vh 方案

• 将像素值（px）按比例换算为视口宽度（vw）和视口高度（vh），能够实时计算图表尺寸、字体大小等

scale 方案

• 根据宽高比例进行动态缩放，代码简洁，几行代码即可解决，但是遇到一些地图或者 Canvas 中的点击事件，可能会存在错位问题，需要做针对性的调整适配

以上三种方式，都能够实现大屏的基本适配！

但是在开发过程中需要对每个字体和容器去做相应的计算调整，相对来说较为繁琐，而且在团队协作过程中也容易出现问题。

那么有没有一种方式，只需要简单的一些配置，就能完全搞定大屏在不同尺寸的屏幕上都能实现良好的适配？

以下给大家推荐三个方案，只需要简单的几行代码配置，可以完全解决大屏开发中的适配问题，让你效率翻倍！！！

autofit.js

autofit.js 基于比例缩放原理，通过动态调整容器的宽度和高度来实现全屏填充，避免元素的挤压或拉伸。

autofit.js 提供了一种简单而有效的方法来实现网页的自适应设计，尤其适合需要在不同分辨率和屏幕尺寸下保持布局一致性的应用场景。

安装：

npm i autofit.js

配置：

import autofit from 'autofit.js';

onMounted(() => {

    autofit.init({

        el: '#page',

        dw: 375,

        dh: 667

    })

})

   * - 传入对象，对象中的属性如下：

   * - el（可选）：渲染的元素，默认是 "body"

   * - dw（可选）：设计稿的宽度，默认是 1920

   * - dh（可选）：设计稿的高度，默认是 1080

   * - resize（可选）：是否监听resize事件，默认是 true

   * - ignore(可选)：忽略缩放的元素（该元素将反向缩放），参数见readme.md

   * - transition（可选）：过渡时间，默认是 0

   * - delay（可选）：延迟，默认是 0

源码地址

Github 地址：https://github.com/995231030/autofit.js

v-scale-screen

大屏自适应容器组件，可用于大屏项目开发，实现屏幕自适应，可根据宽度自适应，高度自适应，和宽高等比例自适应，全屏自适应（会存在拉伸问题），如果是 React 开发者，可以使用 r-scale-screen。

安装：

npm install v-scale-screen

# or

yarn add v-scale-screen

配置：

<template>

  <v-scale-screen width="1920" height="1080">

    <div>

      <v-chart>....</v-chart>

      <v-chart>....</v-chart>

      <v-chart>....</v-chart>

      <v-chart>....</v-chart>

      <v-chart>....</v-chart>

    </div>

  </v-scale-screen>

</template>



<script>

import { defineComponent } from 'vue'

import VScaleScreen from 'v-scale-screen'



export default defineComponent({

  name: 'Test',

  components: {

    VScaleScreen

  }

})

</script>

源码地址

github 地址：https://github.com/Alfred-Skyblue/v-scale-screen

FitScreen

一种基于缩放的大屏自适应解决方案的基本方法，一切都是基于设计草图的像素尺寸，通过缩放进行适配，一切都变得如此简单。

支持 vue2、vue3 以及 react，可以适用于任何框架，只要一点点代码。

安装：

npm install @fit-screen/vue

# or

yarn add @fit-screen/vue

# or

pnpm install @fit-screen/vue

配置：

<script setup>

import FitScreen from '@fit-screen/vue'

</script>



<template>

  <FitScreen :width="1920" :height="1080" mode="fit">

    <div>

      <a href="https://vitejs.dev" target="_blank">

        <img src="/vite.svg" class="logo" alt="Vite logo">

      </a>

      <a href="https://vuejs.org/" target="_blank">

        <img src="./assets/vue.svg" class="logo vue" alt="Vue logo">

      </a>

    </div>

    <HelloWorld msg="Vite + Vue" />

  </FitScreen>

</template>

源码地址

github 地址：https://github.com/jp-liu/fit-screen

最后，如果大家有更好的适配方案，欢迎在评论区留言一起学习交流！👏

最后

如果觉得本文对你有帮助，希望能够给我点赞支持一下哦 💪 也可以关注wx公众号：前端开发爱好者 回复加群，一起学习前端技能 公众号内包含很多实战精选资源教程，欢迎关注

前言

跨端技术一直是移动端开发领域的热门话题，Flutter 作为一种领先的移动跨端技术之一，凭借其快速的渲染引擎、丰富的UI组件库和强大的开发工具，成为了开发人员的首选之一。

从 Flutter 诞生之初，我们就一直关注着它的发展，Flutter 早期版本变更较为频繁，并且经常伴随着 Breaking Change，另外可用的三方插件较少且不稳定。直到2019年，Flutter 的热度暴涨，国内不少团队陆续把 Flutter 引入到了生产环境使用，社区也涌现出不少优秀的开源项目，我们也决定在这个时候做一些技术上的尝试。

经过这几年在 Flutter 技术上的不断学习、探索和积累，Flutter 已经成为了客户端技术体系中的重要组成部分。

回顾整个过程，我们大致经历了这么几个阶段：可行性验证、基建一期建设、小范围试验、基建二期建设、大范围推广、前端生态的探索，下文将分别对每个阶段展开进行介绍。

可行性验证

其实在这之前我们已经做过了一些调研，但许多结论都是来源于网上的一些文章或者其它团队的实践，这些结论是否靠谱是否真实还有待商榷，另外，网上的文章大都千篇一律，要么使劲吹捧，要么使劲贬低，要得出相对客观的结论还是得需要我们自己通过实践才能得出。

目标

我们确定了以下几个维度，用来评估 Flutter 是否值得我们进一步投入：

• 开发效率


• UI一致性


• 性能体验


• 学习成本


• 发展趋势

由于前期对 Flutter 的熟练度不高，基础设施也还没有搭建起来，所以在开发效率上，我们期望的 Flutter 的开发耗时能保持在原生开发耗时的 1.5 倍以内，不然虽然实现了跨端，但是需求的开发周期反而被拉长了，这样得不偿失。在UI一致性上，我们期望同一份代码在两端的表现要基本达到一致，不需要额外的适配成本。在性能方面，尽量保证崩溃、卡顿、内存、帧率这些指标在可控范围内。

方案

我们希望用较小的代价完成上述维度的评估，所以在试验期间的架构及基础设施方面我们做的比较简单。

测试目标

当时我们正在做一个叫切克的 App，用户量级比较小，工程架构也相对简单一些，正好可以用来做一些技术方面的探索和验证。

我们选择的是切克的商品详情页，用 Flutter 技术实现了一个一模一样的商详，按1:1的流量分配给 Native 和 Flutter。

项目架构

由于我们的工程不是一个全新的项目，所以采用的是 Native 与 Flutter 混合开发的方式，Native 主工程只依赖 Flutter 产物即可，同时也尽量避免对原有工程的影响。

关于混合页面栈的问题，我们没有额外处理，因为暂时只测试一个页面，不会涉及到多页面混合栈的问题，所以暂时先忽略。

构建流程

为了降低验证成本，我们没有对接现有的 Native 的持续集成流程，而是直接在本地构建 Flutter 产物，然后上传到远程仓库。

结论

经过一段时间的线上验证，我对 Flutter 技术基本有了一个比较全面的了解：

在开发效率上由于基础库和基建的缺失，在处理 Flutter 业务跟 Native 业务的交互时需要更多的适配成本，包括像页面跳转、埋点上报、接口请求、图片加载等也需要额外的处理，但我们评估随着后续基建的不断完善，这部分的效率是可以逐步得到改善的；而在涉及UI开发方面，得益于热重载等技术，Flutter 的开发效率是要优于原生开发的。整体评估下来，在开发效率方面 Flutter 是符合我们的预期的。

在UI一致性上，除了在状态栏控制和文本在某些情况下需要特殊适配下外，其它控件在两端的表现基本一致。

在性能表现上，Flutter 会额外引入一些崩溃，内存占用也有所上涨，但还在可接受范围内。

Flutter 的学习成本相对还是比较高，毕竟需要单独学习一门语言，另外 Flutter 的渲染原理也跟原生有很多差异，需要转变思维才能更快的适应，此外 Flutter 还提供了众多的 Widget 组件，也需要较长时间学习。

在发展趋势上，Flutter 无疑是当时增长最快的跨端技术之一，社区的活跃程度以及官方的投入都非常高，国内不少团队也都在积极推进 Flutter 技术的发展，Flutter 正处在一个快速的上升期。

整体来说，Flutter 是满足我们团队对跨平台技术的需求的，我们计划在接下来的一段时间投入更多资源，把 Flutter 的基础设施逐渐建立起来。

基建一期建设

基建一期内容主要包括以下几个方面：

• 工程架构


• 开发框架


• 脚本工具


• 自动化构建

在基建一期完成后，我们的目标是要达到：

• 基础能力足够支撑普通业务开发


• 开发效率接近原生开发


• 开发过程要基本顺畅

工程架构

工程架构指的是原生工程与 Flutter 工程之间的关系，以及 Flutter 工程与 Flutter 工程之间的关系。

原生工程与Flutter工程的关系

我们知道，使用 Flutter 开发通常有两种情况，一种是直接使用 Flutter 开发一个新的App，属于纯 Flutter 开发；一种是在已有的 Native 工程中引入，属于混合开发。我们当然属于后者。

而混合开发又可分为两种：源码集成和产物集成。源码集成需要改变原工程的项目结构，并且需要 Flutter 开发环境才能编译，而产物集成则不需要改动原工程的项目结构，只需把 Flutter 的构建产物当作普通的依赖库引入即可，原有 Native 工程和 Flutter 工程从物理上完全独立。显而易见的我们选择产物集成的方式，引入 Flutter对于原工程以及非 Flutter 开发人员来说，基本上是毫无感知的。

所以原生工程与 Flutter 工程之间的关系如下图所示：

Flutter工程之间的关系

根据已有的客户端基建的开发经验，我们将所有 Flutter 工程分为了四层：

• 壳工程


• 业务层


• 公共层


• 容器层

容器层负责提供 Flutter 的基础运行环境，包括 Flutter 引擎管理、页面栈管理、网络框架、KV存储、数据库访问、埋点框架、Native 与 Flutter 通信通道和其它基础功能。

公共层包含一些通用的开源库、自定义UI组件、部分通用业务等。

业务层包含用户信息、商品、发布等业务组件。

壳工程负责集成各业务组件，最终构建出产物集成到 Native 主工程。

其中业务层、公共层、容器层都是由若干个独立的工程所组成，整体结构如下：

开发框架

开发框架是为了提高开发效率、规范代码结构、减少维护成本等考虑而设计的一套软件框架，包括：基础能力、状态管理、页面栈管理等。

基础能力

开发框架需要提供各种必要的能力，比如：页面跳转、埋点、网络请求、图片加载、数据存储等，为了最大化减少研发成本，我们在底层定义了一套通用的数据交互协议，直接复用了现有的 Native 的各项能力，也使得 Native 的各种状态与 Flutter 侧能够保持统一。

状态管理

相信了解 Flutter 的同学一定知道状态管理，这也是跟 Native 开发区别较大的地方。在开发较为复杂的页面时，状态维护是非常繁琐的，在不引入状态管理框架的情况下，开发效率会受很大影响，后期的维护成本以及业务交接都是很大的问题。

另外，在开发框架设计之初，我们就期望从框架上能够在一定程度上限定代码结构、模块之间的交互方式、状态更新方式等，我们期望的是不同的人写出来的代码在逻辑、结构和风格上都能保持比较统一，即在提高开发效率的同时，也能保证项目后续的可维护性和扩展性，减少不同业务间的交接成本。

基于上述这些需求，在我们对比了多个开源项目后，FishRedux 的整体使用感受正好符合我们的要求。

如下图，两个页面的代码结构基本一致：

页面栈管理

在早期版本，Flutter 引擎的实例占用内存较高，为了减少内存消耗，大家普遍采用单实例的模式，而在 Native 和 Flutter 混合开发的场景下就会存在一个问题，就是 Native 有自己的页面栈，而 Flutter 也维护着一套自己的页面栈，如果 Native 页面与 Flutter 页面穿插着打开，在没有特殊处理的情况下，页面栈会发生错乱。在调研了业内的各种开源方案后，我们选择引入 FlutterBoost 用来管理页面混合栈。

脚本工具

为了方便开发同学搭建 Flutter 的开发环境，同时能够管理使用的 Flutter 版本，我们开发了 zflutter 命令行工具，包含以下主要功能：

• Flutter开发环境安装


• Flutter版本管理


• 创建模版工程（主工程、组件工程）


• 创建模版页面（常规页面、列表页、瀑布流页面）


• 创建页面模块


• 组件工程发布


• 构建Flutter产物


• 脚本自更新

如图：

自动化构建

客户端使用的是自研的 Beetle 平台（集工程管理、分支管理、编译、发布于一体），短时间内要支持上 Flutter 不太现实，基于此，我们先临时自己搭台服务器，通过 gitlab 的 webhook 功能结合 zflutter 工具简单实现了一套自动化构建的服务，待 Beetle 支持 Flutter 组件化开发功能后，再将工作流切回到 Beetle 平台。

小范围试验

在完成基建一期的开发工作后，我们决定通过开发几个实际业务来试验目前的基础设施是否达到既定目标。

我们以不影响主流程、能覆盖常见UI功能、并且能跟 Native 页面做AB测试（主要是方便在出问题时能够切换到 Native 版本）为条件挑选了个人资料页和留言列表页进行了 Flutter 化改造，如下图所示：

这两个页面涵盖了网络请求、图片加载、弹窗、列表、下拉刷新、上拉加载更多、左滑删除、埋点上报、页面跳转等常见功能，足以覆盖日常开发所需的基础能力。

经过完整的开发流程以及一段时间的线上观察，我们得出如下结论：

基础能力

目前已具备的基础能力已经足够支撑普通业务开发（开发过程中补足了一些缺失的能力）。

工作流

整个开发过程在工程依赖管理和分支管理方面的支持还比较缺失，比较依赖人工处理。

开发效率

我们在开发前根据页面功能同时做了纯 Native 开发排期和 Flutter 开发排期，按单人日的成本来对比的话，Flutter 实际开发耗时跟 Native 排期耗时比为 1.25:2，Native 是按照 Android+iOS 两端各一人算的，也就是1.25人/日比2人/日，如果后续对 Flutter 技术熟悉度提升后相信效率还可以进一步提升。

性能体验

线上两个 Flutter 页面的体验效果跟 Native 对比基本感觉不到差别，但是首次进入 Flutter 页面时会有短暂的白屏等待时间，这个是由于 Flutter 环境初始化导致的延迟，后续可以想办法优化。

包体积

在引入 Flutter 之后，转转的安装包体积在两端都分别有所增加：

• Android增加6.1M


• iOS增加14M

试验结果基本符合预期，包体积的增量也在我们的可接受范围内，接下来将进行基建二期的建设，补足目前缺失的能力。

基建二期建设

基建二期的内容主要包含以下工作：

• 配合工程效率组完成 Beetle 对 Flutter 项目的支持


• 组织客户端内部进行 Flutter 技术培训

Beetle支持Flutter

为了能让大家更清晰的了解 Beetle 的工程管理机制，这里先简单介绍下客户端的工程类型：

• Native主工程（又分为 Android 和 iOS）


• Native组件工程（又分为 Android 和 iOS）


• Flutter主工程


• Flutter组件工程（即 Flutter 插件工程）

举个例子，当有一个新版本需要开发时，先从 Native 主工程创建一个版本同时创建一个 Release 分支，即版本分支，然后从版本分支根据具体需求创建对应 Native 组件的版本分支，Flutter 主工程此时可看作是一个 Native 组件，比如此时创建了一个 Flutter 主工程的版本分支后，可以进入 Flutter 主工程再根据需要创建对应的 Flutter 组件工程的版本分支。

Beetle 目前已支持 Flutter 工程管理、分支管理、组件依赖管理以及组件的发布、Flutter 产物的构建等，Beetle 的作用贯穿从开发到上线的整个工作流。

Flutter技术培训

为了让大家更快的熟悉 Flutter 开发，我们在客户端内部组织了5次 Flutter 快速入门的系列分享：

同时也逐步完善内部文档的建设，包括：FlutterSdk 源码维护策略、Flutter 入门指南、Flutter 混合开发方案、Flutter 与 Native 通信方案、Flutter 开发环境配置、Flutter 组件化工程结构、Flutter 开发与调试、Flutter 开发工作流、ZFlutter 工具使用介绍、Flutter 开发之 Beetle 使用指南等，涵盖了从环境搭建、开发调试到构建发布的整个过程。

大范围推广

在完成基建二期的建设后，整体基础设施已经能够支撑我们常见的业务，开发工作流也基本顺畅，于是我们开始了在内部大范围推广计划。

我们先后改造和新开发了个人主页、我发布的页面、微商详、奇趣数码页等业务，基本涵盖了常见的各种类型的页面和功能，整体开发效率与原生单端开发效率持平，但是在特别复杂的页面的性能表现上，Flutter 的表现相对要差一些。

部分页面如下图所示：

探索前端生态

在跨端技术领域我们知道 Web 技术是天然支持的，如果能把前端生态引入到 Flutter 中，那么对客户端来说，在业务的支持度上会更上一个台阶，Web 的体验得到提升的同时客户端也具备了动态化，基于此背景我们开始探索 Flutter 在 Web 上的可能性。

技术调研

当时可选的开源方案有：Kraken、MXFlutter、Flutter For Web。

Kraken

Kraken 是一款基于 W3C 标准的高性能渲染引擎。Kraken 底层基于 Flutter 进行渲染，通过其自绘渲染的特性，保证多端一致性。上层基于 W3C 标准实现，拥有非常庞大的前端开发者生态。

Kraken 的最上层是一个基于 W3C 标准而构建的 DOM API，在下层是所依赖的 JS 引擎，通过 C++ 构建一个 Bridge 与 Dart 通信。然后这个 C++ Bridge 把 JS 所调用的一些信息，转发到 Dart 层。Dart 层通过接收这些信息，会去调用 Flutter 所提供的一些渲染能力来进行渲染。

Kraken 是不依赖 Flutter Widget，而是依赖 Flutter Widget 的底层渲染数据结构 —— RenderObject。Kraken 实现了很多 CSS 相关的能力和一些自定义的 RenderObject，直接将生成的 RenderObject 挂载在 Flutter RenderView 上来进行渲染，通过这样的方式能够做到非常高效的渲染性能。

MXFlutter

MXFlutter 是一套使用 TypeScript/JavaScript 来开发 Flutter 应用的框架。

MXFlutter 把 Flutter 的渲染逻辑中的三棵树（即：WidgetTree、Element、RenderObject ）中的第一棵（即：WidgetTree），放到 JavaScript 中生成。用 JavaScript 完整实现了 Flutter 控件层封装，实现了轻量的响应式 UI 框架，支撑JS WidgetTree 的 build逻辑，build 过程生成的UI描述， 通过Flutter 层的 UI 引擎转换成真正的 Flutter 控件显示出来。

Flutter For Web

Flutter 在 Web 平台上以浏览器的标准 API 重新实现了引擎。目前有两种在 Web 上呈现内容的选项：HTML 和 WebGL。

• 在 HTML 模式下，Flutter 使用 HTML、CSS、Canvas 和 SVG 进行渲染。


• 在 WebGL 模式下，Flutter 使用了一个编译为 WebAssembly 的 Skia 版本，名为 CanvasKit。

HTML 模式提供了最佳的代码大小，CanvasKit 则提供了浏览器图形堆栈渲染的最快途径，并为原生平台的内容提供了更高的图形保真度。

结论

我们对以上方案从接入成本、渲染性能、包体积、开发生态、学习成本等多维度进行了对比：

• 接入成本：Kraken ≈ MXFlutter ≈ Flutter For Web


• 渲染性能：Kraken > MXFlutter > Flutter For Web


• 包体积增量：Flutter For Web < Kraken < MXFlutter


• 开发生态：Kraken ≈ MXFlutter > Flutter For Web


• 学习成本：Flutter For Web < Kraken ≈ MXFlutter

最终选择了 Kraken 作为我们的首选方案。

上线验证

为了使 Kraken 顺利接入转转App，我们做了以下几个方面的工作：

• 升级 FlutterSdk 到最新版，满足接入 Kraken 的基础条件


• 统一客户端容器接口，使得 Kraken 容器能够完美继承 Web 容器的能力


• 自己维护 Kraken 源码，及时修复官方来不及修复的问题，方便增加转转特有的扩展能力


• 制定 Kraken 容器与 Web 容器的降级机制


• 兼容 HTML 加载，保持跟 Web 容器一致的加载方式


• 添加监控埋点，量化指标，指导后续优化方向


• 选择一个简单 Web 页并协助前端同学适配

上线后，我们对页面的各项指标进行了对比，使用 Kraken 容器加载比使用 WebView 加载，在首屏加载耗时的指标上平均增加了281毫秒，原因为：当前版本的 Kraken 容器不支持直接加载 HTML，且只能加载单个 JsBundle，导致加载效率比 WebView 差。

通过跟前端同学沟通，从开发效率上来看，Kraken 工程的开发周期会比实现同样需求的普通 Web 工程增加1.5到2倍的时间，主要原因是受到 CSS 样式、Api 差异，无法使用现有UI组件，另外 Kraken 的调试工具目前还不够完善，使用浏览器调试后还须在客户端容器中调试，整体下来导致开发 Kraken 工程会比开发普通Web工程耗费更多时间。

再次验证

由于之前选择的 Web 页面太过简单，不具备代表性，所以我们重新选定了“附近的人”页面做为改造目标，再次验证 Kraken 在实际开发过程中的效率及性能体验。页面如图所示：

最终因为部分问题得不到解决，并且整体性能较差，导致页面没能成功上线。

存在的问题包括但不限于下面列举的一些：

• 表现不一致问题
  
  
  
  1. CSS 定位、布局表现与浏览器表现不一致
  
  
  2. 部分 API 表现与浏览器不一致(getBoundingClientRect等)
  
  
  3. iOS，Android系统表现不一致
  
  
  
  


• 重大 Bug
  
  
  
  1. 页面初始化渲染完成，动态修改元素样式，DOM不重新渲染
  
  
  2. 滑动监听计算导致 APP 崩溃
  
  
  
  


• 调试成本高
  
  
  
  1. 不支持 vue-router，单项目单路由
  
  
  2. 不支持热更新，npm run build 预览
  
  
  3. 不支持 sourceMap，无法定位源代码
  
  
  4. 真机调试只支持 element 和 network；dom 和 element 无法互相选中；无法动态修改 dom 结构，无法直接修改样式.......
  
  
  5. 页面白屏，假死
  
  
  
  


• 安全性问题
  
  
  
  1. 无浏览器中的“同源策略”限制
  
  
  
  


• 兼容性
  
  
  
  1. npm 包不兼容等
  
  
  
  

通过这一系列的探索和尝试，我们了解到了 Kraken 目前还存在许多不足，如果继续应用会带来高额的开发调试以及维护成本，所以暂时停止了在 Kraken 方向上的投入，但我们仍然在这个方向上保持着关注。

结尾

目前转转在Flutter方向上的实践和探索只是一个起点，我们意识到仍然有很多工作需要去做。我们坚信Flutter作为一项领先的跨端技术，将为转转业务的发展带来巨大的潜力和机会。我们将持续努力，加强技术建设，不断完善实践经验，推动Flutter在转转的应用和发展，为用户提供更好的产品和体验。

转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。

关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于QA），更多干货实践，欢迎交流分享~

教你用 uni-app 开发 APP 上架 IOS 和 Android

介绍

本文记录了我使用uni-app开发构建并发布跨平台移动应用的全过程，旨在帮助新手开发者掌握如何使用uni-app进行APP开发并最终成功上架。通过详细讲解从注册开发者账号、项目创建、打包发布到应用商店配置的每一步骤，希望我的经验分享能为您提供实用的指导和帮助，让您在开发之旅中少走弯路，顺利实现自己的应用开发目标。

环境配置

IOS 环境配置

注册开发者账号 

如果没有开发者账号需要注册苹果开发者账号，并且加入 “iOS Developer Program”，如果是公司项目那么可以将个人账号邀请到公司的项目中。

获取开发证书和配置文件

登录Apple Developer找到创建证书入口

申请证书的流程可以参考Dcloud官方的教程，申请ios证书教程

开发证书和发布证书都申请好应该是这个样子

创建App ID

创建一个App ID。App ID是iOS应用的唯一标识符，稍后你会在uni-app项目的配置文件中使用它。

配置测试机

第一步打开开发者后台点击Devices

第二步填写UDID

第三步重新生成开发证书并且勾选新增的测试机，建议一次性将所有需要测试的手机加入将来就不用一遍遍重复生成证书了

Android 环境配置

生成证书

Android平台签名证书(.keystore)生成指南： ask.dcloud.net.cn/article/357…

uni-app 项目构建配置

基础配置

版本号versionCode 前八位代表年月日，后两位代表打包次数

APP 图标设置

APP启动界面配置

App模块配置

注意这个页面用到什么就配置什么不然会影响APP审核

App隐私弹框配置

注意根据工业和信息化部关于开展APP侵害用户权益专项整治要求应用启动运行时需弹出隐私政策协议，说明应用采集用户数据，这里将详细介绍如何配置弹出“隐私协议和政策”提示框

详细内容可参考Uni官方文档
注意！androidPrivacy.json不要添加注释，会影响隐私政策提示框的显示！！！

在app启动界面配置勾选后会在项目中自动添加androidPrivacy.json文件，可以双击打开自定义配置以下内容：

{

    "version" : "1",

    "prompt" : "template",

    "title" : "服务协议和隐私政策",

    "message" : "　　请你务必审慎阅读、充分理解“服务协议”和“隐私政策”各条款，包括但不限于：为了更好的向你提供服务，我们需要收集你的设备标识、操作日志等信息用于分析、优化应用性能。<br/>　　你可阅读<a href="https://xxx.xxx.com/userPolicy.html">《服务协议》</a>和<a href="https://xxxx.xxxx.com/privacyPolicy.html">《隐私政策》</a>了解详细信息。如果你同意，请点击下面按钮开始接受我们的服务。",

    "buttonAccept" : "同意并接受",

    "buttonRefuse" : "暂不同意",

    "hrefLoader" : "system|default",

    "backToExit" : "false",

    "second" : {

        "title" : "确认提示",

        "message" : "　　进入应用前，你需先同意<a href="https://xxx.xxxx.com/userPolicy.html">《服务协议》</a>和<a href="https://xxx.xxxx.com/userPolicy.html">《隐私政策》</a>，否则将退出应用。",

        "buttonAccept" : "同意并继续",

        "buttonRefuse" : "退出应用"

    },

    "disagreeMode" : {

        "loadNativePlugins" : false,

        "showAlways" : false

    },

    "styles" : {

        "backgroundColor" : "#fff",

        "borderRadius" : "5px",

        "title" : {

            "color" : "#fff"

        },

        "buttonAccept" : {

            "color" : "#22B07D"

        },

        "buttonRefuse" : {

            "color" : "#22B07D"

        },

        "buttonVisitor" : {

            "color" : "#22B07D"

        }

    }

}

我的隐私协议页面是通过vite打包生成的多入口页面进行访问，因为只能填一个地址所以直接使用生产环境的例如：xxx.xxxx.com/userPolicy.…

构建打包

使用HBuilderX进行云打包

IOS打包

构建测试包

第一步 点击发行->原生app云打包

第二步配置打包变量

运行测试包

打开HbuildX->点击运行->运行到IOS App基座

选择设备->使用自定义基座运行

构建生产包

和构建测试包基本差不多，需要变更的就是ios证书的profile文件和密钥证书

构建成功后的包在dist目录下release文件夹中

上传生产包

上传IOS安装包的方式有很多我们选择通过transporter软件上传，下载transporter并上传安装包

确认无误后点击交付，点击交付后刷新后台，一般是5分钟左右就可以出现新的包了。

App store connect 配置

上传截屏

只要传6.5和5.5两种尺寸的就可，注意打包的时候千万不能勾选支持ipad选项，不然这里就会要求上传ipad截屏

填写app信息

配置发布方式

自动发布会在审核完成后直接发布，建议选手动发布

配置销售范围

配置隐私政策

配置完之后IOS就可以提交审核了，不管审核成功还是失败Apple都会发一封邮件通知你审核结果

安卓打包

构建测试包

构建的包在dist/debug目录下

运行测试包

如果需要运行的话，点击运行 -> 运行到Android App底座

构建生产包

构建后的包在dist目录下release文件夹中

构建好安卓包之后就可以在国内的各大手机厂商的应用商店上架了，由于安卓市场平台五花八门就不给大家一一列举了。

参考链接:

• 申请ios证书教程


• Android平台签名证书(.keystore)生成指南


• Android平台隐私政策配置

结语

本文介绍了使用uni-app开发并发布跨平台移动应用的完整流程，包括注册开发者账号、项目创建、打包发布以及应用商店配置，帮助开发者高效地将应用上架到iOS和Android平台。感谢您的阅读，希望本文能对您有所帮助。

前言

不知大家有没有留意过，当前大部分 App 或网页中，很少存在允许用户完全自定义要展示信息的颜色的功能。

例如在钉钉的自定义表情中，只允许用户从一组预设的配色中随机切换：

再比如笔记应用 Notion 虽然允许用户改变文本颜色，但也只允许在一组预设色值中选取：

原因无它，配色，不是一件容易事。

对于大众用户而言，没什么颜色理论知识，很可能挑出来的颜色在应用中很难看、看不清，这会极大的影响用户的使用体验（即使是用户自己造成的）。

因此大部分产品选择的做法是提供一组预先检验过的、不会对用户阅读造成困扰的颜色，放在应用中供用户挑选。

今天我来斗胆挑战一下这个业界难题。

在这篇文章中将会探讨两个具体问题：

文本颜色自适应背景色

在下面这张图中，文本的颜色默认都是黑色的，背景色设置了多个明暗不同的颜色。可以看到对于暗色的背景色，此时文本可阅读性特别差（不太明显，想看清楚会很累）。

如果能够自动根据背景色的明暗，决定使用白色还是黑色的文本，那便是实现了文本颜色的自适应了。

首先介绍下借助第三方库实现的方案。

第三方库实现

color 是 JavaScript 生态中在颜色处理方面最流行的库，它有诸多功能：颜色空间转换、颜色通道分解、获取对比度、颜色混合……

在文本颜色自适应这个场景中，最为方便的两个 API 是 isDark() 和 isLight() ，它们分别用来表示一个颜色是否为深色、是否为浅色。

实际应用：

import Color from 'color'



const BgColors = ['#f87171', '#fef08a', '#042f2e', ...]

export default function Page() {

  return (

    <main>

      {BgColors.map((bg) => (

        <div

          style={{

            background: bg,

	          // 根据背景是否为深色决定文本用白色还是黑色

            color: Color(bg).isDark() ? 'white' : 'black'

          }}

        >

          恍恍惚惚

        </div>

      ))}

    </main>

  )

}

实际效果：

很 Nice ～

下面再来看下使用 CSS 的解决方案。

mix-blend-mode: difference

mix-blend-mode: difference 用于指定一个元素的颜色与背景色进行「差值」混合，可以使用如下公式表达：

# || 表示取绝对值

# 最终元素显示的颜色 = |元素原有的颜色 - 背景色|

result_color = | element_color - background_color |

例如：

• 文本颜色为白色 rgb(255 255 255) 背景色为蓝色 rgb(0 0 255) ，最终文本颜色为黄色 rgb(255 255 0)


• 文本颜色为黑色 rgb(0 0 0) ，此时无论背景色是什么颜色，最终文本的颜色一定和背景色完全相同，因为 | 0 - x | = x

下面来看个实际的 demo，这里我们让文本颜色为 rbg(255, 255, 255)，背景色动态调整：

可以看到这个方案会有如下问题：

• 当背景色为灰色时，文本的颜色和背景色很相似，对比度低，可阅读性差


• 当背景色为彩色时，混合出来的颜色也是彩色，而且颜色比较脏，不太美观

CSS 相对颜色

以 CSS 颜色函数 rgb() 举例，相对颜色的语法是通过 from 关键词扩展了该函数的能力：

color: rgb(from red r g b);

由于 red 的 RGB 是 (255, 0, 0) ，因此后面的 r g b 值分别为 255 0 0 。对于 r g b 还可以调用 calc() 或其他 CSS 函数进一步处理。

除了 rgb() ， rgba() hsl() hwb() lch() 等等 CSS 颜色函数都是支持相对颜色语法的。

CSS 相对颜色语法带来的能力有调节亮度、调节饱和度、获取反转色、获取补充色……其中反转色就可以用于文本颜色自适应的场景中。

在上面 Demo 上，使用如下规则使文本的颜色为背景色的反转色：

color: rgb(from var(--bg) calc(255 - r) calc(255 - g) calc(255 - b));

实际效果：

可以看到虽然能一定程度上提升可阅读性，但是有些反转色奇奇怪怪的，和背景色搭配起来实在不美观，并不是特别推荐使用。

color-constract

color-constract() 可以说是最适合文本颜色自适应场景的 CSS 函数了，用法简单，效果好！

color: color-constract(var(--bg) vs color1, color2, ...);

它的作用即从 vs 右边的一堆色值中，挑选一个和 vs 左边的色值对比度最大的返回。

如 color-constract(#ccc vs #000, #fff) ，由于 #ccc 是个浅灰色，色值和 #000 对比度更大，因此这个函数会返回 #000 。

很美好。

但是！这个函数现在几乎不能用！

目前只有 Safari 中能使用，而且必须开启相关的实验性功能 Flag 。

完全允许用户自定义主题色

让文本的颜色根据背景色自适应，本质是在背景色（background）未知、前景色（foreground）有限的情况下，选择一个合适的前景色，使页面的可读性得到保障。

在上面的 Demo 中，背景色有淡紫色、淡黄色、深绿色、深棕色……前景色即文本的颜色只会有白色、黑色两种情况，依据背景色的明暗决定使用白色还是黑色。

相反的，我们讨论下前景色未知、背景色有限的情况。

看下这个实际应用场景：

在这款应用中，支持明、暗两种主题，明亮主题为左边的白色（#FFFFFF），暗夜主题为右边的深蓝色（#020617），这是两个背景色；标签主题色（即前景色）支持用户自己设定，图中以红色（#FF0000）为例。

通过截图可以看到，红色在这两种背景色上展示效果都还不错，主要是因为他们的对比度足够。

• 红色 vs 白色，对比度：3.998


• 红色 vs 深蓝色，对比度：5.045

要使页面的可读性得到保障，对比度至少要 > 3。

如果允许用户完全自定义前景色，就不可避免的出现用户选择的颜色和背景色的对比度 < 3，这时页面阅读起来会很费力，影响用户体验。

下面给出两种解决方案。

及时给出提示

允许用户完全自定义，意味着用户可以从色盘上选取任意颜色。当用户选取的颜色和背景色对比度 < 3 时，界面上可以给出适当提示，让用户自己决定用一个「难看的颜色」还是遵从应用的建议，选择一个对比度合理，在当前应用中可以和背景色合理搭配的颜色。

实际效果：

相关代码并没有太多难点，主要还是借助 color 库，通过 color1.contrast(color2) 获取两个颜色之间的对比度实现，这里就不放代码了。

自动计算对比度安全的颜色

另一种解决方案，就有点「强制」的意思了：在用户从色盘选色时，实时计算色值和背景色的对比度，如果 < 3 了，就使用 color.lightness() API 逐步的调整颜色的明暗，确保最后界面上使用的是安全对比度的色值。

核心代码：

function calcLightColor(originColor: string) {

  const white = Color('#fff')

  let c = Color(originColor)

  // 对比度 < 3，循环迭代使颜色越来越暗

  while (c.contrast(white) < 3) {

    // lightness() 可以读取/赋值颜色的 HSL 中的亮度值

    // 如果是计算暗夜模式下的安全前景色，这里应该是 + 1，即让颜色越来越亮

    c = c.lightness(c.lightness() - 1)

  }

  return c.hex()

}



function calcDarkColor(originColor: string() {

	// ...

}

实际效果：

可以看到当用户选择了偏白的颜色时，明亮主题中实际使用的是灰色作为前景色，当用户选了择偏黑的颜色时，也有同样的自适应处理。

总结

在 2024 年的今天，CSS 看似已经足够强大，但是在颜色自适应类似的需求中还是略显不足，还好有 color 这个方便的 JavaScript 库帮助我们实现类似的需求。

无论背景色未知，还是前景色未知，只要设计界面时通过各种手段能保证前景色和背景色的对比度 > 3，那就可以保证界面的可阅读性。当然了，这里的安全对比度阈值是可以调整的，设为 3.5、3.75 都是可以的，但也非常不建议低于 3。

微信PC端输入框支持图片、文件、文字、Emoji四种消息类型，本篇文章就这四种类型的消息输入进行实现。我们选用HTML5新增标签属性contenteditable来实现。

contenteditable属性

contenteditable是一个全局属性，表示当前元素可编辑。

该属性拥有一下三个属性值：

• true或空字符串: 表示元素可编辑


• false: 表示元素不可编辑


• plaintext-only: 表示只有原始文本可编辑，禁用富文本编辑

给div元素添加contenteditable, 将元素变为可编辑的状态

<div contenteditable></div>

文字输入

当鼠标聚焦在输入框内时，会有outline展示，所以要去掉该样式

<!-- index.html -->

<div contenteditable class="editor"></div>

.editor:focus {

    outline:none;

}

此时文本就可以正常输入了

图片输入

图片输入分为两部分

• 截图粘贴


• 图片文件复制粘贴

有的浏览器是直接支持截图图片的粘贴的，不过图片文件的复制粘贴就不是我们想要的效果(会把图片粘贴成一个文件的图标俺不是展示图片)。

我们这里要自己做一个图片的粘贴展示，以兼容所有的浏览器。

这里我们使用浏览器提供的粘贴事件paste来实现

paste事件函数中存在e.clipboardData.files 属性，该属性是一个数组，当该数组大于0时，就证明用户粘贴的是文件；通过判断 file 的 type 属性是否为image/... 来确定粘贴的内容是否为图片。

const editor = document.querySelector(".editor");



/**

 * 处理粘贴图片

 * @param {File} imageFile 图片文件

 */

function handleImage(imageFile) {

  // 创建文件读取器

  const reader = new FileReader();

  // 读取完成

  reader.onload = (e) => {

    // 创建img标签

    const img = new Image();

    img.src = e.target.result;

    editor.appendChild(img);

  };



  reader.readAsDataURL(imageFile);

}



// 添加paste事件

editor.addEventListener("paste", (e) => {

  const files = e.clipboardData.files;

  const filesLen = files.length;

  console.log("files", files);

  // 粘贴内用是否存在文件

  if (filesLen > 0) {

    //禁止默认事件

    e.preventDefault();

    for (let i = 0; i < filesLen; i++) {

      const file = files[i];

      if (file.type.indexOf("image") === 0) {

        // 粘贴的文件为图片

        handleImage(file);

        continue;

      }

      // 粘贴内容是普通文件

    }

  }

});

现在就可以粘贴图片了，无论是截图的图片还是复制的文件图片都可以粘贴到文本框内了。

现在存在的问题就是，图片尺寸太大，会按原尺寸展示图片。微信输入框展示的尺寸为最大宽高150x150

.image {

    max-width: 150px;

    max-height: 150px;

}

现在图片的粘贴展示部分就是解释正常的了

细心的同学注意到了，粘贴图片后光标不会向后移动，这是因为我们禁用了粘贴的默认事件，这里需要我们手动处理光标；因为我们使用了appendChild 将图片插入到了输入框的最后面，就会出现无论光标在哪里，粘贴的图片都是出现在输入框的最后面，我们希望的是在光标所在的地方粘贴内容，接下来我们处理一下光标。

光标处理

处理光标主要以来两个WebAPI , Selection和 Range

• Selection：Selection 对象表示用户选择的文本范围或插入符号的当前位置。它代表页面中的文本选区，可能横跨多个元素。通过window.getSelection() 获取 Selection 对象。 具体可查阅MDN-Selection


• Range：Range 接口表示一个包含节点与文本节点的一部分的文档片段。可以使用 Document.createRange 方法创建 Range。也可以用 Selection对象的 getRangeAt()方法或者 Document对象的caretRangeFromPoint() 方法获取 Range 对象。具体可查阅MDN-Range

我们使用window.getSelection获取当前位置，通过 getRangeAt()获取当前选中的范围，将选中的内容删除，再把我们自己的内容插入到当前的 Range 中，就实现了文件的输入。在这时插入的文件是选中状态的，所以要将选择范围折叠到结束位置，即在粘贴文本的后面显示光标。

/**

 *  将指定节点插入到光标位置

 * @param {DOM} fileDom dom节点

 */

function insertNode(dom) {

  // 获取光标

  const selection = window.getSelection();

  // 获取选中的内容

  const range = selection.getRangeAt(0);

  // 删除选中的内容

  range.deleteContents();

  // 将节点插入范围最前面添加节点

  range.insertNode(dom);

  // 将光标移到选中范围的最后面

  selection.collapseToEnd();

}

/**

 * 处理粘贴图片

 * @param {File} imageFile 图片文件

 */

function handleImage(imageFile) {

  // 创建文件读取器

  const reader = new FileReader();

  // 读取完成

  reader.onload = (e) => {

    // 创建img标签

    const img = new Image();

    img.src = e.target.result;

-   editor.appendChild(img);

+   insertNode(img);

  };

  reader.readAsDataURL(imageFile);

}

到这里粘贴到光标位置就正常了

文件输入

文件输入分为两部分粘贴文件和选择文件

• 粘贴文件

• 选择文件

粘贴文件

微信是以卡片的方式展示的文件，所以我们先要准备一个类似的dom结构。

/**

 * 返回文件卡片的DOM

 * @param {File} file 文件

 * @returns 返回dom结构

 */

function createFileDom(file) {

  const size = file.size / 1024;

  const templte = `

          <div class="file-container">

            <img src="./assets/PDF.png" class="image" />

            <div class="title">

              <span>${file.name || "未命名文件"}</span>

              <span>${size.toFixed(1)}K</span>

            </div>

          </div>`;

  const dom = document.createElement("span");

  dom.style = "display:flex;";

  dom.innerHTML = templte;

  return dom;

}

.file-container {

    height: 75px;

    width: 405px;

    box-sizing: border-box;

    border: 1px solid rgb(208, 208, 208);

    padding: 13px;

    display: flex;

    justify-content: start;

    gap: 13px;

    background-color: #ffffff;

}

.file-container .image {

    height: 100%;

    object-fit: scale-down;

}

.file-container .title {

    display: flex;

    flex-direction: column;

    gap: 2px;

}

按照微信样式卡片准备DOM的生成函数，如上。

将生成后的DOM加入到光标位置

/**

 * 处理粘贴文件

 * @param {File} file 文件

 */

function handleFile(file) {

  insertNode(createFileDom(file));

}

在页面上就可以看到效果啦

可以看到以上的卡片还是存在问题的，

• 光标位置不在卡片的最后面


• Backspace 不会将整个卡片都删除掉

卡片的删除

因为我们的卡片是DOM，其父元素也就是输入框，开启了contenteditable ，因此它的该属性也继承了父元素的值，所以本身也是可以编辑的。分析到这里，就会涌现出一个方案——将卡片最外层 div 的contenteditable 属性值设为 false 。

但是，设置了 contenteditable="false" 后就变成了不可编辑元素，光标在他周围就不显示了🥹🥹🥹

再接着考虑，思绪一下又回到了图片身上，我们能不能做一个一样的图片呢？答案是肯定的。

说到做图片我们又会有两种方案：

• svg


• canvas

这里就考虑使用SVG制作卡片。

SVG在这里就不多介绍了，直接开始

<svg width="409" height="77" nsxml="http://www.w3.org/2000/svg">

  <!-- 矩形边框 -->

  <rect

    x="2"

    y="0"

    width="405"

    height="75"

    fill="none"

    stroke="rgb(208,208,208)"

  />

  <!-- 右侧文件图标 -->

  <polygon

    points="15 13,36 13,50 30,50 60,15 60"

    fill="rgb(156,193,233)"

    stroke="rgb(0,105,255)"

    stroke-width="2"

  />

  <!-- 图标折叠三角部分 -->

  <polygon points="36 13,36 30,50 30" fill="rgb(0,105,255)" />

  <!-- 文件类型 -->

  <text

    x="32"

    y="50"

    font-size="10"

    text-anchor="middle"

    fill="rgb(0,105,255)"

  >

    xmind

  </text>

  <!-- 文件名称 -->

  <text x="63" y="30" font-size="16">JavaScript.xmind</text>

  <!-- 文件大小 -->

  <text x="63" y="52" font-size="14">206.6K</text>

</svg>

然后就得到了一个卡片

现在我们只要将该卡片使用JS封装，在上传文件的时候调用生成图片就好了。

封装如下：

/**

 * 返回文件卡片的DOM

 * @param {File} file 文件

 * @returns 返回dom结构

 */

function createFileDom(file) {

  const size = file.size / 1024;

  let extension = "未知文件";

  if (file.name.indexOf(".") >= 0) {

    const fileName = file.name.split(".");

    extension = fileName.pop();

  }

  const templte = `

  <rect

    x="2"

    y="0"

    width="405"

    height="75"

    fill="none"

    stroke="rgb(208,208,208)"

  />

  <polygon

    points="15 13,36 13,50 30,50 60,15 60"

    fill="rgb(156,193,233)"

    stroke="rgb(0,105,255)"

    stroke-width="2"

  />

  <polygon points="36 13,36 30,50 30" fill="rgb(0,105,255)" />

  <text

    x="32"

    y="50"

    font-size="10"

    text-anchor="middle"

    fill="rgb(0,105,255)"

  >

   ${extension}

  </text>

  <text x="63" y="30" font-size="16">${file.name || "未命名文件"}</text>

  <text x="63" y="52" font-size="14">${size.toFixed(1)}K</text>

`;

  const dom = document.createElementNS("http://www.w3.org/2000/svg", "svg");

  dom.setAttribute("width", "409");

  dom.setAttribute("height", "77");

  dom.innerHTML = templte;

  const svg = new XMLSerializer().serializeToString(dom);

  const blob = new Blob([svg], {

    type: "image/svg+xml;charset=utf-8",

  });

  const imageUrl = URL.createObjectURL(blob);

  const img = new Image();

  img.src = imageUrl;

  return img;

}

到这里我们的文件粘贴就完成了，来展示

上传文件

上传文件又包含两部分：图片和普通文件

我们需要在这里做一个判断，如果是图片需要将其内容渲染出来，文件用卡片显示。

<div class="controls">

    <img src="./assets/emoji.png" alt="表情" title="表情" />

    <img

      src="./assets/file.png"

      alt="发送文件"

      title="发送文件"

      class="file"

    />

</div>

const fileDom = document.querySelector(".file");



fileDom.addEventListener("click", () => {

  const input = document.createElement("input");

  input.setAttribute("type", "file");

  input.setAttribute("multiple", "true");

  input.addEventListener("change", () => {

    const files = input.files;

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

      const file = files[i];

      fileTypeCheck(file);

    }

  });

  input.click();

});

以上代码，在输入框上方添加了一个文件的icon , 给这个icon 添加点击事件，选择文件并展示。

到这里文件上传就做好了，但是还是存在问题的。

输入框的光标，在鼠标点击页面其他地方的时候会从输入框移出，如果在这时选择文件不会添加到输入框中。

所以，我们在点击文件上传的时候需要叫光标聚焦到输入框。

const fileDom = document.querySelector(".file");



fileDom.addEventListener("click", () => {

+  // 光标聚焦到输入框

+  editor.focus();

  const input = document.createElement("input");

  input.setAttribute("type", "file");

  input.setAttribute("multiple", "true");

  input.addEventListener("change", () => {

    const files = input.files;

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

      const file = files[i];

      fileTypeCheck(file);

    }

  });

  input.click();

});

到这里文件上传就完美了。

总结

以上的源码已经上传到了Github， 想要源码的小伙伴自己去拉。代码读取文件那部分可以使用Promise 进行优化。最后，欢迎大佬批评指正。

被裁员

先说下本人情况，38，坐标杭州，具备后端架构和大数据架构能力。待过大厂，带过团队，落地过大型项目。

近几年被裁员也不算什么稀奇古怪的事情，我记得2022年下半年面试那会行情远比现在好，那会还会有猎头、企业主动找，我2022年的工作就是猎头推进去的。

然而公司运营不善，2023年底裁撤了，因为融资问题，被迫出局。

本想着年后再看工作，也想休息一段时间，于是年前就没理工作这个事。

狗不理

因为信息差，也可能因为行业这种趋势本身就是没法感知的，年后投简历发现了几个情况：

一些感悟

面对这种突如其来的颠覆认知的行情，我有点措手不及，没预想自己可能就此失业了。现在的世界变化太快了，也可能我待在舒适区太久了，根本对外部世界的变化钝感迟缓。

我也没去问招聘方是什么原因，本身就个人从业经历和技能能来说，自认为还OK，但是问人家也未必会告诉你实话，在这个存量市场，势必是僧多肉少，刺刀见红，现实残酷，朝不保夕。

但是反思下十几年的职场生涯，其实多多少少还是有个人原因的，总结出来，留给后来人吧：

个人期望

最后说点自己的个人期望和未深思的规划：
1、后面还是要自己单干的，可以是独立开发、或者其他。
2、还是会热爱技术，即使如果干不了这行了，也会把它当做一个兴趣培养。

一、背景

在讲微前端之前，首先了解下前端开发模式的发展历程，在最早的时候，前端的开发是耦合在服务端，主要的工作其实就是提供一个界面模板，交互也不多，实际的数据还是在服务端渲染的时候提供的。

大概在2010年，界面越来越复杂，调试、部署、都要依赖于后端，如果还是以模板的形式开发效率太低了。于是就提出了前后端分离的模式开发，这个时期也是单页应用开始火起来的时期。

到了2014左右，后端开始了微服务模式的开发，这也为微前端提供的思路。随着前端承担的东西越来越多，不断的迭代后，原本简单的单页应用，已经变成了一个巨石应用，不管是代码量还是页面量都非常庞大，一个单页应用由多个团队一起来维护。同时巨石应用还受到了非常大的约束，比如新技术的更新、打包速度等等问题。

因此，在2019年左右，借鉴微服务的思想，提出了微前端的开发模式，也就是将一个大型的单页应用，以业务域为粒度，拆分为多个子应用，最后通过微前端的技术，整合成一个完整的单页应用，同时，每个子应用也能够享有独立应用开发一致的体验。

二、微前端简介

微前端概念

微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。Micro Frontends

微前端（Micro Frontends）是一种前端架构模式，借鉴了微服务的架构理念，将一个庞大的前端应用拆分为多个独立灵活的小型应用，每个前端应用都可以独立开发、独立运行、独立部署，再将这些小型应用联合为一个完整的应用。

微前端的目标是使前端开发更加容易、可维护和可扩展，并且能够实现团队之间的协作。

微前端的特点

• 技术栈无关 主框架不限制接入应用的技术栈，子应用可自主选择技术栈


• 独立开发/部署 子应用仓库独立，单独部署，互不依赖


• 增量升级 当一个应用庞大之后，技术升级或重构相当麻烦，而微应用具备渐进式升级的特性


• 独立运行 子应用之间运行时互不依赖，有独立的状态管理


• 提升效率 微应用可以很好拆分项目，提升协作效率


• 可维护性 微前端可以更容易地进行维护和测试，因为它们具有清晰的界限和独立的代码库

劣势

• 增加了系统复杂度 需要对系统进行拆分，将单体应用拆分成多个独立的微前端应用。这种拆分可能导致系统整体变得更加复杂，因为需要处理跨应用之间的通信和集成问题


• 需要依赖额外的工具和技术 例如模块加载器、应用容器等，这些工具和技术需要额外的学习和维护成本，也可能会导致一些性能问题


• 安全性问题 由于微前端应用是独立的，它们之间可能存在安全隐患。例如，如果某个微前端应用存在漏洞，攻击者可能会利用这个漏洞来攻击整个系统


• 兼容性问题 由于微前端应用是独立的，它们之间可能存在兼容性问题。例如，某个微前端应用可能使用了一些不兼容的依赖库，这可能会导致整个系统出现问题


• 开发团队需要有一定的技术水平 实现微前端需要开发团队有一定的技术水平，包括对模块化、代码复用、应用集成等方面有深入的了解。如果团队缺乏这方面的技能，可能会导致微前端实现出现问题

三、微前端的技术实现

3.1 微前端的基础架构

微前端架构基本需要实现三个部分:

• 主应用接入子应用，包括子应用的注册、路由的处理、应用的加载和路由的切换。


• 主应用加载子应用，这部分之所以重要，是因为接入的方式决定了是否可以更高效的解耦。


• 子应用的容器，这是子应用加载之后面临的问题，包含了JS沙箱、样式隔离和消息机制。

3.2 微前端的主要技术问题

1） 构建时组合 VS 运行时组合

主框架与子应用集成的方式

微前端架构模式下，子应用打包的方式，基本分为两种：

要实现真正的技术栈无关跟独立部署两个核心目标，大部分场景下需要使用运行时加载子应用这种方案。

2）JS Entry VS HTML Entry

子应用提供什么形式的资源作为渲染入口？

JS Entry 的方式通常是子应用将资源打成一个 entry script。但这个方案的限制也颇多，如要求子应用的所有资源打包到一个 js bundle 里，包括 css、图片等资源。

HTML Entry 则更加灵活，直接将子应用打出来 HTML 作为入口，主框架可以通过 fetch html 的方式获取子应用的静态资源，同时将 HTML document 作为子节点塞到主框架的容器中。

3）样式隔离

由于微前端场景下，不同技术栈的子应用会被集成到同一个运行时中，所以必须在框架层确保各个子应用之间不会出现样式互相干扰的问题。

“甲之蜜糖，乙之砒霜“，每个方案都有着不同的优势与劣势。

• BEM （Block Element Module）规范命名约束


• CSS Modules 构建时生成各自的作用域


• CSS in JS 使用 JS 语言写 CSS


• Shadow DOM 沙箱隔离


• experimentalStyleIsolation 给所有的样式选择器前面都加了当前挂载容器


• Dynamic Stylesheet 动态样式表


• postcss 增加命名空间

4）JS隔离

一个子应用从加载到运行，再到卸载，有可能会对全局产生一些污染。这些污染包括但不限于：添加 / 删除 / 修改全局变量、绑定全局事件、修改原生方法或对象等。而所有这些子应用造成的影响都可能引起潜在的全局冲突。为此，需要在加载和卸载一个应用的同时，尽可能消除这种影响。目前，主要有两种隔离方式，一种是快照沙箱、另外一种是代理沙箱。

• 快照沙箱的核心思想就是在应用挂载（mount方法）的时候记录快照，在应用卸载（unmount）的时候依据快照恢复环境。
  
  

  实现的思路是直接用 window diff，把当前的环境和原来的环境做一个比较，跑两次循环(创建快照和恢复快照)，然后把两个环境做一次比较，最后去全量的恢复回原来的环境。



• 代理沙箱的核心思想是让子应用里面的环境和外面的环境完全隔离。每个应用对应一个环境，比如应用A对应环境A，应用B对应环境B，同时两者之间的环境和全局环境也互不干扰。
  
  

  实现思路是主要利用 ES6 的 Proxy 能力。通过劫持window，可以劫持到子应用对全局环境的一些修改，当子应用往window上挂载、删除、修改的时候，把操作记录下来，当恢复全局环境时，反向执行之前的操作。

四、微前端方案

实现方式	基本思想	优点	不足	代表方案
路由分发	1.前端框架公共路由方案，映射到不同应用 2.服务器反向代理路由到不同应用	1. 维护、开发成本低；2.适应一些关联方不多、业务场景不发展的情况；	不足：1.独立应用的硬聚合，有比较明显的割裂感	--
前端容器化	iframe 可以创建一个全新的独立的宿主环境，这意味着前端应用之间可以相互独立运行，仅需要做好应用之间的管理、通信即可	1. 比较简单，无需过多改造，开发成本低； 2.完美隔离，JS、CSS 都是独立的运行环境； 3. 不限制使用，页面上可以放多个 iframe 来组合业务	1. 无法保持路由状态，刷新后 iframe url 状态丢失（这点也不是完全不能解决，可以将路由作为参数拼接在链接后，刷新时去参数进行页面跳转）； 2. 全局上下文完全隔离，应用之间通信困难（比如iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果）； 3. iframe 中的弹窗无法突破其本身，无法覆盖全局； 4. 加载慢，每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程	Iframe
前端微服务化	前端微服务化，是微服务架构在前端的实施，每个前端应用都是完全独立（技术栈、开发、部署、构建独立）、自主运行的，最后通过模块化的方式组合出完成的应用	1. 应用间通信简单，全局注入； 2. html entry 的方式引入子应用，相比 js entry 极大的降低了应用改造的成本； 3. 完备的js、css 沙箱方案，确保微应用之间的样式/全局变量/事件互相不干扰； 4. 具备静态资源预加载能力，加速微应用打开速度	1. 适配成本比较高，webpack工程化、生命周期、静态资源路径、路由等都要做一系列的适配工作； 2. css 沙箱采用严格隔离会有各种问题，js 沙箱在某些场景下执行性能下降严重； 3. 基于路由匹配，无法同时激活多个子应用，也不支持子应用保活； 4. 无法支持 vite 等 ESM 脚本运行	Single-SPA、qiankun
应用组件化	Web Components 是一套不同的技术，允许开发者创建可重用的定制元素（它们的功能封装在代码之外）并且在 Web 应用中使用它们，其中html imports 被废弃，可以直接加载js即可	1. 使用 类WebComponent 加载子应用相比 single-spa 这种注册监听方案更加优雅a; 2. 组件式的 api 更加符合使用习惯，支持子应用保活; 3. 降低子应用改造的成本，提供静态资源预加载能力; 4. 基于CustomElement和样式隔离、js隔离来实现微应用的加载，所以子应用无需改动就可以接入	1. 类 webcomponent css 沙箱依然无法绝对的隔离; 2. 支持 vite 运行，但必须使用 plugin 改造子应用，且 js 代码没办法做沙箱隔离; 3. 对于不支持 webcompnent 的浏览器没有做降级处理，兼容性不够	micro-app
微件化	微前端下的微件化是指，每个业务团队编写自己的业务代码，并将编译好的代码部署到指定的服务器上，运行时只需要加载指定的代码即可	1. webpack 联邦编译可以保证所有子应用依赖解耦； 2. 应用间去中心化的调用、共享模块； 3. 模块远程 ts 支持	1. 需要相关规范约束各Widget； 2. 没有有效的 css 沙箱和 js 沙箱，需要靠用户自觉； 3. 子应用保活、多应用激活无法实现； 4. 主、子应用的路由可能发生冲突	EMP

五、iframe 项目实践

5.1 iframe的概念以及作用

iframe（内联框架）是HTML标签，也是一个内联元素，作用是文档中的文档，或者浮动的框架(FRAME)，iframe 元素会创建包含另外一个HTML文档的内联框架（即行内框架) 。

简言之，iframe可以在当前页面嵌入其他页面

5.2 优缺点

优点：

缺点：

5.3 主要属性

5.4 父子页面通信

5.4.1 单向通信（父传子）

URL传参： 可以在iframe的src属性中使用URL参数，将父页面的数据传递到iframe嵌入的页面。

<iframe src="http://new-iframe-url?param1=value1&param2=value2"></iframe>

5.4.2 双向通信

父页面和子页面（即iframe内的页面）的通信机制，分为两种

（1）同源的父子页面通信：

如果父页面和子页面同源，可以直接通过JavaScript访问对方的DOM。这是因为同源策略允许同源的文档之间进行完全的交互。

父页面可以通过iframe元素的contentWindow属性获取子页面的window对象，然后直接调用其函数或访问其变量。同样，子页面也可以通过window.parent获取父页面的window对象。

父页面访问子页面：

// 获取iframe元素

const iframe = document.getElementById('myIframe');

// 获取子页面的window对象

const childWindow = iframe.contentWindow;

// 调用子页面的函数

childWindow.myFunction();

// 访问子页面的变量

console.log(childWindow.myVariable);

// 修改子页面的DOM

childWindow.document.getElementById('myElement').innerText = 'hhhh';

子页面访问父页面：

// 获取父页面的window对象

var parentWindow = window.parent;

// 调用父页面的函数

parentWindow.myFunction();

// 访问父页面的变量

console.log(parentWindow.myVariable);

// 修改父页面的DOM

parentWindow.document.getElementById('myElement').innerText = 'hhhh';

(2)不同源的父子页面通信：

如果父页面和子页面不同源，则不能直接通过JavaScript访问对方的DOM。但可以通过HTML5的postMessage API进行跨源通信。

具体来说，一个页面可以通过postMessage方法向另一个页面发送消息，然后另一个页面通过监听message事件来接收这个消息。

父页面发送消息到子页面：

var iframe = document.getElementById('myIframe');

iframe.contentWindow.postMessage('Hello', 'https://example.com');

子页面接收来自父页面的消息：

window.addEventListener('message', function(event) {

  if (event.origin !== 'https://parent.com') return;

  console.log('received message:', event.data);

});

5.5 项目中遇到的问题

问题描述

背景：页面初始化时，子应用iframe要从主应用获取cookie，实现免登

问题实现步骤：清除主应用的cookie，刷新页面，点击加载子应用，此时没获取到cookie，接口报鉴权错误

问题原因

1）异步获取 cookie：cookie 是通过 postMessage 从父页面异步获取的，在发送 HTTP 请求时，cookie可能尚未获取或存储在 sessionStorage 中

2）立即发送请求：在页面组件的 useEffect 钩子中，当组件挂载时立即发送请求，而不等待 cookie 的获取和存储，导致请求发出时缺少 cookie，造成请求失败

cookie交互流程

修复方案

为了确保 token 在 HTTP 请求发送之前已经成功获取并存储，需要实现以下步骤：

1）等待 token 被存储：在 httpMethod 中添加一个辅助函数，用于轮询 sessionStorage，直到 token 被存储

2）在请求之前检查并等待 token：在每个 HTTP 请求方法中，在请求实际发送之前，先调用辅助函数等待 token 被存储

具体实现

修改 api.js文件

1）创建一个waitForToken函数用于等待cookie中的 token

每隔 100ms 检查一次 sessionStorage 中是否存在 Access-Token，并返回一个 Promise。若存在 token ，调用 resolve(token) 方法将 Promise 标记为成功，并返回 token，否则等待 200 毫秒，再次检查token是否存在

const waitForToken = (timeout = 20000) => {

  return new Promise((resolve) => {

    const startTime = Date.now();

    const checkToken = () => {

      const token = window.sessionStorage.getItem("Access-Token");

      if (token) {

        resolve(token);  //找到 token，通过 resolve 通知任务成功完成

      } else if (Date.now() - startTime >= timeout) {

        resolve(null); // 超时后返回 null

      } else {

        setTimeout(checkToken, 200); //如果没找到，每200ms检查一次

      }

    };

    checkToken();

  });

};

2）修改httpMethod

在每个请求方法里调用 waitForToken， 确保在发送请求之前获取到 token，并在获取到 token 后将其从 sessionStorage 中取出并添加到请求头中

const httpMethod = {

  get: async (url, params) => {

    const token = await waitForToken();  //获取token

    return axios

      .get(api + url, {

        params: params,

        headers: Object.assign(

          headers("json"),

          { "Access-Token": JSON.parse(token) },

          options.headers || {}

        ),

      })

      .then(dataError, errorHandle);

  },

 postJson: async (url, data, options = {}) => {

    const token = await waitForToken();  //获取token

    return axios

      .post(api + url, data, {

        ...options,

        headers: Object.assign(

          headers("json"),

          { "Access-Token": JSON.parse(token) },

          options.headers || {}

        ),

      })

      .then(dataError, errorHandle);

  },

}

六、总结

微前端能否做到利大于弊，具体取决于实际情况和条件。对于小型、高度协作的团队和相对简单的产品来说，微前端的优势相比代价来说就很不明显了；而对于大型、功能众多的产品和许多较独立的团队来说，微前端的好处就会更突出。

工程就是权衡的艺术，而微前端提供了另一个可以做权衡的维度。

学习资料：

• Microfrontends: the good, the bad, and the ugly


• 万字长文-落地微前端 qiankun 理论与实践指北

源码实现思路（面试高分回答） 📖

面试官问我 Vue 的 nextTick 原理是怎么实现的，我这样回答：

在调用 this.$nextTick(cb) 之前：

当调用 this.nextTick(cb) 时：

graph TD

    A["this.$nextTick(callback)"] --> B[将回调函数 callback 放入到数组 callbacks 中]

    B --> C[判断是否是第一次调用 nextTick]

    C -->|是| D[执行 timerFunc, 将 flushCallbacks 添加到任务队列]

    C -->|否| F[如果没有 cb, 则retrun Promise]

    D --> F

    F --> 结束

如果上面的描述没有很理解。没关系，花几分钟跟着我下面来，看完下面的源码逐行讲解，你一定能够清晰地向别人讲出你的思路！

nextTick思路详解 🏃‍♂‍➡

1. 核心代码 🌟

下面用十几行代码，就已经可以基本实现nextTick的功能（默认浏览器支持Promise)

// 存储所有的cb回调函数

const callbacks = [];

/*类似于节流的标记位，标记是否处于节流状态。防止重复推送任务*/

let pending = false;



/*遍历执行数组 callbacks 中的所有存储的cb回调函数*/

function flushCallbacks() {

  // 重置标记，允许下一个 nextTick 调用

  pending = false;

  /*执行所有cb回调函数*/

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

    callbacks[i]();

  }

  // 清空回调数组，为下一次调用做准备

  callbacks.length = 0;

}



function nextTick(cb) {

  // 将回调函数cb添加到 callbacks 数组中

  callbacks.push(() => {

    cb();

  });

  

  // 第一次使用 nextTick 时，pending 为 false，下面的代码才会执行

  if (!pending) {

    // 改变标记位的值，如果有flushCallbacks被推送到任务队列中去则不需要重复推送

    pending = true;

    // 使用 Promise 机制，将 flushCallbacks 推送到任务队列

    Promise.resolve().then(flushCallbacks);

  }

}

测试一下：

let message = '初始消息';

  

nextTick(() => {

  message = '更新后的消息';

  console.log('回调：', message); // 输出2: 更新后的消息

});



console.log('测试开始：', message); // 输出1: 初始消息

如果你想要应付面试官，能手写这部分核心原理就已经差不多啦。

如果你想彻底掌握它，请继续跟着我来！！！🕵🏻‍♂

2. nextTick() 返回promise 🌟

我们在开发中，会使用await this.$nextTick();让其下面的代码全部变成异步代码。
比如写成这样：

await this.$nextTick();

......

......



// 或者

this.$nextTick().then(()=>{

    ......

})

核心就是nextTick()如果没有参数，则返回一个promise

const callbacks = [];

let pending = false;



function flushCallbacks() {

  pending = false;

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

    callbacks[i]();

  }

  callbacks.length = 0;

}



function nextTick(cb) {

  // 用于存储 Promise 的resolve函数

  let _resolve;

  callbacks.push(() => {

  /* ------------------ 新增start ------------------ */

    // 如果有cb回调函数，将cb存储到callbacks

    if (cb) {

      cb();

    } else if (_resolve) {

    // 如果参数cb不存在，则保存promise的的成功回调resolve

      _resolve();

    }

  /* ------------------ 新增end ------------------ */

  });

  if (!pending) {

    pending = true;

    Promise.resolve().then(flushCallbacks);

  }

  

  /* ------------------ 新增start ------------------ */

  if (!cb) {

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

      // 保存resolve到callbacks数组中

      _resolve = resolve;

    });

  }

  /* ------------------ 新增end ------------------ */

}

测试一下：

async function testNextTick() {

  let message = "初始消息";

  

  nextTick(() => {

    message = "更新后的消息";

  });

  console.log("传入回调：", message); // 输出1: 初始消息



  // 不传入回调的情况

  await nextTick(); // nextTick 返回 Promise

  console.log("未传入回调后：", message); // 输出2: 更新后的消息

}



// 运行测试

testNextTick();

3. 判断浏览器环境 🔧

为了防止浏览器不支持 Promise，Vue 选择了多种 API 来实现兼容 nextTick：

    Promise --> MutationObserver --> setImmediate --> setTimeout

// 存储所有的回调函数

const callbacks = [];

/* 类似于节流的标记位，标记是否处于节流状态。防止重复推送任务 */

let pending = false;



/* 遍历执行数组 callbacks 中的所有存储的 cb 回调函数 */

function flushCallbacks() {

  // 重置标记，允许下一个 nextTick 调用

  pending = false;

  /* 执行所有 cb 回调函数 */

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

    callbacks[i](); // 依次调用存储的回调函数

  }

  // 清空回调数组，为下一次调用做准备

  callbacks.length = 0;

}



// 判断最终支持的 API：Promise / MutationObserver / setImmediate / setTimeout

let timerFunc;



if (typeof Promise !== "undefined") {

  // 创建一个已resolve的 Promise 实例

  var p = Promise.resolve();

  // 定义 timerFunc 为使用 Promise 的方式调度 flushCallbacks

  timerFunc = () => {

    // 使用 p.then 方法将 flushCallbacks 推送到微任务队列

    p.then(flushCallbacks);

  };

} else if (

  typeof MutationObserver !== "undefined" &&

  MutationObserver.toString() === "[object MutationObserverConstructor]"

) {

  /* 新建一个 textNode 的 DOM 对象，用 MutationObserver 绑定该 DOM 并指定回调函数。

   在 DOM 变化的时候则会触发回调，该回调会进入主线程（比任务队列优先执行），

   即 textNode.data = String(counter) 时便会加入该回调 */

   var counter = 1; // 用于切换文本节点的值

   var observer = new MutationObserver(flushCallbacks); // 创建 MutationObserver 实例

   var textNode = document.createTextNode(String(counter)); // 创建文本节点

   observer.observe(textNode, {

      characterData: true, // 监听文本节点的变化

   });

   // 定义 timerFunc 为使用 MutationObserver 的方式调度 flushCallbacks

  timerFunc = () => {

    counter = (counter + 1) % 2; // 切换 counter 的值（0 或 1）

    textNode.data = String(counter); // 更新文本节点以触发观察者

  };

} else if (typeof setImmediate !== "undefined") {

  /* 使用 setImmediate 将回调推入任务队列尾部 */

  timerFunc = () => {

    setImmediate(flushCallbacks); // 将 flushCallbacks 推送到宏任务队列

  };

} else {

  /* 使用 setTimeout 将回调推入任务队列尾部 */

  timerFunc = () => {

    setTimeout(flushCallbacks, 0); // 将 flushCallbacks 推送到宏任务队列

  };

}



function nextTick(cb) {

  // 用于存储 Promise 的解析函数

  let _resolve; 

  // 将回调函数 cb 添加到 callbacks 数组中

  callbacks.push(() => {

    // 如果有 cb 回调函数，将 cb 存储到 callbacks

    if (cb) {

      cb();

    } else if (_resolve) {

      // 如果参数 cb 不存在，则保存 Promise 的成功回调 resolve

      _resolve();

    }

  });



  // 第一次使用 nextTick 时，pending 为 false，下面的代码才会执行

  if (!pending) {

    // 改变标记位的值，如果有 nextTickHandler 被推送到任务队列中去则不需要重复推送

    pending = true;

    // 调用 timerFunc，将 flushCallbacks 推送到合适的任务队列

    timerFunc(flushCallbacks);

  }



  // 如果没有 cb 且环境支持 Promise，则返回一个 Promise

  if (!cb && typeof Promise !== "undefined") {

    return new Promise((resolve) => {

      // 保存 resolve 到 callbacks 数组中

      _resolve = resolve;

    });

  }

}

你真的太牛了，居然几乎全部看完了！

Vue纯源码

    上面的代码实现，对于 nextTick 功能已经非常完整了，接下来我将给你展示出 Vue 中实现 nextTick 的完整源码。无非是加了一些判断变量是否存在的判断。看完上面的讲解，我相信聪明的你一定能理解 Vue 实现 nextTick 的源码了吧！💡

// 存储所有的 cb 回调函数

const callbacks = [];

/* 类似于节流的标记位，标记是否处于节流状态。防止重复推送任务 */

let pending = false;



/* 遍历执行数组 callbacks 中的所有存储的 cb 回调函数 */

function flushCallbacks() {

  pending = false; // 重置标记，允许下一个 nextTick 调用

  const copies = callbacks.slice(0); // 复制当前的 callbacks 数组

  callbacks.length = 0; // 清空 callbacks 数组

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

    copies[i](); // 执行每一个存储的回调函数

  }

}

// 判断是否为原生实现的函数

function isNative(Ctor) {

  // 如Promise.toString() 为 'function Promise() { [native code] }'

  return typeof Ctor === "function" && /native code/.test(Ctor.toString());

}



// 判断最终支持的 API：Promise / MutationObserver / setImmediate / setTimeout

let timerFunc;



if (typeof Promise !== "undefined" && isNative(Promise)) {

  const p = Promise.resolve(); // 创建一个已解决的 Promise 实例

  timerFunc = () => {

    p.then(flushCallbacks); // 使用 p.then 将 flushCallbacks 推送到微任务队列



    // 在某些有问题的 UIWebView 中，Promise.then 并不会完全失效，

    // 但可能会陷入一种奇怪的状态：回调函数被添加到微任务队列中，

    // 但队列并没有被执行，直到浏览器需要处理其他工作，比如定时器。

    // 因此，我们可以通过添加一个空的定时器来“强制”执行微任务队列。

    if (isIOS) setTimeout(() => {}); // 解决iOS 的bug，推迟 空函数 的执行（如果不理解，建议忽略）

  };

} else if (

  typeof MutationObserver !== "undefined" &&

  (isNative(MutationObserver) ||

    MutationObserver.toString() === "[object MutationObserverConstructor]")

) {

  let counter = 1; // 用于切换文本节点的值

  const observer = new MutationObserver(flushCallbacks); // 创建 MutationObserver 实例

  const textNode = document.createTextNode(String(counter)); // 创建文本节点

  observer.observe(textNode, {

    characterData: true, // 监听文本节点的变化

  });

  // 定义 timerFunc 为使用 MutationObserver 的方式调度 flushCallbacks

  timerFunc = () => {

    counter = (counter + 1) % 2; // 切换 counter 的值（0 或 1）

    textNode.data = String(counter); // 更新文本节点以触发观察者

  };

} else if (typeof setImmediate !== "undefined" && isNative(setImmediate)) {

  timerFunc = () => {

    setImmediate(flushCallbacks); // 使用 setImmediate 推送到任务队列

  };

} else {

  timerFunc = () => {

    setTimeout(flushCallbacks, 0); // 使用 setTimeout 推送到宏任务队列

  };

}



function nextTick(cb, ctx) {

  let _resolve; // 用于存储 Promise 的解析函数

  // 将回调函数 cb 添加到 callbacks 数组中

  callbacks.push(() => {

    if (cb) {

      try {

        cb.call(ctx); // 执行传入的回调函数

      } catch (e) {

        handleError(e, ctx, "nextTick"); // 错误处理

      }

    } else if (_resolve) {

      _resolve(ctx); // 解析 Promise

    }

  });

  // 第一次使用 nextTick 时，pending 为 false，下面的代码才会执行

  if (!pending) {

    pending = true; // 改变标记位的值

    timerFunc(); // 调用 timerFunc，调度 flushCallbacks

  }

  // 如果没有 cb 且环境支持 Promise，则返回一个 Promise

  if (!cb && typeof Promise !== "undefined") {

    return new Promise((resolve) => {

      _resolve = resolve; // 存储解析函数

    });

  }

}

总结

      通过这样分成三步、循序渐进的方式，我们深入探讨了 nextTick 的原理和实现机制。希望这篇文章能够对你有所帮助，让你在前端开发的道路上更加得心应手！🚀

一转眼又快过年了，回想整个23年，简直是我人生中最黑暗的一年(之一)。

23年，我30岁，在北京干了8年程序员。30岁这年我做了一个决定：结束8年北漂生涯，回老家（一个三线城市）自己创业，去做自媒体。

一、为何做出这个决定

这个决定也不是一时拍脑袋做出的决定，导火索是在22年：

那时候大环境不好，大家都越来越卷，下班的时间也越来越晚。

放假回家亲戚朋友总说，你在北京996这么累，图啥啊，工资是高点，但是完全没有生活啊。而且你在北京漂到啥时候是个头？你又买不起房，又没户口，早晚得回来吧。

我仔细想想也有道理，活了这么多年了都在当牛做马，被pua，还得面临35岁危机，真的受够这种生活了！所以那时候心里埋下了一颗种子：我要去浪浪山的那边看看！

其实我本身就是一个喜欢自由的人，这么多年那句“打工是不可能打工的，这辈子都不会打工”一直激励着我，我想自己有一天也能实现不打工这个目标。

于是22年底我做了一个决定：23年去山的那边看看大海的样子！拿完年终奖就辞职！去创业，去开启我的新的人生！

在准备辞职前的几件事情，都让我更加坚定了辞职的决心：

我觉得这不是我想要的生活，每天太累了，身体累不算，心还累，生怕自己负责的业务出了什么问题，如坐针毡，如芒刺背，如履薄冰。

二、我辞职了

终于，熬到23年，拿到年终奖后，我决定提出离职。

当时身边有些人劝我不要辞职，说现在环境不好，更不应该放弃你的老本行，去做啥自媒体。

我当时内心嗤之以鼻，心想程序员这行也就干到35岁，而且现在卷的不行，加班加的身体都快废了，这行岁数大了没前途！我趁现在30岁还年轻，创业正值当年，辞职改行的选择非常有战略眼光！（当时真的是感觉杰克马附体，准备在这个三十而立的年纪，大干一场！）

当然我也不是脑袋一热就想着辞职去做自媒体，辞职前我做了充足的准备，和很长时间的调研&分析：

• 我作为一个互联网人，做实体店肯定不是我擅长的，肯定只能从互联网上选择行业，互联网项目有很多：个人工具站，知乎好物，闲鱼二手书，小红书带货，抖音带货，抖音个人ip，公众号写作，短剧cps，小说推文，知识付费等等的项目，我可以说都看了一个遍，其中抖音现在流量最大，要做风口上的猪，做抖音相关肯定要容易很多。


• 然后我也学习了一些创业相关的知识，比如如何找对标，如何分析对方商业模式，参加了很多知识付费的圈子，然后还报了小红书和抖音的培训班，总共加起来得有1w多呢。


• 而且我还预留了充足的资金，我做了最坏的打算，就算我一分钱不挣，也够我活3年呢，我不会3年都创业不成功吧！（此处白岩松表情包：不会吧！.jpg）

三、想象很美好

为了这次创业，我还制定了计划，年度计划，季度计划，月计划，周计划，天计划，真的非常详细。

我也要很自律，每天按时起床，锻炼，学习，做业务。这次我真的抱着必胜的决心来做！

当然我也提前列出可能要遇到的风险，并思考解决方案：

比如项目进展慢怎么办，拖延症怎么办，家人反对怎么办，朋友约吃饭打乱我的计划怎么办，遇到困难我该怎么应对等等

这么一套组合拳下来，我觉得已经万事俱备，只差开干了！

四、现实很残酷

4月我如期辞职，当时正值清明节，淅淅沥沥的小雨并没有浇灭我开启新生活的热情。辞职后，我就按计划开始早睡早起，锻炼，学习，搞创业的事情。

但是马上就被打脸了，这是我创业中遇到的第一个难题，也是我万万没有预料到的

就在我创业后的不久，我患上焦虑症，失眠了，而且还很严重，就是那种从晚上11点躺下，躺到早上6点才睡着的那种失眠，而且还时不时的心悸。

我万万没想到会患上失眠症。因为我觉得没有上班的压力了，想啥时候干活就啥时候干活，想干多少干多少，想啥时候下班就啥时候下班，也没人pua我了，还有时间锻炼，应该睡得更好才是。

但实际并不是这样，对于一个从小被学校管，长大了被公司管的芸芸众生来说，创业实际是这样的：

所以在此奉劝有裸辞创业想法的人，千万不要裸辞！裸辞创业九死一生！ 正确的做法是一边工作愿一边做副业，等副业的收入和工资差不多甚至超过工资了，再去辞职。有人会说，我工作那么忙，根本没时间搞副业啊。我之前也是这么想的，但是现在我会告诉你：没有时间就去挤出时间，每天晚睡或者早起一会，周末也抽出时间搞。这点问题都解决不了？创业的遇到问题会比这难十倍！如果这个你觉得太难了，那我劝你还是老老实实打工吧。

但是我已经裸辞了，没办法，只能去解决问题，我开始吃助眠药，喝中药，有些好转，但也没治好，只是比之前好点。

就这么拖着残血的半条命，我坚持了半年多，一半时间学习，一半时间实践，搞了两个自媒体号，第一个号违规被封了，第二个号流量也没啥起色。这条路是越走越看不到希望，每天晚上都不想睡觉，因为害怕明天的到来，因为明早一起床，眼前又是一片黑暗。

五、彻底崩溃

11月，因为种种原因和媳妇生了一场气，我觉得对于我创业，她不鼓励也就算了，在我状态这么差的情况下还不能对我包容一点，甚至有点拆后台的感觉，那几天我就像一个泄了气的皮球，内心被彻底击垮了。（所以现在有点理解每个成功男人的背后，都有一个伟大的女人这句话的含义了）

终于，在创业的压力，8个月没有收入的恐慌，焦虑失眠心悸的折磨中，我决定放弃了。

失败了，彻彻底底的失败。回想这次经历，就好像之前在一艘航行的货轮上打工，然后受不船上的种种压榨，终于鼓起勇气，自己带着一艘救生艇，跳海奔向自己想要的自由。结果高估了自己的目前的实力，经不起茫茫大海狂风骤雨，翻船了。。濒临溺亡。。。

六、重新找工作

放弃后的那几周，我开始熬夜，开始暴饮暴食，之前的运动也放弃了。整天在家里拉着窗帘，除了吃饭就是躺在床上刷手机，让我尽可能分散注意力，减少内心的痛苦。

但是这样的状态也不是事儿啊，目前肯定是不想再去面对创业的事情了，那只能去找个工作先干着了。

刚开始找工作内心又有不甘，因为一个三线城市比起北京来说，不管是工作机会，环境，薪资来说，都差太多。

但是没办法，我现在的感觉就是快溺死了，我现在急需一个救命稻草，活下来，是我目前的首要任务。

于是在网上海投了一遍，结果惨不忍睹，根本没几家公司招人，前前后后一个月，真正靠谱的面试就一家，是的，只有一家。

好在这家也顺利拿了offer，是一家刚创业的公司，一共十几个人，薪资只有原来1/3多点，但是拿到offer那一刻我依然有些激动，我感觉我活下来了，不管怎样，现在能喘口气了。

七、迷茫的未来

现在上班已经一个多月了，公司挺好，不加班，基本上7点前就都走了，离家也挺近，骑个共享单车也就10分钟。这一个月，焦虑没了，不心悸了，失眠也好了。每天就是按部就班上下班，完成老板给的任务，其他的事情也不用自己操心，终于又做起自己熟悉且擅长的事情。

但是内心还是有落差，本来北京好好的工作自己作死给辞了，要不这一年也能攒不少钱呢，现在不但钱没了，这几个月还花了好几w，最后还差点嘎了。

其实入职这家公司前，北京之前的同事问我要不要回去，说现在正忙，我说你先问问吧。

我当时也纠结，如果真的能回去，我还要不要回去，毕竟在那边挣一个月顶这边仨月。但是回都回来了，再去北京可能就一辈子留北京了吧。

不过后来同事说年前没有招人计划了，可能要年后了，如果招人到时再联系我。正好我不用纠结了，这可能就是命运的安排吧。

不过真的想问问你们，如果到时有机会，是继续北漂呢，还是选择在老家呢？

八、结语

说实话，我现在知道了，山的那边还是山，我不知道什么时候才能看到海，甚至我可能一辈子都看不到海了。不过目前想的就是，调整好状态，先走一步算一步吧。

30岁的年纪，学会和自己和解，学会接受自己的平庸，但是依然要努力，毕竟在这个阴雨连天的环境下，没有伞的孩子只能努力奔跑。