天天看點

iOS更新經驗分享

作者認為,及時關注、快速反應、覆寫測試是面對iOS系統更新時最重要的三大原則,文中還詳細分析了iCloud Storage和Automatic Reference Counting這兩大iOS 5新特性。

2011年10月初,iOS 5正式釋出,帶來了大量新特性。随之而來的是大量應用需要針對iOS 5系統進行更新适配。每次系統更新,我們公司都要對正在維護的衆多已上線應用進行更新适配,這可以說是一個痛苦的過程,但在這個過程中我們也積累了一些應 對iOS系統更新的原則、方法和經驗。

及時關注iOS系統更新動态

  • iOS開發者門戶網站:開發者官網上擁有大量的最新資訊和每次系統更新的相關資料,并且真實有效,有助于開發者第一時間了解系統更新的相關資訊。
  • 開發者論壇:開發者可以登入官方論壇了解最新的技術,國内的一些iOS開發者論壇也提供了大量本土開發者的開發心得,如CSDN、 CocoaChina等,大家可以找到其他開發者在系統更新中遇到的問題和解決的方案,也可以提出自己遇到的問題,會有很多熱心的開發者來幫助解答。
  • 其他視訊類資源:蘋果每次系統更新或新産品釋出都會舉辦釋出會,會對各種新産品新特性進行說明和示範,這些釋出會的視訊會在第一時間被釋出到蘋果 官網和App Store的Podcasts上,當然這些視訊都是英文的。另外,每年的Apple WWDC即蘋果全球開發者大會上,也會有大量以新系統、新特性為主題的技術講座,這些講座的視訊和PPT資料也會放到開發者門戶上供大家下載下傳學習。

快速反應

快速反應是我們應對系統更新的處理原則,從以往的系統更新情況來看,每次系統更新都會有大量的線上應用出現問題,有些是crash,有些是功能問 題。作為一款線上應用的開發者和營運者,每次面對系統更新,我們要做的最重要的事是在系統釋出的第一時間提供經過新版本适配的應用更新,讓使用者第一時間獲 得适合新系統的穩定版本,有效地穩定應用在App Store的評分。為了第一時間實作提供穩定版本的目的,我們在提供版本更新時需要把應用的穩定性放在第一位。

需要注意的是,每次系統更新都會給開發者提供大量的新功能、新特性,作為一個開發者,内心都會非常興奮,急于把各種新特性應用到産品中,但這些新特 性的使用會遇到兩個問題:一個是新特性的向下相容問題;另一個是應用新特性過程中的時間問題。對此,我的建議是:不要急于應用這些新特性,等提供了一個穩 定的更新版本後,再考慮新特性的使用也不遲。

覆寫測試

衆所周知,測試是發現問題的最佳手段。覆寫測試是我們應對系統更新的最直接手段,對于系統更新的測試,有以下三個方面需要格外注意。

  • 覆寫全部的功能

覆寫全部功能是所有測試的要點,每款應用在上線前都應該經過一個覆寫全部功能的詳盡測試,有條件的情況下要寫下測試用例。這樣,在系統更新過程中,可以利用之前寫下的測試用例針對新系統進行一輪詳細測試,可以有效發現新系統帶來的問題。

  •  覆寫全部的裝置和版本

測試的另一個要點在于對測試裝置和測試系統版本的覆寫,為了做到向下相容,必須在應用上線前在應用需要支援的系統版本和不同裝置上進行測試。

  • 有目的的尋找Bug

在系統更新的過程中,還可以根據蘋果公司釋出的新系統Release Note中的内容,比照自己的應用進行針對性的檢查。另外,在各大論壇上也會有大量的其他開發者釋出系統更新中遇到的問題和解決方案,都可以用來進行針對性的檢查測試。

重要新特性

以上内容是我們針對每次系統更新的一些通用原則和方法手段,接下來針對本次iOS5更新,詳細說明更新中遇到的問題和解決方法。iOS 5帶來了大量的新特性,其中iCloud Storage和Automatic Reference Counting是需要我們重點關注的特性。

iCloud Storage

iCloud是蘋果推出的雲存儲服務。簡單來說,iCloud提供了将iOS應用的資料存儲在雲端,并在不同裝置間同步的能力,對于已有的應用、系 統更新後,應用需要遵循最新的iOS Data Storage Guidelines,蘋果在裡面對應用資料的本地存儲做了一些限制和要求,主要包括以下四個方面。

  • 隻有使用者生成的資料或無法被應用再次生成的資料才可以存放在Document目錄下。在之前的系統中,蘋果對存儲在本地的資料位置并沒有強制要 求,但引入iCloud後,開啟了iCloud的裝置會對存放在Document目錄 (<Application_Home>/Documents)下的檔案做自動的雲端存儲備份,考慮到網絡流量和效率等因素,隻有必要的資料 才可以存放在Document目錄下。
  • 本地緩存資料需要存放在Cache目錄(<Application_Home>/Library/Caches)下。在這裡,緩存資料的定義是指可被重新下載下傳或重新生成的資料,包括新聞雜志類應用的下載下傳資料。
  • 臨時存在的資料,需要放在tmp目錄(<Application_Home>/tmp)下,并在使用結束後删除。
  • 系統會在硬碟資源緊缺的情況下,對存放在Cache目錄下的緩存資料進行删除。在iOS 5.0.1中,系統也提供了一個避免某些檔案被系統删除的功能,即在需要保留的檔案上加上“do not back up”屬性,加上該屬性後,檔案不會被系統自動清除。需要注意的是,這些檔案需要應用自己維護檔案的生命周期,確定該檔案在不需要時能夠被删除。

Automatic Reference Counting

對廣大開發人員來說,ARC是一個令人激動的特性。衆所周知,對很多開發者來說,Objective-C的記憶體管理機制是一門很難掌握的技術,而 iOS應用中大量的crash、不穩定、性能異常等問題都是因為沒有正确管理記憶體造成的。ARC的作用是,将記憶體管理的工作交給編譯器去做,将程式員從複 雜的記憶體管理工作中解放出來,同時也提高了記憶體管理的效率。

無疑,開發者非常希望盡快将這麼好的特性應用到開發中,但對于目前線上應用的更新适配來說,是否采用ARC就需要慎重考慮了。

首先,從向下相容方面考慮,ARC最低支援為4.0系統,并且在4.x系統上無法支援weak和strong兩個關鍵字;其次,對于線上應用,換成 ARC做記憶體管理并不會有實際作用,因為線上應用本身不會存在太大的記憶體管理問題,而使用ARC,需要對代碼進行相當大範圍的改動,改動後又需要一個詳細 全面的測試過程,而這些工作都做完後,應用本身并沒有直覺變化。是以建議開發者對線上應用的更新适配,并不要急于使用ARC,而對新開發的應用可以大膽嘗 試ARC的使用。

除了上面兩個新特性需要特别說明外,還有一些API級别的變化,下面就幾個比較典型的例子詳細說明。

UIKit中UI元件的自定義樣式。在iOS 5中,系統為各種元件提供了大量自定義樣式的方法,而原來廣泛流傳的通過Category 重寫drawRect的方法已不再被使用,是以需要開發者根據目前的系統版本采用不同的處理方式。

UIViewController中的parentViewController屬性值發生變化。 UIViewController中的parentViewController屬性是一個較常用的屬性,尤其是在處理 ModalViewController展現和隐藏時。在iOS 5中,該屬性的值發生了變化,無法再處理ModalViewController的隐藏,需要使用UIViewController的 presentingViewController替換。同樣,presentingViewController也是隻有iOS 5才支援的。

iOS 5中鍵盤高度的處理。在iOS 5之前的系統中,鍵盤的高度是固定的,而在iOS 5中,中文輸入法的鍵盤高度會發生變化,有一些notification事件可以幫助大家處理相關的鍵盤操 作:UIKeyboardDidShowNotification、UIKeyboardWillHideNotification、 UIKeyboardWillChangeFrameNotification等,這幾個notification會在鍵盤隐藏顯示時觸發,并通過其中的 userInfo屬性提供鍵盤高度等相關資訊。

擷取UIDI的變化。UIDI在iOS 5中被标記為deprecated(即不推薦使用,今後也可能不再提供裝置的UDID), 對于這個變化,官方文檔中也提供了替代方法,即在應用中使用CFUUIDCreate方法建立自己的UDID,并保持在NSUserDefault中。

除以上API級别的變化外,還可通過檢視iOS 5 Release Note中的内容,針對性的查缺補漏。

iOS更新經驗分享