开发十年老架构师：Android性能优化实践，程序员如何应对中年危机

2021-07-08 15:32:17

public static Context context;

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
context=this;
}
}

上述代码在MainActivity中context为静态变量，并持有Context，当Activity退出后，由于Activity被context一直引用着，导致Activity无法被回收，因此造成了内存泄漏。上述代码比较明显，一般不会犯这种错误。

例子2：

public class MainActivity extends Activity {
public static Out mOut;

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mOut = new Out(this);
}
}
//外部Out类
public class Out {
Out(Context context) {

}
}

上述代码与例子1类似，mOut为静态变量，生命周期与应用一致，传入的MainActivity也被一直引用，导致Activity无法被回收，造成内存泄漏。

解决方案：

1、在不使用静态变量时，置空。

2、可以使用Application的Context。

3、通过弱引用和软引用来引用Activity。

  • 强引用：直接的对象引用。
  • 软引用：当一个对象只有软引用存在时，系统内存不足时此对象会被GC回收。
  • 弱引用：当一个对象只有弱引用存在时，此对象随时被GC回收。

例子3：

单例模式在Android开发中会经常用到，但是如果使用不当就会导致内存泄露。因为单例的静态特性使得它的生命周期同应用的生命周期一样长，如果一个对象已经没有用处了，但是单例还持有它的引用，那么在整个应用程序的生命周期它都不能正常被回收，从而导致内存泄露。

public class Singleton {
private static Singleton singleton = null;
private Context mContext;

public Singleton(Context mContext) {
this.mContext = mContext;
}

public static Singleton getSingleton(Context context){
if (null == singleton){
singleton = new Singleton(context);
}
return singleton;
}
}

像上面代码中这样的单例，如果我们在调用getInstance(Context context)方法的时候传入的context参数是Activity、Service等上下文，就会导致内存泄露。

当我们退出Activity时，该Activity就没有用了，但是因为singleton作为静态单例（在应用程序的整个生命周期中存在）会继续持有这个Activity的引用，导致这个Activity对象无法被回收释放，这就造成了内存泄露。

2、非静态内部类导致内存泄露

非静态内部类（包括匿名内部类）默认就会持有外部类的引用，当非静态内部类对象的生命周期比外部类对象的生命周期长时，就会导致内存泄露。

非静态内部类导致的内存泄露在Android开发中有一种典型的场景就是使用Handler，很多开发者在使用Handler是这样写的：

public class MainActivity extends AppCompatActivity {

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
start();
}

private void start() {
Message msg = Message.obtain();
msg.what = 1;
mHandler.sendMessage(msg);
}

private Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
if (msg.what == 1) {
// 做相应逻辑
}
}
};
}

当Activity退出后，msg可能仍然存在于消息对列MessageQueue中未处理或者正在处理，那么这样就会导致Activity无法被回收，以致发生Activity的内存泄露。
通常在Android开发中如果要使用内部类，但又要规避内存泄露，一般都会采用静态内部类+弱引用的方式。

public class MainActivity extends AppCompatActivity {

private Handler mHandler;

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mHandler = new MyHandler(this);
start();
}

private void start() {
Message msg = Message.obtain();
msg.what = 1;
mHandler.sendMessage(msg);
}

private static class MyHandler extends Handler {

private WeakReference activityWeakReference;

public MyHandler(MainActivity activity) {
activityWeakReference = new WeakReference<>(activity);
}

@Override
public void handleMessage(Message msg) {
MainActivity activity = activityWeakReference.get();
if (activity != null) {
if (msg.what == 1) {
// 做相应逻辑
}
}
}
}
}

mHandler通过弱引用的方式持有Activity，当GC执行垃圾回收时，遇到Activity就会回收并释放所占据的内存单元。这样就不会发生内存泄露了。
上面的做法确实避免了Activity导致的内存泄露，发送的msg不再已经没有持有Activity的引用了，但是msg还是有可能存在消息队列MessageQueue中，所以更好的是在Activity销毁时就将mHandler的回调和发送的消息给移除掉。

@Override
protected void onDestroy() {
super.onDestroy();
mHandler.removeCallbacksAndMessages(null);
}

非静态内部类造成内存泄露还有一种情况就是使用Thread或者AsyncTask。
比如在Activity中直接new一个子线程Thread：

public class MainActivity extends AppCompatActivity {

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
new Thread(new Runnable() {
@Override
public void run() {
// 模拟相应耗时逻辑
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}).start();
}
}

或者直接新建AsyncTask异步任务：

public class MainActivity extends AppCompatActivity {

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
new AsyncTask<Void, Void, Void>() {
@Override
protected Void doInBackground(Void… params) {
// 模拟相应耗时逻辑
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
return null;
}
}.execute();
}
}

这种方式新建的子线程Thread和AsyncTask都是匿名内部类对象，默认就隐式的持有外部Activity的引用，导致Activity内存泄露。要避免内存泄露的话还是需要像上面Handler一样使用静态内部类+弱应用的方式（代码就不列了，参考上面Hanlder的正确写法）。

3、集合类内存泄露

集合类添加元素后，将会持有元素对象的引用，导致该元素对象不能被垃圾回收，从而发生内存泄漏。

4、未关闭资源对象内存泄露

  • 注销广播：如果广播在Activity销毁后不取消注册，那么这个广播会一直存在系统中，由于广播持有了Activity的引用，因此会导致内存泄露。
  • 关闭输入输出流等：在使用IO、File流等资源时要及时关闭。这些资源在进行读写操作时通常都使用了缓冲，如果不及时关闭，这些缓冲对象就会一直被占用而得不到释放，以致发生内存泄露。因此我们在不需要使用它们的时候就应该及时关闭，以便缓冲能得到释放，从而避免内存泄露。
  • 回收Bitmap：Bitmap对象比较占内存，当它不再被使用的时候，最好调用Bitmap.recycle()方法主动进行回收。
  • 停止动画：属性动画中有一类无限动画，如果Activity退出时不停止动画的话，动画会一直执行下去。因为动画会持有View的引用，View又持有Activity,最终Activity就不能给回收掉。只要我们在Activity退出把动画停掉即可。
  • 销毁WebView：WebView在加载网页后会长期占用内存而不能被释放，因此我们在Activity销毁后要调用它的destory()方法来销毁它以释放内存。或是把使用了 WebView 的 Activity (或者 Service) 放在单独的进程里

WebView扩展：

WebView 解析网页时会申请Native堆内存用于保存页面元素，当页面较复杂时会有很大的内存占用。如果页面包含图片，内存占用会更严重。并且打开新页面时，为了能快速回退，之前页面占用的内存也不会释放。有时浏览十几个网页，都会占用几百兆的内存。这样加载网页较多时，会导致系统不堪重负，最终强制关闭应用，也就是出现应用闪退或重启。
由于占用的都是Native 堆内存，所以实际占用的内存大小不会显示在常用的 DDMS Heap 工具中（ DMS Heap 工具看到的只是Java虚拟机分配的内存，即使Native堆内存已经占用了几百兆，这里显示的还只是几兆或十几兆）。只有使用 adb shell 中的一些命令比如 dumpsys meminfo 包名，或者在程序中使用 Debug.getNativeHeapSize()才能看到 Native 堆内存信息。

5、使用系统服务引发的内存泄漏

为了方便我们使用一些常见的系统服务，Activity 做了一些封装。比如说，可以通过 getPackageManager在 Activtiy 中获取 PackageManagerService，但是，里面实际上调用了 Activity 对应的 ContextImpl 中的 getPackageManager 方法

ContextWrapper#getPackageManager

@Override
public PackageManager getPackageManager() {
return mBase.getPackageManager();
}
ContextImpl#getPackageManager

@Override
public PackageManager getPackageManager() {
if (mPackageManager != null) {
return mPackageManager;
}
IPackageManager pm = ActivityThread.getPackageManager();
if (pm != null) {
// Doesn’t matter if we make more than one instance.
return (mPackageManager = new ApplicationPackageManager(this, pm));//创建 ApplicationPackageManager
}
return null;
}

ApplicationPackageManager#ApplicationPackageManager

ApplicationPackageManager(ContextImpl context,
IPackageManager pm) {
mContext = context;//保存 ContextImpl 的强引用
mPM = pm;
}

private UserManagerService(Context context, PackageManagerService pm,
Object packagesLock, File dataDir) {
mContext = context;//持有外部 Context 引用
mPm = pm;
//代码省略
}
PackageManagerService#PackageManagerService

public class PackageManagerService extends IPackageManager.Stub {
static UserManagerService sUserManager;//持有 UMS 静态引用
public PackageManagerService(Context context, Installer installer,
boolean factoryTest, boolean onlyCore) {
sUserManager = new UserManagerService(context, this, mPackages);//初始化 UMS
}
}

遇到的内存泄漏问题是因为在 Activity 中调用了 getPackageManger 方法获取 PMS ，该方法调用的是 ContextImpl，此时如果ContextImpl 中 PackageManager 为 null，就会创建一个 PackageManger（ContextImpl 会将自己传递进去，而 ContextImpl 的 mOuterContext 为 Activity），创建 PackageManager 实际上会创建 PackageManagerService（简称 PMS），而 PMS 的构造方法中会创建一个 UserManger（UserManger 初始化之后会持有 ContextImpl 的强引用）。
只要 PMS 的 class 未被销毁，那么就会一直引用着 UserManger ，进而导致其关联到的资源无法正常释放。

解决办法：

将getPackageManager()改为 getApplication()#getPackageManager() 。这样引用的就是 Application Context，而非 Activity 了。

内存泄漏工具

1、leakcanary

leakcanary是square开源的一个库，能够自动检测发现内存泄露，其使用也很简单：
在build.gradle中添加依赖：

dependencies {
debugImplementation ‘com.squareup.leakcanary:leakcanary-android:1.6.1’
releaseIm开发十年老架构师：Android性能优化实践，程序员如何应对中年危机
plementation ‘com.squareup.leakcanary:leakcanary-android-no-op:1.6.1’

//可选项，如果使用了support包中的fragments
debugImplementation ‘com.squareup.leakcanary:leakcanary-support-fragment:1.6.1’
}

根目录下的build.gradle添加mavenCentral()即可，如下：

allprojects {
repositories {
google()
jcenter()
mavenCentral()
}
}

然后在自定义的Application中调用以下代码就可以了。

public class MyApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
if (LeakCanary.isInAnalyzerProcess(this)) {
return;
}
LeakCanary.install(this);

//正常初始化代码
}
}

如果检测到有内存泄漏，通知栏会有提示，如下图；如果没有内存泄漏，则没有提示。

2、Memory Profiler

Memory Profiler 是 Android Profiler 中的一个组件，可以帮助你分析应用卡顿，崩溃和内存泄露等等问题。

打开 Memory Profiler后即可看到一个类似下图的视图。

开发十年老架构师：Android性能优化实践，程序员如何应对中年危机

上面的红色数字含义如下：

1.用于强制执行垃圾回收事件的按钮。
2.用于捕获堆转储的按钮。
3.用于记录内存分配情况的按钮。 此按钮仅在连接至运行 Android 7.1 或更低版本的设备时才会显示。
4.用于放大/缩小/还原时间线的按钮。
5.用于跳转至实时内存数据的按钮。
6.Event 时间线，其显示 Activity 状态、用户输入 Event 和屏幕旋转 Event。
7.内存使用量时间线，其包含以下内容：
一个显示每个内存类别使用多少内存的堆叠图表，如左侧的 y 轴以及顶部的彩色键所示。
虚线表示分配的对象数，如右侧的 y 轴所示。
用于表示每个垃圾回收事件的图标。

如何Memory Profiler分析内存泄露，按以下步骤来即可：

1.使用Memory Profiler监听要分析的应用进程
2.旋转几次要分析的Activity。（这是因为旋转Activity后会重新创建）
3.点击捕获堆转储按钮去捕获堆转储
4.在捕获结果中搜索要分析的类。（这里是MainActivity）
5.点击要分析的类，右边会显示这个类创建对象的数量。

如下图：

开发十年老架构师：Android性能优化实践，程序员如何应对中年危机

内存抖动

内存抖动的原因：

内存抖动一般是瞬间创建了大量对象，会在短时间内触发多次GC，产生卡顿。

内存抖动的在分析工具上的表现：
开发十年老架构师：Android性能优化实践，程序员如何应对中年危机

解决方案：

最简单的做法就是把之前的主线程操作放到子线程去，虽然内存抖动依然存在，但是卡顿问题可以大大缓解。

对于内存抖动本身：

尽量避免在循环体内创建对象，应该把对象创建移到循环体外。
需要大量使用Bitmap和其他大型对象时，尽量尝试复用之前创建的对象。

网络优化

客户端请求流程如下：

开发十年老架构师：Android性能优化实践，程序员如何应对中年危机

相关分析工具

分析网络情况的方式可以通过Wireshark, Fiddler, Charlesr等抓包工具，也可以通过Android Studio的Network Profiler

窗口顶部显示的是 Event 时间线以及 1 无线装置功耗状态（低/高）与 WLAN 的对比。 在时间线上，您可以 2点击并拖动选择时间线的一部分来检查网络流量。

下方的3窗口会显示在时间线的选定片段内收发的文件，包括文件名称、大小、类型、状态和时间。 您可以点击任意列标题为此列表排序。

同时，您还可以查看时间线选定片段的明细数据，显示每个文件的发送或接收时间。

点击网络连接的名称即可查看 4 有关所发送或接收的选定文件的详细信息。 点击各个标签可查看响应数据、标题信息或调用堆栈。

开发十年老架构师：Android性能优化实践，程序员如何应对中年危机

注： 必须启用高级分析才能从时间线中选择要检查的片段，查看发送和接收的文件列表，或查看有关所发送或接收的选定文件的详细信息。 要启用高级分析，请参阅启用高级分析。

启用高级分析需要点击Run Configuration：

开发十年老架构师：Android性能优化实践，程序员如何应对中年危机

打开Run/Debug Configurations，左侧选择你的应用，右侧在Profiling中勾选Enable advanced profiling。

开发十年老架构师：Android性能优化实践，程序员如何应对中年危机

通过以上这些工具可以查看某个时间段内网络请求的具体情况，从而进行网络优化的相关工作。

优化建议

1、后端API设计

后端设计API时需要考虑网络请求的频次、资源状态，在某些情况下可以合并多个接口以满足客户端业务需求。

2、Gzip压缩

使用Gzip来压缩request和response, 减少传输数据量, 从而减少流量消耗。同时可以考虑使用Protocol Buffer代替JSON，protobuf会比JSON数据量小很多.

3、图片大小优化

  • 请求图片时告诉服务器需要的图片的宽高。（比如使用七牛时，可以在url后面添加质量、格式、宽高等等来获取合适的图片资源）
  • 列表采用缩略图。
  • 使用Webp格式：安卓系统从Android4.0（API 14）添加了有损耗的WebP support并且在Android4.2（API 17）对无损的，清晰的WebP提供了支持。使用WebP格式；同样的照片，采用WebP格式可大幅节省流量，相对于JPG格式的图片，流量能节省将近 25% 到 35 %；相对于PNG格式的图片，流量可以节省将近80%。最重要的是使用WebP之后图片质量也没有改变。
  • 使用第三方图片加载框架
  • 网络缓存
  • 监听网络状态，非WiFi下可以显示无图页面，WiFi或4G情况下才显示有图页面。
  • IP直连与HttpDns：DNS解析的失败率占联网失败中很大一种，而且首次域名解析一般需要几百毫秒。针对此，我们可以不用域名，才用IP直连省去 DNS 解析过程，节省这部分时间。HttpDNS基于Http协议的域名解析，替代了基于DNS协议向运营商Local DNS发起解析请求的传统方式，可以避免Local DNS造成的域名劫持和跨网访问问题，解决域名解析异常带来的困扰。

电量优化

电量分析工具

1、Batterystats & bugreport

Android 5.0及以上的设备, 允许我们通过adb命令dump出电量使用统计信息.

因为电量统计数据是持续的, 会非常大, 统计我们的待测试App之前先reset下, 连上设备,命令行执行:

$ adb shell dumpsys batterystats --reset
Battery stats reset.

断开测试设备, 操作我们的待测试App，重新连接设备, 使用adb命令导出相关统计数据:

// 此命令持续记录输出, 想要停止记录时按Ctrl+C退出.
$ adb bugreport > bugreport.txt

导出的统计数据存储到bugreport.txt, 此时我们可以借助如下工具来图形化展示电池的消耗情况。

2、Battery Historian

Google提供了一个开源的电池历史数据分析工具

Battery Historian链接

耗电原因
  • 网络请求
  • 使用WakeLock：WakeLock会保持CPU运行,或是防止屏幕变暗/关闭,让手机可以在用户不操作时依然运行。CPU会一直得不到休眠, 而大大增加耗电.
  • GPS
  • 蓝牙传输

建议：
根据具体业务需求，严格限制应用位于后台时是否禁用某些数据传输，尽量能够避免无效的数据传输。
数据传输的频度问题，如网络请求可以压缩合并，如本地数据上传，可以选择恰当的时机上传。

JobScheduler组件

通过不停的唤醒CPU（通过后天常驻的Service）来达到一些功能的使用，这样会造成电量资源的消耗，比如后台日志的上报，定期更新数据等等，在Android 5.0提供了一个JobScheduler组件，通过设置一系列的预置条件，当条件满足时，才执行对应的操作，这样既能省电，有保证了功能的完整性。

JobScheduler的适用场景：

  • 重要不紧急的任务，可以延迟执行，比如定期数据库数据更新和数据上报
  • 耗电量较大的任务，比如充电时才执行的备份数据操作。
  • 不紧急可以不执行的网络任务，比如在Wi-Fi环境下预加载数据。
  • 可以批量执行的任务
  • …等等

JobScheduler的使用

private Context mContext;
private JobScheduler mJobScheduler;

public JobSchedulerManager(Context context){
this.mContext=context;
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
this.mJobScheduler= (JobScheduler) mContext.getSystemService(Context.JOB_SCHEDULER_SERVICE);
}
}

通过getSystemService()方法获取一个JobSchedule的对象。

public boolean addTask(int taskId) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
JobInfo.Builder builder = new JobInfo.Builder(taskId,
new ComponentName(“com.apk.administrator.loadapk”,
JobScheduleService.class.getName()));
switch (taskId) {
case 1:
//每隔1秒执行一次
builder.setPeriodic(1000);
break;
case 2:
//设备重启后，不再执行该任务
builder.setPersisted(false);
break;
default:
break;
}
if (null != mJobScheduler) {
return mJobScheduler.schedule(builder.build()) > 0;
} else {
return false;
}
} else {
return true;
}
}

创建一个JobInfo对象时传入两个参数，第一个参数是任务ID，可以对不同的任务ID做不同的触发条件，执行任务时根据任务ID执行具体的任务；第二个参数是JobScheduler任务的服务，参数为进程名和服务类名。

JobInfo支持以下几种触发条件：

  • setMinimumLatency(long minLatencyMillis)：设置任务的延迟时间（单位是ms），需要注意的是，setMinimumLatency与setPeriodic(long time)方法不兼容，同时调用会引起异常。
  • setOverrideDeadline(long maxExecutionDelayMillis)：设置任务最晚的延迟时间。如果到了规定时间，其它条件还未满足，这个任务也会被启动。与setMinimumLatency(long time)一样，setOverriddeDeadline与setPeriodic(long time)同时调用会引起异常。
  • setPersisted(boolean isPersisted)：设置重启之后，任务是否还要继续执行。
  • setRequiredNetworkType(int networkType)：只有满足指定的网络条件时，才会被执行。有三种网络条件，JobInfo.NETWORK_TYPE_NONE不管是否有网络，这个任务都会被执行（如果未设置，这个参数就是默认参数）；JobInfo.NETWORK_TYPE_ANY只有在有网络的情况下，任务才会执行，和网络类型无关；JobInfo.NETWORK_TYPE_UNMETERED非运营商网络（比如在Wi-Fi连接时），任务才会被执行。
  • setRequiresCharging(boolean * requiresCharging)：只有当设备在充电时，这个任务才会被执行。
    setRequiresDeviceIdle(boolean * requiresDeviceIdle)：只有当用户没有在使用该设备且有一段时间没有使用时，才会启动该任务。

public class JobScheduleService extends JobService {
@Override
public boolean onStartJob(JobParameters params) {
return false;
}

@Override
public boolean onStopJob(JobParameters params) {
return false;
}
}

JobService运行在主线程，如果是耗时任务，使用ThreadHandler或者一个异步任务来运行耗时的任务，防止阻塞主线程。
务都会被执行（如果未设置，这个参数就是默认参数）；JobInfo.NETWORK_TYPE_ANY只有在有网络的情况下，任务才会执行，和网络类型无关；JobInfo.NETWORK_TYPE_UNMETERED非运营商网络（比如在Wi-Fi连接时），任务才会被执行。

  • setRequiresCharging(boolean * requiresCharging)：只有当设备在充电时，这个任务才会被执行。
    setRequiresDeviceIdle(boolean * requiresDeviceIdle)：只有当用户没有在使用该设备且有一段时间没有使用时，才会启动该任务。

public class JobScheduleService extends JobService {
@Override
public boolean onStartJob(JobParameters params) {
return false;
}

@Override
public boolean onStopJob(JobParameters params) {
return false;
}
}

JobService运行在主线程，如果是耗时任务，使用ThreadHandler或者一个异步任务来运行耗时的任务，防止阻塞主线程。

上一篇：java word文档导出统计功能


下一篇：js 实现call