三步瘦身法 司马亮教你为app“塑形”

相信很多同行都遇到过这个问题,那就是随着时间的推移,team合作开发的项目会因为各种原因导致我们的安装包越来越大,大到自己都不愿意去商城点击下载自己开发的这个应用了。应用跟人的身材一样,一旦“肥胖”,则下载量呈直线下滑,因此我们有必要对我们的app进行“塑形”了。

借着这个机会,我对手头的两个项目(iOS应用)进行了“瘦身”,成功瘦身1/3。其实对于一个30M左右的ipa包来说,能够成功瘦身到20M左右,已经相当不容易了。接下里描述下我是如何一步步做到的。

总体来说,应用瘦身分三个大的层次,分别是资源的优化、编译时候的优化以及深层次的可执行文件优化。

如下图所示:
总体优化逻辑

接下来详细描述这三步操作。

第一步:对于资源文件进行压缩优化

所谓对资源文件的处理,就是对项目中一些图片、音频或者视频文件的排查处理。具体方法如下:

1、搜索冗余图片资源

很多时候,我们发现尽管项目中有很多图片资源,但是有一部分图片是并没有使用的,那么如何找到这些未使用的图片呢?这里我介绍两种方法:

a、利用工具
下载一个项目工具(下载地址 http://jeffhodnett.github.io/Unused/ ),然后运行这个项目工具,在弹出的应用工具中选择我们所要排插的工程文件。即可进行自动搜索这些未经使用的文件。

b、终端命令
此种方法需要安装ack  [在终端通过:brew install ack 命令安装ack(ack用于做搜索)]  。
首先建立.sh 文件 如 unusedImage.sh(可以通过sublime Text编写)

#! /bin/bash
for i in `find . -name “*.png” -o -name “*.jpg”`; do
file=`basename -s .jpg $i | xargs basename -s .png | xargs basename -s @2x` result=`ack -i $file`
if [ -z $result ]; then
echo $i
# 如果需要,可以直接执行删除:
# rm “$i”
fi
done

然后进入你要查找的工程目录下执行 这段 shell 脚本,
sh unusedImage.sh
       运行出来的结果就是程序语言所辨别出来的一些未使用的资源图片。但是千万不要将这些图片一起删除了,因为有可能这些图片在某些地方以另外一种方式使用着。

2、排查冗余图片

123

经过运行软件,得到的冗余图片实在是多,我们接下来要做的就是用人脑对每个文件进行排除。一定要确保这个文件在应用中确实没有被使用,才能删除。对于不确定的图片素材,宁愿保留也不要轻易删除。

3、压缩优化大文件

编译项目,在我的资源中,相应路径下找到该项目文件,右键显示包内容,再对这些包内容list按照大小排序,找到其中占据比较大的一些文件。看看能否进行相应优化处理。

4、处理未使用的僵尸文件。

由于应用开发人员较多,导入进去的各种资源有可能重复,也有部分测试用的文件。那么这个时候就需要去找到这些僵尸文件,然后删除。我在整理整个项目的时候,就发现了又几个音频文件保留在项目中,而项目中没有任何地方引用。因此这个时候可以果断删除掉。

第二步:编译优化

1.编译器优化级别

Build Settings->Optimization Level有几个编译优化选项,release版应该选择Fastest, Smalllest,这个选项会开启那些不增加代码大小的全部优化,并让可执行文件尽可能小。

2.去除符号信息

Strip Debug Symbols During Copy 和 Symbols Hidden by Default 在release版本应该设为yes,可以去除不必要的调试符号。Symbols Hidden by Default会把所有符号都定义成”private extern”,具体意思和作用我还不清楚,有待研究,但设了后会减小体积。这些选项目前都是XCode默认选项,但旧版XCode生成的项目可能不是,可以检查一下。

3.PrefixHeader.pch引用瘦身。

尽量避免全局引用,除非是类似网络接口类,这种基本每个类控制器都会用到的引用。我在检查中就发现,很多时候开发人员为了图方便,直接将头文件在PrefixHeader中引入,这样导致的后果就是每次编译都会将该文件引用编译。无端降低了程序运行效率。

第三步:深入分析,对于可执行文件进行压缩

其实做到上面两步,我们应用已经瘦身很多了,至少已经让我的应用安装包瘦身8M(这个数值因人而异,因项目而异),为了追求更加完美,我需要对应用进行更深入的瘦身,且看下面分解。

一、设置link map,以便本地生成记录

通过Xcode自带的link map来记录我们的可执行文件list,这里需要按照下图设置。

设置link map

点击编译,开始本地生成可执行文件记录。

二、打开沙盒路径

1、如果不知道沙盒路径,可以在自己的应用中打印其路径。

NSLog(@”沙盒路径:%@”,NSHomeDirectory());

/Users/apple/Library/Application Support/iPhone Simulator/6.1/Applications/******-****-****-****-************

打开Finder,选择前往-前往文件夹(或选择快捷键command+shift+G)输入打印出来的路径即可会得到打印结果*为字母或数字,即为沙盒的路径

2、打开Finder,选择前往并按住option键,进入资源库

找到这个linkmap 的txt文件,本次路径为:

Path: /Users/mac/Library/Developer/Xcode/DerivedData/WisdomMedical-afinsdxtbizadydfxufjuxeckkew/Build/Products/Debug-iphoneos/WisdomMedical.app/******

跋山涉水,终于找到这个文件:

可执行文件

接下来就是通过脚本文件编辑器来查看分析生成的这个文件

三、分析link map

这个LinkMap里展示了整个可执行文件的全貌,列出了编译后的每一个.o目标文件的信息(包括静态链接库.a里的),以及每一个目标文件的代码段,数据段存储详情。

(1)在LinkMap里首先列出来的是目标文件列表

列表1

前面中括号里的是这个文件的编号,后面会用到,像项目里引用到静态链接库libMobClickLibrary.a里的目标文件都会在这里列出来。

(2)在LinkMap里最后编译成的可执行文件中的偏移位置及大小

接着是一个段表,描述各个段在最后编译成的可执行文件中的偏移位置及大小,包括了代码段(__TEXT,保存程序代码段编译后的机器码)和数据段(__DATA,保存变量值)。

列表2

首列是数据在文件的偏移位置,第二列是这一段占用大小,第三列是段类型,代码段和数据段,第四列是段名称。

每一行的数据都紧跟在上一行后面,如第二行__stubs的地址0x101364528就是第一行__text的地址0×100005B80加上大小0×0135EA8,整个可执行文件大致数据分布就是这样。

这里可以清楚看到各种类型的数据在最终可执行文件里占的比例,例如__text表示编译后的程序执行语句,__data表示已初始化的全局变量和局部静态变量,__bss表示未初始化的全局变量和局部静态变量,__cstring表示代码里的字符串常量,等等。

(3)接着在LinkMap里就是按上表顺序,列出具体的按每个文件列出每个对应字段的位置和占用空间。

列表3

同样首列是数据在文件的偏移地址,第二列是占用大小,第三列是所属文件序号,对应上述Object files列表,最后是名字。

例如第二行代表了文件序号为2(反查上面就是TKPFileInfo.o)的parseWithDictionary方法占用了1000byte大小。

通过这个可以查看编译后可执行文件占据大小,便于定位和优化项目。

好了,三步到此结束。相信只要你按照着三步来进行应用项目分析,一定可以讲应用塑形成“型男”,赢的广大用户的喜爱。

方向比速度重要

最近1-2个月正是金三银四的招聘高峰期,我也和老大一起在负责公司的一部分人员的筛选和招聘工作,在这个过程中我也开始慢慢体会到当初我在初入职场时的迷茫,投递简历时的盲目不用心等等,最关键的是现在当我作为一个站在招聘者角度的人,我更能体会老板在招人时的心理特点和想法。同时作为一个工作快6年的老鸟,对职业发展的各种困惑的次次顿悟和无数迷茫的层层击破,让我觉得互联网IT这行的职业发展规划或者发展方向对于一个从业者而言显得至关重要。回想起当初从大学校门离开的那一刻,没有引路人,全靠自己的感觉去判断未来的路该如何去走,再到慢慢的习惯去咨询那些工作好几年的互联网IT老鸟,让这些过来人给自己指路,我才开始觉得自己能少走很多的弯路,所以从那以后我个人的薪资也是一路水涨船高,基本也实现了翻倍增长的“好业绩”,算不上顶尖,但也足够了。可以不成功,但是不能不成长,这是我一直以来对自己的要求,我对自己限定:每隔18个月,也就是1年半就要实现一次翻倍增长,不仅仅是薪水也有见识和思维能力。

大封面

方向比速度重要,这句感悟是我在上一家公司工作中总结出来的。我之前和绝大多数技术人员一样,都属于那种一到办公室就闷头搞技术的IT男,所以了,习惯了技术仔的思维去做事,不太喜欢与人沟通,导致每次领导给我安排的任务,我最开始总是对工作重心领悟的不太对,做的结果就是南辕北辙。这段时间了,我们公司也招一个UI设计,我和老大都觉得她的设计功底挺不错的,所以就招进来了,结果没想到的是招进来后,发觉她干活非常勤快而且也很追求速度,但是她却表现的比较闷,基本上一天也很少说话和沟通,前几次,我给安排的工作任务,做出来也是一个南辕北辙,有些不是重点不用做的也在花心思做,该做的反倒没花心思做,总之最开始确实让我挺不满意的。可以断定她是一个互联网IT行业的小菜鸟,这女的之前在非互联网的公司做设计,所以她确实也不太懂在互联网IT行业里面及时的沟通反馈,明确方向再做事,是保证敏捷开发的基本前提。这是一个追求速度和效率至上的时代,但如果前行的方向是错误的,那么做再多的努力用再快的速度都是一枉然。

现在才慢慢发觉:人最痛苦的时候其实并不是工资最低的时候,而是苦苦找不到好的方向因此而迷茫的时候。回想起自己这将近6年的经历,相比最开始的自己,拥有了自己坚定的方向,也学会了如何看清大势把握好方向,当然这一路上要多感谢那些给我诚心诚意指路和解惑的引路人。

方向是战略层面的事情,技巧是战术层面的事情,试想一个从业者如果在方向都没有选对或者犹豫不决的情况下,你再怎么努力再怎么用技巧再怎么加速,结果可能依然是一枉然。所以看清大势,把握方向,顺势而为,不做一个两耳不闻窗外事的宅男码农,避免在错误的方向上继续前行,是当下众多踌躇不前的从业者的当务之急。

我觉得以下几种人需要好好的思考下方向的问题:

  1. 即将毕业或刚毕业不久的,这类人自觉做职场发展规划的相对比较少,让能够提前对未来有规划的同学,显然要比同龄人更加领先一步
  2. 入行1-2年的,一般这个时间段内,大多从事的是初级或中级职务,事务性的活相对比较多,冲击高级职务是这个阶段的当务之急,而且这2年的积累也是后期跳槽的根基
  3. 入行3-5年的,这个时间段的人,慢慢开始遭遇到了上升的瓶颈,如果无法突破瓶颈,以后的日子会过的相对比较辛苦一点,在这个时间段能实现向更高级的管理岗转型可能会是一个不错的选择。

产品经理,一定不要成为画图经理

导读:产品经理,一定不要成为画图经理,要把控好大方向,包括行业大事,行业历史行业发展。而不是沉迷于小儿科的东西耍帅,这样往往丢西瓜捡芝麻。

 

常常在产品经理群,看到几个产品人在讨论 axure 如何使用函数、变量、运算符,如何做出高保真装逼原型图,如何将 axure 变成华丽的装逼利器。这样做产品,其实已经走错了方向。我经常和一些产品经理讨论,关于原型,要做高保真,中保真,还是低保真图。调研中发现 30%的产品经理只做低保真,60%的产品经理认为中保真对于指导 UI 作图,开发支持已经足够。10%的产品经理往往很追求细节完美,也会自我强迫的做出保真程度很高的原型。然而,陷入到作图细节中,往往会忽略更多。

很多人一提到产品经理,首先想到的产品经理技能,就是画原型。然而画原型图只是产品经理的一项基本工作,只是工作中的一小部分。例如,我之前做产品的一个新模块,做完调研、需求分析、竞品分析、业务流程、功能组织框架、信息架构后,这时候做原型,就很清晰了,作图加上给项目组开会讨论修改也只用了几天的时间。前面的铺垫做好了,后面做起来比较顺,开发中也不会遇到很多坑。我这几年来做原型,也只做到中保真,没有动效,也没有很复杂的交互。我会在原型中对组件做好备注,对页面做好批注。对于产品上的规则会做补充说明文档,手势基本口述说明。

  产品经理工作:

另外多提一下原型,原型图属于框架层中要完成的部分,框架层主要完成产品页面的结构和布局。在这里,我提一下框架层,这个源于《用户体验要素》,这是一本层次和逻辑交代特别清晰的书。告诉我们做产品要从下往上做,从战略层,范围层,再到结构层,框架层,最后到表现层。关于这本书的理解和分析,我这里不作赘述,相信很多产品人都看过,推荐指数五星。

再拉回主题上来,我时常看到很多文章,教 PM 们如果用 axure 装逼,Axure 如何使用才能成为装逼利器。每每看到这些,简直都如鲠在喉。

产品经理是公司的 “魂”,就算要装逼,也不该在原型高保真上浪费时间,这种炫技,真心随便都能罗列出几点弊端:

产品经理的时间本来就很碎片化,做方案,做业务流程,头脑风暴、信息架构分析、竞品分析,包括产品和数据上的一大摊子事情,所以像我还有一些产品朋友,很多都是抽晚上的休息时间来做原型图,如果做高保真,真心太浪费时间

做高保真原型图,如果中途出现业务或者流程的大改动,要推翻了重来,那 PM 估计会在程序员崩溃前崩溃了吧。

类似于很常用的幻灯片之类,如果原型中用动态面板把这个做的完美了,我就只能呵呵了,我相信这种东西,正常的 Pm 应该会选择多说两句话交代吧。

最后,也是最最要的,产品经理要把控好大方向,大格局,包括行业新鲜大事件,行业大咖,行业历史沿革,行业发展生态链。而不是去沉迷于 axure 炫技,这样往往因小失大,沉迷进去,失掉大格局的眼光。

下面是我整理的关于汽车行业的一个简略图,Y 轴为汽车行业的产品链,X 轴为这些产品的发展史。

 

  那么从炫技中跳出来的产品经理,更应该关注哪些点?

  一、需求分析:

  一定要做好需求分析,做出产品需求和用户需求。

1、需求搜集:产品需求来源于不同的渠道,老板的目标需求,用户的需求和反馈,市场、运营、客服人员的需求等,对需求做好分类,并进行深层次挖掘。通过定量定性的问卷,竞品分析,市场分析及数据分析,对需求进行进一步整理,需求要搜集的越多越好,在需求搜集这里,我们要做加法。

2、需求评估:在五花八门的需求里分析和筛选,哪些是我们核心战略需求,哪些是支撑性需求,哪些是表面需求下面的本质需求。不断挖掘评估,将需求抽象出来。

3、需求管理:需求确定好后,做好需求管理,也就是划分优先级。我们可以根据四象限分析法则对需求进行紧急和重要程度的分析,对需求做好管理。过程中对不要一直加需求,即使是为了更良好的用户体验,做产品,要把控好产品节奏。快速上行,拿到数据和反馈,并做好快速迭代。

 二、找到痛点:

发现用户真正的痛点,这个痛点一定要是痛的,是用户确实需要解决的,而不是你去意淫出来的伪需求。必须是刚需,必须是痛点,必须痛!重要的事情我只能反复强调。然后你去竞品分析,看其他的产品有没有切切实实解决到用户的这个痛点。

三、调研:

找到你的用户,并做好用户调研。如果是 toB 的产品,做好行业调研。此处用户建模,修正数据,情景分析等不作赘述。

  四、关注竞品:

竞品分析是产品经理必做的工作。很多公司在增加一些功能的时候,会选择看看竞品是怎么做的。竞品分析,也慢慢变成了竞品抄袭,所以模仿竞品渐渐的成了一个坑。经常听到产品人说,“XX 产品有啊,我们也做嘛”。做产品千万不能这么做,一定要看清竞品的定位和我们的定位分别是怎样?是一样的用户群吗?功能使用场景一样吗?实现的方式要和竞品一样吗?有没有更好的方法?最后送十六字箴言:取其精华,去其糟泊,抵制诱惑,懂得克制。

 五、流程:

做产品流程图一般分为业务流程和操作流程,流程是否跑的通,是否合理,对一个产品很重要,所以对于流程,一定要多琢磨,想透,想明白。

业务流程:不同角色的人为了完成某个目标而进行的一系列活动。

操作流程:用户完成一个目标要经历的一系列操作。

  六、信息架构:

信息架构由用户、情景和内容构成,把信息和关系抽象出来,从而使我们的产品有了骨架。而产品架构的深度和广度,决定了内容模块和页面的层级复杂度。信息架构绝不是单纯的产品功能组织框架,它更要突出表达的是信息之间的逻辑关系,所以梳理好产品的信息架构,才能使产品更清晰更易用。(其实这里完全阔以另起文章说明了)

七、把控项目,做好迭代:

做好项目管理是产品经理的必备技能。关于怎么把控项目,我这里简单的阐述几个点:

1、做好工作量评估:项目的整体规划,后台、服务端、移动端,有时可能还有 h5 项目,做精确的功能清单,评估技术实现难度,评估优先级,确定工作量。我通常会多给项目留几天的时间,防止出现突发性事件。另外,留好测试时间。

2、设置项目里程碑、做好验收工作:在项目中设置节点,提前一两天做对应的项目验收。

3、经常性的沟通:项目进行中要经常的和团队沟通,鼓励大家的工作积极性,了解团队成员的工作进度和状态,了解潜在的风险并作出对应的解决方案。

4、奖罚制度:项目延期,要分析原因,设立奖惩制度。

 八、关注数据:

这是一个数据驱动的时代,做产品更是要以 “理” 服人,这个 “理” 就是数据支持。

1、推广运营数据:产品经理要关注运营数据,产品怎么优化对节省运营成本上要有自己的理解。产品运营数据如新增,活跃,流量分析,各渠道占比,及漏斗转化等,都是我们需要关注的对象。例如做了灰度发布后,我们看新老版本的产品表现,就要看运营的数据表现,不过这个要建立在数据大的情况下,数据很小的话,分析出的结果可能存在很大的偏差。

2、产品数据:这里我说的产品数据,是对用户行为分析的数据。例如在产品上做埋点,可以在产品上做出指导性的优化调整。

  九、多学习,多积累:

在这个浮躁的互联网氛围下,静下心来多看多想。网上的短文章,简报,终究还是比不上书籍。多看多思考,从而渐渐学会更好的思维方式,对大局观和逻辑架构有更清晰的条理。

本来只想对做 axure 炫技和把时间浪费在研究 axure 复杂函数上的产品经理做一点提醒,结果叨叨到想对自己翻白眼了。文笔粗糙,请谅解,欢迎大家交流。

(转载自网络)