一些个人的开发经验

  真正接触开发Android，已经差不多有接近两年了，从一开始学校设立的 Android 开发基础课启蒙，之后懵懵懂懂的入门，学习。到之后的实习，工作。一路跌跌撞撞，踩过不少的坑，自己也挖了不少的坑，然后也填了不少的坑。两年时间，说长不长，说短不短，在一路的摸索学习中，也渐渐的积累了一些的经验，或者说是 tips 吧，不一定是对的、最好的处理方法。如果有什么好的建议，或者不对的地方，欢迎各位简友指出哦~

分享一波 github 上记录的 Tip1

正文

1.因为 图片加载框架很多，所以在对 Imageview 绑定资源的时候尽量解耦开，可以在一个 Util 中统一处理 ImageView 的绑定，在平常使用中只传 imageView 和 URL 给 Util.setImage()就行，不关心具体使用那一个框架，这样方便在以后切换图片加载框架

2.在使用 logger 工具时，也可以使用如上的方式

3.单独使用一个单例来管理全局的变量，数据，其中持有的 context 最好是 application 的，防止内存泄漏。单例也要注意加锁、同步，保证线程安全

4.创建新的 activity 或者 fragment 时，对于复杂的，非必须马上进行的，或者网络操作都要延时处理，以加快界面创建速度、切换速度。

5.对于所有的延时操作，要注意防止内存泄漏，尽量不持有外部变量，或尽量使用弱引用

6.对于所有的延时操作，也要注意对空置检查，例如在界面创建5秒之后进行 TextVIew.setText();如果用户没有等到5秒就返回从而触发了 onDestroy();这样就很容易触发 NPE 从而 crash

7.最好自定义一个 crashHandler 用于捕捉异常并打印 log

8.最好介入类似 bugly 的组件用于捕获线上正式版本的异常并及时解决（在开发环境中需要关闭，避免开发引发的异常污染线上环境）

9.最好全局定义一个 release 标志或者 debug 标志用于标志当前的是否为开发环境，然后对于一些sdk 或者一些操作做开发/正式环境的区别初始化或区别处理。例如在判断到设置的 releaseFlag 为 true 是才初始化 bugly 来进行捕获异常，但是却关闭 log 的输出等

10.多写注释，因为你也不能保证一个月后自己还能看懂这段代码的作用

11.命名真的要规范，尽量做到只看命名就可以知道其作用。文件的命名也要有技巧，尽量使用：模块_组件_作用 或者其他统一的命名规则，方便自己查找对应的文件，例如 staff_fragment_layout.xml，staff_listview_item_layout.xml,staff_listview_adapter.java,staff_fragment.java等等，这样就能很清楚的知道那个是 staff 模块的界面，哪个是 staff 模块下 listview 的 item 界面及它的适配器

12.使用一个第三方库的时候，一定要想清楚，这是不是一个成熟的库？在项目中使用的场景多不多？是不是必须的？自己实现的话成本大不大？因为第三方库引发的血案不计其数，而且很多人其实只是因为一个小的需求而导入一个大的第三方库，这样其实不划算的

13.编写代码时尽量简洁，符合面向对象编程，而且尽量做到代码可以复用。

14.要注意方法数65535限制，能不超最好，超了就用multidex解决

15.创建项目时最好是用最新的 sdk version，因为很多新兴的库都会要求比较高版本的 SDK

16.当项目的 version 大于23的时候就要开始注意权限的申请，因为在新的 android 版本中为了安全开始把权限划分成普通权限和危险权限，并且危险权限在manifests 中生命是不算数的，必须在使用时再次判断 app 有无此类权限，是否需要重新申请。（可以看看 RxPermission）

17.最好在项目一开始就自定义一个 Application，因为后来你可能需要用到一些库，然后这些库必须在 Application 中初始化。

18.最好定义一个 BaseActivity ,或者 BaseFragment,用于规范统一一些操作、流程

19.其他的代补充咯~

关于其他

这些都是个人的一些见解，有错的帮忙指出咯！

如果有能帮到你的，那也是极好的~

如果你也有一些心得，或者建议，欢迎分享！

知识只有流动起来，才能发挥它更大的价值

如果这篇文章又帮到你的话，请点一下‘喜欢’，我会更努力的创作的