tianshangyu333的专栏

在Android APP的实现中，经常看到 一些信息的提示，比如在微信的未读条数，信息的未读条数。其中信息的未读条数，一般在Launcher的WorkSpace主界面上，会在SMS/MMS图标上显示一个未读数量的图标。关于SMS/MMS未读短信的条数，可以通过Resovler查询sms/mms数据库得到，本文模拟一个在contacts图标上叠加一个未读图标的实现。代码很简单，大

在TEE环境下,o可能由于安全问题,无法使用htobe64函数,所以使用另一种方式来完成这个函数的转换功能:#include #include #include #include #include #include #include #include using namespace std;static uint32_t convert_x(uint

最近写c库时,发现需要对unit64_t  size_t   uint32_t这几个类型进行打印,总结一下:#include #include #include int main(){    size_t i = 1;    uint32_t j = 2;    uint64_t k = 3;    printf("i: [%zu]\n",i);  

最近在ubuntu上使用Android SDK新建模拟器时,发现会提示:[2016-03-22 10:56:20 - SDK Manager] Failed to create the SD card.[2016-03-22 10:56:20 - SDK Manager] Failed to create sdcard in the AVD folder.以前也遇到了这个错误,没有记录

在Android开发中，内存泄漏是比较常见的问题，有过一些Android编程经历的童鞋应该都遇到过，但为什么会出现内存泄漏呢?内存泄漏又有什么影响呢?     在Android程序开发中，当一个对象已经不需要再使用了，本该被回收时，而另外一个正在使用的对象持有它的引用从而导致它不能被回收，这就导致本该被回收的对象不能被回收而停留在堆内存中，内存泄漏就产生

private void initEditText() {        addTextChangedListener(new TextWatcher() {            @Override            public void beforeTextChanged(CharSequence s, int start, int before,

DrawAllocation 避免在draw和layout的时候创建对象，频繁的调用，垃圾回收操作会影响一些UI的体验Avoid object allocations during draw/layout operations (preallocate and reuse instead)Issue: Looks for memory allocations within dr

在做一个项目时，出现问题，就是provider端数据库会不断的有数据更新， 而我们会有 应用APP注册Observer，监听数据库的变化，然后更新界面。在界面中就包含了ImageView,每监听到一次数据库的改变，app就会重新查询，更新头像。数据库的循环插入速度很快，那么ImageView的更新速度也就很快，自然也就出现了闪烁的现象。在网上也查看了一些方法，并不是很有效。

关于Android4.4的图片路径获取，如果回来的Uri的格式有两种[java] view plaincopycontent://com.android.providers.media.documents/document/image:3951  [java] view plaincopy

当ScrollView嵌套ListView时，使用listview设置setAdpter后，需要重新设置listview控件的宽高。在网上尝试了一些方法，重新设置高度之后，仍然不能完全显示，经过调试，使用下面的方法，可以使ListView完全显示。在setAdapter后,使用UtilityHelper .setListViewHeightBasedOnChildren(listview)调用。

最近在调试5.1的代码的时候，调试phone相关的设置部分时，发现CallFeaturesSetting的返回键设置为：     dialog.getActionBar().setDisplayHomeAsUpEnabled(false);设置为true之后：      dialog.getActionBar().setDisplayHomeAsUpEnabled(true);还是

import android.app.admin.DevicePolicyManager;DevicePolicyManager mDPM = (DevicePolicyManager) mContext.getSystemService(Context.DEVICE_POLICY_SERVICE);mDPM.lockNow();

The GCC manual says using "asm volatile" prevents the asm instruction from being "moved significantly" and adding "memory" to the clobber list prevents GCC from keeping memory values cached in