App的打磨之路(上)

標籤：

前言：

俗話說磨刀不誤砍柴工，一個優秀的產品從一個不錯的點子直到使用者的手中，是需要一個團隊不遺餘力協同合作不斷打磨出來的；同樣，一個好的App除正常的代碼編寫外，還需要經過其他方面的不斷打磨才能正式互動，最終到達使用者的手中。該文主要講述一個應用除開發外還需要進行哪些工作才能合格互動，在此拋磚引玉，希望對有需要的朋友一點啟示！
該文由於內容較多故分為三篇博文來描述，主要內容包含：單元測試、效能分析、簽名、混淆、APK瘦身、反編譯、打包及加固，下文主要描述前面三個：單元測試、效能分析及簽名。

一、單元測試

單元測試是編寫測試代碼，用來檢測特定的、明確的、細顆粒的功能。單元測試不僅僅用來保證當前代碼的正確性，更重要的是用來保證代碼修複、改進或重構之後的正確性。對於想打造優秀產品的碼農來說是必不可少的，雖然在大部分公司實現有居多困難。
一般來說，單元測試任務主要包括以下幾個方面：
1. 介面功能測試
主要用來保證介面功能的正確性。
2. 資料結構測試
主要用來保證介面中的資料結構的正確性，比如變數有無初始值，是否溢出等。
3. 邊界條件測試
邊界條件判定是單元測試中最常用的，在開發中也是最容易遇到的BUG，邊界條件判定的類型主要有以下幾種情形：
- 變數是對象：如對象是否為NULL等；
- 變數是數值：數值邊界：最小值、最大值、無窮小、無窮大，溢出邊界：最小值-1、最大值+1，臨近邊界：最小值+1、最大值-1；
- 變數是字串：字串是否為空白，字串的長度進行數值變數的判定；
- 變數是集合：集合是否為空白，集合的大小進行數值變數的判定；
4. 獨立執行通路測試
主要保證代碼的覆蓋率，如語句覆蓋：保證每一條語句都執行到，分支覆蓋：保證每一個分支都執行到，條件覆蓋：保證每一個條件都覆蓋到true和false的情形，路徑覆蓋：保證每一個路徑都執行到；
5. 異常處理通路測試
主要保證所有的異常都經過測試。

JUnit是Java單元測試架構，已經在Android Studio中預設依賴。目前主流的有JUnit3和JUnit4。JUnit3中，測試案例需要繼承TestCase類。JUnit4中，測試案例無需繼承TestCase類，只需要使用@Test等註解。以下通過一個執行個體來更好的展示單元測試過程：
先在應用下建立一個計算工具類，方便寫單元測試：

package com.vise.note.util;/** * 計算相關工具類 * Created by xyy on 16/6/25. */public class CalculatorUtil {    public double plus(double a, double b){        return a + b;    }    public double minus(double a, double b){        return a - b;    }    public double multiply(double a, double b){        return a * b;    }    public double divide(double a, double b) throws Exception {        if(b == 0){            throw new Exception("除數不能為零！");        }        return a / b;    }}

Android Studio提供了一個快速建立測試類別的方法，只需在編輯器內右鍵點擊CalculatorTest類的聲明，選擇Go to > Test，然後點擊”Create a new test…”，到此會彈出兩個選項，一個是androidTest，一個是test目錄下，由於該測試不需要用到模擬器，可以運行在本地電腦Java虛擬機器上，所以此處選擇test目錄下，隨後在test與應用同包的目錄下產生CalculatorUtilTest.java檔案，內容如下（方法內部實現是手動添加的）：

package com.vise.note.util;import org.junit.After;import org.junit.Before;import org.junit.Test;import static org.junit.Assert.*;/** * Created by xyy on 16/6/25. */public class CalculatorUtilTest {    private CalculatorUtil calculatorUtil;    @Before    public void setUp() throws Exception {        calculatorUtil = new CalculatorUtil();    }    @After    public void tearDown() throws Exception {        calculatorUtil = null;    }    @Test    public void testPlus() throws Exception {        assertEquals(6d, calculatorUtil.plus(1d, 5d), 0);    }    @Test    public void testMinus() throws Exception {        assertEquals(-4d, calculatorUtil.minus(1d, 5d), 0);    }    @Test    public void testMultiply() throws Exception {        assertEquals(5d, calculatorUtil.multiply(1d, 5d), 0);    }    @Test    public void testDivide() throws Exception {        assertEquals(0.2d, calculatorUtil.divide(1d, 5d), 0);    }}

最後就可以直接選擇CalculatorUtilTest直接運行了。到此，單元測試就告一段落了，下面是講述效能分析，這個也很重要哦！^_^

二、效能分析1、Memory Monitor

在Android Studio中運行項目後，點擊Android Monitor中的Monitor就可以看到如所示的Memory使用及CPU運行情況：

下面還可以查看GPU和Network的相關情況，其中NetWork的頻繁使用是造成應用耗電的關鍵，70%左右的電量是被上報資料，檢查位置資訊，定時檢索後台廣告資訊所使用掉的，如何平衡之間的使用也是很重要的。

2、Heap Snapshot

依據上面Memory Monitor描述，找到Memory中第三個表徵圖“Dump Java Heap”，每次點擊之後會產生一個.hprof的檔案，點擊一個.hprof檔案，查看右側的Analyzer Tasks,能看到兩個選項，一個是‘Detect Leaeked Activites’，另一個是’Find Duplicate Strings’，點擊右上方的綠色播放按鈕，會自動分析heap dump去定位泄露的activity和重複的string，出現如下的Analysis Results：


從上面兩幅圖中可以看出，第一個選項表示查看的資訊可以有三種類型:App heap/Image heap/Zygote heap.分別代表App堆記憶體資訊，圖片堆記憶體資訊，Zygote進程的堆記憶體資訊。還有一個選項可以選擇Class List View和Package Tree View兩種視圖展示方式。

各屬性中英文對照表

名稱	意義
Total Count	記憶體中該類的對象個數
Heap Count	堆記憶體中該類的對象個數
Sizeof	物理大小
Depth	深度
Shallow size	對象本身佔有記憶體大小
Retained Size	釋放該對象後，節省的記憶體大小
Dominating Size	管轄的記憶體大小

3、LeakCanary

• 使用方法
  在 build.gradle 中加入引用，不同的編譯使用不同的引用：

dependencies {   debugCompile ‘com.squareup.leakcanary:leakcanary-android:1.3‘   releaseCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.3‘}

在 Application 中：

public class ExampleApplication extends Application {  @Override public void onCreate() {    super.onCreate();    LeakCanary.install(this);  }}

應用運行起來後，LeakCanary會自動去分析當前的記憶體狀態，如果檢測到泄漏會發送到通知欄，點擊通知欄就可以跳轉到具體的泄漏分析頁面。

• 工作機制
  1、RefWatcher.watch() 建立一個 KeyedWeakReference 到要被監控的對象。
  2、然後在後台線程檢查引用是否被清除，如果沒有，調用GC。
  3、如果引用還是未被清除，把 heap 記憶體 dump 到 APP 對應的檔案系統中的一個 .hprof 檔案中。
  4、在另外一個進程中的 HeapAnalyzerService 有一個 HeapAnalyzer 使用HAHA 解析這個檔案。
  5、得益於唯一的 reference key, HeapAnalyzer 找到 KeyedWeakReference，定位記憶體泄露。
  6、HeapAnalyzer 計算 到 GC roots 的最短強引用路徑，並確定是否是泄露。如果是的話，建立導致泄露的引用鏈。
  7、引用鏈傳遞到 APP 進程中的 DisplayLeakService， 並以通知的形式展示出來。
  更多關於LeakCanary的使用介紹請參考：LeakCanary 中文使用說明

註：以上都是針對Android Studio IDE的效能分析方式。

三、簽名

簽名的前提得有簽名檔案，產生簽名檔案的方式大同小異，IDE基本都有這個功能，這裡以Android Studio為列講述產生簽名檔案的過程。選擇工具列Build->Generate Signed APK,開啟後選擇對應的module，點擊next，：

點擊Create new，進入如下介面：

資訊注釋Key store path:簽名檔案路徑Password:簽名庫密碼Confirm:確認簽名庫密碼Alias:別名Password:該別名下籤名密碼Confirm:確認該別名下籤名密碼Validity:認證年限First and Last Name:你的全名Organizational Unit:組織單位Organization:組織City or Locality:城市或地區State or Province:川或省Country Code:國家代碼

按照指示填寫對應資訊，點擊OK就產生了簽名檔案。
還一種方式是使用命令的方式建立，進入Java的bin目錄下，如我的Java目錄為：/Library/Java/Home/bin，通過keytool工具來建立keystore庫，輸入以下命令：

keytool -genkeypair -alias - xyy.keystore -keyalg RSA -validity 100 -keystore xyy.keystore

命令說明如下：-genkeypair：指定產生數字證實-alias：指定產生數位憑證的別名-keyalg：指定產生數位憑證的演算法  這裡如RSA演算法-validity：指定產生數位憑證的有效期間-keystore ：指定產生數位憑證的儲存路徑（這裡預設在keytool目錄下）

再按照提示一步步輸入對應的資訊，最後就產生了一個名為xyy.keystore的簽名檔案。
有了簽名檔案後，將簽名檔案放到對應需要簽名的工程目錄module下，再在module對應的build檔案中添加如下籤名資訊(簽名資訊對應輸入自己設定的秘鑰資訊)：

android{    ...    signingConfigs {        debug {            storeFile file("xyy.keystore")            storePassword "xyy"            keyAlias "Note"            keyPassword "xyy"        }        release {            storeFile file("xyy.keystore")            storePassword "xyy"            keyAlias "Note"            keyPassword "xyy"        }    }    buildTypes {        debug {            minifyEnabled false            zipAlignEnabled true            shrinkResources false            signingConfig signingConfigs.debug        }        release {            //是否混淆（註：如果混淆檔案未配置使用false）            minifyEnabled false            //是否支援Zip Align            zipAlignEnabled true            //是否清理無用資源            shrinkResources true            proguardFiles getDefaultProguardFile(‘proguard-android.txt‘), ‘proguard-rules.pro‘            //使用簽名配置            signingConfig signingConfigs.release        }    }    ...}

這樣配置完後每次build工程產生的檔案都會使用debug下的簽名資訊了，gradle配置詳情可參考我的另一篇部落格Android Studio常用Gradle操作。

個人網站：http://www.xiaoyaoyou1212.com 歡迎吐槽圍觀！

App的打磨之路(上)