0-1项目建立需要
1，项目基础组件：
apm
网络
abtest
UI规范
router
代码规范
线程时序问题
使用线程池，不要单独创建线程
使用协程避免回调地狱，业务相关的非耗时操作可以post到主线程
兜底逻辑处理
if 后面要跟 else try catch同理
data class的keep确认
data class需要@Keep注解，同时实现Serializable接口，字段意思注释清楚
重复逻辑考虑抽出公共方法
若有相同的业务逻辑，建议抽到相关的工具类中
引用检查是否释放
持有activity及fragment实例时，必须检查持有者的释放时机，是否会导致实例无法被回收
listener注册
activity, fragment, viewHolder注册listener时，需要检查一下生命周期结束时是否有进行解注册
分支管理
develop为主分支开发
- 每个迭代开发开始时，负责对应需求的同学可以从
develop分支中拉出提测用分支。分支命名一般采用feature或bugfix开头，后面跟着分支的名字，如feature/login-module、bugfix/fix-crash。在基于这条提测分支，拉出自己的开发分支，分支命名一般采用开发同学的名字开头，后面跟上feat或者fix，再跟上分支名，如yinjie/feat/login-module，yinjie/fix/fix-crash, - 在开发完毕后，在 GitLab 中开启一个 Merge Request 将开发分支合并到迭代分支。Merge Request 需要写明此次合并的目的及注意点，如果有相关文档的话也需要写上，并且必须指定至少一人来进行 Code Review，Code Review 通过后才可以合入。
IM的 Git Commit 规范借鉴米游社使用简化版的 AngularJS Git Commit 规范，格式为：
<type>: <subject> // 注意使用英文冒号且后面需要加一个空格
// 空一行
<body>
其中，<type> 和 <subject> 是必需的，<body> 可以根据自己的需要填写或省略。
<type> 只能为以下几种：
feat: 新功能
fix: 修复 bug
docs: 更新文档/注释
style: 不变更逻辑的代码格式更新（如 lint 等）
refactor: 重构
chore: 构建过程与辅助工具的变动（如更新打包脚本、更新项目配置等）
<subject> 为 Commit 的简短描述，可以根据自己的提交内容来写，但要遵循以下几个原则：
- 尽量使用简洁的语句说明 Commit 的内容。
- 不能使用诸如 Fix bug、Update 等意义不明确的提交。
- 不要写跟本次提交无关的内容，如吐槽、抖机灵等。
<body> 为 Commit 的详细描述，可以分为多行，可以根据需要将对应的需求或缺陷的链接写在上面。
以下为规范的 Git Commit Message 的例子：
fix: 聊天列表滑动卡顿整理
开发规范
开发规范
组件工程
主仓模式
组件模块
module分类
-
app
- 壳工程，仅保留Splash & Appliaction的逻辑
- 持有对各个biz模块的依赖
-
biz
- 以业务模块为划分
-
common
- 通用业务组件
-
middleware
- 目前是一些UI相关模块，后续迁入common模块
-
framwork
- 框架层架的组件，和业务逻辑解耦
module命名规范
多个单词以中割符分割 ，如common-ui
module package命名规范
整体路径名(com.xxx.xxx) + module分类(除app) + module名
示例：com.xxx.xxx.biz.login
module res命名规范
资源名前添加前缀，如login_view_option_item.xml
layout & drawable资源前缀命名（便于ViewBinding生成类风格统一）
- module_activtiy_xxxx.xml（Activtiy布局）
- module_fragment_xxxx.xml（Fragment布局）
- module_item_xxxx.xml（ViewHolder布局）
- module_dialog_xxxx.xml（Dialog布局）
- module_icon_xxxx.png（图片资源文件）
