2. 程式人生 > >［Android進階］Binder學習（初始篇）

［Android進階］Binder學習（初始篇）

阿新 • • 發佈：2019-02-04

Android中Binder學習（初始篇）

本篇部落格學習自侯亮的部落格，地址為：

1 什麼是Binder？

簡單地說，Binder是Android平臺上的一種跨程序互動技術。該技術最早並不是由Google公司提出的，它的前身是Be Inc公司開發的OpenBinder，而且在Palm中也有應用。後來OpenBinder的作者Dianne Hackborn加入了Google公司，並負責Android平臺的開發工作，所以把這項技術也帶進了Android。

我們知道，在Android的應用層次上，基本上已經沒有過去的程序概念了。然而在實現層次，它畢竟還是要建構在一個個程序之上的。實際上，在Android內部，那些支撐應用的元件往往會身處於不同的程序，那麼應用的底層必然會牽涉大量的跨程序通訊。為了保證通訊的高效性，Android提供了Binder機制。

Binder機制具有兩層含義：

  1. 是一種跨程序通訊手段（IPC， Inter-Process Communication）。
  2. 是一種遠端過程呼叫手段（RPC，Remote Procedure Call）。

從實現的角度來說，Binder核心被實現成一個Linux驅動程式，並運行於核心態。這樣它才能具有強大的跨程序訪問能力。

1.1 簡述Binder的跨程序機制

為了理解Binder，我們可以先畫一張最簡單的跨程序通訊示意圖：

Mou icon

這個很容易理解，不需贅言。到了Android平臺上，IPC機制就變成了Binder機制，情況類似，只不過為了便於說明問題，我們需要稍微調整一下示意圖：

Mou icon

圖中A側的圓形塊，表示“Binder代理方”，主要用於向遠方傳送語義，而B側的方形塊則表示“Binder響應方”，主要用於響應語義。需要說明的是，這種圖形表示方法是我自己杜撰的，並沒有正規的出處。我個人覺得這種圖形非常簡便，所以在分析Android架構時，會經常使用這種表示法。

在後文中，我們可以看到，Binder代理方大概對應於C++層次的BpBinder物件，而Binder響應方則對應於BBinder物件。這兩個物件在後文會詳細闡述，此處不必太細究。

然而，上圖的Binder代理方主要只負責了“傳遞資訊”的工作，並沒有起到“遠端過程呼叫”的作用，如果要支援遠端過程呼叫，我們還必須提供“介面代理方”和“介面實現體”。這樣，我們的示意圖就需要再調整一下，如下：

Mou icon

從圖中可以看到，A程序並不直接和BpBinder（Binder代理）打交道，而是通過呼叫BpInterface（介面代理）的成員函式來完成遠端呼叫的。此時，BpBinder已經被聚合進BpInterface了，它在BpInterface內部完成了一切跨程序的機制。另一方面，與BpInterface相對的響應端實體就是BnInterface（介面實現）了。需要注意的是，BnInterface是繼承於BBinder的，它並沒有採用聚合的方式來包含一個BBinder物件，所以上圖中B側的BnInterface塊和BBinder塊的背景圖案是相同的。

這樣看來，對於遠端呼叫的客戶端而言，主要搞的就是兩個東西，一個是“Binder代理”，一個是“介面代理”。而服務端主要搞的則是“介面實現體”。因為binder是一種跨程序通訊機制，所以還需要一個專門的管理器來為通訊兩端牽線搭橋，這個管理器就是Service Manager Service。不過目前我們可以先放下Service Manager Service，以後再詳細研究。

2 Binder相關介面和類

Android的整個跨程序通訊機制都是基於Binder的，這種機制不但會在底層使用，也會在上層使用，所以必須提供Java和C++兩個層次的支援。

2.1 Java層次的binder元素

Java層次裡並沒有我們前文圖中所表示的BpBinder、BpInterface、BBinder等較低層次的概念，取而代之的是IBinder介面、IInterface等介面。Android要求所有的Binder實體都必須實現IBinder介面，該介面的定義截選如下：

【frameworks/base/core/java/android/os/IBinder.java】

public interface IBinder 
{
    . . . . . .
    public String getInterfaceDescriptor() throws RemoteException;
    public boolean pingBinder();
    public boolean isBinderAlive();
    public IInterface queryLocalInterface(String descriptor);
    public void dump(FileDescriptor fd, String[] args) throws RemoteException;
    public void dumpAsync(FileDescriptor fd, String[] args) throws RemoteException;
    public boolean transact(int code, Parcel data, Parcel reply, int flags)
throws RemoteException;

    public interface DeathRecipient 
    {
        public void binderDied();
    }
    public void linkToDeath(DeathRecipient recipient, int flags)throws RemoteException;
    public boolean unlinkToDeath(DeathRecipient recipient, int flags);
}

另外，不管是代理方還是實體方，都必須實現IInterface介面：

public interface IInterface
{
    public IBinder asBinder();
}

Java層次中，與Binder相關的介面或類的繼承關係如下：

Mou icon

在實際使用中，我們並不需要編寫上圖的XXXXNative、XXXXProxy，它們會由ADT根據我們編寫的aidl指令碼自動生成。使用者只需繼承XXXXNative編寫一個具體的XXXXService即可，這個XXXXService就是遠端通訊的服務實體類，而XXXXProxy則是其對應的代理類。

關於Java層次的binder元件，我們就先說這麼多，主要是先介紹一個大概。就研究跨程序通訊而言，其實質內容基本上都在C++層次，Java層次只是一個殼而已。以後我會寫專文來打通Java層次和C++層次，看看它們是如何通過JNI技術關聯起來的。現在我們還是把注意力集中在C++層次吧。

2.2 C++層次的binder元素

在C++層次，就能看到我們前文所說的BpBinder類和BBinder類了。這兩個類都繼承於IBinder，IBinder的定義截選如下：

【frameworks/native/include/binder/IBinder.h】

class IBinder : public virtual RefBase
{
public:
    . . . . . .
    IBinder();
    virtual sp<IInterface>  queryLocalInterface(const String16& descriptor);
    virtual const String16& getInterfaceDescriptor() const = 0;

    virtual bool            isBinderAlive() const = 0;
    virtual status_t        pingBinder() = 0;
    virtual status_t        dump(int fd, const Vector<String16>& args) = 0;
    virtual status_t        transact(uint32_t code, const Parcel& data,
                                     Parcel* reply, uint32_t flags = 0) = 0;

    class DeathRecipient : public virtual RefBase
    {
    public:
        virtual void binderDied(const wp<IBinder>& who) = 0;
    };
    virtual status_t        linkToDeath(const sp<DeathRecipient>& recipient,
                                        void* cookie = NULL, uint32_t flags = 0) = 0;
    virtual status_t        unlinkToDeath(const wp<DeathRecipient>& recipient,
                                          void* cookie = NULL, uint32_t flags = 0,
                                          wp<DeathRecipient>* outRecipient = NULL) = 0;

    virtual bool            checkSubclass(const void* subclassID) const;

    typedef void (*object_cleanup_func)(const void* id, void* obj, void* cleanupCookie);
    virtual void            attachObject(const void* objectID, void* object,
                                         void* cleanupCookie, object_cleanup_func func) = 0;
    virtual void*           findObject(const void* objectID) const = 0;
    virtual void            detachObject(const void* objectID) = 0;

    virtual BBinder*        localBinder();
    virtual BpBinder*       remoteBinder();

protected:
    virtual          ~IBinder();
private:
};

C++層次的繼承關係圖如下：

Mou icon

其中有以下幾個很關鍵的類：

  • BpBinder
  • BpInterface
  • BBinder
  • BnInterface

它們扮演著很重要的角色。

2.2.1 BpBinder

BpBinder的定義截選如下：

class BpBinder : public IBinder
{
public:
BpBinder(int32_t handle);
    inline  int32_t     handle() const { return mHandle; }

    virtual const String16&    getInterfaceDescriptor() const;
    virtual bool        isBinderAlive() const;
    virtual status_t    pingBinder();
    virtual status_t    dump(int fd, const Vector<String16>& args);

    virtual status_t    transact(uint32_t code, const Parcel& data,
                                    Parcel* reply, uint32_t flags = 0);
    virtual status_t    linkToDeath(const sp<DeathRecipient>& recipient,
                                    void* cookie = NULL, uint32_t flags = 0);
    virtual status_t    unlinkToDeath(const wp<DeathRecipient>& recipient,
                                            void* cookie = NULL, uint32_t flags = 0,
                                            wp<DeathRecipient>* outRecipient = NULL);
. . . . . .
. . . . . .

作為代理端的核心，BpBinder最重要的職責就是實現跨程序傳輸的傳輸機制，至於具體傳輸的是什麼語義，它並不關心。我們觀察它的transact()函式的引數，可以看到所有的語義都被打包成Parcel了。其他的成員函式，我們先不深究，待我們儲備了足夠的基礎知識後，再回過頭研究它們不遲。

2.2.2 BpInterface

另一個重要的類是BpInterface，它的定義如下：

template<typename INTERFACE>
class BpInterface : public INTERFACE, public BpRefBase
{
public:
BpInterface(const sp<IBinder>& remote);

protected:
    virtual IBinder*     onAsBinder();
};

其基類BpRefBase的定義如下：

class BpRefBase : public virtual RefBase
{
protected:
                            BpRefBase(const sp<IBinder>& o);
    virtual                 ~BpRefBase();
    virtual void            onFirstRef();
    virtual void            onLastStrongRef(const void* id);
    virtual bool            onIncStrongAttempted(uint32_t flags, const void* id);
    inline  IBinder*        remote()                { return mRemote; }
    inline  IBinder*        remote() const          { return mRemote; }

private:
BpRefBase(const BpRefBase& o);
    BpRefBase&              operator=(const BpRefBase& o);
    IBinder* const           mRemote;
    RefBase::weakref_type*  mRefs;
    volatile int32_t         mState;
};

BpInterface使用了模板技術，而且因為它繼承了BpRefBase，所以先天上就聚合了一個mRemote成員，這個成員記錄的就是前面所說的BpBinder物件啦。以後，我們還需要繼承BpInterface<>實現我們自己的代理類。

在實際的程式碼中，我們完全可以建立多個聚合同一BpBinder物件的代理物件，這些代理物件就本質而言，對應著同一個遠端binder實體。在Android框架中，常常把指向同一binder實體的多個代理稱為token，這樣即便這些代理分別處於不同的程序中，它們也具有了某種內在聯絡。這個知識點需要大家關注。

2.2.3 BBinder

Binder遠端通訊的目標端實體必須繼承於BBinder類，該類和BpBinder相對，主要關心的只是傳輸方面的東西，不太關心所傳輸的語義。

class BBinder : public IBinder
{
public:
BBinder();
    virtual const String16& getInterfaceDescriptor() const;
    virtual bool        isBinderAlive() const;
    virtual status_t    pingBinder();
    virtual status_t    dump(int fd, const Vector<String16>& args);

    virtual status_t    transact(uint32_t code, const Parcel& data,
                                      Parcel* reply, uint32_t flags = 0);

    virtual status_t    linkToDeath(const sp<DeathRecipient>& recipient,
                                    void* cookie = NULL, uint32_t flags = 0);

    virtual status_t    unlinkToDeath(const wp<DeathRecipient>& recipient,
                                            void* cookie = NULL, uint32_t flags = 0,
                                            wp<DeathRecipient>* outRecipient = NULL);

    virtual void        attachObject(const void* objectID, void* object,
                                          void* cleanupCookie, object_cleanup_func func);
    virtual void*       findObject(const void* objectID) const;
    virtual void        detachObject(const void* objectID);

    virtual BBinder*    localBinder();

protected:
    virtual             ~BBinder();

    virtual status_t    onTransact(uint32_t code, const Parcel& data,
                                        Parcel* reply, uint32_t flags = 0);
private:
    BBinder(const BBinder& o);
    BBinder&    operator=(const BBinder& o);

    class Extras;
    Extras*     mExtras;
    void*       mReserved0;
};

我們目前只需關心上面的transact()成員函式，其他函式留待以後再分析。transact函式的程式碼如下：

【frameworks/native/libs/binder/Binder.cpp】

status_t BBinder::transact(uint32_t code, const Parcel& data, 
                           Parcel* reply, uint32_t flags)
{
    data.setDataPosition(0);
    status_t err = NO_ERROR;
    switch (code) 
    {
        case PING_TRANSACTION:
            reply->writeInt32(pingBinder());
            break;
        default:
            err = onTransact(code, data, reply, flags);
            break;
    }

    if (reply != NULL) 
    {
        reply->setDataPosition(0);
    }
    return err;
}

看到了嗎，transact()內部會呼叫onTransact()，從而走到使用者所定義的子類的onTransact()裡。這個onTransact()的一大作用就是解析經由Binder機制傳過來的語義了。

2.2.4 BnInterface

遠端通訊目標端的另一個重要類是BnInterface<>，它是與BpInterface<>相對應的模板類，比較關心傳輸的語義。一般情況下，服務端並不直接使用BnInterface<>，而是使用它的某個子類。為此，我們需要編寫一個新的BnXXX子類，並重載它的onTransact()成員函式。

BnInterface<>的定義如下：

template<typename INTERFACE>
class BnInterface : public INTERFACE, public BBinder
{
public:
    virtual sp<IInterface>      queryLocalInterface(const String16& _descriptor);
    virtual const String16&     getInterfaceDescriptor() const;

protected:
    virtual IBinder*            onAsBinder();
};

如上所示，BnInterface<>繼承於BBinder，但它並沒有實現一個預設的onTransact()成員函式，所以在遠端通訊時，前文所說的BBinder::transact()呼叫的onTransact()應該就是BnInterface<>的某個子類的onTransact()成員函式。

2.3 幾個重要的C++巨集或模板

為了便於編寫新的介面和類，Android在C++層次提供了幾個重要的巨集和模板，比如我們在IInterface.h檔案中，可以看到DECLARE_META_INTERFACE、IMPLEMENT_META_INTERFACE的定義。

2.3.1 DECLARE_META_INTERFACE()

DECLARE_META_INTERFACE()的定義如下：

#define DECLARE_META_INTERFACE(INTERFACE)                               \
    static const android::String16 descriptor;                          \
    static android::sp<I##INTERFACE> asInterface(                       \
            const android::sp<android::IBinder>& obj);                  \
    virtual const android::String16& getInterfaceDescriptor() const;    \
    I##INTERFACE();                                                     \
    virtual ~I##INTERFACE();                                            \

我們舉個實際的例子，來說明如何使用這個巨集：

pic

上例中ICamera內部使用了DECLARE_META_INTERFACE(Camera)，我們把巨集展開後，可以看到ICamera類的定義相當於：

class ICamera: public IInterface
{
public:

static const android::String16 descriptor;
static android::sp<ICamera> asInterface( const android::sp<android::IBinder>& obj);
virtual const android::String16& getInterfaceDescriptor() const;
ICamera();
virtual ~ICamera();

virtual void disconnect() = 0;
. . . . . .

巨集展開的部分就是中間那5行程式碼，其中最關鍵的就是asInterface()函數了，這個函式將承擔把BpBinder打包成BpInterface的職責。

2.3.2 IMPLEMENT_META_INTERFACE()

與DECLARE_META_INTERFACE相對的就是IMPLEMENT_META_INTERFACE巨集。它的定義如下：

#define IMPLEMENT_META_INTERFACE(INTERFACE, NAME)                       \
    const android::String16 I##INTERFACE::descriptor(NAME);             \
    const android::String16&                                            \
            I##INTERFACE::getInterfaceDescriptor() const {              \
        return I##INTERFACE::descriptor;                                \
    }                                                                   \
    android::sp<I##INTERFACE> I##INTERFACE::asInterface(                \
            const android::sp<android::IBinder>& obj)                   \
    {                                                                   \
        android::sp<I##INTERFACE> intr;                                 \
        if (obj != NULL) {                                              \
            intr = static_cast<I##INTERFACE*>(                          \
                obj->queryLocalInterface(                               \
                        I##INTERFACE::descriptor).get());               \
            if (intr == NULL) {                                         \
                intr = new Bp##INTERFACE(obj);                          \
            }                                                           \
        }                                                               \
        return intr;                                                    \
    }                                                                   \
    I##INTERFACE::I##INTERFACE() { }                                    \
    I##INTERFACE::~I##INTERFACE() { }                                   \

其中，實現了關鍵的asInterface()函式。

實際使用IMPLEMENT_META_INTERFACE時，我們只需把它簡單地寫在binder實體所處的cpp檔案中即可，舉例如下：

pic

其中的IMPLEMENT_META_INTERFACE(Camera, “android.hardware.ICamera”);一句相當於以下這段程式碼：

const android::String16 ICamera::descriptor(“android.hardware.ICamera”);
const android::String16& ICamera::getInterfaceDescriptor() const 
{
return ICamera::descriptor;
}

android::sp<ICamera> ICamera::asInterface(const android::sp<android::IBinder>& obj)
{
android::sp<ICamera > intr;
if (obj != NULL) 
{
intr = static_cast<ICamera*>(obj->queryLocalInterface(
ICamera::descriptor).get());
        if (intr == NULL) 
{
            intr = new BpCamera(obj);
        }
}
    return intr;
}

ICamera::ICamera() { }
ICamera::~ICamera () { }

看來，其中重點實現了asInterface()成員函式。請注意，asInterface()函式中會先嚐試呼叫queryLocalInterface()來獲取intr。此時，如果asInterface()的obj引數是個代理物件（BpBinder），那麼intr = static_cast

sp<IInterface>  IBinder::queryLocalInterface(const String16& descriptor)
{
    return NULL;
}

另一方面，如果obj引數是個實現體物件（BnInterface物件）的話，那麼queryLocalInterface()函式的預設返回值就是實體物件的this指標了，程式碼如下：

【frameworks/native/include/binder/IInterface.h】

template<typename INTERFACE>
inline sp<IInterface> BnInterface<INTERFACE>::queryLocalInterface(const String16& _descriptor)
{
    if (_descriptor == INTERFACE::descriptor) 
        return this;
    return NULL;
}

在我們所舉的Camera例子中，我們要研究的是如何將BpBinder轉成BpInterface，所以現在我們只闡述obj引數為BpBinder的情況。此時asInterface()函式中obj->queryLocalInterface()的返回值為NULL，於是asInterface()會走到new BpCamera(obj)一句，這一句是最關鍵的一句。我們知道，BpCamera繼承於BpInterface，所以此時所建立的BpCamera物件正是可被App使用的BpInterface代理物件。

BpCamera的定義如下：

class BpCamera: public BpInterface<ICamera>
{
public:
    BpCamera(const sp<IBinder>& impl)
        : BpInterface<ICamera>(impl)
    {
    }

    // disconnect from camera service
    void disconnect()
    {
        LOGV("disconnect");
        Parcel data, reply;
        data.writeInterfaceToken(ICamera::getInterfaceDescriptor());
        remote()->transact(DISCONNECT, data, &reply);
    }
. . . . . .

至此，IMPLEMENT_META_INTERFACE巨集和asInterface()函式的關係就分析完畢了。

2.3.3 interface_cast

不過，我們經常使用的其實並不是asInterface()函式，而是interface_cast()，它簡單包裝了asInterface()：

template<typename INTERFACE>
inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj)
{
    return INTERFACE::asInterface(obj);
}

以上就是關於C++層次中一些binder元素的介紹，下面我們再進一步分析其他細節。

3 ProcessState

前文我們已經提到過，在Android的上層架構中，已經大幅度地弱化了程序的概念。應用程式設計師能看到的主要是activity、service、content provider等概念，再也找不到以前熟悉的main()函數了。然而，底層程式（C++層次）畢竟還是得跑在一個個程序之上，現在我們就來看底層程序是如何運用Binder機制來完成跨程序通訊的。

在每個程序中，會有一個全域性的ProcessState物件。這個很容易理解，ProcessState的字面意思不就是“程序狀態”嗎，當然應該是每個程序一個ProcessState。ProcessState的定義位於frameworks/native/include/binder/ProcessState.h中，我們只截選其中的一部分：

class ProcessState : public virtual RefBase
{
public:
    static  sp<ProcessState>    self();
    . . . . . .
    void                startThreadPool();
    . . . . . .
    void                spawnPooledThread(bool isMain);
    status_t            setThreadPoolMaxThreadCount(size_t maxThreads);

private:
    friend class IPCThreadState;
    . . . . . .

    struct handle_entry 
    {
        IBinder* binder;
        RefBase::weakref_type* refs;
    };
    handle_entry*       lookupHandleLocked(int32_t handle);
    int                 mDriverFD;
    void*               mVMStart;
    mutable Mutex       mLock;  // protects everything below.

    Vector<handle_entry> mHandleToObject;
    . . . . . .
    KeyedVector<String16, sp<IBinder> > mContexts;
    . . . . . .
};

我們知道，Binder核心被設計成一個驅動程式，所以ProcessState裡專門搞了個mDriverFD域，來記錄binder驅動對應的控制代碼值，以便隨時和binder驅動通訊。ProcessState物件採用了典型的單例模式，在一個應用程序中，只會有唯一的一個ProcessState物件，它將被程序中的多個執行緒共用，因此每個程序裡的執行緒其實是共用所開啟的那個驅動控制代碼（mDriverFD）的，示意圖如下：

pic

每個程序基本上都是這樣的結構，組合起來的示意圖就是：

pic

我們常見的使用ProcessState的程式碼如下：

int main(int argc, char** argv)
{
    sp<ProcessState> proc(ProcessState::self());
    . . . . . .
    . . . . . .
    ProcessState::self()->startThreadPool();
    IPCThreadState::self()->joinThreadPool();
}

因為ProcessState採用的是單例模式，所以它的建構函式是private的，我們只能通過呼叫ProcessState::self()來獲取程序中唯一的一個ProcessState物件。self()函式的程式碼如下：

sp<ProcessState> ProcessState::self()
{
    Mutex::Autolock _l(gProcessMutex);
    if (gProcess != NULL) {
        return gProcess;
    }
    gProcess = new ProcessState;
    return gProcess;
}

ProcessState物件構造之時，就會開啟binder驅動：

ProcessState::ProcessState()
    : mDriverFD(open_driver())     // 開啟binder驅動。
    , mVMStart(MAP_FAILED)
    , mManagesContexts(false)
    , mBinderContextCheckFunc(NULL)
    , mBinderContextUserData(NULL)
    , mThreadPoolStarted(false)
    , mThreadPoolSeq(1)
{
    . . . . . .
    mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);
    . . . . . .    
}

注意上面那句mDriverFD(open_driver())，其中的open_driver()就負責開啟“/dev/binder”驅動：

static int open_driver()
{
    int fd = open("/dev/binder", O_RDWR);
    . . . . . .
    status_t result = ioctl(fd, BINDER_VERSION, &vers);
    . . . . . .
    size_t maxThreads = 15;
    result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads);
    . . . . . .
    return fd;
}

ProcessState中另一個比較有意思的域是mHandleToObject：

Vector<handle_entry> mHandleToObject;

它是本程序中記錄所有BpBinder的向量表噢，非常重要。我們前文已經說過，BpBinder是代理端的核心，現在終於看到它的藏身之處了。在Binder架構中，應用程序是通過“binder控制代碼”來找到對應的BpBinder的。從這張向量表中我們可以看到，那個控制代碼值其實對應著這個向量表的下標。這張表的子項型別為handle_entry，定義如下：

struct handle_entry 
{
    IBinder* binder;
    RefBase::weakref_type* refs;
};

其中的binder域，記錄的就是BpBinder物件。

pic

此篇完

相關推薦

［Android進階］Binder學習（初始篇）

Android中Binder學習（初始篇） 本篇部落格學習自侯亮的部落格，地址為： 1 什麼是Binder？ 簡單地說，Binder是Android平臺上的一種跨程序互動技術。該技術最早並不是由Google公司提出的，它的前身是Be Inc

Android進階2之SlidingDrawer（滑動式抽屜）

分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！        

Android進階之使用multidex（產生多個dex）解決Dex超出方法數65535的限制

1 概述 1.1 為什麼要拆包 隨著應用不斷迭代，業務線的擴充套件,應用越來越大(比如集成了各種第三方sdk或者公共支援的jar包,專案耦合性高，重複作用的類越來越多)，出現了一個 dex 包裝不下的情況，出現65536問題。 1.2 為什麼方法數不能

Android進階之路——NDK（二）

　　上一篇部落格介紹了NDK簡介和環境的搭建以及一個簡單的Demo，這篇準備總結一下JNI呼叫Java物件以及在JNI中開啟執行緒。 　　ps：這裡說明一下，我是用Android Studio開發的，如果是用Eclipse開發的朋友，是不能直接匯入我的程式，而

進階面向對象（十一）

C++ 類 對象 繼承 組合 在日常生活中，我們都習慣於對事物進行分類。那麽，這種分類的思想是否也可以引入程序設計中呢？面向對象的意義在於：將日常生活中習慣的思維方式引入程序設計中；將需求中的概念直觀的映射到解決方案中；以模塊為中心構建可復用的軟件系統；提高軟件產品的可維護

阿里架構設計之初體驗，送給準備進階架構的朋友（個人總結）

1 基本概念和目的 架構設計的目的是為了解決系統複雜度帶來的問題，並不是要面面俱到，不需要每個架構都具備高效能、高可用、高擴充套件等特點，而是要識別出實際業務實際情況的複雜點，然後有有針對性地解決問題，即：有的放矢，而不是貪大求全。 在實際情況中，不一定每個系統都要做架

jmu-Java-04面向物件進階--02-介面-Comparator （20 分）

Arrays.sort可以對所有實現Comparable的物件進行排序。但如果有多種排序需求，如有時候需對name進行降序排序，有時候只需要對年齡進行排序。使用Comparable無法滿足這樣的需求。可以編寫不同的Comparator來滿足多樣的排序需求。 1.編寫PersonSortabl

SpringBoot進階之訪問資料庫（含原始碼）

本文介紹在Spring Boot基礎下配置資料來源和通過JdbcTemplate編寫資料訪問的示例。 簡單介紹一下 @Controller：修飾class，用來建立處理http請求的物件 @RestController：Spring4之後加入的註解，原來在

android開源庫---Dagger2入門學習（簡單使用）

Dagger2依賴注入 前面我們做好學習準備接下來就要研究如何使用了，俗話說的好，一個東西需要先會用，然後才更好的學習原理。 一、匯入Dagger2 在工程的build.gradle檔案中新增android-apt外掛（該外掛後面介紹） buil

c# 進階之路-架構（筆記1）

介面： 只要是繼承了介面的類，都包含了接口裡面的方法。介面是一種類與類之間的規範，一種協議！ 架構：通常更側重於巨集觀的設計； 一、物理架構：邏輯架構、開發架構..；要從不同的專案區分析 -----------------------------------------

架構設計之初體驗，送給準備進階架構的朋友（個人總結）

浪費了“黃金五年”的Java程式設計師，還有救嗎？ >>>   

百度T8架構師細談Java架構進階掃盲清單！（附圖文）

普通程式設計師寫程式碼叫編碼，而架構師寫程式碼就叫架構設計。這是因為他們在編碼時考慮的角度完全不同。普通程式設計師只需要考慮如何實

Python學習（第一篇）

logs 完全 python3 兩個 ges tex pytho 格式 代碼 說明：筆者所用的版本是python3.6 首先，說一下python的三種格式輸出。第一種用到了格式化操作符%，格式化字符串時，Python使用一個字符串作為模板。模板中有格式符，這些格式符為真實值

Java多執行緒學習（基礎篇）

1. java對執行緒的支援 java對執行緒的支援主要體現在Thread類以及Runable介面上，他們都位於java.lang包下，無論是Thread類還是Runable介面，它們都有public void run()方法，這個run方法為我們提供了執行緒實際工作時的程式碼，換句

JQuery學習（基礎篇）

學習JQuery需要具備什麼？ 學習JQuery只需要具備js知識; 什麼是JQuery？ JQuery是js的一套框架； 為什麼學習JQuery? 因為JQuery語法簡單，方便開發; JQuery和js有什麼區別? JQuery物件在操作時更加

Android應用程式程序啟動過程（前篇）

前言 在此前我講過Android系統的啟動流程，系統啟動後，我們就比較關心應用程式是如何啟動的，這一篇我們來一起學習Android7.0 應用程式程序啟動過程，需要注意的是“應用程式程序啟動過程”，而不是應用程式啟動過程。關於應用程式啟動過程，我會在後

Android應用程式程序啟動過程（後篇）

前言 在前篇中我們講到了Android應用程式程序啟動過程，這一篇我們來講遺留的知識點：在應用程式程序建立過程中會啟動Binder執行緒池以及在應用程式程序啟動後會建立訊息迴圈。 1.Binder執行緒池啟動過程 我們首先來看RuntimeInit

教你寫Android ImageLoader框架之圖片快取 （完結篇）

在教你寫Android ImageLoader框架系列博文中，我們從基本架構到具體實現已經更新了大部分的內容。今天，我們來講最後一個關鍵點，即圖片的快取。為了使用者體驗，通常情況下我們都會將已經下載的圖片快取起來，一般來說記憶體和本地都會有圖片快取。那既然是框架

windows下sqli-labs的搭建及學習（POST篇）

windows下sqli-labs的搭建及學習（GET篇）： Less-11：基於錯誤的_post_單引號_字元型注入      post型的注入一般都是登入繞過，測試的方法與get都類似，通過檢視原始碼我們知道以post方式傳遞的兩個引數是uname和passwd，那麼

windows下sqli-labs的搭建及學習（GET篇）

環境搭建： 需要搭建以下環境： apache+mysql+php Tomcat+mysql+java（部分關卡需要）         apache的環境在windows下可以直接安裝wamp、phpstudy、apmserv等，我安裝的是wamp，安裝過程中可能會