Android 开发中,有哪些坑需要注意?

楼主自己来一个,用appcompat21版的ActionBar高度默认是56Dp,不知道这个算不算
关注者
5180
被浏览
64466

90 个回答

1、不要排斥新技术和新工具。
Android Studio 1.0 之后的版本,基本已经稳定到可以支持正常的工作开发的程度了。单纯就书写效率而言,Android Studio 带来的好处绝对大于它和Gradle的学习成本。JetBrains的IDE,用过都说好。
还有就是适当的提升targetSdkVersion到新版本。

2、代码设计方面的问题,大部分都能在Android系统源码里找到解决方案。
当你想设计一个新模块,或者实现一个新ui组件的时候,应该采用哪些设计模式、应该以哪种形式给外界提供接口之类的问题,大部分都可以参考Android系统的源码,找到实现方式。Google为安卓程序员提供了一座现成的宝库。

3、理解Android和Java内存管理方式,至少要理解垃圾回收和Java的引用。
就好比学OC就要先理解黄金法则一样,而java的内存管理,其实比OC要好理解多了。
这可能会帮助你大大减少程序异步操作产生的空指针崩溃。也会帮助你理解为什么滥用单例模式会导致内存的臃肿。还会帮助你养成不用“+”去连接超大字符串的好习惯。

4、ContentProvider并不是只有在跨进程共享数据的才有用,把数据库表映射到一个独立的uri是Google鼓励的实现方式。
从设计上讲,用uri(统一资源标识符)去描述数据,肯定比sql语句要理想。
从效果上讲,用CursorLoader读取数据是让iOS程序员都羡慕不已的事情,作为android程序员,何苦不用呢。

5、理解Activity任务栈。
非Activity的Context对象如果直接启动Activity会报错,这只是一个表面现象,真正起作用的其实是Activity任务栈机制。
理解Activity任务栈机制以及Activity的各种启动方式,会帮助解决大部分页面关系错乱问题,以及应用互相掉起、任务栏进入应用、后台弹窗引起的各种问题。

6、对于一些奇葩的第三方ROM,调用其非主流api的时候,可以使用反射。
在适配一些第三方ROM的的时候,调用一些在开发环境中没有,但在运行环境中有的方法时,可以使用反射。比方说,华为双卡手机可能会提供获取第二块SIM卡信息的api,如果直接调用,在开发环境可能无法通过正常编译,用反射就没问题。这属于不得已而用反射的一种情况。

7、SQLite的锁,是数据库级别的锁,也就是说同一个数据库的写操作无法并发执行。
所以,在数据库设计的时候,如果表太多,尽量将没有关联的表拆到多个数据库文件中。

8、Bitmap的内存占用问题。
这是一个困扰2.X时代android程序员的问题。
2.X时代Bitmap对象虽然存储在堆内存中,但是用了一个byte数组存储其像素信息。通过计数器来记录该像素信息被引用的个数。有人认为这个byte数组在native堆中,但事实上它也在堆中。
只有在使用者调用recycle()后,Bitmap对象才会释放像素信息,才会在失去引用后,被垃圾回收机制销毁。再加上DVM的heap size有严格的阀值,所以在使用大量图片资源的时候,及其容易发生OOM。
解决办法一般都是,用一个哈希表存储Bitmap对象的软引用,作为内存缓存,并在适当时机掉用其recycle()。
3.0以上版本Bitmap对象可以通过垃圾回收机制完全销毁,理论上不用再调用recycle()。
作为一个有三、四年Android应用开发经验的码农,自然会遇到很多坑,下面是我能够想起的一些坑(实践证明不记笔记可不是个好习惯),后面有想到其它坑会陆续补上。


  • 有些时候不能使用Application的Context,不然会报错(比如启动Activity,显示Dialog等):

备注:大家注意看到有一些NO上添加了一些数字,其实这些从能力上来说是YES,但是为什么说是NO呢?下面一个一个解释:

1、数字1:启动Activity在这些类中是可以的,但是需要创建一个新的task,一般情况不推荐;

2、数字2:在这些类中去layout inflate是合法的,但是会使用系统默认的主题样式,如果你自定义了某些样式可能不会被使用;

3、数字3:在Receiver为null时允许,在4.2或以上的版本中,用于获取黏性广播的当前值。(可以无视);

4、ContentProvider、BroadcastReceiver之所以在上述表格中,是因为在其内部方法中都有一个context用于使用。


  • 同一个应用的JNI代码,不要轻易换NDK编译的版本,否则会有很多问题(主要是一些方法实现不一样,并且高版本对代码的检测更严格),比如r8没有问题,但到r9就有问题了,这是个大坑;

  • Android的JNI代码中,有返回类型的函数没有返回值编译的时候也不会报错;

  • 当前Activity的onPause方法执行结束后才会执行下一个Activity的onCreate方法,所以在onPause方法中不适合做耗时较长的工作,这会影响到页面之间的跳转效率;

  • 谨慎使用Android的透明主题,透明主题会导致很多问题,比如:如果新的Activity采用了透明主题,那么当前Activity的onStop方法不会被调用;在设置为透明主题的Activity界面按Home键时,可能会导致刷屏不干净的问题;进入主题为透明主题的界面会有明显的延时感;

  • 不要在非UI线程中初始化ViewStub,否则会返回null;

  • 公共接口一定要考虑到代码重入的情况,能设计为单例就尽量用单例;



  • (AnimationDrawable在Android5.0及以上的版本已有明显的优化)尽量不要使用AnimationDrawable,它在初始化的时候就将所有图片加载到内存中,特别占内存,并且还不能释放,释放之后下次进入再次加载时会报错;

  • 9图不能通过tinypng压缩,不然会有问题;

  • genymotion模拟器快是因为它是基于x86架构的,如果你的应用中用到了so,但没有x86架构的so,只能放弃使用它;Android Studio的模拟器也一样;

  • Eclipse的Android开发环境配置好后不要轻易升级ADT和build tools,不然会浪费你很多时间,还有就是一个workspace中的工程不要太多,不然每次启动都会很慢;

  • Android studio每个版本、gradle每个版本差别都比较大(我是这样认为的),对于jni代码的编译建议在Eclipse中进行,如果在Android studio中开发jni会浪费很多时间,主要是编译脚本的配置比较麻烦;

  • Eclipse中的Lint太不靠谱,特别是主工程中依赖library的时候,很多提示都是有问题的,建议使用Android Studio的工程清理工具,特别推荐;


  • 同一个应用,相同的图片分别放在drawable-xxhdpi、drawable-xhdpi、drawable-hdpi、drawable-mdpi、drawable-ldpi中,在同一设备中占用的内存会大不一样(设备的dpi是固定的,图片放在不同的dpi文件夹下,在设备上显示时需要将图片转换成和当前屏幕一样dpi后在设备中显示,所以即使该图片在不同dpi文件夹下大小一样,但放在内存中的大小却不是一样的,并不一定是长*宽*4),做应用的内存优化之前可以先看一看你的工程是如何做屏幕适配的,是否有优化的空间。强烈推荐这个屏幕适配视频教程,花两个半小时就能看完:Android-屏幕适配全攻略

  • 谨慎对待数据库升级(比如需要在原数据库中增加字段),避免数据丢失或者操作数据库异常的情况,数据库升级方法可以查阅《第一行代码》P263;

  • 多个程序共用一套代码(一套代码,在桌面上多个图标)时需要处理好不同入口进入时的堆栈问题;

  • 使用Adapter的时候,如果你使用了ViewHolder做缓存,在getView的方法中无论这项的每个视图是否需要设置属性(比如TextView设置的属性可能为null,item的某一个按钮的背景为透明、某一项的颜色为透明等),都需要为每一项的所有视图设置属性(textview的属性为空也需要设置setText(""),背景透明也需要设置),否则在滑动的过程中会出现内容的显示错乱。

  • 谨慎使用Android的多进程,多进程虽然能够降低主进程的内存压力,但会遇到如下问题:(1)不能实现完全退出所有Activity的功能(如果有同行在应用内采用多进程成功实现过完全退出程序欢迎沟通交流);(2)首次进入新启动进程的页面时会有延时的现象(有可能黑屏、白屏几秒,是白屏还是黑屏和新Activity的主题有关);(3)应用内多进程时,新启动一个进程都会重新跑一次Application的onCreate方法,不上重新创建一个Application,但会重新跑Application的onCreate,这样就不能在Application中缓存数据作为内存共享的途径了;(4)多进程间通过SharedPreferences共享数据时不稳定,具体可以查阅《Android开发艺术探索》。

  • 使用Toast时,建议定义一个全局的Toast对象,这样可以避免连续显示Toast时不能取消上一次Toast消息的情况(如果你有连续弹出Toast的情况,避免使用Toast.makeText);

  • View的面积越大绘制的时间就越长,透明通道对View的绘制速度影响很大;

  • 不要通过Msg传递大的对象,会导致内存问题。


  • Eclipse的工程转成AS的版本后,在同一个机器中安装会报”INSTALL_FAILED_VERSION_DOWNGRADE“这个错误,原因是因为as除了可以在Manifest.xml文件中设置apk的版本名和版本号,还可以在build.gradle文件中设置apk的版本名和版本号,记得修改build.gralde中的版本名和版本号到最新就可以了;

  • 通常情况下,在插入USB之后可能会跳转到一个新的界面,这时候可能你本来是横屏的,突然跳转到这个新界面是竖屏的,虽然你的界面被压在下面,但是还是会被强制横竖屏切换一次,如果这时候你的界面不做处理就会重载,如果你的界面里面有很多fragment,这时候的重载更加复杂,难以处理。所以建议不做横竖屏切换的界面都弄一下横竖屏切换不重载。

  • 如果你在 manifest 中把一个 activity 设置成 android:windowSoftInputMode="adjustResize",那么 ScrollView(或者其它可伸缩的 ViewGroups)会缩小,从而为软键盘腾出空间。但是,如果你在 activity 的主题中设置了 android:windowFullscreen="true",那么 ScrollView 不会缩小。这是因为该属性强制 ScrollView 全屏显示。然而在主题中设置 android:fitsSystemWindows="false" 也会导致 adjustResize 不起作用;

  • 做自定义手写功能时,底层上报的点并不会都在MotionEvent中能够及时接收到,比如底层一秒钟200个点,上层收到的可能只有几十个点,为了提高手写的流畅度,在onTouchEvent中,通过MotionEvent中的getHistorySize能够获取到从底层传输到上层过程中所有的点;

  • 在Android 4.0以后,在Manifest.xml中静态注册的广播,程序安装后必须启动一次才能接收到广播,比如你的应用监听开机启动的广播,必须要你的程序被运行过才能监听到;

  • 一个AS的工程中,module不宜太多,否则会影响编译的速度,建议将不是经常变动的module打包成aar,主工程直接依赖aar可以大大提高编译的速度;

  • 在AS中,如果你想动态同步一个依赖包的更新,可以在依赖包的最后面写上“+”,比如:
compile 'com.android.support:appcompat-v7:23.0.+' 
,但这种方法需要谨慎使用,否则会因为依赖包的变动导致你的项目不稳定:Don't use dynamic versions for your dependencies

  • release版本的apk需要签名才能正常安装;

  • 在2.3之前GC操作是不能并发进行的,也就是系统正在进行GC程序就只能阻塞住等待GC结束,在2.3之后GC操作改成了并发的方式进行,GC过程中不会影响程序的正常运行,但在GC操作的开始和结束还是会短暂阻塞一段时间。所以频繁的GC会导致使用应用的过程中卡顿,所以为了应用在使用过程中更流畅,需要尽量减少触发GC操作,这涉及到性能优化,对于静态代码的分析,AS已经很强大了,可以使用Android Studio的Analyze→Inspect Code...进行分析;

  • 尽量避免给window和Activity同时都设置了背景,这样会造成过渡绘制,可以通过在给Activity设置主题时,去掉windowBackground背景的方式减少一层过渡绘制,有时候为了避免进入Activity时会黑屏或者白屏(和主题有关),会在给Activity设置主题的时候给window设置背景,如果这种情况下给Activity也设置了背景,是会增加一倍内存的:
<item name="android:windowBackground">@null</item>

  • 一个类的finalize方法调用时机是不确定的,应该避免指望通过这个方法去释放与类相关的资源,否则会导致一些随机bug;

  • Activity的onDestory方法调用时机是不确定的(有时候离开界面很久之后才会调用onDestory方法),应该避免指望通过onDestory方法去释放与Activity相关的资源,否则会导致一些随机bug;

  • 不要指望MAT明确告诉你哪里存在内存泄露,它只会提供各个类间的引用关系,所以可以通过leakcanary或者通过adb shell dumpsys meminfo packagename查看进入/退出一个界面后activity和views数量的变化情况,来初步定位可能存在内存泄露的地方,然后通过MAT工具找到具体的地方。

关于更多Android开发方面的文章,可以看看我的专栏:张明云的知识共享 - 知乎专栏
知识面有限,有很多没有深入理解的知识点,可能会导致理解上的偏差,欢迎指正交流~~~
为什么?