ZAOZUO Android代码规范

发表于 | 分类于 | 阅读次数
字数统计 712

规范是提高团队开发协作效率的前提，请大家务必重视；
规范主要解决两个问题：1.提高协作效率；2.绕过已知的问题；

命名规范：

Bundle命名规范：

  • 工程名：
    • 业务Bundle：biz_xxx
    • Library Bundle：lib_xxx
    • jar或aar Bundle：zzbin_xxx
  • 包名：
    • 业务Bundle：com.zaozuo.biz.xxx
    • Library Bundle：com.zaozuo.lib.xxx

包名命名规范：

  • com.zaozuo.[biz/lib].[模块名].[业务名]

    1
    2
    3
    4
    5
    6
    com.zaozuo.biz.show.home
    	entity ：实体类
    	presenter
    	view：Activity/Fragment
    	widget：自定义控件
    	viewholder：item/itemGroup

资源文件命名：

  • 所有在R文件中生成资源文件必须添加模块前缀和业务前缀，规则：[业务模块名] _ [业务名] _ [具体名字]；

    1
    2
    3
    4
    5
    layout命名：
    	activity/fragment对应的xml：biz_order_orderlist.xml
    	item对应的xml：biz_order_orderlist_item_topview.xml
    drawable命名：
    	biz_order_orderlist_btn_camera.xml

  • xml中id对应的控件名字采用缩写：[业务模块名字] _ [业务名] _ [按钮名字] _ [控件简称]；

    1
    2
    biz_order_orderlist_avatar_iv
    biz_order_orderlist_confirm_btn

  • style也需要添加前缀：例如Biz_Show_SplashTheme

UI总线命名：

  • UI总线url命名规则：[业务模块名] _ [业务名] _ [细分的业务名]；

    1
    public static final String Biz_Order_OrderListActivity = "activity://biz_order/orderlist";

消息总线命名：

  • 消息总线，监听收到消息函数命名规则：onXXXEvent，例如：onLoginCompletedEvent

分类规范

  • 同一个模块下资源文件一定要归类，例如string.xml按照业务放在一起；

书写规范：

  • 每个函数，关键位置代码、成员变量添加Java标准注释；
  • 每个类中同一业务逻辑，可使用分割线区分不同的代码块；
  • 每次修改代码加修改说明、复杂逻辑添加实现思路；
  • Bundle引入版本管理，每个Bundle中应该包含版本变化说明；
  • 使用Android Support Annotations优化代码；
    • @Nullable 修饰方法参数、返回值、成员变量，表示可能为空；
    • @NonNull 修饰方法参数、返回值、成员变量，表示不会为空；
    • @StringRes @ColorInt @IntDef @DrawableRes @LayoutRes 修饰资源id；
    • @IntRange @FloatRange 限定参数范围；
    • @CheckResult，必须处理返回值；
    • @UiThread、@MainThread、@WorkerThread、@BinderThread，标识函数运行的线程；
    • @CallSuper，必须调用super；
  • 正确使用Java private protocted default public限定符；
  • 所有内部类或接口必须使用static，防止内存泄露；
  • 所有模块的BuildConfig都不要用，使用BuildInfo；

逻辑规范

数据解析：

  • JSON解析的代码必须try catch；
  • 没有解析JSON的字段加上注解，@JSONField(deserialize = false)，并与参与JSON解析的字段分隔开；
  • 使用fastjson解析基本数据类型，使用getXxxxValue()，不要使用getXx()，它是返回对象类型，如果返回为空，自动拆箱会崩溃；

Entity：

  • entity应该尽量精简，用不到的数据不要解析，结构层级不要纵向延伸；
  • entity只处理简单的逻辑，注意过渡膨胀；
  • 业务entity为减少方法数量，所有成员变量使用public修饰;
0%