Code Review& 编程习惯，安卓工程师面试题
13. 开始之前考虑哪些可以公用，资源，layout，类，做一个结构/架构分析以加快开发，提升代码复用度。
14. 关于形参实参：参数为基本类型传的是传值；参数为对象传递的是引用，即传址，这种改变会作用于原来对象。
15. 控制 Activity 的代码量，保持主要逻辑清晰。其他类遵守 SRP（单一职能），ISP（接口隔离）原则。
16. Log 请打上 Tag，调试打印一定要做标记，能定位打印位置，否则会尴尬不知道是哪里在打印。
17.与 Activity 通讯使用 Handler 更方便； 如果你的框架回调链变长，考虑监听者模式简化回调。
1
8. 构造函数里面不推荐启动异步线程，会埋下内存隐患。
19. UI 显示注意内容过长的情形要提前使用 ScrollView 否则在小手机上尴尬你懂得。
20. String 的比较用 equals，不要一时犯傻用了==。
21. Long a; 判断 a 有没有赋值，if(a == 0)在 a 没有赋值情况下会报错。应该 if(a == null)，Integer、Floag 等也一样。
22. 编码遇到读写、出入等逻辑要双向考虑，文件导入导出，字符字节相互转换都要两边转码。
23. 从资源文件或者文件加载一张图片时注意其宽高，避免 OOM, bitmap 的内存占用是宽 x 高 x 单位像素占用字节（RGB565 是 2 个字节，ARGB8888 是 4 个字节）。
24. 对于并不那么注重访问性能的较小集合而言，List 则是合理的选择。for 循环对下标没有要求的优先使用 foreach 循环。
25. 选择正确的集合类型使你能够在集合性能与内存占用之间达到合理的平衡。例如某些情况下用 SparseArray 代替 HashMap。
26. 充分利用封装（提供接口类来控制访问数据）和委托（helper 对象来实施任务）两种理念。
27. 当逻辑没有明显问题时考虑对象属性、函数参数、网络传输参数是否全部了解，是否设置正确。
28. 拼接字符串避免 String 进行频繁+操作，应该使用 StringBuilder 提升性能，多线程使用 StringBuffer 操作 string 提高程序效率。
29. 基本数据类型定义的变量称自动变量，存的是‘字面值’，存在于栈中，可共享（存在即不新建）。
30. 只要是用 new()来新建对象的，都会在堆中创建，而且其数据是单独存值的，即使与栈中的数据（值）相同，也不会与栈中的数据共享。
31. 能复用同一个对象处理的尽量复用，不要使劲的在那里 new 对象，内存吃不消，尤其是 for 循环等。
32. 改变逻辑的时候考虑全部用到这项功能的地方，分散的地方多了可能会忘记，不要为了填坑而挖了一个坑。
33. 不要在布局文件 xml 中使用 onClick 属性，如果你忘了在代码中声明 onClick 方法就会悲剧。
34. 注意参数的++或者--操作的区别。
35.?服务端可以实现的，就不要放在客户端。
36. 引用第三方库要慎重，避免应用大容量的第三方库，导致客户端包非常大。
37. 重复类似的功能在统一个类中去实现，而不是重复的去 new 一个相同类的实例，如 activity 中在一个 View.OnClickListener 中处理所有的逻辑，接口回调在同一个 callback 中处理。
38. 多用组合，少用继承。
39.? 合理布局，有效运用<include>?，<merge>、<ViewStub>等标签。
40.? 尽量采用懒加载的策略，即在需要的时候才创建。
41.? 尽量使用 HashMap、ArrayList、StringBuilder，除非线程安全需要，否则不推荐使用 Hashtable、Vector、StringBuffer。
42.? 可以使用局部变量代替的，尽量不去创建全局变量。
43.??一个接口可以解决的事，尽量不去导入一个框架。
44. ?控制一个应用中的单列使用场景，防止滥用，单例主要用于控制资源的并发使用、 控制实例的产生， 控制数据的共享。
45.? 基本数据类型转为字符串，推荐方式为：基本数据类型.toString()、String.valueOf(数据)次之、数据 + ""（避免）。
47. ?使用的 UI 切图图片资源等如果太大尽量[压缩](
)以减少 apk 体积。
48. 避免常见的内存泄漏：
单例模式持有的 context 是 Activity 的 context，改为能使用 Application 的 Context 就不要使用 Activity 的 Content，Application 的生命周期伴随着整个进程的周期。
非静态内部类以及匿名内部类的静态实例造成内存泄漏
Handler 和 Thread 使用不当造成的内存泄漏
资源未关闭造成的内存泄漏
使用了静态的 Activity 和 View 造成内存泄漏
注册了系统的服务，但 onDestory 未注销
不需要用的监听未移除会发生内存泄露
集合中对象没清理造成的内存泄漏
大尺寸的图片 Bitmap 使用造成的内存泄漏
内存泄漏相关文章：[避免内存泄漏 1](
)，[避免内存泄漏 2](
)，[避免内存泄漏 3](
)。
49. 使用工具来分析代码：
使用 AS 自带的 Lint 来优化代码结构（什么，你不会？右键 module、目录或者文件，选择 Analyze → Inspect Code），非常有用的一点是它能告诉你 API 版本兼容的需求。
使用 FindBug 插件来查找 bug，AS 自行安装。
使用 AS 自带内存调试工具来查找内存泄漏。不会使用的可以看：[使用 1](
)，?[使用 2](
)。
养成良好的代码规范和编程习惯不是一朝一夕的事，需要持之以恒，要知道妖精在修炼成精以前都是要坚持修炼的，我们程序猿也是如此，建议每天固定时间或隔几天或固定每周几进行一次 Code Review，哪怕只有十分钟半小时，坚持下来也会受益颇多的。
CodeReview 作为业界公认的最佳实践，如果每个团队都能运用起来，固然是最好的，但是这项活动否能有效运作往往跟团队状态、技术信仰和领导者诉求等都有莫大关系。技术驱动型团队、公共服务型团队、新人密集型团队等比较容易有效进行 Code Review，而业务驱动型团队、创新型团队等很难 Code Review 进行，此外还跟团队领导者观念以及公司文化有关（做这件事又不能提高我的绩效为什么要做它？bug 都改不完功能还没做完为什么要做这个？）。
--------------------------------------------------------------------------------------------------------------------------------------------
“什么狗屁代码，老子看了几个小时也没明白！”
“这么烂的代码，到底是谁写的！”
还未添加个人签名 2021.10.31 加入
还未添加个人简介
评论