摘要：由于啟用硬件加速所需的資源增加，您的應(yīng)用程序?qū)⑾母唷Ｖ蕴摼€會(huì)在大部分手機(jī)上繪制成實(shí)現(xiàn)是因?yàn)榫褪且驗(yàn)榈姆椒ú恢С钟布铀佟Ｆ鋵?shí)通過上表可以看到，在級(jí)別以后，就可以不用關(guān)閉硬件加速也可以繪制定義的虛線了。

首發(fā)公眾號(hào)：Android程序員日記
作者：賢榆的榆
如果喜歡，請(qǐng) 關(guān)注 | 贊賞 | 點(diǎn)在看
閱讀時(shí)間：4978字 8分鐘

今天剛好是《千與千尋》在中國(guó)首映的日子。所以放一張《千與千尋》的海報(bào)，我也沒想到過去這么久了，其實(shí)都都已經(jīng)看過很多遍了。但還是想要在大屏幕上再看一次。小時(shí)候看動(dòng)畫片，媽媽會(huì)說，這動(dòng)畫片有什么好看的，你能看一輩子呀！真是一語成真，估計(jì)這輩子是逃不出動(dòng)漫的坑了。（杠精就別糾結(jié)動(dòng)畫片和動(dòng)漫的不同了，在媽媽眼里，那都是一樣一樣的！），好了，娛樂休閑之前先學(xué)習(xí)一波兒！

前幾天做一個(gè)界面的時(shí)候，再一次出現(xiàn)了虛線顯式成實(shí)現(xiàn)的問題，我沒出息的又去搜解決方案了，為了記憶深刻，狠了狠心，深挖了一下。一起來看看吧：

我在xml布局文件中通過給一個(gè)View設(shè)置一個(gè)背景畫了一條虛線分割線代碼如下：

view中引用的common_line_draw_dash.xml代碼如下：

可是設(shè)備上的實(shí)際效果也預(yù)期效果并不一致，見下圖：

可能很多開發(fā)小伙伴都碰到過這個(gè)問題，也知道只需要在View的xml布局中添加如下一行代碼即可解決問題。
android:layerType="software"

古話說“知其然知其所以然”

從谷歌官方提供的關(guān)于硬件加速的資料顯示：

從Android 3.0（API級(jí)別11）開始，Android 2D渲染管道支持硬件加速，這意味著在View的畫布上執(zhí)行的所有繪圖操作都使用GPU。 由于啟用硬件加速所需的資源增加，您的應(yīng)用程序?qū)⑾母郣AM。

并且文章中還講到Android 4.0（API級(jí)別14）開始默認(rèn)開啟了硬件加速；但是

再往上找了一些關(guān)于硬件加速的文章比如這篇《關(guān)于硬件加速那點(diǎn)事兒》
地址：https://www.jianshu.com/p/9cd...
這是一篇Android硬件加速官方文章的譯文
里面介紹了不支持硬件加速的一些操作：

在里面看了一下之后就去掃View的源碼了，果然不出五分鐘就找了上圖中倒數(shù)第三的方法saveLayer();

看到background.draw(canvas)方法時(shí)，你可能想問我怎么知道這個(gè)虛線xml文件，最后實(shí)例化之后的Drawble對(duì)象對(duì)應(yīng)的GradientDrawble的對(duì)象。看下面這張圖，你就明白了：

按照平常，文章寫道這里就已經(jīng)結(jié)束了，一切都已經(jīng)說通了。但是作為一名程序員，嚴(yán)謹(jǐn)是一種良好職業(yè)操守，于是我又去了google官網(wǎng)看了英文原版關(guān)于硬件加速的介紹。
地址：https://developer.android.com...

然后這一看，就看出問題了。當(dāng)我看到上面這張圖的時(shí)候，我特么就尷尬了。怎么和之前我看到的那張圖不一樣了？saveLayer方法支持硬件加速？還是不支持？后來又用google搜索了一些資料，確實(shí)沒有一項(xiàng)有力的證件證明saveLayer方法是不支持硬件加速的；

既然這樣我們就需要重新去須按照其他的證據(jù)來證明View在畫虛線時(shí)，無法使用硬件加速，雖然上面圖中找到的saveLayer方法不能證明是需要關(guān)閉硬件加速的原因。但是這個(gè)View繪制背景的流程是沒有問題的，并且我們知道用標(biāo)簽定義的xml文件在膨脹后得到的是一個(gè)GradientDrawable對(duì)象。

既然在繪制背景流程中沒有可疑的不支持硬件加速的方法，那么在生成Drawable對(duì)象的過程是否能找得到一些可疑的方法呢？上面流程圖中的mBackground對(duì)象又是怎么來的？

帶著這兩個(gè)問題，思考了一下。這個(gè)View是通過xml膨脹生成的，那么應(yīng)該會(huì)調(diào)用View的2各參數(shù)或3個(gè)參數(shù)的構(gòu)造方法，然后我就順著這思路找了一下mBackground對(duì)象是怎么生成：

一路找下去找到了,上圖中藍(lán)色框部分的代碼

final Drawable.ConstantState cs;
if (isColorDrawable) {
    cs = sPreloadedColorDrawables.get(key);
} else {
    cs = sPreloadedDrawables[mConfiguration.getLayoutDirection()].get(key);
}
Drawable dr;
boolean needsNewDrawableAfterCache = false;
if (cs != null) {
    if (TRACE_FOR_DETAILED_PRELOAD) {
        // Log only framework resources
        if (((id >>> 24) == 0x1) && (android.os.Process.myUid() != 0)) {
            final String name = getResourceName(id);
            if (name != null) {
                Log.d(TAG_PRELOAD, "Hit preloaded FW drawable #"
                        + Integer.toHexString(id) + " " + name);
            }
        }
    }
    dr = cs.newDrawable(wrapper);
} else if (isColorDrawable) {
    dr = new ColorDrawable(value.data);
} else {
    dr = loadDrawableForCookie(wrapper, value, id, density, null);
}

然后大概可以看明白當(dāng)cs不為null時(shí)，Drawable是通過cs.newDrawable()方法生成的。cs在上面代碼中的第一行已經(jīng)定義了，它是一個(gè)Drawable的靜態(tài)內(nèi)部類Drawable.ConstantState；

既然前面我們已經(jīng)知道用標(biāo)簽定義的虛線XML文件膨脹后是一個(gè)GradientDrawable對(duì)象。那么GradientDrawable也應(yīng)該有自己的ConstantState內(nèi)部類。點(diǎn)進(jìn)GradientDrawable的源碼拉到底部，果然就看到了一個(gè)繼承自ConstantState的GradientState類。借著又是一招順藤摸瓜：

GradientState類重寫了ConstantState的newDrawable方法，在該方法中通過調(diào)用GradientDrawable的構(gòu)造方法構(gòu)建了一個(gè)GradientDrawable實(shí)例。

在GradientDrawable構(gòu)造方法中則進(jìn)行了一些初始動(dòng)作，其中調(diào)用的updateLocalState方法中的一段代碼（上圖藍(lán)色框）引起了我注意，最引人注目的還是那段紅色框里的的方法。這個(gè)方法好像在不支持硬件加速的操作表中。喜極而泣！明了，明了...。

這里再粘一下這段代碼：

if (state.mStrokeDashWidth != 0.0f) {
    final DashPathEffect e = new DashPathEffect(
            new float[] { state.mStrokeDashWidth, state.mStrokeDashGap }, 0);
    mStrokePaint.setPathEffect(e);
}

它判斷了StrokeDashWidth是否有值，如果有這則根據(jù)虛線的的兩個(gè)重要屬性state.mStrokeDashWidth和state.mStrokeDashGap構(gòu)造一個(gè)DashPathEffect對(duì)象，然后在通過Paint的setPathEffect(e)方法來繪制虛線。

到這里一切都水落石出了。之所以虛線會(huì)在大部分手機(jī)上繪制成實(shí)現(xiàn)是因?yàn)榫褪且驗(yàn)镻aint的setPathEffect()方法不支持硬件加速。其實(shí)通過上表可以看到，在Android 9（API級(jí)別28）以后，就可以不用關(guān)閉硬件加速也可以繪制XML定義的虛線了。

好了這篇文章就寫到這里吧，大家在追源碼的時(shí)候給大家一個(gè)提醒：

晚上10點(diǎn)以后不宜閱讀源，因?yàn)槟愀就２幌聛怼?/pre>
雖然有些滑稽，但卻是真是的哈哈。
另外，如果你是初學(xué)者，到?jīng)]有必要花費(fèi)太多精力去探索。畢竟初學(xué)者完成一個(gè)App，對(duì)知識(shí)和技術(shù)的廣度認(rèn)知比深度要重要的多。但是到了一定時(shí)候（我也說不清是什么時(shí)候，你自己應(yīng)該會(huì)有感覺）——我個(gè)人覺得是做了兩三年吧，當(dāng)你遇到問題時(shí)，就不應(yīng)僅僅只停留在解決問題的層面，還應(yīng)該深入了解一下為什么。哪怕一開始你就知道導(dǎo)致這個(gè)問題的原因是某個(gè)方法。但是找出這個(gè)方法，這一探索，研究的過程才是這個(gè)階段你成長(zhǎng)的最大助力。與君共勉！
如果有想法可以留言；覺得有幫助，可以關(guān)注我的公眾號(hào)
推薦閱讀
系列文章

「Do.006」實(shí)戰(zhàn)(1)——我想說“開始吧”
「Do.007」實(shí)戰(zhàn)(2)——使用Github進(jìn)行版本管理
「Do.008」實(shí)戰(zhàn)((3)——Git 分支管理模型
「Do.009」實(shí)戰(zhàn)(4)——AndroidStudio插件推薦
「Do.014」實(shí)戰(zhàn)(5)—— gradle 配置release與debug環(huán)境分離

其他

「Do.016」圖解Win電腦下載騰訊視頻轉(zhuǎn)mp4
「Do.017」如何高效使用Win電腦？
「Do.018」接私活兒，是否有必要？
「Do.019」2018這一年——年終總結(jié)
「Do.020」程序員該如何在寒冬中自處
「Do.021」一文了解AndroidStudio3.4的全部更新