在hbuildx中,由于项目比较多,使用打开多窗体项目打开的项目就多了,有时候想把不再开发的项目去掉,但是没有查到任何可以改的方式,有没有人知道啊

UTS 插件鸿蒙端开发示例

以上示例已开源
项目地址 请参考 示例代码。

前言

虽然这个 UTS 插件鸿蒙端的示例看起来很简单，但说实话，这一步其实难住了不少开发者。很多人第一次做 UTS 插件，尤其是要跑通鸿蒙端，都会在这里卡壳。希望这份文档能帮你少走弯路，顺利迈过这道坎。

基础知识补充

什么是 UTS 插件？

UTS 插件其实就是 uni-app x 扩展 API 的标准插件形式。你可以把它理解成"写一份 TypeScript 风格的代码，编译后在不同平台都能用"。

说个实话，刚接触 uni-app x 的时候，很多人一看到"插件"两个字就头大，觉得一定很复杂。其实 UTS 插件的本质，就是把你想要的原生能力用 TypeScript 包一层，剩下的交给编译器搞定。

UTS 与 ArkTS 的关系

UTS 和 ArkTS 都是基于 TypeScript 的扩展，但有些细节不同。特别注意：鸿蒙端开发时，所有对象字面量都必须定义类型，不能用 any 类型，否则会直接编译报错。

比如 ArkTS 不允许无类型的对象字面量，UTS 会自动帮你加上类型，但你自己写代码时一定要养成良好习惯：

// 错误写法（鸿蒙端会报错）  
const obj = { a: 1 };  

// 正确写法  
interface Obj { a: number }  
const obj: Obj = { a: 1 };  
// 或  
const obj = { a: 1 } as Obj;

你只需要记住：UTS 写的代码，最终会被编译成 ArkTS（.ets）文件，然后就能愉快地调用鸿蒙的原生 API 了。

配置鸿蒙依赖

鸿蒙的依赖管理工具叫 ohpm，和 npm 很像。三方 SDK 用 .har 文件（有点像 Android 的 .aar）。

配置依赖时，记得在 utssdk/app-harmony/config.json 里写清楚：

{  
  "dependencies": {  
    "@cashier_alipay/cashiersdk": "15.8.26",  
    "local-deps": "./libs/local-deps.har"  
  }  
}

注意：config.json 不能有注释，本地依赖路径是相对的。

资源文件与权限配置

• 插件资源（图片、字体等）放在 utssdk/app-harmony/resources。
• 权限、模块信息等写在 utssdk/app-harmony/module.json5。

比如你要用定位权限，可以这样写：

{  
  "module": {  
    "requestPermissions": [  
      {  
        "name": "ohos.permission.LOCATION",  
        "usedScene": { "when": "inuse" },  
        "reason": "$string:permission_location_reason"  
      }  
    ]  
  }  
}

context 获取

很多鸿蒙原生 API 需要 context。大多数场景下直接用 getContext() 就行：

import settings from '@ohos.settings';  
const context: Context = getContext();  
settings.getValue(context, settings.display.SCREEN_BRIGHTNESS_STATUS, (err, value) => {  
  if (err) {  
    console.error(`Failed to get the setting. ${err.message}`);  
    return;  
  }  
  console.log(`SCREEN_BRIGHTNESS_STATUS: ${JSON.stringify(value)}`)  
});

有一次小王同学写插件，死活拿不到 context，结果发现是忘了在页面生命周期里调用，调试了半天才恍然大悟。遇到问题别慌，先查查官方文档和社区经验，很多"坑"其实大家都踩过。

更多细节和常见问题，建议随时查阅官方文档：UTS for HarmonyOS

步骤详解

友情提示：

虽然下面的步骤看起来很基础，但每一步都很关键。尤其是接口定义和鸿蒙端实现，很多人就是在这里卡住的。别嫌简单，能跑通才是王道。

再次强调：鸿蒙端开发时，所有对象字面量都必须定义类型，不能用 any 类型！

第一步：定义插件接口（interface.uts）

目的：

• 明确插件对外暴露的 API 规范，方便多端实现和 IDE 智能提示。
• 这是 UTS 插件开发的基础，所有端的实现都要遵循这里定义的接口。

操作：

• 在 uni_modules/你的插件名/utssdk/ 下新建或编辑 interface.uts 文件。
• 定义你要暴露的类型、方法签名。例如：

// uni_modules/tt-ost/utssdk/interface.uts  
export type MyApiSync1 = (paramA: string) => string;

第二步：鸿蒙端实现接口（app-harmony/index.uts）

目的：

• 按照接口定义，实现鸿蒙端的具体逻辑。
• 这是很多开发者卡壳的地方，需注意导入接口类型、调用鸿蒙 API、正确导出方法。
• 注意：所有对象字面量都要定义类型，不能用 any！

操作：

• 在 uni_modules/你的插件名/utssdk/app-harmony/ 下新建或编辑 index.uts 文件。
• 按照接口定义，实现方法。例如：

// uni_modules/tt-ost/utssdk/app-harmony/index.uts  
import { MyApiSync1 } from '../interface.uts';  
import { promptAction } from '@kit.ArkUI';  

interface ShowToastOptions {  
  message: string;  
}  

export const myApiSync1: MyApiSync1 = function (paramA: string): string {  
  let ddd: ShowToastOptions = { message: paramA };  
  promptAction.showToast(ddd);  
  return paramA;  
}

• 这里以 Toast 弹窗为例，实际可根据业务需求调用鸿蒙原生能力。

第三步：在页面中调用插件方法

目的：

• 验证插件功能是否生效。
• 体验 UTS 跨端调用的便捷性。

操作：

• 在页面脚本中引入并调用插件方法。例如：

<script>  
import { myApiSync1 } from '@/uni_modules/tt-ost';  
export default {  
  methods: {  
    showToast() {  
      const msg = 'Hello Harmony!';  
      const result = myApiSync1(msg);  
      console.log(result); // 输出: Hello Harmony!  
    }  
  }  
}  
</script>

说明

• 该插件支持多端，鸿蒙端实现了 myApiSync1，会调用 ArkUI 的 promptAction.showToast。
• 其他端（如 Android/iOS）可根据需要实现对应方法。
• 适合演示 UTS 跨端插件的基本用法。

如需更多信息，请参考 uni-app x 官方 UTS 插件开发文档。

有用户反馈钉钉小程序真机调试扫码访问之后会立刻提示报错，提示

本次真机调试已结束，请重新生成调试版本 exceed each tiny app max socket count

解决方法，打开 HBuilderX 再右下角找到 日志回显，选择关闭重新编译一遍钉钉小程序即可

事故一：设置了 value-key，在网页或者小程序代码正常，到了uniapp上出现弹出来空白内容。
问题原因：在uniapp中，需要改为text，value。
解决方案一（不推荐）：直接改为text，value。如下：

const columns = [  
  {  
    merchantName: '用户1',  
    merchantNo: 'uid001'  
  },  
  {  
    merchantName: '用户2',  
    merchantNo: 'uid002'  
  }  
]

改为：

const columns = [  
  {  
    text: '用户1',  
    value: 'u001'  
  },  
  {  
    text: '用户2',  
    value: 'u002'  
  }  
]

解决方案二（推荐）：改为columns-field-names来实现。如：

<van-picker :columns="columns" :columns-field-names="{ text: 'merchantName', value: 'merchantNo'}" />

事故二：滚动选择了其他行，点确定。结果返回来的结果依旧是第一行结果。
问题原因：columns-field-names 没有设置value，导致所有数据没有唯一的value。
解决方案：columns-field-names一定要设置唯一的value。

vue2
升级原因是打包ios app时提示cli版本与打包机器的版本不一致，即使打包成功也无法上传appstore
先在这里cv一遍配置文件：https://uniapp.dcloud.net.cn/vue2-cli-release.html
然后又发现这里的还不是最新版本，又运行命令升级到最新版本：npx @dcloudio/uvm@latest

启动项目，报错：

ValidationError: Invalid options object. Dev Server has been initialized using an options object that does not match the API schema.  
 - options has an unknown property 'disableHostCheck'. These properties are valid:  
   object { allowedHosts?, bonjour?, client?, compress?, devMiddleware?, headers?, historyApiFallback?, host?, hot?, http2?, https?, ipc?, liveReload?, magicHtml?, onAfterSetupMiddleware?, onBeforeSetupMiddleware?, onListening?, open?, port?, proxy?, server?, setupExitSignals?, setupMiddlewares?, static?, watchFiles?, webSocketServer? }

修改vue.config.js，把disableHostCheck: true,修改为allowedHosts: 'all',

启动项目，F12报错：

Reason: Error: ES Modules may not assign module.exports or exports.*, Use ESM export syntax, instead: 42

百度半天，找到解决方法：
原因是自定义的业务代码的js文件里存在module.exports={}，新版好像不支持这种写法了，只能全部替换成export function xxxxx。百度说babel能解决这个问题，看了半天直接放弃，直接替换吧

删除devDependencies里的"@babel/runtime": "~7.12.0"，删除node_modules文件夹，重新install
改了半天js，终于能看到页面了

随便点几个地方测试，页面出现

之前是没有这玩意的，只有控制台打印的异常，解决方法是修改vue.config.js，增加

config.devServer = {  
                client: {  
                    overlay: false  
                }  
}

终于一切正常了，dev启动一切正常，发ios，真机运行发现tabbar没了
原因：编译的时候出现一堆这种警告Deprecation Warning [import]: Sass @import rules are deprecated and will be removed in Dart Sass 3.0.0.
，看不到这个一开始就打印的重要报错：

[webpack-dev-server] Project is running at:  
TypeError: Cannot read property 'compress' of undefined

又是webpack的锅，如图修改：

国产鸿蒙生态发展艰巨而重要。

• 很多开发者想迁移鸿蒙而苦于轮子不完善，不能低成本适配。
• 很多开发者想要一个完美的跨平台方案来全平台覆盖，不必为了跨平台而牺牲性能体验。

uni-app x已经完成Android、iOS、鸿蒙、Web、微信小程序等主流平台全覆盖。

为进一步繁荣uni生态，特别是推动鸿蒙平台的生态建设，惠及产业和开发者，DCloud 正式启动「2025年度插件大赛」。

大赛准备了丰富的奖励，除了流量、荣誉外还有30部纯血鸿蒙手机。

奖项设置：

本次大赛与往届有一个差别，就是更加普惠。本次没有特等奖，三等奖也发放价值2699元的纯血鸿蒙手机（全新机）。

欢迎更多插件作者积极参与，给大家更多机会。

一等奖（2名）：

奖品：1万元插件包销 + 鸿蒙手机1部 + 插件市场置顶推荐半个月 + HBuilderX预置 + HBuilderX超大鼠标垫 + DCloud奖牌

二等奖（8名）：

奖品：1000元插件包销 + 鸿蒙手机1部 + 插件市场置顶推荐1个星期 + HBuilderX超大鼠标垫 + DCloud奖牌

三等奖（20名）：

奖品：200元uniCloud代金券 + 鸿蒙手机1部 + HBuilderX超大鼠标垫 + DCloud奖牌

贡献奖（50名）：

奖品：HBuilderX超大鼠标垫

奖品说明：

1. “插件包销”，是指获奖插件通过插件市场销售，DCloud兜底包销。以1等奖的1万元包销为例，如果获奖插件在插件市场1年内销售额没有达到1万元，则由DCloud付差额给获奖者进行兜底。包销只针对付费插件，如免费插件获得二等奖及以上奖励，其中的包销奖励无效。包销插件需持续迭代，如插件作者放弃维护，则包销无效。

2. “HBuilderX预置”，是在HBuilderX新建项目界面，可直接选择该项目模板。这为插件带来大量的流量。不适合预置的插件类型，无法领取此奖项。HBuilderX预置窗体界面如下：

1. 本次插件大赛，目标是普惠更广大开发者，解决很多工程师缺少鸿蒙真机的困境，故本次奖励的鸿蒙手机为统一型号为nova 14 256GB；

2. 鸿蒙手机的奖励需满足两个条件：

   • 插件兼容鸿蒙平台
   • 插件作者通过DCloud专属链接到鸿蒙开发者平台注册一个新的开发者账号

除上述奖品外：

• 二等奖及以上获奖插件作者，都将进入DCloud VIP技术支持群，享受优先的技术支付、问题反馈。
• 所有获奖插件的集锦页面，还将通过HBuilderX工具、论坛、IM/QQ/微信群进行全量推广，给予优秀插件充分的曝光。

参赛要求：

1. 参赛起止时间：从2025年6月1日起，到2025年8月31日止。
2. 插件鼓励范围
   • 兼容鸿蒙的插件，包括前端插件和uts原生插件。uts插件同时支持uni-app和uni-app x。
   • 适配uni-app x的插件。
   • 对于涉及vue组件和页面的，鼓励组合式，而不鼓励选项式。
   • uniCloud插件：优秀的云端一体插件
   • 有助于开发者广告变现的运营类插件
   • HBuilder插件
     你的插件若能同时覆盖多个鼓励范围的插件，则buff叠满！
3. 在本次大赛有效期内提交或更新插件到插件市场，且下载人数不低于50人，即可自动进入大赛候选名单，无需单独报名。

如需帮助或技术指导，可进入uni-im进行交流，官方团队将为你提供支持。

在弹出层中如果使用 scroll-view，在嵌套使用up-popup组件时会出现弹出层的层级以及遮罩层的层级错乱。
解决办法：在编译成微信小程序时 在up-popup外部加一层 <root-portal> </root-portal> 即可

十年开发、设计经验
1.代做 安卓.9.png 、iOS苹果storyboard 启动图片，不满意免费修改；
2.代上架安卓应用市场/苹果APP Store；
3.解决前/后端问题；
4.定制/二次开发app、小程序、各类网站系统。
5.前端可以做： react、vue、uniapp、Flutter、原生安卓开发、小程序原生开发、安卓原生开发
6.后端可以做：PHP、Java、Python、nodejs
联系方式： wx:lh1845407111 QQ:1845407111
工作室官网：https://www.xiaohongzi.top/h5/#/home 欢迎大家访问
价格便宜，包满意！包满意！包满意！

本人专业uniapp开发，从最开始的5+app到现在的uni，可以说是老玩家了，现在在线求职，有需求的可以联系我qq：1963534590

本人专业uniapp开发，从最开始的5+app到现在的uni，可以说是老玩家了，现在在线求职，有需求的可以联系我qq：1963534590

本人专业uniapp开发，从最开始的5+app到现在的uni，可以说是老玩家了，现在在线求职，有需求的可以联系我qq：1963534590

'''在大多数安全讨论中，我们习惯关注新项目的安全性，从代码结构、API 设计、用户认证机制出发，构建完善的防护体系。但现实是，很多开发者都在维护一些年久失修的老项目——技术架构老旧、团队成员流失、源码混乱甚至缺失。

我最近接手的就是这样一个项目：一款 iOS 工具类 App，五年前开发，只有一份 IPA 包，没有源码，客户希望上线新版前“加点安全措施”。

你没看错，只有一个 IPA 文件，连编译工程都没有。

这篇文章分享我如何在这样的条件下，用现代工具（包括 Ipa Guard）为老项目添加安全混淆保护，让它在 2025 年依然能“站得住”。

项目背景：一个没有源码的 App，你能做什么？

客户提供的是一个旧版 IPA 文件和测试账号，希望我：

• 检查是否存在安全风险；
• 尽量提高防逆向、防破解能力；
• 不破坏原有功能逻辑；
• 减少测试时间和返工成本；

很显然，这不是一个“写代码”的项目，而是一个“如何动最少东西，加最多保护”的挑战。

初步分析：暴露严重，结构清晰

使用 class-dump 和 Hopper 分析 IPA，我们发现了几个严重问题：

• 类名清晰（如 MainVC, LoginService）；
• HTML 页面和 JS 文件全部可见；
• JSON 配置暴露接口地址；
• 图片资源以业务功能命名，例如 withdraw_button@2x.png;

更糟的是，代码中没有做任何字符串加密或资源混淆，攻击者可直接仿制整个逻辑流。

限制条件下的目标设定

既然无法修改源码，我只能从“外部包装”的角度入手，目标如下：

1. 混淆符号与结构：隐藏业务逻辑线索；
2. 资源加密或重命名：降低静态分析价值；
3. 输出可用安装包：不影响现有功能；
4. 本地执行，避免上传云端：客户不允许上传代码；

工具选型

在尝试了几种方式后，我选择了 Ipa Guard，原因如下：

• 完全本地执行，无云端依赖，符合客户要求；
• 无需源码支持，适配这类“只给你个 IPA”的项目；
• 支持多平台结构（OC/Swift/Flutter/H5），未来可能拓展；
• 资源、类名、方法名自动混淆，附带路径同步更新功能；
• 修改 MD5 与文件哈希，增加安全水印；
• 支持重签名后直接安装测试，方便验证兼容性；

实施流程：干净利落的五步混淆

1. 将原始 IPA 导入 Ipa Guard；  
2. 启用混淆选项：类名、方法、资源重命名；  
3. 设置资源水印参数（如替换 UDID）；  
4. 配置本地签名参数；  
5. 导出新 IPA 包并安装测试；

整个流程耗时不到 10 分钟，生成的新包在测试机上运行良好，功能无误。

混淆前后对比效果

老项目不是“无力可救”，只是“没人想救”

维护旧项目从来不是光鲜的事，但现实中这类场景却大量存在。你或许无法改变其代码结构，但可以通过一些“后置安全操作”，大幅度提升其抗风险能力。

像 Ipa Guard 这样不依赖源码的 IPA 混淆工具，正是我们解决老项目安全问题的“补丁工具箱”。你不必重写代码，也不必动底层逻辑，只需多一个处理步骤，就能带来更安心的发布体验。'''

'''几个月前，我们上线了一个版本，结果关键词写错导致搜索权重下降，截图也传错语言版本。用户反馈说“怎么看到的是英文截图”，我们才意识到出了问题。

问题不大，但代价不小——重新提审、审核延迟、运营错过活动窗口。那一次我们意识到：

> 上架流程本身就像上线一样，也需要“容灾设计”。

这篇文章我想聊聊：我们是如何从一次上架失误中总结出“防错 + 回滚 + 可复查”的机制，避免每一次出错都要“靠人脑记忆”处理现场。而 Appuploader，则是这套机制中执行层的核心组件。

出错的真实代价

你可能以为上架错了“改一下再提不就行了”？但实际上：

• 被拒或更新审核通常多花 1～3 天
• 要重传截图、多语言文本，再次校对
• 产品或运营完全无法自助处理，得开发配合
• 用户看到错误内容，反馈影响口碑

比起功能 Bug，更难堪的是“你发布的东西本来就错”。

我们如何构建“上架容灾系统”？

1. 明确上架失败的四种典型场景：

1. 上传错误截图（尺寸或语言不符）
2. 关键词、描述信息拼写或语义误填
3. 证书/描述文件过期、绑定错误导致签名失败
4. 上传成功但 App Store Connect 状态卡住或未知错误

我们先把过去半年出过的问题都列了表，整理出错误源头。

2. 设定“可快速复原”的流程机制

我们从三个层面入手：

• 内容管理结构化：每次截图、关键词信息统一放入文件目录，命名规则一致
• 上传工具图形化 + 状态反馈：使用 Appuploader上传 IPA 与截图时，每一状态都能看到反馈，避免“盲传”
• 操作日志记录：每次发布操作人需登记使用的证书名、截图目录路径、关键词文件版本

Appuploader在容灾流程中承担的角色

我们发现很多出错是因为流程隐形，比如某人点了上传但没有反馈、截图改了一版却没更新上传。

Appuploader提供了几个非常关键的“防错机制”：

图形化上传界面 + 结构化目录识别

你只需要把截图放进指定的多语言目录下，工具会识别设备尺寸和语言，不用担心“拖错图”。

状态实时反馈

上传后，工具会明确提示状态（成功、失败、等待审核），包括 App Store 返回的错误信息，第一时间定位问题，不用去猜。

证书 & Profile 明确绑定

在工具中创建描述文件时，自动绑定选定的证书和 App ID，导出文件自动命名，减少配置错配风险。

上传与文案内容统一操作

产品或运营只需熟悉目录结构，即可在工具中完成多语言截图与文本提交，减少开发介入频率，也减少中间误传。

我们的“快速修复”流程现在是这样：

1. 问题定位（由反馈或审核结果发现）
2. 查发布记录，确认错在哪一步（如截图目录、关键词版本）
3. 替换截图或描述内容，重新上传并备注“修复版本”
4. 所有记录写入版本发布卡片，注明修复原因和操作人

成果：一套流程让我们更少出错，也更快恢复

• 每次出错都有明确记录和责任人
• 修复流程不依赖原操作者，任何人可复现
• 一套统一结构 + Appuploader工具链，把“上线出错”从临时事故变成可控事件

发布错一次没关系，可怕的是“不知道错在哪、也没人能修”

iOS 上架不是提交按钮点一下那么简单，它和产品发布一样需要版本控制、状态管理和结构化交付能力。

Appuploader不是“防错工具”，但它帮我们减少了操作歧义，提高了反馈可视化，成为我们构建容灾机制的核心支撑。

你是否也经历过上架出错？是怎么应对的？是否有人专职处理，还是靠流程消化？欢迎留言讨论你的“上架恢复”机制。'''

'''我原来是做测试的，每天的工作围绕功能点验证、用例执行、Bug记录展开。那时候抓包对我来说是个工具：验证一下接口有没有调用、响应内容对不对，用 Charles 截几张图就完了。

后来转到开发岗，一切变了。

我开始面对：

• 被封装的SDK接口，不知道它内部发了什么；
• 真机上HTTPS请求无法调试；
• 后端说“你这字段不对”，但我不知道它是怎么变的；
• 用户报Bug，我却无法复现；

这时候我重新理解了：抓包，不只是测试的验证手段，更是开发定位问题的“可视化放大镜”。

尤其在 iOS 真机 + HTTPS + SDK 封装三重限制下，像抓包大师 Sniffmaster 这样的工具，成了我们开发调试闭环的关键。

抓包，从“验证”到“解释”

测试阶段我用抓包只是为了“确认是否请求成功”，而作为开发，我必须用抓包来：

• 解释某个字段为何丢失；
• 还原Header拼接过程；
• 判断请求发没发出；
• 比对两个构建包行为差异；

举个例子：

上线后有用户反馈登录失败，测试、后端日志一切正常。我插线用 Sniffmaster 抓真机HTTPS请求，发现登录接口中 X-PLATFORM-TYPE 字段被打包脚本替换错了，返回403。

这个信息，不抓包，完全查不到。

我现在用的抓包工具组合

每个工具我都用过实际场景，最后发现不是工具多就行，而是要“搭配得当”。

Sniffmaster 是什么时候起作用的？

尤其在这些场景里：

• SDK没有开放接口请求日志；
• HTTPS请求加了双向pin，Charles/mitmproxy无法中间人抓包；
• App打包发布后行为变了，但本地无法复现；
• 某些关键字段只有上线构建才出现问题（混淆、代码保护）；

我在这些情况下插上 Sniffmaster，一秒钟就抓到整个包体，甚至还能筛选指定 App 的请求，排除系统干扰。

那种“终于看到底层发生了什么”的感觉，真的像打开了监控摄像头。

案例：一次双重Header拼接的坑

我曾对接一个支付SDK，正式上线后用户频繁出现“支付失败”。后端说“你请求重复Header”，我看代码也没有问题。

后来我抓了真机包，才发现：

• 我们拼接了 X-AUTH-ID；
• SDK内部也拼了一次同名字段；
• 服务端收到双字段冲突，直接丢弃请求；

问题修复逻辑很简单，但如果没有抓包，我根本不会想到“一个Header有两份”这种怪现象。

总结：抓包，是开发调试的X光片

你写得再好，构建时可能被混淆打断，你调得再顺，用户环境可能完全不同，你测得再细，封装内部可能自作主张。

抓包就是帮你在“不确定性”中，把行为“确认”下来。特别是像 Sniffmaster 这样的工具，让我们终于能看清那些原本被封锁的真机HTTPS数据，让你写得更安心，调得更有底。'''