ios哈希表
Snapshot testing is used to test the rendered output of a UI element. The UI element can be a view controller which is a whole screen or just a view component. This idea is introduced by Facebook with the FBSnapshotTestCase project and it is continued by Uber as iOSSnapshotTestCase.
快照测试用于测试UI元素的渲染输出。 UI元素可以是整个屏幕的视图控制器，也可以只是视图组件。 Facebook在FBSnapshotTestCas e项目中引入了这个想法，Uber在iOSSnapshotTestCase中继续了这一想法。
Basic idea of the snapshot testing is to store a reference to disk as an image and compare the reference image with the on the fly renderings while testing. This is working well since a lot of information about a reference is stored already in the image file.
快照测试的基本思想是将对磁盘的引用存储为映像，并在测试时将引用映像与动态渲染图进行比较。 由于许多有关参考的信息已存储在图像文件中，因此效果很好。
I see an improvement point here. Let’s say we have a component and the view model of the component have 8 different property to configure the view. It can be assumed that a fixed value or a nil value is assigned to a property. This ends up with 256 different variations. The number of variations is likely to be increased if projects supports dark mode or RTL languages. If any onf the mis supported, the total number of test cases become 512. If we assume that each image file is 10KB, the total size required to test for a simple view is around 5MB.
我在这里看到了一个改进点。 假设我们有一个组件，并且该组件的视图模型具有8个不同的属性来配置视图。 可以假定为属性分配了固定值或零值。 最终有256个不同的变体。 如果项目支持深色模式或RTL语言，则变体的数量可能会增加。 如果有误，则测试用例的总数为512 。 如果我们假设每个图像文件为10KB ，则测试一个简单视图所需的总大小约为5MB 。
Apparently, this is not a big deal, otherwise there should already be an alternative. As i said, i see this as an improvement point and i propose that this redundant space requirement can be removed by using perceptual hashing.
显然，这没什么大不了的，否则应该已经有了替代方案。 如我所说，我认为这是一个改进点，我建议可以通过使用感知哈希来消除此冗余空间需求。
Perceptual hash is similar to cryptographic hashes in terms of the idea of creating a fingerprint from a data. While cryptographic hash functions have avalanche effect which means the output of the hash function is being effected drastically even just for one bit of changes. However, output of perceptual hash functions are kept same or changed slightly with the small changes in the input data. This property of perceptual hashes make the reverse media search easier like Google Image Search or Shazam.
就从数据创建指纹的观点而言， 感知哈希类似于加密哈希。 尽管加密散列函数具有雪崩效应 ，这意味着即使仅更改一点点，散列函数的输出也会受到极大影响。 但是，随着输入数据的微小变化，感知哈希函数的输出保持相同或略有变化。 感知哈希的此属性使反向媒体搜索(如Google Image Search或Shazam)更加容易。
There are a couple of image hash functions available such as average hash, blockhash, perceptual hash, etc.. Many of them are compared in this article here and perceptual hash seems performing better. I will not go into the details of this algorithm but i recommend you to check how those algorithms work.
有几个可用的图像哈希函数，例如平均哈希，块哈希，感知哈希等。本文在本文中对它们中的许多进行了比较，感知哈希的性能似乎更好。 我不会详细介绍该算法，但我建议您检查一下这些算法的工作方式。
The output size of perceptual hashes are just 64bits. The outputs of them are not randomly distributed by design but it is possible to say two images are most probably similar images if their hash values are same. In the use cases of these algorithms, a threshold value is determined since having same values as a requirement for similarity can be too strict for just a search. The threshold value is simply calculated by Hamming distance of two hashes which is basically the number of different bits in two hashes.
感知哈希的输出大小仅为64位 。 它们的输出不是根据设计随机分布的，但是可以说，如果两个图像的哈希值相同，则它们很可能是相似的图像。 在这些算法的使用情况下，确定阈值是因为具有与相似性要求相同的值对于仅搜索而言可能过于严格。 简单地通过两个哈希的汉明距离来计算阈值，这基本上是两个哈希中不同比特的数量。
Usage of a perceptual hash in testing is a new use case and same hash result should be expected from output of the tests. This is possible if it is guaranteed that the same simulator will be used for tests. When this is guaranteed, even a cryptographic hash may be possible to use. However, this condition is not feasible and different device simulators simulate different screens with different scale values. Basically, the output of two different simulators can produce scaled version of each other and since the data is different the hashes would also be different.
在测试中使用感知哈希是一个新的用例，应该从测试的输出中获得相同的哈希结果。 如果可以保证将同一模拟器用于测试，则可以这样做。 在保证这一点的情况下，甚至可以使用加密哈希。 但是，这种情况不可行，并且不同的设备模拟器会以不同的比例值模拟不同的屏幕。 基本上，两个不同模拟器的输出可以相互产生缩放版本，并且由于数据不同，哈希值也将不同。
It is obvious that, even if scaled images represent different data, they are similar images. This can conclude that the perceptual hashes of them should be close to each other. Using a very small threshold can make the use of perceptual hashes possible in testing and it ends up with 64bits of space requirements for each snapshot which ends up with 4KB instead of 5MB in the previous example above.
显然，即使缩放的图像表示不同的数据，它们也是相似的图像。 这可以得出结论，它们的感知哈希应该彼此接近。 使用很小的阈值可以在测试中使用感性哈希，并且最终每个快照的空间需求为64位，最终以4KB代替上面的上一个示例中的5MB 。
It is good to note that even if the above images produce same perceptual hash values, the distance between two values which is called as threshold above should be small enough. This shows the perceptual hash method does not have platform dependency while cryptographic hashes have.
值得一提的是，即使以上图像产生相同的感知哈希值，两个值之间的距离(也称为“阈值”)也应足够小。 这表明感知哈希方法不具有平台依赖性，而密码哈希具有。
Perceptual hash algorithms are focused on perceptions, not the data integrity that’s why the differences caused by scaling is tolerated. Not only scaling but very small changes can be tolerated as well. For example, in above images the space between title label and bookmark icon is 8px. If the space is increased up to 12px, the algorithm would tolerate and it would end up with the same hash value. Increasing the space to 12px would create 1 bit difference which means that tests can catch this change but will miss the cases between 8px and 12px.
感知哈希算法专注于感知，而不是数据完整性，这就是可以容忍缩放导致的差异的原因。 不仅可以缩放，而且可以容忍很小的变化。 例如，在上面的图像中，标题标签和书签图标之间的空间为8px。 如果空间增加到12px，算法将可以接受，并且最终将具有相同的哈希值。 将空间增加到12px会产生1位差异，这意味着测试可以捕获此更改，但会漏掉8px和12px之间的情况。
One of the calculation steps of perceptual hash is to convert the image into grayscale. This is basically done by taking the average of the RGB values of a pixel. In above design, the user name is rendered with purple colour whose RGB value is (0.5,0,0.5). The grayscale pixels of these purple pixels are calculated as 1/3 = 0.33. If the colour is changed to red with (1,0,0) values, the grayscale pixels will still have the same value 1/3. This shows that the algorithm also tolerates some specific colour changes whose grayscale values are same.
感知哈希的计算步骤之一是将图像转换为灰度。 这基本上是通过获取像素的RGB值的平均值来完成的。 在上述设计中，用户名用紫色表示，其RGB值为(0.5,0,0.5)。 这些紫色像素的灰度像素计算为1/3 = 0.33。 如果用(1,0,0)值将颜色更改为红色，则灰度像素仍将具有相同的值1/3。 这表明该算法还可以承受某些灰度值相同的特定颜色变化。
Changing the colour to a different one whose grayscale value is not 0.33 effects the perceptual hash value. In the image below, the colour is set to (0.7,0.6,0.3) whose grayscale value is 0.8. This will result a hash value 2 bit away from original hash.
将颜色更改为灰度值不是0.33的另一种颜色会影响感知哈希值。 在下图中，颜色设置为(0.7,0.6,0.3)，其灰度值为0.8。 这将导致哈希值与原始哈希值相差2位。
In the lights of these inspections above, it is not easy to say that perceptual hash can be used for any project’s snapshot testing but also it is not easy to say that it is useless. This method can be used if the project is not so sensitive against small changes, so i recommend you to evaluate your project’s requirement before using it.
鉴于以上这些检查，很难说感知哈希可以用于任何项目的快照测试，但是也不容易说它没有用。 如果项目对微小的变化不太敏感，则可以使用此方法，因此，我建议您在使用前评估项目的需求。
Implementations of perceptual hashes are very straight forward, so it can be implemented simply in a project and tweaked a bit if needed or there are available libraries that can be used through CocoaPods like CocoaImageHashing which provides a couple of different hash implementations.
感知哈希的实现非常简单，因此可以简单地在项目中实现，并根据需要进行一些调整，或者可以通过CocoaPods使用的可用库(例如CocoaImageHashing)可以提供几种不同的哈希实现。
I hope you enjoyed reading and thanks for your time.
希望您喜欢阅读，并感谢您的宝贵时间。
翻译自: https://medium.com/swlh/ios-snapshot-testing-with-perceptual-hash-16b23aadf6c3
ios哈希表
扫一扫
1948
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
