一、前言：

用android的都知道版扩，新買的手機(jī)用過一段時(shí)間后废离，手機(jī)變得越來越卡了；裝了一些APP后礁芦，電量用得飛快蜻韭，一天基本要一充；有些APP打開半天加載不出來柿扣；有些APP進(jìn)入某些頁面突然閃退肖方；還有用了一些APP,流量用得飛快，幾百M(fèi)的流量用了幾天就沒有了等等未状；

1. 這是什么原因呢俯画？

• android系統(tǒng)源碼是開放的，可以對(duì)源碼的更改司草，像國內(nèi)的幾大手機(jī)廠商艰垂，都是對(duì)系統(tǒng)進(jìn)入定制開發(fā)，這樣就會(huì)引發(fā)一系列問題埋虹，比如說著名的系統(tǒng)碎片化問題;
• 各大廠商定制的系統(tǒng)猜憎，兼容性肯定不好，開發(fā)人員要對(duì)各個(gè)系統(tǒng)做各種適配吨岭，還有開發(fā)人員的水平參次不齊拉宗，開發(fā)出來的APP就會(huì)出現(xiàn)這樣那樣的問題等等；

2. 那我們又得如何處理這樣的問題呢辣辫？

那就是今天我們要說的APP性能優(yōu)化旦事，開發(fā)人員開發(fā)出來的app要性能好，用戶體驗(yàn)好急灭，性能好的APP總結(jié)一下姐浮，有如下幾點(diǎn)：

• 流暢 （APP不卡頓）；
• 耗損低 （省電葬馋、省流量）卖鲤；
• 安裝包（APP包盡量要小)肾扰；
• 穩(wěn)定（不閃退、內(nèi)存溢出蛋逾、ANR)集晚；

二、流暢-卡頓優(yōu)化

1. Android 應(yīng)用啟動(dòng)慢区匣，使用時(shí)經(jīng)惩蛋危卡頓，是非常影響用戶體驗(yàn)的亏钩，應(yīng)該盡量避免出現(xiàn)莲绰。總的來說造成卡頓的原因有如下幾種：

• UI的繪制姑丑。主要原因是繪制的層級(jí)深蛤签、頁面復(fù)雜、刷新不合理栅哀，由于這些原因?qū)е驴D的場景更多出現(xiàn)在 UI 和啟動(dòng)后的初始界面以及跳轉(zhuǎn)到頁面的繪制上震肮。
• 數(shù)據(jù)處理上。導(dǎo)致這種卡頓場景的原因是數(shù)據(jù)處理量太大昌屉，一般分為三種情況钙蒙，一是數(shù)據(jù)在主線程處理，這個(gè)是初級(jí)工程師會(huì)犯的錯(cuò)誤间驮，二是數(shù)據(jù)處理占用 CPU 高，導(dǎo)致主線程拿不到時(shí)間片马昨，三是內(nèi)存增加導(dǎo)致 GC 頻繁竞帽，從而引起卡頓。引起卡頓的原因很多鸿捧，但不管怎么樣的原因和場景屹篓，最終都是通過設(shè)備屏幕上顯示來達(dá)到用戶，歸根到底就是顯示有問題匙奴，所以堆巧，要解決卡頓，就要先了解 Android 系統(tǒng)的渲染機(jī)制泼菌。
• UI的過度繪制,繪制的頁面有幾層View谍肤，底層View都是隱藏的，這種的還繪制的話就會(huì)造成過度繪制

2. andriod的渲染機(jī)制

要在屏幕上顯示哗伯，其實(shí)要經(jīng)過一系列的過程荒揣，Android 應(yīng)用程序把經(jīng)過測量、布局焊刹、繪制后的 surface 緩存數(shù)據(jù)系任，通過 SurfaceFlinger 把數(shù)據(jù)渲染到顯示屏幕上恳蹲， 通過 Android 的刷新機(jī)制來刷新數(shù)據(jù)。也就是說應(yīng)用層負(fù)責(zé)繪制俩滥，系統(tǒng)層負(fù)責(zé)渲染嘉蕾，通過進(jìn)程間通信把應(yīng)用層需要繪制的數(shù)據(jù)傳遞到系統(tǒng)層服務(wù)，系統(tǒng)層服務(wù)通過刷新機(jī)制把數(shù)據(jù)更新到屏幕上霜旧。

這里我們先介紹一個(gè)名詞：FPS错忱。FPS 表示每秒傳遞的幀數(shù)。在理想情況下颁糟，60 FPS 就感覺不到卡航背，這意味著每個(gè)繪制時(shí)長應(yīng)該在16 ms 以內(nèi)。但是 Android 系統(tǒng)很有可能無法及時(shí)完成那些復(fù)雜的頁面渲染操作棱貌。Android 系統(tǒng)每隔 16ms 發(fā)出 VSYNC 信號(hào)玖媚，觸發(fā)對(duì) UI 進(jìn)行渲染，如果每次渲染都成功婚脱，這樣就能夠達(dá)到流暢的畫面所需的 60FPS今魔。如果某個(gè)操作花費(fèi)的時(shí)間是 24ms ，系統(tǒng)在得到 VSYNC 信號(hào)時(shí)就無法正常進(jìn)行正常渲染障贸，這樣就發(fā)生了丟幀現(xiàn)象错森。那么用戶在 32ms 內(nèi)看到的會(huì)是同一幀畫面，這種現(xiàn)象在執(zhí)行動(dòng)畫或滑動(dòng)列表比較常見篮洁，還有可能是你的 Layout 太過復(fù)雜涩维，層疊太多的繪制單元，無法在 16ms 完成渲染袁波，最終引起刷新不及時(shí)瓦阐。

android的View的繪制流程大家應(yīng)該都知道，都是要經(jīng)過三大核心步驟：Measure篷牌、Layout睡蟋、Draw。具體是如何實(shí)現(xiàn)的建議看一下View的源碼枷颊，這里我就不多說了戳杀；如果繪制的層級(jí)深，頁面復(fù)雜夭苗，在Measure信卡、Layout這二個(gè)步驟要花費(fèi)大量的時(shí)間；這樣也會(huì)造卡頓現(xiàn)象听诸；

3. andriod卡頓優(yōu)化方案

• 不要在主線程進(jìn)行網(wǎng)絡(luò)訪問/大文件的IO操作
• 繪制UI時(shí)坐求，盡量減少繪制UI層次；減少不必要的view嵌套晌梨，可以用Hierarchy Viewer工具來檢測桥嗤，后面會(huì)詳細(xì)講须妻；
• 當(dāng)我們的布局是用的FrameLayout的時(shí)候，我們可以把它改成merge,可以避免自己的幀布局和系統(tǒng)的ContentFrameLayout幀布局重疊造成重復(fù)計(jì)算(measure和layout)
• 提高顯示速度,使用ViewStub：當(dāng)加載的時(shí)候才會(huì)占用泛领。不加載的時(shí)候就是隱藏的荒吏，僅僅占用位置。
• 在view層級(jí)相同的情況下渊鞋，盡量使用 LinerLayout而不是RelativeLayout绰更；因?yàn)镽elativeLayout在測量的時(shí)候會(huì)測量二次，而LinerLayout測量一次锡宋，可以看下它們的源碼儡湾；
• 刪除控件中無用的屬性;
• 布局復(fù)用.比如listView 布局復(fù)用
• 盡量避免過度繪制（overdraw）,比如：背景經(jīng)常容易造成過度繪制。由于我們布局設(shè)置了背景执俩，同時(shí)用到的MaterialDesign的主題會(huì)默認(rèn)給一個(gè)背景徐钠。這時(shí)應(yīng)該把主題添加的背景去掉；還有移除 XML 中非必須的背景
• 自定義View優(yōu)化役首。使用 canvas.clipRect()來幫助系統(tǒng)識(shí)別那些可見的區(qū)域尝丐，只有在這個(gè)區(qū)域內(nèi)才會(huì)被繪制。也是避免過度繪制．
• 啟動(dòng)優(yōu)化,啟動(dòng)速度的監(jiān)控衡奥，發(fā)現(xiàn)影響啟動(dòng)速度的問題所在爹袁，優(yōu)化啟動(dòng)邏輯，提高應(yīng)用的啟動(dòng)速度矮固。比如閃屏頁面失息，合理優(yōu)化布局，加載邏輯優(yōu)化档址，數(shù)據(jù)準(zhǔn)備等根时。
• 合理的刷新機(jī)制，盡量減少刷新次數(shù)辰晕，盡量避免后臺(tái)有高的 CPU 線程運(yùn)行，縮小刷新區(qū)域确虱。

4. andriod卡頓優(yōu)化所用到的工具

性能問題并不容易復(fù)現(xiàn)含友，也不好定位，但是真的碰到問題就需要借助相應(yīng)的的調(diào)試工具,下面介紹比較常用的調(diào)試工具校辩。

• Profile GPU Rendering
  在手機(jī)開發(fā)者模式下窘问，有一個(gè)卡頓檢測工具叫做：Profile GPU Rendering,看圖：

• Debug GPU overDraw過度繪制檢測
  在手機(jī)開發(fā)者模式下，有一個(gè)過度繪制檢測工具叫做：Debug GPU overDraw（調(diào)式 GPU 過度繪制）：
  

  圖片.png

• 原色：沒有過度繪制

• 藍(lán)色：1 次過度繪制

• 綠色：2 次過度繪制

• 粉色：3 次過度繪制

• 紅色：4 次及以上過度繪制

三宜咒、耗損低 -耗電優(yōu)化

在移動(dòng)設(shè)備中惠赫，電池的重要性不言而喻，沒有電什么都干不成故黑。

1. 優(yōu)化方案：

• 合理的使用wack_lock鎖儿咱，wake_lock鎖主要是相對(duì)系統(tǒng)的休眠(這里就是為了省電庭砍，才做休)而言的，意思就是我的程序給CPU加了這個(gè)鎖那系統(tǒng)就不會(huì)休眠了混埠，這樣做的目的是為了全力配合我們程序的運(yùn)行怠缸。有的情況如果不這么做就會(huì)出現(xiàn)一些問題，比如微信等及時(shí)通訊的心跳包會(huì)在熄屏不久后停止網(wǎng)絡(luò)訪問等問題钳宪。所以微信里面是有大量使用到了wake_lock鎖揭北。這里有一篇關(guān)于wake_lock的使用，請(qǐng)查閱吏颖；

• 使用jobScheduler2搔体，集中處理一些網(wǎng)絡(luò)請(qǐng)求，有些不用很及時(shí)的處理可以放在充電的時(shí)候處理半醉，比如疚俱，圖片的處理，APP下載更新等等奉呛，這里有一篇關(guān)于jobScheduler的使用计螺，請(qǐng)查閱；

• 計(jì)算優(yōu)化瞧壮，避開浮點(diǎn)運(yùn)算等登馒。

• 數(shù)據(jù)在網(wǎng)絡(luò)上傳輸時(shí)，盡量壓縮數(shù)據(jù)后再傳輸咆槽，建議用FlatBuffer序列化技術(shù)陈轿，這個(gè)比json效率高很多倍，不了解FlatBuffer秦忿，建議找資料學(xué)習(xí)一下麦射，后面有時(shí)間的話，也會(huì)專門寫關(guān)于FlatBuffer的文章．

2. andriod耗電分析所用到的工具

在 Android5.0 以前灯谣，在應(yīng)用中測試電量消耗比較麻煩潜秋，也不準(zhǔn)確，5.0 之后專門引入了一個(gè)獲取設(shè)備上電量消耗信息的 API:Battery Historian胎许。Battery Historian 是一款由 Google 提供的 Android 系統(tǒng)電量分析工具峻呛，是一款圖形化數(shù)據(jù)分析工具，直觀地展示出手機(jī)的電量消耗過程辜窑，通過輸入電量分析文件钩述，顯示消耗情況，最后提供一些可供參考電量優(yōu)化的方法穆碎。

Battery Historian耗電分析工具
[圖片上傳失敗...(image-4ecfd5-1566722662631)]

Battery Historian耗電分析工具的開源地址;

四牙勘、安裝包-優(yōu)化

隨著功能不斷增加，APP的包肯定不會(huì)斷的變大所禀，但應(yīng)用的安裝包越大方面，用戶下載的門檻越高放钦，特別是在移動(dòng)網(wǎng)絡(luò)情況下，用戶在下載應(yīng)用時(shí)葡幸，對(duì)安裝包大小的要求更高最筒，因此，減小安裝包大小可以讓更多用戶愿意下載和體驗(yàn)產(chǎn)品蔚叨。所以床蜘，我們還是要想辦法去如何去優(yōu)化，盡量減小app的安排包蔑水。

1. res資源優(yōu)化

（1）只使用一套圖片邢锯，使用高分辨率的圖片。
（2）UI設(shè)計(jì)在ps安裝TinyPNG插件搀别，對(duì)圖片進(jìn)行無損壓縮丹擎。
（3）svg圖片：一些圖片的描述，犧牲CPU的計(jì)算能力的歇父，節(jié)省空間蒂培。使用的原則：簡單的圖標(biāo)。
（4）圖片使用WebP(https://developers.google.com/speed/webp/)的格式（Facebook榜苫、騰訊护戳、淘寶在用。）缺點(diǎn)：加載相比于PNG要慢很多垂睬。 但是配置比較高媳荒。工具：http://isparta.github.io/
（5）使用tintcolor(android - Change drawable color programmatically)實(shí)現(xiàn)按鈕反選效果。

2. 代碼優(yōu)化

（1）實(shí)現(xiàn)功能模塊的邏輯簡化
（2）Lint工具檢查無用文件將無用的資源列在“UnusedResources: Unused resources”驹饺，刪除钳枕。
（3）移除無用的依賴庫。

3. lib資源優(yōu)化

（1）動(dòng)態(tài)下載的資源赏壹。
（2）一些模塊的插件化動(dòng)態(tài)添加鱼炒。
（3）so文件的剪裁和壓縮。

4. assets資源優(yōu)化

（1）音頻文件最好使用有損壓縮的格式蝌借，比如采用opus田柔、mp3等格式，但是最好不要使用無損壓縮的音樂格式
（2）對(duì)ttf字體文件壓縮骨望，可以采用FontCreator工具只提取出你需要的文字。比如在做日期顯示時(shí)欣舵，其實(shí)只需要數(shù)字字體擎鸠，但是使用原有的字體庫可能需要10MB大小，如果只是把你需要的字體提取出來生成的字體文件只有10KB

5. 代碼混淆缘圈。

使用proGuard 代碼混淆器工具劣光，它包括壓縮袜蚕、優(yōu)化、混淆等功能绢涡。

6. 7z極限壓縮

具體請(qǐng)參考微信的安接包壓縮,實(shí)現(xiàn)實(shí)現(xiàn)原理牲剃，有時(shí)間再分析；

五雄可、穩(wěn)定-內(nèi)存優(yōu)化

在 Android 系統(tǒng)中有個(gè)垃圾內(nèi)存回收機(jī)制凿傅，在虛擬機(jī)層自動(dòng)分配和釋放內(nèi)存，因此不需要在代碼中分配和釋放某一塊內(nèi)存数苫，從應(yīng)用層面上不容易出現(xiàn)內(nèi)存泄漏和內(nèi)存溢出等問題聪舒，但是需要內(nèi)存管理。

除此之外虐急，部分 Android 應(yīng)用開發(fā)人員在開發(fā)過程中并沒有特別關(guān)注內(nèi)存的合理使用箱残，也沒有在內(nèi)存方面做太多的優(yōu)化，當(dāng)應(yīng)用程序同時(shí)運(yùn)行越來越多的任務(wù)止吁，加上越來越復(fù)雜的業(yè)務(wù)需求時(shí)被辑，完全依賴 Android 的內(nèi)存管理機(jī)制就會(huì)導(dǎo)致一系列性能問題逐漸呈現(xiàn)，對(duì)應(yīng)用的穩(wěn)定性和性能帶來不可忽視的影響敬惦，因此盼理，解決內(nèi)存問題和合理優(yōu)化內(nèi)存是非常有必要的。

在開發(fā)的過程仁热，如果方法不當(dāng)?shù)脑挵褚荆苋菀自斐蓛?nèi)存泄漏，接下來抗蠢，來說一下哪些情景容易出現(xiàn)內(nèi)存泄漏举哟。

1. 內(nèi)存泄漏出現(xiàn)的情景

• 單例中引用的上下文Context，引用了Activity中的Context, 這樣會(huì)造成內(nèi)存泄漏迅矛，要引用Application中的Context;
• 資源性對(duì)象未關(guān)閉妨猩。比如Cursor、File文件等，往往都用了一些緩沖，在不使用時(shí)吞获，應(yīng)該及時(shí)關(guān)閉它們咐汞。
• 注冊(cè)對(duì)象未注銷。比如事件注冊(cè)后未注銷氧映，會(huì)導(dǎo)致觀察者列表中維持著對(duì)象的引用。
• 類的靜態(tài)變量持有大數(shù)據(jù)對(duì)象。
• 非靜態(tài)內(nèi)部類的靜態(tài)實(shí)例约谈。
• Handler臨時(shí)性內(nèi)存泄漏。如果Handler是非靜態(tài)的，容易導(dǎo)致 Activity 或 Service 不會(huì)被回收棱诱。
• 容器中的對(duì)象沒清理造成的內(nèi)存泄漏泼橘。
• WebView。WebView 存在著內(nèi)存泄漏的問題迈勋，在應(yīng)用中只要使用一次 WebView炬灭，內(nèi)存就不會(huì)被釋放掉。

2. 內(nèi)存優(yōu)化的方案

• 對(duì)象引用靡菇。強(qiáng)引用重归、軟引用、弱引用镰官、虛引用四種引用類型提前，根據(jù)業(yè)務(wù)需求合理使用不同，選擇不同的引用類型泳唠。
• 減少不必要的內(nèi)存開銷狈网。注意自動(dòng)裝箱，增加內(nèi)存復(fù)用笨腥，比如有效利用系統(tǒng)自帶的資源拓哺、視圖復(fù)用、對(duì)象池脖母、Bitmap對(duì)象的復(fù)用士鸥。
• 使用最優(yōu)的數(shù)據(jù)類型。比如針對(duì)數(shù)據(jù)類容器結(jié)構(gòu)谆级，可以使用ArrayMap數(shù)據(jù)結(jié)構(gòu)烤礁，避免使用枚舉類型，使用緩存Lrucache等等肥照。
• 圖片內(nèi)存優(yōu)化脚仔。可以設(shè)置位圖規(guī)格舆绎，根據(jù)采樣因子做壓縮鲤脏，用一些圖片緩存方式對(duì)圖片進(jìn)行管理等等。圖片的壓縮幾種方案;
• 大量使用線程時(shí)吕朵，采用線程池猎醇。
• 避免創(chuàng)建過多的對(duì)象。
• 不要過多使用枚舉努溃，枚舉占用的內(nèi)存空間要比整型大硫嘶。
• 常量請(qǐng)使用 static final 來修飾。
• 采用內(nèi)存緩存和磁盤緩存梧税。
• 適當(dāng)使用軟引用和弱引用音半。
• 盡量采用靜態(tài)內(nèi)部類则拷，這樣可以避免潛在的由于內(nèi)部類而導(dǎo)致的內(nèi)存泄漏。

3. 內(nèi)存分析工具

做內(nèi)存優(yōu)化前曹鸠，需要了解當(dāng)前應(yīng)用的內(nèi)存使用現(xiàn)狀，通過現(xiàn)狀去分析哪些數(shù)據(jù)類型有問題斥铺，各種類型的分布情況如何彻桃，以及在發(fā)現(xiàn)問題后如何發(fā)現(xiàn)是哪些具體對(duì)象導(dǎo)致的，這就需要相關(guān)工具來幫助我們晾蜘。以下介紹幾種內(nèi)存分析工具

• Memory Monitor
  Memory Monitor 是一款使用非常簡單的圖形化工具邻眷，可以很好地監(jiān)控系統(tǒng)或應(yīng)用的內(nèi)存使用情況．
  主要有以下功能：

(1) 顯示可用和已用內(nèi)存，并且以時(shí)間為維度實(shí)時(shí)反應(yīng)內(nèi)存分配和回收情況剔交。
(2) 快速判斷應(yīng)用程序的運(yùn)行緩慢是否由于過度的內(nèi)存回收導(dǎo)致肆饶。
(3) 快速判斷應(yīng)用是否由于內(nèi)存不足導(dǎo)致程序崩潰。

• Heap Viewer
  Heap Viewer 的主要功能是查看不同數(shù)據(jù)類型在內(nèi)存中的使用情況岖常，可以看到當(dāng)前進(jìn)程中的 Heap Size 的情況驯镊，分別有哪些類型的數(shù)據(jù)，以及各種類型數(shù)據(jù)占比情況竭鞍。通過分析這些數(shù)據(jù)來找到大的內(nèi)存對(duì)象板惑，再進(jìn)一步分析這些大對(duì)象，進(jìn)而通過優(yōu)化減少內(nèi)存開銷偎快，也可以通過數(shù)據(jù)的變化發(fā)現(xiàn)內(nèi)存泄漏冯乘。
  主要有以下功能：
  (1) 實(shí)時(shí)查看App分配的內(nèi)存大小和空閑內(nèi)存大小
  (2) 發(fā)現(xiàn)Memory Leaks
  Heap Viewer不光可以用來檢測是否有內(nèi)存泄漏，對(duì)于內(nèi)存抖動(dòng)晒夹，我們也可以用該工具檢測裆馒，因?yàn)閮?nèi)存抖動(dòng)的時(shí)候，會(huì)頻繁發(fā)生GC丐怯，這個(gè)時(shí)候我們只需要開啟Heap Viewer,觀察數(shù)據(jù)的變化喷好，如果發(fā)生內(nèi)存抖動(dòng)，會(huì)觀察到數(shù)據(jù)在段時(shí)間內(nèi)頻繁更新响逢。

• Allocation Tracker
  Memory Monitor 和 Heap Viewer 都可以很直觀且實(shí)時(shí)地監(jiān)控內(nèi)存使用情況绒窑，還能發(fā)現(xiàn)內(nèi)存問題，但發(fā)現(xiàn)內(nèi)存問題后不能再進(jìn)一步找到原因舔亭，或者發(fā)現(xiàn)一塊異常內(nèi)存些膨，但不能區(qū)別是否正常，同時(shí)在發(fā)現(xiàn)問題后钦铺，也不能定位到具體的類和方法订雾。這時(shí)就需要使用另一個(gè)內(nèi)存分析工具 Allocation Tracker，進(jìn)行更詳細(xì)的分析矛洞， Allocation Tracker 可以分配跟蹤記錄應(yīng)用程序的內(nèi)存分配洼哎，并列出了它們的調(diào)用堆棧烫映，可以查看所有對(duì)象內(nèi)存分配的周期。

• Memory Analyzer Tool(MAT)
  MAT 是一個(gè)快速噩峦，功能豐富的 Java Heap 分析工具锭沟，通過分析 Java 進(jìn)程的內(nèi)存快照 HPROF 分析，從眾多的對(duì)象中分析识补，快速計(jì)算出在內(nèi)存中對(duì)象占用的大小族淮，查看哪些對(duì)象不能被垃圾收集器回收，并可以通過視圖直觀地查看可能造成這種結(jié)果的對(duì)象凭涂。

4. 穩(wěn)定性優(yōu)化

Android 應(yīng)用的穩(wěn)定性定義很寬泛祝辣，影響穩(wěn)定性的原因很多，比如內(nèi)存使用不合理切油、代碼異常場景考慮不周全蝙斜、代碼邏輯不合理等，都會(huì)對(duì)應(yīng)用的穩(wěn)定性造成影響澎胡。其中最常見的兩個(gè)場景是：Crash 和 ANR孕荠，這兩個(gè)錯(cuò)誤將會(huì)使得程序無法使用，比較常用的解決方式如下：

• 提高代碼質(zhì)量滤馍。比如開發(fā)期間的代碼審核岛琼，看些代碼設(shè)計(jì)邏輯，業(yè)務(wù)合理性等巢株。
• 代碼靜態(tài)掃描工具槐瑞。常見工具有Android Lint、Findbugs阁苞、Checkstyle困檩、PMD等等。
• Crash監(jiān)控那槽。把一些崩潰的信息悼沿，異常信息及時(shí)地記錄下來，以便后續(xù)分析解決骚灸。
• Crash上傳機(jī)制糟趾。在Crash后，盡量先保存日志到本地甚牲，然后等下一次網(wǎng)絡(luò)正常時(shí)再上傳日志信息义郑。

六、總結(jié)：

其實(shí)app性能優(yōu)化丈钙，不是一二天可以完成的非驮，主要是要開發(fā)的過程，不斷的提前代碼的質(zhì)量雏赦，開發(fā)人員提高自己的開發(fā)水平劫笙，發(fā)現(xiàn)了問題芙扎，就要及時(shí)的解決。

參考作者：android的那點(diǎn)事
鏈接：http://www.reibang.com/p/d71b51a0e29f