計(jì)算性能優(yōu)化參考
- 低效率函數(shù)
第1種是相對(duì)執(zhí)行時(shí)間長(zhǎng)的方法专肪，我們可以很輕松的找到這些方法并做一定的優(yōu)化根盒。第2種是執(zhí)行時(shí)間短，但是執(zhí)行頻次很高的方法，因?yàn)閳?zhí)行次數(shù)多饲宛，累積效應(yīng)下就會(huì)對(duì)性能產(chǎn)生很大的影響
- 計(jì)算性能優(yōu)化
(1). 批處理與緩存
(2). 異步操作
(3). 容器性能
(4). 數(shù)據(jù)結(jié)構(gòu)
電量?jī)?yōu)化
- 電量消耗分析：
Battery Historian(電量使用記錄分析工具)
- 電量?jī)?yōu)化的一些建議：
- 充電時(shí)執(zhí)行任務(wù)
- 連接wifi后執(zhí)行任務(wù)
- wake_lock
- 大量高頻次的CPU喚醒及操作集中處理
- 定位
- 網(wǎng)絡(luò)優(yōu)化
網(wǎng)絡(luò)優(yōu)化
- 網(wǎng)絡(luò)分析工具
Network Monitor(網(wǎng)絡(luò)監(jiān)控工具)
代理工具（Fiddler）,分析網(wǎng)絡(luò)請(qǐng)求
模擬弱網(wǎng)（使用Fiddler）
- 網(wǎng)絡(luò)優(yōu)化方案
（一）任務(wù)集中處理（使用JobScheduler）
（二）傳輸數(shù)據(jù)優(yōu)化
- gzip壓縮
static class GzipRequestInterceptor implements Interceptor {
@Override
public Response intercept(Chain chain) throws IOException {
okhttp3.Request originalRequest = chain.request();
if (originalRequest.body() == null || originalRequest.header("Content-Encoding") != null) {
return chain.proceed(originalRequest);
}
okhttp3.Request compressedRequest = originalRequest.newBuilder()
.header("Content-Encoding", "gzip")
.method(originalRequest.method(), gzip(originalRequest.body()))
.build();
return chain.proceed(compressedRequest);
}
private RequestBody gzip(final okhttp3.RequestBody body) {
return new RequestBody() {
@Override
public MediaType contentType() {
return body.contentType();
}
@Override
public long contentLength() {
return -1; // 無(wú)法知道壓縮后的數(shù)據(jù)大小
}
@Override
public void writeTo(BufferedSink sink) throws IOException {
BufferedSink gzipSink = Okio.buffer(new GzipSink(sink));
body.writeTo(gzipSink);
gzipSink.close();
}
};
}
}
> > 2. 代替JSON（使用Protocal Buffers，Nano-Proto-Buffers择份，F(xiàn)latBuffer來(lái)減小序列化的數(shù)據(jù)的大小
）
- 緩存
- 圖片壓縮
(三)不同網(wǎng)絡(luò)狀況蘸嘶，處理不同的任務(wù)
(四)弱網(wǎng)情況下我們應(yīng)該做些什么？
(1).壓縮/減少數(shù)據(jù)傳輸量
(2).利用緩存減少網(wǎng)絡(luò)傳輸
(3).針對(duì)弱網(wǎng)(移動(dòng)網(wǎng)絡(luò)), 不自動(dòng)加載圖片
(4).界面先反饋, 請(qǐng)求延遲提交****
數(shù)據(jù)傳輸優(yōu)化
序列化计雌、反序列化傳輸
- Parcelable相對(duì)于Serializable效率要高
- GSON處理序列化問(wèn)題悄晃，速度更快
可優(yōu)化的數(shù)據(jù)序列化方案：
Protocal Buffers：強(qiáng)大，靈活凿滤，但是對(duì)內(nèi)存的消耗會(huì)比較大妈橄，并不是移動(dòng)終端上的最佳選擇。
Nano-Proto-Buffers：基于Protocal翁脆，為移動(dòng)終端做了特殊的優(yōu)化眷蚓，代碼執(zhí)行效率更高，內(nèi)存使用效率更佳反番。
FlatBuffers：這個(gè)開(kāi)源庫(kù)最開(kāi)始是由Google研發(fā)的沙热，專(zhuān)注于提供更優(yōu)秀的性能。
啟動(dòng)優(yōu)化
- APP的啟動(dòng)方式：
(1). 冷啟動(dòng)（應(yīng)用從桌面上啟動(dòng)罢缸，且后臺(tái)沒(méi)有進(jìn)程的緩存篙贸，這是系統(tǒng)就需要新創(chuàng)建一個(gè)進(jìn)程并且分配資源。）
(2). 熱啟動(dòng) （app在后臺(tái)有進(jìn)程緩存）
- 查看啟動(dòng)過(guò)程消耗時(shí)間的工具
- Loacat輸出的display time
- Traceview
- adb shell
- 啟動(dòng)優(yōu)化方案
流程中很多步驟是系統(tǒng)控制的枫疆，我們能夠控制的和關(guān)注的點(diǎn)有以下幾個(gè)：
(1).Application的onCreate,一般應(yīng)用中通用主件和初始化都放在這里(耗時(shí)主因)
(2).Activity的onCreate爵川，UI布局和渲染(耗時(shí)主因)
(3).顯示啟動(dòng)窗口到窗口替換之間，會(huì)出現(xiàn)白屏的過(guò)度畫(huà)面养铸，體驗(yàn)太差（視主題而定雁芙，必須優(yōu)化）
**(1).Application中初始化優(yōu)化的方案有兩種**
- 不需要立刻初始化的，延遲加載
- 需要初始化的钞螟，開(kāi)啟線(xiàn)程初始化
**(2).Activity的onCreate中優(yōu)化**
- 優(yōu)化布局耗時(shí)：一個(gè)布局層級(jí)越深兔甘，里面包含需要加載的元素越多，就會(huì)耗費(fèi)更多的初始化時(shí)間鳞滨。關(guān)于布局性能的優(yōu)化洞焙，在渲染優(yōu)化的文章中已經(jīng)講過(guò)。
- 異步延遲加載：一開(kāi)始只初始化最需要的布局，異步加載圖片澡匪，非立即需要的組件可以做延遲加載熔任。
- 預(yù)加載：在前一個(gè)顯示時(shí)預(yù)加載下一個(gè)顯示頁(yè)面中需要用到的數(shù)據(jù)（常常用到Spalsh調(diào)整主頁(yè)面時(shí)使用）
包體優(yōu)化
- 清理無(wú)用資源
(1).使用Refactor->Remove unused Resource
(2).使用Lint工具
(3).開(kāi)啟shrinkResources去除無(wú)用資源
(4).刪除無(wú)用的語(yǔ)言資源
(5).清理第三方庫(kù)中冗余代碼
- 圖片資源優(yōu)化
(1)使用壓縮過(guò)的圖片
(2)只用一套圖片
(3)使用不帶alpha值的jpg圖片
（4）使用tinypng有損壓縮
（5）使用webp格式
（6）使用svg
（7）使用shape
（8）使用著色方案
（9）對(duì)打包后的圖片進(jìn)行壓縮
- 資源動(dòng)態(tài)加載
（1）在線(xiàn)化素材庫(kù)
（2）動(dòng)態(tài)加載皮膚
（3）插件化
-
lib庫(kù)優(yōu)化
只提供對(duì)主流架構(gòu)的支持，比如arm唁情，對(duì)于mips和x86架構(gòu)可以考慮不支 持疑苔，這樣可以大大減小APK的體積.
-
7zip壓縮資源
對(duì)于assets或者raw文件夾中的資源，可以使用7zip壓縮甸鸟，使用時(shí)進(jìn)行解壓惦费。
代碼混淆
資源混淆
資源混淆簡(jiǎn)單來(lái)說(shuō)希望實(shí)現(xiàn)將res/drawable/icon,png變成res/drawable/a.png,或我們甚至可以將文件路徑也同時(shí)混淆，改成r/s/a.png抢韭。
建議使用微信的AndResGuard
- 使用微信AndResGuard
- Facebook的redex優(yōu)化字節(jié)碼
