凌晨 3 点，办公室里只剩下屏幕的幽光。又一个被 Bug 困扰的不眠之夜，你是否开始怀疑：为什么同样是写代码，有些人能轻松应对，而自己却总是加班救火？为什么有的同事技术能力突飞猛进，而自己似乎原地踏步？

答案也许不在技术本身，而在于我们的工作习惯。正如斯蒂芬·R·柯维在《高效能人士的七个习惯》中所说："我们看待世界的方式完全取决于我们自己的感知。"今天，让我们从程序员的视角出发，聊聊那些能让你事半功倍的 6 个习惯。

1. 主动积极

在编程的世界里，有两种程序员：被动的和主动的。

被动的程序员总是抱怨外部环境，比如公司制度、项目资源不足，甚至相信看几个“速成教程”就能改变命运。

而主动的程序员则会专注于自己能掌控的事情，比如提升技能、参与开源项目、参加技术竞赛，甚至主动寻找更好的职业机会。

如何做到主动积极？

• 专注于“影响圈” ：不要纠结于那些你无法改变的事情，比如公司政策或市场环境，而是把精力放在你能控制的事情上，比如学习新技术、优化代码质量。


• 为自己的职业负责：不要等待别人给你机会，而是主动创造机会。比如，定期更新简历、参加技术社区活动，或者尝试新的编程语言。

主动积极的程序员明白，职业发展是自己的责任，而不是外界的恩赐。

2. 以终为始

很多程序员在工作中随波逐流，接到任务就埋头苦干，却从未思考过最终的目标是什么。结果就是，花了大量时间，却发现方向错了。斯蒂芬·柯维提出的“以终为始”理念，强调在开始任何事情之前，先明确最终的目标。

如何在编程中应用这一习惯？

• 明确项目目标：在开始一个新项目时，先搞清楚最终的交付成果是什么。功能需求和非功能需求有哪些？用户体验的核心是什么？


• 制定清晰的计划：花 30 分钟规划项目，可以节省 10 小时的开发时间。比如，先需求分析，再决定系统架构，而不是直接开始写代码。

记住，编程不仅仅是写代码，更是解决问题的艺术。明确目标，才能让你的努力更有方向。

3. 先做最重要的事

程序员的日常工作中，往往会被各种紧急任务打断，比如修复 Bug、处理线上问题。

但如果你总是被这些琐事牵着鼻子走，就会忽略那些对长期发展更重要的事情，比如学习新技术、优化系统架构。

如何区分重要和紧急？

• 使用艾森豪威尔矩阵：将任务分为四类：
  
  
  
  
  1. 重要且紧急：立即处理，比如修复生产环境的重大 Bug。
  
  
  2. 重要但不紧急：安排时间，比如学习新技术、优化代码。
  
  
  3. 不重要但紧急：尽量委派，比如回复一些无关紧要的邮件。
  
  
  4. 不重要且不紧急：直接忽略，比如刷社交媒体。
  
  
  
  

优先处理“重要”的任务，因为这些任务决定了你的长期成长。

4. 考虑双赢

程序员的工作并不是孤军奋战，而是与团队协作完成的。无论是与其他工程师合作，还是与产品经理、设计师沟通，双赢的思维都至关重要。

双赢并不是让步，而是找到一种对双方都有利的解决方案。

如何培养双赢思维？

• 欣赏团队的多样性：每个人都有自己的优势和视角，学会倾听和尊重他人的意见。


• 建立信任：通过高质量的代码和积极的态度，赢得团队的信任。


• 共同成长：在代码审查中，不仅指出问题，还要提出改进建议；在项目中，主动分享自己的经验和知识。

双赢的思维不仅能让团队更高效，还能帮助你建立长期的职业人脉。

5. 沟通的艺术，1 + 1 > 2 的力量

程序员之间的沟通，不仅仅是语言上的交流，更是通过代码和文档进行的“无声对话”。

如果你写的代码晦涩难懂，或者文档不清晰，就会给团队带来额外的负担。

如何提升沟通能力？

• 写清晰的代码：变量命名要有意义，注释要简洁明了。记住，代码是写给人看的，机器只是顺便执行。


• 站在用户的角度思考：设计界面时，考虑用户的使用习惯；编写错误提示时，尽量清晰友好，而不是让用户感到困惑。


• 倾听他人的意见：在团队讨论中，先理解别人的观点，再表达自己的看法。

如何实现高效协作？

• 参与代码审查：通过审查他人的代码，学习新的技巧，同时也能帮助团队提高代码质量。


• 结对编程：两个人一起编程，可以互相补充思路，避免遗漏问题。


• 知识分享：定期组织技术分享会，或者在团队中推广最佳实践。

优秀的程序员，不仅能写出高质量的代码，还能通过代码与团队和用户“对话”。

6. 持续学习，永不止步

技术更新迭代飞快，程序员如果不持续学习，很容易被淘汰。磨砺锯子的习惯，强调在忙碌的工作中，抽出时间提升自己。

如何保持学习的动力？

• 学习新技术：每年掌握一门新语言或框架，比如从 node 转向 rust，或者学习嵌入式技术。


• 参与技术社区：通过开源项目、技术论坛、群聊或者线下活动，与其他程序员交流经验。


• 关注行业动态：阅读技术博客、观看技术演讲，了解最新的趋势和工具。

就像磨刀不误砍柴工，持续学习不仅能提升你的技术水平，还能让你在职业生涯中始终保持竞争力。

改变习惯并不容易，但只要你愿意从今天开始，一点点调整自己的行为，就能逐渐看到改变的力量。

webview 我 *

众所周知，将已上线的H5页面转换为小程序，最快的方法是通过WebView进行套壳。然而，在这个过程中，我们需要将H5页面的登录和支付功能迁移到小程序版本。这意味着H5页面需通过特定的方式与小程序进行通信，以实现如支付等关键功能。

因此需要了解H5与WebView之间的通讯方式，以确保数据的顺利传递和功能的无缝对接。

找了很久发现H5与WebView的通讯方式主要有两种：

而webview自带的bindmessage、bindload、binderror，触发条件只有小程序后退、组件销毁、分享、复制链接，给我卡的死死的，只好选择了第一种方式，WebSocket虽然可以实现实时通讯，但会增加额外的开销，不符合我的需求。

这里的URL域名必须添加到 小程序后台中-管理-业务域名内，否则会报无法打开 xxx 页面，个人小程序是没有这个选项的，需要申请成企业小程序

小程序向H5通讯

小程序端

<view class="content">

		<web-view :src="url"></web-view>

	</view>

H5端

// 判断当前页面的 URL 是否包含 'userInfo'，用于识别是否来自小程序端

if (window.location.href.includes('userInfo')) {  

    // 匹配 URL 中的 userInfo 参数

    const userInfoRegex = /userInfo=([^]*)/; 



    // 解码

    const decodedUrl = decodeURIComponent(window.location.href); 



    // 使用正则表达式从解码后的 URL 中提取参数值

    const userInfoMatch = decodedUrl.match(userInfoRegex);

    let auth_token =  userInfoMatch[1];

    localStorage.setItem('loc_token', auth_token);

}

H5向小程序通讯

小程序端

onMounted(() => {

	const paymentData = getCurrentPages().pop().options.paymentData // 获取当前页面参数

	submitInfo(paymentData);

	});

H5端

 wx.miniProgram.navigateTo({

          url: `/pagesMember/pay/pay?paymentData=${payInfo.value}`,

        })

通讯限制也就算了，导航栏不能自定义，还不让去掉，这让自带导航栏显得极其突兀！我 * ！！！

navigationStyle: custom对 web-view 组件无效
一句话干碎我的摸鱼梦，领导要把那块做成透明的，没办法只好把常用页面重构，
but小程序不支持elementPlus啊，太爽了家人们。

【新智元导读】科技行业的就业市场正在发生重大变革，人才供需逆转，初级职位减少，技能要求增加，求职竞争加剧。

科技行业曾是众多人才竞相追求的热门领域，但如今却面临着职位减少的挑战。

根据 Indeed.com 的数据，自 2020 年 2 月以来，软件开发岗位的招聘广告数量已经下降了超过 30%。

Layoffs.fyi 网站的报告也显示，今年科技行业的裁员潮仍在继续，自 1 月份以来，已有约 13.7 万个工作岗位被裁减。

软件工程师在招聘网站上出现的频次对比，以 2018 年 1 月作为基准 100。来源：ADP

对于长期在就业市场占据优势的科技行业来说，这种急剧的变化不仅仅是短期的不适，而是整个行业正在经历的一次根本性的劳动力需求调整，一些从业者正被市场淘汰。

47 岁的 Chris Volz，一位居住在加利福尼亚州奥克兰的工程经理，自 90 年代末就开始在科技行业工作，但在 2023 年 8 月被一家房地产技术公司解雇。他表示：「这次的情况感觉非常、非常不同。」

Volz 之前的经历中，大部分工作机会都是通过猎头或内部推荐获得的。然而现在，他发现他的人脉网络中的许多人也都被裁员了，这迫使他不得不在职业生涯中第一次主动向外投递简历。

虽然在疫情期间，随着消费者将日常生活和消费活动转移到线上，科技公司迎来了招聘热潮，大量扩充员工队伍。

人才争夺战如此激烈，以至于公司囤积员工，不让他们去往竞争对手方工作；一些员工说，他们实际上是被雇佣来无所事事的。

然而，随着通货膨胀和利率的上升，经济形势迅速变化，导致一些大型科技公司开始大规模裁员。

ADP 研究部主管 Nela Richardson 表示，尽管疫情期间的招聘热潮减缓了整体的下降趋势，但并未改变长期趋势，部分原因是数字领域创新的自然发展轨迹，技术解决方案正在取代传统的人力。

她说， 「在数字领域，你不再像早期那样有很多新的突破。因为有越来越多的技术解决方案，而不仅仅是人的解决方案」 。

科技行业的非技术人员，如市场营销、人力资源和招聘人员，也面临着多次解雇的风险。

James Arnold 在过去的 18 年里一直从事科技领域的招聘工作，但在不到两年的时间里却两次被裁员。

在疫情期间，他在 Meta 担任人力资源，快速招聘新员工。2022 年 11 月，他被解雇了，然后花了将近一年的时间找工作，最后才在行业外找到了一份工作。

Arnold 说，他申请的大多数工作的薪水都比过去低三分之一 。

尽管科技公司的财务状况有所反弹，但一些公司更倾向于依赖顾问和外包职位。

Arnold 认为，疫情证明了远程工作的有效性，这为全球化就业市场打开了新的可能性。

初级职位正在减少

以往，初级职位对于技术实习生来说是一个高薪的起点，他们常常能够获得六位数的年薪，并且有很大机会转正。

但是，最近这一趋势发生了转变。企业开始减少实习机会，并降低了初级职位的招聘数量。

现在，即便是入门级职位，也要求应聘者具备多年的工作经验。

薪酬规划初创公司 Pequity 的首席执行官 Kaitlyn Knopp 观察到，过去薪酬过高和职称与经验不匹配的现象已经得到纠正。

她指出：「我们发现职位级别正在重新调整，人们的经验和职责更加匹配了。」

根据 Pequity 的数据，2024 年薪资增长基本停滞，平均薪资仅比去年增长了 0.95%。

Pequity 还发现，自 2019 年以来，中型企业软件即服务公司为初级职位提供的股权补助平均下降了 55%。

然而，目前失业技术人员和职场新人之间的竞争愈发激烈，而面试机会却在不断减少。

同时，企业对工程师的要求更为全面。

人员招聘公司 Robert Half 和技术实践部执行总监 Ryan Sutton 说，为了提高效率和降低成本，他们希望团队成员不仅具备软技能和协作能力，还应了解公司的人工智能战略和发展方向。

他说道：「他们希望看到更多多才多艺的人才。」

通过网上申请在科技领域找工作毫无结果，于是 Glenn Kugelman 采用了另一种策略：用纸和胶带在曼哈顿悬挂传单，宣传他的 LinkedIn 简介

不少技术人员开始寻求提升自身技能，纷纷报名参加人工智能训练营或其他相关课程。

Michael Moore 是亚特兰大的一名软件工程师，今年 1 月被一家网络应用程序开发公司解雇，在七个月的求职无果后，他决定报读一所网络大学。

摩尔曾通过在线课程学习编程，并表示六年前没有大学学位的他依然顺利找到了工作。

科技公司的战略变化

企业战略也正在发生转变。

科技公司不再追求不惜一切代价的增长，也不再对那些宏伟的「登月计划」进行投资，而是将焦点转向能够带来收入的产品和服务上。

他们减少了对初级职位的招聘，缩减了招聘团队，并放弃了一些不盈利领域的项目和工作，比如虚拟现实和设备。

与此同时，企业开始将大量资源投入到人工智能领域。

2022 年末发布的 ChatGPT 让人们看到了生成式人工智能创造类人内容和潜在行业变革的能力。这引发了投资热潮，人们争相构建最先进的人工智能系统。

在这个领域拥有专业知识的工人成为了少数几个强势群体之一。

从事大型语言模型工作的人员目前在市场上非常抢手，这些模型是 ChatGPT 等产品的基础，从事此类工作的人员年收入远超百万美元。

Pequity 的首席执行官 Kaitlyn Knopp 指出，人工智能工程师的薪资是普通工程师的两到四倍，她认为这是对未知技术的极端投资，导致公司无法在其他人才上进行投资。

甚至科技行业之外的公司也在积极招聘人工智能人才。一位猎头 Martha Heller 表示，五年前，董事会并不像现在这样关注公司的人工智能战略。

科技行业的就业市场正在经历一场深刻的变革。虽然初级职位减少，整体就业竞争加剧，但人工智能等新兴技术领域仍然提供了广阔的就业机会。

对于技术人员而言，不断学习新技能，适应行业变化，是在变革中寻找机遇的关键。

而对于行业来说，这也许是一个重新思考和调整人才培养和引进策略的契机。

参考资料：

http://www.wsj.com/tech/tech-j…

背景

这几天写代码，遇到一个不确定的知识点：我在vue的props中如何给一个属性定义小写的bolean，代码就会报错

但是大写的Bolean就没问题

由于我在其他地方我看大小写都可以，有点疑惑，于是想去请教一下同事。然而，没想到同事上来就diss我：

这么基础的知识你都不清楚？这两个根本就不是一个东西！

我有点不开心，想反驳一下：

这两个不都是描述类型的东西吗？我给你看其他地方的代码，这两个都是可以混用的！

同事有点不耐烦，说道：大姐，boolean是TS中的类型声明，Boolean是JavaScript 的构造函数，根本不是一个东西吧！

行吧，我也刚入门不久，确实不了解这个东西，只能强忍委屈，对同事说了声谢谢，我知道了！

然后，我好好的学习了一下Boolean和boolean的知识，终于搞明白他们的区别了。

Boolean和boolean

本质区别

同事说的很对，他们两个的本质区别就是一个是JavaScript语法，一个是TypeScript语法，这意味着非TypeScript项目是不存在boolean这个东西的。

Boolean 是 JavaScript 的构造函数

Boolean 是 JavaScript 中的内置构造函数，用于布尔值的类型转换或创建布尔对象。

typeof Boolean; // "function"

boolean 是 TypeScript 的基本类型

• 如果使用了 TypeScript，boolean 是 TypeScript 中的基本类型，用于静态类型检查。


• 在 JavaScript 的运行时上下文中，boolean 并不存在，仅作为 TypeScript 的静态检查标识。

typeof boolean; // ReferenceError: boolean is not defined

TS中作为类型的Boolean和boolean

在TypeScript中，Boolean和boolean都可以用于表示布尔类型

export interface ActionProps {

	checkStatus: Boolean

}

export interface RefundProps {

	visible: boolean

}

但是，他们存在一些区别

boolean

• boolean 是 TypeScript 的基本类型，用于定义布尔值。


• 它只能表示 true 或 false。


• 编译后 boolean 不会存在于 JavaScript 中，因为它仅用于静态类型检查。

//typescript

let isActive: boolean; // 只能是 true 或 false

isActive = true;       // 正确

isActive = false;      // 正确

isActive = new Boolean(true); // 错误，不能赋值为 Boolean 对象

Boolean

• Boolean 是 JavaScript 的内置构造函数，用于将值显式转换为布尔值或创建布尔对象（Boolean 对象）。


• 它是一个引用类型，返回的是一个布尔对象，而不是基本的布尔值。


• 在 TypeScript 中， Boolean 表示构造函数类型，而不是基本的布尔值类型。

//typescript

let isActive: Boolean; // 类型是 Boolean 对象

isActive = new Boolean(false); // 正确，赋值为 Boolean 对象

isActive = true; // 正确，基本布尔值也可以兼容

关键区别

为什么尽量避免使用 Boolean ？

类型行为不一致：Boolean 是对象类型，而不是基本值类型。这会在逻辑运算中导致混淆：

const flag: Boolean = new Boolean(false);

if (flag) {

  console.log("This will run!"); // 因为对象始终为 truthy

}

性能开销更大：Boolean 会创建对象，而 boolean 是直接操作基本类型。

vue中的Boolean与boolean

Vue 的运行时框架无法识别 boolean 类型，它依赖的是 JavaScript 的内置构造函数（如 Boolean、String、Number 等）来检查和处理 props 类型。

因此，props的Type只能是Boolean、String或Number。

但是如果vue中开启了ts语法，就可以使用boolean 表示类型了

<script lang="ts" setup>

  

interface IProps {

    photoImages?: string[],

    isEdit?: boolean

}



const props = withDefaults(defineProps<IProps>(), {

    photoImages: () => [],

    isEdit: true

})



</script>

欢迎关注微信公众号：FSA全栈行动 👋

一、概述

最近准备使用 Flutter 的 3.24 版本打包上架 APP，结果前天看到有人提了一个 issue: github.com/flutter/flu… ，说分别使用 3.24.3 和 3.24.4 提交苹果审核时，都惨遭被拒~

苹果反馈的信息如下：

Guideline 2.5.1 - Performance - Software Requirements



The app uses or references the following non-public or deprecated APIs:



Frameworks/Flutter.framework/Flutter



Symbols:



• _kCTFontPaletteAttribute

• _kCTFontPaletteColorsAttribute



The use of non-public or deprecated APIs is not permitted, as they can lead to a poor user experience should these APIs change and are otherwise not supported on Apple platforms.

可以看到，是说 Flutter 使用了未公开的 API，并且他使用 strings 命令也验证了这一点。

3.24.x

strings Runner.app/Frameworks/Flutter.framework/Flutter | grep kCT

SkCTMShader

kCTFontVariationAxisHiddenKey

kCTFontPaletteAttribute

kCTFontPaletteColorsAttribute

3.22.3

strings Runner.app/Frameworks/Flutter.framework/Flutter | grep kCT

SkCTMShader

kCTFontVariationAxisHiddenKey

我先在 Flutter 引擎源码中搜索，结果压根就搜索不到，随后打开了前几日编译好的引擎调试项目，结果一搜一个准，在 third_party 依赖下的 Skia 代码中，很快就定位到了引入未公开 API 的相关提交记录 skia-review.googlesource.com/c/skia/+/86… 。

我一看完就啪的一声敲起来了，很快啊！上来就是一个 Revert skia-review.googlesource.com/c/skia/+/91… 。

目前此次受影响的 Flutter 版本范围暂时是 3.24.0 ~ 3.24.4，得等待新版本的发布才可以解决。建议还没用上 3.24 的小伙伴先不要升级，那如果已经是 3.24 或者是一定要用 3.24.4 及以下版本的小伙伴要怎么办呢？那就跟我一起来自编译引擎吧~

二、编译引擎

环境

注意：全程需要科学上网环境，请自行查找和配置

首先拉取最新的 depot_tools，放到一个合适的位置，比如我放在 ~/development 目录下

cd ~/development

git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git

将 depot_tools 添加至环境变量，在你的终端配置文件里补充如下内容

终端配置文件因人而异，如：~/.bash_profile、~/.zshrc、~/.zprofile，请自行判断

export PATH = "$HOME/development/depot_tools":$PATH

然后 source ~/.zshrc（这里请根据自身情况修改终端配置文件路径）

拉源码

找个合适的目录，创建 engine 目录并进入

mkdir engine

cd engine

开始拉取源码

fetch flutter

它会在当前目录下创建 .gclient 文件，写好配置，并执行 gclient sync

solutions = [

  {

    "custom_deps": {},

    "deps_file": "DEPS",

    "managed": False,

    "name": "src/flutter",

    "safesync_url": "",

    "url": "https://github.com/flutter/engine.git",

  },

]

如果在拉取代码的过程中遇到如下问题

remote: Enumerating objects: 835563, done.

remote: Counting objects: 100% (1612/1612), done.

remote: Compressing objects: 100% (1011/1011), done.

error: RPC failed; curl 92 HTTP/2 stream 5 was not closed cleanly: CANCEL (err 8)

error: 1481 bytes of body are still expected

fetch-pack: unexpected disconnect while reading sideband packet

fatal: early EOF

fatal: fetch-pack: invalid index-pack output



src/flutter (ERROR)

----------------------------------------

[0:00:00] Started.

别慌，执行下方命令让其接着拉，直至完成

gclient sync

拉取完成后，去查看我们使用的 Flutter 版本对应的引擎版本，这里以 3.24.4 为例，打开链接：github.com/flutter/flu… ，拿到 db49896cf25ceabc44096d5f088d86414e05a7aa

执行如下命令进行切换

cd src/flutter

git checkout db49896cf25ceabc44096d5f088d86414e05a7aa

执行完成会输出如下内容

Previous HEAD position was b0a4ca92c4 Add FlPointerManager to process pointer events from GTK in a form suitable for Flutter. (#56443)

HEAD is now at db49896cf2 [CP-stable]Add xcprivacy privacy manifest to macOS framework (#55366)

post-checkout: The engine source tree has been updated.



You may need to run "gclient sync -D"

按照提示执行

gclient sync -D

调整源码

按路径 engine/src/flutter/third_party/skia/src/ports/SkTypeface_mac_ct.cpp 打开文件，按下方内容进行修改（红：删除，绿：新增）

static CFStringRef getCTFontPaletteAttribute() {

-    static CFStringRef* kCTFontPaletteAttributePtr =

-        static_cast<CFStringRef*>(dlsym(RTLD_DEFAULT, "kCTFontPaletteAttribute"));

-    return *kCTFontPaletteAttributePtr;

+    return nullptr;

+    //static CFStringRef* kCTFontPaletteAttributePtr =

+    //    static_cast<CFStringRef*>(dlsym(RTLD_DEFAULT, "kCTFontPaletteAttribute"));

+    //return *kCTFontPaletteAttributePtr;

}

static CFStringRef getCTFontPaletteColorsAttribute() {

-    static CFStringRef* kCTFontPaletteColorsAttributePtr =

-        static_cast<CFStringRef*>(dlsym(RTLD_DEFAULT, "kCTFontPaletteColorsAttribute"));

-    return *kCTFontPaletteColorsAttributePtr;

+    return nullptr;

+    //static CFStringRef* kCTFontPaletteColorsAttributePtr =

+    //    static_cast<CFStringRef*>(dlsym(RTLD_DEFAULT, "kCTFontPaletteColorsAttribute"));

+    //return *kCTFontPaletteColorsAttributePtr;

}



...



static bool apply_palette(CFMutableDictionaryRef attributes,

                          const SkFontArguments::Palette& palette) {

    bool changedAttributes = false;

-    if (palette.index != 0 || palette.overrideCount) {

+    if ((palette.index != 0 || palette.overrideCount) && getCTFontPaletteAttribute()) {

        SkUniqueCFRef<CFNumberRef> paletteIndex(

                CFNumberCreate(kCFAllocatorDefault, kCFNumberIntType, &palette.index));

        CFDictionarySetValue(attributes, getCTFontPaletteAttribute(), paletteIndex.get());

        changedAttributes = true;

    }



-    if (palette.overrideCount) {

+    if (palette.overrideCount && getCTFontPaletteColorsAttribute()) {

        SkUniqueCFRef<CFMutableDictionaryRef> overrides(



...

相应修改来自: skia-review.googlesource.com/c/skia/+/91…

编译

来到 engine/src 目录，使用 gn 编译生成 ninja 构建文件

./flutter/tools/gn --runtime-mode release --mac-cpu arm64

./flutter/tools/gn --ios --runtime-mode release

使用 ninja 编译引擎的最终产物

ninja -C out/host_release_arm64

ninja -C out/ios_release

如果你当前是 MacOS 15 的 Sequoia 系统，在执行 ninja -C out/host_release_arm64 时会遇到如下错误

COPY '/System/Library/Fonts/A...arty/txt/assets/Apple Color Emoji.ttc'

FAILED: gen/flutter/third_party/txt/assets/Apple Color Emoji.ttc 

ln -f '/System/Library/Fonts/Apple Color Emoji.ttc' 'gen/flutter/third_party/txt/assets/Apple Color Emoji.ttc' 2>/dev/null || (rm -rf 'gen/flutter/third_party/txt/assets/Apple Color Emoji.ttc' && cp -af '/System/Library/Fonts/Apple Color Emoji.ttc' 'gen/flutter/third_party/txt/assets/Apple Color Emoji.ttc')

cp: chflags: gen/flutter/third_party/txt/assets/Apple Color Emoji.ttc: Operation not permitted

[18/4139] SOLINK libvk_swiftshader.dylib libvk_swiftshader.dylib.TOC

ninja: build stopped: subcommand failed.

别急，打开 engine/src/build/toolchain/mac/BUILD.gn，做如下修改，修改完再执行 gn 和 ninja

    tool("copy") {

-      command = "ln -f {{source}} {{output}} 2>/dev/null || (rm -rf {{output}} && cp -af {{source}} {{output}})"

+      command = "ln -f {{source}} {{output}} 2>/dev/null || (rsync -a --delete {{source}} {{output}})"

      description = "COPY {{source}} {{output}}"

    }

相应的 issue: #152978

好了，静静等待编译完成。

请注意，这将是个十分漫长且全程 CPU 占用率为 100% 的过程~

建议使用一台空闲的 Mac 电脑去做这个事！否则你将啥活也干不了~

验证

进入 engine/src/out/ios_release

strings Flutter.framework/Flutter | grep kCT 



SkCTMShader

kCTFontVariationAxisHiddenKey

可以看到，没有 kCTFontPaletteAttribute 和 kCTFontPaletteColorsAttribute。

使用本地引擎

执行如下命令对项目进行编译

flutter build ipa \

--local-engine-src-path=/Users/lxf/engine/src \

--local-engine=ios_release \

--local-engine-host=host_release_arm64

如果你有使用 realm 的话，可能会遇到如下错误

Installing realm (1.0.3)

[!] /bin/bash -c 

set -e

source "/Users/lxf/app/ios/Flutter/flutter_export_environment.sh" && cd "$FLUTTER_APPLICATION_PATH" && "$FLUTTER_ROOT/bin/flutter" pub run realm install --target-os-type ios --flavor flutter



You must specify --local-engine or --local-web-sdk if you are using a locally built engine or web sdk.

你需要对该文件
/Users/lxf/app/ios/.symlinks/plugins/realm/ios/realm.podspec 进行修改，在 \"$FLUTTER_ROOT/bin/flutter\" 和 pub 中间加上引擎相关参数。如下所示

s.prepare_command           = "source \"#{project_dir}/Flutter/flutter_export_environment.sh\" && cd \"$FLUTTER_APPLICATION_PATH\" && \"$FLUTTER_ROOT/bin/flutter\" --local-engine-src-path /Users/lxf/engine/src --local-engine ios_release --local-engine-host host_release_arm64 pub run realm install --target-os-type ios --flavor flutter"



:script => 'source "$PROJECT_DIR/../Flutter/flutter_export_environment.sh" && cd "$FLUTTER_APPLICATION_PATH" && "$FLUTTER_ROOT/bin/flutter" --local-engine-src-path /Users/lxf/engine/src --local-engine ios_release --local-engine-host host_release_arm64 pub run realm install --target-os-type ios --flavor flutter',

如果你只是想对项目进行配置，则将 ipa 改为 ios，并加上 --config-only 参数即可。

flutter build ios \

--local-engine-src-path=/Users/lxf/engine/src \

--local-engine=ios_release \

--local-engine-host=host_release_arm64 \

--config-only

以前使用本地引擎只需要 --local-engine 参数，现在要求结合 --local-engine-host 一块使用，这里附上相关 issue：github.com/flutter/flu… ，想了解的可以点开看看

三、最后

过程不难，麻烦的是拉源码和编译真的好慢，而且空间占用还大~

好了，本篇到此结束，感谢大家的支持，我们下次再见！ 👋

如果文章对您有所帮助, 请不吝点击关注一下我的微信公众号：FSA全栈行动, 这将是对我最大的激励. 公众号不仅有 iOS 技术，还有 Android，Flutter，Python 等文章, 可能有你想要了解的技能知识点哦~

本人写了五年的后台管理。每次面试前就会头疼，因为写的页面除了表单就是表格。抱怨过苦恼过也后悔过，但是站在现在的时间点回想以前，发现有很多事情可以做的更好，于是有了这篇文章。

写优雅的代码

一道面试题

大概两年以前，面试美团的时候，面试官让我写一道代码题，时间单位转换。具体的题目我忘记了。

原题目我没做过，但是我写的业务代码代码里有类似的单位转换，后端返回一个数字，单位是kb，而我要展示成 KB，MB 等形式。大概写一个工具函数（具体怎么写的忘记了，不过功能比这个复杂点）：

function formatSizeUnits(kb) {

    let units = ['KB', 'MB', 'GB', 'TB', 'PB'];

    let unitIndex = 0;



    while (kb >= 1024 && unitIndex < units.length - 1) {

        kb /= 1024;

        unitIndex++;

    }



    return `${kb.toFixed(2)} ${units[unitIndex]}`;

}

而在此之前，是一个后端同学写的代码（说起来，后台管理系统前端人力不够后端帮忙写好像是常规操作，后端总觉得写前端简单，而我只能说你们那代码写的，一言难尽……），如下：

function formatSizeUnits(kb) {

    var result = '';



    if (kb < 1024) {

        result = kb + ' KB';

    } else if (kb < 1024 * 1024) {

        result = (kb / 1024).toFixed(2) + ' MB';

    } else if (kb < 1024 * 1024 * 1024) {

        result = (kb / 1024 / 1024).toFixed(2) + ' GB';

    } else {

        result = (kb / 1024 / 1024 / 1024).toFixed(2) + ' TB';

    }



    return result;

}

虽然功能都一样，但是我写在面试的时候写了上面的代码得到了面试官的赞扬，也因此非常顺利的通过了面试。而如果我写成了下面的样子，估计不会有这种效果。

如何提升代码质量

想提升代码质量，最理想的是靠 code review ，但实际上这玩意在大多数公司根本就不存在。其次就只能多看看大佬们写的代码，但是一来后台管理本来就没太大难度很少有大佬，二来很多时候一个后台管理系统就一两个人负责。

还好现在有了各种 AI 工具，可以非常方便的优化自己的代码了。

还是上面的问题，看看 GPT 给的答案

// 提问：写一个工具函数，对文件大小的单位进行转换，加注释

// 回答：下面是一个JavaScript工具函数，它接受文件大小、初始单位、目标单位和小数位数，然后返回目标单位下的文件大小。



/**

 * 将文件大小从一个单位转换为另一个单位。

 *

 * @param {number} size 文件大小。

 * @param {string} fromUnit 初始单位（'B', 'KB', 'MB', 'GB', 'TB', 'PB', 'EB', 'ZB', 'YB'）。

 * @param {string} toUnit 目标单位（'B', 'KB', 'MB', 'GB', 'TB', 'PB', 'EB', 'ZB', 'YB'）。

 * @param {number} [decimalPoint=2] 结果保留的小数位数，默认为2。

 * @return {string} 转换后的文件大小，带单位。

 */

function convertFileSize(size, fromUnit, toUnit, decimalPoint = 2) {

  // 定义单位与字节之间的转换关系

  const units = ['B', 'KB', 'MB', 'GB', 'TB', 'PB', 'EB', 'ZB', 'YB'];

  // 获取初始单位和目标单位的索引

  const fromIndex = units.indexOf(fromUnit);

  const toIndex = units.indexOf(toUnit);



  // 如果单位不在列表中，抛出错误

  if (fromIndex === -1 || toIndex === -1) {

    throw new Error('Invalid units');

  }



  // 计算初始单位与目标单位之间的转换系数

  const exponent = toIndex - fromIndex;

  // 计算结果大小

  const resultSize = size / Math.pow(1024, exponent);



  // 返回格式化后的结果

  return parseFloat(resultSize.toFixed(decimalPoint)) + ' ' + toUnit;

}



// 示例使用

console.log(convertFileSize(1, 'GB', 'MB')); // 输出: 1024.00 MB

console.log(convertFileSize(1, 'MB', 'KB')); // 输出: 1024.00 KB

console.log(convertFileSize(1, 'KB', 'B'));  // 输出: 1024.00 B

console.log(convertFileSize(1, 'MB', 'GB', 5)); // 输出: 0.00098 GB

还能说什么，我只能说 NB！（经评论区提示，此段代码可能有问题，建议大家在使用AI工具时，重点是借鉴思路，直接使用代码需要谨慎~）

我现在每次写大段逻辑之后都习惯拿给 AI 看看，有什么更好的实现方式，或者用什么设计模式。AI 是非常低成本且高效提升代码质量的工具。

学会封装

一个功能用到了好多次，为什么不封装成组件？一个组件用到了好几个项目，为什么不单独写个npm包？差不多的项目创建了好几个，为什么不封装成脚手架？

你说，没时间，没必要，复制粘贴反而更快。

那你就完全没理解，这么做不一定是为了让工作更快完成，而是可以让你在年年终述职时更有话说（你就算写了一百个表单表格没有写一个脚手架更值得炫耀），如果不会写可以问问 AI。

而当你真正开始封装组件，开始写工具库了，你会发现你需要思考的确实比之前多了。

关注业务

对于前端业务重要吗？

相比于后端来说，前端一般不会太关注业务。就算出了问题大部分也是后端的问题。

但是就我找工作的经验，业务非常重要！

如果你做的工作很有技术含量，比如你在做低代码，你可以面试时讲一个小时的技术难点。但是你只是一个破写后台管理，你什么都没有的说。这个时候，了解业务就成为了你的亮点。

一场面试

还是拿真实的面试场景举例，当时前同事推我字节，也是我面试过N次的梦中情厂了，刚好那个组做的业务和我之前呆的组做的一模一样。

• 同事：“做的东西和咱们之前都是一样的，你随便走个过场就能过，我在前端组长面前都夸过你了！”


• 我：“好嘞！”

等到面试的时候：

• 前端ld：“你知道xxx吗？（业务名词）”


• 我：“我……”


• 前端ld：“那xxxx呢？（业务名词）”


• 我：“不……”


• 前端ld：“那xxxxx呢？？（业务名词）”


• 我：“造……”

然后我就挂了………………

如何了解业务

关注源码

说到源码， Vue，React 这些基本是每次必问，也有太多大佬们的总结我就不多说了。

除此之外，我想大家每次面试应该都会被问，你写了什么亮点的项目，困难的项目，你会说什么？哦，都是表单表格，都用 Element UI 实现的，没什么难度。那估计你面试也就到这里了。

那说什么，后台管理就这些啊？！

如果你用了 Element UI 你可以说写了什么自定义 Element UI 表单组件，Element UI 表单源码是什么原理，怎么通信的？用了 Axios 可以说 Axios 的原理，它的拦截器怎么实现的？用了编辑器 diff 那你知道 diff 算法是什么吗？用了 ECharts 那你知道他底层是用什么绘制的吗？用了 husky ？husky的原理是什么？用了Vite，它为什么快？是怎么打包的？写过插件吗？

可能有人觉得我离谱，事实上上面每一个问题都是我在面试中真实被问到的。当然，如果全部去了解，肯定不现实，每个人的精力有限，不可能每个用到的每个工具每个库都去了解原理，不过只要有一两个你去了解过，就可以在面试中引导面试官来问，要学会表现出你擅长的点。

至于怎么读源码？以前我不知道，现在嘛…… 为什么不问问神奇的 ChatGPT 呢？

讲一下 Axios 源码中，拦截器是怎么实现的？

Axios 的拦截器实现基于 Axios 的核心原理，即 Axios 实例是一个包含请求和响应拦截器堆栈的对象。当发出请求或接收响应时，Axios 会遍历这些拦截器，并按照添加的顺序执行请求拦截器，以及按照相反的顺序执行响应拦截器。

在 Axios 的源码中，拦截器是通过一个 AxiosInterceptorManager 实例来管理的，它维护了一个拦截器数组。每个拦截器都是一个包含 fulfilled 和 rejected 函数的对象。这两个函数分别对应于拦截器成功处理和拦截器处理出错的情况。

以下是 Axios 拦截器管理器的一个简化版本，展示了其核心实现思路：

class InterceptorManager {

  constructor() {

    this.handlers = []; // 存储拦截器的数组

  }



  use(fulfilled, rejected) {

    this.handlers.push({

      fulfilled: fulfilled,

      rejected: rejected

    });

    return this.handlers.length - 1; // 返回拦截器的ID

  }



  eject(id) {

    if (this.handlers[id]) {

      this.handlers[id] = null; // 移除拦截器

    }

  }



  forEach(fn) {

    this.handlers.forEach((h) => {

      if (h !== null) {

        fn(h);

      }

    });

  }

}

在发送请求或接收响应时，Axios 会创建一个 promise 链，并通过 forEach 方法将拦截器中的 fulfilled 和 rejected 函数添加到这个链中。这样，每个拦截器都可以对请求或响应进行处理，然后将结果传递到链的下一个拦截器，或者在出错时结束链的执行。

axios.interceptors.request.forEach(function unshiftRequestInterceptors(interceptor) {

  chain.unshift(interceptor.fulfilled, interceptor.rejected);

});



axios.interceptors.response.forEach(function pushResponseInterceptors(interceptor) {

  chain.push(interceptor.fulfilled, interceptor.rejected);

});

在 Axios 的完整实现中，这个拦截器机制被集成到了 Axios 的请求发送和响应处理流程中。通过这种方式，Axios 可以在发送请求之前和接收响应之后，但在用户定义的 .then 或 .catch 执行之前，插入自定义的逻辑。

请注意，这里提供的代码只是为了说明 Axios 拦截器的实现原理，并不是 Axios 源码的完整复制。如果你对 Axios 的拦截器实现细节感兴趣，建议查看 Axios 的官方 GitHub 仓库中的源码。

前端基建

当我们工作时间久了面试难免会遇到这些问题，前端工程化，前端监控，工作流，部署，性能等等。其实我们在工作中绝大部分时间都在写代码，对于这些不是所有人都有机会接触到，不过这些和所做的业务无关，是我们提升自己很好的一个思路。

技术选型

技术栈选 Vue 还是 React？Vue 选 Vue2 还是 Vue3？组件库选 ElementUI 还是 Ant Design？微前端有没有使用过？打包工具用 Vite 还是 Webpack？有那么多表单怎么实现的，有没有什么表单配置化方案，比如Formily？

对于我这种菜鸡，我这种只写简单的表单表格的人，这些都……无所谓……

不过为了应对面试我们还是需要了解下未选择技术栈的缺点，和已选择技术栈的优点（有点本末倒置…但是常规操作啦）

Vue 你可以说简单高效轻量级，面试必会问你为什么，你就开始说 Vue 的响应式系统，依赖收集等。

React 你可以说 JSX、Hooks 很灵活，那你必然要考虑 JSX 怎么编译， Hooks 实现方式等。

总体而言，对于技术选型，依赖于我们对所有可选项的理解，做选择可能很容易，给出合理的理由还是需要花费一些精力的。

开发规范

这个方面，在面试的时候我被问到的不多，我们可以在创建项目的时候，配置下 ESlint，stylelint， prettier， commitlint 等。

前端监控

干了这么多年前端，前端监控我是……一点没做过。

前端监控，简单来说就是我们在前端程序中记录一些信息并上报，一般是错误信息，来方便我们及时发现问题并解决问题。除此之外也会有性能监控，用户行为的监控（埋点）等。之前也听过有些团队分享前端监控，为了出现问题明确责任（方便甩锅）。

对于实现方案，无论使用第三方库还是自己实现，重要的都是理解实现原理。

对于错误监控，可以了解一下 Sentry，原理简单来说就是通过 window.onerror 和 window.addEventListener('unhandledrejection', ...) 去分别捕获同步和异步错误，然后通过错误信息和 sourceMap 来定位到源码。

对于性能监控，我们可以通过 window.performance、PerformanceObserver 等 API 收集页面性能相关的指标，除此之外，还需要关注接口的响应时间。

最后，收集到信息之后，还要考虑数据上报的方案，比如使用 navigator.sendBeacon 还是 Fetch、AJAX？是批量上报，实时上报，还是延迟上报？上报的数据格式等等。

CI/CD

持续集成（Continuous Integration, CI）和 持续部署（Continuous Deployment, CD），主要包括版本控制，代码合并，构建，单测，部署等一系列前端工作流。

场景的工作流有 Jenkins、 Gitlab CI 等。我们可以配置在合并代码时自动打包部署，在提交代码时自动构建并发布包等。

这块我了解不多，但感觉这些工具层面的东西，不太会涉及到原理，基本上就是使用的问题。还是需要自己亲自动手试一下，才能知道细节。比如在 Gitlab CI 中， Pipeline 、 Stage 和 Job 分别是什么，怎么配置，如何在不同环境配置不同工作流等。

了解技术动态

这个可能还是比较依赖信息收集能力，虽然我个人觉得很烦，但好像很多领导级别的面试很愿意问。

比如近几年很火的低代码，很多面试官都会问，你用过就问你细节，你没用过也会问你有什么设计思路。

还有最近的两年爆火的 AI，又或者 Vue React的最新功能，WebAssembly，还有一些新的打包工具 Vite Bun 什么的，还有鸿蒙开发……

虽然不可能学完每一项新技术，但是可以多去了解下。

总结

写了这么多，可能有人会问，如果能回到过去，你会怎么做。

啊，我只能说，说是一回事，做又是另一回事，事实上我并不希望回到过去去卷一遍，菜点没关系，快乐就好，一切都是最好的安排。

前言

如果你是一名前端开发，那么你多少有了解过requestAnimationFrame吧？如果没有也接着往下看，会有详细用法说明。

其实很多人会局限于把requestAnimationFrame应用于一些纯动画相关的需求上，但其实在前端很多业务场景下requestAnimationFrame都能用于性能优化，下面将细说一下requestAnimationFrame的具体用法和几种应用场景。

requestAnimationFrame作用与用法

requestAnimationFrame简述

MDN官方说法是这样的

基本示例

<script lang="ts" setup>

    function init() {

      console.log('您好，我是requestAnimationFrame');

    }

    requestAnimationFrame(init)

</script>

效果如下

但是例子上面是最基本的调用方式，并且只简单执行了一次，而对于动画是要一直执行的。

下面直接上图看看官方的文档对这个的说明，上面说具体用法应该要递归调用，而不是单次调用。

递归调用示例

<script lang="ts" setup>

    function init() {

      console.log('您好，递归调用requestAnimationFrame');

      requestAnimationFrame(init)

    }

    requestAnimationFrame(init)

</script>

执行动图效果如下

requestAnimationFrame会一直递归调用执行，并且调用的频率通常是与当前显示器的刷新率相匹配（这也是这个API核心优势），例如屏幕75hz就1秒执行75次。

而且如果使用的是定时器实现此功能是无法适应各种屏幕帧率的。

回调函数

requestAnimationFrame执行后的回调函数有且只会返回一个参数，并且返回的参数是一个毫秒数，这个参数所表示是的上一帧渲染的结束时间，直接看看下面代码示例与打印效果。

<script lang="ts" setup>

  function init(val) {

    console.log('您好，requestAnimationFrame回调:', val);

    requestAnimationFrame(init);

  }

  requestAnimationFrame(init);

</script>

注意： 如果我们同时调用了很多个requestAnimationFrame，那么他们会收到相同的时间戳，因为与屏幕的帧率相同所以并不会不一样。

终止执行

终止此API的执行，官方提供的方法是window.cancelAnimationFrame()，语法如下

ancelAnimationFrame(requestID)   

直接看示例更便于理解，用法非常类似定时器的clearTimeout()，直接把 requestAnimationFrame 返回值传给 cancelAnimationFrame() 即可终止执行。

<template>

  <div>

    <button @click="stop">停止</button>

  </div>

</template>

<script lang="ts" setup>

  let myReq;

  function init(val) {

    console.log('您好，requestAnimationFrame回调:', val);

    myReq = requestAnimationFrame(init);

  }

  requestAnimationFrame(init);



  function stop() {

    cancelAnimationFrame(myReq);

  }

</script>

requestAnimationFrame优势

1、动画更丝滑，不会出现卡顿

对比传统的setTimeout 和 setInterval动画会更流畅丝滑。

主要 原因 是由于运行的浏览器会监听显示器返回的VSync信号确保同步，收到信号后再开始新的渲染周期，因此做到了与浏览器绘制频率绝对一致。所以帧率会相当平稳，例如显示屏60hz，那么会固定1000/60ms刷新一次。

但如果使用的是setTimeout 和 setInterval来实现同样的动画效果，它们会受到事件队列宏任务、微任务影响会导致执行的优先级顺序有所差异，自然做不到与绘制同频。

所以使用setTimeout 和 setInterval不但无法自动匹配显示屏帧率，也无法做到完全固定的时间去刷新。

2、性能更好，切后台会暂停

当我们把使用了requestAnimationFrame的页面切换到后台运行时，requestAnimationFrame会暂停执行从而提高性能，切换回来后会马上提着执行。

效果如下动图，隐藏后停止运行，切换回来接着运行。

应用场景：常规动画

用一个很简单的示例：用requestAnimationFrame使一张图片动态也丝滑旋转，直接看示例代码和效果。

思路：首先在页面初始化时执行window.requestAnimationFrame(animate)使动画动起来，实现动画一直丝滑转运。在关闭页面时用window.cancelAnimationFrame(rafId)去终止执行。

<template>

  <div class="container">

    <div :style="imgStyle" class="earth"></div>

  </div>

</template>



<script setup>

  import { ref, onMounted, reactive, onUnmounted } from 'vue';



  const imgStyle = reactive({

    transform: 'rotate(0deg)',

  });



  let rafId = null;



  // 请求动画帧方法

  function animate(time) {

    const angle = (time % 10000) / 5; // 控制转的速度

    imgStyle.transform = `rotate(${angle}deg)`;



    rafId = window.requestAnimationFrame(animate);

  }



  // 开始动画

  onMounted(() => {

    rafId = window.requestAnimationFrame(animate);

  });



  // 卸载时生命周末停止动画

  onUnmounted(() => {

    if (rafId) {

      window.cancelAnimationFrame(rafId);

    }

  });

</script>



<style scoped>

  body {

    box-sizing: border-box;

    background-color: #ccc;

    height: 100vh;

    display: flex;

    justify-content: center;

    align-items: center;

  }



  .container {

    position: relative;

    height: 100%;

    width: 100%;

    display: flex;

    flex-direction: column;

    align-items: center;

    justify-content: center;

  }



  .earth {

    height: 100px;

    width: 100px;

    background-size: cover;

    border-radius: 50%;

    background-image: url('@/assets/images/about_advantage_3.png'); /* 替换为实际的路径 */

  }

</style>

看看动图效果

应用场景：滚动加载

在滚动事件中用requestAnimationFrame去加载渲染数据使混动效果更加丝滑。主要好久有几个

• 提高性能: 添加requestAnimationFrame之后会在下一帧渲染之前执行，而不是每次在滚动事件触发的时候就立即执行。这可以减少大量不必要的计算，提高性能。


• 用户体验更好：确保在绘制下一帧时再执行，使帧率与显示屏相同，视觉上会更丝滑。

代码示例和效果如下。

<template>

  <div class="container" ref="scrollRef">

    <div v-for="(item, index) in items" :key="index" class="item">

      {{ item }}

    </div>

    <div v-if="loading" class="loading">数据加载中...</div>

  </div>

</template>



<script setup lang="ts">

import { ref, onMounted, onUnmounted } from 'vue';



const loading = ref(false);

let rafId: number | null = null;

// 数据列表

const items = ref<string[]>(Array.from({ length: 50 }, (_, i) => `Test ${i + 1}`));



// 滚动容器

const scrollRef = ref<HTMLElement | null>(null);



// 模拟一个异步加载数据效果

const moreData = () => {

  return new Promise<void>((resolve) => {

    setTimeout(() => {

      const newItems = Array.from({ length: 50 }, (_, i) => `Test ${items.value.length + i + 1}`);

      items.value.push(...newItems);

      resolve();

    }, 1000);

  });

};



// 检查是否需要加载更多数据

const checkScrollPosition = () => {

  if (loading.value) return;



  const container = scrollRef.value;

  if (!container) return;



  const scrollTop = container.scrollTop;

  const clientHeight = container.clientHeight;

  const scrollHeight = container.scrollHeight;



  if (scrollHeight - scrollTop - clientHeight <= 100) {

    startLoading();

  }

};



// 加载数据

const startLoading = async () => {

  loading.value = true;

  await moreData();

  loading.value = false;

};



// 监听滚动事件

const handleScroll = () => {

  console.log('滚动事件触发啦');

  if (rafId !== null) {

    window.cancelAnimationFrame(rafId);

  }

  rafId = window.requestAnimationFrame(checkScrollPosition);

};



// 添加滚动事件监听器

onMounted(() => {

  if (scrollRef.value) {

    scrollRef.value.addEventListener('scroll', handleScroll);

  }

});



// 移除相关事件

onUnmounted(() => {

  if (rafId !== null) {

    window.cancelAnimationFrame(rafId);

  }

  if (scrollRef.value) {

    scrollRef.value.removeEventListener('scroll', handleScroll);

  }

});

</script>



<style scoped>

.container {

  padding: 20px;

  max-width: 800px;

  overflow-y: auto;

  margin: 0 auto;

  height: 600px; 

}



.item {

  border-bottom: 1px solid #ccc;

  padding: 10px;

}



.loading {

  padding: 10px;

  color: #999;

  text-align: center;

}

</style>

看看下面动图效果

小结

通过代码示例配合动图讲解后，再通过两个简单的事例可能大家会发现，只要在页面需要运动的地方其实都可以用到 requestAnimationFrame 使效果变的更加丝滑。

除了上面两个小示例其它非常多地方都可以用到requestAnimationFrame去优化性能，比较常见的例如游戏开发、各种动画效果和动态变化的布局等等。

文章就写到这啦，如果文章写的哪里不对或者有什么建议欢迎指出。

一次代码CR引发的困惑

const asyncErrorThrow = () => {

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

    // 业务代码...

    // 假设这里抛出了错误

    throw new Error('抛出错误');

    // 业务代码...

  })

}

const testFun = async () => {

  await asyncErrorThrow();

  console.log("async 函数中的后续流程"); // 不会执行

}

testFun();

在 testFun 函数中，抛出错误后，await 函数中后续流程不会执行。

仔细回想一下，在我的前端日常开发中，对于错误捕获，还基本停留在使用 Promise时用 catch 捕获一下 Promise 中抛出的错误或者 reject，或者最基本的，在使用 JSON.parse、JSON.stringfy等容易出错的方法中，使用 try..catch... 方法捕获一下可能出现的错误。

后来，这个同学将代码改成了：

const asyncErrorThrow = () => {

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

    // 业务代码...

    throw new Error('抛出错误');

    // 业务代码...

  })

}

const testFun = async () => {

  try {

    await asyncErrorThrow();

    console.log("async 函数中的后续流程"); // 不会执行

  } catch (error) {

    console.log("若错误发生 async 函数中的后续流程"); // 会执行

  } 

}

testFun();

而这次不同的是，这段修改后的代码中使用了 try...catch...来捕获 async...await... 函数中的错误，这着实让我有些困惑，让我来写的话，我可能会在 await 函数的后面增加一个 catch：await asyncErrorThrow().catch(error => {})。因为我之前已经对 try..catch 只能捕获发生在当前执行上下文的错误（或者简单理解成同步代码的错误）有了一定的认知，但是 async...await... 其实还是异步的代码，只不过用的是同步的写法，为啥用在这里就可以捕获到错误了呢？在查阅了相当多的资料之后，才清楚了其中的一些原理。

Promise 中的错误

• 待定（pending）：初始状态，既没有被兑现，也没有被拒绝。


• 已兑现（fulfilled）：意味着操作成功完成。


• 已拒绝（rejected）：意味着操作失败。

当一个 Promise 被 reject 时，该 Promise 会变为 rejected 状态，控制权将移交至最近的 rejection 处理程序。最常见的 rejection 处理程序就是 catch handler或者 then 函数的第二个回调函数。而如果在 Promise 中抛出了一个错误。这个 Promise 会直接变成 rejected 状态，控制权移交至最近的 error 处理程序。

const function myExecutorFunc = () => {

  // 同步代码

  throw new Error();

};

new Promise(myExecutorFunc);

Promise 的构造函数需要传入的 Executor 函数参数，实际上是一段同步代码。在我们 new 一个新的 Promise 时，这个 Executor 就会立即被塞入到当前的执行上下文栈中进行执行。但是，在 Executor 中 throw 出的错误，并不会被外层的 try...catch 捕获到。

const myExecutorFunc = () => {

  // 同步代码

  throw new Error();

};

try {

  new Promise(myExecutorFunc);

} catch (error) {

  console.log('不会执行: ', error);

}

console.log('会执行的'); // 打印

其原因是因为，在 Executor 函数执行的过程中，实际上有一个隐藏的机制，当同步抛出错误时，相当于执行了 reject 回调，让该 Promise 进入 rejected 状态。而错误不会影响到外层的代码执行。

const myExecutorFunc = () => {

  throw new Error();

  // 等同于

  reject(new Error());

};

new Promise(myExecutorFunc);

console.log('会执行的'); // 打印

同理 then 回调函数也是这样的，抛出的错误同样会变成 reject。

在一个普通脚本执行中，我们知道抛出一个错误，如果没有被捕获掉，会影响到后续代码的执行，而在 Promise 中，这个错误不会影响到外部代码的执行。对于 Promise 没有被捕获的错误，我们可以通过特定的事件处理函数来观察到。

new Promise(function() {

  throw new Error("");

}); // 没有用来处理 error 的 catch

// Web 标准实现

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

  console.log(event);

  // 可以在这里采取其他措施，如日志记录或应用程序关闭

});

// Node 下的实现

process.on('unhandledRejection', (event) => {

  console.log(event);

  // 可以在这里采取其他措施，如日志记录或应用程序关闭

});

Promise 是这样实现的，我们可以想一想为什么要这样实现。我看到一个比较好的回答是这个：

传送门。我也比较赞成他的说法，我觉得，Promise 的诞生是为了解决异步函数过多而形成的回调地狱，使用了微任务的底层机制来实现异步链式调用。理论上是可以将同步的错误向上冒泡抛出然后用 try...catch... 接住的，异步的一些错误用 catch handler 统一处理，但是这样做的话会使得 Promise 的错误捕获使用起来不够直观，如果同步的错误也进行 reject 的话，实际上我们处理错误的方式就可以统一成 Promise catch handler 了，这样其实更直观也更容易让开发者理解和编写代码。

async await 的问题

const asyncErrorThrow = () => {

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

    // 业务代码...

    throw new Error('抛出错误');

    // 业务代码...

  })

}

const testFun = async () => {

  try {

    await asyncErrorThrow();

    console.log("async 函数中的后续流程"); // 不会执行

  } catch (error) {

    console.log("若错误发生 async 函数中的后续流程"); // 会执行

  } 

}

testFun();

我思考了很久，最后还是从黄玄大佬的知乎回答中窥见的一部分原理。

这...难道就是浏览器底层帮我们处理的事儿吗，不然也没法解释了。唯一能够解释的事就是，async await 原本就是为了让开发者使用同步的写法编写异步代码，目的是消除过多的 Promise 调用链，我们在使用 async await 时，最好就是不使用 .catch 来捕获错误了，而直接能使用同步的 try...catch... 语法来捕获错误。即使 .catch 也能做同样的事情。只是说，代码编写风格统一性的问题让我们原本能之间用同步语法捕获的错误，就不需要使用 .catch 链式调用了，否则代码风格看起来会有点“异类”。

这就是为什么 async MDN 中会有这样一句解释：

参考文档：

《使用Promise进行错误治理》- zh.javascript.info/promise-err…

《为什么try catch能捕捉 await 后 promise 错误？ 和执行栈有关系吗？》http://www.zhihu.com/question/52…

大家好，我是CodeQi！  一位热衷于技术分享的码仔。

在日常的开发中，很多人习惯于使用 if-else 语句来处理各种条件。但你有没有想过，层层嵌套的条件判断，可能会让代码变得难以维护且难以阅读？今天，我想分享一个让代码更清晰易读的技巧，那就是——return。✨

if-else 真的有必要吗？

初学编程时，我们都习惯通过 if-else 语句来处理分支逻辑。比如判断一个用户是否活跃，是否有折扣，代码通常会写成这样：

function getDiscountMessage(user) {

  if (user.isActive) {

    if (user.hasDiscount) {

      return `折扣已应用于 ${user.name}！`;

    } else {

      return `${user.name} 不符合折扣条件。`;

    }

  } else {

    return `用户 ${user.name} 已被停用。`;

  }

}

你看，这段代码嵌套了多个 if-else 语句。如果我们继续在这种风格的代码上添加更多条件判断，会变得更加难以阅读和维护。过多的嵌套让人一眼难以理清逻辑。更严重的是，随着代码量增多，容易导致出错。

return：清晰与高效的代码编写方式

所谓的提前return，就是在遇到异常情况或不符合条件时，立即返回并结束函数。通过提前处理错误情况或边界情况，我们可以把代码的“理想情况”留到最后处理。这种写法可以让代码更清晰，逻辑更加直接。🎯

示例：用return优化代码

来看一看如何用return来重写上面的代码：

function getDiscountMessage(user) {

  if (!user.isActive) {

    return `用户 ${user.name} 已被停用。`;

  }



  if (!user.hasDiscount) {

    return `${user.name} 不符合折扣条件。`;

  }



  // 理想情况：用户活跃且符合折扣条件

  return `折扣已应用于 ${user.name}！`;

}

🌟 优势

return vs if-else：一个真实场景

假设我们有一个需要检查多个条件的函数，validateOrder，要确保订单状态有效、用户有权限、库存足够等情况：

function validateOrder(order) {

  if (!order.isValid) {

    return `订单无效。`;

  }



  if (!order.userHasPermission) {

    return `用户无权限。`;

  }



  if (!order.hasStock) {

    return `库存不足。`;

  }



  // 理想情况：订单有效，用户有权限，库存足够

  return `订单已成功验证！`;

}

通过这种方式，我们将所有不符合条件的情况都提前处理掉，将主逻辑留到最后一行。这不仅让代码更易读，而且可以提高代码的运行效率，因为无须进入嵌套的条件分支。🎉

何时使用return

虽然提前return是优化代码的好方式，但并不是所有情况下都适用。以下是一些适用场景：

• 多条件判断：需要检查多个条件时，尤其是多个边界条件。


• 简单条件过滤：对于不符合条件的情况可以快速返回，避免执行复杂逻辑。


• 确保主要逻辑代码始终位于底部：这样可以减少逻辑处理的复杂性。

结语

当我们写代码时，保持代码简洁明了是一项重要的原则。通过采用提前return，我们可以减少嵌套层次，避免过度依赖 if-else，让代码更直观、易维护。如果你还没有使用return，不妨从现在开始尝试一下！😎

下次写代码时，记得问自己一句：“这个 if-else 可以用return替换吗？ ”

让我们一起追求清晰、优雅的代码！Happy Coding! 💻

前言

由于谷歌 flutter 团队裁员，导致维护更新满足不了需求，传闻 flutter 团队不足50人，很多跨端的支持以及现有的问题都无法解决，flutter 社区foundation不满足于现有的开发进度，fock flutter维护分支Flock, 貌似不少公司组织已经在这样做了，很多问题也不能怪flutter, 比如最近发的这个问题。

问题

flutter freeze卡死的问题相信很多开发者都遇到过, 最近遇到iOS侧滑返回的导致freeze的问题，很早就发现这个问题，当时的解决方案是在首页禁止侧滑，就是导航栈只有一个页面的时禁用手势

if (self.navigationController.viewControllers.count == 1) {

    self.navigationController.interactivePopGestureRecognizer.enabled = NO;

}

此方案可以将卡死问题很大概率的降低，但是仍然会出现卡死, 可以规避但没找到根本原因

分析

最开始以为是flutter手势和iOS 系统返回手势冲突导致，app 存在一些侧滑的轮播图，经过对比发现有没有轮播图或者flutter 手势都会出现卡死。

问题可能出现在iOS 原生侧,经过尝试发现问题所在，复现代码如下

首页实现手势比如PanGuesture

UIPanGestureRecognizer *panGesture = [[UIPanGestureRecognizer alloc] initWithTarget:**self** action: **@selector**(handlePan:)];

[redView addGestureRecognizer:panGesture];

push 跳转到二级页面，二级页面对重置了导航栏的返回手势的delegate

self.navigationController.interactivePopGestureRecognizer.delegate = nil;

原因：
重置了导航栏的PopGestureRecognizer的delegate，向当前全局的侧滑返回代理回调失效，导致策划返回出现问题，禁用手势不可以讲导航栏的返回手势的delete 置为nil

Flutter为何侧滑可出现卡死，通过分析flutter的源码就很容易知道原因

结论

flutterViewController也实现了手势操作，所以使用依赖原生的flutter出现了这个问题，跳转到其他页面，将PopGestureRecognizer 置为nil, 就出现这个问题

Flutter:这真不是我的锅

感想

从20年开始接触Flutter 也有三四年时间了，Flutter的应用范围也越来越广，但是大厂对flutter的接受度还是不高，要不要继续坚持搞Flutter,作为开发未来将何去何从

什么是灰度发布

在互联网领域，灰度发布是产品质量保障的重要一环，它可以让某次更新的产品，以一种平滑，逐步扩大的方式呈现给用户，在此过程中，产品和技术团队可以对功能进行验证，收集用户反馈，不断优化，从而减少线上问题的影响范围，完善产品功能。

在前端领域，APP和小程序天生就具有灰度的能力，一般基于发布平台来控制。但 H5 却缺少这种天生能力，而且 H5 一旦发布就会影响所有用户，更加需要一套灰度系统，来保证产品的稳定性。

灰度发布的本质

既然要让部分用户先使用新功能，就需要做好两件事情，这也是灰度的本质：

那么想要实现灰度发布有哪些方案呢？

可选的灰度方案

Nginx+lua+redis

通过使用 Nginx 的反向代理特性，我们可以根据请求的特定属性（例如ip、请求头、cookie）等有选择性的将请求路由到全量或灰度版本。

同时在 Nginx 中嵌入 Lua 脚本，负责根据预定义的灰度发布策略处理请求，Lua 脚本可以从 Redis 中获取灰度配置。从而确定哪些用户可以访问新版本，那些用户应该可以访问旧版本。

Redis 用于存储灰度发布的配置数据。

通过这种方式可以实现基于 Ngnix 的灰度发布，但这种方式并不适合我们，为什么呢？

因为我们的C端H5页面连同HTML文件都是直接投放在 CDN 上，这就意味着我们没有中转服务层，无法使用第一套 Nginx 的方案，而且使用 Nginx 也会响应降低页面加载速度，虽然可能很轻微，但却是对所有用户都会有影响。

采用 Nginx 进行中转：

不采用 Nginx 中转：

如上两张图，可以很明显的看到，如果采用 Nginx 来作为中转并进行分流控制，将导致我们的 CDN 优势失效，所有的流量都可能回到上海的机房，再流转到上海的 CDN，这显然不是我们想看到的。

这也是我们放弃 Nginx+lua+redis 方案的原因。

基于 SSR 做灰度

如果我们的前端页面是通过服务端来进行渲染，可以把灰度控制继承在服务端渲染中，基于不同的用户放回不同的HTML，这样也就可以做到灰度发布。

不过这需要有一套完善的 SSR系统，对于访问量大的产品，维持系统稳定性的难度远大于实现 SSR 本身的技术难度。由于我们是前后端分离，并且没有基于 Node 高可用的运维团队和经验，所以这个方案也就放弃了。

APP拦截灰度

基于APP的方案，是在用户点击H5资源位，创建webview时，拉取灰度配置，如果当前页面有灰度，则拉取灰度配置，判断是否命中灰度，如果命中，替换H5链接即可。

看过我其他文章的朋友，应该有了解到我们针对H5秒开有一套配置下发到APP，那么灰度配置，也可以集成到原有配置中，一并下发给APP，这套方案相对而言也比较简单，但是却有如下问题。

所以最后该方案也被排除。

纯前端方案

方案概览

基于如上的一些原因，于是我们采用了一套纯前端的方案，来解决灰度发布问题，虽然这套方案也有一点缺点。前面我们提到灰度发布的本质，其实包含两个方面，一是版本控制，二是分流控制。

版本控制比较好做，我们把全量的HTML代码发布到 index.html 文件，把灰度的HTML代码发布到 gray.html 文件，这样就做到了版本控制。

分流控制，可以被拆分为两部分，一部分只管获取配置、判定是否命中灰度并入在本地，另一部只管读取结果并执行跳转，这样整个系统就解耦了。

方案大体思路是：

流程图：

时序图如下：

灰度版本控制

对于版本控制，我们通过提供了一个 webpack 插件集成到构建流程中，在构建时生成不同文件名的 html 文件。

通过构建命令参数，来区分各种发布情况

npm run build your_project_name -- --gray=open  

# --gray 的值  

# --gray=close 不打开灰度，默认值  

# --gray=open 打开灰度  

# --gray=full 灰度全量  

# --gray=unpublish 撤销灰度

可以分为如下情况：

正式发布

构建时生成：

• index.html 全量页面


• index_backup.html 全量备份页面（用来做回归）

灰度发布

构建时生成：

• gray.html 灰度页面


• gray_backup.html 灰度备份页（用来在全量后替换 index_backup.html）

同时下载 index.html ，注入灰度重定向控制JS。

重定向控制代码如下：

// 标记是否打开灰度  

window.__GRAY_SWITCH__ = 1   

let graySwitchName = 'gray_switch_';  

// 获取去除html后的pathname  

const pathname = window.location.pathname.split('/').slice(0, -1).join('/');   

graySwitchName = graySwitchName + pathname  

const graySwitch = localStorage.getItem(graySwitchName)  

if (graySwitch === '1') {  

    const grayUrl = window.location.href.replace('index.html', '_gray.html')  

    if(window.history.replaceState){  

        // 安卓 app 使用 location.replace 无效  

        window.history.replaceState(null, document.title, grayUrl);  

    }else{  

        window.location.replace(grayUrl);  

    }  

} 

修改输出的 HTML 文件名，是通过编写 webpack 的自定义插件来完成。

原理是通过 compiler.hooks.afterEmit.tapAsync 钩子函数，再 “输出” 阶段，对文件名进行修改。

撤销灰度

从云端下载 index_backup.html 重命名为 index.html 放在打包目录，之后再由发布系统上传。

全量发布

从云端下载 gray.html 和 gray_backup.html，重命名为 index.html 和 index_backup.html，发布后就会替换原有的全量HTML。

灰度分流控制

分流的重点是如何判断哪些用户能命中灰度。每个项目划分人员的策略都可能不同，比如C端页面更倾向于按useID随机划分。而B端拣货、配送等业务线，更需要按门店来进行划分，这样可以做到同门店员工体验一致，便于管理。所以这块这块必须要足够的灵活性。

我们这里采取了两种方式：

第一种是基于接口来做分流控制：把用户信息传给服务端，接口通过配置的灰度规则，计算是否命中，并返回前端。前端只管把结果存入本地。

第二种是把计算逻辑都放在前端，比较适合C端项目，因为C端项目大部分场景都是随机划分灰度用户。

灰度分流计算的JS代码是在用户每次打开后，静默运行，所以需要引入到业务代码中。

引入的代码如下：

import grayManager from '@cherry/grayManager'  

import { getMemberId } from '../utils/index'  

  

// 伪代码，说明GrayOptions 的类型  

interface GrayOptions {  

    // 灰度比例控制 支持固定值和数组阶梯灰度，配置grayScale 后，grayComputeFn无效  

    grayScale: number | [number]  

    // 自定义灰度方法，在内可以请求接口等  

    grayCompute: () => (() => Promise<boolean>) | boolean  

    // 获取维护标识，比如以 shopId 为灰度标识，该函数就返回当前用户的 shopId  

    getGaryData: () => ()=> Promise<string>,  

    // 配置灰度白名单，白名单内的用户都会命中灰度  

    whiteData: string[]  

}  

  

// 初始化灰度计算逻辑  

grayManagerInit({  

    grayScale: 10,  

    whiteData: ['123', '456']  

})

前端计算分流

随机百分比

多数项目，我们一般使用的策略是随机，比如设置10%的用户命中灰度。

我们可以通过生成随机数来判断是否命中灰度，具体步骤如下：

这样可以得到一个近似 10% 比例的灰度用户数。

基于门店和城市分流

如果想基于门店或城市分流，我们只需要配置两个参数， 一是如何获取门店和城市ID

另一个是需要灰度的门店和城市ID

import grayManager from '@cherry/grayManager'  

import { getShopId } from '../utils/index'  

  

grayManagerInit({  

    getGaryData: () => {  

        return await getCityId()  

    },  

    whiteData: ['123', '456']  

})

可以通过 grayScale 配置数组来实现，起始时间为打灰度包构建的时间，我们会把构建时间注入到 HTML 中。

其他注意项

开头讲过，这套方案有一点缺点。可能大家也会发现，灰度时用户需要先进入打 HTML，执行 head 中注入的重定向控制JS，对命中灰度的用户再次跳转到 gray.html。

这样其实带来了两个问题：一是对灰度用户来说经过了两个HTML，白屏的时间会更长。二是灰度用户访问的URL变化了，如果此时用户把页面分享出去，被分享用户将直接打开灰度页面。

对于第一条，全量用户是不会被影响，只有灰度用户才会白屏更久，我们目前测试白屏的时长还能接受。

对于第二条，我们最初是系统通过 Object.defineProperty 来拦截 对 window.location.pathname 的获取，返回 index.html。但window.location.pathname 是一个只读属性不可拦截。

最后只能提供统一的方法，来获取 pathname。

结语

以上就是我们的灰度核心方案，整个方案会比较简单，几乎不依赖外部部门。无论是对于H5还是pcWeb，亦或是不同的容器，都无依赖，各个业务线都可以平滑使用。

二、处理风场数据

grib这个数据格式打不开，看不懂，需要转换成json，有位大牛A写了个java的grib处理工具（grib2json)，然而我用maven打包失败了，然后发现有另一位大牛B封装了大牛A的jar包成node脚本，正好给前端开发者使用。

pnpm add -D @weacast/grib2json

2. 执行脚本，将grib转换成json

使用说明

Usage: grib2json (or node bin.js) [options] 

  -V, --version                   输出版本号

  -d, --data                       输出GRIB记录数据

  -c, --compact                    压缩json

  -fc, --filter.category    选择类目值

  -fs, --filter.surface     选择表面类型

  -fp, --filter.parameter   选择参数值

  -fv, --filter.value       选择表面值

  -n, --names                      打印数字代码的名称

  -o, --output               输出文件名

  -p, --precision       使用小数点后几位数的精度（默认值：-1）

  -v, --verbose                    启用stdout日志记录

  -bs, --bufferSize         stdout或stderr上允许的最大数据量（以字节为单位）

  -h, --help                       使用帮助

pnpm exec  grib2json -c --names --data --fp 2 --fs 103 --fv 10.0 -o output.json D:/code/wind/pgbf2024103000.01.2024103000.grb2

注意：

• --fs 103表面类型103（地面以上指定高度）
• --fv 10.0 距离GRIB2文件10.0米的表面值
• --fp 2 将参数2（U-component_of_wind）的记录输出到stdout
• 需要转换的grib文件放在最后，文件路径要用完整的路径名称

3. 数据格式说明

{

       "header":{

              //数据更新时间

           "refTime":"2024-10-30T00:00:00.000Z",

           

           "parameterCategory":2,//类目号，2表示风力

           "parameterCategoryName":"Momentum",

           "parameterNumber":2,//2表示u,3表示v

           "parameterNumberName":"U-component_of_wind",            

           "numberPoints":65160,//点数量            

           "nx":360,//横向栅格数量

           "ny":181, //纵向栅格数量

           "lo1":0.0,//开始经度

           "la1":-90.0,//开始纬度

           "lo2":359.0,//结束经度

           "la2":90.0,//结束纬度

           "dx":1.0,//横向步长

           "dy":1.0//纵向补偿

       },

       "data":[//方向数据，u数据，要搭配另一个v的数据使用

           -7.8,

           -7.9,

           ]

        }

U表示横向风速，V表示纵向风速，UV的正负值表示风向

4. output.json有2.25MB大，数据里面除了uv方向的数据，还包含了其他的数据，我们只需要有用的一个header和uv数据即可，可以用node处理一下,得到一个header信息数据info.json和风向数据wind.json

const fs = require('fs');

const output = require('./output.json');

let uData = [];

let vData = [];

let header = {};

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

 if (output[i].header.parameterNumber === 2) {//u的数据集

   uData = output[i].data;

   header = output[i].header;

 } else if (output[i].header.parameterNumber === 3) {//v的数据集

   vData = output[i].data;

 }

}



const len = uData.length;

const list = [];

const info = {

 minU: Number.MAX_SAFE_INTEGER,

 maxU: Number.MIN_SAFE_INTEGER,

 minV: Number.MAX_SAFE_INTEGER,

 maxV: Number.MIN_SAFE_INTEGER,

 ...header

};

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

//uv数据组合

 list.push([uData[i], vData[i]]);

 //计算最大最小边界值

 info.minU = Math.min(uData[i], info.minU);

 info.maxU = Math.max(uData[i], info.maxU);

 info.minV = Math.min(vData[i], info.minV);

 info.maxV = Math.max(vData[i], info.maxV);

}



fs.writeFileSync('./wind.json', JSON.stringify(list));

fs.writeFileSync('./info.json', JSON.stringify(info));

三、绘制2D风场图

重头戏来了！瞪大你的眼睛（0 v 0），看好了！

1. 创建风场网格

nx和ny对应横向纵向网格数量，然后uv数据按照nx行，ny列组装添加到二维数组里面就是网格了。

 this.grid = [];

    let index = 0;

for (let j = 0; j < header.ny; j++) {

        const row = [];

        for (let i = 0; i < header.nx; i++) {

          const item = this.data[index++];

          row.push(item);

        }

        this.grid.push(row);

      }

2. 获取点xy对应的风向uv

根据风场网格获取该xy先在应的风向uv,点xy可能不是整数，那么这时候需要使用双线性插值(根据临近的周围四个点计算出插值)算出对应的风向uv。

• 根据xy获取风向uv

 getUV(x, y) {

    let x0 = Math.floor(x),

      y0 = Math.floor(y);

    //正好落在网格里

    if (x0 === x && y0 === y) return this.getGrid(x, y);



    let x1 = x0 + 1;

    let y1 = y0 + 1;



    //临近四周的点

    let g00 = this.getGrid(x0, y0),

      g10 = this.getGrid(x1, y0),

      g01 = this.getGrid(x0, y1),

      g11 = this.getGrid(x1, y1);

    return this.bilinearInterpolation(x - x0, y - y0, g00, g10, g01, g11);

  }

• 不落在整数网格里面的采用双线性插值计算出风向uv

  /**双线性插值

   * g00, g10, g01, g11对应临近可映射的四个点

   * x为当前点与最近点x坐标差

   * y为当前点与最近点y坐标差

   * ***/

 bilinearInterpolation(x, y, g00, g10, g01, g11) {

    let rx = 1 - x;

    let ry = 1 - y;

    let a = rx * ry,

      b = x * ry,

      c = rx * y,

      d = x * y;

    let u = g00[0] * a + g10[0] * b + g01[0] * c + g11[0] * d;

    let v = g00[1] * a + g10[1] * b + g01[1] * c + g11[1] * d;

    return [u, v];

  }

 

• 获取网格数值，需规整超出的边界值

getGrid(x, y) {

    const h = this.header;

    if (x < 0) {

      x = 0;

    } else if (x > h.nx - 1) {

      x = h.nx - 1;

    }



    if (y < 0) {

      y = 0;

    } else if (y > h.ny - 1) {

      y = h.ny - 1;

    }



    return this.grid[y][x];

  }

3. 创建随机点

 createRandParticle() {

 //必须在风场网格范围内才能获取到风向uv

    const x = Math.random() * this.header.nx;

    const y = Math.random() * this.header.ny;



    const uv = this.getUV(x, y);



    return {

      //起点位置

      x,

      y,

      //终点位置=当前位置加上风向偏移

      tx: x + this.speed * uv[0],

      ty: y + this.speed * uv[1],

      //生命周期，将生命周期归零的时候重新设置起点坐标

      age: Math.floor(Math.random() * this.maxAge)

    };

  }

  //重新设置随机点

    setParticleRand(p) {

    const newp = this.createRandParticle();

    for (let k in p) {

      p[k] = newp[k];

    }

  }

• 生成随机点

 

    this.particles = [];

    for (let i = 0; i < this.particlesCount; i++) {

      this.particles.push(this.createRandParticle());

    }

4. 绘制风场图

canvas绘制风场即用线段的起点和终点跟随着风向不断运动形成风场图。

• 设置canvas

//缓存canvas context之前的合成操作类型

      const pre = ctx.globalCompositeOperation;

      //'destination-in'仅保留现有画布内容和新形状重叠的部分。其他的都是透明的。

      ctx.globalCompositeOperation = 'destination-in';

      //之前绘制的保留重叠部分

      ctx.globalAlpha = 0.5;

      ctx.fillRect(0, 0, this.canvas.width, this.canvas.height);

      //还原合成操作类型

      ctx.globalCompositeOperation = pre;

      

      

      //设置线的全局透明度

      ctx.globalAlpha = 0.8;

注意：cxt.fillRect本来清空之前的画布内容，但采用了globalCompositeOperation='destination-in'和globalAlpha=0.5的透明度作为重叠标准，重叠部分以0.5的透明度重新绘制并保留下来，通过这种方式，可以形成很多连续点的感觉，如果设置为1的透明度则会全部保留，并且不停叠加，等价于没有清空画布的状态。

• 遍历随机点更新位置

      this.particles.forEach((p) => {

        if (p.age <= 0) {

          //生命周期耗尽重新设置随机点值

          this.setParticleRand(p);

        } else {

          if (!this.inBound(p.x, p.y)) {

            //画出范围外重新设置随机点值

            this.setParticleRand(p);

          } else {

            //根据下一个点的风向，计算出下一个点的位置

            const uv = this.getUV(p.tx, p.ty);

            const nextx = p.tx + this.speed * uv[0];

            const nexty = p.ty + this.speed * uv[1];

            //将起点换成之前的终点

            p.x = p.tx;

            p.y = p.ty;

            //终点设置成计算出的下一个点

            p.tx = nextx;

            p.ty = nexty;

            //生命周期递减

            p.age--;

          }

        }

        //起始点和终点转换成显示的画布大小

        const start = this.getCanvasPos(p.x, p.y);

        const end = this.getCanvasPos(p.tx, p.ty);

        //渐变跟随线段的方向

        const gradient = ctx.createLinearGradient(start[0], start[1], end[0], end[1]);

        for (let k in this.color) {

          gradient.addColorStop(+k, this.color[k]);

        }

        //绘制线段

        ctx.beginPath();

        ctx.strokeStyle = gradient;

        ctx.moveTo(start[0], start[1]);

        ctx.lineTo(end[0], end[1]);

        ctx.stroke();

      });

5. 使用封装类绘制

async function main() {

    //风场信息数据

        const header = await getData('./info.json');

        //风场uv方向数据

        const data = await getData('./wind.json');



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

        canvas.width = 1200;

        canvas.height = 600;         

        const cw = new Windy({

          header,

          data,

          canvas,

          //运动速度

          speed: 0.1,

          //随机点数量

          particlesCount: 1000,

          //生命周期

          maxAge: 120,

          //1秒更新次数

          frame: 10,

          //线渐变

          color: {

            0: 'rgba(255,255,0,0)',

            1: '#ffff00'

          },

          //线宽度

          lineWidth: 3 

        });

      }

效果非常好，线段顺着风向在运动！

• 上面的线段因为一段段渐变呈现出一个个小蝌蚪的样子，然而利用叠加保留的效果，可以自动将线段绘制渐变色。只需要改变一下绘制顺序就行

  

        //线段绘制开始

        ctx.beginPath();

        //设置纯颜色

        ctx.strokeStyle = this.color;

        //遍历随机点更新位置

        this.particles.forEach((p) => {

           //同上面更新随机点的位置

           //...

           

          //起始点和终点转换成显示的画布大小

          const start = this.getCanvasPos(p.x, p.y);

          const end = this.getCanvasPos(p.tx, p.ty);

          //通过moveTo和lineTo绘制多个线段

          ctx.moveTo(start[0], start[1]);

          ctx.lineTo(end[0], end[1]);

        });

        //最终统一绘制线段

        ctx.stroke();

这样看上去流动线段连续性更强，不那么零散了！

6. 利用图片信息存储数据的优化

wind.json风场uv方向数据有739KB接近1MB，这着实有点大，要是网络稍微有点卡都会很影响首屏加载时间！从webgl-wind中我看到了用Canvas的ImageData中颜色来存储与解析数值,这操作太优秀了！

实现逻辑：用nx*ny与风场网格同样大小的canvas，获取到ImageData,将像素颜色四个数值中red红色和green绿色分别赋值成uv转换后的颜色值，注意透明度一定要置为不透明，然后put回canvas里面绘制,再利用canvas.toDataURL导出图片。

async function createCanvas() {

        const data = await getData('./wind.json');

        const info = await getData('info.json');

        const canvas = document.getElementById('theCanvas');

        canvas.width = info.nx;

        canvas.height = info.ny;



        const minU = Math.abs(info.minU);

        const minV = Math.abs(info.minV);

        // uv风方向范围

        const uSize = info.maxU - info.minU;

        const vSize = info.maxV - info.minV;

        const ctx = canvas.getContext('2d');

        //获取imageData像素数据

        const imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);

        data.forEach((item, i) => {

          //值转换成正数

          const u = item[0] + minU;

          const v = item[1] + minV;

          //转换成颜色值

          const r = (u / uSize) * 255;

          const g = (v / vSize) * 255;

          imageData.data[i * 4] = r;

          imageData.data[i * 4 + 1] = g;

          //透明度默认255即不透明

          imageData.data[i * 4 + 3] = 255;

        });

        //用imageData像素颜色值绘制图片

        ctx.putImageData(imageData, 0, 0);

      }

这样一张360px*181px的图片存储了65,160个点,但仅仅只需要86.6KB,压缩成原来数据的十分之一了。

• 如果改用风场方向图片，那么对应需要添加加载和解析数据的流程

加载风场方向数据图片

  loadImageData() {

    return new Promise((resolve) => {

      const image = new Image();

      image.src = this.imageUrl;

      image.onload = () => {

        const c = document.createElement('canvas');

        c.width = image.naturalWidth;

        c.height = image.naturalHeight;

        const ctx = c.getContext('2d');

        //绘制图片

        ctx.drawImage(image, 0, 0, image.naturalWidth, image.naturalHeight);

        //获取ImageData像素数据

        const imageData = ctx.getImageData(0, 0, image.naturalWidth, image.naturalHeight);

        

        resolve(imageData.data);

      };

    });

  }

解析图片数据成uv,并组装成风场网格Grid

data = await this.loadImageData();



      const minU = Math.abs(header.minU);

      const minV = Math.abs(header.minV);

      //uv风方向范围

      const uSize = header.maxU - header.minU;

      const vSize = header.maxV - header.minV;



      let index = 0;

      for (let j = 0; j < header.ny; j++) {

        const row = [];

        for (let i = 0; i < header.nx; i++) {

          //将颜色数据转化成风向uv数据

          const u = (data[index] / 255) * uSize - minU;

          const v = (data[index + 1] / 255) * vSize - minV;

          row.push([u, v]);

          index = index + 4;

        }

        this.grid.push(row);

      }

后面的绘制风场逻辑跟上面一样，只不过多了个加载图片解析的过程。

加上一张世界地图底图可以更清晰得看到风流动的方向！

四、绘制3D风场图

1.利用Canvas风场贴图绘制3D风场图

• 常规的顶点着色器

varying vec2 vUv;

void main() {

    vUv = uv;

    gl_Position = projectionMatrix * modelViewMatrix * vec4(position, 1.);



}

• 片元着色器，要将世界底图与风场图合并成一张图

varying vec2 vUv;

uniform sampler2D windTex;

uniform sampler2D worldTex;

void main() {

    vec4 color = texture2D(windTex, vUv);

    float a = color.a;

    if(a < 0.01) {

        a = 0.;

    }



    vec4 w = texture2D(worldTex, vUv);

        //根据透明度合并世界贴图和风场贴图

    vec4 c = w * (1. - a) + color * a;



    gl_FragColor = c;

}

• 创建风场贴图

async createWindCanvas() {

          const header = await getData('./info.json');          

          const canvas = document.createElement('canvas');

          //要足够大，否则会贴图模糊

          canvas.width = 4000;

          canvas.height = 2000;

          this.cw = new Windy({

            header,

            // data,

            canvas,

            //运动速度

            speed: 0.1,

            //随机点数量

            particlesCount: 1000,

            //生命周期

            maxAge: 120,

            //1秒更新次数

            frame: 10,

            //线渐变

            // color: {

            //   0: 'rgba(255,255,0,0)',

            //   1: '#ffff00'

            // },

            color: '#ffff00',

            //线宽度

            lineWidth: 3,

            imageUrl: 'wind.png'

            //autoAnimate: true

          });

          const texture = new THREE.CanvasTexture(canvas);

          //因为是动态canvas,所以要置为需要更新

          texture.needsUpdate = true;

          return texture;

        }

• 添加球体

async createChart(that) {

          this.windTex = await this.createWindCanvas();



          const worldTex = new THREE.TextureLoader().load('../assets/world.jpg');

          {

            const material = new THREE.ShaderMaterial({

              uniforms: {

                worldTex: { value: worldTex },



                windTex: { value: this.windTex }

              },

              vertexShader: document.getElementById('vertexShader').innerHTML,

              fragmentShader: document.getElementById('fragmentShader').innerHTML,

              side: THREE.DoubleSide,

              transparent: true

            });



            const geometry = new THREE.SphereGeometry(2, 32, 16);



            const sphere = new THREE.Mesh(geometry, material);

            this.scene.add(sphere);

          }

        }

• 让canvas动起来

animateAction() {

          if (this.windTex) {

            if (this.cw) {

              this.cw.render();

            }

            this.windTex.needsUpdate = true;

          }

        }

地球展开收起动画

• 将顶点着色器替换成下面的，根据uv计算出压平后球体表面点的位置，然后用mix来让原来球体表面的点过渡变化

注意球体半圆周长，对应球体压平后矩形的宽度，球体贴图正好是2:1，长度对应宽度的两倍。

uniform float time;

uniform float radius;

varying vec2 vUv;

float PI = acos(-1.0);

void main() {

    vUv = uv;

             //半圆周长

    float w = radius * PI;

            //随着时间压平或收起球体点位置

    vec3 newPosition = mix(position, vec3(0.0, (uv.y - 0.5) * w, -(uv.x - 0.5) * 2.0 * w), sin(time * PI * 0.5));

    gl_Position = projectionMatrix * modelViewMatrix * vec4(newPosition, 1.0);

}

• 展开或收起球体动画

openMap() {

          const tw = new TWEEN.Tween({ time: 0.0 })

            .to({ time: 1.0 }, 2000)

            .onUpdate((obj) => {

              if (this.mat) {

                this.mat.uniforms.time.value = obj.time;

              }

            })

            .start();

          TWEEN.add(tw);

        }

        closeMap() {

          const tw = new TWEEN.Tween({ time: 1.0 })

            .to({ time: 0.0 }, 2000)

            .onUpdate((obj) => {

              if (this.mat) {

                this.mat.uniforms.time.value = obj.time;

              }

            })

            .start();

          TWEEN.add(tw);

        }