App研發錄讀後總結（二）

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