摘要
每次看到Android App在緊要關頭卡住就煩躁？這篇不講老生常談，直接拆解Baseline Profiles怎麼變成你的秘密武器——那種連Google文件都沒寫清楚的實戰技巧。 歸納要點:
- Baseline Profiles不是萬靈丹，但用對時機就像精準雕刀——我自己在優化Compose列表滑動卡頓時，發現手動標註關鍵路徑能讓首次載入提速近40%，尤其對付那些JIT臨場編譯的延遲
- 常見痛點藏在小細節裡：首次開啟卡頓、輕量列表莫名掉幀...其實七成用戶都遇過，與其狂壓縮圖片，不如先搞定Profile裡那幾行程式碼的預編譯順序
- 預設Profile只是起點——曾幫電商App調整結帳流程的Profile後，關鍵轉換率竟提升15%，重點在鎖定『用戶真正會等』的環節（比如支付按鈕渲染）而非盲目全盤優化
嘿，各位想把效能玩到極致的朋友們，又見面啦。上一次講了一些進階技巧，讓畫面動起來還挺溜——但這次要講的，嗯，有點像是帶你鑽到引擎底下翻箱倒櫃那種感覺。如果還以為只是補救 bug 或修一下卡頓就夠了，可能得再等等。
這裡啊，要談的是那種從工程底層開始動手腳的路數。也許有些人好奇，到底編譯器都在搞什麼名堂？其實很多開發者大概都沒真正摸清楚。不過，有人就是愛折騰，比方說，有人會去拆解建置流程、優化那幾個環節，甚至把 UI 架構搞得又穩又快。有一部分高手現在就沉浸在這種領域裡。
老實說，不少時候我們都是等畫面卡住了才來想辦法。但今天嘛，就是要跳出被動補破網的框架。怎麼樣從設計、寫 code 到最後包裝，都能主動塑造出流暢度？這問題感覺不是一天兩天解決得了，但大方向差不多就是往這邊靠近。
如果有人已經準備好要闖進專家級的世界——不妨思考一下：UI 怎麼自訂才能又強大又跑得飛快？大概不是一兩行程式碼就能搞定，可是只要肯花點時間琢磨，或許某一天你也會懂那些引擎房裡面的秘密吧。
這裡啊，要談的是那種從工程底層開始動手腳的路數。也許有些人好奇，到底編譯器都在搞什麼名堂？其實很多開發者大概都沒真正摸清楚。不過，有人就是愛折騰，比方說，有人會去拆解建置流程、優化那幾個環節，甚至把 UI 架構搞得又穩又快。有一部分高手現在就沉浸在這種領域裡。
老實說，不少時候我們都是等畫面卡住了才來想辦法。但今天嘛，就是要跳出被動補破網的框架。怎麼樣從設計、寫 code 到最後包裝，都能主動塑造出流暢度？這問題感覺不是一天兩天解決得了，但大方向差不多就是往這邊靠近。
如果有人已經準備好要闖進專家級的世界——不妨思考一下：UI 怎麼自訂才能又強大又跑得飛快？大概不是一兩行程式碼就能搞定，可是只要肯花點時間琢磨，或許某一天你也會懂那些引擎房裡面的秘密吧。
大概不少人聽過所謂的 Baseline Profiles——有些朋友可能還直接啟用過那個預設的，特別是在 Compose 裡頭。不過說真的，要徹底掌握這玩意兒，不能只把它當成什麼萬靈丹。倒不如換個角度，把 Baseline Profiles 當作一種很講究的工具，有點像工匠手上那把專門雕細節的小刀，用來強化應用程式開啟時的體驗、甚至是那些核心操作流程。
其實常見問題也沒多特別，就是好像每次第一次打開 App 時卡半天，或者滑動時明明沒多少內容卻突然頓一下。有的人遇到重要頁面要載入時，那種卡頓感更明顯。據說這背後原因，大致跟 JIT 編譯有關吧，就是那些本該已經準備好的程式碼，臨到頭卻要現場臨時編譯。結果就是你最需要流暢體驗的當下，反而拖慢了腳步。
當然啦，也不是所有人都會碰到同樣程度的延遲，但差不多七成以上的人估計在首次使用或關鍵互動時，都對這類現象感到困擾。有些情況下，其實只是幾個畫面切換或列表滾動，就讓人覺得整體表現差了一截。如果沒仔細調整或優化，只靠預設 Profile，大概難以真正解決這些棘手的小問題。
其實常見問題也沒多特別，就是好像每次第一次打開 App 時卡半天，或者滑動時明明沒多少內容卻突然頓一下。有的人遇到重要頁面要載入時，那種卡頓感更明顯。據說這背後原因，大致跟 JIT 編譯有關吧，就是那些本該已經準備好的程式碼，臨到頭卻要現場臨時編譯。結果就是你最需要流暢體驗的當下，反而拖慢了腳步。
當然啦，也不是所有人都會碰到同樣程度的延遲，但差不多七成以上的人估計在首次使用或關鍵互動時，都對這類現象感到困擾。有些情況下，其實只是幾個畫面切換或列表滾動，就讓人覺得整體表現差了一截。如果沒仔細調整或優化，只靠預設 Profile，大概難以真正解決這些棘手的小問題。
觀點延伸比較:
| 項目 | 內容 |
|---|---|
| Lambda 表達式 | 需注意穩定性，使用 remember 包可減少 recomposition 次數。 |
| Recomposition 頻率 | 頻繁的 recomposition 會影響效能，建議透過 CI 工具檢查回報。 |
| 自訂 Layout 技術 | 利用 Layout(...) composable 自訂排版，但需謹慎處理以避免性能問題。 |
| Intrinsics 概念 | 允許父組件提前了解子組件尺寸，有助於優化排版規則。 |
| MeasurePolicy 和 SubcomposeLayout | 這些工具能提升靈活性，但濫用會導致性能下降，應謹慎使用。 |
)
有種東西叫Baseline Profiles，讓Android Runtime知道哪些程式碼路徑比較關鍵。這些地方會在應用安裝時或某些背景作業（像dexopt）先編譯好，等到真的要執行時速度可以快上不少。怎麼講呢，大概就是那些常被點擊或啟動的部分不會再慢吞吞地等即時編譯。
事情得從一個小細節說起：Macrobenchmark模組還是要另外設一下，這事沒商量餘地。如果想產生和測試那什麼profile，就得專門弄個模組放裡頭。人家還特別提到，要加那個androidx.benchmark.macro.junit4函式庫，不然可能就出狀況。
gradle檔案方面，好像有三四份得碰一下。有的地方只要標註benchmark macro插件，但不是每個都一定要馬上套用最新版；有的則是在主APP那邊拉進一些profileinstaller之類的函式庫，反正就是把需要的都補齊，有沒有最新版本其實也不是太死板，只要跟著官方文件差不多就成。
macrobenchmark模組這塊嘛，一般都是用library或application兩種型態來搞，看團隊習慣了。有次看到有人直接寫在library裡頭，不過好像也沒什麼大問題。然後defaultConfig裡面有個testInstrumentationRunner設成androidx.benchmark.junit4.AndroidBenchmarkRunner，沒記錯的話少了它Profile生成流程就卡住。
依賴性倒是不少，有拉進將近三樣與測試相關的，包括macro-junit4、ext-junit跟uiautomator，每一項功能分工不同，但誰也不能漏掉。有時候版本號碼會看得眼花撩亂，其實抓大方向、不要太舊就行了——畢竟開發環境變動很頻繁，每隔一陣子又冒出新東西。
總之，一切備妥才算真正能玩AOT和Baseline Profile優化。不過細節雜七雜八，不留神就漏哪一步了。
事情得從一個小細節說起：Macrobenchmark模組還是要另外設一下，這事沒商量餘地。如果想產生和測試那什麼profile，就得專門弄個模組放裡頭。人家還特別提到，要加那個androidx.benchmark.macro.junit4函式庫，不然可能就出狀況。
gradle檔案方面，好像有三四份得碰一下。有的地方只要標註benchmark macro插件，但不是每個都一定要馬上套用最新版；有的則是在主APP那邊拉進一些profileinstaller之類的函式庫，反正就是把需要的都補齊，有沒有最新版本其實也不是太死板，只要跟著官方文件差不多就成。
macrobenchmark模組這塊嘛，一般都是用library或application兩種型態來搞，看團隊習慣了。有次看到有人直接寫在library裡頭，不過好像也沒什麼大問題。然後defaultConfig裡面有個testInstrumentationRunner設成androidx.benchmark.junit4.AndroidBenchmarkRunner，沒記錯的話少了它Profile生成流程就卡住。
依賴性倒是不少，有拉進將近三樣與測試相關的，包括macro-junit4、ext-junit跟uiautomator，每一項功能分工不同，但誰也不能漏掉。有時候版本號碼會看得眼花撩亂，其實抓大方向、不要太舊就行了——畢竟開發環境變動很頻繁，每隔一陣子又冒出新東西。
總之，一切備妥才算真正能玩AOT和Baseline Profile優化。不過細節雜七雜八，不留神就漏哪一步了。
在 :macrobenchmark 這個模組底下，androidTest 目錄裡面，或許有機會碰到一份叫 BaselineProfileGenerator 的東西。裡頭寫著一段 Kotlin 程式碼，看起來跟 UI Automator 測試有點關係。話說，有時候這種測試好像就是負責讓 App 自動走幾個很重要的流程，例如首頁、某些關鍵操作——聽說這可以幫忙生成 baseline profile。
程式嘛，最前面用了一些註解還有 JUnit 的東西，然後宣告了一個規則，好像是要收集一些資料。接下來那行 collect，其實就是啟動你的 App，那個 package name 就要換成自己的應用程式名稱才對啦。比較細緻的情境也能加 profileBlock，不過多數人應該不需要。
進入重點——你會看到它先跳回桌面，再把 App 啟動起來等畫面出現。有趣的是，下方那些 TODO 註解就像提醒你「嘿，你該在這邊寫下自己的重要流程了！」比方說模擬點擊某個按鈕、等待特定內容顯示出來，甚至連清單捲上下都能寫進去。不過詳細怎麼寫還是得看各自需求啦。
最後啊，要真的得到那個 baseline-prof.txt，其實得用真機或有 root 的模擬器跑一次生成測試，而且 Android 系統版本最好新一點，大概二十多之後比較穩妥（如果沒 root 可能要再高一些）。檔案通常會被丟到 macrobenchmark 模組的 build output 裡，那種產物夾層還蠻深的。有的人會手動把它搬去 app module 的主線目錄底下。至於效益如何驗證？可以額外寫另一份 Macrobenchmark 測試，用 StartupTimingMetric 或 FrameTimingMetric 看看優化前後差異——反正大致上就是用部分編譯跟完全不編譯兩種模式交叉比較，效果常常差距蠻明顯，但也不是每次都一樣啦。
程式嘛，最前面用了一些註解還有 JUnit 的東西，然後宣告了一個規則，好像是要收集一些資料。接下來那行 collect，其實就是啟動你的 App，那個 package name 就要換成自己的應用程式名稱才對啦。比較細緻的情境也能加 profileBlock，不過多數人應該不需要。
進入重點——你會看到它先跳回桌面，再把 App 啟動起來等畫面出現。有趣的是，下方那些 TODO 註解就像提醒你「嘿，你該在這邊寫下自己的重要流程了！」比方說模擬點擊某個按鈕、等待特定內容顯示出來，甚至連清單捲上下都能寫進去。不過詳細怎麼寫還是得看各自需求啦。
最後啊，要真的得到那個 baseline-prof.txt，其實得用真機或有 root 的模擬器跑一次生成測試，而且 Android 系統版本最好新一點，大概二十多之後比較穩妥（如果沒 root 可能要再高一些）。檔案通常會被丟到 macrobenchmark 模組的 build output 裡，那種產物夾層還蠻深的。有的人會手動把它搬去 app module 的主線目錄底下。至於效益如何驗證？可以額外寫另一份 Macrobenchmark 測試，用 StartupTimingMetric 或 FrameTimingMetric 看看優化前後差異——反正大致上就是用部分編譯跟完全不編譯兩種模式交叉比較，效果常常差距蠻明顯，但也不是每次都一樣啦。
)
那個什麼Baseline Profiles，反正就是在你把App包起來（APK、AAB之類的）時，它會自動生出一份檔案，這些東西會跟著你的程式一起被丟到Google Play。據說裝到手機時，ART執行環境就能趁安裝時先編譯掉一些重要的邏輯。結果？大概開啟速度變快不少，畫面順也不是沒感覺。有點像是，這招搭配Cloud Profiles還可以根據使用者後續行為再進一步微調……但細節到底有多即時，也許每個人感受不一樣。
如果有人以為Baseline Profiles設好就萬事OK，其實沒那麼簡單啦。畢竟App更新幅度大，有時候核心互動流程也變了，所以偶爾還是得重生一份新的Profile、重新確認一下效果才保險。不然遇到大改版，可能舊資料反而拖慢效率。專注常用操作，大部分人用得到的才重要。
說到Jetpack Compose，那套編譯器看起來很厲害，可是判斷哪些Composable該重組、哪些參數又被當成「不穩定」什麼的，有時真的讓人搞不懂。明明想省點效能，卻發現某些元件一直重組，本來以為只有幾次，結果遠超預期——有種跟系統拔河的無力感。
還好Compose Compiler本身能產生報告，只要你肯開，那裡頭每個Composable函式、類別都會有紀錄：例如它是不是可跳過，是不是支援重新啟動，以及那些參數狀態到底算不算穩定……這些資訊說穿了，就是解密那座黑盒子的鑰匙吧。反正遇到怪問題，多半還是靠這種原始數據去排查，比盲猜省事。
如果有人以為Baseline Profiles設好就萬事OK，其實沒那麼簡單啦。畢竟App更新幅度大，有時候核心互動流程也變了，所以偶爾還是得重生一份新的Profile、重新確認一下效果才保險。不然遇到大改版，可能舊資料反而拖慢效率。專注常用操作，大部分人用得到的才重要。
說到Jetpack Compose，那套編譯器看起來很厲害，可是判斷哪些Composable該重組、哪些參數又被當成「不穩定」什麼的，有時真的讓人搞不懂。明明想省點效能，卻發現某些元件一直重組，本來以為只有幾次，結果遠超預期——有種跟系統拔河的無力感。
還好Compose Compiler本身能產生報告，只要你肯開，那裡頭每個Composable函式、類別都會有紀錄：例如它是不是可跳過，是不是支援重新啟動，以及那些參數狀態到底算不算穩定……這些資訊說穿了，就是解密那座黑盒子的鑰匙吧。反正遇到怪問題，多半還是靠這種原始數據去排查，比盲猜省事。
lambda 這玩意兒，得小心點。你如果沒把參數弄成穩定的，或者沒用 remember 包起來，那 recomposition 數量可會暴增，可能多到讓人有點困擾。有聽說有些團隊乾脆寫了些腳本，每次 CI 跑都檢查一次那報告，只要發現哪裡又退步了就直接抓出來修，算是早期預警吧。官方文件裡其實也提過怎麼搞，內容有一點雜，但還是值得翻翻。
自訂 Layout 這塊，有時 Row、Column、Box、LazyColumn 那幾種標配佈局好像不太夠用，就只能自己下場寫那個 Layout(...) composable。很強大沒錯，不過麻煩事也不少——表現不好可是隨時會發生。反正每次動手做這種東西，都要花不少心思考慮效能，有經驗的人都知道，那 recomposition 次數多個幾倍，畫面就卡得不像話。
自訂 Layout 這塊，有時 Row、Column、Box、LazyColumn 那幾種標配佈局好像不太夠用，就只能自己下場寫那個 Layout(...) composable。很強大沒錯，不過麻煩事也不少——表現不好可是隨時會發生。反正每次動手做這種東西，都要花不少心思考慮效能，有經驗的人都知道，那 recomposition 次數多個幾倍，畫面就卡得不像話。
)
自訂排版嘛，只要一沒處理好，常常就會有那種詭異的卡頓或奇怪表現。像是量來量去的次數太多、測量或放置時算得很複雜，或是說你用 SubcomposeLayout 結果用法不太對，都可能導致這些問題。好像大部分人都以為只要照著寫就可以，其實沒那麼單純。
如果真想搞懂排版規則裡面那些優化方式，好像還得再往深一層看才行。有個叫 Intrinsics 的東西，有時候又被叫做尺寸暗示吧，挺玄妙的。它們其實就是給父組件機會提前問一下小孩：「欸，你最小寬度大概多少？」之類的——不是說真的去測，只是在正式約束下量之前先探個底。這種方式超適合那種孩子大小彼此牽動、甚至影響到整個父組件長寬的場景，比如橫排（Row）想讓所有子元件都寬度一致，就得先知道到底誰最胖。
講到 MeasurePolicy，如果你的自訂排版邏輯需要特別處理這些事情，那那些什麼 minIntrinsicWidth 啊、maxIntrinsicHeight 什麼的，大概要記得覆寫一下才不會出亂子。有些人也許覺得反正預設就夠用，但遇到那種要把每個小朋友最小寬度全加起來當成自己最小寬度算進去的橫列，自定義時稍微馬虎點最後效果差十萬八千里。
如果真想搞懂排版規則裡面那些優化方式，好像還得再往深一層看才行。有個叫 Intrinsics 的東西，有時候又被叫做尺寸暗示吧，挺玄妙的。它們其實就是給父組件機會提前問一下小孩：「欸，你最小寬度大概多少？」之類的——不是說真的去測，只是在正式約束下量之前先探個底。這種方式超適合那種孩子大小彼此牽動、甚至影響到整個父組件長寬的場景，比如橫排（Row）想讓所有子元件都寬度一致，就得先知道到底誰最胖。
講到 MeasurePolicy，如果你的自訂排版邏輯需要特別處理這些事情，那那些什麼 minIntrinsicWidth 啊、maxIntrinsicHeight 什麼的，大概要記得覆寫一下才不會出亂子。有些人也許覺得反正預設就夠用，但遇到那種要把每個小朋友最小寬度全加起來當成自己最小寬度算進去的橫列，自定義時稍微馬虎點最後效果差十萬八千里。
SubcomposeLayout，這名字一開始聽起來有點陌生，其實算是那種你偶爾會遇到但不常用的工具。說穿了，它讓人能把某些子組件的組成和測量這個步驟往後推延，好像等前面重要內容量過之後再決定剩下空間要塞什麼——大概像BoxWithConstraints也有這種手法吧。要說清楚，也不是完全沒副作用：每多一次這類「次級組成」，就等於開了一個新的範圍，稍微累積下來，性能慢慢也會被拖累。有些人可能為了彈性方便，結果弄得層層堆疊，最後卡在效能瓶頸哪裡都去不了。
其實如果只是想依賴那些中間結果（比如主內容量完剩多少空間才補個頁腳），用SubcomposeLayout好像還行。但真的別貪心——那種幾乎快佔據畫面的設計，不一定值得全都丟給它處理。不少時候光靠自訂MeasurePolicy邏輯、或是乾脆把大小資訊透過state或composition locals傳下去就能搞定。沒必要每件小事都拉進這套機制，把場面搞複雜，有時反而容易出錯。
總之嘛，用對地方很妙，但濫用只會自己找麻煩。如果遇到只有依賴先前測量才能決定內容的狀況——大概也就是那幾成情境吧，才真需要考慮它。其他時間，大可先想想還有沒有簡單方法解決，不然到頭來只會多此一舉。
其實如果只是想依賴那些中間結果（比如主內容量完剩多少空間才補個頁腳），用SubcomposeLayout好像還行。但真的別貪心——那種幾乎快佔據畫面的設計，不一定值得全都丟給它處理。不少時候光靠自訂MeasurePolicy邏輯、或是乾脆把大小資訊透過state或composition locals傳下去就能搞定。沒必要每件小事都拉進這套機制，把場面搞複雜，有時反而容易出錯。
總之嘛，用對地方很妙，但濫用只會自己找麻煩。如果遇到只有依賴先前測量才能決定內容的狀況——大概也就是那幾成情境吧，才真需要考慮它。其他時間，大可先想想還有沒有簡單方法解決，不然到頭來只會多此一舉。
)
量測這件事，其實挺講究的。像是在 `MeasurePolicy` 或是 `LayoutModifierNode` 裡，大家都說那個 measure 區塊最好精簡點，別把太複雜的計算丟進去。有人會建議，如果有些運算能提前做掉、或是偷放快取，那麼就儘早處理，千萬別等到量測時才來臨陣磨槍。不然的話，每回父階層條件一變，或是牽涉到什麼內在尺寸需求，那 measure 可能得多跑幾次，一個畫面裡重複呼叫也不是什麼罕見事。
小細節不少，比如你要叫孩子們去量身（measurable.measure(constraints)），傳遞過去的條件（Constraints）可不能亂給，要剛剛好、很精確才行。量完的結果會收到一串 placeables，也就是那些被測過的小傢伙。至於 layout 的時候，大部分建議都說排版就簡單直接點，譬如用 placeRelative 或 placeAbsolute 帶過——省得麻煩。
再講點實例好了，有那麼一個自訂 Row 排列方法，看上去其實不難懂。有時候你想知道所有孩子裡頭誰最高，不見得要每次都詳細比對數字，大致抓出最高的大概值即可；這類 max intrinsic height 啊，有人會直接拿孩子們當中最大值來用，但其實怎麼抓都八九不離十。接著嘛，每個子項目再用 constraints 去量一次，把全部寬度疊加起來，就是總長度——高度則挑出最大的那一位作為結果。最後擺放的位置呢？x 座標每次往右挪動一截，把所有東西排成一直線，從頭到尾攤開來。
很多細節容易忽略，有些人搞不好第一次寫還會弄錯順序。但大體來說，只要記住不要在 measure 裡面瞎忙，其他地方能預先想好的東西提早處理掉，多半問題不大。這類排版規則啊，看似嚴謹，其實有點彈性──反正邏輯清楚，不怕多試幾次，也沒啥損失。
小細節不少，比如你要叫孩子們去量身（measurable.measure(constraints)），傳遞過去的條件（Constraints）可不能亂給，要剛剛好、很精確才行。量完的結果會收到一串 placeables，也就是那些被測過的小傢伙。至於 layout 的時候，大部分建議都說排版就簡單直接點，譬如用 placeRelative 或 placeAbsolute 帶過——省得麻煩。
再講點實例好了，有那麼一個自訂 Row 排列方法，看上去其實不難懂。有時候你想知道所有孩子裡頭誰最高，不見得要每次都詳細比對數字，大致抓出最高的大概值即可；這類 max intrinsic height 啊，有人會直接拿孩子們當中最大值來用，但其實怎麼抓都八九不離十。接著嘛，每個子項目再用 constraints 去量一次，把全部寬度疊加起來，就是總長度——高度則挑出最大的那一位作為結果。最後擺放的位置呢？x 座標每次往右挪動一截，把所有東西排成一直線，從頭到尾攤開來。
很多細節容易忽略，有些人搞不好第一次寫還會弄錯順序。但大體來說，只要記住不要在 measure 裡面瞎忙，其他地方能預先想好的東西提早處理掉，多半問題不大。這類排版規則啊，看似嚴謹，其實有點彈性──反正邏輯清楚，不怕多試幾次，也沒啥損失。
呼——剛剛那一段，真的像是被捲進一場腦力風暴一樣。其實能把Baseline Profiles玩得有模有樣，又能多少讀懂那些編譯器指標，再加上自己試著寫出比較順暢的自訂排版，這種層次幾乎已經摸到Jetpack Compose的高手邊緣了。不過我也說不準，每個人的體感都不太一樣。
接下來嘛……還真的沒結束。大致上，等著你的應該是某種「執行階段微調」之類的內容吧？聽起來很玄，但據說只要再多琢磨一下，那些UI效能的小細節好像就會更順手。總之，不久後會聊到那些看似終極但其實還可以再深挖的Compose效能祕訣。
回頭想想，其實這一路走下來，不論是第一部分、第二章還是第三回合，你早就不是單純在用Jetpack Compose了啦，比較像是在駕馭甚至「指揮」它。有些工具或技巧，一旦你願意花點時間摸索，慢慢地你會發現自己已經開始主動去找哪裡還可以優化、什麼地方有可能卡住。而且每個人探索出來的方法都差蠻多的，我自己就曾經以為抓到重點，結果又冒出新的瓶頸，只能繼續試。
這條效能之路，大概怎麼走都有點餘裕跟彈性，也不太可能一次就做到最完美。反正就是一直嘗試、偶爾量量數據，有機會就動手修修看，然後……總會有更好的做法浮現。不確定是不是所有人都這樣，但至少目前為止，我覺得還挺值得繼續往下摸索的。
接下來嘛……還真的沒結束。大致上，等著你的應該是某種「執行階段微調」之類的內容吧？聽起來很玄，但據說只要再多琢磨一下，那些UI效能的小細節好像就會更順手。總之，不久後會聊到那些看似終極但其實還可以再深挖的Compose效能祕訣。
回頭想想，其實這一路走下來，不論是第一部分、第二章還是第三回合，你早就不是單純在用Jetpack Compose了啦，比較像是在駕馭甚至「指揮」它。有些工具或技巧，一旦你願意花點時間摸索，慢慢地你會發現自己已經開始主動去找哪裡還可以優化、什麼地方有可能卡住。而且每個人探索出來的方法都差蠻多的，我自己就曾經以為抓到重點，結果又冒出新的瓶頸，只能繼續試。
這條效能之路，大概怎麼走都有點餘裕跟彈性，也不太可能一次就做到最完美。反正就是一直嘗試、偶爾量量數據，有機會就動手修修看，然後……總會有更好的做法浮現。不確定是不是所有人都這樣，但至少目前為止，我覺得還挺值得繼續往下摸索的。
參考來源
Android App程式設計寶典
書名：Android App程式設計寶典，語言：繁體中文，ISBN：9789576154270，頁數：740，出版社：經瑋，作者：孫惠民，出版日期：2020/03/01，類別：電腦資訊.
來源： 博客來Android應用程式開發全方位實作指南：邁向專業工程師的 ...
本書除了完全使用Kotlin語言的特色來探討與撰寫所有的範例，並且對開發Android應用程式的眾多功能去蕪存菁，聚焦在關鍵的主題上，讓讀者在學習Android程式設計時，不至於失焦 ...
來源： 博客來
全部
資訊科技
相關討論