做iOS开发有近两年半(实习一年，毕业一年半)的时间，其中大部分时间都在自学，现在将自己在工作遇到的一些疑问和要思考和注意的地方记录一下，以便于以后回顾，在开发App的过程中，慢慢的发现需要考虑的方面和问题越来越多。
1. 先从项目的结构目录开始说吧.
在建立新的项目的时候，整理好一个结构比较清晰的项目目录，对之后的开发工作包括后续人员的维护来说无异于是一个很好的开始。好的项目目录一目了然，比较直观。而相对于不好的结构目录，比较混乱，查找文件，模块等等都是比较耗费时间的。尤其是对于刚刚接手你的项目的新员工来说，熟悉项目就变的是一件非常痛苦的事情了。所以这一点很重要
2.项目的结构框架 UITabbar
这里的框架是指项目的入口，app的基本骨架，就像是盖房需要考虑的地基一样。根据你项目需求来决定你的UITabbar是否使用系统以及自定义。其实，没什么太大的差别，只不过系统的UITabbar使用起来有一定的局限性，完全不如自定义的Tabbar来的自由。市面上app采用的大多数还是自定义tabbar(个人观点,仅限参考)，不过也有许多app使用的系统的。
3.代码质量
写代码的时候要遵守一条准则高内聚,低耦合,这是一条黄金法则，但是真正写代码能做到的却也是很困难。有些经验不多的人甚至不考虑，只是注重于功能上的实现。这对项目后期来说，维护以及重构将会变得无比困难。所以很重要。
4.项目重构
鉴于这一项与代码质量很接近,就直接说这个。很多项目，由于前期时间比较紧，任务比较繁重，所以developer在开发项目的时候旨在于想将功能实现，后期可以考虑重构，这个确实是很多developer的通病。如果项目基于以上三点而言，重构还是可以进行的，但是如果项目写的很混乱，那么浪费的就是时间成本了。也许实现一个功能只需要一个月的时间，那么重构就需要花费两个月甚至更长时间。所以，如果可以做到，那么在写代码的时候就尽量写的优雅一些，这样对后期的工作会变的轻松。
5.第三方框架的选型
非常感谢那些本着开源精神在开源社区贡献代码，方便别人developer，造了很多非常优秀的轮子供大家使用，为大家节省了很珍贵的时间资源，pod下来就可以使用，甚至不用考虑别人是如何实现的。但是，有一点不得不提醒的，对于一个项目来说，最好还是不要太过于依赖第三方library，假设如果你使用的第三方library不再更新，那么你在更换的时候就会发现项目中到处都是用到它的地方(都要抓狂了)，所以这个时候高内聚，低耦合会拯救你脱离苦海，如果你写的代码，封装的模块比较完美，那么这就不是问题了。还有一种情况就是，也有不少公司，项目中用到所有东西都是自己封装的，不允许使用第三方，你就要不得不强制脱离依赖第三方的习惯，这同样也考验你对iOS API掌握的基本功了。比如说，网络请求，我们从开始开发就使用AFNetworking,在新的公司不允许使用第三方，需要自己封装一套网络请求机制，需要自己实现一套解析机制，你说不会？
6.架构之网络层设计
开发一个app，肯定离不开移动网络。所以，在开发项目的时候，需要封装一套适合于当前项目的网络层。不论底层是依赖于第三方，还是自己实现的。就比如说，一个网络层，层次分为三层，最外层是View,响应用户的交互，第二层则是根据用户的操作，从第一层接收参数并为每个API配置对应的参数，第三层则是发送网络请求的操作，由第二层调用。网络层的设计也要考虑很多因素: 比如 get,post 上传，下载，加密，取消请求，并发异步请求，根据项目的需求，封装对应的接口。
7.数据层之缓存机制的设计
说完网络，就需要考虑本地缓存了。设计适合你app的缓存机制，需要考虑到使用的cocoaTouch框架，perfrence（偏好设置）,plist ,coreData,sqlite.要清晰理解你添加缓存功能的目的，要考虑线程安全，缓存的效率，以及缓存的流程等等。
这里提一下一个人的博客:CasaTaloyum's blog，CasaTaloyum写了几篇关于网络层，数据层以及部署等等的博客，分析很不错。目前就职于天猫。
8.异常处理
app中难免会发生这样或那样的exception，error以及crush，这个同样也考虑好如何处理这些异常，报错以及闪退，还要学会分析错误log，调试，以及进行错误统计。然后尽最大可能的处理这些异常，bug，给你的app提供更好的用户体验。假设你的app偶尔或者经常发生闪退，那么你自己是用户也受不了吧，更别说大多数用户能忍受少数的bug都是万幸了。也许闪退一次就不再使用了。所以，下载量是一个，但是用户留存率更为重要。
9.性能优化
之前看过一篇博文说的是过早的性能优化是不必须的。所以要在合适的时机对你的app进行优化，什么是合适的时机？比如你的app在刚开始使用的时候很流畅。但是由于加载的数据多了，访问的页面多了，请求变的缓慢，页面变的明显卡顿，那么这就是你要优化的信号。优化的地方有很多，也有很多介绍如何优化的帖子，博文。UI的优化，离屏渲染导致的卡顿等等，还有内存溢出、内存泄漏、内存暴增、网络请求加载速度缓慢，弱网络环境下使用的情况，如果一时间加载大量的数据，如何高效率的处理，如分页加载，如何高效的缓存到本地。此外，还要考虑 流量的使用情况，电量的使用情况等等
10.app在svn/git上的版本管理
如果工作过一段时间，那么对于svn/git/cvs等源代码工具一定不会陌生，在开发工程中对于源代码的管理是一部分，对app的版本管理同样也是很重要的一部分。因为我们需要用来进行版本迭代，以及维护之前的版本的app. svn/git flow，是一个很标准的流程，你也可以考虑自己的项目适合怎样的管理流程，我们需要区分dev版以及realease版。在开发过程中，比如程序员A需要在trunk上新开一个分支dev1.2.0上开发新版本的功能，那么realease(发布版)1.1.0如果出现了紧急bug或者其他的问题，就需要程序员B在打的tag的realease_1.1.0上再开一个dev1.1.0分支修复问题，然后提交，合并到realease_1.1.0上重新发布，这样既不影响新版本的开发，又不影响上个版本的维护。
11.后端提供的API版本兼容
说起来这虽然不应该是我们前端要考虑的问题，但是遇到了就一并记录一下，API的兼容性在于比如 后端提供了一个注册的接口，由于初期的接口设计的比较繁琐，需要用户输入的注册信息很多，也就是客户端1.1.0需要post多个参数进行注册，那么我们在开发app1.2.0的时候，后端接口大调整，只保留了手机号码注册。如果不考虑兼容性，那么由于接口结构改变甚至整个接口url都改变了，那么1.1.0v的用户无法再使用注册了。这个问题解决的方案其实也有很多种。我之前Google了一下，就记得一种，先大概写下，具体的真的需要解决，那么就请自行Google。这里提供的一种方案就是后端的api也进行版本管理，app客户端在请求的时候，带上当前版本，然后后端进行版本识别，如果识别到用户使用的是1.1.0v，那么就让他们使用1.1.0v的api。
12.与后端联调的时候遇到的问题以及可以和后端协商实现的功能
我在一次做请求的时候，发现无论我怎么请求，返回的都是之前的数据，未得到任何的刷新(当然我请求的数据是实时性的)，和后端沟通之后，找到了解决的方案，就是我在进行GET请求的时候，由于api接口的请求头信息设置是 cache而不是no-cache，大概就是因为这么个原因，所以我在使用ge方式进行请求的时候，在后面带上一个时间戳，Google了一下，意思是说，这种方式可以欺骗浏览器缓存，在PC前端，经常使用这种方式处理因为缓存而数据未进行刷新的情况。我在带上时间戳之后，发现果然返回的最新的数据。此外，我还考虑到了另外一种情况，就是是否是我设置了AFN的url的缓存策略不合适导致的，这个目前还没有去验证。另外就是与后端协商实现的功能就是缓存了.当数据刷新相对来说比较频繁，或者数据有时候一天更新好几次，有时候也会好几天更新一次，我们不知道什么时候该刷新新的数据，什么时候使用缓存数据，那么我们可以考虑使用ETag/Last-Modified来进行缓存的管理,开发者会把Last-Modified 和ETags请求的http报头一起使用，这样可利用客户端（例如浏览器）的缓存。因为服务器首先产生 Last-Modified/Etag标记，服务器可在稍后使用它来判断页面是否已经被修改。本质上，客户端通过将该记号传回服务器要求服务器验证其（客户端）缓存
13. 注重培养自己的沟通能力以及与团队的协作能力
在工作中，通常需要不断的与团队成员进行沟通，定期汇报项目进度，项目中还存在哪些问题，存在哪些技术门槛等等。一个人具有良好以及优秀的沟通协作能力，对项目的开发具有很大帮助。比如说你及时的反映了项目中存在的问题，那么团队成员就会就会分配开发资源来为你解决难题提供最大的帮助，即使没有帮助，那么你出现了问题，团队成员可以帮助你分析，提供一些不同的解决方案或者思路，你也就不至于闷头不说，到最后一个问题卡着进度，谁也不知道你有解决不了的问题，因为这样耽误工期以及交付时间就有些得不偿失了。这些沟通不仅仅相对于做项目，还有与部门负责人，项目经理，CTO，UI，以及PM等等各个岗位的沟通。所以培养自己的良好的沟通习惯是非常必要的。
14. 对项目工期进行评估
对于产品或者BOSS下发的一个功能或者其他的需求，需要你估计完成任务大概需要的天数，即工期。这时候，有不少人也许会犯眼高手低的毛病，在评估时，不要觉得有些需求看上去很简单，就信誓旦旦的说我需要几天几天就可以搞定，但是真正实现的时候往往会发现很多隐藏的小需求或者坑，完成下来也许会超过预估很多时间，当到了项目工期时你却无法交付，发现还有不少的界面或者功能或者bug没有修改完成。这样的情况真的不少见，实际有经验的developer往往会给出一个大概的时间，在说预计工期时，会习惯的为自己预留出几天的空闲时间来回顾项目的需求，以及修改不完善的地方。
15.app测试以及用户的反馈
在app上线前，往往会将项目打包分发给测试部门进行测试，专业的测试一般会出示一份测试文档以及bug汇总。还有一些部分用的是在线任务/bug管理系统，可以在管理系统上直接指派新的需求或者功能，同时也可以将出现的bug等等指向你，比如我公司现在用的redmine.应该有不少人都用过，各部门还可以清晰查看到你的完成进度，挺好用的管理系统。之后就是线上用户的反馈，要时时的进行关注，调研用户提出的bug，功能建议以及新的需求等等。毕竟用户是上帝嘛。
就先写到这里，明天有时间继续更新，上面的只是我目前想到的，之后想到的会继续记录更新，上面的考虑方面，有哪一点有比较好的实现方式或者解决方案大家可以一起交流学习 我微信和QQ都是:
502086651。有说错的地方或者理解不正确的地方欢迎指正，有补充的也欢迎评论。
网友评论