如果从0创建一个Android APP,设计思路是什么?(架构、activity、layout等复用性的考虑),感觉无从下手

关注者
431
被浏览
30,363

10 个回答

下面的建议只是针对于小的app,结构异常复杂的请忽略,外包的活我一般都是这么干的

1.构建方式,Gradle还是Maven

2.网络框架,包括网络请求,图片异步加载,图片缓存,网络缓存(可以修改Volley使用),力求简单易用

2.数据存储框架,覆盖dataBase存储读取,文件缓存存储读取,这里可以把自己的数据存储框架侵入到网络框架中代替网络框架的缓存模块,同样力求简单易用,公布出去的API要做到傻瓜式调用无错

3.适配资源,这也算是通用模式的一部分,举一个栗子,在xhdpi上面一个字是12sp,那在mdpi下面应该严格来说肯定不应该是12sp了,两种方法,

a.ui一般出图标注是px,可以在UI设计稿对应的屏幕密度下下面建立一套dimen,例如下面这个样子,然后对应的翻译一套其他dpi的,看着设计稿拿来就用而且不用发愁dimen到底起个啥名

b.对于常用的TextSize Margin Padding等做一套对应各种分辨率的资源文件,其他的标注自由发挥,好处在于覆盖了大部分的dimen使用场景,而且不像上面那个方法看起来那么奇葩

4.可选的其他准备,例如社交应用连接模块,统计模块,账号管理模块,耦合度越低越好,调用方式越傻瓜越好,最好能抽出来当SDK使才是最棒的

---------------------------上面这些都是可复用的,一劳永逸,拿来即用,而且可以有项目中的能力较高者专门维护升级而不影响业务代码发展---------------------------------------------------------------

业务相关模块,同样是简单的APP开发,复杂的APP肯定不能这么简单粗暴,而且不一定正确,只是我的个人习惯

5.所有的Activity继承BaseActivity,Fragment继承BaseFragment等等,可能开始Base类就是空的,早晚有一天会用到

6.代码分包,我一般都是按照业务分包,业务下面分UI Utils等等,当然和业务平行的还有Utils,Constants,Provider等包,

7.关于Activity复用,Fragment复用,layout复用等问题,这个永远不可能一下子做到最好,放心大胆去写,只要写的逻辑好,写的时候动脑子,不用担心,后面还有不断的重构呢,每个月看自己上个月写的代码总感觉是傻逼写的,每个月看一遍,代码自然会越来越好

个人意见,欢迎拍砖