iOS應用開發中的裝置標識

但總體來說itunes connect提供的功能還比較有限，而且基本不能定製（除非你能說服蘋果）。

對於應用發布後的跟蹤和資料收集，很多時候是itunes connect之外的事情，甚至有些開發者對於閃退日誌收集等也拋棄了itunes connect的crash report。那麼乙個識別具體裝置的標誌，或者說能夠區分不同裝置的方法就顯得很重要。這篇文章我簡要整理一下。

大家可以明確一點，為了保護使用者隱私，蘋果並沒開放太多api給開發者，使得裝置的資料追蹤變得越來越難。

imei、imsi、iccid這類在itunes mac客戶端可以直接看到的東西，現在都不要想著能通過api在程式中獲取到。

0. udid

在ios6.1及之前，我們可以再uikit.framework的uidevice類中看到乙個屬性，那就是uniqueidentifier，也就是我們通常所提到的udid。

但這個屬性的宣告後面，有ns_deprecated_ios(2_0, 5_0)，意思就是5.0開始就是deprecated的了，是過時的，不建議再繼續使用。

到了ios sdk的7.0版本，在uidevice類中，就再也找不到這個uniqueidentifier屬性了。而且蘋果方面明確表示在2023年5月份之後不再對此支援。即使使用老版本的sdk，也不一定能通過蘋果審核，聽說有人還嚐到過rejected的苦頭。

1. identifierforvendor (idfv)

貌似也有人簡略為idfv，這是蘋果安撫大家的乙個udid的替代品，也是uidevice類的屬性。

按照蘋果的文件說明，這個idfv在同一裝置上的所有同vendor應用得到的id是相同的，而不同的裝置就有不同的idfv。當這個裝置上，同vendor的所有應用都被解除安裝掉之後，不能保證同一裝置再次安裝這個vendor的應用時，得到同樣的id。

簡單來說，如果乙個裝置上只裝了你乙個應用，解除安裝掉再裝id也許就不同了。這樣，對於唯一裝置的定義就和原來udid的很不同。這點並不令廣大開發者感到滿意。

2. mac位址

如上所述，identifierforvendor不是很令大家滿意，於是各種民間方法就出現了。乙個方案就是用mac位址。

學過計算機網路課程的同學們應該了解，要先完成底層網路通訊實現mac位址是必須有的，而這個在網絡卡製造時要保證全球唯一的，乙個裝置通常乙個網絡卡就夠用了，所以這個在一定程度上可以作為裝置標識。

於是乎，拿出了各種底層庫，做各種計算，拿到乙個mac位址字串。

下面這段是網路上比較流行的：

- (nsstring*) macaddress

if(sysctl(mib, 6,null, &len,null, 0) < 0)

if((buf = malloc(len)) ==null)

if(sysctl(mib, 6, buf, &len,null, 0) < 0)

ifm = (structif_msghdr *)buf;

sdl = (structsockaddr_dl *)(ifm + 1);

ptr = (unsignedchar*)lladdr(sdl);

nsstring*outstring = [nsstringstringwithformat:@"%02x:%02x:%02x:%02x:%02x:%02x",

*ptr, *(ptr+1), *(ptr+2), *(ptr+3), *(ptr+4), *(ptr+5)];

free(buf);

returnoutstring;

}

而這段需要引入幾個系統庫：

#include

嗯，不錯，這樣貌似就可以獲取比較有意義的裝置標識了。如果這個時候，你沾沾自喜了，那你還是不了解蘋果為了保護使用者隱私，下了多大力氣。

很遺憾第告訴大家，在裝有ios7的裝置上，這段**計算出的值，永遠是乙個恆定的：

02:00:00:00:00:00

所以，夢又碎了。。

3. advertisingidentifier (idfa)

蘋果為了完善自己的生態圈，在2023年前後推出了iad廣告網路。那麼這個advertisingidentifier和這個iad的關係就不言自喻了。如果不了解廣告也沒關係，簡單來講，現在的網際網路廣告精準投放需要了解使用者資料，基於這些資訊是的廣告更有效率，唯一標識就很重要，就用到了idfa。

advertisingidentifier在adsupport.framework的asidentifiermanager類中，是其中兩個屬性中的乙個。

可以說，用這個idfa標識裝置應該還是很精準的（不然iad就徹底不用玩了），很多開發者還在使用。

但再次，非常遺憾地說，貌似最近蘋果對這個的要求也越來越嚴格了。

我這裡收到過的一次拒審原因是：

pla 3.3.12

specifically, section 3.3.12 of the ios developer program license agreement states:

class: asidentifiermanager

selector: advertisingidentifier

framework: adsupport.framework

所以，還在「濫用」idfa標識裝置的朋友們要小心了。

4. 接下來怎麼辦？

「這是個很好的問題」一般演講者覺得提問者的問題很難回答的時候會這麼說，然後接下來繞彎子兜圈子。。。當然這裡我不會。

原則上來說，ios的開發者是生長在蘋果的生態圈，需要與蘋果合作，尊重其理念。所以這裡的結論是，最好的辦法，就是不去標識裝置id。

但人是活的，所以這裡有乙個比較俗套的辦法：

前面講到idfv不能令人滿意，很大程度上是因為解除安裝之後重灌id就變了。我們在解除安裝乙個應用的時候，其沙箱內的資料應該會一起不見，那有沒有沙箱之外的地方呢？答案自然是肯定的，不過按照蘋果的說法，沙箱之外需要系統的api協助。乙個比較直觀的選擇就是key chain。所以通俗的方案就是自己生成可見範圍內的唯一id，存入key chain，下次再來重灌依然可以讀到。

在蘋果對各種id**後，很多民間的做法就是這種思路。這個做法對於一般條件下的資料收集應該足夠了，但如果考慮到裝置黑名單等安全識別，還差得遠。

附一張**cocoachina的，不考慮現今實際的可用情況，對比一下這些id們的差異：

iOS應用開發中的裝置標識

iOS 裝置標識

獲取iOS裝置的唯一標識

iOS 獲取裝置的唯一標識

iOS應用開發中的裝置標識

iOS 裝置標識

獲取iOS裝置的唯一標識

iOS 獲取裝置的唯一標識

相關推薦