[转载] 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）的可交互性。

Xcode14 下载 watchOS Simulator 失败

Xcode14 为了缩减体积, 将部分组件并未内置在安装包中. 当工程添加了 Watch App 支持, 开始编译时 Xcode 会自动下载 Apple Watch 的模拟器, 否则无法继续编译. 但是使用 Xcode内置的下载又经常下载失败, 报错是网络超时.

原文地址 : 快速链接：优化构建和启动耗时

[转载] 快速链接：优化构建和启动耗时

前言

什么是链接呢？我们在编写代码的同时也会使用到别人提供的库或者框架，为了让我们的代码能使用这些库，此时我们就需要一个链接器。实际上，链接有两种类型，一种是「静态链接」，它发生在编译构建 App 的时候，这一步骤会影响到构建的耗时以及 App 最终的二进制体积；另外一种是「动态链接」，它发生在 App 启动的时候，这一步骤会影响 App 的启动耗时。

在后面的内容我们将会围绕「静态链接」和「动态链接」两个概念进行讨论，最后还会介绍两个用于定位链接性能的工具：