<轉>從Java轉iOS第一個項目總結

標籤：

從Java轉iOS第一個項目總結 閱讀目錄

• 0.前言
• 1.項目介紹
• 2.項目使用的第三方開源庫
• 3.工具和外掛程式介紹
• 4.整合友盟
• 5.即時通訊
• 6.項目總結

  0.前言

        本人14年12月份，從網站開發組轉到了移動開發組，自己的java兩年半工作經驗變成了object-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的返回。所以可能需要添加對test/html返回的支援，否則後台可能無法獲得返回資料。

        另外就是檔案上傳，這裡推薦使用第二種

?

123	[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加密作為檔案名稱緩衝在本地，如果再次載入圖片時，就直接從本地載入。用著也比較簡單。這裡也分享遇到的一個問題，

先從網路載入一張小圖，然後小圖作為展位元影像，再從網路載入一張大圖

?

12345

[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中Google的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（不過是收費的，免費的只能查看），還可以用Firefox瀏覽器的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，需要設定對應平台的分享地址，參考解決方案，比如

?

1234	[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位一些變數的值不同，注意值的越界問題。注意程式的記憶體問題，和使用過程中的記憶體變化

<轉>從Java轉iOS第一個項目總結