摘要 在 iOS 11 Beta 刚刚发布时，有用户在微博反馈：升级到 iOS 11 Beta 后，微信读书 App 遇到启动必 crash 的绝境，无法使用。 用户看到的界面，是我们开源的 iOS
今天主题，产品数量级上去了之后很多人都会去关心性能问题。这里是Info对微信性能优化上的一些探寻，值得参考。
可观测性(Observability)并不是一个新词，而在几十年前被广泛地用于控制理论，用它来描述和理解⾃我调节系统。随着容器技术、微服务、⽆服务器迅速流行，使得系统间的访问越来越复杂，在云上、本地或两者上可能会运⾏数千个进程， 使用传统的监控技术和⼯具很难跟踪这些分布式架构中的通信路径和相互依赖关系。系统内部的可见性就变得非常重要。
程序向系统申请内存，使用完不需要之后,不释放内存还给系统回收，造成申请的内存被浪费.
相信大家都遇到过一段特殊文本可以让iOS设备所有app闪退的经历。前段时间大年初一，又出现某个印度语字符引起iOS11系统奔溃，所幸iOS版微信客户端做了保护并没有引起太大问题（字符处理这类技术问题，其实曾在Android版微信上导致过严重的用户体验危机，感兴趣的可以看看文章《微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉》）。
婚芭莎(中国婚博会)App主要为结婚新人提供一站式备婚方案，包括一二线城市各大主流结婚品牌；专为中国结婚新人提供线上备婚指导教育，线下体验订购服务平台。
6 月 20 日下午，GMTC 北京 2019 全球大前端技术大会「多端提效与质量优化实践」技术专场，来自贝壳找房的四位技术专家分别就“极限前端性能优化”、“贝壳找房 Node 服务稳定性建设”、“贝壳移动端监控建设实践”以及“ Flutter 在贝壳的接入实践”主题进行分享。InfoQ 对本专场的精华内容做了部分梳理和总结。
作者：jackhuali 腾讯PCG工程师 |导语 灯塔SDK当前的日活终端设备数超过10亿，日事件上报量超过万亿条，灯塔SDK是什么，灯塔SDK做了哪些工作来支撑如此大业务需求的呢？灯塔SDK是怎么保障业务客户端事件数据上报的准确性的呢？带着问题我们接下来一步步进行拆解。 灯塔SDK从2011年左右诞生至今，并随着PCG数据治理地持续推进，灯塔SDK逐步被各个业务线所深度使用，灯塔SDK逐渐收敛其余上报通道，成为了公司级统一的数据上报通道。 以下总结了大家日常对灯塔SDK集成、测试、数据验证等使用过
大多数文件系统都会保留一部分空间作为紧急情况时用(比如硬盘空间满了)，这样能保证有些关键应用(比如数据库)在硬盘满的时候有点余地，不至于马上就crash，给监控系统和管理员一点时间去察觉。不过有些时候这部份预留的硬盘空间不用的话有点浪费，如何释放这部分系统预留的空间？
【技思广益 · 腾讯技术人原创集】是腾讯云开发者社区为腾讯技术人与广泛开发者打造的分享交流窗口。栏目邀约腾讯技术人分享原创的技术积淀，与广泛开发者互启迪共成长。
1.找到堆栈信息 一般堆栈在Android log或者tombstore里面,android log里面直接搜libsurfaceflinger或者surfaceflinger定位到log,SW-WD tombstore文件是系统在系统发生NE是抓到的堆栈信息,可能会包含多份文件,找的需要的即可 2.解析堆栈 backtrace信息, 主要看调用栈,我们能从中得到发生问题的具体代码行号,比如:
死锁问题对产品的影响是巨大的，那么是否会有效的方法能够监控Android应用的死锁呢？
作者简介 胡健，携程框架高级研发经理，目前负责多媒体服务的构建和研发工作。 近些年携程业务突飞猛进，用户遍及世界各地。公司对用户体验也越来越重视，每一个小的功能改动、页面改版的背后，都有大量的A/B实验提供保障。与此同时，与用户体验息息相关的媒体文件的应用质量也被放到重要位置，如图片加载延时、成功率、清晰度等数据。 本文将分享携程图片服务架构，包括服务架构的演变过程，以及在生产上实际遇到的一些问题，避免大家重复踩坑。 一、服务架构 1、初始阶段 携程图片的服务架构主要经历了三次比较大的调整。早些年为了满足
如果在使用App时遇到闪退，你可能会选择卸载App、到应用商店怒斥开发者等方式来表达不满。但开发者也同样感到头疼，因为崩溃可能意味着用户流失、营收下滑。为了降低崩溃率，进而提升App质量，App开发团队需要实时地监控App异常。一旦发现严重问题，及时进行热修复，从而把损失降到最低。App异常监控平台，就是将这个方法服务化。 低成本 小型创业团队一般会选择第三方平台提供的异常监控服务。但中型以上规模的团队，往往会因为不想把核心数据共享给第三方平台，而选择独立开发。造轮子，首先要考虑的就是成本问题。我们选择了站
作者简介:胡健，携程框架高级研发经理，目前负责多媒体服务的构建和研发工作。 近些年携程业务突飞猛进，用户遍及世界各地。公司对用户体验也越来越重视，每一个小的功能改动、页面改版的背后，都有大量的A/B实验提供保障。与此同时，与用户体验息息相关的媒体文件的应用质量也被放到重要位置，如图片加载延时、成功率、清晰度等数据。 本文将分享携程图片服务架构，包括 服务架构的演变过程，以及在生产上实际遇到的一些问题，避免大家重复踩坑。 一、服务架构 1、初始阶段 携程图片的服务架构主要经历了三次比较大的调整。早些年为了
概述 近期碰到了一个 Linux Systemd 服务 Crash, Crash 后需要人工介入重启. 那么, 有没有办法如何实现 Linux 服务 Crash 后自动重启? Systemd Syst
七月份，波多老师线下作了一场题为“PXC、MGC&MGR原理与实践对比”的精彩分享，整场下来，干货满满，现场的童鞋都听得灰常认真，反响热烈。分享结束后，也有很多童鞋对错过了波多老师的分享而感到遗憾。
跨端技术的本质是实现代码复用，减少开发者在多平台上的适配工作量，移动互联网发展至今，跨端技术经历了许多阶段，大体上可以分成如下四类：
CAT(Central Application Tracking)是由吴其敏（前大众点评首席架构师，现携程架构负责人）主导设计基于Java开发打造的实时应用监控平台，为大众点评网提供了全面的监控服务和决策支持。
对于Android应用来说，内存向来是比较重要的性能指标。内存占用过高，会影响应用的流畅度，甚至引发OOM，非常影响用户体验。因此，内存优化也向来是行业内的重点工作项和难点工作项。
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/。
sentry是一个跨平台的错误监控和搜集的异常上报监控系统。sentry主要用于实时监控的应用服务，收集相关应用服务在运行状态时出现的异常或者错误日志信息，并且sentry会通过自身集成的通知渠道将错误信息推送给维护人员。
本文要分享的是iOS版微信内部正在推广和使用的一个高性能通用key-value 组件的技术实践过程，该组件在微信内部被命名为MMKV（以下简称MMKV）。
Dalvik Debug Monitor Service ( Dalvik调试监控服务) ,可视化的图形界面调试监控工具。不同等级log信息显示的颜色不同,使用起来方便直观。ddms监控系统或应用日志、监控线程状态、VM使用状况(内存泄漏通过它来判断)、模拟短信电话事件、生成logcat日志、文件管理及截屏等功能。
我们从事 Web 开发工作中，异常监控系统已经是我们朝夕相处的好助手，但是这些异常处理工具通常都是建立在 Web 生态，或者是假定运行在浏览器环境下的，但是当我们需要给一套跨端系统搭建一套类似的异常监控系统，并且期望该系统兼容 Web 生态，现有的工具很可能就不满足我们的需求了，因此我们需要考虑一套完整的异常监控系统整个链路将会涉及到哪些工具链，以及如何修改这些工具链来适配我们的跨端系统。
稳定性始终会是一家成功公司的重要指标，在移动端亦是如此。跟大部分创业公司一样，有赞在创业初期选择以核心业务为主， 在一些基础设施的搭建上主要以使用三方平台为主(腾讯bugly)。随着业务的发展和bugly的长期不维护，慢慢出现一些三方平台的弊端。例如：
众所周知，苹果iOS 9的推新速度已经打破了纪录，9.1刚刚于上周推出后，昨天，9.2 beta1已经出来了。 那么，到底iOS9都有哪些坑？网上能够搜索到的那些大的方面，本文不再罗列，想必每一个使用Xcode7编译的App都已经做过了相关的工作。本文只讲本团队开发过程中遇到的非常小但却非常隐蔽的“坑”“坑”“坑”！ 1问题的发现 某天，本团队正在如常监控App的Crash数据，突然发现其中多了几个特殊的Crash类型。经过汇总分析，发现了重现Crash的软硬件环境，于是尝试重现了一下，将系统升级到9.1b
爱奇艺作为中国最大的互联网视频综合门户，一直致力于给用户提供更好的使用体验及观影品质。PC主站作为爱奇艺的门户，日均覆盖用户达千万级别。随着公司业务的扩展及端上对项目更新迭代的频率越来越快，对接口的性能、响应时间、缓存策略、接口定制化等要求越来越高，需要对接的接口团队也越来越多，单纯的靠PC Web前端发送ajax请求去调用接口整合数据，会让前端的业务逻辑变得越来越复杂；同时对接团队越多也意味着会带来更多的沟通成本，不利于项目需求的快速开发迭代，而且前端调用接口属于外网调用，接口的响应时间相比内网调用会更长，导致页面渲染速度变慢，用户体验变差。
快速的业务迭代要求快速的App发版节奏，随之而来的是质量保障压力的增大。而增大自动化程度，提升QA效率就是一种非常重要的手段，以适应快速发版的要求。
内容来源：2018 年 01 月 05 日，美团高级技术专家李燕青在“2018 移动技术创新大会”进行《终端主动监控平台的建设》演讲分享。IT 大咖说（微信id：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。
前端一直是距离用户最近的一层，随着产品的日益完善，我们会更加注重用户体验，而前端异常却如鲠在喉，甚是烦人。
对于 JS 而言，我们面对的仅仅只是异常，异常的出现不会直接导致 JS 引擎崩溃，最多只会使当前执行的任务终止。
Crash率是衡量一个App好坏的重要指标之一，如果你忽略了它的存在，它就会愈演愈烈，最后造成大量用户的流失，进而给公司带来无法估量的损失。本文讲述美团外卖Android客户端团队在将App的Crash率从千分之三做到万分之二过程中所做的大量实践工作，抛砖引玉，希望能够为其他团队提供一些经验和启发。
Prometheus受启发于Google的Brogmon监控系统（相似的Kubernetes是从Google的Brog系统演变而来），从2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。
异常是不可控的，并不能确定什么时候或者什么场景会发生异常，但它却会实实在在的影响用户体验。
Crash率是衡量一个App好坏的重要指标之一。如果你忽略了它的存在，它就会得寸进尺，愈演愈烈，最后造成大量用户的流失，进而给公司带来无法估量的损失。本文讲述美团外卖Android客户端团队在将App的Crash率从千分之三做到万分之二过程中所做的大量实践工作，抛砖引玉，希望能够为其他团队提供一些经验和启发。
昨天我们进行了开发流程中的第二步架构设计，并且创建了vite+vue的项目并且引入了antd的UI组件，今天我们就进行开发流程中的比较费时间的第三部分，就是前后端功能模块的实际开发，利用程序实现自己的业务需求。
大白（Baymax），迪士尼动画《超能陆战队》中的健康机器人，是一个体型胖胖的充气机器人，因呆萌的外表和善良的本质获得大家的喜爱，被称为“萌神”。
对于传统意义的监控来说，监控系统属于安防系统中应用最多的系统之一，主要是用来监控异常和不好的事情发生，或者提供事件发生过程的记录和事后分析等功能。如视频监控系统就是典型的监控系统，视频监控系统就从早期的 CCTV 发展到 DVR到目前已经发展为基于 IP 网络的视频监控 IPVS。
前端监控包括行为监控、异常监控、性能监控等，本文主要讨论异常监控。对于前端而言，和后端处于同一个监控系统中，前端有自己的监控方案，后端也有自己等监控方案，但两者并不分离，因为一个用户在操作应用过程中如果出现异常，有可能是前端引起，也有可能是后端引起，需要有一个机制，将前后端串联起来，使监控本身统一于监控系统。因此，即使只讨论前端异常监控，其实也不能严格区分前后端界限，而要根据实际系统的设计，在最终的报表中体现出监控对开发和业务的帮助。
理解OpenShift（5）：从 Docker Volume 到 OpenShift Persistent Volume
先给大家讲个小故事吧！ 2011年底，鹅厂内部出现一个“Crash监控”的服务后，开发某App的企鹅们发现了一个真相：原来自以为很稳定的版本，结果上线后竟然……。后来，这些企鹅们就开始默默地修Crash了。再后来，鹅厂的所有App都接入了Crash监控服务。 一般的产品开发过程，都会历经几大阶段。经过多年的经验积累，企鹅们已经将Crash监控充分融入到研发流程的各个阶段。在每个研发阶段充分利用Crash监控服务，让企鹅们的研发效率和质量得到大大的提升。 开发阶段
监控是运维系统的基础，我们衡量一个公司/部门的运维水平，看他们的监控系统就可以了。一个完善的监控系统可以提高应用的可用性和可靠性，在提供更优质服务的前提下，降低运维的投入和工作量，为用户带来更多的商业利益和客户体验。下面就带大家彻底搞懂监控系统，使用Prometheus +Grafana搭建完整的应用监控系统。
为什么需要监控？ 为了保证系统的稳定性，可靠性，可运维性。 掌控集群的核心性能指标，了解集群的性能表现； 集群出现问题时及时报警，便于运维同学及时修复问题； 集群重要指标值异常时进行预警，将问题扼杀在摇篮中，不用等集群真正不可用时才采取行动； 当集群出现问题时，监控系统可以帮助我们更快的定位问题和解决问题。 如何构建 HBase 集群监控系统？ 公司有自己的监控系统，我们所要做的就是将 HBase 中我们关心的指标项发送到监控系统去，问题就转换为我们开发，采集并返回哪些 HBase 集群监控指标项。 H
监控系统是运维体系乃至整个软件产品生命周期中最重要的一环，完善的监控可以帮助我们事前及时发现故障，事后快速追查定位问题。而在以微服务为代表的云原生架构体系中，系统分为多个层次，服务之间调用链路复杂，系统中需要监控的目标非常多，如果没有一个完善的监控系统就难以保证整体服务的持续稳定。
作者 金 戈 沃趣科技技术专家 传统监控系统面临的问题 Prometheus的前身：Borgmon Borgmon介绍 应用埋点 服务发现 指标采集与堆叠 指标数据存储 指标 指标的查询 规则计算
作者：鲁可——腾讯SNG专项测试组 测试工程师 背景 承上《经典随机Crash之一：线程安全》 问题的模型 好几次灰度top1、top2 Crash发生场景：在很平常、频繁的使用页面，打开一个界面，马上返回，piaji，挂了，估计用户心中有千万只草泥马在奔腾，手机QQ究竟怎么呢？ 找到开发童鞋，还是熟悉的对话： 请教：这个Crash能复现吗？开发答：场景就在这，就是复现不了啊 这里有个空指针，那我就加个判空 我只好去看下开发童鞋的代码，发现都有一个共性，跟handler postDelayed有关系，这里抽
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
