Fragment常见问题
- 自己构造Fragment一定要把数据存起来；
- DialogFragment show()方法会有大量的崩溃，现在都改成showAllowingStateLoss啦，后面不要再用show()方法啦；
- 同样所有Fragment的commit也会存在大量的崩溃，需要都改成commitAllowingStateLoss；
- Fragment中getContext getActivity都不要用，崩溃概率很大，请在onAttach方法中获取Activity使用；
- 所有基于MVP的Fragment都需要处理Activity重启后Presenter的恢复；
Activity
- Activity Theme不统一，应该使用Application中配置；
第三方服务
- 所有第三方服务初始化必须try catch并异常上报；
Intent
- 涉及到系统的intent一定要trycatch，这个兼容性问题比较大，很容易crash
Application
- Application onCreate在多进程场景下的处理；
通用问题
- drawable下xml资源存放错误，新建xml或拷贝png文件时请认真选择drawable目录；
- 当请求失败，接口返回的msg为空时，需要加上默认文案；
- 依赖第三方库应该指定版本号，防止自动升级引发新问题，每次升级都需要经过测试；
- 项目中依然缺少大量必要的非空或size校验；
- App主题设置为透明导致所有Activity onStart onStop方法失效问题；
- 使用消息总线发送的消息没有唯一标识保证一对一，多页面会引发逻辑错误；
- Adapter中缺少数据为空的处理，容易崩溃；
规范问题
- 网络请求的代码过于分散，不要写在除presenter之外的代码里，独立的网络请求类除外；
- 接口url未定义在常量里；
- 不要直接访问某个类的成员变量(entity除外)
- 大量资源文件命名未按照约定添加前缀；
- 为方便后期语言国际化，代码中不要使用汉字；
- 不同业务间使用的参数常量不要串用；
- 单个类中代码量较大时，可使用分隔符分割同一业务的代码块；
- 部分包结构未统一；
- reformer和ItemDecoration中避免单个函数大量代码片段，合理查分为小函数；
- 过渡封装，例如：model中有明确type情况下，无必要使用枚举；
性能问题
- ListView的getView方法中不要或尽量少的创建对象；
- 存在大量的字符串拼接，特别是在bindData等执行频繁的地方，容易造成内存抖动，引发频发GC，可以提前并使用StingBuilder拼接；
- Activity、Fragment、Presenter等在销毁时，回收资源、对于读取数据的API请求可取消并回收资源；
- for循环中调用notifyDataSetChanged，会导致页面频繁刷新；
- 打印Log，请添加LogUtils.DEBUG判断，避免生产环境中大量字符串拼接；
JSON解析
- 解析代码添加trycatch；
- 解析数据等逻辑存在大量的非空检查；
- 解析数据的代码过于分散，尽量写在reformer里面；
- 新建的entity如果涉及到json解析都加上@keep，防止代码混淆造成错误；
- set函数一定要和变量名对应，不可交叉，否则使用fastjson会造成赋值错误；
内存泄露
- handler在activity销毁时要调用removeCallbacksAndMessages, 1. 可以避免泄露；2. 解决用户点击返回键后不会执行其它操作；特别是有延迟任务的时候，特别注意下；
- 回调对象如果在用在activity中的，请使用weak防止内存泄露；
- 第三方初始化，放在Application中就可以，此处context不要使用activity，因为不清楚第三方怎么使用context，存在泄露的风险；
- 单例对象引用view，导致内存泄露的情况；