问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
请求同一个接口的数据，我现在是第一个请求成功后请求下一个，有没有其他更快的方法呢?网上说可以自定义几个串行队列，并发执行？求方法。谢谢
-(void)requestfilterData:(NSString *)item
NSString *urlStr = [NSString stringWithFormat:@"%@/api/product/filter/list?filtername=%@" ,SERVER_ADDRESS,item];
NSURL *url = [NSURL URLWithString:urlStr];
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:60];
[request setHTTPMethod:@"GET"];
[NSURLConnection sendAsynchronousRequest:request queue:[[NSOperationQueue alloc]init] completionHandler:^(NSURLResponse *response, NSData *data, NSError *connectionError) {
if (connectionError) {
NSLog(@" good commet list recv data error");
[self receivedfilterConditionsReturnJSON:data];
-(void)receivedfilterConditionsReturnJSON:(NSData *)data
NSError *localError =
id parsedObject = [NSJSONSerialization JSONObjectWithData:data options:NSJSONReadingMutableContainers error:&localError];
if (localError != nil) {
NSLog(@"sport train filter list
JSON data error: %@", [localError description]);
NSDictionary *recvDic = (NSDictionary *)parsedO
//接收商品评论数据
NSString *result =
[recvDic objectForKey:@"result"];
if ([result isEqualToString:@"1"]) {
dispatch_async(dispatch_get_main_queue(), ^{
[self showItemController:recvDic];
需求：实在页面出现的时候，要根据参数分三次调用这个接口（服务端就是这么设计的，并不是一次返回了）。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
谢邀。第一次被邀请 必须好好回答。
建议阅读同步与异步
看了下您的问题，但是总觉得你对同步和异步的理解有差(可能是我看错了)，但是我建议首先阅读下这篇文章
虽然讲的是如何使用，但是作者很好的诠释了同步和异步的区别，也有实际例子来阐述两者。
建议阅读－NSOperationQueue
有了同步与异步，那么解决这个问题还需要多线程和队列的知识，阅读下下面的链接
楼主的问题解析
楼主可否思考下，如何将上面的两者结合下，运用于自己的程序中？
思路一:直接多线程执行...
这里我们使用上面我提到的［NSURLConnection的使用］的代码为例子，github地址： 请自己下载下来
//ViewController.m中的viewDidLoad
- (void)viewDidLoad
[super viewDidLoad];
[self fetchAppleHtml];
[self fetchYahooData];
[self fetchYahooData];
[self fetchYahooData2_GCD];
[self fetchYahooData2_GCD];//连续两次运行试一下，看下打印的信息
[self httpGetWithParams];
思路二:队列执行网络层...
与第一种差不多，但是是在网络请求内容执行队列
写了那么多，不知道是不是回答道重点上了。
我没有亲自试，所以题主测试下，我可能理解有偏差，见谅。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
可不可以解释一下，你为什么要对这三次请求与响应做同步处理？
一个请求的发出依赖另一个跟它同类请求的响应，会造成这种情况，给人第一感觉是设计有问题啊。
我没看懂你的问题，只能凭直觉猜测一下你想干什么。我的直觉是你只是想在回调方法里知道请求是谁发的。。。我猜我是理解错了。。不能是这么简单的问题吧。。
有人看懂问题了吗？
顺便建议用NSURLSession代替NSURLConnection，如果不需要兼容7.0之前的设备的话。
-(void)requestfilterData:(NSString *)item requestCode:(int)requestCode
NSString *urlStr = [NSString stringWithFormat:@"%@/api/product/filter/list?filtername=%@" ,SERVER_ADDRESS,item];
NSURL *url = [NSURL URLWithString:urlStr];
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:60];
[request setHTTPMethod:@"GET"];
[NSURLConnection sendAsynchronousRequest:request queue:[[NSOperationQueue alloc]init] completionHandler:^(NSURLResponse *response, NSData *data, NSError *connectionError) {
if (connectionError) {
NSLog(@" good commet list recv data error");
[self receivedfilterConditionsReturnJSON:data requestCode:requestCode];
-(void)receivedfilterConditionsReturnJSON:(NSData *)data requestCode:(int)requestCode
NSError *localError =
id parsedObject = [NSJSONSerialization JSONObjectWithData:data options:NSJSONReadingMutableContainers error:&localError];
if (localError != nil) {
NSLog(@"sport train filter list
JSON data error: %@", [localError description]);
NSDictionary *recvDic = (NSDictionary *)parsedO
//接收商品评论数据
NSString *result =
[recvDic objectForKey:@"result"];
if ([result isEqualToString:@"1"]) {
switch(requestCode)
case REQUEST_0:
case REQUEST_1:
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
想了好久还是使用了dispatch_group_t,多路执行后收到通知再执行UI操作，然后，调用的接口我改成了同步请求，（异步也可以吧，需要在创建一个NSOperationQueue）本身dispatch_get_global_queue就是异步了，在开一个感觉没必要）
dispatch_group_t group =
dispatch_group_create();
dispatch_group_async(group, dispatch_get_global_queue(0, 0), ^{
[self requestfilterData:@"location"];
dispatch_group_async(group, dispatch_get_global_queue(0, 0), ^{
[self requestfilterData:@"age"];
dispatch_group_async(group, dispatch_get_global_queue(0, 0), ^{
[self requestfilterData:@"item"];
dispatch_group_notify(group, dispatch_get_global_queue(0, 0), ^{
//汇总结果
dispatch_async(dispatch_get_main_queue(), ^{
//同步请求数据
-(void)requestfilterData:(NSString *)item
NSString *urlStr = [NSString stringWithFormat:@"%@/api/product/filter/list?type=%ld&filtername=%@" ,SERVER_ADDRESS, (long) self.type, item];
NSURL *url = [NSURL URLWithString:urlStr];
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:60];
[request setHTTPMethod:@"GET"];
NSURLResponse *response =
NSError *error =
NSData *data =[NSURLConnection sendSynchronousRequest:request returningResponse:&response error:&error];
if (error) {
NSLog(@" good commet list recv data error");
[self receivedfilterConditionsReturnJSON:data withCode:item];
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
自己实现一个队列管理，完成之后在进行下一个。如果要精确控制的话，可以看看asi框架的 queue代码。
同步到新浪微博
分享到微博？
你好！看起来你挺喜欢这个内容，但是你还没有注册帐号。 当你创建了帐号，我们能准确地追踪你关注的问题，在有新答案或内容的时候收到网页和邮件通知。还能直接向作者咨询更多细节。如果上面的内容有帮助，记得点赞 (????)? 表示感谢。
明天提醒我
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：18117人阅读
App接口设计与开发（32）
最近接触到了移动端API开发的问题，为了确保应用与API 服务器之间的安全通信，防止数据篡改等恶意攻击，和同事探讨出此验证方法：
首先向移动端应用分配APP_ID(int) ,APP_KEY（32位随机字串）,移动端利用APP_ID 与 APP_KEY向服务器端请求，服务器端判断该应用是否合法；
应用合法则生成临时Token返回给(Token有效期默认3600s),服务器端该T
应用每次向接口请求数据都必须将Token与APP_ID一同请求，端进行Token验证。
APP应用& ------请求指定接口(APP_ID,APP_KEY)获取Token--------&生成Token接口(首先判断Token是否存在,存在则直接返回,不存在创建后返回给应用)
APP应用 -------请求相应功能接口(APP_ID, Token,...其他参数)-----&执行相应功能接口(Token有效期延长3600s)
APP应用--------获取Token一小时后请求---------------------------------&由于Token过期,验证无法通过,需调用相应接口重新请求新Token
这只是个简单的Api安全通信验证,对要求较高的应用此验证方法还有很多不妥，如果大家有更好的API验证方法，欢迎吐嘈。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：3325748次
积分：20965
积分：20965
排名：第359名
原创：25篇
转载：808篇
评论：898条
(26)(1)(5)(3)(74)(30)(126)(18)(3)(1)(3)(7)(16)(43)(1)(5)(2)(2)(1)(18)(6)(3)(27)(10)(7)(6)(2)(7)(8)(1)(6)(27)(22)(9)(29)(30)(42)(19)(34)(10)(27)(83)(17)(17)铜币96068两
威望1977点
贡献99634点
阅读：13724回复：85
移动端如果开放h5，各位都需要有哪些接口？
发布于： 14:07
亲们，做个统计：
如果移动端开放h5，各位亲们都需要有哪些接口？
回帖跟进哈，期待大家的反馈~~
最新喜欢：
需要插件与模板就到/products/?tag=phpwind
PW moblie内测组
发布于： 14:13
短信。。。 不解释 地方站！
铜币96068两
威望1977点
贡献99634点
发布于： 14:15
：短信。。。 不解释 地方站！ ，正恩速度~
需要插件与模板就到/products/?tag=phpwind
PW moblie内测组
<span class="lou J_floor_copy" title="复制此楼地址"
data-hash="read_楼#
发布于： 14:16
：，正恩速度~ ios 放点 截图出来！ 你看大家急的！ 好歹你们最近加加班吧，加班有加班工资不？
铜币96068两
威望1977点
贡献99634点
<span class="lou J_floor_copy" title="复制此楼地址"
data-hash="read_楼#
发布于： 14:18
楼不要歪了~~
需要插件与模板就到/products/?tag=phpwind
<span class="lou J_floor_copy" title="复制此楼地址"
data-hash="read_楼#
发布于： 14:38
希望能自主引入第三方sdk，以便增加个性化功能
铜币96068两
威望1977点
贡献99634点
<span class="lou J_floor_copy" title="复制此楼地址"
data-hash="read_楼#
发布于： 14:44
继续继续~~其他亲呢？都午睡了？
需要插件与模板就到/products/?tag=phpwind
PW官方团队
<span class="lou J_floor_copy" title="复制此楼地址"
data-hash="read_楼#
发布于： 14:45
：ios 放点 截图出来！ 你看大家急的！ 好歹你们最近加加班吧，加班有加班工资不？ 你听说过互联网公司加班有加班费？你要是知道这类公司告诉我一下，我过去
PW moblie内测组
<span class="lou J_floor_copy" title="复制此楼地址"
data-hash="read_楼#
发布于： 14:59
：你听说过互联网公司加班有加班费？你要是知道这类公司告诉我一下，我过去
我这有！ 本地互联网公司！
<span class="lou J_floor_copy" title="复制此楼地址"
data-hash="read_楼#
发布于： 15:57
用户被禁言,该主题自动屏蔽!
铜币96068两
威望1977点
贡献99634点
<span class="lou J_floor_copy" title="复制此楼地址"
data-hash="read_楼#
发布于： 16:14
这个调查关乎到咱移动端未来的发展方向，大家积极反馈下哦。。
需要插件与模板就到/products/?tag=phpwind
<span class="lou J_floor_copy" title="复制此楼地址"
data-hash="read_楼#
发布于： 16:16
常见的api肯定都要开啥。。。用户模块；帖子数据；积分系统；等等这些基本API最好是都有。
铜币96068两
威望1977点
贡献99634点
<span class="lou J_floor_copy" title="复制此楼地址"
data-hash="read_楼#
发布于： 16:27
：常见的api肯定都要开啥。。。用户模块；帖子数据；积分系统；等等这些基本API最好是都有。 恩呢，越详细越好撒~~
需要插件与模板就到/products/?tag=phpwind
<span class="lou J_floor_copy" title="复制此楼地址"
data-hash="read_楼#
发布于： 16:42
我是技术白痴，不知道什么意思。只会用。能有投票啊，售卖系统啊什么的就更好了。可以丰富移动段的使用场景的接口功能。毕竟现在纯内容真的太难了。
PW moblie内测组
<span class="lou J_floor_copy" title="复制此楼地址"
data-hash="read_楼#
发布于： 16:55
：常见的api肯定都要开啥。。。用户模块；帖子数据；积分系统；等等这些基本API最好是都有。 无用！ &现在要丰富论坛 必须要的是 互动投票 图片类的！
您需要登录后才可以回帖，&或者&
Powered by频频卡顿崩溃？移动应用如何跟踪定位性能问题
发表于 12:55|
来源中国财经网|
作者中国财经网
摘要：更新迭代越快，应用存在的性能问题就越突出，性能问题造成业务下降影响已经占到25%甚至更多，应用本身的变革迫在眉睫。
& & &百年前，人们获取信息的方式是通过书籍、报纸；十年前，人们获取信息的方式是通过PC、互联网；如今，在移动互联网高速发展的环境下，人们获取信息的方式已经全面转向了小小的手机。短短几年里，移动互联网已经与我们的生活形影不离，一部手机走天下不再是梦想。
& & 移动应用的商业价值在互联网时代发生了变化，越来越多企业通过移动应用为用户提供服务，应用改变了商业世界。2016年Q1，用户从iOS和Android应用市场下载的应用数量高达172亿个，94%的应用以火箭般的速度进行更新。更新迭代越快，应用存在的性能问题就越突出，性能问题造成业务下降影响已经占到25%甚至更多，应用本身的变革迫在眉睫。
& & 透视宝mobile APM 从五个维度解析移动应用性能
& & 移动应用发布上线之后，由于缺少有效的性能监控手段，对于开发和运维来说其架构、应用、程序代码的执行情况都是一个黑盒，无法感知到用户使用APP的真实感受，无法预知应用发生了什么样的问题，看不到业务具体数据到底是怎么执行，更没办法准确定位到问题，而APM通过以下五个重要维度能够帮你把黑盒子打开。
& & 1、 用户从哪来，网络接入性能怎么样？
& & 地域分析可以了解我们的用户都是从哪些地域使用APP，各地的响应时间是否存在很大差异，耗时较高的地区根据网络节点调整CDN，优化网站层面的性能问题。
& & 2、 用户使用的什么设备，不同运营商对网络响应是否达标？
& & 设备、运营商、APP版本分析可以帮忙了解用户使用什么品牌的手机访问APP应用，不同的终端存在不同的差异，据统计iPhone6 使用较为稳定，而华为设备发生崩溃几率最低，通过这些设备、运营商、APP版本的分析结果可以在新版本迭代中安排重点测试和适配。
& & 3、用户做了什么操作，在APP中的用户体验如何？
& & 用户行为监控能够将所有用户在APP中的点击操作与性能数据关联，通过HTTP请求响应耗时，请求错误，崩溃等维度分析APP中最影响用户体验的用户行为。并且可分析受到影响的每一位用户的在APP中行为操作路径及流程，协助研发人员还原用户使用场景从而精准定位问题发生的原因。
& & 4、APP中是否发生了崩溃、ANR等问题？
& & 崩溃是APP应用中最影响用户体验的问题之一，而且是移动开发者最大的痛点，所以收集崩溃日志、快速定位问题根源是最好的解决办法。崩溃分析可按APP版本，崩溃趋势，设备型号，运营商，接入方式，地域崩溃等多个维度分析和统计。
& & 崩溃分析可以解析崩溃堆栈定位发生崩溃的代码片段和行数，并且通过收集分析用户发生崩溃的设备，接入方式，内存，CPU使用率以及用户操作的行为轨迹助研发人员能快速定位问题，还原案发现场。
& & 5、APP前端页面交互性能和Service端代码执行效率
& & APP中的性能问题大体可以分为两部分：1、前端页面交互性能 2、后端Service端代码效率。
& & 前端页面交互性能主要体现在页面加载缓慢，请求错误异常，卡顿等方面，而目前webview在APP开发中已经非常普遍，对性能的监控需求也越来越强烈。我们提出白屏时间、页面请求耗时分解、页面加载资源耗时分解等性能指标，可以对页面请求耗时诊断慢在哪个环节。
& & 面响应时间分解，将整个H5页面加载的耗时分解到网络请求的每一个细节上去。如上图主要包括：重定向起止时间、缓存起止时间、域名解析起止时间、TCP传输起止时间、请求起止时间、响应起止时间、Dom加载起止时间、页面渲染起止时间等。&
图：H5页面加载的资源时序图，明确告知每一个资源类型的加载时间。
& & APP端除了前端的性能问题需要关注，Service端的性能问题同样不容忽视，由于篇幅问题本文不做重点介绍，但是需要介绍mobile端与service的端到端的特性。
& & 端到端事务分析
& & 针对移动端的事务我们可以诊断定位到耗时情况，除了前端页面的资源加载占用大量资源外，Service代码造成缓慢的因素同样需要准确定位，所以透视宝提供了端到端事务分析。
& & 移动端嵌入SDK，Service端部署Smart Agent，通过UUID关联了APP中所有的请求事务，定位后端的代码执行最慢的方法，SQL语言，参数等指标。
& & 针对HTTP的网络数据收集主要分为以下指标：请求时间、网络吞吐量和网络错误，劫持分析等。
& & 请求时间是指一个http请求从发起请求到接收到服务端的响应，这期间所经历的时间。这个指标可以跟踪后台接口的响应是否正常，网络环境是否正常。
& & 网络错误主要是跟踪url请求过程中的错误，分为http本身的错误和因网络状况出现的错误。
& & 某个客户的一个杭州用户在6分钟内发起了5800多次请求，请求错误率高达98%以上。当时他们不相信那是真实的，后来与客户交流发现该网络请求接口存在循环调用，请求接口在请求成功之前会一直循环调用，直到请求成功或是断网，而这正是造成导致循环请求的真正原因。
& & 还是这个客户，我们通过Smart SDK发现他的很多API报错是找不到主机，经确认APP开发在版本迭代过程中把很多接口废弃了，但客户端还在调用，通过HTTP错误和网络错误请求分析就可以帮助客户清理废弃的API，保证我们的业务正常服务。
& & 而做到这一切，只需要嵌入透视宝Smart SDK的两行代码， 5分钟轻松实现对APP应用的性能监控，业务运营监控的需求。以往通过用户投诉和反馈，开发总是最后一个发现问题，而被动的解决问题更是费时费力。使用透视宝后可以提前发现应用性能问题，快速迭代修复问题，避免用户流失提升用户体验。
& & 移动端性能管理技术实现
& & 透视宝Smart SDK自动收集性能数据是不需要埋点的。iOS和Android由于平台的差异性实现方式是不同的。Objective-C语言具有动态运行时的特性，因此iOS平台使用Hook机制来拦截方法的执行，从而收集性能数据；而Java语言不具备这样的特性，但能够对字节码进行改写，因此Android平台使用ASM框架动态注入代码到相关的方法中收集性能数据。
& & iOS&Smart SDK技术原理
& & iOS的Hook技术使用Objective-C提供的Method Swizzling机制。Method Swizzling是Objective-C的运行时技术，指的是改变一个已存在的选择器对应的实现的过程，它依赖于Objectvie-C中方法的调用能够在运行时进行改变&&通过改变类的调度表（dispatch table）中选择器到最终函数间的映射关系。
& & 原理图如下：
& & 每一个Selector（选择器）对应一个IMP（实现体），通过Method Swizzling可以动态改变这种对应关系。Swizzling通常被程序开发认为是一种巫术，容易导致不可预料的行为和结果。但是如果采取下面这些措施，Method Swizzling还是很安全的：
& & 1、Swizzling应该在+load方法中实现。
& & Objective-C中每个类都有+load和+initialize两个方法。这两个方法会被Objective-C运行时系统自动调用，+load是在一个类最开始加载时调用，+initialize是在应用中第一次调用该类或它的实例的方式之前调用。这两个方法都是可选的，都是只有实现了才会被执行。
& & 因为method swizzling会影响全局，所以减少冒险情况就很重要。+load能够保证在类初始化的时候就会被加载，这为改变系统行为提供了一些统一性。但+initialize并不能保证在什么时候被调用&&事实上也有可能永远也不会被调用，例如应用程序从未直接的给该类发送消息。
& & 2、Swizzling应该在dispatch_once中实现。还是因为swizzling会改变全局，我们需要在运行时采取所有可用的防范措施。保障原子性就是一个措施，它确保代码即使在多线程环境下也只会被执行一次。GCD中的diapatch_once就可以提供这些保障。
& & 3、始终调用方法的原始实现。系统提供的&API为输入和输出提供规约，但它里面具体的实现其实是个黑匣子，在Method Swizzling过程中不调用它原始的实现可能会破坏一些私有状态，导致程序运行不稳定。
& & Android&Smart SDK技术原理
& & 首先来看看Android app的打包流程
& & 该图翻译成技术语言，如下图
& & 图中标明了sdk中代码的工作位置：
& & 就是在 .class文件转化成.dex文件的过程中，通过ASM框架改写代码的。通过对字节码的读写，找到感兴趣的方法，加入收集信息的代码。原生的网络请求、用户行为、页面加载等方面的性能数据，就是以这样的方式收集到的。
& & 透视宝端到端技术方案重点不在移动端，而在于后端。移动端只是针对从APP中发出的每一条网络请求打上标记，后端节点上的Agent接收到该条请求，解析标记，记录下来，并且打上该节点的标记。最终通过这些标记画出该条请求所经过的所有节点的拓扑图，将节点上的应用的性能指标关联起来。
& & 崩溃信息收集和分析
& & iOS的崩溃信息收集和分析原理
& & 崩溃信息收集，通过系统提供的异常信息捕获接口，设置回调函数，捕获异常信息。通过解析解码文件，将解码文件与崩溃信息里的内存地址结合起来，分析出发生崩溃的位置和代码段
& & 通过设置系统异常信息收集的回调函数到系统相应的接口上，捕获系统的异常信息。
& & 崩溃信息解析过程：
& & 1、& 从崩溃日志中获取代码行的地址偏移量。（已从前面的崩溃信息中获取到）
& & 1、& 解析符号表文件dSYM, 使用dwarfdump命令从dSYM文件中抽取相关信息。比较常用的两个命令：
& & dwarfdump -e --debug-info YourPath/YourApp.dSYM/Contents/Resources/DWARF & info.txt
& & dwarfdump -e --debug-line YourPath/YourApp.dSYM/Contents/Resources/DWARF & line.txt
& & 其中，info.txt文件中包含类文件的具体信息，比如类名，方法名，方法的内存起止地址等。
& & 如下图所示：
& & 由图中可知，只要偏移量在0x和0x之间的代码，就对应JKBOverviewVC.m文件的 -[JKBOverviewVC&tableView:cellForRowAtIndexPath:]函数。
& & 具体崩溃在该函数的哪一行，通过line.txt文件中的内容得出
& & line.txt文件中，包含函数中每一行代码的内存地址对应的相关信息，如下图所示
& & 崩溃日志中，偏移量在0x和0x之间的代码，在这个line.txt文件中就能找到具体的代码行。至此，iOS的崩溃日志就分析完成了。
& & Android的崩溃收集原理
& & 1.&&&&&& Java层的崩溃信息收集原理，如下图所示：
& & Java 层的堆栈信息收集是通过定义一个Handler类去实现Thread.UncaughtExceptionHandler接口的void uncaughtException(Thread t, Throwable e)方法，然后，通过在Thread.setDefaultUncaughtExceptionHandler方法将我们定义的Handler和APP的线程关联起来。在uncaughtException方法中去收集APP 没有捕获的异常，然后将其堆栈信息收集起来。
& & 2.& Native层的崩溃信息收集原理，如下图所示：
& & 由于Android 底层使用的是linux内核，所以Native层先通过sigaction()函数去注册我们需要监视的Crash相关的信号量，同时，修改相关信号量发生的回调函数，在回调函数中我们通过Android的libcorkscrew.so(5.0版本以下) 和 libunwind.so(5.0及以上版本)提供的打印堆栈函数去收集Native层的堆栈信息，然后通过JNI层回调到Java层，从而收集到native的信息和Java层当前的所有线程信息。
& & H5页面的性能数据收集方案
& & H5页面的性能数据采集通过注入js代码来实现的。移动端的H5页面展示过程，主要分为数据请求、数据加载、页面渲染等。而其中数据加载是将H5页面的数据从服务端一段一段的load到移动端，JS代码的注入就是在这个阶段完成的。
& & 在数据load阶段注入js代码，待数据load完成之后渲染，这样做既不会影响客户代码的执行，也能保证JS代码能够监控H5页面的整个生命周期中的用户操作和页面加载情况。
& & 由于移动端操作系统对webkit进行了高度封装，开放出来的API还少，以致不能获取H5页面的详细加载情况，只能借助于JS代码，获取页面的performance参数，从而获取到页面加载的各个性能指标。
原文链接：
声明：CSDN登载此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章