蜻蜓FM陷“造假门”，网络电台掀互黑撕逼大战
&&发布于& 08:21
浏览(258)|回应(0)
来源：寻找中国创客作者：曾庆雪近日，蜻蜓FM被曝数据造假的新闻甚嚣尘上。网络红人王思聪也加入骂战，称“蜻蜓FM老板应该坐牢”。不过蜻蜓FM回应称，一切都是竞争对手的恶意抹黑。这并不是网络FM第一次陷入口水战。2015年4月，包括多听、荔枝、蜻蜓、喜马拉雅等多家网络FM就曾因版权等问题互相攻讦。分析指出，网络FM行业竞争激烈，盈利一直是难题，前期通过烧钱积累大量用户，但商业模式尚未成型。如果不能解决变现问题，竞争只能是一场零和博弈。网络FM双11节前开撕 双方针锋相对11月9日，蜻蜓FM被爆数据造假。文章称，蜻蜓FM通过一个名叫“普罗米修斯”的后台程序，伪造日活；并用一个“宙斯”程序，用看不见的浏览器打开广告主的网站，用程序模拟用户行为点击，消耗用户电量和流量，欺骗广告商和投资人。媒体随后的报道，将曝光蜻蜓FM造假的信息源指向喜马拉雅。竞争对手之间的攻讦公开化。蜻蜓FM在回应中称，“文中所提到的‘普罗米修斯’是蜻蜓FM用来在新功能上线时进行AB对照测试、统计相关用户指标，以便产品决策的技术框架，事实上专业人士可以轻易的发现此文刻意忽略了其中关键的几处逻辑判断，从而把读者导向伪造日活的错误结论中。”喜马拉雅随即提出质疑，“普罗米修斯”这个后台程序，将数据发送给友盟等第三方数据监测平台，导致第三方数据监测平台将“当天未打开App的用户”记录成活跃用户；“宙斯”模拟用户访问广告链接，导致广告的展示量和点击量虚假提升，并且导致用户手机耗电异常，并非简单的A/Btest。蜻蜓FM则表示，网上传播的所谓广告刷量代码，其实是用于数据比对和验证的技术方法。原因是因为目前第三方广告监测平台众多，各家的广告监测代码格式都不一样。而Android系统又具有严重的碎片化问题。在做一些广告平台的对接时，真实用户环境下的测试和验证显得非常必要。双方的系统联调以及数据对比，对损耗误差调校是一个常规过程。有传闻称，喜马拉雅发难，正值蜻蜓FM下一轮融资的关键时期。据一匿名业内人士透露，喜马拉雅目前也在寻求下一轮融资。数据造假不少见 甚至成行业潜规则有业内人士对寻找中国创客（ID：xjbmaker）表示，使用非正常的程序逻辑来伪造用户活跃和流量的做法，在业内并不少见，甚至成为行业的潜规则。而自启动的问题，在安卓系统更容易实现，“IOS系统控制要严格，像自启动这种事情，iOS干不了。”网络工程师、知乎网友“狂男风”称，对用户而言，不断自启本身没什么大问题，国内很多厂商都会添加相互唤醒进程和线程以保持后台的组件，其绝大部分用途都是用来维持网络推送。有的时候，应用为了维持后台推送不被杀掉，开发商会采用不断重启这一策略。因为在安卓的机制中，新启动的进程拥有较大优先级，往往在内存紧张的时候能够免于被系统杀掉（再搭配一些唤醒机制就能“永活”），所以大家都在拼命常驻后台。另一位网友则称，今天刷完知乎马上打开应用管理看看哪个app后台运行了多个进程……然而……喜马拉雅才打开三分钟就三个进程了，而且杀掉还自动重启。试了一下，别的程序也一样，运行多个进程而且杀不掉。是通病吗？一家第三方监测平台的CEO告诉寻找中国创客（ID：xjbmaker），反造假难度很高，“在线广告反作弊做了那么多年，到现在哪家广告网络也不能说自己找出了所有作弊的流量。在博弈的过程中，双方的能力都会不断增强。”这位CEO称，第三方监测机构只是提供工具的公司，没办法控制开发者。“就好像一个生产菜刀的公司，有人拿菜刀去杀猪，有人拿菜刀去杀人。作为菜刀公司，是没法，也负不了责任的。”网络FM盈利难 恶性竞争频现口水战的背后，是整个行业的困境。目前网络电台内容模式主要分为PGC和UGC两大类。PGC内容来自电台、电视台等机构，UGC内容主要来自用户。无论哪种方式，网络FM普遍存在同质化、模式单一、盈利水平低的问题。音频和视频一样，盈利是建立在用户增长与活跃的基础上。用户增长需要巨额的营销开支。喜马拉雅电台创始人余建军就曾公开表明态度：“这个行业肯定很烧钱，我们已经准备好了。” 蜻蜓FM的CEO杨廷皓也曾说：“移动电台还远不到谈盈利的时候。”烧钱需要资本的支持。2014年，蜻蜓FM、考拉FM、喜马拉雅听书、荔枝FM、多听、优听等移动网络电台纷纷先后完成融资。公开消息显示，喜马拉雅的B轮融资高达5000万美元，荔枝FM的C轮融资为2000万美元，考拉FM的B轮融资达到2亿人民币，蜻蜓也于2015年初完成了C轮融资，但金额未透露。网络分析师王亚谦称，平台无二大，把别的竞争打死打死是件必要的事情。背后有投资人支持的网络FM，不缺现金流，为了获得份额频频出招，有时甚至陷入恶性竞争。早在2015年4月，多听FM和荔枝FM两款网络电台APP突然被App Store下架，两家公司一起将矛头不约而同地对准喜马拉雅FM，指责其是幕后黑手。随后，蜻蜓FM也卷入骂战，诸如“产品抄袭”、“内容侵权”、“排行榜造假”等问题被曝光，网络FM行业一团浑水的业态，首次遭遇公开。据第三方监测机构，截止到日，蜻蜓FM累计下载量以16713万次位列第一，考拉FM电台排名第二，下载量为13606万次，喜马拉雅听书以12290万次排在第三位。过亿的下载量并不能有效解决流量变现问题。虎嗅在文中提到，有知情消息称，喜马拉雅2014年全年和2015年上半年的营收都不足千万元。而团队成本、推广营销费用、以及版权开支，却是营收的数倍。王亚谦称，网络FM盈利的途径主要广告和内容付费。但是与视频内容相比，音频广告在展现形式上有很多限制，并不受广告主的青睐。另外，国内消费者并没有付费收听的习惯，用户教育也需要较长的时间。蜻蜓FM副总郭嘉告诉记者，从长远看，广告只是一种收入手段，并不是一个可持续的商业模式，蜻蜓目前签了很多优质内容团队，未来将通过做一些自制节目，用粉丝经济，在产品本身上实现盈利，“比如罗振宇的罗辑思维，靠卖书来赚钱，而不是广告。”附录：喜马拉雅的四点质疑一、虎嗅章中提及蜻蜓FM对数据造假的回应：“‘普罗米修斯’是蜻蜓FM用来在新功能上线时进行AB对照测试、统计相关用户指标，以便产品决策的技术框架。”我们的质疑是：既是新功能上线时进行的A/BTest，为什么所有安卓应用商店渠道的蜻蜓FM都有完全一样的“普罗米修斯”？A/BTest到底测试什么？敢说吗？二、“普罗米修斯”这个后台程序，将数据发送给友盟、talkingdata、艾瑞等第三方数据监测平台，导致第三方数据监测平台将“当天未打开App的用户”记录成活跃用户。如此，蜻蜓FM的装机量直接记为了日活，这就是蜻蜓FM回应的A/BTest吗？三、蜻蜓FM代码中代号为“宙斯”的后台程序，在手机后台打开一个隐藏的浏览器，模拟用户访问广告链接，最终导致广告的展示量和点击量大幅虚假提升，并且导致用户手机耗电异常。“宙斯”代码的这个功能，安卓程序员人人都能看懂，这也是A/BTest吗？四、实测结果显示，“宙斯”后台程序，会把其模拟点击所产生的虚假数据发送给“秒针”“doubleclick”等第三方广告统计平台，这难道还是A/BTest吗？蜻蜓FM的回应作为一家互联网公司，蜻蜓FM一直崇尚开源共享的互联网精神，早已计划把我们在产品测试，数据统计等领域的框架贡献出来，回馈技术社区，正因为此我们的代码也没有做混淆处理。由于近期外界的特别关切，我们决定将开源计划提前，相关代码都将在近期以开源的形式公诸于众。任何代码都应该在其实际使用场景下看待其用途，而非断章取义来曲解其意义。如果是为了商业的目的，做恶意的解读，并误导受众，蜻蜓FM将保留诉诸法律的权利了。关于多个后台service在Android平台上，启动后台service一直都是业内常规的技术手段，比如通知用户关注的收藏节目有更新，设置闹钟，预约节目等都需要后台service存在。比如点击其中进程列表中的一项，会看到如下详细信息：对于这些进程的耗电和流量我们都加了严格的控制，大家也从源代码中可以看到，不用担心，如果对流量有疑问，可以直接发送邮件至。以下是一些其他App启动后台服务的例子：关于所谓“日活造假”喜马拉雅在此处做了严重的误导，甚至是刻意忽略某些关键逻辑判断，网上公布的代码段，并不能达到刷高日活数据的效果。如下图所示，该段执行条件被刻意忽略，而即使满足执行条件下，也只会做卸载率的采集统计，完全没有刷新日活的行为。事实上，如果真的为了刷日活的话，蜻蜓FM的数据早就该超越数千万了。关于广告监测网上传播的所谓广告刷量代码，其实是用于数据比对和验证的技术方法。原因是因为目前第三方广告监测平台众多，各家的广告监测代码格式都不一样。而Android系统又具有严重的碎片化问题。在做一些广告平台的对接时，真实用户环境下的测试和验证显得非常必要。双方的系统联调以及数据对比，对损耗误差调校是一个常规过程。为了尽量不影响用户体验，这个测试不会产生可见的用户界面，也只会在WIFI环境下发生，所以即使执行也不会消耗用户流量。以上整个测试的执行都会提前告知有需要的相关广告厂商和监测平台，产生的数据也会与双方验证确认。综上，基于反编译的代码片段，引申出任何业务解读都是非常可笑的，而且被反编译的仅仅是部分客户端代码片段，稍有技术常识即可知道完整的业务逻辑是需要服务端和客户端协同工作的。而蜻蜓FM做到如今的体量、更多的复杂业务逻辑几乎都在服务端，与此同时，秒针等第三方广告监测方都在该领域上有多年的技术储备，也一直和蜻蜓FM保持着良好的合作关系，双方的各项业务仍然在有条不紊的进行，并不用理会网文中的抹黑行径。本文仅代表作者观点，不代表3W立场
作者：添加作者
(以上内容来自于网友投稿，如侵犯了您的相关权利，请点击
通知我们，我们将尽快予以删除。)
写回应|发话题
话题描述...
加入成功!退出成功!退出以后，该精选社将不会显示在您的首页退出&&我再想想您发布的内容超过140字了，试试投稿功能吧您发布的不能超过500字了！您发布的内容已经超过500字了，您只能使用投稿功能发布立即使用别忘了点击发布哦！发布成功！成功发布到审核区!举报你为什么要举报此投稿？色情暴力骚扰谩骂广告欺诈侵犯版权反动政治其他举报说明：(可选)提交取消成为小编才能给社长推荐哦！我再想想我要当小编举报成功！推荐成功!已举报！收藏成功！取消收藏成功！您还没有认证为原创作者若您先提交此文章,稍后认证,我们会将其自动添加到您的原创先投稿稍后认证最近撕得火热的喜马拉雅FM真的很纯粹吗?
按投票排序
谢邀，非利益相关，非小号非匿名，被邀请可能因为回答过几个播客的问题。之前写论文的关系，对音频行业有过一些调研，主要是对于喜马蜻蜓和荔枝，也知道喜马拉雅动不动撕逼，不过这次闹的确实比较大。程序和代码我不懂，就来谈谈我看到的一些喜马黑料。1. ASO的最高境界，就是成为app store牛皮癣什么是牛皮癣，搜同行荔枝FM能搜到它，这是正常的，可是当你看到他们排在第一时，是不是觉得他们牛逼轰轰。你觉得这样就够了？NO NO NO,远不止于此，搜QQ能搜到，搜微信能搜到，就连搜支付宝都能搜到，你吓尿了吗？你以为喜马拉雅只是听书的？其实他们做社交、做金融、银行....来看看喜马18cm长的标题B12传送门：2. 因恶意刷榜被苹果和安卓市场多次下架2015年4月以后出现了一件“怪事”：排名靠前的喜马拉雅和荔枝在2个月内连续多次下架，其中荔枝FM被下架4次，喜马拉雅FM被下架3次。更为巧合的是，两家有两次下架的日期都是同一天。喜马6月那次下架时间长达一个月，下架原因并非版权，被“恶意刷榜是导致下架”才是真正原因。从苹果后台的下载量可以看出，4月22日的下载量高达9.2万次，但是根据第三方平台TalkingData的统计，实际激活量仅为1.46万。7月，喜马拉雅FM因刷量被华为开发者联盟拉黑三个月；10月中旬，喜马拉雅FM又开始重操旧业，为最近一次与私募股权的融资事件刷量做准备。图：造第一，喜马拉雅9月—11月疯狂开启刷数据图：喜马拉雅FM非法刷量渠道曝光 遭平台警告网易新闻传送门:「喜马拉雅与荔枝为何频遭下架」 链接 3. 陷入版权危机，与阅文版权合作或卖股平风波表面上喜马拉雅与阅文的合作充实了喜马拉雅FM的音频IP。然而值得注意的是，这样的合作并没现金交易，与喜马拉雅的“老对头”（喜马拉雅FM此前与阅文有过版权纠纷）阅文的合作实属无奈，由于喜马拉雅的音频多来自于外链或非正规方式盗播阅文的版权作品，面对阅文索赔的巨额费用时，赔不起的喜马拉雅FM被逼无奈才让出股份与阅文合作，其资金短板的窘境也可见一斑。版权战仅仅只是一个方面，更值得警惕的是喜马拉雅FM竟然上了“非法视频应用软件”黑名单。据和讯科技的报道，这一黑名单，是由中央网信办和广电总局联合发布，上榜原因是这些移动端视频软件上发现有“违规境外内容。”不过毕竟总局，不敢苟同今日头条传送门：4. 财务黑洞资金链断裂，C轮融资难上加难据了解，喜马拉雅FM从2014年至2015年7月，持续处于巨大亏损、严重入不敷出的状态，这也成为其掣肘投资者伸出援手的重要原因。内容上竞争力的匮乏直接导致流量下跌，盈利能力也开始遭受到质疑。有媒体爆出喜马拉雅FM2104年亏损5439万，而2015年仅1-7月份亏损已达到6877万元。铤而走险的背后实则指向喜马拉雅FM融资过程中诸多的不顺。事实上，早在今年4月份，喜马拉雅FM就宣布启动C轮融资，但如今半年过去了，其融资仍尚未完全落实。传送门：5. 个人观点：喜马在这次撕逼中显得没风度，昨天起官微或明或暗发布一些挑衅话语，就算有王思聪支持你们能不能矜持点！！虽然蜻蜓对于代码的解释并未让人满意，但现在还不是得意的时候，何况这次主动举报的居心还有待考量…（对，是我腹黑-3-）虎嗅传送门：*我是围观撕逼小能手，以上都是公开资料或新闻稿件，为了保住小命都带上传送门求不举报
的回答：1，onResume是页面展示时系统自动调用的方法，它在不同页面切换，解锁屏，前后台切换都会被调用。但问题的关键是：喜马拉雅却在onResume中直接调用广告监测代码，而不是在广告展示时调用，这就会造成大量的虚假广告数据发送给监测平台。注意：页面展示了不代表广告展示了，原文截图是在喜马拉雅的搜索页面，并没有任何广告展示！！但却赤裸裸地发送了广告监测请求。2，@陆栋栋 您贵为喜马拉雅的CTO大人，我一个小开发也看的出您所说的这句话就是在诡辩。首先，获取参数没问题，但喜马拉雅却在thirdAdstatRequest中发送了广告监测请求。另外，字符串拼接替换确实是耗时操作，但也无需通过启动线程来优化！首先，获取参数没问题，但喜马拉雅却在thirdAdstatRequest中发送了广告监测请求。另外，字符串拼接替换确实是耗时操作，但也无需通过启动线程来优化！3,
好的，代码上就给你清晰的逻辑,看看喜马拉雅是怎么发的广告监测请求。
各位请看上图线程中的run()方法，其中的f.a().a(*)就是发送广告监测请求的关键调用，我们具体看看它的执行流程：
各位请看上图线程中的run()方法，其中的f.a().a(*)就是发送广告监测请求的关键调用，我们具体看看它的执行流程：其中f()是类的构造方法，里面定义了e，是个AsyncHttpClient，用来做异步网络请求，后文会提到。f.a()获取singleton单例，下一步是f.a().a(*)的调用。这就是用来发送广告监测请求的关键调用。其中f()是类的构造方法，里面定义了e，是个AsyncHttpClient，用来做异步网络请求，后文会提到。f.a()获取singleton单例，下一步是f.a().a(*)的调用。这就是用来发送广告监测请求的关键调用。f.a().a(*)中的s就是third_url，即doubleclick、秒针等的广告检测链接。f.a().a(*)中的s就是third_url，即doubleclick、秒针等的广告检测链接。
利益相关：CS学生，参加了喜马拉雅校招宣讲会互联网数据造假的现象越来越严重了，在这么愉快的双十一日子里，又被爆出了喜马拉雅后台刷广告的事实，两点特别有感触。1 安卓市场上代码安全堪忧，若要人不知除非己莫为，即使做了代码模糊，被人揭发出来也是分分钟的事，只要有心，多花点心思，找出来也是很容易的，原来不仅仅是反编译可以查看到代码，还有抓包也可以反查到代码。2 10月份参加校招，看到了几个数字，当时就震惊了，当时因为标题比较拽，“喜马拉雅校园招聘，爱来不来”，所以就特别留意了一下几个数据，2亿用户，日活用户1000万，日志12T/天，人均收听时长92分钟，怎么可能平均收听会有这么高，也就只有微信能到那个级别吧，稍微想想就知道这个数字多么不靠谱。深深觉得现在互联网的圈子太浮躁了，也许是因为融资的关系，需要把数据提升上去，但不得不说，做好市场公关宣传的同时，还是要把产品做好，不要太浮夸，这样真的不好。
在下帖看到两码农实力回复，当一次义务搬运工吧这两天围观了喜马拉雅和蜻蜓的撕逼大战，作为一个圈内技术狗，实在是被喜马拉雅的行为震撼到了，这flag一路立的飞起，感觉是不想在圈里混的节奏了，那我就扒你一把送送你。喜马的代码混淆了，反编译后简单看了看结构，搜了一些域名地址关键词这些都没有，继续磕代码会比较慢，先假设存在刷量，从抓包分析开始找证据，开个fiddler，打开app首屏就有广告，顺利找到doubleclick请求。点击二级页面，看到也在发doubleclick，嗯也有banner属于正常，点击进入一个功能页，嗯就这么容易，又看到了doubleclick， 这一瞬间我有种还没开始发力你就倒下了的赶脚。。。又到处试了试，发现刷的机制很简单，页面切换、后台到前台、锁屏到解锁都会触发，嗯应该是写在onResume里的。 解锁的:切到前台的:再补一个综合成果:再补一个综合成果:都是doubleclick。略叼略叼！就是这么刷假数据的~嗯就这么简单，flag立的好啊，咬之前也不把自己处理好点，就这手段也敢出来现，还tm挑衅行业底线，技术实力着急，智商着急。我觉得我开了个好头哈，其他人感兴趣可以继续扒，看有没有牛人从混淆代码里再抓出来点更直接的证据，给丫们再好好上一课，不过得抓紧，有可能是纯在线控制的，丫们看到这个估计就会关了。这帖子可能得罪人，得匿得匿~再来看另外一位网友的解读著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。作者：齐康宏链接：来源：知乎看楼上发的喜马拉雅抓包分析启发了我，我反编译了一下喜马拉雅app。从原来的抓包分析中看到带有的链接，其中有个find_banner，它请求的内容如下，里面包含doubleclick（这东西是广告第三方监测商）的链接。在混淆的代码中grep一下find_banner，只出现了一个文件RecommendCategoryFragmentNew。看这个名字应该是主页的推荐首页。根据之前抓包情况，在亮屏时能抓到doubleclick和miaozhen的包，那就肯定是在onResume里了。RecommendCategoryFragmentNew.java中onResume():这里每次onResume调用都会触发statFocusAd，也就是说，在APP每次启动、前后台切换、解锁时，都会启动广告刷量！因此这里的statFocusAd会被大量的频繁调用。再查看ThirdAdStatUtil.getInstance().statFocusAd(mFocusImages,true)：看名字像是做广告统计的，但是除了所谓的广告统计，其实还会广告检测请求。注意参数里的third_url就是find_banner里的thirdStatUrl，也就是用户点击的广告地址。以下是实际执行的广告刷量代码：这里的s正是这个focusimagemodelnew.third_url。这里代码做了混淆，但是看到start方法像是开个线程去做广告刷量，果不其然：这里混淆的比较难读，大部分变量名或函数名都变成了a、b、f、obj这样的字母。s就是third_url，付给了a，然后再封装成了一个对象obj。接下来obj作为参数传给f.a().a(*)调用。但是刷量逻辑很清晰的，关键代码就在f.a().a(*)函数中，让我们来看这个函数做了什么其中f()是类的构造方法，里面定义了e，是个AsyncHttpClient，用来做异步网络请求，后文会提到。f.a()获取singleton单例，下一步是f.a().a(*)的调用。f.a().a(*)中的s就是上文中的third_url，即doubleclick的检测链接。代码里用上文中的e（AsyncHttpClient）调用了这个链接。总结，在RecommendCategoryFragmentNew的每次onResume调用，都会向配置的third_url发送一次请求。而这个onResume是在什么时候调用呢？应用启动时，切到后台再切回来时，锁屏再亮屏时，打开其他应用再回来时；而且由于这个fragment是放在viewpager里，那么切到别的tab再切回来时也会调用。所以这个third_url在应用使用期间会被大量频繁的访问，恐怕比真的展示多了不只几倍的量。这也解释印证了楼上童鞋提到的抓包分析里面的现象。我们再回过头看下third_url刷了哪些第三方广告监测平台。首页广告api：测试时请求到的数据截图如下是配置的doubleclick内容分类中的广告配置的是秒针的刷量链接.是否有其他刷量的地方，我没有深挖，因为混淆过再反编译的代码阅读起来实在是不怎么顺畅。但这段广告监测请求的逻辑放在onResume里就足以说明一切。作为一个资深码农，不得不说，喜马拉雅在刷量这件事上确实动了脑筋。一是代码混淆，隐藏的很深；二是动态下发刷量链接，方案可扩展性极强。利用这种原理，除了刷广告监测，其他http类的请求都可以动态生成访问，想象空间还是很大的，有兴趣的同学可以继续研究，（提示一下，启动的时候有下载其它app的功能，看看有没有同学能分析出来）。最后附上反编译的source code：贵圈真乱
双十一加上redis crackit问题，搞得比较晚，现在才来答可能效果不好，也罢！利益相关，蜻蜓FM员工，流媒体后台开发。知乎快四年用户，从不匿名。实名评论了
的回答，指出其答非所问不在重点，随即遭到
的人肉搜索截图。本来就没打算藏身份，但是对这种不负责任发照片的行为依然表示非常愤怒！！已经举报！此外，蜻蜓员工怎么就不能回答了？！什么强盗逻辑！！？p.s. 以后发我照片请用这张，好看点！
————————————————————正文分割线———————————————— 本来评论里说的不够清楚，这里直接回答，以下是正文：主要做后端，略懂android开发，而且基本的onresume，onpause是任何一个android开发新人都应该知道的常识，这些生命周期函数会被系统在很多情况下反复调用，这点相信不用我多说。原贴中人家
贴出了反编译代码，指出喜马拉雅在这么关键的onresume函数中插入访问doubleclick的代码，而
却在介绍onresume和onpause这种函数的其他功能（更新界面ui，当然这其实才是onresume，onpause本来的主要功能），这叫答到点子上了？最最关键的！！！！！最最关键的！！！！！最最关键的！！！！！别人抓的喜马拉雅的包，在一个没有任何广告的搜索页面，每次开锁解锁都反复请求doubleclick。 说整个代码逻辑是开屏广告的逻辑，当众自打脸。
居然还说doubleclick是喜马拉雅自己的服务端，喜马拉雅也真够厉害的，把doubleclick都承包了？常识问题。
在空白页面没有任何广告展示的情况下发出大量广告监测请求，都这么明显了不知道还有什么可辩解？！
--------------------------------------------------------------------------------------------
好了，现在看到了
（据说是喜马拉雅CTO）的回答，我帮大家理下其思路：
1. onresume是app界面显示时的系统的正常调用
2. 广告展示后应该发送广告统计监测请求
3. 在onresume中就应该调用发起广告统计监测请求
可笑的逻辑问题！
app界面显示并不是广告展示！app界面显示并不是广告展示！app界面显示并不是广告展示！别人原文 中抓包是在喜马拉雅的搜索页面，界面展现了也并无任何广告展示，然而却发现了偷刷广告检测的数据包！怎么解释？？？请
直面问题！！！
没想到年底能看到声音界一号和二号的对撕 对于在互联网里混了不算短的一员 不禁发问这次曝光的始作俑者到底只是剑指蜻蜓FM还是整个移动互联网行业？ 此举值得深思
日14:42更新一觉起来发现被建议修改答案了想了半天没想通哪里不友善。唉，看了看新闻发现整个事件好像已经结束了，就修改一下答案，贴一个时间线大家来看看吧：先是有这个问题，然后有了然后自称是蜻蜓FM员工的林睿同学和自称是喜马拉雅CTO的陆栋栋同学这样回答然后网上出现了这么一个视频过不多久喜马拉雅官方微博遍发表声明说视频里曝光的在完全没有广告展示的搜索页进行锁屏、解锁、切后台、切前台都会发送广告统计请求的现象是存在的，但是是一个bug最后是蜻蜓官方微博对此的转发再后来就没有然后了。
互联网原本都这样，本来也没什么好大惊小怪的。不过这喜马拉雅也真是傻逼，自己屁股都没擦干净还说别人。看吧，说别人代码有问题别人还能解释，你这下包都被抓了，还有的跑。利益相关必须匿，以前配合推广的时候跟他们合作过，做事很流氓。
大家好，我是喜马拉雅的技术负责人--陆栋栋，从毕业到现在一直在写代码。这是我平生第一次遇到竞争对手这么强大公关力量，也是第一次抛投露面和别人做技术交流。有什么答的不对的地方，请知乎网友和蜻蜓童鞋纠正。 刚上班就看到你们的很多质疑，不好意思让蜻蜓的同事久等了。我们android客户端一直采用的是单Activity多fragment的架构。1. 正常回到前一个fragment是不会发的，只是整个Activity在resume的时候才会多发，我前面也说了喜马拉雅是单Activity架构，所以只有整个喜马拉雅app退到后台再回到前台才会多发。我们在做这个架构的时候确实有疏忽，应该屏蔽最底下的fragment的resume。2. 但是我们从最后一个fragment退回到首页的时候，不会触发fragment栈最底下的fragment的onResume，这时候却会少发。多发和少发，我们也不必纠结哪个量少，哪个量大。在此由衷感谢蜻蜓的童鞋，给我们提出bug，我们在下个版本会立即修复。谢谢你们。下午 答蜻蜓同事的质疑：质疑喜马拉雅的文章故意混淆事实真相，真相是
，请验证：1. onResume是用户界面展示时程序正常的执行方法， “质疑文章”提到在APP每次启动、前后台切换、解锁时会调用onResume方法，是试图引起不懂技术的读者的恐慌。2. “质疑文章”提到在onResume方法执行的时候，对第三方统计公司的url进行了调用，就是刷量。而事实是正常用户操作，正常的广告展示，正常的向第三方数据平台发送数据。请所有程序员详看下述和”质疑文章”对照的逻辑：请求从服务端加载需要的广告列表，字段thirdStatUrl，是第三方广告统计的地址，每个广告是不同的，因为广告不同，需要辅助监测的第三方就不同。thirdStatUrl用于向第三方发送广告统计。应用在展示广告的时候，向第三方发送统计请求是正常行为，用于第三方广告监测，这一点想必所有行业内的人或程序员都应该是认同的。而OnResume是界面显示的时候是android系统调用的方法，所以在onResume的时候，肯定是会发送统计的，以记录广告的展示量。到这里，没有问题。仔细说明，被onResume方法调用的StatFocusAd方法，做了两件事，一是调用ThirdAdStatRequest发送第三方广告统计，随后DataCollectUtil.statOnlineAd()进行了喜马拉雅自己的广告统计。原作者随后说，在ThirdAdStatRequest发送统计的时候，喜马拉雅FM把third_url作为参数，在这个方法中启动了一个线程，随后进行了刷量，然而，本身就是为了发第三方发送广告统计，必然需要third_url，启动线程是因为第三方统计所要求客户端传许多参数，我们认为获取这些参数和在URL中字符串拼接替换是耗时操作，所以启动了一个线程，异步请求，使用户使用不卡，目的是优化用户体验。拼接替换完参数后，自然就是发起URL请求。这时候”质疑文章”作者这样说到“这里混淆的比较难读，但是刷量的逻辑很清晰的，关键代码就在f.a().a(*)函数中，让我们看看这个函数做了什么：” 然后”质疑文章”贴了两个图这里实际上也就是通过AsyncHttpClient就是对第三方发了一个HTTP GET请求。原作者或许自己也词穷了，只好强行说 “至此，广告刷量的整个流水线都浮出水面了。”，根本没有任何解释，全是编造。
原来喜马拉雅是用这个做法正面回复 蜻蜓FM 的啊。。。
已有帐号？
无法登录？
社交帐号登录