移動研發最佳實踐-苗順平

一個移動應用從開發到上線，咱們應該考慮哪些問題？問題出現的時侯，如何完備的提出相關方案？並如何在這些技術方案中做出選擇？應用穩定性的檢查可使用哪些工具？從哪些地方能夠提升應用的性能？圖片、音視頻資源、網絡、優化算法？兼容性問題和安全性問題又該從何入手呢？帶着這些疑問，七牛雲存儲邀請到思必馳高級技術總監苗順平爲你們進行一個總結和分析，下面是完整的現場記錄：
我想先看一下參與移動開發的人有哪些？能夠佔到一半，另外一半是服務端研發。跟你們討論一下，對於一個移動應用來講咱們關注的有哪些方面，從一個想法出來，到最後咱們上線，或者說咱們在整個的過程當中會考慮哪些問題，咱們這裏面簡單的列了一下，也是拋磚引玉，也是本身的一些經驗積累；另一方面是能學習一些新的想法，好比說FIR.im咱們也在用，咱們也本身搭了一套聊天系統，七牛的服務、CDN咱們也在用，可以認識這麼多小夥伴很高興。

第一個問題是最近很大的事件，H5的規劃已經確認下來了，可是在業內並無引發多麼大的轟動；第二個是咱們的穩定性，第三個是關於性能。第四個是兼容性；還有一個是耗電量；最後兩個是安全性和可靠性。我列的不見得全，緯度也不見得是一個緯度，很隨意的列舉一下。其實每個都是有一些坑的，也是給你們作一個提醒。先說一下H5，最先接觸到這個事情的是在用開心的時候，關於Facebook、開心、人人網都面臨一個問題，消息流特別多。

圖上右邊是咱們最先用，可是咱們調研了以後否認了這個建議，我否認這個建議的時候承受了不少壓力，這個地方並非說徹底的擁護者，或者損毀者，其實這個應該看一看爲何。

關於Native App和Web App有一些區別，爲何要否認H5整個性能呢？咱們採用的是原始的方案。這一塊我相信如今有太多的例子給了咱們一些指導，好比說微信，就是用的這個方案。咱們看的朋友圈等等都是這樣，只是和你們分享的。若是說有志於作一款性能跟用戶體驗，跟兼容性各方面都折中的一個方案的時候，你們不妨去思考一下咱們的方案是什麼？咱們的技術人員、產品經理都會面臨時間的壓力、資源的壓力，一開始搞一個網頁上去了，過段時間再去返工效果是很差的。

說一下穩定性，最直觀的指標是Crash率，我不太清楚在座的研發人員是否瞭解本身的移動服務的Crash率是多少。這個數字說出來很驚人，兩年前咱們安卓加iphone是1.6%。也就是說一百次啓動裏面就有1.6次Crash，這個是很是痛苦的一個體驗，如今的確有一些大牛們在這方面下了功夫，我給你們同步一個數據，是跟支付寶的基礎負責人溝通時，瞭解到去年十一月份他們的ios加安卓平均Crash率達到了萬分之二，一萬次纔有兩次，兩次包含了全部的狀況。

如今，大多數的應用有過幾個版本的迭代和正常維護流程，基本是千分之幾或者是十幾的概念，到了十幾的概念是沒有什麼進展了。咱們對穩定性這方面是否是有一些直觀的認識？好比說一萬次裏面，不算用戶的，若是說發現了一兩次，計算的方法跟用戶數沒有關係。好比說咱們應用了一次Crash，心情好可能還會再打開，若是心情很差就直接關掉了，對產品是一個直接的影響。

我先說一下安卓的穩定性建議，裏面有不少工具，本身有代碼檢查工具，好比說Lint工具，種類有十幾個類別，每個類別裏面還有不少。我不知道咱們的開發人員有沒有對它有一個直觀的警告和認識，每一條其實都是有緣由的。關於穩定性有一個兼容的問題，好比說4.0的API在2.3裏面使用了，就會提一個問題，會致使2.3的活動裝上以後沒法使用。

Findbugs能檢查不少問題，越界或者其餘的一些問題，這個地方每每是可以作一些最初的判斷。由於不少狀況你們都經歷過，咱們的應用發出去以後就像潑出去的水收不回來。可是咱們又沒有遇到的話，很是的不幸。早期還好，幾百個用戶沒有問題，Crash沒有關係，可是若是說微信如今出這麼一個問題就成爲業界笑話了。

關於流程的個有兩個工具，第一個是Reviewboard，好比說我這個團隊歷來沒有出過事故，我能夠繼續作，可是我所知道的團隊都出過事故。還有一個是架構清晰的邏輯分層，這個事情說出來很容易，可是作出來比較難。

我們接着談性能，用戶等待時間七秒和三秒的演變，iPhone第一代的時候，喬布斯引領的蘋果團隊作過一個體驗，一個頁面或者一個UI用戶最多能夠等多長時間是有耐心呢？答案是七秒，這是2005年仍是2006年的時候，可是如今3秒不出來，我就認爲你是出問題了。性能對一個移動應用來講是很是關鍵的，談到影響性能的因素有哪些，這個地方我列了一下：

好比我買了一個很便宜的手機，已經有四五年了，我很珍愛它，還在用，這個時候會出現穩定性的問題，爲何我把這個狀況列在第一位？由於它是直接相關，性能這個地方的比例是最少的，統計來說一兩年就會換一個手機，性能差致使一些遊戲跑不起來是沒有辦法的，網絡IO佔了很大一部分，咱們前面的嘉賓也介紹了不少雲的服務，有不少雲的創業項目和產品，其實這個是對優化咱們產品性能有幫助的，IO沒有問題。若是我傳一兆和1K，確定是1K更快一些。

第四個是說咱們第三方登錄，這個地方咱們曾經出現過問題。早期的時候咱們作聯合登錄，咱們作定位，最先的是關於定位方面，我僅僅須要十秒。如今慢慢的也就行了，這方面也是緣由之一。

關於性能的建議，這一塊說一下圖片緩存和網絡、數據量以及應用代碼和服務器的性能。圖片緩存每次分享都會說這個問題，這個跟應用是息息相關的。關於圖片緩存是這樣的，以前有朋友說個人應用優化不少，每次很慢。可是我發現他們的圖片是這樣存的，把圖片的URL放到數據庫裏面，把本地的路徑放在裏面，每次顯示圖片的時候用URL查詢一下，每次滑動的時候老是卡，不少人都知道IO性能是很是慢的，這多是一個笑話，如今這種作法不用查數據庫，就能夠判斷文件在不在的狀況。

還有一個狀況是作了一個現成的框架，能夠去設置，還能夠對你容量大小的緩存設置一百兆或者多大均可以，咱們以前作應用開發的人，都作過相似於這樣的事情，最後都紛紛放棄了本身原來的那套，或者作一些適應性的調整，其實這是主要問題的一些集中，就像作過推送、聊天的人都知道里面的坑實在太多了。

再一個是優化咱們的網絡，好比說部署和CDN等等，這裏咱們有一個親身體驗。好比說作移動互聯網開發或者移動平臺的人，對服務端架構不是很清楚，能力怎麼樣不少時候也不會提出來。不少時候會有一個很是明顯的提高，好比說文本有20%、30%的壓縮率，只有1K的20%到30%，這是最簡單的優化，可是作的人也不見得多，可是這個是必需要作的。

第二個是關於圖片，我以前是在糯米，跟普通的電商沒有區別，有太多的圖片須要顯示，2G、3G的網絡下顯示很是困難，圖片的方式有不少壓縮，第一是使用模塊，好比說在手機上快速瀏覽的時候，最大容忍最低的圖片質量是多少？最開始的時候，實際上是90%，默認的。100 *100的圖片須要十幾K或者20K，如今2K網絡下平均速度是兩到3K,因此這個地方對圖片自己的壓縮，好比把質量調整到40%，快速滑動是看不出來的。這個對網絡IO、對服務的帶寬、對手機流量都是一個很大的節省。第二種圖片壓縮是圖片的金字塔，其實最先作的就是地圖，最大比例是圖片最大，在手機上也是同樣的，咱們徹底能夠把這個東西作成離線化，處理全部的圖片，適應手機的分辨率，對於手機來講，不須要下載多餘的，這個也能提升性能。還有一個是ios、安卓在項目輸出的時候，咱們團隊都有UI，或者是幹UI的那麼一我的會輸出。咱們全部的圖片是否是都壓縮了呢？好比說不少用戶下載失敗了等等的問題，因此說Pngout是主要的工具。

而音視頻這一塊，像YY、優酷、愛奇藝其實也同樣，視頻上去有離線的數據處理中心，都會作一些視頻的處理，咱們在看視頻的時候，用手機上是流暢，家裏用無線是1080P。每次切換的時候都會作一些壓縮，分辨率也會有壓縮。好比說我上傳的時候，本身拍一個視頻，我拍一分鐘是幾百兆，可是像YY這種，你們有用過YY的視頻客戶端或者QQ視頻，其實流量很省，是對整個作了研究的。

優化本機的性能是應用代碼，多線程你們不少在用，可是不知道清不清楚，好比說我在手機上跑一千多個多線程，這些線程是否是輪轉到它呢？或者時間夠不夠？咱們的應用界面有多少是真正須要去作？好比說UI界面來說，最底下的設置了一個背景，在它上面咱們給它疊加了不少層，每一層都是這個背景，UI測試的時候，或者說咱們提到的單元測試、人工測試的時候以爲是對的，可是對於CPU來講這麼多層，最底下的根本就沒有顯示，或者沒有必要顯示，剛纔我提到了另一個例子，圖片的緩存是否是在？我只要作一個轉換就能夠了。

還有一個是合理的使用硬件加速，這個級別是不同的，這裏會有一個新的問題，即這個平臺上的硬件支持，在另一個平臺不支持，用這個硬件最好的仍是廠商，由於它只負責本身的硬件，可是對於我們作開放APP的話，這個地方要慎重。我給你們舉一個例子，我不知道你們是從哪一個版本的百度地圖開始使用的，2.0和如今的繪圖是不同的，地圖繪製起來很是麻煩，一根線一個點一個面的畫起來，很是的痛苦，這個地方我問過他們的技術人員或者產品負責人，我說爲何用這個呢？由於咱們當時是在糯米的技術上作二次開發，他說他們作過一些分析，在通用的場景下適當的選擇本身的用戶。

優化算法這一塊有些能夠列出來，咱們如今作的一些名字規劃，這裏提一點咱們的業務，好比說我打電話給伍總、星星，其實都是名字規劃的一種處理方法，並非他都知道，而是說咱們預先作了處理，由於處理一個名字須要九毫秒，很是痛苦。咱們優化了以後，處理十個名字也不會超過一個毫秒，這是算法的優化，可是對於處理的結果是不同的。

兼容性這一塊OS版本，是SDK版，在作移動開發的時候，必定要注意咱們適配的版本是什麼，支持的平臺是哪些？這是很是現實的問題，上圖列了一下安卓系統的市場佔有率，到2014年9月份，已經有不多的用戶還在使用2.0了，這是OS一個較大的演變過程，系統更新的速度是很是快的。

談到開發工具了，也說一下相關的東西，說到設計這一塊，它是咱們全部UI的源頭，設計人員有沒有同步顯示在手機上？1080P的手機出來的時候，咱們說分辨率好高，作了一系列的圖咱們看着很漂亮，在PC、投影和屏幕上，可是在手機上無法看，由於咱們的字體過小，看不到，因此騰訊這方面也是巨頭提供的工具，作了PS Play，我但願你們推薦一下。若是咱們UI沒有作這個事情的話，咱們能夠提升一下，是在同網絡下的wifi傳到手機上。

適配這個問題也是很重要的，之前在聯想採購適配的費用是七十萬人民幣，對於初創的企業很是難，有一些雲測試平臺，你們能夠試一下，包括版本的適配、API的適配，分辨率也能夠。網絡兼容性這邊設置網速，能夠在電腦上模擬2G、3G甚至更高的網絡測試，這樣能夠體驗你應用的速度，這個速度仍是很是靠譜的。

耗電量是服務端不須要關注的問題，機房電源很穩定，整個的保護措施也很好，斷電是千載難逢的，主要的原件是CPU、屏幕，好比安卓裏面有一個應用，點一下就能夠知道。我最近有一個軟件沒有用它，它無形的跑到第一了，我無情的解決了它。若是說咱們的應用很不幸跑到第一名，除非我很是喜歡這個遊戲，我每天玩。若是沒有用的話，卸載率很高，我估計產品的負責人會很頭疼。關於耗電量來講，第一個是本身的服務一直在後臺運行；第二個是推送方案有問題，好比說剛纔說的聊天服務，他們在這方面會有一些考慮，包括從一個山頭過另一個山頭，好比說我在地鐵上試一下，網絡切換咱們會遇到，可是處理的方法是不同的；還有一個是大數據量的網絡傳輸，若是我們的手機去保持一個連接，大概是十幾毫安，若是說要開始傳東西，穩定在三百到四百毫安；用手機下載一個東西是三百到四百毫安；屏幕常亮在100到150之間，因此數據壓縮提高整個性能的時候，電量也是一種方法。

這裏就是一些經驗和相關的東西，後臺的服務部用時要關掉，避免頻繁的喚醒；Sensor用完要關掉，Push方案這一塊咱們的團隊比較小，業務比較少的時候，儘量選擇第三方的東西，任何一個團隊除非是專門作推送的，很難作一套很好的推送方案，在到達率和網絡佔用各方面都考慮的時候，還有一個是網絡IO。

安全性這一塊剛纔也有好多人提到了，以前咱們有一個討論，全部的應用均可以破解，只是說咱們願意不肯意花這麼大精力，對於電商來講，一個永恆的話題是每次發起一個活動，用戶作什麼東西能夠拿代金券或者現實的獎勵，不少獎勵都被黃牛拿走了，他從中牟利，這是一個行業，專門作這個事情，京東、天貓、美團都有專門的團隊，這個是咱們安全性沒有考慮的事情。工具的測試手機和PC這裏，經過PC代理看一下本身的包，有的時候你看一下是觸目驚心的，不少用戶密碼是經過明文傳的，設置代理在同網站下走整個PC的網絡。

安全性我以爲有幾個東西你們能夠考慮，第一個是HTTPS自己，不少協議都是走APP，都有一些關聯的狀況。在合理的狀況下用HTTPS，它本身的性能不見得好，因此說要合理的使用；加密這一塊有不少，還有一個是涉及到第三方工具以及反逆向工程，這一塊是作最好的棋盤，作最壞的打算；可拓展性這一塊可能一個產品經理提出需求的時候沒有想太多，過幾天的時候說我要改一下，若是說你寫死的，必定是不行的，若是作了很好的分層，只是一個組合的問題，很容易的就解決了，一個分層是很是重要的，並且這個力度是對後續的貢獻最大，這和服務端是同樣的，UI和業務邏輯的分離尤爲重要。

以上內容來自思必馳技術高級總監 苗順平 在11月29日「開發者實踐日技術沙龍」上題爲《移動研發最佳實踐》的分享。

順便通知一下你們：開發者最佳實踐日·第7期－互聯網產品從設計到上線 上海站將於12月13日在上海創業者公共實訓基地5號樓1層，EFG一樓舉行，歡迎XX社區的各路猿們來相聚！

報名地址：http://qiniu-7.eventdove.com/

「開發者最佳實踐日」是由七牛雲存儲發起並聯合各方小夥伴爲開發者舉辦的系列技術沙龍，關注開發者在實際應用中可能遇到的技術問題。致力於爲敢於創新的開發者們提供行業內最前沿最熱門的技術乾貨，以技術驅動應用創新，讓更多的開發者享受技術帶來的生活樂趣。