App開發中高階技巧

2.1  crash 異常收集與統計，作者在書中介紹瞭如何收集crash 到資料庫，如何對大量crash資訊進行去重，如何生成crash報表，如何將crash 自動分配給開發人員提供一整套解決方案。

2.2 作者花了大量時間，列舉出100多個crash例項，且分析出出現原因，並給出解決方案，而且這些crash也多是專案中可能出現的，有了這些crash資訊庫，可以幫助我們快速定位處理crash，我們在專案中就可能遇到過

比如除數為0，textView.settext(count) count為int型（會報找不到資源id）、is your activity running（dialog，popwindow show時，activity未啟動完或actiivty已關閉）、rmeabi 和armeabi-v7a中so包數量不一致，會導致UnsatisfiedLinkError、不要相信api 返回資料，必須做非空判斷，型別異常等容錯處理、遍歷集合時不能刪除集合中資料，否則發生崩潰、多個執行緒同時操作同一集合資料也可能會發生崩潰、網路請求時，實體類被混淆、系統碎片化，高版本api在低版本崩潰、SQLite 支援單執行緒、多執行緒、序列三種模式，但是多執行緒中使用單個數據庫連線不是安全的，當一個執行緒寫資料，一個在刪資料會拋I/O 異常，當一個操作完關閉資料庫，另外一個還在操作也會導致Crash等，作者將100多個carsh分為以下幾類：

1 java語法相關的異常

2 acitivty相關的異常

3 序列化相關的異常

4 列表相關的異常

5 窗體相關的異常

6 資源相關的異常

7 系統碎片化的異常

8 sql相關異常

9 其他異常

限於篇幅問題，就不一一列舉了，有興趣的朋友可以去詳細閱讀下，對快速處理crash是有很大幫助的。

2.3  混淆

      有時我們會遇到直接AS 執行專案，沒問題，但打release包時某些功能模組就有bug, 花上大半天也不知問題所在，這種情況下就要考慮下是不是混淆所致了。

針對app 量身定製一套混淆規則：

     1 保留實體類和成員不被混淆，作者是建議將keep 實體類所在的包下所有類，本人之前在專案中也用過另外一種方式

  定義一個介面類：

public interface NonProguard {
}

不想被混淆的類 實現這個介面

public class ErrorResponeBean implements NonProguard{
    private String errorCode;
    private String errorMessage;

    public String getErrorCode() {
        return errorCode;
    }

    public void setErrorCode(String errorCode) {
        this.errorCode = errorCode;
    }

    public String getErrorMessage() {
        return errorMessage;
    }

    public void setErrorMessage(String errorMessage) {
        this.errorMessage = errorMessage;
    }
}

在混淆檔案中新增：

-keep interface com.example.NonProguard

    2 內部類不被混淆

-keep class tv.danmaku.ijk.media.player$* {*;}

$符用來分割內部類與其母體的標誌

   3 對webview的處理

-keepclassmembers class * extends android.webkit.webViewClient {

    public void *(android.webkit.WebView, java.lang.String, android.graphics.Bitmap);

    public boolean *(android.webkit.WebView, java.lang.String)

}

-keepclassmembers class * extends android.webkit.webViewClient {

    public void *(android.webkit.webView, java.lang.String)

}

4 對javaScript的處理

  app供h5呼叫的原生方法不能被混淆

-keepclassmembers class com.example.youngheart.MainActivity$JSInterface1 {

    <methods>;

}

5 保留自定義控制元件（繼承自View）不被混淆

-keep public class * extends android.view.View {

    *** get*();

    void set*(***);

    public <init>(android.content.Context);

    public <init>(android.content.Context, android.util.AttributeSet);

    public <init>(android.content.Context, android.util.AttributeSet, int);

}

6 第三方jar包 

  有些第三方sdk已經是混淆了，所以要在混淆規則 keep ，不過一般第三方都會提供混淆規則，直接複製到自己的專案中的混淆規則檔案中即可。

2.4 競品分析

 對於競品，從技術上講，有以下幾個點是重點研究方向：

為什麼他們的App體積比我們小？

為什麼他們App訪問速度比我們快？

為什麼他們App基本上不咋崩潰？

通過競品分析，作者提供一些優化方案，

1 知己知彼，百戰不殆。通過分析競品app安裝包結構，瞭解競品可能用到的技術點，獲取競品app資源，如動畫，xml等, 但直接解壓的xml 檔案，我們看到的是亂碼，作者提供了一款神器AXMLPrinter2.jar,執行

 java -jar AXMLPrinter2 AndroidManifest.xml

此外我們還可以通過app 反編譯工具如apktool 對dex 包進行反編譯，檢視dex包中的原始碼

apktool使用 可參考：http://blog.csdn.net/vipzjyno1/article/details/21039349/

2 提升Splash 廣告速度，書中提到的方法和目前我們專案中用到的差不多，首次非同步調介面api，獲取廣告資訊及快取廣告圖片到本地，下次啟動直接展示已快取的圖片，同時非同步呼叫介面檢查有無新廣告，有則快取，此時要針對 使用者網路情況 如是wifi，還是使用流量採取不同的策略。

3 H5頁面提速：

     將常用的h5頁面、css ，js打成zip包，app每次啟動，啟用一個執行緒，非同步將zip包解壓到本地，每次從本本地讀取H5頁面，就不用每次從伺服器獲取。為了保證H5頁面是最新的，我們需要對zip包進行版本化管理，每次載入H5頁面都向伺服器詢問當前版本號，如過期重新下載zip包，同時為避免app自帶zip版本過舊，導致新使用者下載的包比較大，每次發版前都要將最近的zip包內嵌到app內。

     製作增量zip包，為了提升zip包下載速度及節省流量，引入增量更新概念，每次只將新增及修改的檔案放入zip包，同時控制圖片資源數量，即使是增量更新也要控制增量包的大小在100K內。

4 png/jpg使用：png是無損的，jpg是有損的，同樣尺度的圖片，png會大些，但手機偏偏對png情有獨鍾，會對其進行硬加速，雖然png體積大些，但載入速度快。所以APP內的圖片優先使用png格式。但尺度大的圖片，如splash圖、引導圖、大的背景圖及需要網路下載的圖片，為了減小App體積，可以考慮採用jpg.

google提供了一種新的圖片格式 webP,壓縮率比jpg更好，android是支援的，ios如個使用需要引入WebP解碼器。

5 自動選取最佳伺服器策略：專案可能有多臺伺服器，分別接入電信、移動或者聯通專線，可以考慮讓app嘗試從哪個伺服器連線速度快些，同時要處理好伺服器的負載平衡。

6 熱修復， 熱修復可以解決一下緊急bug，而不需要發版本，但目前ios禁止了熱修復使用。

 android 熱修復技術可參考：http://blog.csdn.net/yangxi_pekin/article/details/54929809

原文連結：https://my.oschina.net/u/3729392/blog/1606942