App在迭代过程中，随着新需求的不断丰富，包体积逐渐增大。早期功能较简单，优化空间有限，用户感知不明显，包大小问题未受重视。随着功能多元化，包大小水涨船高，大到一定值后，会产生一些消极影响。

iOS 设计模式 - App中的SOLID原则；单一职责原则、开闭原则 、里氏替换原则、接口隔离原则、依赖倒置原则

上一篇文章介绍了卡顿产生的本质原因以及监控卡顿的方案，本篇将主要介绍一下常见的导致卡顿的场景，以及对 CPU 和 GPU 的资源消耗的场景。 CPU 资源的消耗 CPU 一般负责视图创建、销毁，布局计

背景 在游戏发行行业，iOS 不像安卓会有很多的渠道，为什么 iOS 需要做一个切包系统呢？在以往 iOS 端游戏出包过程中，经常会遇到一些问题： SDK 版本更新，需依赖研发打包，研发侧经常因排期过

我正在参加「掘金·启航计划」 前言 客户端现状   工作中，经常遇到产品想尽快上线看数，CR业务也总是倒排期状态，native 的发版窗口是他们经常要关注的，往往因为窗口时间问题，导致某个需求业务迭代

iOS 自动打包主要用 xcodebuild 命令, 在终端输入 xcodebuild --help 可以查看 xcodebuild 的参数。

随着业务的扩展、项目体积的增大，CocoaPods组件库越来越多，每次重新编译的时候速度越来越慢，这给我们提出了需要提高编译速度的需求。 前两个就不在这里讨论了可以看看这篇讲解。今天重点给大家分享一下第三和第四种方案的实施，但是目前只能针对私有库实施，对于一些第三方的公有库目前…

可以带着以下问题来阅读本文 基础问题 什么是 Block？请举例说明 Block 的使用场景。 Block 如何捕获外部变量？请解释 Block 捕获变量的规则。 请解释 Block 的内存管理，特别

为什么要优化包大小？ 首先是 Apple Store 数据下载的限制； 另外无非就是包大了，用户不愿意下载了，空间不足的时候要删除 App 第一个想到的就是删除大的 App。 怎么优化？ 1. 删除无