本文共 2112 字,大约阅读时间需要 7 分钟。
晚上,实在是无聊的蛋痛,就用自己的APK查看了一下手机中所有应用软件的信息,忽然看到一个APK,
/system/priv-app/ApeTaleEditor/ApeTaleEditor.apk: 63M
此APK有63M,这明显是不正常的,是此APK太大了,我比较了手机中的191个APK应用,APK大小超过60M的就二个应用,一个此应用,还有一个是谷歌的Chrome应用。
/system/app/Chrome/Chrome.apk: 68M
其它的应用绝大部分不超过10M,而我们的手机是低端机的入门机器,一个60多M的应用,明显是不正常,应该是需要优化的。
我就将此问题反馈给SPM,定位到此应用为我们公司自己开发的回忆相册应用。那好了,SPM就更简单粗暴了,要求直接去了此应用,原因是此应用占用了大量的空间,并且有性能上的问题。但是,商务和开发当然是不同意删除此应用。于是,在群里开始了一轮大公司常见的扯蛋秀了。
犯贱的我,在群里说了一下自己的观点:
其实这个APK,问题的关键还是优化APK大小,60多M肯定是太大了
这一下,摸了老虎的屁股了,立刻就有一位高人回复:
里面都是第三方提供的素材,怎么优化,搞笑吧?
我吧,偏不信邪,一个APK大小当然是可以优化的,我就百度了一下APK大小优化,将此搜索到的结果截图发了一下,并回复:
APK大小优化,不是搞笑
此位高人立刻回复:
里面都是必须的素材,删除掉就不能正常使用,怎么优化?APK大小优化不是只有你知道
然后屏蔽了此群的信息。
我回复了:
哎........................................................
表示对此位高级工程师的无奈和无语。
优化APK的大小方法许多,怎么一定要删除这些必须的素材呢?
于是对此所谓的高级工程师的工作态度,工作能力,责任心都是满满的大问号。
没有办法,许多时候,工作就是一帮队友窝里斗。
我定位到此应用,解压此APK,看了一下此APK,谈谈自己的优化想法:
优化的核心一定是优化占用空间的资源。
查看了一下此库文件,有二个目录:arm64-v8a,armeabi-v7a。arm64-v8a目录下的库文件有6M,armeabi-v7a目录下的库文件有5M。而我们只是32位的项目,也就是将库文件对应平台来发布就可以节省6M的APK大小。
网上有一些优化方式,个人觉得对此做的最好的,也是最权威的,应该是谷歌的APK应用。他们优化的方式就是对应分辨率的应用只提供对应的资源。这个优化,往往可以将APK优化为现在几分之一。
哈哈,谷歌,你牛,你是我们的亲哥。
下面给了一个谷歌的样例,就是参考google的GMS包中的Duo应用:
Android.mk
################################################################################ DuoLOCAL_PATH := $(call my-dir)my_archs := arm arm64 x86my_src_arch := $(call get-prebuilt-src-arch, $(my_archs))include $(CLEAR_VARS)LOCAL_MODULE := DuoLOCAL_MODULE_CLASS := APPSLOCAL_MODULE_TAGS := optionalLOCAL_BUILT_MODULE_STEM := package.apkLOCAL_MODULE_SUFFIX := $(COMMON_ANDROID_PACKAGE_SUFFIX)#LOCAL_PRIVILEGED_MODULE :=LOCAL_CERTIFICATE := PRESIGNED#LOCAL_OVERRIDES_PACKAGES :=LOCAL_DPI_VARIANTS := xxxhdpi xxhdpi xhdpi hdpi mdpiLOCAL_DPI_FILE_STEM := $(LOCAL_MODULE)_$(my_src_arch)_%.apkLOCAL_SRC_FILES := $(LOCAL_MODULE)_$(my_src_arch).apk#LOCAL_REQUIRED_MODULES :=LOCAL_MODULE_TARGET_ARCH := $(my_src_arch)include $(BUILD_PREBUILT)
此方法可以总结为一句话:
分别针对不同的分辨率和不同的平台提供对应的APK应用,尽量减少不需要的占用空间的资源。
1.Android apk大小优化之自我实践
2.Android产品研发(四)–>减小Apk大小