关于程序员:Android性能优化之疑难杂症解决方案UAPM的性能监控分析

32次阅读

共计 4145 个字符,预计需要花费 11 分钟才能阅读完成。

目录

一. 启动慢 / 白屏 / 黑屏优化
1. 批改主题 / 背景图
2. 初始化机会
3. 子线程初始化
4.ConstraintLayout
二. 解体 /ANR/OOM
1. 解体
2.ANR
三.U-APM
1. 集成
2. 应用
四. 作者介绍

对于 Android 倒退至今,在各项性能非常成熟的状况下,咱们越来越器重 App 的性能优化,以及用户体验,这关乎一个线上利用的 DAU 持续增长的根底,以及用户口碑的问题,明天刘某人带大家来一起剖析一下解体 / 卡顿 /ANR/OOM/ 启动慢等问题是如何解决的,以及应用友盟性能监控平台 U -APM 的便捷。

一. 启动慢 / 白屏 / 黑屏优化
咱们在利用开发的时候,经常会提前初始化一些数据和性能,来保障用户应用的过程中,不会产生额定的停留,等待时间,那么当一个我的项目非常宏大的时候,初始化的数据也十分的多,另外因为设施的性能,渲染的机制等各种起因,时常会呈现启动慢导致白屏,黑屏等状况,基于此状况,咱们来看下如何解决。

1. 批改主题 / 背景图
咱们先来看下 Activity 的构造

批改主题只须要将启动页的主题批改为通明或者图片,这样在 ContentView 加载进去之前,咱们会透过启动的 Activity 看到桌面,就不会有黑 / 白屏的景象。再把标题栏去掉,把 Activity 设置成全屏的,成果挺不错,毛病是如果启动的是一个有简单耗时操作的 Activity,那么会有一种提早的感觉。

将主题背景设置成一张图片,把标题栏去掉,把 Activity 设置成全屏的,这这样在 ContentView 加载进去之前,咱们就能看到一张默认背景图,然而图片的屏幕适配问题就须要思考了,主题里的背景图片会主动拉伸,可能会导致失真或者比例失调的问题,解决办法是应用一张.9 的图片。

代码如下
<!– 启动页通明主题,如果想设置为背景,则批改 windowBackground–>
<style name=”SplashStyleTransparent” parent=”Theme.TestPerformance”>

<item name="android:windowBackground">@android:color/transparent</item>
<item name="android:windowFullscreen">true</item>
<item name="android:navigationBarColor">@android:color/transparent</item>
<item name="android:statusBarColor">@android:color/transparent</item>
<item name="windowNoTitle">true</item>
<item name="windowActionBar">false</item>
<item name="android:windowContentOverlay">@null</item>
<item name="android:windowDisablePreview">false</item>

</style>

2. 初始化机会
咱们常见的初始化,无外乎在 Application 的 onCreate 或者启动页的 onCreate 创立回调中进行初始化,然而理解生命周期你能够发现,实际上 onCreate 还在进行渲染的操作,所以咱们能够把初始化的动作放在 onResume 中,然而 onResume 是屡次回调的,所以咱们还须要进行初始化的判断。

代码如下
@Override
protected void onResume() {

super.onResume();
// 未初始化才进行初始化
if (!ThirdSDK.getInstance().isInit()) {ThirdSDK.getInstance().init();}

}

3. 子线程初始化
如果非强制必要在主线程应用,或者非强制要疾速初始化,疾速调用的函数,咱们能够通过在子线程初始化的形式来优化大量函数初始化的状况

代码如下
public class BaseApp extends Application {

@Override
public void onCreate() {super.onCreate();
    // 多过程的状况下,只在主过程进行一次初始化
    if (CommonUtils.isMainProcess()) {new Thread(() -> {if (!ThirdSDK.getInstance().isInit()) {ThirdSDK.getInstance().init();}
        }).start();}
}

}
4.ConstraintLayout
束缚布局曾经成为 Android Studio 官网模板中默认的父布局了,可见其位置,ConstraintLayout
可让您应用扁平视图层次结构(无嵌套视图组)创立简单的大型布局。它与 RelativeLayout 类似,其中所有的视图均依据同级视图与父布局之间的关系进行布局,但其灵活性要高于 RelativeLayout,并且更易于与 Android Studio 的布局编辑器配合应用。他针对的不光是启动页的优化,所以放在最初,ConstraintLayout 能缩小布局渲染的层级,也能起到肯定的优化作用。

具体应用形式能够参考 Google 文档:
https://developer.android.goo…

二. 解体 /ANR/OOM
1. 解体
解体的问题是运行时所产生的,并且会抛出 Exception,最常见的就是空指针,数组越界等异样了,如果是调试过程中呈现解体,我置信略微有一些根底的同学都晓得如何去解决问题,在 logcat 中搜寻 AndroidRuntime 即可,解决起来依据谬误提醒修复即可,如果非调试状态,而是在线上,那咱们就须要日志的采集了,解体日志采集个别本地化做的话,徒增了很多的工作量,我比拟举荐友盟的挪动统计 U -App 来采集日志,应用办法见下文
2.ANR
ANR 的体现在老的 Android 版本上会弹出一个提示框(利用已进行),然而当初支流的版本个别都是间接闪退了,ANR 的解决形式比较复杂,须要依据堆栈的溢出信息来逐渐剖析,体现如图

负责更新界面的利用主线程无奈解决用户输出事件或绘制操作,这样会引起用户的不满,所以零碎会依据以后的场景期待,期待超时则进行响应,个别以下几种状况会导致 ANR。

1. 当您的 Activity 位于前台时,您的利用在 5 秒钟内未响应输出事件或 BroadcastReceiver(如按键或屏幕轻触事件)。
2. 尽管前台没有 Activity,但您的 BroadcastReceiver 用了相当长的工夫仍未执行结束。

Android 提供了一些形式来帮忙咱们剖析出问题,详情能够查看下官网的文档
https://developer.android.goo…

当然,对于线上的 App 呈现问题,咱们就须要借助友盟的 U -App 来采集日志,才不便咱们剖析问题,应用办法见下文。

3.OOM
OOM 内存溢出,呈现的状况大多数是在援用图片上出的问题,全称“Out Of Memory”, 最常见的 OOM 状况有以下三种:
 java.lang.OutOfMemoryError: Java heap space
 java 堆内存溢出,此种状况最常见,个别因为内存泄露或者堆的大小设置不当引起。对于内存泄露,须要通过内存监控软件查找程序中的泄露代码,而堆大小能够通过虚拟机参数 -Xms,-Xmx 等批改。
 java.lang.OutOfMemoryError: PermGen space
 java 永恒代溢出,即办法区溢出了,个别呈现于大量 Class 或者 jsp 页面,或者采纳 cglib 等反射机制的状况,因为上述情况会产生大量的 Class 信息存储于办法区。此种状况能够通过更改办法区的大小来解决,应用相似 -XX:PermSize=64m -XX:MaxPermSize=256m 的模式批改。另外,过多的常量尤其是字符串也会导致办法区溢出。
 java.lang.StackOverflowError
 不会抛 OOM error,但也是比拟常见的 Java 内存溢出。JAVA 虚拟机栈溢出,个别是因为程序中存在死循环或者深度递归调用造成的,栈大小设置太小也会呈现此种溢出。能够通过虚拟机参数 -Xss 来设置栈的大小。

咱们通常应用 heapdump 来剖析内存的波形查找问题,当然,咱们也能够先采集日志,见下文

三.U-APM
1. 集成
咱们能够应用友盟的 APM 先把日志采集了,便于咱们解决问题,U-APM 是在原 U -App 稳定性剖析根底上全新降级的独立产品, 所以已计入的同学间接降级即可:https://at.umtrack.com/LrKb0f

依照文档形容咱们来接入,接入的流程步骤如图

1. 咱们首先在 project 的 build.gradle 中增加友盟的仓库,如图示代码

2. 在 app/build.gradle 中增加依赖

3. 增加权限

4. 初始化,须要先调用预初始化,再调用初始化

好的,所有准备就绪,咱们就能够来模仿下谬误的采集了,然而要留神,APP_KEY 是须要本人去申请的,而 APP_CHANNEL 对应的是渠道标记,如果没有多渠道,能够忽视,如果有多渠道的打包和统计,那么传入对应渠道名即可。

2. 应用

来到友盟 APM 治理平台

能够看到我创立的 DEMO 显示已集成 APM,我来模仿一条空指针的谬误

能够看到,实时显示,并且抓到的日志是比拟精准的,咱们来看下详情

这样就功败垂成了,再有解体,ANR,OOM 都能捕捉到了,而且能够基于友盟的根底能力,咱们能够实时统计日活,事件上报等性能,还是蛮不错的。

当然,采集到日志,包含检测到异样,咱们拿到日志,都是要本人剖析的,这个剖析的过程,还是须要集体的教训,以及仔细和急躁,解决 Bug 的路线是干燥且乏味的,静下心来,能力体验代码之美。

作者:刘桂林
CSDN 博客专家,CSDN 博客之星,CSDN/ 慕课网认证讲师,具备多年 Android 软件开发教训,次要从事车载前装行业,互联网广告行业,精通 Android,乐于分享,在网络上发表原创博客文章备受好评,酷爱新技术,对技术有着近乎刻薄的要求,讲课语言晦涩,思路清晰,口才风趣,已在慕课网公布三门实战课程。

正文完
 0