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