java转单片机开发难度

0.前言

1.项目介绍

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

3.工具和插件介绍

4.集成友盟

5.即时通讯

6.项目总结

0.前言

本人14年12月份，从网站开发组转到了移动开发组，自己的java两年半工作经验变成了Objective-C零经验。2015年1月份新启动了一个移动项目，年后因为人事变动，自己从辅助开发变成了"核心"开发，目前项目基本接近尾声，下面进行总结，希望对一些人能有帮助, 另外也希望iOS大牛进行指导。

1.项目介绍

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

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

http://github.ibireme.com/github/list/ios/整理了比较常用的iOS第三方组件，以及github上的统计。

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

(1)AFNetworking

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

需要注意的是AFNetworking对服务器返回的ContentType要求比较严格，默认只支持application/json的返回。所以可能需要添加对text/html返回的支持，否则可能无法获得返回数据。

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

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

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

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

(2).FMDB

对sqlite数据库操作进行了封装，demo也比较简单。

(3).MBProgressHUD

也是iOS项目常用的一个组件，用于显示过渡效果的，比如网络请求之前显示loading，网络结束隐藏loading。建议封装在BaseViewController中，所有ViewController继承就能使用。

(4).MJRefresh

这个是李明杰老师的作品，自己的OC基础就是看他的视频半个周末就基本拿下了。MJRefresh主要用于刷新操作，提供了常用的刷新操作，还有刷新动画，用着很好用。建议把方法封装在BaseViewController中，这样修改刷新操作时，就只需要改动一份。（之前用的旧版MJRefresh，只支持普通的刷新，不支持动画，后来更新后版本变化比较大，旧的方法已经不推荐使用了，所以还是封装基类中使用比较好，方便以后修改）(5).SDWebImage

也是iOS最常用的一个组件，用户加载网络图片，可以缓存到本地。大概原理时，第一次加载后，会根据url加密作为文件名缓存在本地，如果再次加载图片时，就直接从本地加载。用着也比较简单。这里也分享遇到的一个问题，先从网络加载一张小图，然后小图作为占位图，再从网络加载一张大图。

[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调用友盟的推送接口，友盟再去发起苹果的推送服务，使对应的设备收到远程推送信息。

(2).关于第三方登录和分享

这块儿都在友盟的社会化分享中，里面提供了比较全面的文档。建议第三方分享模块不用自己特殊设计，可以使用友盟的默认分享模块（我们项目的分享模块自己进行了设计，包括了收藏，所以整块都需要自定义写UI和写分享代码）。关于友盟的第三方登录和分享需要注意的时，QQ和微信登录分享，都需要手机上安装应用，appstore审核会卡这点，所以需要判断手机是否安装应用，隐藏没有安装应用的图标，这块儿友盟的sdk已经有相关的判断方法（应该是友盟集成了QQ和微信sdk，QQ和微信sdk提供了判断方法）。

第三方登录分享需要到相关的平台注册开发者账号。微信开发者账号（注意不是订阅号）第三方登录需要交钱才能开通，可以支持微信和朋友圈分享。QQ开发者账号可以支持QQ和QQ空间分享（QQ微博好像需要微博开发者账号）。新浪微博需要微博开发者账号。QQ分享开发阶段需要把测试账号加成开发者账号的好友才能测试，微博也类似。

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

第三方登录，我们项目集成了QQ，微信，新浪微博登录。三个平台都能获得用户的screen_name（用户名称），以及对应的平台唯一的id，其中QQ和微信都是openid，新浪是userid。

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

[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时就断开，进入应用再连接。同时应用使用状态下，有心跳检测，判断是否保持连接。

考虑到iOS的特殊性，我们采取了xmpp和远程推送都走的方法，推送的自定义消息体和xmpp消息体一样，消息的处理方法一样。用户聊天发送xmpp消息的同时也调用我们的消息推送接口调用友盟push（push可以设置过期时间，避免特殊情况，推送延时，聊天结束了才收到推送）。一是解决iOS应用未启动时的推送接收，二是解决xmpp丢消息的问题。

关于推送，AppDelage中有两个方法，一个是使用中收到推送，不会提示，会直接处理推送信息。另外是程序非使用状态，收到推送，会进行提示，可以点击推送消息进入应用，获取这一条推送消息的推送消息（需要注意，点击推送启动应用拿到信息时view还没有加载，消息不能立刻处理）。

android端因为是真后台，可以后台一直保持运行，无论收到xmpp消息还是友盟推送，都可以自己进行处理，然后自己弹一个本地推送（也有弊端，如果android程序杀死，就无法接受消息和推送）。iOS端因为后台不可控，所以推送使用远程推送，进入应用连接xmpp再收全部离线消息（不保证友盟推送能否保证及时）。当然大部分都还是正常情况，网络情况比较好的条件下，就实时收到了xmpp的消息或者远程推送。我们又不是QQ和微信，只要保证用户看到的数据能保持一致性就行了（所以QQ和微信就是diao啊）。

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

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

6.项目总结

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

• 框架搭建的时候，要考虑好App中各功能点的实现方案。设计好相关文件目录，封装相关类文件。
• 封装整理相关方法，比如BaseViewController中包括，基本ui，顶部导航条，左按钮，右按钮，标题，相关点击事件，显示/隐藏loading，网络请求失败统一处理方法，上拉/下拉刷新绑定，刷新显示/隐藏。分析项目中的功能相同模块，封装对应操作，相同功能代码维护一份。
• 考虑好刷新机制，比如A页面进入B页面，B更新后，返回后A页面的刷新，如果采用block/delegate的方法，可以统一进行设计。或者多个页面之间的数据刷新，采用通知的方式（KVO），进行更新操作。尽量开发阶段，就把可能出现的问题提前解决。
• 确定是否进行相关页面统计，比如加友盟的页面统计，需要设置相关view的viewWillAppear和viewWillDisappear（）
• ViewController中初始化view和数据请求后刷新view代码分离，封装整理好网络请求前和请求后的操作，考虑好下拉刷新页面和上拉加载更多的相关数据请求和处理。考虑有网状态下的数据缓存以及无网状态下的缓存数据加载
• 提前做好相关页面的跳转，代码解耦，不断优化和重构代码。发现问题或者有更好的解决方案，尽量早期就进行修改，避免修修补补，方便后期维护和扩展。在可以接受的情况下，可以牺牲一些系能，保持逻辑简单，便于维护。
• 通过代码写view计算坐标时，尽量参考上一个元素的坐标和宽高，这样当一个元素位置或宽高发生变化时，其他元素基本都能随着发生变化。
• 数据处理能放在服务器端处理就由服务器端处理，前台就进行无脑显示。
• 考虑程序的兼容性，32位和64位一些变量的值不同，注意值的越界问题。注意程序的内存问题，和使用过程中的内存变化。
• 考虑信息的安全性，沙盒存储的信息可以被查看修改，重要信息请加密。

目录1.UITableView滑动卡顿的优化

2.右滑手势返回

3.添加页面统计

4.debug版和release版

5.关于页面刷新

6.关于页面布局

7.推荐博客

遇到问题和解决方案

本文是Java转iOS-第一个项目总结(1)?的内容补充，分析遇到的一些问题和解决方案，分享一些收获。

1.UITableView滑动卡顿的优化

因为 `UITableView`的cell中有很多图片，在4/4s上滑动比较卡，最开始觉得是机器太老了，但是对比微信和QQ空间，发现还是我们的问题，所以后期进行了优化，通过xcode的性能监控，内存变化不大，但是cpu飙升的俩厉害，通过xcode的Time Profiler工具进行了监控（Product—Profile—Time Profiler），找到了执行比较慢的方法，原因是转换图片路径的时候，调用自己的方法进行了log打印，造成滑动卡顿。

网上关于UITableView的性能优化的文章有很多，官方给了一个例子LazyTableImages介绍懒加载UITableview的Image，在滑动的时候，不加载图片，停止滑动时再加载图片，并把UIImage放在对象中，判断对象中图片不会空则显示图片，否则还是占位图。例子中图片都是app的icon，都是小图，所以那样做也没问题。但是我们项目中的图片都是大图片，如果把图片放在对象中，显然不合适，所以当时pass了这个方案。

前几天在Glow 技术团队博客看到了UIScrollView 实践经验 

这篇博客，里面讲到了相同的技术，优化了滑动减速过程中也进行图片加载，另外用到了SDWebImage，里面判断SDWebImage是否缓存过图片，如果缓存过，从本地加载图片，否则使用占位图，应该是比较好的解决方案了

2.右滑手势返回

iOS7自带了这个功能，后来设计人员提出了优化建议，但我们的程序却不能支持这个功能，原因程序返回操作的方法包含其它业务逻辑，比如返回后刷新上一页面的数据，返回后是否显示底部菜单。而系统的默认的右滑返回，只是做了页面返回，并不会触发自己的返回方法。

所以为了这个功能还是代码进行了修改，更新上级页面的操作放在本页面数据刷新的地方。底部菜单只在首页的几个页面显示隐藏，其它去掉相关业务逻辑。因为改这个地方还和测试起了冲突，因为项目临近收尾，修改可能会带来问题，优化的功能可以放在后期。但是作为开发人员还是进行了修改，加班进行了测试。表面上看这是个优化，其实却是问题暴漏。如果有新需求的可以不做，但是有问题却应该尽早解决。

另外这个地方做个内容补充，页面之间的逆向数据传递，可以用回调（block）、委托（delegate）和通知（notifacation），需要熟练掌握这几个知识点以及实现方法，区分之间的差别。

3.添加页面统计

友盟统计还是比较强大的，虽然项目没有要求加相关功能，但是还是加了相关统计，需要在对应ViewController中的viewWillAppear和viewWillDisappear中加入一行代码，传入当前页面的名字，最开始只加了几个页面，所以代码是写死的。全部页面要加统计,需要对代码进行了改进，封装在自己BaseViewController中

-(void)beginLogPageView
{
    [MobClick beginLogPageView:NSStringFromClass([self class])];
}
-(void)endLogPageView;
{
    [MobClick endLogPageView:NSStringFromClass([self class])];
}

在子页面中调用统计就比较简单了

-(void)viewWillAppear:(BOOL)animated{
    [super viewWillAppear:animated];
    //添加页面统计
    [self beginLogPageView];
}
-(void)viewWillDisappear:(BOOL)animated{
    [super viewWillDisappear:animated];
    //结束页面统计
    [self endLogPageView];
}

Method Swizzling和 AOP实践里面提供了更高大上的解决方案，顺便可以学习OC的runtime。 

在Java领域中，Spring框架以IOC和AOP著称，所以语言和涉及里面都是想通的。虽然作为io是新手，但是我是懂AOP的_。

4.debug版和release版

之前自己对于debug版和release版没有太多概念，只是知道平时开发的时候是debug版，当要发布的时候改成release版，看到一些宏定义，根据不同版本设置不同的宏，比如debug版的时候，NSLog可以输出，release的时候不输出。

前段时间，看到一篇Xcode宏定义选项以及Release版去NSLog的文章时，就想明白了，在xcode中可以设置宏，debug下有个默认设置 debug=1，所以

#if DEBUG    
#warning NSLogs will be shown
#else
#define NSLog(...) {}
#endif

应该就是判断这个值 

在之前的JavaWeb项目中，我们会使用Maven进行项目管理，在Maven的pom.xml可以添加profiles,配置不同的版本，比如开发版，测试版，生产版，不同版本下有不同的配置文件，比如数据库连接，log配置等,打包编译项目时可以通过Maven选择不同的版本。这样的好处是切换版本的时候，不用修改相关带代码，避免出现不必要的错误。

转iOS后一直在找相关的解决方案，后来才意识到这个就可以做到，只不过苹果里面只有debug版和release版，没办法自定义新的版本（或者是我还没找到，请大神赐教），但是也可以进行相关配置，保证release版的配置都是正确的

另外补充一下，在C/C++中重复引用头文件会出错，所以头文件引用的时候可以使用下面方法，自定义头文件的引用名，xcode生成头文件的时候也会默认加上这个

#ifndef xxxx
#define xxxx
#endif

所以就会引起一个疑问，自己平时在程序中如果不是这样引用头文件，是否会引起冲突，网上搜索给出答案。oc中不推荐#include引用头文件，推荐使用#import就是可以解决这个问题的。

5.关于页面刷新

一个页面，可能包括下拉刷新，上拉加载更多，翻页到最后时隐藏刷新，没网下从缓存中加载数据等多种情况，所以页面刷新的功能最好提前考虑到，否则这些功能在后期修改时会变得很麻烦，一不小心就容易出问题。比如翻页到最后隐藏加载更多，然后下拉刷新的时候，可能需要把隐藏的控件给显示出来。所以代码要考虑好，设计好，封装好。

6.关于页面布局

现在的iOS教程，大部分讲得都是故事板，但是在实际项目中，更多的还是用代码。 

唐巧的博客StoryBoard–看上去很美中说明了原因，公司项目多是协同开发，一旦两个人同时修改了故事板，基本上都会产生冲突，解决起来会非常麻烦，所以作为新手还是应该多学习纯代码开发。之前项目使用的就是代码写UI，获得屏幕宽高，在不同控件之间算坐标，如果代码不规范,控件的坐标和宽高是独立的，如果一个控件发生变化，就会产生雪崩。

这里推荐Masonry，也是github上非常有名的一个iOS组件，解决了自动布局写约束麻烦且繁琐的缺点，比较容易学习和令人接受。iOS还有个VFL语言，相比还是Masonry感觉更好。

这里再推荐一个iOS组件--ReactiveCocoa，是一个kvo组件，用来做消息监听，效果就是可以像Java写事件监听一样写OC代码 。之前给一个UIButton绑定事件，需要调用addTarget绑定，然后再写一个方法，或者监听UITextFiled的变化，都要写很多委托方法。使用ReactiveCocoa后，写法就大变了，代码看起来会整洁很多，而且显得比较高大上一点。

现在新的项目中，添加使用了上面两个组件。