精品欧美一区二区三区在线观看 _久久久久国色av免费观看性色_国产精品久久在线观看_亚洲第一综合网站_91精品又粗又猛又爽_小泽玛利亚一区二区免费_91亚洲精品国偷拍自产在线观看 _久久精品视频在线播放_美女精品久久久_欧美日韩国产成人在线

得物 iOS 啟動優化之 Building Closure

移動開發 iOS
我們探索了 BuildingClosure 的生成過程,發現在Building Closure階段中,可能存在字符串的 Hash 碰撞 引發循環次數大幅增加,進而引發了啟動耗時暴增,進而導致啟動耗時的大幅增加。

一、神秘的 BuildingClosure

    1. dyld && BuildingClosure

    2. BuildingClosure 非常耗時

    3. BuildingClosure 文件解析

二、離奇的啟動耗時暴增事件 

    1. 啟動耗時暴增 200ms

    2. BuildingClosure 耗時異常變化定位

三、啟動優化新秘境

    1. Perfect Hash

    2. 向前一步

四、總結

得物一直重視用戶體驗,尤其是啟動時長這一重要指標。在近期的啟動時長跟進中,我們發現了在BuildingClosure 階段的一個優化方式,成功的幫助我們降低了 1/5 的 BuildingClosure 階段的啟動耗時。Building Closure 并非工程的編譯階段(雖然它有一個building),Building Closure 是應用初次啟動時會經歷的階段,因此它會影響應用的啟動時長。

單就BuildingClosure階段而言,我們觀察到該階段其中一個函數從 480ms 暴增到 1200ms 左右(PC 電腦端運行 dyld 調試統計耗時數據),我們通過優化,將耗時從1200ms降低到110ms。即使相比最開始的情況,也相當于從480ms降低到了110ms,由此可見Building Closure 優化是應用進行啟動優化必不可少的一個重要手段。因此在這里我們也和各位讀者進行分享,期望能夠對各自項目有所幫助。

一、神秘的 BuildingClosure

啟動優化的技術、實現方案業界有不少的文章可以參考學習,這里不再額外贅述。我們來探索下啟動過程中非常神秘的 BuildingClosure。

BuildingClosure 是在 System Interface Initialization 階段 dyld 生成的,并且我們也無法做任何的干預,另外相關的剖析文章相對較少,所以說 BuildingClosure 較為神秘,也是實至名歸。

BuildingClosure 是由 dyld 在應用啟動階段執行的,所以想要了解 BuildingClosure 還是要從 dyld 開始了解。

dyld && BuildingClosure

Dyld 源碼可以在 Apple GitHub 上查閱 https://github.com/apple-oss-distributions/dyld

相信大家都應該了解過,BuildingClosure 是在 iOS 13 引入進來的,對應的 dyld 為 dyld3,目的是為了減少啟動環節符號查找、Rebase、Bind 的耗時。

核心技術邏輯是將重復的啟動工作只做一次,在 App 首次啟動、版本更新、手機重啟之后的這次啟動過程中,將相關信息緩存到 Library/Caches/com.app.dyld/xx.dyld 文件中,App 在下次啟動時直接使用緩存好的信息,進而優化二次啟動的速度。

在 iOS 15 Dyld4 中更是引入了 SwiftConformance,進一步解決了運行時 Swift 中的類型、協議檢查的耗時。

圖片圖片

以上優化,我們都無需做任何工作即可享受 dyld 帶來的啟動速度的優化,可以感受到 Apple 的開發人員也在關心啟動速度并為之做了大量的工作。

BuildingClosure 非常耗時

我們通過 instrument 觀測到 BuildingClosure 的耗時占據了啟動耗時將近 1/3 的時間。

雖然說,BuildingClosure 只會在首次啟動、版本更新、手機重啟的第一次啟動生成和耗時,但是對用戶的體驗影響是非常之大的。

圖片圖片

BuildingClosure 文件解析

我們通過對 dyld 的編譯和搭建模擬手機環境,成功模擬器了 dyld 加載可執行文件的過程,也就成功解析了 BuildingClosure 文件。BuildingClosure 文件數據格式如下(數據格式、注釋僅供參考,并非全部的數據格式):

BuildingClosure 文件內部結構(數據格式、注釋僅供參考)BuildingClosure 文件內部結構(數據格式、注釋僅供參考)

其中占用比較大的部分主要為 Loader-selectorReferencesFixupsSize SwiftTypeConformance  objcSelector objcClass

二、離奇的啟動耗時暴增事件

如上,我們已經對 BuildingClosure 有了基本的了解和對 dyld 的執行過程有了一定的了解。但是這份寧靜在某一天突然被打破。

啟動耗時暴增 200ms

在我們一個新版本開發過程中,例行對啟動耗時進行跟蹤測試,但是發現新版本啟動耗時暴增 200ms,可以說是災難級別的事情。

我們開始對最近的出包做了基本的耗時統計,方式為基于 instrument,統計出來啟動各個階段的耗時數據。經過對比,可以明顯觀測到,200ms 耗時的增加表現在 BuildingClosure 這個環節。

但是 BuildingClosure 耗時的增加既不是階梯式增加,也不是線性增加,并且只在新版本有增加。在排除相關因素(動態庫、工程配置、打包腳本、編譯環境)之后,仍然沒有定位明確的原因。

在以上定位工作之后,最終確定耗時確實在 dyld 的 BuildingClosure 階段耗時,并且懷疑可能是某些代碼觸發了 Dyld 的隱藏彩蛋。所以我們開始了對 BuildingClosure 更深一步的研究。

BuildingClosure 耗時異常變化定位

通過使用 Instrument 對 System Interface Initialization 階段進行堆棧分析,最終發現了耗時最高的函數:dyld4::PrebuiltObjC::generateHashTables(dyld4::RuntimeState&)

在對比了新老版本數據,耗時變化差異的函數也是此函數,我們簡稱為 generateHashTables。這樣使得我們更加確定耗時為 dyld 過程中的 BuildingClosure 階段。

圖片

使用 Instrument 分析 BuildingClosure 階段耗時

三、啟動優化新秘境

在發現 BuildingClosure 生成過程中耗時占比非常大,并且有異常時,起初并沒有意識到有什么問題,因為這是 dyld 內的代碼,并未感覺會有什么問題。但是一切都指向了該函數,于是開始擼起袖子看代碼。

從代碼中可以看到,此處是為了生成 BuildingClosure 中 objcSelector objcClass objcProtocol 這三個部分的 HashTable(可以參考上面的 【BuildingClosure 文件解析】部分)。

拿起 dyld 開始對耗時異常版本的可執行文件進行調試,通過對該函數和內部實現的代碼邏輯閱讀,以及增加耗時信息打印。最終確定,耗時的代碼在 make_perfect 這個函數中,這個函數是對【輸入的字符串列表】生成一個【完美 Hash 表】。

void PrebuiltObjC::generateHashTables(RuntimeState& state)
{
    // Write out the class table
    writeObjCDataStructHashTable(state, PrebuiltObjC::ObjCStructKind::classes, objcImages, classesHashTable, duplicateSharedCacheClassMap, classMap);
    // Write out the protocol table
    writeObjCDataStructHashTable(state, PrebuiltObjC::ObjCStructKind::protocols, objcImages, protocolsHashTable, duplicateSharedCacheClassMap, protocolMap);
    // If we have closure selectors, we need to make a hash table for them.
    if ( !closureSelectorStrings.empty() ) {
        objc::PerfectHash phash;
        objc::PerfectHash::make_perfect(closureSelectorStrings, phash);
        size_t size = ObjCStringTable::size(phash);
        selectorsHashTable.resize(size);
        //printf("Selector table size: %lld\n", size);
        selectorStringTable = (ObjCStringTable*)selectorsHashTable.begin();
        selectorStringTable->write(phash, closureSelectorMap.array());
    }
}

繼續深入了解 make_perfect 這個函數的實現。

Perfect Hash

通過對研讀代碼邏輯和耗時分析,最終定位到耗時代碼部分為PerfectHash.cpp 中 findhash 函數,這個函數也是 完美散列函數 的核心邏輯。

  這里涉及到了一個概念PerfectHash,PerfectHash 的核心是完美散列函數,我們看下維基百科的解釋:

https://zh.wikipedia.org/wiki/%E5%AE%8C%E7%BE%8E%E6%95%A3%E5%88%97

對集合S的完美散列函數是一個將S的每個元素映射到一系列無沖突的整數的哈希函數

簡單來講 完美散列函數 是【對輸入的字符串列表】【為每個字符串生成一個唯一整數】。

for (si=1; ; ++si)
    {
        ub4 rslinit;
        /* Try to find distinct (A,B) for all keys */
        *salt = si * 0x9e3779b97f4a7c13LL; /* golden ratio (arbitrary value) */
        initnorm(keys, *alen, blen, smax, *salt);
        rslinit = inittab(tabb, keys, FALSE);
        if (rslinit == 0)
        {
            /* didn't find distinct (a,b) */
            if (++bad_initkey >= RETRY_INITKEY)
            {
                /* Try to put more bits in (A,B) to make distinct (A,B) more likely */
                if (*alen < maxalen)
                {
                    *alen *= 2;
                }
                else if (blen < smax)
                {
                    blen *= 2;
                    tabb.resize(blen);
                    tabq.resize(blen+1);
                }
                bad_initkey = 0;
                bad_perfect = 0;
            }
            continue;                             /* two keys have same (a,b) pair */
        }
        /* Given distinct (A,B) for all keys, build a perfect hash */
        if (!perfect(tabb, tabh, tabq, smax, scramble, (ub4)keys.count()))
        {
            if (++bad_perfect >= RETRY_PERFECT)
            {
                if (blen < smax)
                {
                    blen *= 2;
                    tabb.resize(blen);
                    tabq.resize(blen+1);
                    --si;               /* we know this salt got distinct (A,B) */
                }
                else
                {
                    return false;
                }
                bad_perfect = 0;
            }
            continue;
        }
        break;
    }

此時通過對比新老版本的數據(使用 dyld 分別運行新老版本的可執行文件對比打印的日志),發現:

  • 老版本循環了 31 次成功生成 HashTable
  • 新版本循環了 92 次成功生成 HashTable

至此,我們距離成功已經非常接近了,于是進一步研讀 dyld 源碼和增加了更多打印信息代碼,最終找到了相互沖突的函數字符串名稱。

/*
 * put keys in tabb according to key->b_k
 * check if the initial hash might work
 */
static int inittab_ts(dyld3::OverflowSafeArray<bstuff>& tabb, dyld3::OverflowSafeArray<key>& keys, int complete, int si)
// bstuff   *tabb;                     /* output, list of keys with b for (a,b) */
// ub4       blen;                                            /* length of tabb */
// key      *keys;                               /* list of keys already hashed */
// int       complete;        /* TRUE means to complete init despite collisions */
{
  int  nocollision = TRUE;
  ub4 i;
  memset((void *)tabb.begin(), 0, (size_t)(sizeof(bstuff)*tabb.maxCount()));
  /* Two keys with the same (a,b) guarantees a collision */
  for (i = 0; i < keys.count(); i++) {
    key *mykey = &keys[i];
    key *otherkey;
    for (otherkey=tabb[mykey->b_k].list_b;
     otherkey;
     otherkey=otherkey->nextb_k)
    {
      if (mykey->a_k == otherkey->a_k)
      {
          // 打印沖突的字符串
        std::cout << mykey->name_k << " and " << otherkey->name_k << " has the same ak " << otherkey->a_k << " si is " << si << std::endl;
        nocollision = FALSE;
          /* 屏蔽此處代碼,有沖突的情況下,繼續執行,便于打印所有的沖突
    if (!complete)
      return FALSE;
           */
      }
    }
    ++tabb[mykey->b_k].listlen_b;
    mykey->nextb_k = tabb[mykey->b_k].list_b;
    tabb[mykey->b_k].list_b = mykey;
  }
  /* no two keys have the same (a,b) pair */
  return nocollision;
}

根據以上信息,我們已經了解到在Building Closure階段中,可能存在字符串的 Hash 碰撞 引發循環次數大幅增加,進而引發了啟動耗時暴增。

在經過 dyld 調試的耗時數據、構建出包后驗證的數據驗證后,通過避免 Hash 碰撞,我們完成了啟動時長的優化。

向前一步

其實從打印的沖突函數名稱來看,歷史代碼中已經存在了 Hash 碰撞 的現象。

猜想,如果我們解決了所有的字符串的 Hash 碰撞,豈不是不僅可以修復啟動耗時異常上升的問題,還可以進一步降低啟動耗時,提高啟動速度?

于是我們對每個有碰撞的函數名稱進行修改,經過出包驗證,結果與我們猜測的一致,啟動耗時有明顯的下降。

數據為 PC 電腦端運行 dyld 生成 BuildingClosure 的耗時數據,非手機端數據數據為 PC 電腦端運行 dyld 生成 BuildingClosure 的耗時數據,非手機端數據


四、總結

我們探索了 BuildingClosure 的生成過程,發現在Building Closure階段中,可能存在字符串的 Hash 碰撞 引發循環次數大幅增加,進而引發了啟動耗時暴增,進而導致啟動耗時的大幅增加。

我們也發現,Building Closure Hash碰撞相關的啟動耗時,其實與項目配置、編譯環境、打包腳本等均無任何關系,就只是存在了字符串的Hash 碰撞 ,才引發循環次數大幅增加,進而導致啟動時長增加。

責任編輯:武曉燕 來源: 得物技術
相關推薦

2023-08-30 18:49:05

2024-09-03 16:09:59

2023-05-10 18:34:49

推薦價格體驗優化UV

2023-07-19 22:17:21

Android資源優化

2022-11-14 14:53:14

架構技術編輯工具

2021-11-23 10:25:35

性能優化iOS App 啟動優化

2024-08-13 15:26:44

2019-12-13 10:25:08

Android性能優化啟動優化

2023-03-30 18:39:36

2025-11-11 01:55:00

2022-12-12 18:56:04

2023-08-21 19:37:21

得物DGraph引擎

2023-04-28 18:37:38

直播低延遲探索

2023-10-09 18:35:37

得物Redis架構

2025-03-13 06:48:22

2017-01-19 19:07:28

iOS進階性能優化

2019-09-25 08:03:21

Android加速Google

2022-12-14 18:40:04

得物染色環境

2024-12-03 11:12:47

2023-02-08 18:33:49

SRE探索業務
點贊
收藏

51CTO技術棧公眾號

欧洲杯足球赛直播| 欧美特黄色片| 国产女人水真多18毛片18精品视频 | 国产精品久久久久影院日本| 裸体武打性艳史| 乱亲女h秽乱长久久久| 欧美性色综合网| 国产精品视频二| 国产在线一二三| 国产成人综合亚洲91猫咪| 欧美在线性视频| 劲爆欧美第一页| 欧美极品在线观看| 日韩美女视频一区二区在线观看| 免费黄色特级片| 国内高清免费在线视频| 欧美国产精品v| 国内成+人亚洲| 国产美女精品视频国产| 免费在线成人| 久久久人成影片一区二区三区| 免费视频91蜜桃| 丝袜av一区| 日韩欧美的一区| 免费成年人高清视频| 在线黄色的网站| 亚洲高清免费在线| 日本老太婆做爰视频| 国产原创av在线| 99久久精品国产精品久久| 91免费电影网站| 中文字幕日韩经典| 久久资源在线| 69视频在线免费观看| 国产一区二区视频在线观看免费| 欧美艳星介绍134位艳星| 日韩成人中文字幕在线观看| 佐山爱在线视频| 视频欧美精品| 欧美日韩免费不卡视频一区二区三区 | 成人av片网址| 亚洲国产精品国自产拍久久| 国内久久精品视频| 成人黄色免费看| 91影院在线播放| 美女网站色91| 国产日韩精品在线| 伊人免费在线观看高清版| 日韩和的一区二区| 国产精品电影在线观看| av首页在线观看| 日本不卡视频一二三区| 国产精品日韩在线| 最近中文字幕av| 免费精品视频最新在线| 国产精品欧美日韩久久| 国产精品露脸视频| 久草精品在线观看| 亚洲综合av影视| 亚洲av色香蕉一区二区三区| 风流少妇一区二区| 久久精品国产综合精品| 色综合久久网女同蕾丝边| 久久久综合九色合综国产精品| 欧美日韩在线观看一区二区三区| 理论在线观看| 亚洲国产高清aⅴ视频| 中文字幕av日韩精品| h片在线播放| 天天av天天翘天天综合网色鬼国产| 免费av手机在线观看| 忘忧草在线日韩www影院| 91久久精品午夜一区二区| 欧美婷婷精品激情| 狂野欧美xxxx韩国少妇| 欧美精品一区二区蜜臀亚洲| 插吧插吧综合网| 日本欧美视频| 欧美成人激情图片网| 国产乡下妇女做爰视频| 性欧美暴力猛交另类hd| 成人亚洲欧美一区二区三区| 日韩中文字幕免费观看| 国产女主播在线一区二区| 国产在线拍揄自揄拍无码| 免费电影网站在线视频观看福利| 天天影视涩香欲综合网| 亚洲欧美另类动漫| 4438全国亚洲精品观看视频| 亚洲欧美一区二区三区情侣bbw| 成年人视频软件| 99精品福利视频| 国产欧美韩国高清| 欧美一级性视频| 国产精品初高中害羞小美女文| 性一交一乱一伧国产女士spa| 羞羞影院欧美| 日韩精品一区二区三区在线| 日本一区二区视频在线播放| 激情综合亚洲| 国产视频999| 亚洲人视频在线观看| 中文字幕在线不卡视频| 免费看的黄色大片| 日韩精品一区二区三区免费视频| 亚洲午夜av久久乱码| 久视频在线观看| 免费观看成人av| 久久大片网站| 欧美人动性xxxxz0oz| 欧美日韩亚洲国产综合| 亚洲国产精品成人综合久久久| 欧美在线国产| 国产精品视频内| 免费在线毛片| 香蕉加勒比综合久久| 制服丝袜中文字幕第一页| 嫩草一区二区三区| 97久久精品人人澡人人爽缅北| 国产成人久久精品77777综合 | 91在线播放网址| 99er在线视频| 韩国三级大全久久网站| 中文一区二区视频| av首页在线观看| 久久久久久亚洲综合影院红桃| www成人免费| 国产成人精品a视频一区| 两女双腿交缠激烈磨豆腐| 福利视频亚洲| 亚洲午夜精品视频| 日本中文在线播放| 成人免费高清在线| 国产中文字幕乱人伦在线观看| 欧美第一在线视频| 久久久精品国产一区二区| 中文字幕人妻精品一区| 国产欧美日本一区二区三区| 妞干网在线免费视频| 蜜臀久久99精品久久一区二区| 26uuu国产精品视频| 少妇人妻偷人精品一区二区| 亚洲福中文字幕伊人影院| 制服丝袜av在线| 国内精品久久久久久久97牛牛| 3d蒂法精品啪啪一区二区免费| 免费网站黄在线观看| 欧美日高清视频| 免费观看特级毛片| 韩国精品免费视频| 日本福利视频网站| 99亚洲乱人伦aⅴ精品| 久久人人爽人人| 亚欧在线观看视频| 色又黄又爽网站www久久| 99国产精品免费| 久久国产成人午夜av影院| 午夜在线视频免费观看| 警花av一区二区三区| 久久99国产综合精品女同| 亚洲精品无码久久久| 午夜电影久久久| 丝袜美腿中文字幕| 日韩电影免费一区| 一本一道久久a久久精品综合 | 成人免费网视频| 超碰在线最新| 亚洲国产精品小视频| 久久国产乱子伦精品| 最近日韩中文字幕| 亚洲av无码一区东京热久久| 久久精品亚洲一区二区| 在线观看日韩片| 成功精品影院| 国产精品电影观看| 青草在线视频在线观看| 亚洲精品在线视频| 国产精品国产三级国产普通话对白| 亚洲一区二区视频| 公侵犯人妻一区二区三区| 看片网站欧美日韩| 精品视频在线观看一区| 波多野结衣在线观看一区二区三区| 亚洲999一在线观看www| 伊人网在线播放| 日韩有码在线视频| 少妇激情av一区二区| 69av一区二区三区| 中文字幕日韩一级| 中文字幕日本不卡| 青青草成人免费视频| 国产一二三精品| 熟妇人妻va精品中文字幕| 欧美aⅴ99久久黑人专区| 欧洲亚洲一区| 老司机在线精品视频| 91精品国产综合久久香蕉的用户体验| av大全在线| 在线精品高清中文字幕| 人妻精品一区一区三区蜜桃91| 欧美性大战久久久久久久蜜臀| 国产精品999久久久| 国产精品国产a| 亚洲精品午夜视频| 成人福利在线看| 亚洲色图欧美自拍| 麻豆精品国产传媒mv男同| 国产 福利 在线| 国模大胆一区二区三区| 日本一级淫片演员| 欧美性感美女一区二区| 久久99精品国产一区二区三区| 欧美午夜在线播放| 成人黄色在线免费| 国产a亚洲精品| 国产精品99久久久久久www| 91吃瓜在线观看| 欧美国产日韩免费| 黄在线免费观看| 日韩在线免费视频观看| 户外极限露出调教在线视频| 亚洲精品美女在线观看播放| www.精品视频| 欧美一区二区在线观看| 中文字幕有码视频| 欧美亚洲综合一区| www.久久视频| 一本久道久久综合中文字幕| 国产成人免费观看视频| 午夜精品在线看| 国产精品第56页| 亚洲一区二区三区四区五区中文| 男女羞羞免费视频| 亚洲欧美色图小说| 国精品无码一区二区三区| 国产精品久久久久久久久图文区| 永久免费毛片在线观看| 日本一区免费视频| 国产又粗又猛又爽又黄av| 26uuu成人网一区二区三区| 日本一卡二卡在线| 97久久精品人人爽人人爽蜜臀| 国产一卡二卡三卡四卡| 99久久精品国产毛片| 播金莲一级淫片aaaaaaa| 久久亚洲综合av| 美女爆乳18禁www久久久久久| 久久婷婷久久一区二区三区| 91久久免费视频| 中文成人综合网| 视频国产一区二区| 亚洲四区在线观看| 久久久久久久九九九九| 亚洲大片精品永久免费| 国产小视频在线免费观看| 一本色道久久加勒比精品| 中文字幕+乱码+中文乱码91| 欧美日韩免费一区二区三区| 国产99999| 亚洲精品成人久久电影| 蜜芽tv福利在线视频| 国产小视频国产精品| 精精国产xxxx视频在线| 国产69精品久久久久99| 日韩电影免费观| 国产综合香蕉五月婷在线| 爱爱精品视频| 日韩久久不卡| 中文字幕一区二区三区在线视频| 日本中文字幕在线视频观看| 国产亚洲综合精品| 91女神在线观看| 国产成人午夜视频| 中文字幕在线看高清电影| 中文字幕制服丝袜一区二区三区| 久草中文在线视频| 色婷婷综合久久久中文一区二区| 国产一区二区三区中文字幕| 亚洲国产中文字幕久久网| 韩国中文免费在线视频| 欧美xxxx做受欧美.88| 国产欧洲在线| 成人黄色在线免费| 四虎884aa成人精品最新| 中文字幕不卡每日更新1区2区| 亚洲免费激情| 国产成人美女视频| 97久久人人超碰| 美女的奶胸大爽爽大片| 色屁屁一区二区| 性生活视频软件| 中文字幕亚洲一区二区三区| 乱馆动漫1~6集在线观看| 91在线视频九色| 伊人久久综合影院| 国产av熟女一区二区三区| 人人爽香蕉精品| 久久人妻一区二区| 亚洲免费观看高清完整版在线观看熊| 亚洲精品午夜国产va久久成人| 欧美一区二区网站| www.中文字幕久久久| 国内精品久久久久久影视8| 先锋影音网一区二区| 欧美人与物videos另类| 国产一区美女| 天天久久综合网| 国产日本一区二区| 日本视频www| 日韩免费成人网| 黄色大片在线播放| 国产精品欧美激情| 在线日本制服中文欧美| 日本wwwcom| 国产精品1区二区.| 国产一二三区精品| 欧美日本精品一区二区三区| p色视频免费在线观看| 91精品国产91久久久久久吃药| 日韩成人视屏| 国产又粗又大又爽的视频| 美女网站色91| 国产7777777| 在线观看一区日韩| 欧美色综合一区二区三区| 欧美做受高潮电影o| 久久亚洲道色| 国产精品自拍片| 成人av电影在线播放| 久久久一二三区| 精品久久一区二区三区| 调教一区二区| 不卡的av一区| 亚洲激情国产| 国产在线观看无码免费视频| 天天操天天色综合| 日本福利在线观看| 国产成人精品久久久| 国产亚洲一区| 国产九九在线观看| 国产精品久久久久9999吃药| 亚洲中文一区二区三区| 日韩中文字幕国产| 欧美电影在线观看一区| 成人av在线不卡| eeuss影院一区二区三区| 青青草成人av| 国产视频精品一区二区三区| xx欧美xxx| 性欧美.com| 精品一区二区三区免费视频| 久久久久99精品成人片试看| 日韩精品一区二区三区四区| 91福利区在线观看| 欧美日韩一区在线观看视频| 日本成人中文字幕在线视频 | 牛牛热在线视频| 国产精品成人久久久久| 999国产精品| 欧美熟妇精品一区二区| 欧美日韩国产丝袜另类| 国产一级片在线| 亚洲一区制服诱惑| 伊人成人在线视频| 少妇精品无码一区二区免费视频| 欧美日韩一级二级| 免费毛片在线看片免费丝瓜视频| 久久99国产精品| 麻豆专区一区二区三区四区五区| 天天看片中文字幕| 精品无人区太爽高潮在线播放 | 精品综合免费视频观看| 青青青在线视频| 亚洲女人被黑人巨大进入| 福利精品在线| 国产人妻777人伦精品hd| 欧美激情一区不卡| wwwxxxx国产| 国产成人一区二| 欧美日韩91| 天天干天天舔天天操| 日韩欧美一区二区久久婷婷| 日韩伦理三区| 欧美性猛交内射兽交老熟妇| 国产视频一区二区三区在线观看| www.黄色小说.com| 国产精品99蜜臀久久不卡二区| 欧美精品18| av片在线免费看| 亚洲国产另类 国产精品国产免费| 国产亚洲精彩久久| 免费看一级大黄情大片| 中文字幕一区二区三区av| 视频国产在线观看| www 成人av com| 久久97超碰国产精品超碰| 久久久久亚洲av成人毛片韩| 久久电影一区二区| av中文一区| 免费在线观看你懂的|