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教程