Java轉iOS-第一個項目總結(1)

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.工具和插件介紹

1. Xcode

   iOS開發的官方工具，也沒別的選擇。有些功能作的確實挺帥的，好比StroyBoard的拖拽事件綁定。不爽的地方就是沒有代碼格式化，另外點擊方法，可能跑到另一個類中了！！另外左邊的目錄也不會自動發生變化，定位到對應文件，須要command+shift+j

2. SimPholders2

   能夠快速找到模擬器對應的沙盒目錄，啓動後右側頂部工具欄有個相似關閉按鍵的按鈕，顯示最近的幾個應用，點擊就進入到了對應的沙盒目錄

3. 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中的，相關頁面繼承，同時傳入對應的資源類型，只用維護一份代碼。

        另外微信分享可能須要注意一下content的長度

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的總結下：

    1.框架搭建的時候，要考慮好App中各功能點的實現方案。設計好相關文件目錄，封裝相關類文件。

   2.封裝整理相關方法，好比BaseViewController中包括，基本ui，頂部導航條，左按鈕，右按鈕，標題，相關點擊事件，顯示/隱藏loading，網絡請求失敗統一處理方法，上拉/下拉刷新綁定，刷新顯示/隱藏。分析項目中的功能相同模塊，封裝對應操做，相同功能代碼維護一份。

    3.考慮好刷新機制，好比A頁面進入B頁面，B更新後，返回後A頁面的刷新，若是採用block/delegate的方法，能夠統一進行設計。或者多個頁面之間的數據刷新，採用通知的方式（KVO），進行更新操做。儘可能開發階段，就把可能出現的問題提早解決。

    4.肯定是否進行相關頁面統計，好比加友盟的頁面統計，須要設置相關view的viewWillAppear和viewWillDisappear（）

    5.ViewController中初始化view和數據請求後刷新view代碼分離，封裝整理好網絡請求前和請求後的操做，考慮好下拉刷新頁面和上拉加載更多的相關數據請求和處理。考慮有網狀態下的數據緩存以及無網狀態下的緩存數據加載

    6.提早作好相關頁面的跳轉，代碼解耦，不斷優化和重構代碼。發現問題或者有更好的解決方案，儘可能早期就進行修改，避免修修補補，方便後期維護和擴展。在能夠接受的狀況下，能夠犧牲一些系能，保持邏輯簡單，便於維護。

    7.經過代碼寫view計算座標時，儘可能參考上一個元素的座標和寬高，這樣當一個元素位置或寬高發生變化時，其餘元素基本都能隨着發生變化。

    8.數據處理能放在服務器端處理就由服務器端處理，前臺就進行無腦顯示

    9.考慮程序的兼容性，32位和64位一些變量的值不一樣，注意值的越界問題。注意程序的內存問題，和使用過程當中的內存變化

    10.考慮信息的安全性，沙盒存儲的信息能夠被查看修改，重要信息請加密

Java轉iOS-第一個項目總結(2)