安装包越攒越大，下载那一步就会悄悄走掉一批人
新版本推出去，看后台发现从点下下载到装成之间少了一截人，比上一版明显。问了一圈才想起这半年往包里塞了不少东西，谁加的时候都觉得不大，合起来就让人在进度条那儿等不住了。一、先称一称包里都装了什么
把包拆开按来历分量：自己写的代码占多少、图片和音视资源占多少、引来的三方库占多少，各列一行。不称这一下，讨论减体积就只剩一句别装那么多，谁也不知道该从哪头下手。老包收掉之前给归属团队发一句问询，有的那一路其实还有人在用，只是量小不显眼，问过再动不至于把人断在半路。
称完标出近几版涨得快的那几行。多数时候包不是均匀变胖，是某一版顺手带进来一整套用不上的资源，往后每版都照搬，找出来收掉一次，后面几版都跟着轻。拆包称量这件事排进谁的一周里要写清，不然谁都觉得顺手能做，末了谁也没做，数字仍旧一路慢慢往上走。
二、大资源改成用到再取
首装不必把往后会用到的图、示例、离线材料全带上。先把主流程要用的装齐，其余等走到那一步再取，装的人当下少等一截，用不到的人干脆不必花那份流量。季度盘点把各版体积和问过来的条数并排看，涨得快说明带进来的东西多，问得多说明哪处没交代清，两样凑一起才有方向。
按需取也要想好取不到的时候怎么显示，别让页面空着一块或者一直转圈。留个能看懂的占位和一句再试一次的入口，取失败这件小事才不会变成用户以为功能坏掉了。给大资源的取用留一份带宽预算，别等慢的那些天有人集中问过来，才临时去算这一块到底吃掉了多少。
三、同一用途的库合成一份
几个团队各引一套做同一件事的库，打进包里就是几份。合的时候先对一下版本和用法，确认没有哪一处还依着旧行为，再统一到一份上，减下来的常常不止一处体积。归档目录按版本类型分开，找的人想的是那一版属于大改还是小补，不是文件存在哪个文件夹，顺着念头排才找得快。
合完别急着收工，把各团队走过的主流程各点一遍。库换了版本，个别边界上的表现会变，这种变化不报错、也不在包体数字里显出来，只有真走过那条路才看得见。几处团队都要引新东西的时候，碰一次头比各自加完再回头合省事，会上把用途说清，常常发现本来就是同一件事。
四、每次合入记一笔体积变化
打包时顺手把这一版比上一版多了多少、哪一行多出来的记成一条。谁把包撑大的、为什么撑大，一眼能对上，不用过三个月翻提交记录一行行猜那是哪次加的。
涨得特别多的那笔自动标出来提醒一下，多数是正常的大功能，也有几回是把调试用的整包素材一起带进来了。提醒不拦人，只是让带进来的人当场再看一眼。每版多出来的那点体积由谁记归档，定一个名字就行，没名字的记录过两个月就没人认得是谁顺手写的那一行。
五、定个提醒线别一刀切
体积定一个数当提醒是好的，但别拿它卡死所有版本。大版本多带些东西说得过去，小修小补还一路涨就该问一句；按版本类型分开看，比一个数管到底更贴合实际。
看数的时候也按网络环境分档。同一份包在无线网下几十秒的事，在慢一些的网上就是几分钟，掉人的往往正是那一档，加总里被前一半的顺利盖了过去。和业务方沟通时把慢网下的等待也讲明白，先应下再解释反而被动，对方早把预期摆好，两边都不必在群里追着问。
六、老版本也要能继续取到
减体积别减到把还在用的老包下掉。有人手里的机型装不了新版，有人正卡在半路需要退回去，取不到就只能找客服要，几句话能说清的事变成一整趟人工。
留哪些老包按装机数定，量还在的留着，长期没人取的分批收。收之前在对应表里改个状态，让人查的时候知道是刻意收了，不是哪台机器上的文件悄悄不见了。提醒线定在多少留一页说明，写清当时照的是哪几档机型，来年机型换了，照着缘由调比拍一个新数稳妥。
下载那一步掉人，看着像是用户没耐心，其实是包里攒了太多没人回头看的东西。称清楚、按需取、合并同用途、逐笔记账、分档看、留老包，六件事围着「装得动」转，进度条才不用替人扛账。 楼主态度很认真，回复也很耐心，这样的楼主值得大家支持。 非常有建设性的意见，对解决实际问题有很大的参考意义。
说得很有道理，很多观点都说到点子上了，希望以后能多看到这类帖子。 看完之后深有感触，有些话真的说到心坎里了，很有共鸣。 没想到还有这么多细节，之前一直没注意到，感谢楼主提醒和科普。
页:
[1]