一个APP项目开发总结

呱牛
2020-12-04 16:52:51
APP开发
APP开发 Android 经验分享

最近做了一个小的Android APP项目，领导同学说，这个项目在大牛你的手上，三两天就搞定了，结果肯定是三两天没有搞定，消耗了差不多一个月才经过验收，可能是多年没有做近乎纯前端的项目，多少还是有不适应，所以简单做个总结！

这个项目说小，主要是功能的业务逻辑很纯粹，就是一个增删改查系统的客户端，所以显得这个APP的整体功能简单，但麻雀虽小五脏俱全，增加的表单是动态的，多流程的，输入项有20多项，还支持动态扩展；查询简单但数据项多；修改是流程审批制的，有状态机的流转；而UI大概涉及30个页面，所以整体还是消耗了不少的精力。

从分层的角度看，一个App主要包括：前端UI、业务逻辑、基础架构和组件！常用的开发模式是一个开发将独立模块的UI、业务逻辑、基础框架和公共组件全都包揽，这会导致多个模块的重复工作量，比方基础框架和组件这块；另一种开发模式是UI、业务模块、架构和基础分离，起码角色上分离，不同角色考虑问题的时候，才有可能形成通用的基础框架和公共组件库，并形成技术积累和资产，否则会在多个项目中疲于奔命，开发技术也成长不得的恶性循环。

如果就工作内容、工作时长和输出质量来说，可能我就是一个不合格Android开发了，因为在UI这块耗费了大量精力，输出的版本经过UI设计师检查后，找到了非常多的细节问题！毕竟作为一个App工程师，在画UI上打磕绊，多少是不是就不合格了！当然也是自己最不满意的地方，后面或许不轻易做完整的APP了！在过往的项目中，和同事分工采用的是业务和UI分离的开发模式，经常是我做擅长的业务模块，（或者需要JNI的C/C++模块，因为音视频很多的包括协议栈、技术框架需要C/C++实现，比方SIP/FFMPEG等三方开源库），还能像一个APP工程师的样子，毕竟业务逻辑是我的长项，输出质量也还不错，当然也就不知前端UI开发的辛苦，等到需要一个人独自完成整个APP的时候，就显得不合格了。

客户端开发，除了业务逻辑之外，更多的还是画UI的工作，所以不可避免的是，与UI原型效果图的还原度如何，是评价一款APP好坏的衡量标准之一，APP上线之后，如果因为APP设计或者交互上被诟病，极有可能是开发并没有很好的按照UI设计师的设计效果图来，毕竟UI设计师多少会抱怨开发输出的效果和设计不符，开发却以不能实现或者不好实现为由，拒绝或者对设计师输出的效果图在实现时大打折扣，而UI设计师检查的严谨度，也直接决定了这个项目的周期。

最近的这个项目，因为一个界面有很多变化的块状布局（比方多个区块，每个块类的布局样式却长的不一样，很难套用固定的布局样式），所以只能选择通过代码去删减自定义控件来做，开始赶功能时，压根没有关注控件的上边距、下边距等细节问题，后期做了好多修改才符合设计师的要求！

这次项目碰上一个非常严谨的设计师，UI设计问题归类包括：

1、圆弧角度和圆弧底部阴影效果；

2、字体颜色、字号大小和字号间距；

3、上边距和下边距、图片大小和对齐必须严格一致；

4、动画转场效果和UI卡顿；

---

如果UI设计师是一个暴脾气，假设你把上面的问题都犯全了，反馈到领导那里，可能开发这个饭碗就不保了！

所以总结一点点APP开发的经验是：

1、多总结基础框架；

2、不要偷懒，严格按照UI设计师的输出来画界面，实在画不出来的，同设计师好好沟通，修改原型；

3、重复第二条；

完整的APP开发，需要可以重复使用的基础框架，这个可以极大的节省开发的工作量，并且提升输出的质量，之前的工作中有些积累但不完整，这次完整的APP开发过程，有机会重新整理基础框架：

1、基础的UI组件，比方对话框、弹出框、基础的控件和样式；

2、业务层的框架代码，MVP/MVVM的基础框架代码，不管是Activity/Fragment，还是Presenter，都能有固定的代码模板，获取数据，刷新界面，下一页的加载和刷新等等都有固定的框架去支撑这些业务的完成；

3、支撑的工具类、和常用的类库，包括DB库、缓存库、日志库、Crash跟踪等常用的基础库支撑后续版本的发布、问题的定位、运营层面的需求；

这次使用的基本框架和技术：QMUI作为基础的UI框架、RxJava、OKHTTP、Retrofit作为HTTP的数据源请求，整个框架采用MVP的架构，工具类包括BitmapUtil、Xlog、SPUtil等等处理工具类。

APP开发工程师，其实质还是一个客户端工程师，在大一统的前端技术背景下，也可以说是一个前端工程师，但面对现在广义的前端开发来说，传统的Android开发多少还是缺少优势，出活慢，质量不高，付出的劳动力时间成本却不低！为什么这么讲,一方面传统Android开发主要还是基于Android的标准SDK基础上，在项目行业不确定的情况下，很难总结出一套通用的代码框架，而重度的UI工作量，又在拖慢整个开发的进度！

纵观APP的开发形式，从Native APP（iOS和Android开发称之为原生开发）,Web APP,Hybrid App混合APP（原生和Web结合的开发）,以及只使用Flutter 开发APP（一次开发，同时输出多端的版本的开发语言），似乎有统一APP技术的霸气；技术驱动的原动力，还是人力成本的考量，消耗最低的开发成本，拥有高质量的输出，但这些技术有没有让开发同学更轻松，解放开发同学的双手做更有意义的事情，可能又是另一个值得探讨的问题！

呱牛笔记