2015年扣墩，是移動(dòng)領(lǐng)域新技術(shù)取得極大豐收的一年。
（一）Android篇
這里我不談Google IO大會的各種新概念新思想叉信，不談Android 5.0和高逼格的Material Design拆檬，那些都是浮云约素，熱鬧過后，能沉淀下來用于App應(yīng)用的干貨并不多贝攒。我只談這一年來盗誊，我認(rèn)為Android技術(shù)界最激動(dòng)人心的三件事。最后再聊一聊八卦隘弊。
首先是插件化技術(shù)的百家爭鳴哈踱。在此之前，關(guān)于Android插件化的介紹鳳毛麟角梨熙，Android程序員即使想去研究也無從下手开镣。2015年，幾家大的互聯(lián)網(wǎng)公司陸續(xù)開放了自己的插件化編程的項(xiàng)目源碼咽扇，值得注意的是邪财，各家的實(shí)現(xiàn)思想還都不同，各有特色质欲。
1）DL插件化體系
第一個(gè)要介紹的是DL插件化框架树埠，GitHub地址為：https://github.com/singwhatiwanna/dynamic-load-apk。
這個(gè)框架早在2014年3月就在Github上了把敞，直到2015年才基本穩(wěn)定下來弥奸，開始有越來越多的Android開發(fā)人員關(guān)注這個(gè)項(xiàng)目。它是由“民間”三位Android開發(fā)者共同研發(fā)出來的奋早，分別是任玉剛盛霎、田嘯、宋思宇耽装。
這個(gè)項(xiàng)目的特色是愤炸，通過宿主程序中一個(gè)叫做proxy的Activity，去調(diào)用插件中的Activity掉奄。
以下圖片摘取自任玉剛的博客规个，形象的表達(dá)了DL的核心思想：
牛人直播揭秘凤薛，送獨(dú)家賺錢戰(zhàn)法， 【免費(fèi)加群】跟對牛人诞仓，l輕松盈利缤苫！
DL框架面臨兩個(gè)棘手的問題：
首先是通過proxy調(diào)用插件中的Activity，那么插件中的Activity就是一個(gè)普通的類了墅拭，不再具有原有的生命周期活玲，為此需要重寫插件中的Activity的所有生命周期方法，proxy手動(dòng)去管理插件中每個(gè)Activity的onCreate谍婉、onResume這樣的方法舒憾。
其次是插件中的資源，不能再通過R來訪問穗熬，為此要重寫Context中的getAssets方法和getResources方法镀迂。
DL框架最有名的發(fā)明創(chuàng)造。莫過于that語法了唤蔗。在插件中探遵，我們將盡量使用that關(guān)鍵字來替代this。
DL目前還有很多不完善的地方措译。但據(jù)我所知别凤，已經(jīng)有大型移動(dòng)互聯(lián)網(wǎng)公司的Android插件化體系就是基于DL的。
2）Fragment系
https://github.com/mmin18/AndroidDynamicLoader
早在2012年7月领虹，就有大眾點(diǎn)評的屠毅敏在Github上發(fā)布了一個(gè)名為AndroidDynamicLoader的開源項(xiàng)目规哪，這應(yīng)該是第一個(gè)Android插件化的項(xiàng)目，它的亮點(diǎn)在于大規(guī)模的使用Fragment來代替Activity塌衰。所有的Fragment都運(yùn)行在一個(gè)Activity上诉稍，從而在Manifest文件中只事先聲明這個(gè)Activity就夠了，這樣就避免了每次新增一個(gè)Activity都要修改Manifest文件的尷尬最疆。
2015年也有類似的一款基于Fragment的插件化框架問世杯巨，詳情請參見以下地址：
博文介紹：http://blog.csdn.net/sbsujjbcy/article/details/47060211
Github下載：https://github.com/lizhangqu/CorePage
3）阿里系插件化體系
阿里其實(shí)幾年前就在搞插件化編程了，代號為Atlas努酸，只是2015年才把這套技術(shù)公布于眾服爷。先是命名為OpenAtlas，然后改名為ACDD获诈，最后不知道為什么又把GitHub的地址改為ACDDExtension——其實(shí)這3個(gè)項(xiàng)目是一回事仍源，相關(guā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)在于對R進(jìn)行分區(qū)秩铆，從而確保資源相互獨(dú)立互不沖突朗鸠。為此，把功夫做足在aapt這個(gè)命令層面谷市，需要額外修改aapt中的邏輯亡嫌，以確保資源分區(qū)沒有問題嚎于。
4）攜程
https://github.com/CtripMobile/DynamicAPK
攜程的插件化思想和阿里的Atlas有很多相同的地方掘而，由此可見這是一套通用的技術(shù)解決方案，所謂的“正統(tǒng)思想”于购，主要包括以下幾點(diǎn)：
1.aapt上的改造
2.gradle上的改造
3.資源ID分區(qū)
4.修改Context的getAssets方法和getResources方法袍睡，解決R文件的讀取問題。
5）對插件本身沒有限制的新思路
https://github.com/houkx/android-pluginmgr
看慣了前面的各種插件化技術(shù)价涝，細(xì)心的朋友是否發(fā)現(xiàn)女蜈，我們對插件做的太重了，比如說要遵守各種人為的規(guī)定色瘩，重寫aapt指令，資源分區(qū)逸寓，that語法等等居兆。
這個(gè)世界總是太浮躁，讓我們靜下心來做減法竹伸，閉上眼睛思考我們究竟想要什么泥栖，而不是各種跟風(fēng)。是否可以搭建這樣的一個(gè)Android宿主程序勋篓，它可以把任何未經(jīng)安裝吧享、默默躺在SD卡上的apk程序都作為插件加載進(jìn)來。這樣就降低了插件編寫的難度譬嚣。
本篇要介紹的pluginmgr就是這樣的思想钢颂，作者在試圖搭建這樣的一個(gè)萬能的Android宿主程序。
pluginmgrd的核心思想有2點(diǎn)：
一是把插件中所有的Activity都動(dòng)態(tài)生成一個(gè)相對應(yīng)的PluginActivity拜银。啟動(dòng)插件的某個(gè)Activity時(shí)殊鞭，先找PluginActivity，再找對應(yīng)的Activity——所謂的依賴反轉(zhuǎn)的思想尼桶。這就不需要把插件中的Activity還要在宿主中的Manifest文件中注冊操灿。
二是在啟動(dòng)插件的Activity時(shí)，不是通過自己寫程序手動(dòng)去new一個(gè)Activity泵督，而是由Android系統(tǒng)來new這個(gè)Activity趾盐。我們將宿主的ClassLoader替換為FrameworkClassLoader。
注意小腊，所有的插件apk都是不需要安裝的救鲤，只需要靜靜的躺在SD卡上即可。由萬能的pluginmgrd在運(yùn)行時(shí)將這些apk加載進(jìn)來溢豆。
6）更優(yōu)雅的修bug：AndFix
https://github.com/alibaba/AndFix
Android插件化是為了解決什么問題蜒简？
65536方法數(shù)爆棚。
減少apk體積漩仙。
不通過發(fā)版就能發(fā)布新功能
不通過發(fā)版就能修復(fù)線上bug和崩潰搓茬。
但我們經(jīng)過實(shí)踐發(fā)現(xiàn)犹赖，插件化更多的運(yùn)用于修復(fù)線上bug和崩潰。這是一個(gè)很輕量的需求卷仑，卻為此花費(fèi)了大量的人力和財(cái)力去運(yùn)行這樣一套龐大的架構(gòu)體系峻村，是相當(dāng)不劃算的。為此锡凝，2015年github上出現(xiàn)了AndFix粘昨，這款A(yù)ndroid輕量級線上bug修復(fù)工具。
AndFix的核心思想是窜锯，把a(bǔ)pp中的方法B替換為新的方法B ‘,為此张肾，我們把新方法B’所在的代碼進(jìn)行重新打包，并和就的apk包進(jìn)行差分比較锚扎，得到一個(gè)差分包吞瞪，放到服務(wù)器提供舊版apk下載，那么apk在接收到差分包后驾孔，就會執(zhí)行新的方法B’了芍秆，如下圖所示：
這類似于iOS的JSPatch實(shí)現(xiàn)。只不過Objective-C是一門動(dòng)態(tài)語言翠勉，天生就支持這樣的特性妖啥。而在Android中，則需要修改Native底層了对碌。
在Native底層荆虱，有一個(gè)dalvik_dispatcher方法負(fù)責(zé)最終執(zhí)行哪個(gè)方法。就是在這里做一些手腳俭缓，把舊方法替換為新方法克伊。
對于功能不是很多的App而言，AndFix是首選华坦，可以快速修復(fù)線上bug而不用發(fā)新版愿吹，而實(shí)現(xiàn)成本也很低。對于規(guī)模不大的團(tuán)隊(duì)而言惜姐，相當(dāng)劃算犁跪。
這里不得不說到dexposed。dexposed和AndFix都是阿里推出的開源框架歹袁，用以解決Android熱修復(fù)的兩種實(shí)現(xiàn)坷衍，原理兩者類似，都是在在Native底層的dalvik_dispatcher方法做文章条舔。但是dexposed有一個(gè)硬傷枫耳，就是不支持art，這使得很多粉絲轉(zhuǎn)而去投標(biāo)AndFix陣營孟抗。dexposed的github地址為：
https://github.com/alibaba/dexposed
8）360系插件化
https://github.com/Qihoo360/DroidPlugin
縱覽了前面的所有插件化技術(shù)迁杨，你會發(fā)現(xiàn)钻心，它們都是基于單進(jìn)程的。這就是說铅协，插件更新只能等到App重新啟動(dòng)才能生效捷沸。
但是我們的用戶大都是不懂得如何重啟App的。這就導(dǎo)致了插件升級后的更新率并不高狐史，兩周時(shí)間也就50%的升級率痒给，然后App就又發(fā)大版本了。
對于這個(gè)問題骏全，360推出了DroidPlugin的插件化技術(shù)苍柏，它是基于多進(jìn)程的思想。比如說一個(gè)App中有吃喝玩樂4個(gè)插件姜贡，如果“吃”這個(gè)插件有升級序仙，DroidPlugin就可以把正在運(yùn)行的“吃”的舊版本的這個(gè)進(jìn)程殺掉，然后運(yùn)行新的插件版本鲁豪。
目前看起來，對于電商律秃、O2O爬橡、OTA這樣多業(yè)務(wù)線、并偏重于閉環(huán)的App而言棒动，DroidPlugin是一個(gè)終極解決方案糙申。
第二個(gè)激動(dòng)人心的是Facebook開源的Fresco，這是一款強(qiáng)大的圖片加載組件船惨，github地址：https://github.com/facebook/fresco柜裸。
Android領(lǐng)域最讓程序員苦惱的莫過于內(nèi)存不足夠?qū)е碌腛OM異常了，這大都是由于加載大量圖片而沒有及時(shí)回收導(dǎo)致的粱锐。為了解決這個(gè)問題疙挺，Android有很多專門用于加載圖片的組件，比較著名的有ImageLoader怜浅、Picaso等铐然，它們只能在Android層面通過及時(shí)回收圖片資源來緩解Android的內(nèi)存使用，來減緩OOM的發(fā)生頻率恶座。
接下來我們說Fresco搀暑，它引進(jìn)了三級緩存的概念（Bitmap緩存、內(nèi)存緩存和硬盤緩存）跨琳，它比其他圖片下載組件消耗的內(nèi)存小自点，就在于這個(gè)全新的緩存設(shè)計(jì)。三級緩存中脉让，尤以Bitmap緩存最亮眼桂敛。在Android 4.x和更低的系統(tǒng)功炮，Bitmap緩存位于ashmem中，而不是位于Java的堆（heap）中埠啃。這意味著圖片的創(chuàng)建和回收不會引發(fā)過多的GC死宣。
關(guān)于Fresco的更多介紹，請參見Fresco的官方文檔：http://fresco-cn.org/docs/index.html
最后碴开，是針對于Android的線上崩潰的收集整理和分析修復(fù)毅该。其實(shí)收集整理這件事，要么是使用第三方平臺的系統(tǒng)潦牛，要么是自己做眶掌，但是收集到數(shù)據(jù)并去重后，如果分析這些崩潰信息并修復(fù)巴碗，是件很棘手的事情朴爬。要針對于機(jī)型、使用場景橡淆，具體問題具體分析召噩，社區(qū)上（比如CSDN或Stackflow）針對于每個(gè)崩潰信息的分析和修復(fù)方案，魚目混雜逸爵，或只言片語具滴，或空穴來風(fēng)，要逐一訂正是件很費(fèi)神的事情师倔。
我曾經(jīng)試圖來整理這些崩潰的原因和修復(fù)方案构韵，耗費(fèi)半年時(shí)間，也才完成84個(gè)（可以參見《App研發(fā)錄》第6章）趋艘。就在我干這件事的同時(shí)疲恢，騰訊有一個(gè)團(tuán)隊(duì)Bugly也在做類似的事情，他們在11月搞了這樣的一個(gè)活動(dòng)“騰訊 Bugly Android 異常案例解決方案征集”（活動(dòng)的詳細(xì)地址參加http://www.oschina.net/news/67914/tencent-bugly-projects）瓷胧，試圖通過社區(qū)的力量來建立一個(gè)Android的崩潰倉庫显拳。天地萬物皆有時(shí)，崩潰倉庫在2015年只是一個(gè)萌芽抖单，能否做大做全萎攒，我們期待2016年。
前面說了Android太多普大喜奔的事情矛绘，接下來說一說Android在2015年遇到的一個(gè)安全問題耍休。
我敢打賭說，大部分公司的Android項(xiàng)目货矮，會為了方便羊精，而把簽名密鑰放在了項(xiàng)目中，所有開發(fā)人員都可以看到。隨著這幾年開發(fā)人員的流動(dòng)喧锦，密鑰已不再是密鑰了读规。
把密鑰從項(xiàng)目中移除，保存在1-2個(gè)人手中燃少，是個(gè)不錯(cuò)的辦法束亏。但是仍不能避免之前的同事手中握有這份密鑰。密鑰一旦被流傳到市場上阵具，就會有不懷好意的人在原先的App加一些惡意的功能碍遍，然后重新簽名。
更換密鑰嗎阳液？這是個(gè)餿主意怕敬，這會導(dǎo)致生成一個(gè)新的App，而不再是原先的那個(gè)App了帘皿。
其實(shí)這個(gè)問題早就存在东跪，只是現(xiàn)在才擺上臺面而已。目前還沒有更好的解決辦法鹰溜，也只能縮小直到密鑰的人員虽填。
末了插播一條新聞。2015年6月曹动，Google宣布將在年底前停止對Eclipse Android開發(fā)工具的一切支持卤唉，從此我們只能使用Android Studio開發(fā)Android。對于一個(gè)使用Eclipse3年的開發(fā)者而言仁期，我感到非常不適應(yīng)。相信和我有相同感受的朋友不在少數(shù)竭恬。從此跛蛋，Gradle成為標(biāo)配。
ADT的沒落完全是咎由自取痊硕，自身的不努力赊级，導(dǎo)致Google不再花費(fèi)時(shí)間和精力去支持。這樣也好岔绸，集中精力先把一個(gè)IDE做好理逊，目前看起來，Android Studio比微軟的Visual Studio還差很多很多盒揉。
（二）iOS篇
2015年晋被，iOS有太多的事情發(fā)生，每一次事件都促進(jìn)了iOS技術(shù)的一次飛躍刚盈。
首先是蘋果宣布從2015年2月1日開始羡洛，所有上傳至App Store官方商店的新iOS應(yīng)用都必須支持64位。為此藕漱，所有的App在打包時(shí)要兼容32位和64位欲侮，雖然某些機(jī)型上速度快了不少崭闲，但是App的體積卻大了不少。
2015年應(yīng)該是iOS的“瘦身年”威蕉。各大公司在發(fā)現(xiàn)自己的iOS App超過了50M之后刁俭，紛紛開始組織iOS團(tuán)隊(duì)對App進(jìn)行減肥，然后我們就會發(fā)現(xiàn)韧涨，體積變大牍戚，不光是兼容64位導(dǎo)致的，兼容64位只會導(dǎo)致.a文件的增加氓奈，而資源文件是導(dǎo)致體積變大的另一個(gè)因素翘魄。
先說資源文件，包括以下幾點(diǎn)：
減少圖片和音頻文件的大幸獭（這一點(diǎn)攜程的App做的不錯(cuò)暑竟，每個(gè)圖片都不超過100k，甚至50-100k之間的圖片都很少育勺，而很多App之所以體積大但荤，是因?yàn)槠渲杏泻芏?M以上的圖片）。
對于PNG圖片涧至，由于它內(nèi)部保存了額外的分層和透明通道信息腹躁，統(tǒng)稱為EXIF，所以它會比JPG圖片大一些南蓬。App開發(fā)推薦使用PNG圖片是因?yàn)閄Code會在打包時(shí)壓縮PNG圖片的大小纺非。我們可以寫一個(gè)腳本，在打包前赘方，把PNG圖片中這些多余的信息烧颖，刪除掉。
單色圖片使用使用字體文件窄陡。關(guān)于字體文件的技術(shù)炕淮，也就是IconFont，網(wǎng)上有很多例子跳夭，同時(shí)適用于Andorid和iOS涂圆，我這里就不多說了。
使用.9圖币叹。之所周知.9圖是Android的技術(shù)润歉，能極大減小圖片的體積，殊不知颈抚，iOS也有類似的實(shí)現(xiàn)方式卡辰。
動(dòng)態(tài)下載表情包。把聊天時(shí)用到的表情圖片，做成從服務(wù)器下載zip包的方式九妈，而不是打包在App中反砌。
清除不再使用的圖片。每次迭代做新需求萌朱，都會導(dǎo)致一些舊圖片不再使用了宴树。XCode不提供檢查未使用圖片的功能，那我們就需要自己寫一個(gè)腳本晶疼，每次發(fā)版前酒贬，對整個(gè)工程檢查一次。
再說.a文件翠霍。.a文件是編譯文件锭吨，這個(gè)文件大，說明代碼多寒匙。于是我們檢查項(xiàng)目中的代碼零如，真的要寫那么多行嗎？其實(shí)有很多優(yōu)化的空間锄弱。
冗余的類和方法考蕾。這些冗余仍然是因?yàn)樽鲂滦枨髮?dǎo)致的，忘記刪除不用的類和方法会宪，需要寫腳本查找肖卧，定期刪除。
相似度極高的代碼片段掸鹅。初級程序員在寫代碼時(shí)塞帐，喜歡把一段代碼從A類粘貼到B類中，然后修改其中的幾個(gè)變量名稱巍沙，這個(gè)功能就算做完了壁榕。于是兩段相似度極高的代碼就產(chǎn)生了。
稍微懂得些面向?qū)ο笏枷氲娜耸晗梗贾肋@時(shí)候需要把這樣的代碼抽象出來，比如說在Utils類中新建一個(gè)方法颊咬，然后要用到這段邏輯的人調(diào)用Utils類的這個(gè)方法即可务甥。
但并不是所有的程序員都有這樣的境界，即使是有幾年經(jīng)驗(yàn)的人喳篇，也會因?yàn)榧敝掳喽耸澜缁蛘呓o孩子換尿布而采用復(fù)制粘貼大法敷衍了事敞临。久而久之，冗余代碼就多了麸澜，包的體積自然就大了挺尿。為此，我們需要有一個(gè)檢查代碼相似度的工具。在iOS領(lǐng)域编矾，我推薦Simian這個(gè)工具熟史。有興趣的讀者可以嘗試一下，對你們的項(xiàng)目使用一下這個(gè)工具窄俏，看能找出來多少相似的代碼來
使用代碼生成UI蹂匹，而不是使用Xib或Storyboard。經(jīng)過測試凹蜈，對于同一個(gè)頁面限寞，使用代碼而導(dǎo)致的.a文件增加的體積，大于Xib的體積仰坦。是時(shí)候該返璞歸真履植，考慮使用Xib來布局了。Xib之所以廣受詬病悄晃，是因?yàn)閄Code這個(gè)IDE工具很爛玫霎，另一個(gè)原因是我們使用的少，人總是會抵觸陌生的事物传泊，在使用Xib的過程中遇到障礙了鼠渺，就又轉(zhuǎn)到寫代碼的路線了。
使用Hybird方案來代替iOS原生代碼眷细。我做過嘗試拦盹，一個(gè)功能模塊，導(dǎo)致.a文件增加3M溪椎，但使用Hybird卻只有1-2M的樣子普舆，而且這1-2M中有一部分打包放在App中，另一部分則做成增量下載校读，從而從整體上減少App包的大小沼侣。其中Hybird的增量包技術(shù)是關(guān)鍵。
編譯選項(xiàng)的優(yōu)化歉秫。比如說Strip Link Product設(shè)為Yes啊蛾洛，Make Strings Read-Only設(shè)為Yes啊，去掉異常支持啊雁芙，都能減少包的大小轧膘。此外，經(jīng)常檢查LinkMap文件兔甘，也是控制瘦身的一個(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的后門泄露事件拯啦。所謂后門，就是App開發(fā)期間熔任，方便開發(fā)人員和測試人員的一些功能褒链，比如說：
開發(fā)人員和測試人員可以隨意切換到任意服務(wù)器（線上環(huán)境、測試環(huán)境）進(jìn)行開發(fā)測試工作笋敞。傳統(tǒng)的做法碱蒙，這些地址是寫死的，每次打包出來的App只能在固定的一個(gè)環(huán)境下運(yùn)行夯巷，我們迫切需要一個(gè)后門頁面赛惩，能夠靈活配置。當(dāng)然趁餐，線上用戶是不能看到這個(gè)后門的喷兼，必須做一個(gè)類似于彩蛋的功能，比如在設(shè)置頁的某個(gè)位置連續(xù)點(diǎn)100次后雷，才會彈出一個(gè)密碼輸入框季惯，只有輸入正確了，才能進(jìn)入后門頁面配置服務(wù)器地址臀突。
考慮到發(fā)布到線上的App勉抓，存在這樣的彩蛋是非常危險(xiǎn)的。于是我們需要一個(gè)Flag標(biāo)記候学，在發(fā)布App時(shí)要把這個(gè)值設(shè)置為false藕筋，從而關(guān)閉后門入口。但人總是會犯錯(cuò)誤的梳码，即使有測試團(tuán)隊(duì)把關(guān)也還是會有紕漏隐圾。于是，國內(nèi)某款著名的App在春節(jié)期間就把這樣的后門漏出來了掰茶，也許是開發(fā)或測試人員急著回家過年暇藏。這是這次無心之失，讓我們領(lǐng)略了這款A(yù)pp強(qiáng)大的后門里隱藏的功能濒蒋。比如說盐碱，
服務(wù)器切換功能（上午已經(jīng)介紹過）。
記錄App的崩潰信息沪伙。有這樣一種場景瓮顽，測試人員在測試過程中發(fā)現(xiàn)的一個(gè)崩潰，雖然也記錄在Bug倉庫中了焰坪，但是等開發(fā)人員去修復(fù)的時(shí)候，卻難以再現(xiàn)這個(gè)崩潰了聘惦。如果能把崩潰記錄到App本地某饰，那么測試同學(xué)提bug的時(shí)候儒恋，就可以把崩潰信息一起貼出來。
提供一個(gè)后門頁面供Html5團(tuán)隊(duì)進(jìn)行調(diào)試黔漂，該頁面內(nèi)置一個(gè)WebView诫尽，加載Html5團(tuán)隊(duì)正在開發(fā)的Html頁面，要支持調(diào)試炬守。
對App進(jìn)行流量測試牧嫉，統(tǒng)計(jì)某個(gè)頁面所花費(fèi)的流量，包括調(diào)用MobileAPI减途、下載圖片酣藻、上傳文件、XMPP聊天等等鳍置。其中辽剧，從App啟動(dòng)到首頁加載完成所花費(fèi)的流量是我們關(guān)心的一個(gè)關(guān)鍵點(diǎn)，而手機(jī)待機(jī)時(shí)税产，App所花費(fèi)的流量也是我們所關(guān)心的怕轿。我們需要這樣一個(gè)后門頁面，看到這些數(shù)據(jù)統(tǒng)計(jì)辟拷。
對App進(jìn)行電池電量消耗測試撞羽。需要有個(gè)后門頁面記錄每次打開App和退出App的時(shí)間，以及這段時(shí)間內(nèi)我們的App所消耗的電量衫冻。為了確保數(shù)據(jù)的準(zhǔn)確性诀紊，需要確保手機(jī)上只安裝了一個(gè)App，而且處于相同的網(wǎng)絡(luò)環(huán)境下羽杰，比如3G渡紫。
測試某個(gè)頁面請求了哪些MobileAPI接口，打印出調(diào)用這些接口時(shí)輸入的參數(shù)和返回JSON數(shù)據(jù)考赛。這樣就能夠在線上App發(fā)現(xiàn)某個(gè)頁面有問題時(shí)惕澎，及時(shí)在App后門中檢查數(shù)據(jù)是否正常，而不用App開發(fā)人員和MobileAPI開發(fā)人員坐在一起逐行聯(lián)調(diào)代碼颜骤，極大的節(jié)省了人力唧喉。
在窺探到后門中這許多先進(jìn)技術(shù)之后，各家無線團(tuán)隊(duì)紛紛在自己的App中增加類似的功能忍抽，只是不知道最初把后門漏出來的那個(gè)哥們離職了沒有八孝？
2015年最犀利的技術(shù)首推JSPatch，使用這門技術(shù)鸠项，iOS可以快速修復(fù)線上bug而不需要重新提交AppStore審核干跛。
這門技術(shù)最早起源于大眾點(diǎn)評的屠毅敏的一個(gè)開源項(xiàng)目WaxPatch。它是通過重寫runtime的class_replaceMethod方法祟绊，從而可以修改任何一個(gè)類的任何一個(gè)方法楼入，該項(xiàng)目的GitHub地址為：https://github.com/mmin18/WaxPatch
WaxPatch上支持的語言為Lua哥捕，也就是說，建立了一套Objective C和Lua語言之間大部分語法的映射關(guān)系嘉熊，我們只要熟記這些轉(zhuǎn)換語法遥赚，就能快速把一個(gè)Objective C方法翻譯為Lua方法。然后我們把需要修改的Lua方法所在的類文件打包成zip阐肤，由App在啟動(dòng)的時(shí)候下載zip包并解壓到本地目錄凫佛，于是我們會看到，當(dāng)運(yùn)行到舊的Objective C方法時(shí)孕惜，實(shí)際執(zhí)行的是下載到的Lua方法愧薛。這一切都因?yàn)镺bjective是一門動(dòng)態(tài)語言，我們可以基于此制造一些“黑魔法”诊赊。
但是WaxPatch從2013年10月起就不再更新了厚满。當(dāng)2015年2月蘋果宣布所有上傳至App Store官方商店的新iOS應(yīng)用都必須支持64位，這時(shí)我們發(fā)現(xiàn)WaxPatch并不支持64位碧磅。這就間接導(dǎo)致了很多已經(jīng)在項(xiàng)目中使用了WaxPatch的App碘箍，必須砍掉WaxPatch熱修復(fù)功能，后來社區(qū)有人給出了WaxPatch的64位解決方案鲸郊，才讓熱修復(fù)技術(shù)能繼續(xù)向前發(fā)展丰榴，這個(gè)項(xiàng)目的的GitHub地址為：https://github.com/maxfong/WaxPatch_X64/commits/master
盡管如此，WaxPatch還是有很多局限性秆撮。比如說它不支持多線程四濒、不支持Block，不支持結(jié)構(gòu)體和結(jié)構(gòu)體指針這兩個(gè)類型职辨，這就導(dǎo)致了當(dāng)我們在程序中使用了這些語法時(shí)盗蟆，是沒有機(jī)會把這些語法轉(zhuǎn)換為Lua代碼的。
通過上文的分析舒裤，我們知道喳资，只要重寫runtime的class_replaceMethod方法，就可以熱修復(fù)Objective C中的任何類的任何方法腾供，WaxPatch只不過使用了Lua作為新方法的語言載體仆邓，我們完全可以使用Python、JavaScript這樣的腳本再寫出一個(gè)新的Patch伴鳖。
這時(shí)終于輪到JSPatch登場了节值，它是由騰訊的陳振焯（英文名Bang）于2015年5月編寫的開源項(xiàng)目，從名字就能猜出來榜聂，它使用的是JavaScript語言作為新方法的語言載體搞疗，GitHub地址為：https://github.com/bang590/JSPatch。這個(gè)項(xiàng)目解決了上述WaxPatch所不支持的那些語法须肆。目前這個(gè)項(xiàng)目還在每周持續(xù)更新中匿乃。
JSPatch還有一個(gè)亮眼的功能脐往，就是支持一鍵生成，把一個(gè)Objective C方法翻譯為JavaScript的方法扳埂。按照這個(gè)思路再往前走一步，就是iOS的“插件化編程”瘤礁。我們可以把一個(gè)模塊所涉及的所有頁面都使用Objective C先實(shí)現(xiàn)了阳懂，然后一鍵生成JavaScript方法代碼，打包成一個(gè)zip包柜思，這就是插件化編程岩调。不得不說的是，對大量的代碼執(zhí)行反射操作赡盘，性能是一個(gè)問題号枕，究竟能往前走多遠(yuǎn)，2016年陨享，我們拭目以待葱淳。
2015年注定是iOS領(lǐng)域不平凡的一年，比如說抛姑，在9月份大規(guī)模爆發(fā)的XCodeGhost病毒赞厕。IDE也能攜帶病毒，這是我一個(gè).NET出身定硝、用慣了Visual Studio的程序員所不可理解的一件事皿桑。只要是非官方下載的XCode，都有可能通過CoreService庫文件進(jìn)行感染蔬啡，使用有毒XCode開發(fā)的App诲侮，都會感染病毒叫潦。這就像給病人動(dòng)手術(shù)模暗，結(jié)果手術(shù)刀沒消毒，病人就會有生命危險(xiǎn)褪秀。
關(guān)鍵是AppStore還無法檢測出病毒顽腾，傳聞將近800款A(yù)pp感染了這一病毒近零。
盡管事后立即有人站出來，聲明自己是XCodeGhost的作者抄肖，并宣稱是個(gè)“苦X程序員的”久信、“無害的”、“實(shí)驗(yàn)”漓摩，同時(shí)承認(rèn)自己出于私心裙士，在代碼里加入了廣告功能，并說自己在10天前管毙，已主動(dòng)關(guān)閉服務(wù)器腿椎，并刪除所有數(shù)據(jù)桌硫。
但很多證據(jù)表明，這是一個(gè)蓄謀已久的惡性事件啃炸。
當(dāng)號稱“封閉安全”的AppStore也不再安全铆隘，我們還能相信誰？
接下來介紹React Native南用。這是Facebook在React.js Conf 2015 大會上推出了基于JavaScript的開源框架膀钠。同時(shí)支持iOS和Android，Github地址為：
http://facebook.github.io/react-native/
首先裹虫，React Native不是依賴于WebView的肿嘲，所以它不是Hybird。React Native是把js翻譯為Objective-C筑公，倒是與JSPatch有些淵源
我一直在關(guān)注著這門技術(shù)的發(fā)展雳窟。但目前看起來，還很不成熟匣屡。盡管在2015年的各種技術(shù)大會上封救，React Native出盡了風(fēng)頭，但據(jù)我所示捣作，目前也就BAT這種公司愿意燒錢讓團(tuán)隊(duì)去嘗試使用兴泥。
有關(guān)React Native的更詳細(xì)介紹，推薦大家看下面這兩篇文章：
我對 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的開源搓彻。
Swift從面世伊始，就號稱要取代Obejctive C成為新的iOS開發(fā)語言嘱朽，但是幾年過后卻還是一個(gè)很小眾的語言旭贬。沒聽說有哪家大公司的代碼全都切換到Swift了。也許是我孤陋寡聞了搪泳，至少在App應(yīng)用領(lǐng)域是這樣稀轨。
從2015年12月初Swift開源，截止到本文寫作期間岸军，這個(gè)項(xiàng)目的Watch（郵件提醒）為1484奋刽、Star為22569，F(xiàn)ork為2652艰赞，火得一塌糊涂佣谐。但是熱鬧過后，又會有多少人真正關(guān)注方妖？蘋果官方給出了開源后的諸多好處和美妙的前瞻狭魂，這不過是官方的PR稿子，這不由得讓我想起了.NET當(dāng)初開源，也是叫好聲一片雌澄，但實(shí)際效果并不理想斋泄，參見以下報(bào)道：
作為有著十多年編程經(jīng)驗(yàn)的碼農(nóng)，我不能潑太多冷水镐牺。我不想澆滅剛?cè)胄械男∨笥训纳鐓^(qū)熱情炫掐。究竟Swift開源后能產(chǎn)生什么驚天地泣鬼神的作用，2016年睬涧，請用事實(shí)驗(yàn)證吧卒废。
（三）App項(xiàng)目管理
2015年，在App項(xiàng)目管理領(lǐng)域宙地，仍沒有太大的進(jìn)展。我悲觀的認(rèn)為逆皮，App項(xiàng)目管理宅粥，已經(jīng)到了糟糕透頂?shù)牡夭健?/p>
從事傳統(tǒng)項(xiàng)目管理的工作人員，并沒有與時(shí)俱進(jìn)电谣，還在把舊的項(xiàng)目管理方式直接套用在App項(xiàng)目管理上秽梅。主要體現(xiàn)為傳統(tǒng)項(xiàng)目管理只涉及到產(chǎn)品經(jīng)理、開發(fā)和測試三個(gè)團(tuán)隊(duì)剿牺，開發(fā)完畢介入測試企垦，測試完畢隨時(shí)可以發(fā)布上線，如果一個(gè)團(tuán)隊(duì)延期晒来，另一個(gè)團(tuán)隊(duì)可以做下一次迭代的工作钞诡。
但是App開發(fā)就不同了，涉及到產(chǎn)品經(jīng)理湃崩、Android荧降、iOS、服務(wù)器攒读、測試共計(jì)5個(gè)團(tuán)隊(duì)的協(xié)作朵诫，有時(shí)還會牽扯進(jìn)H5前端團(tuán)隊(duì)，那就更復(fù)雜了薄扁。
App區(qū)別于傳統(tǒng)項(xiàng)目的另一點(diǎn)就在于它有發(fā)版時(shí)間限制剪返。2周或4周的迭代時(shí)間，到了最后一天就必須要提交APpStore審核或發(fā)布到各大Android市場邓梅，一般不能延期脱盲，否則不光影響技術(shù)團(tuán)隊(duì)，市場推廣團(tuán)隊(duì)也會受到影響日缨。哪個(gè)做不完或者測不完宾毒，就只能等下次發(fā)版再上，那就是一個(gè)月之后了。
既然迭代周期是固定的诈铛，App項(xiàng)目管理所關(guān)心的乙各，就在于如何能在有限的時(shí)間內(nèi)完成盡可能多的需求，而不是每天糾結(jié)于“敏捷白板上的小紙條哪里格式不對了”這種形式主義的東西幢竹。
如果有可能耳峦，我真心想把每個(gè)公司所使用的項(xiàng)目管理工具（比如Wiki）廢棄了，工程師們往往是在項(xiàng)目完成后才更新Wiki上的項(xiàng)目狀態(tài)焕毫，而做不到即時(shí)更新蹲坷。我只能在每次App發(fā)版后才看到大量項(xiàng)目的狀態(tài)變更。那我還要這種工具干什么呢邑飒？而過度的要求工程師實(shí)時(shí)使用Wiki來更新項(xiàng)目狀態(tài)循签，那無疑是重流程的軟件公司的打法，不適用于互聯(lián)網(wǎng)高速發(fā)展的文化疙咸。越是大公司县匠，這種官僚文化越嚴(yán)重，迭代速度遠(yuǎn)低于創(chuàng)業(yè)公司撒轮。因?yàn)榛ヂ?lián)網(wǎng)公司現(xiàn)在錢很多乞旦，很多軟件公司的項(xiàng)目管理人員都跳槽到了大型互聯(lián)網(wǎng)公司，無形中就把這種文化也帶過來了题山。
說真的兰粉，我不喜歡循規(guī)蹈矩。我喜歡時(shí)刻去改變?nèi)L試顶瞳，直到找到一條切實(shí)的解決方案玖姑，所以我經(jīng)常會到一線去，和團(tuán)隊(duì)一起加班一起熬夜慨菱。在4年的App項(xiàng)目管理經(jīng)驗(yàn)中客峭，我觀察到的是，對于10人左右的小團(tuán)隊(duì)抡柿，每天可以在晨會上把產(chǎn)品舔琅、Android、iOS洲劣、Server备蚓、QA的進(jìn)度都過一遍，控制在10分鐘以內(nèi)囱稽。而對于40人左右的中型團(tuán)隊(duì)郊尝，這時(shí)一般會按照Android、iOS這樣的技術(shù)工種細(xì)分為多個(gè)小團(tuán)隊(duì)战惊，每天晨會問技術(shù)經(jīng)理團(tuán)隊(duì)的項(xiàng)目進(jìn)度流昏，他一般不會知曉團(tuán)隊(duì)中每個(gè)成員的工作狀態(tài)，所以這樣的晨會是很沒有效率的。這時(shí)需要把團(tuán)隊(duì)按照需求拆分為若干虛擬小團(tuán)隊(duì)况凉，每個(gè)需求的虛擬團(tuán)隊(duì)都由產(chǎn)品經(jīng)理谚鄙、具體的iOS開發(fā)、Android開發(fā)刁绒、Server開發(fā)和測試人員組成闷营，采取產(chǎn)品經(jīng)理負(fù)責(zé)制，每天組織各自的晨會并發(fā)會議紀(jì)要知市。
項(xiàng)目管理人員手中應(yīng)該有一份所有人的名單傻盟，減去產(chǎn)品經(jīng)理日報(bào)中涉及的人力輸出，那么剩下來的人力嫂丙，要么是請假了娘赴，要么是在做技術(shù)需求，還剩下來的人跟啤，就是真的沒事做了诽表，浪費(fèi)掉了。
這時(shí)團(tuán)隊(duì)每個(gè)人的工作狀態(tài)就都一目了然了腥光。我們不苛求每天都把人力充分使用，但至少要做到啞巴吃餃子——心里有數(shù)糊秆。
那種靠每周發(fā)周報(bào)的項(xiàng)目管理方式武福，屬于事后補(bǔ)救，難道我們要在一周之后才知道人員利用率不高而導(dǎo)致的項(xiàng)目風(fēng)險(xiǎn)嗎痘番？這對于兩周發(fā)一次版本的App而言捉片，多少有些可笑了。
我們不可能安排一個(gè)開發(fā)人員一個(gè)迭代只做一個(gè)需求汞舱，也許這個(gè)需求兩天就做完了伍纫，難道剩下的時(shí)間全都用于修bug嗎？這種敷衍的說法昂芜，用于哄弄那些不懂技術(shù)的老板的莹规。剩下的時(shí)間應(yīng)該去做更多的需求，那么就會有人問什么時(shí)間修bug泌神？兩周的迭代周期要怎么安排比較合理良漱？
下面我給出兩周的迭代周期圖，這在我所從事的一家大型互聯(lián)網(wǎng)公司一直堅(jiān)持到現(xiàn)在欢际，兩年多了一直風(fēng)雨無阻：
由上圖我們可以看出母市，
1）開發(fā)只有第1周周二到第2周周三共計(jì)7天時(shí)間。
2）測試團(tuán)隊(duì)要在開發(fā)人員提測后立即介入损趋，而不是等到所有項(xiàng)目都完成后統(tǒng)一測試患久。
3）開發(fā)人力不足，一般是第1周加班；測試人力不足蒋失，一般是第2周加班返帕，但沒有定式。
4）第2周周三晚上為Code Complete高镐，周五晚上為Code Freeze溉旋，這兩個(gè)點(diǎn)很關(guān)鍵，直接決定了是否要加班以及是否會延期嫉髓。
當(dāng)一個(gè)Task的開發(fā)時(shí)間观腊，從3天（粗略評估）被壓縮到2天（精準(zhǔn)評估）后，多出的1天時(shí)間做什么算行？
首先是看還能不能消化更多的需求梧油。
其次，就是重構(gòu)州邢，做技術(shù)需求儡陨。App領(lǐng)域有太多的技術(shù)需要升級，我分析過100多款國內(nèi)比較知名的App量淌，發(fā)現(xiàn)各自的瑕疵都還是有很多的骗村。Android的技術(shù)工作會更多，比如每次迭代要擠出1-2天時(shí)間來修復(fù)線上千奇百怪的崩潰呀枢。
最后胚股，就是研究新技術(shù)。要時(shí)刻了解市面上的新思想和新技術(shù)裙秋。
上述這若干文字琅拌，都是在詮釋一個(gè)詞，節(jié)奏摘刑。
團(tuán)隊(duì)多了自然就會有溝通上的障礙进宝，從而導(dǎo)致效率大幅下降。而我的觀察是枷恕，只要讓所有團(tuán)隊(duì)踩準(zhǔn)了節(jié)奏党晋，App和Server團(tuán)隊(duì)同一時(shí)間聯(lián)調(diào)而不是互相等待，按時(shí)提測而不耽誤測試人員的進(jìn)度徐块，提前介入測試而不是前松后緊隶校，當(dāng)所有的團(tuán)隊(duì)能夠踩住這幾個(gè)節(jié)奏，那么我們就能在有限的時(shí)間內(nèi)按時(shí)完成足夠多的需求蛹锰。
2016年深胳，我們應(yīng)該重點(diǎn)關(guān)注App的項(xiàng)目管理，多開幾次會各個(gè)公司分享一下經(jīng)驗(yàn)铜犬，總結(jié)出一條好的方式來舞终。
（四）綜合篇
接下來的篇幅轻庆，不限于Android或iOS。
2015年敛劝，各大互聯(lián)網(wǎng)公司開始經(jīng)營自己技術(shù)團(tuán)隊(duì)的微信公眾號余爆。以下是我收集到的幾個(gè)（排名不分先后哦），歡迎讀者補(bǔ)充更多的技術(shù)團(tuán)隊(duì)公眾號：
淘寶：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ū)的公眾號（排名不分先后哦）：
InfoQ：infoqchina
CSDN：mobilehub
OSChina 開源中國：gh_430521f7587e
51CTO技術(shù)博客：blog51cto
CocoaChina：cocoachinabbs
極客學(xué)院：jikexueyuan00
通過持續(xù)關(guān)注這些公眾號夸盟，尤其是無線相關(guān)的內(nèi)容蛾方，可以大致知道業(yè)界最新的技術(shù)趨勢，比如Android插件化編程上陕，比如iOS瘦身桩砰。
2015年，對無線領(lǐng)域的技術(shù)分析正式擺上了臺面释簿。之前肯定有公司也在小規(guī)模的做這個(gè)事情亚隅，只是不能多做宣傳罷了。
競品分析的手段一般分為幾種：
1）iOS的代碼是無法反編譯的庶溶，但是Android卻可以煮纵，大多數(shù)App做了代碼混淆，但也有的App直接裸奔就發(fā)到了市場上偏螺。即使代碼做了混淆行疏，我們也能從關(guān)鍵片段中看出端倪來。關(guān)于這個(gè)技術(shù)我不能再講下去了套像，否則就要教壞小朋友了酿联。目前看起來，對Android進(jìn)行加固是一個(gè)好的辦法凉夯，也有一些公司從事這個(gè)領(lǐng)域货葬，但還沒有廣泛應(yīng)用起來采幌，比如說愛加密和梆梆劲够。
2）所有的apk或ipa文件，都是壓縮包休傍，我們將其后綴修改為zip格式征绎，就可以解壓并看到其中的文件了。通過分析這些文件磨取，我們可以學(xué)習(xí)到優(yōu)秀的公司是如何解決App體積大小人柿、性能優(yōu)化新技術(shù)，一般的話忙厌，一個(gè)新的思想或新的技術(shù)凫岖，都會伴隨一個(gè)配置文件在App包中，比如ABTest逢净。
此外哥放，我們知道歼指，Android App中的動(dòng)畫，會放在Apk包res/anim目錄中甥雕，當(dāng)我們喜歡某款A(yù)pp的動(dòng)畫效果時(shí)踩身，按圖索驥，直接可以在上述目錄中找到相應(yīng)的動(dòng)畫文件社露；但是挟阻，當(dāng)我們在ipa包中也看到類似的動(dòng)畫文件時(shí)，那十有八九是這款A(yù)pp的iOS版本中峭弟，存在一個(gè)動(dòng)畫引擎附鸽，iOS程序員可以把Android團(tuán)隊(duì)的動(dòng)畫文件直接復(fù)制過來就可以使用了。
關(guān)于競品分析的更多介紹孟害，請參見我發(fā)表在CSDN上的系列文章：
http://blog.csdn.net/JspAndAsp/article/details/49339363
2015年拒炎，我終于看到美團(tuán)在App中使用ABTest來做產(chǎn)品。產(chǎn)品經(jīng)理可以根據(jù)線上A和B兩種策略各自的轉(zhuǎn)化率來迅速?zèng)Q策哪種策略更適合挨务。
也許ABTest這門技術(shù)击你，其他公司早就開始在做了，只是沒有聲張而已谎柄，在此請不要笑話我的孤陋寡聞丁侄。我把自己在實(shí)施ABTest的一些經(jīng)驗(yàn)分享出來，請參見下面這篇文章：http://blog.csdn.net/jspandasp/article/details/49339443
數(shù)據(jù)驅(qū)動(dòng)產(chǎn)品——我認(rèn)為這才是做產(chǎn)品的方式朝巫，而不是靠拍腦袋鸿摇。稍微高級一點(diǎn)的產(chǎn)品經(jīng)理，會收集有利的數(shù)據(jù)來支撐自己要做的需求劈猿，而有意識的忽略那些不利的數(shù)據(jù)拙吉。這多少有些偷奸耍滑揪荣，需求上線后的結(jié)果也是聽天由命大都結(jié)局不好筷黔。
產(chǎn)品需求分為兩個(gè)方向，一是剛需仗颈，二是交互和UI設(shè)計(jì)佛舱。
對于第一個(gè)方向，需要對這個(gè)領(lǐng)域浸染很多年挨决，才能真正知道用戶和供應(yīng)鏈上的真正痛點(diǎn)请祖，目前我見過這個(gè)方向最好的產(chǎn)品經(jīng)理就是楊威。也許以后還能遇到更好的脖祈，但是目前就是他了肆捕。2015年我有幸見到了他是怎么在幾個(gè)月內(nèi)從謀劃到調(diào)動(dòng)整個(gè)部門完成了機(jī)票整個(gè)流程的改造，最后做出來一套逆向報(bào)價(jià)系統(tǒng)盖高。
對于第二個(gè)方向慎陵，則多少有些自說自話了掏秩。一套好的UI設(shè)計(jì)怎么評定？首先是老板喜歡荆姆，這是因?yàn)橐惶自O(shè)計(jì)不可能讓所有人都滿意蒙幻，但只要老板滿意，就是好的設(shè)計(jì)胆筒，搞定了老板邮破，后面的都好談；其次是風(fēng)格要統(tǒng)一仆救；再次是要時(shí)刻關(guān)注競爭對手的App改版抒和。
對于好的交互設(shè)計(jì)又怎么評定？首先不能設(shè)計(jì)出“反人類”的交互彤蔽；其次要看PV和UV數(shù)據(jù)摧莽，看哪里的轉(zhuǎn)化率低；再次看用戶反饋顿痪，廣泛吸取各方意見镊辕；最后看競品，取長補(bǔ)短蚁袭。
無論哪個(gè)方向征懈，都需要數(shù)據(jù)說話。運(yùn)營才是王道揩悄，因?yàn)橹挥兴麄儾拍芡ㄟ^調(diào)整策略得到不同的數(shù)據(jù)卖哎，分析數(shù)據(jù)最終做出判斷。運(yùn)營人員欠缺的就是不知道如何把需求組織成文檔給開發(fā)人員删性，這時(shí)候就輪到產(chǎn)品經(jīng)理出場了亏娜。
產(chǎn)品經(jīng)理應(yīng)該學(xué)點(diǎn)數(shù)學(xué)，能根據(jù)運(yùn)營妹紙?zhí)峁┑臄?shù)據(jù)蹬挺，總結(jié)成公式维贺，才是好的產(chǎn)品經(jīng)理。數(shù)據(jù)驅(qū)動(dòng)產(chǎn)品汗侵，重要的事情說三遍幸缕，不寫出來了群发，心中默念三遍即可晰韵。
接下來介紹一款由騰訊團(tuán)隊(duì)于2015年發(fā)布的App尾隨測試的神器，GT（隨身調(diào)）熟妓。
2015年的最后一門技術(shù)雪猪，那就是App緩存命中率。
從事App開發(fā)的同學(xué)可能不清楚緩存命中率的概念起愈。這一般是做在數(shù)據(jù)庫層面只恨，對于頻繁訪問的數(shù)據(jù)译仗，會放入緩存中，從而下次訪問時(shí)不會再執(zhí)行SQL語句官觅，極大地節(jié)省了性能纵菌，但是也不能把所有的數(shù)據(jù)都放在緩存上哦，沒有那么大的控件休涤。對此咱圆，我們的妥協(xié)方案是，設(shè)置一個(gè)閾值功氨，大于這個(gè)閾值序苏，緩存的時(shí)間會長一些；否則捷凄，就只有3分鐘后緩存就會失效忱详。
其實(shí)這個(gè)思想也可以做在App層面，把相同的邏輯搬到App應(yīng)用中跺涤，從而減少訪問服務(wù)器的頻率匈睁。有些公司已經(jīng)在App所使用的服務(wù)器接口層面做了類似的緩存策略，但是還沒有在App中嘗試實(shí)施這種策略桶错。
（五）結(jié)束語
本人從事App開發(fā)4年時(shí)間软舌。當(dāng)初比較貪心，iOS和Android是一起學(xué)的牛曹，這就導(dǎo)致了精力要一分為二佛点，結(jié)果哪門技術(shù)都做不到非常精深，而我又額外花費(fèi)了很多時(shí)間在項(xiàng)目管理上黎比，這也是我所喜愛的一個(gè)領(lǐng)域超营。所以上述若干文字，盤點(diǎn)了2015年App領(lǐng)域的若干新技術(shù)和新思想阅虫，但難免掛一漏萬演闭，或文中觀點(diǎn)有所偏頗，還請各位讀者多多指教颓帝。
最后米碰，再奉獻(xiàn)給讀者們一個(gè)建議。微信這個(gè)工具大家經(jīng)常使用吧购城，我們經(jīng)常收藏朋友圈中別人分享的一些好的技術(shù)文章吕座，但當(dāng)時(shí)看的并不是很仔細(xì)，是時(shí)候把2015年收藏的所有技術(shù)文章重新翻出來研讀一遍了瘪板，我這幾天就在干這個(gè)事情吴趴，收獲還是很大的。
