Cocos小游戏开发学习笔记

Cocos 是全球领先的游戏引擎,拥有强大的跨平台开发能力,同时具备易上手、轻量化、开源、免费、高能等优势。Cocos 小游戏系列文章将记录1个月内了解并掌握 Cocos 专项技能，最终达到开发 Cocos 相关游戏项目的能力。

转载: 原文地址

[转载] 头条稳定性治理：ARC 环境中对 Objective-C 对象赋值的 Crash 隐患

ARC 环境下在多线程中执行赋值代码可能会产生野指针，导致 EXC_BAD_ACCESS 崩溃。
这种崩溃发生的概率很低，在开发和灰度阶段即使执行到相应代码也很难崩溃，因此容易遗漏到正式环境。在上亿级用户的 App 往往会成为 Top 问题，对指标造成影响，并且很难排查。
今日头条在治理 Crash 的过程中彻底解决了数十个此类崩溃，发现其具有一定共性。本文详细分析崩溃发生的过程，以及总结了容易出现问题的场景，希望在大家遇到此类问题时能提供一些思路。

转载: 原文地址

[转载] 抖音 Swift 编译优化 - 基于自定义 Toolchain 编译提速 60%

本文重点探讨全部模块化后带来的依赖解析瓶颈，主要包括对头文件增量编译分析等内容。
优化方案基于 Swift Toolchain 源码，本文不再探讨 Toolchain 相关基本概念及配置流程等，仅聚焦方案本身。

背景

随着混编落地的业务场景越来越多，越来越大，开发中出现的性能痛点开始显现，问题很明显集中在被 Swift 环境所依赖的 OC 仓的头文件改动上。因此基建架构把重点放在接口层依赖的性能分析上，力求解决性能瓶颈。
抖音基础技术团队借助自定义 Toolchain 能力，通过自定义编译参数，裁剪 Clang Header 指定内容，最终实现编译提速 60% 。
本方案已于 2022 年 11 月底上线，在抖音稳定运行近 5 个月。下面就让我们一起回顾下整个方案从提出到落地的全过程。

转载: 原文地址

Block 内调用 super 引发的循环引用

TLDR

1. 介绍了两种较为少见的 Block 循环引用，并提供了解决方法。
2. 宏的替换在 Preprocessed 阶段，super 的变更在 compile 阶段，因此对 self 进行 weak/strong dance 并解决不了 super 导致的循环引用问题。
3. 同时通过 RewriteObjc 与 Disassembly 的方法从底层原理上分析了 super 与 Block 调用的本质，辅以内存实际情况与示意图方便加深理解。穿插了 objc_msgSend Stub 相关的知识。
4. 验证了在 Block 中调用 super 时，RewriteObjc 生成代码的一个 bug 。

转载: 原文地址

背景

图片库加载服务是为bilibili打造的移动端一站式解决方案，集图像加载、显示、处理、监控于一体，以高可用、高性能、可高度定制、数据服务、省流量五大核心优势被公司各个业务接入使用，经过长期的迭代与维护，已成熟稳定。

在如今越来越看重体验的大环境下，对图片库的要求也日益攀升。从成本的角度来看，使用AVIF格式可以节省大量的网络带宽和存储空间，减少网站加载时间，并且可以改善用户体验，进而提高网站的效率和收益，从而节约大量的费用。

AVIF格式能够带来许多优势，首先，AVIF格式具有明显的压缩率优势，可以比其他常用图片格式(如JPEG、PNG)节省更多的存储空间，减少图片加载所需时间和带宽，提高网站加载速度，提高访问者的体验；其次，AVIF格式丰富的特性支持，可以支持更多的设备和浏览器，提高图片的可用性，并可以免专利费的优势；最后，AVIF格式支持图片的质量优化，可以保证图片的质量，同时节省更多的容量。

腾讯云 COS 上传

端内文件上传, 之前各个业务都是自己写的上传, 有的是用 PUT 请求, 有的是放在业务POST请求的 body 中, 对于批量图片上传由于担心上传长时间抢占带宽设置了30 秒强制超时, 对于大文件比如视频上传则是业务自己实现了分片上传, 上传逻辑复杂, 业务自己实现细节繁多, 成功率也不高. 后来切换到了腾讯云的 COS 上传, 图片上传成功率由97.5% 上升至 99.13%, 视频上传成功率由 92.88% 上升到 96.92%. 同时将 COS上传 封装为通用的上传逻辑, 输入支持磁盘文件/内存对象的上传, 输出支持进度以及结果回调, 并额外支持了秒传/续传/分片上传/批量上传/取消上传/秘钥续期/容灾/结果统计等能力.

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

宝塔面板

国内的最新版(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 异步调用相关的系统堆栈，如下图所示。而真正与业务相关的堆栈却“不见踪影”，这样的堆栈信息无法帮助我们确定耗电问题出现的具体位置。