Android 优化

一.启动优化

    1.主题不启用透明背景（不然会有透明卡顿），设置背景图。

    2.Appllication 中起启动服务来启动优化（将耗时和复杂的操作放到服务当中），保证onCreate()方法快速启动：
    
    3.尽量使用热启动和温启动（8.0之前应用保活，9.0统统枪毙），和手机厂商谈才能做到，以后就是用dex分包，插件化，热启动。

 

Application启动

    
    LuancherActivity   》    AMS(ActivityManganerServices)  》    Zygote (受精卵)  》  ActivityThread    main 方法。

        参考：https://www.cnblogs.com/lixiansheng/p/11381951.html
 

    traceView工具的使用：
            
            使用方法：
               开始：     Debug.startMethodTracing("fileName"); 参数 文件名字 
               停止：     Debug.stopMethodTracing("");
    

二.体积优化：

 缺点：
            Google等市场限制。包越大，推广价格越高，安装时间越长，

1.图片的优化：    
            
        使用webP编码图片优于哈夫曼压缩（微信压缩）  哈夫曼压缩变频是压缩，对rgb进行变频压缩 ，webP压缩是帧内压缩，是对多余的空间进行压缩

        Android12以上支持有损的，Android18以上无损的。12以下要导入包

 

2.Grade压缩：
        
            不存在国际化去掉。v7包中存在国际化资源  grade配置 参数reconfigs  "en"
        
            ndk 支持 v7a就好了 x86机器都能支持v7a 去除ABI 

            
            混淆：（反射和JNI不能混淆）
                      
            功能：1.裁剪，优化，混淆。

            Grade增加参数打包,去除没有引用的文件（由于R文件的引用，不会删除文件，只会将内容去掉），如果想不去除，反射的一些文件。增加keep文件，进行文件保留。

                       shrinkResources true
                       minifyEnabled true

    
            apk包中，只有accets 文件夹不会处理。其余都会被处理，赋予一个id.
    
            
            release会进行资源文件混淆，所以比debug包小

 

  3.Dex 压缩
            
            每个Dex持有65536个方法  ，由于classe1.dex 调用 classes2.dex 的方法，所以classe1.dex 中存在class2.dex方法。 将多余的classe1.dex 中class2.dex方法去掉就是减少体积了(没有试过)。

 

三.UI优化：

  

 

    Android 界面绘制过程   BUTTON   》   CPU  》   OPENGL   》   GPU对图形进行栅格化，过程必须在16ms以内完成 FPS说明原因

  

     FPS
       12fps,每秒12帧
       24fps,每秒24帧
       。。。
       60FPS，让人的肉眼看不出来，每秒必须要有60帧
       1000ms/60=16ms  平均必须每隔16刷新一次
       Android 系统每个16ms就会刷新一次  只能手机耗电的原因，屏幕最耗电

 

 

卡顿原理：
        
        当一帧画面渲染超过16ms,垂直同步机制会让显示器等待GPU完成栅格化渲染操作。
       
        这样会让这一帧的画面，多停留16ms,甚至更多，这样就让用户看起来卡顿（LOL游戏，网速慢时，团战过几秒才会显示上一个画面）。

        16ms内所做的工作  
            1. cpu,将UI对象转成多边形和纹理。
            2. cpu传递数据到GPU，GPU进行绘制。
           16ms必须处理上面的两步，否则会丢帧或者显示到下一帧造成卡顿。

            自己理解：也就是16ms内必须将前面16毫秒改变的屏幕数据处理完成，并且完美的绘制到屏幕上。

 

 

         

解决卡顿
    
      减少时间
    
        1.CPU减少XML转换成对象时间。
        2.GPU减少重复绘制(CUP)。
        
        
        1.布局层级太深，用户看不到的区域也会被绘制，会被绘制两次。

        2.自定义控件中，onDraw方法过多的绘制。

 

  GPU 过度绘制分析工具  1.代表绘制两层，2.三层 ,3x 四层， 4x 5层

    
    总结：
        1.布局中的背景是否有必要
        2.自定义VIew是否进行裁剪
        3.布局是否能够扁平化（删除多余布局）

    附件：
    
        4.当前页面是否有非常耗内存代码存在 （耗内存代码会内存抖动》gc频繁的回收内存》回收会暂停其他线程（当中包括UI线程）UI线程16ms不能重新绘制界面)
        5.webView 通过单开进程方法 （web内存极度不稳定，会造成内存抖动或者内存溢出）
        6.关于图片的计算是否需要动用代码 （通过UI来处理）

 

 

界面太过复杂 可以使用ConstraintLayout ，减少绘制层级

  简历亮点：
     
        负责整体UI优化，代码review，负责安全优化，启动优化，内存优化，卡顿优化，网络优化，存储优化。

本文地址：https://blog.csdn.net/liweicai137/article/details/107467620