響應(yīng)時(shí)間罢屈，它是用來(lái)衡量系統(tǒng)運(yùn)行效率的一個(gè)重要指標(biāo)嘀韧。評(píng)價(jià)一個(gè)應(yīng)用的響應(yīng)時(shí)間，可以從用戶(hù)感知和系統(tǒng)性能這兩個(gè)角度來(lái)考量缠捌。

響應(yīng)時(shí)間的長(zhǎng)短锄贷，可能影響用戶(hù)對(duì)某個(gè)功能、某個(gè)應(yīng)用、乃至某個(gè)系統(tǒng)的使用谊却。畢竟如果有選擇蹂随，沒(méi)有哪個(gè)人會(huì)愿意去使用卡頓的應(yīng)用，運(yùn)行慢的手機(jī)因惭。

作為一名開(kāi)發(fā)者，雖然我們平時(shí)可能只關(guān)注于堆業(yè)務(wù)绩衷，根本就沒(méi)有時(shí)間或者機(jī)會(huì)去優(yōu)化我們程序的響應(yīng)時(shí)間蹦魔，但是這些內(nèi)容對(duì)我們個(gè)人的技術(shù)成長(zhǎng)是至關(guān)重要的。大的不說(shuō)咳燕，這部分也是面試中經(jīng)澄鹁觯考察的內(nèi)容，知道了也不至于吃虧招盲。

那么接下來(lái)我們就長(zhǎng)話(huà)短說(shuō)低缩，趕緊來(lái)瞧瞧，到底如何來(lái)優(yōu)化我們應(yīng)用的響應(yīng)時(shí)間曹货。

1. 核心原則

在算法中咆繁，我們經(jīng)常會(huì)從時(shí)間復(fù)雜度和空間復(fù)雜度這兩個(gè)緯度來(lái)衡量算法的優(yōu)劣。

很多時(shí)候顶籽，我們無(wú)法做到時(shí)間復(fù)雜度和空間復(fù)雜度兩者都最佳玩般，只能在"時(shí)間"和"空間"中，取折中的最優(yōu)解礼饱。同樣的坏为，如果我們追求最極致的"時(shí)間"最佳，就可能需要犧牲一部分的"空間"镊绪，這就是拿"空間"換"時(shí)間"的解法匀伏。

即響應(yīng)時(shí)間優(yōu)化的核心：空間 -> 時(shí)間 （用空間換時(shí)間）

那么我們應(yīng)該怎么做呢？下面是我歸納總結(jié)出來(lái)的四項(xiàng)基本原則：

• 1.緩存優(yōu)先：能讀緩存讀緩存蝴韭。
• 2.減少新建：能復(fù)用絕不新建够颠。
• 3.減少任務(wù)：能不做的盡量不做。
• 4.具體問(wèn)題具體分析：針對(duì)具體事務(wù)本身進(jìn)行分析万皿，必須做的能提前做就提前做摧找，不必須做的延后做。

2. 優(yōu)化措施

可能我上面說(shuō)的這些核心和基本原則牢硅，對(duì)絕大多數(shù)人來(lái)說(shuō)都非常好理解蹬耘，但是知道了這些，并不代表你懂得如何進(jìn)行優(yōu)化减余。 這就好比你高中學(xué)數(shù)學(xué)综苔，即便告訴了你一堆的公式，但真要讓你來(lái)一道相關(guān)的應(yīng)用題，你還真不一定能解得出來(lái)如筛，這個(gè)時(shí)候"例題"就很關(guān)鍵了堡牡。

同樣的，即便你知道了一些關(guān)于應(yīng)用響應(yīng)時(shí)間優(yōu)化的核心和原則后杨刨，當(dāng)你真正面臨具體的優(yōu)化問(wèn)題時(shí)晤柄，你可能也會(huì)手足無(wú)措。

所以妖胀，接下來(lái)我就從任務(wù)執(zhí)行芥颈、資源加載、數(shù)據(jù)結(jié)構(gòu)赚抡、線(xiàn)程/IO和頁(yè)面渲染這五個(gè)角度爬坑，來(lái)給出我的優(yōu)化建議。

2.1 任務(wù)執(zhí)行

• 1.業(yè)務(wù)/任務(wù)梳理：對(duì)業(yè)務(wù)進(jìn)行拆分涂臣，對(duì)任務(wù)進(jìn)行整合盾计。
• 2.任務(wù)轉(zhuǎn)換：串行 -> 并行, 同步 -> 異步。
• 3.執(zhí)行順序按優(yōu)先級(jí)調(diào)整赁遗。
• 4.延遲執(zhí)行署辉、空閑執(zhí)行，如:IdleHandler岩四。

2.1.1 業(yè)務(wù)/任務(wù)梳理

業(yè)務(wù)往往是由一個(gè)個(gè)任務(wù)流組合而成涨薪。合理的業(yè)務(wù)/任務(wù)粒度可以有效提高響應(yīng)的速度。

對(duì)業(yè)務(wù)和任務(wù)的梳理炫乓，正確的方式是先進(jìn)行業(yè)務(wù)的拆分刚夺，將業(yè)務(wù)拆分為一個(gè)個(gè)子任務(wù)，再根據(jù)需要對(duì)子任務(wù)進(jìn)行整合末捣。

（1）對(duì)不合理的業(yè)務(wù)流進(jìn)行拆分侠姑。

• 對(duì)業(yè)務(wù)進(jìn)行拆分，拆分出主要（必要）業(yè)務(wù)和次要（非必要）業(yè)務(wù)箩做。
• 分別對(duì)主要業(yè)務(wù)和次要業(yè)務(wù)進(jìn)行優(yōu)先級(jí)評(píng)估莽红，業(yè)務(wù)執(zhí)行按優(yōu)先級(jí)從高到底依次執(zhí)行。

（2）對(duì)任務(wù)流進(jìn)行整合邦邦。

• 多個(gè)相關(guān)的串行任務(wù)安吁，可以整合為統(tǒng)一的業(yè)務(wù)整體。
• 多個(gè)不相關(guān)的串行任務(wù)燃辖，可以整合為一個(gè)并行的業(yè)務(wù)鬼店。

2.1.2 任務(wù)轉(zhuǎn)換

1.串行 -> 并行的適用范圍：

• 多個(gè)不相關(guān)的串行任務(wù)。
• 多個(gè)任務(wù)弱相關(guān)且耗時(shí)黔龟，但是耗時(shí)接近妇智。例如某個(gè)頁(yè)面你需要調(diào)用多個(gè)模塊的接口查詢(xún)數(shù)據(jù)進(jìn)行展示滥玷。

2.同步 -> 異步的適用范圍：

• 非必要（重要性不高）且耗時(shí)的任務(wù)。
• 耗時(shí)且關(guān)聯(lián)性不大的任務(wù)巍棱。
• 耗時(shí)且存在一定相關(guān)性的任務(wù)惑畴。使用異步線(xiàn)程 + 同步鎖的方式執(zhí)行。

2.1.3 任務(wù)優(yōu)先級(jí)

類(lèi)似線(xiàn)程中的優(yōu)先級(jí)Priority航徙，當(dāng)系統(tǒng)資源緊張的時(shí)候如贷，優(yōu)先執(zhí)行優(yōu)先級(jí)高的線(xiàn)程。

首先我們要對(duì)應(yīng)用內(nèi)所有需要優(yōu)化的業(yè)務(wù)以及其子任務(wù)的優(yōu)先級(jí)進(jìn)行定義到踏，然后按優(yōu)先級(jí)順序進(jìn)行排列和執(zhí)行倒得。

那么如何才能保證任務(wù)被按優(yōu)先級(jí)進(jìn)行執(zhí)行呢？

1.對(duì)于線(xiàn)程夭禽，我們可以直接設(shè)置其Priority值。（但是一般我們不能直接使用線(xiàn)程谊路，所有這個(gè)可以忽略）
2.對(duì)于線(xiàn)程池讹躯，我們可以從代碼層將任務(wù)按優(yōu)先級(jí)順序加入到線(xiàn)程池中。注意缠劝，這里的線(xiàn)程池最好是阻塞式的潮梯，例如：使用PriorityBlockingQueue實(shí)現(xiàn)的優(yōu)先級(jí)線(xiàn)程池 PriorityThreadPoolExecutor 。
3.使用第三方的任務(wù)執(zhí)行框架惨恭，這里推薦我開(kāi)源的 XTask 供大家參考秉馏。

2.1.4 延遲執(zhí)行

延遲執(zhí)行，是將一些不必要脱羡、重要性不高或者高耗時(shí)的任務(wù)暫停執(zhí)行萝究，等后面資源充足或者要使用時(shí)才執(zhí)行。

常見(jiàn)的延遲執(zhí)行有以下幾種：

• 延遲某個(gè)特定的時(shí)間執(zhí)行锉罐。例如：某應(yīng)用啟動(dòng)后帆竹，每隔2分鐘同步一下用戶(hù)狀態(tài)。
• 待某個(gè)特定的任務(wù)執(zhí)行完成之后再執(zhí)行脓规。例如：導(dǎo)航應(yīng)用定位獲取成功后栽连，再執(zhí)行目的地推薦獲取的任務(wù)。
• 直接不執(zhí)行侨舆，等相關(guān)業(yè)務(wù)用到的時(shí)候再執(zhí)行秒紧。
• 空閑執(zhí)行，等待頁(yè)面都完全渲染完畢之后再執(zhí)行挨下。例如：使用IdleHandler熔恢，具體使用如下：

Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {
    @Override
    public boolean queueIdle() {
        // 執(zhí)行你的任務(wù)
        return false;
    }
});

當(dāng)然，如果你想在空閑的時(shí)候執(zhí)行多個(gè)任務(wù)臭笆，你也可以這樣寫(xiě)：

public class DelayTaskQueue {

  private final Queue<Runnable> mDelayTasks = new LinkedList<>();

  private final MessageQueue.IdleHandler mIdleHandler = () -> {
    if (mDelayTasks.size() > 0) {
      Runnable task = mDelayTasks.poll();
      if (task != null) {
        task.run();
      }
    }
    // mDelayTasks非空時(shí)返回ture表示下次繼續(xù)執(zhí)行绩聘，為空時(shí)返回false系統(tǒng)會(huì)移除該IdleHandler不再執(zhí)行
    return !mDelayTasks.isEmpty();
  };

  public DelayTaskQueue addTask(Runnable task) {
    mDelayTasks.add(task);
    return this;
  }

  public void start() {
    Looper.myQueue().addIdleHandler(mIdleHandler);
  }
}

2.2 資源加載

• 1.懶加載
• 2.分段加載（部分加載）
• 3.預(yù)加載（數(shù)據(jù)沥割、布局頁(yè)面等）

2.2.1 懶加載

對(duì)于一些不常用或者不重要的數(shù)據(jù)、圖片凿菩、控件以及其他一些資源机杜，我們可以在用到時(shí)再進(jìn)行加載。

1.數(shù)據(jù)懶加載

• kotlin中的lazy標(biāo)簽：修飾val變量衅谷，程序第一次使用到這個(gè)變量(或者對(duì)象)時(shí)再初始化椒拗。
• Map、List和SharedPreferences等大數(shù)據(jù)的延遲初始化获黔。

private Map getSystemSettings() {
    if (mSettingMap == null) {
        mSettingMap = initSystemSettings();
    }
    return mSettingMap;
}

2.圖片資源懶加載

• 對(duì)于不常用的圖片蚀苛，可以使用云端圖片的資源url來(lái)替代。
• 對(duì)于非程序預(yù)置的圖片（本地圖片文件或者云端圖片）玷氏，用到時(shí)再加載堵未。

3.控件懶加載

• 使用ViewStub進(jìn)行布局的延遲加載。
• 使用ViewPager2+Fragment進(jìn)行Fragment的懶加載盏触。
• 使用RecyclerView替代ListView渗蟹。

2.2.2 分段加載

分段加載常見(jiàn)應(yīng)用于大數(shù)據(jù)的加載，這里包括大圖和長(zhǎng)視頻等多媒體資源的加載赞辩。做到用到哪雌芽，加載到哪，完全不必要等全部加載完才給用戶(hù)使用辨嗽。

1.大圖的分段加載：對(duì)于大圖世落，我們可以將其按一定尺寸進(jìn)行切分，分割成一塊一塊的小瓦片糟需，然后設(shè)定一個(gè)預(yù)覽預(yù)加載范圍屉佳，用戶(hù)預(yù)覽到哪里我們就加載到哪里。（就類(lèi)似地圖的加載）

2.長(zhǎng)視頻的分段加載：對(duì)于長(zhǎng)視頻洲押，我們可以將其按時(shí)間片進(jìn)行拆分忘古，并設(shè)置一個(gè)加載緩存池。這樣用戶(hù)瀏覽一個(gè)長(zhǎng)視頻時(shí)诅诱，就可以快速打開(kāi)加載髓堪。

3.大文件或者長(zhǎng)WebView的分段加載：對(duì)于一些閱讀類(lèi)的app，經(jīng)常會(huì)遇到大文件和長(zhǎng)WebView的加載娘荡，這里我們也可以同理對(duì)其進(jìn)行拆分處理干旁。

2.2.3 預(yù)加載

分段加載常和預(yù)加載一起組合使用。對(duì)于一些加載非常耗時(shí)的內(nèi)容炮沐，我們可以將加載時(shí)機(jī)提前争群，從而減小用戶(hù)感知的加載時(shí)間。

預(yù)加載的本質(zhì)是提前加載大年，這樣這個(gè)提前加載的時(shí)機(jī)就非常的關(guān)鍵和重要换薄。因?yàn)轭A(yù)加載時(shí)機(jī)如果太晚玉雾，幾乎看不出效果；但是如果預(yù)加載的時(shí)機(jī)過(guò)早轻要，有可能搶占其他模塊資源复旬，造成資源緊張。

那么我們何時(shí)可以觸發(fā)預(yù)加載冲泥，預(yù)加載的時(shí)機(jī)是什么呢驹碍？下面我舉幾個(gè)簡(jiǎn)單的例子。

1.用戶(hù)操作時(shí)凡恍。如果用戶(hù)點(diǎn)擊了第2章志秃，我們就開(kāi)始預(yù)加載下一章和上一章；用戶(hù)上滑到了第3頁(yè)嚼酝，我們預(yù)加載第4頁(yè)浮还，用戶(hù)下滑到第5頁(yè)，我們預(yù)加載第4頁(yè).

2.應(yīng)用空閑時(shí)闽巩。例如之前說(shuō)的IdleHandler钧舌。或者在onUserInteraction中監(jiān)聽(tīng)用戶(hù)的操作又官，一段時(shí)間沒(méi)有操作即視為空閑。

3.耗時(shí)等待時(shí)漫试。對(duì)于一些常見(jiàn)的耗時(shí)操作六敬，我們可以在其開(kāi)始時(shí)，并行進(jìn)行一些預(yù)加載操作驾荣，從而提高時(shí)間的利用率外构。例如Activity的創(chuàng)建比較耗時(shí)，我們可以在startActivity前就開(kāi)始預(yù)加載數(shù)據(jù)播掷，這樣Activity創(chuàng)建完之后有可能數(shù)據(jù)就已經(jīng)加載好了审编，直接可以拿來(lái)渲染。例如一些有開(kāi)屏廣告的app歧匈，可以在廣告開(kāi)始時(shí)垒酬，同步進(jìn)行一些數(shù)據(jù)資源的預(yù)加載。

2.3 數(shù)據(jù)結(jié)構(gòu)

• 1.數(shù)據(jù)結(jié)構(gòu)優(yōu)化（空間大小件炉、讀取速度勘究、復(fù)用性、擴(kuò)展性）斟冕。
• 2.數(shù)據(jù)緩存（內(nèi)存緩存口糕、磁盤(pán)緩存、網(wǎng)絡(luò)緩存）磕蛇，分段緩存景描。這里可以參考glide.
• 3.鎖優(yōu)化（減少過(guò)度鎖十办，避免死鎖），悲觀鎖/樂(lè)觀鎖超棺。
• 4.內(nèi)存優(yōu)化向族，避免內(nèi)存抖動(dòng)，頻繁GC（尤其關(guān)注bitmap）

2.3.1 數(shù)據(jù)結(jié)構(gòu)優(yōu)化

不同的數(shù)據(jù)結(jié)構(gòu)有不同的使用場(chǎng)景说搅，選擇適合的數(shù)據(jù)結(jié)構(gòu)能夠事半功倍炸枣。

1.ArrayList和LinkedList：

• ArrayList：底層數(shù)據(jù)結(jié)構(gòu)是數(shù)組，查詢(xún)快弄唧、增刪慢适肠。
• LinkedList：底層數(shù)據(jù)結(jié)構(gòu)是鏈表，查詢(xún)慢候引、增刪快侯养。

2.HashMap和SparseArray：

• HashMap：底層數(shù)據(jù)結(jié)構(gòu)是數(shù)組和鏈表（或紅黑樹(shù)）的組合，結(jié)合了ArrayList和LinkedList的優(yōu)點(diǎn)澄干，查詢(xún)快逛揩、增刪也快。但是擴(kuò)容很耗性能麸俘，且空間利用率不高(75%)辩稽，浪費(fèi)內(nèi)存。
• SparseArray：底層數(shù)據(jù)結(jié)構(gòu)是雙數(shù)組从媚，一個(gè)數(shù)組存key逞泄，一個(gè)數(shù)組存value。使用二分法查詢(xún)進(jìn)行優(yōu)化拜效，在數(shù)據(jù)量信缰凇（一百條以下）的情況下，速度和HashMap相當(dāng)紧憾，但是空間利用率大大提升到千。
• ArrayMap：底層數(shù)據(jù)結(jié)構(gòu)是雙數(shù)組，一個(gè)數(shù)組存key的hash值赴穗，一個(gè)數(shù)組存value憔四。設(shè)計(jì)與SparseArray類(lèi)似，在數(shù)據(jù)量小的情況下般眉，可完全替代HashMap加矛。

3.Set: 保證每個(gè)元素都必須是唯一的。

4.TreeSet和TreeMap：有序的集合煤篙，保證存放的元素是排過(guò)序的斟览，速度慢于HashSet和HashMap。

可以看到辑奈，在不考慮空間利用率的情況下苛茂，HashMap的性能是不錯(cuò)的已烤。

但是由于存在初始化大小和擴(kuò)展因子對(duì)其性能有所影響，我們?cè)谑褂脮r(shí)妓羊，盡量根據(jù)實(shí)際需要設(shè)置合理的初始化大锌杈俊：避免設(shè)置小了擴(kuò)容帶來(lái)性能消耗，設(shè)置大了造成空間浪費(fèi)躁绸。

因?yàn)镠ashMap的默認(rèn)擴(kuò)容因子是0.75裕循，如果你實(shí)際使用的數(shù)量是8，那你初始化大小就設(shè)置16净刮；如果你實(shí)際使用的數(shù)量是60剥哑，那你初始化大小就設(shè)置128。

2.3.2 數(shù)據(jù)緩存

對(duì)于一些變化不是很頻繁的數(shù)據(jù)資源淹父，我們可以將其緩存下來(lái)株婴。這樣我們下次需要使用它們的時(shí)候，就可以直接讀取緩存暑认，這樣極大地減少了加載和渲染所需要的時(shí)間困介。

一般意義上的緩存，按讀取的時(shí)間由快到慢蘸际，我們可分為內(nèi)存緩存座哩、磁盤(pán)緩存、網(wǎng)絡(luò)緩存粮彤。

• 內(nèi)存緩存根穷，就是存儲(chǔ)在內(nèi)存中，我們可以直接讀取使用驾诈。而如果從界面渲染的角度缠诅，我們又可以將內(nèi)存緩存分為Active(活躍/正在顯示)緩存和InActive(非活躍/不可顯示)緩存溶浴。
• 磁盤(pán)緩存乍迄，就是存儲(chǔ)在磁盤(pán)文件中，每次讀取都需要將磁盤(pán)文件內(nèi)容讀取到內(nèi)存中士败，方可使用闯两。
• 網(wǎng)絡(luò)緩存，就是存儲(chǔ)在遠(yuǎn)端服務(wù)器中谅将，每次讀取需要我們進(jìn)行一次網(wǎng)絡(luò)請(qǐng)求漾狼。一般來(lái)說(shuō)，我們也可以將一次網(wǎng)絡(luò)緩存請(qǐng)求到的數(shù)據(jù)緩存到磁盤(pán)中饥臂，將網(wǎng)絡(luò)緩存轉(zhuǎn)化為磁盤(pán)緩存逊躁，通過(guò)減少網(wǎng)絡(luò)請(qǐng)求，來(lái)提升讀取速度隅熙。

某種意義上來(lái)說(shuō)稽煤，內(nèi)存緩存核芽、磁盤(pán)緩存和網(wǎng)絡(luò)緩存，它們又是可以相互轉(zhuǎn)化的酵熙，一般來(lái)說(shuō)轧简，我們會(huì)將網(wǎng)絡(luò)緩存->磁盤(pán)緩存->內(nèi)存緩存，進(jìn)行使用匾二，從而提升讀取速度哮独。

具體我們可以參考glide框架和RecyclerView的實(shí)現(xiàn)原理。

2.3.3 鎖優(yōu)化

鎖是我們解決并發(fā)的重要手段察藐，但是如果濫用鎖的話(huà)皮璧，很可能造成執(zhí)行效率下降，更嚴(yán)重的可能造成死鎖等無(wú)法挽回的場(chǎng)景转培。

當(dāng)我們需要處理高并發(fā)的場(chǎng)景時(shí)恶导，同步調(diào)用尤其需要考量鎖的性能損耗：

• 能用無(wú)鎖數(shù)據(jù)結(jié)構(gòu)，就不要用鎖浸须。
• 縮小鎖的范圍惨寿。能鎖區(qū)塊，就不要鎖住方法體;能用對(duì)象鎖删窒，就不要用類(lèi)鎖裂垦。

那么我們具體應(yīng)該怎么做呢？下面我簡(jiǎn)單講幾個(gè)例子肌索。

1.使用樂(lè)觀鎖代替悲觀鎖蕉拢，輕量級(jí)鎖代替重量級(jí)鎖。

利用CAS機(jī)制, 全稱(chēng)是Compare And Swap诚亚，即先比較晕换，然后再替換。就是每次執(zhí)行或者修改某個(gè)變量時(shí)站宗，我們都會(huì)將新舊值進(jìn)行比較闸准，如果發(fā)生偏移了就更新。這就好比在一些無(wú)鎖的數(shù)據(jù)庫(kù)中梢灭，每次的數(shù)據(jù)庫(kù)操作都會(huì)攜帶一個(gè)唯一的版本號(hào)夷家，每次進(jìn)行數(shù)據(jù)庫(kù)修改的時(shí)候都會(huì)對(duì)比一下數(shù)據(jù)庫(kù)記錄和操作請(qǐng)求的版本號(hào)，如果版本號(hào)是最新的版本號(hào)敏释，則進(jìn)行修改库快，否則丟棄。

需要注意的是钥顽，CAS必須借助volatile才能讀取到共享變量的最新值來(lái)實(shí)現(xiàn)【比較并交換】的效果义屏，因?yàn)?code>volatile會(huì)保證變量的可見(jiàn)性。

在Java中，JDK給我們默認(rèn)提供了一些CAS機(jī)制實(shí)現(xiàn)的原子類(lèi)闽铐，如AtomicInteger膀曾、AtomicReference等。

2.縮小同步范圍阳啥，避免直接使用synchronized添谊，即使使用也要盡量使用同步塊而不是同步方法。多使用JDK提供給我們的同步工具：CountDownLatch察迟，CyclicBarrier斩狱，ConcurrentHashMap。

3.針對(duì)不同使用場(chǎng)景扎瓶，使用不同類(lèi)型的鎖所踊。

• 針對(duì)并發(fā)讀多，寫(xiě)少的概荷，我們可以使用讀寫(xiě)鎖（多個(gè)讀鎖不互斥秕岛，讀鎖與寫(xiě)鎖互斥）：ReentrantReadWriteLock，CopyOnWriteArrayList误证，CopyOnWriteArraySet继薛。
• 針對(duì)某一個(gè)并發(fā)操作通常由某一特定線(xiàn)程執(zhí)行時(shí)，可嘗試使用偏向鎖（偏向于第一個(gè)獲得它的線(xiàn)程）愈捅。
• 針對(duì)存在大量并發(fā)資源競(jìng)爭(zhēng)的場(chǎng)景遏考，推薦使用重量級(jí)鎖synchronized。

2.3.4 內(nèi)存優(yōu)化

內(nèi)存優(yōu)化的核心是避免內(nèi)存抖動(dòng)蓝谨。不合理的內(nèi)存分配灌具、內(nèi)存泄漏、對(duì)象的頻繁創(chuàng)建和銷(xiāo)毀譬巫，都會(huì)導(dǎo)致內(nèi)存發(fā)生抖動(dòng)咖楣，最終導(dǎo)致系統(tǒng)的頻繁GC。

頻繁的GC芦昔，必定會(huì)導(dǎo)致系統(tǒng)運(yùn)行效率的下降诱贿，嚴(yán)重的可能會(huì)導(dǎo)致頁(yè)面卡頓，造成不好的用戶(hù)體驗(yàn)烟零。那么我們應(yīng)該著手從哪些地方進(jìn)行優(yōu)化呢瘪松？

• 解決應(yīng)用的內(nèi)存泄漏問(wèn)題咸作。這里我們可以使用LeakCanary 或者 Android Profile 等工具來(lái)檢查我們查詢(xún)可能存在的內(nèi)存泄漏锨阿。
• 平時(shí)編碼應(yīng)當(dāng)注意避免內(nèi)存泄漏。如避免全局靜態(tài)變量和常量记罚、單例持有資源對(duì)象（Activity墅诡，F(xiàn)ragment，View等），資源使用完立即釋放或者recycle（回收）等末早。
• 避免創(chuàng)建大內(nèi)存對(duì)象烟馅，頻繁創(chuàng)建和釋放對(duì)象（尤其是在循環(huán)體內(nèi)），頻繁創(chuàng)建的對(duì)象需要考慮復(fù)用或者使用緩存然磷。
• 加載圖片可以適當(dāng)降低圖片質(zhì)量郑趁，小圖標(biāo)盡量使用SVG，大圖/復(fù)雜的圖片考慮使用webp姿搜。盡量使用圖片加載框架寡润，如glide，這些框架都會(huì)幫我們進(jìn)行加載優(yōu)化舅柜。
• 避免大量bitmap的繪制梭纹。
• 避免在自定義View的onMeasure、onLayout和onDraw中創(chuàng)建對(duì)象致份。
• 使用SpareArray变抽、ArrayMap替代HashMap。
• 避免進(jìn)行大量的字符串操作氮块，特別是序列化和反序列化绍载。不要使用+(加號(hào))進(jìn)行字符串拼接。
• 使用線(xiàn)程池（可設(shè)置適當(dāng)?shù)淖畲缶€(xiàn)程池?cái)?shù)）執(zhí)行線(xiàn)程任務(wù)滔蝉，避免大量Thread的創(chuàng)建及泄漏逛钻。

2.4 線(xiàn)程/IO

• 1.線(xiàn)程優(yōu)化（統(tǒng)一、優(yōu)先級(jí)調(diào)度锰提、任務(wù)特性）
• 2.IO優(yōu)化（網(wǎng)絡(luò)IO和磁盤(pán)IO）曙痘，核心是減少I(mǎi)O次數(shù)
  • 網(wǎng)絡(luò)：請(qǐng)求合并，請(qǐng)求鏈路優(yōu)化立肘，請(qǐng)求體優(yōu)化边坤，系列化和反序列化優(yōu)化品洛，請(qǐng)求復(fù)用等椭赋。
  • 磁盤(pán)：文件隨機(jī)讀寫(xiě)、SharePreference讀寫(xiě)等（例如對(duì)于讀多寫(xiě)少的锐想，可使用內(nèi)存緩存）
• 3.log優(yōu)化（循環(huán)中的log打印融蹂，不必要的log打印旺订，log等級(jí)）

2.4.1 線(xiàn)程優(yōu)化

當(dāng)我們創(chuàng)建一個(gè)線(xiàn)程時(shí)，需要向系統(tǒng)申請(qǐng)資源超燃，分配內(nèi)存空間区拳，這是一筆不小的開(kāi)銷(xiāo)，所以我們平時(shí)開(kāi)發(fā)的過(guò)程中都不會(huì)直接操作線(xiàn)程意乓，而是選擇使用線(xiàn)程池來(lái)執(zhí)行任務(wù)樱调。所以線(xiàn)程優(yōu)化的本質(zhì)是對(duì)線(xiàn)程池的優(yōu)化。

線(xiàn)程池使用的最大問(wèn)題就在于如果線(xiàn)程池設(shè)置不對(duì)的話(huà)，很容易被人濫用笆凌，引發(fā)內(nèi)存溢出的問(wèn)題圣猎。而且通常一個(gè)應(yīng)用會(huì)有多個(gè)線(xiàn)程池，不同功能乞而、不同模塊乃至是不同三方庫(kù)都會(huì)有自己的線(xiàn)程池送悔，這樣大家各用各的，就很難做到資源的協(xié)調(diào)統(tǒng)一爪模，勁不往一處使放祟。

那么我們應(yīng)該如何進(jìn)行線(xiàn)程池優(yōu)化呢？

1.建立主線(xiàn)程池+副線(xiàn)程池的組合線(xiàn)程池呻右，由線(xiàn)程池管理者統(tǒng)一協(xié)調(diào)管理跪妥。主線(xiàn)程池負(fù)責(zé)優(yōu)先級(jí)較高的任務(wù)，副線(xiàn)程池負(fù)責(zé)優(yōu)先級(jí)不高以及被主線(xiàn)程池拒絕降級(jí)下來(lái)的任務(wù)声滥。

這里執(zhí)行的任務(wù)都需要設(shè)置優(yōu)先級(jí)眉撵，任務(wù)優(yōu)先級(jí)的調(diào)度通過(guò)PriorityBlockingQueue隊(duì)列實(shí)現(xiàn)，以下是主副線(xiàn)程池的設(shè)置落塑，僅供參考：

• 主線(xiàn)程池：核心線(xiàn)程數(shù)和最大線(xiàn)程數(shù)：2n（n為CPU核心數(shù)）纽疟，60s keepTime，PriorityBlockingQueue（128）憾赁。
• 副線(xiàn)程池：核心線(xiàn)程數(shù)和最大線(xiàn)程數(shù)：n（n為CPU核心數(shù)）污朽，60s keepTime，PriorityBlockingQueue（64）龙考。

2.使用Hook的方式蟆肆，收集應(yīng)用內(nèi)所以使用newThread方法的地方，改為由線(xiàn)程池管理者統(tǒng)一協(xié)調(diào)管理晦款。

3.將所有提供了設(shè)置線(xiàn)程池接口的第三方庫(kù)炎功，通過(guò)其開(kāi)放的接口，設(shè)置為線(xiàn)程池管理者管理缓溅。沒(méi)有提供設(shè)置接口的蛇损，考慮替換庫(kù)或者插樁的方式，替換線(xiàn)程池的使用坛怪。

2.4.2 IO優(yōu)化

IO優(yōu)化的核心是減少I(mǎi)O次數(shù)淤齐。

1.網(wǎng)絡(luò)請(qǐng)求優(yōu)化。

• 避免不必要的網(wǎng)絡(luò)請(qǐng)求袜匿。對(duì)于那些非必要執(zhí)行的網(wǎng)絡(luò)請(qǐng)求更啄，可以延時(shí)請(qǐng)求或者使用緩存。
• 對(duì)于需要進(jìn)行多次串行網(wǎng)絡(luò)請(qǐng)求的接口進(jìn)行優(yōu)化整合沉帮，控制好請(qǐng)求接口的粒度锈死。比如后臺(tái)有獲取用戶(hù)信息的接口、獲取用戶(hù)推薦信息的接口穆壕、獲取用戶(hù)賬戶(hù)信息的接口待牵。這三個(gè)接口都是必要的接口，且存在先后關(guān)系喇勋。如果依次進(jìn)行三次請(qǐng)求缨该，那么時(shí)間基本上都花在網(wǎng)絡(luò)傳輸上，尤其是在網(wǎng)絡(luò)不穩(wěn)定的情況下耗時(shí)尤為明顯川背。但如果將這三個(gè)接口整合為獲取用戶(hù)的啟動(dòng)（初始化）信息贰拿，這樣數(shù)據(jù)在網(wǎng)絡(luò)中傳輸?shù)臅r(shí)間就會(huì)大大節(jié)省，同時(shí)也能提高接口的穩(wěn)定性熄云。

2.磁盤(pán)IO優(yōu)化

• 避免不必要的磁盤(pán)IO操作膨更。這里的磁盤(pán)IO包括：文件讀寫(xiě)、數(shù)據(jù)庫(kù)（sqlite）讀寫(xiě)和SharePreference等缴允。
• 對(duì)于數(shù)據(jù)加載荚守，選擇合適的數(shù)據(jù)結(jié)構(gòu)×钒悖可以選擇支持隨機(jī)讀寫(xiě)矗漾、延時(shí)解析的數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)以替代SharePreference。
• 避免程序執(zhí)行出現(xiàn)大量的序列化和反序列化（會(huì)造成大量的對(duì)象創(chuàng)建）薄料。

2.5 頁(yè)面渲染

下面是我簡(jiǎn)單列舉的幾點(diǎn)加快頁(yè)面渲染的方法敞贡，相信大家或多或少都用過(guò)，這里我就不詳細(xì)闡述了：

• 1.降低布局層級(jí)摄职、減少嵌套誊役、避免過(guò)度渲染（背景）(merge，ConstraintLayout)
• 2.頁(yè)面復(fù)用(include)
• 3.頁(yè)面懶加載
• 4.布局延遲加載(ViewStub)
• 5.inflate優(yōu)化（布局預(yù)加載+異步加載谷市，動(dòng)態(tài)new控件/X2C）
• 6.動(dòng)畫(huà)優(yōu)化（注意動(dòng)畫(huà)的執(zhí)行耗時(shí)和內(nèi)存占用势木，不可見(jiàn)時(shí)暫停動(dòng)畫(huà)，可見(jiàn)時(shí)再恢復(fù)動(dòng)畫(huà)）
• 7.自定義view優(yōu)化（減少onDraw歌懒、onLayout啦桌、onMeasure的對(duì)象創(chuàng)建和執(zhí)行耗時(shí)）
• 8.bitmap和canvas優(yōu)化（bitmap大小、質(zhì)量及皂、壓縮甫男、復(fù)用；canvas復(fù)用：clipRect验烧，translate）
• 9.RecycleView優(yōu)化（減少刷新次數(shù)板驳，緩存復(fù)用）

3. 推薦工具

• systrace、Perfetto 碍拆、Android Profile
• DoKit
• LeakCanary
• performance

最后

還是那句話(huà)若治，百聞不如一見(jiàn)慨蓝，百見(jiàn)不如一試。寫(xiě)了這么多端幼，我還是希望大家在平時(shí)開(kāi)發(fā)的過(guò)程中礼烈，多重視一些應(yīng)用響應(yīng)時(shí)間優(yōu)化的相關(guān)技巧，讓我們開(kāi)發(fā)出流暢順滑的應(yīng)用吧婆跑。（盡管很多時(shí)候此熬，我們所謂的優(yōu)化會(huì)被產(chǎn)品或者設(shè)計(jì)diss）

我是xuexiangjys，一枚熱愛(ài)學(xué)習(xí)滑进，愛(ài)好編程犀忱，勤于思考，致力于Android架構(gòu)研究以及開(kāi)源項(xiàng)目經(jīng)驗(yàn)分享的技術(shù)up主扶关。獲取更多資訊阴汇，歡迎微信搜索公眾號(hào)：【我的Android開(kāi)源之旅】