两周过去了。
创新互联服务项目包括金安网站建设、金安网站制作、金安网页制作以及金安网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，金安网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到金安省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！
在 WWDC20 震惊全场的 iOS 14.
如今终于迎来了第二个版本。
在这个版本中除了带来了新的「文件」桌面小组件。
以及一些细节的调整之外。
更多看得到的改进，则是稳定性方面的提升。
包括流畅度、汉化完成度、组件的宽度统一。
完成度比上一个版本又精进了许多。
除了期待的时钟小组件和 AirPods Pro 空间音频依旧没有到来之外。
这次更新还是比较给人安慰的。
而至于更详细的本次更新内容。
欢迎大家往下看本次的 iOS Beta 体验报告：
•测试机型：iPhone 11•测试版本：iOS 14 Beta 2 •对比系统：iOS 14 Beta 1•版本号：（18A5319i）•版本类型：开发者测试版
1、流畅度提升。（玄学警告⚠️）
2、新增了更多的汉化内容，比如「主屏幕」和「软件更新」内。
3、新增了「文件」桌面组件，包含两种尺寸，可以显示最近编辑过的文件。
4、新增了「研究目的」和「隐私政策」，在「设置 - 研究」中。（@冰阔落一块钱四瓶 提供）
5、新增了 Apple Music 操作按钮的触觉反馈，现在摸上去会震动。
7、新增了电话设置中「来电」和「来电时语音提示」的图标。(@阿毛 提供）
8、调整了时钟、日历图标的文字、时针和分针的粗细，现在更粗了一些，日历也将「星期」改为「周」。
9、调整了天气挂件中最高/低温度的文字，由中文代替了 H/L 的字样。
10、调整了第三方应用组件的宽度，与小挂件统一了。（舒服多了）
11、调整了「家庭共享」的图标。（@HChiehNi 提供）
1、依然出现了汉化不完全的问题。
2、修复了在「设置-通用-iPhone 储存空间」中查看较大附件时，点开就闪退的问题。（@imshane 提供）
电池续航方面。
我们将使用 GeekBench 4 对该版本进行为期 3 小时的续航测试，测试结果将在 @iBeta尝鲜派（新浪微博）发布。
1、 直接在浏览器中打开：iBeta.me[1]，跳转至 @iBeta尝鲜派，选择描述文件并按图所示安装至你的设备。
2、 安装描述文件后重启。
3、重启后即可收到更新推送，点击「下载并安装」即可。
本次测试结果与本体验报告及配图版权均属于 @iBeta 尝鲜派。
栏目头图设计来自 @李星佑。
为了尊重我们的劳动成果和付出的精力，降低您日后转载的难度。
感谢「高品质的二手商城 · 爱否二手」提供的测试机。
本人觉得这个打包framework还是一个比较重要的功能，可以用来做一下事情：(1)封装功能模块，比如有比较成熟的功能模块封装成一个包，然后以后自己或其他同事用起来比较方便。(2)封装项目，有时候会遇到这个情况，就是一家公司找了两个开发公司做两个项目，然后要求他们的项目中的一个嵌套进另一个项目，此时也可以把呗嵌套的项目打包成framework放进去，这样比较方便。我们为什么需要框架(Framework)?要想用一种开发者友好的方式共享库是很麻烦的。你不仅仅需要包含库本身，还要加入所有的头文件，资源等等。苹果解决这个问题的方式是框架(framework)。基本上，这是含有固定结构并包含了引用该库时所必需的所有东西的文件夹。不幸的是，iOS禁止所有的动态库。同时，苹果也从Xcode中移除了创建静态iOS框架的功能。Xcode仍然可以支持创建框架的功能，重启这个功能，我们需要对Xcode做一些小小的改动。把代码封装在静态框架是被app store所允许的。尽管形式不同，本质上它仍然是一种静态库。框架(Framework)的类别大部分框架都是动态链接库的形式。因为只有苹果才能在iOS设备上安装动态库，所以我们无法创建这种类型的框架。静态链接库和动态库一样，只不过它是在编译时链接二进制代码，因此使用静态库不会有动态库那样的问题(即除了苹果谁也不能在iOS上使用动态库)。“伪”框架是通过破解Xcode的目标Bundle(使用某些脚本)来实现的。它在表面上以及使用时跟静态框架并无区别。“伪”框架项目的功能几乎和真实的框架项目没有区别(不是全部)。“嵌入”框架是静态框架的一个包装，以便Xcode能获取框架内的资源(图片、plist、nib等)。本次发布包括了创建静态框架和“伪”框架的模板，以及二者的“嵌入”框架。用哪一种模板?本次发布有两个模板，每个模板都有“强”“弱”两个类别。你可以选择最适合一种(或者两种都安装上)。最大的不同是Xcode不能创建“真”框架，除非你安装静态框架文件xcspec在Xcode中。这真是一个遗憾(这个文件是给项目使用的，而不是框架要用的)。简单说，你可以这样决定用哪一种模板：如果你不想修改Xcode，那么请使用“伪”框架版本如果你只是想共享二进制(不是项目)，两种都可以如果你想把框架共享给不想修改Xcode的开发者，使用“伪”框架版本如果你想把框架共享给修改过Xcode的开发者，使用“真”框架版本如果你想把框架项目作为另一个项目的依赖(通过workspace或者子项目的方式)，请使用“真”框架(或者“伪”框架，使用-framework——见后)如果你想在你的框架项目中加入其他静态库/框架，并把它们也链接到最终结果以便不需要单独添加到用户项目中，使用“伪”框架“伪”框架“伪”框架是破解的“reloacatable object file”(可重定位格式的目标文件， 保存着代码和数据，适合于和其他的目标文件连接到一起，用来创建一个可执行目标文件或者是一个可共享目标文件)，它可以让Xcode编译出类似框架的东西——其实也是一个bundle。“伪框架”模板把整个过程分为几个步骤，用某些脚本去产生一个真正的静态框架(基于静态库而不是reloacatable object file)。而且，框架项目还是把它定义为wrapper.cfbundle类型，一种Xcode中的“二等公民”。因此它跟“真”静态框架一样可以正常工作，但当存在依赖关系时就有麻烦了。依赖问题如果不使用依赖，只是创建普通的项目是没有任何问题的。但是如果使用了项目依赖(比如在workspace中)，Xcode就悲剧了。当你点击“Link Binary With Libraries”下方的’+’按钮时，“伪框架”无法显示在列表中。你可以从你的“伪”框架项目的Products下面将它手动拖入，但当你编辑你的主项目时，会出现警告：warning: skipping file '/somewhere/MyFramework.framework' (unexpectedfile type 'wrapper.cfbundle' in Frameworks Libraries build phase)并伴随“伪”框架中的链接错误。幸运的是，有个办法来解决它。你可以在”Other Linker Flags”中用”-framwork”开关手动告诉linker去使用你的框架进行链接：-framework MyFramework警告仍然存在，但起码能正确链接了。添加其他的库/框架如果你加入其他静态(不是动态)库/框架到你的“伪”框架项目中，它们将“链接”进你最终的二进制框架文件中。在“真”框架项目中，它们是纯引用，而不是链接。你可以在项目中仅仅包含头文件而不是静态库/框架本身的方式避免这种情况(以便编译通过)。“真”框架“真”框架各个方面都符合“真”的标准。它是真正的静态框架，正如使用苹果在从Xcode中去除的那个功能所创建的一样。为了能创建真正的静态框架项目，你必需在Xcode中安装一个xcspec文件。如果你发布一个“真”框架项目(而不是编译)，希望去编译这个框架的人必需也安装xcspec文件(使用本次发布的安装脚本)，以便Xcode能理解目标类型。注意：如果你正在发布完全编译的框架，而不是框架项目，最终用户并不需要安装任何东西。我已经提交一个报告给苹果，希望他们在Xcode中更新这个文件，但那需要一点时间.OpenRadarlink here加其他静态库/框架如果你加入其他静态(不是动态)库/框架到你的“真”框架项目，它们只会被引用，而不会象“伪”框架一样被链接到最终的二进制文件中。从早期版本升级如果你是从Mk6或者更早的版本升级，同时使用“真”静态框架，并且使用Xcode4.2.1以前的版本，请运行uninstall_legacy.sh以卸载早期用于Xcode的所有修正。然后再运行install.sh，重启Xcode。如果你使用Xcode4.3以后，只需要运行install.sh并重启Xcode。安装分别运行Real Framework目录或Fake Framework目录下的install.sh脚本进行安装(或者两个你都运行)。重启Xcode，你将在新项目向导的FrameworkLibrary下看到StaticiOS Framework(或者Fake Static iOS Framework)。卸载请运行unistall.sh脚本并重启Xcode。创建一个iOS框架项目创建新项目。项目类型选择FrameworkLibrary下的Static iOS Framework(或者Fake Static iOS Framework)。选择“包含单元测试”(可选的)。在target中加入类、资源等。凡是其他项目要使用的头文件，必需声明为public。进入target的Build Phases页，Copy Headers项，把需要public的头文件从Project或Private部分拖拽到Public部分。编译你的 iOS 框架选择指定target的scheme修改scheme的Run配置(可选)。Run配置默认使用Debug，但在准备部署的时候你可能想使用Release。编译框架(无论目标为iOS device和Simulator都会编译出相同的二进制，因此选谁都无所谓了)。从Products下选中你的framework，“show in Finder”。在build目录下有两个文件夹：(yourframework).framework and (your framework).embeddedframework.如果你的框架只有代码，没有资源(比如图片、脚本、xib、coredata的momd文件等)，你可以把(yourframework).framework 分发给你的用户就行了。如果还包含有资源，你必需分发(your framework).embeddedframework给你的用户。为什么需要embedded framework?因为Xcode不会查找静态框架中的资源，如果你分发(your framework).framework, 则框架中的所有资源都不会显示，也不可用。一个embedded framework只是一个framework之外的附加的包，包括了这个框架的所有资源的符号链接。这样做的目的是让Xcode能够找到这些资源。使用iOS 框架iOS框架和常规的Mac OS动态框架差不多，只是它是静态链接的而已。在你的项目中使用一个框架，只需把它拖仅你的项目中。在包含头文件时，记住使用尖括号而不是双引号括住框架名称。例如，对于框架MyFramework：#import使用问题Headers Not Found如果Xcode找不到框架的头文件，你可能是忘记将它们声明为public了。参考“创建一个iOS框架项目”第5步。No Such Product Type如果你没有安装iOS Universal Framework在Xcode，并企图编译一个universal框架项目(对于“真”框架，不是“假”框架)，这会导致下列错误：target specifies product type 'com.apple.product-type.framework.static',but there's no such product type for the 'iphonesimulator' platform为了编译“真”iOS静态框架，Xcode需要做一些改动，因此为了编译“真”静态框架项目，请在所有的开发环境中安装它(对于使用框架的用户不需要，只有要编译框架才需要)。The selected run destination is not valid for this action有时，Xcode出错并加载了错误的active设置。首先，请尝试重启Xcode。如果错误继续存在，Xcode产生了一个坏的项目(因为Xcode4的一个bug，任何类型的项目都会出现这个问题)。如果是这样，你需要创建一个新项目重来一遍。链接警告第一次编译框架target时，Xcdoe会在链接阶段报告找不到文件夹：ld: warning: directory not found for option'-L/Users/myself/Library/Developer/Xcode/DerivedData/MyFramework-ccahfoccjqiognaqraesrxdyqcne/Build/Products/Debug-iphoneos'此时，可以clean并重新编译target，警告会消除。Core Data momd not found对于框架项目和应用程序项目，Xcode会以不同的方式编译momd(托管对象模型文件)。Xcode会简单地在根目录创建.mom文件，而不会创建一个.momd目录(目录中包含VersionInfo.plist和.mom文件)。这意味着，当从一个embedded framework的model中实例化NSManagedObjectModel时，你必需使用.mom扩展名作为model的URL，而不是采用.momd扩展名。NSURL *modelURL = [[NSBundle mainBundle]URLForResource:@"MyModel" withExtension:@"mom"];Unknown class MyClass in Interface Builder file.由于静态框架采用静态链接，linker会剔除所有它认为无用的代码。不幸的是，linker不会检查xib文件，因此如果类是在xib中引用，而没有在O-C代码中引用，linker将从最终的可执行文件中删除类。这是linker的问题，不是框架的问题(当你编译一个静态库时也会发生这个问题)。苹果内置框架不会发生这个问题，因为他们是运行时动态加载的，存在于iOS设备固件中的动态库是不可能被删除的。有两个解决的办法：让框架的最终用户关闭linker的优化选项，通过在他们的项目的Other Linker Flags中添加-ObjC和-all_load。在框架的另一个类中加一个该类的代码引用。例如，假设你有个MyTextField类，被linker剔除了。假设你还有一个MyViewController，它在xib中使用了MyTextField，MyViewController并没有被剔除。你应该这样做：在MyTextField中：+ (void)forceLinkerLoad_ {}在MyViewController中：+(void) initialize { [MyTextField forceLinkerLoad_]; }他们仍然需要添加-ObjC到linker设置，但不需要强制all_load了。第2种方法需要你多做一点工作，但却让最终用户避免在使用你的框架时关闭linker优化(关闭linker优化会导致object文件膨胀)。unexpected file type 'wrapper.cfbundle' in Frameworks Libraries build phase这个问题发生在把“假”框架项目作为workspace的依赖，或者把它当作子项目时(“真”框架项目没有这个问题)。尽管这种框架项目产生了正确的静态框架，但Xcode只能从项目文件中看出这是一个bundle，因此它在检查依赖性时发出一个警告，并在linker阶段跳过它。你可以手动添加一个命令让linker在链接阶段能正确链接。在依赖你的静态框架的项目的OtherLinker Flags中加入：-framework MyFramework警告仍然存在, 但不会导致链接失败。Libraries being linked or not being linked into the finalframework很不幸， “真”框架和“假”框架模板在处理引入的静态库/框架的工作方式不同的。“真”框架模板采用正常的静态库生成步骤，不会链接其他静态库/框架到最终生产物中。“假”框架模板采用“欺骗”Xcode的手段，让它认为是在编译一个可重定位格式的目标文件，在链接阶段就如同编译一个可执行文件，把所有的静态代码文件链接到最终生成物中(尽管不会检查是否确实目标代码)。为了实现象“真”框架一样的效果，你可以只包含库/框架的头文件到你的项目中，而不需要包含库/框架本身。Unrecognized selector in (some class with a category method)如果你的静态库或静态框架包含了一个模块(只在类别代码中声明，没有类实现)，linker会搞不清楚，并把代码从二进制文件中剔除。因为在最终生成的文件中没有这个方法，所以当调用这个类别中定义的方法时，会报一个“unrecognizedselector”异常。要解决这个，在包含这个类别的模块代码中加一个“假的”类。linker发现存在完整的O-C类，会将类别代码链接到模块。我写了一个头文件 LoadableCategory.h，以减轻这个工作量：#import "SomeConcreteClass+MyAdditions.h"#import "LoadableCategory.h" MAKE_CATEGORIES_LOADABLE(SomeConcreteClass_MyAdditions); @implementation SomeConcreteClass(MyAdditions)...@end在使用这个框架时，仍然还需要在Build Setting的Other Linker Flags中加入-ObjC。执行任何代码前单元测试崩溃如果你在Xcode4.3中创建静态框架(或库)target时，勾选了“withunit tests”，当你试图运行单元测试时，它会崩溃：Thread 1: EXC_BAD_ACCESS (code=2, address=0x0) 0 0x00000000 --- 15 dyldbootstrap:start(...)这是lldb中的一个bug。你可以用GDB来运行单元测试。编辑scheme，选择Test，在Info标签中将调试器Debugger从LLDB改为GDB。
一、如何获得crash日志
当一个iOS应用程序崩溃时，系统会创建一份crash日志保存在设备上。这份crash日志记录着应用程序崩溃时的信息，通常包含着每个执行线程的栈调用信息(低内存闪退日志例外)，对于开发人员定位问题很有帮助。
如果设备就在身边，可以连接设备，打开Xcode - Window - Organizer，在左侧面板中选择Device
Logs(可以选择具体设备的Device Logs或者Library下所有设备的Device
Logs)，然后根据时间排序查看设备上的crash日志。这是开发、测试阶段最经常采用的方式。
如果应用程序已经提交到App Store发布，用户已经安装使用了，那么开发者可以通过iTunes Connect(Manage Your
Applications - View Details - Crash
Reports)获取用户的crash日志。不过这并不是100%有效的，而且大多数开发者并不依赖于此，因为这需要用户设备同意上传相关信息，详情可参见iOS:
Providing Apple with diagnostics and usage information摘要。
考虑到并不是所有iPhone用户都允许自动发送诊断报告(crash日志)，而且对于部分提交到Apple得crash日志，开发者还需要手动去拉取，然后找到对应的符号文件进行解析——这是一件很繁琐的事情。所以实际项目开发中，通常接入现有的crash收集工具(参考1，参考2)，或者自己编写一个进行自动化收集、解析和统计汇总。
二、如何解析crash日志
当获得一份crash日志时，我们需要将初始展示的十六进制地址等原始信息映射为源代码级别的方法名称和代码行数，使其对开发人员可读。这个过程称为符号化解析。要成功地符号化解析一份crash日志，我们需要有对应的应用程序二进制文件以及符号(.dSYM)文件。
如果处于开发调试阶段，通常Xcode都能匹配到crash日志对应的二进制文件和符号文件，所以能够帮我们自动解析。
如果处于测试阶段，测试人员已经安装了不同的版本(比如alpha、beta版本)，那么需要保存好对应版本的二进制文件和符号文件，以便在应用程序崩溃时对crash日志进行解析。对于这种场景下产生的crash日志，只需要将.crash文件、.app文件和.dSYM文件三者放在同一个目录下，然后将.crash文件拖放到Xcode
- Window - Organizer中左侧面板Library下的Device Logs中，即可进行解析。
如果要提交发布，那么我们通常会先执行Clean，再Build，最后通过Product -
Archive来打包。这样，Xcode会将二进制文件和符号文件归档在一起，可以通过Organizer中的Archives进行浏览。
三、如何分析crash日志
在分析一份crash日志之前，如果开发人员对于常见的错误类型有所了解，那定是极好的。
crash日志的产生来源于两种问题：违反iOS策略被干掉，以及自身的代码bug。
1. iOS策略
1.1 低内存闪退
前面提到大多数crash日志都包含着执行线程的栈调用信息，但是低内存闪退日志除外，这里就先看看低内存闪退日志是什么样的。
我们使用Xcode 5和iOS
7的设备模拟一次低内存闪退，然后通过Organizer查看产生的crash日志，可以发现Process和Type都为Unknown：
而具体的日志内容如下：
第一部分是崩溃信息，包括识别标识、软硬件信息和时间信息等。
第二部分是内存页分配信息，以及当前占用内存最多的进程，上图中为crashTypeDemo。
第三部分是具体的进程列表，描述着每个进程使用内存的情况以及当前状态。在较早的版本中可以在某些进程后面看到“jettisoned”字样，表明这些进程使用过多内存被终止了，而现在我们看到的是“vm-pageshortage”字样。
当iOS检测到内存过低时，它(的VM系统)会发出低内存警告通知，尝试回收一些内存;如果情况没有得到足够的改善，iOS会终止后台应用以回收更多内存;最后，如果内存还是不足，那么正在运行的应用可能会被终止掉。
所以，我们的应用应该合理地响应系统抛出来的低内存警告通知，对一些缓存数据和可重新创建的对象进行释放，同时要避免出现内存泄露等问题。
低内存闪退是由iOS策略决定终止应用程序运行的，同样基于iOS策略的还有Watchdog超时和用户强制退出。
1.2 Watchdog超时
Apple的iOS Developer
Library网站上，QA1693文档中描述了Watchdog机制，包括生效场景和表现。如果我们的应用程序对一些特定的UI事件(比如启动、挂起、恢复、结束)响应不及时，Watchdog会把我们的应用程序干掉，并生成一份响应的crash报告。
这份crash报告的有趣之处在于异常代码：“0x8badf00d”，即“ate bad food”。
如果说特定的UI事件比较抽象，那么用代码来直接描述的话，对应的就是(创建一个工程时Xcode自动生成的)UIApplicationDelegate的几个方法：
所以当遇到Watchdog日志时，可以检查下上图几个方法是否有比较重的阻塞UI的动作。
QA1693举的例子是在主线程进行同步网络请求。如果我们是在公司的Wifi环境下使用则一切顺利，但当应用程序发布出去面向很大范围的用户，在各种网络环境下运行，则不可避免地会出现一片Watchdog超时报告。
另一种可能出现问题的场景就是数据量比较大的情况下进行的数据库版本迁移(同样是在主线程上)，这也是促使我写这篇总结的一个直接因素。
1.3 用户强制退出
一看到“用户强制退出”，首先可能想到的双击Home键，然后关闭应用程序。不过这种场景是不会产生crash日志的，因为双击Home键后，所有的应用程序都处于后台状态，而iOS随时都有可能关闭后台进程，所以这种场景没有crash日志。
另一种场景是用户同时按住电源键和Home键，让iPhone重启。这种场景会产生日志(仅验证过一次)，但并不针对特定应用程序。
这里指的“用户强制退出”场景，是稍微比较复杂点的操作：先按住电源键，直到出现“滑动关机”的界面时，再按住Home键，这时候当前应用程序会被终止掉，并且产生一份相应事件的crash日志。
通常，用户应该是遇到应用程序卡死，并且影响到了iOS响应，才会进行这样的操作——不过感觉这操作好高级，所以这样的crash日志应该比较少见。
2. 常见错误标识
2.1 Exception codes
上面“用户强制退出”的crash日志中的Exception
Codes是“0xdeadfa11”，再上面“Watchdog超时”的crash日志中的Exception
Codes是“0x8badf00d”，这些都是特有的Exception codes。
根据官方文档描述，至少有以下几种特定异常代码：
0x8badf00d错误码：Watchdog超时，意为“ate bad food”。
0xdeadfa11错误码：用户强制退出，意为“dead fall”。
0xbaaaaaad错误码：用户按住Home键和音量键，获取当前内存状态，不代表崩溃。
0xbad22222错误码：VoIP应用(因为太频繁?)被iOS干掉。
0xc00010ff错误码：因为太烫了被干掉，意为“cool off”。
0xdead10cc错误码：因为在后台时仍然占据系统资源(比如通讯录)被干掉，意为“dead lock”。
2.2 Exception types
查看我们的crash分析报告邮件，会发现最经常遇到的错误类型是SEGV(Segmentation
Violation，段违例)，表明内存操作不当，比如访问一个没有权限的内存地址。
当我们收到SIGSEGV信号时，可以往以下几个方面考虑：
访问无效内存地址，比如访问Zombie对象;
尝试往只读区域写数据;
解引用空指针;
使用未初始化的指针;
栈溢出;
此外，还有其它常见信号：
SIGABRT：收到Abort信号，可能自身调用abort()或者收到外部发送过来的信号;
SIGBUS：总线错误。与SIGSEGV不同的是，SIGSEGV访问的是无效地址(比如虚存映射不到物理内存)，而SIGBUS访问的是有效地址，但总线访问异常(比如地址对齐问题);
SIGILL：尝试执行非法的指令，可能不被识别或者没有权限;
SIGFPE：Floating Point Error，数学计算相关问题(可能不限于浮点计算)，比如除零操作;
SIGPIPE：管道另一端没有进程接手数据;
3. 代码bug
此外，比较常见的崩溃基本都源于代码bug，比如数组越界、插空、多线程安全性、访问野指针、发送未实现的selector等。如果引入Core
Data，则又有另外一些常见问题，不过这是另一个话题了。
遇到这些bug时，都有比较清楚的错误原因说明，比如“index 0 beyond bounds for empty
array”等。需要稍微注意点的是多线程问题，当一时找不到解决思路时，不妨往多线程方面考虑下。
ios不像Android可以ddms抓取。
1、ios用自动化工具instrument或者monkey跑的时候会调用xcode的模板，这个模板会有trace文件，通过trace文件解析可以知道时间和操作元素哪里crash。
2、另外，你的app crash后在你手机里面会有崩溃日志的，你用iTools找到plist对应的文件给开发看
3、第三个文件是dsym二进制符号表的堆栈信息，验证xxx.crash、xxx.app和xxx.dSYM三者的uuid是否一致。这个开发知道，必须告诉开发对应编译版本和你的plist文件一起，开发才能真正解析出bug产生日志。
iOS 13正式版于9月20日正式发布，从时间上来看，9月20号到10月底，大约有40天。以月为时间周期，我们统计了整体的数据情况，希望这份数据报告也能更好的帮助开发者了解iOS 13的热搜。
同时，由于热搜当前涉及【 关键词】 及【 App】 ，此处仅展示App相关数据报告。如有想对“关键词”作相关了解的朋友，可以关注 巨掌数据（ID:BJ-adjuz） ，在历史消息第一条查看另一篇关于 iOS 13 热搜关键词 的数据报告。
注：此处数据报告选取数据区间为9月20日至10月19日，为一个月完整区间。描述统计时无独立说明，均为未去重数据，因为Apple会重复推荐关键词或关键词重复上热搜。
一、整体数据概览
在数据导出上，我们选择了“推荐日期”、“最近更新时间”、“推荐类别”、“热搜关键词”、“热度”等作为数据的分析维度，以下为整理的数据示例图：
根据这个数据情况，同时我们也做了一个数据报表，包括关键词的每日推荐量，推荐趋势，特殊关键词推荐次数等等，以下为数据表报概览：
注：后台回复【1101】获取已整理好的数据仪表盘。
二、重点数据分析说明
1、每日推荐App数量
1.1、数据图：
1.2、数据分析：
①从数据上来看，平均每日推荐的App数量在227款左右。
②个别时间会出现推荐量接近400，或者推荐量不足200的情况。
2、App被推荐次数
2.1、数据图：
2.2、数据分析：
①部分App出现了极高的推荐次数，例如“神武3”，日均推荐10-11次。 这里如果有看过另一篇“iOS 13热搜数据报告 （巨掌数据公众号历史消息第一篇） ”文章的朋友，可能会发现这里有个App叫“神武3”，而关键词那边则有个关键词叫“神物3”，对应一下，也算是印证关键词数据报告的某项数据结论。
②从推荐App的类型来看，各个类别App均有被推荐可能，例如音乐、游戏、教育、工具等等。
③从整体看，也是游戏产品被推荐次数更多，或与App Store整体游戏产品偏多及游戏产品贡献营收有关。
3、极高推荐度App上热搜数据情况
3.1、数据图：
3.2、数据分析：
①根据数据可以看到，日均在11次左右。
②有出现单日21次及19次的情况(这里猜测是Apple未更新或抓取接口数据返回问题)。
4、被推荐App在分类下占比(未去重)
4.1、数据图：
4.2、数据分析：
①游戏占推荐49.92%。
②教育类其次，占11.45%。
5、被推荐App在分类下占比(已去重)
5.1、数据图：
5.2、数据分析：
①游戏占推荐32.75%。
②摄影录像其次，占11.17%。
6、最后更新时间与被推荐关系
6.1、数据图：
6.2、数据分析：
①最后更新时间在近期的产品，更有被推荐的可能。
②非近期更新的产品也有被推荐情况，例如“腾讯微博”为2年前产品，且尚未更新。
7、产品发布时间与被推荐关系
7.1、数据图：
7.2、数据分析：
①不同发布年份的产品均有被推荐的可能。
②整体数据呈平衡状态，在2017年的最多，或由于2017年本身发布产品数量较多导致。
③因整体数据未有较为突出代表性，所以此处认为产品发布时间与被推荐关系并不大，而产品最后更新时间或与被推荐有较大关系。
8、无内购产品每日被推荐数量
Tips：此处所说的“无内购”并非是产品内无支付功能，而是产品内未用到Apple的支付方式，且不需要给Apple分30%收益。
8.1、数据图：
8.2、数据分析：
①日均被推荐33次。
②部分天数出现48或57的极高情况。
9、无内购产品被推荐次数
9.1、数据图：
9.2、数据分析：
①最高推荐37次，日均1次，也就是4小时左右。
②推荐主要类别包含购物、工具、教育、生活类别等。
10、无内购产品推荐应用类别
10.1、数据图：
10.2、数据分析：
①购物类被推荐最高，占24.53%。
②旅游类其次，占13.84%。
③此两类也算是无Apple内购的典型产品，产品内购买内容为实物，基本符合App Store应用情况。
11、有内购产品每日被推荐数量
11.1、数据图：
11.2、数据分析：
①日均被推荐194次。
②部分天数出现310或300的极高情况。
12、有内购产品被推荐次数
12.1、数据图：
12.2、数据分析：
①最高推荐321次，日均10-11次。
②推荐主要类别包含游戏、工具、教育类别等。
13、有内购产品推荐应用类别
13.1、数据图：
13.2、数据分析：
①游戏类被推荐最高，占57.54%。
②教育类其次，占12.48%。
③这里也基本能看到App Store主要内购产品的内购类别，包括消耗型游戏内购，会员制App订阅付费等。
三、数据洞察结论
1、游戏类产品被推荐率在50%左右，且App被推荐后，有潜在可能把覆盖的部分关键词一并推荐。
2、时常做产品更新的App更有助于被Apple推荐上热搜。更新产品一方面是在于修复产品bug及提升用户体验，另一方面是在于及时融合Apple推出的新功能，例如iOS13的暗黑模式。
3、iOS13上9月-10月热搜推荐App数据表明，带Apple付费的产品被Apple推荐几率更高(这里也跟App Store整体的游戏产品数量占比有关)。
ios开发cup使用过大会崩溃。
处理的要素
iOS设备上的应用闪退时，操作系统会生成一个崩溃报告，也叫崩溃日志，保存在设备上。
崩溃日志上有很多有用的信息，包括应用是什么情况下闪退的。通常，上面有每个正在执行线程的完整堆栈跟踪信息，所以你能从中了解到闪退发生时各线程都在做什么，并分辨出闪退发生在哪个线程上。
数据获取
设备与电脑上的iTunes Store同步后，会将崩溃日志保存在电脑上。根据电脑操作系统的不同，崩溃日志将保存在以下位置
Windows XP:
Windows Vista or 7:
