iOS网络性能监控

最新推荐文章于 2024-04-14 09:56:09 发布
最新推荐文章于 2024-04-14 09:56:09 发布
阅读量715 收藏
点赞数
文章标签： 移动开发 运维 json
原文链接：https://juejin.im/post/5c233a42518825079f7842eb
版权

现在的Native App平台化趋势越来越明显，网络层架构也越来越复杂。一个App基本都有多个不同的网络模块。 从简单的业务数据的HTTP/HTTPS(基于NSURLConnection或者NSURLSession),到WebView的WebCore网络层，到基于TCP长连接的推送模块，到各种第三方组件比如统计、日志上报各自的网络层，或者很多app采用基于TCP的私有协议等等，网络层越来越复杂，对Native开发者来说越来越像一个黑盒模块。 Native开发者只能着眼于业务开发，对网络层的异常、性能等等问题一无所知。

初识iOS网络层API

让我们剥开网络相关的SDK，一层一层地看每一层做了些什么。

AFNetworking

AFNetworking是对NSURLConnection/NSURLSession的封装。增加了如下逻辑

  • 封装成NSOperation的形式，提供了resume/cancel等等处理。
  • 增加了NSData的文件处理，上传/下载
  • 方便处理JSON/XML数据
  • 方便处理HTTPS
  • 有Reachablity的API
NSURLSession/NSURLConnection

NSURLSession/NSURLConnection 都是基于CFNetwork的。

NSURLConnection - CFURLConnection的封装。提供了create,start,cancel,send(同步或者异步)，设置回调，设置runloop等函数。

NSURLSession/NSURLSessionTask - NSCFURLSession/NSCFURLSessionTask等等的封装。

NSURLXXX这一层主要处理了:

  • 把CFNetwork的blockhandler封装成delegate的方式
  • 处理NSURLProtocol相关的代理
  • 处理NSURLCache的缓存相关,是对CFURLCache的封装
  • 封装sendAsync/和sendSync方法。
  • 把CFURLResponse的statusCode转化成String
CFNetwork

CFNetwork 展示了如何把字节流封装成HTTP协议的请求收发。

[图片上传失败...(image-4f1c4b-1535019216015)]

  • CFURLRequest由用户创建，里面包括URL/header/body这些请求的信息。然后CFURLRequest会被转换成CFHTTPMessage的格式。
  • CFHTTPMessage里主要是HTTP协议的定义和转换，把每一个请求request转换成标准的HTTP格式的文本。
  • CFURLConnection 里主要是处理请求任务,包括pthread线程、CFRunloop,请求队列的管理等等。所以提供了start、cancel等等操作的api。也有操作CFReadStream等API
  • CFHost:负责DNS，在有CFHostStartInfoResolution等函数，基于dns_async_start和getaddrinfo_async_start方法。在iOS8/9基于getaddrinfo。主要是同步调用和异步调用的区别。
  • CFURLCache/CFURLCredential/CFHTTPCookie:处理缓存/证书/cookie相关的逻辑，都有对应的NS类。

主要的数据交换调用基于CFStream的API。

CFStream

借助CFSocketStream,封装BSD Socket,和SecurityTransport(SSL调用)。

由于BSD Socket都是同步调用。所以CFStream这一层主要是Runloop逻辑,锁,dowhile等待等等。 类似BSD socket一样是数据流输入/输出的API。

CFStream 创建时要传入一堆callback，包括open/close,read/write等等。比如CFSocketStream，封装了BSD Socket的作为callback传入CFStream。

CFSocketStream 也包括了DNS、SSL连接、Connect握手等等逻辑。

BSD Socket

有多组API，包括connect/shutdown,send/recv,read/write,recvfrom/sendto,recvmsg/sendmsg. 作为客户端一般不使用accept/bind.

send/recv和read/write的区别在于多了一个flags参数。当flag为0时，send等同于write。

对于发送消息。send只可用于基于连接的套接字，sendto 和 sendmsg既可用于无连接的socket，也可用于基于连接的socket。除了socket设置为非阻塞模式，调用将会阻塞直到数据被发送完。

DNS方法: getaddrinfo 是对 gethostbyname/gethostbyaddr 的替代，支持了ipv6，返回一个地址struct链表。在iOS8/9中使用。 getaddrinfo_async_start 在iOS10中使用，支持了异步。

监控什么

iOS-Monitor-Platform 这篇文章提出了一些监控指标(然而他提供的方法并不能监控到)。

  • TCP 建立连接时间
  • DNS 时间
  • SSL 时间
  • 首包时间
  • 响应时间
  • HTTP 错误率
  • 网络错误率
  • 流量

APM厂听云提供的一些监控指标:

  • TOP5 响应时间最慢主机
  • TOP5吞吐率最高主机
  • TOP5 DNS时间最慢地域
  • TCP建连最慢主机
  • 连接次数最多主机

HTTP抓包工具Charles提供的监控指标:

  • Request Start Time
  • Request End Time
  • Response Start Time
  • Response End Time
  • Duration
  • DNS
  • Connect
  • SSL Handshake
  • Latency

当然如果可行的话，想每一个细节都监控到。但是很多数据都有实现成本，本文用最低的成本力求收集尽可能多的指标。

具体实现

HTTP 的监控

HTTP的监控最佳的实践当然就是利用NSURLSession的NSURLSessionTaskMetrics。

[图片上传失败...(image-7b6c8-1535019216015)]

想探究NSURLSessionTaskMetrics的实现，如果反编译CFNetwork的源码，可以看到-[NSURLSessionTaskMetrics _initWithPerformanceTiming] 这个方法，说明是来自一个叫TimingPerformance的类。 TimingPerformance的初始化方法代码如下，可以看到这里定义了所有NSURLSessionTaskMetrics时间节点需要的key，几乎完全一致。然后初始化时利用CFAbsoluteTimeGetCurrent函数来记录初始化的时间。

int __ZN17PerformanceTimingC2Ev() {
    rbx = rdi;
    CFObject::CFObject();
    ...
    *(rbx + 0x20) = @"_kCFNTimingDataRedirectStart";
    *(rbx + 0x30) = @"_kCFNTimingDataRedirectEnd";
    *(rbx + 0x40) = @"_kCFNTimingDataFetchStart";
    *(rbx + 0x50) = @"_kCFNTimingDataDomainLookupStart";
    *(rbx + 0x60) = @"_kCFNTimingDataDomainLookupEnd";
    *(rbx + 0x70) = @"_kCFNTimingDataConnectStart";
    *(rbx + 0x80) = @"_kCFNTimingDataConnectEnd";
    *(rbx + 0x90) = @"_kCFNTimingDataSecureConnectionStart";
    *(rbx + 0xa8) = @"_kCFNTimingDataRequestStart";
    *(rbx + 0xb8) = @"_kCFNTimingDataRequestEnd";
    *(rbx + 0xc8) = @"_kCFNTimingDataResponseStart";
    *(rbx + 0xd8) = @"_kCFNTimingDataResponseEnd";
    *(rbx + 0xe8) = @"_kCFNTimingDataRedirectCountW3C";
    *(rbx + 0xf8) = @"_kCFNTimingDataRedirectCount";
    *(rbx + 0x108) = @"_kCFNTimingDataTaskResumed";
    *(rbx + 0x118) = @"_kCFNTimingDataConnectCreate";
    *(rbx + 0x128) = @"_kCFNTimingDataTCPConnected";
    *(rbx + 0x138) = @"_kCFNTimingDataFirstWrite";
    *(rbx + 0x148) = @"_kCFNTimingDataFirstRead";
    *(rbx + 0x158) = @"_kCFNTimingDataConnectionInit";
    *(rbx + 0x168) = @"_kCFNTimingDataConnected";
    ....
    *(rbx + 0x1f0) = @"_kCFNTimingDataTimingDataInit";
    ...
    CFAbsoluteTimeGetCurrent();
    ....
    return rax;
}
复制代码

这个类是怎么使用的呢，可以看到[NSCFURLSessionTask resume]这个方法里:

void -[__NSCFURLSessionTask resume](void * self, void * _cmd) {
    rbx = self;
            ...
            __setRecordForKeyInternalPerformanceTiming(@"streamTask-resume");
            r15 = rbx->_performanceTiming;
            if (r15 != 0x0) {
                    PerformanceTiming::Class();
                    xmm0 = intrinsic_movsd(xmm0, *(r15 + 0x110));
                    xmm0 = intrinsic_ucomisd(xmm0, 0x0);
                    if ((xmm0 == 0x0) && (!CPU_FLAGS & P)) {
                            CFAbsoluteTimeGetCurrent();
                            *(r15 + 0x110) = intrinsic_movsd(*(r15 + 0x110), xmm0);
                    }
            }
            __setRecordForKeyInternalPerformanceTiming(@"start-task-resume-to-loader-start-load");
              ...
    return;
}
复制代码

可以看到这里rbx寄存器存储的就是NSCFURLSessionTask对象，这个对象有一个成员变量就是_performanceTiming,放在r15这个寄存器里。上面的代码可以看到(0x108)对应的就是_kCFNTimingDataTaskResumed这个key，而这里xmm0寄存器是个浮点数存储的寄存器，存储的是(r15 + 0x110)，对应应该是，然后判断xmm0是否为空，如果是空的话，就调用CFAbsoluteTimeGetCurrent函数获取当前CPU时间，然后再赋给(r15 + 0x110)，对应的应该就是_kCFNTimingDataTaskResumed这个key对应的value。

至于__setRecordForKeyInternalPerformanceTiming 这个函数，可以看到它的key并不存在于PerformanceTiming对象初始化的时候，它应该是InternalPerformanceTiming，这是个不同的类，可能是PerformanceTiming的子类。他的key是不同的，判断是这个库内部使用的，并没有作为NSURLSessionTaskMetrics传递出去。

发现__ZN17PerformanceTiming32fillW3NavigationTimingAWDMetricsEP27PerformanceTimingAWDMetrics,__ZN17PerformanceTiming30fillStreamTaskTimingAWDMetricsEP26StreamTaskTimingAWDMetrics这两个函数，说明PerformanceTiming和W3NavigationTiming，以及StreamTaskTiming这几个东西的AWDMetrics是可以互相转化的。W3NavigationTiming很容易想到是用于WebView的Timing的API。

NSURLSessionTaskMetrics的优点是苹果帮咱实现了，但是有很严重的缺点是只能适用于iOS10以后的NSURLSession。NSURLConnection是用不了的。iOS10以下也是用不了的。 (见后文重大发现)

其它方案的分析

对于iOS10以下的NSURLSession以及NSURLConnection,想要打点统计时间点挺困难的，主要困难点在不同SDK的API调用不同,比如iOS8和9的DNS,可以hook到getaddrinfo函数,iOS10有时可以hook到getaddrinfo_async_start函数，但是对于iOS11，我尝试了各种跟DNS相关的函数，完全hook不到。反编译CFNetwok出来的跟DNS相关的函数，也都没有被NSURLSession/NSURLConnection调用。 SSL的情况也非常类似，目前只知道iOS8/9会通过SecurityTransport的SSLHandshake/SSLRead/SSLWrite等函数,但是iOS10以上就完全懵逼。这些尝试只能宣告失败，告一段落了。

有的文章认为是iOS10之后系统屏蔽了某些BSD Socket函数的hook,比如connect/read/write 等等。 据我观察并不是这样,BSD socket还是能够hook到，只是大部分情况下不调用这些API了，少数情况还是有使用的。 如果真的被屏蔽了，应该是完全hook不到的。

有些文章写了说监控HTTP，可以采用NSURLProtocol拦截请求的方式(比如听云)。我都是持怀疑态度的，因为监控性能，如果没有DNS/SSL相关的监控就失去了大部分意义，而监控request/response的就不需要用hook这种方式了(完全可以在自己封装的网络层部分实现)。 而针对于NSURL相关API的hook是统计不到DNS/SSL的，因为它们不在这一层实现。

也有些文章说hook CFStream的方式(比如网易APM)。 但是如果看到CFStream的实现就知道CFStream是对BSD Socket的封装，Open/Close/read/Write 如果看CFSocketStream的源码，这些API都还是BSD Socket实现的，就是说hook CFStream 和 BSD socket没有很大的区别。 还是没有hook到DNS/SSL的点上。

WebView 的监控

WebView的监控是相对简单的，主要是Timing API。

[图片上传失败...(image-56e48e-1535019216015)]

好处是兼容性很好，目前UIWebView和WKWebView都支持，iOS9以上都支持。因为是浏览器的API。

WebCore里，跟这个timing相关的API主要是PerformanceTiming类:

class PerformanceTiming : public RefCounted<PerformanceTiming>, public DOMWindowProperty {
public:
    static Ref<PerformanceTiming> create(Frame* frame) { return adoptRef(*new PerformanceTiming(frame)); }

    unsigned long long navigationStart() const;
    unsigned long long unloadEventStart() const;
    unsigned long long unloadEventEnd() const;
    unsigned long long redirectStart() const;
    unsigned long long redirectEnd() const;
    unsigned long long fetchStart() const;
    //...省略部分函数
    unsigned long long domContentLoadedEventStart() const;
    unsigned long long domContentLoadedEventEnd() const;
    unsigned long long domComplete() const;
    unsigned long long loadEventStart() const;
    unsigned long long loadEventEnd() const;

private:
    explicit PerformanceTiming(Frame*);
    const DocumentTiming* documentTiming() const;
    DocumentLoader* documentLoader() const;
    LoadTiming* loadTiming() const;
};

} // namespace WebCore
复制代码

头文件里有一堆getter函数的定义，同时初始化方法只有一个，入参是单一的Frame对象，说明一个Frame对象就能够提供到这些所有的参数。

unsigned long long PerformanceTiming::requestStart() const
{
    DocumentLoader* loader = documentLoader();
    if (!loader)
        return connectEnd();

    const NetworkLoadMetrics& timing = loader->response().deprecatedNetworkLoadMetrics();
    ASSERT(timing.requestStart >= 0_ms);
    return resourceLoadTimeRelativeToFetchStart(timing.requestStart);
}
unsigned long long PerformanceTiming::domInteractive() const
{
   const DocumentTiming* timing = documentTiming();
   if (!timing)
       return 0;
   return monotonicTimeToIntegerMilliseconds(timing->domInteractive);
}
unsigned long long PerformanceTiming::loadEventStart() const
{
    LoadTiming* timing = loadTiming();
    if (!timing)
        return 0;
    return monotonicTimeToIntegerMilliseconds(timing->loadEventStart());
}
复制代码

再看cpp文件就知道，PerformanceTiming是对Frame类中已经统计好的参数的一个封装，内部并没有逻辑。数据其实就是来自于NetworkLoadMetrics、DocumentTiming 和 LoadTiming 三部分。也很容易理解就是分别对应网络请求相关的性能统计、对应DOM加载相关的和WebView加载相关的性能统计。

有一个细节就是NetworkLoadMetrics里有0ms的判断，保证NetworkLoadMetrics返回的相关数据大于0。而DocumentTiming 和 LoadTiming返回的数据为空时就是0。实际上使用这一系列数据时确实会出现一部分参数为0的情况，而且跟调用PerformanceTiming的接口有关。

WebCore的类的架构如下图。 [图片上传失败...(image-449013-1535019216015)] 那WebView里，网络是怎么一层层调用的呢？ 追踪WKWebView的loadRequest:方法，调用栈应该是这样的:

- (WKNavigation *)loadRequest:(NSURLRequest *)request
void WebPage::loadRequest(const LoadParameters& loadParameters)
void UserInputBridge::loadRequest(FrameLoadRequest&& request, InputSource)
void FrameLoader::load(FrameLoadRequest&& request)
void FrameLoader::load(DocumentLoader* newDocumentLoader)
void FrameLoader::loadWithDocumentLoader(DocumentLoader* loader, FrameLoadType type, FormState* formState, AllowNavigationToInvalidURL allowNavigationToInvalidURL)
void FrameLoader::continueLoadAfterNavigationPolicy(const ResourceRequest& request, FormState* formState, bool shouldContinue, AllowNavigationToInvalidURL allowNavigationToInvalidURL)
void DocumentLoader::startLoadingMainResource()
void ResourceLoader::start()
void ResourceHandle::createNSURLConnection(id delegate, bool shouldUseCredentialStorage, bool shouldContentSniff, SchedulingBehavior, NSDictionary *connectionProperties);
复制代码

ResourceLoader是资源加载，而真正操作网络请求的类在ResourceHandle。看代码就发现WebCore的网络层在iOS上也是基于NSURLConnection的。可以通过AOP的方式hook到某个位置，然后使用NSURLConnection的API进行操作。

有一处比较有意思，WebCore中实现了一个NSURLSession，叫WebCoreNSURLSession。这个类似乎只在MediaPlayer里面使用。相同的是他们也有类似的API，比如dataTaskWithRequest:等等，但是内部实现不一样，WebCoreNSURLSession也是基于ResourceLoader的子类。而NSURLSession是基于CFNetwork。

使用Timing系列的API也有需要注意的细节。WebCore内核在iOS上和在Mac的Safari上是不一样的。iOS10以后的WKWebView才实现.toJSON()。如果是UIWebView，或者是iOS10以下的WKWebView，需要先执行一段js脚本，方便我们把js对象转换为json。

NSString *funcStr = @"function flatten(obj) {"
        "var ret = {}; "
        "for (var i in obj) { "
        "ret[i] = obj[i];"
        "}"
        "return ret;}";
[webView stringByEvaluatingJavaScriptFromString:funcStr];
复制代码

TCP的监控

一般App的网络层长连接，会基于TCP实现自定义的协议或者使用Websocket。有的app会基于BSD Socket封装(比如微信的mars)。有的会先利用一些开源的框架比如 CocoaAsyncSocket 或者 SocketRocket，然后再进行封装。

CocoaAsyncSocket

CocoaAsyncSocket是基于BSD Socket,CFStream,SecurityTransport的封装，封装成TCP/UDP协议。这几个API的共同之处在于都是数据流读写的形式。BSD Socket主要是同步阻塞，而CFStream是异步的。

既然是数据流读写，所以CocoaAsyncSocket肯定是包括数据流的处理和转换了。主要是缓冲区，ReadBuffer/WriteBuffer,判断读取的结尾CRLF, 读取的长度length和读取的超时机制等等。 CocoaAsyncSocket也封装了DNS、ipv4和ipv6、SSL等等逻辑。

SocketRocket

是基于NSStream 的封装，不同于CocoaAsyncSocket的传输层协议, 支持HTTP/WebSocket的应用层协议，定义了header的字段等等。 由于是基于数据流读写的，所以也包括readBuffer/WriteBuffer等数据处理逻辑。 也包括Runloop，线程等异步处理逻辑和阻塞同步逻辑。 还实现了PingPong这样的，跟服务端配合的保活逻辑。

所以TCP的监控可以hook BSD Socket 的API，包括 connect/disconnect/read/write等等调用，如果是同步调用，所以可以在执行函数前后埋点计算时间。 也需要hook DNS方面的API，比如 gethostbyname/getaddrinfo等同步调用的以及getaddrinfo_async_start等等异步调用的API。 也可以hook SSL 方面的API，比如 SSLHandshake/SSLRead/SSLWrite，实现对SSL连接的监测。

剧情反转，重大发现 (这一段是后来加的)

HTTP的性能监控因为NSURLSessionTaskMetrics的兼容性问题似乎已经穷途末路了，但是在写第二部分WebView的时候突然有了一个巨大的发现，这个发现来自于在看WebCore的源码的时候发现了一些神奇的东西。

#if !HAVE(TIMINGDATAOPTIONS)
void setCollectsTimingData()
{
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        [NSURLConnection _setCollectsTimingData:YES];
        ...
    });
}
#endif
复制代码

这是说NSURLConnection本身有一套TimingData的收集API，只是没有暴露给开发者而已，但是WebCore里一直在用...苹果你为啥这么小气？！ 然后就很轻易地在runtime header里找到了NSURLConnection的_setCollectsTimingData: API，还有_timingData的API。 这货iOS8以后都是支持的，iOS8之前也许也支持了。

那么NSURLSession呢，是不是也类似？果然。在iOS9之前，也只需要设置_setCollectsTimingData:就好了。 搜了一下google和github，我应该是第一个发现这个私有API的人...

所以很神奇地，很轻易地，就实现了NSURLConnection和NSURLSession全套的支持....

总结

我们几乎可以用很少的代码实现HTTP/WebView/TCP跨框架的大部分网络性能数据收集。如果把兼容性整理成一张表的话可以看到我们几乎支持了大部分的场景。

iOS SDKNSURLConnetionNSURLSessionUIWebViewWKWebViewTCP
8.4YESYESvia TCPvia TCPYES
9.3YESYESYESYESYES
10.3YESYESYESYESYES
11.3YESYESYESYESYES

NetworkTracker 是我封装的一部分代码。并将监控结果简单地画了个图表。还是比较直观的。

转载于:https://juejin.im/post/5c233a42518825079f7842eb

weixin_34226182
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
getaddrinfo函数
hjhomw的博客
04-11 446
getaddrinfo 函数允许将将一个主机名和一个服务名映射到一个地址。函数原型：#include <sys/socket.h> #include <netdb.h>int getaddrinfo(const char *restrict host, const char *restrict service, const struct addrinfo *restrict hint, struct
NetworkMonitor:iOS网络请求监控
05-07
NetworkMonitor 简介 NetworkMonitor主要用于监控应用的网络请求，获取网络请求相关的性能参数，方便开发、测试、产品等人员对应用进行分析。监控的指标主要有：成功率、状态码、流量、网络响应时间、HTTP与HTTPS的 DNS 解析、TCP握手、SSL握手（HTTPS）等。 NetworkMonitor的优点主要有： 收集数据全面。主要监控参数如上所述，基本涵盖了网络监控需求。 监控范围广。基本涵盖了应用层的网络请求，但是UIWebView/WKWebView除外，这个是后续开发方向。 接入使用方便。采用无埋点的数据收集方式，用户不需要手动埋点，接入只需要几行代码，即可收集基本数据。 可扩展性强。除了基本参数之外，用户还可以自定义扩展参数。 简洁轻量。SDK包大小不到0.5M，运行内存小，不挤占主应用资源。 数据准确度较高。SDK尽可能地使用了系统提供的数据，对于自己计
IOS 监听网络状态
KingToAce
01-05 2258
监听网络状态
iOS性能监控及自动化测试辅助工具对比-tidevice、py-ios-device（pyidevice）、sonic-ios-bridge（sib）
aovenus的专栏-测试新时代（微信公众号：测试新时代）
08-13 3376
iOS性能监控及自动化测试辅助工具对比-tidevice、py-ios-device（pyidevice）、sonic-ios-bridge（sib）
iOS 性能监控(1)——CPU、Memory、FPS
feelinghappy的专栏
12-22 4659
前段时间，在公司的 App 中集成了一个性能监视器，效果如下所示。在这个过程中，扒了一些性能监测开源框架的源码，并学习了其中的原理。本文就对此做一些简要的总结。 image 概述 通常情况下，App 的性能问题并不会导致 App 不可用，但是会潜在地影响用户体验。比如：CPU 占用率过高会导致电量消耗过快，手机发热等问题。为了能够主动、高效地发现性能问题，避免 App 质量进入无人监控的状态，我们需要对 App 的性能进行监控。目前，对 App 的性能监控，主要分为线下和线上两种监控维度。 ...
iOS APM监控总览
hnliuyiyun的专栏
06-29 3006
APP APM考察指标主要包含卡顿、网络、crash、耗电量、CPU使用率、内存消耗等几个方面
iOS集成-基调听云App性能监控
10-12
在iOS应用开发中，性能监控是一项至关重要的任务，它能够帮助开发者及时发现并解决应用程序中的各种性能问题，提升用户体验。基调听云提供的App性能管理产品就是这样一个工具，它通过集成SDK的方式，对App的崩溃、...
iOS监控编程
08-15
- 网络性能：监测网络请求的延迟、带宽使用和错误处理。 - 唤醒源分析：找出应用唤醒设备的频繁原因，优化电池寿命。 2. 编程技术： - Instruments工具：Apple提供的强大的性能分析工具，包含Leak、Time ...
移动端性能监控方案
08-22
据统计，有十种应用性能问题危害最大，分别为：连接超时、闪退、卡顿、崩溃、黑白屏、网络劫持、交互性能差、CPU 使用率问题、内存泄露、不良接口。 开发者难以兼顾所有的性能问题，而在传统的开发流程中，我们解决...
微信读书 iOS 性能优化总结 | WeRead团队博客1
08-04
业务性能监控通过在应用中关键业务的开始和结束处添加打点，收集数据进行后台分析，以便发现性能瓶颈。卡顿监控则分为两种主要方法：主线程卡顿监控和FPS监控。主线程卡顿监控通过监测主线程runLoop的状态，判断是否...
ffmpeg/libavformat/tcp.c中getaddrinfo在IOS下的问题
SaunterCloud的专栏
05-28 896
IOS的播放器用了ffmpeg 3.1 , 发现不支持ipv6  跟踪到ffmpeg/libavformat/tcp.c下的getaddrinfo函数， 发现执行完之后，如果是由ipv4合成ipv6的时候,会把端口设成0 所以，执行完这一句，把得到的地址，重新赋值上端口，ipv6就支持了  为了同时支持ipv4和ipv6,所以getaddrinfo的hint的ai_family填的
iOS-Monitor-Platform, iOS 性能监控 SDK —— Wedjat（华狄特）开发过程的调研和整理.zip
09-16
iOS-Monitor-Platform, iOS 性能监控 SDK —— Wedjat（华狄特）开发过程的调研和整理.zip
DetoxInstruments：iOS测试和性能监控的利器
最新发布
gitblog_00022的博客
04-14 307
DetoxInstruments：iOS测试和性能监控的利器 项目地址:https://gitcode.com/wix-incubator/DetoxInstruments DetoxInstruments 是由 Wix 开发的一个开源项目，它为 iOS 应用开发者提供了一套强大的工具，用于实时测试、性能监控和调试。通过直观的 UI 和深入的数据分析，你可以更好地理解和优化你的应用在运行时的行为。...
sonic-ios-bridge（sib）性能监控
aovenus的专栏-测试新时代（微信公众号：测试新时代）
09-07 882
使用sonic-ios-bridge（sib）对iOS app进行性能监控
检测iOS手机端时间准确性方法
归零者的博客
06-01 689
原理:通过获取服务端的时间, 来跟手机系统时间进行对比, 来检查本地时间的准确性.如何方便和相对准确的, 随时获取服务端时间?(默认服务端时间是准确的, 或者你选择时间准确的服务器来获取时间)
NSURLSession最全攻略
SOHU_TECH的博客
03-12 1057
本文字数：11276字预计阅读时间：32分钟NSURLSessionNSURLSession在iOS7中推出，NSURLSession的推出旨在替换之前的NSURLConnection...
查看ios 应用程序性能
m0_74760716的博客
12-29 545
本篇博文将介绍一款重量级性能测试工具——克魔助手，针对iOS应用程序的性能监控进行详细介绍。通过克魔助手，开发者可以方便地查看应用程序的CPU、内存、GPU性能情况，以及网络监控和抓包等功能，帮助优化应用的性能。本文将重点介绍克魔助手的各项性能监控功能，并附带示例截图，帮助读者更好地了解和使用该工具。软件的性能是评价一个软件质量的重要指标，尤其在今天这个时代，性能已成为大型项目不可或缺的考虑因素之一。对于用户量极大的软件，如网银系统、在线购物商城等，更是必须保证其高效稳定的性能。
ios 网速监控_iOS_实时监测网络变化
weixin_28406969的博客
01-14 1160
一、概述在开发中, 实时监测网络变化有时候是有必要的, 好处啥的就不用说了.网上类似的文章还是不少的, 但对方法种类的总结还是不够齐全, 这里本猿就勉为其难的搞搞自认为比较齐全的;目前来说, 实时检测网络变化的方法主要有四个, 分别是:Reachability --- 苹果官方的AFNetworkReachabilityManager ---- AFNetWorking自带的第三方框架检测状态...
美团移动端性能监控方案：实时优化与内部实践
美团的内部分享提供了一套移动端性能监控方案，该方案针对iOS平台，旨在帮助开发者预防和解决常见的性能瓶颈。 方案的核心关注点包括： 1. 关键性能指标：例如CPU使用率、帧速率（FPS）等，这些是衡量应用运行效率...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值