最近有網(wǎng)友發(fā)現(xiàn)友盟的數(shù)據(jù)統(tǒng)計里面，活躍用戶的數(shù)量有點不大對勁，跟啟動次數(shù)相比，嚴重偏少。sdk的使用方式?jīng)]啥好說的，就那么簡單幾步，應該不會是sdk設置的問題。于是就從友盟關(guān)于活躍用戶的定義開始，著手分析這個問題。

創(chuàng)新互聯(lián)建站憑借專業(yè)的設計團隊扎實的技術(shù)支持、優(yōu)質(zhì)高效的服務意識和豐厚的資源優(yōu)勢，提供專業(yè)的網(wǎng)站策劃、成都網(wǎng)站建設、網(wǎng)站設計、網(wǎng)站優(yōu)化、軟件開發(fā)、網(wǎng)站改版等服務，在成都10余年的網(wǎng)站建設設計經(jīng)驗，為成都上千余家中小型企業(yè)策劃設計了網(wǎng)站。

活躍用戶的定義：打開應用的用戶即為活躍用戶，不考慮用戶的使用情況。

從上面的文章，了解到Umeng里面對用戶的定義：友盟將一個獨立的設備視為一個用戶，然而每個獨立的用戶是通過UMID來進行唯一標識的。然而UMID又是神馬鬼東西？簡單來說就是友盟會在第一次安裝的時候生成一個UMID，當ID生成以后友盟會盡量保證這個UMID不會發(fā)生變化。

在應用對應的存儲目錄下面，我們可以找到這個UMID的身影：

ngeIdentity.json這個文件來說，cat一下里面的內(nèi)容，應該可以看到：

筆者發(fā)現(xiàn)公司里多臺設備的UMID都居然是一個相同的UMID值，WTF！??！也同樣是上面這串神秘的代碼：528c8e6cd4a3c6598999a0e9df15ad32。

這個時候就需要查一下UMID的生成方式了，從上面那篇UMID方案解析的文章中，可以了解到Android系統(tǒng)中與UMID相關(guān)的幾個ID：imei、mac地址、android_id。有了這些關(guān)鍵點，我們就可以開始去反編譯友盟的sdk包并進行下一步的搜索了（這里反編譯了友盟最新的jar包：umeng-analytics-v6.0.1.jar）。。。果然，使用上面這幾個關(guān)鍵字，很快就搜索到了一些關(guān)鍵的代碼：

段代碼邏輯比較簡單（由于筆者所調(diào)試系統(tǒng)<23，故省略了一部分代碼），首先TelephonyManager.getDeviceId()獲取imei，若取不到則調(diào)用u(context)函數(shù)獲取下一個字符串，若再取不到，則獲取android_id。其實這里可以猜測到，u()中返回的字符串應該就是mac地址，我們來看下函數(shù)u()的邏輯代碼：

果然，函數(shù)u(context)就是返回wifi的mac地址的。那么，回到剛剛的那個問題，到底那串神秘的UMID是528c8e6cd4a3c6598999a0e9df15ad32根據(jù)啥來生成的？看著這格式有點像md5。然后把機器上的imei、mac地址、android_id都打印了出來：

突然發(fā)現(xiàn)公司設備上打印出來的mac地址都是00:00:00:00:00:00（因為木有wifi模塊，只有ethernet模塊，囧！?。。?，怒將其轉(zhuǎn)為md5，正是上面的串代碼。

可是，為啥當mac地址是00:00:00:00:00:00的時候，不去選擇android_id呢？回去仔細看代碼，發(fā)現(xiàn)友盟用的是坑爹的TextUtils.isEmpty()來判斷mac地址的有效性，跪了，上面那串明明就是無效的mac地址好么？只能說代碼寫得不嚴謹。。。

至此，代碼及原因分析完畢。當一些Android平板設備統(tǒng)一返回相同的mac地址，如00:00:00:00:00:00時（有可能是沒有wifi模塊；也有可能是山寨機出現(xiàn)這種情況的時候），友盟將會將其數(shù)據(jù)識別成同一用戶，并且將會造成嚴重的MAC地址漂移。

作為比較，我們來看一下友盟的競爭對手shareinstall的渠道統(tǒng)計代碼！

首先，我們開看看shareinstall的web集成步驟：

shareinstall提供完整的javascript api，方便Web開發(fā)者實現(xiàn)完全自主的設計。

再開看看shareinstall的代碼配置（測試）：

如果做測試，獲取參數(shù)，則必須在Appdelegate.h加上如下測試代碼。

#pragma mark 將oc數(shù)據(jù)類型轉(zhuǎn)成NSString
-(NSString *)DataTOjsonString:(id)object
{
if (!object) {
return null;
}

NSString *jsonString = null;
NSError *error;
NSData *jsonData = [NSJSONSerialization dataWithJSONObject:object
                                                   options:NSJSONWritingPrettyPrinted
                                                     error:&error];
if (! jsonData) {
    NSLog(@"Got an error: %@", error);
} else {

jsonString = [[NSString alloc] initWithData:jsonData encoding:NSUTF8StringEncoding];
}
return jsonString;
}
使用Shareinstall 控制中心提供的渠道統(tǒng)計時，在App用戶注冊完成后調(diào)用，可以統(tǒng)計渠道注冊量。

警告：必須在注冊成功的時調(diào)用[ShareInstallSDK reportRegister] 方法，否則可能導致注冊統(tǒng)計不準。

由上比較得知，shareinstall與友盟最大的優(yōu)勝點就在于首先實現(xiàn)完全自主。這很大一部分是因為它們一開始實現(xiàn)目的就有差別。例如：友盟針對一項SDK下載，需要同時下載3個包，而shareinstall則可以一鍵完成；而在集成上，友盟面對不同的項目需要不同的操作，過程過于繁瑣。而shareinstall通過 URL Scheme 和 Universal Links 實現(xiàn)在不同瀏覽器中拉起APP，應用集成造成的代碼冗余少，集成簡單。攜參安裝實現(xiàn)個性化，渠道統(tǒng)計更精確。