前一個版本實作判斷相片是否被修改，是拿相片最後修改時間來比較，不過卻發生異常狀況，使得就算用戶沒有修改過相片，還是會跑到有修改過相片的流程，這讓我們家負責客服的同事哀嚎了一下⋯⋯大概讓我們損失好幾萬美元的營收。😳
透過PHAsset拿到相片資料中的modificationDate，也就是相片的最後修改時間，照理說應是沒有問題才是⋯⋯
RGB各通道的灰階影像。
自家測試員總共也才測不到10次，一定會有漏掉的流程，於是僅能關注已安裝此版本的用戶，會不會有異常狀況發生。既然現在發現嚴重瑕疵，就得抽絲剝繭找到問題關鍵所在⋯⋯
我實際使用內建相片App來操作別的功能，發現流程中用來判斷相片修改時間的值modificationDate，除了理所當然會改變此值的行為影像處理（如旋轉、裁切、濾鏡等等），沒想到在內建相簿App中操作：
- 相片傳送Air Drop會改變modificationDate
- 相片加入最愛會改變modificationDate
- 相片取消最愛會改變modificationDate
- 相片刪除後回復會改變modificationDate
甚至還有尚未測試的功能也可能會改變modificationDate，進而會一直有此狀況【作品最後編輯時間 < 相片最後編輯時間】，於是使用此值來判斷相片有無被修改就不恰當，必須再想其他方式偵測！
/**
Theme: Image Hash
IDE: Xcode 12
Language: Objective C
Date: 110/01/12
Author: HappyMan
Blog: https://cg2010studio.com/
*/
<CommonCrypto/CommonDigest.h>
unsigned char result[CC_MD5_DIGEST_LENGTH];
NSData *imageData = [NSData dataWithData:UIImagePNGRepresentation(inImage)];
CC_MD5([imageData bytes], [imageData length], result);
NSString *imageHash = [NSString stringWithFormat:
@"%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X",
result[0], result[1], result[2], result[3],
result[4], result[5], result[6], result[7],
result[8], result[9], result[10], result[11],
result[12], result[13], result[14], result[15]
];
imageHash會是32個字元的字串。
經過測試，以下操作行為的Image Hash變化：
原始
BC8C86FE8CA8324F8BD50F27078206CE加入最愛
BC8C86FE8CA8324F8BD50F27078206CE刪除後復原
BC8C86FE8CA8324F8BD50F27078206CE套用濾鏡
68B7FB375F958F9C6509A58D104DB9B9復原
BC8C86FE8CA8324F8BD50F27078206CE套用裁切
DEE696A0228ACF1AC04B16763135425A復原
BC8C86FE8CA8324F8BD50F27078206CE
這個方法就跟最後修改時間沒有關係，只是針對影像本身被修改才會改變Image Hash，至於EXIF這類meta data則不影響Image Hash。
看來可以安心使用！😗
隨意留個言吧：）～