性能监控：衡量 App 质量的那把尺

性能监控：衡量 App 质量的那把尺 通常情况下，App 的性能问题虽然不会导致 App不可用，但依然会影响到用户体验。如果这个性能问题不断累积，达到临界点以后，问题就会爆发出来。这时，影响到的就不仅仅是用户了，还有负责App开发的你。为了能够主动、高效地发现性能问题，避免App质量进入无人监管的失控状态，我们就需要对App的性能进行监控。目前，对App的性能监控，主要是从线下和线上两个维度展开。

日志监控：怎样获取 App 中的全量日志

日志监控：怎样获取 App 中的全量日志 我在前面的几篇分享了崩溃、卡顿、内存问题的监控。一旦监控到问题，我们还需要记录下问题的详细信息，形成日志告知开发者，这样开发者才能够从这些日志中定位问题。但是，很多问题的定位仅靠问题发生的那一刹那记录的信息是不够的，我们还需要依赖更多的日志信息。在以前公司还没有全量日志的时候，我发现线上有一个上报到服务器的由数据解析出错而引起崩溃的问题。由于数据解析是在生

临近 OOM，如何获取详细内存分配信息，分析内存问题

临近 OOM，如何获取详细内存分配信息，分析内存问题 今天我们来聊聊，临近OOM，如何获取详细的内存分配信息，分析内存问题的话题。OOM，是Out of Memory的缩写，指的是App占用的内存达到了iOS系统对单个App占用内存上限后，而被系统强杀掉的现象。这么说的话，OOM其实也属于我们在第12篇文章“iOS 崩溃千奇百怪，如何全面监控？”中提到的应用“崩溃”中的一种，是由iOS的Jetsa

如何利用 RunLoop 原理去监控卡顿

如何利用 RunLoop 原理去监控卡顿 卡顿问题，就是在主线程上无法响应用户交互的问题。如果一个 App 时不时地就给你卡一下，有时还长时间无响应，这时你还愿意继续用它吗？所以说，卡顿问题对App的伤害是巨大的，也是我们必须要重点解决的一个问题。现在，我们先来看一下导致卡顿问题的几种原因：复杂 UI 、图文混排的绘制量过大；在主线程上做网络同步请求；在主线程做大量的IO 操作；运算量过大，CPU

Clang的App 提质

Clang的App 提质 以前在工作中，有段时间连续发生了多次线上事故，在复盘时大家都提出是因为代码不规范、代码规范执行不到位，从而导致代码质量过差，无法监管，我们才被动处理线上事故。会上牢骚发完，会后应该怎么执行呢？我们都知道，监管手段是需要自己动手建设的，第三方工具无法满足所有的业务技术规范监控。在上篇文章“Clang、Infer 和 OCLint ，我们应该使用谁来做静态分析？”中，我们提到

iOS 崩溃千奇百怪如何全面监控

iOS 崩溃千奇百怪如何全面监控 App上线后，我们最怕出现的情况就是应用崩溃了。但是，我们线下测试好好的App，为什么上线后就发生崩溃了呢？这些崩溃日志信息是怎么采集的？能够采集的全吗？采集后又要怎么分析、解决呢？接下来，通过今天这篇文章，你就可以了解到造成崩溃的情况有哪些，以及这些崩溃的日志都是如何捕获收集到的。App 上线后，是很脆弱的，导致其崩溃的问题，不仅包括编写代码时的各种小马虎，还包

包大小：如何从资源和代码层面实现全方位瘦身

包大小：如何从资源和代码层面实现全方位瘦身 今天我来跟你说下如何对 App 包大小做优化。对App包大小做优化的目的，就是节省用户流量，提高用户下载速度。当初，我在主持客户端的瘦身时，就是奔着对包大小进行最大化优化的目标，3个月内将包大小从106MB降到了最低64MB，半年内稳定在了70MB。当时业务还没有停，从106MB降到64MB的这3个月里如履薄冰，不同团队各显神威，几乎用到了所有手段，也

无侵入的埋点方案如何实现

无侵入的埋点方案如何实现 在iOS开发中，埋点可以解决两大类问题：一是了解用户使用App的行为，二是降低分析线上问题的难度。目前，iOS开发中常见的埋点方式，主要包括代码埋点、可视化埋点和无埋点这三种。代码埋点主要就是通过手写代码的方式来埋点，能很精确的在需要埋点的代码处加上埋点的代码，可以很方便地记录当前环境的变量值，方便调试，并跟踪埋点内容，但存在开发工作量大，并且埋点代码到处都是，后期难以维

静态分析工具的选择

静态分析工具的选择 随着业务开发迭代速度越来越快，完全依赖人工保证工程质量也变得越来越不牢靠。所以，静态分析，这种可以帮助我们在编写代码的阶段就能及时发现代码错误，从而在根儿上保证工程质量的技术，就成为了iOS开发者最常用到的一种代码调试技术。Xcode 自带的静态分析工具 Analyze，通过静态语法分析能够找出在代码层面就能发现的内存泄露问题，还可以通过上下文分析出是否存在变量无用等问题。但是