首页 文章 精选 留言 我的

精选列表

搜索[MaaS平台],共10000篇文章
优秀的个人博客,低调大师

JavaMelody 1.80.0 发布,Java 应用监控平台

JavaMelody 1.80.0 发布了。JavaMelody 是一个监控系统,目标是在 QA 和生产环境中监控Java 或 Java EE 应用程序。 此版本主要更新内容包括: fix#851:当使用 spring-boot 并在同一类上使用 @Service 和 @MonitoredWithSpring、@Async 或 @Scheduled 时,命中次数将被计算多次。 fix#848:使用 spring-boot-devtools 时,热重启后会 NPE。 fix#863:如果 executeBatch 没有 prepareStatement 或 addBatch,则触发 JdbcWrapper 中的 NullPointerException。 added:当使用 spring-boot-starter-data-elasticsearch 或当 Spring 上下文中有 ElasticsearchRestTemplate(或 ElasticsearchTemplate)时,自动监视 Elasticsearch 调用。 添加了 JSP 标记以将其它指标导出到 Prometheus:从 JBean 中的 MBean,自定义 Java 代码,某些 HTTP 请求或其它请求的统计信息中。 .../monitoring?format=prometheus添加新的 Prometheus 指标:使用的非堆内存、使用的缓冲内存、使用的物理内存、使用的交换空间、已加载的类数。 详情查看更新说明: https://github.com/javamelody/javamelody/releases/tag/javamelody-core-1.80.0 下载: Maven 依赖: <dependency> <groupId>net.bull.javamelody</groupId> <artifactId>javamelody-core</artifactId> <version>1.80.0</version> </dependency> javamelody-core-1.80.0.jar: Jar for integration in a webapp javamelody-collector-server-1.80.0.war: War of the optional collect server, not needed in most use cases Plugins: JIRA / Confluence / Bamboo / Bitbucket Jenkins Liferay Alfresco Sonar Grails

优秀的个人博客,低调大师

Rider 2019.2.3 发布,跨平台 .NET IDE

Rider 2019.2.3 发布了,此版本的主要目标是为刚刚发布的 .NET Core 3.0 添加完全支持。 除此之外,Rider 团队还修复了 YouTrack 中的许多问题。主要更新内容如下: 修复了 Xamarin Android 的“无法启动调试”错误 修复了 Azure DevOps 源代码管理的相应插件中的多个问题 修复了“覆盖”代码完成的问题 在代码注释中键入单引号时,不再插入一对单引号 发布公告:https://blog.jetbrains.com/dotnet/2019/10/18/rider-2019-2-3-bugfix/

优秀的个人博客,低调大师

Godot 3.2 发布,跨平台游戏引擎

Godot 3.2已经发布,带来了如下变化: 支持 WebRTC,一种可用于多人游戏的实时通信协议 对其视觉着色器系统进行了重大改进 更好的可视化脚本支持 Godot 编辑器中的版本控制系统集成 一种用于分析网络拥塞问题的网络分析器 MSAA 对 OpenGL ES 2 渲染器的消除混叠支持,以及对 GLES 2 代码路径的其他改进 在 Clang 编译器下构建时,支持在 Linux 上链接 LLD。还有一个新的标志用于链接到 ThinLTO 支持 Android 上的 Oculus Mobile SDK 详情见发布说明

优秀的个人博客,低调大师

PulseAudio 13 发布,跨平台声音服务

PulseAudio是许多基于 Linux 的操作系统默认使用的开源声音系统/服务器,它可以用来作为一种简易改进的开放声音后台(ESD)替换。PulseAudio 13已经发布,该版本内容如下: 支持 Dolby TrueHD 和 DTS-HD 主音频 增加对 SteelSeries Arctis 5 USB 耳机的支持 改进了 ALSA 卡的初始卡配置文件选择 Cmedia USB 2.0 High-Speed TrueHD Audio 的 S/PDIF 改进 删除 BlueZ 4支持 放弃了对 intlTool 转换工具的支持 有一个新的函数,它有助于实现客户端线程的实时调度 从 pa_Format_info 获取各种参数的新函数 默认情况下在 module-loopback 中使用通道映射和源示例规范的能力 PulseAudio 13 系列还添加了几个新的模块参数,包括module-loopback的max_latency_msec,module-rtp-send的stream_name,module-udev-detect和module-alsa-card的avoid_resampling,默认情况下不再使用持久蓝牙卡配置文件选择,建议用户默认使用 A2DP。同时此版本也是第一个采用新的 Meson 构建系统的开源版本。 详情见发布说明: https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/13.0/ 下载地址: https://linux.softpedia.com/get/Multimedia/Audio/PulseAudio-11830.shtml

优秀的个人博客,低调大师

Rider 2019.2.2 发布,跨平台 .NET IDE

Rider 2019.2.2 发布了,这是一个修复版本,最主要的更新内容如下: 支持 .NET Core 3 Preview 8 对代码完成的一些修复 ASP.NET 项目中解决方案宽错误分析(Solution Wide Error Analysis,SWEA)的性能得到了改进 对 Razor 支持的大量修复,包括解析标记帮助(tag helpers)和视图组件、更好的格式化等 Android Layout Preview 中的问题已得到修复 修复了代码分析的问题 修复了 JavaScript 调试器再次在断点处停止的问题 发布公告:https://blog.jetbrains.com/dotnet/2019/08/29/rider-2019-2-2/

优秀的个人博客,低调大师

Rider 2019.2.1 发布,跨平台 .NET IDE

Rider 2019.2.1 发布了,这是针对 2019.2 的修复版本,包含以下错误修复: 合并 DataGrip 的修复程序,以停止导致完全冻结的高内存使用 Enter、Tab 和 Space 再次完成代码完成中的所选项目 现在,在 Visual Studio 安装中捆绑的 MSBuild 在自动检测中成为首选,它取代了在 Rider 安装中捆绑的 MSBuild 发布公告:https://blog.jetbrains.com/dotnet/2019/08/20/rider-2019-2-1/

优秀的个人博客,低调大师

基于iOS平台的性能检测方案

导语 在开发过程中,功能不仅要满足业务需求,也要关注功能对App性能带来的一些问题。开发人员在开发阶段检测性能比较容易,iOS端可以直接通过instruments工具进行检测。但是在测试阶段,测试人员要检测性能需要下载开发工具成本比较高。如果客户端能够将性能数据上传到服务端并且通过一些界面进行展示,对测试人员来说是一种可以检测性能的比较好的方法。 本文章主要介绍iOS端如何通过代码采集性能数据,其中包括电池数据,CPU数据,内存数据,卡顿数据,流量数据以及冷启动时间等。 电池数据 首先来看一下电池数据,iOS电池数据采集方案主要有以下三种方案:UIDevice,IOKit,越狱。 1、UIDevice:提供了获取设备电池的相关信息,包括当前电池的状态以及电量。获取电池信息之前需要先将 batteryMonitoringEnabled 属性设置为 YES,然后就可以通过 batteryState 和 batteryLevel 获取电池信息。 优点:api简单,易于使用。 缺点:粗粒度,能够采集到的数据较少,不符合需求。 2、IOKit: 是一个iOS 系统的私有框架,它可以被用来获取硬件和设备的详细信息,也是与硬件和内核服务通信的底层框架。通过它可以获取设备电量信息,精确度达到1%。 优点:可以获取较多的电池相关的数据。 缺点:因为要访问私有api,不能通过苹果审核,只能在线下取值。获取到的值是设备的电池数据,无法达到应用级别的数据获取。 3、越狱方案:通过iOSDiagnosticsSupport 私有库,Runtime 拿到 MBSDevice 实例,获取电量日志信息表,日志信息表中包含了 iOS 系统采集的小时级别的耗电量。 优点:可以获取到应用的耗电量。 缺点:获取到的耗电量是以小时为单位的,时间间隔太长,不符合需求。 最后,为了能够采集更多的电池数据,我们选择的方案是通过访问IOKit的私有api获取数据,并且在提交到app store时将这部门代码从包里移除掉,以免影响app的审核结果。 核心代码如下: 通过以上方式可以获取到的数据包括但不限于: 当前充电状态 电量 是否连接USB(支持iOS10以下系统) 是否有电池 最大值 电压 温度(支持iOS10以下系统) CPU数据 iOS的线程技术是基于Mach 线程技术实现的,在 Mach 层中thread_basic_info 结构体提供了线程的基本信息,并且每个线程中包含线程的cpu_usage。获取当前App的占用率就是所有线程的cpu_usage之和。 通常一个 task 包含多个线程,在内核提供了 task_threads API 调用获取指定 task 的线程列表以及线程个数,也就是target_task 任务中的所有线程保存在 act_list 数组中,数组中包含 act_listCnt 个条目。然后可以通过 thread_info API 调用来查询指定线程的信息。 因此,获取当前APP的CPU占用率需要遍历所有线程,将cpu_usage求和。 接下来就是获取当前设备的CPU总占用率。 iOS中CPU状态一般包括CPU_STATE_USER, CPU_STATE_SYSTEM, CPU_STATE_IDLE 和 CPU_STATE_NICE等四种。 1、CPU_STATE_USER:运行在用户态空间或者说是用户进程。 2、CPU_STATE_SYSTEM:在内核空间运行的分配内存、IO操作、创建子进程……等。 3、CPU_STATE_IDLE:空闲状态。 4、CPU_STATE_NICE:用户空间进程的CPU的调度优先级。 因此,除了空闲状态都属于CPU占用状态,因此当前CPU的总使用率为(用户+系统+调度)/(用户+系统+调度+空闲)。通过host_statistics获取host_cpu_load_info结构体数据,该结构体中 cpu_ticks 包含了 CPU 运行时四种不同该状态的时钟脉冲的数量,并且根据这四个不同状态的时间脉冲,计算出CPU的总占用率。 内存数据 获取内存数据同样也可以通过mach_task_basic_info结构获取resident_size值作为当前App已占用的内存大小。 但是在测试中发现,通过该结构体获取的值与Xcode中的内存数据对不上,往往差好几兆甚至好几十兆。因此通过查找资料,有一篇文章介绍通过逆向Xcode来获取Xcode计算内存方法以及结构体。该方法获取到的已占用内存大小与Xcode的值几乎一致,可以作为一个判断标准。具体参考代码如下: 接下来,如果要获取当前设备可以使用的空闲内存,首先要了解iOS系统的内存分配。 Free Memory:未使用的 RAM 容量,随时可以被应用分配使用。 Wired Memory:用来存放内核代码和数据结构,它主要为内核服务,如负责网络、文件系统之类的;对于应用、framework、一些用户级别的软件是没办法分配此内存的。但是应用程序也会对 Wired Memory 的分配有所影响。 Active Memory:活跃的内存,正在被使用或很短时间内被使用过。 Inactive Memory:最近被使用过,但是目前处于不活跃状态。 Purgeable Memory:可以理解为可释放的内存,主要是大对象或大内存块才可以使用的内存,此内存会在内存紧张的时候自动释放掉。 因此,空闲内存看成总内存大小减去 Wired Memory大小,Active Memory大小以及Inactive Memory大小。在32位系统通过这种方式获取空闲内存与Xcode数据作比较误差范围较小,而在64位系统上的数据与Xcode数据一比较误差较大,同样找到一个逆向Xcode获取Xcode的计算内存方法。64位系统获取空闲内存的具体代码如下: 卡顿数据 检测卡顿数据的方式通常有两种:一种是FPS卡顿检测,另一种是主线程卡顿检测。 FPS卡顿检测:检测当前页面的帧率,帧率越高意味着界面越流畅,通过计算丢帧率来检测当前页面的卡顿情况。 主线程卡顿检测:通过开辟一个子线程来监控主线程的RunLoop,当两个状态区域之间的耗时大于阈值时,就记为发生一次卡顿。 一、FPS卡顿检测 目前我们要采集的方主要是基于CADisplayLink以屏幕刷新频率同步绘图的特性,观察屏幕当前帧数的指示器,若帧率少于指定的帧率看成一个FPS卡顿。具体代码如下: 二、主线程卡顿检测 在主线程在Runloop的某个阶段进行长时间的耗时操作,因此主要思路就是开辟一个子线程去计算kCFRunLoopBeforeSources和kCFRunLoopAfterWaiting两个状态区域之间的耗时是否超过某个阀值来断定主线程的卡顿情况。 那么,为什么要用kCFRunLoopBeforeSources和kCFRunLoopAfterWaiting状态进行判定呢?首先要理清楚Runloop的运行机制,以下为RunLoop 顺序: 看完RunLoop顺序,就可以看到处理事件主要有两个时间段 — kCFRunLoopBeforeSources 发送之后与 kCFRunLoopAfterWaiting 发送之后。dispatch_semaphore_t 是一个信号量机制,信号量到达或者超时会继续向下进行。若超时则返回的结果必定不为0,若信号量到达返回的结果为0。利用这个特性我们判断卡顿出现的条件为在信号量发送 kCFRunLoopBeforeSources和kCFRunLoopAfterWaiting后进行了大量的操作,在一段时间内没有再发送信号量,看成超时。也就是主线程长时间的停留在这两个状态上。转换为代码就是判断有没有超时,若超时了,再判断当前停留的状态是不是这两个状态,如果是,就判定为卡顿。具体参考代码如下: 流量数据 流量数据主要统计在当前App内发生的所有网络请求相应的数据大小。首先,先通过facebook提供的sonar框架捕捉app内的所有request和response。在实际的网络请求中 Request 和 Response 不一定是成对的,如果网络断开、或者突然关闭进程,都会导致不成对现象,如果将 Request 和 Response 记录在同一条数据,将会对统计造成偏差。因此request和response分开统计流量。若有对SonarKit框架感兴趣的同学可以直接访问官网进一步了解,官网:https://fbsonar.com/docs/getting-started.html 一、统计Request流量 首先需要了解请求报文的组成,如图: 那么,Request所花费的流量就是将把Line的大小,Header的大小,空格以及Body大小累加的合。 1、Line大小的统计 Line没有可以直接转换成CFNetwork相关数据的私有接口,但是我们很清楚 HTTP 请求报文 Line 部分的组成,因此可以手动计算Line的大小。 2、Header大小统计 通过request.allHTTPHeaderFields 拿到的头部数据是有很多缺失的,并不是完整的数据。同时由于无法直接转换到 CFNetwork 层,所以一直拿不到完整的 Header 数据。缺少的数包括但不限于以下几个字段:Accept,Connection,Host,当前Request的Cookie。由于基本上缺失的都是固定的几个字段,忽略这几个字段对统计的结果影响不大。因此主要针对cookie的数据并且手动大小进行补全。因此总Header的大小可以看成request.allHTTPHeaderFields数据大小加上cookie大小。 3、Body大小统计 最后是body部分,通过resquest.HTTPBody来计算Body大小。这里要注意的地方就是通过 NSURLConnection 发出的网络请求 resquest.HTTPBody 拿到的是 nil。需要通过 HTTPBodyStream 读取 stream 来获取 request 的 Body 大小。 最后,将Line大小,Header大小,Body大小相加就是当前request所话费的流量。 二、统计Response流量 请求报文的组成如下: 那么Response所花费的流量就是将把Status Line的大小,Header的大小,空格以及Body大小累加的合。 1、StatusLine大小 NSURLResponse没有接口能直接获取报文中的 Status Line。因此,最后通过转换到 CFNetwork 相关类拿到了Status Line 的数据后计算它的大小,这其中可能涉及到了读取私有 API,因此需要注意审核问题。 2、Header大小 通过 httpResponse.allHeaderFields拿到 Header 字典,转换成 NSData 计算大小。 3、Body大小 对于 Body 的计算,采用 expectedContentLength 或者去 NSURLResponse 对象的 allHeaderFields 中获取 Content-Length 值,其实都不够准确。Content-Length 只是表示 Body 部分的大小,因此采取直接获取body大小的方式。还有一个需要注意对 gzip 情况进行区别分析。我们知道 HTTP 请求中,客户端在发送请求的时候会带上 Accept-Encoding,这个字段的值将会告知服务器客户端能够理解的内容压缩算法。而服务器进行相应时,会在 Response 中添加 Content-Encoding 告知客户端选中的压缩算法。若Content-Encoding使用了 gzip,则模拟一次 gzip 压缩,再计算字节大小。 冷启动时间 App的冷启动就是,当应用启动时,后台没有该应用的进程,这时系统会重新创建一个新的进程分配给该应用, 这个启动方式就叫做冷启动(后台不存在该应用进程)。下面先看看苹果官方文档给的应用的启动时序图,图中可以看到冷启动是一个User taps app icon到Final initialization(applicationDidFinishLaunching: withOptions:)的过程,所以冷启动时间就是从用户唤醒App开始一直到App已启动所消耗的时间。 因此,冷启动时间 =DidLauching时间 - main()函数执行之前的时间。类的+ load方法在main函数执行之前调用,所以我们采取在+ load方法记录开始时间的方案。具体参考代码如下: 当applicationDidFinishLaunching:withOptions:方法执行完毕后,添加一个回调获取AppDidFinishLaunching后的时间。并且将开始时间与load开始时间相减作为应用冷启动时间。 总结 以上介绍了iOS中通过代码采集性能数据的方案,目前还在继续优化采集方案,希望本文章能够帮助大家对iOS性能数据采集的了解。 参考文章: https://fbsonar.com/docs/getting-started.html http://www.cocoachina.com/ios/20170629/19680.html http://www.cocoachina.com/ios/20180606/23691.html https://cloud.tencent.com/developer/article/1006222 https://www.jianshu.com/p/6c10ca55d343 http://ddrccw.github.io/2017/12/30/2017-12-30-reverse-xcode-with-lldb-and-hopper-disassembler/ https://www.jianshu.com/p/8e764d05275b?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

用户登录
用户注册