Diff应用：从LCS到UICollectionView
什么是Diff？
日常编程中有时候会遇到对比字符串，对比数组的情况，找出前后新旧数据的不同，可以称之为Diff。
什么是LCS？
Longest Common Subsequence 的简称，最长公共子序列。
LCS有哪些应用？
1.Git等版本控制，常用的git diff命令
2.一些对比软件，如Kaleidoscope，能进行图片、文件、文本的对比
3.Facebook iOS Snapshot Test框架，通过snapshot的方式，进行页面UI测试
4.IGListKit一个基于UICollectionView的框架，通过LCS衍生优化算法，进行UICollectionView的刷新
关于本文…
前几部分都是LCS算法的一些简单介绍，感兴趣的可以看看，也可直接看靠后的LCS算法在UICollectionView中的应用。
[转载] 基于NSURLCache的缓存实现
缓存设计应该是每个客户端程序开发所必须考虑的问题，如果同一个功能需要多次访问，而每次访问都重新请求的话势必降低用户体验。但是如何处理客户端缓存貌似并没有统一的解决方案，多数开发者选择自行创建数据库直接将服务器端请求的JSON（或Model）缓存起来，下次请求则查询数据库检查缓存是否存在。事实上iOS系统自身也提供了一套缓存机制，本文将结合URL Loading System简单介绍一下如何利用系统自身缓存设计来实现一套缓存机制来平滑的扩展图虫客户端的缓存处理。
升级到 Xcode 14.3 编译部分工程出现错误
1 | ld: file not found: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/arc/libarclite_iphoneos.a |
查到是 Xcode14 支持最低版本是 iOS 11, 然后部分库基于 arc 的支持在 Xcode14.3 被移除了, 升级到 14.3 后无法链接, 就报错了
[转载] iOS端一次视频全屏需求的实现
对于一个带有视频播放功能的app产品来说，视频全屏是一个基本且重要的需求。虽然这个需求看起来很简单，但是在实现上，我们前后迭代了三套技术方案。这篇文章将介绍这三种实现方案中的利弊和坑点，以及实现过程中积累的经验。
[转载] iOS性能优化实践：头条抖音如何实现OOM崩溃率下降50%+
iOS OOM 崩溃在生产环境中的归因一直是困扰业界已久的疑难问题，字节跳动旗下的头条、抖音等产品也面临同样的问题。
在字节跳动性能与稳定性保障团队的研发实践中，我们自研了一款基于内存快照技术并且可应用于生产环境中的 OOM 归因方案——线上 Memory Graph。基于此方案，3 个月内头条抖音 OOM 崩溃率下降 50%+。
本文主要分享下该解决方案的技术背景，技术原理以及使用方式，旨在为这个疑难问题提供一种新的解决思路。
[转载] 抖音 iOS 启动优化 - 原理篇
前言
启动是 App 给用户的第一印象，启动越慢用户流失的概率就越高，良好的启动速度是用户体验不可缺少的一环。启动优化涉及到的知识点非常多面也很广，一篇文章难以包含全部，所以拆分成两部分：原理和实战。
本文从基础知识出发，先回顾一些核心概念，为后续章节做铺垫；接下来介绍 IPA 构建的基本流程，以及这个流程里可用于启动优化的点；最后大篇幅讲解 dyld3 的启动 pipeline，因为启动优化的重点还在运行时。
[转载] 抖音 iOS 启动优化 - 实战篇
前言
启动是 App 给用户的第一印象，启动越慢，用户流失的概率就越高，良好的启动速度是用户体验不可缺少的一环。启动优化涉及到的知识点非常多，面也很广，一篇文章难以包含全部，所以拆分成两部分：原理和实战，本文是实战篇。
转载 今日头条 iOS 安装包大小优化 - 新阶段、新实践
前言
今日头条 iOS 端从 2016 年起就关注到了安装包大小的问题，并启动了包大小优化。2017 年，我们将当时的经验发表为技术文章 《干货｜今日头条iOS端安装包大小优化—思路与实践》[1]。
如今三年过去了。今日头条在继续探索包大小优化时实践了更多思路，包括构建配置、图片压缩、__TEXT 段迁移、二进制段压缩等。这些优化项在业务入侵较少的前提下给今日头条带来了显著的包大小收益。同时，整个业界在包大小优化上也产出了更多方案。因此我们更新文章，期待与大家共同交流包大小优化这件事。
[转载] iOS 稳定性问题治理：卡死崩溃监控原理及最佳实践
不同于 Android 系统中的卡死（ANR）问题，目前业界对 iOS 系统中 App 发生的卡死崩溃问题并无成熟的解决方案，主要原因是：
通常 App 卡死时间超过 20s 之后会触发操作系统的保护机制，发生崩溃，此时在用户的设备中能找到操作系统生成的卡死崩溃日志，但是因为 iOS 系统封闭生态的关系，App 层面没有权限拿到卡死崩溃的日志。
一般而言用户遇到卡死问题的时候并没有耐心等待那么久的时间，可能在卡住 5s 时就已经失去耐心，直接手动关闭应用或者直接将应用退到后台，因此这两种场景下系统也就不会生成卡死崩溃日志。
由于上面提到的两个原因，目前业界 iOS 生产环境中的卡死监控方案其实主要是基于卡顿监控，即当用户在使用 App 的过程中页面响应时间超过一定的卡顿的阈值（一般是几百 ms）之后判定为一次卡顿，然后抓取到当时现场的调用栈并且上报到后台分析。这种方案的缺陷主要体现在：
[转载] 抖音 iOS 工程架构演进
2016.09.26，抖音版本 1.0.0 上线，随后不断迭代优化和丰富产品，截止目前，抖音日活跃用户突破 6 亿，短短 4 年间，抖音从零爆发性增长。
快速的业务发展也对技术支撑提出了更高的要求，为了保障敏捷的业务开发，提升跨团队的协同合作效率，提高本地研发和 CI/CD 效率，抖音 iOS App 工程架构在不同的阶段进行了不同的技术方案的改进，满足合理的架构演化，同时又不影响正常的业务迭代速度。