双卡双待手机[海信]挂断回电...- AMS起步进程过程~(转) - lbs中从库中查询某中纬度2KM范围内的数据

当前位置: 编程技术>移动开发

本页文章导读:

▪双卡双待手机[海信]挂断回电和指定卡去电实现双卡双待手机[海信]挂断来电和指定卡去电实现海双卡双待手机[海信]挂断来电和指定卡去电实现的技术调研信双卡手机拨打电话时,在启动拨打电话时,传递一个参数给系统,这样系统的可.........

▪ AMS起步进程过程~(转) AMS启动进程过程~(转) Instrumentation.callActivityOnCreate(Activity, Bundle) line: 1047 ActivityThread.performLaunchActivity(ActivityThread$ActivityRecord, Intent) line: 2459 ActivityThread.handleLaunchActivity(ActivityThread$Activ.........

▪ lbs中从库中查询某中纬度2KM范围内的数据 lbs中从库中查询某经纬度2KM范围内的数据 sql语句查询经纬度范围指定一个经纬度，给定一个范围值(单位:千米)，查出在经纬度周围这个范围内的数据。经度:113.914619 纬度:22.50128 范围:2k.........

[1]双卡双待手机[海信]挂断回电和指定卡去电实现

来源: 互联网发布时间: 2014-02-18

双卡双待手机[海信]挂断来电和指定卡去电实现
海双卡双待手机[海信]挂断来电和指定卡去电实现的技术调研信双卡手机拨打电话时,在启动拨打电话时,传递一个参数给系统,这样系统的可以根据该参数判断使用指定的卡:

 Intent i = new Intent();
 i.setAction(Intent.ACTION_CALL);
 i.setData(Uri.parse("tel:" + address));
 i.putExtra("subscription", type);// subscription 是名称,不可改变. type :1为gsm卡|0为电信卡
 i.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
 context.startActivity(i);

海信手机在挂断电话时,使用反射方法,获取endcall(int) 参数来挂断电话,

 try {
                TelephonyManager mTelephyMgr = (TelephonyManager)mContext.getSystemService(Context.TELEPHONY_SERVICE);
                Method getITelephonyMethod = mTelephyMgr.getClass().getDeclaredMethod("getITelephonyMSim");
                getITelephonyMethod.setAccessible(true);
                Object objITelephonyMSim = getITelephonyMethod.invoke(mTelephyMgr);
                Method intEndCall = objITelephonyMSim.getClass().getMethod("endCall", int.class);
                intEndCall.invoke(objITelephonyMSim, 1);//可挂断主/副卡来电(挂断当前来电)    
//              intEndCall.invoke(objITelephonyMSim, 0);//只能挂断副卡来电
                AVLog.d("block", "block the incoming call");
            } catch (Exception e) {
                e.printStackTrace();
            }

上面代码中之所以没有将注视的代码去掉是因为,经测试当endcall方法参数为1时,可以挂断主卡和副卡来电,参数为0时,只能挂断副卡来电.那么

intEndCall.invoke(objITelephonyMSim, 1);

以上一句话就是可以挂断两个卡的来电了. 移植项目中测试发现.打进电话测试: 广播接收到"android.intent.action.PHONE_STATE"这个action ,监听到此广播,再判断来电状态

TelephonyManager tm = (TelephonyManager) context.getSystemService(Service.TELEPHONY_SERVICE);
int callState = tm.getCallState();//获取来电时状态

主卡来电时,上面代码通过,但是在副卡来电获取callState状态时,callState状态是0(PHONE_IDLE =0 电话挂断状态,PHONE_RINGRING = 1是响铃状态).那么继续猜测,副卡来电时,android系统的api方法getCallState()是不能获取副卡的来电状态的,这需要使用反射方法获取主卡和副卡的状态,只要有来电,一定有一个卡的callstate是PHONE_RINGRING状态,代码如下

        Method getITelephonyMethod = mTelephyMgr.getClass().getDeclaredMethod("getITelephonyMSim");
        getITelephonyMethod.setAccessible(true);
        Object objITelephonyMSim = getITelephonyMethod.invoke(mTelephyMgr);
        Method intEndCall = objITelephonyMSim.getClass().getMethod("getCallState", int.class);
        int state1 = (Integer) intEndCall.invoke(objITelephonyMSim, 0);//主卡状态
        int state2 = (Integer)intEndCall.invoke(objITelephonyMSim, 1);//副卡状态
        if (state1 == 1 || state2 ==1) {
        //来电话了,执行拒接逻辑
        }

[2] AMS起步进程过程~(转)

来源: 互联网发布时间: 2014-02-18

AMS启动进程过程~(转)

Instrumentation.callActivityOnCreate(Activity, Bundle) line: 1047
ActivityThread.performLaunchActivity(ActivityThread$ActivityRecord, Intent) line: 2459
ActivityThread.handleLaunchActivity(ActivityThread$ActivityRecord, Intent) line: 2512
ActivityThread.access$2200(ActivityThread, ActivityThread$ActivityRecord, Intent) line: 119
ActivityThread$H.handleMessage(Message) line: 1863
ActivityThread$H(Handler).dispatchMessage(Message) line: 99
Looper.loop() line: 123
ActivityThread.main(String[]) line: 4363
Method.invokeNative(Object, Object[], Class, Class[], Class, int, boolean) line: not available [native method]
Method.invoke(Object, Object...) line: 521
ZygoteInit$MethodAndArgsCaller.run() line: 860
ZygoteInit.main(String[]) line: 618
NativeStart.main(String[]) line: not available [native method]

Dalvik_dalvik_system_Zygote_fork()@dalvik/vm/native/dalvik_system_Zygote.c
Dalvik_dalvik_system_Zygote_forkAndSpecialize()@dalvik/vm/native/dalvik_system_Zygote.c
Dalvik_dalvik_system_Zygote_forkSystemServer()@dalvik/vm/native/dalvik_system_Zygote.c
const DalvikNativeMethod dvm_dalvik_system_Zygote[] = {
{ "fork",            "()I",
Dalvik_dalvik_system_Zygote_fork },
{ "forkAndSpecialize",            "(II[II[[I)I",
Dalvik_dalvik_system_Zygote_forkAndSpecialize },
{ "forkSystemServer",            "(II[II[[I)I",
Dalvik_dalvik_system_Zygote_forkSystemServer },
{ NULL, NULL, NULL },
};

Android Application

Android提供给开发程序员的概念空间中Application只是一个松散的表征概念，没有多少实质上的表征。在Android实际空间中看不到实际意义上的应用程序的概念,即使有一个叫Application的类，这个也就是个应用程序上下文状态，是一个极度弱化的概念。Application只是一个空间范畴的概念，Application就是Activity，Service之类的组件上下文描述。Application并不是Android 的核心概念，而Activity才是Android的核心概念。

从Android的SDK文档中，我们知道一般情况Android应用程序是由以下四种组件构造而成的：Activity，Broadcast Intent Receiver，服务（Service），内容提供器（Content Provider）。我们可以使用下面的图来表示一下Android的概念空间。这些组件依附于应用程序中，应用程序并不会一开始就建立起来，而是在这些组件建立起来后，需要运行时，才开始建立应用程序对象。

2.1应用进程名称

为什么要从应用进程名称开始？作为内核研究，我们还是回到问题的最本质处：不管Activity，Service等组件如何设计和运行，它要提供服务，就必须要依附在Linux的进程上，建立消息循环，组件才能够真正的运作。Activity实例是如何Hosting在Linux进程上的？这个是我们首先想要弄明白的。

我们在的process="string"这个定义。

allowClearUserData=["true" | "false"]
android:allowTaskReparenting=["true" | "false"]
android:backupAgent="string"
…

android:label="string resource"
android:manageSpaceActivity="string"
android:name="string"
android:permission="string"
android:persistent=["true" | "false"]
android:process="string"
android:restoreAnyVersion=["true" | "false"]
android:taskAffinity="string"
android:theme="resource or theme" >
. . .

在SDK用已经描述的很清楚到了。

android:process

The name of a process where all components of the application should run. Each component can override this default by setting its own process attribute.

By default, Android creates a process for an application when the first of its components needs to run. All components then run in that process. The name of the default process matches the package name set by the element.

By setting this attribute to a process name that's shared with another application, you can arrange for components of both applications to run in the same process — but only if the two applications also share a user ID and be signed with the same certificate.

为什么要提出这么一个定义？android:process名称。

默认状态下，Activity Manager Service在应用程序的第一个组件需要运行时将会为应用程序建立一个进程，而这个进程的名字就是android:process=”string”所指定，缺省的是应用程序包的名字。该进程一旦建立，后面的该应用的组件都将运行在该进程中，他们绑定的根据就是这个Android：Process指定的名称，因为在他们都在同一个应用程序包里，也就具有了同样的进程名字，于是他们都托管在了同一进程中。组件将通过ClassLoader从Package 中获取到应用程序的信息。

在建立Actvitiy时，如果在应用进程端没有应用对象，系统在该过程中利用makeApplication建立一个Application对象，实例化"android.app.Application"，建立一个应用程序上下文完成例如资源，package等信息管理。

2.2 ActivityThread运行框架

在分析中，我们可以看到真正对应应用进程的不是Application而是ActivityThread。我们从实际的应用堆栈可以看到：

NaiveStart.main()

ZygoteInit.main

ZygoteInit$MethodAndArgsCall.run

Method.Invoke

method.invokeNative

ActivityThread.main()

Looper.loop()

....

每个应用程序都以ActivityThread.main()为入口进入到消息循环处理。对于一个进程来讲，我们需要这个闭合的处理框架。

ActivitiyThread是应用程序概念空间的重要概念，他建立了应用进程运行的框架，并提供了一个IActivityThread接口作为与 Activity Manager Service的通讯接口.通过该接口AMS可以将Activity的状态变化传递到客户端的Activity对象。

2．3 ActivitiyThread的建立

为了叙述的方便我将Actvitiy Manager Service简写成AMS。

在AMS中关于应用程序的概念是ProcessRecord，请求都是从Activity，Service…等开始的，在Activity需要Resume时，此时如果与Activity相关的应用进程没有起来，AM则启动应用进程。

AMS与应用进程的绑定分为两个部分，第一部分就是AM建立应用进程，第二部分就是应用进程Attach到AM，与AM建立通讯通道。

1）创建建立进程：startProcessLocked(processName,Appinfo.uid)。该函数在StartSecificActivityLocked等调用。

（1）建立ProcessRecord对象app,并将该对象添加到mProcessNames中。应用对象在mProcessNames中使用应用名字和 uid来标识自己。如果在同一个Package中的Activity,如果都使用默认设置，那么这些Activity都会托管在同一个进程中，这是因为他们在带的ApplicationInfo中的ProcessName都是一样的。

mPidsSelfLocked数组记录了PID，这个将会在应用进程跑起来后，将自己Attach到AM时，根据pid找到自己的前世：ProcessRecord.

2）android.app.ActivityThread进程启动

Android.app.ActivityThread进程建立后，将跳入到ActivityThread的main函数开始运行，进入消息循环。

应用进程使用thread.attach()发起AMS的AttachApplicationLocked调用，并传递 ActvitiyThread对象和CallingPid。AttachApplicationLocked将根据CallingPid在 mPidsSelfLocked找到对应的ProcessRecord实例app,将ActvitiyThread放置app.thread中。这样应用进程和AMS建立起来双向连接。AM可以使用AIDL接口，通过app.thread可以访问应用进程的对象。

应用程序通过ActivityThread提供的框架，建立消息循环Looper和Handler。从前面的相关章节我们知道有Looper和Handler,整个系统就可以运作了。

为了更为系统的了解应用程序的建立时序及其涉及到数据操作，我给出了应用进程的建立过程示意图：

[3] lbs中从库中查询某中纬度2KM范围内的数据

来源: 互联网发布时间: 2014-02-18

lbs中从库中查询某经纬度2KM范围内的数据

sql语句查询经纬度范围

指定一个经纬度，给定一个范围值(单位:千米)，查出在经纬度周围这个范围内的数据。
经度:113.914619
纬度:22.50128
范围:2km
longitude为数据表经度字段
latitude为数据表纬度字段
SQL在mysql下测试通过,其他数据库可能需要修改
SQL语句如下:
select * from location where sqrt( ( ((113.914619-longitude)*PI()*12656*cos(((22.50128+latitude)/2)*PI()/180)/180) * ((113.914619-longitude)*PI()*12656*cos (((22.50128+latitude)/2)*PI()/180)/180) ) + ( ((22.50128-latitude)*PI()*12656/180) * ((22.50128-latitude)*PI()*12656/180) ) )<2

MySQL性能调优 – 使用更为快速的算法进行距离

最近遇到了一个问题,通过不断的尝试最终将某句原本占据近1秒的查询优化到了0.01秒,效率提高了100倍.

问题是这样的,有一张存放用户居住地点经纬度信息的MySQL数据表,表结构可以简化为:id(int),longitude(long),latitude()long. 而业务系统中有一个功能是查找离某个用户最近的其余数个用户,通过代码分析,可以确定原先的做法基本是这样的:

//需要查询的用户的坐标

$lat=20;
$lon=20;//执行查询,算出该用户与所有其他用户的距离,取出最近的10个
$sql='select * from users_location order by ACOS(SIN(('.$lat.' * 3.1415) / 180 ) *SIN((latitude * 3.1415) / 180 ) +COS(('.$lat.' * 3.1415) / 180 ) * COS((latitude * 3.1415) / 180 ) *COS(('.$lon.' * 3.1415) / 180 - (longitude * 3.1415) / 180 ) ) * 6380 asc limit 10';

而这条sql执行的速度却非常缓慢,用了近1秒的时间才返回结果,应该是因为order里的子语句用了太多的数学计算公式,导致整体的运算速度下降.

而在实际的使用中,不太可能会发生需要计算该用户与所有其他用户的距离,然后再排序的情况,当用户数量达到一个级别时,就可以在一个较小的范围里进行搜索,而非在所有用户中进行搜索.

所以对于这个例子,我增加了4个where条件,只对于经度和纬度大于或小于该用户1度(111公里)范围内的用户进行距离计算,同时对数据表中的经度和纬度两个列增加了索引来优化where语句执行时的速度.

最终的sql语句如下

$sql='select * from users_location where
latitude > '.$lat.'-1 and
latitude < '.$lat.'+1 and
longitude > '.$lon.'-1 and
longitude < '.$lon.'+1
order by ACOS(SIN(('.$lat.' * 3.1415) / 180 ) *SIN((latitude * 3.1415) / 180 ) +COS(('.$lat.' * 3.1415) / 180 ) * COS((latitude * 3.1415) / 180 ) *COS(('.$lon.'* 3.1415) / 180 - (longitude * 3.1415) / 180 ) ) * 6380 asc limit 10';

经过优化的sql大大提高了运行速度,在某些情况下甚至有100倍的提升.这种从业务角度出发,缩小sql查询范围的方法也可以适用在其他地方.

http://my.oschina.net/laserdance/blog/40854