每个人都知道一个 App 的成功&＃xff0c;与这个 App 的性能体验有着很密切的关系。但是如何让你的 App 拥有极致性能体验呢&＃xff1f;在 DroidCon NYC 2015 的这个分享里&＃xff0c;Boris Farber 带来了他关于 Android Api 以及如何避免一些常见坑的经验。带你了解如何缩短启动时间&＃xff0c;优化滑动效果&＃xff0c;创建更加顺滑的用户体验。
简介
大家好&＃xff0c;我是 Boris&＃xff0c;现在是 Google 的一枚员工&＃xff0c;目前专注于需要高性能的 App。这个分享是我长期以来从错误中&＃xff0c;以及在给合作伙伴做咨询的时候攒下的最佳实践。如果你有一个小型的 App&＃xff0c;读过之后&＃xff0c;会在你的 App 成长阶段起到帮助。
我常常会见到那些启动时间很长&＃xff0c;滑动不流畅&＃xff0c;甚至出现没有反应的 App。我们通常要花很多时间去改善这些问题&＃xff0c;毕竟我们都希望自己的 App 能够成功。
Activity 泄漏
我们第一个需要修复的问题就是 Activity 泄漏&＃xff0c;我们先来看看内存泄漏是怎么发生的。 Activity 泄漏通常是内存泄漏的一种。为什么会泄漏呢&＃xff1f;如果你持有一个未使用的 Activity 的引用&＃xff0c;其实也就持有了 Activity 的布局&＃xff0c;自然也就包含了所有的 View。最棘手的是持有静态引用。别忘了&＃xff0c;Activity 和 Fragment 都有自己的生命周期。一旦我们持有了静态引用&＃xff0c;Activity 和 Fragment 就不会被垃圾回收器清理掉了。这就是为什么静态引用很危险。
- m_staticActivity &＃61; staticFragment.getActivity()
我看过太多次这样的代码了。
另外&＃xff0c;泄漏 Listener 也是经常会发生的事情。比如说&＃xff0c;我有下面的代码。LeakActivity继承自 Activity&＃xff0c;我们有一个单例&＃xff1a;NastyManager&＃xff0c;当我们通过 addListener(this) 将 Activity 作为 Listener 和 NastyManager 绑定起来的时候&＃xff0c;不好的事情就发生了。
- public class LeakActivity extends Activity {
- &＃64;Override
- protected void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- NastyManager.getInstance().addListener(this);
- }
- }
想要修复这样的 Bug&＃xff0c;其实相当简单&＃xff0c;就是在你的 Acitivity 被销毁的时候&＃xff0c;将他和 NastyManager 取消掉绑定就好了。
- &＃64;Override
- public void onDestroy() {
- super.onDestroy();
- NastyManager.getInstance().removeListener(this);
- }
相对上面的解决方案&＃xff0c;我们自然还有更好的。比如我们真的需要用到单例吗&＃xff1f;通常&＃xff0c;并不需要。不过某些时候可能真的很需要。我们得权衡和设计。不过无论如何&＃xff0c;记住&＃xff0c;当 Activity 销毁的时候&＃xff0c;在单例中移除掉对 Activity 的引用。下面我们讨论下&＃xff1a; 如果是内部类&＃xff0c;会发生什么&＃xff1f;比如说&＃xff0c;我们有一个在 Activity 里有一个很简短的非静态 Handler。
尽管它看起来很短&＃xff0c;但是只要它还存活着&＃xff0c;那么包含它的 Activity 就会存活着。如果你不信我&＃xff0c;在 VM 里试试看。这就是另一个内存泄漏的案例&＃xff1a;Activity 内部的 Handler。
- public class MainActivity extends Activity {
- //...
- Handler handler;
- &＃64;Override
- protected void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- //...
- handler &＃61; new Handler() {
- &＃64;Override
- public void handleMessage(Message msg) {
- }
- }
- }
Handler 是个很常用也很有用的类&＃xff0c;异步&＃xff0c;线程安全等等。如果有下面这样的代码&＃xff0c;会发生什么呢&＃xff1f;handler.postDeslayed &＃xff0c;假设 delay 时间是几个小时… 这意味着什么&＃xff1f;意味着只要 handler 的消息还没有被处理结束&＃xff0c;它就一直存活着&＃xff0c;包含它的 Activity 就跟着活着。我们来想办法修复它&＃xff0c;修复的方案是WeakReference&＃xff0c;也就是所谓的弱引用。垃圾回收器在回收的时候&＃xff0c;是会忽视掉弱引用的&＃xff0c;所以包含它的 Activity 会被正常清理掉。大概代码如下&＃xff1a;
概括来说&＃xff1a;我们有个内部类&＃xff0c;就像 Handler&＃xff0c;内部非静态类是不能脱离所属类而单独存活的&＃xff0c;Android 里通常是 Activity。所以&＃xff0c;看看你的代码里的内部类&＃xff0c;确保他们没有出现内存泄漏。
相比非静态内部类&＃xff0c;最好使用静态内部类。区别就是静态内部类不依赖所属类&＃xff0c;他们拥有不同的生命周期。我经常见到类似的原因引起的内存泄露。
如何避免 Activity 泄漏?
- 移除掉所有的静态引用。
- 考虑用 EventBus 来解耦 Listener。
- 记着在不需要的时候&＃xff0c;解除 Listener 的绑定。
- 尽量用静态内部类。
- 做 Code Review。个人经验&＃xff1a;Code Review 能很早的发现内存泄漏。
- 了解你程序的结构。
- 用类似 MAT&＃xff0c;Eclipse Analyzer&＃xff0c;LeakCanary 这样的工具分析内存。
- 在 Callback 里打印 Log。
滑动
实现流畅滑动的技巧&＃xff1a;UI 线程只用作 UI 渲染。这一条真谛能够解决 99% 的滑动卡顿问题。不要在 UI 线程做下面的事情&＃xff1a;
- 载入图片
- 网络请求
- 解析 JSON
- 读取数据库
做这些操作是很慢的&＃xff0c;像图片&＃xff0c;网络&＃xff0c;JSON考虑用现成的库&＃xff0c;有很多社区提供的解决方案&＃xff0c;数据库考虑下用 Loader&＃xff0c;支持批量更新和载入。
图片
图片相关的库有很多&＃xff0c;比如 Glide, Picasso, Fresco。你可以自己去了解下他们之间的区别&＃xff0c;以帮助自己在特定场景下做出取舍。
内存
Bitmap 操作是很需要技巧的&＃xff0c;图片一般比较大&＃xff0c;而且系统对最大内存又有限制和要求。在我面对 4.0 之前的系统的时候&＃xff0c;我简直要崩溃了。内存管理也很需要技巧。有的时候需要放到文件里&＃xff0c;有的时候需要放到内存里&＃xff0c;别忘了&＃xff0c;我们还有一个很有用的工具&＃xff1a;LRUCache。
网络
首先&＃xff0c;Java 的网络请求确实是 Android 的一个阻碍。很多 Java.net 的 API 都是阻断执行的&＃xff0c;切记不可在 UI 线程执行网络请求。在线程里执行或者直接使用第三方库吧。
异步 HTTP 其实也挺麻烦的&＃xff0c;4.4 起 OkHttp 就成了 Android 代码的一部分了&＃xff0c;然而… 如果你需要最新版本的 OkHttp &＃xff0c;可以考虑自己引入。另外有个不错的库叫&＃xff1a; Volley&＃xff0c;也可以试试 Square 的 Retrofit。这些都能让你的网络请求变得更友好。
大 JSON
在 UI 线程&＃xff0c;也不做解析 Json 的事情&＃xff0c;因为这是一个很耗时的事情。试着用 Google 的 GSON 来做反序列化的操作。
对于巨大的 JSON 解析&＃xff0c;建议用更快的 Jackson 以及 ig-json-parser&＃xff0c;这两个工具在 JSON 的解析上做的非常漂亮。从公司的反馈结果来看 ig-json-parser 的效率是最高的。
Looper.myLooper() &＃61;&＃61; Looper.getMainLooper() 是可以帮助你确定你是否在主线程的代码。
如何优化滑动速度?
- UI 线程只做 UI 更新。
- 理解并发 API。
- 开始使用优秀的第三方库。
- 使用 Loader 加载数据库数据
之所以要用第三方库&＃xff0c;是因为你自己去完善一个复杂功能是需要花时间的。如果你打算专注在自己的功能性的 App 上&＃xff0c;那么用库吧。
并发 APIs
如何让 App 快速响应请求是个很重要。开发者们&＃xff0c;甚至包括我&＃xff0c;经常忘记 Service 的方法是在 UI 线程执行的。请考虑使用 IntentService&＃xff0c;AsyncTask&＃xff0c;Executors&＃xff0c;Handler 和 Loopers。
我们来盘点下这些的区别&＃xff1a;
IntentService
我在之前的公司&＃xff0c;我用 IntentService 来执行上传功能。IntentService 是一个单线程&＃xff0c;一次一个任务的工作流。我们没有很复杂的任务系统。如果你有大型复杂的任务&＃xff0c;而且这个任务不需要跟 UI 打交道&＃xff0c;那么考虑用 IntentService 吧。
AsyncTask
如果你的任务需要更新 UI&＃xff0c;那么考虑用 AsyncTask 吧&＃xff0c;AsyncTask 虽然相对容易&＃xff0c;但是有些坑得留意。当你旋转手机的时候&＃xff0c;Activity 会被关闭&＃xff0c;然后重启。不然可能造成内存泄露。
Executor Framework
这是 Java 6 自带的并发方案。默认是存在一个由系统管理的线程池&＃xff0c;你可以通过 callback&＃xff0c;future 来控制和管理。这根 MapRedues 发难有点像&＃xff0c;面对复杂的任务&＃xff0c;你希望能够把他们拆分交给多个线程来处理。Executor 的框架就很能胜任这种场景。
如何适应并发APIs?
- 学会和理解 API&＃xff0c;懂得权衡
- 确保找到了问题的正确解决方案
- 了解问题真实所在
- 重构代码
Deprecation
我们肯定都知道&＃xff0c;最好能够避免使用废弃的 API。比如以下的例子&＃xff1a;
- 不要通过反射来调用私有 API。
- 不要再 NDK 和 C 语言层调用私有 Native 方法。
- 不要轻易调用 Runtime.exec 指令完成进程通讯功能。
- adb shell am 做进程通讯并不好。
废弃的意思是这些 API 将会被移除&＃xff0c;通常在正式版发布 1&＃xff0c;2天左右&＃xff0c;你的 App 就不会工作了。更糟糕的情况是&＃xff0c;如果你的 App 依赖了一些库&＃xff0c;而这些库哟改了废弃的 Api 或者工具。那可就惨了&＃xff0c;如果一旦作者没有更新…你懂得。
不要用废弃 Api 的另一个原因是性能问题和安全问题。
如何避免废弃 Api&＃xff1a;
- 使用正确的 API。
- 重构依赖。
- 不要滥用系统。
- 更新依赖和工具。
- 越新的通常越好。
用 Toolbar 而非 ActionBar&＃xff0c;在需要动画的时候用 RecyclerView&＃xff0c;因为它专门为动画做过优化。同时 Android M 里移除了 Apache Http Connection。请使用 HttpURLConnection&＃xff0c;它拥有更简单的 API&＃xff0c;更小的体积&＃xff0c;默认的压缩功能&＃xff0c;更好的 Response 缓存&＃xff0c;等等其他很赞的功能。
架构
架构中的 Bug 总是最为烦人。想要避免这种问题&＃xff0c;学习下 App 组件的生命周期。比如什么是 Activity 的 Flag&＃xff1f;什么是 Fragment&＃xff1f;什么事 stated fragment&＃xff1f;什么是 task&＃xff1f;读读文档&＃xff0c;尝试下用回调的 log 搞清楚这些概念。
时常有人问我&＃xff1a;“Picasso 和 Glide 哪个更好&＃xff1f;我改用 Volley 还是 OkHttp&＃xff1f;”&＃xff0c;这种问题根本没有 100% 正确的答案。不过&＃xff0c;当我在选择一个库的时候&＃xff0c;我会用下面的 Checklist 来决策&＃xff1a;
- 确保它能够解决你的问题。
- 确保它和当前所有的依赖能正常工作。
- 检查依赖
- 留意一下依赖的版本冲突
- 了解维护情况和成本
总的来说&＃xff0c;提及架构和设计&＃xff0c;最好的方法就是让你的程序最快响应。确保用户能够快速理解你的 App&＃xff0c;并且拥有良好体验。
本文转自&＃xff1a;https://realm.io/cn/news/droidcon-farber-improving-android-app-performance/
京公网安备 11010802041100号