原文地址

FOOM（Foreground Out Of Memory），是指App在前台因消耗内存过多引起系统强杀。对用户而言，表现跟crash一样。Facebook早在2015年8月提出FOOM检测办法，大致原理是排除各种情况后，剩余的情况是FOOM，具体链接。

微信自15年年底上线FOOM上报，从最初数据来看，每天FOOM次数与登录用户数比例接近3%，同期crash率1%不到。而16年年初某东老大反馈微信频繁闪退，在艰难拉取2G多日志后，才发现kv上报频繁打log引起FOOM。接着16年8月不少外部用户反馈微信启动不久后闪退，分析大量日志还是不能找到FOOM原因。微信急需一个有效的内存监控工具来发现问题。

原文地址

Matrix-iOS 卡顿监控

前言

–

在早期开发 iOS 微信的过程中，我们时不时会收到类似的反馈：

• “我的微信卡在主界面，怎么也滑动不了”
• “我的微信从后台切换前台卡了一下，最近偶尔会遇到几次”，等等。

这类问题有个共同点：用户的微信在一段时间内无法点击；即使获得用户的操作路径，也无法重现。 我们把这类问题叫做卡顿问题。这类问题很影响用户的体验，是必须进行解决的。为了精确地定位用户的卡顿问题，iOS 微信在 2014 年 9 月份上线了卡顿监控系统。在这几年间，卡顿监控经历了几次优化，不断成熟，在这里我们将其分享出来。

Swift和OC有什么区别？

Swift和Objective-C是两种不同的编程语言，用于开发应用程序和软件。它们有以下几个主要区别：

在程序开发中, 我们经常会遇到 浅拷贝 深拷贝 的问题, 针对堆中的数据, 我们会有栈上的指针指向对象所在的地址, 当我们需要对堆上的对象进行拷贝时, 有两个选择

• 浅拷贝: 只复制指向某个对象的指针, 而不复制对象本身, 新旧对象还是共享同一块内存
• 深拷贝: 会另外创造一个一模一样的对象, 新对象跟原对象不共享内存, 修改新对象不会改到原对象

但是在 iOS 开发中, 也会经常遇到深浅拷贝问题, 比如我有一个对象, 想复制一份, 如果直接使用指针, 其实是浅拷贝, 只是指向同一个内存位置, 同时该对象的引用计数会 +1

SQLite3中可以使用 BEGIN TRANSACTION 和 COMMIT TRANSACTION 来开始和结束一个事务, 使用 ROLLBACK 来回滚未被提交(COMMIT)的事务. 如果没有添加这些事务语句, SQLite3会为每条SQL语句加上一个事务. 要想优化SQLite3的性能, 那么必须要了解SQLite3中一次事务执行过程.

今天遇到了一个 UILabel 的 textColor 自动跟肤的问题, 复现路径是

1. 打开出问题页面, 文字显示黑色, 显示正常
2. 从手机屏幕右上角下滑, 在屏幕亮度中打开”深色模式”, 回到 app
3. 原本显示黑色的 UILabel 就变成了白色

由于业务比较复杂, 我直接用符号断点去看哪个业务做的这个颜色的修改, 诡异的是在 Xcode 打符号断点 -[UILabel setTextColor:] 居然捕获不到这次变色, 说明并不是业务层代码主动去改的颜色.

原文地址

正文

对于移动开发者来说，最大的尴尬莫过于用户反馈程序出现问题，但因为不能重现且没有日志无法定位具体原因。这样看来客户端日志颇有点”养兵千日，用兵一时”的感觉，只有当出现问题且不容易重现时才能体现它的重要作用。为了保证关键时刻有日志可用，就需要保证程序整个生命周期内都要打日志，所以日志方案的选择至关重要。

预编译与预处理的区别是什么

原文地址

可变参数宏 __VA_ARGS__ 简介

ARC & MRC

“引用计数”是 iOS 系统管理堆内存的主要手段, 在早期 iOS 开发中, 引用计数是需要开发者手动管理, 称为 MRC.