最近幾天遇到了兩個令人發(fā)指的啟動速度影響問題
1.Android9.0,targetSdkVersion>=28,系統(tǒng)就建議如果WebView是多進程使用的衬以，需要在Application中手動設(shè)置WebView的獨立進程的數(shù)據(jù)目錄又厉，如下：
你敢想？提交之后冗荸，冷啟動變慢了30ms+,郵件發(fā)出來的瞬間，懵逼了利耍。蚌本。。隘梨。在快速定位到這個提交點之后程癌，我反復(fù)的看代碼，感覺只可能和這個有關(guān)轴猎。嵌莉。。捻脖。锐峭，但是在方法前后加log打印查看耗時情況。可婶。沿癞。。矛渴。納尼椎扬？不耗時啊。具温。蚕涤。一點都不耗時。铣猩。揖铜。。是不是測試結(jié)果有問題剂习。蛮位。失仁。萄焦。立刻馬上找測試同學(xué)再來一遍，我不信在抛。。朴读。這不存在的衅金。。拙寡。5分鐘后般堆，啪啪打臉。和橙。五辽。乡翅。很穩(wěn)定的就是多30ms+,無奈蠕蚜，我又回過頭來看代碼，在反問了自己10遍不可能之后，萬分無奈澈灼。。店溢。我選擇先注釋掉看下叁熔。。床牧。荣回。結(jié)果很棒，冷啟動的時間數(shù)據(jù)正常了戈咳，好的心软。。著蛙。那是為什么呢删铃？本身方法不耗時，而且測試的手機還是5.0的手機踏堡，邏輯都不會走猎唁。。顷蟆。怎么多了一行代碼就唧唧思密達了诫隅。。帐偎。逐纬。難道只是因為引用了這個靜態(tài)方法就導(dǎo)致耗時？好吧肮街，我們把代碼改一下风题，反射試試？
呵呵，完美解決沛硅。數(shù)據(jù)一如既往的完美眼刃。。摇肌。擂红。有時候繼續(xù)寫
增加于2019/12/05,距離上次寫這篇記錄已經(jīng)過去好幾個月，后來在嘗試其他解決方案后围小，發(fā)現(xiàn)直接將原有的直接引用抽取到一個工具類中以靜態(tài)方法的方式調(diào)用也同樣能解決問題昵骤，那感覺可能就和java代碼編譯有關(guān)了，有興趣的朋友可以去了解下肯适。
