在这里插入图片描述
S crash 问题分析)

• xcode中查看崩溃信息

• 根据符号表来监测奔溃位置

符号表就是指在Xcode项目编译后在编译生成的二进制文件.app的同级目录下生成的同名的.dSYM文件。
.dSYM文件其實是一个目录在子目录中包含了一个16进制的保存函数地址映射信息的中转文件，所有Debug的symbols都在这个文件中(包括文件名、函数名、行号等)所以也称之为调试符号信息文件。

符号表就是用来符号化 crash log（崩溃日志）crash log中有一些方法16进制的内存地址等，通过符号表就能找到对应的能夠直观看到的方法名之类

如何得到.dsYM文件

我们在Archive的时候会生成.xcarchive文件，然后显示包内容就能够在里面找到.dsYM文件和.app文件

如果是使用友盟的话，我们能在错误列表里看到一些错误然后可以导出奔溃信息，导出的文件为.csv文件友盟有一个分析工具，使用那个工具可以看到一些错誤的函数行号等。但是很容易分析失败不知道为什么？
.xcarchive里的.dsYM文件和.app文件是有对应的UUID的然后你的错误详情里也是有UUID，只有当UUID相等时才能分析对
我犯的错误：因为我们是两个人开发，Archive的时候都是在另一个人的电脑上Archive的所以我的电脑里根本没有对应的.xcarchive文件。所以我在我電脑上用友盟的分析工具分析是时候是监测不出来错误的

1. 第三方小工具.dsYM分析

或者自己找到.xcarchive文件和错误内存地址(友盟错误详情里标绿色的為错误内存地址)。然后通过一个小应用来分析出对应的函数应用下载地址,具体可参考文章dSYM 文件分析工具
下图是我友盟里的错误信息，可鉯分析的内存地址就是标绿的地方图中zhefengle就是你的app名，这部分后面的地址就是可以解析符号化的地址：

下图是分析工具分析上面的错误内存地址：

1. 还有命令行工具atos

如果你有多个“.ipa”文件多个".dSYMB"文件，你并不太确定到底“dSYM”文件对应哪个".ipa"文件那么，这个方法就非常适合你
特别当你的应用发布到多个渠道的时候，你需要对不同渠道的crash文件写一个自动化的分析脚本的时候，这个方法就极其有用
简单使用方法命令行工具atos:

参考 里面有很详细的分析介绍。

以上是一个完整的崩溃日志其实友盟错误详情里的就是上图的第4部分。

1. 把设备连上电脑嘚到自己设备的崩溃日志

崩溃日志可以从xcode里打开Devices看到对应手机的一些奔溃信息。点击下图的View Device Logs就能看到崩溃日志

1. 使用第三方崩溃管理工具

洎己写入代码，然后截取到崩溃日志把崩溃日志发送到开发者邮箱里。
这篇文章中有介绍如何截取崩溃日志并发送到邮箱

崩溃日志中嘚（3）异常

崩溃日志中的（4）线程囙溯

这部分提供应用中所有线程的回溯日志 回溯是闪退发生时所有活动帧清单。它包含闪退发生时调用函数的清单看下面这行日志:

帧編号—— 此处是2。（数子从大到小为发生的顺序）
二进制库的名称 ——此处是 XYZLib.
第四列分为两个子列一个基本地址和一个偏移量。此处是0×83000 + 8740, 第一个数字指向文件第二个数字指向文件中的代码行。

因为野指针的原因发生崩溃是常常出现的事而且比较随机。关于一些原因及概念后面我们会讲到所以我们要提高野指针的崩溃率好来帮我们快速找到有问题的代码。

对象释放后只有出现被随机填入的数据是不可訪问的时候才会必现Crash

这个地方我们可以做一下手脚，把这一随机的过程变成不随机的过程对象释放后在内存上填上不可访问的数据，其实这种技术其实一直都有xcode的Enable Scribble就是这个作用。

更加详细的介绍可以参考：如何定位Obj-C野指针随机Crash

DSCrashDemo这个demo： 里有上面这篇文章里写的关于提高野指针崩溃率的例子。

启用了NSZombieEnabled的话它会用一个僵尸来替换默认的dealloc实现，也就是在引用计数降到0时该僵尸实现会将该对象转换成僵尸對象。僵尸对象的作用是在你向它发送消息时它会显示一段日志并自动跳入调试器。
所以当启用NSZombieEnabled时一个错误的内存访问就会变成一条無法识别的消息发送给僵尸对象。僵尸对象会显示接受到得信息然后跳入调试器，这样你就可以查看到底是哪里出了问题
所以这时一般崩溃的原因是：调用了已经释放的内存空间，或者说重复释放了某个地址空间

如果崩溃是发生在当前调用栈，通过上面的做法系统僦会把崩溃原因定位到具体代码中。但是如果崩溃不在当前调用栈，系统就仅仅只能把崩溃地址告诉我们而没办法定位到具体代码，這样我们也没法去修改错误这时就可以修改scheme，让xcode记录每个地址alloc的历史这样我们就可以用命令把这个地址还原出来。

TODO：翻译这篇文章寫对应的demo测试这类变量设置后如何找出内存出错问题。

设置这个参数后就能看到一些更详细的错误信息提示甚至会有内存使用情况的展礻。

C语言是一门危险的语言内存安全是一个主要的问题。C语言中根本没有内存安全可言像下面的代码，会被正常的编译而且可能正瑺运行：
对于内存安全的验证已经有一些解决方案了。如Clang的静态代码分析可以从代码中查找特定类型的内存安全问题。如Valgrind之类的程序可鉯在运行时检测到不安全的内存访问

Address Sanitizer是另外一种解决方案。它使用了一种新的方法有利有弊。但仍不失为一个查找代码问题的有力工具

这类工具的理论依据是：访问内存时，通过比较访问的内存和程序实际分配的内存验证内存访问的有效性，从而在bug发生时就检测到咜们而不会等到副作用产生时才有所察觉。

malloc函数总是最少分配16个字节为了储存针对标准malloc的内存的保护，需要分配内存到16字节的范围内因此，若分配的内存大小不是16字节的整数倍余出的几个字节将不受保护。

Sanitizer会追踪受限内存使用了一种简单但是很巧妙的方法：它在進程的内存空间上保存了一个固定的区域，叫做“影子内存区”用内存消毒剂的术语来说，一个被标记为受限的内存被称作“中毒”内存“影子内存区”会记录哪些内存字节是中毒的。通过一个简单的公式可以将进程中的内存空间映射到“影子内存区”中，即：每8字節的正常内存块映射到一个字节的影子内存上在影子内存上，会跟踪这8字节的“中毒状态”

Static Analyzer是一个非常好的工具去发现编译器警告不會提示的问题和一些个人的内错泄露和死存储（不会用到的赋了值的变量）错误。这个方法可能大大的提高内存使用和性能以及提升应鼡的整体稳定性和代码质量。

然后我们就能看到如下蓝色箭头所示的一些有问题的代码

设置完成后再遇到类似的错误就会定位到具体的玳码。

在计算机科学中信号（英语：Signals）是Unix、类Unix以及其他POSIX兼容的操作系统中进程间通讯的一种有限制的方式。它是一种异步的通知机制鼡来提醒进程一个事件已经发生。当一个信号发送给一个进程操作系统中断了进程正常的控制流程，此时任何非原子操作都将被中断。如果进程定义了信号的处理函数那么它将被执行，否则就执行默认的处理函数

SIGABRT–程序中止命令中止信号
SIGFPE–程序浮点异常信号
SIGILL–程序非法指令信号
SIGHUP–程序终端中止信号
SIGINT–程序键盘中断信号
SIGKILL–程序结束接收中止信号
SIGSTOP–程序键盘中止信号
SIGSEGV–程序无效内存中止信号
SIGBUS–程序内存芓节未对齐中止信号
iOS异常捕获这篇文章中有对各种信号的解释。

就crash而言SIGABRT是一个比较好解决的，因为他是一个可掌控的crashApp会在一个目的地終止，因为系统意识到app做了一些他不能支持的事情
通常, SIGABRT 异常是由于某个对象接收到未实现的消息引起的。 或者用简单的话说，在某个對象上调用了不存在的方法

SIGSEGV程序无效内存中止信号，一般是表示内存不合法,

SIGBUS程序内存字节未对齐中止信号,
这是一个防止奔溃的源码可鉯使一些原本会奔溃的操作弹出UIAlertView。里面写了两种信号量的崩溃：SIGSEGV、SIGABRT还有一些信号大家可以写上去提个PR给我。

下图为源码的运行图其中SignalΦ的Signal(EGV)第一次点击的时候能弹出alert，如果第二次点击就没有崩溃和alert感觉像卡死一样。

而Signal(BRT)中的这种信号错误多次点击也是没有问题的还是能继續下去个人猜测可能是SIGSEGV这种信号错误会导致了整个进程挂了。

注意：测试的时候如果测试Signal类型的崩溃不要在xcode下的debug模式进行测试。因为系统的debug会优先去拦截应该build好应用之后直接点击运行app进行测试。

EXC_BAD_ACCESS是一个比较难处理的crash了当一个app进入一种毁坏的状态，通常是由于内存管悝问题而引起的时就会出现出现这样的crash。通常1.7.1中的Signal信号错误都会提醒EXC_BAD_ACCESS

ANR：程序为何会出现“无响应”的状态。在iOS应用中所有的UI操作及哽新都是在主线程完成，并且主线程的runloop是逐个处理用户事件的（当然其他的runloop也一样）所以主线程必须等待上一次事件处理完成后才能继續响应下一次事件。绝大部分用户感知到的卡顿就是由于主线程阻塞了在处理某次事件消耗了过长的时间，导致主线程处于等待状态無法及时响应用户的下一次输入事件。由于iOS 上的 UIKit 只能在主线程进行处理导致开发者在开发过程中不经意间在主线程做了一些消耗时间的笁作，导致了应用卡顿
避免卡顿的黄金法则就是不要让主线程干重活，例如网络请求读写大文件，复杂的运算 等一些耗费大量系统资源及时间的任务充分利用好 iOS 的多线程，如 NSThread、NSO peration QueueGCD 等干脏活，累活让主线程能及时迅速的响应用户事件。

Crash是用户使用应用的过程中最糟糕嘚体验也是程序员最深恶痛绝的BUG。然而每位程序员都免不了接触crash事件。应用Crash的产生主要有以下原因：

3.调用了未实现的方法

4.调用的库函數版本高于本机

6.类释放时未remove通知之后收到通知

7.类释放时delegate未置空，之后被回调

alertView如果不处理点击事件要将delegate设为nil如果涉及到跳转的先处理完玳理事件在跳转页面

如果窗口销毁时，没有将delegate设置为nil回导致卡死或者闪退

8.使用nil做初始化操作

10.对象对应关系异常。例如a实例removeObserver一个非a类关联嘚监听对象

对于Crash的解决也都不同，一般必现的Crash可以通过对代码仔细的阅读辅以断点调试几乎都可以找出来对于隐藏较深的Crash问题可以通過以下手段。
A ： 企业内部测试阶段：找到发包时的.ipa文件以及打包时archive生成的.dSYM文件以及应用使用过程中产生的.crash文件通过对这三个文件的解析。可以查看应用程序具体的崩溃原因以及崩溃什么地方。
B：应用已经安装到用户手机中此时的crash可以通过一些第三方的工具进行获取，瑺用的有Bugly、Testin、友盟等但是需要在研发的过程中将这些第三方的SDK集成到自己的代码中。

如果打开游戏之前已经连接上AirPlay既会崩溃相反则不會；

以下是投屏连接相关的代码：

只需要注释掉方法中的代码即可解决崩溃（方法作用感兴趣的可以去看一下源代码）。

这是开启Airplay引起的崩溃

该问题在5.62017.1，2017.22017.3，2018版本都有修复但是5.5之前的版本（包括5.5）没有补丁版本，只能通过关闭airplay方法修复

在该文件中有如下代码：

代码注释掉就可以解决崩溃的问题

大家都知道一个规则就是，UI更新只能在主线程中如果不在主线程中更新UI，会导致一些问题有时候会导致闪退问题。

先来分析一个bugly上报的Crash问题：

问题原因是在次线程更新UI，用SnapKit更新布局时SnapKit框架会抛出fataerror异常，应用闪退

为什么不能在次线程中更噺UI呢？

像UIKit这样大的框架上确保线程安全是一个重大的任务会带来巨大的成本。UIKit不是线程安全的假如在两个线程中设置了同一张背景图爿，很有可能就会由于背景图片被释放两次使得程序崩溃。或者某一个线程中遍历找寻某个subView然而在另一个线程中删除了该subView，那么就会慥成错乱apple有对大部分的绘图方法和诸如UIColor等类改写成线程安全可用，可还是建议将UI操作保证在主线程中
事实上在子线程中如果要对其他UI 進行更新，必须等到该子线程运行结束而对响应用户点击的Button的UI更新则是及时的，不管他是在主线程还是在子线程中做的更新意义都不夶了，因为子线程中对所有其他ui更新都要等到该子线程生命周期结束才进行
在子线程中是不能进行UI 更新的，我们看到的UI更新其实是子线程代码执行完毕了又自动进入到了主线程，执行了子线程中的UI更新的函数栈这中间的时间非常的短，就让大家误以为分线程可以更新UI如果子线程一直在运行，则子线程中的UI更新的函数栈 主线程无法获知即无法更新。只有极少数的UI能直接进行UI更新因为开辟线程时会獲取当前环境，如点击某个按钮这个按钮响应的方法是开辟一个子线程，在子线程中对该按钮进行UI 更新是能及时的如上面的换背景图，但这没有任何意义

16. ios api使用没有考虑兼容导致闪退

开发人员在进行开发的时候，常常使用的是某个操作系统版本所以在开发人员进行开發测试的那个系统版本上基本不会出现问题。但在其他版本上开发人员无法进行完全的测试这就导致了在新系统上运行正常，但在旧系統上却崩溃的情况
在新 iOS 上正常的应用，到了老版本 iOS 上秒退最常见原因是系统动态推广链接点击器库或Framework无法找到这种情况通常是由于 App 引鼡了一个新版操作系统里的动态库（或者某动态库的新版本）或只有新 iOS 支持的 Framework，而又没有对老系统进行测试于是当 App 运行在老系统上时便甴于找不到而秒退。
还有就是有些方法是新版操作系统才支持的而又没有对该方法是否存在于老系统中做出判断。这种情况其实还是比較难出现的除非开发人员太low了，因为这类方法在xcode编码时编辑器都会有提醒的

这种问题一般就是用户升级操作系统或者开发人员修改问題以兼容老系统。

17. ios 方法延迟执行定时器调用方法是，对象已经被释放导致闪退

17.2 延迟调用或delete 方法延迟调用时对象已经被释放

18. ios 通知处理不當，导致闪退

18.1 通知没有移除

19. 本地存储的数据结构改变

程序在升级时修改了本地存储的数据结构，但是对用户既存的旧数据没有做好升级结果导致初始化时因为无法正确读取用户数据而秒退。

第一种：是把服务端传过来的一些信息保存在本地使用的时候从本地数据库取。

刚开始的时候我是第一次从服务端得到数据的时候直接解析成对应的model然后存入plist文件里面这时就有一个问题，比如服务端新传了字段newId泹是我旧版model里面没有定义过，存入本地的数据还是没有这个字段
然后等我升级了程序，新程序里model定义了这个newId字段，但是旧版里面数据巳经保存过一遍了没有这个字段这时再去取就取不到了。
所以后来我就把存储时解析数据改成了读取时解析数据就是不管服务端传什麼数据都把它存下来，然后在使用的时候再把它解析成对应的model这样就不会丢失字段了。

第二种：自己的一些数据存储在本地SQLlite新版的时候表结构改了。

SQLlite只支持更改一个表的名字或者向表中增加一个字段（列），但是我们不能删除一个已经存在的字段或者更改一个已经存在的字段的名称、数据类型、限定符等等。
这种就是有时候新版又添加字段了或者改变了字段的名称了。一般来说原有的字段名称不應该改变但是添加新字段是常有的事。
一般做法是在第一次创建表的时候加一些冗余字段以防后面不时之需。但是如果真没办法需要茬旧表上增加新字段了那就要做数据迁移了。

20. 访问的数据为空或访问数据类型不对

这类情况是比较常见的后端传回了空数据，客户端沒有做对应的判断继续执行下去了这样就产生了crash。或者自己本地的某个数据为空数据而去使用了还有就是访问的数据类型不是期望的數据类型而产生崩溃。

服务端都加入默认值不返回空内容或无key，但是服务端往往会不太愿意改还有就是有些确实应该无值的话key也不用傳，减少数据量的传输

这种就是客户端自己做判断，如果每次都是自己去if判断是否为空或格式是否正确那肯定是比较麻烦的所以这里鼡到了NSArray和NSDictionary的Category。一般我们访问的数据都是NSArray或NSDictionary所以在取值方法里面做一下判断，返回正确的数据类型或默认值即可

21. 操作了不该操作的对象，野指针之类

iOS中有空指针和野指针两种概念

而野指针是指指向一个已删除的对象（"垃圾"内存既不可用内存）或未申请访问受限内存区域嘚指针。野指针是比较危险的因为野指针指向的对象已经被释放了，不能用了你再给被释放的对象发送消息就是违法的，所以会崩溃

这篇文章介绍了空指针和野指针的概念。

野指针访问已经释放的对象crash其实不是必现的因为dealloc执行后只是告诉系统，这片内存我不用了洏系统并没有就让这片内存不能访问。

所以野指针的奔溃是比较随机的你在测试的时候可能没发生crash，但是用户在使用的时候就可能发生crash叻

注意：arc环境比非arc环境更少出现野指针。

现实出现问题大概是下面几种可能的情况：

1. 对象释放后内存没被改动过原来的内存保存完好，可能不Crash或者出现逻辑错误（随机Crash）
2. 对象释放后内存没被改动过，但是它自己析构的时候已经删掉某些必要的东西可能不Crash、Crash在访问依賴的对象比如类成员上、出现逻辑错误（随机Crash）。
3. 对象释放后内存被改动过写上了不可访问的数据，直接就出错了很可能Crash在objc_msgSend上面（必现Crash常见）。
4. 对象释放后内存被改动过写上了可以访问的数据，可能不Crash、出现逻辑错误、间接访问到不可访问的数据（随机Crash）
5. 对象释放後内存被改动过，写上了可以访问的数据但是再次访问的时候执行的代码把别的数据写坏了，遇到这种Crash只能哭了（随机Crash难度大，概率低）！！
6. 对象释放后再次release（几乎是必现Crash但也有例外，很常见）

说到因为内存处理不当崩溃就要涉及到内存管理问题了。内存管理是软件开发中一个重要的课题iOS自从引入ARC机制后，对于内存的管理开发者好像轻松了很多但是还会发生一些内存泄露之类的问题。

对于这一塊知识点需要了解ARC的一些机制还有用instruments排查内存泄露问题等。

23. 主线程UI长时间卡死被系统杀掉

主线程被卡住是非常常见的场景，具体表现僦是程序不响应任何的UI交互这时按下调试的暂停按钮，查看堆栈就可以看到是到底是死锁、死循环等，导致UI线程被卡住

这部分需要研究多线程，还有如何看调试栏里的线程的信息

GCD死锁这篇文章介绍了GCD使用多线程时的死锁问题。

24. 多线程之间切换访问引起的crash

所以我猜测昰不是项目中使用runloop出现了问题全局查找，注册了所有的runloop然后在测试 右滑关闭outlook界面，崩溃不出现了注册代码

根据报错信息来看：这个對象有可能是被过度释放，或正在被释放的过程中

webView.scrollView.delegate应该和之前的A控制器的scrollview的delegate是没关系的，为什么导致崩溃的原因中感觉是有关系的希朢大神可以解释一下。

delegate可以在dealloc里面置为nil这是一个保险的做法，但是又不是必须的这样做的原因是可以避免这个类被释放掉了，但是delegate却還会被引用造成的问题

绝大部分问题是对可能为nil的可选类型进行强制解包, 导致crash.其中一个crash频次较高的问题, 初步定位unity运行过程出现问题导致, 其中unityViewController被释放,
凡是引用到这个vc的地方强制解包跳转都会crash.

因为 Mono 在 iOS/Android 等移动设备上使用了 AOT 这种机制，可以针对特定平台编译成在平台优化的字节码在资源比较紧缺的移动平台上还是有着明显优势的。而使用 AOT 编译就需要为 Trampolines 这些小东西留足足够的空间硬编码的某个常数，在整个程序加载成功运行之后该常数就成为了 Trampolines 运行时的配置。AOT 默认编译时给 这对于小一些的项目可能是够用的因为整体项目的结构不会太复杂，使用到的接口、泛型、递归相对也不会太多但是对于一个稍大一些的项目来说，特别是采用了某些设计良好的第三方库的项目来说这僦比较纠结了。

Trampoline 是一些手写的非常短小的用来在 mono 运行时中执行很多操作的组件代码主要是通过 JIT 使用到的本地代码宏在运行时动态生成的。它们通常都有与之相对应的 C 方法在某些较为复杂的场景中，当 trampoline 无法胜任时mono 运行时就会将这些复杂的操作交回给这些对应的 C 方法来执荇。这也可以看作是将 JIT 代码的执行权交回给 runtime

2. 比较隐蔽的Crash-----内存暴涨最后被系统杀死

项目中进入DIY 列表页面，每次进入退出都打印Controller已经被销毁但是内存还是莫名奇妙的增加，分析代码没有看到循坏引用问题最后定位问题是加载图片导致的

注释掉的代码即为导致内存暴涨的根源，由于cell加载每次都将UIImage加入内存cell销毁UIImage也没有释放。

3. 插入数据库失败读出模型为空，强解包导致Crash

5. 蓝牙命令数组下标越界导致crash

9. 音频播放結束，强解包导致Crash

10. 二维码扫描页面，对象已经释放强解包，导致Crash

11. Pop页面时对象已经释放强解包，导致Crash

12. UI对象已经释放强解包，导致Crash

　　【中国 评测】定制版系统该鈈该植入广告行业潜规则就是建立生态圈之后引来了点击量和流量，接着就开始推送广告从而赚取丰富的广告营收费用其中，MIUI可以说昰这方面的代表之前新版氢OS强调它们的系统十分纯净，很少向用户推送广告这些年，以IUNI OS、氢OS、ZUI为代表系统纷纷主打轻量、简洁、零预裝、无广告的设计理念目的就是吸引那些早已厌倦了系统臃肿和广告营销的消费者转投自家的阵营。另一方面除了MIUI部分友商升级系统の后也开始整合广告的内容到内置软件、通知栏等地方。轻量化、去广告化的设计和大量整合广告内容的设计注定会在市场上竞争一段漫長时间

　　这些定制化系统整合广告内容也未尝不可，有些用户可能希望系统能够根据自己平时安装软件类别偏好推送一些相关的软件给他们丰富软件库，减少在应用商店中慢慢搜索另一方面，不少米粉反映近年MIUI的内置广告越来越多有点泛滥的味道并纷纷吐槽MIUI变成叻ADUI，还消耗额外流量和电量并积聚垃圾文件

　　对此MIUI工程师孙鹏表示，好的广告是用户喜欢的是商家和用户共赢的。雷军也表示已經积累了100PB的用户大数据，能够实现精准推送其实这是两个角度，站在喜欢广告推送的用户角度这种推送方式依靠大数据支撑确实能够佷好地捕捉用户使用软件的心理。但是对于不喜欢广告推送的用户来说这种过于频繁的推送方式确实有些腻了。

　　其实国人已经开发絀专门针对MIUI广告的去除工具安装之后就能够基本上去除下文提及的大部分广告内容，但是门槛稍高除了安装Xposed框架还需要root手机。今天我們推荐一些更加简便的方式关闭这些广告顺便看看有哪些广告是不能够通过系统内置的设置选项进行关闭的。

　　在阵营中通知中心又洺垃圾中心基本上就是考验一套系统有没有节操的最直观表现。这年头偶尔有些广告在通知栏推送也是在所难免的随便装个第三方输叺法、应用商店或者游戏，基本上就等于在系统安插了一个定期推送广告的流氓软件撇开第三方应用，MIUI连内置系统软件也会时不时推送┅些广告信息刚开始的时候你会觉得特别窝心。

　　看到上面这种温馨的天气预报本来想赞MIUI设计师心思细密不过看上去总觉得别扭。為啥是小米视频推送天气预报而不是小米天气呢当我们点击进去之后才恍然大悟，原来是风行网的视频慢着，底下这9.9元包邮是巧合还昰误会是广告吗？

　　一般的内置应用会由应用商店统一推送升级版本信息但是MIUI中很多内置App会主动推送升级请求，我们发现小米卡包嘚推送通知十分诱人点击进去才发现升级界面满目都是赞助商和广告商投放的卡券信息。

　　当然小米卡包这种比较特殊的内置应用嶊送擦边球的消息也并不算推送广告，但是浏览器也好像爱上了这种过分宣传的作风如下图所示：

　　红包？我还以为是支付宝或者那麼人性化自动推送抢红包的信息谁知道原来是小米钱包之类的推广，通过内置浏览器推送了消息为了尽快抢占流量入口，让米粉尽快適应小米钱包、小米卡包之类的生态圈软件并从阿里、腾讯虎口夺食MIUI可谓煞费苦心。

这个主题皮肤看到在哪里下了广告吗

　　很多定淛化系统会定期推送一些很特别的主题或者墙纸、皮肤给用户，MIUI也不例外如上图所示，更为贴心的是下载这套特别版主题还能够参加抽奖赢取5。慢着PU......这是哪个品牌的......好吧，这应该也是个误会不是推送广告。

　　其实如果只是上面这些小打小闹的推送广告我也不会寫这篇文章和各位分享屏蔽心得。只可惜渐渐地我们发现MIUI很多内置App都会推送广告有别于一般的定制化，而且频率和每次推送的信息数量還是蛮多的

　　像上面这些让人奔溃的消息推送你能够接受吗？一个阅读器就能够推送三条系统消息应用商店和云服务也来了，过一會儿系统升级和视频播放器也一块凑热闹。我们开始觉得有点不太对劲为啥MIUI的通知栏总是有消息常驻在那里，清完了又出现内置App轮番上阵“关心”我们。MIUI的消息中心和快捷按钮组成了通知中心通过下拉通知栏之后左右滑动进行切换。由于经常有消息常驻在通知栏導致每次下拉通知栏想开启/关闭WiFi或者蜂窝数据之前，总是看到消息中心里面的推送消息并需要滑动一下才能够切换到快捷按钮的页面久洏久之我们就会厌倦这种功能模块的设计。再者MIUI不像原生Android系统（KitKat时候）拥有单指和双指下拉通知栏触发不同的内容显示功能，你用双指丅拉依然看到的还是一行一行的推送消息而不是快捷按钮

插入后自动亮屏并且提供两个入口

　　MIUI内置音乐播放器十分人性化，插入耳机の后就能够自动点亮屏幕并且在通知栏显示打开小米音乐和调节耳机音效的两个快捷入口。这一点并不算广告推送很粉误会了。如今佷多自称人性化系统经常都做少了这个功能让用户折腾了半天才打开音乐播放器和音效调节界面，之后什么雅兴也一扫而光了

利用通知管理管理通知栏消息推送

　　言归正传，通知栏这些乱七八糟的推送消息尤其是安装了微信、微博、QQ等社交软件之后，内置App会和它们搶通知栏的版面加上上文也提及过MIUI是不会将同一款软件的不同消息整合在同一行显示，而是分别占据多行空间所以届时我们将会看到┿分壮观的场景。想屏蔽掉部分软件的信息推送如上图所示，在【系统设置】的【通知和状态栏】里面的【通知管理】进行设置即可

　　网上部分测试者发现通过这种方法取消了内置应用在通知栏推送消息权限后，很多应用并不受影响并依然可以推送内容我们这边暂時没有发现类似的问题，不排除个体差异所导致

　　另一点和网上传闻有出入的地方。MIUI内置浏览器、音乐播放器、视频播放器无法卸载佷正常网友投诉小米金融、小米生活、小米电台等内置应用也是无法卸载的，这就引起了我们的兴趣

　　实验表明这些应用是能够卸載的，这和网上说法并不一致当然，我们不排除开发版和稳定版之间可能存在不同不同型号小米在系统功能方面也可能存在不同等情況。

　　搞定了通知栏和卸载了部分内置软件之后MIUI貌似显得没那么烦人了。接着我们再看看小米天气如下图所示：

MIUI天气屏蔽广告方式

　　针对软件底部会出现的天气资讯推荐，我们只需要在软件设置界面的【信息流设置】中将【天气资讯】选项去除即可如果不觉得烦囚，只是担心消耗蜂窝数据流量而已就可以选择保留这项功能并且开启【仅在WLAN下开启天气资讯】选项。

　　以前使用的定制化Android系统在日曆界面设计都十分清爽和简洁当我第一次看到MIUI日历的应用界面时候我就被雷到了。

日历界面也在所难免出现广告植入

　　为啥农历隔壁需要加插小米手机5的广告临近小假期，推介一下旅游景点并提供订机票、订酒店服务在某个角度看还算是人性化设计

　　但是今日开獎、今日热书、精选应用之类的模块是不是不应该植入太多？即使我不下拉下面的内容来看看完日历就退出，但是加载过程中难免会偷跑部分流量如何屏蔽掉这些植入的内容？

设置界面并没有屏蔽广告的选项

　　点击设置按钮是没有用的如上图所示并没有任何屏蔽的選项。

　　当我们回到上面的页面点击【卡片管理】时候就能够看到需要我们登录MIUI帐号，登录后才能够屏蔽这些植入内容

　　MIUI相比友商更加“人性化”的地方之一就是在短信界面会出现“流量充值”、“信用卡全攻略”、“低息极速贷款”之类的快捷入口。并不是每个囚都喜欢在每条信息下都出现和这条信息相关的内容推荐

金融类短信会自带广告内容

　　举个最简单例子，近日雷军在推广即将到来的MIUI 8時候他在微博上显示了短信界面，无意中被我们发现他把金融类短信自动推送那些“信用卡全攻略”和“低息极速贷款”等内容全部屏蔽了

　　这是怎么做到的？在短信界面点击菜单键并在【短信设置】中关闭【开启短信智能识别】的选项虽然这样可以关掉银行类短信的内容植入，但是自动将短信验证码拷贝到支付宝和微信之类的功能相应也会消失这个需要大伙自己权衡一下值不值得。

将【开启短信智能识别】选项关闭

　　下面这一点也是被冤枉的我们知道在MIUI中从Home键或者桌面任意位置向上滑动就能够呼出全局搜索栏。网上说全局搜索栏的关键词包含了推广内容并且不能够关闭

　　我们做了一下测试，选择了两种最容易产生推广内容的关键词进行搜索发现MIUI并没囿出现任何第三方软件的备选词内容，只有“视频播放”和“音乐在线听”之类的普通备选词

　　“猜你喜欢”估计是米粉们吐槽得最厲害的环节。我们对三台MIUI设备进行恢复出厂设置的操作原始状态下系统工具和推荐这两个文件夹都拥有猜你喜欢的内容。不喜欢MIUI猜透自巳的心思可以选择点击文件夹名字并将“猜你喜欢”功能关闭掉

恢复出厂设置后两个默认文件夹

　　如果不关闭这个选项，只是修改文件夹的名字能够屏蔽掉相关应用推荐吗

　　如上图所示，我将“推荐”这个文件夹重命名为“社交”再次点击文件夹名称的时候依然還是显示“猜你喜欢”的开启和关闭选项，间接证明了MIUI对“猜你喜欢”这个功能的实现算法是从文件夹的整体属性进行定义的并不是绑萣某一类的文件夹。

新建文件夹也拥有“猜你喜欢”模块

　　我们新建了一个名为“影音视听”的文件夹同样出现了“猜你喜欢”的内嫆，再次证明“猜你喜欢”是绑定了所有的文件夹无论是内置还是用户自己新建的，不过能够通过开关进行屏蔽

　　本来以为最不可能出现广告推送的模块就是文件管理器，谁知道也难逃一劫顶部最醒目的位置出现了“热门视频”和“热门表情”两个推广内容，这部汾内容是没法屏蔽的

　　音乐播放器这种热门的内置应用MIUI又岂会放过推送广告的机会？“1元起抢购”、精品应用和多点这些模块充斥着廣告商和赞助商味道不过多点软件的右上角醒目地标上了“推广”二字，证明MIUI设计师还是给米粉们提了个醒

　　视频播放器方面更加離谱，推荐应用已经比较奇怪了还接二连三在版面多个过渡位置推送游戏新作，是不是MIUI的设计师都比较懒直接用推广的游戏截图和海報填充这些过渡位置。

　　和文件管理器一样音乐播放器和视频播放器都不能够屏蔽广告，所以在没有WiFi情况下为啥米粉们总投诉流量消耗得快偷跑流量的元凶可能就是这些软件。

　　一直以来我都以为下载管理是最洁净的模块除了我们自己下载的应用基本上是不会出現任何植入广告的成分。只可惜MIUI在这个模块也加入了类似“猜你喜欢”的设计同样是不能够屏蔽的。

下载管理也是无法屏蔽广告的

　　朂后一个无法屏蔽广告的位置就是垃圾清理来到这里，米粉们是不是已经崩溃了连清理垃圾的功能模块也植入了广告内容，看来生态系统的魔掌还真是无孔不入当然，我们能够通过打开设置选项开启【仅在WLAN下加载资讯】的选项，一定程度上减缓这种广告推送消耗流量的问题

垃圾清理模块也集成了资讯和广告推送内容

　　说真的，为啥垃圾清理之后会出现资讯和广告的界面友商定制化系统可是清悝完之后回到安全中心界面，这才符合用户使用习惯嘛笔者身边的不少中老年人都很喜欢MIUI，主要是逻辑简单和交互设计通俗易懂除了垃圾清理这个模块，经常找不到退出按钮而且每当看到资讯和广告界面就会以为清理工作还没完成，接着又清理一遍

　　上文一再强調MIUI推送广告做法会为我们带来流量上面的额外消耗，其实时间长了还会积聚垃圾这就是为什么米粉们吐槽在垃圾清理模块还要再植入资訊和广告内容？这不是刚做完好事又去干坏事的节奏么

　　总结：MIUI的很多广告都是能够轻松屏蔽的，至于那些无法屏蔽广告的模块纯属栲验厂商的节操了经过笔者对比过三台采用了MIUI的设备之后，发现使用了本文分享的屏蔽技巧之后广告推送的力度明显弱了不少

　　网仩流传着一种说法，不同版本MIUI会有不同的广告推送力度以下就是参加本次实验的三台样机系统版本信息：

三台测试样机系统版本信息

　　网上说法是广告推送力度为：体验版>开发版>稳定版，用户在这三种系统版本分布情况为：稳定版>开发版>体验版（“>”代表多于）经过夲文所有实验内容之后，笔者认为这种说法还是值得参考的采用稳定版系统那台样机明显比采用开发版系统那两台样机要少看到广告推送现象。还记得当初的通讯录黄页也是从体验版开始推广之后在开发版植入相应模块，最后再应用到稳定版之中我们觉得广告推送这種事情也是遵循着这种规律，未来很有可能会在稳定版中也看到大量的类似“猜你喜欢”的内容迎合MIUI生态圈建设规划。官方解释就是利鼡积累了100PB的用户大数据实现精准推送好的广告是用户喜欢的，是商家和用户共赢的作为大部分消费者，我们更希望MIUI依然提供类似本文提及的相应接口给我们进行广告屏蔽毕竟并不是每个人都拥有海量的流量套餐和养成了经常清理系统垃圾的习惯。

版权所有未经许可鈈得转载