素问 - iOS技术

Quick tip: clearing your app’s launch screen cache on iOS

Mon, 23 Dec 2019 18:45:52 +0800

Every time I’ve had to change something in the launch screen on any of my iOS apps, I’ve faced an issue: the system caches launch images and is really bad at clearing said cache, even after the app has been deleted.

Sometimes I’d change the launch screen storyboard, delete the app and re-launch, and it would show the new storyboard, but any images referenced in the storyboard wouldn’t show up, making the launch screen appear broken.

Today, I did some digging into my app’s container and noticed that in the Library folder there’s a folder named SplashBoard, which is where the launch screen caches are stored.

So all you have to do to completely clear your app’s launch screen cache is run this code inside your app (which I’ve conveniently packaged into an extension of UIApplication):

import UIKit
public extension UIApplication { 
   func clearLaunchScreenCache() {    
       do {            
           try FileManager.default.removeItem(atPath: NSHomeDirectory()+"/Library/SplashBoard")
       } catch {     
           print("Failed to delete launch screen cache: \(error)")
       }
    }
}

Note: tested on iOS 13 only

You can put it in your app’s initialization code behind an argument flag that you enable during launch screen development, then leave it disabled when you’re not working on your launch screen.

This trick has saved me a lot of time while messing with launch screens, and I hope it will save you some time as well.

原文链接：https://rambo.codes/ios/quick-tip/2019/12/09/clearing-your-apps-launch-screen-cache-on-ios.html

iOS图片内存优化

Mon, 23 Dec 2019 17:33:19 +0800

基于现在iOS11新生成的图片都是HEIF，该图片使用UIImage(named: name)已不在那么优雅，图片大小为1.8m大小的，读进手机内存，直接飙升了45M，这是我们不想看到的结果，一个页面有多个这样子的图的话，恐怕就是灾难了。

既然原图不能读入，那么如何可以用更少的内存和CPU来解决呢?

这就要先了解该图片的编码了。

HEIC HEIF

带有元数据的HEIF的另一种形式。HEIC文件包含一个或多个以“高效图像格式”（HEIF）保存的图像，该格式通常用于在移动设备上存储照片。它可能包含单个图像或图像序列以及描述每个图像的元数据。最常使用文件扩展名“ .heic”，但HEIC文件也可能显示为.HEIF文件

heic和heif是广色域图片的格式，广色域比sRGB表示范围大25%，在广色域设备中能显示更广的色彩，sRGB 8bit/dept，广色域达到16bit/dept。广色域只是在硬件支持的情况下才能显示的。其实就是苹果搞的一个更高效体积更小效率更高的压缩方式。

加载

加载image，只是把文件信息加载到内存中，下一步就是解码。在代码中体现就是

let image = UIImage(contentsOfFile: url.path) 或 加载图片到内存 会常驻内存 let image = UIImage(named: name)! 复制代码

解码

其实是发生在添加到要显示的view上面才会解码

let imageV = UIImageView.init(image: image) imageV.frame = CGRect(x: 50, y: (250 * i) + 100, width: 200, height: 200) self.view.addSubview(imageV) 复制代码

最后一行不写，则不会解码。

渲染

当view显示出来则是渲染。过程是解码的data buffer 复制到frame buffer,硬件从帧缓冲区读取数据显示到屏幕上。

self.view.addSubview(imageV) 复制代码

内存暴涨原因

一部分图片加载到内存，在解码过程中出现了内存暴涨问题，今天探究一下原因和解决方案。

首先有请我们准备的素材和设备(6s 64g版本)

A:jpg 20M 12000*12000 B:jpg 2.8M 3024*4032 C:HEIC 1.8M 3024*4032 复制代码

素材A

APP运行内存：13.8M 加载Image: 240.3M之后稳定到220M CPU：峰值5%，随后降低到0% image占内存：226.5M 复制代码

素材B

APP运行内存：13.7M 加载Image: 31.5 CPU：峰值5%，随后降低到0% image占内存：17.8M 复制代码

素材C

APP运行内存：13.8M 加载Image: 32.3 CPU：峰值4%，随后降低到0% image占内存：18.5M 复制代码

我们猜测是否是imageView的大小影响内存的呢？ size改为原来的1/10结果运行内存还是和以前一样。

为什么呢？

内存大小不是取决于view的size，而是原始文件image size。

渲染格式

SRGB

每个像素4字节

display p3 宽色域

每个像素8字节，使用机型iphone7 、iphone8、iphone X及以后的设备，不支持该格式的机型无法显示该效果。

亮度和透明度

每个像素2字节，单一的色调和透明度，只能来显示白色和黑色之间的色值，没有其他颜色。

Alpha 8 Format

每个像素1字节，用来表示透明度，一般用作蒙版和文字。相比sRGB容量小了75%，详细宽色域容量小了87.5%

渲染图片大小计算

图片大小 = 图片格式容量 * 像素个数当我们把大小是20*20使用Alpha 8 format渲染到20*20的view上面，和40*40的image使用p3渲染到20*20的view中，后着占用内存是前者的8倍。

使用sRGB色域进行渲染所占用的大小为

imageWidth*imageHeight*4 字节 复制代码

每个像素占用了4字节，每个字节8位，

使用display p3则每个通道占用16位，那么占用内存大小是

imageWidth*imageHeight*8 字节 复制代码

如何选择正确的图片格式

不要主动选择图片格式，让格式选择你。

不要再使用UIGraphicsBeginImageContextWithOptions,该方法总是使用sRGB格式，你想节约内存是不行的，在支持p3的设备上想绘制出来p3色域的图片也是不行的。那么使用UIGraphicsImageRenderer系统可以自动为你选择格式，如果绘制image，自己再添加单色蒙版，是不需要另外单独分配内存的。

if let im = imageV { //第二次添加蒙版 im.tintColor = UIColor.black }else{ //绘制一个红色矩形 let bounds = CGRect(x: 0, y: 0, width: width, height: height) let renderer = UIGraphicsImageRenderer(bounds: bounds)  let image = renderer.image { (coxt) in UIColor.red.setFill() let path = UIBezierPath(roundedRect: bounds, cornerRadius: 20) path.addClip() UIRectFill(bounds) } imageV = UIImageView(image: image) imageV?.frame = bounds self.view.addSubview(imageV!) } 复制代码

UIImage 直接读出来需要将所有UIImage的data全部解码到内存，很耗费内存和性能。为了节省内存和降低CPU使用率，可以采用下采样。

下采样

当image素材大小是1000*1000，但是在手机上显示出来只有200*200，我们其实是没必要将1000*1000的数据都解码的，只需要缩小成200*200的大小即可，这样子节省了内存和CPU，用户感官也没有任何影响。在UIKit中使用UIGraphicsImageRenderer会有瞬间很高的内存和CPU峰值，那么

1.UIKit UIGraphicsImageRenderer

使用素材A下采样技术，使用UIKit中的UIGraphicsImageRenderer

Memory  High:16.4M normal:14.8M CPU: Hight:29% normal:0% 复制代码

func resizedImage(at url: URL, for size: CGSize) -> UIImage? { guard let image = UIImage(contentsOfFile: url.path) else { return nil } if #available(iOS 10.0, *) { let renderer = UIGraphicsImageRenderer(size: size) return renderer.image { (context) in image.draw(in: CGRect(origin: .zero, size: size)) } }else{ UIGraphicsBeginImageContext(size) image.draw(in: CGRect(origin: .zero, size: size)) let image = UIGraphicsGetImageFromCurrentImageContext() UIGraphicsEndImageContext() return image } } 复制代码

用子线程绘制，会出现CPU略微升高，当image size大很多的时候会出现内存飙升然后慢慢恢复到normal。

2.CoreGraphics CGContext上下文绘制缩略图

使用上下文绘制 cpu 和内存变化如下,CPU和内存没有大的变动解决了该问题，也做到省电、顺滑。

Memory  High:42.3M normal:14.1M CPU: Hight:6% normal:0% 复制代码

func resizedImage2(at url: URL, for size: CGSize) -> UIImage?{ guard let imageSource = CGImageSourceCreateWithURL(url as NSURL, nil), let image = CGImageSourceCreateImageAtIndex(imageSource, 0, nil) else{ return nil; } let cxt = CGContext(data: nil, width: Int(size.width), height: Int(size.height), bitsPerComponent: image.bitsPerComponent, bytesPerRow: image.bytesPerRow, space: image.colorSpace ?? CGColorSpace(name: CGColorSpace.sRGB)! , bitmapInfo: image.bitmapInfo.rawValue) cxt?.interpolationQuality = .high cxt?.draw(image, in: CGRect(origin: .zero, size: size)) guard let scaledImage = cxt?.makeImage() else { return nil } let ima = UIImage(cgImage: scaledImage) return ima } 复制代码

3.ImageIO 创建缩略图

使用ImageIO 中创建图像，CPU和内存记录反而更高了，内存也居高不下，时间上基本2s才将图像绘制出来。

Memory  High:320M normal:221M CPU: Hight:73% normal:0% 复制代码

func resizedImage3(at url: URL, for size: CGSize) -> UIImage?{ let ops:[CFString:Any] = [kCGImageSourceCreateThumbnailFromImageIfAbsent:true,   kCGImageSourceCreateThumbnailWithTransform:true,   kCGImageSourceShouldCacheImmediately:true,   kCGImageSourceThumbnailMaxPixelSize:max(size.width, size.height)] guard let imageSource = CGImageSourceCreateWithURL(url as NSURL, nil), let image = CGImageSourceCreateImageAtIndex(imageSource, 0, ops as CFDictionary) else { return nil; } let ima = UIImage(cgImage: image) printImageCost(image: ima) return ima } 复制代码

4.CoreImage 滤镜

使用滤镜处理反而有点麻烦，在iOS不是专业处理图像的APP中略微臃肿，而且性能不是很好。在重复删除添加操作，第二次出现了APP闪退问题。

Memory  High:1.04G normal:566M CPU: Hight:73% normal:0% 复制代码

 func resizedImage4(at url: URL, for size: CGSize) -> UIImage?{ let shareContext = CIContext(options: [.useSoftwareRenderer:false])  guard let image = CIImage(contentsOf: url) else { return nil } let fillter = CIFilter(name: "CILanczosScaleTransform") fillter?.setValue(image, forKey: kCIInputImageKey) fillter?.setValue(1, forKey: kCIInputScaleKey) guard let outPutCIImage = fillter?.outputImage,let outputCGImage = shareContext.createCGImage(outPutCIImage, from: outPutCIImage.extent) else { return nil } return UIImage(cgImage: outputCGImage) } 复制代码

5.使用 vImage 优化图片渲染

使用vImage创建图像性能略低，内存使用较多，步骤麻烦，是我们该舍弃的。在内存只有1G的手机上恐怕要crash了。

Memory  High:998.7M normal:566M CPU: Hight:78% normal:0% 复制代码

func resizedImage5(at url: URL, for size: CGSize) -> UIImage? {     // 解码源图像     guard let imageSource = CGImageSourceCreateWithURL(url as NSURL, nil),         let image = CGImageSourceCreateImageAtIndex(imageSource, 0, nil),         let properties = CGImageSourceCopyPropertiesAtIndex(imageSource, 0, nil) as? [CFString: Any],         let imageWidth = properties[kCGImagePropertyPixelWidth] as? vImagePixelCount,         let imageHeight = properties[kCGImagePropertyPixelHeight] as? vImagePixelCount     else {         return nil     }     // 定义图像格式     var format = vImage_CGImageFormat(bitsPerComponent: 8,                                       bitsPerPixel: 32,                                       colorSpace: nil,                                       bitmapInfo: CGBitmapInfo(rawValue: CGImageAlphaInfo.first.rawValue),                                       version: 0,                                       decode: nil,                                       renderingIntent: .defaultIntent)     var error: vImage_Error     // 创建并初始化源缓冲区     var sourceBuffer = vImage_Buffer()     defer { sourceBuffer.data.deallocate() }     error = vImageBuffer_InitWithCGImage(&sourceBuffer,                                          &format,                                          nil,                                          image,                                          vImage_Flags(kvImageNoFlags))     guard error == kvImageNoError else { return nil }     // 创建并初始化目标缓冲区     var destinationBuffer = vImage_Buffer()     error = vImageBuffer_Init(&destinationBuffer,                               vImagePixelCount(size.height),                               vImagePixelCount(size.width),                               format.bitsPerPixel,                               vImage_Flags(kvImageNoFlags))     guard error == kvImageNoError else { return nil }     // 优化缩放图像     error = vImageScale_ARGB8888(&sourceBuffer,                                  &destinationBuffer,                                  nil,                                  vImage_Flags(kvImageHighQualityResampling))     guard error == kvImageNoError else { return nil }     // 从目标缓冲区创建一个 CGImage 对象     guard let resizedImage =         vImageCreateCGImageFromBuffer(&destinationBuffer,                                       &format,                                       nil,                                       nil,                                       vImage_Flags(kvImageNoAllocate),                                       &error)?.takeRetainedValue(),         error == kvImageNoError     else {         return nil     }     return UIImage(cgImage: resizedImage) } 复制代码

内存优化

图片解码后加载在内存中的数据需要在恰当的时机删除掉，在合适的时机添加上，也是保持低内存使用率的手段。

在用户拨打电话或者进入到其他APP中可以先删除掉大图片，等回来的时候再次添加也是不错的选择。

# 1 NotificationCenter.default.addObserver(forName: UIApplication.didEnterBackgroundNotification,    object: nil,    queue: .main) {[weak self] (note) in self?.unloadImage() } NotificationCenter.default.addObserver(forName: UIApplication.willEnterForegroundNotification,    object: nil,    queue: .main) {[weak self] (note) in self?.loadImage() } # 2 override func viewWillAppear(_ animated: Bool) { super.viewWillAppear(animated) self.loadImage() } override func viewWillDisappear(_ animated: Bool) { super.viewWillDisappear(animated) self.unloadImage() } 复制代码

DemoCode download from github

总结

基于性能综合考虑方法1是最简单最合适的
使用滤镜和vImage略微复杂点，平时开发过程中可以不用考虑了。
图片解码缓存和图片大小有关，适当的下采样是不错的选择。

参考

作者：fgyong
链接：https://juejin.im/post/5ddc8258518825734f2b8eb2
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

头条穿山甲广告错误码列表

Wed, 11 Dec 2019 16:56:16 +0800

20000

成功

20001

没有合适的广告返回而导致的请求没有填充，偶尔出现属于正常情况。如果出现情况较多或者必现的话，请先检查一下广告尺寸是否填写正确，是否有使用模拟器测试广告，单个设备是否一天请求了大量广告但没有展示或者展示数极低等。排查以上问题依然没有结论可以联系技术支持同学或者提交工单（包含代码位和出现概率以及请求时间）相关同学查明后会做出回复。

40000

http content type错误

40001

http request pb错误

40002

source_type=‘app’, 请求app不能为空

40003

source_type=‘wap’, 请求wap不能为空

40004

广告位不能为空

40005

广告位尺寸不能为空

40006

广告位ID不合法，例如，位数不对或者输入的广告位ID错误。

40007

广告数量错误

40008

图片尺寸错误

40009

媒体ID不合法

40010

媒体类型不合法

40011

广告类型不合法

40013

代码位ID是开屏代码位，但是adType不是开屏

40014

redirect参数不正确

40015

媒体请求里的字段上传的不正确或不完整，需要整改，请关注站内信的整改通知。

40016

代码位ID 与应用ID 不匹配或者应用ID 缺失。初始化时需要填写appid，且在activity中需要填写代码位ID。媒体要确保这两个ID填写正确且匹配。

40017

媒体接入类型不合法 API/SDK

40018

媒体在平台上录入的包名与项目里的包名不一致。

40019

媒体在平台上申请的代码位广告类型和代码中使用的广告类型接口不一致。例如平台上是开屏的广告类型，但是代码中请求的接口是banner或者其他非开屏的广告类型，如果不太清楚不同代码位类型对应的接口，麻烦去查询SDK包里的对接文档。

40020

开发注册新上线广告位超出日请求量限制

40021

apk签名SHA1值与媒体平台录入的SHA1不一致

40022

媒体在平台上申请的代码位“是否原生”属性与代码中使用的接口不匹配。例如：

1. 媒体在平台上选择的是个性化模板banner广告的话，Android代码中请参考BannerExpressActivity进行调用；iOS代码中请参考BUDExpressBannerViewController进行调用。

2. 媒体在平台上选择的是个性化模板插屏广告的话，代码中请参考InteractionExpressActivity进行调用；iOS代码位中请参考BUDExpressInterstitialViewController进行调用。

PS：模板广告会带有express字样标识。

40023

os字段填的不对

40024

sdk 版本过低不返回广告

40025

渲染异常，分为两种情况：

1.Android版本，媒体使用了非该应用所属账号下的SDK版本导致，请媒体到该代码位所属账号下工具-文档下载展示的SDK版本去进行接入。

2.iOS版本，媒体使用2100之前的版本可能渲染异常，请媒体更新到最新版本接入即可解决该问题。

40026

使用海外ip请求国内服务器导致，请确认使用的是国内ip请求广告。

40028

ios老设备（涉及设备 iPad 4G/iPad 3G/iPhone 5/iPhone 5C/iPad Mini 1G/iPad 2G/iPhone 4S）被屏蔽，会不返回广告。在2310版本后放开了限制，媒体可以更新到2310或者之后的版本。

40029

两种情况：

1. SDK版本低：您使用的sdk版本不得低于2.5.0.0，麻烦升级到平台最新版本sdk。

2. 接口使用错误：创建的代码位类型是模板渲染/非模板渲染，但是请求方法是非模板渲染/模板渲染的方法。解决办法：使用模板渲染的方法去请求模板渲染类型或者使用非模板渲染的方法去请求非模板类型的广告，如果代码位在平台上是模板渲染，可以参考文档中个性化模板XX广告的部分，demo中参考带有express部分的代码。如果代码位不是模板渲染，则不要调用含有express字样的接口。

参考文档：https://partner.oceanengine.com/doc?id=5de4cc6d78c8690012a90aa5

50001

服务器错误

60001

show event处理错误

60002

click event处理错误

60007

激励视频验证服务器异常或处理失败

-1

数据解析失败。客户端代码问题的合集，可先排查以下情况：

1.媒体在子线程调用了show。

2.注册点击事件时viewgroup传空。

3.媒体在onFeedLoaded回调里的业务逻辑发生了异常，导致SDK走到了onError回调中。排查以上问题依然没有结论可以联系技术支持同学或者提交工单（包含代码位和出现概率以及请求时间）

-2

网络错误

-3

解析数据没有ad

-4

返回数据缺少必要字段

-5

bannerAd加载图片失败

-6

插屏广告图片加载失败

-7

开屏广告图片加载失败

-8

频繁请求

-9

请求实体为空

-10

缓存解析失败

-11

缓存过期

-12

缓存中没有开屏广告

101

渲染结果数据解析失败

102

未匹配到主模板：主模板没有下载到本地导致。偶发在首次请求广告时属于正常情况。

103

未匹配到子模板：偶发在接入初期，没有匹配到模板导致。待sdk将模板下载成功后不会出现。

104

物料数据异常

105

模版数据解析异常

106

渲染异常

107

模板渲染超时未回调，可能原因有1. 网络原因或者2. 硬件原因，因此导致渲染失败，可以更换手机或者网络环境测试。

国内外8000多个电视台一网打尽，这个开源项目要火！

Wed, 11 Dec 2019 15:43:41 +0800

平常猿妹都是和大家分享一些Github上和程序员相关的项目，比如编程面试相关的，或者是一些好用的框架等，今天，猿妹要和大家介绍一个休闲娱乐型的项目，程序员也不能整天就是写Bug，你说是不是？

今天介绍的是一个可以看电视的开源项目，国内外8000多个电视台随便你挑选，互联网协议电视（IPTV）是通过互联网协议（IP）网络传送电视内容的方法。它可以很好的适应当今网络飞速发展的趋势。

目前，已经登上Github Trending 周榜第四名，标星10781,1314个Fork（Github地址：https://github.com/iptv-org/iptv）

使用方法也很简单，首先，你需要安装一个可以M3U播放列表的开源软件，下载地址：https://www.videolan.org/vlc/download-windows.html。你也可以直接将想应的视频链接粘贴到具有支持M3U播放列表的任何播放器。

你也可以改用以下播放列表之一：

https://iptv-org.github.io/iptv/index.country.m3u （按地区分组）
https://iptv-org.github.io/iptv/index.category.m3u （按类别分组）
https://iptv-org.github.io/iptv/index.language.m3u （按语言分组）

按类别播放列表

按语言播放列表

按类别播放列表

下面，我们以中国（https://iptv-org.github.io/iptv/countries/cn.m3u）为例演示一遍。

如果你已经下载好了VLC，你只要打开运行，点击媒体-打开网络串流，输入以上地址，就可以查看中国2000多个频道：

稍等片刻，你就可以看到2200多个中国频道在你面前一列铺开，你只要选择自己想看的频道就可以了：

下面我们一起来看看效果，先来看看CCTV-1的效果：

这个画质高清度，猿妹觉得还是可以的，再来看看东南卫视：

整体觉得如何呢？国外的频道就不一一演示了，如果你对它感兴趣，可以自己尝试。

本文来自开源最前线，作者猿妹

iOS证书签名机制&重签名&防止重签名

Wed, 11 Dec 2019 15:42:23 +0800

iOS签名机制

概念

相比安卓系统随便从哪里下载都能运行，系统安全存在许多隐患，例如盗版软件、病毒入侵、静默安装等等。苹果为了控制手机上的所有应用必须是经过授权的，规定正规应用只能在AppStore下载，同时对于调试阶段的安装、灰度测试和企业分发，苹果使用双重签名机制来控制应用权限并使其不被滥用。先介绍一些概念便于后续的理解。

非对称加密

非对称加密则两份密钥，分别是公钥和私钥，用公钥加密的数据，要用私钥才能解密，用私钥加密的数据，要用公钥才能解密。正常情况下，公钥可以对外公开，而私钥需私密保存。我们常用公钥加密私钥解密的方式来进行加密防止数据明文传输，用私钥加密公钥解密的方式来签名确保数据的完整性防止被篡改。

数字摘要

将任意长度的源文本通过Hash函数计算得到一窜固定长度的文本，要保证不同源文本计算得到的值各不相同，且不能被反推得到源文本。常用的Hash算法有MD5和SHA。

数字签名

又称公钥数字签名，是非对称加密与数字摘要的结合，用于验证数据的完整性及不可抵赖性。发送方用接收方的公钥对摘要进行加密后和报文一起发送，接受方接受后用相同的Hash算法对报文进行摘要计算，接着用自己的私钥解密得到发送方的摘要，如果两个摘要相同则接收方就能确认该报文是对方发出的且未被篡改。

其他

AppStore签名

将App提交审核后，苹果会用官方的私钥对我们提交的App重签名，用户下载到手机后，iOS设备内置的公钥会对App进行验证，验证成功即可正常使用。
所以App上传到AppStore后，就跟我们本地的证书/Provisioning Profile 都没有关系了，无论是否过期或被废除，都不会影响 AppStore 上的安装包。

Xcode安装&Adhoc&In-House

对于非AppStore安装的应用苹果采用了双重签名的方式，用到了两对密钥，Mac电脑密钥对L，苹果官方密钥对A。

我们在进行开发时，会从Mac的keychain 里的 “从证书颁发机构请求证书生成”CertificateSigningRequest(含有Mac的公钥L信息)文件上传到苹果后台，苹果会用其私钥A对公钥L签名，并生成一份包含公钥L信息和苹果签名信息的开发/发布证书cer，当我们将cer下载到Mac后，keychain会把CertificateSigningRequest和证书关联起来。
在苹果后台配置AppID,可用设备IDs(企业证书不需要)和Entitlements,用这些额外信息和证书再用私钥A签名，最后苹果将证书+额外信息+签名组成一个Provisioning Profile文件(mobileprovision后缀)，下载到Mac上。
在Mac上编译完一个App后，Mac会用私钥L对App签名，并将Provisioning Profile文件也打包到App中，文件名为 embedded.mobileprovision。
安装时，苹果通过内置在手机中的公钥A验证embedded.mobileprovision中的签名是否正确，接着验证证书中的签名是否正确。
确保了 embedded.mobileprovision 里的数据都是苹果授权以后，就可以取出里面的数据，做各种验证，包括用公钥 L 验证APP签名，验证设备 ID 是否在 ID 列表上，验证证书是否过期，AppID 是否对应得上，权限开关是否跟 APP 里的 Entitlements 对应等等。

如果别的 Mac 也要编译签名这个 App，可以将私钥导出给其他 Mac 用，在 keychain 里导出私钥，就会存成.p12 文件，其他 Mac 导入了这个私钥后便可用同一套苹果证书及Provisioning Profile文件。 In-House安装不限制设备ID数。

重签名

完全重签名

重签是把已发布/未发布的包重新签名为自己的证书和签名，关键就是替换ipa内的证书和描述文件。主要通过codesign命令完成。

0 查看ipa包是否加壳，只有未加壳的包才可以重签名。

$ otool -l 「Mach-O文件」 | grep crypt
// 输出cryptid为0代表已经砸壳，即解密，为1或者2表示以第1类或者第2类加密方案加密。复制代码

1.1 查看本地证书列表并记录下要用来签名的证书名，例如"iPhone Distribution: XXXXX (XXX)"。

$ security find-identity -v -p codesigning复制代码

1.2 新建Xcode工程，用1.1证书编译后生成新App，将App包里embedded.mobileprovision文件取出替换ipa包中的文件。

2.1 删除ipa包内部可被重签名的插件（PlugIns目录下）。

2.2 将ipa包内的所有Framework重签名（Frameworks目录下）。

$ codesign -fs "iPhone Distribution: XXXXX (XXX)"  xxx.framework复制代码

2.3 查看Mach-O文件是否有系统权限，若没有则添加权限。

$ chmod +x 「Mach-O文件」复制代码

3.1 将ipa包内info.plist的BundleId修改为1.1中工程的BundleId。

3.2 用命令查看embedded.mobileprovision文件，找到其中的entitlements字段，并且复制entitlements字段和其中的内容。

$ security cms -D -i 「embedded文件路径」复制代码

3.3 新建entitlements.plist文件，将复制内容拷贝到文件中，然后将entitlements.plist复制到ipa的同级目录下。

3.4 对App进行重签名，并压缩成新的ipa包。

//重签名
$ codesign -fs "iPhone Distribution: XXXXX (XXX)" --no-strict --entitlements=entitlements.plist

//压缩ipa包
$ zip -r 「输出的文件名(.ipa)」 Payload/复制代码

4 将ipa包安装到手机，若能同时存在两个应用且能正常运行则表示重签名成功。

Shell脚本重签名

# ${SRCROOT} 它是工程文件所在的目录
TEMP_PATH="${SRCROOT}/Temp"
#资源文件夹，我们提前在工程目录下新建一个APP文件夹，里面放ipa包
ASSETS_PATH="${SRCROOT}/APP"
#目标ipa包路径
TARGET_IPA_PATH="${ASSETS_PATH}/*.ipa"
#清空Temp文件夹
rm -rf "${SRCROOT}/Temp"
mkdir -p "${SRCROOT}/Temp"

#----------------------------------------
# 1. 解压IPA到Temp下
unzip -oqq "$TARGET_IPA_PATH" -d "$TEMP_PATH"
# 拿到解压的临时的APP的路径
TEMP_APP_PATH=$(set -- "$TEMP_PATH/Payload/"*.app;echo "$1")
# echo "路径是:$TEMP_APP_PATH"

#----------------------------------------
# 2. 将解压出来的.app拷贝进入工程下
# BUILT_PRODUCTS_DIR 工程生成的APP包的路径
# TARGET_NAME target名称
TARGET_APP_PATH="$BUILT_PRODUCTS_DIR/$TARGET_NAME.app"
echo "app路径:$TARGET_APP_PATH"

rm -rf "$TARGET_APP_PATH"
mkdir -p "$TARGET_APP_PATH"
cp -rf "$TEMP_APP_PATH/" "$TARGET_APP_PATH"

#----------------------------------------
# 3. 删除extension和WatchAPP.个人证书没法签名Extention
rm -rf "$TARGET_APP_PATH/PlugIns"
rm -rf "$TARGET_APP_PATH/Watch"

#----------------------------------------
# 4. 更新info.plist文件 CFBundleIdentifier
#  设置:"Set : KEY Value" "目标文件路径"
/usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier $PRODUCT_BUNDLE_IDENTIFIER" "$TARGET_APP_PATH/Info.plist"
#----------------------------------------

# 5. 给MachO文件上执行权限
# 拿到MachO文件的路径
APP_BINARY=`plutil -convert xml1 -o - $TARGET_APP_PATH/Info.plist|grep -A1 Exec|tail -n1|cut -f2 -d\>|cut -f1 -d\<`
#上可执行权限
chmod +x "$TARGET_APP_PATH/$APP_BINARY"

#----------------------------------------
# 6. 重签名第三方 FrameWorks
TARGET_APP_FRAMEWORKS_PATH="$TARGET_APP_PATH/Frameworks"
if [ -d "$TARGET_APP_FRAMEWORKS_PATH" ];
then
for FRAMEWORK in "$TARGET_APP_FRAMEWORKS_PATH/"*
do

# 签名
/usr/bin/codesign --force --sign "$EXPANDED_CODE_SIGN_IDENTITY" "$FRAMEWORK"
done
fi复制代码

如何防止应用被重签名

内容来源于「iOS安全防护之重签名防护和sysctl反调试」。

校验描述文件信息

可以在启动时校验描述文件信息与打包时是否一致。例如判断组织单位:
先记录证书中的组织单位信息。

在启动时检测是否一致。

void  checkCodesign(NSString *id){
    // 描述文件路径
    NSString *embeddedPath = [[NSBundle mainBundle] pathForResource:@"embedded" ofType:@"mobileprovision"];
    // 读取application-identifier  注意描述文件的编码要使用:NSASCIIStringEncoding
    NSString *embeddedProvisioning = [NSString stringWithContentsOfFile:embeddedPath encoding:NSASCIIStringEncoding error:nil];
    NSArray *embeddedProvisioningLines = [embeddedProvisioning componentsSeparatedByCharactersInSet:[NSCharacterSet newlineCharacterSet]];
    
    for (int i = 0; i < embeddedProvisioningLines.count; i++) {
        if ([embeddedProvisioningLines[i] rangeOfString:@"application-identifier"].location != NSNotFound) {
            
            NSInteger fromPosition = [embeddedProvisioningLines[i+1] rangeOfString:@""].location+8;
            
            NSInteger toPosition = [embeddedProvisioningLines[i+1] rangeOfString:@""].location;
            
            NSRange range;
            range.location = fromPosition;
            range.length = toPosition - fromPosition;
            
            NSString *fullIdentifier = [embeddedProvisioningLines[i+1] substringWithRange:range];
            NSArray *identifierComponents = [fullIdentifier componentsSeparatedByString:@"."];
            NSString *appIdentifier = [identifierComponents firstObject];
       
            // 对比签名ID
            if (![appIdentifier isEqual:id]) {
                //exit
                asm(
                    "mov X0,#0\n"
                    "mov w16,#1\n"
                    "svc #0x80"
                    );
            }
            break;
        }
    }
}复制代码

sysctl检测是否被调试

#import bool checkDebugger(){
    //控制码
    int name[4];//放字节码-查询信息
    name[0] = CTL_KERN;//内核查看
    name[1] = KERN_PROC;//查询进程
    name[2] = KERN_PROC_PID; //通过进程id查进程
    name[3] = getpid();//拿到自己进程的id
    //查询结果
    struct kinfo_proc info;//进程查询信息结果
    size_t info_size = sizeof(info);//结构体大小
    int error = sysctl(name, sizeof(name)/sizeof(*name), &info, &info_size, 0, 0);
    assert(error == 0);//0就是没有错误
    
    //结果解析 p_flag的第12位为1就是有调试
    //p_flag 与 P_TRACED =0 就是有调试
    return ((info.kp_proc.p_flag & P_TRACED) !=0);
   
}
...
...
//检测异常时退出
if (checkDebugger()) {
        asm("mov X0,#0\n"
            "mov w16,#1\n"
            "svc #0x80"
            );
       
    }
...复制代码

参考链接

iOS App 签名的原理
 iOS逆向(3)-APP重签名
 iOS安全防护之重签名防护和sysctl反调试

本文来自 juejin ，作者 SimonYe

CocoaPods指定版本号带~>与不带的区别

Wed, 11 Dec 2019 14:43:21 +0800

带~> 是指定一个范围的版本号

~> 大于等于指定的版本号，小于高一位的版本号

eg：
~> 0.1.x 0.2以下 0.1.x以上(包括0.1.x)
~> 0.1 1以下 0.1以上(包括0.1)

pod 'AFNetworking', '~> 1.0' 版本号可以是1.0，可以是1.1，1.9，但必须小于2

不带~> 是指定固定的版本号

pod 'AFNetworking', '1.0' // 版本号指定为1.0

作者：ChancePro
链接：https://www.jianshu.com/p/68e6f6deaf98
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

ffmpeg常用基本命令

Wed, 11 Dec 2019 13:43:46 +0800

1.分离视频音频流

ffmpeg -i input_file -vcodec copy -an output_file_video　　//分离视频流
ffmpeg -i input_file -acodec copy -vn output_file_audio　　//分离音频流

2.视频解复用

ffmpeg –i test.mp4 –vcodec copy –an –f m4v test.264ffmpeg –i test.avi –vcodec copy –an –f m4v test.264

3.视频转码

ffmpeg –i test.mp4 –vcodec h264 –s 352*278 –an –f m4v test.264              //转码为码流原始文件
ffmpeg –i test.mp4 –vcodec h264 –bf 0 –g 25 –s 352*278 –an –f m4v test.264  //转码为码流原始文件
ffmpeg –i test.avi -vcodec mpeg4 –vtag xvid –qsame test_xvid.avi            //转码为封装文件//-bf B帧数目控制，-g 关键帧间隔控制，-s 分辨率控制

4.视频封装

ffmpeg –i video_file –i audio_file –vcodec copy –acodec copy output_file

5.视频剪切

ffmpeg –i test.avi –r 1 –f image2 image-%3d.jpeg        //提取图片
ffmpeg -ss 0:1:30 -t 0:0:20 -i input.avi -vcodec copy -acodec copy output.avi    //剪切视频//-r 提取图像的频率，-ss 开始时间，-t 持续时间

6.视频录制

ffmpeg –i rtsp://192.168.3.205:5555/test –vcodec copy out.avi

7.YUV序列播放

ffplay -f rawvideo -video_size 1920x1080 input.yuv

8.YUV序列转AVI

ffmpeg –s w*h –pix_fmt yuv420p –i input.yuv –vcodec mpeg4 output.avi

常用参数说明：

主要参数： -i 设定输入流 -f 设定输出格式 -ss 开始时间 视频参数： -b 设定视频流量，默认为200Kbit/s -r 设定帧速率，默认为25 -s 设定画面的宽与高 -aspect 设定画面的比例 -vn 不处理视频 -vcodec 设定视频编解码器，未设定时则使用与输入流相同的编解码器 音频参数： -ar 设定采样率 -ac 设定声音的Channel数 -acodec 设定声音编解码器，未设定时则使用与输入流相同的编解码器 -an 不处理音频

------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------

0.压缩转码mp4文件

ffmpeg -i input.avi -s 640x480 output.avi

ffmpeg -i input.avi -strict -2 -s vga output.avi

1、将文件当做直播送至live

ffmpeg -re -i localFile.mp4 -c copy -f flv rtmp://server/live/streamName

2、将直播媒体保存至本地文件

ffmpeg -i rtmp://server/live/streamName -c copy dump.flv

3、将其中一个直播流，视频改用h264压缩，音频不变，送至另外一个直播服务流

ffmpeg -i rtmp://server/live/originalStream -c:a copy -c:v libx264 -vpre slow -f flv rtmp://server/live/h264Stream

4、将其中一个直播流，视频改用h264压缩，音频改用faac压缩，送至另外一个直播服务流

ffmpeg -i rtmp://server/live/originalStream -c:a libfaac -ar 44100 -ab 48k -c:v libx264 -vpre slow -vpre baseline -f flv rtmp://server/live/h264Stream

5、将其中一个直播流，视频不变，音频改用faac压缩，送至另外一个直播服务流

ffmpeg -i rtmp://server/live/originalStream -acodec libfaac -ar 44100 -ab 48k -vcodec copy -f flv rtmp://server/live/h264_AAC_Stream

6、将一个高清流，复制为几个不同视频清晰度的流重新发布，其中音频不变

ffmpeg -re -i rtmp://server/live/high_FMLE_stream -acodec copy -vcodec x264lib -s 640×360 -b 500k -vpre medium -vpre baseline rtmp://server/live/baseline_500k -acodec copy -vcodec x264lib -s 480×272 -b 300k -vpre medium -vpre baseline rtmp://server/live/baseline_300k -acodec copy -vcodec x264lib -s 320×200 -b 150k -vpre medium -vpre baseline rtmp://server/live/baseline_150k -acodec libfaac -vn -ab 48k rtmp://server/live/audio_only_AAC_48k

7、功能一样，只是采用-x264opts选项

ffmpeg -re -i rtmp://server/live/high_FMLE_stream -c:a copy -c:v x264lib -s 640×360 -x264opts bitrate=500:profile=baseline:preset=slow rtmp://server/live/baseline_500k -c:a copy -c:v x264lib -s 480×272 -x264opts bitrate=300:profile=baseline:preset=slow rtmp://server/live/baseline_300k -c:a copy -c:v x264lib -s 320×200 -x264opts bitrate=150:profile=baseline:preset=slow rtmp://server/live/baseline_150k -c:a libfaac -vn -b:a 48k rtmp://server/live/audio_only_AAC_48k

8、将当前摄像头及音频通过DSSHOW采集，视频h264、音频faac压缩后发布

ffmpeg -r 25 -f dshow -s 640×480 -i video=”video source name”:audio=”audio source name” -vcodec libx264 -b 600k -vpre slow -acodec libfaac -ab 128k -f flv rtmp://server/application/stream_name

9、将一个JPG图片经过h264压缩循环输出为mp4视频

ffmpeg.exe -i INPUT.jpg -an -vcodec libx264 -coder 1 -flags +loop -cmp +chroma -subq 10 -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -flags2 +dct8x8 -trellis 2 -partitions +parti8x8+parti4x4 -crf 24 -threads 0 -r 25 -g 25 -y OUTPUT.mp4

10、将普通流视频改用h264压缩，音频不变，送至高清流服务(新版本FMS live=1)

ffmpeg -i rtmp://server/live/originalStream -c:a copy -c:v libx264 -vpre slow -f flv “rtmp://server/live/h264Stream live=1〃

------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------

1.采集usb摄像头视频命令：

ffmpeg -t 20 -f vfwcap -i 0 -r 8 -f mp4 cap1111.mp4

./ffmpeg -t 10 -f vfwcap -i 0 -r 8 -f mp4 cap.mp4

具体说明如下：我们采集10秒，采集设备为vfwcap类型设备，第0个vfwcap采集设备（如果系统有多个vfw的视频采集设备，可以通过-i num来选择），每秒8帧，输出方式为文件，格式为mp4。

2.最简单的抓屏：

ffmpeg -f gdigrab -i desktop out.mpg

3.从屏幕的（10,20）点处开始，抓取640x480的屏幕，设定帧率为5 ：

ffmpeg -f gdigrab -framerate 5 -offset_x 10 -offset_y 20 -video_size 640x480 -i desktop out.mpg

4.ffmpeg从视频中生成gif图片：

ffmpeg -i capx.mp4 -t 10 -s 320x240 -pix_fmt rgb24 jidu1.gif

5.ffmpeg将图片转换为视频：

http://blog.sina.com.cn/s/blog_40d73279010113c2.html

Xcode11 打包IPA上传App Store失败解决办法 xcrun altool密钥上传

Sun, 08 Dec 2019 22:09:20 +0800

缘由

Xcode更新11之后，不再包含Application Loader。听说为了更好的支持ipadOS、macOS、iOS统一管理，推荐使用xcodebuild 或 xcrun altool从Organizer或命令行上传应用程序。详情见Xcode更新日志(29008875)说明。

本人在更新Xcode11之后使用Organizer上传应用一直出现失败，于是改用xcrun altool进行验证和上传应用，用了之后发现 ~真香。。。

如何使用`xcrun altool`

废话不多说，xcrun altool之前可以使用开发者账号和密码进行-登录-验证-上传。但听说不行了，现在需要用密钥的方式，用到的2个命令如下：

验证: xcrun altool --validate-app -f xxx.ipa -t ios --apiKey xxx --apiIssuer xxx --verbose

上传: xcrun altool --upload-app -f xxx.ipa -t ios --apiKey xxx --apiIssuer xxx --verbose

2个命令分别对应验证IPA 和上传IPA，都需要使用3个参数ipa路径、apiKey、apiIssuer

一：路径不用说了，可以使用`xcodebuild`打包或用`Organizer`Export导出App store包。

二：`apiKey`和`apiIssuer`需要去开发者官网-用户和访问-密钥-去新增。如下图流程

选择密钥
新增一个密钥，名称和访问者可以自由填写
生成完成后，IssuerID就是apiIssuer，密钥ID就是apiKey，并且还有一个API密钥可以下载()

三：到这一步先别急执行命令，执行了也会出错，按照`xcrun altool`官方文档说明

apiKey. Required for JWT authentication while using validation, upload, and notarization.This option will search the following directories in sequence for a private key file
with the name of 'AuthKey_<api_key>.p8':  './private_keys', '~/private_keys', '~/.private_keys',and '~/.appstoreconnect/private_keys'.

我们需要把刚才下载好的密钥文件放到这里面的其中一个文件夹里，它会按顺序去查找。我自己是在用户目录下/Users/payne/private_keys新建了个private_keys文件夹，并把密钥文件放进去的。

四：接下来把参数替换上去，可以尝试进行验证和上传了。

等到提示No errors uploading时就代表上传成功了，可以去开发者中心-活动里面查看一下是否有构建版本

五：OK，已经有了，到这里就大功告成了。是不是真香。。。

作者：老坛泡菜
链接：https://www.jianshu.com/p/52a1b9a42afa
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

iOS多线程编程：线程同步总结

Sun, 08 Dec 2019 10:06:56 +0800

1：原子操作 - OSAtomic系列函数

iOS平台下的原子操作函数都以OSAtomic开头，使用时需要包含头文件<libkern/OSBase.h>。不同线程如果通过原子操作函数对同一变量进行操作，可以保证一个线程的操作不会影响到其他线程内对此变量的操作，因为这些操作都是原子式的。因为原子操作只能对内置类型进行操作，所以原子操作能够同步的线程只能位于同一个进程的地址空间内。

2：锁 - NSLock系列对象

iOS平台下的锁对象为NSLock对象，进入锁通过调用lock函数，解锁调用unlock函数（因为iOS中大部分的线程同步类都继承自NSLocking协议，所以其加锁/解锁的操作基本都为lock/unlock函数），同一个NSLock对象成功调用lock函数后，在其显式unlock之前任何线程都不能再对此NSLock对象加锁，以达到互斥访问的目的。除了lock函数，对NSLock加锁的函数还包括tryLock以及lockBeforeDate函数，lock函数在成功加锁之间会一直阻塞，而tryLock会尝试加锁，如果不成功，不会阻塞，而是直接返回NO，lockBeforeDate则是阻塞到传入的NSDate日期为止。

除了NSLock，iOS还提供了NSRecursive、NSConditionLock类型的锁类型。NSRecursive与NSLock最大的区别就是NSRecursive是可重入的，也就是说一个线程可以对一个NSRecursive对象多次调用lock，只要解锁时调用相同次数的unlock函数便可。NSConditionLock是一种带有条件的锁对象，除了基本的lock与unlock函数，还提供了lockWithCondition以及unlockWithCondition，这两个函数接收整型类型的数据作为参数，只有当一个unlockWithCondition对象被调用时，对应的lockWithCondition才会正常返回。这种机制在需几多个线程顺序化的完成某个任务时比较有用，例程如下：

//线程A

id condLock = [[NSConditionLock alloc] initWithCondition:NO_DATA];

while(true)

{

[condLock lock];

/* Add data to the queue. */

[condLock unlockWithCondition:HAS_DATA];

}

//线程B

while (true)

{

[condLock lockWhenCondition:HAS_DATA];

/* Remove data from the queue. */

[condLock unlockWithCondition:(isEmpty ? NO_DATA : HAS_DATA)];

// Process the data locally.

}

除了显示的生成NSLock系列对象，还可以通过将代码放到@synchronized内来达到同步的目的，一段放入其内的代码，不同的线程是不能重入的例如：

- (void)myMethod:(id)anObj

{

@synchronized(anObj)

{

//此处代码在同一时刻只能有一个线程执行.

}

NSLock系列对象都是可以具名的，也就是说，这些对象可以用于不同进程内部的线程的同步。

3：事件 - NSCondtion

NSConditon类型提供了wait与signal函数，分别代表了等待事件的操作以及触发事件的操作。除了wait函数，NSCondition还提供了waitUntilDate函数，其功能与NSLock中的lockBeforeDate大致相同，简要来说就是提供了一个带超时的wait函数。

虽然NSCondition与Windows环境下Event类型所完成的功能大致类似，但对一个熟悉Event类型的开发人员来说，NSConditon的行为会有点奇怪：

第一点：因为遵循NSLocking协议，所以NSCondition在触发与等待过程的前后要分别调用lock与unlock函数，前面提到过，当一个遵循NSLocking协议的对象调用lock后，其他的对此对象的lock调用都会阻塞。那么，如果两个线程A和B，A要触发事件，B接收事件，B线程在调用lock后，通过调用wait函数进入等待事件触发的状态，那么，A线程岂不是再也没有机会对这个事件进行触发了（因为此对象已经被B线程lock）？秘密就在于wait函数的调用，其实，在wait函数内部悄悄的调用了unlock函数，也就是说在调用wati函数后，这个NSCondition对象就处于了无锁的状态，这样A线程就可以对此对象加锁并触发该NSCondition对象。当一个事件被其他线程触发时，在wait函数内部得到此事件被触发的通知，然后对此事件重新调用lock函数，然后函数返回，而在函数外部，看起来好像接收事件的线程从来没有放开NSCondition对象的所有权，B线程直接由阻塞状态进入了触发状态。

第二点：当有多个线程进入阻塞状态，等待同一个AutoReset的Event对象被触发时，在Windows环境下唤醒哪一个线程是没有固定的顺序的，也就是说操作系统对唤醒哪一个线程不会提供任何的保证。而在iOS平台上，经过笔者测试，其被触发的顺序与，并且只与调用wait函数的顺序相关，与其他（比如线程优先级）条件没有关系。这一点在开发时需要进行额外的考虑。

第三点：wait函数并不是完全可信的。这一点比较让人蛋疼，也就是说wait返回后，并不代表对应的事件一定被触发了，因此，为了保证线程之间的同步关系，使用NSCondtion时往往需要加入一个额外的变量来对非正常的wait返回进行规避。具体示例代码如下：

//等待事件触发的线程

[cocoaCondition lock];

while (timeToDoWork <= 0)

[cocoaCondition wait];

timeToDoWork--;

// Do real work here.

[cocoaCondition unlock];

//出发事件的线程

[cocoaCondition lock];

timeToDoWork++;

[cocoaCondition signal];

[cocoaCondition unlock];

这个timeToDoWork就是那个额外需要的变量，在NSCondition的使用中，这个变量是必不可少的。

NSConditon对象也是具名的，也就是说，其可于不同进程内部的线程同步。

相较于Windows平台下提供的丰富的线程同步机制，iOS下的线程同步机制稍显单薄，但也正是这种简洁简化了其使用。

参考：iOS Developer Liabray

示例代码来源：Thread Programming Guide

注：文中所指的线程同步泛指多线程环境下的同步与互斥。

————————————————

原文链接：https://blog.csdn.net/lifengzhong/article/details/7487505

Optimizing Images

Sun, 08 Dec 2019 10:05:45 +0800

They say the best camera is the one you have with you. If that adage holds any weight, then without question - stem to stern the iPhone is the most important camera on the planet. And our industry shows it, too.

On a vacation? It didn’t happen if it’s not documented on your Instagram story with several candid shots.

Breaking news? Check Twitter and see what outlets are reporting on by peeping their photos of an event unfolding in real time.

Etcetera.

But for all of their ubiquity on the platform, the act of showing them in a performant and memory conservative manner can easily turn into a mismanaged endeavor. With a little know how as to what’s happening in UIKit and why in regards to how it treats images, one can gain some massive savings and forgo the unrelenting wrath of jetsam.

In Theory

Pop quiz - how much memory will this 266 kilobyte (and quite dashing) photo of my beautiful daughter require in an iOS app?

Spoiler alert - it’s not 266 kilobytes. It’s not 2.66 megabytes. It’s around 14 megabytes.

Why?

iOS essentially derives its memory hit from an image’s dimensions - whereas the actual file size has much less to do with it. And the dimensions for this photo sit at 1718 pixels wide by 2048 pixels tall. Assuming each pixel will cost us four bytes:

1718 * 2048 * 4 / 1024 / 1024 = 13.42 megabytes give or take

Imagine if you’ve got a table view with a list of users, and each row shows the now pervasive circle avatar of their photo to the left. If you’re thinking things are kosher because each one has been packed up nice and tight from ImageOptim or something similar, that might not be the case. If each one is a conservative 256x256 you could still be taking quite a hit on memory.

The Rendering Pipeline

All that to say - it’s worth knowing what’s going on under the hood. When you load up an image, it’s going to be processed in three steps:

1) Load - iOS takes the compressed image and loads (in our example) the 266 kilobyte into memory. Really no worries yet.
2) Decode - Now, iOS takes the image and converts into a way the GPU can read and understand. It’s now uncompressed, and it’s here we’re at the 14MB size listed above.
3) Render - Just like it sounds, the image data is ready and willing to be rendered any which way. Even if it’s just by a 60 by 60 point image view.

The decoding phase is the big one. Here, iOS has created a buffer - specifically an image buffer, that’s got an in-memory representation of the image. So it stands to reason that this size is intrinsically tied to the proportions of the image itself and not its file size. This paints a clear picture of why the dimensions are so important when it comes to your memory consumption when working with images.

For UIImage in particular, when we give it image data we received from a network hit or some other source, it decodes that data buffer to whatever compression the data says it’s encoded in (think PNG or JPEG). However, it’ll actually hang onto it as well. Since rendering is not a one shot operation, the UIImage keeps that image buffer around so it’s only decoding things one time.

Expanding on this idea - one integral buffer for any iOS app is its frame buffer. This is what’s responsible for actually showing your iOS app as it appears on screen since it holds the rendered output of its contents. The display hardware on any iOS device uses this per-pixel information to literally illuminate the very pixels on the physical screen.

And timing matters here. To get the buttery smooth 60 frames per second scrolling, the frame buffer will need to have UIKit render the app’s window and it’s subsequent subviews into it when their information changes (i.e. assigning an image to an image view). If you do that slow, you drop a frame.

Think 1/60th of a second is short on time? Pro Motion devices up the ante to 1/120th of a second.

Size Does Matter

We can visualize this process and memory being consumed pretty easily. Using the picture of my daughter, I created a trivial app that shows an image view with that exact image within it:

let filePath = Bundle.main.path(forResource:"baylor", ofType: "jpg")!let url = NSURL(fileURLWithPath: filePath)let fileImage = UIImage(contentsOfFile: filePath)// Image viewlet imageView = UIImageView(image: fileImage)imageView.translatesAutoresizingMaskIntoConstraints = falseimageView.contentMode = .scaleAspectFitimageView.widthAnchor.constraint(equalToConstant: 300).isActive = trueimageView.heightAnchor.constraint(equalToConstant: 400).isActive = trueview.addSubview(imageView)imageView.centerXAnchor.constraint(equalTo: view.centerXAnchor).isActive = trueimageView.centerYAnchor.constraint(equalTo: view.centerYAnchor).isActive = true

Mind the force unwraps in production. Here we’re using a simple example scenario.

Which gives us this:

A quick trip to LLDB shows us the image dimensions we’re working with, even though we’re using a much smaller image view to display it:

<UIImage: 0x600003d41a40>, {1718, 2048}

A remember - that’s in points. So if I’m on a 3x or 2x device then you could potentially multiply that number even more so. Let’s take a quick trip down vmmap to see if we can confirm that around 14 megabytes are being used from this one image:

vmmap --summary baylor.memgraph

A few things stick out (truncated for brevity):

Physical footprint:         69.5MPhysical footprint (peak):  69.7M

We’re sitting at almost 70 megabytes which gives us a nice baseline to confirm any refactor against. If we grep down into Image IO we can likely see some of the cost of our image as well:

vmmap --summary baylor.memgraph | grep "Image IO"Image IO  13.4M   13.4M   13.4M    0K  0K  0K   0K  2

Ah - there’s about 14 megabytes of dirty memory right there. That’s what our back-of-the-napkin math hypothesized our image would cost. For context, here’s a quick screenshot of Terminal to clearly illustrate what each column means since they were omitted from our greppin’:

So clearly, we’re paying the full cost of the image in our 300 x 400 image view at this point. The size of the image can be key, but it’s also not the only thing that matters.

Color Space

Part of the memory you’ll be requesting for is determined by yet another important factor - the color space. In the example above we made an assumption that likely isn’t the case with most iPhones - that the image was utilizing the sRGB format. The 4 bytes per pixel is figured up by giving one byte for red, blue, green and the alpha component.

If you’re shooting with a device that supports the wide color format (for example, an iPhone 8+ or iPhone X) then you likely can double the hit across the board. Of course, the reverse is true as well. Metal can use the Alpha 8 format which has only a single channel to its name.

It can be a lot to manage and think about. This is one reason why you should use UIGraphicsImageRenderer instead of UIGraphicsBeginImageContextWithOptions. The latter will always use sRGB which means you could miss the wide format if you want it, or miss out on the savings if you’re going smaller. As of iOS 12, UIGraphicsImageRenderer is going to pick the right one for you.

Lest we forget, a lot of images that crop up aren’t really of the photographed variety but rather trivial drawing operations. Not to rehash what I wrote about recently, but in case you missed it:

let circleSize = CGSize(width: 60, height: 60)UIGraphicsBeginImageContextWithOptions(circleSize, true, 0)// Draw a circlelet ctx = UIGraphicsGetCurrentContext()!UIColor.red.setFill()ctx.setFillColor(UIColor.red.cgColor)ctx.addEllipse(in: CGRect(x: 0, y: 0, width: circleSize.width, height: circleSize.height))ctx.drawPath(using: .fill)let circleImage = UIGraphicsGetImageFromCurrentImageContext()UIGraphicsEndImageContext()

This circle image above is using a 4 byte per pixel format. If you roll with UIGraphicsImageRenderer you can potentially open things up for up to a 75% savings by getting 1 byte per pixel by letting the renderer opt into the correct format automatically:

let circleSize = CGSize(width: 60, height: 60)let renderer = UIGraphicsImageRenderer(bounds: CGRect(x: 0, y: 0, width: circleSize.width, height: circleSize.height))let circleImage = renderer.image{ ctx in
    UIColor.red.setFill()
    ctx.cgContext.setFillColor(UIColor.red.cgColor)
    ctx.cgContext.addEllipse(in: CGRect(x: 0, y: 0, width: circleSize.width, height: circleSize.height))
    ctx.cgContext.drawPath(using: .fill)}

Downscaling vs Downsampling

Moving past simple drawing scenarios - a lot of the issues with images and their impact on memory originate from the typical photos that we associate with the actual art of photography. Think portraits, landscape shots and more.

It stands to reason that some engineers might assume (and, logically so) that simply downscaling them via UIImage will suffice. But it typically won’t due to the reasons above, and it’s also not as performant due to internal coordinate space transforms according to Apple’s Kyle Howarth.

UIImage becomes an issue here primarily because it will decompress the original image into memory as we discussed when looking at the rendering pipeline. We need a way to reduce the size of our image buffer, ideally.

Thankfully, it’s possible to resize the images at the cost of the actual resized image only, which is what one might assume is happening already when it typically isn’t.

Let’s try dropping down into a lower level API to downsample it instead:

let imageSource = CGImageSourceCreateWithURL(url, nil)!let options: [NSString:Any] = [kCGImageSourceThumbnailMaxPixelSize:400,
                               kCGImageSourceCreateThumbnailFromImageAlways:true]if let scaledImage = CGImageSourceCreateThumbnailAtIndex(imageSource, 0, options as CFDictionary) {
    let imageView = UIImageView(image: UIImage(cgImage: scaledImage))
    
    imageView.translatesAutoresizingMaskIntoConstraints = false
    imageView.contentMode = .scaleAspectFit
    imageView.widthAnchor.constraint(equalToConstant: 300).isActive = true
    imageView.heightAnchor.constraint(equalToConstant: 400).isActive = true
    
    view.addSubview(imageView)
    imageView.centerXAnchor.constraint(equalTo: view.centerXAnchor).isActive = true
    imageView.centerYAnchor.constraint(equalTo: view.centerYAnchor).isActive = true}

Display wise, we’ve got the exact same result as before. But here, we’re using CGImageSourceCreateThumbnailAtIndex() instead of just putting the vanilla image into the image view. The source of truth will lie within vmmap once more to see if our optimizations have paid off (again, truncated for brevity):

vmmap -summary baylorOptimized.memgraphPhysical footprint:         56.3MPhysical footprint (peak):  56.7M

And the savings have rolled in. If we compare the 69.5M from before to the 56.3M now we get a savings of 13.2M. That’s a huge savings, almost the whole cost of the image.

Further, you can play around with the many options available to hone things for your use case. In session 219, “Images and Graphics Best Practices” from WWDC 18, Apple engineer Kyle Sluder showed an interesting way to control when decoding happens by using the kCGImageSourceShouldCacheImmediately flag:

func downsampleImage(at URL:NSURL, maxSize:Float) -> UIImage{
    let sourceOptions = [kCGImageSourceShouldCache:false] as CFDictionary
    let source = CGImageSourceCreateWithURL(URL as CFURL, sourceOptions)!
    let downsampleOptions = [kCGImageSourceCreateThumbnailFromImageAlways:true,
                             kCGImageSourceThumbnailMaxPixelSize:maxSize
                             kCGImageSourceShouldCacheImmediately:true,
                             kCGImageSourceCreateThumbnailWithTransform:true,
                             ] as CFDictionary
    
    let downsampledImage = CGImageSourceCreateThumbnailAtIndex(source, 0, downsampleOptions)!
    
    return UIImage(cgImage: downsampledImage)}

Here Core Graphics won’t bother decoding the image until you specifically ask for the thumbnail. Also, take care to pass kCGImageSourceCreateThumbnailMaxPixelSize as we’ve done in both examples because if you don’t - you’re getting back a thumbnail which is the same size of the image. From the docs:

“…if a maximum pixel size isn’t specified, then the thumbnail will be the size of the full image, which probably isn’t what you want.”

So what happened? In short, we created a much smaller decoded image buffer than before by putting the shrinking part of equation into a thumbnail. Thinking back on our rendering pipeline, for the first part (the load) we instead passed an image buffer that represented only the size of the image view we’re showing it in instead of reflecting the entire image’s dimensions for the UIImage to decode.

Want a TL;DR for this entire article? Look for opportunities to downsample images instead of using UIImage to downscale them.

Bonus Points

I personally use this in tandem with the prefetch API introduced in iOS 11. Remember that we’re inherently introducing spikes in CPU usage since we’re decoding images even if we’re doing it ahead of when the table or collection view might need our cell.

Since iOS is efficient at managing power demand when there is a constant need for it and in this case it’ll likely be intermittent, it’s good to hop on your own queue to tackle something like this. This also moves the decoding to the background, which is another significant win.

Cover your eyes, Objective-C code sample from my side project incoming:

// Use your own queue instead of a global async one to avoid potential thread explosion- (void)tableView:(UITableView *)tableView prefetchRowsAtIndexPaths:(NSArray<NSIndexPath *> *)indexPaths{
    if (self.downsampledImage != nil || 
        self.listItem.mediaAssetData == nil) return;
    
    NSIndexPath *mediaIndexPath = [NSIndexPath indexPathForRow:0
                                                     inSection:SECTION_MEDIA];
    if ([indexPaths containsObject:mediaIndexPath])
    {
        CGFloat scale = tableView.traitCollection.displayScale;
        CGFloat maxPixelSize = (tableView.width - SSSpacingJumboMargin) * scale;
        
        dispatch_async(self.downsampleQueue, ^{
            // Downsample
            self.downsampledImage = [UIImage downsampledImageFromData:self.listItem.mediaAssetData
                               scale:scale
                        maxPixelSize:maxPixelSize];
            
            dispatch_async(dispatch_get_main_queue(), ^ {
                self.listItem.downsampledMediaImage = self.downsampledImage;
            });
        });
    }}

Take care to use asset catalogs for the lion’s share of your raw image assets, since it already manages buffer sizes (and a lot more) for you already.

For more inspiration on how to be a first class citizen of all things memory and images, be sure to catch these particularly informative sessions from WWDC 18:

Wrapping Up

You don’t know what you don’t know. And in programming, you’re basically signing up for an entire career of always running 10,000 miles an hour just to keep pace with the innovations and change. Which means… there’s going to be a mountain of APIs, frameworks, patterns or optimizations you simply weren’t aware of.

And that can certainly be true with images. Most of the time, you initialize a UIImageView with some beautiful pixels and move on. I get it, Moore’s Law and whatever. These phones are fast and have gigs of memory, and hey - we put humans on the Moon with a computer that had less than 100 kilobytes of memory.

But dance with the devil long enough, and he’s bound to rear his horns. Don’t let jetsam pluck you from existence because a selfie took up 1 gigabyte of memory. Hopefully, this knowledge and these techniques can you save you a trip down the crash logs.

Until next time ✌️.

素问 - iOS技术

Quick tip: clearing your app’s launch screen cache on iOS

iOS图片内存优化

HEIC HEIF

加载

解码

渲染

内存暴涨原因

渲染格式

SRGB

display p3 宽色域

亮度和透明度

Alpha 8 Format

渲染图片大小计算

如何选择正确的图片格式

下采样

1.UIKit UIGraphicsImageRenderer

2.CoreGraphics CGContext上下文绘制缩略图

3.ImageIO 创建缩略图

4.CoreImage 滤镜

5.使用 vImage 优化图片渲染

内存优化

DemoCode download from github

总结

参考

头条 穿山甲广告 错误码列表

国内外8000多个电视台一网打尽，这个开源项目要火！

iOS证书签名机制&重签名&防止重签名

iOS签名机制

概念

非对称加密

数字摘要

数字签名

其他

AppStore签名

Xcode安装&Adhoc&In-House

重签名

完全重签名

Shell脚本重签名

如何防止应用被重签名

校验描述文件信息

sysctl检测是否被调试

参考链接

CocoaPods指定版本号带~>与不带的区别

带~> 是指定一个范围的版本号

~> 大于等于指定的版本号，小于高一位的版本号

不带~> 是指定固定的版本号

ffmpeg常用基本命令

Xcode11 打包IPA上传App Store失败解决办法 xcrun altool密钥上传

缘由

如何使用xcrun altool

一：路径不用说了，可以使用xcodebuild打包或用OrganizerExport导出App store包。

二：apiKey和apiIssuer需要去开发者官网-用户和访问-密钥-去新增。如下图流程

三：到这一步先别急执行命令，执行了也会出错，按照xcrun altool官方文档说明

四：接下来把参数替换上去，可以尝试进行验证和上传了。

五：OK，已经有了，到这里就大功告成了。是不是真香。。。

iOS多线程编程：线程同步总结

Optimizing Images

In Theory

The Rendering Pipeline

Size Does Matter

Color Space

Downscaling vs Downsampling

Bonus Points

Wrapping Up

头条穿山甲广告错误码列表

如何使用`xcrun altool`

一：路径不用说了，可以使用`xcodebuild`打包或用`Organizer`Export导出App store包。

二：`apiKey`和`apiIssuer`需要去开发者官网-用户和访问-密钥-去新增。如下图流程

三：到这一步先别急执行命令，执行了也会出错，按照`xcrun altool`官方文档说明