24小时接单的黑客

联系黑客,怎么找黑客,黑客怎么找,黑客接单,破解系统

iOS远程看对方手机屏幕(远程看对方手机屏幕软件)

  作者:杨津,腾讯移动客户端开发 高级工程师

  商业转载请联系腾讯WeTest获得授权,非商业转载请注明出处。

  原文链接:https://wetest.qq.com/lab/view/367.html

  WeTest 导读

  目前iOS主流的内存监控工具是Instruments的Allocations,但只能用于开发阶段。本文介绍如何实现离线化的内存监控工具,用于App上线后发现内存问题。

  FOOM(Foreground Out Of Memory),是指App在前台因消耗内存过多引起系统强杀。对用户而言,表现跟crash一样。Facebook早在2015年8月提出FOOM检测办法,大致原理是排除各种情况后,剩余的情况是FOOM,具体链接:https://code.facebook.com/posts/1146930688654547/reducing-fooms-in-the-facebook-ios-app/。

  微信自15年年底上线FOOM上报,从最初数据来看,每天FOOM次数与登录用户数比例接近3%,同期crash率1%不到。而16年年初某东老大反馈微信频繁闪退,在艰难拉取2G多日志后,才发现kv上报频繁打log引起FOOM。接着16年8月不少外部用户反馈微信启动不久后闪退,分析大量日志还是不能找到FOOM原因。微信急需一个有效的内存监控工具来发现问题。

  一、实现原理

  微信内存监控最初版本是使用Facebook的FBAllocationTracker工具监控OC对象分配,用fishhook工具hook malloc/free等接口监控堆内存分配,每隔1秒,把当前所有OC对象个数、TOP 200最大堆内存及其分配堆栈,用文本log输出到本地。该方案实现简单,一天内完成,通过给用户下发TestFlight,最终发现联系人模块因迁移DB加载大量联系人导致FOOM。

  不过这方案有不少缺点:

  1、监控粒度不够细,像大量分配小内存引起的质变无法监控,另外fishhook只能hook自身app的C接口调用,对系统库不起作用;

  2、打log间隔不好控制,间隔过长可能丢失中间峰值情况,间隔过短会引起耗电、io频繁等性能问题;

  3、上报的原始log靠人工分析,缺少好的页面工具展现和归类问题。

  所以二期版本以Instruments的Allocations为参考,着重四个方面优化,分别是数据收集、存储、上报及展现。

  1.数据收集

  16年9月底为了解决ios10 nano crash,研究了libmalloc源码,无意中发现这几个接口:

  

  当malloc_logger和__syscall_logger函数指针不为空时,malloc/free、vm_allocate/vm_deallocate等内存分配/释放通过这两个指针通知上层,这也是内存调试工具malloc stack的实现原理。有了这两个函数指针,我们很容易记录当前存活对象的内存分配信息(包括分配大小和分配堆栈)。分配堆栈可以用backtrace函数捕获,但捕获到的地址是虚拟内存地址,不能从符号表dsym解析符号。所以还要记录每个image加载时的偏移slide,这样符号表地址=堆栈地址-slide。

  

  另外为了更好的归类数据,每个内存对象应该有它所属的分类Category,如上图所示。对于堆内存对象,它的Category名是“Malloc ”+分配大小,如“Malloc 48.00KiB”;对于虚拟内存对象,调用vm_allocate创建时,最后的参数flags代表它是哪类虚拟内存,而这个flags正对应于上述函数指针__syscall_logger的第一个参数type,每个flag具体含义可以在头文件

  二、降低误判

  先回顾Facebook如何判定上一次启动是否出现FOOM:

  

  1.App没有升级

  2.App没有调用exit()或abort()退出

  3.App没有出现crash

  4.用户没有强退App

  5.系统没有升级/重启

  6.App当时没有后台运行

  7.App出现FOOM

  1、2、4、5比较容易判断,3依赖于自身CrashReport组件的crash回调,6、7依赖于ApplicationState和前后台切换通知。微信自上线FOOM数据上报以来,出现不少误判,主要情况有:

  ApplicationState不准

  部分系统会在后台短暂唤起app,ApplicationState是Active,但又不是BackgroundFetch;执行完didFinishLaunchingWithOptions就退出了,也有收到BecomeActive通知,但很快也退出;整个启动过程持续5~8秒不等。解决方法是收到BecomeActive通知一秒后,才认为这次启动是正常的前台启动。这方法只能减少误判概率,并不能彻底解决。

  群控类外挂

  这类外挂是可以远程控制iPhone的软件,通常一台电脑可以控制多台手机,电脑画面和手机屏幕实时同步操作,如开启微信,自动加好友,发朋友圈,强制退出微信,这一过程容易产生误判。解决方法只能通过安全后台打击才能减少这类误判。

  CrashReport组件出现crash没有回调上层

  微信曾经在17年5月底爆发大量GIF crash,该crash由内存越界引起,但收到crash信号写crashlog时,由于内存池损坏,组件无法正常写crashlog,甚至引起二次crash;上层也无法收到crash通知,因此误判为FOOM。目前改成不依赖crash回调,只要本地存在上一次crashlog(不管是否完整),就认为是crash引起的APP重启。

  前台卡死引起系统watchdog强杀

  也就是常见的0x8badf00d,通常原因是前台线程过多,死锁,或CPU使用率持续过高等,这类强杀无法被App捕获。为此我们结合了已有卡顿系统,当前台运行最后一刻有捕获到卡顿,我们认为这次启动是被watchdog强杀。同时我们从FOOM划分出新的重启原因叫“APP前台卡死导致重启”,列入重点关注。

  三、成果

  微信自2017年三月上线内存监控以来,解决了30多处大大小小内存问题,涉及到聊天、搜索、朋友圈等多个业务,FOOM率由17年年初3%,降到目前0.67%,而前台卡死率由0.6%下降到0.3%,效果特别明显。

  

  

  四、常见问题

  UIGraphicsEndImageContext

  UIGraphicsBeginImageContext和UIGraphicsEndImageContext必须成双出现,不然会造成context泄漏。另外XCode的Analyze也能扫出这类问题。

iOS远程看对方手机屏幕(远程看对方手机屏幕软件)

  UIWebView

  无论是打开网页,还是执行一段简单的js代码,UIWebView都会占用APP大量内存。而WKWebView不仅有出色的渲染性能,而且它有自己独立进程,一些网页相关的内存消耗移到自身进程里,最适合取替UIWebView。

  autoreleasepool

  通常autoreleased对象是在runloop结束时才释放。如果在循环里产生大量autoreleased对象,内存峰值会猛涨,甚至出现OOM。适当的添加autoreleasepool能及时释放内存,降低峰值。

  互相引用

  比较容易出现互相引用的地方是block里使用了self,而self又持有这个block,只能通过代码规范来避免。另外NSTimer的target、CAAnimation的delegate,是对Obj强引用。目前微信通过自己实现的MMNoRetainTimer和MMDelegateCenter来规避这类问题。

  大图片处理

  举个例子,以往图片缩放接口是这样写的:

  但处理大分辨率图片时,往往容易出现OOM,原因是-[UIImage drawInRect:]在绘制时,先解码图片,再生成原始分辨率大小的bitmap,这是很耗内存的。解决方法是使用更低层的ImageIO接口,避免中间bitmap产生:

  

  大视图

  大视图是指View的size过大,自身包含要渲染的内容。超长文本是微信里常见的炸群消息,通常几千甚至几万行。如果把它绘制到同一个View里,那将会消耗大量内存,同时造成严重卡顿。最好做法是把文本划分成多个View绘制,利用TableView的复用机制,减少不必要的渲染和内存占用。

  ● Memory Usage Performance Guidelines

  https://developer.apple.com/library/content/documentation/Performance/Conceptual/ManagingMemory/ManagingMemory.html#//apple_ref/doc/uid/10000160-SW1

  ● No pressure, Mon!

  https://www.newosxbook.com/articles/MemoryPressure.html

  腾讯WeTest iOS预审工具

  为了提高IEG苹果审核通过率,腾讯专门成立了苹果审核测试团队,打造出iOS预审工具这款产品。经过1年半的内部运营,腾讯内部应用的iOS审核通过率从平均35%提升到90%+。

iOS远程看对方手机屏幕(远程看对方手机屏幕软件)

  现将腾讯内部产品的过审经验,以线上工具的形式共享给各位。在WeTest腾讯质量开放平台上可以在线使用。点击 https://wetest.qq.com/product/ios 即可立即体验!

  如果使用当中有任何疑问,欢迎联系腾讯WeTest企业QQ:800024531

  iOS预审服务

  【扫描工具】上传IPA包、图片、视频、应用描述即可进行测试; 多维度自动扫描提审材料的被拒风险;1小时内反馈全面的扫描报告。

  【专家预审】腾讯专家为您遍历App所有功能模块;全面暴露App内容被拒风险;跟进问题直至上线(需提供官方拒绝邮件)。

  【专家咨询】资深预审专家一对一服务; 咨询时间灵活可选,按需购买;有的放矢解 决审核问题。

  【ASO优化】专业团队多维度深度剖析App的ASO现状;围绕App目标用户群筛选高 度关联的关键词;帮助提升App在苹果应用商店中的曝光率。

发表评论:

Powered By

Copyright Your WebSite.Some Rights Reserved.