开工准备

在项目业务代码开工之前，最好把这些问题都解决掉，否则必将酿成大祸害。它们是：

• 组件路由

• 异步处理

• 组件化模块工程

• 全局网络拦截器

• 异常统一处理器

• 基础视图组件封装

• 日志记录工具

• 解决写无数次一模一样代码的模板（如自定义MVP模板）

机型适配

特定的机型上出问题时，别着急。我们可以尝试以下几个办法。

• 反编译rom，看底层改动(条件略高)

• 联系该厂商的工程师（如果可以的话）

• 拷贝整个我们调用api的源码进行单独依赖，而放弃系统内的

• 逆向在该机型上正常的同类app，参考逆向后的代码实现

• 参考各个版本不同的Android API变化，可以从源码入手进行对

• 利用反射获取该特定机型上的某个我们想知道的方法，动态调试

排查崩溃闪退日志:

1.如果app在调试的过程中出现闪退,此时在logcat下日志会被新起来的进程冲刷掉。这时需要把过滤器选择为No filter 把日志级别选为 error即可查看到上一次崩溃的日志。

2.有一种情况是手机并不在我们身边,我们也无法使用调试工具。此时可以接入一些第三方的日志记录工具。在开发状态下不建议使用友盟 360之类sdk,因为很有可能我们的app根本无法连接到网络就崩溃了。 可以选择把日志存到本地文件中。再由使用手机的人发回来。一般这个人是测试。

3.如果app未接入任何日志保存工具,可以在data/anr/目录下查看到所有的ANR异常信息。但需要su权限。否则无法访问到。

APP性能体验优化

1.素材有必要使用压缩后的。推荐熊猫PNG压缩。

2.资源能用代码画尽量使用代码去画，而不要使用静态资源。

3.在复杂的布局上,比如很多app的首页需要加载不同类型的item。使用了RecyclerView多类型加载,刷新数据时一定要使用单独对item刷新api。切勿使用notifyDataSetChanged()方法,这里要用两个参数的notifyItemChanged(1,"gfg")方法。

4.数据懒加载，或排队加载。

5.混淆可以使包减小含:(xml 资源 class等)

6.如果玩得不是很6，尽量不要写静态引用，匿名内部类这种会导致内存泄漏的东西。如果很担心自己失误的写了，一定要去分析它们，把他们揪出来。

7.Activity的层级不要太深。过深的层级会在低内存设备上被回收栈底的Activity。

建议和技巧

1.发现某处代码可以复用性的封装一下或者改良一下会更好的时候一定要乘早，不要拖延。（烂泥巴只会越来越烂，后面改=永远没可能）

2.debug编译期间可以把用不到的abi过滤掉，会让我们加速部署。

3.尽量保持较新的 support library依赖。因为较高的版本中修复了一些bug。

4.接入第三方包时，最好与自身模块保持独立，做到随时解耦，随便复用。

5.多个native库依赖时，若发现某些abi上不支持，那么就需要保持最小的abi。否则会给某些机型优先读取它更合适的架构。会造成灾难性的崩溃。如:ARM文件夹中含两个so，ARMv8中只有一个。届时手机优先加载了ARMV8的情况下，将带来找不到so库的崩溃异常。

6.不要太随性的引入第三方依赖库，如果只是用了很小一部分功能，建议剥出来自己封装。

7.第三方的包含私有api为暴露时，记得用反射去实现。当然这一切需要我们能翻他们的sdk源码读。也许被混淆了。这时就可以使用动态调试去跟踪。

8.多数情况下官方的support包比第三方要好得多。只是我们不知道，或者不熟悉。

9.渐变图、纯色图、带一根线的图用shape，不要静态图。会引发血案！

10.当无法通过搜索解决问题的时候，读源码是最快的解决思路。千万不要瞎猜和尝试随缘写代码来解决问题。

11.封装控件时注意对资源类型做校验 
如:image.setImageResource(img);
这里的img需要做强校验，类型检测，防止别人用的时候不小心写错了。因为如果我们不主动抛出异常。靠LayoutInflater通过反射去解析xml时提示出了的错误日志非常难看。一般还会伴随一大堆调用栈和闪退出现。

12.冷启动优化，不要在Application启动时里做过多的任务&第一个Activity里也是一样。最好把初始化的白屏Window设上一张图片过渡一下。

有不妥之处，欢迎指出和补充，拼死挣扎的Android程序员。

原文链接：http://www.apkbus.com/blog-889706-76976.html