<转>从Java转iOS第一个项目总结

从Java转iOS第一个项目总结

阅读目录

0.前言

1.项目介绍

2.项目使用的第三方开源库

3.工具和插件介绍

4.集成友盟

5.即时通信

6.项目总结

0.前言

本人14年12月份，从网站开发组转到了移动开发组，本身的java两年半工做经验变成了object-c零经验。2015年1月份新启动了一个移动项目，年后由于人事变更，本身从辅助开发变成了"核心"开发，目前项目基本接近尾声，下面进行总结，但愿对一些人能有帮助, 另外也但愿ios大牛进行指导

回到顶部

1.项目介绍

项目属于一款社区类软件，包含小组/帖子，视频，文章，推荐搜索，即时通信，好友，第三方登陆/分享，推送等，涵盖经常使用app的基本功能

回到顶部

2.项目使用的第三方开源库

github.ibireme.com/github/list…整理了比较经常使用的ios第三方组件，以及github上的统计

项目使用了CocoaPods(相似java中的maven)管理经常使用的第三方库,一些特殊的单独引用,下面介绍下比较好用的几个

1.AFNetworking

目前比较推荐的ios网络请求组件，默认网络请求是异步，经过block回调的方式对返回数据进行处理。

须要注意的是AFNetworking对网络请求返回的ContentType要求严格，好比默认只支持application/json的返回。因此可能须要添加对test/html返回的支持，不然后台可能没法得到返回数据。

另外就是文件上传，这里推荐使用第二种

1

2

3[formData appendPartWithFormData: name:];

[formData appendPartWithFileData: name: fileName: mimeType:];

第一种只须要传入表单名和文件流，源码也是根据文件流得到对应的文件名和文件类型而后调用第二种方法。可是楼主遇到了使用第一种方法，提交后后台判断为非文件上传，没法得到文件流。还有若是后台是根据文件后缀文件类型，那么第一种也没法使用。

AFNetworking是异步的，也可使用同步的网络请求方法.

2.FMDB

对sqlite数据库操做进行了封装，对于作后台开发多年的我来讲，没有什么问题，看一下就知道怎么用了

3.MBProgressHUD

也是ios项目经常使用的一个组件，用于显示过渡效果的，比较网络请求以前显示loding，网络结束隐藏loading。建议封装在BaseViewController中，全部ViewController继承就能使用

4.MJRefresh

这个是传智播客李明杰老师的做品，本身的oc基础就是看他的视频半个周末就基本拿下了。MJRefresh主要用于刷新操做，提供了经常使用的刷新操做，还有刷新动画，用着很好用。建议把方法封装在BaseViewController中，这样修改刷新操做时，就只须要改动一份。（以前用的旧版MJRefresh，只支持普通的刷新，不支持动画，后来到更新后发现变化很大，旧的方法已经不推荐使用了，因此仍是封装基类中使用比较好，也方便修改）

5.SDWebImage

这个也是ios最经常使用的一个组件，用户加载网络图片，能够缓存到本地。大概原理时，第一次加载后，会根据url加密做为文件名缓存在本地，若是再次加载图片时，就直接从本地加载。用着也比较简单。这里也分享遇到的一个问题，

先从网络加载一张小图，而后小图做为展位图，再从网络加载一张大图

1

2

3

4

5[imageView sd_setImageWithURL:[NSURL URLWithString:imageURLString] placeholderImage:DefaultPostPic];

[imageView sd_setImageWithURL:[NSURL URLWithString:_bigImageURLStringArray[i]] placeholderImage:imageView.image options:SDWebImageDelayPlaceholder completed:^(UIImage *image, NSError *error, SDImageCacheType cacheType, NSURL *imageURL) {

}];

6.RDVTabBarController

一个TabBar组件，能够方便设置底部菜单的文字图片，点击效果，小红点提示等

7.Toast

相似android的toast提示效果，封装在BaseViewController中，须要的地方进行提示

8.XMPPFramework

ios惟一的xmpp类库，做者在去年8月份添加了xep-0198协议支持（流管理，用于xmpp断线重连），可是经过pod进行更新时，没法下载到最新版本，可能0198尚未完善好，没法做为正式版。

9.TPKeyboardAvoiding

用户键盘弹出自动计算高度，进行屏幕滚动操做

10.AMR

作即时通信的音频处理，目前咱们的即时通信使用的录音文件是m4a，便于web端的音频播放

11.TQRichTextView

用于作富文本视图控件显示，用于即时通信的表情显示，以及资源评论的富文本显示

12.CSGrowingTextView

用做即时通信文本框和评论文本框使用，能够显示多行输入

13.MJExtension

也是李明杰老师的做品，用于json转model进行使用，有点相似于java中谷歌的Gson.转换效率听说也很高，使用也比较简单，只要先后台约定好，json直接就转成了model。一个工做多年的ios朋友说，一个项目主要的是对model层的管理，他推荐的是Mantle。不过MJ这个更轻量级点,用着也更加简单。

回到顶部

3.工具和插件介绍

Xcode

ios开发的官方工具，也没别的选择。有些功能确实作的挺帅的，好比StroyBoard的拖拽事件绑定。不爽的地方就是没有代码格式化，另外点击方法，可能跑到另一个类中了！！另外左边的目录也不会自动发生变化，定位到对应文件，须要command+shift+j

SimPholders2

能够快速找到模拟器对应的沙盒目录，启动后右侧顶部工具栏有个相似关闭按键的按钮，显示最近的几个应用，点击就进入到了对应的沙盒目录

VVDocumenter-Xcode

xcode工具，///生成注解模板，xcode这功能都不给集成，唉

其余的基本就不用介绍了，有的也不怎么好用。SVN可使用Cornerstone，Git可使用SourceTree，sqlite可使用SQLite Professional（不过是收费的，免费的只能查看），还能够用火狐浏览器的sqlite插件。

回到顶部

4.集成友盟

友盟，提供了App和运用的一站式解决方案。公司上个移动项目用到了友盟的推送服务，这个项目中, 还使用了分享，第三方登陆的功能，本身也亲自参与到了相关集成。友盟的开发者文档还算是比较全的，遇到问题能够联系客服或者到友盟的论坛找解决方案。

1.关于推送

ios推送分为本地推送和远程推送，本地推送是指本地本身弹出信息，另一个就是远程推送，当应用未启动时，也能收到相关推送信息。咱们项目没有使用本地推送，使用的都是友盟的远程推送。包括消息（聊天）和通知（用户信息通知）中。用户在聊天过程当中，手机除了发送即时通信之外，也调用后台接口，发送友盟推送。另外用户的帖子，评论，关注，点赞等都会由后台调用友盟的推送。

友盟推送（和友盟地址不一样）包括单播，列播，和广播，其中广播限定次数天天3次，能够和友盟申请提升次数，其余不限定次数，目前来看单播速度仍是挺快的。使用友盟推送，须要在苹果开发者帐号中，新建两个推送证书，提交给友盟（友盟有详细的文档，能够参考）。能够在友盟后台，把测试设备的deviceToken加到友盟推送的后台（须要64位token，须要经过方法进行计算，直接在xcode或者ituns中拿到token不行），从友盟后台发起推送。

推送的大概流程就是，手机在第一次启动app的时候开启推送服务，手机在启动app的时候，注册友盟服务，同时把deviceToken提交到本身的后台，后台在能够在须要的时候拿着deviceToken调用友盟的推送接口，友盟再去发起苹果的推送服务，使对应的设备收到远程推送信息。

咱们的推送消息，自定义消息体和xmpp消息体同样，除了友盟远程推送之外，xmpp也会发一份，两个消息本地只存储一份，哪一个收到先处理哪一个。

2.关于第三方登陆和分享

这块儿都在友盟的社会化分享中，里面也提升了比较全面的文档。建议第三方分享不用本身特殊设计，可使用友盟的默认分享模块（咱们项目的分享模块本身进行了设计，包括了收藏，因此整块都须要自定义写UI和写分享代码）。关于友盟的第三方登陆和分享须要注意的时，QQ和微信登陆分享，都须要手机上安装应用，因此须要特殊处理，判断手机是否安装应用，不然隐藏相关的图标，这块儿友盟的sdk已经有相关的判断方法（应该是友盟集成了QQ和微信，QQ和微信sdk提供了判断方法）。

第三方登陆分享须要到相关的平台注册开发者帐号。微信开发者帐号（不是订阅号）的第三方登陆须要交钱才能开通功能，能够支持微信和朋友圈分享。QQ开发者帐号能够支持QQ和QQ空间分享（QQ微博好像须要微博开发者帐号）。新浪微博须要微博开发者帐号。QQ好像须要把测试帐号加成QQ开发者帐号的好友才能测试，微博也相似。

第三方登陆本身遇到了QQ提示不是最新版的文本，在友盟论坛中找到了解决方案。

第三方登陆，咱们项目集成了QQ，微信，新浪微博登陆。三个平台都能得到用户的screen_name（用户名称），另外得到对应的平台惟一的id，其中QQ和微信都是openid，新浪是userid。

第三方分享，文档提供了分享图片，视频，语音。若是是分享url，须要设置对应平台的分享地址，参考解决方案，好比

1

2

3

4[UMSocialData defaultData].extConfig.qqData.url = shareUrl;

[UMSocialData defaultData].extConfig.qzoneData.url = shareUrl;

[UMSocialData defaultData].extConfig.wechatSessionData.url = shareUrl;

[UMSocialData defaultData].extConfig.wechatTimelineData.url = shareUrl;

另外分享到QQ空间，必须制定一张图片，不然分享不成功。

第三方分享建议封装到一个类中，咱们项目是几个详情页都有分享，评论，举报，收藏，点赞等功能。封装在一个BaseDetailViewController中的，相关页面继承，同时传入对应的资源类型，只用维护一份代码。

回到顶部

5.即时通信

即时通信网上有第三方的解决方案，好比环信，融云等。咱们是本身搭的xmpp服务器，服务器使用的tigase，以前写过相关的博客，本身去年也作了对应的webim。前段时间看了环信webim的sdk，使用的也是strophe的js类库，相关实现跟咱们的差很少，不过本身实现的xmpp会遇到了很多问题，好比丢消息。因此若是想比较快速的实现im，推荐使用第三方的解决方案。

移动端的丢消息大概是这个样子。A和B通信，A发了一条消息给服务器，服务器发给B，可是B网络很差掉线了，而服务器殊不知道B退出了（B正常退出会给服务器发通知），因此消息丢失了。XMPP中有xep-0184协议（消息回执），A给B发消息，消息体中带一行代码，要求消息回执，当B收到消息后发送一条回执，证实我收到了。后来XMPP又有了xep-0198协议（流管理），断线后快速重链，同时判断必定时间收不到消息，就把消息写离线消息，减小丢消息状况。可是可能网络状况复杂，加上各类不肯定因素，可是还会出现丢消息的问题。因此目前比较靠谱的方法就是存全部的聊天记录，由手机端根据时间点去数据库拉消息，只要发出的消息就不会丢。

此次即时通信模块进行了相关改动，也是参考了以前开发人员的一些建议。好比用户home返回的时候，断开xmpp链接（ios进入后台后，只有5秒的处理时间，特殊方法可延长到10分钟，若是内存不够，应用随时就被杀死了）。因此返回home时就断开，进入应用再链接。同时应用使用状态下，有心跳检测，判断是否保持链接。用户聊天除了发送xmpp消息，同时也调用远程push（push设置过时时间，避免特殊状况，推送延时，聊天结束了才收到推送）。

关于推送，ios有AppDelage中有两个方法，一个是使用中收到推送，不会提示，会直接处理推送信息。另外是程序非使用状态，收到推送，会进行提示，点击推送进入应用，调用对应方法得到对应的推送消息，（须要注意，点击推送启动应用，view尚未加载，消息不能马上处理）。

因此考虑到ios的特殊性，采起了xmpp和远程推送都走的方法，推送的自定义消息体和xmpp消息体同样，消息的处理方法同样。一是解决ios应用未启动时的推送接收，二是解决xmpp丢消息的问题。

android端由于是真后台，因此能够后台一直保持运行，android端不管收到xmpp消息仍是友盟推送，都是本身处理，而后本身弹一个本地推送（也有弊端，若是android程序杀死，就没法接受消息和推送）。ios端由于后台不可控，因此推送使用远程推送，进入应用再收xmpp所有离线消息（也可能有问题，好比用户量大，友盟推送可否保证及时）。固然大部分仍是正常状况，在使用过程当中，就实时收到了xmpp的消息或者远程推送，直接就提示了。只要保证用户看到的数据一致性就好了（因此QQ和微信难以望其项背啊）。

根据测试反馈的状况，IOS这个应用的丢消息状况比上个应用有必定改善。具体状况再进一步观察把。

咱们的即时通信也包括语音和图片，采用的是http的解决方案，xmpp也支持二进制的传输，可是估计都没人那样用。具体就是先把附件传到附件服务器拿到附件服务器的地址，再封装到消息体。接收方收到消息解析的时候，再从附件服务器拿到对应的资源，加载到本地。 同时屏蔽，取消屏蔽等一些实时操做也都会发xmpp，第一时间双方更新状态。

回到顶部

6.项目总结

目前项目已经接近尾声了，再过不到半月就要上线了。本身算是项目的主要负责人了。项目前期ios和android有一周多前期准备和框架搭建，另外就是我根据页面原型，定义接口文档开发计划，协调开发。可能你们项目经验也都很少把，框架和接口或多或少都会有点问题，随着经验慢慢积累确定都会愈来愈好的。关于IOS的总结下：

1.框架搭建的时候，要考虑好App中各功能点的实现方案。设计好相关文件目录，封装相关类文件。

2.封装整理相关方法，好比BaseViewController中包括，基本ui，顶部导航条，左按钮，右按钮，标题，相关点击事件，显示/隐藏loading，网络请求失败统一处理方法，上拉/下拉刷新绑定，刷新显示/隐藏。分析项目中的功能相同模块，封装对应操做，相同功能代码维护一份。

3.考虑好刷新机制，好比A页面进入B页面，B更新后，返回后A页面的刷新，若是采用block的方法，能够统一进行设计。或者多个页面之间的数据刷新，采用通知的方式（KVO），进行更新操做。尽可能开发阶段，就把可能出现的问题提早解决。

4.肯定是否进行相关页面统计，好比加友盟的页面统计，须要设置相关view的viewWillAppear和viewWillDisappear（）

5.ViewController中初始化view和数据请求后刷新view分离，封装和整理好网络请求前和请求后的相关操做，考虑下拉刷新页面和上拉加载更多的相关数据处理和view显示。有网下的数据缓存以及无网下的缓存数据加载

6.提早作好相关页面的跳转，以及代码解耦，须要不断优化和重构代码。若是发现问题或者有更好的解决方案，尽可能早期就进行修改，避免修修补补，代码不便于后期维护和扩展。在能够接受的状况下，能够牺牲一些系能，保持逻辑简单，便于维护。

7.经过代码写view计算坐标时，尽可能参考上一个元素的坐标和宽高，这样当一个元素位置或宽高发生变化时，其余元素基本都能随着发生变化。

8.数据处理能放在服务器端处理就由服务器端处理，前台就进行无脑显示

9.考虑程序的兼容性，32位和64位一些变量的值不一样，注意值的越界问题。注意程序的内存问题，和使用过程当中的内存变化