正则表达式:使用、原理和优化

转载: 原文地址

什么是正则表达式

正则表达式描述了一种字符串匹配模式,包括普通字符(如a-z之间的字母)和特殊字符(比如.^$等有特殊意义的专用字符)。

典型的搜索和替换操作要求我们提供与预期的搜索结果匹配的确切文本。虽然这种技术对于对静态文本执行简单搜索和替换任务可能已经足够了,但它缺乏灵活性,若采用这种方法搜索动态文本,即使不是不可能,至少也会变得很困难。
比如,需要验证用户输入的电话号码符合###-###-#### 格式(#表示一个数字)时,如果不使用正则表达式,则需要遍历用户输入的每个字符,确保#位置输入的是数字,非#位置输入的是-。而使用正则表达式的话,一行语句就可以完成验证功能。

阅读全文 »

MetricKit2.0 总结

MetricKit2.0 的新功能

MetricKit 会将过去 24 小时内收集的性能数据合并,在下一次 App 启动时,通过 delegate 方法回调给我们。
MetricKit1.0 知识请参考 iOS13+ 性能和耗电量信息收集框架
以下均为 MetricKit2.0(iOS14) 新增功能.

阅读全文 »

原文地址 : 探秘越来越复杂的 ImageIO 框架

探秘越来越复杂的 ImageIO 框架

前言

ImageIO 是 Apple 提供的上层框架,用于处理常见图像格式的编解码支持。这篇文章主要讲述了三个子话题:WebP/AVIF 的支持进展,IOSurafce 和硬件解码优化 50%内存开销,以及 CGImageSource 机制变化导致的线程安全问题

ImageIO 的定位是上层的支持框架,其封装了诸多的苹果的底层解码器,开源编解码器,硬件 HEVC/ProRes 加速器等等底层细节,致力于提供和上层 UI 框架(如 UIKit/CoreGraphics)的可交互性。

阅读全文 »

Xcode14 下载 watchOS Simulator 失败

Xcode14 为了缩减体积, 将部分组件并未内置在安装包中. 当工程添加了 Watch App 支持, 开始编译时 Xcode 会自动下载 Apple Watch 的模拟器, 否则无法继续编译. 但是使用 Xcode内置的下载又经常下载失败, 报错是网络超时.

阅读全文 »

原文地址 : 快速链接:优化构建和启动耗时

[转载] 快速链接:优化构建和启动耗时

前言

什么是链接呢?我们在编写代码的同时也会使用到别人提供的库或者框架,为了让我们的代码能使用这些库,此时我们就需要一个链接器。实际上,链接有两种类型,一种是「静态链接」,它发生在编译构建 App 的时候,这一步骤会影响到构建的耗时以及 App 最终的二进制体积;另外一种是「动态链接」,它发生在 App 启动的时候,这一步骤会影响 App 的启动耗时。

在后面的内容我们将会围绕「静态链接」和「动态链接」两个概念进行讨论,最后还会介绍两个用于定位链接性能的工具:

阅读全文 »

Git 相关

lfs

转换普通文件为LFS托管

如果项目是从外部导入或从SVN导入的,本地全部历史都需进行LFS转换,且需保留历史的,请使用以下方式:

如何知道全部的commit历史中哪些文件过大?必须使用(git-lfs/2.7.1及以上版本)

阅读全文 »

原文地址 : RTC 弱网对抗之冗余策略

[转载] RTC 弱网对抗之冗余策略

背景

当下社会,实时音视频通话已经成为人们生活、工作中重要的组成部分,如商务会谈、亲朋聊天等。而在通话过程中,总会存在着这样那样的意外情况:可能你坐在飞驰的高铁上——信号时好时坏;又或者在会议途中离开办公室——网络从 wifi 切换到 4G……实现高质量的实时音视频通话需要搭建一座无视距离连接人们的“桥梁”,而这座“桥梁”需要优秀的“基建技术”来保障网络传输的稳定性和可靠性。

阅读全文 »

原文地址 : YYEVA

动画方案

概述

在目前的视频直播行业,礼物动画效果越来越酷炫。但由于动画方案和设备性能的原因,动画设计师的好多想法并没有得到很好的还原。YY的动画方案在近10年的时间也是经历了图片序列帧、SVGA、MP4、到现在的支持动态插入元素的YYEVA(YY Effect Video Animate)方案。目前已经基本能够实现设计师所见即所得,充分解放了设计师的想象力,同时能够在体积和性能上取得平衡。
在这篇文章中,我会从原理上去讲解目前市面上和YY的动画方案。也提供对比,以及分析各自的优缺点,方便开发者进行方案的选择。

阅读全文 »

原文地址 : 抖音 iOS 推荐 Feed 容器化总结

[转载]抖音 iOS 推荐 Feed 容器化总结

背景

抖音 Feed 容器在推荐、关注、同城、朋友等多个场景中使用,每个场景都有自身的逻辑和业务,最终汇总在 FeedViewController 中,随着业务的迭代,代码越来越臃肿,面临如下的问题:

  • 容器类(FeedViewController) 有 10000+行,还有十多个业务分类,整体的理解和维护成本高
  • 容器类 框架和业务边界不清晰,框架代码的修改不收敛和不规范,业务改动可能导致线上问题,如数据层不收敛导致的问题:自动删除导致一次滑动多个视频或者自动跳转到第一个视频等问题
  • 容器类 承担了推荐、关注、朋友三个大场景,细节的业务逻辑差异较多,目前多业务代码耦合在一起,增加新功能时需要考虑其他业务方,容易引入问题,开发和测试效率低
  • 内流容器和外流容器,形态相似但是代码分离,主体代码重复,新增功能时需要在两个类中做重复开发,如:视频预加载优化等,开发和维护成本高
  • 核心功能的监控和代码防劣化的体系不完善
阅读全文 »