移動研發最佳實踐 苗順平

2021-06-28 00:15:31 字數 3297 閱讀 7517

第乙個問題是最近很大的事件,h5的規劃已經確認下來了,但是在業內並沒有引起多麼大的轟動;第二個是我們的穩定性,第三個是關於效能。第四個是相容性;還有乙個是耗電量;最後兩個是安全性和可靠性。我列的不見得全,緯度也不見得是乙個緯度,很隨意的列舉一下。其實每乙個都是有一些坑的,也是給大家做乙個提醒。先說一下h5,最早接觸到這個事情的是在用開心的時候,關於facebook、開心、人人網都面臨乙個問題,訊息流特別多。

圖上右邊是我們最早用,但是我們調研了之後否定了這個建議,我否定這個建議的時候承受了很多壓力,這個地方並不是說完全的擁護者,或者損毀者,其實這個應該看一看為什麼。

說一下穩定性,最直觀的指標是crash率,我不太清楚在座的研發人員是否了解自己的移動服務的crash率是多少。這個數字說出來很驚人,兩年前我們安卓加iphone是1.6%。也就是說一百次啟動裡面就有1.6次crash,這個是非常痛苦的乙個體驗,現在的確有一些大牛們在這方面下了功夫,我給大家同步乙個資料,是跟支付寶的基礎負責人溝通時,了解到去年十一月份他們的ios加安卓平均crash率達到了萬分之二,一萬次才有兩次,兩次包含了所有的情況。

現在,大多數的應用有過幾個版本的迭代和正常維護流程,基本是千分之幾或者是十幾的概念,到了十幾的概念是沒有什麼進展了。我們對穩定性這方面是不是有一些直觀的認識?比如說一萬次裡面,不算使用者的,如果說發現了一兩次,計算的方法跟使用者數沒有關係。比如說我們應用了一次crash,心情好可能還會再開啟,如果心情不好就直接關掉了,對產品是乙個直接的影響。

我先說一下安卓的穩定性建議,裡面有很多任務具,自己有**檢查工具,比如說lint工具,種類有十幾個類別,每乙個類別裡面還有很多。我不知道我們的開發人員有沒有對它有乙個直觀的警告和認識,每一條其實都是有原因的。關於穩定性有乙個相容的問題,比如說4.0的api在2.3裡面使用了,就會提乙個問題,會導致2.3的活動裝上之後無法使用。

關於流程的個有兩個工具,第乙個是reviewboard,比如說我這個團隊從來沒有出過事故,我可以繼續做,但是我所知道的團隊都出過事故。還有乙個是架構清晰的邏輯分層,這個事情說出來很容易,但是做出來比較難。

咱們接著談效能,使用者等待時間七秒和三秒的演變,iphone第一代的時候,賈伯斯引領的蘋果團隊做過乙個體驗,乙個頁面或者乙個ui使用者最多可以等多長時間是有耐心呢?答案是七秒,這是2023年還是2023年的時候,但是現在3秒不出來,我就認為你是出問題了。效能對乙個移動應用來說是非常關鍵的,談到影響效能的因素有哪些,這個地方我列了一下:

比如我買了乙個很便宜的手機,已經有四五年了,我很珍愛它,還在用,這個時候會出現穩定性的問題,為什麼我把這個情況列在第一位?因為它是直接相關,效能這個地方的比例是最少的,統計來講一兩年就會換乙個手機,效能差導致一些遊戲跑不起來是沒有辦法的,網路io佔了很大一部分,我們前面的嘉賓也介紹了很多雲的服務,有很多雲的創業專案和產品,其實這個是對優化我們產品效能有幫助的,io沒有問題。如果我傳一兆和1k,肯定是1k更快一些。

第四個是說我們第三方登陸,這個地方我們曾經出現過問題。早期的時候我們做聯合登陸,我們做定位,最早的是關於定位方面,我僅僅需要十秒。現在慢慢的也就好了,這方面也是原因之一。

關於效能的建議,這一塊說一下快取和網路、資料量以及應用**和伺服器的效能。快取每次分享都會說這個問題,這個跟應用是息息相關的。關於快取是這樣的,之前有朋友說我的應用優化很多,每次很慢。但是我發現他們的是這樣存的,把的url放到資料庫裡面,把本地的路徑放在裡面,每次顯示的時候用url查詢一下,每次滑動的時候總是卡,很多人都知道io效能是非常慢的,這可能是乙個笑話,現在這種做法不用查資料庫,就可以判斷檔案在不在的情況。

還有乙個情況是做了乙個現成的框架,可以去設定,還可以對你容量大小的快取設定一百兆或者多大都可以,我們之前做應用開發的人,都做過類似於這樣的事情,最後都紛紛放棄了自己原來的那套,或者做一些適應性的調整,其實這是主要問題的一些集中,就像做過推送、聊天的人都知道裡面的坑實在太多了。

再乙個是優化我們的網路,比如說部署和cdn等等,這裡我們有乙個親身體驗。比如說做移動網際網路開發或者移動平台的人,對服務端架構不是很清楚,能力怎麼樣很多時候也不會提出來。很多時候會有乙個非常明顯的提公升,比如說文字有20%、30%的壓縮率,只有1k的20%到30%,這是最簡單的優化,但是做的人也不見得多,但是這個是必須要做的。

優化本機的效能是應用**,多執行緒大家很多在用,但是不知道清不清楚,比如說我在手機上跑一千多個多執行緒,這些執行緒是不是輪轉到它呢?或者時間夠不夠?我們的應用介面有多少是真正需要去做?比如說ui介面來講,最底下的設定了乙個背景,在它上面我們給它疊加了很多層,每一層都是這個背景,ui測試的時候,或者說我們提到的單元測試、人工測試的時候覺得是對的,但是對於cpu來說這麼多層,最底下的根本就沒有顯示,或者沒有必要顯示,剛才我提到了另外乙個例子,的快取是不是在?我只要做乙個轉換就可以了。

優化演算法這一塊有些可以列出來,我們現在做的一些名字規劃,這裡提一點我們的業務,比如說我打**給伍總、星星,其實都是名字規劃的一種處理方法,並不是他都知道,而是說我們預先做了處理,因為處理乙個名字需要九毫秒,非常痛苦。我們優化了之後,處理十個名字也不會超過乙個毫秒,這是演算法的優化,但是對於處理的結果是不一樣的。

相容性這一塊os版本,是sdk版,在做移動開發的時候,一定要注意我們適配的版本是什麼,支援的平台是哪些?這是非常現實的問題,上圖列了一下安卓系統的市場占有率,到2023年9月份,已經有很少的使用者還在使用2.0了,這是os乙個較大的演變過程,系統更新的速度是非常快的。

適配這個問題也是很重要的,以前在聯想採購適配的費用是七十萬人民幣,對於初創的企業非常難,有一些雲測試平台,大家可以試一下,包括版本的適配、api的適配,解析度也可以。網路相容性這邊設定網速,可以在電腦上模擬2g、3g甚至更高的網路測試,這樣可以體驗你應用的速度,這個速度還是非常靠譜的。

這裡就是一些經驗和相關的東西,後台的服務部用時要關掉,避免頻繁的喚醒;sensor用完要關掉,push方案這一塊我們的團隊比較小,業務比較少的時候,盡可能選擇第三方的東西,任何乙個團隊除非是專門做推送的,很難做一套很好的推送方案,在到達率和網路占用各方面都考慮的時候,還有乙個是網路io。

安全性這一塊剛才也有好多人提到了,之前我們有乙個討論,所有的應用都可以破解,只是說我們願意不願意花這麼大精力,對於電商來說,乙個永恆的話題是每次發起乙個活動,使用者做什麼東西可以拿代金券或者現實的獎勵,很多獎勵都被黃牛拿走了,他從中牟利,這是乙個行業,專門做這個事情,京東、天貓、美團都有專門的團隊,這個是我們安全性沒有考慮的事情。工具的測試手機和pc這裡,通過pc**看一下自己的包,有的時候你看一下是觸目驚心的,很多使用者密碼是通過明文傳的,設定**在同**下走整個pc的網路。

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

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

移動端字型設定最佳實踐

body ios 4.0 ios 9以下系統已經非常少 使用英文本型 helvetica neue,之前的ios版本降級使用 helvetica。中文字型設定為華文黑體stheiti。微軟雅黑是為了相容win系統,畢竟視網膜解析度的win系統用simsun是非常醜陋的,可以用4k屏 windowns...

移動 Web 最佳實踐 MWBP 速記卡

這是一套關於移動 web 設計最佳實踐的快速參考卡片,它總結自 mobile web best practices 1.0 文件。卡片內容包含了 60 條指導 方針及其詳細解釋,是乙份很有用的隨身學習資料。該套卡片同時還有 pdf 版本 除了該中文版外,這套卡片同時還提供以下語言版本 英語,法語,德...

QCon北京2015 移動開發最佳實踐專題前瞻

從社交到遊戲,從電商到o2o,移動網際網路已經深入滲透到各行各業,而外賣和打車市場,更是正在經歷著一些深刻的變化。鉅額的融資和龐大的使用者群當然是吸引眼球的,但是小團隊背後的故事或許也能讓你眼前一亮。不同的行業有其各自的特點,相應的,對於工程團隊的要求也各不相同,有些專案要處理海量請求,有些專案則面...