应用中性能优化实践与总结(精心总结)
任何优化都需要进行检测,以数据说话,优化前和优化后有了怎样的提升
[TOC]
检测工具任选其一
从点击应用的启动图标開始创建出一个新的进程直到我们看到了界面的第一帧， 这段时间就是应用的启动时间
adb shell am start -W 包名/.第一个activity
冷启动
Activi
TotalTime: 1074
WaitTime: 1075
Complete
热启动
TotalTime: 115
WaitTime: 117
Complete
优化后冷启动
TotalTime: 773
WaitTime: 774
Complete
热启动
TotalTime: 114
WaitTime: 115
Complete
注意有个点
1、ThisTime:一般和 TotalTime 时间一样。除非在应用启动时开了一个透明的
Activity 预先处理一些事再显示出主 Activity，这样将比 TotalTime 小。
2、TotalTime:应用的启动时间。包含创建进程+Application 初始化+Activity 初
始化到界面显示。
3、WaitTime:一般比 TotalTime 大点，包含系统影响的耗时。
查看优化后数据
Displayed com.sinochem.www.car.owner/.activity.WelcomeActivity: +1s104ms
classpath 'com.jakewharton.hugo:hugo-plugin:1.2.1'
apply plugin: 'com.jakewharton.hugo'
注意在每个lib里面都要加上 你想在那个lib里面打印就在那个lib里面加上这句
3. 在类或方法上声明@DebugLog注解。
@Override @DebugLog
public void onCreate() {
super.onCreate();
}
在MyApplication 的onCreate 上面加上注解
2021-01-31 15:03:01.871 26943-26943/com.sinochem.www.car.owner V/MyApplication: ⇢ onCreate()
2021-01-31 15:03:02.161 26943-26943/com.sinochem.www.car.owner V/MyApplication: ⇠ onCreate [289ms]
过滤关键字就是在哪个方法上面加上的DebugLog.比如在onCreate方法上加的, 过滤关键字就是onCreate.
在打印的列表搜索方法名称，就可以知道该方法的运行耗时。
自己写一个时间检测的工具类- 使用自定义注解实现 AOP模式
在MyApplication 初始化一些第三方库的时候使用线程池异步加载
举例:
ThreadManager.getDownloadPool().execute(new Runnable() {
@Override
public void run() {
//屏幕适配
configUnits();
// mCounDownLatch.countDown();
}
});
原来的时间:
2021-01-31 15:03:01.871 26943-26943/com.sinochem.www.car.owner V/MyApplication: ⇢ onCreate()
2021-01-31 15:03:02.161 26943-26943/com.sinochem.www.car.owner V/MyApplication: ⇠ onCreate [289ms]
效果:
2021-01-31 16:46:45.652 26568-26568/com.sinochem.www.car.owner V/MyApplication: ⇢ onCreate()
2021-01-31 16:46:45.882 26568-26568/com.sinochem.www.car.owner V/MyApplication: ⇠ onCreate [229ms]
优化了60多 毫秒.
可以采用方案 CountDownLauch 同步计数器,同步工具类，用来协调多个线程之间的同步，或者说起到线程之间的通信
不仅可以用在这里. 也可以用在其他地方.
比如在第一个页面就需要异步的结果,就可以使用 CountDownLauch
countDownLatch这个类使一个线程等待其他线程各自执行完毕后再执行。
是通过一个计数器来实现的，计数器的初始值是线程的数量。每当一个线程执行完毕后，计数器的值就-1，当计数器的值为0时，表示所有线程都执行完毕，然后在闭锁上等待的线程就可以恢复工作了。
使用方法:
private CountDownLatch mCounDownLatch = new CountDownLatch(1);
这里的1 是指有几个地方用到了,也就是说异步任务有几个需要主线程确定执行完毕的.
ThreadManager.getDownloadPool().execute(new Runnable() {
@Override
public void run() {
//屏幕适配
configUnits();
mCounDownLatch.countDown();
}
});
//在代码的最后 也就是需要确定的地方加上这个
try {
mCounDownLatch.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
这样就形成了 必须等屏幕适配结束 才继续.
可以看到运行时间289ms
在 MainActivity#OnCreate 执行一个 postDelayed(Runnable r, long delayMillis)
Handler.postDelay()不能确定具体需要 delay 的时间.
如果时间设置过短，那么此时 UI 还没渲染完毕，这势必会阻塞到 UI 的渲染，如果过长，那么又导致延迟时间变长了。
IdleHandler(闲时机制) 处理延迟加载
IdleHandler是一个回调接口，可以通过MessageQueue的addIdleHandler添加实现类。当MessageQueue中的任务暂时处理完了（没有新任务或者下一个任务延时在之后），这个时候会回调这个接口，返回false，那么就会移除它，返回true就会在下次message处理完了的时候继续回调。
源码位置：MessageQueue.IdleHandler
自建一个队列保存任务
//LinkedList 实现了Deque 接口 Deque接口继承了Queue 所以可以这样创建对象
private Queue<Runnable> delayTasks = new LinkedList<>();
使用
private MessageQueue.IdleHandler idleHandler = new MessageQueue.IdleHandler() {
@Override
public boolean queueIdle() {
LogUtils.d("queueIdle调用");
if (delayTasks.size() > 0) {
LogUtils.d("从队列取出");
Runnable runnable = delayTasks.poll();
if (runnable != null) {
runnable.run();
}
}
return !delayTasks.isEmpty();
//delayTasks非空时返回ture表示下次继续执行
//为空时返回false系统会移除该IdleHandler不再执行
}
};
TODO 写一个启动器处理启动任务
AppStartFaster:
AppStartFaster 项目 主要是通过 ClassName 找到相应的 Task，
阿里 alpha项目 :
是通过 taskName 找到相应的 Task，并且需要指定 ITaskCreator。两种方式各有优缺点，具体看使用场景。
对于应用的启动时间，仅仅能是尽量的避免一些耗时的、非必要的操作在主线程 中，这样相对能够缩减一部分启动的耗时，另外一方面在等待第一帧显示的时间
里，能够增加一些配置以增加体验，比方增加 Activity 的 background，这个背 景会在显示第一帧前提前显示在界面上。
单独做个主题 也可以做个透明的样式 都可以我这里做了图片
<style name="AppTheme.welcome" parent="@style/Theme.AppCompat.Light.NoActionBar">
<item name="android:windowBackground">@android:color/transparent</item>
</style>
<style name="AppTheme.welcome" parent="@style/Theme.AppCompat.Light.NoActionBar">
<item name="android:windowBackground">@android:color/transparent</item>
</style>
然后可以在下一个页面恢复样式
Override
protected void onCreate(Bundle savedInstanceState) {
setTheme(R.style.AppTheme); super.onCreate(savedInstanceState);
在 Application 的构造器方法、attachBaseContext()、onCreate()方法中不要 进行耗时操作的初始化，一些数据预取放在异步线程中，能够採取 Callable 实现。
对于 sp 的初始化，由于 sp 的特性在初始化时候会对数据所有读出来存在内 存中，所以这个初始化放在主线程中不合适，反而会延迟应用的启动速度，对于 这个还是须要放在异步线程中处理。
对于 MainActivity，由于在获取到第一帧前。须要对 contentView 进行測量 布局绘制操作，尽量降低布局的层次。考虑 StubView 的延迟载入策略。当然在 onCreate、onStart、onResume 方法中避免做耗时操作。
不创建全局静态对象，而是转为单例模式，其中应用仅在第一次访问对象时初始化它们。此外，考虑使用依赖注入框架（如 Dagger），它们会在首次注入时创建对象和依赖项。
多进程任务导致Application重复启动
解决方案:
把下面代码放到MyApplication开头
//多进程会重复调用
String curProcessName = getCurrentProcessName(this);
if (!curProcessName.equals(getPackageName())) {
return;
}
/**
* 获取当前的进程名
*
* @param context:上下文
* @return :返回值
*/
public String getCurrentProcessName(Context context) {
int pid = android.os.Process.myPid();
ActivityManager am = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);
List<ActivityManager.RunningAppProcessInfo> runningApps = am.getRunningAppProcesses();
if (runningApps == null) {
return null;
}
for (ActivityManager.RunningAppProcessInfo procInfo : runningApps) {
if (procInfo.pid == pid) {
return procInfo.processName;
}
}
return null;
}
StrictMode主要检测两大问题：线程策略（TreadPolicy）和VM策略（VmPolicy）。
ThreadPolicy线程策略：
自定义的耗时调用，使用detectCustomSlowCalls()开启；
磁盘读取操作，使用detectDiskReads()开启；
磁盘写入操作，使用detectDiskWrites()开启；
网络操作，使用detectNetwork()开启。
VmPolicy虚拟机策略：
Activity泄漏，使用detectActivityLeaks()开启；
未关闭的Closable对象泄漏，使用detectLeakedClosableObjects()开启；
泄漏的Sqlite对象，使用detectLeakedSqlLiteObjects()开启；
检测实例数量，使用setClassInstanceLimit()开启。
注意:我们只需要在 app 的开发版本下使用 StrictMode，线上版本避免使
经过以上优化结果 adb检测 从1074ms ,优化到773ms.Application的onCreate检测 从288ms 优化到220ms.
表现形式:
android studio 自带的. 找不到profile 的话 顶部导航栏
这样可以看到当前内存是哪里消耗的最多,还有一些其他的内存信息, 还可以看一个bitmap的预览图
ActivityManager有一个MemoryInfo对象，可以进行进程的内存获取；同时我们需要RunningAppProcessInfo获取到当前系统正在运行的进程的集合，然后去遍历这个集合，根据每个元素的processName（包名）字段去筛选我们需要获取内存信息的进程，然后通过ActivityManager的getProcessMemoryInfo方法去获取到这个进程的内存值，通过换算得到进程的内存占用信息；然后将这个进程的各项信息，比如包名，PID，内存占用等信息
https://square.github.io/leakcanary/getting_started/
大致原理
监听Activity生命周期->onDestroy以后延迟5秒判断Activity有没有被回收->如果没有回收,调用GC，再此判断是否回收，如果还没回收，则内存泄露了，反之，没有泄露。没有回收的话会dump 内存 然后去分析
引入:
dependencies {
// debugImplementation because LeakCanary should only run in debug builds.
debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.6'
}
对bitmap检测不合理
支持ART上的Java方法HOOK. 使用 epic 库
hok 住 imageview 的setImageBitmap 即可
https://github.com/tiann/epic
implementation 'me.weishu:epic:0.11.0'
public class ImageHook extends XC_MethodHook {
/**
* hook方法之后的一个回调
*
* @param param
* @throws Throwable
*/
@Override
protected void afterHookedMethod(MethodHookParam param) throws Throwable {
super.afterHookedMethod(param);
//实现逻辑
checkBitmap(param);
}
private void checkBitmap(MethodHookParam param) {
// DexposedBridge.findAndHookMethod(ImageView.class, "setImageBitmap", Bitmap.class, new XC_MethodHook() {
// @Override
// protected void afterHookedMethod(MethodHookParam param) throws Throwable {
// super.afterHookedMethod(param);
if (param.thisObject instanceof ImageView) {
final ImageView imageView = (ImageView) param.thisObject;
if (imageView.getDrawable() instanceof BitmapDrawable) {
BitmapDrawable drawable = (BitmapDrawable) imageView.getDrawable();
final Bitmap bitmap = drawable.getBitmap();
if (bitmap != null) {
//bitmap 宽高
int bitmapWidth = bitmap.getWidth();
int bitmapHeight = bitmap.getHeight();
//视图宽高
int viewWidth = imageView.getWidth();
int viewHeight = imageView.getHeight();
if (viewHeight > 0 && viewWidth > 0) {//view 有宽高
//当图片宽高都大于视图宽高的2倍时就报出警告
if (bitmapWidth >= viewWidth << 2 && bitmapHeight >= viewHeight << 2) {
warn(bitmapWidth, bitmapHeight, viewWidth, viewHeight);
}
} else {
imageView.getViewTreeObserver().addOnPreDrawListener(new ViewTreeObserver.OnPreDrawListener() {
@Override
public boolean onPreDraw() {
int bitmapWidth = bitmap.getWidth();
int bitmapHeight = bitmap.getHeight();
int viewWidth = imageView.getWidth();
int viewHeight = imageView.getHeight();
if (bitmapWidth >= viewWidth << 2 && bitmapHeight >= viewHeight << 2) {
warn(bitmapWidth, bitmapHeight, viewWidth, viewHeight);
}
imageView.getViewTreeObserver().removeOnPreDrawListener(this);
return true;
}
});
}
}
}
}
// }
// });
}
private void warn(int bitmapWidth, int bitmapHeight, int viewWidth, int viewHeight) {
StringBuffer msg = new StringBuffer();
msg.append("图片大小不合理：")
.append("bitmapWidth=").append(bitmapWidth)
.append(",bitmapHeight=").append(bitmapHeight)
.append(",viewWidth=").append(viewWidth)
.append(",viewHeight=").append(viewHeight);
//不合理
LogUtil.e((new Throwable(msg.toString())));
}
}
//方式1 hook方式 注册到setImageBitmap 里面去
DexposedBridge.findAndHookMethod(ImageView.class, "setImageBitmap", Bitmap.class, new ImageHook());
用的时候minSdkVersion 21
用的时候无法注入.
简单原理:
实时检查View中的BitmapDrawable，判断bitmap大小和view图片的大小是否匹配
float scale = Math.max(bitmap.getHeight()*1.0f/view.getHeight(),bitmap.getWidth()*1.0f/view.getWidth());
解决办法: 由于1个集合中有许多元素，故最简单的方法 = 清空集合对象 & 设置为null
解决办法:
解决方案 单例模式引用的对象的生命周期 = 应用的生命周期
解决方案:
将非静态内部类设置为：静态内部类（静态内部类默认不持有外部类的引用）
该内部类抽取出来封装成一个单例
尽量 避免 非静态内部类所创建的实例 = 静态
使用leakcannry检测到内存泄漏后分析.一般造成内存泄漏的原因有以下几种
储备知识
举例:
//1. 实例化自定义的Handler类对象-
//注：此处并无指定Looper，故自动绑定当前线程(主线程)的Looper、MessageQueue
private Handler handler; = new Handler();
在Handler消息队列 还有未处理的消息 / 正在处理消息时，消息队列中的Message持有Handler实例的引用
1、资源性对象未关闭
对于资源性对象不再使用时，应该立即调用它的close()函数，将其关闭，然后再置为null。例如Bitmap
等资源未关闭会造成内存泄漏，此时我们应该在Activity销毁时及时关闭。
2、注册对象未注销
例如BraodcastReceiver、EventBus未注销造成的内存泄漏，我们应该在Activity销毁时及时注销。
3、类的静态变量持有大数据对象
尽量避免使用静态变量存储数据，特别是大数据对象，建议使用数据库存储。
4、单例造成的内存泄漏
优先使用Application的Context，如需使用Activity的Context，可以在传入Context时使用弱引用进行封
装，然后，在使用到的地方从弱引用中获取Context，如果获取不到，则直接return即可。
5、非静态内部类的静态实例
该实例的生命周期和应用一样长，这就导致该静态实例一直持有该Activity的引用，Activity的内存资源
不能正常回收。此时，我们可以将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如
果需要使用Context，尽量使用Application Context，如果需要使用Activity Context，就记得用完后置
空让GC可以回收，否则还是会内存泄漏。
6、Handler临时性内存泄漏
Message发出之后存储在MessageQueue中，在Message中存在一个target，它是Handler的一个引
用，Message在Queue中存在的时间过长，就会导致Handler无法被回收。如果Handler是非静态的，
则会导致Activity或者Service不会被回收。并且消息队列是在一个Looper线程中不断地轮询处理消息，
当这个Activity退出时，消息队列中还有未处理的消息或者正在处理的消息，并且消息队列中的Message
持有Handler实例的引用，Handler又持有Activity的引用，所以导致该Activity的内存资源无法及时回
收，引发内存泄漏。解决方案如下所示：
1、使用一个静态Handler内部类，然后对Handler持有的对象（一般是Activity）使用弱引用，这样在回收时，也可以回收Handler持有的对象。
2、在Activity的Destroy或者Stop时，应该移除消息队列中的消息，避免Looper线程的消息队列中有待处理的消息需要处理。需要注意的是，AsyncTask内部也是Handler机制，同样存在内存泄漏风险，但其一般是临时性的。对于类似AsyncTask或是线程造成的内存泄漏，我们也可以将AsyncTask和Runnable类独立出来或者使用静态内部类。
7、容器中的对象没清理造成的内存泄漏
在退出程序之前，将集合里的东西clear，然后置为null，再退出程序
8、WebView
WebView都存在内存泄漏的问题，在应用中只要使用一次WebView，内存就不会被释放掉。我们可以为
WebView开启一个独立的进程，使用AIDL与应用的主进程进行通信，WebView所在的进程可以根据业
务的需要选择合适的时机进行销毁，达到正常释放内存的目的。
9、使用ListView时造成的内存泄漏
在构造Adapter时，使用缓存的convertView。
查看: 主要查看memoryProfiler里面的内存是否总是频繁回收
解决办法:
主要查看是否有循环创建清空对象的地方.
https://github.com/smallnew/BitmapCanary
使用bBitmapCanary检测后,对图片进行处理
https://juejin.cn/post/6854573219425288199
onTrimMemory 与 onLowMemory Android 系统的每个进程都有一个最大内存限制，如果申请的内存资源超过这个 限制，系统就会抛出 OOM 错误。 onTrimMemory 所以在实际开发过程中我们要尽可能避免内存泄漏与内存抖动之外，还要格外注 意内存使用情况。根据《Manage Your App’s Memory》，
我们可以对内存的状 态进行监听，我们的 Application、Acivity、Service、ContentProvider 与 Fragment 都实现了 ComponentCallbacks2 接口。所以能够重写 onTrimMemory 与 onLowMemory 函数。
onLowMemory 这个函数看名字就是低内存。这个函数的回调意味着后台进程已经被干掉了。这 个回调可以作为 4.0 兼容 onTrimMemory 的 TRIM_MEMORY_COMPLETE 来使用 如果希望在其他组件中也能接收到这些回调可以使用上下文的 registerComponentCallbacks 注册接收， unRegisterComponentCallbacks 反注册
在Application的onTrimMemory(level)
内存紧张时停止一些非必要功能，如关闭推送进程，关闭后台service等
@Override
public void onTrimMemory(int level) {
super.onTrimMemory(level);
switch (level) {
case TRIM_MEMORY_COMPLETE:
//内存不足，并且该进程在后台进程列表最后一个，马上就要被清理
LogUtil.d("内存不足，并且该进程在后台进程列表最后一个，马上就要被清理");
break;
case TRIM_MEMORY_MODERATE:
//内存不足，并且该进程在后台进程列表的中部
LogUtil.d("内存不足，并且该进程在后台进程列表的中部");
break;
case TRIM_MEMORY_BACKGROUND:
//内存不足，并且该进程是后台进程
LogUtil.d("内存不足，并且该进程是后台进程");
break;
case TRIM_MEMORY_UI_HIDDEN:
//内存不足，并且该进程的UI已经不可见了。
LogUtil.d("内存不足，并且该进程的UI已经不可见了");
break;
case TRIM_MEMORY_RUNNING_CRITICAL:
//内存不足(后台进程不足3个)，并且该进程优先级比较高，需要清理内存
LogUtil.d("内存不足(后台进程不足3个)，并且该进程优先级比较高，需要清理内存");
break;
case TRIM_MEMORY_RUNNING_LOW:
//内存不足(后台进程不足5个)，并且该进程优先级比较高，需要清理内存
LogUtil.d("内存不足(后台进程不足5个)，并且该进程优先级比较高，需要清理内存");
break;
case TRIM_MEMORY_RUNNING_MODERATE:
//内存不足(后台进程超过5个)，并且该进程优先级比较高，需要清理内存.
LogUtil.d("内存不足，(后台进程超过5个)，并且该进程优先级比较高，需要清理内存");
break;
}
}
@Override
public void onLowMemory() {
super.onLowMemory();
//被回调时，已经没有后台进程
//通过一键清理后，OnLowMemory不会被触发，而OnTrimMemory会被触发一次。
LogUtils.d("内存不够了");
}
上述系统提供的API，还可以自己实现ComponentCallbacks，通过API注册，这样也能得到OnLowMemory回调。例如：
public static class MyCallback implements ComponentCallbacks {
@Override
public void onConfigurationChanged(Configuration arg) {
}
@Override
public void onLowMemory() {
//do release operation
}
}
然后，通过
Context.registerComponentCallbacks()
在合适的时候注册回调就可以了。通过这种自定义的方法，可以在很多地方注册回调，而不需要局限于系统提供的组件。
后台监控中采用garylog ,客户端就直接用post请求发送一些异常日志.
这里择机发送日志需要注意几个方面:
Chrash现象: 之前出现的兼容性问题主要出现在内存消耗峰值过高,以及存在内存泄漏情况.
检测方案: 采用技术工具检测到内存消耗过大的原因有几个方面.
解决办法: 针对上面问题解决办法如下
优化结果: 从1.1.0版本 标准兼容性测试开始通过率72%左右. 到现在通过率95%以上. 内存峰值消耗由原来300M+ 到现在稳定220M左右.