博客

java虚拟机运行一般都有一个内存界限，超过这个界限，就会报outofmemory。这个时候一般都是存在内存泄漏。解决内存泄漏问题，窃以为分为两个步骤：分析应用程序是否真的有内存泄漏，找到内存泄漏的地方。这两个步骤都不是一般意义上的调试，直接打log，断点调试都不是太给力。动脑筋想一想，内存问题应该在很多地方上都会出现，这么常见的问题应该是有工具的。android现在更可以说是一个生态系统，当然也

啰嗦下：发现自己的blog被转载了，不过没有注明出处，有点痛并快乐着的感觉。这里正式申明下：转载请注明出处，感谢。如有商用目的请务必知会本人。         在android上工作不少时间，很多工作都是在解bug上。大多数情况下，debug总是要用到log，系统自带的或者自己添加的。在有的应用的某些功能上，android自带的log基本足够了，这个时候只要打开log开关就行。一般应用的l

啰嗦下：发现自己的blog被转载了，不过没有注明出处，有点痛并快乐着的感觉。这里正式申明下：转载请注明出处，感谢。如有商用目的请务必知会本人。          目前从http://developer.android.com/sdk/index.html下载的android集成开发工具已经为我们配好了本地开发的基本环境。安装完这个环境，配好了环境变量使得命令行能正常执行android提供的

工作内容集中到Contact模块，这个应用查询数据的地方很多，其使用了CursorLoader这个工具大大简化了代码复杂度。android自3.0提供了Loader机制，当时google的API只是简单的介绍了一下没有给出用法，大家很少有关注。后来因为重度模型下的性能优化，R&D的朋友发现这个东西非常给力，这才开始注意到这个强大的工具。CursorLoader是Loader的子类，可以说是Load

在android开发中，为了UI线程能及时响应需要避免在其中执行耗时操作，以防止界面假死甚至ANR。我们一般把耗时操作如下载，查询放在一个单独的线程中。这之后再将结果更新到UI界面。android平台在非UI线程中更新界面大致有以下几种方式：Activity.runOnUiThread(Runnable)View.post(Runnable)AsyncTaskHandler.pos

上一次周例会上，有关专家介绍了一下android5.0的一些新特性。其中一个是主色提取，按照产品经理的意思，下一期需求上我们最好能加上这个特性。于是乎，我们就开始研究一下这个新特性了。这个是放在support包里面的新增接口，也就是说这个接口和android版本无关。看来源码也不会太大。:-)        先看一下google官方说明。https://developer.android.co

android4.4对短信引入了一个全新的概念：默认短信应用。即android用户可以在系统设置里面选择一个默认的短信应用，只有这个应用才能进行手机的基本短信操作。按照google自己的解释这样做的原因是因为很多第三方的APP使用了一些隐藏的API接口，应该是反射调用把，既然是反射调用的非常规接口，因此这些接口就并不会有兼容性即CTS测试，也就不能保证稳定可靠。个人看来，目前市场上第三方短信应用太

先说两句题外话，很感谢android，在这里能看到很多优秀的代码。同时也感觉到外面的工程师真的很厉害，都是java人家就能写出这么牛的东西。感慨之下就有了些思考：我们绝大多数人只要把那些牛人已经创造出来的牛逼的东西，记住并且弄懂就是一件非常不错的事情，至少能衣食无忧。:-D 读书的时候需要经常做题，在理解的基础上记住解题方法基本就能很牛了，事实上高考中考绝大多数都是已经有过的题型，能做到前面所说的

发现自己的手机上某个界面出现了花屏，某些控件背景被拉伸过多遮住了其他控件，很难看。这种现象高概率出现，分析了下发现：一旦发生这种现象，必然会打印下面这种log，google了下，这种log应该是硬件加速引入的。在从view层级关闭了硬件加速开关之后，问题没有再出现。D/OpenGLRenderer(10887): GL error from OpenGLRenderer: 0x501E/O

什么是号码匹配，个人理解，即判断两组号码是否属于同一个号码。在实际使用过程中，接触到的号码会涉及到区号，国家编码以及IP号码等，这个时候就用到了号码匹配。两个内容不一样的号码，如+86***和17951***，是不是同一个号码。就需要软件判断是否同一个号码。手机里面涉及号码匹配的场景很多，打电话发短信都要用到。和前面的+86***和17951***两个号码所示，号码匹配是从后往前进行比较的，可以猜