如何看待手机内存 RAM 容量疯长甚至有隐隐超过电脑通用 8G 的趋势？ 第1页

谷歌那帮人懒呗, 你看谷歌雇佣的那帮人, 写出来的东西哪个是省油的灯? 你看我的电脑:

第一个studio64 就是 AndroidStudio 这个L J玩意儿. 同样都是开一个工程.比下面的devenv( VS2015) 大一倍.

而且编译工程 时,卡的一逼. cpu有几个核吃掉几个核. 结果占用这么多cpu, 编译时间还比VS2015慢N倍.

但是你看看谷歌的招聘新闻, 他们招的那帮人都号称是XX名牌大学, XX项目经历. Leetcode刷题上百.... 各种名号集于一身.

但是这帮张口算法.闭口优化的 吹牛B程序员. 写出来的东西.

你不给他配上i7,i9cpu 就卡死给你看.

你不给他配64G内存 就卡死给你看.

你不给他配最快的 SSD固态. 就卡死给你看.

哎...拿超高的工资. 装最牛的B. 写最卡的代码, 浪费全行业的资源....

有啥办法...

我平时是开发安卓平台小程序的.因为是和厂商合作. 因此开发内容经常要和安卓最底层framework结合. 也就是改内核.

就这几年的经历. 总结下来就是....安卓本质上真是个恶心到不行的半功能机系统.你稍微想做一点底层的东西.都需要各种绕道.各种技巧.途中你会遇到各种恶心的设计和构架.

时间长了 你会发现安卓系统的整体设计. 从来就不考虑模块的速度 和性价比. 就是怎么写代码写的爽怎么来. 效率和内存占用优化等方面它安卓根本不考虑.

(中间一段我删掉了.之前是我臭骂安卓Bitmap的565格式是每像素浪费4byte,但早上上班做了几个实验,发现565确实是2比优特每像素的,这个点我道歉,大概率是记错了,或者是极特殊情况是例外. 现在无法还原现场了.等再遇到了再改答案.

565,888这些格式的问题,其实是去年的事情,我又回忆了一下,当时是给一家超级穷逼的客户做手机美颜相机,机器配置是超级便宜的路边摊CPU: mt6580,和1G内存, 后来调试时发现内存极其紧张, 每次按下拍照按钮,底层传过来JPEG格式的照片, 我不得不再开一张Bitmap,将图片内容解压到Bitmap里,然后再传入OPENGL进行美颜处理. 而就是这么简单的操作, 安卓提示内存不足,然后相机闪退. 当时测试发现如果安卓的Bitmap能直接解压成RGB888格式,或者说直接通过GraphicsBuffer解压进Opengl的纹理中, 内存爆表就可以避免. 然而现实是可悲的.为了这种低端机,代码不知道改了多少套路,快气疯了.)

在实际工作中. 我经常要加载一张jpeg图片(JPEG默认解压出来RGB格式,不含Alpha通道)到Opengl里面, 为了节约一丁点内存, 我不得不先来个for循环, 把那笨蛋Bitmap图片 转化成 RGB888格式. 然后再调用opengl的加载语句glTextureImage2D,才能正确地加载RGB888格式的图片.

之后, 经过一系列opengl的操作,特效处理结束后, 我又需要把opengl的绘制结果 , 保存成jpeg. 我只能用"glReadpixel"语句来截屏.

扯到截屏,有两种操作, RGBA格式 和 BGRA格式, RGBA兼容性好,基本各个档次的GPU都支持.

但是,你用RGBA截屏出来的数据块儿, 你试试看直接用笨蛋Bitmap里面的compress函数压缩,你会得到:

而如果用BGRA模式截屏...有的手机GPU 却又不支持.截屏出来的结果很可能是一团黑色.因为驱动没写完.

我们的开发机大多是MTK的芯片,而MTK里的程序员压力也大 ,不可能OPENGLES2 和 3 的驱动都写的很完美.不常用的功能他们就偷懒不写了,因为写了也不会增加什么额外收益, 人家也要早点下班回家抱老婆不是吗?

所以总结一下我做美颜相机的处理步骤:

1. 用户按下拍照按钮,相机底层开始感光,生成照片.

2.笨蛋HAL2底层传来 压缩好的JPEG照片 (想传来未压缩的RAW照片?做梦!)

3.我花费1秒多把照片解压(只能解压成RGBX格式)

4.为了节约内存,RGBX格式简单压缩一下变成RGB格式. 节约25%内存.

5.送入OPENGL, 进行各种处理.

6.截屏,用RGBA格式.(BGRA格式截屏,兼容性不好)

7.RGBA格式图片 ,笨蛋Bitmap不能直接压缩,所以我需要再花大约1秒转化成BGRA格式.

8.笨蛋Bitmap终于可以压缩图片成JPEG了,最后存盘.

看看,恶心不恶心? 知道ARM CPU为啥那么累了吧? 一半的功劳要仰仗这位笨蛋Bitmap.

最后我干脆自己移植著名的 LibJpegTurbo库.这里顺便打一波广告. 这个库很好用, 压缩解压缩图片 功能齐全,速度又快.比恶心安卓给你们提供的功能强大一百倍!

(小提示, JPEG其实也可以储存RGBA图片, 你只要用 CMYK格式对着一张含alpha通道的图片进行操作就行了.实测没啥大问题)

再不用安卓那套傻了吧唧的 Bitmap系统了. 浪费内存又没效率. 写这个的懒蛋简直就是硅谷耻辱 .就这种水平也配写操作系统?

再说个例子, 我以前在写一个opengl小引擎, 需要绘制字体. 在windows上超级方便. 我下载Freetype字体SDK. 然后结合windows/fonts 文件夹下的ttf字体文件就ok了. 因为直接操作ttf文件可以得到一些字体的原始描边数据.我在opengl里可以用这些线段数据来构建字体模型.

可到了安卓系统里. 系统文件统统不能访问, 只读权限都没. 我就想问问,我访问个字体文件能获得个啥用户资料? 逼着我的apk里夹带几十兆的字体你就高兴了?你觉着访问权限有安全隐患, 可以采用映射等等一系列方法来规避吗?谷歌给你们安卓每年那么多投资,你们是不是都用来逛夜店和买冈本套套 了?总觉着套套上那些波纹回路都比你们脑白质上的沟纹深点.

所以安卓的设计水平,充其量和win98打个平手. 可人家win98装好就200M. 他安卓要5个G.

为啥? 处处都是重复文件. 全部没有共享.都在不停地浪费你宝贵的手机存储空间.你买个16G空间的手机. 一开机就发现安卓ROM占了12个G. 这很正常.

谷歌的程序员从来不考虑空间利用率. 按他们的屁话说法: 硬件永远不是问题, 考虑软件运行效率的程序员都是Loser. 未来多快的CPU 都有,多大的内存都有. 我就用最省事的算法写代码,写系统,到5点就下班泡妞去了, 至于你跑不动....那是你的问题.关我屁事?

呵呵. 所以我现在最大理想就是cpu的制程和电池的密度 50年内不要再革命性变化了. 只有硬件停止摩尔定律这种大跨步进步, 程序员才会停下来反省自己的烂代码, 才会淘汰掉一大堆只会写蠢代码的 吹逼狂.

这种吹逼狂挂在嘴边的一句就是: 你机器配置低,怪谁?

昨天有小白,质疑我的bitmap通道,他说什么: RGBA转化成BGRA 不就是转化一下通道吗?用C在NDK里,来一遍for循环不就好了吗? 你连查个资料都懒,有啥资格质疑我的安卓爸爸?

呵呵,我去年写内置相机程序时遇到的这个问题, 请问一张1300万像素的图片,美颜磨皮做一套. 最后截屏出来就要半秒. 你再来个for循环 把RGBA通道折腾一遍...不花时间的咯?

然后再调用bitmap内置的那套二百五的compress函数,压缩成jpeg, 最后一算,都8秒了,你拍一张自拍8秒能忍吗你?

最后我就完全舍弃bitmap了. 图片一律采用byte[]数组,压缩图片采用libjpegturbo,爽歪歪!!!

(小插曲:

说到opengles的截屏,当图片太大时,一次glReadpixel也是蛮浪费时间的, 所以我们研究了下如何能够直接访问opengl内部纹理数据的方法,后来查到有个GraphicsBuffer的东西,但这东西只能在framework里使用, 你的app里面的so无权限使用,于是我们费了大劲写了个能用GB的so,每次修改都要用adb push到手机的system/lib 下面. 结果安卓这苯蛋有时竟然出现这么个情况: 你push1个10M的东西到system/lib 里. adb 提示:空间不足! 然后你只能找下system/app 里某些不会被用到的内置app, 删掉它们,你自我感觉腾出来了50M空间. 这总够了吧? 再push一次,还是提示不够. 后来有同事提示:可能你需要重启手机, 然后 adb root remount ....一大堆命令再来一遍..

我的妈呀,都他妹的 9012年了. 安卓上干点啥都要重启. 这tm是win95 换壳吧? 人家win7 重装显卡驱动都不用重启了呀!!

就算是去路边洗脚店 玩大保健, 我中途想换个姿势, 安卓技师小妹你跟我说,需要我穿好裤子,从前门再进来一次,并再脱一次裤子?????

我是没刷过leetcode和eulerproject,也不会各种装逼式的语法糖... 可是...没想到这帮 浓眉大眼,刷题上千,年薪百万的连一个好用点的框架都写不出来. 整天逼着程序员 反复重启手机,反复噼噼啪啪敲打着那一堆可怜兮兮的命令行... 这..难道是今后50年的常态??? 真的是可悲.

人家搞金融的到了下午3点就下班 去抱妞了. 一帮程序员却 窝在办公室里噼噼啪啪敲键盘, 打着什么 adb root reboot remount ... install -r -t ????.apk , 世上还有比这还惨的事情吗?

)

(以前买过一个psp 2000, 毕竟是sony的扛把子! psp真是不错的设计, 开机时按住RB按钮,可以进入一个类似于PC的BIOS界面, 里面可以设置很多东西, 什么cpu频率啦, USB充电许可啦. wifi是否关闭啦... 这么好用的设计 安卓为啥没有? root模式我为啥不能在bios里永久设置一次? 必须每次重启都要adb root来一遍? 设计者你是不是手指头痒? 在家打飞机还没打够 来公司上班还要练练手速? )

现在还纠结的是 安卓框架没有开放出来底层硬件 RAW图片传输和 硬件jpeg压缩 这两个接口. 目前还在和台湾MTK工程师沟通中. 他们如果能开口子让我们app能用到这些功能,那么我们的相机就能快很多了.

给安卓这LJ玩意儿写代码,真是倒了八辈子霉了.接口恶心就恶心吧.赚钱也行. 可谷歌最近几年把能赚钱的接口全部封死了. 只能他自己加广告赚钱. 我们就只能给他白做. 所谓改一点底层就过不了他的所谓GSP认证.

今年最后一年了. 再不赚钱我们公司就转行业了. 不陪这LJ平台玩了.

挂个反动派.

我们公司拿到的方案公司的 mtk8.0 ,9.0 源代码,我同事研究过. bitmap底层也是用的libjpegturbo. 但我奇怪的是,经过安卓这么一包. 速度不仅变慢了.功能还变少了.1300万像素的一张图片, 用bitmap来压缩,我印象中是3秒.(在我的开发机 MT6750 cpu的机器上)而用我的自己的jpeg-turbo库,2秒不到.大约是1:2的关系. 同理解压时间也类似.

这个反动派强行为安卓站台, 让我把jpeg用Bitmap的口子解压出来,成RGBX的格式(X表示安卓为了4byte对齐浪费1字节),然后再写一堆neon指令代码, 我跟你们说neon指令写起来很恶心的,但是你写了又怎样呢. 同样的时间,我的so 都解压两次了呵呵.

而且jpeg-turbo库, 支持直接解压成gray,rgb565,rgb888,rgba8888(通过CMYK实现),既然这么强大了.我还要bitmap这鸡肋干啥?每日使用打卡 攒积分?

这种反动派,就是典型的经验太少. 极限情况没遇到过. 而且整个思维局限在安卓给的垃圾框架内不能自拔,任何人,只要说安卓不好.他就跳脚.

Bitmap在NDK里的定义里:

       typedef struct {     uint32_t    width;     uint32_t    height;     uint32_t    stride;     int32_t     format;     uint32_t    flags;      // 0 for now } AndroidBitmapInfo;     

这货就从没见过stride 比 width *pixelsize 大好几百的情况. 而这种情况,但凡是个经常用so处理bmp图片的程序员,都是经常遇到的.自己掰吃还叽叽歪歪. 现在大家知道自己的安卓机器为啥明明很卡,但是很多安卓程序员却死活不承认安卓有问题了吧?

明明是安卓的效率低质量差,非要说是用户的钱包有问题.

你穷逼,买不起顶配安卓机.所以你不配说安卓垃圾.

你不会用VIM + NEON,所以你垃圾.不配说安卓效率底下.

我就不知道这帮人为啥会这么积极主动地维护安卓这垃圾框架, 真不愧是1粉顶10黑啊.

初中时老师就说过,尽信书不如无书,一点质疑精神都不敢有,可真是党的三好学生. 当5道杠大队长的料.

从这人的回复可以看出，他只会命令行加几句可怜兮兮的neon指令集，对gpu的shader编程屁也不懂，

这种人我是不会拉黑他的，狗咬人人不能咬狗，我倒是要看看他每天能放啥味儿的屁。当个兽医程序员好辛苦啊，哈哈。