记录下云服务器自己的踩坑

宝塔面板

国内的最新版(7.9.8)登录需要绑定宝塔的账号, 降级到不需要绑定的又有各种问题, 担心绑定账号有安全风险, 最后换成了宝塔国外版aaPanel, 除了页面是英文, 其他跟国内一样用

最好用全新的服务器安装, 不然各种问题, 别踩坑了

[转载] 从汇编角度分析objc_msgSend的hook过程

转载: 原文地址

objc_msgSend 是基于汇编实现的，hook objc_msgSend 和我们平时 hook OC 方法不一样，在 github 上有开源的项目通过 hook objc_msgSend 来监控每个函数的耗时情况。这篇文章对其 hook 逻辑的主要代码进行分析记录。阅读前建议先了解开源库 fishhook 的源码。

[转载] Matrix-iOS 耗电监控

转载: 原文地址

前言

在微信开发过程中，有时会收到一些反馈说，手机使用微信一段时间后就开始发烫了。为了跟进用户的发烫问题，最开始的时候，我们只能通过日志看看用户在这段时间做了些什么操作，努力去复现问题。

会导致手机发烫的原因很多，有可能只是用户在阳光下使用手机；但也有可能真的是微信某个模块代码有问题，导致当前 CPU 占用过高。这很让人头疼。如果能像查卡顿问题一样，有堆栈就好了。

在 WWDC 2018 What’s New in Energy Debugging 苹果推介了 Energy Log 这种日志来查耗电问题。系统定期会获取当前应用的线程堆栈，当应用在前台平均三分钟或者后台平均一分钟内 CPU 占用超过 80%，系统会将收集到的线程堆栈组合成一颗函数调用树形成 Energy Log。

在 “Xcode -> Organizer -> Energy Log” 中可以看到应用上报上来的 Energy Log 数据。这些数据确实暴露了微信的一些代码问题，拿到几份 Energy Log 后，我们能快速地定位出一些耗电场景。但是 Energy Log 日志是 iOS 系统收集的，我们无法对日志做定制化，无法扩展；而且在日常开发过程中，获取 Energy Log 的成本很高。

经 Energy Log 的启发，我们在 Matrix 扩展实现了耗电监控功能，现在 Matrix 也能上报应用的 “Energy Log” —— 耗电堆栈。

[转载] Matrix for iOS macOS 异步堆栈回溯

转载: 原文地址

前言

在当前微信耗电监控上报的堆栈当中，我们发现了大量与 GCD 异步调用相关的系统堆栈，如下图所示。而真正与业务相关的堆栈却“不见踪影”，这样的堆栈信息无法帮助我们确定耗电问题出现的具体位置。

[转载] GCDAsyncSocket 在 iOS15 出现 -[_NSThreadPerformInfo dealloc] 崩溃排查笔记

转载: 原文地址

本文会通过对 NSThread 的原理进行分析，对 iOS 15 开始出现的 [_NSThreadPerformInfo dealloc] 相关崩溃进行定位，并提供相应的解决方案

M1 Mac 外接屏幕 开启 HiDPI 方法

Mac 的屏幕缩放功能是非常厉害的(HiDPI), 但是苹果一直不支持第三方模拟器使用这个功能.
以前有个 one-key-hidpi 可以为开启第三方屏幕开启 HiDPI. 但是 M1 芯片的 Mac 就不再支持了.

新的方法可以使用 BetterDummy 这个软件来免费开启, 缺点是每次电脑重启后需要自己手动打开软件.

iOS 16 计算文本尺寸崩溃

线上出现一个奇怪的崩溃, 堆栈信息比较少, 每天十几次, 发现是 iOS16 的新坑.

正则表达式：使用、原理和优化

转载: 原文地址

什么是正则表达式

正则表达式描述了一种字符串匹配模式，包括普通字符（如a-z之间的字母）和特殊字符（比如.、^、$等有特殊意义的专用字符）。

典型的搜索和替换操作要求我们提供与预期的搜索结果匹配的确切文本。虽然这种技术对于对静态文本执行简单搜索和替换任务可能已经足够了，但它缺乏灵活性，若采用这种方法搜索动态文本，即使不是不可能，至少也会变得很困难。
比如，需要验证用户输入的电话号码符合###-###-#### 格式（#表示一个数字）时，如果不使用正则表达式，则需要遍历用户输入的每个字符，确保#位置输入的是数字，非#位置输入的是-。而使用正则表达式的话，一行语句就可以完成验证功能。

MetricKit2.0 总结

MetricKit2.0 的新功能

MetricKit 会将过去 24 小时内收集的性能数据合并，在下一次 App 启动时，通过 delegate 方法回调给我们。
MetricKit1.0 知识请参考 iOS13+ 性能和耗电量信息收集框架
以下均为 MetricKit2.0(iOS14) 新增功能.

原文地址 : 探秘越来越复杂的 ImageIO 框架

探秘越来越复杂的 ImageIO 框架

前言

ImageIO 是 Apple 提供的上层框架，用于处理常见图像格式的编解码支持。这篇文章主要讲述了三个子话题：WebP/AVIF 的支持进展，IOSurafce 和硬件解码优化 50%内存开销，以及 CGImageSource 机制变化导致的线程安全问题

ImageIO 的定位是上层的支持框架，其封装了诸多的苹果的底层解码器，开源编解码器，硬件 HEVC/ProRes 加速器等等底层细节，致力于提供和上层 UI 框架（如 UIKit/CoreGraphics）的可交互性。