1、优化布局 多数开发者人为使用基本布局结构会产生高效的布局性能,其实这个想法是不完全正确。我们每一个添加到应用的控件和布局,都需要初始化,布局,绘制,这些多是需要时间降低显示速度。另外,嵌套多个使用layout_weight属性的Linearlayout实例会花费更大的代价,因为每一个布局都要测量两次,如果这种布局使用在Listview或者GrideView中,渲染是更耗时。
在布局优化中,Android官方提到了这三种布局 include、merge、Viewstub并介绍这三种布局各有优势,布局重用,减少视图层级,需要时加载。
2、Android UI优化
HierarchyView工具,后续补充。
3、代码优化
使用Android lint工具,代码优化主要是减少版本迭代过程遗留的无用代码,以及开发过程中废弃代码,当然也可以有效的帮助开发者找到内存泄漏问题。
Android studio 如图点击Inspect Code后根据提示可以选择
Whole project 或者Module app等一会就会在控制状态显示代码分析,找到androidLint 的Unuse resourse 就是没有用到的资源文件可以删除。当然也会有内存泄露部分代码的提示根据提示修改代码。
4、apk瘦身
如上所述根据Lint工具检测出的无用文件的删除可以缩小安装包,当然还可以通过studio Build的Analyze Apk来分析apk中到底哪些文件比较大,据我分析文件资源的图片和三方库比较大,所以做图片适配的时候大多数产品有一套图放到xhdpi中适配就可以了。
5、内存泄露优化
常见内存泄漏原因
- 资源对象没关闭。
如Cursor、File等资源。他们会在finalize中关闭,但这样效率太低。容易造成内存泄露。
SQLiteCursor,当数据量大的时候容易泄露 - 使用Adapter时,没有使用系统缓存的converView。
- 即时调用recycle()释放不再使用的Bitmap。
适当降低Bitmap的采样率,如:BitmapFactory.Options options = newBitmapFactory.Options(); options.inSampleSize = 2;//图片宽高都为原来的二分之一,即图片为原来的四分之一 Bitmap bitmap =BitmapFactory.decodeStream(cr.openInputStream(uri), null, options); preview.setImageBitmap(bitmap);
- 使用application的context来替代activity相关的context。
尽量避免activity的context在自己的范围外被使用,这样会导致activity无法释放。 - 注册没取消造成内存泄露
如:广播 - 集合中的对象没清理造成的内存泄露我们通常把一些对象的引用加入到了集合中,当我们不需要该对象时,并没有把它的引用从集合中清理掉,这样这个集合就会越来越大。如果这个集合是static的话,那情况就更严重了。
- Handler应该申明为静态对象, 并在其内部类中保存一个对外部类的弱引用。如下:
staticclassMyHandlerextendsHandler { WeakReference<Activity > mActivityReference; MyHandler(Activity activity) { mActivityReference= new WeakReference<Activity>(activity); } @OverridepublicvoidhandleMessage(Message msg) { final Activity activity = mActivityReference.get(); if (activity != null) { mImageView.setImageBitmap(mBitmap); } } }