跳至内容小超的漏雨茅屋身正不怕影子斜菜单和挂件WELCOME本人来自中国广西，2011年毕业于西安电子科技大学，现居住在新西兰  用以下邮箱与我联系E-mail: TagsAndroidApachearchlinuxbashC++crontabdddebiandebugdriverelggfedoraffmpeggrubjavascriptjsKDEkernelLinuxlooplupaworldmini2440mini6410mmapnginxopensourcepasswdPHPphp-cgiplasmaqtRewriteshellUbuntuwindowswxWidgets同学学习数学物理方程用户管理硬盘安装笔记编程西电金工实习分类目录AndroidC++FeelingsFFmpegJust talkLinuxMathPHPQSaxTranslatorQTScience&TechnologyWebWebKitwxWidgets嵌入式开发服务器未分类生活琐事生活随拍文章归档2014年十一月2013年一月2012年三月2011年十一月2011年七月2011年六月2011年五月2011年三月2011年一月2010年十二月2010年十一月2010年九月2010年七月2010年五月2010年三月2010年二月2010年一月2009年十二月2009年十一月2009年十月2009年九月2009年八月2009年七月2009年六月2009年五月2009年四月2009年三月2009年二月2009年一月2008年十二月2008年十一月来自Google的广告Android中对推送服务的优化考虑在“国内安卓手机都没有Google Play Services”这个预设下想仍然要完成推送的任务，可以有一些优化的考虑：1. 以单独的进程来监听推送服务。这个可能会有争议，待会说说争议的原因。单独的进程有一个好处，你App的UI进程一旦进入后台，由于没有任何服务在运行，安卓可以随时轻易地干掉你的App然后回收大量内存（安卓会缓存你加载的位图等资源，所以你会发现在后台运行没有被杀掉的App重新呼会前台会很快），而你的推送服务进程由于没有加载任何的UI资源，其内存使用其实一直都是在很低的水平。反之如果你在主进程里实现推送服务，那么你的App不是最高优先级被杀的，因为UI缓存的缘故你的App可能一直占用很大内存。这里有可能有人会说这是在优化内存，不是在优化电量。我的看法是你的主动优化内存，应该可以减轻系统在内存紧张时对其它App都来一次GC和Low Memory通知的消耗（无证据，纯粹程序员第六感）。也有人希望自己的App再次运行的时候能快一点也能省电力，所以留在内存更好，甚至有人专门为这个优化而耍花招，我认为这是个流氓行径。安卓的内存使用方案一向是前台优先，要是每个后台App都想自己下次快点而死赖在那岂不是乱套了。扯远了。2. 为了实现第1点的效果，就不能在App.onCreate里做太多事情，甚至压根不要做什么事情，这样即使被broadcast唤醒（例如你的推送进程把消息通知你）、推送进程被重启，也不会产生额外的初始化消耗。这就是谷歌在文档里说，如果要用Singleton设计模式，推荐使用Lazy initialisation而不要在App.onCreate创建静态对象的原因。3. 统一化推送。统一所有App显然比较不现实，但是一个公司的产品，统一一下推送应该不难吧（说的就是你们BAT）？大家都把推送的代码打到每一个产品里，哪个产品先运行了，就启动单例的服务来进行推送。说到这个也开开脑洞，为啥腾讯不在微信上做一个开发者开放平台，可以让应用接入腾讯的推送服务呢？想几乎每台中国的安卓手机都装了QQ或者微信，造福一下人类还是不错的嘛。4. 优化推送的策略。例如根据网络类型、时间间隔来推送。在移动网络下一直保持着长连接来监听服务器就是个流氓，除非你是即使消息型的应用，这种应用不多吧？没事就像知乎一样推送个消息，完全可以半小时、半天甚至一天连接一次服务器检查一次啊，我想还没有哪个产品经理拍个脑袋说，啊哈，我们的广告推送要精确到秒吧？（啥？你公司的产品就是这样？）切换到WIFI时，自然可以采取一些间隔更短的策略，同理，用户锁屏、开屏的时候多长都可以作为优化的切入点，甚至可以由本条推送消息的内容决定下条推送消息的检查时间……暂时只能想到这么多了。上班的时候跟同事说，“你要用谷歌服务的推送，要考虑一下那些没有装谷歌市场的手机啊”，他一脸不懈地说，“我从没见过没有谷歌市场的手机”。心里万只草泥马飞过，这世界上99%的安卓手机都没有谷歌服务好吧？！难道我们没生活在一个世界？VN:F [1.9.22_1171]please wait...Rating: 0.0/10 (0 votes cast)VN:F [1.9.22_1171]Rating: 0 (from 0 votes)发布于 2014年11月20日作者 Fanchao分类 Android标签 Android、优化、推送于Android中对推送服务的优化考虑留下评论Android和iOS内存机制的比较这个应该是个java和objC的比较：Java里内存的回收是由JVM虚拟机控制的，啥时候回收由JVM决定。这样做程序员基本上不需要关心内存的泄漏(注意我用的是“基本”)和非法访问了。回收的过程就是GC，GC会暂停整个程序的运行，深入内存分配树去寻找垃圾，然后释放掉。正是由于这棵树的存在，循环引用不再是个问题。稍后会说循环引用。objC采用引用计数来管理内存。一个对象引用一次+1，解引用-1，当计数降为0就立即释放内存。其实这也不是objc的专利了，这是一种很普遍的模式吧。引用计数有个缺点，无法解开循环引用。设想对象A引用B, B引用A，两个对象计数都不为零，结果无法回收A和B，于是内存泄漏掉了。Java用树描绘了对象间的引用关系。GC的任务就是把图中没有任何引用的对象B们找出来，删掉。什么算法？似乎跟不同的实现有关，我也没深入研究。在树的结构下，如果A和B发生了循环引用，那么无所谓，反正他们与树没有关系，GC的时候他们一起被释放掉。其实所有引用关系最终都能成为“树”，但是侧重点不一样，JVM依赖树的结构来寻找垃圾，而objC则只关心引用计数，“树”只是个附产品。（顺便插一局，在Java中，所有的static变量都是根，如果你不小心跟静态变量发生强引用关系，那么你就等着内存泄漏吧，所以文章开头说“基本”）在objC引用计数下，可以使用弱引用来打破一方对另一方的“强”引用，于是只有A对B或者B对A的引用，反过来是没有的（在弱引用的时候总是检查指针是否为空，才能访问）。这个就不详说了。说这么多，就是想给下面结论做个铺垫：JVM：优点：程序猿不需要太关心这种循环引用导致的内存泄露，减轻了负担（否则循环引用很容易就写出来了）缺点：1. 很难控制内存的释放时机，大的内存分配往往需要等待GC才能进行2. GC就是个猛兽，所有线程都要暂停以便GC。有时GC甚至有几十毫秒——足以让UI（特别是动画）卡出翔，这也是Android卡顿的原因之一objC/引用计数:优点：内存释放及时、平滑，时机可控缺点