Android 开发最佳实践
持续更新
1摘要
选择一个好用 IDE Andriod Studio
关于包的结构
我建议具体业务相关的包结构是将它们置入在一个包内。而不是在整个应用包的根下
因为我们的业务是不断的增加。就种增加也应当增相应的包名。这样的话包结构的变化就是会明显的变化
不利于稳定。
越是公用的东西则应该放置在明显的地方。如果工具类。
还有一些其他公用的管理类。这些东西可以放置在更高层级的类包下
这种做法使得其他小伙伴可以一眼看到,并且使用它们。
而与你协同开发的小伙伴可能根本不关心你的功能(业务)。
但是包结构的变化使得小伙伴分心。或是误入到其他。引起冲突等
关于依赖关系,尽量做到单向依赖
这个也从包的层次表现出来,
越是靠近根目录的文件,功能,相当于洋葱的内层,他是越是公用的,核心的。需要被依赖的。
越是远离根目录的文件,功能,相当于洋葱的外层,他就越是私用的,他依赖于核心的
关于包的结构
module:业务模块
utils:工具类
widget(视图控件——含自定义view,弹窗,浮窗,通知条。
service:后台服务()
data:数据
common:常用的管理功能
base:不以业务相关的基本类
log:日志的打印
config:配置
entity:实体类
module:业务模块是放置一个个独立的模块。
network:网络
image:图片
location:地理位置
locale:国际化(含多国语言的配置管理)
permission:权限
manager:
data :
创建线程池管理类,统一管理线程的创建和销毁。减少系统不必要的开销。控制来内存管理
接口化
定义内层的输入,输出接口,是内层自己的职责。(内层通常是最接近数据的,但又不能耦后外层,只是定义输入输出接口,这样方便对接所有关心数据的人)
是不是过度复杂了?
当你习惯了就简单了
我们希望数据流可以从外层流向内层,反之亦然。但是依赖规则不允许。
Log 日志的打印要尽量还原真实场景,不要处理发生的时数据。不需要美化。他当时发生的数据是什么就是什么。
美化后的数据会隐盖有用的信息。可能会使得调查问题发生的原因出现偏差。
在团队协作时,怎么能让代码的单向依赖原则不被破坏,即内层的包,不使用外层的包。
1限制类,方法,参数的访问限制,
2使用依赖原则。将代码分划成为模块后,外层的模块依赖引入内层的模块,不允许内层模块引入外层的模块。
3更不要跨层访问
少写注释,多起一些有意义的名称。有明确的方法名称,类名,属性名等。
公用的静态方法放置在UTIL包下
如使web显示页面的,请使用WebView下的Html5Activity
如果使用自定义,或是你要自己定义一个view.请将他们放置到Widget包里
C。是我们的常量类
Config是配置
service是服务的
entity是实体类。(实体类不要作涉业务的逻辑,不要依赖平台, 保持他的纯java特性)
module功能模块
data数据。
base是基本父类。(作好的,我们以后可以作一个开发框架)
工具类理应能够抽像化,公用化。也理应不涉及具体业务细节。
如果工具类只提供给某个业务使用,那么他的命名上需要下一些工夫,表达出它的使用范
或是的包可以范围应该被控制在包内可以访问,避免外部误用了。
内层定义更抽象的部分,外层定义更具体的部分。
尽可能的作单向依赖,即是外圈使用内圈的类,代码。反之内圈不使用外圈的类,代码。
如查你发现依赖倒置,内层依赖外层的类,代码,尝试把他移动到内圈。
如查你发现跨层依赖,或是新增一个中间件在内层进行处理。不直接依赖使用。
内层的包不要使用外层的包
*定义输入输出接口是内层的职责。
例如 Http协议定义的Content-Length
如果我们也有类似的字符,也作相同的命名的话会与之有冲突。不能正常区分,
这就里需要个可以区分的命名规范。使用小驼峰命名
关于Android布局文件(layout)定义规范要求
关于layout 的命名规范
使用小写字符,字符之间隔使用下横线_
Activity使用的布局文件加上前缀activity_
Fragment使用的布局件加上前缀fragment_
自定义控制件使用的布局加前缀widget_
公用的布局件加上前缀layout_
Adapter使用的布局件加上前缀item_
代码组织方面。Package Diagram对一些大型的项目特别有用。顺便说一句,良好的代码组织,对软件的可维护性至关重要,请认真的规划你的包结构。下文将简单介绍Package Diagram,主要分两块,什么是Package,以及Package之间的关系。
网友评论