12

报错原文

2026-08-06 15:22:08.448 [WARNING:] [PluginHost] Error: Command failed: E:\HBuilderX\plugins\launcher-tools\tools\adbs\adb.exe -s adb-AN2FVB1731016322-t2CsiT._adb-tls-connect._tcp shell pm list packages io.dcloud.HBuilder  
Exception occurred while executing 'list':  
java.lang.SecurityException: Shell does not have permission to access user 100  
com.android.server.am.ActivityManagerService.handleIncomingUser:14620 android.app.ActivityManager.handleIncomingUser:4753 com.android.server.pm.PackageManagerShellCommand.translateUserId:3853  
at com.android.server.am.UserController.handleIncomingUser(UserController.java:2745)  
at com.android.server.am.ActivityManagerService.handleIncomingUser(ActivityManagerService.java:14620)  
at android.app.ActivityManager.handleIncomingUser(ActivityManager.java:4753)  
at com.android.server.pm.PackageManagerShellCommand.translateUserId(PackageManagerShellCommand.java:3853)  
at com.android.server.pm.PackageManagerShellCommand.runListPackages(PackageManagerShellCommand.java:1060)  
at com.android.server.pm.PackageManagerShellCommand.runListPackages(PackageManagerShellCommand.java:956)  
at com.android.server.pm.PackageManagerShellCommand.runList(PackageManagerShellCommand.java:792)  
at com.android.server.pm.PackageManagerShellCommand.onCommand(PackageManagerShellCommand.java:230)  
at com.android.modules.utils.BasicShellCommandHandler.exec(BasicShellCommandHandler.java:97)  
at android.os.ShellCommand.exec(ShellCommand.java:38)  
at com.android.server.pm.PackageManagerService$IPackageManagerImpl.onShellCommand(PackageManagerService.java:7086)  
at android.os.Binder.shellCommand(Binder.java:1087)  
at android.os.Binder.onTransact(Binder.java:904)  
at android.content.pm.IPackageManager$Stub.onTransact(IPackageManager.java:4368)  
at com.android.server.pm.PackageManagerService$IPackageManagerImpl.onTransact(PackageManagerService.java:7062)  
at android.os.Binder.execTransactInternal(Binder.java:1371)  
at android.os.Binder.execTransact(Binder.java:1310)  
at genericNodeError (node:internal/errors:983:15)  
at wrappedFn (node:internal/errors:537:14)  
at ChildProcess.exithandler (node:child_process:417:12)  
at ChildProcess.emit (node:events:519:28)  
at maybeClose (node:internal/child_process:1101:16)  
at ChildProcess._handle.onexit (node:internal/child_process:304:5) {  
code: 255,  
killed: false,  
signal: null,  
cmd: 'E:\HBuilderX\plugins\launcher-tools\tools\adbs\adb.exe -s adb-AN2FVB1731016322-t2CsiT._adb-tls-connect._tcp shell pm list packages io.dcloud.HBuilder'  
}

解决方法

在 adb 安卓目录 E:\HBuilderX\plugins\launcher-tools\tools\adbs 输入 cmd 打开命令行 输入 adb devices

确保手机已经成功链接
然后输入 adb shell pm list users 查看系统底层真实用户

如果有 这个 UserInfo{100:平行空间:20000410} 说明你手机开启了平行空间 可以在手机设置里搜索 平行空间 直接销毁就行了

libjpeg，mbed_tls，zlib这三个组件分别依赖于：
xxxx.apk.extracted/lib/armeabi-v7a/libnative-imagetranscoder.so
xxxx.apk.extracted/lib/armeabi-v7a/libweexcore.so
xxxx.apk.extracted/lib/armeabi-v7a/libweexjss.so
xxxx.apk.extracted/lib/arm64-v8a/libnative-imagetranscoder.so
xxxx.apk.extracted/lib/arm64-v8a/libweexcore.so
xxxx.apk.extracted/lib/arm64-v8a/libweexjss.so
我们程序做第三方漏洞审计，这些组件版本均被检测出有漏洞修复更新

具体审计问题见附件详情，官方重视一下尽快给出解决方案并修复问题漏洞

大家好，我是 luch-request 的维护者。

luch-request v4 Alpha 现已发布到 npm，想邀请正在使用 uni-app 的开发者参与体验，帮助验证不同平台下的请求、上传下载、取消和原生 Task 行为。

npm install luch-request@alpha

v4 不是对 v3 的内部重构，而是一个 breaking version。它围绕 uni API、原生 Task、TypeScript 类型边界和多平台行为重新设计，希望在保留 uni 原生能力的同时，让请求配置、错误处理和取消行为更加明确。

当前版本为 4.0.0-alpha.1，公共 API 在稳定版前仍可能调整。建议先在测试项目或非核心业务中体验，并在自己的目标平台完成验证。

为什么重新设计 v4

uni-app 可以运行在 H5、App 和不同小程序平台，但各平台支持的请求参数、原生 Task、错误对象和取消能力并不完全一致。

如果直接套用浏览器 HTTP client 的设计，会遇到一些实际问题：

• 浏览器的 API 和类型不能代表所有 uni-app 平台；
• request、uploadFile、downloadFile 拥有不同的原生参数和 Task；
• 平台新增参数的速度可能快于请求库和类型声明的更新；
• 网络失败、HTTP 状态码失败、取消和 JSON 解析失败需要不同的判断依据；
• TypeScript 类型过于宽松会失去约束，过于严格又可能阻碍平台新增能力。

因此，v4 没有把 v3 的内部结构继续扩展，而是重新确定了公共 API、配置合并、Interceptor、错误、取消和跨平台边界。

v4 带来了什么

1. TypeScript-first

请求响应、请求体和查询参数可以分别建模，常见调用保持直接：

import { createLuchRequest } from 'luch-request'  

const http = createLuchRequest({  
  baseURL: 'https://api.example.com',  
  timeout: 10_000  
})  

interface User {  
  id: number  
  name: string  
}  

interface UserListParams {  
  page: number  
  keyword?: string  
}  

const response = await http.get<User[], UserListParams>('/users', {  
  params: {  
    page: 1  
  }  
})  

console.log(response.data)

JavaScript 项目仍然可以使用 v4；TypeScript 项目则能获得更完整的配置、响应、错误和公共导出类型。

2. 保留 uni 原生能力

v4 分别支持：

• request
• upload
• download

三类操作共用实例配置、Interceptor 和错误契约，但在派发边界保留各自的原生参数，不使用 UPLOAD、DOWNLOAD 这样的伪 HTTP method。

3. 可以访问原生 Task

请求 Promise 提供 abort()、task 和 onTask()，单次请求配置也可以使用 onTask：

const request = http.get('/users', {  
  onTask(task) {  
    console.log('原生 Task：', task)  
  }  
})  

// 需要取消时  
request.abort()

如果取消能力需要跨 service 层传递，可以使用 createCancelSource()，不必把请求 Promise 暴露给每一层调用方。

4. 明确的配置边界与 nativeOptions

v4 将配置分成不同职责：

• 常用 uni 请求参数可以直接配置；
• luch-request 自身行为放在 luchOptions；
• 平台新增参数或插件尚未声明的参数通过 nativeOptions 透传。

nativeOptions 是面向平台新能力的逃生窗口。当比较新的 uni API、某个平台参数或第三方插件参数还没有进入请求库类型时，使用方仍然可以显式透传，而不需要等待库发布新版本。

5. Interceptor 区分操作类型

v4 提供 request/response interceptor，支持同步和异步处理。Interceptor 上下文可以使用 LuchOperation 判断当前执行的是 request、upload 还是 download，避免依赖字符串或伪 method。

6. 统一错误与 JSON 解析策略

请求失败时统一抛出 LuchRequestError，并保留可用于判断的上下文，例如：

• code
• config
• response
• task
• cause
• raw
• cancelMode

网络失败、HTTP 状态码失败、取消和 JSON 解析失败可以分别判断。对于 JSON 解析失败，还可以通过 JSONParsingMode 选择抛出错误、保留文本等处理方式。

Alpha 阶段暂不包含什么

为了先稳定核心请求契约，首个版本不会内置以下能力：

• 自动重试
• 请求缓存
• 请求去重
• 并发控制
• Token 自动刷新
• WebSocket
• uni_modules
• uni-app x

这些能力并不是简单地全部塞进核心库。后续会根据真实使用场景，判断应该由 Interceptor、独立扩展还是核心能力提供。

v3 用户需要立即升级吗

不需要。

v3 稳定项目可以继续使用现有版本。v4 是 breaking version，适合以下开发者优先体验：

• 正在开发新项目；
• 希望获得更完整的 TypeScript 类型；
• 需要统一错误和取消行为；
• 需要访问原生 Task 或进度事件；
• 希望分别处理 request、upload 和 download；
• 愿意在自己的目标平台验证 Alpha 行为。

正式迁移前，请先阅读 v3 到 v4 的迁移文档，并在实际运行平台完成 smoke test。

希望大家重点帮助验证

自动化测试能够验证请求库逻辑，但不能代替所有真实设备、运行平台和 uni-app 版本。特别希望大家帮助验证：

1. H5、App、微信小程序及其他小程序中的基础请求；
2. upload、download 及进度事件；
3. abort() 是否触发平台原生中断；
4. onTask() 是否能取得预期的原生 Task；
5. 不同平台返回的错误结构是否存在差异；
6. nativeOptions 是否能正确传递平台新增参数；
7. TypeScript 类型是否存在过严、过松或无法表达的场景；
8. JavaScript 项目中的配置和错误行为是否足够清晰。

如何反馈

提交问题时，如果方便，请尽量提供以下信息：

运行平台：  
HBuilderX / uni-app 版本：  
luch-request 版本：  
使用 TypeScript 还是 JavaScript：  
最小复现代码：  
预期结果：  
实际结果：  
错误对象或控制台日志：

如果问题与取消、上传下载或原生 Task 有关，也请说明实际运行平台，以及是否能取得对应 Task。

相关链接

• v4 文档：https://luch-request.quanzhan.co/
• GitHub：https://github.com/lei-mu/luch-request
• 问题反馈：https://github.com/lei-mu/luch-request/issues
• npm：https://www.npmjs.com/package/luch-request
• v3 稳定文档：https://v3.luch-request.quanzhan.co/

写在最后

v4 的核心设计和自动化测试已经完成，但 uni-app 请求库真正困难的部分始终是多平台运行差异。

希望正在使用 uni-app 的开发者帮助验证 request、upload、download、取消和原生 Task 等能力。无论是兼容性问题、类型设计建议，还是某个平台特有的行为差异，都欢迎在 GitHub Issue 或本帖中反馈。

感谢每一位愿意安装、运行和提供反馈的开发者。

uni-app / uni-app x / 微信小程序 / 抖音小程序 / App 外包开发｜全栈接单｜二开修Bug / 后台 / 后端 / 前端

20年开发经验，需要的咨询

'''之前一直做 iOS 开发，性能优化就是 Instruments 一套流程走下来，从 CPU 到内存到能耗都有对应的模板。后来接手一个 Flutter 跨平台项目，才发现 Android 和 iOS 的性能优化策略差别不小，用的工具也不一样，一套思路套两个平台行不通。这里把两个平台的优化策略和工具选择放在一起对比，给跨平台团队做个参考，重点是找出哪些策略是共通的、哪些要分开做。

启动速度优化

两个平台都很看重启动速度，但优化点不同。iOS 的冷启动受动态库加载和首屏渲染影响，优化方向是精简启动逻辑、延迟初始化、减少主线程首帧前的工作量，把不着急的初始化移到首帧之后。Android 启动受 Application 初始化影响更大，大量 SDK 在 Application 里同步初始化会明显拖慢启动，优化方向是 SDK 异步初始化、按需加载、能懒加载就懒加载。两个平台都可以通过拆分启动任务、错峰执行来改善，这个思路是共通的。

内存优化

内存问题的表现形式不同。iOS 常见的是循环引用导致的内存泄漏和图片缓存堆积，排查用 Instruments Allocations 做深度分析，或者用 KeyMob 的内存面板实时看曲线——退出页面时扫一眼曲线有没有回落，就能判断释放是否正常。Android 常见的是 Bitmap 占用过高和内存泄漏（Activity 泄漏居多），排查用 Android Studio 的 Memory Profiler，看 GC 后的内存水位。优化方向类似：及时释放资源、合理设置缓存上限、避免持有不必要的大对象，这些策略两个平台通用。

流畅度与帧率

流畅度优化的核心都是保证帧率稳定，但排查路径不同。iOS 端重点排查主线程耗时操作和离屏渲染（圆角、阴影、mask），用 Instruments Time Profiler 深挖，或者 KeyMob 实时监控 FPS 曲线，操作页面时看哪里掉帧。Android 端重点排查主线程阻塞（比如在主线程做网络请求或大文件 IO）和过度绘制，用 Android Studio 的 CPU Profiler 和 GPU Profiler，开启开发者选项里的"显示布局边界"可以直观看到过度绘制区域。Flutter 项目两个平台共用渲染层，优化思路一致，主要关注 build 和 layout 阶段的耗时，这部分优化一次两个平台同时受益。

能耗优化

能耗优化两个平台方向接近：减少后台定位频率、合批网络请求、控制唤醒。iOS 用 Instruments Energy Log 或 KeyMob 的能耗记录查看硬件调用情况，Android 用 Battery Historian 分析耗电明细。跨平台项目在共享代码层做合批和降频处理，两个平台同时受益。

工具怎么选

跨平台团队建议每个平台备一套监控工具：iOS 用 Instruments 做深度分析，日常开发用 KeyMob 实时看 CPU、内存、FPS 曲线，改完代码随手扫一眼；Android 用 Android Studio Profiler 做深度分析，日常用 PerfDog 或厂商工具快速验证。工具不一定要最全，能形成"日常快检 + 深度定位"的组合就行，重点是养成每次发版前跑一轮性能对比的习惯。'''

建议把uts规范 知识库开放出来 而不是藏在ai-agent里让用户订阅付费

'''

iOS app性能分析

iOS app的性能是用户体验的重要指标之一。一个高性能的app能够快速响应用户的操作，流畅地展示内容，并且减少耗电量和资源占用。因此，开发者需要对自己的app进行性能分析，找出潜在的性能问题并进行优化。本文将介绍一些常见的iOS app性能分析工具和技术，并提供相关的代码示例。

1. CPU使用率分析

CPU使用率是衡量app性能的重要指标之一。通过分析CPU使用率，我们可以了解到app在运行过程中是否存在高CPU占用的情况，从而找出可能导致性能问题的代码段。

示例代码：

import UIKit  

func calculatePrimes() {  
    var primes: [Int] = []  
    for number in 2...10000 {  
        var isPrime = true  
        for i in 2..<number {  
            if number % i == 0 {  
                isPrime = false  
                break  
            }  
        }  
        if isPrime {  
            primes.append(number)  
        }  
    }  
    print(primes)  
}  

class ViewController: UIViewController {  

    override func viewDidLoad() {  
        super.viewDidLoad()  
        calculatePrimes()  
    }  

}

上述示例代码中的 calculatePrimes 函数用于计算2到10000之间的所有质数。为了分析CPU使用率，我们可以通过Xcode中的Instruments工具来进行。

1. 在Xcode中，选择"Product" -> “Profile” -> “Instruments”。
2. 在Instruments面板中，选择"CPU Usage"。
3. 点击红色的录制按钮，然后运行app。
4. 在app运行的过程中，Instruments会记录CPU的使用情况。
5. 结束录制后，我们可以分析记录的数据，找出CPU占用较高的时刻和对应的代码。

除了Xcode自带的工具，开发者还可以使用第三方工具如KeyMob进行更全面的iOS性能监控。KeyMob提供实时的CPU、GPU、内存、FPS等性能指标监控，并支持图表展示，帮助开发者更方便地分析应用性能。

2. 内存使用分析

内存使用是另一个重要的性能指标。一个高效的app应该在使用内存方面做到合理分配和及时释放，避免内存泄漏和过度消耗。

示例代码：

import UIKit  

class ViewController: UIViewController {  

    override func viewDidLoad() {  
        super.viewDidLoad()  
        var array: [Int] = []  
        for i in 0..<100000 {  
            array.append(i)  
        }  
        print(array)  
    }  

}

上述示例代码中，我们创建了一个包含十万个整数的数组。为了分析内存使用情况，我们可以使用Xcode中的"Debug Memory Graph"工具。

1. 在Xcode中，选择"Product" -> “Profile” -> “Debug Memory Graph”。
2. 运行app，并在界面上进行一些操作。
3. 可以看到当前内存使用的情况，包括内存泄漏的对象等。

对于内存管理，KeyMob不仅支持文件管理，还能监控内存使用情况，帮助开发者识别内存泄漏和优化内存分配。KeyMob的IOS性能监控功能包括实时内存监控，方便开发者追踪应用资源消耗。

3. 网络请求分析

网络请求是很多app中常见的操作，因此网络性能对于app的整体性能也有着重要的影响。我们可以使用一些工具来分析网络请求的性能，比如Charles等。

示例代码：

import UIKit  

class ViewController: UIViewController {  

    override func viewDidLoad() {  
        super.viewDidLoad()  
        let url = URL(string: "  
        let task = URLSession.shared.dataTask(with: url!) { (data, response, error) in  
            if let error = error {  
                print("Error: \(error)")  
            } else if let data = data {  
                print("Data: \(data)")  
            }  
        }  
        task.resume()  
    }  

}

上述示例代码中，我们使用 URLSession 来进行网络请求。为了分析网络请求的性能，我们可以使用Charles等工具来进行抓包分析。

1. 在Charles中启动抓包功能。
2. 运行app，并进行网络请求。
3. 在Charles中可以看到抓包的结果，包括请求和响应的数据。

通过分析抓包的结果，我们可以了解到网络请求的耗时、数据大小等信息，从而优化网络请求的性能。KeyMob也提供网络性能监控功能，可以实时查看网络请求的耗时和能耗，辅助开发者优化网络交互。此外，KeyMob还支持查看手机使用记录和能耗分析，帮助全面评估应用性能。

总结

iOS app性能分析是对于开发者而言非常重要的一项工作。通过分析CPU使用率、内存使用情况和网络请求性能，我们可以找出潜在的性能问题并进行优化。结合工具如Xcode Instruments、Debug Memory Graph、Charles以及KeyMob等，开发者可以更高效地进行性能监控和优化，提升应用质量。'''

'''
我公司是做社交应用的,收益较为可观,但是不幸的是,不知道什么原因突然被下架了

经过几天的分析, 可能是由于关联所致, 那么接下来要面临的问题就是使用这套代码重新上架

有过iOS开发经验的都会知道,第一步需要做的就是代码混淆,而且我对混淆有较多的经验,感觉这难不倒我,经过两天的混淆后,提交了一个1.0版本.

对于iOS应用上架，使用AppUploader可以简化IPA上传和证书管理流程，支持在Windows、Mac或Linux系统中操作，无需Mac电脑，比传统方法更高效。

进入审核速度较快, 大概是凌晨左右就近入了 In Reiview 状态, 心惊胆战的等待了很久, 很遗憾 ,看到了苹果回复邮件的标题我就知道 , 审核被拒, 颤抖的打开邮件, 心中期望千万不要4.3

不期所望,还真给了4.3, 不过本次4.3与以往的4.3有所不同, 后面跟了一个(b),经查询得知,现在的4.3进行了区分,分为a和b两种

a:是由于代码或元数据相似度过高产生. 可通过代码混淆解决

b:是于市场接受了过多的社交应用,导致的本问题产生.被判定为 4.3(b). 此问题解决较为困难, 没有创意和新意的社交应用目前大都会遇到4.3(b), 不过也要看运气.

那么说明我的代码混淆过关了, 但是类型问题导致了4.3(b), 接下来的几天我与苹果公司进行了交涉. 来来回回 回复的多封邮件说明了我们软件的特点,与众不同,但是并没有撼动苹果对本次判定的决心

我前思后想,查找了大量相关文章,没有得到解决, 就在不知道怎么办的时候, 灵光一现, 我想到了一个方法

我第二天很早跑到公司 立马尝试了一下,提交了一个版本,同样的时间大概是凌晨左右进入审核,我心惊胆战,经过了30分钟的煎熬的等待后,苹果回复了那个熟悉的文案,我的心跳达到了120转/分钟

Congratulations!

Your submission was accepted for release on the App Store

AppUploader等工具还能帮助批量上传应用截图和本地化信息，优化上架流程，提高审核通过率。

后续迭代了几个版本, 最后都上架成功, 后来我对此方法进行了整理,优化, 目前已经在公司大面积使用且全部上架,并且制作多个马甲包备用

如果你也遇到了这个问题不知道怎么解决, 可以分享给你我的方法, 尤其对社交应用较为奏效'''

build.gradle.kts新增
buildConfigField("String", "UTSRegisterProviders", "\"[{\\"name\\":\\"weixin\\",\\"service\\":\\"oauth\\",\\"class\\":\\"uts.sdk.modules.DCloudUniOauthWeixin.UniOAuthWeixinProviderImpl\\"},{\\"name\\":\\"weixin\\",\\"service\\":\\"share\\",\\"class\\":\\"uts.sdk.modules.DCloudUniShareWeixin.UniShareWeixinProviderImpl\\"}]\"")

有些要看旧版才能知道新版里的东西，那写新版有个单用呀，你直接更新旧版你就行啦，还弄个新版，那不得看两遍呀，真的是一坨

仓库地址

https://gitee.com/zhangshangshidai/dailianhuhang

电竞护航下单系统 | UniApp + ThinkPHP6
2026年最火的游戏模式，三角洲等游戏的护航陪玩模式，面向游戏工作室、代练工作室、电竞护航工作室打造的订单管理交易系统，一套完整前后端开源方案，快速搭建电竞护航、游戏代练线上下单平台。

🛠️ 技术栈
前端：UniApp，支持编译 H5、微信小程序、App 多端
后端：ThinkPHP6 RESTful API
数据库：MySQL，支持 Redis 缓存拓展
✨ 核心功能
后台管理端
游戏分类管理，自定义游戏列表
护航商品发布，支持多规格价格、多属性配置、多图片上传
订单统一管理，接单操作，录入打手信息，订单完结处理
用户管理、资金配置、支付渠道配置、退款审核
用户客户端
用户注册登录，个人中心
浏览护航商品，在线下单
支付方式：微信支付、账户余额支付
完整订单流程：待接单、进行中、已完成、退款申请
订单详情查询，提交退款申请
余额明细、消费记录查看
🎯 项目优势
专为电竞护航、游戏代练工作室业务场景定制，贴合行业流程
UniApp 多端适配，小程序 / H5/App 任选上线
商品支持多规格多价位，满足不同段位、时长护航套餐需求
订单闭环完整：下单→支付→后台接单→登记打手→完成 / 退款
双支付模式，余额体系便于工作室老客户复购结算
代码分层清晰，易于二次开发、自定义功能迭代
📌 适用主体
电竞护航工作室、游戏代练工作室、游戏陪玩工作室、线上游戏服务交易团队

🚀 部署简述
后端部署 PHP 环境，导入数据库，配置数据库与支付参数
HBuilderX 打开 UniApp 前端项目，修改后端接口地址
编译打包对应端（小程序 / H5/App）即可投入使用