안드로이드 성능 향상을 위한 제안

앱의 성공이 앱의 성능 경험과 밀접한 관련이 있다는 것은 누구나 알고 있습니다. 하지만 앱이 최고의 성능을 경험하게 하려면 어떻게 해야 할까요? DroidCon NYC 2015의 이 강연에서 Boris Farber는 Android API에 대한 자신의 경험과 몇 가지 일반적인 함정을 피하는 방법을 소개합니다. 시작 시간을 단축하고, 슬라이딩 효과를 최적화하고, 보다 원활한 사용자 경험을 만드는 방법을 알아보세요.

소개

안녕하세요 여러분. 저는 현재 Google에 입사하여 고성능이 필요한 앱을 담당하고 있는 보리스입니다. 이 공유는 제가 오랜 시간 동안 저의 실수와 파트너와의 상담을 통해 축적한 모범 사례입니다. 작은 앱을 가지고 있다면 이 글을 읽으면 앱의 성장 단계에 도움이 될 것입니다.

시작하는 데 시간이 오래 걸리거나, 매끄럽게 슬라이드되지 않거나, 응답하지 않는 앱을 ​​자주 봅니다. 우리는 일반적으로 이러한 문제를 개선하는 데 많은 시간을 소비합니다. 결국 우리 모두는 앱이 성공하기를 원합니다.

Activity Leak

가장 먼저 해결해야 할 문제는 ​​Activity Leak 입니다. 먼저 메모리 누수가 어떻게 발생하는지 살펴보겠습니다. 활동 누수는 일반적으로 메모리 누수 유형입니다. 왜 누출되나요? 사용되지 않은 활동에 대한 참조를 보유하는 경우 실제로 모든 뷰를 포함하는 활동의 레이아웃을 보유하게 됩니다. 가장 까다로운 것은 정적 참조를 유지하는 것입니다. Activity와 Fragment에는 고유한 수명 주기가 있다는 점을 잊지 마세요. 정적 참조를 보유하면 활동 및 조각이 가비지 수집기에 의해 정리되지 않습니다. 이것이 바로 정적 참조가 위험한 이유입니다.

m_staticActivity = staticFragment.getActivity()

이 코드를 너무 많이 봤습니다.

또한 Listener가 유출되는 일도 다반사입니다. 예를 들어 다음 코드가 있습니다. LeakActivity는 Activity에서 상속받습니다. NastyManager라는 싱글톤이 있습니다. addListener(this)를 통해 Activity를 Listener와 NastyManager로 바인딩하면 나쁜 일이 발생합니다.

public class LeakActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); NastyManager.getInstance().addListener(this);  
  }  
}

이 버그를 수정하는 방법은 실제로 매우 간단합니다. 활동이 삭제되면 NastyManager에서 바인딩을 해제하면 됩니다.

@Override public void onDestroy() { super.onDestroy();  
  NastyManager.getInstance().removeListener(this);  
}

위의 솔루션과 비교하면 당연히 더 나은 솔루션이 있습니다. 예를 들어, 정말로 싱글톤을 사용해야 할까요? 일반적으로 필요하지 않습니다. 하지만 때로는 정말 필요할 수도 있습니다. 우리는 무게를 재고 디자인해야 합니다. 하지만 무슨 일이 있어도 Activity가 소멸되면 해당 Activity에 대한 참조가 싱글톤에서 제거된다는 점을 기억하세요. 아래에서 논의해 봅시다: 내부 클래스라면 어떻게 될까요? 예를 들어 활동에는 매우 짧은 비정적 핸들러가 있습니다.

짧아 보여도 그것이 살아있는 한, 그것을 담은 활동도 살아있을 것입니다. 믿을 수 없다면 VM에서 시도해 보세요. 이는 메모리 누수의 또 다른 경우입니다. 활동 내부의 핸들러입니다.

public class MainActivity extends Activity { //...  Handler handler; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); 
//...  handler = new Handler() { @Override public void handleMessage(Message msg) {  
              }  
  }  
}

핸들러는 비동기식, 스레드 안전성 등 매우 일반적이고 유용한 클래스입니다. 다음과 같은 코드가 있다면 어떻게 될까요? handler.postDeslayed, 지연 시간이 몇 시간이라고 가정하면... 이것은 무엇을 의미합니까? 즉, 핸들러의 메시지가 처리되지 않은 한 메시지는 항상 활성화되고 이를 포함하는 활동도 활성화됩니다. 이를 해결할 수 있는 방법을 찾아보겠습니다. 바로 Weak Reference라고 불리는 WeakReference입니다. 가비지 수집기는 재활용 시 약한 참조를 무시하므로 해당 참조가 포함된 활동은 정상적으로 정리됩니다. 대략적인 코드는 다음과 같습니다.

요약: Handler와 마찬가지로 내부 클래스가 있습니다. 내부 비정적 클래스는 Android에서 일반적으로 Activity입니다. 따라서 코드의 내부 클래스를 살펴보고 메모리 누수가 없는지 확인하세요.

비정적 내부 클래스보다 정적 내부 클래스를 사용하는 것이 더 좋습니다. 차이점은 정적 내부 클래스는 자신이 속한 클래스에 의존하지 않고 수명 주기가 다르다는 것입니다. 비슷한 이유로 메모리 누수가 발생하는 경우를 자주 봅니다.

활동 유출을 방지하는 방법은 무엇인가요?

移除掉所有的静态引用。
考虑用 EventBus 来解耦 Listener。
记着在不需要的时候，解除 Listener 的绑定。
尽量用静态内部类。
做 Code Review。个人经验：Code Review 能很早的发现内存泄漏。
了解你程序的结构。
用类似 MAT，Eclipse Analyzer，LeakCanary 这样的工具分析内存。
在 Callback 里打印 Log。

스와이프

实现流畅滑动的技巧：UI 线程只用作 UI 渲染。这一条真谛能够解决 99% 的滑动卡顿问题。不要在 UI 线程做下面的事情：

载入图片
网络请求
解析 JSON 读取数据库

做这些操作是很慢的，像图片，网络，JSON考虑用现成的库，有很多社区提供的解决方案，数据库考虑下用 Loader，支持批量更新和载入。

图片

图片相关的库有很多，比如 Glide, Picasso, Fresco。你可以自己去了解下他们之间的区别，以帮助自己在特定场景下做出取舍。

内存

Bitmap 操作是很需要技巧的，图片一般比较大，而且系统对最大内存又有限制和要求。在我面对 4.0 之前的系统的时候，我简直要崩溃了。内存管理也很需要技巧。有的时候需要放到文件里，有的时候需要放到内存里，别忘了，我们还有一个很有用的工具：LRUCache。

网络

首先，Java 的网络请求确实是 Android 的一个阻碍。很多 Java.net 的 API 都是阻断执行的，切记不可在 UI 线程执行网络请求。在线程里执行或者直接使用第三方库吧。

异步 HTTP 其实也挺麻烦的，4.4 起 OkHttp 就成了 Android 代码的一部分了，然而… 如果你需要最新版本的 OkHttp ，可以考虑自己引入。另外有个不错的库叫： Volley，也可以试试 Square 的 Retrofit。这些都能让你的网络请求变得更友好。

大 JSON

在 UI 线程，也不做解析 Json 的事情，因为这是一个很耗时的事情。试着用 Google 的 GSON 来做反序列化的操作。

对于巨大的 JSON 解析，建议用更快的 Jackson 以及 ig-json-parser，这两个工具在 JSON 的解析上做的非常漂亮。从公司的反馈结果来看 ig-json-parser 的效率是最高的。

Looper.myLooper() == Looper.getMainLooper() 是可以帮助你确定你是否在主线程的代码。

如何优化滑动速度?

UI 线程只做 UI 更新。
理解并发 API。
开始使用优秀的第三方库。
使用 Loader 加载数据库数据

之所以要用第三方库，是因为你自己去完善一个复杂功能是需要花时间的。如果你打算专注在自己的功能性的 App 上，那么用库吧。

并发 APIs

如何让 App 快速响应请求是个很重要。开发者们，甚至包括我，经常忘记 Service 的方法是在 UI 线程执行的。请考虑使用 IntentService，AsyncTask，Executors，Handler 和 Loopers。

我们来盘点下这些的区别：

IntentService

我在之前的公司，我用 IntentService 来执行上传功能。IntentService 是一个单线程，一次一个任务的工作流。我们没有很复杂的任务系统。如果你有大型复杂的任务，而且这个任务不需要跟 UI 打交道，那么考虑用 IntentService 吧。

AsyncTask

如果你的任务需要更新 UI，那么考虑用 AsyncTask 吧，AsyncTask 虽然相对容易，但是有些坑得留意。当你旋转手机的时候，Activity 会被关闭，然后重启。不然可能造成内存泄露。

Executor Framework

这是 Java 6 自带的并发方案。默认是存在一个由系统管理的线程池，你可以通过 callback，future 来控制和管理。这根 MapRedues 发难有点像，面对复杂的任务，你希望能够把他们拆分交给多个线程来处理。Executor 的框架就很能胜任这种场景。

如何适应并发APIs?

学会和理解 API，懂得权衡
确保找到了问题的正确解决方案
了解问题真实所在
重构代码

Deprecation

我们肯定都知道，最好能够避免使用废弃的 API。比如以下的例子：

不要通过反射来调用私有 API。
不要再 NDK 和 C 语言层调用私有 Native 方法。
不要轻易调用 Runtime.exec 指令完成进程通讯功能。
adb shell am 做进程通讯并不好。

废弃的意思是这些 API 将会被移除，通常在正式版发布 1，2天左右，你的 App 就不会工作了。更糟糕的情况是，如果你的 App 依赖了一些库，而这些库哟改了废弃的 Api 或者工具。那可就惨了，如果一旦作者没有更新…你懂得。

不要用废弃 Api 的另一个原因是性能问题和安全问题。

如何避免废弃 Api：

使用正确的 API。
重构依赖。
不要滥用系统。
更新依赖和工具。
越新的通常越好。

用 Toolbar 而非 ActionBar，在需要动画的时候用 RecyclerView，因为它专门为动画做过优化。同时 Android M 里移除了 Apache Http Connection。请使用 HttpURLConnection，它拥有更简单的 API，更小的体积，默认的压缩功能，更好的 Response 缓存，等等其他很赞的功能。

架构

架构中的 Bug 总是最为烦人。想要避免这种问题，学习下 App 组件的生命周期。比如什么是 Activity 的 Flag？什么是 Fragment？什么事 stated fragment？什么是 task？读读文档，尝试下用回调的 log 搞清楚这些概念。

时常有人问我：“Picasso 和 Glide 哪个更好？我改用 Volley 还是 OkHttp？”，这种问题根本没有 100% 正确的答案。不过，当我在选择一个库的时候，我会用下面的 Checklist 来决策：

确保它能够解决你的问题。
确保它和当前所有的依赖能正常工作。
检查依赖
留意一下依赖的版本冲突
了解维护情况和成本

总的来说，提及架构和设计，最好的方法就是让你的程序最快响应。确保用户能够快速理解你的 App，并且拥有良好体验。