android佈局優化的一些實用建議
前言
Android的繪制優化其實可以分為兩個部分，即佈局(UI)優化和卡頓優化，而佈局優化的核心問題就是要解決因佈局渲染性能不佳而導致應用卡頓的問題，所以它可以認為是卡頓優化的一個子集。
本文主要包括以下內容
- 為什麼要進行佈局優化及android繪制，佈局加載原理
- 獲取佈局文件加載耗時的方法
- 介紹一些佈局優化的手段與方法
- 一些常規優化手段
為什麼要進行佈局優化？
為什麼要進行佈局優化？答案是顯而易見的，如果佈局嵌套過深，或者其他原因導致佈局渲染性能不佳，可能會導致應用卡頓 那麼佈局到底是如何導致渲染性能不佳的呢？首先我們應該瞭解下android繪制原理與佈局加載原理
android繪制原理
Android的屏幕刷新中涉及到最重要的三個概念（為便於理解，這裡先做簡單介紹）
- CPU：執行應用層的measure、layout、draw等操作，繪制完成後將數據提交給GPU
- GPU：進一步處理數據，並將數據緩存起來
- 屏幕：由一個個像素點組成，以固定的頻率（16.6ms，即1秒60幀）從緩沖區中取出數據來填充像素點
總結一句話就是：CPU 繪制後提交數據、GPU 進一步處理和緩存數據、最後屏幕從緩沖區中讀取數據並顯示
雙緩沖機制
看完上面的流程圖，我們很容易想到一個問題，屏幕是以16.6ms的固定頻率進行刷新的，但是我們應用層觸發繪制的時機是完全隨機的（比如我們隨時都可以觸摸屏幕觸發繪制）. 如果在GPU向緩沖區寫入數據的同時，屏幕也在向緩沖區讀取數據，會發生什麼情況呢？有可能屏幕上就會出現一部分是前一幀的畫面，一部分是另一幀的畫面，這顯然是無法接受的，那怎麼解決這個問題呢？
所以，在屏幕刷新中，Android系統引入瞭雙緩沖機制
GPU隻向Back Buffer中寫入繪制數據，且GPU會定期交換Back Buffer和Frame Buffer，交換的頻率也是60次/秒，這就與屏幕的刷新頻率保持瞭同步。
雖然我們引入瞭雙緩沖機制，但是我們知道，當佈局比較復雜，或設備性能較差的時候，CPU並不能保證在16.6ms內就完成繪制數據的計算，所以這裡系統又做瞭一個處理。當你的應用正在往Back Buffer中填充數據時，系統會將Back Buffer鎖定。如果到瞭GPU交換兩個Buffer的時間點，你的應用還在往Back Buffer中填充數據，GPU會發現Back Buffer被鎖定瞭，它會放棄這次交換。
這樣做的後果就是手機屏幕仍然顯示原先的圖像，這就是我們常常說的掉幀
佈局加載原理
由上面可知，導致掉幀的原因是CPU無法在16.6ms內完成繪制數據的計算。而之所以佈局加載可能會導致掉幀，正是因為它在主線程上進行瞭耗時操作，可能導致CPU無法按時完成數據計算
佈局加載主要通過setContentView來實現，我們就不在這裡貼源碼瞭，一起來看看它的時序圖
我們可以看到，在setContentView中主要有兩個耗時操作
- 解析xml,獲取XmlResourceParser,這是IO過程
- 通過createViewFromTag,創建View對象，用到瞭反射
以上兩點就是佈局加載可能導致卡頓的原因，也是佈局的性能瓶頸
獲取佈局文件加載耗時的方法
我們如果需要優化佈局卡頓問題，首先最重要的就是：確定定量標準 所以我們首先介紹幾種獲取佈局文件加載耗時的方法
常規獲取
首先介紹一下常規方法
val start = System.currentTimeMillis() setContentView(R.layout.activity_layout_optimize) val inflateTime = System.currentTimeMillis() - start
這種方法很簡單，因為setContentView是同步方法，如果想要計算耗時，直接將前後時間計算相減即可得到結果瞭
AOP(Aspectj,ASM)
上面的方式雖然簡單，但是卻不夠優雅，同時代碼有侵入性，如果要對所有Activity測量時，就需要在基類中復寫相關方法瞭，比較麻煩瞭 下面介紹一種AOP的方式計算耗時
@Around("execution(* android.app.Activity.setContentView(..))")
public void getSetContentViewTime(ProceedingJoinPoint joinPoint) {
Signature signature = joinPoint.getSignature();
String name = signature.toShortString();
long time = System.currentTimeMillis();
try {
joinPoint.proceed();
} catch (Throwable throwable) {
throwable.printStackTrace();
}
Log.i("aop inflate",name + " cost " + (System.currentTimeMillis() - time));
}
上面用的Aspectj，比較簡單，上面的註解的意思是在setContentView方法執行內部去調用我們寫好的getSetContentViewTime方法 這樣就可以獲取相應的耗時 我們可以看下打印的日志
I/aop inflate: AppCompatActivity.setContentView(..) cost 69
I/aop inflate: AppCompatActivity.setContentView(..) cost 25
這樣就可以實現無侵入的監控每個頁面佈局加載的耗時 具體源碼可見文末
獲取任一控件耗時
有時為瞭更精確的知道到底是哪個控件加載耗時，比如我們新添加瞭自定義View,需要監控它的性能 我們可以利用setFactory2來監聽每個控件的加載耗時 首先我們來回顧下setContentView方法
public final View tryCreateView(@Nullable View parent, @NonNull String name,
...
View view;
if (mFactory2 != null) {
view = mFactory2.onCreateView(parent, name, context, attrs);
} else if (mFactory != null) {
view = mFactory.onCreateView(name, context, attrs);
} else {
view = null;
}
...
return view;
}
在真正進行反射實例化xml結點前，會調用mFactory2的onCreateView方法 這樣如果我們重寫onCreateView方法，在其前後加上耗時統計，即可獲取每個控件的加載耗時
private fun initItemInflateListener(){
LayoutInflaterCompat.setFactory2(layoutInflater, object : Factory2 {
override fun onCreateView(
parent: View?,
name: String,
context: Context,
attrs: AttributeSet
): View? {
val time = System.currentTimeMillis()
val view = delegate.createView(parent, name, context, attrs)
Log.i("inflate Item",name + " cost " + (System.currentTimeMillis() - time))
return view
}
override fun onCreateView(name: String, context: Context, attrs: AttributeSet): View? {
return null
}
})
}
如上所示：真正的創建View的方法，仍然是調用delegate.createView,我們隻是其之前與之後做瞭埋點 註意，initItemInflateListener需要在onCreate之前調用 這樣就可以比較方便地實現監聽每個控件的加載耗時
佈局加載優化的一些方法介紹
佈局加載慢的主要原因有兩個,一個是IO,一個是反射 所以我們的優化思路一般有兩個
- 側面緩解(異步加載)
- 根本解決(不需要IO,反射過程,如X2C,Anko,Compose等)
AsyncLayoutInflater方案
AsyncLayoutInflater 是來幫助做異步加載 layout 的，inflate(int, ViewGroup, OnInflateFinishedListener) 方法運行結束之後 OnInflateFinishedListener 會在主線程回調返回 View；這樣做旨在 UI 的懶加載或者對用戶操作的高響應。
簡單的說我們知道默認情況下 setContentView 函數是在 UI 線程執行的，其中有一系列的耗時動作：Xml的解析、View的反射創建等過程同樣是在UI線程執行的，AsyncLayoutInflater 就是來幫我們把這些過程以異步的方式執行，保持UI線程的高響應。
使用如下:
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
new AsyncLayoutInflater(AsyncLayoutActivity.this)
.inflate(R.layout.async_layout, null, new AsyncLayoutInflater.OnInflateFinishedListener() {
@Override
public void onInflateFinished(View view, int resid, ViewGroup parent) {
setContentView(view);
}
});
// 別的操作
}
這樣做的優點在於將UI加載過程遷移到瞭子線程，保證瞭UI線程的高響應 缺點在於犧牲瞭易用性，同時如果在初始化過程中調用瞭UI可能會導致崩潰
X2C方案
X2C是掌閱開源的一套佈局加載框架 它的主要是思路是在編譯期，將需要翻譯的layout翻譯生成對應的java文件，這樣對於開發人員來說寫佈局還是寫原來的xml，但對於程序來說，運行時加載的是對應的java文件。這就將運行時的開銷轉移到瞭編譯時 如下所示,原始xml文件：
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:paddingLeft="10dp">
<include
android:id="@+id/head"
layout="@layout/head"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_centerHorizontal="true" />
<ImageView
android:id="@+id/ccc"
style="@style/bb"
android:layout_below="@id/head" />
</RelativeLayout>
X2C 生成的 Java 文件
public class X2C_2131296281_Activity_Main implements IViewCreator {
@Override
public View createView(Context ctx, int layoutId) {
Resources res = ctx.getResources();
RelativeLayout relativeLayout0 = new RelativeLayout(ctx);
relativeLayout0.setPadding((int)(TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_DIP,10,res.getDisplayMetrics())),0,0,0);
View view1 =(View) new X2C_2131296283_Head().createView(ctx,0);
RelativeLayout.LayoutParams layoutParam1 = new RelativeLayout.LayoutParams(ViewGroup.LayoutParams.WRAP_CONTENT,ViewGroup.LayoutParams.WRAP_CONTENT);
view1.setLayoutParams(layoutParam1);
relativeLayout0.addView(view1);
view1.setId(R.id.head);
layoutParam1.addRule(RelativeLayout.CENTER_HORIZONTAL,RelativeLayout.TRUE);
ImageView imageView2 = new ImageView(ctx);
RelativeLayout.LayoutParams layoutParam2 = new RelativeLayout.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT,(int)(TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_DIP,1,res.getDisplayMetrics())));
imageView2.setLayoutParams(layoutParam2);
relativeLayout0.addView(imageView2);
imageView2.setId(R.id.ccc);
layoutParam2.addRule(RelativeLayout.BELOW,R.id.head);
return relativeLayout0;
}
}
使用時如下所示,使用X2C.setContentView替代原始的setContentView即可
// this.setContentView(R.layout.activity_main); X2C.setContentView(this, R.layout.activity_main);
X2C優點
- 在保留xml的同時，又解決瞭它帶來的性能問題
- 據X2C統計，加載耗時可以縮小到原來的1/3
X2C問題
- 部分屬性不能通過代碼設置,Java不兼容
- 將加載時間轉移到瞭編譯期，增加瞭編譯期耗時
- 不支持kotlin-android-extensions插件，犧牲瞭部分易用性
Anko方案
Anko是JetBrains開發的一個強大的庫,支持使用kotlin DSL的方式來寫UI,如下所示
class MyActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?, persistentState: PersistableBundle?) {
super.onCreate(savedInstanceState, persistentState)
MyActivityUI().setContentView(this)
}
}
class MyActivityUI : AnkoComponent<MyActivity> {
override fun createView(ui: AnkoContext<MyActivity>) = with(ui) {
verticalLayout {
val name = editText()
button("Say Hello") {
onClick { ctx.toast("Hello, ${name.text}!") }
}
}
}
}
如上所示，Anko使用kotlin DSL實現佈局，它比我們使用Java動態創建佈局方便很多，主要是更簡潔，它和擁有xml創建佈局的層級關系，能讓我們更容易閱讀 同時，它去除瞭IO與反射過程,性能更好，以下是Anko與XML的性能對比
不過由於AnKo已經停止維護瞭，這裡不建議大傢使用，瞭解原理即可 AnKo建議大傢使用Jetpack Compose來替代使用
Compose方案
Compose 是 Jetpack 中的一個新成員，是 Android 團隊在2019年I/O大會上公佈的新的UI庫,目前處於Beta階段 Compose使用純kotlin開發，使用簡潔方便，但它並不是像Anko一樣對ViewGroup的封裝 Compose 並不是對 View 和 ViewGroup 這套系統做瞭個上層包裝來讓寫法更簡單，而是完全拋棄瞭這套系統，自己把整個的渲染機制從裡到外做瞭個全新的。
可以確定的是,Compose是取代XML的官方方案
Compose的主要優點就在於它的簡單好用，具體來說就是兩點
- 它的聲明式 UI
- 去掉瞭 xml，隻使用 Kotlin 一種語言
由於本文並不是介紹Compose的，所以就不繼續介紹Compose瞭，總得來說，Compose是未來android UI開發的方向,讀者可以自行查閱相關資料
一些常規優化手段
上面介紹瞭一些改動比較大的方案，其實我們在實際開發中也有些常規的方法可以優化佈局加載 比如優化佈局層級，避免過度繪制等，這些簡單的手段可能正是可以應用到項目中的
優化佈局層級及復雜度
- 使用ConstraintLayout,可以實現完全扁平化的佈局，減少層級
- RelativeLayout本身盡量不要嵌套使用
- 嵌套的LinearLayout中，盡量不要使用weight，因為weight會重新測量兩次
- 推薦使用merge標簽，可以減少一個層級
- 使用ViewStub延遲加載
避免過度繪制
- 去掉多餘背景色,減少復雜shape的使用
- 避免層級疊加
- 自定義View使用clipRect屏蔽被遮蓋View繪制
總結
到此這篇關於android佈局優化的一些實用建議的文章就介紹到這瞭,更多相關android佈局優化內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！