'''## 从 Instruments 到 KeyMob 克魔：四款我用过的 iOS 性能分析工具

做 iOS 开发这几年，越来越有一个体会：你写的代码，不一定能跑得快；能跑得快的代码，也未必跑得稳。无论是做原生开发，还是混合框架（Flutter、React Native、Unity等），最终用户体验好不好，常常取决于你能否及时发现并解决那些看不见的性能问题。

这篇文章我不打算大谈优化技巧，而是想结合自己的开发经验，分享四款我在日常开发中反复使用过的 iOS 性能分析工具，包括大家熟悉的 Instruments，也包括最近发现的 KeyMob（克魔）这种国产小众但实用的工具，希望对你有所帮助。

1. Instruments（Xcode 自带）

如果你做 iOS 原生开发，一定绕不开 Instruments。它是 Xcode 内置的一整套性能分析工具，涵盖 CPU、Memory、Time Profiler、Leaks、Energy Log 等多个模块。

在一个 SwiftUI 项目中，我们遇到过界面打开瞬间卡顿的问题。用 Time Profiler 跑了一次，很快就发现是在 NavigationLink 中触发了大量 View 计算，而这些计算又引发了内存分配暴涨。后面我们通过结构优化和懒加载处理后，页面切换流畅度提升了不止一点。

优点：

• 官方工具，数据精度高；
• 功能齐全，分析全面；
• 适合查找底层瓶颈。

不足：

• 使用门槛高，界面不够友好；
• 需要连接 Xcode，分析流程不轻便；
• 分析结果不易分享，团队协作不便。

2. Charles / Proxyman（网络调试）

网络请求慢、失败、重复发送这些问题，在 App 性能优化中非常常见。Charles 是我最早用的抓包工具，可以查看 App 所有 HTTP/HTTPS 请求，还能修改参数、断点调试。

不过 Charles 在 macOS 上的体验不算特别好，于是后面我换成了 Proxyman，它界面更现代，支持 Apple Silicon，证书配置也更自动化。

在做一个 hybrid App 时，我们用 Charles 成功抓到了某一段 iframe 中 JS 请求耗时超过 2 秒的问题，而 Proxyman 用于 Flutter 项目的时候也能清晰地看到某些 Dart 层发出的冗余请求。

3. KeyMob 克魔（性能监控 + 文件分析 + 日志查看）

这是我最近半年接触的一款工具，使用频率意外地高。最初是同事推荐，说可以“不越狱查看真机App性能”，我半信半疑，试了发现功能确实很全，而且对开发者非常友好。

使用场景一：帧率突降问题分析

有个老项目（基于Unity）在低端 iPhone 上运行时偶尔会卡顿，用 Instruments 查不到明显问题。后来我们用 KeyMob 的“应用帧率实时监控”功能，直接在 iPhone XR 上测试，结果发现 GPU 使用率一到特定页面就飙升。

再结合它的 GPU 图表与帧率折线对比，很快确认是某个粒子动画在低端设备上渲染压力太大。关闭动画后，帧率稳定在 60fps。

使用场景二：日志与崩溃信息提取

在一次上线版本中，用户频繁反馈 App 崩溃，但后台日志缺乏足够信息。KeyMob 可以导出 iPhone 真机上的 crash log，并支持符号化和格式化，省去了用 Xcode 连线调试的麻烦。

使用场景三：文件系统与数据解密

这个功能我一开始没太在意，后来发现在调试一些 App 的离线缓存逻辑时特别有用。KeyMob 可以列出所有 App 的目录结构，包括用户数据、缓存、配置文件等，而且支持直接解密某些 App 保存的数据内容（比如图片、音频、视频等），无需越狱。

此外，它还能查看历史使用记录（如 App 启动/关闭时间、能耗使用情况），非常适合做使用行为分析。

优点：

• 不依赖 Xcode，跨平台支持（Windows/macOS/Linux）；
• 界面清晰，使用上手快；
• 功能集成度高，尤其适合需要查看系统底层文件的开发者。

不足：

• UI 偏向工具性设计，不够“美观”；
• 某些系统权限功能仍有一定限制。

4. FLEX / Reveal（界面层级分析）

调试界面布局问题时，FLEX 是个小巧但非常高效的利器。它可以直接嵌入 App 中运行，在运行时查看 View 层级、响应链、属性等，非常适合分析一些 UI 异常问题。

Reveal 则更强大，支持可视化查看整个 App 的界面树，像是 Photoshop 看图层一样。缺点是只能在 macOS 上运行，而且需要连线。

我们之前在排查一个 SwiftUI 弹窗层级异常时，用 Reveal 很快发现是某个隐藏的透明 View 抢占了触控响应，省去了大量手动猜测调试时间。

结语：优化是一场信息战

iOS 性能调优并不神秘，关键在于你是否拥有合适的工具去洞察 App 的真实运行状态。Instruments 给了你最底层的“手术刀”，Charles/Proxyman 让你看清网络层的脉络，而 KeyMob 克魔这样更靠近系统的数据分析工具，能在你找不到 Xcode 的时候仍然提供第一手信息。

开发本就是不断踩坑与修复的过程，如果工具能让你少踩两次坑，那就值得一试。'''

'''# 一个跨平台开发者如何在没有 Mac 的情况下把 iOS 应用上架？

前段时间我们团队做了一个用 Flutter 开发的 App，Android 上架很顺利，结果到了 iOS 上架环节卡了整整三天。

这段经历让我深刻体会到：对很多非苹果阵营的开发者来说，iOS 上架门槛真的不低——尤其是当你没有一台 Mac 的时候。

我们当时面临的问题：

1. 没 Mac —— 公司是以 Windows 为主的开发环境，测试机倒是有，但不能拿来做构建和证书管理。
2. 证书配置繁琐 —— iOS 的开发者证书、发布证书、描述文件一大堆，而且如果不是用 Xcode 的 GUI，纯命令行配置真的很绕。
3. IPA 上传困扰 —— Application Loader 早就被淘汰了，altool 有的版本还依赖 Xcode CLI。
4. 协作困难 —— 团队中不同成员需要用到不同的证书，光同步这些文件就头疼。

尝试了几个方案：

• 一开始我们试过用 macOS 虚拟机，理论上可行，但各种签名问题搞了半天都没成功，而且速度极慢。
• 后来又找了第三方上传工具，比如 Fastlane，虽然很好用，但证书申请和管理依旧不够便捷。
• 最后，我偶然试到了一个叫 Appuploader 的工具，给我的体验说实话有点像是找到了另一个维度的 Application Loader。

Appuploader的作用

它有点像是证书申请器 + App Store Connect 批处理工具 + 设备测试工具的合体。我是直接在一台 Linux 上用它上传 IPA 的——流程如下：

1. 创建一个 Apple 开发者账号
2. 用这个工具直接创建开发/发布证书（甚至不需要钥匙串助手）
3. 一键打包好 IPA 后上传
4. 本地设备测试安装也支持（扫码安装比 testflight 快）

更好的是，它支持团队证书协同，这对多端协作来说非常友好。

> 补充一下，这里我也用了 Fastlane 来生成 metadata，再通过这个工具上传，效率大大提升。

和其他工具配合效果更佳

比如截图我用的是 shotbot.io 自动生成的，配合这个工具的多语言上传接口，基本可以做到全自动化批量上传——包括 App 描述、关键词、截图、多语言等内容。

如果你是用 Flutter、React Native 等框架，强烈建议你探索一下这些组合打法。上架流程可以快到令人惊讶。

写在最后

当然，Appuploader并不一定适合所有人。如果你手上有 Mac，Xcode 用得顺畅，Fastlane 配得得心应手，那可能你未必需要它。

但如果你是像我一样的跨平台开发者、或者你的主开发环境不是 macOS，真的可以考虑试试这种组合。

我只是作为一个曾经在上架环节抓狂了无数次的开发者，记录下我找到的一个可行的解决方案。'''

'''### 在日常开发中，我是如何处理各种网络抓包场景的？

做移动端开发久了，几乎所有人都会遇到调试 HTTPS 请求的烦恼。特别是 iOS 平台，不越狱就想抓包？早年想都不敢想。

有一次，我在排查一个移动 App 的登录失败问题，明明服务端响应是 200，但客户端死活提示“网络错误”。这类问题最直接有效的方法就是抓包，可惜当时没办法在非越狱设备上获取 HTTPS 内容。尝试了各种工具，不是配置复杂就是证书安装过程卡人。最终只得抓桌面端流量间接判断，非常低效。

直到我发现几个功能强的跨平台抓包工具，才真正解决这个问题。

多平台调试的那些工具们

目前我个人使用的工具组合主要有：

• Wireshark（老牌选手，适合底层协议分析）
• Charles（经典 GUI 工具，适合代理模式）
• 抓包大师 Sniffmaster（最近在重度使用，主要解决 iOS 抓包痛点）

举个真实例子：最近测试一个 iOS 客户端的支付流程，遇到 HTTPS 双向验证。Charles 和 mitmproxy 根本搞不定，设备拒绝连接代理。但用 Sniffmaster 插上设备直接分析系统层 TCP 数据流，不用越狱、不用改配置，明文内容直接看，甚至还能爆破 HTTPS 双向认证。抓包效率直线上升。

Sniffmaster 还能直接写 JavaScript 脚本对请求/响应做修改，在调试 ABTest 场景时特别方便，比如强制替换某个响应字段、注入参数、模拟慢速网络等。

日常常用技巧

对于复杂项目，我建议大家：

• 多使用域名过滤：只抓某个目标服务，排除无关请求
• 保存特定数据包：以便问题复现或团队讨论
• 配合脚本编写 mock 响应：无需后端参与也能前端调试

这些技巧，在 Charles 或 mitmproxy 中都能实现，但 Sniffmaster 的脚本支持和自动识别协议能力（如 HTTP, HTTPS, mDNS）让调试更自然。

小结

每个工具都有它的用武之地。Wireshark 在深入协议层时无可替代，Charles 简洁直观适合快速调试，而 Sniffmaster 真正让我在 iOS HTTPS 抓包上不再焦虑。

对开发者来说，提升调试效率的工具，不在多，而在于贴合你的工作场景。下次你再被“iOS 抓不了包”困扰时，不妨试试不同的组合，说不定就有惊喜。

（以上内容纯属个人经验分享，如有兴趣，可深入研究各类抓包工具的官方文档和案例）'''

HbuilderX 打包后打开某个页面报错TypeError in data() no access。但是在本地电脑端运行时正常。
最近 HBuilderX对
data() {
return {
}
}
其中的 return进行了规则附加校验。

之前:
data() {
return {
offlineSignAction: Function(),
offlineInputAction: Function(),
}
}编译运行通过、打包后通过。

现在：
data() {
return {
offlineSignAction: Function(),
offlineInputAction: Function(),
}
}编译运行通过、打包后不通过。
目前Hbuilder云打包不支持上述语法。

'''最近在给一个 Hybrid App 项目做移动端适配，遇到个老大难问题：WebView 页面在 iOS 上表现一切正常，Android 上却死活点不动某个按钮。最离谱的是，这个 bug 还不一定复现，每次重启又好了。

我一开始以为是 CSS 或 JS 写得有问题，但用 console.log 打了半天也没看出什么。于是开始研究各种调试工具，趁这次机会总结一下这几种工具的体验，也算是给有类似需求的开发者一点参考。

Chrome DevTools + 模拟器

最基础的办法，调试 Android WebView，理论上 Android 系统自带的浏览器或 WebView 是支持远程调试的。在 Chrome 浏览器里 chrome://inspect/#devices 可以连上模拟器或真机。

优点：

• 上手简单
• 接近熟悉的 DevTools 界面

缺点：

• 只能调试 Android，iOS 完全不行
• 有时连接不上，设备识别有延迟
• WebView 要打开调试开关才能看到内容

结论：入门可用，但局限性大。

Safari 开发者工具

用 Mac 开发的同学可能都用过 Safari 的调试工具，可以连接 iOS 真机上的 Safari 页面。

优点：

• 调试原生 Safari 页面还不错
• 连线比较稳定

缺点：

• WebView 页面看不到（unless 你控制了 app 的调试配置）
• 功能不如 Chrome DevTools 丰富

结论：仅限 iOS + Safari 场景，WebView 基本无用。

Charles / Proxyman / Fiddler

这些抓包工具倒是挺稳的，网络层能看到很多东西。比如：

• 查看请求 headers、body、响应内容
• 重放请求、模拟失败
• 观察加载时间

缺点显而易见：

• 看不到 DOM / JS / 样式
• 只是网络层，页面逻辑一头雾水

结论：搭配使用不错，但调试网页不够全面。

WebDebugX

这是我在逛 GitHub 的时候看到有人推荐的工具，本来没抱太大希望，结果真香。

WebDebugX 支持跨平台运行，我用的是 Linux 版，几乎 plug and play。连接 Android 或 iOS 设备后，可以实时调试 Web 页面或 WebView。

实际用例：我调试一个页面支付流程时，发现某些状态参数丢失。用 WebDebugX 的控制台 + 网络面板查了下，原来是 session 跨域 cookie 没同步成功，前端也没有 fallback 逻辑。

功能亮点：

• 类似 Chrome DevTools 的调试体验（元素、控制台、源码、网络、性能）
• 真机页面实时同步改动
• 网络请求可以断点、拦截、修改
• 性能面板能查内存和 CPU 使用

结论：目前我主力使用的调试工具，特别适合 WebView 开发。

RemoteDebug + ADB 端口转发

这个方式比较折腾。你得在 JS 中手动插入 remote debug client，再通过 ADB 把端口转发到本地。理论上能实现调试，但流程比较原始。

适合哪些人？框架开发者、高级调试场景、或是爱折腾的人。

我试过一次，花了两个小时配置环境，最后还是放弃了。

总结

调试移动端网页确实不容易，不同工具有各自擅长的领域：

• 快速看请求：用 Charles
• Android WebView：Chrome DevTools
• iOS 原生浏览器：Safari 开发者工具
• 高效调试 WebView：我推荐 WebDebugX

欢迎大家留言说说你们还用过什么调试工具，有哪些奇技淫巧，一起提升调试效率！'''

'''> 一行代码的疏忽，一个默认的类名，一个未混淆的资源路径，都可能成为攻击者入侵的入口。

背景：一次“不值一提”的上线，成了代价惨重的经验

故事的起点很简单：我们给销售部门做了一款小型内部演示 App，用企业证书分发、功能不复杂。但上线第三天，就有人在外部反馈：“UI 被换了、支付接口接不上”。我们本以为是网络或环境问题，结果越查越离谱——App 被别人重新打包、修改接口、重新分发。

用一句话总结：我们以为发的是 App，其实是开源代码 + 自带手册 + 后门。

破解流程（模拟复现）

出于排查目的，我们对泄露版本做了完整逆向操作流程，发现攻击者的路径清晰明确：

1. 下载原始IPA，使用 7zip 或 unzip 解压结构
2. 用 class-dump 分析 OC 类结构，或者直接拖进 Hopper 查看可读符号
3. 查找关键方法如 verifyLoginWithCode: 或 uploadUserInfo:
4. 修改资源（如 JSON、图标、文本提示等）
5. 重新打包并使用企业签名工具签回
6. 分发灰色版本到越狱社区或私人微信群

整个过程没有门槛，完全自动化脚本都可完成。

解决：使用 Ipa Guard 做混淆保护（以及其他工具实测）

我们开始调研市面上几种 iOS IPA 文件的后处理方案，不依赖源码、支持已有 IPA 文件操作的工具非常少见。幸运的是我们测试到 Ipa Guard，以下是测试结果：

特性一：无需源码

直接读取 IPA，处理二进制和资源层，无需原始工程，适合 CI/CD 流程接入。

特性二：类名、方法名、参数名等符号随机重命名

即使攻击者使用 class-dump 或 Hopper 也无法一眼看出 loginManager 或 payToken 等关键词。

特性三：资源文件全路径重命名

图片、xib、json、mp3 文件名自动更换为无意义字符，并修改 MD5、避免通过差异比对还原。

特性四：本地执行，无需云端上传

整个混淆流程可在本地运行，避免代码上传过程的隐患。

我们实际应用的方案组合如下：

实战建议：开发者该如何应对“看得见的裸奔”

1. 默认方法名是最大漏洞源
   一定要避免出现业务意图强烈的类名，例如 PayManager, LoginHandler, UserCenterVC，越容易读懂，越容易破解。
2. 资源文件同样暴露大量信息
   我们测试中发现攻击者甚至通过图片中的 UI icon 猜出功能走向，资源文件混淆应当列入开发安全策略。
3. 混淆不是为绝对安全，而是为拖延攻击者
   正如 HTTPS 也能被中间人攻击，混淆无法“绝对防护”，但它让破解成本翻倍，对中低水平攻击者具备极强抑制力。

结语：安全防护永远是主动而非补救

我们希望分享这些经验不是为了“宣传某个工具”（事实上我们也评估了多个方案），而是想提醒每一位开发者：App 一旦发出门，就不属于你了。

从 Ipa Guard 到 class 名脱敏，从注入检测到资源哈希比对，工具永远是手段，关键是你是否意识到自己的 App 正在裸奔。

hh-router-guard

一、插件简介

hh-router-guard 是一款专为 UniApp 框架设计的路由守卫插件，基于 Vue 3 构建。它提供了强大的页面访问权限控制、登录拦截和白名单功能，帮助开发者轻松管理应用的路由权限，提升应用安全性和用户体验。

通过简单配置，您可以：

• 拦截所有页面跳转请求，实现统一权限校验
• 强制未登录用户跳转至登录页面
• 灵活定义无需登录即可访问的白名单页面
• 自定义登录状态检查逻辑和错误处理机制

二、版本信息

• 当前版本：1.0.0
• 更新日期：2025-05-12
• 兼容性：支持所有 UniApp 支持的平台（微信小程序、H5、App、支付宝小程序等）

三、安装与引入

方式一：从 DCloud 插件市场下载

1. 访问 hh-router-guard 插件详情页
2. 点击「使用 HBuilderX 导入插件」按钮，将插件导入到您的项目中
3. 插件会自动被放置在项目的 uni_modules 目录下

方式二：手动导入

1. 下载插件源码压缩包
2. 将解压后的文件复制到项目的 uni_modules/hh-router-guard 目录

引入插件

在项目的 main.js 中引入并注册插件：

import { createSSRApp } from 'vue'  
import App from './App.vue'  
// 从 uni_modules 引入插件  
import routerGuard from '@/uni_modules/hh-router-guard/src/index'  

export function createApp() {  
  const app = createSSRApp(App)  

  // 安装路由守卫插件  
  app.use(routerGuard, {  
    // 配置选项  
  })  

  return { app }  
}

四、快速上手

基础配置

以下是一个基础配置示例，展示如何设置白名单和登录检查逻辑：

app.use(routerGuard, {  
  // 白名单：无需登录即可访问的页面路径  
  whiteList: [  
    '/pages/login/index',      // 登录页  
    '/pages/public/*',         // 所有公共页面  
    '/pages/about',            // 关于页  
  ],  

  // 自定义登录检查函数（返回 true 表示已登录）  
  checkLogin: () => {  
    const token = uni.getStorageSync('token')  
    return !!token  
  },  

  // 登录页面路径  
  loginPath: '/pages/login/index',  

  // 未登录时的处理逻辑  
  loginHandler: (to) => {  
    uni.navigateTo({  
      url: `${loginPath}?redirect=${encodeURIComponent(to)}`  
    })  
  }  
})

完整配置选项

五、高级用法

自定义错误处理

您可以通过 errorHandler 选项自定义错误处理逻辑：

app.use(routerGuard, {  
  // ...其他配置  
  errorHandler: (error) => {  
    uni.showToast({  
      title: `路由错误: ${error.message}`,  
      icon: 'none'  
    })  
  }  
})

在组件中使用

插件会在 Vue 实例上挂载 $routerGuard 对象，您可以在组件中访问：

export default {  
  methods: {  
    checkPermission() {  
      const isAllowed = this.$routerGuard.check('/pages/protected')  
      console.log('当前用户是否有权限:', isAllowed)  
    }  
  }  
}

六、示例项目

以下是一个完整的项目示例结构，展示如何集成和使用 hh-router-guard：

your-project/  
├── pages/  
│   ├── login/  
│   │   └── index.vue         # 登录页面  
│   ├── public/  
│   │   ├── index.vue         # 公共页面  
│   │   └── about.vue         # 关于页面  
│   └── protected/  
│       └── index.vue         # 需要登录才能访问的页面  
├── uni_modules/  
│   └── hh-router-guard/     # 插件目录  
├── App.vue  
└── main.js                   # 引入和配置插件的文件

七、更新日志

v1.0.0 (2025-05-12)

• 初始版本发布，支持基本的路由拦截、白名单和登录检查功能
• 新增：支持自定义错误处理函数
• 优化：增强插件的容错能力，避免因配置错误导致应用崩溃
• 改进：添加版本信息输出，方便追踪插件版本

八、常见问题

1. 如何解决 "routerGuard is not defined" 错误？

• 确保插件路径正确，特别是从 uni_modules 引入时
• 检查插件是否正确导出（使用 export default）
• 尝试重启 HBuilderX 清除缓存

2. 白名单路径支持哪些匹配模式？

• 完全匹配：如 /pages/login/index
• 前缀匹配：如 /pages/public/* 会匹配所有以 /pages/public/ 开头的路径

3. 如何在小程序和 H5 中使用不同的登录逻辑？

您可以在 checkLogin 函数中通过 uni.getSystemInfoSync().platform 判断运行环境，实现差异化逻辑：

checkLogin: () => {  
  if (uni.getSystemInfoSync().platform === 'h5') {  
    // H5 平台的登录检查逻辑  
    return localStorage.getItem('token') !== null  
  } else {  
    // 小程序平台的登录检查逻辑  
    return uni.getStorageSync('token') !== ''  
  }  
}

九、贡献与反馈

如果您在使用过程中遇到问题或有任何建议，欢迎：

• 在 插件市场评论区 留言反馈
• 提交 Issues 到 Github 仓库
• 提交 Pull Requests 参与开发

十、许可证

本插件采用 MIT 许可证 发布，您可以自由使用、修改和分发。

'''# 日常开发中，那些帮我省下无数时间的抓包工具

在iOS开发这几年里，遇到最多的问题，除了证书安装失败和接口调试不通，就是“我到底怎么才能方便地抓到这个App的网络包？”

一开始，我们都用Charles

如果你是前端或iOS新手，最先接触的应该是 Charles。UI不错，代理配置方便，还有各种断点修改功能。它对HTTP支持很好，对HTTPS支持也算稳定，但iOS设备上用它，难点主要有两个：

• 要配置 WiFi 代理，并安装证书
• 多数App现在启用了 HTTPS 双向验证（SSL Pinning），这就麻烦了

这时候很多人就放弃了。

Fiddler：老牌PC工具，但不太适合移动端

Fiddler 对Windows用户来说非常熟悉，特别是在企业内网或者做接口分析的时候。但它的劣势也明显：

• 在Mac上体验不佳
• 对iOS设备抓包依旧需要设置代理
• 双向验证的App依然无法搞定

你可以试着配合一些动态注入工具（例如 Frida）手动绕过pin校验，不过成本很高，效率低。

Wireshark：强大但门槛高

如果你想分析TCP、UDP甚至底层协议，Wireshark几乎无敌。但它也不是真正意义上的“开发者日常工具”。
比如你只是想看看某个App是不是成功登录、调用了哪个API，Wireshark就过于重量级了。

那有没有一个更轻量、直观，而且不需要越狱就能抓App包的方式？

其实有很多类似小工具这两年都在兴起，比如 PacketCapture、HTTP Catcher、Thor 等。有些是iOS App 有些是桌面软件，每个都有优缺点。

在尝试了几个之后，我现在用得比较多的，是一个叫 抓包大师（Sniffmaster） 的桌面端工具。它有个我非常喜欢的特性：

> HTTPS抓包插上设备就能直接抓包，不需要配置WiFi代理，也不需要越狱。

比如有次我在调试一个使用了 SSL pinning 的 App 登录逻辑，用传统方法抓不了包。用它插上iPhone，点击App登录，立刻就能看到 HTTPS 解密后的请求内容，包括完整的请求头、Body、返回状态码和数据。

它和其它工具的主要差别是：

• 支持直接插线抓包（iOS/Windows/mac都支持）
• 自动安装证书，不弹窗，不提示，静默处理（非常适合内测和大批量设备调试）
• 内置拦截器，可以写 JavaScript 脚本动态修改请求或响应，等于是把 Charles 的断点调试功能提了个速

当然，我并不是说它一定比其它工具强，只是这套“即插即用、HTTPS免代理免越狱、还能脚本拦截”的组合，确实让我这半年开发效率提升不少。特别是测试阶段抓取登录、支付流程的数据，方便得多。

总结

其实工具没有好坏，只有适不适合当前任务。Charles适合做基础代理调试，Fiddler是Windows上的经典之选，Wireshark适合协议分析。而像抓包大师这种新型工具，更适合做移动端HTTPS解密和快速验证。

有时候，把工具换一换，效率就上来了。'''

为了减轻服务器负担，不少站长会选择将图片托管在图床上。本文整理了一些好用的免费图床服务（文末也列出了部分收费图床）

2025.05.04更新:

五一期间更新，追加图床，自测都是可用的图床。

1. 敖武的图床 支持免费使用，支持多种格式

原推荐图床：

原文来自网络，我进行了有效性的验证，已删除无效图床，并会进行长期更新维护，方便大家使用。

1.微博图床

堪称国内图床的中流砥柱，很多站长都在用。各种插件和在线上传都层出不穷，使用起来很方便。

• 速度：国内国外都非常快

• CDN：国内分别接入使用了蓝汛、网宿、阿里云 CDN、加速乐等，在国外使用了 Akamai CDN、http://Tierra.Net 的 CDN 等

• HTTPS：支持（不完全支持 HTTP2，得看你被解析到了哪个服务商的节点）

• 域名：

• ww1.sinaimg.cnww2.sinaimg.cnww3.sinaimg.cnww4.sinaimg.cn

• wx1.sinaimg.cnwx2.sinaimg.cnwx3.sinaimg.cnwx4.sinaimg.cn

• ws1.sinaimg.cnws2.sinaimg.cnws3.sinaimg.cnws4.sinaimg.cn

• 等等等等。。。

• 上传地址

• Chrome 插件

2.sm.ms 图床

土豪兽兽建的图床，2015 年开始正式运营。

• 速度：现在估计是被滥用了没那么快了 烧风购买了更多节点、修改了服务架构，现在全球速度还是不错的。

• CDN：烧风自建的 CDN，有香港阿里云、DigitalOcean 欧洲和 Linode 北美等节点

• HTTPS：HTTP 会被 301 跳转 HTTPS（支持 HTTP2）

• 域名：ooo.0o0.oooi.loli.net

• 上传地址

支持 API 操作，图片存储非常可靠，V2EX 钦点的图床。iOS 和 Android 应用 即将开发完毕已经分别上架 iTunes 和 Play Store，甚至有第三方做的 Telegram Bot。在众多公共图床中最看好它和 imgur。

3.ooxx

V2EX 上找到的一家老牌图床，2013 年就开始运营了，不过 2017 年年初才在 V2EX 上发帖。

• 速度：CloudFlare 的网络特点，大家都懂

• CDN：CloudFlare

• HTTPS：支持（支持 HTTP2）

• 域名：i.ooxx.ooo

• 上传地址

V2EX 上的介绍说最早是为了收集一些网络图片作为大数据分析和机器学习用的，所以借用机器闲置的带宽搞了这个图床。运营了四年，看起来还会继续运营下去。

4.PostImage

• 速度：国外速度杠杠的，国内别被墙就好

• CDN：AdvancedHosted CDN

• HTTPS：支持

• 域名：s1.postimg.orgs2.postimg.org 等。

• 上传地址

PostImage 图床的介绍说是为了方便用户在 Facebook 和 Twitter 上传图。这个图床用的 CDN 服务商不太有名。

5. http://6.UPLOAD.CC

• 速度：看下面一条用的 CDN

• CDN：CloudFlare

• HTTPS：支持

• 域名：upload.cc。

• 上传地址

这个图床是香港人开的，TOS 写的挺详细的。提供了 Android 版 APP（Google Play 上可下载），还提供有 Chrome 和 Firefox 的插件，挺方便的。

6.小贱贱图床

• 速度：一般般~获取一个简单的外链，图床用的是微博空间，速度很快，但是图片清晰度会变低。

• 每日可以上传图片20张，上传后可以

• 上传地址

7.聚合图床

• 速度：集合多家图床，速度还是可以的~

• 上传时一张图片会分发至多个图床，同时图片会保存在本站服务器上

• 上传地址

8.偶流社区图床

• 免注册，有一定历史，比较可靠

• 限制：图片最大10M，不定期会清理垃圾文件

• 上传地址

9.路过图床

• 支持免注册上传图片，永久存储，支持HTTPS加密访问和调用图片，提供多种图片链接格式

• 限制：最大10M

• 上传地址

10.极简图床

• 主要提供图片上传和管理界面，需要用户自己设置微博、七牛云或者阿里云OSS信息

• 目前站点维护，原因不详

• 上传地址

11.Imgbb

• 最大 16 MB 图片大小. 直接的源图片链接, BBCode代码和HTML缩略图显示

• 上传地址

以下为收费（部分包含使用期限）

1.又拍云

• 注册认证后有10G永久免费空间，每月15G的HTTP和HTTPS流量，提供两款可以免费续期的SSL证书，不过用户需要加入又拍云联盟（即在网站底部添加又拍云logo及官网链接）

• 图片上传限制：无

• 上传地址

2.腾讯云

• 可以使用六个月的免费存储容量、免费请求和免费流量

• 限制：时间、流量、空间大小均有限制

• 上传地址

3.阿里云OSS

• 海量、安全、低成本、高可靠的云存储服务，提供99.999999999%的数据可靠性。使用RESTful API 可以在互联网任何位置存储和访问，容量和处理能力弹性扩展，多种存储类型供选择全面优化存储成本。

• 不一定存储图片，文件都是ok的，不过扣量很严重，以为这个网站之前就是用的oss。

• 官网

原来页面encodeURIComponent编码URL传参数，在接收页面不需要手动给option decodeURIComponent解码 。

关于iOS应用提交App Store提示SDK版本不兼容的解决方案（ITMS-90725错误）

问题现象：
使用HBuilder开发的UniApp项目通过提交后，提示：
"This app was built with the iOS 17.5 SDK. All iOS and iPadOS apps must be built with the iOS 18 SDK or later..."

或者使用蛋壳Uploader 上传报错, 验证失败:

Validation failed (409) SDK version issue. This app was built with the iOS 17.5 SDK. All iOS and iPadOS apps must be built with the iOS 18 SDK or later, included in Xcode 16 or later, in order to be uploaded to App Store Connect or submitted for distribution

根本原因：
2024年6月苹果强制要求所有新提交应用必须使用Xcode 16（含iOS 18 SDK）构建。当前开发环境使用的SDK版本已不符合最新要求。

解决方案：
请按以下步骤升级开发环境：

1. 升级基础开发工具

   • 安装最新Xcode 16（通过App Store或开发者官网下载）
   • 确保MacOS系统版本符合Xcode 16要求（建议Ventura 13.5或更高）

2. 更新HBuilder开发环境

   • 打开HBuilderX
   • 导航至【帮助】→【检查更新】安装最新正式版（推荐3.9.10+）
   • 重启IDE使更新生效

3. 更新UniApp依赖链
   在项目根目录执行：

   npx @dcloudio/uvm@latest

   该命令将自动更新以下关键组件：

   • uni-app编译器至最新稳定版
   • iOS平台特定依赖
   • 原生插件兼容层

4. 重建生产包

   • 清理项目缓存：菜单【运行】→【清理项目缓存】
   • 重新生成iOS证书文件（建议更新为2024年签发的证书）
   • 使用【发行】→【原生App-云打包】生成新二进制文件

验证要点：
完成上述步骤后，通过HBuilder控制台检查构建日志，确认包含以下信息：

Using iOS SDK version: 18.0+
Xcode version: 16.0+

补充说明：
若使用自定义原生插件，需同步更新插件代码至适配iOS 18的版本。建议在真机调试阶段使用Xcode 16连接设备进行兼容性验证，避免因API变更导致的运行时异常。

更多讨论:

https://ask.dcloud.net.cn/article/41555

最近使用了uni-automator对小程序项目进行自动化测试
由于官方文档比较简单，并没有罗列一些常见问题，再加上本身用的人就少，可以说踩尽了坑。

问题一：

问题二：

所有的测试用例只有第一条能执行成功，后续用例结果都会变成 [object HTMLElement]

并且开发者工具中会抛出大片错误，并且点击页面元素没有交互响应。

Converting circular structure to JSON  
--> starting at object with constructor 'l'  
| property 'parentNode' -> object with constructor 'd'  
| property 'childNodes' -> object with constructor 'Array'  
--- index 0 closes the circle(env: macOS,mp,1.06.2412050; lib: 3.7.10)>

也是一个百思不得其解的问题，又耽误了我两天，最后发现是开发者工具的版本问题，当时用的是1.06.2503281，后来卸载安装了1.06.2409140是可以的。

后续遇到其他问题再更新....