Could not find gdb.setup under ./libs/armeabi

运行ndk-gdb出现了下面的错误,

Could not find gdb.setup under ./libs/armeabi
This usually means you modified your AndroidManifest.xml to set
the android:debuggable flag to ‘true’ but did not rebuild the
native binaries. Please call ‘ndk-build’ to do so,
*then* re-install to the device!

原来是因为我在jni目录下运行的ndk-build命令, 而不是在项目的根目录下, 可能在jni下运行的话可能根本没有办法检测到根目录下的AndroidManifest.xml里的android:debuggable=”true” (只是猜测)

连不上mysql, can’t connect to mysql

明明已经grant all on *.* to xx@’%’ identified by ‘xxx’;了, 而且还运行了flush privileges;
可用Mysql Workbench就是连不上mysql,

折腾了半天,发现原来新装的centos的防火墙是打开的, 对mysql端口3306没有开放, 只要把这个端口打开就连上了

Capture

AsyncTask并不是多线程异步执行多任务

关于AsyncTask, 我想大家可能会有些误解, 这其中也包括我自己, 一度被这个问题调试了好久, 开始以为是DefaultHttpClient不能同时发多个request, 这主要是因为还有个AsyncHttpClient, 这个一直让我觉得DefaultHttpClient不是异步的

从字面上来看AsyncTask它是一个多线程异步执行的任务, 但实际上不完全是这样的

例如 我如果像下面这样连续创建5个AsyncTask,  它实际上是一个接着一个连续执行的, 并不会异步多线程同时执行

for (int i = 1; i <= 5; i++) {

Log.d(DEBUG_TAG, “for : ” + i);

String url = “http://baidu.com?i=” + i;

new DownloadWebpageTask(url).execute();

}

为什么呢, 我们可以从官方文档里找到原因: Order of execution

When first introduced, AsyncTasks were executed serially on a single background thread. Starting with DONUT, this was changed to a pool of threads allowing multiple tasks to operate in parallel. Starting with HONEYCOMB, tasks are executed on a single thread to avoid common application errors caused by parallel execution.

也就是说现在所有的AsyncTask都只在一个线程里执行, 一个执行完了再执行另外一个

如果要多个AsyncTask在多个线程里异步执行, 我们可以这样做:

private static ExecutorService LIMITED_TASK_EXECUTOR = (ExecutorService) Executors.newFixedThreadPool(THREAD_NUMBER);

new DownloadWebpageTask(url).executeOnExecutor(LIMITED_TASK_EXECUTOR);

LruCache为什么需要保存到RetainFragment, why need RetainFragment?

看了android 文档里的bitmapfun例子, 一开始怎么都不明白为什么需要把LruCache放到fragment里面, 后来再仔细回头看了看文档:

Runtime configuration changes, such as a screen orientation change, cause Android to destroy and restart the running activity with the new configuration (For more information about this behavior, see Handling Runtime Changes). You want to avoid having to process all your images again so the user has a smooth and fast experience when a configuration change occurs.

Luckily, you have a nice memory cache of bitmaps that you built in the Use a Memory Cache section. This cache can be passed through to the new activity instance using a Fragment which is preserved by callingsetRetainInstance(true)). After the activity has been recreated, this retained Fragment is reattached and you gain access to the existing cache object, allowing images to be quickly fetched and re-populated into theImageView objects.

 

原来当手机横竖屏变化时, activity会被销毁再创建,为了不丢失LruCache, 所以通过setRetainInstance(true), 保存了cache里的数据, 我就更疑惑了, 为什么不把LruCache设置成全局静态变量, 这样不是程序所有地方都可以共享地用到cache了吗