热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

走出MFC子类化的迷宫---原创

走出MFC子类化的迷宫KEYWORDS:子类化SUBCLASSWINDOWMFC消息机制许多Windows程序员都是跳过SDK直接进行RAD开发工具[或VC,我想VC应不属于RAD]的学
走出MFC子类化的迷宫
KEY WORDS:子类化 SUBCLASSWINDOW  MFC消息机制

许多Windows程序员都是跳过SDK直接进行RAD开发工具[或VC,我想VC应不属于RAD]的学习,有些人可能对子类化机制比较陌生。
我们先看看什么是Windows的子类化。Windows给我们或是说给它自己定义了许多丰富的通用控件,如:Edit、ComboBox 、ListBox……等,这些控件功能丰富,能为我们开发工作带来极大方面,试想:我们单单是自己实现一个EDIT控件是多么的艰难!但是,在实际开发中还是有些情况这些标准控件也无能为力,比如:在我们的应用中要求一个EDIT得到老师对学生的评价A、B、C[不要对我说你想用ComboBox实现J],这时,要求在Edit中禁止对其它字母、数字的输入操作,怎么办?EDIT控件本身没有提供这种机制,我们就可以采用子类化很好的解决这类问题。
我们知道,每一个Windows窗口[这里是EDIT]都有一个窗口处理函数负责对消息处理,子类化的办法就是用我们自己的消息处理函数来替代窗口原有的、标准的处理函数。当然我们自己的窗口处理函数只是关心那些特定的消息[在这里当然是WM_CHAR了],而其它消息,再发给原来的窗口函数处理。在SDK中的实现方法是调用函数SetWindowLong :
WNDPROC * oldWndProc = (WNDPROC)SetWindowLong(hWnd, GWL_WNDPROC,(DWORD)AfxGetAfxWndProc());
其中AfxGetAfxWndProc()是我们自己的窗口处理函数,在其中处理过我们感兴趣的消息后就可能通过返回的原窗口处理函数指针oldWndProc来把其它消息按标准方法处理掉,具体做法请查阅相关资料。
但到了MFC“时代”,一切都被包装起来了,原来的窗口类注册、窗口函数都不见了[或是说隐身了],我想对于那些“刨根问底”的程序员有兴趣了解在MFC中的子类化机制,本人就自己做的一点“探索”作出总结,希望能给大家点启示。
我们先用MFC实现我上面提到的要求:一个只能输入A,B,C的EDIT控件。
启动时界面如下:
 
输入时就只能输入A、B、C,并且只允许输入一个字母。
 
实现方法:
先派生一个自己的类CsuperEdit,Ctrl + W后,在其中处理WM_CHAR,然后再编辑这个消息处理函数:

void CSuperEdit::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags) 
{
// TODO: Add your message handler code here and/or call default
TCHAR ch[20];
GetWindowText(ch,20);
if (strlen(ch) == 1 && (nChar <= 'C' && nChar >= 'A'))
return;
if (nChar != 'A' 
&& nChar != 'B'
&& nChar != 'C'
)
return;

CEdit::OnChar(nChar, nRepCnt, nFlags);
}

然后再给我们Cprog1Dlg类中加入一个数据成员CsuperEdit m_edit,在CProg1Dlg::OnInitDialog()中加入:
m_edit.SubclassDlgItem(IDC_EDIT1,this);
m_edit.SetWindowText("<请输入A、B、C>");
并处理EDIT向DIALOG发送的通知消息:EN_SETFOCUS:
void CProg1Dlg::OnSetfocusEdit1() 
{
// TODO: Add your control notification handler code here
m_edit.SetWindowText("");
m_edit.SetFocus();
}

OK,一切搞定!和SDK的子类化方法比起来,这是多么的容易!
我们看看MFC背着我们到底做了什么!这里主要解决两个容易让初学者比较疑惑的问题:
1、 m_edit只是我们定义的一个C++类对象,为什么通过它调用其成员函数SetWindowText便可以控制我们程序中资源编号为:IDC_EDIT1的控件?
2、 CSuperEdit类为什么可以处理WM_CHAR消息?

大家都知道,控制Windows窗口、控件、资源……都是通过它们的句柄来实现,如
HHANDLE、HWND、HDC都是句柄,它表现为一个32位长整形数据,存放于Windows中的特定区域,我们可以把它理解为指向我们想控制的窗口、控件、资源的索引,有了它,我们就可以控制我们想要控制的对象。
这里你可以想到为什么多数API函数都有一个参数HWND hwnd了吧!
BOOL SetWindowText(
  HWND hWnd,         // handle to window or control
  LPCTSTR lpString   // title or text
);

123 个解决方案

#1


我们的C++变量m_edit要想控制IDC_EDIT1,也要通过它的句柄,但这又是如何实现的呢?您可能注意到了m_edit.SubclassDlgItem(IDC_EDIT1,this);一句,对了,这就是关键所在!
在此处F9设置断点,F5之后,程序到达此处,F11跟入SubclassDlgItem函数:
BOOL CWnd::SubclassDlgItem(UINT nID, CWnd* pParent)
{
ASSERT(pParent != NULL);
ASSERT(::IsWindow(pParent->m_hWnd));

// check for normal dialog control first
HWND hWndControl = ::GetDlgItem(pParent->m_hWnd, nID);
if (hWndControl != NULL)
return SubclassWindow(hWndControl);

#ifndef _AFX_NO_OCC_SUPPORT
if (pParent->m_pCtrlCont != NULL)
{
// normal dialog control not found
COleControlSite* pSite = pParent->m_pCtrlCont->FindItem(nID);
if (pSite != NULL)
{
ASSERT(pSite->m_hWnd != NULL);
VERIFY(SubclassWindow(pSite->m_hWnd));

#ifndef _AFX_NO_OCC_SUPPORT
// If the control has reparented itself (e.g., invisible control),
// make sure that the CWnd gets properly wired to its control site.
if (pParent->m_hWnd != ::GetParent(pSite->m_hWnd))
AttachControlSite(pParent);
#endif //!_AFX_NO_OCC_SUPPORT

return TRUE;
}
}
#endif

return FALSE;   // control not found
}
代码开始时对传入的父窗口做些检查,然后就是
HWND hWndControl = ::GetDlgItem(pParent->m_hWnd, nID);
if (hWndControl != NULL)
return SubclassWindow(hWndControl);
这是关键的代码,先用hWndControl得到我们IDC_EDIT1控件的句柄,然后调用
SubclassWindow函数,这个函数是实现的关键,我们来看一下它做了什么:



BOOL CWnd::SubclassWindow(HWND hWnd)
{
if (!Attach(hWnd))
return FALSE;

// allow any other subclassing to occur
PreSubclassWindow();

// now hook into the AFX WndProc
WNDPROC* lplpfn = GetSuperWndProcAddr();
WNDPROC oldWndProc = (WNDPROC)::SetWindowLong(hWnd, GWL_WNDPROC, (DWORD)AfxGetAfxWndProc());
ASSERT(oldWndProc != (WNDPROC)AfxGetAfxWndProc());

if (*lplpfn == NULL)
*lplpfn = oldWndProc;   // the first control of that type created
#ifdef _DEBUG
else if (*lplpfn != oldWndProc)
{
TRACE0("Error: Trying to use SubclassWindow with incorrect CWnd\n");
TRACE0("\tderived class.\n");
TRACE3("\thWnd = $%04X (nIDC=$%04X) is not a %hs.\n", (UINT)hWnd,
_AfxGetDlgCtrlID(hWnd), GetRuntimeClass()->m_lpszClassName);
ASSERT(FALSE);
// undo the subclassing if continuing after assert
::SetWindowLong(hWnd, GWL_WNDPROC, (DWORD)oldWndProc);
}
#endif

return TRUE;
}

函数Attach内部如下:
BOOL CWnd::Attach(HWND hWndNew)
{
ASSERT(m_hWnd == NULL);     // only attach once, detach on destroy
ASSERT(FromHandlePermanent(hWndNew) == NULL);
// must not already be in permanent map

if (hWndNew == NULL)
return FALSE;

#2


CHandleMap* pMap = afxMapHWND(TRUE); // create map if not exist
ASSERT(pMap != NULL);

pMap->SetPermanent(m_hWnd = hWndNew, this);

#ifndef _AFX_NO_OCC_SUPPORT
AttachControlSite(pMap);
#endif

return TRUE;
}

这里要说明的是pMap->SetPermanent(m_hWnd = hWndNew, this);一句,它把我们IDC_EDIT1的句柄赋值给类CsuperEdit的数据成员m_hWnd [别忘了我们的CsuperEdit类是派生于Cedit的],大家可能现在已经隐约的明白了些什么,不错,在m_edit.SetWindowText("<请输入A、B、C>");中正是通过这个数据成员m_hWnd实现对IDC_EDIT1控制的:
void CWnd::SetWindowText(LPCTSTR lpszString)
{
ASSERT(::IsWindow(m_hWnd));

if (m_pCtrlSite == NULL)
::SetWindowText(m_hWnd, lpszString);
else
m_pCtrlSite->SetWindowText(lpszString);
}
其它CEdit类的函数也都是围绕 “m_hWnd + API函数” 进行包装的。
而我们常用的DDX_Control方法说到底也是调用SubclassWindow。

怎么样?第一个问题的来龙去脉搞明白了吧?

现在看看第二个问题:CSuperEdit类为什么可以处理WM_CHAR消息?
可能有的朋友现在疑惑,虽然通过句柄实现了m_edit对IDC_EDIT的控制,但发送给它的消息照样跑到EDIT的标准处理函数中,对WM_CHAR的处理是如何实现的呢?
如果消息照样跑到EDIT的标准处理函数中,那当然是不能处理了!不知您有没有看到在上面的SubclassWindow函数中有这么一小段我加了重点标示:
// now hook into the AFX WndProc
WNDPROC* lplpfn = GetSuperWndProcAddr();
WNDPROC oldWndProc = (WNDPROC)::SetWindowLong(hWnd, GWL_WNDPROC, (DWORD)AfxGetAfxWndProc());
ASSERT(oldWndProc != (WNDPROC)AfxGetAfxWndProc());

if (*lplpfn == NULL)
*lplpfn = oldWndProc;   // the first control of that type created
再和我们开始讲到的SDK中子类化机制联系起来,明白了吧?MFC在这里神不知鬼不觉的搞起偷天换日的勾当!
这个AfxGetAfxWndProc()函数是这样的:


WNDPROC AFXAPI AfxGetAfxWndProc()
{
#ifdef _AFXDLL
return AfxGetModuleState()->m_pfnAfxWndProc;
#else
return &AfxWndProc;
#endif
}
读过侯捷先生《深入浅出MFC》的朋友不知还是否记得MFC的命令路由机制正是以这个函数为起点的!
这样当程序收到发给Edit的WM_CHAR时,本应调用EDIT标准窗口处理函数,现在被改为调用LRESULT CALLBACK AfxWndProc(HWND hWnd, UINT nMsg, WPARAM wParam, LPARAM lParam)了,然后WM_CHAR消息进行一系列的流窜,最终成功到达我们的处理函数CSuperEdit::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags),至于是如何流窜的、怎么到达的请参考《深入浅出MFC》[如果您的书是繁体电子版,请从566页读起]。

终于,我们走出了FMC子类化的迷宫。


CSDN 烤鸡翅膀
2002-12-3
[FINISH]

PS:本人才疏学浅,如果说得有什么让人“笑得露齿”的地方,一定要通知我呦。

#3


很好!
继续努力!

#4


谢谢。

#5


佩服

#6


学习

#7


好样的,继续来!

#8


嗯,做个记号先……

#9


m

#10


没什么!

#11


up

#12


up

#13


收藏

#14


study

#15


也收藏

#16


mark

#17


void CSuperEdit::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags) 
{
// TODO: Add your message handler code here and/or call default

TCHAR ch[20];
GetWindowText(ch,20);
if(::isalpha(nChar))
 {
//make all the input characters are the uppercase!
::CharUpper((char*)&nChar);
if(strlen(ch)==0&&(nChar>='A')&&(nChar<='C'))
//must call the defWindowProc() to send the nChar!
this->DefWindowProc(WM_CHAR, nChar , MAKELPARAM (nRepCnt, nFlags ));
 }
else if(nChar==VK_BACK)
CEdit::OnChar(nChar, nRepCnt, nFlags);

}
-----------------------------
你的CSuperEdit实现的有点问题!

#18


学习
呵呵

#19


太太感谢了!我可以给你分吗!向这种前辈学习!


传道授业解惑------------------师之道也!
希望下个星期再能看见你的“消息处理机制和各种实现实例”的“大作”
那就更是感激不尽了!

#20


To psusong(人类失去指针,世界将会怎样?) :
是的,你说的对.您采用的方法会更好.
我由开始写文章到提交,包括那个小实例,一共花了不到2小时.

#21


good and up

#22


收藏!
谢谢!

#23


呵呵.......

#24


mark

#25


mark

#26


文档中心里有吧?是你写的?

#27


To njtu_shiyl(玉晶):
是地。

#28


mark

#29


mark

#30


mark

#31


mark

#32


敬佩!

#33


pfpf.多写点好东西共享哈。

#34


佩服

#35


谢谢各位支持……
更多我的文字请看:
http://www.csdn.net/develop/author/netauthor/mahongxi/

#36


应该是不需要EN_SETFOCUS消息

#37


佩服,高人!

#38


学习

#39


支持

#40


上网匆匆,不过还好,收藏!

#41


(不好意思,我见了什么都喜欢提反面意见,仅供交流)

在对象实例对某个窗体句柄子类化(亦称:超类化)后,系统提供了这样两种能力:
1.我们对该对象实例调用函数将会直接改变相关窗体句柄对应的窗体
2.系统的对传给该窗体句柄的消息会先经过对象实例的消息映射


对象实例对某个窗体句柄子类化的过程可用以下代码(在CProg1Dlg::OnInitDialog中,CSuperEdit m_edit;为CProg1Dlg的成员变量)表示:
HWND hWndControl = ::GetDlgItem(pParent->m_hWnd, IDC_EDIT1);
m_edit.SubclassWindow (hWndControl);

这样子类化处理以后:
当我们调用m_edit.SetWindowText("<请输入A、B、C>");,后IDC_EDIT1窗体上对应的文字就会改变为"<请输入A、B、C>"

当用户在IDC_EDIT1窗体中敲键盘时,系统会调用CSuperEdit::OnChar函数

#42


所有的秘密都在CWnd::SubclassWindow 中,让我们查看一下SubclassWindow 做了些什么吧,以下是函数体(在WINCORE.CPP文件内):
BOOL CWnd::SubclassWindow(HWND hWnd)
{
  if (!Attach(hWnd))
     return FALSE;

   // allow any other subclassing to occur
  PreSubclassWindow ();

  // now hook into the AFX WndProc
  WNDPROC* lplpfn = GetSuperWndProcAddr();
  WNDPROC oldWndProc = (WNDPROC)::SetWindowLong(hWnd, GWL_WNDPROC, (DWORD)AfxGetAfxWndProc());
  ASSERT(oldWndProc != (WNDPROC)AfxGetAfxWndProc());
  return TRUE;
}

结合注释不难理解PreSubclassWindow 是非功能性的函数,所以我们只要研究两个函数就可以了解CWnd::SubclassWindow 的大概功能
CWnd::Attach和 ::AfxGetAfxWndProc

#43


两者中其中CWnd::Attach 对应于实现了功能1,即“我们对该对象实例调用函数将会直接改变相关窗体句柄对应的窗体”
::AfxGetAfxWndProc函数对应于实现了功能2,即“系统的对传给该窗体句柄的消息会先经过对象实例的消息映射”


CWnd::Attach 的函数体如下:
BOOL CWnd::Attach(HWND hWndNew)
{
  if (hWndNew == NULL)
     return FALSE;

  CHandleMap* pMap = afxMapHWND(TRUE); // create map if not exist

  ASSERT(pMap != NULL);
  pMap->SetPermanent(m_hWnd = hWndNew, this);
  return TRUE;
}
最关键的是m_hWnd = hWndNew 一句,显然只要我把窗体的句柄保存下来,那我就可以唯一地指定一个窗体,然后对该窗体进行操作
是的,思路就是这么简单。我们现在看到CWnd(别忘了CsuperEdit 是从CWnd继承的,这里的CWnd实际就是CsuperEdit )在Attach 函数中把IDC_EDIT1 的句柄保存在了成员变量m_hWnd 中,那么实现功能1,自然也就不在话下了
至于CHandleMap::SetPermanent 函数则是用来延长句柄的使用期的,于“超类化”无关,具体实现可参考WINHAND_.H文件


该看::AfxGetAfxWndProc 函数与功能2的实现,但是只看楼主的文章却无法得知如何实现这第二个功能,我只有等楼主在发文时再做总结了,就此搁笔

#44


up

#45


up~~~~~~~~~~~

#46


我们知道Window操作系统中是没有CWnd 类的,也没有类的继承、重载等概念的,而另一方面,我们所做的只是编写CsuperEdit::OnChar 函数,填写了CsuperEdit类的消息映射。那么“超类化”是如何让操作系统在接受到按键消息后找到CsuperEdit::OnChar 函数的呢?以下我就讨论这个问题:


// 窗体句柄的GWL_WNDPROC属性
在前面的讨论中,我说过这个过程是跟::AfxGetAfxWndProc 有关的,该函数的实现是这样的:
WNDPROC AFXAPI AfxGetAfxWndProc()
{
#ifdef _AFXDLL
return AfxGetModuleState()->m_pfnAfxWndProc;
#else
return &AfxWndProc;
#endif
}

这是指在DLL中调用的话返回AfxGetModuleState()->m_pfnAfxWndProc;否则返回AfxWndProc 函数的地址。于是超类化所做的事可以简化为::SetWindowLong(hWnd, GWL_WNDPROC, (DWORD)&AfxWndProc);
该函数的作用是把窗体句柄hWnd的GWL_WNDPROC属性设置为AfxWndProc的地址,那么现在的问题转化为:窗体句柄的GWL_WNDPROC属性是干什么用的?其实不用我说,大家都猜得到(因为我们一直在讨论窗体的消息嘛,而且我也一直在说AfxWndProc是一个函数),它的作用是窗体消息的处理函数
对于该属性更准确地描述如下:对于发给窗体的所有消息,Windows操作系统将会以该消息为参数调用窗体句柄的GWL_WNDPROC属性所指定的函数

#47


// 被传递到MFC环境中
(以下叙述参考侯捷老师《深入浅出MFC》中的“消息映射与命令传递”一章的“两万五千里长征”一节)
LRESULT CALLBACK AfxWndProc(HWND hWnd, UINT nMsg, WPARAM wParam, LPARAM lParam)
{
 // special message which identifies the window as using AfxWndProc
 if (nMsg == WM_QUERYAFXWNDPROC)
  return 1;

 // all other messages route through message map
 CWnd* pWnd = CWnd::FromHandlePermanent(hWnd);
 return AfxCallWndProc(pWnd, hWnd, nMsg, wParam, lParam);
}

如上所列::AfxWndProc 整个函数只有四行,显然它仅仅是包装了::AfxCallWndProc 函数,只是把hWnd参数包装成pWnd,然后转道::AfxCallWndProc。
::AfxCallWndProc该函数才是真正做了一些事的,但其中与消息映射有关直接关系的就一句:
LRESULT AFXAPI AfxCallWndProc(CWnd* pWnd, HWND hWnd, UINT nMsg,
WPARAM wParam = 0, LPARAM lParam = 0)
{
 ...

 // delegate to object's WindowProc
 lResult = pWnd->WindowProc(nMsg, wParam, lParam);

 ...
 return lResult;
}

现在我们通过::AfxWndProc/::AfxCallWndProc两个函数的接力,已经看到操作系统中消息是如何被传递到MFC环境中的,把所有的目光都集中到LRESULT CWnd::WindowProc(UINT message, WPARAM wParam, LPARAM lParam);

#48


// 总结
现在我们看到转机了:为了实现不同的函数调用,OOP(面对对象编程)本身提供继承、虚函数之类的许多的方法。CsuperEdit 是继承自CEdit,CEdit 又继承自CWnd,我们要让程序调用CsuperEdit::OnChar也就没什么技术难度
比如,可以在CWnd中写一个响应键盘消息的虚函数 virtual void CWnd::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags);
在CWnd::WindowProc 中调用OnChar,那现在我写了CsuperEdit::OnChar 函数之后,程序自然就会调用我写的函数了

微软为了减小程序文件的体积,做了一些优化工作,它未用virtual 修饰符来修饰所有的函数,而是把一个要响应的消息和相应的响应函数登记在一张MESSAGE_MAP 里。
在AFXMSG_.H文件中ON_WM_CHAR 宏定义被为{WM_CHAR, 0, 0, ... &OnChar},它的作用就是把当前类(现在指CsuperEdit)的OnChar函数,填加到了MESSAGE_MAP 登记表中
既然有了MESSAGE_MAP 这样的登记表,对于“让CWnd在接受到WM_CHAR 消息时调用CsuperEdit::OnChar”的算法和代码,估计你我都能实现,我在此处就不再罗嗦,请参考“深入浅出”一书
(Panr 2002-12-13 12:00)

#49


学习

#50


#ifndef _AFX_NO_OCC_SUPPORT
if (pParent->m_pCtrlCont != NULL)
{
    // normal dialog control not found
    COleControlSite* pSite = pParent->m_pCtrlCont->FindItem(nID);
    if (pSite != NULL)
   {
ASSERT(pSite->m_hWnd != NULL);
VERIFY(SubclassWindow(pSite->m_hWnd));
         if (pParent->m_hWnd != ::GetParent(pSite->m_hWnd))
    AttachControlSite(pParent);
         return TRUE;
   }
#endif
-------------------------------------
这一小片代码上面好像都没提到,我来补充一下。
当你的Edit不是一个普通的windows窗口,而是ole容器中的一个控件/com组建的时候,消息处理的方法略微复杂一些。
首先,你要在你的容器中(比如COleDocument派生的文档/视图)通过ID取得你的控件现场(COleControlSite),然后从其中提取出你需要的hWnd;
然后继续进入SubclassWindow(),使得hWnd得以保存;
最后,判断控件是否是运行时不可见得(比如vb中的定时器),如果是,
需要调用AttachControlSite(pParent)来保存父窗口,使容器在运行态下可以控制控件行为。

upup

推荐阅读
  • 本文深入探讨了 MXOTDLL.dll 在 C# 环境中的应用与优化策略。针对近期公司从某生物技术供应商采购的指纹识别设备,该设备提供的 DLL 文件是用 C 语言编写的。为了更好地集成到现有的 C# 系统中,我们对原生的 C 语言 DLL 进行了封装,并利用 C# 的互操作性功能实现了高效调用。此外,文章还详细分析了在实际应用中可能遇到的性能瓶颈,并提出了一系列优化措施,以确保系统的稳定性和高效运行。 ... [详细]
  • PHP中元素的计量单位是什么? ... [详细]
  • 本文介绍了如何通过掌握 IScroll 技巧来实现流畅的上拉加载和下拉刷新功能。首先,需要按正确的顺序引入相关文件:1. Zepto;2. iScroll.js;3. scroll-probe.js。此外,还提供了完整的代码示例,可在 GitHub 仓库中查看。通过这些步骤,开发者可以轻松实现高效、流畅的滚动效果,提升用户体验。 ... [详细]
  • 本题库精选了Java核心知识点的练习题,旨在帮助学习者巩固和检验对Java理论基础的掌握。其中,选择题部分涵盖了访问控制权限等关键概念,例如,Java语言中仅允许子类或同一包内的类访问的访问权限为protected。此外,题库还包括其他重要知识点,如异常处理、多线程、集合框架等,全面覆盖Java编程的核心内容。 ... [详细]
  • 如何在 Java LinkedHashMap 中高效地提取首个或末尾的键值对? ... [详细]
  • 进程(Process)是指计算机中程序对特定数据集的一次运行活动,是系统资源分配与调度的核心单元,构成了操作系统架构的基础。在早期以进程为中心的计算机体系结构中,进程被视为程序的执行实例,其状态和控制信息通过任务描述符(task_struct)进行管理和维护。本文将深入探讨进程的概念及其关键数据结构task_struct,解析其在操作系统中的作用和实现机制。 ... [详细]
  • C#编程指南:实现列表与WPF数据网格的高效绑定方法 ... [详细]
  • 深入解析Gradle中的Project核心组件
    在Gradle构建系统中,`Project` 是一个核心组件,扮演着至关重要的角色。通过使用 `./gradlew projects` 命令,可以清晰地列出当前项目结构中包含的所有子项目,这有助于开发者更好地理解和管理复杂的多模块项目。此外,`Project` 对象还提供了丰富的配置选项和生命周期管理功能,使得构建过程更加灵活高效。 ... [详细]
  • 本文深入探讨了RecyclerView的缓存与视图复用机制,详细解析了不同类型的缓存及其功能。首先,介绍了屏幕内ViewHolder的Scrap缓存,这是一种最轻量级的缓存方式,旨在提高滚动性能并减少不必要的视图创建。通过分析其设计原理,揭示了Scrap缓存为何能有效提升用户体验。此外,还讨论了其他类型的缓存机制,如RecycledViewPool和ViewCacheExtension,进一步优化了视图复用效率。 ... [详细]
  • 如何在Spark数据排序过程中有效避免内存溢出(OOM)问题
    本文深入探讨了在使用Spark进行数据排序时如何有效预防内存溢出(OOM)问题。通过具体的代码示例,详细阐述了优化策略和技术手段,为读者在实际工作中遇到类似问题提供了宝贵的参考和指导。 ... [详细]
  • 本文介绍了Android动画的基本概念及其主要类型。Android动画主要包括三种形式:视图动画(也称为补间动画或Tween动画),主要通过改变视图的属性来实现动态效果;帧动画,通过顺序播放一系列预定义的图像来模拟动画效果;以及属性动画,通过对对象的属性进行平滑过渡来创建更加复杂的动画效果。每种类型的动画都有其独特的应用场景和实现方式,开发者可以根据具体需求选择合适的动画类型。 ... [详细]
  • 计算 n 叉树中各节点子树的叶节点数量分析 ... [详细]
  • 深入解析 Django 中用户模型的自定义方法与技巧 ... [详细]
  • 本文详细探讨了Java集合框架的使用方法及其性能特点。首先,通过关系图展示了集合接口之间的层次结构,如`Collection`接口作为对象集合的基础,其下分为`List`、`Set`和`Queue`等子接口。其中,`List`接口支持按插入顺序保存元素且允许重复,而`Set`接口则确保元素唯一性。此外,文章还深入分析了不同集合类在实际应用中的性能表现,为开发者选择合适的集合类型提供了参考依据。 ... [详细]
  • 成功实现Asp.Net MVC3网站与MongoDB数据库的高效集成
    我们成功地构建了一个基于Asp.NET MVC3框架的网站,并实现了与MongoDB数据库的高效集成。此次更新不仅完善了基本的创建和显示功能,还全面实现了数据的增删改查操作。在创建功能方面,我们修复了之前代码中的错误,确保每个属性都能正确生成。此外,我们还对数据模型进行了优化,以提高系统的性能和稳定性。 ... [详细]
author-avatar
大鱼
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有