Question

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

Answer 1

Android在开发和学习过程中要注意的点：
1、 在Androidlibrary中不能使用switch-case语句访问资源ID；
2、 不能在Activity没有完全显示时显示PopupWindow和Dialog；
3、 在多进程之间不要用SharedPreferences共享数据，虽然可以（MODE_MULTI_PROCESS），但极不稳定；
4、 有些时候不能使用Application的Context，不然会报错（比如启动Activity，显示Dialog等）：
5、 Android的JNI代码中，有返回类型的函数没有返回值编译的时候也不会报错；
6、 不要在非UI线程中初始化ViewStub，否则会返回null；
7、 不要通过Bundle传递大块的数据，否则会报TransactionTooLargeException异常：
8、 尽量不要使用AnimationDrawable，它在初始化的时候就将所有图片加载到内存中，特别占内存，并且还不能释放，释放之后下次进入再次加载时会报错；
9、 Eclipse的Android开发环境配置好后不要轻易升级ADT和build tools，不然会浪费很多时间，还有就是一个workspace中的工程不要太多，不然每次启动都会很慢；

Answer 2

1、不要排斥新技术和新工具。 Android Studio 1.0 之后的版本，基本已经稳定到可以支持正常的工作开发的程度了。单纯就书写效率而言，Android Studio 带来的好处绝对大于它和Gradle的学习成本。JetBrains的IDE，用过都说好。还有就是适当的提升targetSdkVer… 显示全部
　　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()。

Answer 3

　　1、不要排斥新技术和新工具。 Android Studio 1.0 之后的版本，基本已经稳定到可以支持正常的工作开发的程度了。单纯就书写效率而言，Android Studio 带来的好处绝对大于它和Gradle的学习成本。JetBrains的IDE，用过都说好。还有就是适当的提升targetSdkVer… 显示全部
　　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()。