人妻无码二区自慰系列,国产精品露脸国语对白AV,女人被狂躁高潮啊的视频在线看

當(dāng)前位置 > 首頁(yè) > 職場(chǎng)資訊 > 2015年移動(dòng)技術(shù)白皮書(shū)（總結(jié)）

2015年移動(dòng)技術(shù)白皮書(shū)（總結(jié)） 瀏覽次數(shù)：1120　發(fā)布日期：2016-1-5 15:08:00　來(lái)源：CSDN資訊

2015年，是移動(dòng)領(lǐng)域新技術(shù)取得極大豐收的一年。

(一)Android篇

這里我不談Google IO大會(huì)的各種新概念新思想，不談Android 5.0和高逼格的Material Design，那些都是浮云，熱鬧過(guò)后，能沉淀下來(lái)用于App應(yīng)用的干貨并不多。我只談這一年來(lái)，我認(rèn)為Android技術(shù)界最激動(dòng)人心的三件事。最后再聊一聊八卦。

首先是插件化技術(shù)的百家爭(zhēng)鳴。在此之前，關(guān)于Android插件化的介紹鳳毛麟角，Android程序員即使想去研究也無(wú)從下手。2015年，幾家大的互聯(lián)網(wǎng)公司陸續(xù)開(kāi)放了自己的插件化編程的項(xiàng)目源碼，值得注意的是，各家的實(shí)現(xiàn)思想還都不同，各有特色。

1)DL插件化體系

第一個(gè)要介紹的是DL插件化框架，GitHub地址為：https://github.com/singwhatiwanna/dynamic-load-apk。

這個(gè)框架早在2014年3月就在Github上了，直到2015年才基本穩(wěn)定下來(lái)，開(kāi)始有越來(lái)越多的Android開(kāi)發(fā)人員關(guān)注這個(gè)項(xiàng)目。它是由“民間”三位Android開(kāi)發(fā)者共同研發(fā)出來(lái)的，分別是任玉剛、田嘯、宋思宇。

這個(gè)項(xiàng)目的特色是，通過(guò)宿主程序中一個(gè)叫做proxy的Activity，去調(diào)用插件中的Activity。

以下圖片摘取自任玉剛的博客，形象的表達(dá)了DL的核心思想：

DL框架面臨兩個(gè)棘手的問(wèn)題：

首先是通過(guò)proxy調(diào)用插件中的Activity，那么插件中的Activity就是一個(gè)普通的類(lèi)了，不再具有原有的生命周期，為此需要重寫(xiě)插件中的Activity的所有生命周期方法，proxy手動(dòng)去管理插件中每個(gè)Activity的onCreate、onResume這樣的方法。

其次是插件中的資源，不能再通過(guò)R來(lái)訪(fǎng)問(wèn)，為此要重寫(xiě)Context中的getAssets方法和getResources方法。

DL框架最有名的發(fā)明創(chuàng)造。莫過(guò)于that語(yǔ)法了。在插件中，我們將盡量使用that關(guān)鍵字來(lái)替代this。

DL目前還有很多不完善的地方。但據(jù)我所知，已經(jīng)有大型移動(dòng)互聯(lián)網(wǎng)公司的Android插件化體系就是基于DL的。

2)Fragment系

早在2012年7月，就有大眾點(diǎn)評(píng)的屠毅敏在Github上發(fā)布了一個(gè)名為AndroidDynamicLoader的開(kāi)源項(xiàng)目，這應(yīng)該是第一個(gè)Android插件化的項(xiàng)目，它的亮點(diǎn)在于大規(guī)模的使用Fragment來(lái)代替Activity。所有的Fragment都運(yùn)行在一個(gè)Activity上，從而在Manifest文件中只事先聲明這個(gè)Activity就夠了，這樣就避免了每次新增一個(gè)Activity都要修改Manifest文件的尷尬。

2015年也有類(lèi)似的一款基于Fragment的插件化框架問(wèn)世，詳情請(qǐng)參見(jiàn)以下地址：

博文介紹：http://blog.csdn.net/sbsujjbcy/article/details/47060211

Github下載：https://github.com/lizhangqu/CorePage

3)阿里系插件化體系

阿里其實(shí)幾年前就在搞插件化編程了，代號(hào)為Atlas，只是2015年才把這套技術(shù)公布于眾。先是命名為OpenAtlas，然后改名為ACDD，最后不知道為什么又把GitHub的地址改為ACDDExtension——其實(shí)這3個(gè)項(xiàng)目是一回事，相關(guān)地址請(qǐng)參見(jiàn)：

OpenAtlas：http://blog.csdn.net/column/details/openatlas.html

ACDD：https://github.com/bunnyblue/ACDD

ACDDExtension：https://github.com/bunnyblue/ACDDExtension

Atlas的亮點(diǎn)在于對(duì)R進(jìn)行分區(qū)，從而確保資源相互獨(dú)立互不沖突。為此，把功夫做足在aapt這個(gè)命令層面，需要額外修改aapt中的邏輯，以確保資源分區(qū)沒(méi)有問(wèn)題。

4)攜程

攜程的插件化思想和阿里的Atlas有很多相同的地方，由此可見(jiàn)這是一套通用的技術(shù)解決方案，所謂的“正統(tǒng)思想”，主要包括以下幾點(diǎn)：

1.aapt上的改造

2.gradle上的改造

3.資源ID分區(qū)

4.修改Context的getAssets方法和getResources方法，解決R文件的讀取問(wèn)題。

5)對(duì)插件本身沒(méi)有限制的新思路

看慣了前面的各種插件化技術(shù)，細(xì)心的朋友是否發(fā)現(xiàn)，我們對(duì)插件做的太重了，比如說(shuō)要遵守各種人為的規(guī)定，重寫(xiě)aapt指令，資源分區(qū)，that語(yǔ)法等等。

這個(gè)世界總是太浮躁，讓我們靜下心來(lái)做減法，閉上眼睛思考我們究竟想要什么，而不是各種跟風(fēng)。是否可以搭建這樣的一個(gè)Android宿主程序，它可以把任何未經(jīng)安裝、默默躺在SD卡上的apk程序都作為插件加載進(jìn)來(lái)。這樣就降低了插件編寫(xiě)的難度。

本篇要介紹的pluginmgr就是這樣的思想，作者在試圖搭建這樣的一個(gè)萬(wàn)能的Android宿主程序。

pluginmgrd的核心思想有2點(diǎn)：

一是把插件中所有的Activity都動(dòng)態(tài)生成一個(gè)相對(duì)應(yīng)的PluginActivity。啟動(dòng)插件的某個(gè)Activity時(shí)，先找PluginActivity，再找對(duì)應(yīng)的Activity——所謂的依賴(lài)反轉(zhuǎn)的思想。這就不需要把插件中的Activity還要在宿主中的Manifest文件中注冊(cè)。

二是在啟動(dòng)插件的Activity時(shí)，不是通過(guò)自己寫(xiě)程序手動(dòng)去new一個(gè)Activity，而是由Android系統(tǒng)來(lái)new這個(gè)Activity。我們將宿主的ClassLoader替換為FrameworkClassLoader。

注意，所有的插件apk都是不需要安裝的，只需要靜靜的躺在SD卡上即可。由萬(wàn)能的pluginmgrd在運(yùn)行時(shí)將這些apk加載進(jìn)來(lái)。

6)更優(yōu)雅的修bug：AndFix

Android插件化是為了解決什么問(wèn)題?

65536方法數(shù)爆棚。

減少apk體積。

不通過(guò)發(fā)版就能發(fā)布新功能

不通過(guò)發(fā)版就能修復(fù)線(xiàn)上bug和崩潰。

但我們經(jīng)過(guò)實(shí)踐發(fā)現(xiàn)，插件化更多的運(yùn)用于修復(fù)線(xiàn)上bug和崩潰。這是一個(gè)很輕量的需求，卻為此花費(fèi)了大量的人力和財(cái)力去運(yùn)行這樣一套龐大的架構(gòu)體系，是相當(dāng)不劃算的。為此，2015年github上出現(xiàn)了AndFix，這款A(yù)ndroid輕量級(jí)線(xiàn)上bug修復(fù)工具。

AndFix的核心思想是，把a(bǔ)pp中的方法B替換為新的方法B ‘,為此，我們把新方法B’所在的代碼進(jìn)行重新打包，并和就的apk包進(jìn)行差分比較，得到一個(gè)差分包，放到服務(wù)器提供舊版apk下載，那么apk在接收到差分包后，就會(huì)執(zhí)行新的方法B’了，如下圖所示：

這類(lèi)似于iOS的JSPatch實(shí)現(xiàn)。只不過(guò)Objective-C是一門(mén)動(dòng)態(tài)語(yǔ)言，天生就支持這樣的特性。而在Android中，則需要修改Native底層了。

在Native底層，有一個(gè)dalvik_dispatcher方法負(fù)責(zé)最終執(zhí)行哪個(gè)方法。就是在這里做一些手腳，把舊方法替換為新方法。

對(duì)于功能不是很多的App而言，AndFix是首選，可以快速修復(fù)線(xiàn)上bug而不用發(fā)新版，而實(shí)現(xiàn)成本也很低。對(duì)于規(guī)模不大的團(tuán)隊(duì)而言，相當(dāng)劃算。

這里不得不說(shuō)到dexposed。dexposed和AndFix都是阿里推出的開(kāi)源框架，用以解決Android熱修復(fù)的兩種實(shí)現(xiàn)，原理兩者類(lèi)似，都是在在Native底層的dalvik_dispatcher方法做文章。但是dexposed有一個(gè)硬傷，就是不支持art，這使得很多粉絲轉(zhuǎn)而去投標(biāo)AndFix陣營(yíng)。dexposed的github地址為：https://github.com/alibaba/dexposed

8)360系插件化

縱覽了前面的所有插件化技術(shù)，你會(huì)發(fā)現(xiàn)，它們都是基于單進(jìn)程的。這就是說(shuō)，插件更新只能等到App重新啟動(dòng)才能生效。

但是我們的用戶(hù)大都是不懂得如何重啟App的。這就導(dǎo)致了插件升級(jí)后的更新率并不高，兩周時(shí)間也就50%的升級(jí)率，然后App就又發(fā)大版本了。

對(duì)于這個(gè)問(wèn)題，360推出了DroidPlugin的插件化技術(shù)，它是基于多進(jìn)程的思想。比如說(shuō)一個(gè)App中有吃喝玩樂(lè)4個(gè)插件，如果“吃”這個(gè)插件有升級(jí)，DroidPlugin就可以把正在運(yùn)行的“吃”的舊版本的這個(gè)進(jìn)程殺掉，然后運(yùn)行新的插件版本。

目前看起來(lái)，對(duì)于電商、O2O、OTA這樣多業(yè)務(wù)線(xiàn)、并偏重于閉環(huán)的App而言，DroidPlugin是一個(gè)終極解決方案。

第二個(gè)激動(dòng)人心的是Facebook開(kāi)源的Fresco，這是一款強(qiáng)大的圖片加載組件，github地址：https://github.com/facebook/fresco。

Android領(lǐng)域最讓程序員苦惱的莫過(guò)于內(nèi)存不足夠?qū)е碌腛OM異常了，這大都是由于加載大量圖片而沒(méi)有及時(shí)回收導(dǎo)致的。為了解決這個(gè)問(wèn)題，Android有很多專(zhuān)門(mén)用于加載圖片的組件，比較著名的有ImageLoader、Picaso等，它們只能在Android層面通過(guò)及時(shí)回收?qǐng)D片資源來(lái)緩解Android的內(nèi)存使用，來(lái)減緩OOM的發(fā)生頻率。

接下來(lái)我們說(shuō)Fresco，它引進(jìn)了三級(jí)緩存的概念(Bitmap緩存、內(nèi)存緩存和硬盤(pán)緩存)，它比其他圖片下載組件消耗的內(nèi)存小，就在于這個(gè)全新的緩存設(shè)計(jì)。三級(jí)緩存中，尤以Bitmap緩存最亮眼。在Android 4.x和更低的系統(tǒng)，Bitmap緩存位于ashmem中，而不是位于Java的堆(heap)中。這意味著圖片的創(chuàng)建和回收不會(huì)引發(fā)過(guò)多的GC。

關(guān)于Fresco的更多介紹，請(qǐng)參見(jiàn)Fresco的官方文檔：http://fresco-cn.org/docs/index.html

最后，是針對(duì)于Android的線(xiàn)上崩潰的收集整理和分析修復(fù)。其實(shí)收集整理這件事，要么是使用第三方平臺(tái)的系統(tǒng)，要么是自己做，但是收集到數(shù)據(jù)并去重后，如果分析這些崩潰信息并修復(fù)，是件很棘手的事情。要針對(duì)于機(jī)型、使用場(chǎng)景，具體問(wèn)題具體分析，社區(qū)上(比如CSDN或Stackflow)針對(duì)于每個(gè)崩潰信息的分析和修復(fù)方案，魚(yú)目混雜，或只言片語(yǔ)，或空穴來(lái)風(fēng)，要逐一訂正是件很費(fèi)神的事情。

我曾經(jīng)試圖來(lái)整理這些崩潰的原因和修復(fù)方案，耗費(fèi)半年時(shí)間，也才完成84個(gè)(可以參見(jiàn)《App研發(fā)錄》第6章)。就在我干這件事的同時(shí)，騰訊有一個(gè)團(tuán)隊(duì)Bugly也在做類(lèi)似的事情，他們?cè)?1月搞了這樣的一個(gè)活動(dòng)“騰訊 Bugly Android 異常案例解決方案征集”(活動(dòng)的詳細(xì)地址參加http://www.oschina.net/news/67914/tencent-bugly-projects)，試圖通過(guò)社區(qū)的力量來(lái)建立一個(gè)Android的崩潰倉(cāng)庫(kù)。天地萬(wàn)物皆有時(shí)，崩潰倉(cāng)庫(kù)在2015年只是一個(gè)萌芽，能否做大做全，我們期待2016年。

前面說(shuō)了Android太多普大喜奔的事情，接下來(lái)說(shuō)一說(shuō)Android在2015年遇到的一個(gè)安全問(wèn)題。

我敢打賭說(shuō)，大部分公司的Android項(xiàng)目，會(huì)為了方便，而把簽名密鑰放在了項(xiàng)目中，所有開(kāi)發(fā)人員都可以看到。隨著這幾年開(kāi)發(fā)人員的流動(dòng)，密鑰已不再是密鑰了。

把密鑰從項(xiàng)目中移除，保存在1-2個(gè)人手中，是個(gè)不錯(cuò)的辦法。但是仍不能避免之前的同事手中握有這份密鑰。密鑰一旦被流傳到市場(chǎng)上，就會(huì)有不懷好意的人在原先的App加一些惡意的功能，然后重新簽名。

更換密鑰嗎?這是個(gè)餿主意，這會(huì)導(dǎo)致生成一個(gè)新的App，而不再是原先的那個(gè)App了。

其實(shí)這個(gè)問(wèn)題早就存在，只是現(xiàn)在才擺上臺(tái)面而已。目前還沒(méi)有更好的解決辦法，也只能縮小直到密鑰的人員。

末了插播一條新聞。2015年6月，Google宣布將在年底前停止對(duì)Eclipse Android開(kāi)發(fā)工具的一切支持，從此我們只能使用Android Studio開(kāi)發(fā)Android。對(duì)于一個(gè)使用Eclipse3年的開(kāi)發(fā)者而言，我感到非常不適應(yīng)。相信和我有相同感受的朋友不在少數(shù)。從此，Gradle成為標(biāo)配。

ADT的沒(méi)落完全是咎由自取，自身的不努力，導(dǎo)致Google不再花費(fèi)時(shí)間和精力去支持。這樣也好，集中精力先把一個(gè)IDE做好，目前看起來(lái)，Android Studio比微軟的Visual Studio還差很多很多。

(二)iOS篇

2015年，iOS有太多的事情發(fā)生，每一次事件都促進(jìn)了iOS技術(shù)的一次飛躍。

首先是蘋(píng)果宣布從2015年2月1日開(kāi)始，所有上傳至App Store官方商店的新iOS應(yīng)用都必須支持64位。為此，所有的App在打包時(shí)要兼容32位和64位，雖然某些機(jī)型上速度快了不少，但是App的體積卻大了不少。

2015年應(yīng)該是iOS的“瘦身年”。各大公司在發(fā)現(xiàn)自己的iOS App超過(guò)了50M之后，紛紛開(kāi)始組織iOS團(tuán)隊(duì)對(duì)App進(jìn)行減肥，然后我們就會(huì)發(fā)現(xiàn)，體積變大，不光是兼容64位導(dǎo)致的，兼容64位只會(huì)導(dǎo)致.a文件的增加，而資源文件是導(dǎo)致體積變大的另一個(gè)因素。

先說(shuō)資源文件，包括以下幾點(diǎn)：

減少圖片和音頻文件的大小(這一點(diǎn)攜程的App做的不錯(cuò)，每個(gè)圖片都不超過(guò)100k，甚至50-100k之間的圖片都很少，而很多App之所以體積大，是因?yàn)槠渲杏泻芏?M以上的圖片)。

對(duì)于PNG圖片，由于它內(nèi)部保存了額外的分層和透明通道信息，統(tǒng)稱(chēng)為EXIF，所以它會(huì)比JPG圖片大一些。App開(kāi)發(fā)推薦使用PNG圖片是因?yàn)閄Code會(huì)在打包時(shí)壓縮PNG圖片的大小。我們可以寫(xiě)一個(gè)腳本，在打包前，把PNG圖片中這些多余的信息，刪除掉。

單色圖片使用使用字體文件。關(guān)于字體文件的技術(shù)，也就是IconFont，網(wǎng)上有很多例子，同時(shí)適用于Andorid和iOS，我這里就不多說(shuō)了。

使用.9圖。之所周知.9圖是Android的技術(shù)，能極大減小圖片的體積，殊不知，iOS也有類(lèi)似的實(shí)現(xiàn)方式。

動(dòng)態(tài)下載表情包。把聊天時(shí)用到的表情圖片，做成從服務(wù)器下載zip包的方式，而不是打包在App中。

清除不再使用的圖片。每次迭代做新需求，都會(huì)導(dǎo)致一些舊圖片不再使用了。XCode不提供檢查未使用圖片的功能，那我們就需要自己寫(xiě)一個(gè)腳本，每次發(fā)版前，對(duì)整個(gè)工程檢查一次。

再說(shuō).a文件。.a文件是編譯文件，這個(gè)文件大，說(shuō)明代碼多。于是我們檢查項(xiàng)目中的代碼，真的要寫(xiě)那么多行嗎?其實(shí)有很多優(yōu)化的空間。

冗余的類(lèi)和方法。這些冗余仍然是因?yàn)樽鲂滦枨髮?dǎo)致的，忘記刪除不用的類(lèi)和方法，需要寫(xiě)腳本查找，定期刪除。

相似度極高的代碼片段。初級(jí)程序員在寫(xiě)代碼時(shí)，喜歡把一段代碼從A類(lèi)粘貼到B類(lèi)中，然后修改其中的幾個(gè)變量名稱(chēng)，這個(gè)功能就算做完了。于是兩段相似度極高的代碼就產(chǎn)生了。

稍微懂得些面向?qū)ο笏枷氲娜�，都知道這時(shí)候需要把這樣的代碼抽象出來(lái)，比如說(shuō)在Utils類(lèi)中新建一個(gè)方法，然后要用到這段邏輯的人調(diào)用Utils類(lèi)的這個(gè)方法即可。

但并不是所有的程序員都有這樣的境界，即使是有幾年經(jīng)驗(yàn)的人，也會(huì)因?yàn)榧敝掳喽耸澜缁蛘呓o孩子換尿布而采用復(fù)制粘貼大法敷衍了事。久而久之，冗余代碼就多了，包的體積自然就大了。為此，我們需要有一個(gè)檢查代碼相似度的工具。在iOS領(lǐng)域，我推薦Simian這個(gè)工具。有興趣的讀者可以嘗試一下，對(duì)你們的項(xiàng)目使用一下這個(gè)工具，看能找出來(lái)多少相似的代碼來(lái)。

使用代碼生成UI，而不是使用Xib或Storyboard。經(jīng)過(guò)測(cè)試，對(duì)于同一個(gè)頁(yè)面，使用代碼而導(dǎo)致的.a文件增加的體積，大于Xib的體積。是時(shí)候該返璞歸真，考慮使用Xib來(lái)布局了。Xib之所以廣受詬病，是因?yàn)閄Code這個(gè)IDE工具很爛，另一個(gè)原因是我們使用的少，人總是會(huì)抵觸陌生的事物，在使用Xib的過(guò)程中遇到障礙了，就又轉(zhuǎn)到寫(xiě)代碼的路線(xiàn)了。

使用Hybird方案來(lái)代替iOS原生代碼。我做過(guò)嘗試，一個(gè)功能模塊，導(dǎo)致.a文件增加3M，但使用Hybird卻只有1-2M的樣子，而且這1-2M中有一部分打包放在App中，另一部分則做成增量下載，從而從整體上減少App包的大小。其中Hybird的增量包技術(shù)是關(guān)鍵。

編譯選項(xiàng)的優(yōu)化。比如說(shuō)Strip Link Product設(shè)為Yes啊，Make Strings Read-Only設(shè)為Yes啊，去掉異常支持啊，都能減少包的大小。此外，經(jīng)常檢查L(zhǎng)inkMap文件，也是控制瘦身的一個(gè)辦法。

微信團(tuán)隊(duì)2015年9月中旬發(fā)布了iOS微信安裝包的瘦身經(jīng)驗(yàn)，其中有很多實(shí)際經(jīng)驗(yàn)。文章地址如下：http://mp.weixin.qq.com/s?__biz=MzAwNDY1ODY2OQ==&mid=207986417&idx=1&sn=77ea7d8e4f8ab7b59111e78c86ccfe66&3rd=MzA3MDU4NTYzMw==&scene=6#rd

其次是春節(jié)期間，某款知名App的后門(mén)泄露事件。所謂后門(mén)，就是App開(kāi)發(fā)期間，方便開(kāi)發(fā)人員和測(cè)試人員的一些功能，比如說(shuō)：

開(kāi)發(fā)人員和測(cè)試人員可以隨意切換到任意服務(wù)器(線(xiàn)上環(huán)境、測(cè)試環(huán)境)進(jìn)行開(kāi)發(fā)測(cè)試工作。傳統(tǒng)的做法，這些地址是寫(xiě)死的，每次打包出來(lái)的App只能在固定的一個(gè)環(huán)境下運(yùn)行，我們迫切需要一個(gè)后門(mén)頁(yè)面，能夠靈活配置。當(dāng)然，線(xiàn)上用戶(hù)是不能看到這個(gè)后門(mén)的，必須做一個(gè)類(lèi)似于彩蛋的功能，比如在設(shè)置頁(yè)的某個(gè)位置連續(xù)點(diǎn)100次，才會(huì)彈出一個(gè)密碼輸入框，只有輸入正確了，才能進(jìn)入后門(mén)頁(yè)面配置服務(wù)器地址。

考慮到發(fā)布到線(xiàn)上的App，存在這樣的彩蛋是非常危險(xiǎn)的。于是我們需要一個(gè)Flag標(biāo)記，在發(fā)布App時(shí)要把這個(gè)值設(shè)置為false，從而關(guān)閉后門(mén)入口。但人總是會(huì)犯錯(cuò)誤的，即使有測(cè)試團(tuán)隊(duì)把關(guān)也還是會(huì)有紕漏。于是，國(guó)內(nèi)某款著名的App在春節(jié)期間就把這樣的后門(mén)漏出來(lái)了，也許是開(kāi)發(fā)或測(cè)試人員急著回家過(guò)年。這是這次無(wú)心之失，讓我們領(lǐng)略了這款A(yù)pp強(qiáng)大的后門(mén)里隱藏的功能。比如說(shuō)，服務(wù)器切換功能(上午已經(jīng)介紹過(guò))。

記錄App的崩潰信息。有這樣一種場(chǎng)景，測(cè)試人員在測(cè)試過(guò)程中發(fā)現(xiàn)的一個(gè)崩潰，雖然也記錄在Bug倉(cāng)庫(kù)中了，但是等開(kāi)發(fā)人員去修復(fù)的時(shí)候，卻難以再現(xiàn)這個(gè)崩潰了。如果能把崩潰記錄到App本地，那么測(cè)試同學(xué)提bug的時(shí)候，就可以把崩潰信息一起貼出來(lái)。

提供一個(gè)后門(mén)頁(yè)面供Html5團(tuán)隊(duì)進(jìn)行調(diào)試，該頁(yè)面內(nèi)置一個(gè)WebView，加載Html5團(tuán)隊(duì)正在開(kāi)發(fā)的Html頁(yè)面，要支持調(diào)試。

對(duì)App進(jìn)行流量測(cè)試，統(tǒng)計(jì)某個(gè)頁(yè)面所花費(fèi)的流量，包括調(diào)用MobileAPI、下載圖片、上傳文件、XMPP聊天等等。其中，從App啟動(dòng)到首頁(yè)加載完成所花費(fèi)的流量是我們關(guān)心的一個(gè)關(guān)鍵點(diǎn)，而手機(jī)待機(jī)時(shí)，App所花費(fèi)的流量也是我們所關(guān)心的。我們需要這樣一個(gè)后門(mén)頁(yè)面，看到這些數(shù)據(jù)統(tǒng)計(jì)。

對(duì)App進(jìn)行電池電量消耗測(cè)試。需要有個(gè)后門(mén)頁(yè)面記錄每次打開(kāi)App和退出App的時(shí)間，以及這段時(shí)間內(nèi)我們的App所消耗的電量。為了確保數(shù)據(jù)的準(zhǔn)確性，需要確保手機(jī)上只安裝了一個(gè)App，而且處于相同的網(wǎng)絡(luò)環(huán)境下，比如3G。

測(cè)試某個(gè)頁(yè)面請(qǐng)求了哪些MobileAPI接口，打印出調(diào)用這些接口時(shí)輸入的參數(shù)和返回JSON數(shù)據(jù)。這樣就能夠在線(xiàn)上App發(fā)現(xiàn)某個(gè)頁(yè)面有問(wèn)題時(shí)，及時(shí)在App后門(mén)中檢查數(shù)據(jù)是否正常，而不用App開(kāi)發(fā)人員和MobileAPI開(kāi)發(fā)人員坐在一起逐行聯(lián)調(diào)代碼，極大的節(jié)省了人力。

在窺探到后門(mén)中這許多先進(jìn)技術(shù)之后，各家無(wú)線(xiàn)團(tuán)隊(duì)紛紛在自己的App中增加類(lèi)似的功能，只是不知道最初把后門(mén)漏出來(lái)的那個(gè)哥們離職了沒(méi)有?

2015年最犀利的技術(shù)首推JSPatch，使用這門(mén)技術(shù)，iOS可以快速修復(fù)線(xiàn)上bug而不需要重新提交AppStore審核。

這門(mén)技術(shù)最早起源于大眾點(diǎn)評(píng)的屠毅敏的一個(gè)開(kāi)源項(xiàng)目WaxPatch。它是通過(guò)重寫(xiě)runtime的class_replaceMethod方法，從而可以修改任何一個(gè)類(lèi)的任何一個(gè)方法，該項(xiàng)目的GitHub地址為：https://github.com/mmin18/WaxPatch。

WaxPatch上支持的語(yǔ)言為L(zhǎng)ua，也就是說(shuō)，建立了一套Objective C和Lua語(yǔ)言之間大部分語(yǔ)法的映射關(guān)系，我們只要熟記這些轉(zhuǎn)換語(yǔ)法，就能快速把一個(gè)Objective C方法翻譯為L(zhǎng)ua方法。然后我們把需要修改的Lua方法所在的類(lèi)文件打包成zip，由App在啟動(dòng)的時(shí)候下載zip包并解壓到本地目錄，于是我們會(huì)看到，當(dāng)運(yùn)行到舊的Objective C方法時(shí)，實(shí)際執(zhí)行的是下載到的Lua方法。這一切都因?yàn)镺bjective是一門(mén)動(dòng)態(tài)語(yǔ)言，我們可以基于此制造一些“黑魔法”。

但是WaxPatch從2013年10月起就不再更新了。當(dāng)2015年2月蘋(píng)果宣布所有上傳至App Store官方商店的新iOS應(yīng)用都必須支持64位，這時(shí)我們發(fā)現(xiàn)WaxPatch并不支持64位。這就間接導(dǎo)致了很多已經(jīng)在項(xiàng)目中使用了WaxPatch的App，必須砍掉WaxPatch熱修復(fù)功能，后來(lái)社區(qū)有人給出了WaxPatch的64位解決方案，才讓熱修復(fù)技術(shù)能繼續(xù)向前發(fā)展，這個(gè)項(xiàng)目的的GitHub地址為：https://github.com/maxfong/WaxPatch_X64/commits/master。

盡管如此，WaxPatch還是有很多局限性。比如說(shuō)它不支持多線(xiàn)程、不支持Block，不支持結(jié)構(gòu)體和結(jié)構(gòu)體指針這兩個(gè)類(lèi)型，這就導(dǎo)致了當(dāng)我們?cè)诔绦蛑惺褂昧诉@些語(yǔ)法時(shí)，是沒(méi)有機(jī)會(huì)把這些語(yǔ)法轉(zhuǎn)換為L(zhǎng)ua代碼的。

通過(guò)上文的分析，我們知道，只要重寫(xiě)runtime的class_replaceMethod方法，就可以熱修復(fù)Objective C中的任何類(lèi)的任何方法，WaxPatch只不過(guò)使用了Lua作為新方法的語(yǔ)言載體，我們完全可以使用Python、javascript這樣的腳本再寫(xiě)出一個(gè)新的Patch。

這時(shí)終于輪到JSPatch登場(chǎng)了，它是由騰訊的陳振焯(英文名Bang)于2015年5月編寫(xiě)的開(kāi)源項(xiàng)目，從名字就能猜出來(lái)，它使用的是javascript語(yǔ)言作為新方法的語(yǔ)言載體，GitHub地址為：https://github.com/bang590/JSPatch。這個(gè)項(xiàng)目解決了上述WaxPatch所不支持的那些語(yǔ)法。目前這個(gè)項(xiàng)目還在每周持續(xù)更新中。

JSPatch還有一個(gè)亮眼的功能，就是支持一鍵生成，把一個(gè)Objective C方法翻譯為javascript的方法。按照這個(gè)思路再往前走一步，就是iOS的“插件化編程”。我們可以把一個(gè)模塊所涉及的所有頁(yè)面都使用Objective C先實(shí)現(xiàn)了，然后一鍵生成javascript方法代碼，打包成一個(gè)zip包，這就是插件化編程。不得不說(shuō)的是，對(duì)大量的代碼執(zhí)行反射操作，性能是一個(gè)問(wèn)題，究竟能往前走多遠(yuǎn)，2016年，我們拭目以待。

2015年注定是iOS領(lǐng)域不平凡的一年，比如說(shuō)，在9月份大規(guī)模爆發(fā)的XCodeGhost病毒。IDE也能攜帶病毒，這是我一個(gè).NET出身、用慣了Visual Studio的程序員所不可理解的一件事。只要是非官方下載的XCode，都有可能通過(guò)CoreService庫(kù)文件進(jìn)行感染，使用有毒XCode開(kāi)發(fā)的App，都會(huì)感染病毒。這就像給病人動(dòng)手術(shù)，結(jié)果手術(shù)刀沒(méi)消毒，病人就會(huì)有生命危險(xiǎn)。

關(guān)鍵是AppStore還無(wú)法檢測(cè)出病毒，傳聞將近800款A(yù)pp感染了這一病毒。

盡管事后立即有人站出來(lái)，聲明自己是XCodeGhost的作者，并宣稱(chēng)是個(gè)“苦X程序員的”、“無(wú)害的”、“實(shí)驗(yàn)”，同時(shí)承認(rèn)自己出于私心，在代碼里加入了廣告功能，并說(shuō)自己在10天前，已主動(dòng)關(guān)閉服務(wù)器，并刪除所有數(shù)據(jù)。

但很多證據(jù)表明，這是一個(gè)蓄謀已久的惡性事件。

當(dāng)號(hào)稱(chēng)“封閉安全”的AppStore也不再安全，我們還能相信誰(shuí)?

接下來(lái)介紹React Native。這是Facebook在React.js Conf 2015 大會(huì)上推出了基于javascript的開(kāi)源框架。同時(shí)支持iOS和Android，Github地址為：http://facebook.github.io/react-native/。

首先，React Native不是依賴(lài)于WebView的，所以它不是Hybird。React Native是把js翻譯為Objective-C，倒是與JSPatch有些淵源。

我一直在關(guān)注著這門(mén)技術(shù)的發(fā)展。但目前看起來(lái)，還很不成熟。盡管在2015年的各種技術(shù)大會(huì)上，React Native出盡了風(fēng)頭，但據(jù)我所示，目前也就BAT這種公司愿意燒錢(qián)讓團(tuán)隊(duì)去嘗試使用。

有關(guān)React Native的更詳細(xì)介紹，推薦大家看下面這兩篇文章：

我對(duì) React Native 的理解和看法：http://div.io/topic/851?utm_source=tuicool&utm_medium=referral

React Native概述：背景、規(guī)劃和風(fēng)險(xiǎn)：https://github.com/tmallfe/tmallfe.github.io/issues/18。

2015年iOS的最后一件“振奮人心”的事情是Swift的開(kāi)源。

Swift從面世伊始，就號(hào)稱(chēng)要取代Obejctive C成為新的iOS開(kāi)發(fā)語(yǔ)言，但是幾年過(guò)后卻還是一個(gè)很小眾的語(yǔ)言。沒(méi)聽(tīng)說(shuō)有哪家大公司的代碼全都切換到Swift了。也許是我孤陋寡聞了，至少在App應(yīng)用領(lǐng)域是這樣。

從2015年12月初Swift開(kāi)源，截止到本文寫(xiě)作期間，這個(gè)項(xiàng)目的Watch(郵件提醒)為1484、Star為22569，F(xiàn)ork為2652，火得一塌糊涂。但是熱鬧過(guò)后，又會(huì)有多少人真正關(guān)注?蘋(píng)果官方給出了開(kāi)源后的諸多好處和美妙的前瞻，這不過(guò)是官方的PR稿子，這不由得讓我想起了.NET當(dāng)初開(kāi)源，也是叫好聲一片，但實(shí)際效果并不理想，參見(jiàn)以下報(bào)道：

作為有著十多年編程經(jīng)驗(yàn)的碼農(nóng)，我不能潑太多冷水。我不想澆滅剛?cè)胄械男∨笥训纳鐓^(qū)熱情。究竟Swift開(kāi)源后能產(chǎn)生什么驚天地泣鬼神的作用，2016年，請(qǐng)用事實(shí)驗(yàn)證吧。

(三)App項(xiàng)目管理

2015年，在App項(xiàng)目管理領(lǐng)域，仍沒(méi)有太大的進(jìn)展。我悲觀的認(rèn)為，App項(xiàng)目管理，已經(jīng)到了糟糕透頂?shù)牡夭健?/FONT>

從事傳統(tǒng)項(xiàng)目管理的工作人員，并沒(méi)有與時(shí)俱進(jìn)，還在把舊的項(xiàng)目管理方式直接套用在App項(xiàng)目管理上。主要體現(xiàn)為傳統(tǒng)項(xiàng)目管理只涉及到產(chǎn)品經(jīng)理、開(kāi)發(fā)和測(cè)試三個(gè)團(tuán)隊(duì)，開(kāi)發(fā)完畢介入測(cè)試，測(cè)試完畢隨時(shí)可以發(fā)布上線(xiàn)，如果一個(gè)團(tuán)隊(duì)延期，另一個(gè)團(tuán)隊(duì)可以做下一次迭代的工作。

但是App開(kāi)發(fā)就不同了，涉及到產(chǎn)品經(jīng)理、Android、iOS、服務(wù)器、測(cè)試共計(jì)5個(gè)團(tuán)隊(duì)的協(xié)作，有時(shí)還會(huì)牽扯進(jìn)H5前端團(tuán)隊(duì)，那就更復(fù)雜了。

App區(qū)別于傳統(tǒng)項(xiàng)目的另一點(diǎn)就在于它有發(fā)版時(shí)間限制。2周或4周的迭代時(shí)間，到了最后一天就必須要提交APpStore審核或發(fā)布到各大Android市場(chǎng)，一般不能延期，否則不光影響技術(shù)團(tuán)隊(duì)，市場(chǎng)推廣團(tuán)隊(duì)也會(huì)受到影響。哪個(gè)做不完或者測(cè)不完，就只能等下次發(fā)版再上，那就是一個(gè)月之后了。

既然迭代周期是固定的，App項(xiàng)目管理所關(guān)心的，就在于如何能在有限的時(shí)間內(nèi)完成盡可能多的需求，而不是每天糾結(jié)于“敏捷白板上的小紙條哪里格式不對(duì)了”這種形式主義的東西。

如果有可能，我真心想把每個(gè)公司所使用的項(xiàng)目管理工具(比如Wiki)廢棄了，工程師們往往是在項(xiàng)目完成后才更新Wiki上的項(xiàng)目狀態(tài)，而做不到即時(shí)更新。我只能在每次App發(fā)版后才看到大量項(xiàng)目的狀態(tài)變更。那我還要這種工具干什么呢?而過(guò)度的要求工程師實(shí)時(shí)使用Wiki來(lái)更新項(xiàng)目狀態(tài)，那無(wú)疑是重流程的軟件公司的打法，不適用于互聯(lián)網(wǎng)高速發(fā)展的文化。越是大公司，這種官僚文化越嚴(yán)重，迭代速度遠(yuǎn)低于創(chuàng)業(yè)公司。因?yàn)榛ヂ?lián)網(wǎng)公司現(xiàn)在錢(qián)很多，很多軟件公司的項(xiàng)目管理人員都跳槽到了大型互聯(lián)網(wǎng)公司，無(wú)形中就把這種文化也帶過(guò)來(lái)了。

說(shuō)真的，我不喜歡循規(guī)蹈矩。我喜歡時(shí)刻去改變?nèi)L試，直到找到一條切實(shí)的解決方案，所以我經(jīng)常會(huì)到一線(xiàn)去，和團(tuán)隊(duì)一起加班一起熬夜。在4年的App項(xiàng)目管理經(jīng)驗(yàn)中，我觀察到的是，對(duì)于10人左右的小團(tuán)隊(duì)，每天可以在晨會(huì)上把產(chǎn)品、Android、iOS、Server、QA的進(jìn)度都過(guò)一遍，控制在10分鐘以?xún)?nèi)。而對(duì)于40人左右的中型團(tuán)隊(duì)，這時(shí)一般會(huì)按照Android、iOS這樣的技術(shù)工種細(xì)分為多個(gè)小團(tuán)隊(duì)，每天晨會(huì)問(wèn)技術(shù)經(jīng)理團(tuán)隊(duì)的項(xiàng)目進(jìn)度，他一般不會(huì)知曉團(tuán)隊(duì)中每個(gè)成員的工作狀態(tài)，所以這樣的晨會(huì)是很沒(méi)有效率的。這時(shí)需要把團(tuán)隊(duì)按照需求拆分為若干虛擬小團(tuán)隊(duì)，每個(gè)需求的虛擬團(tuán)隊(duì)都由產(chǎn)品經(jīng)理、具體的iOS開(kāi)發(fā)、Android開(kāi)發(fā)、Server開(kāi)發(fā)和測(cè)試人員組成，采取產(chǎn)品經(jīng)理負(fù)責(zé)制，每天組織各自的晨會(huì)并發(fā)會(huì)議紀(jì)要。

項(xiàng)目管理人員手中應(yīng)該有一份所有人的名單，減去產(chǎn)品經(jīng)理日?qǐng)?bào)中涉及的人力輸出，那么剩下來(lái)的人力，要么是請(qǐng)假了，要么是在做技術(shù)需求，還剩下來(lái)的人，就是真的沒(méi)事做了，浪費(fèi)掉了。

這時(shí)團(tuán)隊(duì)每個(gè)人的工作狀態(tài)就都一目了然了。我們不苛求每天都把人力充分使用，但至少要做到啞巴吃餃子——心里有數(shù)。

那種靠每周發(fā)周報(bào)的項(xiàng)目管理方式，屬于事后補(bǔ)救，難道我們要在一周之后才知道人員利用率不高而導(dǎo)致的項(xiàng)目風(fēng)險(xiǎn)嗎?這對(duì)于兩周發(fā)一次版本的App而言，多少有些可笑了。

我們不可能安排一個(gè)開(kāi)發(fā)人員一個(gè)迭代只做一個(gè)需求，也許這個(gè)需求兩天就做完了，難道剩下的時(shí)間全都用于修bug嗎?這種敷衍的說(shuō)法，用于哄弄那些不懂技術(shù)的老板的。剩下的時(shí)間應(yīng)該去做更多的需求，那么就會(huì)有人問(wèn)什么時(shí)間修bug?兩周的迭代周期要怎么安排比較合理?

下面我給出兩周的迭代周期圖，這在我所從事的一家大型互聯(lián)網(wǎng)公司一直堅(jiān)持到現(xiàn)在，兩年多了一直風(fēng)雨無(wú)阻：

由上圖我們可以看出，

1)開(kāi)發(fā)只有第1周周二到第2周周三共計(jì)7天時(shí)間。

2)測(cè)試團(tuán)隊(duì)要在開(kāi)發(fā)人員提測(cè)后立即介入，而不是等到所有項(xiàng)目都完成后統(tǒng)一測(cè)試。

3)開(kāi)發(fā)人力不足，一般是第1周加班;測(cè)試人力不足，一般是第2周加班，但沒(méi)有定式。

4)第2周周三晚上為Code Complete，周五晚上為Code Freeze，這兩個(gè)點(diǎn)很關(guān)鍵，直接決定了是否要加班以及是否會(huì)延期。

當(dāng)一個(gè)Task的開(kāi)發(fā)時(shí)間，從3天(粗略評(píng)估)被壓縮到2天(精準(zhǔn)評(píng)估)后，多出的1天時(shí)間做什么?

首先是看還能不能消化更多的需求。

其次，就是重構(gòu)，做技術(shù)需求。App領(lǐng)域有太多的技術(shù)需要升級(jí)，我分析過(guò)100多款國(guó)內(nèi)比較知名的App，發(fā)現(xiàn)各自的瑕疵都還是有很多的。Android的技術(shù)工作會(huì)更多，比如每次迭代要擠出1-2天時(shí)間來(lái)修復(fù)線(xiàn)上千奇百怪的崩潰。

最后，就是研究新技術(shù)。要時(shí)刻了解市面上的新思想和新技術(shù)。

上述這若干文字，都是在詮釋一個(gè)詞，節(jié)奏。

團(tuán)隊(duì)多了自然就會(huì)有溝通上的障礙，從而導(dǎo)致效率大幅下降。而我的觀察是，只要讓所有團(tuán)隊(duì)踩準(zhǔn)了節(jié)奏，App和Server團(tuán)隊(duì)同一時(shí)間聯(lián)調(diào)而不是互相等待，按時(shí)提測(cè)而不耽誤測(cè)試人員的進(jìn)度，提前介入測(cè)試而不是前松后緊，當(dāng)所有的團(tuán)隊(duì)能夠踩住這幾個(gè)節(jié)奏，那么我們就能在有限的時(shí)間內(nèi)按時(shí)完成足夠多的需求。

2016年，我們應(yīng)該重點(diǎn)關(guān)注App的項(xiàng)目管理，多開(kāi)幾次會(huì)各個(gè)公司分享一下經(jīng)驗(yàn)，總結(jié)出一條好的方式來(lái)。

(四)綜合篇

接下來(lái)的篇幅，不限于Android或iOS。

2015年，各大互聯(lián)網(wǎng)公司開(kāi)始經(jīng)營(yíng)自己技術(shù)團(tuán)隊(duì)的微信公眾號(hào)。以下是我收集到的幾個(gè)(排名不分先后哦)，歡迎讀者補(bǔ)充更多的技術(shù)團(tuán)隊(duì)公眾號(hào)：

淘寶：TaobaoTech

天貓：tmalltech

手淘：AlibabaMTT

微信：WeMobileDev

QQ空間前端：QzoneWeb

Bugly：weixinBugly

京東：JDTechEd

美團(tuán)：meituantech

攜程：ctriptech

去哪兒：QunarTL

途牛：tuniutech

當(dāng)當(dāng)：當(dāng)當(dāng)Tech

此外還有技術(shù)社區(qū)的公眾號(hào)(排名不分先后哦)：

InfoQ：infoqchina

CSDN：mobilehub

OSChina 開(kāi)源中國(guó)：gh_430521f7587e

51CTO技術(shù)博客：blog51cto

CocoaChina：cocoachinabbs

極客學(xué)院：jikexueyuan00

通過(guò)持續(xù)關(guān)注這些公眾號(hào)，尤其是無(wú)線(xiàn)相關(guān)的內(nèi)容，可以大致知道業(yè)界最新的技術(shù)趨勢(shì)，比如Android插件化編程，比如iOS瘦身。

2015年，對(duì)無(wú)線(xiàn)領(lǐng)域的技術(shù)分析正式擺上了臺(tái)面。之前肯定有公司也在小規(guī)模的做這個(gè)事情，只是不能多做宣傳罷了。

競(jìng)品分析的手段一般分為幾種：

1)iOS的代碼是無(wú)法反編譯的，但是Android卻可以，大多數(shù)App做了代碼混淆，但也有的App直接裸奔就發(fā)到了市場(chǎng)上。即使代碼做了混淆，我們也能從關(guān)鍵片段中看出端倪來(lái)。關(guān)于這個(gè)技術(shù)我不能再講下去了，否則就要教壞小朋友了。目前看起來(lái)，對(duì)Android進(jìn)行加固是一個(gè)好的辦法，也有一些公司從事這個(gè)領(lǐng)域，但還沒(méi)有廣泛應(yīng)用起來(lái)，比如說(shuō)愛(ài)加密和梆梆。

2)所有的apk或ipa文件，都是壓縮包，我們將其后綴修改為zip格式，就可以解壓并看到其中的文件了。通過(guò)分析這些文件，我們可以學(xué)習(xí)到優(yōu)秀的公司是如何解決App體積大小、性能優(yōu)化新技術(shù)，一般的話(huà)，一個(gè)新的思想或新的技術(shù)，都會(huì)伴隨一個(gè)配置文件在App包中，比如ABTest。

此外，我們知道，Android App中的動(dòng)畫(huà)，會(huì)放在Apk包res/anim目錄中，當(dāng)我們喜歡某款A(yù)pp的動(dòng)畫(huà)效果時(shí)，按圖索驥，直接可以在上述目錄中找到相應(yīng)的動(dòng)畫(huà)文件;但是，當(dāng)我們?cè)趇pa包中也看到類(lèi)似的動(dòng)畫(huà)文件時(shí)，那十有八九是這款A(yù)pp的iOS版本中，存在一個(gè)動(dòng)畫(huà)引擎，iOS程序員可以把Android團(tuán)隊(duì)的動(dòng)畫(huà)文件直接復(fù)制過(guò)來(lái)就可以使用了。

關(guān)于競(jìng)品分析的更多介紹，請(qǐng)參見(jiàn)我發(fā)表在CSDN上的系列文章：http://blog.csdn.net/JspAndAsp/article/details/49339363。

2015年，我終于看到美團(tuán)在App中使用ABTest來(lái)做產(chǎn)品。產(chǎn)品經(jīng)理可以根據(jù)線(xiàn)上A和B兩種策略各自的轉(zhuǎn)化率來(lái)迅速?zèng)Q策哪種策略更適合。

也許ABTest這門(mén)技術(shù)，其他公司早就開(kāi)始在做了，只是沒(méi)有聲張而已，在此請(qǐng)不要笑話(huà)我的孤陋寡聞。我把自己在實(shí)施ABTest的一些經(jīng)驗(yàn)分享出來(lái)，請(qǐng)參見(jiàn)下面這篇文章：http://blog.csdn.net/jspandasp/article/details/49339443。

數(shù)據(jù)驅(qū)動(dòng)產(chǎn)品——我認(rèn)為這才是做產(chǎn)品的方式，而不是靠拍腦袋。稍微高級(jí)一點(diǎn)的產(chǎn)品經(jīng)理，會(huì)收集有利的數(shù)據(jù)來(lái)支撐自己要做的需求，而有意識(shí)的忽略那些不利的數(shù)據(jù)。這多少有些偷奸�；�，需求上線(xiàn)后的結(jié)果也是聽(tīng)天由命大都結(jié)局不好。

產(chǎn)品需求分為兩個(gè)方向，一是剛需，二是交互和UI設(shè)計(jì)。

對(duì)于第一個(gè)方向，需要對(duì)這個(gè)領(lǐng)域浸染很多年，才能真正知道用戶(hù)和供應(yīng)鏈上的真正痛點(diǎn)，目前我見(jiàn)過(guò)這個(gè)方向最好的產(chǎn)品經(jīng)理就是楊威。也許以后還能遇到更好的，但是目前就是他了。2015年我有幸見(jiàn)到了他是怎么在幾個(gè)月內(nèi)從謀劃到調(diào)動(dòng)整個(gè)部門(mén)完成了機(jī)票整個(gè)流程的改造，最后做出來(lái)一套逆向報(bào)價(jià)系統(tǒng)。

對(duì)于第二個(gè)方向，則多少有些自說(shuō)自話(huà)了。一套好的UI設(shè)計(jì)怎么評(píng)定?首先是老板喜歡，這是因?yàn)橐惶自O(shè)計(jì)不可能讓所有人都滿(mǎn)意，但只要老板滿(mǎn)意，就是好的設(shè)計(jì)，搞定了老板，后面的都好談;其次是風(fēng)格要統(tǒng)一;再次是要時(shí)刻關(guān)注競(jìng)爭(zhēng)對(duì)手的App改版。

對(duì)于好的交互設(shè)計(jì)又怎么評(píng)定?首先不能設(shè)計(jì)出“反人類(lèi)”的交互;其次要看PV和UV數(shù)據(jù)，看哪里的轉(zhuǎn)化率低;再次看用戶(hù)反饋，廣泛吸取各方意見(jiàn);最后看競(jìng)品，取長(zhǎng)補(bǔ)短。

無(wú)論哪個(gè)方向，都需要數(shù)據(jù)說(shuō)話(huà)。運(yùn)營(yíng)才是王道，因?yàn)橹挥兴麄儾拍芡ㄟ^(guò)調(diào)整策略得到不同的數(shù)據(jù)，分析數(shù)據(jù)最終做出判斷。運(yùn)營(yíng)人員欠缺的就是不知道如何把需求組織成文檔給開(kāi)發(fā)人員，這時(shí)候就輪到產(chǎn)品經(jīng)理出場(chǎng)了。

產(chǎn)品經(jīng)理應(yīng)該學(xué)點(diǎn)數(shù)學(xué)，能根據(jù)運(yùn)營(yíng)妹紙?zhí)峁┑臄?shù)據(jù)，總結(jié)成公式，才是好的產(chǎn)品經(jīng)理。數(shù)據(jù)驅(qū)動(dòng)產(chǎn)品，重要的事情說(shuō)三遍，不寫(xiě)出來(lái)了，心中默念三遍即可。

接下來(lái)介紹一款由騰訊團(tuán)隊(duì)于2015年發(fā)布的App尾隨測(cè)試的神器，GT(隨身調(diào))。

2015年的最后一門(mén)技術(shù)，那就是App緩存命中率。

從事App開(kāi)發(fā)的同學(xué)可能不清楚緩存命中率的概念。這一般是做在數(shù)據(jù)庫(kù)層面，對(duì)于頻繁訪(fǎng)問(wèn)的數(shù)據(jù)，會(huì)放入緩存中，從而下次訪(fǎng)問(wèn)時(shí)不會(huì)再執(zhí)行SQL語(yǔ)句，極大地節(jié)省了性能，但是也不能把所有的數(shù)據(jù)都放在緩存上哦，沒(méi)有那么大的控件。對(duì)此，我們的妥協(xié)方案是，設(shè)置一個(gè)閾值，大于這個(gè)閾值，緩存的時(shí)間會(huì)長(zhǎng)一些;否則，就只有3分鐘后緩存就會(huì)失效。

其實(shí)這個(gè)思想也可以做在App層面，把相同的邏輯搬到App應(yīng)用中，從而減少訪(fǎng)問(wèn)服務(wù)器的頻率。有些公司已經(jīng)在App所使用的服務(wù)器接口層面做了類(lèi)似的緩存策略，但是還沒(méi)有在App中嘗試實(shí)施這種策略。

(五)結(jié)束語(yǔ)

本人從事App開(kāi)發(fā)4年時(shí)間。當(dāng)初比較貪心，iOS和Android是一起學(xué)的，這就導(dǎo)致了精力要一分為二，結(jié)果哪門(mén)技術(shù)都做不到非常精深，而我又額外花費(fèi)了很多時(shí)間在項(xiàng)目管理上，這也是我所喜愛(ài)的一個(gè)領(lǐng)域。所以上述若干文字，盤(pán)點(diǎn)了2015年App領(lǐng)域的若干新技術(shù)和新思想，但難免掛一漏萬(wàn)，或文中觀點(diǎn)有所偏頗，還請(qǐng)各位讀者多多指教。

最后，再奉獻(xiàn)給讀者們一個(gè)建議。微信這個(gè)工具大家經(jīng)常使用吧，我們經(jīng)常收藏朋友圈中別人分享的一些好的技術(shù)文章，但當(dāng)時(shí)看的并不是很仔細(xì)，是時(shí)候把2015年收藏的所有技術(shù)文章重新翻出來(lái)研讀一遍了，我這幾天就在干這個(gè)事情，收獲還是很大的。

人才招聘

關(guān)于我們 | 法律聲明 | 廣告報(bào)價(jià) | English | 網(wǎng)站地圖

<strike id="mi2mm"></strike>