app 2015

時間  2019-11-08
標籤 app 简体版
原文   原文鏈接

2015年，是移動領域新技術取得極大豐收的一年。html

（一）Android篇

這裏我不談Google IO大會的各類新概念新思想，不談Android 5.0和高逼格的Material Design，那些都是浮雲。熱鬧事後，能沉澱下來用於App應用的乾貨並很少。前端

我僅僅談這一年來。我以爲Android技術界最激動人心的三件事。最後再聊一聊八卦。react

首先是插件化技術的百家爭鳴。android

在此以前，關於Android插件化的介紹百裏挑一。Android程序猿即便想去研究也無從下手。git

2015年。幾家大的互聯網公司陸續開放了本身的插件化編程的項目源代碼，值得注意的是。各家的實現思想還都不一樣。各有特點。
1）DL插件化體系
第一個要介紹的是DL插件化框架。GitHub地址爲：https://github.com/singwhatiwanna/dynamic-load-apk。
這個框架早在2014年3月就在Github上了，直到2015年才基本穩定下來。開始有愈來愈多的Android開發人員關注這個項目。它是由「民間」三位Android開發人員共同研發出來的。各自是任玉剛、田嘯、宋思宇。
這個項目的特點是，經過宿主程序中一個叫作proxy的Activity，去調用插件中的Activity。
下面圖片摘取自任玉剛的博客，形象的表達了DL的核心思想：github

圖片描寫敘述

DL框架面臨兩個棘手的問題：數據庫

  • 首先是經過proxy調用插件中的Activity，那麼插件中的Activity就是一個普通的類了。再也不具備原有的生命週期，爲此需要重寫插件中的Activity的所有生命週期方法。proxy手動去管理插件中每個Activity的onCreate、onResume這個方案。
  • 其次是插件中的資源，不能再經過R來訪問，爲此要重寫Context中的getAssets方法和getResources方法。

DL框架最有名的發明創造。編程

莫過於that語法了。react-native

在插件中，咱們將盡可能使用thatkeyword來替代this。
DL眼下還有很是多不無缺的地方。但據我所知，已經有大型移動互聯網公司的Android插件化體系就是基於DL的。緩存

2）Fragment系

https://github.com/mmin18/AndroidDynamicLoader
早在2012年7月。就有大衆點評的屠毅敏在Github上公佈了一個名爲AndroidDynamicLoader的開源項目，這應該是第一個Android插件化的項目。它的亮點在於大規模的使用Fragment來取代Activity。所有的Fragment都執行在一個Activity上，從而在Manifest文件裏僅僅事先聲明這個Activity就夠了。這樣就避免了每次新增一個Activity都要改動Manifest文件的尷尬。

2015年也有相似的一款基於Fragment的插件化框架問世，詳情請參見下面地址：

3）阿里系插件化體系
阿里事實上幾年前就在搞插件化編程了，代號爲Atlas，僅僅是2015年才把這套技術發佈於衆。先是命名爲OpenAtlas，而後更名爲ACDD，最後不知道爲何又把GitHub的地址改成ACDDExtension——事實上這3個項目是一回事，相關地址請參見：

Atlas的亮點在於對R進行分區，從而確保資源相互獨立互不衝突。爲此，把功夫作足在aapt這個命令層面。需要額外改動aapt中的邏輯，以確保資源分區沒有問題。

4）攜程
https://github.com/CtripMobile/DynamicAPK
攜程的插件化思想和阿里的Atlas有很是多一樣的地方，因而可知這是一套通用的技術解決方式。所謂的「正統思想」，主要包含下面幾點：

1.aapt上的改造
2.gradle上的改造
3.資源ID分區
4.改動Context的getAssets方法和getResources方法，解決R文件的讀取問題。

5）對插件自己沒有限制的新思路
https://github.com/houkx/android-pluginmgr
看慣了前面的各類插件化技術，細心的朋友是否發現，咱們對插件作的過重了，比方說要遵照各類人爲的規定，重寫aapt指令，資源分區。that語法等等。
這個世界老是太浮躁，讓咱們靜下心來作減法，閉上眼睛思考咱們到底想要什麼，而不是各類跟風。可否夠搭建這種一個Android宿主程序。它可以把不論什麼未經安裝、默默躺在SD卡上的apk程序都做爲插件載入進來。這樣就減小了插件編寫的難度。
本篇要介紹的pluginmgr就是這種思想，做者在試圖搭建這種一個萬能的Android宿主程序。


pluginmgrd的核心思想有2點：

  • 一是把插件中所有的Activity都動態生成一個相相應的PluginActivity。啓動插件的某個Activity時，先找PluginActivity。再找相應的Activity——所謂的依賴反轉的思想。這就不需要把插件中的Activity還要在宿主中的Manifest文件裏註冊。
  • 二是在啓動插件的Activity時。不是經過本身敲代碼手動去new一個Activity。而是由Android系統來new這個Activity。咱們將宿主的ClassLoader替換爲FrameworkClassLoader。

注意，所有的插件apk都是不需要安裝的，僅僅需要靜靜的躺在SD卡上就能夠。

由萬能的pluginmgrd在執行時將這些apk載入進來。

6）更優雅的修bug：AndFix
https://github.com/alibaba/AndFix
Android插件化是爲了解決什麼問題？

  • 65536方法數爆棚。
  • 下降apk體積。
  • 不經過發版就能公佈新功能
  • 不經過發版就能修復線上bug和崩潰。

但咱們通過實踐發現。插件化不少其它的運用於修復線上bug和崩潰。

這是一個很是輕量的需求，卻爲此花費了大量的人力和財力去執行這樣一套龐大的架構體系，是至關不划算的。爲此。2015年github上出現了AndFix，這款Android輕量級線上bug修復工具。
AndFix的核心思想是。把app中的方法B替換爲新的方法B ‘,爲此，咱們把新方法B’所在的代碼進行又一次打包。並和就的apk包進行差分比較，獲得一個差分包，放到server提供舊版apk下載。那麼apk在接收到差分包後。就會運行新的方法B’了，例如如下圖所看到的：

圖片描寫敘述

這相似於iOS的JSPatch實現。僅僅只是Objective-C是一門動態語言。天生就支持這種特性。而在Android中，則需要改動Native底層了。
在Native底層，有一個dalvik_dispatcher方法負責終於運行哪一個方法。

就是在這裏作一些手腳，把舊方法替換爲新方法。

對於功能不是很是多的App而言，AndFix是首選，可以高速修復線上bug而不用發新版。而實現成本也很是低。

對於規模不大的團隊而言，至關划算。

這裏不得不說到dexposed。

dexposed和AndFix都是阿里推出的開源框架，用以解決Android熱修復的兩種實現。原理二者相似。都是在在Native底層的dalvik_dispatcher方法作文章。但是dexposed有一個硬傷，就是不支持art，這使得很是多粉絲轉而去投標AndFix陣營。dexposed的github地址爲：
https://github.com/alibaba/dexposed

8）360系插件化
https://github.com/Qihoo360/DroidPlugin
縱覽了前面的所有插件化技術，你會發現，它們都是基於單進程的。這就是說，插件更新僅僅能等到App又一次啓動才幹生效。
但是咱們的用戶大都是不懂得怎樣從新啓動App的。

這就致使了插件升級後的更新率並不高。兩週時間也就50%的升級率。而後App就又發大版本號了。


對於這個問題，360推出了DroidPlugin的插件化技術，它是基於多進程的思想。比方說一個App中有吃喝玩樂4個插件。假設「吃」這個插件有升級，DroidPlugin就可以把正在執行的「吃」的舊版本號的這個進程殺掉，而後執行新的插件版本號。
眼下看起來，對於電商、O2O、OTA這樣多業務線、並偏重於閉環的App而言，DroidPlugin是一個終極解決方式。

第二個激動人心的是Facebook開源的Fresco，這是一款強大的圖片載入組件，github地址：https://github.com/facebook/fresco。


Android領域最讓程序猿苦惱的莫過於內存不足夠致使的OOM異常了。這大都是由於載入大量圖片而沒有及時回收致使的。爲了解決問題，Android有很是多專門用於載入圖片的組件，比較著名的有ImageLoader、Picaso等，它們僅僅能在Android層面經過及時回收圖片資源來緩解Android的內存使用。來減緩OOM的發生頻率。
接下來咱們說Fresco，它引進了三級緩存的概念（Bitmap緩存、內存緩存和硬盤緩存），它比其它圖片下載組件消耗的內存小，就在於這個全新的緩存設計。

三級緩存中。尤以Bitmap緩存最亮眼。

在Android 4.x和更低的系統。Bitmap緩存位於ashmem中。而不是位於Java的堆（heap）中。這意味着圖片的建立和回收不會引起過多的GC。


關於Fresco的不少其它介紹。請參見Fresco的官方文檔：http://fresco-cn.org/docs/index.html

最後。是針對於Android的線上崩潰的收集整理和分析修復。事實上收集整理這件事。要麼是使用第三方平臺的系統，要麼是本身作，但是收集到數據並去重後。假設分析這些崩潰信息並修復，是件很是棘手的事情。

要針對於機型、使用場景，詳細問題詳細分析。社區上（比方CSDN或Stackflow）針對於每個崩潰信息的分析和修復方案，魚目混雜，或僅僅言片語，或空穴來風。要逐一訂正是件很是費神的事情。
我之前試圖來整理這些崩潰的緣由和修復方案，耗費半年時間，也才完畢84個（可以參見《App研發錄》第6章）。就在我幹這件事的同一時候，騰訊有一個團隊Bugly也在作相似的事情，他們在11月搞了這種一個活動「騰訊 Bugly Android 異常案例解決方式徵集」（活動的具體地址參加http://www.oschina.net/news/67914/tencent-bugly-projects），試圖經過社區的力量來創建一個Android的崩潰倉庫。

天地萬物皆有時，崩潰倉庫在2015年僅僅是一個萌芽。是否能作大作全，咱們期待2016年。

前面說了Android太多普大喜奔的事情，接下來講一說Android在2015年遇到的一個安全問題。


我敢打賭說，大部分公司的Android項目，會爲了方便，而把簽名密鑰放在了項目中，所有開發者都可以看到。隨着這幾年開發者的流動，密鑰已再也不是密鑰了。


把密鑰從項目中移除，保存在1-2我的手中，是個不錯的辦法。但是仍不能避免以前的同事手中握有這份密鑰。密鑰一旦被流傳到市場上，就會有不懷好意的人在原先的App加一些惡意的功能，而後又一次簽名。
更換密鑰嗎？這是個餿主意。這會致使生成一個新的App。而再也不是原先的那個App了。
事實上這個問題早就存在，僅僅是現在才擺上檯面而已。眼下尚未更好的解決的方法。也僅僅能縮小直到密鑰的人員。

末了插播一條新聞。

2015年6月。Google宣佈將在年末前中止對Eclipse Android開發工具的一切支持，今後咱們僅僅能使用Android Studio開發Android。對於一個使用Eclipse3年的開發人員而言。我感到很不適應。

相信和我有一樣感覺的朋友不在少數。今後。Gradle成爲標配。
ADT的沒落全然是咎由自取，自身的不努力。致使Google再也不花費時間和精力去支持。這樣也好。集中精力先把一個IDE作好，眼下看起來，Android Studio比微軟的Visual Studio還差很是多很是多。

（二）iOS篇

2015年。iOS有太多的事情發生，每一次事件都促進了iOS技術的一次飛躍。

首先是蘋果宣佈從2015年2月1日開始，所有上傳至App Store官方商店的新iOS應用都必須支持64位。爲此，所有的App在打包時要兼容32位和64位。儘管某些機型上速度快了很多。但是App的體積卻大了很多。
2015年應該是iOS的「瘦身年」。各大公司在發現本身的iOS App超過了50M以後。紛紛開始組織iOS團隊對App進行減肥，而後咱們就會發現，體積變大，不光是兼容64位致使的，兼容64位僅僅會致使.a文件的添加。而資源文件是致使體積變大的還有一個因素。
先說資源文件。包含下面幾點：

  • 下降圖片和音頻文件的大小（這一點攜程的App作的不錯。每個圖片都不超過100k。甚至50-100k之間的圖片都很是少，而很是多App之因此體積大，是因爲當中有很是多1M以上的圖片）。
  • 對於PNG圖片，因爲它內部保存了額外的分層和透明通道信息，統稱爲EXIF，因此它會比JPG圖片大一些。App開發推薦使用PNG圖片是因爲XCode會在打包時壓縮PNG圖片的大小。咱們可以寫一個腳本，在打包前，把PNG圖片中這些多餘的信息，刪除掉。
  • 單色圖片使用使用字體文件。關於字體文件的技術。也就是IconFont，網上有很是多樣例，同一時候適用於Andorid和iOS，我這裏就很少說了。
  • 使用.9圖。之所周知.9圖是Android的技術。能極大減少圖片的體積，卻不知，iOS也有相似的實現方式。
  • 動態下載表情包。把聊天時用到的表情圖片，作成從server下載zip包的方式。而不是打包在App中。
  • 清除再也不使用的圖片。每次迭代作新需求，都會致使一些舊圖片再也不使用了。

    XCode不提供檢查未使用圖片的功能。那咱們就需要本身寫一個腳本。每次發版前。對整個project檢查一次。

再說.a文件。.a文件是編譯文件。這個文件大。說明代碼多。

因而咱們檢查項目中的代碼。真的要寫那麼多行嗎？事實上有很是多優化的空間。

  • 冗餘的類和方法。這些冗餘仍然是因爲作新需求致使的。忘記刪除不用的類和方法，需要寫腳本查找。按期刪除。
  • 類似度極高的代碼片斷。0基礎程序猿在寫代碼時，喜歡把一段代碼從A類粘貼到B類中，而後改動當中的幾個變量名稱，這個功能就算作完了。

    因而兩段類似度極高的代碼就產生了。


    略微懂得些面向對象思想的人，都知道這時候需要把這種代碼抽象出來。比方說在Utils類中新建一個方法，而後要用到這段邏輯的人調用Utils類的這種方法就能夠。
    但並不是所有的程序猿都有這種境地，即便是有幾年經驗的人，也會因爲急着下班二人世界或者給孩子換尿布而採用複製粘貼大法敷衍了事。長此以往。冗餘代碼就多了，包的體積天然就大了。

    爲此，咱們需要有一個檢查代碼類似度的工具。

    在iOS領域，我推薦Simian這個工具。

    有興趣的讀者可以嘗試一下，對大家的項目使用一下這個工具，看能找出來多少類似的代碼來

  • 使用代碼生成UI。而不是使用Xib或Storyboard。通過測試，對於同一個頁面。使用代碼而致使的.a文件添加的體積，大於Xib的體積。是時候該返璞歸真。考慮使用Xib來佈局了。Xib之因此廣受詬病，是因爲XCode這個IDE工具很是爛。還有一個緣由是咱們使用的少。人老是會抵觸陌生的事物，在使用Xib的過程當中遇到障礙了。就又轉到寫代碼的路線了。
  • 使用Hybird方案來取代iOS原生代碼。我作過嘗試，一個功能模塊，致使.a文件添加3M，但使用Hybird卻僅僅有1-2M的樣子，而且這1-2M中有一部分打包放在App中，還有一部分則作成增量下載，從而從整體上下降App包的大小。當中Hybird的增量包技術是關鍵。
  • 編譯選項的優化。比方說Strip Link Product設爲Yes啊。Make Strings Read-Only設爲Yes啊。去掉異常支持啊。都能下降包的大小。

    此外。經常檢查LinkMap文件。也是控制瘦身的一個辦法。

微信團隊2015年9月中旬公佈了iOS微信安裝包的瘦身經驗，當中有很是多實際經驗。文章地址例如如下：
http://mp.weixin.qq.com/s?__biz=MzAwNDY1ODY2OQ==&mid=207986417&idx=1&sn=77ea7d8e4f8ab7b59111e78c86ccfe66&3rd=MzA3MDU4NTYzMw==&scene=6#rd

其次是春節期間，某款知名App的後門泄露事件。所謂後門，就是App開發期間。方便開發者和測試人員的一些功能，比方說：
開發者和測試人員能夠隨意切換到隨意server（線上環境、測試環境）進行開發測試工做。傳統的作法。這些地址是寫死的，每次打包出來的App僅僅能在固定的一個環境下執行，咱們迫切需要一個後門頁面。能夠靈活配置。固然。線上用戶是不能看到這個後門的，必須作一個相似於彩蛋的功能，比方在設置頁的某個位置連續點100次。纔會彈出一個password輸入框，僅僅有輸入正確了，才幹進入後門頁面配置server地址。
考慮到公佈到線上的App，存在這種彩蛋是很危急的。因而咱們需要一個Flag標記，在公佈App時要把這個值設置爲false，從而關閉後門入口。但人老是會犯錯誤的，即便有測試團隊把關也仍是會有紕漏。因而，國內某款著名的App在春節期間就把這種後門漏出來了。或許是開發或測試人員急着回家過春節。這是此次無意之失。讓咱們領略了這款App強大的後門裏隱藏的功能。比方說，

  • server切換功能（上午已經介紹過）。
  • 記錄App的崩潰信息。

    有這樣一種場景。測試人員在測試過程當中發現的一個崩潰，儘管也記錄在Bug倉庫中了，但是等開發者去修復的時候，卻難以再現這個崩潰了。

    假設能把崩潰記錄到App本地，那麼測試同窗提bug的時候，就行把崩潰信息一塊兒貼出來。

  • 提供一個後門頁面供Html5團隊進行調試。該頁面內置一個WebView。載入Html5團隊正在開發的Html頁面。要支持調試。
  • 對App進行流量測試，統計某個頁面所花費的流量，包含調用MobileAPI、下載圖片、上傳文件、XMPP聊天等等。當中。從App啓動到首頁載入完畢所花費的流量是咱們關心的一個關鍵點。而手機待機時，App所花費的流量也是咱們所關心的。咱們需要這樣一個後門頁面。看到這些數據統計。

  • 對App進行電池電量消耗測試。需要有個後門頁面記錄每次打開App和退出App的時間。以及這段時間內咱們的App所消耗的電量。爲了確保數據的準確性。需要確保手機上僅僅安裝了一個App，而且處於一樣的網絡環境下，比方3G。
  • 測試某個頁面請求了哪些MobileAPI接口。打印出調用這些接口時輸入的參數和返回JSON數據。這樣就行在線上App發現某個頁面有問題時，及時在App後門中檢查數據是否正常。而不用App開發者和MobileAPI開發者坐在一塊兒逐行聯調代碼，極大的節省了人力。

在窺探到後門中這不少先進技術以後。各家無線團隊紛紛在本身的App中添加相似的功能，僅僅是不知道最初把後門漏出來的那個哥們離職了沒有？

2015年最犀利的技術首推JSPatch，使用這門技術。iOS可以高速修復線上bug而不需要又一次提交AppStore審覈。
這門技術最先起源於大衆點評的屠毅敏的一個開源項目WaxPatch。它是經過重寫runtime的class_replaceMethod方法。從而可以改動不論什麼一個類的不論什麼一個方法，該項目的GitHub地址爲：https://github.com/mmin18/WaxPatch
WaxPatch上支持的語言爲Lua。也就是說，創建了一套Objective C和Lua語言之間大部分語法的映射關係，咱們僅僅要熟記這些轉換語法，就能高速把一個Objective C方法翻譯爲Lua方法。

而後咱們把需要改動的Lua方法所在的類文件打包成zip。由App在啓動的時候下載zip包並解壓到本地文件夾，因而咱們會看到。當執行到舊的Objective C方法時。實際執行的是下載到的Lua方法。這一切都因爲Objective是一門動態語言，咱們可以基於此製造一些「黑魔法」。
但是WaxPatch從2013年10月起就再也不更新了。

當2015年2月蘋果宣佈所有上傳至App Store官方商店的新iOS應用都必須支持64位，這時咱們發現WaxPatch並不支持64位。這就間接致使了很是多已經在項目中使用了WaxPatch的App，必須砍掉WaxPatch熱修復功能。後來社區有人給出了WaxPatch的64位解決方式。才讓熱修復技術能繼續向前發展，這個項目的的GitHub地址爲：https://github.com/maxfong/WaxPatch_X64/commits/master
雖然如此，WaxPatch仍是有很是多侷限性。比方說它不支持多線程、不支持Block，不支持結構體和結構體指針這兩個類型，這就致使了當咱們在程序中使用了這些語法時，是沒有機會把這些語法轉換爲Lua代碼的。
經過上文的分析，咱們知道，僅僅要重寫runtime的class_replaceMethod方法，就可以熱修復Objective C中的不論什麼類的不論什麼方法，WaxPatch僅僅只是使用了Lua做爲新方法的語言載體，咱們全然可以使用Python、JavaScript這種腳本再寫出一個新的Patch。
這時最終輪到JSPatch登場了，它是由騰訊的陳振焯（英文名Bang）於2015年5月編寫的開源項目，從名字就能猜出來。它使用的是JavaScript語言做爲新方法的語言載體。GitHub地址爲：https://github.com/bang590/JSPatch。這個項目攻克了上述WaxPatch所不支持的那些語法。眼下這個項目還在每週持續更新中。


JSPatch另外一個亮眼的功能。就是支持一鍵生成，把一個Objective C方法翻譯爲JavaScript的方法。依照這個思路再往前走一步，就是iOS的「插件化編程」。咱們可以把一個模塊所涉及的所有頁面都使用Objective C先實現了，而後一鍵生成JavaScript方法代碼，打包成一個zip包，這就是插件化編程。不得不說的是。對大量的代碼運行反射操做。性能是一個問題，到底能往前走多遠。2016年。咱們拭目以待。

2015年註定是iOS領域不平庸的一年，比方說，在9月份大規模爆發的XCodeGhost病毒。IDE也能攜帶病毒，這是我一個.NET出身、用慣了Visual Studio的程序猿所不可理解的一件事。僅僅要是非官方下載的XCode，都有可能經過CoreService庫文件進行感染。使用有毒XCode開發的App，都會感染病毒。這就像給病人動手術，結果手術刀沒消毒。病人就會有生命危急。
關鍵是AppStore還沒法檢測出病毒，傳聞將近800款App感染了這一病毒。
雖然過後立刻有人站出來。聲明本身是XCodeGhost的做者，並宣稱是個「苦X程序猿的」、「無害的」、「實驗」，同一時候認可本身出於私心。在代碼裏增長了廣告功能，並說本身在10天前，已主動關閉server。並刪除所有數據。
但很是多證據代表，這是一個蓄謀已久的惡性事件。
當號稱「封閉安全」的AppStore也再也不安全，咱們還能相信誰？

接下來介紹React Native。這是Facebook在React.js Conf 2015 大會上推出了基於JavaScript的開源框架。

同一時候支持iOS和Android。Github地址爲：
http://facebook.github.io/react-native/
首先，React Native不是依賴於WebView的，因此它不是Hybird。React Native是把js翻譯爲Objective-C，卻是與JSPatch有些淵源
我一直在關注着這門技術的發展。但眼下看起來，還很是不成熟。

雖然在2015年的各類技術大會上。React Native出盡了風頭，但據我所看到的。眼下也就BAT這樣的公司願意燒錢讓團隊去嘗試使用。
有關React Native的更具體介紹，推薦你們看如下這兩篇文章：

2015年iOS的最後一件「振奮人心」的事情是Swift的開源。
Swift從面世伊始。就號稱要代替Obejctive C成爲新的iOS開發語言，但是幾年事後卻仍是一個很是小衆的語言。

沒據說有哪家大公司的代碼全都切換到Swift了。或許是我孤陋寡聞了，至少在App應用領域是這樣。


從2015年12月初Swift開源，截止到本文寫做期間。這個項目的Watch（郵件提醒）爲148四、Star爲22569。Fork爲2652，火得一塌糊塗。

但是熱鬧事後，又會有多少人真正關注？蘋果官方給出了開源後的諸多優勢和美妙的前瞻。這只是是官方的PR稿子，這不禁得讓我想起了.NET當初開源，也是叫好聲一片。但實際效果並不理想，參見下面報道：

圖片描寫敘述

做爲有着十多年編程經驗的碼農。我不能潑太多冷水。我不想澆滅剛入行的小朋友的社區熱情。到底Swift開源後能產生什麼驚天地泣鬼神的做用，2016年，請用事實驗證吧。

（三）App項目管理

2015年，在App項目管理領域。仍沒有太大的進展。我悲觀的以爲，App項目管理。已經到了糟糕透頂的地步。


從事傳統項目管理的工做人員，並無與時俱進，還在把舊的項目管理方式直接套用在App項目管理上。主要體現爲傳統項目管理僅僅涉及到產品經理、開發和測試三個團隊，開發完成介入測試，測試完成隨時可以公佈上線，假設一個團隊延期。還有一個團隊可以作下一次迭代的工做。


但是App開發就不一樣了，涉及到產品經理、Android、iOS、server、測試共計5個團隊的協做，有時還會牽扯進H5前端團隊，那就更復雜了。
App差異於傳統項目的還有一點就在於它有發版時間限制。2周或4周的迭代時間，到了最後一天就必須要提交APpStore審覈或公佈到各大Android市場。通常不能延期。不然不光影響技術團隊，市場推廣團隊也會受到影響。

哪一個作不完或者測不完，就僅僅能等下次發版再上，那就是一個月以後了。
既然迭代週期是固定的，App項目管理所關心的。就在於怎樣能在有限的時間內完畢儘量多的需求，而不是天天糾結於「敏捷白板上的小紙條哪裏格式不正確了」這樣的形式主義的東西。
假設有可能，我真心想把每個公司所使用的項目管理工具（比方Wiki）廢棄了。project師們每每是在項目完畢後才更新Wiki上的項目狀態。而作不到即時更新。我僅僅能在每次App發版後纔看到大量項目的狀態變動。那我還要這樣的工具幹什麼呢？而過分的要求project師實時使用Wiki來更新項目狀態。那無疑是重流程的軟件公司的打法。不適用於互聯網快速發展的文化。越是大公司。這樣的官僚文化越嚴重。迭代速度遠低於創業公司。因爲互聯網公司現在錢很是多。很是多軟件公司的項目管理人員都跳槽到了大型互聯網公司，無形中就把這樣的文化也帶過來了。


說真的，我不喜歡循規蹈矩。我喜歡時刻去改變去嘗試，直到找到一條切實的解決方式，因此我經常會到一線去，和團隊一塊兒加班一塊兒熬夜。在4年的App項目管理經驗中，我觀察到的是，對於10人左右的小團隊，天天可以在晨會上把產品、Android、iOS、Server、QA的進度都過一遍，控制在10分鐘之內。而對於40人左右的中型團隊，這時一般會依照Android、iOS這種技術工種細分爲多個小團隊，天天晨會問技術經理團隊的項目進度，他通常不會知曉團隊中每個成員的工做狀態，因此這種晨會是很是沒有效率的。這時需要把團隊依照需求拆分爲若干虛擬小團隊，每個需求的虛擬團隊都由產品經理、詳細的iOS開發、Android開發、Server開發和測試人員組成，採取產品經理負責制，天天組織各自的晨會併發會議紀要。


項目管理人員手中應該有一份所有人的名單，減去產品經理日報中涉及的人力輸出，那麼剩下來的人力，要麼是請假了，要麼是在作技術需求，還剩下來的人，就是真的沒事作了，浪費掉了。
這時團隊每個人的工做狀態就都一目瞭然了。咱們不苛求天天都把人力充分使用。但至少要作到啞吧吃餃子——內心有數。


那種靠每週發週報的項目管理方式，屬於過後補救，難道咱們要在一週以後才知道人員利用率不高而致使的項目風險嗎？這對於兩週發一次版本號的App而言，多少有些好笑了。
咱們不可能安排一個開發者一個迭代僅僅作一個需求，或許這個需求兩天就作完了。難道剩下的時間全都用於修bug嗎？這樣的敷衍的說法，用於哄弄那些不懂技術的老闆的。

剩下的時間應該去作不少其它的需求，那麼就會有人問什麼時間修bug？兩週的迭代週期要怎麼安排比較合理？
如下我給出兩週的迭代週期圖，這在我所從事的一家大型互聯網公司一直堅持到現在。兩年多了一直風雨無阻：

圖片描寫敘述

由上圖咱們可以看出，

1）開發僅僅有第1週週二到第2週週三共計7天時間。
2）測試團隊要在開發者提測後立刻介入，而不是等到所有項目都完畢後統一測試。
3）開發人力不足，一般是第1周加班；測試人力不足，一般是第2周加班。但沒有定式。
4）第2週週三晚上爲Code Complete，週五晚上爲Code Freeze，這兩個點很是關鍵，直接決定了是否要加班以及是否會延期。

當一個Task的開發時間，從3天（粗略評估）被壓縮到2天（精準評估）後，多出的1天時間作什麼？

首先是看還能不能消化不少其它的需求。
其次，就是重構，作技術需求。App領域有太多的技術需要升級。我分析過100多款國內比較知名的App，發現各自的瑕疵都仍是有很是多的。Android的技術工做會不少其它，比方每次迭代要擠出1-2天時間來修復線上千奇百怪的崩潰。
最後。就是研究新技術。要時刻了解市面上的新思想和新技術。

上述這若干文字，都是在詮釋一個詞，節奏。
團隊多了天然就會有溝通上的障礙，從而致使效率大幅降低。

而個人觀察是。僅僅要讓所有團隊踩準了節奏。App和Server團隊同一時間聯調而不是互相等待，按時提測而不耽誤測試人員的進度。提早介入測試而不是前鬆後緊，當所有的團隊能夠踩住這幾個節奏，那麼咱們就能在有限的時間內按時完畢足夠多的需求。
2016年。咱們應該重點關注App的項目管理，多開幾回會各個公司分享一下經驗，總結出一條好的方式來。

（四）綜合篇

接下來的篇幅，不限於Android或iOS。

2015年。各大互聯網公司開始經營本身技術團隊的微信公衆號。下面是我收集到的幾個（排名不分前後哦）。歡迎讀者補充不少其它的技術團隊公衆號：

  • 淘寶：TaobaoTech
  • 天貓：tmalltech
  • 手淘：AlibabaMTT
  • 微信：WeMobileDev
  • QQ空間前端：QzoneWeb
  • Bugly：weixinBugly
  • 京東：JDTechEd
  • 美團：meituantech
  • 攜程：ctriptech
  • 去哪兒：QunarTL
  • 途牛：tuniutech
  • 噹噹：噹噹Tech

此外還有技術社區的公衆號（排名不分前後哦）：

  • InfoQ：infoqchina
  • CSDN：mobilehub
  • OSChina 開源中國：gh_430521f7587e
  • 51CTO技術博客：blog51cto
  • CocoaChina：cocoachinabbs
  • 極客學院：jikexueyuan00

經過持續關注這些公衆號，尤爲是無線相關的內容。可以大體知道業界最新的技術趨勢。比方Android插件化編程，比方iOS瘦身。

2015年，對無線領域的技術分析正式擺上了檯面。

以前確定有公司也在小規模的作這個事情。僅僅是不能多作宣傳罷了。
競品分析的手段通常分爲幾種：
1）iOS的代碼是沒法反編譯的，但是Android卻可以。大多數App作了代碼混淆，但也有的App直接裸奔就發到了市場上。即便代碼作了混淆，咱們也能從關鍵片斷中看出端倪來。關於這個技術我不能再講下去了。不然就要教壞小朋友了。眼下看起來。對Android進行加固是一個好的辦法，也有一些公司從事這個領域，但尚未普遍應用起來，比方說愛加密和梆梆。
2）所有的apk或ipa文件。都是壓縮包，咱們將其後綴改動爲zip格式，就可以解壓並看到當中的文件了。經過分析這些文件，咱們可以學習到優秀的公司是怎樣解決App體積大小、性能優化新技術，通常的話，一個新的思想或新的技術，都會伴隨一個配置文件在App包中，比方ABTest。
此外。咱們知道，Android App中的動畫，會放在Apk包res/anim文件夾中。當咱們喜歡某款App的動畫效果時。按圖索驥，直接可以在上述文件夾中找到對應的動畫文件；但是。當咱們在ipa包中也看到相似的動畫文件時，那十有八九是這款App的iOS版本號中，存在一個動畫引擎。iOS程序猿可以把Android團隊的動畫文件直接複製過來就可以使用了。
關於競品分析的不少其它介紹，請參見我發表在CSDN上的系列文章：
http://blog.csdn.net/JspAndAsp/article/details/49339363

2015年，我最終看到美團在App中使用ABTest來作產品。產品經理可以依據線上A和B兩種策略各自的轉化率來迅速決策哪一種策略更適合。


或許ABTest這門技術，其它公司早就開始在作了。僅僅是沒有聲張而已，在此請不要笑話個人孤陋寡聞。

我把本身在實施ABTest的一些經驗分享出來，請參見如下這篇文章：http://blog.csdn.net/jspandasp/article/details/49339443
數據驅動產品——我以爲這纔是作產品的方式，而不是靠拍腦殼。略微高級一點的產品經理。會收集有利的數據來支撐本身要作的需求，而有意識的忽略那些不利的數據。

這多少有些偷奸耍滑，需求上線後的結果也是聽天由命大都結局很差。


產品需求分爲兩個方向。一是剛需。二是交互和UI設計。
對於第一個方向，需要對這個領域浸染很是多年，才幹真正知道用戶和供應鏈上的真正痛點，眼下我見過這個方向最好的產品經理就是楊威。或許之後還能遇到更好的。但是眼下就是他了。2015年我有幸見到了他是怎麼在幾個月內從謀劃到調動整個部門完畢了機票整個流程的改造。最後作出來一套逆向報價系統。
對於第二個方向。則多少有些自說自話了。一套好的UI設計怎麼評定？首先是老闆喜歡，這是因爲一套設計不可能讓所有人都愜意。但僅僅要老闆愜意，就是好的設計。搞定了老闆，後面的都好談。其次是風格要統一。再次是要時刻關注競爭對手的App改版。


對於好的交互設計又怎麼評定？首先不能設計出「反人類」的交互。其次要看PV和UV數據。看哪裏的轉化率低；再次看用戶反饋，普遍吸收各方意見。最後看競品，取長補短。
無論哪一個方向，都需要數聽說話。運營纔是王道，因爲僅僅有他們才幹經過調整策略獲得不一樣的數據，分析數據終於作出推斷。運營人員欠缺的就是不知道怎樣把需求組織成文檔給開發者，這時候就輪到產品經理出場了。
產品經理應該學點數學。能依據運營妹紙提供的數據，總結成公式，纔是好的產品經理。數據驅動產品，重要的事情說三遍。不寫出來了。心中默唸三遍就能夠。

接下來介紹一款由騰訊團隊於2015年公佈的App跟隨測試的神器，GT（隨身調）。

2015年的最後一門技術，那就是App緩存命中率。
從事App開發的同窗可能不清楚緩存命中率的概念。這一般是作在數據庫層面。對於頻繁訪問的數據。會放入緩存中。從而下次訪問時不會再運行SQL語句。極大地節省了性能，但是也不能把所有的數據都放在緩存上哦，沒有那麼大的控件。

對此。咱們的妥協方案是，設置一個閾值，大於這個閾值，緩存的時間會長一些；不然，就僅僅有3分鐘後緩存就會失效。
事實上這個思想也可以作在App層面。把一樣的邏輯搬到App應用中，從而下降訪問server的頻率。有些公司已經在App所使用的server接口層面作了相似的緩存策略。但是尚未在App中嘗試實施這樣的策略。

（五）結束語

本人從事App開發4年時間。當初比較貪心，iOS和Android是一塊兒學的，這就致使了精力要一分爲二，結果哪門技術都作不到很是精深，而我又額外花費了很是多時間在項目管理上，這也是我所喜好的一個領域。因此上述若干文字，盤點了2015年App領域的若干新技術和新思想，但不免掛一漏萬，或文中觀點有所偏頗，還請各位讀者多多不吝賜教。

最後，再奉獻給讀者們一個建議。微信這個工具你們經常使用吧。咱們經常收藏朋友圈中別人分享的一些好的技術文章，但當時看的並不是很是細緻，是時候把2015年收藏的所有技術文章又一次翻出來研讀一遍了，我這幾天就在幹這個事情，收穫仍是很是大的。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程