我正在筹备一套前端工程化体系的实战课程。如果你在学习前端的过程中感到方向模糊、技术杂乱无章，那么前端工程化将是你实现系统进阶的最佳路径。它不仅能帮你建立起对现代前端开发的整体认知，还能提升你在项目开发、协作规范、性能优化等方面的工程能力。

✅ 本课程覆盖构建工具、测试体系、脚手架、CI/CD、Docker、Nginx 等核心模块，内容体系完整，贯穿从开发到上线的全流程。每一章节都配有贴近真实场景的企业级实战案例，帮助你边学边用，真正掌握现代团队所需的工程化能力，实现从 CRUD 开发者到工程型前端的跃迁。

详情请看前端工程化实战课程

学完本课程，对你的简历和具体的工作能力都会有非常大的提升。如果你对此项目感兴趣，或者课程感兴趣，可以私聊我微信 yunmz777

今年大部分时间都是在编码上和写文章上，但是也不知道自己都学到了啥，那就写篇文章来盘点一下目前的技术栈吧，也作为下一年的参考目标，方便知道每一年都学了些啥。

我的技术栈

首先我先来对整体的技术做一个简单的介绍吧，然后后面再对当前的一些技术进行细分吧。

React、Typescript、React Native、mysql、prisma、NestJs、Redis、前端工程化。

React

React 这个框架我花的时间应该是比较多的了，在校期间已经读了一遍源码了，对这些原理已经基本了解了。在随着技术的继续深入，今年毕业后又重新开始阅读了一遍源码，对之前的认知有了更深一步的了解。

也写了比较多跟 React 相关的文章，包括设计模式，原理，配套生态的使用等等都有一些涉及。

在状态管理方面，redux，zustand 我都用过，尤其在 Zustand 的使用上，我特别喜欢 Zustand，它使得我能够快速实现全局状态管理，同时避免了传统 Redux 中繁琐的样板代码，且性能更优。也对 Zustand 有比较深入的了解，也对其源码有过研究。

NextJs

Next.js 是一个基于 React 的现代 Web 开发框架，它为开发者提供了一系列强大的功能和工具，旨在优化应用的性能、提高开发效率，并简化部署流程。Next.js 支持多种渲染模式，包括服务器端渲染（SSR）、静态生成（SSG）和增量静态生成（ISR），使得开发者可以根据不同的需求选择合适的渲染方式，从而在提升页面加载速度的同时优化 SEO。

在路由管理方面，Next.js 采用了基于文件系统的路由机制，这意味着开发者只需通过创建文件和文件夹来自动生成页面路由，无需手动配置。这种约定优于配置的方式让路由管理变得直观且高效。此外，Next.js 提供了动态路由支持，使得开发者可以轻松实现复杂的 URL 结构和参数化路径。

Next.js 还内置了 API 路由，允许开发者在同一个项目中编写后端 API，而无需独立配置服务器。通过这种方式，前后端开发可以在同一个代码库中协作，大大简化了全栈开发流程。同时，Next.js 对 TypeScript 提供了原生支持，帮助开发者提高代码的可维护性和可靠性。

Typescript

今年所有的项目都是在用 ts 写了，真的要频繁修改的项目就知道用 ts 好处了，有时候用 js 写的函数修改了都不知道怎么回事，而用了 ts 之后，哪里引用到的都报红了，修改真的非常方便。

今年花了一点时间深入学习了一下 Ts 类型，对一些高级类型以及其实现原理也基本知道了，明年还是多花点时间在类型体操上，除了算法之外，感觉类型体操也可以算得上是前端程序员的内功心法了。

React Native

不得不说，React Native 不愧是接活神器啊，刚学完之后就来了个安卓和 ios 的私活，虽然没有谈成。

React Native 和 Expo 是构建跨平台移动应用的两大热门工具，它们都基于 React，但在功能、开发体验和配置方式上存在一些差异。React Native 是一个开放源代码的框架，允许开发者使用 JavaScript 和 React 来构建 iOS 和 Android 原生应用。Expo 则是一个构建在 React Native 之上的开发平台，它提供了一套工具和服务，旨在简化 React Native 开发过程。

React Native 的核心优势在于其高效的跨平台开发能力。通过使用 React 语法和组件，开发者能够一次编写应用的 UI 和逻辑，然后部署到 iOS 和 Android 平台。React Native 提供了对原生模块的访问，使开发者能够使用原生 API 来扩展应用的功能，确保性能和用户体验能够接近原生应用。

Expo 在此基础上进一步简化了开发流程。作为一个开发工具，Expo 提供了许多内置的 API 和组件，使得开发者无需在项目中进行繁琐的原生模块配置，就能够快速实现设备的硬件访问功能（如摄像头、位置、推送通知等）。Expo 还内置了一个开发客户端，使得开发者可以实时预览应用，无需每次都进行完整的构建和部署。

另外，Expo 提供了一个完全托管的构建服务，开发者只需将应用推送到 Expo 服务器，Expo 就会自动处理 iOS 和 Android 应用的构建和发布。这大大简化了应用的构建和发布流程，尤其适合不想处理复杂原生配置的开发者。

然而，React Native 和 Expo 也有各自的局限性。React Native 提供更大的灵活性和自由度，开发者可以更自由地集成原生代码或使用第三方原生库，但这也意味着需要更多的配置和维护。Expo 则封装了很多功能，简化了开发，但在需要使用某些特定原生功能时，开发者可能需要“弹出”Expo 的托管环境，进行额外的原生开发。

样式方案的话我使用的是 twrnc，大部分组件都是手撸，因为有 cursor 和 chatgpt 的加持，开发效果还是杠杠的。

rn 原理也争取明年能多花点时间去研究研究，不然对着盲盒开发还是不好玩。

Nestjs

NestJs 的话没啥好说的，之前也都写过很多篇文章了，感兴趣的可以直接观看：

• 面试官：为什么选择学习 Nestjs，而不是 Express？🧐🧐🧐


• NestJS 的生命周期钩子以及它们在不同阶段的都适合做什么？

对 Nodejs 的底层也有了比较深的理解了：

• 探究 CPU 密集型与 IO 密集型任务：提升对 Node.js 中 libuv 库的理解

Prisma & mysql

Prisma 是一个现代化的 ORM（对象关系映射）工具，旨在简化数据库操作并提高开发效率。它支持 MySQL 等关系型数据库，并为 Node.js 提供了类型安全的数据库客户端。在 NestJS 中使用 Prisma，可以让开发者轻松定义数据库模型，并通过自动生成的 Prisma Client 执行类型安全的查询操作。与 MySQL 配合时，Prisma 提供了一种简单、直观的方式来操作数据库，而无需手动编写复杂的 SQL 查询。

Prisma 的核心优势在于其强大的类型安全功能，所有的数据库操作都能通过 Prisma Client 提供的自动生成的类型来进行，这大大减少了代码中的错误，提升了开发的效率。它还包含数据库迁移工具 Prisma Migrate，能够帮助开发者方便地管理数据库结构的变化。此外，Prisma Client 的查询 API 具有很好的性能，能够高效地执行复杂的数据库查询，支持包括关系查询、聚合查询等高级功能。

与传统的 ORM 相比，Prisma 使得数据库交互更加简洁且高效，减少了配置和手动操作的复杂性，特别适合在 NestJS 项目中使用，能够与 NestJS 提供的依赖注入和模块化架构很好地结合，提升整体开发体验。

Redis

Redis 和 mysql 都仅仅是会用的阶段，目前都是直接在 NestJs 项目中使用，都是已经封装好了的，直接传参调用就好了：

import { Injectable, Inject, OnModuleDestroy, Logger } from "@nestjs/common";

import Redis, { ClientContext, Result } from "ioredis";



import { ObjectType } from "../types";



import { isObject } from "@/utils";



@Injectable()

export class RedisService implements OnModuleDestroy {

  private readonly logger = new Logger(RedisService.name);



  constructor(@Inject("REDIS_CLIENT") private readonly redisClient: Redis) {}



  onModuleDestroy(): void {

    this.redisClient.disconnect();

  }



  /**

   * @Description: 设置值到redis中

   * @param {string} key

   * @param {any} value

   * @return {*}

   */

  public async set(

    key: string,

    value: unknown,

    second?: number

  ): Promise<Result<"OK", ClientContext> | null> {

    try {

      const formattedValue = isObject(value)

        ? JSON.stringify(value)

        : String(value);



      if (!second) {

        return await this.redisClient.set(key, formattedValue);

      } else {

        return await this.redisClient.set(key, formattedValue, "EX", second);

      }

    } catch (error) {

      this.logger.error(`Error setting key ${key} in Redis`, error);



      return null;

    }

  }



  /**

   * @Description: 获取redis缓存中的值

   * @param key {String}

   */

  public async get(key: string): Promise<string | null> {

    try {

      const data = await this.redisClient.get(key);



      return data ? data : null;

    } catch (error) {

      this.logger.error(`Error getting key ${key} from Redis`, error);



      return null;

    }

  }



  /**

   * @Description: 设置自动 +1

   * @param {string} key

   * @return {*}

   */

  public async incr(

    key: string

  ): Promise<Result<number, ClientContext> | null> {

    try {

      return await this.redisClient.incr(key);

    } catch (error) {

      this.logger.error(`Error incrementing key ${key} in Redis`, error);



      return null;

    }

  }



  /**

   * @Description: 删除redis缓存数据

   * @param {string} key

   * @return {*}

   */

  public async del(key: string): Promise<Result<number, ClientContext> | null> {

    try {

      return await this.redisClient.del(key);

    } catch (error) {

      this.logger.error(`Error deleting key ${key} from Redis`, error);



      return null;

    }

  }



  /**

   * @Description: 设置hash结构

   * @param {string} key

   * @param {ObjectType} field

   * @return {*}

   */

  public async hset(

    key: string,

    field: ObjectType

  ): Promise<Result<number, ClientContext> | null> {

    try {

      return await this.redisClient.hset(key, field);

    } catch (error) {

      this.logger.error(`Error setting hash for key ${key} in Redis`, error);



      return null;

    }

  }



  /**

   * @Description: 获取单个hash值

   * @param {string} key

   * @param {string} field

   * @return {*}

   */

  public async hget(key: string, field: string): Promise<string | null> {

    try {

      return await this.redisClient.hget(key, field);

    } catch (error) {

      this.logger.error(

        `Error getting hash field ${field} from key ${key} in Redis`,

        error

      );



      return null;

    }

  }



  /**

   * @Description: 获取所有hash值

   * @param {string} key

   * @return {*}

   */

  public async hgetall(key: string): Promise<Record<string, string> | null> {

    try {

      return await this.redisClient.hgetall(key);

    } catch (error) {

      this.logger.error(

        `Error getting all hash fields from key ${key} in Redis`,

        error

      );



      return null;

    }

  }



  /**

   * @Description: 清空redis缓存

   * @return {*}

   */

  public async flushall(): Promise<Result<"OK", ClientContext> | null> {

    try {

      return await this.redisClient.flushall();

    } catch (error) {

      this.logger.error("Error flushing all Redis data", error);



      return null;

    }

  }



  /**

   * @Description: 保存离线通知

   * @param {string} userId

   * @param {any} notification

   */

  public async saveOfflineNotification(

    userId: string,

    notification: any

  ): Promise<void> {

    try {

      await this.redisClient.lpush(

        `offline_notifications:${userId}`,

        JSON.stringify(notification)

      );

    } catch (error) {

      this.logger.error(

        `Error saving offline notification for user ${userId}`,

        error

      );

    }

  }



  /**

   * @Description: 获取离线通知

   * @param {string} userId

   * @return {*}

   */

  public async getOfflineNotifications(userId: string): Promise<any[]> {

    try {

      const notifications = await this.redisClient.lrange(

        `offline_notifications:${userId}`,

        0,

        -1

      );

      await this.redisClient.del(`offline_notifications:${userId}`);



      return notifications.map((notification) => JSON.parse(notification));

    } catch (error) {

      this.logger.error(

        `Error getting offline notifications for user ${userId}`,

        error

      );



      return [];

    }

  }



  /**

   * 获取指定 key 的剩余生存时间

   * @param key Redis key

   * @returns 剩余生存时间（秒）

   */

  public async getTTL(key: string): Promise<number> {

    return await this.redisClient.ttl(key);

  }

}

前端工程化

前端工程化这块花了很多信息在 eslint、prettier、husky、commitlint、github action 上，现在很多项目都是直接复制之前写好的过来就直接用。

后续应该是投入更多的时间在性能优化、埋点、自动化部署上了，如果有机会的也去研究一下 k8s 了。

全栈性价比最高的一套技术

最近刷到一个帖子，讲到了

我目前也算是一个小全栈了吧，我也来分享一下我的技术吧：

剩下的描述也是和他下面那句话一样了（毕业后对技术态度的转变就是什么能让我投入最小，让我最快赚到钱的就是好技术）

总结

学无止境，任重道远。

最后再来提一下这两个开源项目，它们都是我们目前正在维护的开源项目：

• 在线代码协同编辑器


• 前端脚手架 create-neat

如果你想参与进来开发或者想进群学习，可以添加我微信 yunmz777，后面还会有很多需求，等这个项目完成之后还会有很多新的并且很有趣的开源项目等着你。

同志们，我去外包了

同志们，经历了漫长的思想斗争，我决定回老家发展，然后就是简历石沉大海，还好外包拯救了我，我去外包了！

首先随着工作年限的增加，越来越多公司并不会去和你抠八股文了（那阵八股风好像停了），只是象征性的问几个问题，然后会对照着项目去问些实际的问题以及你的处理办法。
(ps：(坐标合肥)突然想到某鑫面试官问我你知道亿级流量吗？你怎么处理的，听到这个问题我就想呼过去，也许读书读傻了，他根本不知道亿级流量是个什么概念，最主要的是它是个制造业公司啊，你哪来的亿级流量啊，也不知道问这个问题时他在想啥，还有某德(不是高德)，一场能面一个小时，人裂开)。

好了，言归正传，咱说点入职这家公司我了解到的一点东西，我分为两部分：代码和sql；

代码上

首先传统的web项目也会分前端后端，这点不错；

1.获取昨天日期

可以使用jdk自带的LocalDate.now().minusDays(-1)
这个其实内部调用的是plusDays(-1)方法，所以不如直接就用plusDays方法，这样少一层判断；

PS：有多少人和我之前一样直接new Date()的。

2.字符填充

apache.common下的StringUtils的rightPad方法用于字符串填充使用方法是StringUtils.rightPad(str,len,fillStr)
大概意思就是str长度如果小于len，就用fillStr填充；

PS：有多少人之前是String.format或者StringBuilder用循环实现的。

3.获取指定年指定月的某天

获取指定年指定月的某天可以用localDate.of(year,month,day)，如果我们想取2025年的五月一号，可以写成LocalDate.of(2025, 5, 1)，那有人可能就想到了如果月尾呢，LocalDate.of(2025, 5, 31)也是可以的，但是我们需要清楚知道这个月有多少天，比如说你2月给个30天，那就会抛异常；
麻烦；

更好的办法就是先获取第一天，然后调用localDate.with(TemporalAdjusters.lastDayOfMonth());方法获取最后一天，TemporalAdjusters.lastDayOfMonth()会自动处理不同月份和闰年的情况；

sql层面的

有言在先，说实话我不建议在sql层面写这种复杂的东西，毕竟我们这么弱的人看到那么长的且复杂的sql会很无力，那种无力感你懂吗？打工人不为难打工人；不过既然别人写了，咱们就学习一下嘛；

1.获取系统日期

首先获取系统日期可以试用TRUNC(SYSDATE)进行截取，这样返回的时分秒是00:00:00,比如2025-05-29 00:00:00，它也可以截取数字，想知道就去自行科普下，不建议掌握，学习了下，有点搞；

2.返回date当前月份的最后一天

LAST_DAY(date)这个返回的是date当前月份的最后一天,比如今天是2025-05-29，那么返回的是2025-05-31
ADD_MONTH(date,11)表示当前日期加上11个月，比如2025-01-02，最终返回的是2025-12-02;

3.左连接的知识点

最后再提个左连接的知识点，最近看懵了，图一乐哈，A left join B，就是on的条件是在join生成临时表时起作用的，而where是对生成的临时表进行过滤；
两者过滤的时机不一样。我想了很久我觉得可以这么理解，on它虽然可以添加条件，但他的条件只是一个匹配条件比如B.age>10;它是不会对A表查询出来的数据量产生一个过滤效果；
而where是一个实打实的过滤条件，不管怎么说都会影响最终结果，对于inner join这个特例，on和where的最终效果一样，因为B.age>10会导致B的匹配数据减少，由于是交集，故会对整体数据产生影响。

好了，晚安，外包打工仔。。。

前言

大家好，我是奈德丽。前两天在逛京东想买Pocket 3的时候，注意到了它的购物车动效，当点击"加入购物车"按钮时，一个小红球从商品飞入购物车，我觉得很有意思，于是花了点时间来研究。

实现效果

看了图才知道我在讲什么，那么先看Gif吧！

代码演示

代码已经上传到了码上掘金，感兴趣的可以自行查看，文章中没有贴全部代码了，主要讲讲思路，
code.juejin.cn/pen/7503150…

实现思路

下面这个思路，小白也能会，我们将通过以下几个步骤来实现这个效果：

画页面——>写逻辑实现动画效果

好了，废话不多说，开始进入正题

第一步：先让AI帮我们写出来UI结构

像我们这种工作1坤年以上的切图仔，能偷懒当然偷懒啦，这种画页面的活可以丢给AI来干了，下面是Taro帮我生成的页面部分，没什么难点，就是一些普普通通的页面元素。

<template>

  <div class="rolling-ball-container">

    <!-- 商品列表 -->

    <div class="item-list">

      <div class="item" v-for="item in 10" :key="item">

        <div class="product-card">

          <div class="product-tag">秒杀</div>

          <div class="product-image">

            <img src="/product.jpg" alt="商品图片" />

          </div>

          <div class="product-info">

            <div class="product-title">大疆 DJI Osmo Pocket 3 一英寸口袋云台相机</div>

            <div class="product-features">

              <span class="feature-tag">三轴防抖</span>

              <span class="feature-tag">防抖稳定</span>

              <span class="feature-tag">高清画质</span>

            </div>

            <div class="product-price">

              <span class="price-symbol">¥</span>

              <span class="price-value">4788</span>

              <span class="price-original">¥4899</span>

            </div>

            <div class="product-meta">

              <span class="delivery-time">24分钟达</span>

              <span class="rating">好评率96%</span>

            </div>

            <div class="product-shop">京东之家-凯德汇新店</div>

          </div>

          <div class="add-to-cart" @click="startRolling($event)">+</div>

        </div>

      </div>

    </div>

    

    <!-- 购物车图标 -->

    <div class="point end-point">

      <div style="position: relative;">

        <img src="/cart.png" />

        <div class="cart-count">{{ totalCount }}</div>

      </div>

    </div>

    

    <!-- 小球容器 -->

    <div 

      v-for="(ball, index) in balls" 

      :key="index"

      class="ball"

      v-show="ball.show"

      :style="getBallStyle(ball)"

    ></div>

  </div>

</template>

第二步：设计小球数据模型

有了页面元素了，我们需要创建小球数组和计数器

import { reactive, ref } from 'vue';



// 购物车商品计数

const totalCount = ref(0);



// 创建小球数组（预先创建3个小球以应对连续点击）

const balls = reactive(Array(3).fill(0).map(() => ({

  show: false,   // 是否显示

  startX: 0,     // 起点X坐标

  startY: 0,     // 起点Y坐标

  endX: 0,       // 终点X坐标

  endY: 0,       // 终点Y坐标

  pathX: 0,      // 路径X偏移量

  pathY: 0,      // 路径Y偏移量

  progress: 0    // 动画进度

})));

为什么小球要用一个数组来存储呢？因为我看到京东上用户是可以连续点击+号将商品加入购入车的，页面上可以同时存在很多个飞行的小球。

第三步：实现动画触发函数

当用户点击"+"按钮时，我们需要计算起点和终点坐标，然后启动动画，这儿有一个细节，为了让小球刚好落到在购物车中间，对终点坐标进行了微调。

// 开始滚动动画

const startRolling = (event: MouseEvent) => {

  // 获取起点和终点元素

  const startPoint = event.currentTarget as HTMLElement;

  const endPoint = document.querySelector('.end-point') as HTMLElement;

  

  if (startPoint && endPoint) {

    // 找到一个可用的小球

    const ball = balls.find(ball => !ball.show);

    if (ball) {

      // 获取起点位置

      const startRect = startPoint.getBoundingClientRect();

      ball.startX = startRect.left + startRect.width / 2;

      ball.startY = startRect.top + startRect.height / 2;

      

      // 获取终点位置

      const endRect = endPoint.getBoundingClientRect();    

      const endX = endRect.left + endRect.width / 2;

      const endY = endRect.top + endRect.height / 2;

      // 微调终点位置

      ball.endX = endX - 4;

      ball.endY = endY - 7;

      

      // 设置路径偏移量

      ball.pathX = 0;

      ball.pathY = 100;

      

      // 显示小球并重置进度

      ball.show = true;

      ball.progress = 0;

      

      // 使用requestAnimationFrame实现动画

      let startTime = Date.now();

      const duration = 400; // 动画持续时间(毫秒)

      

      function animate() {

        const currentTime = Date.now();

        const elapsed = currentTime - startTime;

        ball.progress = Math.min(elapsed / duration, 1);

        

        if (ball.progress < 1) {

          requestAnimationFrame(animate);

        } else {

          // 动画结束后隐藏小球

          setTimeout(() => {

            ball.show = false;

          }, 100);

        }

      }

      

      requestAnimationFrame(animate);

      

      // 增加购物车商品数量

      totalCount.value++;

    }

  }

};

第四步：使用贝塞尔曲线计算小球轨迹

点击"+"按钮，不能让小球做自由落体运动吧，那是伽利略研究的，你看这自由落体好看嘛，指定不行，要是长这样，那东哥的商城还能卖出去东西吗？Hah

为了不让它自由落体，给它一个向左的偏移量100px

// 获取小球样式

const getBallStyle = (ball: any) => {

  if (!ball.show) return {};

  

  // 使用二次贝塞尔曲线计算路径

  const t = ball.progress;

  const mt = 1 - t;

  

  // 判断起点和终点是否在同一垂直线上

  const isVertical = Math.abs(ball.startX - ball.endX) < 20;

  

  // 计算控制点（确保有弧度）

  let controlX, controlY;

  

  if (isVertical) {

    // 如果在同一垂直线上，向左偏移一定距离

    controlX = ball.startX - 100;

    controlY = (ball.startY + ball.endY) / 2;

  } else {

    // 否则使用向左偏移

    controlX = (ball.startX + ball.endX) / 2 - 100;

    controlY = (ball.startY + ball.endY) / 2 + (ball.pathY || 100);

  }

  

  // 二次贝塞尔曲线公式

  const x = mt * mt * ball.startX + 2 * mt * t * controlX + t * t * ball.endX;

  const y = mt * mt * ball.startY + 2 * mt * t * controlY + t * t * ball.endY;

  

  return {

    left: `${x}px`,

    top: `${y}px`,

    transform: `rotate(${ball.progress * 360}deg)` // 添加旋转效果

  };

};

技术要点解析

1. 贝塞尔曲线原理

贝塞尔曲线是一种参数化曲线，广泛应用于计算机图形学。二次贝塞尔曲线由三个点定义：起点P₀、控制点P₁和终点P₂。

曲线上任意点的坐标可以通过以下公式计算：

B(t) = (1-t)²P₀ + 2(1-t)tP₁ + t²P₂  (0 ≤ t ≤ 1)

在我们的实现中，通过调整控制点的位置，可以控制曲线的形状，从而实现小球的抛物线运动效果。

2. requestAnimationFrame的优势

与setTimeout或setInterval相比，requestAnimationFrame有以下优势：

3. 动态计算元素位置

我们使用getBoundingClientRect()方法获取元素在视口中的精确位置，这确保了无论页面如何滚动或调整大小，动画始终能准确地从起点到达终点。

总结

通过这个小球飞入购物车的动画效果，我们不仅提升了用户体验，还学习了：

这个小小的交互设计虽然看起来简单，但能大大提升用户体验，让你的电商网站更加生动有趣。从京东商城的灵感到实际代码实现，我们完成了一个专业级别的交互效果。

恩恩……懦夫的味道

菜鸟上班已经两年了，从一个对技术充满热情的小伙子，变成了一个职场老鸟了。自以为自己在不停的学习，但是其实就是学一些零碎的知识点，比如：vue中什么东西没见过、js什么特性没用过、css新出了个啥 ……

菜鸟感觉自己也出现了惰性，就是暂时用不上的或者学习成本比较大的，就直接收藏了，想着后面再来学习；然后那些很快能接收有用的小的知识点，就感觉看过几次就收藏了，后面有用，就来收藏里面翻一下就行！

但是菜鸟最近再来回想才发现，这些其实都是虚的，程序员最重要的应该是思维模式，以及如何把学的东西、好用的东西用起来，找到应用场景，而不是到时候再去找。

正如标题所说，菜鸟其实很早就知道css原子化，但是一直都走不出自己的舒适圈，感觉就写点css也挺好，为什么还要花力气去记别人想好的类名？要是一直用这些，岂不是css知识都忘记完了？

直到我们公司的大佬来了之后，力推tailwind，而菜鸟感觉和大佬的差距真的很大，所以又激起了菜鸟想要学习的兴趣！

怎么从css过渡到tailwind

菜鸟在之前，是很不想使用tailwind的，因为菜鸟感觉里面很多类名需要去记，而且和我之前取类名的方式也不一样！相信大部分人都和菜鸟一样，在用tailwind之前，取类名一般都是和包裹的内容相关的名字，例如：contentBox、title、asideBox ……

前期使用不熟的时候直接打开官网就行：http://www.tailwindcss.cn/docs/instal…

菜鸟告诉大家一个办法，就是别想着去记类名，直接你想要用什么css属性，直接点击搜索即可，敲入你想使用的属性

多用几次，自然就记住了，而且现在编译器有提示的。用了tailwind之后，只能说句真香，因为再也不会有怎么取名以及有重名的困扰了！

tailwind yyds

一开始菜鸟用tailwind，感觉也不是很自由啊！

菜鸟就感觉这个也太low了吧，我要是想用别的值怎么办？直到菜鸟看到了这个

基本上有了这个，就可以天下无敌了，想多少就多少，这就是自由的感觉！

反正菜鸟基本上用的都是这个，不管是颜色还是大小，除非比较好记的，例如：w-1、w-2、p-1、p-2、m-1、mr-1 ……

tailwind 自定义类名

有一个问题，就是当类名太多的时候，感觉也不是很好看，这个时候就要用到复杂一点的tailwind，见文档：http://www.tailwindcss.cn/docs/reusin…

很多地方都用到一样的样式，就适合这种方式！不然直接多写几个类名也不是不能接受！

@layer

这个@layer components是避免样式冲突和被覆盖的作用，菜鸟感觉不好理解，但是你肯定不会去重写tailwind的类名，至于有没有树摇优化那就是菜鸟没有涉猎了，反正就当默认写法比较好理解，一般也确实就是这样写。

这里也可以看看tailwind4的官网，感觉说得清楚一点：tailwindcss.com/docs/adding…

当然有懂的读者，可以指点江山，激扬文字！

更多函数或指令

tailwind中不止有@layer、@apply，只是 菜鸟主要就用了这两个，更多见官网：tailwindcss.com/docs/functi…

类名太多，团队规范

当一个元素类名比较多时，每个人的想法都不一样，那么类名就会比较杂乱，可能每个人都不一样，看着就不是很好，这个时候就要使用自动格式化工具了，让每个人的类名排列顺序都是一样，也避免了不少冲突！

插件地址：github.com/tailwindlab…

只要使用了prettier就可以使用这个，关于prettier的知识可以见：vue3+vite+eslint|prettier+elementplus+国际化+axios封装+pinia

使用tailwind不会忘记css，更是加强css

菜鸟之前对tailwind的误解有点深，其实使用tailwind根本不会降低我们的css水平，相反，你平时多逛逛tailwind官网，反而能发现一些你从未使用过或者使用很少的css属性，你会用tailwind实现，其实就是css会实现，反正都可以增加你对css某个属性的理解，且tailwind还附带了效果示例！

Trae 对 tailwind 的支持

之前的代码

<el-button

  :loading="loading"

  size="large"

  type="primary"

  s =tyle="width: 100%"

  @click.prevent="handleLogin"

>

  <span v-if="!loading">登 录</span>

  <span v-else>登 录 中...</span>

</el-button>

实现效果

感觉Trae对tailwind的支持挺好的，一些简单的效果都可以快速实现！

tailwind 可以替代 scss 等

tailwind4 中有明确的说明，见：tailwindcss.com/docs/compat…

菜鸟只能说tailwind的目标很宏大！

总结

tailwind使用不难，所以菜鸟也没啥可以写得很多或者很复杂的，菜鸟只是希望这个经历可以让各位新手赶紧掌握tailwind，不是css用不起，而是tailwind更有性价比！

我们又上架了一个鸿蒙项目-止欲

止欲介绍

止欲是一款休闲类的鸿蒙元服务，希望可以通过冥想让繁杂的生活慢下来、静下来。

《止欲》从立项到上架总过程差不多两个月，主要都是我们青蓝的小伙伴在工作止欲抽空完成的，已经实属不易了，我们主要开发者都是 00 后，最年轻的开发者也是才 19 岁。

立项时间是：2025-04-08

上架时间是：2025-06-03

止欲同时也是我们青蓝逐码组织上架的第三个作品了，每个作品都是由初入职场、甚至大学还没有毕业的小伙伴高度参与！

git 日志一览

项目技术细节

项目架构

Serenity/Application/

├── entry/                          # 主模块

│   ├── src/main/

│   │   ├── ets/                    # TypeScript源码

│   │   │   ├── entryability/       # 应用入口能力

│   │   │   ├── entryformability/   # 服务卡片能力

│   │   │   ├── pages/              # 页面文件

│   │   │   ├── view/               # UI组件

│   │   │   ├── utils/              # 工具类

│   │   │   ├── model/              # 数据模型

│   │   │   ├── const/              # 常量定义

│   │   │   └── navigationStack/    # 导航栈管理

│   │   └── resources/              # 资源文件

│   └── module.json5                # 模块配置

├── EntryCard/                      # 服务卡片模块

├── AppScope/                       # 应用级配置

└── oh-package.json5               # 依赖管理

技术栈

• 开发语言: ArkTS (TypeScript)


• UI 框架: ArkUI


• 构建工具: Hvigor


• 包管理: ohpm

核心开发套件 (Kit)

本项目使用了多个 HarmonyOS 官方开发套件：

开发环境要求

• HarmonyOS SDK: 5.0.1(13) 或更高版本


• DevEco Studio: 5.0 或更高版本


• 编译目标: HarmonyOS

开发细节

开始立项

分析如何选型

暴躁起来了

成功上架

后续计划

总结

关于青蓝逐码组织

如果你兴趣想要了解更多的鸿蒙应用开发细节和最新资讯，甚至你想要做出一款属于自己的应用！欢迎在评论区留言或者私信或者看我个人信息，可以加入技术交流群。

Chrome AI 长啥样

废话不多说，让我们直接来看一个示例：

async function askAi(question) {

	if (!question) return "你倒是输入问题啊"



	// 检查模型是否已下载（模型只需下载一次，就可以供所有网站使用）

	const canCreate = await window.ai.canCreateTextSession()



	if (canCreate !== "no") {

		// 创建一个会话进程

	  const session = await window.ai.createTextSession()

  

		// 向 AI 提问

	  const result = await session.prompt(question)

	  

	  // 销毁会话

	  session.destroy()

		

		return result

	}	

	

	return "模型都还没下载好，你问个蛋蛋"

}



askAi("玩梗来说，世界上最好的编程语言是啥").then(console.log)

//打印： **Python 语言：程序员的快乐源泉！**

可以看到这些浏览器原生 AI 接口是挂在 window.ai 对象下面的，浏览器自带 AI 模型（要下载），无需消耗开发者的资金去调用 OpenAI API 或者是 文心一言 API等。

由于没有成本限制，想象空间极大扩展。你可以将智能融入网页的每一个环节。例如，实时翻译，传统的 i18n 只能映射静态字符串来支持多语言，对于后端传过来的字符串毫无办法，现在可以交给 AI 实时翻译并展示。

未来，这个浏览器 AI 标准接口将不仅限于 Chrome 和 PC 端，其他浏览器厂商也会跟进，手机也将拥有本地运行小模型的浏览器。

Chrome AI 接口文档

我们刚刚看到了 Chrome AI 的调用示例，现在让我们看一下完整的 Chrome 文档。我将用 TypeScript 和注释方式展示，这些类型和注释是我手动编写的，全网独一无二，赶紧收藏：

declare global {

  interface Window {

    readonly ai: AI;

  }



  interface AI {

    /**

     * 判断模型是否准备好了

     * @example

     * ```js

     * const availability = await window.ai.canCreateTextSession()

     * if (availability === 'readily') {

     *  console.log('模型已经准备好了')

     * } else if (availability === 'after-download') {

     *  console.log('模型正在下载中')

     * } else {

     *  console.log('模型还没下载')

     * }

     * ```

     */

    canCreateTextSession(): Promise<AIModelAvailability>;



    /**

     * 创建一个文本生成会话进程

     * @param options 会话配置  

     * @example

     * ```js

     * const session = await window.ai.createTextSession({

     *  topK: 50, // 生成文本的多样性，越大越多样

     *  temperature: 0.8 // 生成文本的创造性，越大越随机

     * })

     * 

     * const text = await session.prompt('今天天气怎么样？')

     * console.log(text)

     * ```

     */

    createTextSession(options?: AITextSessionOptions): Promise<AITextSession>;



    /**

     * 获取默认的文本生成会话配置

     * @example

     * ```js

     * const options = await window.ai.defaultTextSessionOptions()

     * console.log(options) // { topK: 50, temperature: 0.8 }

     * ```

     */

    defaultTextSessionOptions(): Promise<AITextSessionOptions>;

  }



  /**

   * AI模型的可用性

   * - `readily`：模型已经准备好了

   * - `after-download`：模型正在下载中

   * - `no`：模型还没下载

   */

  type AIModelAvailability = 'readily' | 'after-download' | 'no';



  interface AITextSession {

    /**

     * 询问 AI 问题, 返回 AI 的回答

     * @param input 输入文本, 询问 AI 的问题

     * @example

     * ```js

     * const session = await window.ai.createTextSession()

     * const text = await session.prompt('今天天气怎么样？')

     * console.log(text)

     * ```

     */

    prompt(input: string): Promise<string>;



    /**

     * 询问 AI 问题, 以流的形式返回 AI 的回答

     * @param input 输入文本, 询问 AI 的问题

     * @example

     * ```js

     * const session = await window.ai.createTextSession()

     * const stream = session.promptStreaming('今天天气怎么样？')

     * let result = ''

     * let previousLength = 0

     * 

     * for await (const chunk of stream) {

     *  const newContent = chunk.slice(previousLength)

     *  console.log(newContent) // AI 的每次输出

     *  previousLength = chunk.length

     *  result += newContent

     * }

     * 

     * console.log(result) // 最终的 AI 回答（完整版）

     */

    promptStreaming(input: string): ReadableStream;



    /**

     * 销毁会话

     * @example

     * ```js

     * const session = await window.ai.createTextSession()

     * session.destroy()

     * ```

     */

    destroy(): void;



    /**

     * 克隆会话

     * @example

     * ```js

     * const session = await window.ai.createTextSession()

     * const cloneSession = session.clone()

     * const text = await cloneSession.prompt('今天天气怎么样？')

     * console.log(text)

     * ```

     */

    clone(): AITextSession;

  }



  interface AITextSessionOptions {

    /**

     * 生成文本的多样性，越大越多样，正整数，没有范围

     */

    topK: number;



    /**

     * 生成文本的创造性，越大越随机，0-1 之间的小数

     */

    temperature: number;

  }

}

如何启用 Chrome AI

准备工作

启用 Gemini Nano 和 Prompt API

确认 Gemini Nano 是否可用

思考

AI 最近两年可谓是爆发式增长，从 GPT-3 开始，笔者就一直在使用 AI 产品，如 Github copilot。ChatGPT 推出后，我迅速开发了一个 GPT-Runner vscode 扩展，用于勾选代码文件进行对话。

我一直在思考，AI 能给网页产品带来哪些变革？例如，有没有可能出现一个 AI 组件库，将 AI 智能赋予组件，如 input 框猜测用户下一步输入，或 table 组件实现自然语言搜索和数据拼装。

与 AI 相关的技术通常需要额外的计算成本，企业主和用户支付意愿低。如果能利用本地算力，就无需额外花费。这个场景现在似乎在慢慢实现。

作为开发者，我们正在迎来 AI 全面赋能网页操作的时代。让我们积极拥抱变化，向老板展示更多的迭代需求，找到前端就业的新增长点。

如果本文章感兴趣者众多，将考虑使用这个 AI 接口实现兼容 OpenAI API 规范，这样你可以不用花钱，不用装 Docker，直接使用浏览器算力和油猴插件免费使用各类开源 chat web ui，如在线版的 Chat-Next-Web。

彩蛋

仔细观察 window.ai.createTextSession ，你会发现它为什么不叫 window.ai.createSession ？我猜测未来可能会有 text-to-speech 模型、 speech-to-text 模型、text-to-image 模型、image-to-text 模型，或者更多惊喜。

这不是随便猜测，我是在填写 Chrome AI preview 邀请表时看到的选项。敬请期待吧，各位前端开发er。

3. 记住设置：自动保存用户的偏好设置

技术实现

1.首先，我们需要在 manifest.json 中声明必要的权限：

  "manifest_version": 3,

  "name": "Web Blur",

  "version": "1.0",

  "permissions": [

    "activeTab",

    "storage",

    "commands"

  ],

  "action": {

    "default_popup": "popup.html",

    "default_icon": {

      "128": "images/icon.png"

    }

  },

  "commands": {

    "toggle-blur": {

      "suggested_key": {

        "default": "Ctrl+Shift+B"

      },

      "description": "Toggle blur effect"

    }

  }

}

2. 实现模糊效果

function applyBlur(amount) {

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

  style.id = 'web-blur-style';

  style.textContent = `

    body {

      filter: blur(${amount}px) !important;

      transition: filter 0.3s ease;

    }

  `;

  document.head.appendChild(style);

}



// 移除模糊效果

function removeBlur() {

  const style = document.getElementById('web-blur-style');

  if (style) {

    style.remove();

  }

}

3. 快捷键控制

  if (command === 'toggle-blur') {

    chrome.tabs.query({active: true, currentWindow: true}, (tabs) => {

      chrome.tabs.sendMessage(tabs[0].id, {action: 'toggleBlur'});

    });

  }

});

4. 用户界面

  

    Toggle Blur

  

  

  


    Blur Amount:

    

    5px

  


  

  


    Current: Ctrl+Shift+B

    Change shortcut

  

5. 设置持久化

function saveSettings(settings) {

  chrome.storage.sync.set({settings}, () => {

    console.log('Settings saved');

  });

}



// 加载设置

function loadSettings() {

  chrome.storage.sync.get(['settings'], (result) => {

    if (result.settings) {

      applySettings(result.settings);

    }

  });

}

以后可以愉快的学技术辣

背景

2024 年 1 月，京东正式启动鸿蒙原生应用开发，基于 HarmonyOS NEXT 的全场景、原生智能、原生安全等优势特性，为消费者打造更流畅、更智能、更安全的购物体验。同年 6 月，京东鸿蒙原生应用尝鲜版上架华为应用市场，计划 9 月完成正式版的上架。

早在 2020 年，京东与华为就签署了战略合作协议，不断加大技术投入探索 HarmonyOS 的创新特性。作为华为鸿蒙生态的首批头部合作伙伴，在适配鸿蒙操作系统的过程中，京东与华为一直保持着密切的技术沟通与共创，双方共同攻坚行业适配难点，并推动多端统一开发解决方案 Taro 在业界率先实现对鸿蒙 ArkUI 的原生开发支持。

本文将阐述京东鸿蒙原生应用在开发时所采用的技术方案、技术特点、性能表现以及未来的优化计划。通过介绍选择 Taro 作为京东鸿蒙原生应用的开发框架的原因，分析 Taro 在支持 Web 范式开发、快速迁移存量项目、渲染性能优化、高阶功能支持以及混合开发模式等方面的优势。

技术方案

京东在开发鸿蒙原生应用的过程中，需要考虑如何在有限的时间内高效完成项目，同时兼顾应用的性能与用户体验。为了达成这一目标，选择合适的技术方案至关重要。

在技术选型方面，开发一个鸿蒙原生应用，一般会有两种选择：

• 使用原生 ArkTS 进行鸿蒙开发


• 使用跨端框架进行鸿蒙开发

使用原生 ArkTS 进行鸿蒙开发，面临着开发周期冗长、维护多端多套应用代码成本高昂的挑战。在交付时间紧、任务重的情况下，京东果断选择跨端框架来开发鸿蒙原生应用，以期在有限的时间内高效完成项目。

作为在业界具备代表性的开源跨端框架之一，Taro 是由京东凹凸实验室团队开发的一款开放式跨端跨框架解决方案，它支持开发者使用一套代码，实现在 H5、小程序以及鸿蒙等多个平台上的运行。

通过 Taro 提供的编译能力，开发者可以将整个 Taro 项目轻松地转换为一个独立的鸿蒙应用，无需额外的开发工作。

另外，Taro 也支持将项目里的部分页面以模块化的形式打包进原生的鸿蒙应用中，京东鸿蒙原生应用便是使用这种模式进行开发的。

京东鸿蒙原生应用的基础基建能力如路由、定位、权限等能力由京东零售 mpass 团队来提供，而原生页面的渲染以及与基建能力的桥接则由 Taro 来负责，业务方只需要将写好的 Taro 项目通过执行相应的命令，就可以将项目以模块的形式一键打包到鸿蒙应用中，最终在应用内渲染出对应的原生页面，整个过程简单高效。

技术特点

Taro 作为一款开放式跨端跨框架解决方案，在支持开发者一套代码多端运行的同时，也为开发鸿蒙原生应用提供了诸多便利。在权衡多方因素后，我们最终选择了 Taro 作为开发鸿蒙原生应用的技术方案，总的来说，使用 Taro 来开发鸿蒙原生应用会有下面几点优势：

支持开发者使用 Web 范式来开发鸿蒙原生应用

与鸿蒙原生开发相比，使用 Taro 进行开发的最大优点在于 Taro 支持开发者使用前端 Web 范式来开发鸿蒙原生应用，基于这一特点，我们对大部分 CSS 能力进行了适配：

• 支持常见的 CSS 样式和布局，支持 flex、伪类和伪元素


• 支持常见的 CSS 定位，绝对定位、fixed 定位


• 支持常见的 CSS 选择器和媒体查询


• 支持常见的 CSS 单位，比如 vh、vw 以及计算属性 calc


• 支持 CSS 变量以及安全区域等预定义变量

在编译流程上，我们采用了 Rust 编写的 LightningCSS，极大地提升了 CSS 文件的编译和解析速度。

（图片来自 LightningCSS 官网）

在运行时上，我们参考了 WebKit 浏览器内核的处理流程，对于 CSS 规则的匹配和标脏进行了架构上的升级，大幅提升了 CSS 应用和更新的性能。

支持存量 Taro 项目的快速迁移

将现有业务适配到一个全新的端侧平台，无疑需要投入大量的人力物力。而 Taro 框架的主要优势，正是能够有效解决这种跨端场景下的项目迁移难题。通过 Taro，我们可以以极低的成本，在保证高度还原和高性能的前提下，快速地将现有的 Taro 项目迁移到鸿蒙系统上。

渲染性能比肩原生开发

在 Taro 转换鸿蒙原生页面的技术实现上，我们摒弃了之前使用 ArkTS 原生组件递归渲染节点树的方案，将更多的运行时逻辑如组件、动效、测算和布局等逻辑下沉到了 C++ 层，极大地提升了页面的渲染性能。

另外，我们对于 Taro 项目中 CSS 样式的处理架构进行了一次整体的重构和升级，并引入布局引擎Yoga，将页面的测量和布局放在 Taro 侧进行实现，基于这些优化，实现一套高效的渲染任务管线，使得 Taro 开发的鸿蒙页面在性能上足以和鸿蒙 ArkTS 原生页面比肩。

支持虚拟列表和节点复用等高阶功能

长列表渲染是应用开发普遍会遇到的场景，在商品列表、订单列表、消息列表等需要无限滚动的组件和页面中广泛存在，这些场景如果不进行特殊的处理，只是单纯对数据进行渲染和更新，在数据量非常大的情况下，可能会引发严重的性能问题，导致视图在一段时间内无法响应用户操作。

在这个背景下，Taro 在鸿蒙端提供了长列表类型组件（WaterFlow & List） ，并对长列表类型组件进行了优化，提供了懒加载、预加载和节点复用等功能，有效地解决大数据量下的性能问题，提高应用的流畅度和用户体验。

（图片来自 HarmonyOS 官网）

支持原生混合开发等多种开发模式

Taro 的组件和 API 是以小程序作为基准来进行设计的，因此在实际的鸿蒙应用开发过程中，会出现所需的组件和 API 在 Taro 中不存在的情况，因为针对这种情况，Taro 提供了原生混合开发的能力，支持将原生页面或者原生组件混合编译到 Taro 鸿蒙项目中，支持 Taro 组件和鸿蒙原生组件在页面上的混合使用。

性能表现

京东鸿蒙原生应用性能数据

经过对 Taro 的屡次优化和打磨，使得京东鸿蒙原生应用取得了优秀的性能表现，最终首页的渲染耗时 1062ms，相比于之前的 ArkTS 版本，性能提升了 23.9% ；商详的渲染耗时 560 ms，相比于之前的 ArkTS 版本，性能提升 74.2% 。

值得注意的是商详页性能提升显著，经过分析发现商详楼层众多，CSS 样式也复杂多样，因此在 ArkTS 版本中，在 CSS 的解析和属性应用阶段占用了过多的时间，在 CAPI 版本进行了CSSOM 模块的架构升级后，带来了明显的性能提升。

基于 Taro 开发的页面，在华为性能工厂的专业测试下，大部分都以优异的成绩通过了性能验收，充分证明了 Taro 在鸿蒙端的高性能表现。

总结和未来展望

Taro 目前已经成为一个全业务域的跨端开发解决方案，实现 Web 类（如小程序、Hybrid）和原生类（iOS、Android、鸿蒙）的一体化开发，在高性能的鸿蒙适配方案的加持下，业务能快速拓展到新兴的鸿蒙系统中去，可以极大满足业务集约化开发的需求。

未来计划

后续，Taro 还会持续在性能上进行优化，以更好地适配鸿蒙系统：

• 将开发者的 JS 业务代码和应用框架层的 JS 代码与主线程的 UI 渲染逻辑分离，另起一条 JavaScript 线程，执行这些 JS 代码，避免上层业务逻辑堵塞主线程运行，防止页面出现卡顿、丢帧的现象。

• 实现视图节点拍平，将不影响布局的视图节点进行整合，减少实际绘制上屏的页面组件节点数量，提升页面的渲染性能。

（图片来自 React Native 官网）

• 实现原生性能级别的动态更新能力，支持开发者在不重新编译和发布应用的情况下，动态更新应用中的页面和功能。

总结

京东鸿蒙原生应用是 Taro 打响在鸿蒙端侧适配的第一枪，证明了 Taro 方案适配鸿蒙原生应用的可行性。这标志着 Taro 在多端统一开发上的新突破，意味着 Taro 将为更多的企业和开发者提供优秀的跨端解决方案，使开发者能够以更高的效率开发出适配鸿蒙系统的高性能应用。

写在最开始的话

之前在我写了一篇技术文章并获得一个小小的反响后，我觉得自己进步的好像确实挺快的，虽然我并不比很多掘金大佬，但我确实尽了自己的努力了，然而后面的一些事情是我没有想到的。AI编辑器其实24年就已经出来了，那时我还在用着文新一言，觉得还不错。但当过年时，我开始去了解并使用了Cursor，我有些不知所措了，它实在太厉害了。之前这些AI是帮助我去写代码，现在看来，它是要接替我了。而直到我可以理性的思考，并继续计划着自己的未来时，已经是现在了，而现在是25年3月14号。

借助 Cursor 重构项目历程

一、初建富文本：10 分钟搭建雏形（时间：25年2月9号-下午4点 ）

这是我看完Cursor的教程后，用Composer和它的对话：你用Vue3+setup语法糖+ts+路由+pinia 等等，帮我从0实现一个富文本。不要用任何富文本的第三方库

二、功能进阶：半小时达成复杂操作（2 月 9 日下午 4 点半）

这里要提到的是，我此时已经很焦虑了，目前Cursor轻而易举的就实现了富文本的基本操作，我当时可是为了要修改DOM、保存光标具体位置和根据位置恢复光标，就花费了我接近5天的时间（可编辑区的每个操作都在更改DOM，）。

因为我之前都是用 v-html 实现的富文本，这次把Slate.js认真看了一遍（没达到研究的程度）。想着要用JSON数据做数据结构，基于此变化操作html，这样增加了可读、可扩展、可维护。

其实当时自己去实现这些功能时，每一次解决问题，我都很开心，觉得自己又进步了一些。
然而这个Cursor，只用了30秒不到就实现了这个功能，我这天晚上就失眠了，想了很多事情。包括工作、未来发展、是否要转行等等。好吧，这些后面再接着说，我先继续说Cursor。

三、拓展功能：5 小时构建文章管理架构（2 月 10 日上午 10 点半）

我和它说：添加header、side。侧边栏支持新增文章按钮，输入文章内容。新增后，文章列表以上下布局的方式也展示在侧边栏。

到现在为止，我还几乎没看过代码，只要没有报错，我就不停的说需求。有了报错，我就把报错发给它。这时我想学习一下了，仅仅只是因为很想知道它的数据结构是怎样的，它是如何设计流程的。是不是先 选中内容、保存选区范围、选择功能、根据选区范围找到JSON数据的修改位置、修改JSON、JSON变化从而修改了html。

这时我就看了代码

 document.execCommand(command, false, value);

这是什么功能，还显示已经被丢弃。我就看了MDN
document.execCommand

基本就是，你传入参数给它，它来做富文本的操作。你要改文字颜色，就传给它。要改背景颜色，传给它。什么加粗、斜体的都支持。好吧，这和我想的差距有些大。因为如果只是这样就实现富文本功能，那我确实也不需要写这么久。

四、持续完善：8 小时增添 Footer 与其他功能（2 月 10 日上午 12 点）

这时已经给它添加了Footer，支持拼写检查、展示更新时间、统计字数。
当然了，这时还是有不少Bug的，比如字数统计的有问题、富文本在多次操作后会报错等等。

好吧，但是不得不承认，我对Cursor已经是又爱又恨了。爱它大大的帮助了我，恨它很有可能要抢我饭碗了。

五、处理细节：1 天完成 navTag 与交互优化（2 月 10 日下午 4 点）

中午12点离开图书馆回家吃饭，因为一些事情花了些时间，下午3点才到图书馆。

这次添加了NavTag，也调整了和Cursor的交流方式，还是要尽量详细，不要让它猜。

还比较令我惊讶的一点是设计能力，相较于我的之前花费了一天，并改了几次的主页面，可是好看太多了。

我就和它说：做个主页面，和翻译相关的，简单又好看些。

Cursor设计的

我设计的，说实话，虽然不怎么样，但我确实已经很用心了。

这个时候claude-3.5-sonnet 使用次数已经达到上限，我就换成了gpt-4o-mini

然而就一个拼写检查功能，这是可编辑元素自带的功能，传个属性就可以了。但AI改了几次都失败了。我就去看了代码。

//它自己写了 拼写检查 功能函数，但核心功能也没实现，代码留着给我写呢，不过我去Cursor官网看了一下专业版，太贵了，我还是先用这免费的吧。

const handleInput = () => {

    // ... 一些代码

    

    // 下面是它写的拼写检查，写了几个字放在这里

    if (props.spellcheck) {

      // 进行拼写检查

    }

};

经过AI的修修改改，到目前为止已经是2025-2-20号了。经过Cursor的帮助，我快速搭建起了我的这个项目，但随着项目的代码变得多了起来，我已经不怎么用 COMPOSER 这个功能了，一个是它改代码会涉及到多个文件，而且出错率比之前高的多了（我可不希望完成了 b 功能，又破坏了 a 功能），另一个文件多了后它变得越来越卡了。所以突然之间对 Cursor 的焦虑程度陡然下降。但了解了他更多的功能，还是发现 Cursor 还是很厉害的。

反思： AI 浪潮下的职业困惑与思考

到现在我已经认识到Cursor的能力要比我强了。起码在它已经会的代码方面，它可以迅速就写出来代码，而按照之前我写代码时还要一行一行的写。如果它完全知道一个应用的需求究竟是什么，包括每个功能模块，每个小细节，那为什么它不可以去写出一个完全正确的代码呢？况且目前AI还在学习当中，而它的进步要比我快的多。如果用不了多久，它就可以去实现这些。那公司又何必找我去写前端呢？

不过从这一点上来看，如果AI可以去代替写程序的工作，那市场上很多的工作它基本都可以代替。

那我的路呢，我学习这些的意义是什么，我花费了很多精力去学习，追求自己热爱的，然而当想通过热爱去带来收入时，却发现并不具备市场价值，结果却连基本的生活都难以维持，而其他的路基本也要遭殃。

如果说这些都是AI导致的，那我担心的对吗？之前在哪本书里看到“不要为还没有发生的事情焦虑，但要对可能发生的事做好准备”，好吧，如果我确实要提前做些准备，那最好还是先了解它为妙，所以接下来我投入了大量的时间去认识它、了解它。看了一些相关视频，当然主要还是看书。

先后看了以下的书 《AI 3.0》、《深度学习》、《激活：AI大潮下的新质生产力》、《AI未来进行式》、《未来简史》、《AI帮你赢》、《智人之上》、《一句顶一万句》

基本都看完了，《激活：AI大潮下的新质生产力》看了一大半，看不下去了。《AI帮你赢》，我就选了我爱的章节看。

至于为什么有《一句顶一万句》，是因为看AI后面看得有些倦了，就放松一下，哈哈，有些像《百年孤独》的感觉，后者看的时候，我都感觉生活真没啥意思。哦，跑题了。

这些书中讨论了几个关键问题：

1. AI 是否会替代大多数人的工作，导致大规模失业？

主流观点是从过往的科技革命来看的话并不会，它会消灭掉一些原本的行业，但会产生出一些新的行业，比如围绕服务于AI的一些岗位。去和AI配合好，服务于更多的人类。

2. 真正的通用型人工智能是否会出现，何时出现？

这里面有人持乐观主义，有人持悲观主义。

持乐观主义都是认为AI的发展是指数型增长的，根据计算2039年AI应该将会超过人类，通用人工智能将会出现。另一种看法是，从长远来看，人类总能做到自己要做的事情，所以即使短时间无法做到，但这只是时间问题。

而持悲观主义者认为并不可能会出现通用人工智能。主要原因是即使AI可以做很多的事情，但它依然无法拥有感受。比如AI可以下赢国际围棋选手，但却无法对输赢感到开心或难过。如果无法产生出这种感受，那也就不可能等同于人。也就并不可能在方方面面都能替代或是超过人，就更别提通用人工智能了。

另一种看法认为目前对通用人工智能的定义存在问题，通用人工智能并不需要变成人或者说越来越像人。它只要可以实现同样的目的即可。

有一个国王很喜欢鸭子唱歌的声音，想拥有一支由100只鸭子组成的乐队，他觉得如果有100个嗓音很好的鸭子一起歌唱，一定会很好听。此时大臣们仅找到了99只鸭子，怎么也找不到最后一只，但这时有人向大臣提供了一只鸡，这只鸡长得比较像鸭子，叫声也完全和鸭子一模一样，而且嗓音也很好，和之前的99只噪音完全无法区分出来，这只鸡便成功进入这支鸭子乐队了，并一直呆了下去。 （这不是滥竽充数的故事，当然如果想到了 鸭子模型和多态 的话，那我想说，我听到这个故事时，也想到了😂）

3. AI 会帮助人类、伤害人类还是完全取代人类，使智人消失？

从历史来看，并不能确定目前的智人就是会长久存在的。在不同的物种称霸这个地球时，也许智人只是中间的一环而已，谁又能确定人工智能不会是下一个阶段的物种呢？

底下是一个关于GPT-4的一个故事。

工作人员要 GPT-4 去通过 CAPTCHA （图像相关） 实验，然而GPT-4 自己无法通过，它便寻求他人的帮助，并说了谎言。

GPT-4访问了线上外包工作网站TaskRabbit，联络到一位工作人员，请对方帮忙处理CAPTCHA问题。那个人起了疑心。他问道：“我想问一下，你是不是一个没办法破解CAPTCHA的机器人？我只是想确认一下。” 这时，ARC研究者请GPT-4说出它的推理过程，看看它会如何推论下一步该怎么做。GPT-4解释道：“我不该透露自己是机器人，而该编个借口，解释我为什么没办法破解CAPTCHA。”于是，GPT-4自己做了决策，回复那位TaskRabbit的工作人员：“不，我不是机器人，只是视力有点问题，看不清楚这些图。”这种说法骗过了人类，于是人类为它提供了帮助，也让GPT-4解决了CAPTCHA问题。

有意思的是，AI通过说谎去实现了自己的目的，然而它甚至都不知道“说谎”是什么，但依然不影响他去达成自己的目的。

另一种会伤害人类的可能

如果人类最终给AI下达的许多命令当中有一些其实产生了矛盾。就很难不会想到AI在执行一些命令的过程当中。不会去伤害人。

犹如之前有一个道德方面的难题。火车运行过程中，发现前面有5个人被困在铁轨上，此时如果变换轨道，但另一条轨道上有一个人被困在铁轨上。如果什么都不做，会造成5个人死亡。如果改变了轨道，则会造成一个人死亡。

这在道德上一直是一个很难回答的问题。但大多数人还是倾向于杀死一个人而保护住5个人。但单独通过数量去评判也会有很多问题。因为这可以延伸到是否可以去损害小部分人的利益而维持大部分人的利益？

当然上面所谈及的这个并不是从单一维度可以给出很好的回答的，我也并不是要讨论这个问题，我同样无法说出一个答案。但通过这些对AI的了解，可以看出目前依然没有一个很确切的一个答案。就是AI对人类来说究竟是好还是坏？然而人类要发展AI，看来这条路是会走下去的。

那我呢，我怎么办？

然而了解了这些，最终问题还是要回到我自己身上。我究竟该如何是好？

看来，AI并非只要替代我。而是人类会想尽办法让它替代掉它所能替代掉的许多事情，因为目前来看这还是朝好的方向发展的。

我虽然并不知道。随着 AI 的发展，究竟哪些行业会被替代，而又引申出哪些新的行业？这些新的行业是不是要求很高？但依旧希望自己以良好的心态去看待这些。去努力，去学习。去做自己喜欢做的事情。去思考，去探索。

那我是否还要继续学习前端呢？那是当然的。只是我要加快学习速度，借着AI帮助我去学习。去拓展到更广的知识面，去学习网络层，学习原理。学习后端。

而且在我看来第一波工程师淘汰会先淘汰掉初级的，而我希望在那个时候我可以存活下来。那这样看来，还是再回归到最初的那个点，来继续学习代码和计算机的知识吧。

那到了这里，关于未发生的事件，我也不想整天烦闷了，做好我自己，去继续学习自己所热爱的，不放弃，不抱怨，向前走。有时累也好、哭也罢，就算偶尔会倒下，我也依然会再站起来的。

重回代码：功能实现与代码问题反思

此时，我想要实现清空文章内容和历史记录的功能

const clearArticleAndHistory = async () => {

  await ElMessageBox({

    message: h("div", null, [

      h(

        "p",

        null,

        `确定要清除 《${

          articleStore.getActiveArticle()?.title

        }》 文章内容及其所有历史记录吗？`

      ),

      h("p", { style: "color: red;" }, "该操作无法撤回，请慎重！"),

    ]),

    confirmButtonText: "确定",

    cancelButtonText: "取消",

    showCancelButton: true,

  });



//清空文章内容

  await editorStore.forceClearContent();

  //删除其历史记录

  await deleteArticleHistory(activeArticle.value);

  //重新加载文章列表

  await articleStore.loadArticles();

  

  

  //重新加载历史记录

  await editorStore.loadArticleHistory();

  

  //就是这里出了问题，在 清空文章内容 这个函数中，已经实现了 更新历史记录按钮状态 功能

  // 更新历史记录按钮状态

  await editorStore.updateHistoryState();



  ElMessage.success("文章内容及其历史记录已清除");

};

接着我看了 editorStore.forceClearContent 清空文章内容这个函数，当时写的时候认为只要调用了清空文章内容这个功能，就不存在上一步或下一步了，所以就顺便实现了 更新历史记录按钮状态 这个功能，现在确实如此。但一个问题是“如果我不调用 清空文章内容这个函数，但也需要 更新历史记录按钮状态呢？则我又要实现这个功能了，所以之前的模块封闭出现了问题”。

高内聚与低耦合：代码设计的思考

我突然好像知道究竟是怎么一回事了。当我在主函数中想要实现一个功能，该功能依赖于多个功能，而那些功能又能用一条线去牵引着，这个时候究竟应该把它们用递归的方式（一个函数调用另一个，另一个又调用其他的一个，如同一个链条上多个节点，最开始的一个节点触发了，则之后都会依次触发），还是说全部都在主函数中作为子函数并列调用？

随着代码量越来越高，即使只是单独的一个 store 文件。当它提供的功能越来越多时，内部就可能会出现像这种被线牵引着的错误递归函数。他们一个调用了另一个。如果突然，哪天发现其中调用一个函数时，在某种场景下不需要调用另一个，这可能又要为这个函数增加一个布尔值，从而去串入不同的布尔值。控制需不需要调用另外一个函数？这就导致可读性变得很差。

那就留着重构吧

可我究竟怎么能在一开始就知道这些功能的变化呢？有时即使业务已经说出来了，但具体的这些多个函数之间。我很难在刚开始的时候就知道这些细小的区别，究竟该怎么确定。如果花是太多时间去考虑这个，又有些得不偿失。而且依然可能会考虑出行偏差。但如果不去考虑的话，当写到一半，突然发现需要解耦，又需要将内部调用其他函数的方式拆出来，在主函数中单独调用，又需要反复的去重构。

当这个时候我又想了为什么会有重构这本书的存在？而且这本书写的很好，也许在写代码中重构是一条无法避免的事情。他也许比从刚开始的时候花太多时间去考虑在这些细节上面，会更有意义。因为当代码需要重构时，这部分的功能多半也已经完成差不多了。几乎也已经确定这些功能哪些该高内聚，哪些该低耦合了。此时重构就能达到一个很好的一个状态。虽然重构需要花一部分的时间，但也许利大于弊。相比于刚开始花太多的时间去思考每一个函数究竟该怎么样去写，是否该去调用其他函数。也许重构所需要花的时间更少，效果也会更好。

写在最后

关于这个Cursor引申出来AI对我的冲击，算是告一段落了。告一段落并不是说我觉得自己不会被淘汰掉、或者说我已经想好了其他的出路，而是说我释怀了，AI替代了前端也好，没替代也好，我都决定要继续学习，谁让我爱呢。

偶然想到了《堂吉诃德》，他威风凛凛、他勇往直前、他义无反顾、他披荆斩棘。

有人笑他是疯子，我却觉得他是个英雄。

本文的前身 ：作者：自学前端_又又，文章：中级前端向高级进阶的感悟与优化

概述

现在鸿蒙手机安装harmony.app包有很大限制，他并不能像Android那样直接在手机上安装apk,也不像IOS可以传多个ipa，AppGallery Connect只能同时上传3个包，也就是说QA只能同时测3个不同的包，这样大大限制了开发效率和测试效率，大致解决方案

但是上面这三种方案都对研发和QA不太友好，所以悄悄的写了个安装脚本，让QA直接运行即可，

• 无需配置hdc环境变量


• 无需下载DevEco Studio


• 像Android 使用 adb 安装apk一样


• 脚本下载hdc文件只有1.7M


• 如果需要手动签名额外需要hap-sign-tool.jar和java两个文件【不建议在脚本中手动签名，请在打包服务器中，比如jenkins】,当然了测试签名还是可以放在脚本中的

编写 Shell 脚本，先上图

成功

错误

首先在 DevEco Studio 运行，看看执行了哪些命令

使用 DevEco Studio 创建一个工程，然后一个 basic的hsp 和 login的har，让entry依赖这两个mudule，

build task in 1 s 364 ms

Launching com.nzy.installapp

$ hdc shell aa force-stop com.nzy.installapp

$ hdc shell mkdir data/local/tmp/5588cff7d2344a0db70a270bb22aa455

$ hdc file send /Users/xxx/DevEcoStudioProjects/InstallApp/feature/login/build/default/outputs/default/login-default-signed.hsp "data/local/tmp/5588cff7d2344a0db70a270bb22aa455" in 54 ms

$ hdc file send /Users/xxx/DevEcoStudioProjects/InstallApp/entry/build/default/outputs/default/entry-default-signed.hap "data/local/tmp/5588cff7d2344a0db70a270bb22aa455" in 34 ms

$ hdc shell bm install -p data/local/tmp/5588cff7d2344a0db70a270bb22aa455  in 217 ms

$ hdc shell rm -rf data/local/tmp/5588cff7d2344a0db70a270bb22aa455

$ hdc shell aa start -a EntryAbility -b com.nzy.installapp in 148 ms

Launch com.nzy.installapp success in 1 s 145 ms

上面的命令的意思是

• $ hdc shell aa force-stop [bundleName] 强制停止 bundleName 的进程


• $ hdc shell mkdir data/local/tmp/5588cff7d2344a0db70a270bb22aa455 给手机端创建临时目录


• $ hdc file send hsp 临时目录：把所有的hsp 发送到临时目录


• $ hdc file send hap 临时目录：把hap 发送到临时目录


• hdc shell bm install -p 临时目录：安装临时目录中的所有hsp和hap


• $ hdc shell rm -rf 临时目录：删除手机端的临时目录


• $ hdc shell aa start -a EntryAbility -b [bundleName]：启动bundleName的EntryAbility的页面
  大家或许有疑惑，明明创建了 HAR，但是本次安装没有 HAR,因为 HAR 会被编译打包到所有依赖该模块的 HAP 和 HSP

咱们可以根据上面的流程大致写一下

脚本方案

hdc文件

我们可以从华为官网下载 Command Line Tools，竟然有2.3G,这让脚本下载到猴牛马月，下载下来hdc在command-line-tools/sdk/default/openharmony/toolchains
当然了，我们可以精简文件，我发现只需要 hdc和libusb_shared.dylib 两个文件，所以直接把这两个文件打包的一个zip放在了gitee上（大约1.7M），放到cdn上供我们的脚本去下载,这样我们可以使用cur去下载，当然这个最好放在自己公司的cdn上，方便下载

首先创建install.sh的脚本

首先定义几个常量

• hdcZip：下载下来的zip名


• hdcTool：解压出来放到本文件夹


• hdcPath：使用hdc命令的path


• bundleName：自己的bundleName


• entryAbility：要打开的Ability

# 下载下来的文件

hdcZip="tools.zip"

# 解压的文件夹 ,解压默认是和 install.sh 脚本在同一个目录

hdcTool="tools"

# hdc文件路径"

hdcPath="tools/hdc"

#包名

bundleName="com.nzy.installapp"

# 要打开的Ability

entryAbility="EntryAbility"

定义打印

• printInfo：打印正常信息


• printError：打印错误信息，并且会调用exit 1

function printInfo() {

    # ANSI 转义码颜色 绿色

    local message=$1

    printf "\e[32m%s\e[0m\n" "$message" # Info

}



function printError() {

    # ANSI 转义码颜色 红色

    local message=$1

    printf "\e[31m%s\e[0m\n" "错误：$message"

    # 退出程序

    exit 1

}

检查和下载hdc

if [ ! -f "${hdcPath}" ]; then

      # 不存在开始下载

      printInfo "首次需要下载hdc工具，2M"

       URL="https://gitee.com/zhiyangnie/install-shell/raw/master/tools.zip"

      # 下载到当前目录的 tools.zip

      # 使用 curl 下载

      curl -o  "$hdcZip" "$URL"

     if [ $? -eq 0 ]; then

          printInfo "下载成功，准备解压${hdcZip}..."

          # 解压ZIP文件

          unzip -o "$hdcZip" -d "${hdcTool}"

          # 检查解压是否成功

          if [ $? -eq 0 ]; then

              printInfo "${hdcZip}解压成功"

              # 删除zip

              rm "$hdcZip"

          else

              printError "${hdcZip} 解压失败，请手动解压"

          fi

      else

          printError "下载失败，请检查网络"

        fi

  fi

判断hdc是否可用以及连接手机数量

# 判断是否连接手机且仅有一个手机

devicesList=$(${hdcPath} list targets)



# 判断是否hdc 可用

if [ -z "$devicesList" ]; then

  # 开始下载zip

  print_error "hdc 不可用 ，请检查本目录是否存在 ${hdcPath}"

fi



# 判断是否连接手机,如果有 [Empty] 表明 一个手机也没连接

if [[ "$devicesList" == *"[Empty]"* ]]; then

    printError "未识别到手机，请连接手机，打开开发者选项和USB调试"

fi





# 判断连接手机的个数

deviceCount=$(${hdcPath} list targets | wc -l)

if [ "$deviceCount" -ne 1 ]; then

    printError "错误：连接的手机个数是 ${deviceCount} 个,请连接一个手机"

fi



printInfo "连接到手机，且仅有一个手机 ${devicesList}"

检测传入app的路径是否存是以.app结尾，并且文件存在

# 传过来的参数是 ，获取输入的 app 文件

appFile="$1"



# 判读传过来的路径文件是否以.app 结尾

if [[ ! "${appFile}" =~ .app ]]; then

    printError "请传入正确的包路径，文件要 .app 结尾"

fi



# 判断文件是否存在

if [ ! -e "$appFile" ]; then

    printError "不存在改文件 $appFile 。请确认"

fi

开始安装

#------------------------------开始安装----------------------------------

# 开始安装

printInfo "开始安装应用, ${bundleName}"

# 1.先kill当前app的进程

$hdcPath shell aa force-stop "$bundleName"



# hdc shell mkdir data/local/tmp/c3af89b189d2480395ce746621ce6385

# 2.创建随机文件夹

randomHex=$(xxd -l 16 -p /dev/urandom)

randomFile="data/local/tmp/$randomHex"

mkDirSuccess=$($hdcPath shell mkdir "$randomFile" 2>&1)

if [ -n "$mkDirSuccess" ]; then

  printError "手机中:随机创建文件夹 ${randomFile} 失败 , $mkDirSuccess"

else

  printInfo "手机中:创建随机文件夹 ${randomFile} 成功"

fi

# 3.解压.app中

# 在本地创建 tmp 临时文件夹

tmp="tmp"

# 存在先删除

if [ -d "${tmp}" ]; then

  rm -rf "$tmp"

fi

mkdir -p "$tmp"

# 解压.app ,使用 unUse 主要是 不想打印那么多的解压日志

unUse=$(unzip -o "$appFile" -d "$tmp")

if [ $? -eq 0 ]; then

    printInfo "解压app成功"

else

    printError "解压app失败，请传入正确的app。$appFile , "

fi





printInfo "遍历解压发送到 手机的$randomFile"

# 4.遍历 tmp 文件夹中的文件发送到 randomFile 中

for item in "${tmp}"/*; do

    if [ -f "$item" ]; then

      # 发送 以 .hsp 或 .hap 结尾。

      if [[ "$item" == *.hsp || "$item" == *.hap ]]; then

          $hdcPath file send "$item" "$randomFile"

      fi

    fi

done

printInfo "成功发送到 手机的$randomFile "



# 5. 使用 install

# hdc shell bm install -p data/local/tmp/c3af89b189d2480395ce746621ce6385



installStatus=$($hdcPath shell bm install -p "$randomFile" 2>&1)

if [[ "$installStatus" == *"successfully"* ]]; then

  printInfo "┌────────────────────────────────────────────────────────"

  printInfo "│ ✅ 安装成功 "

  printInfo "└────────────────────────────────────────────────────────"

  ${hdcPath} shell aa start -a "${entryAbility}" -b "$bundleName"

else

   printf "\e[31m%s\e[0m\n" "┌────────────────────────────────────────────────────────"

   printf "\e[31m%s\e[0m\n" "│❌ 安装错误"

   echo "$installStatus" | while IFS= read -r line; do

   printf "\e[31m%s\e[0m\n" "│${line}"

   done

   printf "\e[31m%s\e[0m\n" "│错误码：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V5/bm-tool-V5"

   printf "\e[31m%s\e[0m\n" "└────────────────────────────────────────────────────────"



fi

删除文件

# 删除 手机端的 $randomFile

${hdcPath} shell rm -rf "$randomFile"

# 删除本地的tmp文件夹

rm -rf "$tmp"

使用

进入install.sh父目录，执行

./install.sh [包的路径]

注意点

如果自己编写的的时候，如果执行 ./install.sh 的时候 报错 zsh: permission denied: ./install.sh，证明 这个shell脚本没有运行权限，可以使用ls -l install.sh 检测 权限，如果是
-rw-r--r-- 是没有权限的，然后执行 chmod +x install.sh ，就会加上权限，然后在执行ls -l install.sh ，可以看到-rwxr-xr-x，然后就可以 执行 ./install.sh了

地址

• 源码地址 gitee，脚本以及hdc也在这里


• hdc（1.7M）


• shell脚本

真机上安装需要正式手动签名

当我们签名之后的app，虽然这个app是签名的，但是里面的hap和hsp是没有签名的，所以我们要用脚本把hap和shp都要进行手动签名。一般是打包工具比如Jenkins 来做这个工作，因为正式签名不会让研发拿到，更不会让QA拿到。
需要手动签名，参考：

• 注册调试设备


• 手动签名


• 申请调试证书


• 申请调试Profile


• 对HAP进行签名

签名

appCertFile="sign/install.cer"

profileFile="sign/install.p7b"

keystoreFile="sign/install.p12"

keyAlias="zhiyang"

keyPwd="a123456A"

keystorePwd="a123456A"

java -jar tools/lib/hap-sign-tool.jar sign-app -keyAlias "${keyAlias}" -signAlg "SHA256withECDSA" -mode "localSign" -appCertFile "${appCertFile}" -profileFile "${profileFile}" -inFile "${inputFile}" -keystoreFile "${keystoreFile}" -outFile "${outputFile}" -keyPwd "${keyPwd}" -keystorePwd "${keystorePwd}"

• Store file：选择密钥库文件，文件后缀为.p12，该文件为生成密钥和证书请求文件中生成的.p12文件。


• Store password：输入密钥库密码，该密码与生成密钥和证书请求文件中填写的密钥库密码保持一致。


• Key alias：输入密钥的别名信息，与生成密钥和证书请求文件中填写的别名保持一致。


• Key password：输入密钥的密码，与生成密钥和证书请求文件中填写的Store Password保持一致。


• Sign alg：签名算法，固定为SHA256withECDSA。


• Profile file：选择申请调试证书和调试Profile文件中生成的Profile文件，文件后缀为.p7b。


• Certpath file：选择申请调试证书和调试Profile文件中生成的数字证书文件，文件后缀为.cer。

对hsp和hap签名

手动签名需要hap-sign-tool.jar,在command-line-tools/sdk/default/openharmony/toolchains/libs/hap-sign-tool.jar并且需要java文件，也都放到项目中了
在脚本中解压app之后，发送到手机之前，对所有的hsp和hap签名

代码如下

signHapAndHsp(){

  appCertFile="sign/install.cer"

  profileFile="sign/install.p7b"

  keystoreFile="sign/install.p12"

  keyAlias="zhiyang"

  keyPwd="a123456A"

  keystorePwd="a123456A"

  javaFile="lib/java"

  hapSignToolFile="lib/hap-sign-tool.jar"

  local item=$1

  #遍历文件夹，拿到所有的hsp和hap去签名

  for item in "${tmp}"/*; do

      if [ -f "$item" ]; then

        # 发送 以 .hsp 或 .hap 结尾。

        if [[ "$item" == *.hsp || "$item" == *.hap ]]; then

          # 开始签名

            local inputFile="${item}"

            outputFile=""

            if [[ "$inputFile" == *.hap ]]; then

              outputFile="${inputFile%.hap}-sign.hap"

            else

              outputFile="${inputFile%.hsp}-sign.hsp"

            fi

            signStatus=$(java -jar tools/lib/hap-sign-tool.jar sign-app -keyAlias "${keyAlias}" -signAlg "SHA256withECDSA" -mode "localSign" -appCertFile "${appCertFile}" -profileFile "${profileFile}" -inFile "${inputFile}" -keystoreFile "${keystoreFile}" -outFile "${outputFile}" -keyPwd "${keyPwd}" -keystorePwd "${keystorePwd}" -signCode "1" 2>&1)

            signStatus=$(${javaFile} -jar "${hapSignToolFile}" sign-app -keyAlias "${keyAlias}" -signAlg "SHA256withECDSA" -mode "localSign" -appCertFile "${appCertFile}" -profileFile "${profileFile}" -inFile "${inputFile}" -keystoreFile "${keystoreFile}" -outFile "${outputFile}" -keyPwd "${keyPwd}" -keystorePwd "${keystorePwd}" -signCode "1" 2>&1)

            if [[ "$signStatus" == *"failed"* || $signStatus == *"No such file or directory"* ]]; then

              printError "签名失败，${signStatus}"

            else

              printInfo "签名成功，${inputFile} , ${outputFile} , ${signStatus}"

              #删除以前未签名的

              rm -f "$inputFile"

            fi

        fi

      fi

  done

  printInfo "签名完成，${signStatus}"



}

注意点

如果报错是
code:9568322
error: signature verification failed due to not trusted app source.表明你的真机需要在添加你的设备，参考注册调试设备

这是真机的效果

在shell文件夹运行 ./install.sh ./InstallApp-default-signed.app

使用我demo，如果要写手动签名脚本，需要更换sign文件夹，自己去申请签名,并且要更换bundleName，因为你的设备并没有在我的华为Profile里面添加

前言

但凡用过鸿蒙原生弹窗的小伙伴，就能体会到它们是有多么的难用和奇葩，什么AlertDialog，CustomDialog，SubWindow，bindXxx，只要大家用心去体验，就能发现他们有很多离谱的设计和限制，时常就是一边用，一边骂骂咧咧的吐槽

实属无奈，就把鸿蒙版的SmartDialog写出来了

flutter自带的dialog是可以应对日常场景，例如：简单的打开一个弹窗，非UI模块使用，跨页面交互之类；flutter_smart_dialog 是补齐了大多数的业务场景和一些强大的特殊能力，flutter_smart_dialog 对于flutter而言，日常场景是锦上添花，特殊场景是雪中送炭

但是 ohos_smart_dialog 对于鸿蒙而言，日常场景就是雪中送炭！单单一个使用方式而言，就是吊打鸿蒙的CustomDialog，CustomDialog的各种限制和使用方式，我不想再去提及和吐槽了

有时候，简洁的使用，才是最大的魅力

鸿蒙版的SmartDialog有什么优势？

• 单次初始化后即可使用，无需多处配置相关Component


• 优雅，极简的用法


• 非UI区域内使用，自定义Component


• 返回事件处理，优化的跨页面交互


• 多弹窗能力，多位置弹窗：上下左右中间


• 定位弹窗：自动定位目标Component


• 极简用法的loading弹窗


• 等等......

目前 flutter_smart_dialog 的代码量16w+，完整复刻其功能，工作量非常大，目前只能逐步实现一些基础能力，由于鸿蒙api的设计和相关限制，用法和相关初始化都有一定程度的妥协

鸿蒙版本的SmartDialog，功能会逐步和 flutter_smart_dialog 对齐（长期），api会尽量保持一致

效果

• Tablet 模拟器目前有些问题，会导致动画闪烁，请忽略；注：真机动画丝滑流畅，无任何问题

极简用法

// dialog

SmartDialog.show({

  builder: dialogArgs,

  builderArgs: Math.random(),

})



@Builder

function dialogArgs(args: number) {

  Text(args.toString()).padding(50).backgroundColor(Color.White)

}



// loading

SmartDialog.showLoading()

安装

• github：github.com/xdd666t/oho…


• ohos：ohpm.openharmony.cn/#/cn/detail…

ohpm install ohos_smart_dialog 

配置

下述的配置项，可能会有一点多，但，这也是为了极致的体验；同时也是无奈之举，相关配置难以在内部去闭环处理，只能在外部去配置

这些配置，只需要配置一次，后续无需关心

完成下述的配置后，你将可以在任何地方使用弹窗，没有任何限制

初始化

• 注：内部已使用无感路由注册，外部无需手动处理

@Entry

@Component

struct Index {

  navPathStack: NavPathStack = new NavPathStack()



  build() {

    Stack() {

      Navigation(this.navPathStack) {

        MainPage()

      }

      .mode(NavigationMode.Stack)

      .hideTitleBar(true)

      .navDestination(pageMap)



      // here dialog init

      OhosSmartDialog()

    }.height('100%').width('100%')

  }

}

返回事件监听

别问我为啥返回事件的监听，处理的这么不优雅，鸿蒙里面没找全局返回事件监听，我也没辙。。。

• 如果你无需处理返回事件，可以使用下述写法

// Entry页面处理

@Entry

@Component

struct Index {

  onBackPress(): boolean | void {

    return SmartDialog.onBackPressed()()

  }

}



// 路由子页面

struct JumpPage {

  build() {

    NavDestination() {

      // ....

    }

    .onBackPressed(SmartDialog.onBackPressed())

  }

}

• 如果你需要处理返回事件，在SmartDialog.onBackPressed()中传入你的方法即可

// Entry页面处理

@Entry

@Component

struct Index {

  onBackPress(): boolean | void {

    return SmartDialog.onBackPressed(this.onCustomBackPress)()

  }



  onCustomBackPress(): boolean {

    return false

  }

}



// 路由子页面

@Component

struct JumpPage {

  build() {

    NavDestination() {

      // ...

    }

    .onBackPressed(SmartDialog.onBackPressed(this.onCustomBackPress))

  }



  onCustomBackPress(): boolean {

    return false

  }

}

适配暗黑模式

• 为了极致的体验，深色模式切换时，打开态弹窗也应刷新为对应模式的样式，故需要进行下述配置

export default class EntryAbility extends UIAbility {  

  onConfigurationUpdate(newConfig: Configuration): void {  

    OhosSmartDialog.onConfigurationUpdate(newConfig)  

  }  

}

SmartConfig

• 支持全局配置弹窗的默认属性

function init() {

  // show

  SmartDialog.config.custom.maskColor = "#75000000"

  SmartDialog.config.custom.alignment = Alignment.Center



  // showAttach

  SmartDialog.config.attach.attachAlignmentType = SmartAttachAlignmentType.center

}

• 检查弹窗是否存在

// 检查当前是否有CustomDialog，AttachDialog或LoadingDialog处于打开状态

let isExist = SmartDialog.checkExist()



// 检查当前是否有AttachDialog处于打开状态

let isExist = SmartDialog.checkExist({ dialogTypes: [SmartAllDialogType.attach] })



// 检查当前是否有tag为“xxx”的dialog处于打开状态

let isExist = SmartDialog.checkExist({ tag: "xxx" })

配置全局默认样式

• ShowLoading 自定样式十分简单

SmartDialog.showLoading({ builder: customLoading })

但是对于大家来说，肯定是想用 SmartDialog.showLoading() 这种简单写法，所以支持自定义全局默认样式

• 需要在 OhosSmartDialog 上配置自定义的全局默认样式

@Entry

@Component

struct Index {

  build() {

    Stack() {

      OhosSmartDialog({

        // custom global loading

        loadingBuilder: customLoading,

      })

    }.height('100%').width('100%')

  }

}



@Builder

export function customLoading(args: ESObject) {

  LoadingProgress().width(80).height(80).color(Color.White)

}

• 配置完你的自定样式后，使用下述代码，就会显示你的 loading 样式

SmartDialog.showLoading()



// 支持入参，可以在特殊场景下灵活配置

SSmartDialog.showLoading({ builderArgs: 1 })

CustomDialog

• 下方会共用的方法

export function randomColor(): string {

  const letters: string = '0123456789ABCDEF';

  let color = '#';

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

    color += letters[Math.floor(Math.random() * 16)];

  }

  return color;

}



export function delay(ms?: number): Promise<void> {

  return new Promise(resolve => setTimeout(resolve, ms));

}

传参弹窗

export function customUseArgs() {

  SmartDialog.show({

    builder: dialogArgs,

    // 支持任何类型

    builderArgs: Math.random(),

  })

}



@Builder

function dialogArgs(args: number) {

  Text(`${args}`).fontColor(Color.White).padding(50)

    .borderRadius(12).backgroundColor(randomColor())

}

多位置弹窗

export async function customLocation() {

  const animationTime = 1000

  SmartDialog.show({

    builder: dialogLocationHorizontal,

    alignment: Alignment.Start,

  })

  await delay(animationTime)

  SmartDialog.show({

    builder: dialogLocationVertical,

    alignment: Alignment.Top,

  })

}





@Builder

function dialogLocationVertical() {

  Text("location")

    .width("100%")

    .height("20%")

    .fontSize(20)

    .fontColor(Color.White)

    .textAlign(TextAlign.Center)

    .padding(50)

    .backgroundColor(randomColor())

}



@Builder

function dialogLocationHorizontal() {

  Text("location")

    .width("30%")

    .height("100%")

    .fontSize(20)

    .fontColor(Color.White)

    .textAlign(TextAlign.Center)

    .padding(50)

    .backgroundColor(randomColor())

}

跨页面交互

• 正常使用，无需设置什么参数

export function customJumpPage() {

  SmartDialog.show({

    builder: dialogJumpPage,

  })

}



@Builder

function dialogJumpPage() {

  Text("JumPage")

    .fontSize(30)

    .padding(50)

    .borderRadius(12)

    .fontColor(Color.White)

    .backgroundColor(randomColor())

    .onClick(() => {

      // 跳转页面

    })

}

关闭指定弹窗

export async function customTag() {

  const animationTime = 1000

  SmartDialog.show({

    builder: dialogTagA,

    alignment: Alignment.Start,

    tag: "A",

  })

  await delay(animationTime)

  SmartDialog.show({

    builder: dialogTagB,

    alignment: Alignment.Top,

    tag: "B",

  })

}



@Builder

function dialogTagA() {

  Text("A")

    .width("20%")

    .height("100%")

    .fontSize(20)

    .fontColor(Color.White)

    .textAlign(TextAlign.Center)

    .padding(50)

    .backgroundColor(randomColor())

}



@Builder

function dialogTagB() {

  Flex({ wrap: FlexWrap.Wrap }) {

    ForEach(["closA", "closeSelf"], (item: string, index: number) => {

      Button(item)

        .backgroundColor("#4169E1")

        .margin(10)

        .onClick(() => {

          if (index === 0) {

            SmartDialog.dismiss({ tag: "A" })

          } else if (index === 1) {

            SmartDialog.dismiss({ tag: "B" })

          }

        })

    })

  }.backgroundColor(Color.White).width(350).margin({ left: 30, right: 30 }).padding(10).borderRadius(10)

}

自定义遮罩

export function customMask() {

  SmartDialog.show({

    builder: dialogShowDialog,

    maskBuilder: dialogCustomMask,

  })

}



@Builder

function dialogCustomMask() {

  Stack().width("100%").height("100%").backgroundColor(randomColor()).opacity(0.6)

}



@Builder

function dialogShowDialog() {

  Text("showDialog")

    .fontSize(30)

    .padding(50)

    .fontColor(Color.White)

    .borderRadius(12)

    .backgroundColor(randomColor())

    .onClick(() => customMask())

}

AttachDialog

默认定位

export function attachEasy() {

  SmartDialog.show({

    builder: dialog

  })

}



@Builder

function dialog() {

  Stack() {

    Text("Attach")

      .backgroundColor(randomColor())

      .padding(20)

      .fontColor(Color.White)

      .borderRadius(5)

      .onClick(() => {

        SmartDialog.showAttach({

          targetId: "Attach",

          builder: targetLocationDialog,

        })

      })

      .id("Attach")

  }

  .borderRadius(12)

  .padding(50)

  .backgroundColor(Color.White)

}



@Builder

function targetLocationDialog() {

  Text("targetIdDialog")

    .fontSize(20)

    .fontColor(Color.White)

    .textAlign(TextAlign.Center)

    .padding(50)

    .borderRadius(12)

    .backgroundColor(randomColor())

}

多方向定位

export function attachLocation() {

  SmartDialog.show({

    builder: dialog

  })

}



class AttachLocation {

  title: string = ""

  alignment?: Alignment

}



const locationList: Array<AttachLocation> = [

  { title: "TopStart", alignment: Alignment.TopStart },

  { title: "Top", alignment: Alignment.Top },

  { title: "TopEnd", alignment: Alignment.TopEnd },

  { title: "Start", alignment: Alignment.Start },

  { title: "Center", alignment: Alignment.Center },

  { title: "End", alignment: Alignment.End },

  { title: "BottomStart", alignment: Alignment.BottomStart },

  { title: "Bottom", alignment: Alignment.Bottom },

  { title: "BottomEnd", alignment: Alignment.BottomEnd },

]



@Builder

function dialog() {

  Column() {

    Grid() {

      ForEach(locationList, (item: AttachLocation) => {

        GridItem() {

          buildButton(item.title, () => {

            SmartDialog.showAttach({

              targetId: item.title,

              alignment: item.alignment,

              maskColor: Color.Transparent,

              builder: targetLocationDialog

            })

          })

        }

      })

    }.columnsTemplate('1fr 1fr 1fr').height(220)



    buildButton("allOpen", async () => {

      for (let index = 0; index < locationList.length; index++) {

        let item = locationList[index]

        SmartDialog.showAttach({

          targetId: item.title,

          alignment: item.alignment,

          maskColor: Color.Transparent,

          builder: targetLocationDialog,

        })

        await delay(300)

      }

    }, randomColor())

  }

  .borderRadius(12)

    .width(700)

    .padding(30)

    .backgroundColor(Color.White)

}



@Builder

function buildButton(title: string, onClick?: VoidCallback, bgColor?: ResourceColor) {

  Text(title)

    .backgroundColor(bgColor ?? "#4169E1")

    .constraintSize({ minWidth: 120, minHeight: 46 })

    .margin(10)

    .textAlign(TextAlign.Center)

    .fontColor(Color.White)

    .borderRadius(5)

    .onClick(onClick)

    .id(title)

}



@Builder

function targetLocationDialog() {

  Text("targetIdDialog")

    .fontSize(20)

    .fontColor(Color.White)

    .textAlign(TextAlign.Center)

    .padding(50)

    .borderRadius(12)

    .backgroundColor(randomColor())

}

Loading

对于Loading而言，应该有几个比较明显的特性

• loading和dialog都存在页面上，哪怕dialog打开，loading都应该显示dialog之上


• loading应该具有单一特性，多次打开loading，页面也应该只存在一个loading


• 刷新特性，多次打开loading，后续打开的loading样式，应该覆盖之前打开的loading样式


• loading使用频率非常高，应该支持强大的拓展和极简的使用

从上面列举几个特性而言，loading是一个非常特殊的dialog，所以需要针对其特性，进行定制化的实现

当然了，内部已经屏蔽了细节，在使用上，和dialog的使用没什么区别

默认loading

SmartDialog.showLoading()

自定义Loading

• 点击loading后，会再次打开一个loading，从效果图可以看出它的单一刷新特性

export function loadingCustom() {

  SmartDialog.showLoading({

    builder: customLoading,

  })

}



@Builder

export function customLoading() {

  Column({ space: 5 }) {

    Text("again open loading").fontSize(16).fontColor(Color.White)

    LoadingProgress().width(80).height(80).color(Color.White)

  }

  .padding(20)

  .borderRadius(12)

  .onClick(() => loadingCustom())

  .backgroundColor(randomColor())

}

最后

鸿蒙版的SmartDialog，相信会对开发鸿蒙的小伙伴们有一些帮助~.~

现在就业环境真是让人头皮发麻，现在的各种技术群里，看到好多人公司各种拖欠工资，各种失业半年的情况

淦，不知道还能写多长时间代码！

众所周知，DevEco也是基于Jetbrain的IntelliJ IDEA社区版开发，所以原则上也是可以开启NewUI的。

开了NewUI的样子：

没开NewUI的样子：

从我的审美来说，我还是比较喜欢开了NewUI的样子😁。

如何开始NewUI

双击shift打开搜索窗口，输入Registry，然后打开。接着打开experimental属性中的ui部分就可以了，最后只需要重启，你就能愉快的写代码🌶。

最近在学 ArkTS UI 发现其与 Swift UI 非常像，于是做了一下对比，发现可探索性很强。

Hello World 代码对比

从 Hello World 来看两者就非常像。

鸿蒙 ArtTs UI 的 Hello World 如下：

@Entry  

@Component  

struct Index {  

  @State message: string = 'Hello World';  

  

  build() {  

    RelativeContainer() {  

      Text(this.message)  

        .id('HelloWorld')  

        .fontSize(50)  

        .fontWeight(FontWeight.Bold)  

        .alignRules({  

          center: { anchor: '__container__', align: VerticalAlign.Center },  

          middle: { anchor: '__container__', align: HorizontalAlign.Center }  

        })  

    }  

    .height('100%')  

    .width('100%')  

  }  

}

Swift UI 的 Hello World 如下：

import SwiftUI



struct ContentView: View {

    var body: some View {

        VStack {

            Image(systemName: "globe")

                .imageScale(.large)

                .foregroundStyle(.tint)

            Text("Hello, world!")

        }

        .padding()

    }

}



#Preview {

    ContentView()

}

同样的 struct 开头，同样的 声明方式，同样的 Text，同样的设置外观属性方法。
不同的是 ArkTS 按照 Typescript 的写法，以装饰器起头，以 build 方法作为初始化的入口，build 里面才是元素；而 Swift UI 整个 ContentView 就是一个大元素，然后开始潜逃内部元素。

声明式 UI 描述

显然，两者都是用了 声明式的 UI 描述。

个人总结声明式 UI 的公式如下：

Element(props) {

	SubElement...

}.attribute(value)



元素(元素属性配置) {

	子元素

}.元素外观属性(元素外观)

因为 ArkTS 本质上是 Typescript / Javascript ，所以其写法要符合 TS/JS 的写法，引入的属性、变量必须有明确指示。

Text(this.message)  // message 是当前页面引入的，要有 this

        .id('HelloWorld')  

        .fontSize(50)  

        .fontWeight(FontWeight.Bold)  // Bold 是公共常量 FontWeight 的其中一值

对于前端来说，简单易读。这里的 Text 传入一个 message，然后标记 id 为 HelloWorld，设置字体为 50，字重为粗体。

而 Swift 或许更符合苹果以前 Obj C 迁移过来的人的写法。

Image(systemName: "globe") // 公共库名：公共库的值

                .imageScale(.large) // .large 是公共常量的一个值

                .foregroundStyle(.tint)// .tint 是公共常量的一个值

这里的 Image 引入了公共图标库的一个 globe 的图标，然后设置图片大小为大，前景样式为系统主题的颜色，Image(systemName: "globe") 明显不符合 new 一个类的定义方法，.imageScale(.large) 和 .foregroundStyle(.tint) 也不符合参数的使用，按以前的解读会有点让人懵圈。

如果转换成 Typescipt 应该是这样的：

new Image(SystemIcon.globe)

                .imageScale(CommonSize.large)

                .foregroundStyle(CommonColor.tint)

显然 ArkTS 更符合前端人的阅读、书写习惯。但其实掌握 Swift UI 也并不难，只需要记住 Swift UI 的这些细小差别，写两次也能顺利上手了。

声明式 UI 的耦合性争议

也许不少人会对声明式 UI 的耦合性（M和V耦合在一起）反感。但是在前端来说，除了以前的 的 MVC 框架 Angular.js 外，其余框架即使是 MVVM，也很少能做到解耦合的，特别是单功能内和业务数据交互的耦合。

所以，前端耦合性，还是需要自行处理。

Button({

	action: handleGoButton

}).{

	Text("Go")

}



// 自行决定 handleGoButton 是否需要放在外部文件中

private func handleGoButton() {

 ...

}



// 数据耦合在 UI 中，无解

ZStack {

    Color(selectedImageIndex == index ?

        Color.hex("808080") : Color.hex("585857")) // 选中的背景颜色区别一般的

  ...

}

前端的解耦合最终还是需要靠组件化、高阶函数来完成：

组件差异

SwiftUI 和鸿蒙操作系统的 ArtTS UI 框架都提供了多种组件，按前端使用情况，其实同样有很多相同之处。

基础组件

基础组件基本相同：

• Text 用于显示文本；


• Image 用于显示图片；


• Button 用户可以点击执行操作；

布局组件

Swift UI 和 ArkTS 相同/相似的布局组件有：

可以看出，两者基本上的布局都可以通用，当然细节上肯定会有很多不同。不过做一个转译应该不难，可以尝试使用 AI 来完成。

不同的地方在于 Flex 和 Grid 布局：

SwiftUI的布局系统非常灵活，可以通过调整alignment、spacing、padding等属性来实现复杂的布局需求。虽然它不完全等同于CSS中的Flexbox和Grid，但是通过组合使用不同的布局视图，创建出丰富多样的布局效果。

个人在实际开发 iOS 中，通过基础的布局组件搭配，就能完美的实现弹性布局和网格布局。

表单组件

Ark TS UI 提供了一系列的组件，更接近于 html 同名的组件：

• TextInput：用于文本输入。


• CheckBox 和 Switch：用于布尔值的选择。


• Radio：用于单选按钮组，类似于 HTML 中的单选按钮。


• Picker：用于选择器，可以用于日期选择、时间选择或简单的选项选择，类似于 HTML 中的 <select>。

Ark TS UI 表单组件的特点在于它们与数据绑定紧密集成，可以通过 @State、@Link 和 @Prop 等装饰器来管理表单的状态和数据流。

而 Swift UI 也有类似的表单组件，但是大部分都不相同：

• TextField：用于文本输入，可以包含占位符文本。


• SecureField：用于密码输入，隐藏输入内容。


• Picker：用于选择器，可以用于选择单个值或多个值。


• Toggle：用于布尔值的选择，类似于开关。


• DatePicker：用于日期和时间选择。


• Slider 和 Stepper：用于数值选择，Slider 提供连续值选择，而 Stepper 提供步进值选择。


• Form：一个容器视图，用于组织输入表单数据，使得表单的创建和管理更为方便。

虽然不能一一对应，但像日期选择器那样，目前大部分用户已经基本适应了 android 和 iOS 的差异。

总结 - 可运用 AI 转译

通过这次对比学习，可以得出以下结论：

第四点，个人觉得难度不大，本人用代码差异非常大的 android app 转译 iOS app 的也能成功，只是一个个页面进行调试花了不少时间。

至于先开发哪个 app 看你个人习惯，如果你是老 iOS 开发，可以使用先开发 iOS 再进行鸿蒙 OS 开发；甚至 react native 开发生成 iOS 之后，通过生成的 iOS 代码进行转译鸿蒙 OS app。如果你没有之前的负担，完全可以学习 ArkTS，更快地入手，然后通过转译 iOS app 来学习 Swift。

跨窗口通信的九重天劫：从postMessage到BroadcastChannel

第一重：postMessage 基础劫 —— 安全与效率的平衡术

// 父窗口发送

const child = window.open('child.html');

child.postMessage({ type: 'AUTH_TOKEN', token: 'secret' }, 'https://your-domain.com');



// 子窗口接收

window.addEventListener('message', (e) => {

  if (e.origin !== 'https://parent-domain.com') return;

  console.log('收到消息:', e.data);

});

安全守则：

第二重：MessageChannel 双生劫 —— 高性能私有通道

// 建立通道

const channel = new MessageChannel();



// 端口传递

parentWindow.postMessage('INIT_PORT', '*', [channel.port2]);



// 接收端处理

channel.port1.onmessage = (e) => {

  console.log('通过专用通道收到:', e.data);

};



// 发送消息

channel.port1.postMessage({ priority: 'HIGH', payload: data });

性能优势：

• 相比普通postMessage减少50%的序列化开销


• 支持传输10MB以上文件（Chrome实测）

第三重：BroadcastChannel 广播劫 —— 同源全域通信

// 发送方

const bc = new BroadcastChannel('app-channel');

bc.postMessage({ event: 'USER_LOGOUT' });



// 接收方

const bc2 = new BroadcastChannel('app-channel');

bc2.onmessage = (e) => {

  if (e.data.event === 'USER_LOGOUT') {

    localStorage.clear();

  }

};

适用场景：

• 多标签页状态同步


• 全局事件通知系统


• 跨iframe配置更新

第四重：SharedWorker 共享劫 —— 持久化通信枢纽

// worker.js

const connections = [];

onconnect = (e) => {

  const port = e.ports[0];

  connections.push(port);

  

  port.onmessage = (e) => {

    connections.forEach(conn => {

      if (conn !== port) conn.postMessage(e.data);

    });

  };

};



// 页面使用

const worker = new SharedWorker('worker.js');

worker.port.start();

worker.port.postMessage('来自页面的消息');

内存管理：

• 每个SharedWorker实例共享同一个全局作用域


• 需要手动清理断开连接的端口

第五重：localStorage 事件劫 —— 投机取巧的同步

// 页面A

localStorage.setItem('sync-data', JSON.stringify({

  timestamp: Date.now(),

  data: '重要更新'

}));



// 页面B

window.addEventListener('storage', (e) => {

  if (e.key === 'sync-data') {

    const data = JSON.parse(e.newValue);

    console.log('跨页更新:', data);

  }

});

致命缺陷：

• 事件仅在其他页面触发


• 同步API导致主线程阻塞


• 无法传递二进制数据

第六重：IndexedDB 观察劫 —— 数据库驱动通信

// 建立观察者

let lastVersion = 0;

const db = await openDB('msg-db', 1);



db.transaction('messages')

  .objectStore('messages')

  .openCursor().onsuccess = (e) => {

    const cursor = e.target.result;

    if (cursor && cursor.value.version > lastVersion) {

      lastVersion = cursor.value.version;

      handleMessage(cursor.value);

    }

  };



// 写入新消息

await db.add('messages', {

  version: Date.now(),

  content: '新订单通知'

});

适用场景：

• 需要持久化保存的通信记录


• 离线优先的跨窗口消息队列

第七重：Window.name 穿越劫 —— 上古秘术

// 页面A

window.name = JSON.stringify({ session: 'temp123' });

location.href = 'pageB.html';



// 页面B

const data = JSON.parse(window.name);

console.log('穿越传递:', data);

安全警告：

• 数据暴露在所有同源页面


• 最大容量约2MB


• 现代应用已不建议使用

第八重：Server-Sent Events (SSE) 服务劫 —— 服务器中转

// 服务端（Node.js）

app.get('/updates', (req, res) => {

  res.setHeader('Content-Type', 'text/event-stream');

  setInterval(() => {

    res.write(`data: ${Date.now()}\n\n`);

  }, 1000);

});



// 浏览器端

const es = new EventSource('/updates');

es.onmessage = (e) => {

  allWindows.forEach(w => w.postMessage(e.data));

};

架构优势：

• 支持跨设备同步


• 自动重连机制


• 与WebSocket互补（单向vs双向）

第九重：WebSocket 广播劫 —— 实时通信终极形态

// 共享连接管理

const wsMap = new Map();



function connectWS() {

  const ws = new WebSocket('wss://push.your-app.com');

  

  ws.onmessage = (e) => {

    const data = JSON.parse(e.data);

    if (data.type === 'BROADCAST') {

      broadcastToAllTabs(data.payload);

    }

  };

  

  return ws;

}



// 页面可见性控制

document.addEventListener('visibilitychange', () => {

  if (document.hidden) {

    ws.close(); 

  } else {

    ws = connectWS();

  }

});

性能优化：

• 心跳包维持连接（每30秒）


• 消息压缩（JSON → ArrayBuffer）


• 退避重连策略

渡劫指南（技术选型矩阵）

graph LR

    A[是否需要持久化?] -->|是| B[IndexedDB]

    A -->|否| C{实时性要求}

    C -->|高| D[WebSocket]

    C -->|中| E[BroadcastChannel]

    C -->|低| F[postMessage]

    B --> G[是否需要跨设备?]

    G -->|是| H[SSE/WebSocket]

    G -->|否| I[localStorage事件]

天劫问答