微试驾项目总结

一、 项目前瞻

 

如今,随着移动互联的发展,汽车行业渐渐与传统的汽车行业背相而驰。为顺应时代与科技发展的趋势,为满足线上线下预约试驾的移动性和试驾业务的完整性,特产生了微试驾这款APP

 

二、 项目启动

 

1. 业务需求的了解

2. APP原型的制作

3. APP原型的评审

4. APP框架搭建

5. APP模块分类

6. 模块分工开始代码编写

7. 单元测试

8. BUGS修改

9. 上线

 

三、 项目所用

A、 物理:

1. IOS设备若干台,MAC电脑一台,企业级开发者帐号

2. 开发人员:1人(若干人)

3. 外网上网卡

4. 服务器

 

B、 软件:

1. XCODE

2. MAC OS

3. JSON查看工具

4. SVN工具

 

C、 类库与框架:

1. EAP联友科技内部框架(SDK)

2. 百度地图SDK

3. ASIHTTPRequest组件

4. MJRefresh上下拉刷新组件

5. PPSSignatureView签名组件

6. UICustomActionSheet下弹框组件

7. SDWebImage网络图片加载组件

8. TYMActivityIndicatorView 等待菊花进度条

9. Toast+UIView 用于显示提示信息

 

D、 自定义工具类

1. EvaluationView 根据评分来控制心型的数量

2. TabbarController 底部导航栏,自定义底部切换动画与图标,原理简述:在原有的UITabBar上再加了一层自定义的UIView层,并在上面添加相应的按钮,通过代理的方式来响应苹果官方类的响应事件,从而实现相应的点击效果。

3. SizeCalculator用于计算长文本的SIZECGFloat height , CGFloat width)

4. HttpUtils 自定义的网络请求类,继承于EAP请求类LYHTTPREQUEST,作用:方便统一操作网络状况的判断,统一加载或隐藏网络请求与相应的等待进度提示框,统一处理网络回调。

5. ImageUtils 图片生成工具类,作用:截取视图的画面生成图片,将图片保存到本地文件夹或相册

6. FileUploader 文件上传类,继承于NSObject,组合EAP框架的类LYTasksManager实现文件的异步上传

 .etc


四、 项目构造 

 

1. 框架:由UIStoryBoard搭建 (不做过多的依赖)

2. 页面主要组成部分:xib 和 UITableView

3. 自定义UITableViewCell主要由xib实现

4. 自动登录:进入登录界面之后,判断是否登入而未登出,若是则在其上覆盖一层启动画面相同的UIImageView控件,屏蔽登录界面,自动提交用户名与密码来完成自动登录。

5. 版本更新:企业级项目,只用企业服务器判断版本与相应APP下载路径,沿用之前东本App的版本更新代码

6. 拍照与保存图片,上传。

7. 地图打点,图片上传

8. 其他页面的简单页面展示与操作

9. 预约消息推送(尚未需实现)

 

五、 项目总结

 

由于开发周期比较短,所以开始创建框架的时候就使用了storyboard的方式来搭建。对于小项目来说使用storyboard可以很快速的把项目的框架搭建起来,而且可视化的界面让人有一种结构清晰的感觉。当前,苹果公司也是推荐开发者使用这种模式开发应用的,而且storyboard的布局其实是xml语言,说到底也是可移植的.但可能现如今为了适配更低的系统版本所以就不能够太过多的依赖于storyboard,一些布局上的控件,最好使用纯代码编写,这样的项目的可移植性就会更高,为以后的项目的更高的开发效率打下基础。

在一些controller界面上,UITableviewCell自定义上还使用了xib去创建,因为有些界面用代码去完成会相对会锁碎一点,而用xib可以快速创建控件,结构也比较清晰,对一些不熟悉的控件用xib去完成控件的创建可以极大的提高开发效率。虽然xib给开发者带来了极大的方便,但在开发的后期做适配的时候,因为使用了xcode6版本的xib,里面的xib包含了旧版本sdk里尚不存在的方法,所以会导致在旧版本的IOS6系统会不支持,这样就很难去做适配了,暂且不说是否还需不需要适配IOS6版本的系统,就这种情况来看,这种项目的可移植性就被大大地扣除了一大半了,所以在              以后的开发过程中,应当去熟悉每个版本SDK的过时方法与不存在的方法,以纯代码为主,合理地搭配storyboard与xib为辅,才能更好的提高效率,并提高项目的可移植性。

关于ARC内存管理机制,现如今上架的项目都是ARC的项目,而且ARC人内存管理确实有极大的好处,一者可以提高开发效率,不再需要开发者去手动管理内存,二者可以提高APP的执行效率,因为APP直接略过了NSZone。但是ARC并不是万能,多多少少还会有一点内存的泄漏,而且进行ARC代码的编写的时候,也有很多内存的泄漏的陷阱,比如循环引用的情况等等,ARC的使用另一方面也会让代码对内存的管理的可制性不高,也不利于定位内存泄漏。所以对若是MRC内存管理机制有一定的了解的话,对使用ARC的机制的使用也是很有帮助的。在微试驾这个项目,使用了大量的delegate与block块回调,稍有不慎就会造成内存泄漏。


六、尚存在的问题


1. 调用EAP框架上传之后,内存上升很快,离开相应的页面之后,内存减幅不大,疑有内存泄漏,可能与自定义上传类fileuploader的单例化有关。

2. 调用BAIDU地图SDK定位(且打开地图界面),内存上升幅度极大,按百度地图SDK指导相应方法避免不必要的内存泄漏,但是离开相应的页面之后,内存减幅依旧不大。但是重复进入相应的地图界面,内存基本恒定(+-0.1M)。

3. 打点功能不完美:

  打点位置不太准确,可能因为定位不准确导致,尚不知道解决方案。


 

你可能感兴趣的:(项目经验)