android終端專項寶典-下篇先行版

先行版必看說明！先行版必看說明！/mobileperfman/BookResource/issues，創(chuàng)建issue。給我們寶貴的意見，讓我誰適合讀此書誰適合讀此書致謝致謝 avin專家，Emi,，的鼎力支持先行版必看說明 誰適合讀此 致 歡迎你離開桌面的世 故事的起 如何利用 資源類性 CPU 原理 工具 案例：音樂放的卡頓問 磁盤 原理 工具 案例：手Q啟動過程中/proc/cpuinfo由10次的讀操作降到2 案例：ObjectOutputStream的4000多次的寫操 案例：手Q“健康中心”使用的Buffer過 案例：手Q解壓文件使用Buffer太 案例：主線程有DB操 案例表剛創(chuàng)建完，就做大量的查詢操作。.. 案例重復(fù)打開數(shù)據(jù) 網(wǎng)絡(luò) 工具 案例：數(shù)據(jù)上報與流量的取 案例：WebView緩存使用的 案例：離線包重復(fù)案 案例：使用壓縮策略優(yōu)化資源流 案例：手Q發(fā)圖速度優(yōu) 案例：手Q在弱網(wǎng)下PTT重復(fù)發(fā) 網(wǎng)絡(luò)軍 電池 原理 工具 案例：QQWIFI耗 案例：動畫沒有及時釋 穩(wěn)定 穩(wěn)定性原 案例：反復(fù)的空指針問 案例 內(nèi)存不足異常原因分 內(nèi)存不足異常類型分 內(nèi)存不足類異常的原因排查和解 內(nèi)存不足之前，我們能做哪些事情... 工具 兼容 原理 工具 動態(tài)檢查：云測 動態(tài)檢查：眾 靜態(tài)檢查 靜態(tài)檢查：卡帕萊（優(yōu)測 歡歡迎你離開桌面的世界故事的起點故事的起點記得我從和MACQQ項目中解放出來，就開始接手Q，組建專項測試團隊。那時有幾個小伙越來越差，我們開始用更嚴厲的標準像守護者一樣守護QQ，例如：安裝包的大小，接手后的超過則需求都不讓合進來，從此安裝包也剎住了車。但KPI這東西真的很厲害，像是洪水，不泄呢？為什么不能占用的內(nèi)存？我提供服務(wù)，為什么不能消耗流量？為什么？能再變大了。這里需要，運營同學(xué)找到了應(yīng)用寶的數(shù)據(jù)，發(fā)現(xiàn)有不少用戶是3G，還有失敗率的影響。數(shù)據(jù)跟匯報過后，我們拍定了更嚴厲的標準：0增長。類似的這些故事，解決專項BUG，有跟產(chǎn)品經(jīng)理PK需求與專項性能的平衡。但是知道故事的人并不多，知道“為什面會介紹工具原理但更重要 是是一個個真實的案例BUG解決方案。如何利用我如何利用我資源類資源類性能CPU原理篇I/O密集型問題，另外一種就是現(xiàn)在要介紹具發(fā)現(xiàn)。但是，難道這章就沒有東西可以說了？當然不是。我們就先從CPU作為硬件講起?，F(xiàn)在的CPU有非常多款，比較有名氣的有MTK系列的，m系列的，三星的獵戶座，的CPUV4倍。另外就是核心數(shù)，根據(jù)統(tǒng)計數(shù)據(jù)估算，現(xiàn)在主流的數(shù)依然是4核，起碼有60%以上的用戶量，8核的而另外一個跟CPU非常有關(guān)的，就是CPU調(diào)度器的策略配置。如上圖所示，現(xiàn)在的主流其實是Hotplug,interactive,ondemand,pegasusq。下面工具集里面有每個的策略的含義。這里重點要說的interactiive,分析卡頓的時候可以關(guān)注在hotplug工具集TOP命令大家應(yīng)該是非常熟悉的了，依靠adbstop就可以簡單地列出進程們的各種信息。缺點TOPTOP。下面舉幾個TOP的小例子：11.排除的進程信adbtp|ev0S只打印1次按CPU排序的TOP10的進程信息：adbstop-m10-scpu-n指定進程的CPU，內(nèi)存等消耗，并設(shè)置刷新間隔：adbstop-d1|grepadbsps-p-t-P-x–cPROCPROCCUCat/proc/[pid字 內(nèi) pgrpofthe session ttytheprocess pgrpofthe task numberofminor numberofminorfaultswithchild's numberofmajorfaults numberofmajorfaultswith 用戶態(tài)CPU消耗（usermodejiffies） CPU消耗（usermodejiffieswithcstimecstimeT 下的信息adbadb cat 按需調(diào)節(jié)cpu頻率,不操作的時候控制在最低頻率,滑屏或進入應(yīng)用后會迅速提升至最平。是一種在電池和性能之間趨向平衡的默認模式,但是對于智能來說,ondemand在性CPU運行在配置的頻率范圍內(nèi),配置中的用戶自己添加的省電設(shè)置。當?shù)托枨髸r逐漸降低頻率,相比ondemand費電很好,CP本身不需要資源去調(diào)整頻率,但是電量消耗較快,溫度也高些。源自三星獵戶座處理器的一個調(diào)速器，可以單獨調(diào)控單個CPU內(nèi)核，理論上性能不錯也很省電。DUMPSYS通過執(zhí)行adb SYSTRACE&TRACEVIEW&CPU相關(guān)。SYSTRACETRACEVIEW作為定位工具，在交互類性能的工具里面已經(jīng)說過了。而TREN會作為耗電的分工具在后面再重點介紹案例：音樂 的卡頓問問題類型：CPU消耗過高CPUQQ音樂在小米3上鎖屏時會出現(xiàn)概率性斷斷續(xù)續(xù)，但亮屏時是不卡的具體細節(jié)：優(yōu)化效果磁盤篇磁盤篇原理篇/O統(tǒng)I/O的調(diào)度策略等。磁盤硬件結(jié)構(gòu)目前上使用大多為NANDFlash，NANDFlash架構(gòu)是由東芝在1989年的，NANDFlash具有較快的抹寫時間，而且每個單元的面積也較小，這讓NANDFlash相較于NORNANDFlash的I/O接口并沒有隨機存取外部地址總線，它必須以區(qū)塊性的方式進行，NAND由數(shù)個頁（Page，多為4KB）所構(gòu)成。為了延長驅(qū)動器的，其讀寫操作均是以“頁”為單位進“寫入放大”效應(yīng)存空間上（已擦除狀態(tài)）LBAFTL地址。此時，舊的地址內(nèi)容在上述的無效區(qū)域進行再次寫入的話，為了得到空閑空間，閃存必須先該“塊”中所有的有效比如，現(xiàn)在寫入一個4KB的數(shù)據(jù)，的情況就是，一個塊里已經(jīng)沒有干間了，但是恰好4KB新時帶來了原本只需要簡單的寫4KB的操作變成“閃存(512KB)→緩存改（4KB）→閃存擦除（512KB（WriteAplificaton）問題。1SD1M文件，統(tǒng)計文件寫入耗時干凈的數(shù)據(jù)塊。這時再向SD卡寫入1M的文件，統(tǒng)計文件寫入耗時910090069300SD卡沒有I/O調(diào)度策略有4種：cfq、deadline、noop和row，我們對目前市面上的339款 采樣，有88.8%使用的是fcfq：I/ORT(reltim)、BEbesttry)、ILE(idle其中TBE又可8個子優(yōu)先級。2.6.26I/O優(yōu)先級的進程通常使用“none”作為調(diào)度I/O優(yōu)先級會根據(jù)這些進程的CPUnice級別動態(tài)變更，io_priority=(cpu_nice+20)/5。操作。同時，noopFIFO的基礎(chǔ)上還做了相鄰I/O請求的合并。更全的I/O調(diào)度策略及對比，詳見：/p/io-低磁盤空間的影響即在可用磁盤空間很少的情況下，APP的性能會有怎樣的表現(xiàn)。這里作為磁盤專題，我們就來看看寫入1M大小的文件，統(tǒng)計寫入文件的耗時，一直到可用空間為5M為止。然后剛寫入的文DEMO12款機型上測試，下圖是寫文件的耗時曲線圖（橫軸是磁盤可用空間，從左到右依從下表可以看出 MT7和OPPON5207的SD卡型號同為Toshiba032GE4，但是卻有不同機B-199MT7-TL10OPPOvivoSM-GT-HMNOTEMI工具集 啟動慢、滑動不流暢？開發(fā)在費了九牛二虎之力后，無奈地說沒辦法了，類的性能問題就隨之解決了，用戶的也就煙消云散，你又可以做著升職加薪的美夢了！資源類性能用戶雖然不能直接感受到，如磁盤、cpu等，但是會直接影響交互類的體驗。了這塊的不足后，專項測試組最終自研了一款磁盤I/O的工具-I/OMonitor一、hookjavanative方法調(diào)調(diào)用系統(tǒng)IO方法變成調(diào)調(diào)調(diào)用java層回調(diào)函調(diào)調(diào)用系統(tǒng)原有對應(yīng)的IO方調(diào)用jaa層回調(diào)函數(shù)aftrbeorehookedmehod獲取此次IO操作的信2.1I/Oapp_process是Android中Java程序的，通過替換app_process，就可以控制，在任何一個應(yīng)用中運行我們的代碼。替換后的app_process工作流程如下：調(diào)用啟動調(diào)用啟動YlibforkoLD在UNIX的動 庫的世界中，LD_PREOAD就是這樣一個環(huán)境變量它可以影響程序的運行時 ，zygoteLD_PRELOADzygote的所有子進程都會繼承這個環(huán)境變用我實現(xiàn)的fork函數(shù)，fork函數(shù)的流程如下：調(diào)用fork調(diào)用forkJavaVMYTENXPlatform.jar添加到環(huán)境變量

dexCLASSPATH中（XPlatform實現(xiàn)方法不同，但效果相同dex可以直importdexCLASSPATHDexClassLoader類來使用另一個jar包中的類，這樣使用起來很麻煩，并且會有很大的限制。在XPlatform中主要hook了兩個java方法，來system_server進程和應(yīng)用進程的啟動，并在這創(chuàng)建的任何一個應(yīng)用進程和system_server進程也是生效的。N在Y這樣就實現(xiàn)了在應(yīng)用進程啟動時控制在指定進程中運行OMonitor本，這樣就可以實現(xiàn)指定場景的I/O信息收集，使做到更精準。運行python運行python控通過adb來運行運機上的運行Xplatform.jar的類導(dǎo)能，下面就來介紹I/OMonitor是如何使用的。hookI/OMonitor是用python寫的控制，用來控制I/OMonitor的開始和停止。3，待安裝完成后，把“/dt/dataom.xptformistller/co dl.xml”文件pull到電腦<moduledexname="common.jar"<moduledexname="common.jar"5，修改完成后，需要把module.xml文件push到“ ifname=="mainMonitorifname=="mainMonitor=IOMonitor('com.tencent.mobileqq')print"press'y'to7，運行runIOMonitor.py->操作APP->停止I/OMonitor，就可以獲取到整個操作過程中，APP進行的I/O數(shù)據(jù)，I/OI/OMonitorcsvpullD盤下面，文件名為I/OI/O

從上圖中可以看出，I/OMonitor獲取到了相當多的數(shù)據(jù)，下面介紹一下各列數(shù)據(jù)的含義 操作該文件的線程名稱readcount(writecount)： publicvoidonCreate()if(DEVELOPER_MODE)}}性能分析 工具pagesizeI/O，而這些都是我們常規(guī)的優(yōu)化數(shù)據(jù)庫的。習慣從分析業(yè)務(wù)特性、嘗試優(yōu)化策略、驗證的正數(shù)據(jù)庫I/O數(shù)據(jù)JavaHook技術(shù)，獲取到了Java層的I/O操作數(shù)據(jù)，雖然的IO操作在lib.so進行，而lib.so屬于Native層，但很自然地想到通過NativeHook的I/O數(shù)據(jù)。些了解，NativeHook主要有以下實現(xiàn)方式：Inline1，修改環(huán)境變量這種方式實現(xiàn)最簡單，重寫系統(tǒng)函數(shù)open、read、writeclose，將so庫放進環(huán)境變量數(shù)?？梢詤⒖糀ndroid使用LD_PRELOAD進行HOOK。2，修改GOTSO外部函數(shù)的時候，在編譯時會將外部函數(shù)的地址以Stub的形式存放在.GOT表中，加載時linker再進行重定位，即將真實的外部函數(shù)寫到此stub中。HOOK的思路就是：替換.GOT表中的外部函數(shù)地址。而lib.so中的I/O操作是調(diào)用libc.so中系統(tǒng)函數(shù)進行，所以修改GOT表的HOOK方案是可行的。修改GOT表的方案們采用的是orbywang提供的HOOKDK。libqliteoopnclose函red/writesqlit的源碼下來，自看了許久的源碼，經(jīng)過無數(shù)次的調(diào)試，終于定位到原因，提供了unixSetSystemCall函數(shù)，可以來修改系統(tǒng)調(diào)用。如果把這個方法注釋掉，就可以HOOKreadwrite的方法。staticint3_vfs*pNotUsed, /*TheVFSpointer.Notused*/constchar /*Nameofsystemcalltooverride3_syscall_ptr /*Pointertonewsystemcallvalueunsignedintintrc=_NOTFOUND;if(zName==0/*IfnozNameisgiven,restoreallsystemcallstotheir**settingsandreturnrc=for(i=0;i<sizeof(aSyscall)/sizeof(aSyscall[0]);沒啥卵用，日志不輸出，文件不創(chuàng)建。一切能想到的都用了，實在是不知道里面動了什3，INLINEInlineHook開始InlineHok可以Hook 庫的內(nèi)部函數(shù)，我們首先想到的是H klib .so內(nèi)部I/O接口posixOpen、sekandrad、seekandwte以及robust_close。但是成功的 總是充滿波折， 竟然將大部分的關(guān)鍵函數(shù)定義為tatic函數(shù)，如posixOpen 在c語言，sati函數(shù)是不導(dǎo)出符號的，而InlineHook就是要在符號表中找到對應(yīng)的函數(shù)位置這樣一來通過ooksqle內(nèi)部函數(shù)的staticintposixOpen(constchar*zFile,intflags,intmode){returnopen(zFile,flags,mode);}既然這樣不行，那我們只能更地Hooklibc.so中的open、read、write和close方法。因為不管種方法在自己編譯的lib.so里面證實是可行的。幾乎是的。為什么編譯的lib.so庫可以，用上的就不行呢？調(diào)用系統(tǒng)函數(shù)pread、pread64以及read來進行讀文件。莫非編的so和里面的so的編譯staticintseekAndRead(unixFile*id,3_int64offset,void*pBuf,intcnt){intgot;intprior=i64newOffset;#ifgot=osPread(id->h,pBuf,cnt,offset);SimulateIOError(got=-1);#elifgot=osPread64(id->h,pBuf,cnt,offset);SimulateIOEror(got -1);newOffset=lseek(id->h,offset,SEEK_SET);SimulateIOError(newOffset--);HOOK應(yīng)用層SQL操作Hook應(yīng)用代碼其實就是HookDatabase里面的數(shù)據(jù)庫增刪改查操作，java層hook我們有一套Q啟動過程中/PROC/CPUINFO10次的讀操作降到2是同一個方法調(diào)用的，所以可以在isSupportGAudio()方法中，將的信息保存起來，下次再調(diào)用時，就不用再去文件中了。些信息了，優(yōu)化后，該文件的讀操作有10次降為2次避免重復(fù)打開關(guān)閉文件就是很有效的，即要避免重復(fù)讀寫。從上文得知I/O信息中的每一行數(shù)十有是可以優(yōu)化的。使用緩存，對于需要多次的數(shù)據(jù)，在第一次取出數(shù)據(jù)時，將數(shù)據(jù)放到案例：對于系統(tǒng)API，只知其一造成重復(fù)寫入Android系統(tǒng)中使用SharedPreferences文件來保存數(shù)據(jù)非常方便，在需要保存數(shù)據(jù)的地方調(diào)用關(guān)閉，從而造成commit()方法的隨意調(diào)用，導(dǎo)致文件的重復(fù)打開和關(guān)閉。Android .qzone.xml文.qzone.xmlTT案例：手Q啟動將 .MYCARRIER文件的寫操作由主線 到QQ_FILE_RW線程I/O眾所周知，Android的UI操作在主線程進行操作，主線程耗時越少，UI界面的生成就可以更OBJECTOUTPUTSTREAM4000多次的寫操作1KObjectOutputStream()4000+次造成了很大的性能影響。存區(qū)中，然后再寫到磁盤上。:找尋序列化最佳的實踐I/OKB1000多次，頻繁的寫入勢必嚴重影響APP性能。解決方法：可以通過使用緩沖區(qū)有效減少磁盤I/O46%36%I/OAPP來說，這個效果會更明I/O耗時11QBUFFER過小案例分析：從“健康中心”的I/O信息可以到，OfflineSecurity()方法了100多個文件，通過計Q解壓文件使用BUFFER太小問題類型：問題類型：I/O 看到在該方法中使用Buffer大小確實只有2KB。經(jīng)驗，這里推薦使用的Buffer大小為8KB，這和java的默認的Buffer大小一致，Buffer大小至少應(yīng)為4KB。當然，Buffer也不是越大越好，Buffer如果太大，會導(dǎo)致申請Buffer的時間變長，反而導(dǎo)致整體效率不高從上文看出I/OMonitor可以獲取到讀寫的大小和次數(shù) 統(tǒng)API的次數(shù)所以讀寫大小/讀寫次數(shù)就可以得到Buffer的大小，如果uffer太小存在問題，則一：尋找解壓和壓縮的最佳實踐AndroidZIPAndroid的有兩種解壓ZIP的方法，ZipFileZipInputStream帶著以上問題，現(xiàn)在就開始ZIP的解壓之旅。有些同學(xué)可能對理論分析不感，想知道結(jié)論1，ZIP文件結(jié)構(gòu)ZIPFileEntry表示一個文件實體,存一個文件實體的偏移，文件最后由Endofcentraldirectory結(jié)束。04404426282224CRC-32442文件名稱長度2擴展字段長度nmETNCEData增加一個Datadescriptor來記錄。04CRC-3244CentralDirectoryFileENN04ENN044262822224CRC-32442文件名稱長度2擴展字段長度2文件注釋長度2244nmkEndofCentralDirectoryEN EN 字0404262822442Zip文件注釋長度nQ1：CentralDirectory通過CentralDirectory獲取ZIP信息，而不能通過掃描文件的方式，因為centraldirectory可能一些文件被刪除或者已經(jīng)更新。CentralDirectory中Entry的順序可以和文件的實際順序不一樣。Q2：ZIPCZIPCentralDirectoryA和新文件C，這樣就實現(xiàn)了刪除文件B和更新文件C。2，ZIP文件解壓ZipInputStreamreadZipF壓縮文件 Yzlib解壓出count字返返這里要重點介紹一下需要讀入數(shù)據(jù)？N 解壓入的數(shù)從流程圖可以看jBffernave層。每次傳入的數(shù)據(jù)大小是固定值為512字節(jié)，在InflaterInputStream.java中定義如下：staticfinalintBUFSIZE=對于壓縮文件來說，最終會調(diào)用zlib中的inflate.c來解壓文件，inflate.c通過狀態(tài)機來對文件進 /4.4.4r1/xref/external/zlib/src/inflate.c，返回count字節(jié)并不等于buffer的大小，取決于inflate解壓返回的數(shù)據(jù)。ZipFile通過RandomAccessFile隨機zip文件，通過CentralDirectory得到zip中所有的面就可以利用RandomAccessFile的特性，每次讀入的數(shù)據(jù)來提高解壓效率。RandomAccessFile和InflateInputStream，通過getInputStream()返回，ZipFile的解壓流程和ZipInputStream類似。protectedvoidfill()throwsIOExceptionif(nativeEndBufSize>0)ZipFile.RAFStreamis=(ZipFile.RAFStream)len=is.fill(inf,}elseif((len=in.read(buf))>0)inf.setInput(buf,0, 下面同樣給出需要讀入數(shù)據(jù)？nflater 據(jù)的大小傳到native層nativebufferZipFile1KB64KB之間，如果文件大小介于二者之間，則可以一次將文件處理完。而對于ZipInputStream來說，每次能處理的數(shù)據(jù)只能是512個字節(jié)，所以ZipFile的解壓3，ZIPFILEVSZIPINPUTSTREAM效率對比解壓文件可以分三步：1，從磁盤讀出zip文件2，inflate3，ZipFile在ative1KB~64KBZipInutream只有采用更大Buffer才可能達到ZiFil的性能。從上文可知，inflateinflate的解壓算法有關(guān)，另一方面取nativeinfalte.cZipInputStream512字節(jié)數(shù)據(jù)到nativeZipFile每次傳遞的數(shù)據(jù)可以在1KB~64KBZipFile的解壓效率更高。從javautilzipInflater.cppAndroiddemo驗證（關(guān)鍵代碼FileInputStreamFileInputStreamfis=newZipInputStreamzis=newZipInputStream(newBufferedInputStream(fis));byte[]buffer=newbyte[8192];FiledstFile=newFile(dir+"/"+ze.getName());FileOutputStreamfos=newFileOutputStream(dstFile);while((count=zis.read(buffer))!=-1){}}}ZipFilezipFileZipFilezipFile=newZipFile(files);InputStreamis=null;Enumeratione=zipFile.entries();while(e.hasMoreElements()){entry=(ZipEntry)e.nex is=dstFile=newFile(dir+"/"+entry.getName());fos=newFileOutputStream(dstFile);byte[]buffer=newwhile((count=is.read(buffer,0,buffer.length))!=-}}osizsiz100jpg低壓縮率文高壓縮率文read用次耗時read用次耗時ZipFile減少百分結(jié)論：1ZipFile的read39%~93%ZipFile的數(shù)據(jù)輸出到BufferedOutputStream，等buffer滿后再寫入文件，這樣做的弊端是，因為要湊滿bufferread的調(diào)用次數(shù)增加，下面就對ZipFileZipInputstream做一個對比。FileInputStreamFileInputStreamfis=newZipInputStreamzis=newZipInputStream(newBufferedInputStreambis=newBufferedInputStream(zis)byte[]buffer=newbyte[8192];FiledstFile=newFile(dir+"/"+ze.getName());FileOutputStreamfos=newFileOutputStream(dstFile);while((count=bis.read(buffer))!=-1){}}ZipFileZipFilezipFile=newInputStreamis=null;Enumeratione=zipFile.entries();while(e.hasMoreElements()){entry=(ZipEntry) is=newBufferedInputStream(zipFile.getInputStream(entry));dstFile=newFile(dir+"/"+entry.getName());fos=newFileOutputStream(dstFile);byte[]buffer=newbyte[8192];while((count=is.read(buffer,0,buffer.length))!=-}}低壓縮率高壓縮率ZipFile耗時減buffer，增加了read的調(diào)用次數(shù)，導(dǎo)致整體耗時增加）Q4ZipFileZipInputStream且需全部解壓出ZIP中的文件，如果你的場景符合以上兩點，使用ZipFile無疑是正確的。同時，也可以利用ZipFile的隨機能力，實現(xiàn)解壓ZIP中間的某幾個文件。1ZipputStream是順序按流的方式文件，這種場景實現(xiàn)起來毫無壓力。Directory會帶來額外的耗時。ZipInputStream有15%~27%的提升。 顧一下ZipInputStream和ZipFile最高效的用法（紅色為關(guān)鍵部分。ZipInputStreamzis=newZipInputStream(newBufferedInputStream(fis));BufferedInputStreambis=newBufferedInputStream(zis)byte[]buffer=newbyte[8192];1){}}while(e.hasMoreElements()){entry=(ZipEntry)e.nexement();if低壓縮率文件，如文本isnewBufferedInputStream(zipFile.getInputStream(entry));elseif高壓縮率文件，如is=ziFile.getnputStreamentrybyte[]buffer=new1){}案例：主線程有DB操作解決方案：將DB操作移動其他線程進行案例：表剛創(chuàng)建完，就做大量的查詢操作。通過獲取手Q首次啟動的I/O數(shù)據(jù)，看到大量的對 字節(jié)。通過時間戳找到對應(yīng)的SQL語句，其對應(yīng)的是大量的SELECT*FROMExtensionInfoWHEREuin=?和SELECT*FROMFriendsWHEREuin=?語句，select語句耗時超過6秒。分 FriendsExtensionInfo在創(chuàng)建完之后，在插入好友信息前，需要先去表里面查詢一下是否存在該記錄。此時表是空的，所以才有大量的16字節(jié)的。案例：重復(fù)打開數(shù)據(jù)庫竟然打開數(shù)據(jù)庫424次，簡直駭人聽聞。多次打開數(shù)據(jù)庫有什接就會被緩存，以供下次使用，只有當真正不需要時，調(diào)用close關(guān)閉即可。為什么要appplugindownloaddb80ms120ms每次打開I/O操作。gtWritableDatabas的注釋也明確說明，該方法比較耗時，不能最后的話目前我們可以獲取到SQL語句的堆棧和耗時，以及其對應(yīng)的詳細的磁盤I/O信息，我相信這對數(shù)據(jù)庫優(yōu)化來說有很大幫助。雖然我們也有些成果，但我相信應(yīng)該還有可以做的事情，如果你有好的AUTOINCREMENT可沒有你想的那么簡單背景最近在分析手空（Android）60ms+，并且這條插1HOOKINSERTINTOevents(timestamp,content,status,send_count)VALUES(1445916309639,test,1索引惹的禍？createtableifnotexistsevents(event_idINTEGERPRIMARYKEYAUTOINCREMENTNOTNULL,contentTEXT,statusINTEGER,send_countINTEGER,timestampLONG)CREATEINDEXifnotexistsstatus_idxON3創(chuàng)建表的SQL4eventsINSERT耗時MTA（含索引MTA（不含索引AUTOINCREMENT-漏網(wǎng)之魚INSERT耗時((INSERT1條INSERT1條INSERT50條AUTOINCRM到這里用過Qte的同學(xué)能會對這個結(jié)果覺得難置信OEMET關(guān)鍵字在里面好像很常用啊，大家用的時候似乎也沒有擔心效率問題。Q2：AUTOINCREMENTINTEGERPRIMARYKEY就是“主鍵”，我們先來了解一下主鍵。表的每行都有一個行號，行號用64位有符號的整形表示。支持使用默認的列名ROWID、_ROWID_和OID來行號。同時，如果表里某一列指定為INTEGERPRIMARYKEY類型，那么這一列和ROWID是等價的。也就是如果你指定某一列為主鍵，該列其實就是1開始，如果在插入數(shù)據(jù)時明確指定行號，則會將數(shù)據(jù)插入對號，就會出現(xiàn)_FULL錯誤，主鍵加了小結(jié)：AUTOINCREMENT的作用是保證主鍵是嚴格單調(diào)遞增的。AUTOINCREMENT實現(xiàn)原理創(chuàng)建一個叫 _sequence的內(nèi)部表來記錄該表使用的最大的行號。如果指定使用AUTOINCREMENT來創(chuàng)建表，則 可能會修改site_sequence的內(nèi)容因為 qlite_squene表帶來的額外開銷，將會導(dǎo)致INSERT 優(yōu)化-逆向思維可好？里面紹的方法獲取到兩種情況下磁盤的讀寫數(shù)據(jù)。從中可以看出，AUTOINCREMENT會使寫磁盤次數(shù)由2次增加到11次。這也能很好說明，因為要_sequence而增加額外的IO開銷。5I/OAUTOINCREMENT的坑Q的現(xiàn)狀？于主DB。6手QSQL7Q優(yōu)化優(yōu)化優(yōu)化79Q總結(jié)以使用AUTOINCREMENT且不可，用在用該用的地方效果才更佳。網(wǎng)絡(luò)篇網(wǎng)絡(luò)篇一步推進，不妨把精力放在流量大帶來的加載體驗問題和服務(wù)器帶寬成本問題上，這樣會更容易驅(qū)動優(yōu)化。尤其是流量帶來的交互類性能問題，包括場景下帶來的交互類性能問題，例如，這時，關(guān)于流量，從需求設(shè)計開始我們需要思考壓縮，增量，不要忽略用戶，而且成功的場景都比較。另外加上讓產(chǎn)品痛的數(shù)據(jù)上報來說明問題，例如在復(fù)雜的WEBVIEW界面可以上工具集Q分業(yè)務(wù)流量統(tǒng)計實現(xiàn)用socket，有使用HTTP連接的，如果在應(yīng)用層做流量統(tǒng)計，顯然會異常復(fù)雜，手Q找到了一個巧1，流量統(tǒng)計上報模型流量數(shù)據(jù)隊流量數(shù) 是否為N發(fā)發(fā)送消息到2，實現(xiàn)細節(jié)APPLICATION進行初始化系統(tǒng)SOCKETMonitorSocketImpl對象。MonitorSketImpl：tendsSockeIml通過反實例化出統(tǒng)的SocketImplgetInputStream()和getOutpuStream方法read方法，然后把的大小保存到MonitorSocketStat中。的write方法，然后把的大小保存到MonitorSocketStat中。整體流程覆寫覆寫輪詢流量發(fā)送消息到

3，DEMO驗證 logcatFIDDLER-HTTP協(xié)議測試Fiddler是一個HTTP協(xié)議調(diào)試工具，它能夠記錄并檢查所有電腦和互聯(lián)網(wǎng)之間的HTTP通信，查看所有“進出”Fiddler的數(shù)據(jù)（指、html、js、cssPC時代，F(xiàn)iddler是前端調(diào)試和測試的利器，但是到了移動時代，F(xiàn)iddler就被歷史淘汰了嗎？答案當然是否定的。Appwebview頁面，webview的流量往往是很大的，因此發(fā)現(xiàn)其中的FIDDLER的工作原理Fiddler是在WinINetAPI和服務(wù)器之間做一個，通過定制這個的功能可以實現(xiàn)HTTP請求和前端調(diào)試的功能，這里我們主要用Fiddler來HTTP請求，從而找出其中的優(yōu)化使用 是用Fiddle作為 跟電腦在一個局域網(wǎng)內(nèi)可以用處于相同wifi下的筆記 的設(shè)置功能，打開WLAN并連到指定WiFiB，長按WiFi進入設(shè)置界面，選擇“修改網(wǎng)絡(luò)配置”C，在網(wǎng)絡(luò)修改界面將設(shè)置為手動，同時輸入主機名和服務(wù)器端口，這里的主機名為pc的IP地址，端為8888（Fiddler默認端）D，點擊后，的設(shè)置就完成FiddlerToolsFiddlerOptions…ConnectionsAllowremotecomputerstoconnect，同時也在“HTTPS”頁面通過設(shè)置是Fiddler支持HTTPS協(xié)議，完成后重新啟動Fiddler。Transfo去除GZip、DEFLATETransfo去除GZip、DEFLATEHTTP流量優(yōu)化優(yōu)化HTTP的流量主要是減少Response的大小，可以使用的方法有：緩存和壓縮緩存求時，就可以直接從緩存中資源，而不需要通過網(wǎng)絡(luò)重新。1Pragma:no-2If-Modified-3If-None-Modified，客戶端會使用緩存的response。上圖中，HTTP的請求中緩存策略就設(shè)置為Pragma:no-cache，即不使用緩存，直接去服務(wù)器拉取新的ResponseControl控制Response如何在客戶端緩存。Cache-Control可以標明Response如何以及如何使用，可以是如下選項Response可以在任何cache中，包括共享的Response將來不會被使must-和原始服務(wù)器確認Response是后，可以使用緩HTTP壓縮CSS和JS可以通過壓縮可以減少50%以上，所以對于文本資源推薦使用壓縮后傳輸。式，如下圖，該Response用的是gzip壓縮方式。另外可以使用“Transformer”Response，可以看到壓縮前后，Responsebody的大小，可以看到壓縮前184KB，通過gzip壓縮后，節(jié)省70%的流量。TCPDUMP-抓包的不二選是前提你得有對應(yīng)的流量包，如何在上抓包呢？這時tcpdump就閃亮登場了，或許你對tcpdumpUnix系統(tǒng)，它可以將網(wǎng)絡(luò)中傳送not等邏輯語句來過濾掉無用信息。其在Windows下對應(yīng)的版本成為WinDump，相信經(jīng)常在Windows上抓包的同學(xué)一定不陌生。一、準備工作要想在上抓包你得先有一部才行（這不是廢話嗎？，Android和都tcpdumpAndoid為例進行介紹，其實這里的重點是你是要有root權(quán)限?；蛟S你會說，如果我的rootAdroid是沒辦法獲取root權(quán)限的，沒關(guān)系，后面我們會介紹不需要rot權(quán)限的方法。 二、開始抓包之旅用的/data/local/tmp，完整的adb命令如下：adbpushtcpdump/data/local/tmpod777 tcpdump–w/data/local/tmp/tcp.pcap 5，把pcap拷貝到電腦上，就可以用wireshark按照我們之前介紹的方法來分析流量問題了。-c--i-r-s產(chǎn)生比vv更詳細的輸出.比如 ent時所使用的SBSE選項將會被打三、TCPDUMP高級應(yīng)用cpdum最為有用的高級用法，可以利用它來匹配一些符合規(guī)則的數(shù)據(jù)包，便于后續(xù)分析，如果tcpdump中沒有表達式，那么tcpdump會把網(wǎng)卡上的所有數(shù)據(jù)包輸出，否則會將被expression匹配的包輸出。srcdst,dstorsrcdstandsrc這些關(guān)鍵字指明了傳輸?shù)姆较颉Ｈ绻麤]有指明方向關(guān)鍵字，則缺省是srcordst關(guān)鍵字。ether、ip、arp、rarp、tcp、udp等類型。ether是匹配網(wǎng)卡，其他的幾個關(guān)鍵字就是指明了的包的協(xié)議內(nèi)容。如果沒有指定任何協(xié)議，則tcpdump將會not、!and、&&or、||，這些關(guān)鍵字可以組合起WIRESHARK-流量分析wireshark，讓你一躍成為wireshark高手。會成為你使用wireshark的門檻，因此這里不再介紹安裝步驟。 抓包是通過tcpdump實現(xiàn)的，上文已經(jīng)介紹過，這里我們 地介紹wireshark分析包的能力。過濾從上文中得知，我們在使用tcpdump抓包時，可以指定過濾條件，用來過濾指定的主機和協(xié)重任就交給wireshark了。協(xié)議過濾語法語法：Protocol.String1.String2ComparisonoperatorValueLogicalOperationsOther（string1string2是可選項http.request.methodPOSTor snmp||dns||icmp顯示SNMP或DNS或ICMP封包 ip.addrip.addr==ip.src!=orip.dst!=ip.src/16顯示來自10.230tcp.port25TCPtcp.dport=25TCPhttp.quest.method==PST"psthttphttp.host=="為httpT入”ip.”可以看到ip協(xié)議相關(guān)的過濾條件。內(nèi)容過濾語法contains：Doestheprotocol,fieldorslicecontainatcpcontainshttp"payload中包含"http"tcptcp[20:3]47:45:54/*16進制形式，tcp20payload的前三個字節(jié)進行過濾*/過濾中函數(shù)的使用（upper、upper(string-field)-convertsastringfieldtouppercaselower(string-field)-convertsastringfieldtoupper(http.request.uri)contains過濾運算符EqualNotEqualne!=GreaterThangt小于LessTanlt<

GaterthanorEquatogeLessthanorEqualtoleLogicalANDandLogicalORorLogicalNOTnotcontains""bytes，不能用于原子字段，例IP地址，matchperl規(guī)則的正則表達式，對應(yīng)協(xié)議或協(xié)議負載內(nèi)的字符使用“FOLLOWTCPSTREAM”統(tǒng)計流量統(tǒng)計的方法，下面介紹一些wireshark中常用的流量統(tǒng)計功能。1“Summary”和“CommentsSummary”顯示流量包的概要信息，包括數(shù)據(jù)包個數(shù)、數(shù)據(jù)包大小、抓包持續(xù)2，“Showaddressresolution”將IP地址解析為對應(yīng)的3，“ProtoclHierarchy”按照TCP/IP4，onv tnList”將流量包中的連接劃分不同類型連接的詳二進階篇IOIOGraphs是個強大牛的功能，可以配置出各種不同的圖例。例如：利用bytes_in_flight+IOGraphs，就可以很方便對比大家的發(fā)包策略,Server的窗口策略。如圖所示，配置filter分別為tcp.stream等于0，tcp.stream等于4，然后YAxis->Unit選擇高級，之后就會有Calc可以填寫，信則相對較少，這可以推斷，手Q的接收窗口比 大，手Q在差網(wǎng)絡(luò)下更容易遇到網(wǎng)絡(luò)擁塞，當然也有可能是服務(wù)器回復(fù)ack的速度太慢導(dǎo)致。ack_rttIOGraphQRTT的時間比RTT略高，而在這種情Wireshark分析功能：Statistics->TCPStreamGraph->Time-SequenceGraph(Stevens)。利用Time-SequenceGraph很方便可以看出發(fā)包的方式，例如手Q會同一時刻發(fā)送許多包， 一個包等ACK回復(fù)。VOIP分析,今國外比較火的聊天軟件）來舉個例子，錄制數(shù)據(jù)包TWiresharRTPT ehony->RTP,我們可以看到全部的Stream，因為存在發(fā)送和接收語音，而發(fā)送時沒有經(jīng)過網(wǎng)絡(luò)的，因此我們先關(guān)注接收，也 是圖三的數(shù)據(jù)，最大延時，最大抖動，平均抖動和丟 COMAEP利用sh，對齊兩設(shè)備時間 Echo$1sshroot@$1dateY%m%ds$nowdate”sshroot@$1“date+%T–s 的差距（從發(fā)到接到的時間差：2090.072,另外，各種異常情況也在下面可以很方便的分析。使用命令行wireshark不僅有圖形化的界面，還提供了完備令行解析方式，你可能會問：已經(jīng)有圖形化wireshark在wireshrk看分以實有有wireshark的的tshark命令行簡單的介紹，參數(shù)參考文檔。-r-r-r-RReadfil -R-z-z-z顯示HTTP請求的模式以及狀態(tài)-z務(wù)器名和-zHTTPIP地址IP地址和狀態(tài)三擴展篇-流量自動化測試方案tcpdump+tshark來進行流量自動化測試的方案盡管很方并不完美的，在有些情況下是存在問題的，比如：當在抓包時并沒有精確地過濾出待測APP的流量（做到這一點往往也是的，因為IP地址經(jīng)常改變那么統(tǒng)計出來的流量就會包括其他APP或者服務(wù)的流量，造成不com.android.defcontainer的uid是10018。B、通過dAPP使的套接字通過/proc/net/tcp和/proc/net/tcp6APP在操作過程中使用的套接字，二者分別保存IPv4IPv6的套接字信息，如下圖，uid10034的套接字信息是：IP地址A，端口tshark命令：tsharkraaa.pcapqzconv,tcp，得到如下結(jié)果，可以看到第一列就是會話的IP地址和端令行來做的自動化分析。PCAPHTP文件自動導(dǎo)出分析工具工具能力：自動導(dǎo)出Pcap中hp文 分析其中的重復(fù)資 工具原理pcaptcptcpsession。分析每一個Zip文件、gz文件：解壓其中的文件至當前 session錄的以及相應(yīng)的session信息。工具用法分析，然后通過云分析的web頁面查看結(jié)果，示例如下：Perflib在獨立工具 gemonitor_box中調(diào)用云分析wgemonitor_box是一個可以獨立運行的工具，通過命令行交互界面，獲取用戶的操作的開的url，然后展示給用戶。工具地址用法，詳見 PCAPHAR分析工具工具原理格式，基于JSON。Har目前是一種比較通用的數(shù)據(jù)格式。Har文件示例如下：{{"log":"veron":"2","creaor":{"browser":{},"pages":"entries":"comment":}}ResponseHeader等信息，然后按照規(guī)范，轉(zhuǎn)換成通用har文件。等。har文件包含以下字段：–creator[object]HARbrowser[object,可選]–]–entriesarray]–HTTPcommentstring,可選]（newin1.2）–內(nèi)容就是一個HTTP請求的相應(yīng)信息，信息格式如下："entries":{"pageref":"time":50,"response":"timngs":{"servrIPAddess":"10.0"connection":52492,"comment":""}]request、respone、timingpagerefpages字段是否是4XX、5XX，是否開啟了gzip壓縮，請求相應(yīng)時間是否超過限制等。工具用法分析，然后通過云分析的web頁面查看結(jié)果，示例如下：Perflibjb運行完后通過httpwbpagemonitorboxwgemonitor_box是一個可以獨立運行的工具，通過命令行交互界面，獲取用戶的操作的開始點以及結(jié)束點，并抓取相應(yīng)的包Pcap包，然后提交云分析（調(diào)用接口的sdk使用的是Perflib中的，云分析結(jié)束后，打開分析結(jié)果的url，然后展示給用戶。工具地址用法，詳見 案例：數(shù)據(jù)上報與流量的取舍數(shù)據(jù)上報是指應(yīng)用程序用戶的某一行為的數(shù)據(jù)，并將統(tǒng)計數(shù)據(jù)上傳到后端服務(wù)器的過程。上報驗。數(shù)據(jù)上報對有志于提升用戶體驗的公司而言是經(jīng)常使用的一種，對于騰訊這種追求用戶體APP是耗費流量最多的，他肯定會以APP才導(dǎo)致還沒到月末就沒流量用了，又要他浪費銀子去加流量了，久而久之，這會嚴重損害應(yīng)用的體驗和口碑。所以，對于移動端的APP來說，絕對不能數(shù)據(jù)上報，在每次使用手Q這樣的超級APP使用的數(shù)據(jù)上報也是多如牛毛，我們也盡量保證對每次上報的數(shù)據(jù)在頻率報告，這樣可以及時發(fā)現(xiàn)問題手Q的質(zhì)量。13KB左右，這里面可能就有問題了，于是就開始對該用例生成的pcap包和日志進行分析。11.5222.2612.0212.0912.0514.0912.7312.7214.0512.02，數(shù)據(jù)，是導(dǎo)致流量上升的主要原因，下面就把第6次的pcap包和日志拿出來進行分析。2wireshark分析pcapTCP12pcap包中有完整的建立和結(jié)束過程（TCP建立連接的三次”握手”和結(jié)束連接的三次“揮手3沒有連接建立和結(jié)束的過程，即連接3在抓包之前就已經(jīng)建立的。通過對連接1的IP地址分析，確認該IP指向的 upload.zip上（導(dǎo)出HTTP請求內(nèi)容方法上文已講過，和開發(fā)確認該連接為燈塔上報。2TCP數(shù)據(jù)包的傳輸音令字）報（連接1）和語音發(fā)送沒關(guān)系，燈塔上報可能是流量存在異常的一個原因。1pcap分析第3-9次pcap包，統(tǒng)計以上三個連接耗費的流量語音發(fā)送發(fā)304050670890100平均7308689811自動化數(shù)據(jù)燈塔上報次數(shù)（次數(shù)1232燈塔上報導(dǎo)致流量增 msf的流量是 7月308月68月98月11ptt發(fā)送流 7月308月68月98月11msf手Q的每次燈塔上報都會有l(wèi)ogcat日志輸出，對應(yīng)的關(guān)鍵字是RQD，通過查找日志，最終發(fā)現(xiàn)發(fā)送狀態(tài)上報是為了上報該次語音是否發(fā)送成功，這為了保證語音發(fā)送的成功率，可以及時發(fā)現(xiàn)網(wǎng)絡(luò)中出現(xiàn)的各種問題這個上報對實時性要求比較高，因此實時上報時必的。語音質(zhì)量上報是為了掌握每次語音的發(fā)送質(zhì)量，進而在語音質(zhì)量方面提高用戶體驗，該上IMEI、版本號等大量的重復(fù)，如果用戶每WEBVIEW緩存使用的坑策略，緩存的資源會在/data/data/packagedatabasecache兩個文件夾，但是理想是費。當我們在打開手Q的大表情頁面時，就抓到了開發(fā)類似的罪行，下面就看看我們是如何抓到2wiresharkpcap文件，統(tǒng)計整個過程消耗的流量，wireshark統(tǒng)計流量的方法有多面使用的流量為1.19M，手Q的“大表情”頁面為webview頁面，包含了大量的和文本信息，webview頁面沒有使用緩存，從而導(dǎo)致再次進入該頁面時，資源通過網(wǎng)絡(luò)又被重新方法1，查看磁盤 Android的weveiw的緩存策略會在/datadata/應(yīng)用package下生成dabase與cache兩個文件夾，database可以存放多個數(shù)據(jù)庫文件，數(shù)據(jù)庫中保存的是請求的url（手Q大表情”頁面的緩存的url保存在webviwCooksChromiumrivatd 中，database中的數(shù)據(jù)庫文件可以用Anroid的SDK 3.ee打開下圖就是ebviewookiesCh db中的內(nèi)容可以清晰地看到大表從導(dǎo)出的f_000089文件可以更直觀地看出，大表情資源已在本地保存。cache文件 2fiddlerFiddler是一個http協(xié)議調(diào)試工具，它能夠記錄并檢查電腦和互聯(lián)網(wǎng)之間的http通訊，現(xiàn)在也可以用它來捕獲上的http請求（操作步驟后文會介紹下圖為fiddler的操作界面，左邊為的HTTP請求的列表，右邊為指定HTTP請求的詳細信息，包括時間統(tǒng)計、請求內(nèi)容等信息，這fiddlerB，點擊“Caching”，如下圖，可以得到該HTTP請求的頭部中的Cache-Control為max- 秒，對應(yīng)的是365天，從下面的解釋可以得出，該資源的有效期為HTTPCache-Control進行簡單的介紹，HTTPRequestCache-Control可以為no-cache、no-store、max-age、max-stale、min-fresh、no-transform、only-if-cached以及cache-extension，HTTPResponseCache-Controlpublic、private、no-cache、no-transform、must-響應(yīng)和其對應(yīng)的請求都不使用cache方法三：使用HARPageSpeedHARViewer中點擊某cache-control為秒。cache中加載cache遍，這涉及到客戶端發(fā)送HTTP請求時的緩存模式，客戶端可以指定五種緩存模式，分別如下： LOAD_CACHE_NORMALAPIlevel17中已經(jīng)廢棄,APIlevel11LOAD_DEFAULTLOAD_NO_CACHE:不使用緩存，只從網(wǎng)絡(luò)獲取數(shù)據(jù)所以開發(fā)在這里就把緩存策略設(shè)置為LOAD_NO_CACHE，即所有的數(shù)據(jù)都只從網(wǎng)絡(luò)上獲取。最后，開發(fā)通過對不同進程的緩存做了（這也是為什么手Q的databases下有多個dbcache-control決定是否從網(wǎng)絡(luò)上取數(shù)據(jù)，從而很好地解決了該問題，當前的代碼如下：if(!enableCache){}案例：離線包重 載案發(fā)現(xiàn)過程以及影響pcap中的http文件比較md5值，發(fā)現(xiàn)部落的離線包存在重復(fù)的情況。同時通過觀察大盤數(shù)據(jù)發(fā)現(xiàn)，每天資源使用量（直接線上資源）每天增加1百萬～2百萬，而離線資源使用量（使用離線包）每天減少1百萬～2百萬；：離線比從3:7變成了5:5，而且比例仍然在變問題定位以及解決方案手Q的離線包功能使用的是應(yīng)用寶提供的一個jar包，這個jar包在離線包的時候會針對下載的url進行去重，不會針對同一個url多次，可以保證上層調(diào)用一次，只一次。了。經(jīng)過排查發(fā)現(xiàn)上層確實調(diào)用了jar包進行了多次，但是為什么會多次調(diào)用？載用的jar于古老，不支持gzip解壓，導(dǎo)致離線包無法使用。最終耗費了用戶的流量，同時因案例：使用壓縮策略優(yōu)化資源流量Appwebw1Q打開這個頁面是都會拉取大量的文本資源這些資源能壓縮（資源也可以壓縮，是可現(xiàn)場，有點像掃黃時使用的機，然后逐個webview界面都打開一下（也可以使用monkey配合獲取了我們的pcap文件。下面我們使用了兩個方法來定位問題：方法一：使用1Webview:androidweb2TcpdumpB 了足足503KB，這帶來的效益是非常明顯的。方法二：使用A，打開/，如下HAR”，即可保存對應(yīng)的HAR文件A，打開http: /flint/index.php，這個可以為HAR文件生成對應(yīng)的PageSpeed分數(shù)，如下除了文本可以壓縮，當然也可以壓縮。之前在手Q，我們就遇到過這個情況，使用tcpdump錄制登錄和登錄后5分鐘，使用剛剛提到的“方法一”，發(fā)現(xiàn)將近1M的流量，其中800多KB為PNG，而且大多數(shù)是沒有alpha通道的。這時，使用jpeg壓縮的優(yōu)化效果是非常顯著的，當時優(yōu)化近30%的流量。顯示。這時可以配合pyon獲取文件的類型描述來更正的擴展名。importimportima=Image.opn(path)ifima.format==Q發(fā)圖速度優(yōu)化1，背景對于即時通信的APP來說，發(fā)送是最基礎(chǔ)的功能，發(fā)送的快慢直接影響到用戶體驗，手Q為了提高的發(fā)送速度，和進行了發(fā)圖速度的對比，不比不知道，一比才知道和之測試場景為：使用100KB的分別在3G網(wǎng)絡(luò)和WiFi下，對二者進行發(fā)圖速度的對比，測試 的耗時的3.5 的耗時的1.07 2，原因分析我們可以把的傳輸過程分為三部分，分別是客戶端、傳輸鏈路以及服務(wù)器。傳輸鏈路對于我們來說是無法控制的我們只能從客戶端和服務(wù)器來著優(yōu)化客戶端客戶端有兩個點可能影響到發(fā)圖速度，（1）SendBuffer的大小，（2）戶態(tài)向內(nèi)核傳輸數(shù)據(jù)的wiresark的OGraph功能TCP ysisbytesinflight的關(guān)系，如下圖所示window_sizebytes_in_flight滑動窗口說明接收端允許發(fā)送端發(fā)送的數(shù)據(jù)的大小，bytes_in_flight表示鏈路中確認的字節(jié)和服務(wù)器的處理能力，提高的發(fā)送速度。應(yīng)用層在傳輸時，會將分成小片，調(diào)用send方法向內(nèi)核傳送分片，這里分片的8KB32KB，可以有效提高客戶端的數(shù)據(jù)傳輸速率，調(diào)整后的window_size和bytes_in_flightwindow_sizebytes_in_flight非常接近，說明客戶端已經(jīng)充服務(wù)器我們知道服務(wù)器的RcvBuffer決定著滑動窗口的大小，因此可以增大RcvBffer來增加滑動窗口 RcvBuffer由3MS最大報文段）調(diào)整到10MSS，通過wireshark的Time-SequenceGraph可以看出，RcvBffer調(diào)整1MSS圖13MSSTime-Sequence 圖210MSSTime-Sequence3優(yōu)化驗證在完成以上優(yōu)化后，又對手Q和 進行了發(fā)送速度的競品對比，如下圖所示，可以看出手Q的發(fā)圖速率在WiFi環(huán)境下優(yōu)于 發(fā)圖速率(KB/秒手Q在弱網(wǎng)下PTT重復(fù)發(fā)送移動網(wǎng)絡(luò)錯綜復(fù)雜，WiFi和G移動網(wǎng)絡(luò)錯綜復(fù)雜，WiFi和G目前手Q遇到了這樣的場景，用同樣的發(fā)送PTT，手Q流量耗費是 么原因造成如此大的差距，下面就讓我們一步一步地揭開的面紗。2案例分析2.1在3G網(wǎng)絡(luò)下，用nexus5對比手Q和 發(fā)送20秒PTT的流量耗費，從看出，手Q流量為41KB，是 的將近2倍。場倍2.2結(jié)果分析1，從手Q日志看，原來nexus5在3G網(wǎng)絡(luò)下，連接非常不穩(wěn)定，PTT發(fā)送過程中出現(xiàn)連接中斷，同時證實，在發(fā)送PTTQ的流量是的1Qlogcat數(shù)據(jù)。手Q在重連后，繼續(xù)將剩余的8~18分片傳完，后因在斷網(wǎng)期間4-7個分片丟失，服務(wù)器要求圖2服務(wù)器日原來手Q的PTT采用的是流式傳輸，即一邊，一邊進行傳輸，這樣文件的傳輸過程采用的Q的傳輸協(xié)議在弱網(wǎng)下，針對重傳機制設(shè)計的并不完善，導(dǎo)致在出現(xiàn)丟包的情況下，需要重傳從丟失分片到當前文件的最后一個分片，造成了大量不必要的重2.3問題從上文得知，手Q的PTT發(fā)送采用的是流式傳輸，即邊邊發(fā)送，那么如果出現(xiàn)分片丟失，按照傳輸協(xié)議的邏輯，客戶端需要傳輸從丟失分片到當前文件的最后一個分片。舉例說明，如果當前到第8分片，這時服務(wù)器告訴客戶端第4分片丟失，那么客戶端只需傳從丟失分片到結(jié)束，要注意，這里是結(jié)束而不是當前的文件，為什么會這樣呢？當前分片去掉。這樣就導(dǎo)致如果沒有結(jié)束的話，除了當前正在錄制的分片，仍會少傳輸一個分的分片，依次循環(huán)下去，一直到結(jié)束。造成的結(jié)果是：不管有沒有結(jié)束，重傳都會持續(xù)到2.4結(jié)論任何一個疏忽都有可能為用戶造成損失網(wǎng)絡(luò)軍規(guī)WIFIAPP20KB接收富消耗<60K(富包括：，表情，語音，文件電池篇電池篇原理篇電功率。在電壓恒定的前提下，我們只需要測量電流和時間就可以確定耗電。非充電狀態(tài)下，的電能都是來自的電池。不妨從每臺都會有power_profile.xml開始著手。PowerProfile，在廠家出ROM的時候，android是建議廠商通過下面介紹的PowerMonitor之類的工具來測試每個硬件模塊的耗電情還有其實不屬于硬件模塊的和音頻的耗電。下面我們來逐個介紹幾個重要的硬件模塊。硬件模塊耗電分析TAndroid包含TAndroid包含AP和BP兩個CPU，AP即Application 所有的用戶界面以及app都是行在ap上的BP即asebandPrcesso 射頻都是運行在這個CPU上的而一般我們說的耗電，PowerProfile里面的CPU，其實是AP。CPUBP5mA左右，但是因為喚醒，CPU（AP）就會運作，不同情況不一樣，至少會導(dǎo)致20～30mA左右的耗電。另參考：Active就是開機之等sensor也會關(guān)閉，但這時系統(tǒng)其實依舊在運行狀態(tài)。PowerManagerServer就會寫“on”到/sys/power/state來執(zhí)行l(wèi)ateresume的設(shè)Suspend：當系統(tǒng)剛進入EarlySuspend，而且wakelock已經(jīng)都release了之而所謂喚醒就是讓系統(tǒng)從S pen到Resmework或者Ac 或者是從arlyuspend到Active。怎樣做到呢？主要靠alrmmanger和waklck做到。這里只介紹幾個重點，AlarmManagerRTCELAPSED兩種鬧鐘，前者是絕對時間，后者是相對時間，請不要搞是等到被其他原因喚醒了，他才觸發(fā)鬧鐘。用的WakeLock還有一大堆。例如你應(yīng)用間接調(diào)用mediaserver音樂的時候，也會起使用才能確保WIFI不會休眠。 /reference/android/app/AlarmManager.html另外一種耗電的情況就是CPU本身的高負荷。雖然大部分的POWER_PROFILE都不靠譜，但是我們姑且相信大廠的，如三星的。觀察這些PowerProfile會發(fā)現(xiàn)一個規(guī)律，耗電在頻率的時候，耗電會更加被放大。例如下圖GT-i7100，CPU頻率800是400的兩倍，對應(yīng)的耗電是1.5倍，但是電的一個主要原因，而不是簡單的CPU運作就會很耗電。。。display按屏幕的材質(zhì)分類，目前智能主流的屏幕可分為兩大類，：一種是LCD（LiquidCrystalDisplay的簡稱OLED（OrganicLight-EmittingDiode的簡稱）即有機發(fā)系列屏幕則隸屬OLED的范疇。其它的IPS、ASV、NOVA等并非屏幕材質(zhì)，把它們稱為屏幕顯示技LCD屏幕本身是不發(fā)光的，白色光線由其背后的燈管發(fā)出，屏幕，照射到我們的眼睛，所以我們能夠看OLED屏幕的顯示機制與LCD不同，其屏幕的每一個像素是可以獨立發(fā)光的。當顯示全黑時，所有的像素都不發(fā)光，其效果相當于關(guān)屏（近似于LCD屏幕，且功耗更低。3G4G，WIFI，2G也會有類似的狀態(tài)機概念。所以真正

C我們使用安卓SDK的C我們使用安卓SDK的API的reqetLocaonUpdate方法控制GPS的狀態(tài)切換使用射 儀 的active狀態(tài)；搜到很少 的active狀GPS耗電與應(yīng)用調(diào)用（requestLocationUpdate）更新GPS頻率無關(guān)工具集下面介紹一系列的工具。實際上對于大部分的低級錯誤，這些工具都可以查出來。但是我們到現(xiàn)在位置，大部分的耗電成因還是產(chǎn)品需求，因此非常重要，而POWERMONITOR就是的工具，可以估算出的待機時間，并給予產(chǎn)品經(jīng)理決策。 M移動設(shè)備工具TREPNPROFILER(以下簡稱TP)TP工作原理（如DS2780、MAX17048等）直接獲取電流數(shù)據(jù)，可以理解成SnapDragon800+系列專門在如每個cpu、數(shù)字、電量等處buildin了多個sensors，當開始運行trepnprofiler時sensor說到這里有必要簡單介紹下flugC 即電量計 ，因為 需要確定電池的可用電以及充電狀態(tài)(SO，主要是根據(jù)剩余電量與電池容量的比來確定的，而 電池經(jīng)過多次充放電導(dǎo)致電池容量變化，以及電壓與電量之間不存在明確的關(guān)系。所以為了達到足夠高的電量計量精度，引入了fulue，下圖是現(xiàn)在使用比較廣泛的 S2786（/en/app-notes/index.mvp/id/4224不過也基于依賴fuelgaugeIC獲取數(shù)據(jù)的原因，電池類型不同肯定不同，不同也有可能不同，所以某些設(shè)備的數(shù)據(jù)并確，如已知以下幾款（發(fā)現(xiàn)木有都是三星啊...SamsungGalaxySIII(SCH-SamsungGalaxyS4(SCH-SamsungGalaxySamsungGalaxyNoteSamsungGalaxyNote3(SM-DragonBoard(allInforceIFC6410 m測試確認數(shù)據(jù)無誤的/ASUSNexusLGNexusLGNexusHTCOneSonyXperiaHTCDroidLGOptimusG軟件用法ECLIPSE插件大家提到的一些問題，這次專門介紹一下這個TP的插件，讓TP的使用更加得心應(yīng)手。（TrepnPlug-inforEclipseGettingStarted）首先，安裝TP插件需要：EclipsewiththeADTADBv1.0.31EclipseJuno setting100ms，以及下面數(shù)據(jù)完后用來過濾視圖的，所以需要哪些數(shù)據(jù)，需要在這里設(shè)置，而非control面板上確認。之后就開始操作，完成之后點擊停止，數(shù)據(jù)會自動記錄到PC上，點打開文件的 是要停止之后才會傳到PC，這時才能在charts里看到數(shù)據(jù)，所以開始后看不到數(shù)據(jù)不要驚慌。從官網(wǎng)安裝（安裝eclipse插件后，使用時也會自動在上安裝 /mobile-development/increase-app-performance/trepn-A、右上角的在設(shè)置頁面DATAPOINTS頁面可以選 CPU，內(nèi)存，GPS，屏幕等 的appC、選擇Grap查看 的結(jié)果，StpPrflin停止 缺點 連接到PC之后處于充電狀態(tài)，所以DEVELOPERTOOLSFORBATTERY版的android提供了一個工具，用于獲取耗電量，adbs dumpsysbatterystats，這個工具可以獲取各個app的wakelock、CPU時間占用等信息，同是增加了一個Estimatedpoweruse(mAh)功$adb$adbdumpsys Batterystats(batterystats)dump[--checkin][--history][--history-start][--unplugged][--charged][-c][--reset][--write][-h][<>]--checkin:formatoutputforacheckin--history:showonlyhistory--history-start<num>:showonlyhistorydatastartingatgiventime--unplugged:onlyoutputdatasincelast--charg