[转载] 深入理解内存分配
相信大家在学习C语言的时候,malloc是最早遇到的几个方法之一,这里就来深入的了解下,macOS/iOS中用户空间的内存分配。
[转载] QQ 客户端性能稳定性防劣化系统 Hodor 技术方案
防劣化是比较经典的技术话题,手 Q 的防劣化系统从 2021 年 10 月开始投入研发,从 0 到 1 迭代了将近三年的时间,已经达到了业界先进水平。为了守护好手 Q 性能稳定性的门禁,我们将其命名为 Hodor 系统,即 Hold the door!
从验证可行性跑通最小闭环,到搭建群控机架一次次为集群扩容,实属不易。其中涉及到大量的方案讨论甚至推翻,很多思路和实现细节是业界找不到公开方案的,只能自己摸索。本文详细分享了手 Q 防劣化系统的构建链路,相信对业界和开发者们都有较高的借鉴意义。
产品提了一个需求, 有一个屏幕浮层, 里面有个列表, 滑动列表时候整个分层要能跟着在屏幕上挪动, 同时浮层上方还有个拖动区域, 也要能拖曳, 我们知道 UITableView
自己本身可以相应滚动手势, 列表上方可以通过一个UIPanGestureRecognizer
手势来拖曳, 但是怎么让两者之间相互适配, 更丝滑的实现滚动效果, 还是花了很多时间, 处理的细节比较多, 比如:
开发需求中, 产品经常希望知道列表中的某个元素是不是曝光了, 但是曝光的规则又会给的很复杂, 比如
甚至不同的产品不同的业务这里曝光规则都会不一样, 如果每个业务自己去单独实现, 又会有很多重复代码.
需求需要实现一个轻摇手机时候, 页面背景左右挪动, 同时图片翻转的效果, 一般我们会直接用到CMMotionManager
, CMMotionManager
是 Core Motion Framework 的一部分,它可以让我们方便地获取设备的运动数据,如加速计数据、陀螺仪数据、磁力计数据等。
但是 这个工具中能使用的传感器东西比较多, 最终我是使用 CMAcceleration.gravity 设备受到的重力的加速度 这个数据来完成的.
为什么 iOS 主流 App 显示的总大小都无法对齐系统”iPhone存储空间”内的显示?本文分析了差异的主要原因和新版快手存储空间页如何做到对齐系统,通过深入研究苹果文件系统的机制和一系列实验验证,抽丝剥茧一步步确认了iOS存储空间的显示口径。
总结
原因一:App自身大小
原因二:进制差异
原因三:口径差异
原因四:统计路径差异
我们收到用户反馈,快手App内显示的已用存储空间与iOS系统设置中显示的大小不一致。在调研了几款主流App后发现各家显示的大小和系统或多或少都有些差异,App的存储空间的占用作为近些年微博热搜的常客,这个问题引起了我们的极大的兴趣和关注。
Redis是一个高性能的开源内存数据库,以其快速的读写速度和丰富的数据结构支持而闻名。作为一个轻量级、灵活的键值存储系统,Redis在各种应用场景下都展现出了惊人的性能优势。无论是作为缓存工具、会话管理组件、消息传递媒介,还是在实时数据处理任务和复杂的分布式系统架构中,Redis均扮演了至关重要的角色。而Redis为什么快的原因也是我们尝尝遇见的高频面试问题。接下来我们就一起探讨一下Redis快的原因。
我们从 AppStore 下载的 App 一般都是被加密过的, 这是因为 iOS2.0时引入了强制代码签名(Mandatory Code Signing)技术, 只有被苹果设备认可的证书签名的代码能够被执行.
但是跟签名相关的概念十分繁杂, 各种证书,Provisioning Profile,entitlements,CertificateSigningRequest,p12,AppID,概念一堆,也很容易出错, 这里稍微梳理一下相关概念
App 需要做一个防止用户截屏的功能,在 android 可以通过设置 Activity 的 Flag 来实现。在ios中系统只提供了两个事件:
UIApplicationUserDidTakeScreenshotNotification
UIScreenCapturedDidChangeNotification
通知局限性