原文地址: App 二进制文件重排已经被玩坏了

『二进制文件重排优化启动速度』本是一项上古 PC 时代就玩过的东东，前一阵子借助某宇宙大厂重新火了一把。不过令我惊讶的是：这么简单个事情竟然搞得如此复杂，而且还声称『开拓性的探索、在没有业界经验可供参考』。。。

说真话可能会得罪人，但是我怕过吗？ 我怂了，这段掐了。

其实二进制文件重排很简单啊，重点在于生成 order 文件。我基于 Clang SanitizerCoverage 和业界已有的经验，整了个 AppOrderFiles，一个调用搞定！Enjoy it！

hook 在 iOS 开发中又叫 Swizzle Method, 简单说就是交换两个函数/方法的地址, 一般是交换某个系统方法和自己实现的方法, 用于实现对系统行为的监控或者边界保护.
iOS 开发中有多种 hook 的方法, 本文主要聚焦于 fishhook 的实现与应用

今天收到一个反馈, 说有个按钮突然不显示, 排除了网络配置等因素的影响后, 查看文件修改记录, 发现最近一年都没有动过相关代码, 一时有点尬住了. 按钮的明明有 getter 方法, 但是加到 UI 上的时候就变成 nil 了, 排查代码也没有逻辑对按钮的 property 置空. 所以直接看 property 定义如下:

1

@property (nonatomic, weak) UIButton *emptyButton;

居然是个 weak 属性.

PNG 的二进制文件由文件头(文件署名域, 决定文件类型)加上多个块组成, 其中每个块又有四个部分, 如下:

原文地址

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中一次事务执行过程.