Litho官網(wǎng)
公司主營業(yè)務(wù)：網(wǎng)站設(shè)計制作、網(wǎng)站設(shè)計、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。成都創(chuàng)新互聯(lián)是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊有機(jī)會用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)推出撫遠(yuǎn)免費做網(wǎng)站回饋大家。
Litho是Facebook推出的一套高效構(gòu)建Android UI的聲明式框架，主要目的是提升RecyclerView復(fù)雜列表的滑動性能和降低內(nèi)存占用。
聲明式組件
允許用戶使用聲明式的API（注解）來構(gòu)建符合Flexbox規(guī)范的布局。
異步布局
支持組件掛載，異步線程執(zhí)行measure和layout操作，UI線程完成繪制工作
扁平化布局
Litho使用Yoga來完成組件布局的測量和計算，而且支持將View轉(zhuǎn)換成Drawable渲染，降低了View層級，實現(xiàn)了布局的扁平化
細(xì)粒度組件復(fù)用
支持Text、Image或者Video細(xì)粒度組件的復(fù)用，尤其在多ItemType的列表中有顯著性能提升
Litho采用聲明式的API來定義UI組件，組件通過一組不可變的屬性來描述UI。這種組件化的思想靈感來源于React，實踐過ReactNative或React都深有體會。不過聲明式組件也有弊端，開發(fā)者不能直接預(yù)覽布局編寫，從而影響開發(fā)效率。
Android系統(tǒng)在繪制時為了防止頁面錯亂，頁面所有View的測量（Measure）、布局（Layout）以及繪制（Draw）都是在UI線程中完成的。當(dāng)頁面UI非常復(fù)雜、視圖層級較深時，難免Measure和Layout的時間會過長，從而導(dǎo)致頁面渲染時候丟幀出現(xiàn)卡頓情況。
Litho鑒于此，提出了異步布局思想，最終實現(xiàn)了控件維度下異步線程完成measure和layout操作，在主線程完成draw操作。
首先，我們了解下 Android原生為什么不支持異步布局呢？
Litho的對策是怎樣的呢 ？
View onMeasure時，在LayoutState中的clollectResults() 遞歸調(diào)用了nodeTree中的結(jié)點，最終調(diào)用yoga來計算結(jié)點的位置，目標(biāo)就算是把所有的節(jié)點最終繪制到一個View中，降低View的層級。
View onLayout時，在MountState中，對所有的Component進(jìn)行Mount調(diào)用，準(zhǔn)備好需要繪制的具體內(nèi)容，以待繪制調(diào)用。
同時Litho引入了緩存機(jī)制，可以提前在異步線程中進(jìn)行measure和layout的操作，這樣在繪制過程中只需要draw就可以了，理論提升效率35%（FaceBook宣傳）
使用Litho布局，我們可以得到一個極致扁平的視圖效果。它可以減少渲染時的遞歸調(diào)用，加快渲染速度。
下面是同一個視圖在Android和Litho實現(xiàn)下的視圖層級效果對比?？梢钥吹剑瑯拥臉邮?，使用Litho實現(xiàn)的布局要比使用Android原生實現(xiàn)的布局更加扁平。
雖然平坦的視圖結(jié)構(gòu)對內(nèi)存使用和繪圖時間有重要的好處，但它們并非萬能的靈丹妙藥。Litho 有一個非常通用的系統(tǒng)來自動“ unflatten（堆疊起來） ” 已掛載組件的層次結(jié)構(gòu)，當(dāng)使用 Android View 里一些不可或缺的功能，如觸摸事件的處理，無障礙功能，或限制失效等。例如，如果要在示例中啟用單擊圖像或文本，則框架會自動將它們包裝在視圖中。
Litho中的所有組件都可以被回收，并在任何位置進(jìn)行復(fù)用。這種細(xì)粒度的復(fù)用方式可以極大地提高內(nèi)存使用率，尤其適用于多Item類型的復(fù)雜列表，內(nèi)存優(yōu)化非常明顯。
RecyclerView 支持顯示多樣內(nèi)容。為此，它根據(jù)視圖的類型將視圖保存在不同的緩沖池中。雖然這個概念在簡單的情況下工作得很好，但是對于具有許多不同視圖類型的 UI 來說，它可能會出現(xiàn)問題。在包含許多視圖類型的場景中，在滾動事件之后進(jìn)入窗口的視圖更有可能是 RecyclerView 第一次顯示的視圖。如果發(fā)生這種情況，RecyclerView 必須分配一個新的視圖。發(fā)生分配的 16ms 時間槽內(nèi) RecyclerView 也必須同時對即將顯示的視圖執(zhí)行綁定、測量和布局操作
Litho 提供更具擴(kuò)展性和高效率的回收系統(tǒng)，同時我們希望從 API 中消除視圖類型的復(fù)雜性。 Litho 布局的表示與在屏幕上渲染布局的 View 和Drawable 完全脫節(jié)。這意味著，當(dāng)我們需要在屏幕上放置一個新的 RecyclerView 視圖時，我們已經(jīng)知道該項目的內(nèi)容以及它相對于其余 UI 的位置。 這使 Litho 完全擺脫 View 類型的概念。在 RecyclerView 滾動時，我們可以遞增地使用文本或圖像等構(gòu)建塊，而不是重新使用表示RecyclerView中項目的整個 View。 這對于傳統(tǒng)的 Android 視圖來說是不可能的，因為布局計算在完整的視圖樹上運行，并且當(dāng)我們知道所有視圖在一行中的位置時，所有視圖都已經(jīng)被實例化了。
InternalNode：由Component+（View）NodeInfo轉(zhuǎn)化得到的表示布局信息的節(jié)點
DiffNode：InternalNode的輕量級表示形式，用于在兩個布局樹的計算之間緩存測量結(jié)果，如果不需要更新，那么直接復(fù)用DiffNode即可
MountSpec：對應(yīng)的Component包含純粹的View或者Drawable，比如TextSpec，ImageSpec
LayoutSpec：對應(yīng)的Component類似于ViewGroup，內(nèi)部組織管理了很多子Component，比如CardSpec，SpinnerSpec
什么條件復(fù)用DiffNode至InternalNode ？
參考
Litho的使用及原理剖析
LithoGitBook
工具/原料
android 基礎(chǔ)
91桌面
數(shù)據(jù)線
android手機(jī)
方法/步驟
在手機(jī)安裝好91桌面哈，然后將頁面滑到最左面的“快速搜索頁”
hierarchyviewer.bat是sdk自帶的工具，在tools文件夾下。雙擊即可打開
在此頁面，加粗顯示的就是當(dāng)前進(jìn)程，點擊load view hierarchy就可以分層查看布局
左邊的大圖，為應(yīng)用圖層的樹形結(jié)構(gòu)。上面有控件名稱和id等信息。然后下面三個圓點代表渲染的速度，綠色最快，紅色最慢，其中從左到右依次表示的是測量大小，布局和繪制。再看右下角的那個數(shù)字，代表的是此節(jié)點在父節(jié)點中的索引。
整張圖的右下角，表示的該應(yīng)用的當(dāng)前頁面。在左邊的樹形圖中點擊某個節(jié)點，會在這里用紅框標(biāo)出響應(yīng)的位置。左上角的圖可以查看當(dāng)前選中節(jié)點的具體布局?jǐn)?shù)據(jù)，寬高什么的。
這里可以看出“快速搜索屏”的實現(xiàn)是，
draglayer--孩子---workspacelayer-----孩子0---workspace；
------孩子1---singleViewGroup;
singleViewGroup就是快速搜索屏的布局view
在網(wǎng)上找到一個圖，覺得很好，介紹的精確完整，貼過來，給大家看看
ConstraintLayout (約束布局) 繼承于ViewGroup 允許開發(fā)者以靈活的方式定位和調(diào)整小部件的大小
ConstraintLayout 可讓開發(fā)者使用扁平視圖層次結(jié)構(gòu)（無嵌套視圖組）創(chuàng)建復(fù)雜的大型布局。它與 RelativeLayout 相似，其中所有的視圖均根據(jù)同級視圖與父布局之間的關(guān)系進(jìn)行布局，但其靈活性要高于 RelativeLayout ，并且更易于與 Android Studio 的布局編輯器配合使用。我理解為ConstraintLayout是一個更加靈活且減少嵌套的 RelativeLayout 的布局
ConstraintLayout作為支持庫提供，開發(fā)者可以在從 API 級別 9 (Gingerbread) 開始的 Android 系統(tǒng)上使用。
相信在面對一些復(fù)雜的UI頁面,咱們都是使用 RelativeLayout , LinearLayout 層層嵌套實現(xiàn)的.雖然能實現(xiàn)效果.但是層層嵌套層層解析加載View 無疑會耗費加載時間,耗費手機(jī)性能.這是時候ConstraintLayout(約束布局),就應(yīng)運而生了,它出現(xiàn)的目的就是減少嵌套,優(yōu)化層層嵌套狀況帶來的弊端
要在 ConstraintLayout 中定義某個視圖的位置， 您必須為該視圖添加至少一個水平約束條件和一個垂直約束條件 。每個約束條件均表示與其他視圖、父布局或隱形引導(dǎo)線之間連接或?qū)R方式。每個約束條件均定義了視圖在豎軸或者橫軸上的位置；因此每個視圖在每個軸上都必須至少有一個約束條件，但通常情況下會需要更多約束條件。
當(dāng)您將視圖拖放到布局編輯器中時，即使沒有任何約束條件，它也會停留在您放置的位置。不過，這只是為了便于修改；當(dāng)您在設(shè)備上運行布局時，如果視圖沒有任何約束條件，則會在位置 [0,0]（左上角）處進(jìn)行繪制。
在圖 1 中，布局在編輯器中看起來很完美，但視圖 C 上卻沒有垂直約束條件。在設(shè)備上繪制此布局時，雖然視圖 C 與視圖 A 的左右邊緣水平對齊，但由于沒有垂直約束條件，它會顯示在屏幕頂部
請注意，約束中不能有循環(huán)依賴。
相對定位是在 ConstraintLayout 中創(chuàng)建布局的基本構(gòu)建塊之一。這些約束允許您相對于另一個小部件定位給定的小部件。您可以在水平和垂直軸上約束一個小部件：
如下圖,這告訴系統(tǒng)我們希望按鈕 B 的左側(cè)被約束到按鈕 A 的右側(cè)。這樣的位置約束意味著系統(tǒng)將嘗試讓兩側(cè)共享相同的位置。
這是可用約束的列表：
app:layout_constraintLeft(自身)_toLeftOf(相對于的控件)="相對的控件ID"
1.2 layout_constraintBaseline_toBaselineOf 基線對齊
如果設(shè)置了側(cè)邊距，它們將應(yīng)用于相應(yīng)的約束（如果存在）（圖 ），將邊距強制為目標(biāo)端和源端之間的空間。通常的布局邊距屬性可用于此效果
2.1屬性:
請注意，邊距只能為正數(shù)或等于零，并且取Dimension.
2.2. 約束目標(biāo)View.GONE的時候 的邊距
3.1 居中定位,就是把定位控件的左邊對應(yīng)目標(biāo)的左邊 右邊對應(yīng)目標(biāo)的右邊,上邊對應(yīng)目標(biāo)的上邊
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintTop_toTopOf="parent"
如上圖,Button的左邊位于父布局的左邊,右邊位于父布局的右邊就做到了水平居中的效果
3.2 偏移 : 有時候居中展示還需要做出偏移效果
可以以一定角度和距離約束一個小部件中心相對于另一個小部件中心。這允許您將一個小部件定位在一個圓圈上
ConstraintLayout對標(biāo)記為 的小部件進(jìn)行了特定處理View.GONE。
GONE像往常一樣，小部件不會被顯示并且不是布局本身的一部分（即，如果標(biāo)記為 ，它們的實際尺寸不會改變GONE）。
但就布局計算而言，GONE小部件仍然是其中的一部分，但有一個重要區(qū)別：
注意：
使用的邊距將是 B 在連接到 A 時定義的邊距（參見圖 7 示例）。在某些情況下，這可能不是您想要的邊距（例如，A 到其容器的一側(cè)有 100dp 的邊距，B 到 A 的邊距只有 16dp，將 A 標(biāo)記為已消失，B 到容器的邊距為 16dp）。出于這個原因，您可以指定在連接到被標(biāo)記為已消失的小部件時使用的備用邊距值（請參閱 上面有關(guān)已消失的邊距屬性的部分 ）
1.1 您可以為自身定義最小和最大尺寸ConstraintLayout
1.2 控件尺寸約束
android:layout_width可以通過 3 種不同方式設(shè)置和 android:layout_height屬性 來指定控件的尺寸：
重要提示：
MATCH_PARENT不建議用于ConstraintLayout. 可以通過MATCH_CONSTRAINT將相應(yīng)的左/右或上/下約束設(shè)置為來定義類似的行為"parent"。
WRAP_CONTENT （添加在 1 . 1中）：強制約束
如果維度設(shè)置為WRAP_CONTENT，則在 1.1 之前的版本中，它們將被視為文字維度——也就是說，約束不會限制結(jié)果維度。雖然通常這已經(jīng)足夠（并且更快），但在某些情況下，您可能希望使用WRAP_CONTENT，但繼續(xù)強制執(zhí)行約束以限制結(jié)果維度。在這種情況下，您可以添加相應(yīng)的屬性之一：
MATCH_CONSTRAINT維度（添加在 1 . 1中）
當(dāng)維度設(shè)置為MATCH_CONSTRAINT時，默認(rèn)行為是讓結(jié)果大小占用所有可用空間。有幾個額外的修飾符可用：
layout_constraintWidth_min和layout_constraintHeight_min: 將設(shè)置此維度的最小尺寸
layout_constraintWidth_max和layout_constraintHeight_max: 將設(shè)置此維度的最大尺寸
layout_constraintWidth_percent和layout_constraintHeight_percent: 將此維度的大小設(shè)置為父維度的百分比
比率: 寬高比
您還可以將小部件的一個維度定義為另一個維度的比率。為此，您需要將至少一個約束維度設(shè)置為0dp（即MATCH_CONSTRAINT），并將屬性設(shè)置layout_constraintDimensionRatio為給定的比率。例如：
除此之外，在設(shè)置寬高比的值的時候，還可以在前面加W或H，分別指定寬度或高度限制。 例如：
app:layout_constraintDimensionRatio="H,2:3"指的是 高:寬=2:3
app:layout_constraintDimensionRatio="W,2:3"指的是 寬:高=2:3
...
Guildline的主要屬性：
Constraint 約束布局為了解決嵌套布局的弊端,更快的加載頁面而出現(xiàn),但是約束布局需要整體架構(gòu)頁面要有明確的構(gòu)建頁面的思維,故而學(xué)習(xí)以及思維模式要有的.所以個人感覺是簡單頁面還是用相對布局,線性布局就夠了,對于復(fù)雜布局約束布局是你優(yōu)化頁面加載的不二之選.
*寫作不容易,且贊且珍惜!!!*
Android啟動應(yīng)用, 按 官方說法 分為冷啟動, 溫啟動和熱啟動.
具體的定義可以看官方文檔, 簡單地說
一般我們只需要關(guān)注冷啟動即可.
要想啟動快, 硬件性能必然有影響, 在硬件一定的前提下, 我們要盡量 降低啟動應(yīng)用時CPU的負(fù)載 , 讓CPU有更多的算力投入到啟動流程中:
在做好一些基本原則后, 接著看具體的流程優(yōu)化點
在應(yīng)用進(jìn)程創(chuàng)建后, 首先必然是加載類, 此時一些靜態(tài)變量就會初始化了, 因此我們應(yīng)該
類加載完畢后就是創(chuàng)建 Application 實例了, 因此我們應(yīng)該
之后會先創(chuàng)建 ContentProvider 和執(zhí)行 ContentProvider.onCreate() , 因此我們應(yīng)該
跟接著就會執(zhí)行 Application.onCreate() 等方法, 因此我們應(yīng)該
接著就進(jìn)入 Activity 環(huán)節(jié).
同樣第一步會是創(chuàng)建實例, 因此我們應(yīng)該
在 Activity 進(jìn)程生命周期后, 第一步就是渲染(inflate)布局, 我們應(yīng)該
在應(yīng)用啟動的瞬間, 系統(tǒng)服務(wù)會先展示一個空白窗口, 等待應(yīng)用第一幀繪制完畢后, 再從該窗口切換到應(yīng)用, 如果啟動耗時較長, 就會明顯看到白屏, 對于這一點, 常見的操作有
可以使用IdleHandler, 在主線程空閑時再執(zhí)行某些不重要的操作
實際上異步初始化只是不阻塞主線程, 但是子線程一樣會占用CPU資源, 讓主線程的執(zhí)行時間變少, 所以不應(yīng)該盲目地將所有工作放到子線程.
優(yōu)化做到最后, 就是在系統(tǒng)流程上做文章了
原理是將啟動時加載的類放到主dex，提升了這些類的內(nèi)聚，讓更多的類滿足pre-verify的條件，在安裝時就做了校驗和優(yōu)化，以減少首次加載的耗時，從而優(yōu)化冷啟動耗時。
Redex 初探與 Interdex：Andorid 冷啟動優(yōu)化
應(yīng)用啟動過程中會從apk壓縮包中讀取文件, 該優(yōu)化的原理是利用Linux中的Pagecache機(jī)制, 讓啟動過程會用到的文件盡可能進(jìn)入緩存中, 減少磁盤IO次數(shù)
支付寶 App 構(gòu)建優(yōu)化解析：通過安裝包重排布優(yōu)化 Android 端啟動性能
在Dalvik VM(Android5.0以前)加載類的時候會有一個類校驗過程, 它需要校驗方法的每一個指令, 是一個比較耗時的過程, 可以通過Hook去掉類加載過程中的類驗證過程. 不過對于ART(Android5.0之后)來說, 這個過程在安裝時已經(jīng)做了, 所以用處不大.
不進(jìn)入冷啟動, 就不用優(yōu)化了~
這個Android Studio自帶的工具, 可以看到啟動過程中詳細(xì)的方法執(zhí)行流程, 但是采集數(shù)據(jù)本身會影響方法執(zhí)行, 所以不能準(zhǔn)確判斷每個方法的耗時, 但是仍可以判斷哪個方法相對來說耗時.
這個工具的好處是可以自定義事件, 可以指定需要采集的數(shù)據(jù)集, 可以看到線程間的狀態(tài)等.
啟動優(yōu)化的一個關(guān)鍵點在于定義啟動結(jié)束的點, 以及如何測量啟動時間.
在Android4.4以上, 系統(tǒng)進(jìn)程會提供一個類似 ActivityManager: Displayed ***: +3s534ms 的日志, 表示從啟動進(jìn)程到首次繪制完畢所用的時間.
應(yīng)用可以在任何時候調(diào)用該方法, 觸發(fā)系統(tǒng)打印類似 system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms 的日志
應(yīng)用可以通過 ViewTreeObserver 來監(jiān)聽繪制前回調(diào)來判斷第一幀的繪制時機(jī), 或者直接在控件樹的末尾加一個簡單的View, 它 onDraw 調(diào)用時即表示頁面(差不多)繪制完畢.
應(yīng)用啟動過程可以參考 Android Vitals Series' Articles 系列文章
Android常見的5個布局，我想大家一定不會陌生。LinearLayout、RelativeLayout和FrameLayout也是使用頻率較高的布局方式，做Android開發(fā)的一定使用過。
傳統(tǒng)的5種布局方式：
不過我的問題并不是問面試者如何使用這些基礎(chǔ)的布局，而是要看面試者怎么解決布局嵌套（影響性能）和屏幕適配問題。
我們都清楚Android界面的布局太復(fù)雜，嵌套層次過深，會使整個界面的測量、布局和繪制變得更復(fù)雜，對性能會造成影響。所以我們在寫Layout文件時，也要盡量避免布局的嵌套層次過深的問題。
在怎么解決問題之前，我們得有一個好方法先判斷當(dāng)前的問題情況。Android SDK工具箱中有一個叫做Hierarchy Viewer的工具，能夠在App運行時分析Layout。
注意： 在ROOT的手機(jī)，或者是安裝開發(fā)版的ROM的手機(jī)可以直接使用Hierarchy Viewer。如果沒有Root的手機(jī)(SDK 4.1及以上)，需要在你的PC端添加一個環(huán)境變量“ANDROID_HVPROTO=ddm”。
下面列舉一些面試者常使用的方式。
merge merge標(biāo)簽的作用是合并UI布局，使用該標(biāo)簽?zāi)芙档蚒I布局的嵌套層次。
merge標(biāo)簽可用于兩種情況：
ViewStub ViewStub標(biāo)簽引入的布局默認(rèn)不會inflate，既不會顯示也不會占用位置。 ViewStub常用來引入那些默認(rèn)不會顯示，只在特殊情況下顯示的布局，如數(shù)據(jù)加載進(jìn)度布局、出錯提示布局等。
需要在使用時手動inflate:
ViewStub在一定的程度可以起到減少嵌套層次的作用，特別是很多時候我們的程序可能不需要走到ViewStub的界面。
include 將可復(fù)用的組件抽取出來并通過include標(biāo)簽使用，但include標(biāo)簽?zāi)軠p少布局的層次嗎？
我認(rèn)為不能。include主要解決的是相同布局的復(fù)用問題，它并不能減少布局的層次。
用RelativeLayout代替LinearLayout
很多人為了減少布局層次喜歡用RelativeLayout代替LinearLayout，不過可能達(dá)到的效果并不會很明顯。層次是減少了，但本身RelativeLayout就會比LinearLayout性能差一點。
有一些界面，比如一個圖片和一個文本的布局（ListItem常見的布局方式），可以利用TextView有drawableLeft, drawableRight等屬性，完全不需要RelativeLayout或者LinearLayout布局。
傳統(tǒng)的布局方式存在一定的缺陷，如RelativeLayout要兩次測量（measure）它的子View才能知道確切的高度；如果LinearLayout布局的子View有設(shè)置了layout_weight，那么它也需要測量兩次才能獲得布局的高度。
相對于傳統(tǒng)的布局方式，Android官方還推出了兩種新的布局方式：ConstraintLayout和FlexboxLayout。
ConstraintLayout ConstraintLayout即約束布局，在2016年由Google I/O推出。ConstraintLayout和RelativeLayout有點類似，控件之間根據(jù)依賴關(guān)系而存在，但比RelativeLayout更加靈活。創(chuàng)建大型復(fù)雜的布局仍然可以使用扁平的層級(不用嵌套View Group)，說的簡單些就是，再復(fù)雜的界面也可以只有2層層次。
要使用ConstraintLayout需要在build.gradle中添加相關(guān)的support庫：
使用ConstraintLayout可以有效的解決布局嵌套過多導(dǎo)致的性能問題，官方也對其渲染性能進(jìn)行了優(yōu)化，并且ConstraintLayout支持可視化的方式編寫布局。
不過學(xué)會熟練使用ConstraintLayout會需要一點時間，但這是值得的。
FlexBoxLayout 做過前端開發(fā)（CSS方面）的同學(xué)對FlexBox一定不會陌生，最近我在做微信小程序開發(fā)時也涉及到FlexBox。FlexBox(彈性布局)是w3c在2009年提出的一種新的布局方案，解決以前那種傳統(tǒng)css的盒模型的局限性。
Google開源了FlexboxLayout布局和前端CSS FlexBox布局具有相同的功能（肯定有不一樣的地方），但已經(jīng)足夠在Android上改進(jìn)布局的構(gòu)建方式。
FlexBoxLayout可以理解成一種更高級的LinearLayout，不過比LinearLayout更加強大和靈活。如果我們使用LinearLayout布局的話，那么不同的分辨率，也許我們要重新調(diào)整布局，勢必會需要跟多的布局文件放在不同的資源目錄。而使用FlexBoxLayout來布局的話，它可以適應(yīng)各種界面的改變（所以叫響應(yīng)式布局）。
如果對前端的Flexbox不太了解的話，你還需要補一些概念，好在這些東西在網(wǎng)上很容易找到。
可能很多讀者會覺這樣的面試題是吹毛求疵，很多項目中哪有這么復(fù)雜的界面，根本就用不到這些優(yōu)化措施。
可以說厲害的人，或者叫高手，可能只是比較多在意這些細(xì)節(jié)而已。在實踐中的經(jīng)歷告訴我，很多難于解決的性能問題，并不是因為有一個影響性能的問題無法攻克，而是沒有一個明顯的制約因素，是有各種小問題一點一點堆積起來，最終積重難返。
所以，把細(xì)節(jié)做好，或者意識到細(xì)節(jié)的地方可能引發(fā)的問題，對我們解決問題是很有幫助的，不要浪費了讓你可以成長的細(xì)節(jié)。
有需要更多Android高級進(jìn)階和面試資料的朋友可以私信我獲取
布局誘惑就是減少層級嵌套，減少overdraw。越簡單越好
1、善用相對布局Relativelayout
在RelativeLayout和LinearLayout同時能夠滿足需求時，盡量使用RelativeLayout，因為可以通過扁平的RelativeLayout降低LinearLayout嵌套所產(chǎn)生布局樹的層級。
可以使用AS自帶工具協(xié)助優(yōu)化布局---- Hierarchy View ，
用法：打開需要獲取view層級的那個界面，然后依次點擊菜單Tools - Android - Android Device Monitor。
2.2、merge標(biāo)簽
merge標(biāo)簽是作為include標(biāo)簽的一種輔助擴(kuò)展來使用，它的主要作用是為了防止在引用布局文件時產(chǎn)生多余的布局嵌套。如：
這樣提取出來后，使用上述的include標(biāo)簽引用布局時，就可以減少一個布局的嵌套了。而這一布局的子View的父層級直接是使用include引用的布局
2.3、viewstub標(biāo)簽
viewstub是view的子類。他是一個輕量級View， 隱藏的，沒有尺寸的View。他可以用來在程序運行時簡單的填充布局文件。同時他也有一個layout屬性，當(dāng)它隱藏時，不會顯示任何布局和占據(jù)任何空間。當(dāng)它顯示時，就會用layout內(nèi)的布局替代顯示layout內(nèi)的布局。
這里的ViewStub控件的layout指定為item_test_linear_layout。當(dāng)點擊button隱藏的時候不會顯示item_test_linear_layout，而點擊button顯示的時候就會用item_test_linear_layout替代ViewStub。
3、使用最新布局ConstaintLayout
ConstraintLayout允許你在不適用任何嵌套的情況下創(chuàng)建大型而又復(fù)雜的布局。它與RelativeLayout非常相似，所有的view都依賴于兄弟控件和父控件的相對關(guān)系。
具體的使用可以查看相關(guān)的文檔： ConstaintLayout使用
4、Android Lint工具尋求可能優(yōu)化布局的層次
一些Lint規(guī)則如下：
1、使用組合控件： 包含了一個ImageView以及一個TextView控件的LinearLayout如果能夠作為一個組合控件將會被更有效的處理。即自定義控件類型
2、合并作為根節(jié)點的幀布局(Framelayout) ：如果一個幀布局是布局文件中的根節(jié)點，而且它沒有背景圖片或者padding等，更有效的方式是使用merge標(biāo)簽替換該Framelayout標(biāo)簽 。
3、無用的葉子節(jié)點：通常來說如果一個布局控件沒有子視圖或者背景圖片，那么該布局控件是可以被移除(由于它處于 invisible狀態(tài))。
4、無用的父節(jié)點 ：如果一個父視圖即有子視圖，但沒有兄弟視圖節(jié)點，該視圖不是ScrollView控件或者根節(jié)點，并且它沒有背景圖片，也是可以被移除的，移除之后，該父視圖的所有子視圖都直接遷移至之前父視圖的布局層次。同樣能夠使解析布局以及布局層次更有效。
5、過深的布局層次：內(nèi)嵌過多的布局總是低效率的。考慮使用一些扁平的布局控件，例如 RelativeLayout、GridLayout ，來改善布局過程。默認(rèn)最大的布局深度為10 。
文章出處： 更詳細(xì)文章： Android性能優(yōu)化之布局優(yōu)化
重慶分公司
重慶分公司
