iPhone/iPad设备型号对应常用名称列表(2023更新至iPhone 15 Pro Max | iPad Air 5 | iPad10 | iPad Pro 12.9-inch 6)

设备型号 名称
iPhone3,1 iPhone 4
iPhone3,2 iPhone 4
iPhone3,3 iPhone 4
iPhone4,1 iPhone 4S
iPhone5,1 iPhone 5
iPhone5,2 iPhone 5
iPhone5,3 iPhone 5c
iPhone5,4 iPhone 5c
iPhone6,1 iPhone 5s
iPhone6,2 iPhone 5s
iPhone7,1 iPhone 6 Plus
iPhone7,2 iPhone 6
iPhone8,1 iPhone 6s
iPhone8,2 iPhone 6s Plus
iPhone8,4 iPhone SE
iPhone9,1 iPhone 7
iPhone9,2 iPhone 7 Plus
iPhone9,3 iPhone 7
iPhone9,4 iPhone 7 Plus
iPhone10,1 iPhone 8
iPhone10,2 iPhone 8 Plus
iPhone10,4 iPhone 8
iPhone10,5 iPhone 8 Plus
iPhone10,3 iPhone X
iPhone10,6 iPhone X
iPhone11,2 iPhone XS
iPhone11,4 iPhone XS Max
iPhone11,6 iPhone XS Max
iPhone11,8 iPhone XR
iPhone12,1 iPhone 11
iPhone12,3 iPhone 11 Pro
iPhone12,5 iPhone 11 Pro Max
iPhone12,8 iPhone SE 2
iPhone13,1 iPhone 12 mini
iPhone13,2 iPhone 12
iPhone13,3 iPhone 12 Pro
iPhone13,4 iPhone 12 Pro Max
iPhone14,4 iPhone 13 mini
iPhone14,5 iPhone 13
iPhone14,2 iPhone 13 Pro
iPhone14,3 iPhone 13 Pro Max
iPhone14,6 iPhone SE 3
iPhone14,7 iPhone 14
iPhone14,8 iPhone 14 Plus
iPhone15,2 iPhone 14 Pro
iPhone15,3 iPhone 14 Pro Max
iPhone15,4 iPhone 15
iPhone15,5 iPhone 15 Plus
iPhone16,1 iPhone 15 Pro
iPhone16,2 iPhone 15 Pro Max
i386 Simulator
x86_64 Simulator
iPod1,1 iPod Touch 1G
iPod2,1 iPod Touch 2G
iPod3,1 iPod Touch 3G
iPod4,1 iPod Touch 4G
iPod5,1 iPod Touch 5G
iPod7,1 iPod Touch 6G
iPod9,1 iPod Touch 7G
iPad1,1 iPad
iPad1,2 iPad 3G
iPad2,1 iPad 2
iPad2,2 iPad 2
iPad2,3 iPad 2
iPad2,4 iPad 2
iPad2,5 iPad Mini
iPad2,6 iPad Mini
iPad2,7 iPad Mini
iPad3,1 iPad 3
iPad3,2 iPad 3
iPad3,3 iPad 3
iPad3,4 iPad 4
iPad3,5 iPad 4
iPad3,6 iPad 4
iPad4,1 iPad Air
iPad4,2 iPad Air
iPad4,3 iPad Air
iPad4,4 iPad Mini 2
iPad4,5 iPad Mini 2
iPad4,6 iPad Mini 2
iPad4,7 iPad Mini 3
iPad4,8 iPad Mini 3
iPad4,9 iPad Mini 3
iPad5,1 iPad Mini 4
iPad5,2 iPad Mini 4
iPad5,3 iPad Air 2
iPad5,4 iPad Air 2
iPad6,3 iPad Pro 9.7
iPad6,4 iPad Pro 9.7
iPad6,7 iPad Pro 12.9
iPad6,8 iPad Pro 12.9
iPad6,11 iPad 5
iPad6,12 iPad 5
iPad7,1 iPad Pro 12.9 inch 2nd gen
iPad7,2 iPad Pro 12.9 inch 2nd gen
iPad7,3 iPad Pro 10.5 inch
iPad7,4 iPad Pro 10.5 inch
iPad7,5 iPad 6
iPad7,6 iPad 6
iPad7,11 iPad 7
iPad7,12 iPad 7
iPad8,1 ~ 8,4 iPad Pro 11-inch
iPad8,5 ~ 8,8 iPad Pro 12.9-inch 3rd gen
iPad8,9 ~ 8,10 iPad Pro 11-inch 2nd gen
iPad8,11 ~ 8,12 iPad Pro 12.9-inch 4th gen
iPad11,1 iPad Mini 5
iPad11,2 iPad Mini 5
iPad11,3 iPad Air 3
iPad11,4 iPad Air 3
iPad11,6 iPad 8
iPad11,7 iPad 8
iPad13,1 iPad Air 4
iPad13,2 iPad Air 4
iPad12,1 iPad 9
iPad12,2 iPad 9
iPad14,1 iPad Mini 6
iPad14,2 iPad Mini 6
iPad13,4 ~ 13,7 iPad Pro 11-inch 3nd gen
iPad13,8 ~ 13,11 iPad Pro 12.9-inch 5th gen
iPad13,16 iPad Air 5
iPad13,17 iPad Air 5
iPad13,18 iPad 10
iPad13,19 iPad 10
iPad14,3 ~ 14,4 iPad Pro 11-inch 4th gen
iPad14,5 ~ 14,6 iPad Pro 12.9-inch 6th gen

参考链接


OpenSSL通过OCSP手动验证证书

这篇文章主要用来说明如何借助ocsp服务器来验证证书。ocsp(The Online Certificate Status Protocol)是一种验证证书状态的一种方式,也是CRL(certificate revocation list)证书吊销的一种替代方式。

与传统的CRL比较有以下特点:

  • 由于相对于传统的CRL,一个ocsp响应包含的信息更少,故ocsp能够更有效利用网络和客户资源
  • 用OCSP,客户无需自己解析CRL证书吊销列表,但是客户需要存储状态信息,而由于客户侧需要维护存储缓存,故导致存储信息很复杂。在实际使用中,这点带来的影响却很小,由于第三库提供的相关接口已经帮我们完成此类工作
  • OCSP通过专用网络、专用证书、在特定的时间公开其服务。OCSP不强制加密,故可能带来信息泄露的风险。

此文章中用到的openssl的版本为:OpenSSL 1.0.1g 7 Apr 2014

1、获取证书用于ocsp验证

首先,我们将从一个网站上获取一个证书,这里我们用Wikipedia作为样例来进行。我们获取证书通过如下命令:

过该命令可以获取wikipedia.org的客户端证书

保存这个输出到wikipedia.pem文件中

 现在,检查整个证书中是否包含ocsp网址

若执行正确则输出 http://ocsp.digicert.com ,否则你就不能通过ocsp验证这个证书

2、获取证书链

由于这个证书认证是一级一级逐层进行,故需要获得与这个证书相关的证书链。利用openssl s_client -showcerts 选项,能够查看到在该信任链上的所有相关证书

如你所见,输出能够看到两个证书,number 1 和number 0,其中number 0就是我们刚刚获取的那个证书。如果你的网站有更多证书在认证链中,那么你将看到更多证书。为了发送证书,需要保存证书链中所有证书到一个文件chain.pem,按照刚刚命令输出的证书顺序,根证书总是在文件结尾。

3、发送ocsp认证请求

现在我们有ocsp认证请求的所有信息,使用下面命令发送ocsp认证请求。

其结果如下 

如果你需要更简略的输出,去掉-text 选项,该选项一般用于调试

4、吊销证书

如果你有一个吊销的证书,你也可以测试该证书按照上述步骤,所得的响应如下:

5、其他错误

如果证书和ocsp服务不匹配,验证将错误,使用-text选项可以查看具体错误。

参考链接


Flutter 3.16中WillPopScope过期使用PopScope来代替

Flutter 3.16WillPopScope 过期了,需要使用 PopScope 来代替。

针对 PopScopecanPop 参数,官方文档解释如下:

canPopfalse,则执行系统返回时会被拦截,并且调用 onPopInvoked 方法,同时 didPopfalse,此时进行逻辑判断,如果需要返回则执行 Navigator.of(context).pop();

注意此时 onPopInvoked 又会被调用,并且 didPoptrue

参考Demo: github.com

示例代码如下:

修改之前的代码( WillPopScope )如下:

修改之后的代码( PopScope )如下:

参考链接


Flutter的Don't use BuildContext's across async gaps警告解决方法

问题

Flutter开发中遇到Don't use BuildContext's across async gaps警告

有问题的源码

问题原因

“不要在异步间隙(async gaps)中使用 BuildContext” 是一个Flutter中的常见警告消息,通常表示你正在尝试在异步操作中访问 BuildContext,这是一个不推荐的做法,因为它可能引发不确定的行为或错误。

如果在将上下文传递给AlertDialog后导航堆栈发生更改,并且尝试使用旧上下文再次导航,则会出现错误。

问题分析

Context的含义

Flutter中的 BuildContext 和 Context 是相同的,BuildContext 是 Context 的别名。这两个术语用来表示小部件树中的位置信息和上下文环境,用于在构建小部件树和访问资源(例如主题、本地化、导航等)时提供上下文信息。

在Flutter中,BuildContext 或 Context 表示的是一个由小部件树组成的层次结构中的位置。每个小部件都有一个与之相关的 BuildContext,这个上下文包含有关小部件的信息,例如其位置、父级小部件、主题数据等等。

尽管 Context 和 BuildContext 是相同的类型,但通常我们更倾向于使用 BuildContext 这个术语,因为它更明确地表示它是与构建过程相关的上下文。

BuildContext的作用

BuildContext 类型通常用于以下操作:

  • 访问父级小部件:你可以使用 BuildContext 访问小部件树中的父级小部件,这对于在小部件之间传递数据和状态非常有用。
  • 获取主题数据:通过 BuildContext 可以访问当前主题的数据,如颜色、字体、间距等。
  • 获取本地化信息:你可以使用 BuildContext 获取本地化信息,以根据用户的语言偏好来显示文本。
  • 导航:BuildContext 通常用于导航操作,如推送新路由或弹出对话框。
  • 构建小部件:BuildContext 是在小部件的 build 方法中传递的,它告诉小部件在小部件树中的位置。

BuildContext 和 Context 都代表了小部件树中的位置和上下文信息,它们在构建和交互中扮演着关键的角色,但它们实际上是相同的概念的不同表达方式。因此,你可以放心地将它们视为等同的,使用其中一个作为标识符,以便更清晰地表示其作用。

特殊情况

然而,在某些情况下,你可能需要在异步操作中访问 BuildContext,例如在异步回调中执行 UI 操作。这通常是不安全的,因为异步操作可能会在 BuildContext 不再有效的情况下执行,从而引发错误。

解决方法


使用

不要在异步间隙中直接使用 BuildContext,因为它可能会导致不安全的操作。使用提供的方法来安全地查找小部件并在异步操作中访问它们的上下文。这可以帮助你避免潜在的问题和错误。

官方说明如下:

Details

DON’T use BuildContext across asynchronous gaps.

Storing BuildContext for later usage can easily lead to difficult to diagnose crashes. Asynchronous gaps are implicitly storing BuildContext and are some of the easiest to overlook when writing code.

When a BuildContext is used, its mounted property must be checked after an asynchronous gap.

BAD:

GOOD:

GOOD:

参考链接


性能有坑 | 慎用 Java 8 ConcurrentHashMap 的 computeIfAbsent

前言

我们先看一段代码,代码中使用 Map 的时候,有可能会这么写:

Java 8 的 java.util.Map 里面有个方法 computeIfAbsent,能够简化以上代码:

以上这种写法除了简洁,如果使用的是 java.util.concurrent.ConcurrentHashMap,还能够在并发调用的情况下确保 calculateValue 方法不会被重复调用,保证原子性。

不过,前段时间对 Apache ShardingSphere-Proxy 做压测时遇到一个问题,当 BenchmarkSQL 连接 ShardingSphere Proxy 的 Terminal 数量比较高时,其中一条很简单的插入 SQL 执行延迟增加了很多。借助 Async Profiler 发现 Java 8 ConcurrentHashMap 的 computeIfAbsent 在性能上有坑。

不了解 Apache ShardingSphere 的读者可以参考 https://github.com/apache/shardingsphere

继续阅读性能有坑 | 慎用 Java 8 ConcurrentHashMap 的 computeIfAbsent

解决Windows 10备份和还原遇到的0x80070544问题

随着主力计算机设备年限越来越近,对数据保护的重视度也越来越高,尤其之前遭遇过数据损失。目前采用的备份方案是使用文件历史记录功能对 OneDrive 等经常会访问和编辑的目录进行备份。对于其他归档用途的目录则使用备份和还原功能,定期执行一次备份。而备份的位置建议是额外的磁盘或 NAS 提供的 iSCSI,gOxiA 为了图方便和节省 NAS 空间,则使用的是共享文件夹的方式。在实际配置过程中如果使用共享文件夹这样的网络位置,则可能会遇到 0x80070544 故障问题,提示为“请求的验证信息类无效”。

继续阅读解决Windows 10备份和还原遇到的0x80070544问题

Android:Installed Build Tools revision 33.0.2 is corrupted.

使用33.0.2及以上版本的build-tools编译Android应用时。

有些人会按照提示去SDK Manager中重新安装build tools,然后发现这样做是无用的

编译时会收到:

Windows:

Linux/macOS:

解决方案:

更改批处理文件名称

Windows系统:

  1. 找到build tools目录中的d8.bat,将文件名修改为dx.bat。
  2. 找到build tools目录中的lib/d8.jar,将文件名修改为dx.jar。
  3. 回到Android Studio重新打包。

Linux/macOS系统:

  1. 找到build tools目录中的d8,创建软链接 ln -s d8 dx
  2. 找到build tools目录中的lib/d8.jar,创建软链接 ln -s d8.jar dx.jar
  3. 回到Android Studio重新打包。

参考链接


Android:Installed Build Tools revision 33.0.2 is corrupted.

使用UrlQuerySanitizer来处理URL

网上对于 UrlQuerySanitizer 的资料比较少,这个是 Android 提供的一个用来处理 url 的 API。由于项目的需要,需要对 url 的 query 参数进行排序,因此需要解析 url 并处理 query 参数。

最初的方法是使用 Uri:

通过这样的方式就可以解析 url,并获取到各个 query 参数。但后来发现 Uri 不能处理一些特殊字符,比如#,Uri 会截断#以后的内容,这样就不能满足开发需求。经过各种 google,最后发现了一个 UrlQuerySanitizer 的 API:

首先要使用 setAllowUnregisteredParamaters 让其支持特殊字符,然后使用 setUnregisteredParameterValueSanitizer 来设置支持哪些特殊字符,UrlQuerySanitizer 提供了集中默认的 ValueSanitizer:

每种 ValueSanitizer 都对应过滤哪些字符,被过滤掉的特殊字符会被替换成_或者空格。
如果默认的 ValueSanitizer 不能满足开发需求,还可以自己构造 ValueSanitizer:

UrlQuerySanitizer 也可以通过 key 来获取相应的 value,比如给一个 url:http://coolerfall.com?name=vincent:

UrlQuerySanitizer 还可以只解析 query 参数,比如:name=vincent&article=first:

以上就是 UrlQuerySanitizer 大致用法,用来解析处理 url 非常的方便。

参考链接


使用 UrlQuerySanitizer 来处理 url

macOS Sonoma(14.2.1)通过UTM虚拟机编译Android 12.1源码过程总结(MacBook Pro 2023-Apple M2 Pro)

前置条件


根据 Google 官方文档,2021年6月22日之后的Android系统版本不支持在macOS系统上构建,我们在 Applic SiliconmacOS 系统是不能直接成功构建后续版本的,但是之前的版本可以在修改编译配置后成功编译,只是是否能正常运行存疑

尝试过使用 Podman Desktop / Docker 方式进行编译、也尝试过借助 OrbStackLima 这些纯虚拟机通过安装 ubuntu 22.04 系统镜像的方式进行编译,结果都在执行 lunch 命令的时候长时间卡住,观察系统进程发现名为 nsjail 进程的 CPU 占用持续卡住在 100% 上无法继续编译,并且由于 Docker 或者虚拟机文件系统是 Linux 文件系统,而宿主机的文件系统是 AppleFS 文件系统,导致需要进行文件转换,中间的转换性能代价非常高,性能很差。

相反,目前测试来看,直接在 UTM 虚拟机里执行编译的性能反倒更好一些。

目前测试发现存在严重的文件系统缺陷,编译/大量文件复制过程中,经常出现文件系统损坏,导致编译失败。

原因参考:

https://github.com/utmapp/UTM/pull/5869
https://github.com/utmapp/UTM/pull/5919

需要等待 UTM 合并到主分支。

另外,我们需要安装 Rosetta 2 支持运行部分 x86_64 应用。注意  Rosetta 2 只支持 64 位应用,不支持 32 位应用。 参考 Does Rosetta 2 support 32-bit Intel apps?

继续阅读macOS Sonoma(14.2.1)通过UTM虚拟机编译Android 12.1源码过程总结(MacBook Pro 2023-Apple M2 Pro)

ubuntu 22.04.3使用blivet-gui创建SoftwareRAID

最近家里安装降噪棉的时候使用了钉书钉,结果安装的时候,意外震坏了一块八年历史的老西数硬盘,造成数据丢失。

话说,西部数据的硬盘耐用性真的很成问题,家里至少已经坏了五块硬盘了,四块都是西部数据的。

于是另购了一块希捷的银河系列 16TB 硬盘,打算跟现存的一个刚刚替换的西部数据的 12TB 红盘(质保期之内坏了,走售后,花了一个多月换了一张盘,估计寿命也是堪忧),组一个 Raid 1 软阵列,到时候万一再有硬盘损坏,至少可以保住数据。

当前设备是使用 HP Gen8 上安装的 ubuntu 22.04.3 系统,四个盘位,其中两个从群晖上替换下来的 4TB 硬盘直接挂载到两个盘位上,依旧保持群晖的 Raid 1 软阵列。另外两个盘位,就是我们需要新组的软件 Raid 1 的位置了。

网上搜索了半天,都是需要通过命令行,逐个磁盘分区,分区之后再使用 mdadm 通过命令行组建阵列,虽然难度不大,但是操作比较繁琐,还是希望能在 UI 界面上点击一下鼠标搞定。

可以使用 storaged-project/blivet-gui 这个开源项目完成这个需求。

继续阅读ubuntu 22.04.3使用blivet-gui创建SoftwareRAID